Swift 6.2.4 へ上げたいのに、CodeQL の解析が止まるのは避けたい。そんな現場にとって、2026年3月31日に公開された GitHub Changelog の更新は重要です。CodeQL 2.25.0 は、Swift 6.2.4 でビルドされたアプリの解析をサポートしました。GitHub.com の Code scanning 利用者には新しい CodeQL が自動展開されるため、多くのチームでは Swift の更新後も解析を継続しやすくなります。一方で、GHES、CodeQL CLI を自前管理している CI、macOS ランナー不足、手動ビルド設定の不整合は別の停止要因として残ります。つまり今回のニュースは、単なる対応表の更新ではなく、Swift 開発のセキュリティ解析基盤を止めにくくするアップデートとして見るのが実務的です。 (The GitHub Blog)
CodeQL が Swift 6.2.4 に対応、iOS / macOS 開発の解析基盤は止まらないか
結論から言えば、GitHub.com で標準的な Code scanning を使っている Swift プロジェクトなら、今回の対応で解析基盤はかなり止まりにくくなると考えてよいです。CodeQL は GitHub の code scanning を支える静的解析エンジンで、今回の 2.25.0 では Swift 向けの主要改善として「Swift 6.2.4 を解析可能にした」ことが案内されています。GitHub.com では新しい CodeQL が自動展開されるため、Swift ツールチェーンの更新に解析側が追従しやすいからです。逆に、GHES や外部 CI で CodeQL を明示的に管理している場合は、その恩恵が自動では届かない可能性があります。 (GitHub Docs)
CodeQL 2.25.0 で実際に変わったこと
GitHub の Changelog では、CodeQL 2.25.0 について「Swift 6.2.4 をサポート」と明記されています。CodeQL 本体の changelog でも、Swift の主要改善として「Swift 6.2.4 を解析できるようにした」と記載されています。あわせて GitHub 側は、2.25.1 も利用可能だが、そちらは軽微なバグ修正だけだと案内しています。つまり、今回の本題は 2.25.0 系での Swift 6.2.4 対応です。 (The GitHub Blog)
| バージョン | Swift まわりの主な告知 | 実務上の見方 |
|---|---|---|
| CodeQL 2.24.0 | Swift 6.2.2 / 6.2.3 のサポート | Swift 6.2 系への追従を進めた段階 |
| CodeQL 2.25.0 | Swift 6.2.4 のサポート | 6.2 系の最新パッチまで追従した段階 |
この流れを見ると、今回の更新は「Swift 6.2 系を現場で使い続けるための追従」であり、Swift 開発者にとっては新しい目玉機能よりも解析の継続性を支えるアップデートと捉えるのが自然です。 (The GitHub Blog)
Swift 開発者への意味は「新機能追加」より「解析継続性」
CodeQL は、コードベースをデータベース化してクエリを走らせ、結果を GitHub 上の code scanning アラートとして表示する仕組みです。Swift は compiled language として扱われ、ビルドモードやランナー構成の影響を受けます。つまり、言語やツールチェーンの更新に解析側が追従できないと、検出精度以前に「そもそも解析が回り続けるか」が運用上の課題になりやすいのです。今回の Swift 6.2.4 対応の価値は、まさにそのボトルネックを一つ減らした点にあります。 (GitHub Docs)
環境ごとに受ける影響は違う
| 利用形態 | 影響の大きさ | まずやること |
|---|---|---|
| GitHub.com の default setup | 影響は比較的小さい | 最新のスキャンが成功しているか確認する |
| GitHub Actions の advanced setup | 中程度 | macOS ランナー、autobuild / manual、依存関係インストールを確認する |
| GHES / 既存 CI / CodeQL CLI 管理環境 | 大きい | CodeQL の実バージョンを確認し、必要なら手動アップグレードを検討する |
この差が生まれるのは、GitHub.com では新しい CodeQL が自動展開される一方で、GHES には将来のリリースで取り込まれる形になるからです。また Swift 解析は macOS ランナーとビルド設定に依存するため、ワークフローを細かく触っている環境ほど確認項目が増えます。 (The GitHub Blog)
まず確認すべき3つのポイント
github.com か GHES か
最初に見るべきなのは、どこで CodeQL を動かしているかです。GitHub Changelog では、新しい CodeQL は GitHub.com の code scanning 利用者へ自動展開され、同じ機能は将来の GHES リリースにも含まれると説明されています。GHES を使っていて、しかも現行バージョンが古い場合は、Swift 6.2.4 対応を待つか、手動で CodeQL を上げる必要が出てきます。ここを見誤ると、「ニュースでは対応済みなのに、自社環境ではまだ動かない」というズレが起きやすいです。 (The GitHub Blog)
Swift 解析が macOS ランナーで動いているか
Swift の code scanning は macOS ランナーが前提です。GitHub Docs でも、ARC のランナーは Linux ベースのため Swift 解析をサポートしないと明記されています。さらに見落としやすいのが、default setup で larger runner を使うケースです。現時点では、default setup の larger runner で Swift 解析は利用できず、Swift を含むリポジトリでは self-hosted の macOS ランナーを追加するか、code-scanning ラベル付き larger runner へのアクセス設計を見直す必要があります。 (GitHub Docs)
build-mode と依存関係の扱い
Swift では none ではなく、autobuild または manual が前提です。GitHub Docs では xcodebuild と swift build の両方がサポートされ、ビルド時は単一アーキテクチャを対象にすることが推奨されています。また、CocoaPods や Carthage で管理している依存関係は、CodeQL データベース生成前に明示的にインストールする必要があります。つまり、Swift 6.2.4 対応だけ見て安心するのではなく、ビルドと依存関係の準備が今のワークフローに残っているかまで確認すべきです。 (GitHub Docs)
デフォルトセットアップなら、まずは「動き続けているか」を見る
default setup を使っているなら、最優先はワークフローを書き換えることではありません。GitHub Docs にある通り、default setup は言語・クエリスイート・スキャンのトリガーを自動で選び、必要に応じて編集もできます。Swift のように none build を使えない compiled language では、default setup は autobuild を使います。したがって、Swift 6.2.4 へ上げた後は、最新の push / pull request / 定期スキャンが成功しているか、アラートが継続して出ているかを先に確認するのが正解です。設定を大きく触るのは、失敗していると分かってからで十分です。 (GitHub Docs)
高度なセットアップやモノレポでは「言語行列」まで見る
advanced setup を使っている場合は、ワークフローの作り方が結果に直結します。GitHub Docs では、github/codeql-action/init@v4 に matrix.language を渡す形が推奨されており、言語ごとに並列実行できる構成が標準です。逆に languages を明示せず順次解析にすると、時間がかかるうえ、1言語の失敗で全体が失敗する可能性があります。Swift を含むモノレポや mixed-language リポジトリでは、swift を明示した行列構成にしておくと、今回のような言語バージョン追従の影響範囲を切り分けやすくなります。 (GitHub Docs)
セキュリティチェックの追従性は、クエリスイートの選び方でも変わる
今回の更新は、Swift 6.2.4 を解析できるようにしたことが主眼です。一方で、Swift 向けの CodeQL クエリ自体はもともと default と security-extended の両スイートで提供されています。GitHub Docs によると、default は高精度で false positive が少なく、security-extended はそれに加えて精度や重大度がやや低い追加クエリも走らせる構成です。つまり、互換性の確保は 2.25.0 が担い、どこまで広く拾うかはクエリスイート選びが担う、という役割分担で考えると判断しやすくなります。ノイズを抑えたいなら default、リスクの高いアプリでカバレッジを広げたいなら security-extended が候補です。 (GitHub Docs)
見落としやすい失敗ポイント
- Swift 6.2.4 対応のニュースだけ見て、ランナーが Linux のまま
Swift 解析はmacOS前提です。ARC ベースの Linux ランナーでは通りません。 (GitHub Docs) - default setup + larger runner なら速くて安心だと思い込む
現時点では、default setup の larger runner で Swift 解析はそのまま使えません。Swift リポジトリだけ self-hostedmacOSランナーを別に用意する判断が必要です。 (GitHub Docs) - 手動ビルドにしているのに、依存関係のインストールを省く
CocoaPods / Carthage 管理の依存関係は、CodeQL データベース生成前に明示インストールが必要です。 (GitHub Docs) - 多言語リポジトリで
languagesの切り分けをしていない
順次解析のままだと、1言語の失敗が全体失敗につながりやすくなります。 (GitHub Docs)
いま取るべき行動
- まず、自分の環境が GitHub.com / GHES / 外部 CI のどれかを確認する
- Swift 6.2.4 または対応する Xcode 更新後の 最新 Code scanning 実行結果 を確認する
- advanced setup なら
macOSランナー、autobuild/manual、依存関係インストール、swiftの言語行列 を点検する - 互換性確認の次に、
defaultのまま行くかsecurity-extendedへ広げるか をリポジトリのリスクで判断する
CodeQL 2.25.0 の Swift 6.2.4 対応は、派手な新機能というより、Swift チームのセキュリティ運用を止めないための更新です。GitHub.com を使っているなら、まずは「何かを変える」より「最新スキャンが正常に流れているか」を見るのが先です。GHES や自前 CI なら、ここを機に CodeQL の実バージョン、ランナー OS、ビルドモード、依存関係の扱いを棚卸ししてください。記事を読み終えたら、最初にやるべきことは一つです。直近の Code scanning 実行結果を開き、Swift 6.2.4 のブランチでアラートが継続して出ているかを確認することです。 (The GitHub Blog)
コメント