macOSやXcodeを更新する際は、CodeQLが解析に使う環境の確認も必要です。アプリのビルドが通ることと、CodeQLが解析用の情報を取り込めることは別です。

GitHubは2026年10月19日の公式告知で、macOS 27、Xcode 27、Swift 6.4に関する制約と、スキャンを続けるための選択肢を示しました。ビルド追跡の対象として挙げているのは、C/C++、C#、Go、Java、Kotlin、Swiftです。[3]

影響を受ける環境と言語を分ける

告知の条件は次のように分かれています。

条件告知にある扱い
Xcode 27がインストールされている上記6言語の追跡型抽出（traced extraction）は利用不可
macOS 27を使う同じ言語群で追跡型抽出を利用できない可能性がある
Swift 6.4を解析するプラットフォームを問わずCodeQL非対応[6]
IntelベースMacを使う2026年12月中旬にサポートが非推奨となる予定。告知はその時点での即時終了を示していない[5]

追跡型ビルドを続ける案内は、macOS 26以前かつXcode 26以前への固定です。C/C++、C#、Javaには、ビルド追跡を使わないnoneという選択肢もあります。[7, 8]

Xcode 27とmacOS 27では、告知の表現が異なります。また、ビルド追跡の制約と、IntelベースMacの非推奨化は別の条件です。前者はOSやXcodeの版、後者は機種のサポート方針として説明されています。[5]

10月9日の先行告知では、コンパイル言語のautobuildとmanualは、macOS 27ではXcodeの版を問わず非対応と説明しています。macOS 26でも、Xcode 27を選んだ場合は非対応としています。影響表は10月19日の告知の表現を示しています。

理由についてGitHubは、CodeQLがビルド追跡に使う一部のシステムバイナリやライブラリから、AppleがIntel（x86_64）コードを外したためと説明しています。これは解析を実行する環境側の変更です。[3]

ビルドコマンドの指定と、ビルド追跡を分ける

CodeQLの解析は、コードから解析用のデータベースを作り、クエリで問題を調べる流れです。ビルドを使う解析では、ビルド過程を監視して必要な情報を抽出器へ渡し、抽出器が入力ファイルごとの関係データとソース参照を作成します。[1]

ビルドモードは、解析用データベースを作る方法の指定です。[2]

モードデータベースを作る方法
noneプロジェクト全体をビルドせず、コードベースから作る
autobuildビルド方法などを自動検出し、言語ごとの処理で作る
manualワークフローに指定したビルドコマンドを使う

manualは、実行するビルドコマンドを指定する方法です。追跡型抽出を使う構成では、manualでもビルドを監視して情報を集めるため、今回のシステム側の制約が残ります。[4]

autobuildが行う処理は言語ごとに異なります。たとえばGoの公式説明では、既定でリポジトリ内のGoコードを抽出し、指定したビルドでコンパイルされたファイルだけに対象を限定するには別途ビルド追跡が必要とされています。利用者は、抽出されるファイルの範囲と対応環境を、自分の構成に照らして確認します。

環境を固定するか、noneを選ぶか

Swiftのスキャンや、他言語の追跡型ビルドを続ける場合、GitHubはmacOS 26以前かつXcode 26以前への固定を案内しています。GitHub Actionsでは、ランナーイメージとツールチェーンの両方が対象です。[7] Swift 6.4の非対応は独立した条件なので、OSとXcodeを固定しても、Swift 6.4は解析対象になりません。[6]

自分でActionsのワークフローを管理する構成では、runs-onをmacos-26などの世代ラベルで指定し、macos-latestのような移動するラベルへの依存を避ける方法があります。ただし、世代ラベルだけでイメージのビルド番号やツールのバージョンまでは固定できません。実行ログの「Set up job」で「Runner Image」を開き、ログ内の「Included Software」リンクをたどる手順に従って、その実行で使われたイメージを確認します。選択中のXcodeは、xcodebuild -versionの出力と照合します。[12] 10月19日の告知は「Xcode 27がインストールされている」場合を条件にしているため、選択中のXcodeだけでなく、実行イメージにXcode 27が含まれるかも確認します。[3]

別の選択肢がビルド追跡を必要としないnoneです。今回の告知が案内するのはC/C++、C#、Javaへの適用です。Go、Kotlin、Swiftには同じ代替策を使えません。[8]

JavaとKotlinが混在する構成は、特に区別が必要です。java-kotlinにbuild-mode: noneを指定すると、解析されるのはJavaだけで、Kotlinには警告が出ます。Kotlinも解析したい構成では、noneに変えてジョブを成功させるだけでは目的を満たせません。[11]

noneへ変えた後の解析範囲を確認する

言語別の公式仕様によると、noneにも、通常のビルドから得る情報を別の方法で補う処理があります。JavaはGradleやMavenから依存情報を照会しますが、通常のビルド自体は行いません。C#では依存関係の復元と、一部の補助ソース生成を行います。[9]

C#のnoneでは、公式の依存解決条件も確認します。パブリックインターネットまたはプライベートNuGetフィードへのアクセスが必要で、依存復元やソースのコンパイルに問題があると解析精度に影響します。

Javaでは、依存情報を取得できず推定を誤った場合や、通常のビルド中にコードを生成する構成で、解析の範囲や精度に影響が出ます。[10] C/C++では、ヘッダーにない独自マクロへ強く依存する場合や、外部依存が多い場合に精度が下がることがあります。[9] ビルドモードを変えた際は、従来取り込んでいたコードや依存情報を維持できたかを確認する必要があります。

以下は、今回の環境・モード変更について本記事で提案する点検の順序です。自分でCodeQLワークフローを管理している場合は、設定と実際の解析結果を次の順に照合してください。

  1. 対象言語とモード ワークフローの公式設定例と照合し、言語のmatrixやinitのlanguages、build-modeを読み、解析したい言語が指定されているかを確かめます。JavaとKotlinが混在する場合は、Kotlinを解析できないという警告も確認します。[11]
  2. ビルド対象と生成工程 手動のビルド手順を指定する構成では、実行するコマンドや対象、必要なソースを生成する工程を点検します。autobuildでは、言語ごとの処理と対象範囲を確認します。[2]
  3. 抽出の診断 データベース作成時のextraction errorsやwarningsを調べ、取り込めなかったコードがないかを確認します。これらのログは抽出漏れを調べる手掛かりであり、ジョブの成否だけで解析対象を判断しません。[14]

解析された範囲が分からない場合は、公式の診断手順にあるinitのdebug: trueでCodeQLデータベースのアーティファクトを取得し、src.zipに入ったソースとリポジトリの実ファイルを比べる方法もあります。ソースコードを含むアーティファクトなので、保存先と共有範囲も確認します。[13]