CodeQLでXcode 27のスキャンが阻まれたら？2026年修正ガイド

症状： Xcode 27のインストール時、C/C++、C#、Go、Java、Kotlin、Swiftの追跡式抽出が利用できないとGitHubが案内しています。互換性の告知を確認してください。

最短の対処： SwiftはSwift 6.4への更新を保留し、macOS 26以前とXcode 26以前の組み合わせに固定してから、分析結果まで検証します。C/C++、C#、Javaはbuild mode noneを候補にできますが、追跡式ビルドと同等だと決めつけず、カバレッジを確認してください。

このガイドの対象 GitHub ActionsとCodeQLのワークフローを管理し、環境更新後のスキャン失敗を切り分けるIT・プラットフォームエンジニア。 Swift/iOSのセキュリティ分析を担当し、Swift 6.4やXcode 27への対応を決めるセキュリティエンジニア。 Macビルドノードの構成と運用を計画する技術責任者。

最終更新：2026年10月24日。GitHubの2026年10月19日付告知と、現行のCodeQLコンパイル型言語ドキュメントを基に整理しています。

Swift 6.4のCodeQLスキャンはなぜ止まるのか

GitHubはCodeQLがSwift 6.4の分析に対応していないと明記しています。Swiftのコンパイルが成功しても、それだけではCodeQLによるセキュリティ分析が成立した証拠になりません。Swift 6.4を使う必要がある場合も、対応状況が確認できるまでは、該当リポジトリのスキャンを成功扱いにしないでください。

Swift/iOSプロジェクトでは、まずスキャン用のRunnerが使うmacOSとXcodeを確認し、macOS 26以前、Xcode 26以前の組み合わせに固定します。CodeQL告知にあるこの案内は、特定のMacノードだけの問題ではなく、Swift 6.4の非対応とは別に、追跡式ビルドの環境条件も満たすための対処です。

Xcode 27ではどのコンパイル言語の追跡式抽出が影響を受けるのか

Xcode 27をインストールすると、C/C++、C#、Go、Java、Kotlin、Swiftの追跡式抽出が利用できないとGitHubは告知しています。影響するのは、これらの言語についてCodeQLがビルド中の情報を追跡する方式であり、通常のビルドが通るかどうかとは別の判定です。Xcode 27 Runnerの公開情報も参照し、Runnerイメージの更新時期と実際のワークフロー設定を照らし合わせてください。

影響の切り分けでは、リポジトリで有効なスキャン言語、Runnerの実イメージ、選択されたXcode、CodeQLのビルドモードを一組として確認します。Xcodeの選択設定だけを見て、ホストにインストールされた実際のバージョンや、ワークフローが参照するRunnerイメージを見落とすと、修正後も互換性のない環境でジョブが動くことがあります。

まず記録する項目

• スキャン対象のリポジトリと有効なCodeQL言語
• ジョブが割り当てられたRunnerイメージと、実際に選択されたXcode
• CodeQLのビルドモードと、ビルド・抽出・分析の各ステップの結果
• データベース生成、分析結果、SARIFアップロードの有無

この一覧は、CI設定だけでなく実行ログや成果物で埋めてください。GitHubのコンパイル型言語のビルドオプションでは、言語やビルド方式により利用できる選択肢と制約が異なります。

macOS 27とXcode 27をどう切り分けるか

macOS 27上では、関連する追跡式抽出が利用できない可能性もGitHubから示されています。ただし、これはmacOS 27を使うすべてのプロジェクトが必ず失敗する、という意味ではありません。Xcode 27のインストールによる制限と、macOS 27上での制限は、関連はしていても同一の条件ではありません。

まずRunnerの実イメージ、選択中のXcode、CodeQLのビルドモードを別々に記録します。その上で、受け持つワークロードごとに互換性を確認し、必要であればmacOS 26以前とXcode 26以前に固定したジョブを用意して再実行してください。環境を変更した場合は、ジョブの終了状態だけではなく、CodeQLデータベース、分析結果、アップロードされたSARIFをそれぞれ確認します。

