Java 26移行とCodeQL運用を同時に成立させるための実装指針

Javaランタイム更新時に最も起こりやすい失敗は、「ビルドは通ったから安全性も維持されたはず」という思い込みです。実際には、CodeQLを含む解析基盤は、JDK変更・依存更新・CIイメージ変更の影響を強く受けます。移行期こそ、検知の抜け漏れが生まれやすい局面です。

なぜ移行期に検知品質が落ちるのか

Java 26への移行では、次の連鎖が発生します。

• ビルドプラグイン更新
• テスト基盤更新
• フレームワーク追従
• CIランナー変更

これらは解析DB生成やクエリ実行挙動に直接影響します。CI緑でも、解析同等性が崩れているケースは珍しくありません。

先に“二重ベースライン”を取る

移行前に現行JDKで以下を記録します。

• クエリ成功率
• 重大度/CWE別の検知件数
• 実行時間・タイムアウト率
• 上位誤検知率

移行後は同じ指標で比較し、急減・急増を理由付きで説明できる状態にします。特に「検知減少」は改善ではなく抽出失敗の可能性があります。

リポジトリを層別に移行する

• Tier1: 内部ツール・低重要度
• Tier2: 顧客向けだが非規制領域
• Tier3: 認証・決済・規制中核

Tierごとに“解析同等性ゲート”を満たしたら次へ進む方式が安全です。

CIに追加すべき検証

• CodeQL DB抽出完了の明示チェック
• 移行波ごとのquery pack固定
• 過去既知欠陥クラスに対するカナリアクエリ
• メモリ/時間劣化の閾値監視

カナリアクエリは特に有効です。既知パターンが急に消えたら、設定不整合を疑えます。

検知差分レビューを運用化する

新ランタイム対応で、クエリ精度は変化します。差分は次のように分類します。

• 期待差分（ルール改善による変化）
• 非期待差分（設定・抽出の異常）

分類結果をドキュメント化しないと、開発側はすべてを“ノイズ”として無視し始めます。

実行しやすい移行パターン

1. 旧JDK/新JDKの並走ビルド
2. 主要サービスでCodeQL二重実行
3. 週2回の差分審査会
4. 層別カットオーバーとロールバック条件明記

この進め方なら、移行速度を保ちながら検知品質を維持できます。

経営・管理層に示すべき指標

• 移行波別のセキュリティゲート通過率
• 事前ベースラインに対する検知同等率
• 解析ジョブ失敗率
• 新規高重大度の修正滞留日数

これらを“移行成功条件”に入れることで、品質と納期の対立を減らせます。

Java 26移行とCodeQL運用は別プロジェクトではありません。ひとつの変更プログラムとして設計した組織ほど、移行期の盲点を作らず安全に前進できます。