--- title: "GitHub Code Scanningとは？CodeQLの設定手順・対応言語・料金とAI Scan【2026年10月】" url: "https://www.issoh.co.jp/tech/details/5210/" published: 2025-02-06 updated: 2026-10-23 categories: ["GitHub"] publisher: "株式会社一創" --- # GitHub Code Scanningとは？CodeQLの設定手順・対応言語・料金とAI Scan【2026年10月】 GitHub Code Scanningは、リポジトリのコードを解析して脆弱性やコーディングエラーを見つけ、GitHub上にアラートとして表示する機能です。解析エンジンの中心はGitHub製の**CodeQL**で、SARIF形式を出力する他社ツールの結果も同じ画面に取り込めます。この記事では2026年10月時点の公式ドキュメントをもとに、無料で使える範囲と料金、default setupとadvanced setupの使い分け、CodeQL対応言語とPHPを補うAI Scan、CodeQLのライセンス条件を整理します。CodeQL 2.27.3で実際にサンプルを解析し、どんなアラートが出るかも確かめました。 ## まとめ：GitHub Code Scanningの要点 - **公開リポジトリは無料**。private・internalリポジトリで使うには**GitHub Code Security**（1アクティブコミッターあたり月30ドル）のライセンスが要り、GitHub TeamとGitHub Enterprise Cloudで購入できます。 - CodeQLをGitHub Actionsで実行する構成では**Actionsの分数を消費**します。外部CIで解析してSARIFだけをアップロードする構成も選べます。 - 始めるなら**default setup**。設定画面から有効にするとCodeQLの構成が自動生成され、既定ブランチへのpushとプルリクエストでスキャンします。週次の定期実行は、有効化後にpushかプルリクエストで解析が1回走ってから始まり、直近180日間にそうした解析が無いと止まります。 - CodeQLの対応はC/C++・C#・Go・Java/Kotlin・JavaScript/TypeScript・Python・Ruby・Rust・Swift・GitHub Actionsワークフロー。**PHPはCodeQL非対応**で、2026年10月15日に一般提供となったAI Scanがプルリクエストの差分だけを補います。Copilotのライセンスは不要ですが、Code Security AI Creditsを消費します。 - AI Scanの結果はプルリクエストの画面にだけ出て、マージは止められません。既存コード全体の点検やマージゲートが要る言語は、SARIFを出す他社ツールで受けるのが現実的な組み合わせです。 - CodeQL CLIを自前のCIで回す場合は**ライセンス条件**に注意が必要です。無料で自動解析に使えるのは「GitHub.com上でホストされるOSS」に限られます。 以下、仕組み→料金→対応言語とAI Scan→設定→検出結果の実例→アラート運用→構成別の選び方→失敗パターンの順に見ていきます。 ## GitHub Code Scanningの仕組みとCodeQLの位置づけ ### Code Scanningのアラート生成から修正後の自動クローズまでの流れ Code Scanningが問題の可能性があるコードを見つけると、リポジトリの「Security」タブにアラートが作られます。プルリクエストで検出された場合は、差分の該当行への注釈という表示形式です。コードを修正して再スキャンで検出されなくなれば、アラートは自動でクローズされます。スキャンのタイミングは、pushなどのイベント起点と、曜日・時刻を指定したスケジュール起点の2通りです。 ### CodeQLの解析方式：コードのデータベース化とクエリによる検出 CodeQLは、ソースコードを抽出して「CodeQLデータベース」を作り、そこへQL言語で書かれたクエリを流して脆弱なパターンを探す方式の静的解析エンジンです。たとえば「HTTPリクエストの入力が、無害化されないままSQL文の組み立てに流れ込む経路」をデータフロー（テイント解析）として関数やファイルをまたいで追跡できる点が、単一行のパターン照合との違いです。静的解析全般の位置づけは[SASTとDAST・SCAの違い](/tech/details/15880/)で整理しています。 CodeQL以外のツールも利用可能です。SARIF 2.1.0形式で結果を出力できるツールなら、GitHub Actions内で実行しても外部CIで実行しても、アップロードした結果がCodeQLのアラートと同じ画面に並びます。[Semgrep](/tech/details/12476/)のように自社ルールを書きやすいツールをCodeQLと併用する構成は、この仕組みで成り立っています。 ### Secret Protectionなど関連3製品との検査対象と守備範囲の違い GitHubのセキュリティ機能は名前が似ているため、何を見る機能なのかを先に切り分けておくと購入判断で迷いません。 | 機能 | 見る対象 | private向けの製品 | | --------------- | ----------------- | ------------------------ | | Code Scanning | 自分たちが書いたコードの脆弱性 | GitHub Code Security | | Dependabot | 依存パッケージの既知脆弱性 | 不要（全リポジトリで利用可） | | Secret scanning | コミットされたAPIキー・トークン | GitHub Secret Protection | | Code Quality | 保守性・信頼性の問題 | GitHub Code Quality | 依存ライブラリの脆弱性はCode Scanningでは拾えないため、[Dependabot](/tech/details/6796/)との併用が前提です。保守性の指摘まで広げたい場合は[GitHub Code Quality](/tech/details/9791/)が別製品として用意されています。 ## GitHub Code Securityの料金と公開・private別の利用条件 GitHubは2025年4月1日に、それまで一括販売していたGitHub Advanced Securityを**GitHub Secret Protection**（月19ドル）と**GitHub Code Security**（月30ドル）に分割しました。Code ScanningはCode Securityに含まれます（[GitHub Docs: About code scanning](https://docs.github.com/en/code-security/concepts/code-scanning/code-scanning)）。 | リポジトリ | Code Scanning | 費用 | | -------------------- | ----------------------- | ---------------- | | 公開（public） | 利用可 | 無料 | | private（個人アカウント） | 利用不可 | – | | private・internal（組織） | Code Securityのライセンスで利用可 | 月30ドル／アクティブコミッター | 課金単位の「アクティブコミッター」は、直近90日間にライセンス対象のリポジトリへpushされたコミットのコミッターを、重複なしで数えたものです（GitHub Appのボットは除外）。数え方や予算上限の設定は[GitHub Advanced Securityの料金と課金の数え方](/tech/details/5211/)で詳しく解説しています。 もう1つの費用がGitHub Actionsの実行時間です。default setupやadvanced setupでCodeQLをActions上で動かす場合は、スキャン1回ごとに分数を消費します。privateリポジトリではActionsの無料枠を超えた分が従量課金になるので、分単価は[GitHub Actionsの料金](/tech/details/16698/)で確認してください。 3つ目が**Code Security AI Credits**です。2026年10月15日に一般提供となったAI Scanとエージェント型autofix（どちらも後述）は、ライセンスとは別にこのクレジットを消費し、ライセンスが要らない公開リポジトリでも消費は発生します。Copilotの契約に含まれるAIクレジットがあればそちらから先に使われ、使い切った後は従量課金になります（[GitHub Docs: GitHub Advanced Security billing](https://docs.github.com/en/billing/concepts/product-billing/github-advanced-security)）。組織で有効にする前に、請求管理者が予算を設定しておくのが安全です。 購入前に影響を測りたい組織には、無料の**Code Security リスク評価**があります。直近90日のコミット活動をもとに最大20のprivate・internalリポジトリを選んでスキャンし、脆弱性の分布をまとめたレポートを得られる仕組みです。ライセンス料もActionsの分数もかからず、90日ごとに再実行できます。 ## CodeQLの対応言語とPHP・Terraformを検査する際の選択肢 ### CodeQL対応言語の10系統と解析時に選べるビルドモードの違い 2026年10月時点でCodeQLが解析できるのは次の10系統です。Rustは正式対応に移行済みで、GitHub Actionsのワークフローファイルも解析対象に入りました。 | 言語 | 指定キー | ビルドなし解析（none） | | ---------------------- | ----------------------- | ----------------- | | C/C++ | `c-cpp` | 対応 | | C# | `csharp` | 対応 | | Go | `go` | autobuildまたは手動ビルド | | Java/Kotlin | `java-kotlin` | Javaのみ対応 | | JavaScript/TypeScript | `javascript-typescript` | ビルド不要 | | Python | `python` | ビルド不要 | | Ruby | `ruby` | ビルド不要 | | Rust | `rust` | 対応 | | Swift | `swift` | autobuildまたは手動ビルド | | GitHub Actions（ワークフロー） | `actions` | ビルド不要 | コンパイル言語はビルドの扱いが3通りあります。`none`はビルドせずにソースから抽出する方式で、C/C++・C#・Java・Rustが対応しています。`autobuild`はCodeQLがビルドコマンドを推測する方式、`manual`は自分でビルド手順を書く方式です。Kotlinを含むプロジェクトやGo・Swiftでは、ビルドが通る環境を用意する必要があります。 ### PHP・Shell・Terraformを見るAI Scan（2026年10月GA） 「codeql php」で検索されることが多いのですが、**CodeQLはPHPに対応していません**。この空白を埋めるのがAI Scan for pull requestsです。2026年7月14日にパブリックプレビューで始まり、10月15日に一般提供（GA）になりました（[GitHub Changelog: AI Scan for pull requests generally available](https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/)）。対象として挙がっているのはPHP、Shell/Bash、Terraform（HCL）、Dockerfileに加え、JavaのJSPやC#のBlazorのようにCodeQLのフレームワーク対応が手薄な部分です。ドキュメントはこの一覧を例示としており、対象は今後変わり得ます。 GAで利用条件が変わりました。プレビュー中はGitHub Advanced SecurityとCopilotの両方のライセンスが必要でしたが、現在は**Copilotのライセンスが不要**です。 | リポジトリ | AI Scan | 課金 | | -------------------- | --------------------- | ------------- | | 公開（組織・個人） | 利用可（ライセンス不要） | AI Creditsを消費 | | private・internal（組織） | Code SecurityかGHASが必要 | AI Creditsを消費 | | private（個人アカウント） | 利用不可 | – | それでも、CodeQLの代わりにはなりません（[GitHub Docs: AI Scan for pull requests](https://docs.github.com/en/code-security/concepts/code-scanning/ai-powered-security-detections)）。 - 解析するのは**プルリクエストの差分だけ**です。リポジトリ全体のスキャンはできず、検出結果がSecurityタブのアラート一覧に残ることもありません。 - 結果は助言扱いで、Code Scanningのチェックを失敗させず、**マージを止めるrulesetにも使えません**。 - フォークからのプルリクエストとDependabotのプルリクエストでは動きません。 組織で有効にすると、Code Scanningが有効な対象リポジトリに設定が適用されます。クレジットを消費するのは、対応言語・フレームワークの変更を含む対象プルリクエストを実際に解析したときです。エンタープライズのポリシーの既定は「許可しない」です。CodeQLのdefault setupは前提ではなく、CodeQLの解析が失敗していても実行されます。 PHP資産の既存コード全体を点検したい場合は、AI Scanでは届きません。SARIFを出力できる他社の静的解析ツールを組み合わせるか、リリース前に[脆弱性診断・セキュリティ診断](/service/system/vulnerability/)を受けて既存コードの穴を洗い出す方が確実です。 ### AI Scanの有効化手順：エンタープライズ・組織・個人リポジトリの設定 AI Scanは、Code Scanningが有効で、かつリポジトリに効いているAI Scanの設定がオンのときに、プルリクエストで自動的に走ります。設定は上の階層から順に決まるので、誰がどこで操作するかを先に押さえておくと導入が止まりません。 1. **エンタープライズ**：エンタープライズオーナーが、配下の組織にAI Scanの有効化を許すかをポリシーで決めます。既定は「Not allowed」なので、エンタープライズに属する組織はここを変えない限り先へ進めません。 2. **組織**：組織オーナーかセキュリティマネージャーが、対象リポジトリでAI Scanを有効にします。リポジトリは組織の設定を引き継ぎます。 3. **組織所有のリポジトリ**：組織で有効になっていれば、リポジトリ管理者は個別にオプトアウトできます。逆に組織側が無効のときは、リポジトリだけでオプトインすることはできません。 4. **個人アカウントの公開リポジトリ**：リポジトリ管理者が、設定の「Code scanning」配下にある「AI Scan for pull requests」のトグルで切り替えます。 多数のリポジトリへ一括で適用したい場合は、REST APIのCode Scanning設定にある`ai-scan`の項目でも管理できます。使うモデルを選ぶ手順は無く、有効にすればそのまま動きます。 ### AI Scanの結果の見え方とAI Creditsの消費・予算切れの挙動 検出結果は、プルリクエストの「Conversation」タブと「Files changed」タブに、CodeQLのアラートと並んで表示されます。AI Scan由来の指摘には「AI」のラベルが付き、セキュリティ上のリスクの説明と、多くの場合は修正案も添えられる形式です。CodeQLとAI Scanのどちらの結果が先に出るかは、それぞれの解析が終わる順番で変わります。誤検知を含み得るため、指摘ごとに付いているサムアップ・サムダウンで評価を返せます。 課金の扱いは次のとおりです（[GitHub Docs: AI Scan for pull requests](https://docs.github.com/en/code-security/concepts/code-scanning/ai-powered-security-detections)）。 - 消費は、対象のプルリクエストが実際に解析された時点で発生し、アクティブコミッター単位のライセンスとは別に計上されます。 - 組織所有のリポジトリは、その組織の請求先に請求されます。個人アカウントの公開リポジトリは、組織やエンタープライズからCopilotのライセンスを受けている場合を除いて、個人アカウントへの請求です。 - 利用量は、エンタープライズの課金画面にある「AI usage」で「Advanced Security」製品として見られ、Code Security AI CreditsのSKU単位で予算を設定できます。 - 上限を超えると止まるハード予算でクレジットを使い切ると、**指摘は生成されなくなります**。チェックが失敗するわけではないので、黙って検出が止まる点に注意が必要です。 この最後の挙動は運用上の落とし穴になります。AI Scanの指摘が来ないプルリクエストが続いたら、「問題が無い」のか「予算が尽きた」のかを課金画面で切り分けてください。月初に予算の残量を確認する手順を、リリース前のチェックリストへ入れておくと見落としを防げます。 ## default setupの有効化手順と初回・週次解析の実行タイミング default setupを使えるのは、GitHub Actionsが有効で、かつリポジトリが公開されているかCode Securityが有効になっている場合です。手順は次のとおりです。 1. リポジトリの「Settings」を開き、サイドバーの「Advanced Security」へ進みます。 2. 「Code Security」の項目にある「CodeQL analysis」の右で「Set up」を開き、「Default」を選びます。 3. 自動生成された構成（解析する言語・クエリスイート）を確認し、必要なら「Edit」で変更します。 4. 「Enable CodeQL」を押すと、構成を試すワークフローが走り、初回の解析が始まります。 初回の解析の後は、既定ブランチと保護ブランチへのpush、それらのブランチを対象にしたプルリクエストの作成・更新（フォークからのものを除く）、週1回のスケジュール実行で起動します。 週次スケジュールの条件は2026年10月1日のドキュメント更新で明確になりました。週次スキャンが始まるのは、default setupを有効にした**後**にpushかプルリクエストでスキャンが1回走ってからです。直近180日間にpushかプルリクエスト起点のスキャンが無いと週次は止まり、次のpushやプルリクエストで再開します。初回スキャンや設定変更によるスキャンは「活動」に数えません。動きの無いリポジトリも定期的に見たい場合は、組織オーナーが設定すれば30日ごとにスキャンできます（[GitHub Docs: Code scanning setup types](https://docs.github.com/en/code-security/concepts/code-scanning/setup-types)）。 CodeQL対応言語を含まないリポジトリで有効化しても、スキャンは走らず分数も消費しません。後から対応言語のコードが既定ブランチに入った時点で自動的に解析が始まるので、組織の全リポジトリに一括で有効化しておく運用が公式にも推奨されています。セルフホストランナーで動かしたい場合は、ランナーに`code-scanning`ラベルを付けると割り当てられます。 ## advanced setupのワークフローとdefault setupとの使い分け ### advanced setupに移る4つの条件と既定設定で対応できる範囲 default setupでも、解析言語・クエリスイート（defaultかsecurity-extended）・脅威モデル・CodeQLモデルパックは変更できます。さらに組織のリポジトリプロパティで、`github-codeql-config-file`（CodeQLの設定ファイル）や`github-codeql-extra-queries`（追加クエリ）をdefault setupにも適用できます（[GitHub Docs: Repository properties for code scanning](https://docs.github.com/en/code-security/concepts/code-scanning/repository-properties)）。以前よりadvanced setupが必要な場面は減りましたが、次のどれかに当てはまるなら移行を検討します。 - Go・Swift・Kotlinなどで、独自のビルド手順を書かないと解析できない - 組織のプロパティではなく、リポジトリごとのワークフローでクエリや解析対象を書き分けたい - モノレポで、ディレクトリごとに解析範囲やスケジュールを分けたい - GitHub Actionsではなく、Jenkinsなど外部CIでCodeQLを回したい どれにも当てはまらないなら、default setupのままにしてください。advanced setupのワークフローは自分で保守する対象になり、アクションのメジャー更新（現行は`codeql-action` v4）にも自分で追随する必要があります。 ### codeql.ymlの最小構成と解析言語・実行権限を指定する設定例 GitHub公式のスターターワークフロー（CodeQL Advanced）を、TypeScriptとPythonのリポジトリ向けに絞るとこうなります。 ``` name: "CodeQL" on: push: branches: [ "main" ] pull_request: branches: [ "main" ] schedule: - cron: "27 3 * * 1" jobs: analyze: name: Analyze (${{ matrix.language }}) runs-on: ubuntu-latest permissions: security-events: write packages: read actions: read contents: read strategy: fail-fast: false matrix: include: - language: javascript-typescript build-mode: none - language: python build-mode: none steps: - name: Checkout repository uses: actions/checkout@v7 - name: Initialize CodeQL uses: github/codeql-action/init@v4 with: languages: ${{ matrix.language }} build-mode: ${{ matrix.build-mode }} # 初回導入では既定のクエリスイートを使用 - name: Perform CodeQL Analysis uses: github/codeql-action/analyze@v4 with: category: "/language:${{ matrix.language }}" ``` 要になるのは`permissions`の`security-events: write`です。これが無いと解析結果をアップロードできません。GITHUB\_TOKENの権限をリポジトリ既定で絞っている場合の考え方は[GitHub Actionsのpermissions](/tech/details/16937/)を参照してください。`category`は解析結果を区別して保存するための値です。Actionsのanalyzeステップでは省略しても自動で付くので、ここでは言語名が分かる値を明示しています。security-extendedに広げるときは、initステップの`with`に`queries: security-extended`を1行足します。 ### CodeQLの3種類のクエリスイートと検出範囲・誤検知による選択基準 | スイート | 内容 | default setup | | ---------------------- | ------------------------- | ------------------ | | `default` | 精度の高いセキュリティクエリのみ | 選択可（既定） | | `security-extended` | defaultに精度・重大度がやや低いクエリを追加 | 選択可（画面表記はExtended） | | `security-and-quality` | 拡張スイートに保守性・信頼性を追加 | 設定画面では選択不可 | スイートの差を量で見るため、CodeQL 2.27.3の同梱クエリパックに対して`codeql resolve queries`を実行し、各スイートに入るクエリ数を数えました（診断・集計用のクエリを除く）。数はGitHub Docsの言語別クエリ一覧の「Default」「Extended」列と一致しています。 | 言語 | default | security-extended | security-and-quality | | --------------------- | ------- | ----------------- | -------------------- | | Java/Kotlin | 66 | 110（+44） | 230 | | C/C++ | 50 | 87（+37） | 172 | | JavaScript/TypeScript | 85 | 101（+16） | 199 | | C# | 44 | 55（+11） | 156 | | Python | 41 | 48（+7） | 170 | | Ruby | 37 | 43（+6） | 46 | | GitHub Actions | 17 | 23（+6） | 27 | | Rust | 17 | 19（+2） | 21 | | Go | 33 | 34（+1） | 56 | | Swift | 24 | 25（+1） | 25 | security-extendedで増えるクエリは、JavaとC/C++では4割以上ですが、GoとSwiftでは1本だけです。ただし1本のクエリでも多くの箇所に当たり得るので、検出件数や誤検知の増加幅は対象コード次第です。security-extendedへの切り替え前後で結果を比較してください。Java・C/C++の既存コードに初めて当てるときは、defaultで始めて件数を見てから広げてください。 security-and-qualityが追加するのは保守性・信頼性のクエリで、セキュリティの検出範囲はsecurity-extendedと同じです。脆弱性の検出が目的ならdefaultかsecurity-extendedで足り、保守性の指摘を別に管理したい場合は[GitHub Code Quality](/tech/details/9791/)という製品もあります。 ## CodeQL CLIとSARIFによる外部CI・他社ツールとの連携 ### CodeQL CLIでのデータベース作成から解析結果のアップロードまでの手順 GitHub Actionsを使わない場合は、CodeQL CLI（2026年10月20日公開のv2.27.3が最新）を外部CIに組み込み、SARIFをアップロードします。下の例は、CLIとクエリパックを導入済みで、リポジトリのルートで実行し、`security-events`への書き込み権限を持つトークンを`GITHUB_TOKEN`に入れてある前提です。`--ref`と`--commit`は、解析したチェックアウトと一致させます。 ``` codeql database create codeql-db --language=python --source-root=. codeql database analyze codeql-db codeql/python-queries \ --format=sarif-latest --output=results.sarif echo "$GITHUB_TOKEN" | codeql github upload-results --github-auth-stdin \ --repository=OWNER/REPO --ref=refs/heads/main \ --commit="$(git rev-parse HEAD)" --sarif=results.sarif ``` 他社ツールの結果をActions内で取り込むときは、`github/codeql-action/upload-sarif@v4`にSARIFファイルのパスを渡します。 ### SARIFアップロード時のファイル容量・実行数・検出結果数の上限値 大規模リポジトリや検出の多いツールでは、上限に当たってアップロードが拒否されることがあります。受理の上限を超えたファイルは拒否され、受理された結果も表示は上限までに切り詰められます（[GitHub Docs: SARIF support for code scanning](https://docs.github.com/en/code-security/reference/code-scanning/sarif-files/sarif-support)）。 | 項目 | 受理の上限 | 表示・保存の上限 | | ---------------- | --------- | ------------- | | ファイルサイズ（gzip圧縮後） | 10MB | – | | 1ファイルあたりのrun数 | 20 | – | | 1runあたりの結果数 | 25,000 | 重大度順に上位5,000件 | | 1runあたりのルール数 | 25,000 | – | | リポジトリのアラート総数 | 1,000,000 | – | 結果数が多すぎる場合は、テストコードや同梱した外部ライブラリを解析対象から外すのが先です。クエリスイートを1段階落とす方法もあります。 ### CodeQL CLIのライセンス：GitLab上のOSSや社内CIで使えないケース 見落とされやすいのが、CodeQL本体の利用条件です。[GitHub CodeQL Terms and Conditions](https://github.com/github/codeql-cli-binaries/blob/main/LICENSE.md)が無償で認めているのは、学術研究、デモ、OSSのクエリのテスト、OSI承認ライセンスのコードベースの解析です。CIや自動解析でのデータベース生成は、**そのOSSがGitHub.com上でホスト・保守されている場合に限る**と書かれています。 条文どおりに読むと、次の使い方は無償の範囲に入りません。 - 社内のprivateコードをCodeQL CLIで解析する（ローカル実行でも同じ） - GitLabや自社のGitサーバーでホストしているOSSを、CIでCodeQL解析する - GitHub上のOSSでも、OSI承認ライセンスを付けていないリポジトリを解析する これらの制限は、GitHub Advanced Security（現在はCode Security）の有償ライセンスで使う場合は適用されません。「CodeQL CLIは無料でダウンロードできるから、社内CIにも入れてよい」は誤りです。導入前に法務とライセンス形態を確認してください。 ## CodeQL 2.27.3でPythonのサンプルを解析した検出結果 Code Scanningを有効にすると実際に何が出るのかを確かめるため、2026年10月23日にCodeQL CLI 2.27.3（python-queries 1.8.13）で41行のFlaskアプリを解析しました。サンプルはMITライセンスを付けたデモ用のコードで、CodeQLの利用条件が無償で認める「ソフトウェアのデモ」の範囲で実行しています。 ### Pythonサンプルの解析に使ったコードとCodeQLの実行コマンド 掲載コードを`sample/app.py`として保存し、その親ディレクトリから後述のコマンドを実行します。結果を比較する場合は、CodeQL CLI 2.27.3とpython-queries 1.8.13を使用してください。 脆弱な処理を3つ（SQLの文字列連結、シェル経由のコマンド実行、パスワードのMD5ハッシュ）と、比較用にプレースホルダを使った安全なSQLを1つ入れています。 ``` # SPDX-License-Identifier: MIT import hashlib import sqlite3 import subprocess from flask import Flask, request app = Flask(__name__) @app.route("/user") def user(): name = request.args.get("name", "") conn = sqlite3.connect("app.db") # 入力をそのまま連結したSQL rows = conn.execute("SELECT * FROM users WHERE name = '" + name + "'").fetchall() return str(rows) @app.route("/user_safe") def user_safe(): name = request.args.get("name", "") conn = sqlite3.connect("app.db") # プレースホルダを使う版（検出されないはず） rows = conn.execute("SELECT * FROM users WHERE name = ?", (name,)).fetchall() return str(rows) @app.route("/ping") def ping(): host = request.args.get("host", "") return subprocess.check_output("ping -c 1 " + host, shell=True) def save_password(password): return hashlib.md5(password.encode()).hexdigest() @app.route("/register", methods=["POST"]) def register(): return save_password(request.form["password"]) ``` データベースの作成は`codeql database create db --language=python --source-root=sample --build-mode=none`、解析は`codeql database analyze db codeql/python-queries:codeql-suites/python-code-scanning.qls --format=sarif-latest --output=python-code-scanning.sarif`です。`python-code-scanning.qls`はクエリパックの既定スイートで、Code Scanningの`default`スイートに当たります。 ### Pythonサンプルで検出された3件のルールIDとセキュリティ重大度 | 行 | ルールID | severity | security-severity | CWE | | -- | ------------------ | -------- | ----------------- | --------------- | | 16 | `py/sql-injection` | error | 8.8（High） | CWE-89 | | 32 | コマンドインジェクション | error | 9.8（Critical） | CWE-78・88 | | 36 | 機密データへの弱いハッシュ | warning | 7.5（High） | CWE-327・328・916 | 表のコマンドインジェクションのルールIDは`py/command-line-injection`、機密データへの弱いハッシュのルールIDは`py/weak-sensitive-data-hashing`です。 プレースホルダを使った24行目は検出されませんでした。MD5の指摘が出たのは36行目の`hashlib.md5()`で、SARIFには41行目の`request.form["password"]`が「機密データ（password）」の出どころとして記録されています。`save_password()`という関数をまたいで、フォームの値がハッシュ処理に届く経路を追っているわけです。このクエリは機密データとして扱われる値がハッシュに渡る経路を探すもので、`md5`という語の有無だけで判定しているのではありません。 同じデータベースをsecurity-extendedとsecurity-and-qualityでも解析しましたが、結果は3件のままでした。Pythonのsecurity-and-qualityはクエリが170本で、defaultの41本の4倍ありますが、このサンプルには追加分に当たるコードが無かったためです。スイートを広げても、問題のある書き方が無ければ件数は増えません。逆に既存の大規模コードでは、広げた分だけ保守性の指摘が積み上がりやすくなります。 ## 検出アラートの読み方と重大度によるトリアージ・マージ保護の設定 ### CodeQLアラートの重大度とセキュリティ重大度の2軸による優先順位 すべてのアラートには`Error`・`Warning`・`Note`のいずれかの重大度（severity）が付きます。CodeQLのセキュリティクエリで見つかったアラートには、これとは別に`Critical`・`High`・`Medium`・`Low`のセキュリティ重大度が付き、画面ではこちらが優先表示されます。セキュリティ重大度は、クエリに付いたCWEタグと同じCWEを持つCVEを集め、そのCVSSスコアの75パーセンタイルをクエリの値として定めたものです。画面では数値がCVSSの区分（9.0以上はCritical、7.0〜8.9はHigh）に置き換えられます。前章のサンプルでは、severityが同じ`error`でも、コマンドインジェクションは9.8でCritical、SQLインジェクションは8.8でHighでした。対応の優先順位は、CriticalとHighから片付けるのが基本です。 ### 誤検知や修正しないアラートを閉じるときのdismiss理由と記録 修正しないアラートは「dismiss」で閉じます。ドキュメントが説明する理由は`false positive`（誤検知）、`won't fix`（修正しない）、`used in tests`（テストコード内）の3つで、REST APIのスキーマには4つ目として`mitigated`（別の手段で緩和済み）も定義されています。選んだ理由は、そのクエリを今後の解析に含め続けるかの判断材料にも使われるため、実態と合うものを選ぶ形です。dismissは全ブランチに効き、コメントはアラートの履歴に残るので、監査で説明できる根拠を書き添えておきましょう。 ### rulesetsでアラートに基づきマージを止める条件と適用対象の例外 rulesetsにCode Scanningのルールを加えると、次の場合にプルリクエストのマージを止められます。 - 必須に指定したツールが、rulesetで定めた重大度以上のアラートを検出した（アラートが示す行がすべてプルリクエストの差分に含まれる場合） - 必須ツールの解析がまだ終わっていない - 必須ツールがリポジトリに設定されていない リポジトリ単位で設定でき（privateリポジトリではCode Securityが前提）、組織単位の設定はEnterpriseプランに限られます。例外として、マージキューのグループと、default setupで解析されるDependabotのプルリクエストには適用されません。rulesetを作ってもCode Scanning自体は有効にならないので、スキャンの有効化は別に済ませておきます。AI Scanの指摘はこのrulesetの判定に使えないため、マージを止めたい言語はCodeQLかSARIFを出す他社ツールで受ける必要があります。 ### Copilot Autofixによる修正案とエージェント型autofix [Copilot Autofix](/tech/details/5213/)は、対応するクエリで見つかったCodeQLのアラートに、LLMで生成した修正案を提示します（案が生成されない場合もあります）。Copilotの契約は不要で、AIクレジットも消費しません。公開リポジトリと、Code Securityのライセンスを持つ組織のprivate・internalリポジトリで既定で有効です。 もう1つが、2026年10月15日に一般提供となった**エージェント型autofix**です（[GitHub Changelog: Agentic autofix general availability](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability)）。アラートをCopilotに割り当てると、エージェントが関連ファイルを調べて修正を作り、CodeQLを再実行してアラートが消えることを確かめてから、下書きのプルリクエストを開きます。 - 対象は既定ブランチのアラートだけです。プルリクエスト上や他のブランチでだけ検出されたアラートは割り当てられません。 - 一覧から最大25件をまとめて1つのプルリクエストで直させることもできます。 - CodeQLの再実行で修正を確かめられるのは標準のクエリだけで、security-extendedスイート、自作クエリ、他社ツールのアラートは検証の対象外です。 - Code Security AI CreditsとActionsの分数の両方を消費します。有効にすると、無料の「Generate Fix」ボタンが「Assign to Copilot」に置き換わります。 利用できるのは、公開リポジトリと、Code SecurityかGHASを持つ組織のリポジトリです（Copilotのライセンスは不要）。組織のリポジトリでは組織オーナーかセキュリティマネージャーが有効にし、組織がエンタープライズに属する場合はエンタープライズ側の許可も要ります。なお10月15日のGA告知は対象を「GitHub Enterprise Cloudの顧客」と書いており、ドキュメントより狭く読めます。導入前に自社の契約形態で設定画面に項目が出るかを確かめてください。手元で1件ずつ確認しながら直すなら、クレジットを使わないCopilot Autofixのままで十分です。 ## CodeQL・AI Scan・他社SASTの組み合わせ方：採用条件と見送る場面 ここまでの制約を、リポジトリの言語構成と置き場所に当てはめると、選ぶべき構成はほぼ決まります。判断の軸は「CodeQLが対応しているか」「既存コード全体を見たいか、差分だけでよいか」「マージを止める必要があるか」の3つです。 ### リポジトリの言語構成と置き場所で決めるスキャン構成の5パターン | リポジトリの状況 | 中心にする仕組み | 補う仕組み | | ----------------------- | ------------------ | ----------------- | | CodeQL対応言語・公開 | default setup | AI Scan（予算を設定） | | CodeQL対応言語・private | Code Security＋既定設定 | 必要ならAI Scan | | PHP中心 | SARIFを出す他社SAST | AI Scanで差分を確認 | | Terraform・Dockerfileを含む | IaCスキャナ | AI Scanで差分を確認 | | GitLab・自社Gitで管理 | 他社SAST | Code Scanningは対象外 | CodeQL対応言語が中心なら、default setupから始める構成が基本です。AI Scanはその上に重ねる補助で、CodeQLが見ないShellスクリプトやDockerfileの変更を拾ってくれます。公開リポジトリではライセンスが要らない一方、AI Creditsは消費するので、組織で有効にする前に予算を入れておきます。 PHP中心のリポジトリは、AI Scanだけでは既存コードの点検もマージの停止もできません。全体を定期的に解析できる他社のSASTを主役に置き、その結果をSARIFでCode Scanningへ取り込むと、アラートの管理画面を1つにまとめられます。候補の比べ方は[Snykのスキャンと料金](/tech/details/17518/)や[SonarQubeの機能と品質ゲート](/column/details/2988/)の解説が参考になります。導入前に、自社の言語とフレームワークが各ツールの対応範囲に入っているかを公式の一覧で確かめてください。 TerraformやDockerfileは、AI Scanが差分の誤りを指摘してくれますが、既にある設定ファイルを一括で検査する用途には向きません。[Trivyの使い方](/tech/details/10398/)で紹介しているIaCスキャンのようにリポジトリ全体を走査できるツールを組み合わせると、既存の設定と新しい変更の両方を押さえられます。 GitLabや自社のGitサーバーでコードを管理している場合、Code ScanningもAI ScanもGitHub上のリポジトリでしか動きません。前述のとおりCodeQL CLIの無償利用にも制限があるため、GitHubへ移さないなら最初から他社ツールで設計する方が手戻りがありません。CodeQLのワークフロー設計やSARIF連携を含めて、既存のCI/CDパイプラインへ検査工程をどう差し込むかで迷う場合は、[DevOps・CI/CD導入支援](https://www.issoh.co.jp/service/system/devops/)として構成の設計から相談いただけます。 ### AI ScanとCode Securityの導入を見送るべき3つの場面 - **外部からのプルリクエストが大半のOSS**：AI Scanはフォークからのプルリクエストで動きません。貢献の多くがフォーク経由なら、クレジットを払っても検査される変更はわずかです。CodeQLのdefault setupで既定ブランチへのpushを見る構成で足ります。 - **マージを止める仕組みが要件になっている**：監査や社内規程で「重大な脆弱性を含む変更はマージさせない」と決まっている場合、AI Scanの指摘はrulesetに使えないため要件を満たしません。CodeQLか、SARIFを出すツールの結果で判定します。 - **CodeQL対応言語をほとんど含まないprivateリポジトリ**：Code Securityのライセンスを買っても、CodeQLが解析できるコードが無ければ主要な価値は得られません。AI Scanのためだけに購入するより、全体を解析できる他社ツールを先に検討します。 反対に、CodeQL対応言語が中心のprivateリポジトリで、GitHub Actionsでの開発が定着しているなら、Code Securityの購入は見送る理由が少ない投資です。まずは無料のリスク評価で検出の傾向を確かめ、件数を見てから契約範囲を決める手順が堅実です。 ## Code Scanningの導入で失敗しやすい5つのパターンと設定上の注意点 公式ドキュメントの制約から逆算すると、導入時につまずきやすいのは次の5点です。 - **既存の大規模リポジトリでsecurity-extendedから始める**：公式ドキュメントは、security-extendedはdefaultより誤検知が多くなる可能性があると説明しています。初回からアラートが積み上がるとトリアージが追いつかないので、defaultで始めてCriticalとHighを片付けてから広げます。 - **default setupを有効にしたままadvanced setupを足す**：default setupが有効な間は、CodeQLアクションやCodeQL CLIで作ったSARIFのアップロードが拒否されます。advanced setupへ移るときはdefault setupを先に無効にします（逆にdefault setupへ切り替えると、既存のワークフローは無効化されます）。 - **フォークからのプルリクエストも検査されると思い込む**：default setupはフォークからのプルリクエストを対象外にしています。外部貢献の多いOSSでは、マージ後の既定ブランチへのpushで検出される前提で運用を組みます。 - **有効化しただけで週次スキャンが回ると思い込む**：前述のとおり、週次スキャンは有効化後にpushかプルリクエストでスキャンが1回走るまで始まりません。スキャンが期待どおりに動かないときは、SecurityタブのCode Scanningの画面から「Tool status」を開きます。言語ごとにスキャンできたファイルの割合と、解析ごとのエラーメッセージが見られるので、ここが切り分けの出発点です。 - **PHP中心のリポジトリで有効化して安心する**：CodeQL対応言語が無ければスキャンは走りません。AI Scanもプルリクエストの差分しか見ないため、既存コード全体の監査にはSARIFを出力できる他社ツールを用意します。 逆に、CodeQL対応言語が中心で、GitHub Actionsをすでに使っているチームなら、default setupをdefaultスイートで有効にするだけで十分な出発点になります。 ## よくある質問 ### GitHub Code Scanningは無料で使えますか？ 公開リポジトリなら無料です。組織が所有するprivate・internalリポジトリで使うには、GitHub Code Securityのライセンス（1アクティブコミッターあたり月30ドル）が必要で、GitHub TeamかGitHub Enterprise Cloudで購入できます。個人アカウントのprivateリポジトリでは使えません。Actions上でCodeQLを動かす場合は、privateリポジトリではActionsの実行料金も確認してください。AI Scanを有効にすると、公開リポジトリでもCode Security AI Creditsの消費が別に発生します。 ### CodeQLとは何ですか？ GitHubが開発する静的解析エンジンで、Code Scanningの標準の解析ツールです。ソースコードをCodeQLデータベースに変換し、QL言語で書かれたクエリを実行して、入力値が無害化されないまま危険な処理に届く経路などを探します。対応は10系統で、PHPは含まれません。自作クエリは、advanced setupのワークフローで指定するほか、組織のリポジトリプロパティ`github-codeql-extra-queries`を使えばdefault setupにも追加できます。 ### CodeQLはPHPに対応していますか？ 対応していません。代わりの手段は2つで、1つはプルリクエストの差分をAIで検査するAI Scan（2026年10月15日に一般提供。Copilotのライセンスは不要で、privateリポジトリではCode Securityが必要、利用分はCode Security AI Creditsを消費）、もう1つはSARIFを出力できる他社の静的解析ツールです。AI Scanは差分しか見ず、マージを止めるrulesetにも使えないため、既存コード全体を検査してゲートに使えるのは後者です。 ### CodeQLの利用に料金はかかりますか？ GitHub.com上の公開リポジトリで使うぶんには無料です。条件を分けるのは実行場所ではなく解析対象で、CodeQLの利用条件が無償の自動解析を認めるのは「GitHub.com上でホスト・保守されるOSI承認ライセンスのOSS」です。社内のprivateコードは、ローカル実行でも外部CIでも、GitHub Code Securityの有償ライセンスが前提になります。 ### Code Scanningの設定方法は？ 最も簡単なのはdefault setupです。リポジトリの「Settings」から「Advanced Security」を開き、「CodeQL analysis」で「Default」を選び、表示された構成を確認して「Enable CodeQL」を押す手順です。有効化時の初回解析に加え、既定・保護ブランチへのpushと、それらを対象とするフォーク以外のプルリクエストで解析されます。週次実行は、有効化後にこれらのイベントで解析が走ると始まり、継続の条件は直近180日間にその解析があることです。独自のビルド手順が要る場合など、default setupの拡張で足りないときだけ、`.github/workflows/codeql.yml`を置くadvanced setupに切り替えます。AI Scanは別の設定で、組織では組織オーナーかセキュリティマネージャーが、個人の公開リポジトリでは「Code scanning」配下のトグルで有効にします。 ## 関連記事 - [GitHub Advanced Securityとは｜Secret Protection月19ドル・Code Security月30ドルの料金と課金の数え方【2026年】](/tech/details/5211/) - [GitHub Copilot Autofixとは？対応言語・料金・エージェント型自動修正【2026年版】](/tech/details/5213/) - [GitHub Code Qualityとは？料金・対応言語・PHPの扱いと導入手順](/tech/details/9791/) - [Dependabotとは｜料金は無料・dependabot.ymlの書き方とRenovateとの違い【2026年10月】](/tech/details/6796/) - [SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説](/tech/details/15880/) - [Trivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定まで【v0.76対応】](/tech/details/10398/) - [Snykとは？CLIでの脆弱性スキャンとCI組み込み・料金の実額を実装視点で解説](/tech/details/17518/) --- 出典: [GitHub Code Scanningとは？CodeQLの設定手順・対応言語・料金とAI Scan【2026年10月】]()（株式会社一創）