こんにちは、AIあれこれ散歩道のもっちゃんです。
2026年10月15日、GitHubはプルリクエスト向けのGitHub AI Scanを一般提供しました。コードの変更をAIで調べ、見落としやすい脆弱性をプルリクエスト上に示してくれる機能です。
便利そうに見える一方で、「公開リポジトリなら無料なのか」「Copilotの契約は必要なのか」「指摘が出たらマージできなくなるのか」と迷う方も多いでしょう。結論から言うと、Copilot契約は不要ですが、スキャンはCode Security AI Creditsを消費します。公開リポジトリで使えることと、費用が一切発生しないことは同じではありません。
この記事では、GitHubの2026年10月17日時点の公式案内をもとに、対象、料金、設定、結果の扱い方を初めての方にも分かる言葉で解説します。
- GitHub AI Scanが調べる範囲とCodeQLとの違い
- 無料で使える対象とAI Creditsの考え方
- 有効化前に確認する設定と対象外PR
- 指摘と修正案を安全に扱う実務手順
先に結論：GitHub AI Scanは、CodeQLを置き換える機能ではありません。CodeQLがまだ対応していない言語や構成の変更を補い、プルリクエスト上で追加の安全確認を行うための機能です。指摘は助言扱いなので、最終判断は人が行います。
GitHub AI Scanの対象・料金・仕組み
まず、GitHub AI Scanが何を調べ、どのリポジトリで使えるのかを確認しましょう。ここを曖昧にしたまま有効化すると、期待したPRが検査されなかったり、思わぬAI Credits消費につながったりします。
この機能は何をするのか
GitHub AI Scanは、プルリクエストに含まれるコード変更をAIベースのエンジンで調べ、セキュリティ上の問題候補を示す機能です。GitHub公式は、PHP、Shell/Bash、Terraform設定のHCL、Dockerfile、JavaのJSP、C#のBlazorなど、CodeQLが現在カバーしていない言語や構成の例を挙げています。
対象になりうる問題は、文字列を組み立てたSQLやシェルコマンドへの注入、不適切な暗号方式、アクセス制御の不足、機密情報の露出、危険な設定、認証の不備、安全でないデシリアライズ、サーバーサイドリクエストフォージェリ、固定されていない外部依存関係などです。
スキャンはPRを作成したときと、そのPRへ新しいコミットを追加したときに走ります。結果はPRの「Conversation」と「Files changed」に表示され、CodeQLの結果とは「AI」表示で見分けられます。問題の説明に加え、多くの指摘には修正案が付くこともあります。
ただし、AI Scanはリポジトリ全体をさかのぼって検査するものではありません。対象はプルリクエスト内の変更です。既存コードすべてを確認したい場合は、CodeQLやほかの検査手段も必要になります。
この違いは、導入時の期待値に直結します。たとえばDockerfileを1行変えたPRなら、その差分と周辺情報から危険な設定がないかを探せます。しかし、変更されていない古いDockerfileや、PRに含まれない別ブランチのコードまで一斉に洗う機能ではありません。新機能の入口で事故を減らす門番として使い、過去資産の点検とは分けて考えると分かりやすいでしょう。
AI Scanはビルド環境を用意しなくてもPRの変更を調べられます。必要に応じてリポジトリ内を検索し、周辺コードの文脈も参照します。一方、/.github/copilot-instructions.mdや/CLAUDE.mdのような個別の指示ファイルは、この検査には使われません。
無料で使える対象と使えない対象
利用可否は、リポジトリの所有者と公開範囲で変わります。公開リポジトリは対象が広いものの、非公開リポジトリでは契約条件が加わります。
| 所有者 | 公開範囲 | 利用条件 |
|---|---|---|
| Organization | Public | アクティブコミッター向けライセンスなしで利用可能 |
| Organization | Private / Internal | GitHub Code SecurityまたはGitHub Advanced Securityが必要 |
| 個人アカウント | Public | 利用可能 |
| 個人アカウント | Private | 利用不可 |
また、Managed User Accountの個人名前空間にあるリポジトリでは、公開リポジトリでも利用できません。会社でEnterprise Managed Usersを使っている場合は、個人名義の置き場所を選ぶ前にこの条件を確認しておきたいところです。
GitHub Copilotのライセンスは必須ではありません。ここは誤解しやすい部分ですね。AIを使う機能ではありますが、「Copilotを契約していないから使えない」という仕組みではありません。
ただし、利用可能と無料は別です。公開リポジトリではAdvanced Securityのアクティブコミッターライセンスが不要な場合でも、AI Scan自体はCode Security AI Creditsを消費します。個人の公開リポジトリでは、基本的にその個人アカウントへ使用量が付く仕組みです。OrganizationやEnterpriseからCopilotライセンスを付与されている場合は、提供元の請求先へ帰属するケースもあります。
AI Creditsの課金で見落としやすい点
GitHubの案内では、AI Scanの使用量は「Code Security AI Credits」というSKUで扱われます。Organization所有のリポジトリなら、Organizationの費用を負担するアカウントへ計上されます。公開リポジトリでも、AI機能の使用量まで必ず無料になるわけではありません。
請求先にGitHub Copilot由来の付与済みAI Creditsがあれば、対象となる使用量は先にそこから消費されます。付与分を使い切ったあと、または付与分がない場合は、設定された予算と従量課金の条件に従います。
ここで確認したいのは、機能を有効にする権限と、費用を管理する権限が別の担当者に分かれている可能性です。セキュリティ担当者が便利だからと組織全体で有効にすると、各リポジトリの管理者が無効化する前に、条件を満たしたPRで使用量が発生することがあります。
費用面の注意：Organization全体へ有効化する前に、付与済みAI Credits、Code Security AI Creditsの予算、上限到達時の動作を請求管理者と確認してください。厳しい上限によって利用可能なCreditsがなくなると、AI Scanは指摘を作れなくなり、上限変更か次の請求期間まで再開しません。
AI Scanを試すときは、最初から全リポジトリへ広げるより、PRの頻度と変更量を見積もりやすい数件で始めると判断しやすいです。1週間または1スプリント使い、発生した指摘数、採用した修正案、誤検知、Credits消費を並べてから展開範囲を決めるとよいでしょう。
予算の上限に達したときの扱いも、試験期間中に確かめておきましょう。AI Scanの結果が出ない状態を「問題なし」と読み違えると危険です。スキャンが実行されたのか、対象変更があったのか、Creditsが利用可能だったのかを区別して記録してください。PRテンプレートへ確認欄を足すだけでも、見逃しを減らせます。
CodeQLとの違いと併用する理由
CodeQLはコードをデータとして解析し、定義されたクエリで脆弱性やエラーを見つける仕組みです。多くの主要言語に対応し、リポジトリのセキュリティ画面へ蓄積されるアラートや、既存コードを含む検査に利用できます。
AI Scanは、CodeQLが現在扱っていない言語や枠組みを中心に、PRの差分へ追加の検査をかけます。指摘はPR内だけで確認でき、リポジトリのセキュリティ画面にバックログとして残るCodeQLアラートとは扱いが違います。
もう一つ大切なのは依存関係です。AI Scanを使うにはcode scanningそのものが有効である必要がありますが、CodeQLのデフォルトセットアップは必須ではありません。CodeQLの解析が失敗中または待機中でも、AI Scanの条件を満たしていれば独立して走ります。
どちらか一方を選ぶより、担当範囲を分ける考え方が合っています。CodeQLで対応言語と既存アラートを継続確認し、AI Scanで対応外のPR差分に目を配る形です。そこへ依存関係の確認、シークレットスキャン、人のレビューを重ねると、ひとつの道具へ頼り切らずに済みます。
◆もっちゃんのワンポイント
AI Scanの表示がなければ安全、とは言えません。検出対象は変わる可能性があり、スキャンされないPRもあります。指摘ゼロは「この検査で候補が出なかった」という意味で受け止めるのがちょうどいいですよ。
GitHubのAI機能を開発作業全体で見直したい方は、GitHub Copilot Computer Useの設定と注意点もあわせて確認できます。AI Scanとは用途が異なるため、契約や権限を混同しないようにしましょう。
GitHub AI Scanの有効化と安全な運用方法
対象と費用を確認したら、実際の導入手順へ進みます。有効化のスイッチを押すだけで終わらせず、スキャン条件、結果の確認方法、誤検知時の扱いまで決めると運用が安定します。
有効化前に確認する4つの条件
GitHub AI Scanが自動実行されるには、複数の条件を同時に満たす必要があります。次の図を先に見ると、設定したのに動かない原因を探しやすくなります。
第1の条件は、リポジトリでcode scanningが有効になっていることです。第2は、Organizationまたはリポジトリにおける実効的なAI Scan設定が有効であること。第3は、PRが対応する言語や構成の変更を含んでいることです。第4として、forkからのPRやDependabot作成のPRではない必要があります。
Enterpriseでは、Enterprise OwnerがOrganizationによる有効化を許可できます。初期状態は「Not allowed」とされており、許可しても自動的に有効になるわけではありません。Organization OwnerまたはSecurity ManagerがOrganization設定を有効にし、対象リポジトリへ引き継がせます。
Organization側で有効になっている場合、リポジトリ管理者は対象リポジトリをオプトアウトできます。一方、Organization側で無効なら、リポジトリだけで勝手に有効化できません。個人所有の公開リポジトリでは、管理権限を持つ人がcode scanning設定内のAI Scan切り替えを操作します。
多数のリポジトリを扱う場合はREST APIでも状態を取得・変更できます。Organization向けは/orgs/{org}/code-scanning/ai-scan、リポジトリ向けは/repos/{owner}/{repo}/code-scanning/ai-scanです。APIは公開プレビュー扱いのため、自動化へ組み込む際はAPIバージョンと権限要件を確認し、応答変更に備えてください。
結果の見方と修正案を採用する手順
指摘が出たら、最初に「AI」表示を見てCodeQLアラートと区別します。次に、指摘された行だけでなく、変更前後の処理、入力元、出力先、認証境界まで読みます。セキュリティ問題は一行の見た目だけでは判断しにくいからです。
おすすめの順序は、問題の再現条件を確認し、外部入力が到達するかを調べ、既存テストを読み、修正案の副作用を考え、別ブランチで変更してテストする流れです。自動修正案が出ても、そのまま採用せず、データ形式や互換性が変わらないかを確認してください。
指摘の優先度を決めるときは、攻撃者が入力を制御できるか、認証前に到達できるか、機密情報や権限へ触れるか、公開環境で実行されるかを見ます。表示された説明が短くても、影響範囲が広いケースはあります。反対に、開発用の閉じた処理だけを示している場合は、すぐに本番事故へ結びつかないかもしれません。それでも、却下するなら根拠をレビューへ残すのが親切です。
たとえば、文字列連結によるSQL生成が指摘された場合、パラメーター化クエリへ置き換える方向は妥当でも、利用中のデータベースライブラリ、トランザクション、型変換によって適切な書き方は変わります。修正案がテストを通っただけで終わらず、攻撃入力を使った否定テストも追加すると安心です。
GitHub公式も、AIベースの道具には誤検知があり得ると案内しています。誤っていると判断したときは、親指の上げ下げによるフィードバックを使えます。ただし、レビューコメントで却下理由を残しておくと、チーム内で同じ指摘を繰り返し議論する手間を減らせます。
採用判断の基準：修正案の見た目ではなく、攻撃経路が閉じたか、既存機能が壊れていないか、テストで再確認できるかを見ます。AIの説明は調査の出発点として使い、マージ判断は担当者が引き受けましょう。
対象外になるPRと運用上の制限
AI Scanは、forkから作られたPRでは走りません。オープンソースでは外部貢献者がforkからPRを送ることが多いため、ここだけで全PRを確認できるわけではありません。Dependabotが作成したPRも対象外です。
さらに、AI Scanの指摘は助言です。Code scanning checkを失敗扱いにせず、rulesetの要件としてマージを自動で止めることもできません。「重大そうな指摘が出たら誰が止めるのか」を人のレビュー手順へ書いておく必要があります。
対応言語や検出分類は、機能の更新とともに変わる可能性があります。導入時の一覧をずっと固定ルールとして扱わず、新しいリポジトリや言語を追加するときに公式ドキュメントを見直しましょう。
また、AI Scanの結果はPR内に表示されますが、リポジトリのセキュリティ画面へ通常のバックログアラートとして並ぶものではありません。PRを閉じたあとに追跡したい指摘は、Issueやセキュリティ作業票へ移す運用が向いています。
チーム導入で決めておく費用と権限
チームで使うなら、少なくとも「誰が有効化できるか」「誰が予算を見るか」「誰が指摘を判定するか」「停止時に誰が対応するか」を決めます。全部を一人へ任せる必要はありませんが、連絡先が分からない状態は避けたいところです。
Organization OwnerやSecurity Managerは設定を扱えますが、請求管理者とは限りません。Billing and licensingのAI usageでは、AI Scanの使用量がAdvanced Security製品として表示されます。SKU単位の予算も用意できるため、試験導入時は小さな上限と通知から始める方法があります。
効果を見るときは、指摘総数だけで判断しないほうがよいでしょう。GitHubのsecurity overviewでは、生成された指摘、解決数、対応率、対象リポジトリ、期間ごとの推移、自動修正案の採用状況などを確認できます。数が多いほど良いのではなく、重大な問題を早めに見つけ、妥当な対応へ結びついたかが大切です。
導入記録には、対象リポジトリ、開始日、請求先、予算上限、例外リポジトリ、判定担当、見直し日を残しておくと便利です。設定画面のスクリーンショットだけで済ませず、判断理由も短く書いておくと、担当者が交代しても迷いません。
月に一度は、不要になった対象リポジトリや、ほとんどPRがないリポジトリも見直してください。設定を増やし続けるだけでは、誰も見ない指摘や把握しにくい費用が残ります。利用実績がない場合は無効化を検討し、必要になった時点で再評価するほうが運用しやすいこともあります。
よくある質問（FAQ）
Q1. GitHub AI Scanは完全無料ですか？
A. 無条件で完全無料とは言えません。公開リポジトリではAdvanced Securityのアクティブコミッターライセンスが不要な場合がありますが、AI ScanはCode Security AI Creditsを消費します。請求先の付与済みCreditsと予算設定を確認してください。
Q2. GitHub Copilotの契約は必要ですか？
A. 必須ではありません。ただし、請求先にCopilot由来の付与済みAI Creditsがある場合は、AI Scanがその枠を先に使うことがあります。
Q3. 指摘が出るとPRをマージできなくなりますか？
A. AI Scanの指摘は助言扱いです。Code scanning checkを失敗にせず、ruleset要件でマージを自動停止することもできません。チームのレビュー規則で対応を決めます。
Q4. CodeQLを有効にしないと動きませんか？
A. code scanning自体は有効である必要がありますが、CodeQLのデフォルトセットアップは必須ではありません。CodeQL解析が失敗中や待機中でも、AI Scanの条件を満たせば独立して実行されます。
Q5. forkやDependabotのPRも調べられますか？
A. 現在はforkからのPRとDependabotが作成したPRでは動きません。これらはCodeQL、依存関係レビュー、人の確認など別の手段で補う必要があります。
GitHub AI Scanを使う前の最終チェック
GitHub AI Scanは、CodeQLがまだ扱っていない領域のPR変更に目を配れる便利な機能です。2026年10月15日に一般提供となり、公開リポジトリから組織の非公開リポジトリまで、条件に応じて利用できます。
一方で、公開リポジトリだから無条件で費用ゼロとは限りません。Code Security AI Creditsの請求先と予算を確認し、forkやDependabotのPRは対象外、指摘はマージを自動停止しない、誤検知もあり得るという制限を理解して使うことが大切です。
- リポジトリの所有者と公開範囲が利用条件を満たすか確認する
- code scanningと実効的なAI Scan設定を確認する
- AI Creditsの請求先、付与枠、予算上限を確認する
- fork・Dependabot・非対応変更を別の検査で補う
- 指摘と自動修正案を人が検証してから採用する
最初の一歩は、対象を限定した試験導入です。費用と精度を同時に見ながら、自分のチームに合う範囲へ少しずつ広げていきましょう。
参照：GitHub Changelog「AI Scan for pull requests generally available」、GitHub Docs「AI Scan for pull requests」（2026年10月17日確認）
