Code scanning alertを開いても従来のGenerate fixが見つからない場合、最初に疑うべきなのは障害ではなく、Agentic Autofixへの切り替えです。2026年7月にパブリックプレビューが始まった新しい仕組みでは、対象リポジトリの個別アラート画面でGenerate fixがAssign to Copilotに置き換わり、Copilotがコード調査、修正、検証、修正PRの作成まで進めます。
利用には、対象リポジトリで有効なGitHub Code SecurityまたはGitHub Advanced Security、Copilotの有料ライセンス、Copilot cloud agentの有効化が必要です。実行後は通常2～4分程度でドラフトPRが作成されますが、AI creditsとGitHub Actions minutesを消費します。(The GitHub Blog)
Assign to Copilotも表示されない場合は、ライセンス、Copilot Autofixポリシー、cloud agentの利用可否、ユーザー権限を確認します。UIを使えない場合には、code scanning alertのassigneeをcopilot-swe-agent[bot]へ変更するREST APIも、GitHub公式の実行経路として用意されています。
まず確認したい「ボタン表示別」の結論
| アラート画面の表示 | 状態 | 取るべき操作 |
|---|---|---|
Assign to Copilotが表示される | Agentic Autofixを利用可能 | Copilotへ割り当ててドラフトPRを作成する |
Generate fixが表示される | classic Autofixを利用可能 | 修正案を生成し、内容を確認してPRを作成する |
| どちらも表示されない | ライセンス、ポリシー、権限、アラートの対応状況に問題がある可能性 | Code Security、Copilot Autofix、cloud agent、write権限を順番に確認する |
| UIから操作できない | APIによる割り当てを検討 | assigneeにcopilot-swe-agent[bot]を設定する |
Agentic Autofixを利用できるリポジトリでは、従来の無料のGenerate fixがAssign to Copilotに置き換わるため、ボタンが消えたこと自体は不具合とは限りません。一方、Copilot cloud agentを利用できないリポジトリでは、従来型のCopilot Autofixが引き続き利用できる場合があります。(The GitHub Blog)
GitHub code scanningのAgentic Autofixとは
Agentic Autofixは、code scanning alertをCopilotへ割り当てることで、修正作業をエージェントセッションとして実行する機能です。
Copilotは単に警告箇所の数行を書き換えるだけではありません。関連するファイルや処理を調査し、修正を作成したうえで、必要に応じて検証と修正を繰り返し、レビュー用のドラフトPRを作成します。
基本的な処理の流れは次のとおりです。
- アラートと関連コードを調査する
- リポジトリ内の関連ファイルを確認する
- 修正案を実装する
- CodeQLなどによる検証を試みる
- 必要に応じて修正を繰り返す
- 修正内容と検証結果を記載したドラフトPRを作成する
PRが作成された後は、PRコメントやリポジトリのAgentsタブから、Copilotへ追加修正を依頼できます。通常の所要時間は2～4分程度ですが、これは目安であり、リポジトリの規模、ビルド時間、依存関係、検証内容によって長くなることがあります。(The GitHub Blog)
Copilot coding agentの現在の名称はCopilot cloud agent
従来「Copilot coding agent」と呼ばれていた機能は、2026年に「Copilot cloud agent」へ名称変更されています。
管理画面や新しいGitHub Docsではcloud agentと記載されるため、設定を探すときは「coding agent」だけでなく「cloud agent」という名称も確認してください。(The GitHub Blog)
CodeQL以外のアラートにも割り当てられる
Agentic Autofixのパブリックプレビューは、CodeQLだけでなく、SARIFなどを通じて登録されたサードパーティ製スキャンツールのcode scanning alertも対象とされています。(The GitHub Blog)
ただし、割り当て可能であることと、同じ精度で検証できることは別です。
GitHub Docsでは、Copilotによる検証はCodeQLの標準的なcode-scanning query suiteを利用したベストエフォートであり、次のアラートでは修正完了を十分に確認できない可能性があると説明されています。
- カスタムCodeQLクエリによるアラート
security-extendedクエリスイート固有のアラート- サードパーティ製スキャンツールのアラート
- ビルドやテストに特殊な外部環境が必要なリポジトリ
サードパーティ製ツールのアラートを修正した場合は、CopilotのPRだけで完了と判断せず、元のスキャンツールを再実行してください。(GitHub Docs)
Agentic Autofixとclassic Autofixの違い
GitHubのcode scanningには、現在、Agentic Autofixと従来型のCopilot Autofixという2つの修正経路があります。
| 比較項目 | Agentic Autofix | classic Copilot Autofix |
|---|---|---|
| 主な操作 | Assign to Copilot | Generate fix |
| 修正方法 | エージェントが関連ファイルを調査して実装 | 個別アラートに対する1回の修正案を生成 |
| 対応範囲 | 複数ファイルをまたぐ修正に対応しやすい | アラート周辺を中心とした限定的な修正 |
| 成果物 | CopilotがドラフトPRを自動作成 | 修正案を確認後、利用者がPR作成を指示 |
| 再修正 | PRコメントやAgentsタブから依頼可能 | 基本的には生成された差分を人が編集 |
| 検証 | CodeQL再実行などを試み、必要に応じて反復 | 生成された修正案を利用者が確認 |
| 複数アラート | 1～25件をまとめて1つのPRにできる | 基本的に個別アラート単位 |
| Copilotライセンス | 有料Copilotライセンスが必要 | Copilotライセンスは不要 |
| AI credits | 消費する | 消費しない |
| Actions minutes | cloud agentの処理で消費する | Autofix生成自体とは別に、PRのCI実行で通常のActions minutesが発生する場合がある |
| 提供状態 | パブリックプレビュー | cloud agentを利用できない場合などに利用可能 |
| ポリシー | Copilot Autofixの共通設定に従う | Copilot Autofixの共通設定に従う |
classic Copilot Autofixは、Copilotのサブスクリプションがなくても利用でき、AI creditsも消費しません。GitHub.com上のパブリックリポジトリ、およびGitHub Code Securityが有効な組織所有リポジトリで利用できます。ただし、すべてのアラートで必ず修正案が生成されるわけではありません。(GitHub Docs)
Agentic Autofixの利用要件
組織のリポジトリでAgentic Autofixを利用する場合は、次の条件を確認します。
| 要件 | 確認内容 |
|---|---|
| Code SecurityまたはGHAS | 対象リポジトリでGitHub Code SecurityまたはGitHub Advanced Securityが有効になっている |
| code scanning | CodeQLまたはサードパーティ製ツールから、対象のcode scanning alertが登録されている |
| Copilotライセンス | 操作するユーザーに有料のGitHub Copilotライセンスが割り当てられている |
| Copilot cloud agent | 組織・Enterpriseのポリシーで有効になっている |
| リポジトリの利用許可 | 対象リポジトリがcloud agentの利用対象から除外されていない |
| Copilot Autofix | Enterprise、Organization、Repositoryの各階層で無効化されていない |
| ユーザー権限 | 操作するユーザーがリポジトリにwrite権限を持っている |
| 利用枠 | AI creditsとGitHub Actions minutesを利用できる状態になっている |
Copilot cloud agentはすべての有料Copilotプランで提供されています。ただし、Copilot BusinessとCopilot Enterpriseでは初期状態で無効となる場合があり、管理者によるポリシーの有効化が必要です。個人向けのCopilot Pro、Pro+、Maxでは、cloud agentが標準で有効とされています。(GitHub Docs)
また、code scanning alertの修正操作にはwrite権限が必要です。アラートを閲覧できても、read権限しかなければ割り当てや修正PR作成を実行できません。(GitHub Docs)
Code scanning alertをCopilotへAssignする手順
個別アラートから修正PRを作る
- GitHubで対象リポジトリを開きます。
Security and qualityタブを開きます。- 左側のメニューから
Code scanningを選択します。 - 修正したいアラートを開きます。
- 画面上部の
Assign to Copilotをクリックします。 - Copilotのエージェントセッションが開始されたことを確認します。
- 作成されたドラフトPRを開きます。
- 修正差分、説明、検証結果をレビューします。
通常は数分でドラフトPRが作成されます。PRには、修正内容、アラートが解消される理由、Copilotが実施した検証内容が記載されます。(The GitHub Blog)
複数アラートを1つのPRで修正する
code scanning alertの一覧画面またはsecurity campaignから、1～25件のアラートを選択し、まとめてCopilotへ割り当てることもできます。
ただし、単に件数を減らす目的で無関係なアラートをまとめるのは避けるべきです。次のような、修正箇所や原因が共通するアラートをまとめるとレビューしやすくなります。
- 同じ入力検証処理に起因する複数のアラート
- 同じ共通ライブラリから発生しているアラート
- 同一の認証・認可処理に関連するアラート
- 同じ修正でまとめて解消できる重複アラート
認証不備、SQLインジェクション、パストラバーサルなど、原因や影響範囲が異なる問題は別々のPRに分けた方が、安全にレビューできます。複数アラートをまとめた場合、Copilotは選択されたアラートを1つのPRで解決しようとします。(GitHub Docs)
UIが使えない場合はREST APIで割り当てる
GitHub公式は、code scanning alertのassigneeにcopilot-swe-agent[bot]を設定するREST API経路を案内しています。
GitHub CLIを利用する例は次のとおりです。
OWNER="your-organization"
REPO="your-repository"
ALERT_NUMBER="123"
gh api \
--method PATCH \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"/repos/$OWNER/$REPO/code-scanning/alerts/$ALERT_NUMBER" \
-f 'assignees[]=copilot-swe-agent[bot]'OWNER、REPO、ALERT_NUMBERを対象の値へ置き換えて実行します。アラート番号は、code scanning alertのURL末尾やREST APIのnumberフィールドで確認できます。
Fine-grained personal access tokenやGitHub Appを利用する場合は、対象リポジトリに対するCode scanning alerts: write権限が必要です。(GitHub Docs)
Agentic Autofixとclassic AutofixではAPIが異なる
ここは間違えやすいポイントです。
- Agentic Autofix
code scanning alertのassigneeをcopilot-swe-agent[bot]へ変更する - classic Autofix
/code-scanning/alerts/{alert_number}/autofixなどの従来のAutofix APIを使用する
従来のCreate an autofixエンドポイントを呼び出しても、Agentic Autofixのエージェントセッションを開始する操作とは同じになりません。Copilotに調査、反復修正、PR作成まで行わせる場合は、alertのassigneeを変更します。(GitHub Docs)
なお、APIはポリシーを回避する仕組みではありません。EnterpriseやOrganizationでCopilot Autofixまたはcloud agentが禁止されている場合、APIから割り当てても利用できません。
作成された修正PRで確認すべきポイント
Agentic Autofixは修正PRまで作成しますが、自動生成されたPRをそのままマージする運用は避けるべきです。GitHubも、検証をベストエフォートとして位置付けています。(GitHub Docs)
アラートの原因が本当に解消されているか
単にCodeQLの警告が消えただけでなく、脆弱なデータフローそのものが遮断されているかを確認します。
例えばSQLインジェクションの場合、文字列を独自にエスケープする修正よりも、プレースホルダーを使ったパラメーター化クエリへ変更する方が適切です。
セキュリティ機能が弱くなっていないか
警告を消すために、入力チェックや認可処理を削除していないか確認します。
特に次の修正には注意が必要です。
- エラーを握りつぶす
- セキュリティチェックを条件分岐から外す
- 危険な値を固定値へ置き換えるだけ
- テストを削除してCIを通す
- 権限チェックの範囲を狭める
- 検証処理をコメントアウトする
元のスキャナーで再検査したか
サードパーティ製スキャンツールやカスタムCodeQLクエリのアラートでは、Copilotの検証だけでは不十分なことがあります。
PRブランチに対して元の解析処理を再実行し、対象アラートが実際に閉じることを確認します。
既存機能を壊していないか
最低限、次のテストを実施します。
- 変更箇所の単体テスト
- 脆弱性を再現する回帰テスト
- 正常系と異常系の統合テスト
- 認証・認可に関するテスト
- ビルドと静的解析
- 依存関係やAPI互換性の確認
リポジトリのカスタム指示に、ビルド方法、テストコマンド、コーディング規約、変更禁止領域を記載しておくと、Agentic Autofixがプロジェクトに沿った修正を作りやすくなります。(GitHub Docs)
Agentic Autofixの課金と利用量
Agentic Autofixは、classic Autofixとは異なり、Copilot cloud agentの利用として課金・計測されます。
| 利用項目 | Agentic Autofixの扱い |
|---|---|
| AI credits | 修正セッションを実行したときに消費 |
| GitHub Actions minutes | 調査、ビルド、テスト、検証などの処理で消費 |
| 1件あたりの固定料金 | なし。モデルや処理トークン、実行内容によって変動 |
| 追加料金 | 契約に含まれる利用枠を超え、追加利用が許可されている場合に発生 |
| プレビュー中の明細 | 他のCopilot利用と分離して表示されない場合がある |
GitHubの発表では、パブリックプレビュー中のAgentic Autofixは、実際に修正処理を実行したアラートについてAI creditsを消費します。また、Agentic Autofixの利用量は、プレビュー期間中、ほかのCopilotアクティビティと個別に分離されないと説明されています。(The GitHub Blog)
AI creditsの消費量は「アラート1件につき一定」ではありません。使用モデル、入力コード量、関連ファイル数、生成量、修正の反復回数などで変わります。契約に含まれるAI creditsとActions minutesの範囲内であれば、直ちに追加料金が発生するとは限りません。(GitHub Docs)
一方、classic Copilot AutofixはCopilotライセンスを必要とせず、修正案の生成でAI creditsを消費しません。ただし、classic Autofixから作成したPRで通常のGitHub Actionsワークフローが起動すれば、そのCI処理については通常どおりActions minutesが計上される可能性があります。(GitHub Docs)
Assign to CopilotやGenerate fixが表示されない原因
| 症状 | 主な原因 | 対処 |
|---|---|---|
Generate fixがなく、Assign to Copilotがある | Agentic Autofixへ切り替わっている | Assign to Copilotを使用する |
Assign to Copilotがなく、Generate fixがある | cloud agentを利用できない、またはclassic Autofixが選択されている | classicを利用するか、Copilotライセンスとcloud agentポリシーを確認する |
| どちらのボタンもない | Copilot Autofixが無効、権限不足、対象外アラート、ライセンス不足 | Enterprise、Organization、Repositoryの設定とwrite権限を確認する |
| Copilotへ割り当てても開始されない | cloud agentの無効化、リポジトリ除外、AI creditsの利用制限 | cloud agentポリシーと利用予算を確認する |
| APIが403になる | API権限不足、リポジトリがアーカイブ済み、Code SecurityやGHASが無効 | Code scanning alerts: writeとリポジトリ状態を確認する |
| 数分待ってもPRができない | ビルド失敗、検証不能、処理長期化、アラートが誤検知の可能性 | Agentsタブやセッションログを確認する |
| PRはできたがアラートが閉じない | 修正不足、別ブランチの状態、複数解析設定、第三者ツールの再解析未実施 | 元の解析を再実行し、対象ブランチと解析設定を確認する |
2～4分という時間は一般的な目安であり、完了保証時間ではありません。処理が長引いている場合は、同じ操作を何度も実行する前に、Agentsタブ、ドラフトPR、セッションログ、Actionsの実行状況を確認してください。(The GitHub Blog)
Copilot Autofixの無効化ポリシーはclassicとagenticの両方に影響する
Agentic Autofixには独立した完全別設定があるわけではありません。基盤となるCopilot Autofixが無効化されると、classic AutofixだけでなくAgentic Autofixもブロックされます。
設定の確認場所は管理階層によって異なります。
Enterprise
Policiesからcode security関連のポリシーを開き、Copilot AutofixがNot allowedになっていないか確認します。
Organization
OrganizationのSettingsから、Advanced Security、Global settingsへ進み、Code scanningセクションのCopilot Autofixを確認します。
Repository
リポジトリのSettingsからAdvanced Securityを開き、Code SecurityセクションのCopilot Autofixを確認します。
Agentic Autofixだけを停止したい場合は、Copilot Autofix全体を無効にする方法のほか、対象リポジトリをCopilot cloud agentの利用対象から除外する方法があります。前者はclassicとagenticの両方を止め、後者はcloud agentを利用するAgentic Autofixを止めます。(GitHub Docs)
なお、code security向けのCopilot Autofixを無効にしても、GitHub Code Qualityの結果に対するAutofixは別の扱いとなる場合があります。code scanningとCode Qualityの設定を混同しないようにしてください。(GitHub Docs)
安全に導入するための運用例
最初から多数のアラートをCopilotへ割り当てるのではなく、次の順序で導入すると問題を切り分けやすくなります。
- テスト環境が整った小規模リポジトリを選ぶ
- 原因が明確なCodeQLアラートを1件選ぶ
Assign to CopilotでドラフトPRを作成する- セッションログとActions利用量を確認する
- 人によるセキュリティレビューを実施する
- 元のCodeQL解析を再実行する
- 問題がなければ、関連する複数アラートへ対象を広げる
- AI creditsとActions minutesの予算・利用量を継続的に監視する
ブランチ保護、必須レビュー、CI、CodeQL解析を維持したまま使うことが重要です。Agentic Autofixは修正担当者を置き換える機能ではなく、修正案の調査と実装を高速化し、人がレビューできるPRへ変換する機能として扱うのが適切です。
まとめ
Generate fixが見つからない場合は、まず同じ場所にAssign to Copilotが表示されていないか確認してください。Agentic Autofixを利用可能なリポジトリでは、これが従来のclassic Autofixに代わる主要な操作になります。
利用に必要なのは、対象リポジトリのGitHub Code SecurityまたはGitHub Advanced Security、有料Copilotライセンス、Copilot cloud agent、Copilot Autofixの許可、ユーザーのwrite権限です。実行すると通常2～4分程度でドラフトPRが作成され、AI creditsとGitHub Actions minutesを消費します。
UIから操作できない場合は、alertのassigneeをcopilot-swe-agent[bot]へ変更するREST APIを利用できます。ただし、APIでEnterpriseやOrganizationの禁止ポリシーを回避することはできません。
まずは対象アラートを1件開き、Assign to Copilot、Generate fix、どちらもない、の3状態を確認してください。その結果に応じて、cloud agent、Copilot Autofix、Code Security、権限、利用枠の順に切り分けると、修正PRを作れない原因を効率よく特定できます。
コメント