2026年10月15日（執筆時点）、GitHubが「AI Scan for pull requests」と「Agentic autofix for code scanning alerts」の2つを正式版（GA）にしました。どちらも、システムの部品（プログラム）の安全性チェックにAIを使う機能です。
「開発会社が『AIでセキュリティチェックしています』と言い出した。それで本当に安心していいの？費用は変わるの？」
先に結論をお伝えします。この機能は「安全の保証」ではなく「見落としを減らす補助」です。発注者がやることは、使うかどうかを決めることより、「使っている場合に何が確認され、誰が最終判断し、費用を誰が持つか」を開発会社と確認しておくことです。
この記事では、ニュースの要点、発注者にとって変わること・変わらないこと、そのまま使える確認リストと質問例を整理します。
今回のニュース：AIによる脆弱性の発見と、修正案づくりが正式版に
GitHub（ソースコードを預ける開発者向けサービス）は、2026年10月15日に次の2機能を正式版にしたと発表しました（いずれも執筆時点）。
📰 出典：GitHub Changelog「AI Scan for pull requests generally available」
📰 出典：GitHub Changelog「Agentic autofix for code scanning alerts general availability」
| 機能 | 何をするか | 主な条件（発表内容） |
|---|---|---|
| AI Scan | プログラムの変更内容（プルリクエスト）を、AIが自動で調べて脆弱性の疑いを知らせる。従来の検査ツール（CodeQL）が対応していない言語や構成（PHP、シェルスクリプト、Terraform、Dockerfile など）も対象 | 非公開のリポジトリでは有料のセキュリティ製品（GitHub Code Security／Advanced Security）が必要。Copilotのライセンスは不要 |
| Agentic autofix | 検査で見つかった警告に対し、AI（Copilot）が修正案を作り、確認用の下書き（ドラフトのプルリクエスト）を出す。修正後に再検査して警告が消えたかも確かめる | GitHub Enterprise Cloud の Code Security／Advanced Security 契約者向け。管理者の設定が必要 |
費用面では、どちらも「Code Security の AIクレジット」を消費すると説明されています。1回あたりの単価は発表ページには書かれていません。管理者は、AIクレジットに予算の上限を設定できます。
発表で明記されている注意点もあります。
- AI Scan の指摘は参考情報で、検査の合否には影響せず、マージ（本番に取り込む操作）を止める設定にはできません
- フォークからの変更や、Dependabot（部品の自動更新）の変更には動きません
- 自動修正の対象は、本流（デフォルトブランチ）にある警告だけです
発注者にとって何が変わるか・変わらないか
ここからは、ニュースの事実ではなく筆者の見解です。
変わりうること
- 開発会社が脆弱性の見落としを減らせる可能性が上がります。 特にPHPやDockerなど、従来の検査が弱かった領域を補えます
- 修正案づくりの手間が減り、対応が早くなる可能性があります。 ただし、効果は案件ごとに違い、「必ず費用が下がる」とは言えません
- AIの利用料という新しい費用項目が増えます。 開発会社の自社契約で使う場合、その費用が見積もりや保守費に含まれるのか別なのか、確認が必要です
変わらないこと
- AIの指摘が正しいかの判断と、修正を取り込む責任は人にあります。 誤検知（問題のないものを危険と判定）も、見逃しも起こりえます
- 本番に出す前の受け入れテストや、セキュリティ要件の合意は、これまでどおり必要です。 契約上の責任の置き場所も、この発表では変わりません
- 発注者のデータやコードが、どこで処理されるかの確認は引き続き必要です。 発表ページには、データの保管や保持期間の説明はありませんでした。詳しくは公式ドキュメントで確認するか、開発会社に聞いてください
今やるべきこと・まだ様子見でいいこと
| 区分 | 内容 |
|---|---|
| 今やること | 開発会社に、自社の案件でこのようなAIチェックを使っているか（使う予定か）を聞く。使うなら、費用の負担者と上限を決める |
| 今やること | 「AIが指摘した → 人が確認した → 直した」という流れの記録を、納品物や報告に残してもらえるか確認する |
| 様子見でよいこと | 乗り換えや新規契約。自社の開発会社が別の検査ツールをすでに使っているなら、この機能のために慌てて変える必要はありません |
| 様子見でよいこと | 効果の数値。公式発表は機能の説明が中心で、精度の公表値は見当たりませんでした。しばらく実績を見てから判断で十分です |
発注者向けチェックリスト（開発会社に確認する5つ）
- ☐ 使っている検査の種類：AIによる検査と、従来型の検査（CodeQL等）のどちらを、どの工程で使っているか
- ☐ 人の確認：AIの指摘を誰が見て、誰が「直す・直さない」を決めているか
- ☐ 費用：AIの利用料は見積もり・保守費に含まれるか、別請求か。月の上限はあるか
- ☐ データの扱い：自社のコードや資料が、どのサービスで処理されるか。社外秘が含まれる場合の取り扱いルールはあるか
- ☐ 報告：高い危険度の指摘が出たときの連絡期限と、連絡先が決まっているか
開発会社へのそのまま使える質問例
> 「当社の案件で、GitHubのAIによる脆弱性チェック（AI Scan）や自動修正案（Agentic autofix）を使っていますか。使う場合は、どの工程で、誰が最終確認をしますか。」
> 「AIの利用料（AIクレジット）は、見積もりや保守費に含まれていますか。別請求になる場合の目安と、上限の設定を教えてください。」
> 「AIの指摘は参考情報で、合否を止める仕組みではないと聞きました。重大な指摘が出た場合、リリースを止める基準はどう決めていますか。」
> 「当社のソースコードがAIの処理で外部に送られる範囲と、その契約上の取り扱いを教えてください。」
まとめ
- GitHubは2026年10月15日に、AIによる脆弱性チェック（AI Scan）と自動修正案（Agentic autofix）を正式版にしました（執筆時点）
- 見落としを減らす補助にはなりますが、安全を保証するものではなく、指摘は参考情報です
- 発注者は、使っているかの確認、人による最終判断、費用の負担、データの扱い、重大な指摘の連絡期限の5点を、開発会社と先に決めておきましょう
「うちの案件ではどこまでセキュリティチェックを頼めるのか」「AIの利用料をどう見積もりに入れるか」など、迷う点があれば、状況を整理するところからご相談ください。
あわせて読みたい関連記事
コメント
コメント一覧 （1件）
[…] この機能のニュースについては別の記事でも取り上げています（GitHubがAIで脆弱性を見つけて直す機能を正式公開）。ここで押さえたいのは、こうした「自動で修正案を出す」仕組みは、他のAIツールでも同じ構造だということです。「送られるか」ではなく「送られた先で何が起きるか」を確認するのが現実的です。 […]