チーム内でXcodeとmacOSのバージョン管理ルールを整える場合は、既存の企業向けXcode CloudとPRビルドの条件設定も参照し、ビルドの条件とセキュリティスキャンの合格条件を混同しないようにしてください。

build mode noneは追跡式ビルドの代替になるのか

C/C++、C#、Javaでは、追跡式ビルドを使わないbuild mode noneを評価できます。ただし、このモードは追跡式抽出と自動的に同等になるわけではなく、対象言語なら無条件で切り替えてよいという意味でもありません。適用範囲と制約はGitHubのビルドモード資料で確認してください。

切り替え前後では、CodeQLデータベースに期待するソースや依存情報が含まれているか、生成コードが分析対象に入っているか、結果の差分が許容できるかを確認します。生成コードの扱いがセキュリティ判断に関わる場合は、生成コードに対するアラートの説明も照合し、除外設定や検出結果の意味をレビューしてください。

次の順序で検証すると、単にビルド方式を変更しただけで不完全な分析を通してしまうリスクを抑えられます。

• 対象言語がbuild mode noneの検討対象に含まれることを確認する
• 変更前のビルドモードと分析結果を記録する
• 新しいモードでデータベースが生成されることを確かめる
• 依存情報や生成コードなど、プロジェクト固有の対象が含まれるか確認する
• 分析結果とSARIFを比較し、差分を担当者が承認する

SARIFファイルが生成されたとしても、アップロードまで成功したとは限りません。ワークフローの完了条件には、SARIFアップロードの仕様に沿ったアップロード状態を含めてください。

Intel Macに依存するスキャンはどう扱うか

Intel MacでCodeQLを動かしている場合は、Xcode 27の問題とは分けて移行計画に記録します。GitHubはIntel MacのCodeQLサポートを2026年12月中旬に非推奨とする予定を告知しています。この日程は、Xcode 27による追跡式抽出の制限を解消する方法ではありません。

該当するRunner、そこで動くスキャン、移行の責任者を一覧化し、実行環境の変更後にデータベースからSARIFアップロードまで再検証できる計画を立てます。Intel Macの対応終了予定とXcode 27の互換性問題を一つの移行チケットにまとめると、片方を修正しただけで両方が解決したと誤認するおそれがあります。

修正後のスキャンを完了と判断するチェック項目

パイプラインが緑色でも、スキャンの完全性を単独で証明するものではありません。次の項目をすべて確認してから、対象リポジトリのCodeQLスキャンを復旧済みと判断してください。

• [ ] スキャン対象の言語と、適用するビルドモードを確認した
• [ ] Runnerイメージ、macOS、選択中のXcodeをログで確認した
• [ ] Swiftを分析する場合、Swift 6.4を避け、対応する環境の組み合わせに固定した
• [ ] ビルドまたは抽出が完了し、期待するCodeQLデータベースが生成された
• [ ] 分析結果に必要なソース、依存情報、生成コードが含まれるかレビューした
• [ ] SARIFが生成され、GitHubへのアップロードが完了した
• [ ] Intel Mac依存の有無と、移行責任者を記録した

ワークロード別に選ぶ復旧経路

まずはリポジトリの言語、CodeQLのビルドモード、現在のRunnerとXcodeを照合してください。Mac上で動かす必要があるスキャンでも、既存の自社Macは調達や保守の負担があり、容量を固定すると一時的な検証用に余剰コストが生じることがあります。一方で、常時稼働の大きな負荷や物理インターフェースが必要なら、自社Macを維持する方が適する場合もあります。

短期間の検証や一時的なMac CI環境が必要で、既存の承載方法では用意しにくい場合は、KVMFLUXのリモートMacレンタルも比較対象になります。Macで実行すること自体がCodeQLの互換性を保証するわけではないため、利用を決める前に必要なXcodeとmacOS、CodeQLの組み合わせを確認し、企業向けMac CIの利用シーンを見て自社の運用条件に合うか判断してください。