AIに実装を任せると、差分の広がり方が変わる。
人間が1ファイルだけ直すつもりの作業でも、AIはテスト、README、設定例、サンプルの環境変数、lock fileまでまとめて触る。この速さの代わりに、PRを開いた瞬間のレビュー対象は散らばりやすくなる。
このとき最初に落としたいのは、コードの美しさより混入物だ。秘密情報が入っていないか。追加した依存に既知脆弱性がないか。ここを人間の集中力に頼ると、AIで増えた差分の量にレビューが負ける。
2026年5月5日、GitHubはGitHub MCP Server経由のsecret scanningを一般提供にした。
同じ日にdependency scanningもpublic previewとして出した。これで、secretと脆弱な依存をPR後ではなくcommit前に確認しやすくなった。
AI生成PRは、人間が読む前に「秘密情報」と「依存関係」を検査する。そのためにGitHub MCPを使う。
GitHub MCPで何が変わったか
MCPはModel Context Protocolの略で、AIエージェントが外部ツールを呼び出すための共通プロトコルだ。GitHub MCP Serverは、AIエージェントからGitHubの機能を使うための公式MCPサーバーになる。
今回扱う機能は2つある。
| 機能 | 状態 | 何を返すか |
|---|---|---|
| secret scanning | 一般提供 | 秘密情報の種類、ファイル、行、修正案 |
| dependency scanning | public preview | 影響パッケージ、severity、修正推奨バージョン |
secret scanningは、public repositoryで使える。private / internal repositoryではGitHub Secret Protectionが必要になる。
GitHubの説明では、MCP対応IDEやAI coding agentからcommitやPRの前に現在の変更を検査できる。利用者には対象リポジトリへのwrite accessが必要だ。
dependency scanningは、Dependabot alertsが有効なリポジトリ向けのpublic previewだ。
dependabot toolsetとして提供され、GitHub Advisory Databaseを参照して脆弱な依存を返す。より詳しいpost-commit検査では、Dependabot CLIをローカルで動かし、変更前後のdependency graphを比較できる。
この機能をPR前に置くと、人間はレビューの邪魔になる混入物を片付けてから差分を読める。
PR前検査の役割
GitHub MCP経由の検査結果は、エージェントの作業セッション内に返る。GitHub Docsは、MCPで返るfindingsはephemeral、一時的な結果だと説明している。
監査に残す本線は、通常のsecret scanning alerts、push protection、Dependabot alerts、CI、監査ログに置く。MCP検査は、その前段で使う。
順番はこうなる。
- AIが実装する
- commit前にsecret scanningを走らせる
- 依存を追加・更新した場合はdependency scanningを走らせる
- 検出があればAIに修正させる
- もう一度検査する
- PR本文に検査結果だけ短く残す
この順番にすると、人間のレビューは「混入物探し」から始まらない。仕様、設計、テスト、権限、データ移行に集中できる。
AI生成PRで混ざりやすいもの
AIが混ぜやすい範囲は、本番コード以外にも広がる。
.env.exampleに本物に近いトークンを書いてしまう- READMEに古いinstall手順を足す
- サンプルコードに固定APIキーのような文字列を置く
- npm、PyPI、Mavenなどの依存を深く考えずに追加する
- lock fileを更新し、意図しないtransitive dependencyを増やす
transitive dependencyは、直接追加したパッケージが内部で引き込む依存のことだ。
人間は package.json や pyproject.toml を見て安心しがちだ。実際の攻撃面はlock file側で増えることがある。
dependency scanningをPR前に呼ぶと、AIが入れた依存をGitHub Advisory Databaseの既知脆弱性に照らして確認できる。
Copilot CLIで呼び出す
Copilot CLIにはGitHub MCP Serverが組み込まれている。
secret scanningでは、secret_protection toolsetと run_secret_scanning toolを明示する。
copilot mcp --toolsets=secret_protection --tools=run_secret_scanningdependency scanningでは、dependabot toolsetを有効にする。
copilot --add-github-mcp-toolset dependabotAdvanced Security pluginを入れると、Copilot ChatやCLIからslash commandでも呼べる。
/plugin install advanced-security@copilot-pluginsMCP対応クライアントでは、GitHub MCP Serverのheadersにtoolsetを指定する。
{
"servers": {
"github": {
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"X-MCP-Toolsets": "secret_protection",
"X-MCP-Tools": "run_secret_scanning"
}
}
}
}dependency scanning用ならこうする。
{
"servers": {
"github": {
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"X-MCP-Toolsets": "dependabot"
}
}
}
}毎回の口頭指示にしない
AIに毎回「安全確認して」と頼む運用は崩れやすい。リポジトリ側に書く。
GitHub Copilotには .github/copilot-instructions.md や .github/instructions/*.instructions.md がある。
GitHub Docsでは、AI agents向けの指示として AGENTS.md も扱われている。Copilotが作業する場所に近い AGENTS.md が優先される。
AGENTS.mdは、AI coding agent向けのREADMEのようなものだ。build手順、テスト、PRルール、セキュリティ上の注意を置く。モノレポならpackageごとに置ける。
このリポジトリなら、たとえば次を入れる。
AI-generated changes:
- Before committing AI-generated changes, run GitHub MCP secret scanning.
- If package manifests or lock files changed, run GitHub MCP dependency scanning.
- Do not open a PR until both results are summarized.
- If a real credential may have been committed or shown to the agent, remove it and mention whether rotation is needed.
- In the PR body, include only the scan result summary. Do not paste secret values.AIに任せる作業が増えるほど、この種の作業規約が役に立つ。毎回のプロンプトで頑張るより、リポジトリに書いておくほうが再現性が高い。
検出されたときの扱い
secret scanningで何か出たら、まず値を削除する。実在するcredentialの可能性があるならrotateする。rotateは、APIキーやトークンを無効化し、新しい値に置き換えることだ。
dependency scanningで脆弱性が出たら、同じPRで直すか分けるかを決める。見るのは、修正が小さいか、破壊的変更を含むか、テストが足りるかだ。
AIには次の形で返させると読みやすい。
security preflight:
- secret scanning: passed / findingあり
- dependency scanning: passed / findingあり
- fixed in this PR:
- left for separate PR:
- human review needed:長い説明はいらない。PRレビューで必要なのは、検査したか、何が出たか、どう扱ったかだ。
レビュー前に検査する
GitHub MCPのsecret scanningとdependency scanningの役割は狭い。AIがcommitやPRを作る前に、秘密情報と既知脆弱性を検出して修正する。
AIによってPRの量と差分の幅が増えるなら、人間が読む前に検査を挟む。先に混入物を減らしてから、人間が設計と意味を読む。