CodeQL共通バンドル廃止予告：バージョンより先にOS・CPU別の導入経路を確認する
セキュリティ解析ツールのバージョンは更新していても、インストール用ファイル名は何年も同じかもしれません。独自CIや社内ミラーでCodeQLを取得するチームは、バージョンと取得先を一緒に確認しましょう。
GitHubは2026年9月22日、全プラットフォームをまとめたCodeQLバンドルの廃止を予告しました。本稿では公式の内容と、移行をレビュー可能にする実務上の提案を分けて説明します。
廃止予告と現在の障害を区別する
CodeQL CLI 2.27.0からcodeql-bundle.tar.gzとcodeql-bundle.tar.zstは非推奨となり、2027年3月中旬に削除予定です。対応するOSとアーキテクチャ別のバンドルが推奨されています。
Linux ARM64のバイナリはプラットフォーム別ダウンロードにのみ含まれます。ただし、既存の全ワークフローが今日から失敗するわけではありません。まず対象ファイルを直接取得しているか確認してください。
直接インストールする経路を探す
ワークフローのYAMLだけでは、コンテナーイメージ、初期化スクリプト、社内成果物リポジトリ内の導入を見落とせます。URLを組み立てる場所と解析を実行する環境を結び付けて一覧化します。
実行環境、OS、CPU、取得ファイル、キャッシュ場所、担当者を記録できます。これは公式要件ではなく運用上の提案です。秘密のトークンや内部アドレスを公開Issueに貼る必要はありません。
OS名だけで選ばない
同じLinuxでもx86-64とARM64は異なる実行対象です。ホストとコンテナーの環境を区別し、リリース資産の正確な名前で対応付けてください。不明な組み合わせを既定値に流さず失敗させる方が原因を追いやすくなります。
2.27.0ではLinux ARM64用CLIとバンドルが案内されています。しかし、ファイルの存在は全言語・全ビルド構成の対応を保証しません。現在の要件にはLinux ARM64のbeta表記があるため、適用条件も確認しましょう。
キャッシュに移行失敗を隠させない
ファイル名を変更しても、古いキャッシュが旧実行ファイルを返せば新経路の試験にはなりません。キーやミラーパスにバージョンとプラットフォームを反映し、初回検証では実際のファイルとCLIバージョンを記録します。
公式配布物と提供される完全性情報を使いましょう。検証済み資産を社内保管するなら、元のバージョンとプラットフォームも残します。異なるCPUで同じキャッシュ名を共有する場合は特に注意します。
起動成功から解析成功まで
CLIの起動だけで以前と同等とは判断できません。代表リポジトリの同じコミットでデータベース作成、クエリ、結果アップロードまで確認し、対象言語やビルドモードの抜けも比較します。
アプリのリファクタリングやクエリ方針変更を混ぜると差分の説明が難しくなります。導入経路の変更を独立してレビューし、予期しない結果はツールとパックの版、ビルドログから調べましょう。
まず一つの再現可能な経路から
小さなチームは最重要の独自CI一つからでも始められます。成功条件と戻す設定を記録し、ミラーや古いイメージの担当者にも同じ基準を共有すれば残りの範囲が明確です。
公開リリースやIssueは互換性調査の出発点ですが、他のリポジトリの成功は自分たちの検証の代わりにはなりません。本稿はコミュニティの総意や成功率を主張しません。
今日残す変更記録
PRには旧ファイル名、新しい対応表、実行環境、代表解析の結果を添えましょう。未確認の環境も明記すると、レビュー側が完了範囲を判断できます。
削除までに必要なのは警告を隠すことではなく、導入経路を変えて検証することです。正確な日付が追記される可能性もあるため、公式変更履歴と要件を再確認する担当者も決めてください。