GitHub Agentic Autofixが正式提供：セキュリティアラートからレビュー済みの修正へ

セキュリティアラートは、対処すべき問題があることを知らせてくれます。しかし、アプリケーションを壊さずにどう直すかまで教えてくれるとは限りません。小さなアプリを保守し始めた人にとっては、その隔たりが修正に着手する妨げになります。経験のある開発者にとっても、見慣れた警告が未対応のまま積み上がる原因になり得ます。

GitHubは2026年10月15日、コードスキャンのアラート向けAgentic Autofixの一般提供を発表しました。アラートをCopilotに割り当てると、エージェントがコードを調査し、変更を提案し、検証を試みて、ドラフトのプルリクエストを作成します。実用上の変化は、作業の出発点にあります。空のエディターから始める代わりに、確認できる修正案を受け取れます。GitHubの一般提供発表、2026年10月15日

このガイドでは、対象リポジトリの確認から最初の修正をレビューするまでを案内し、関連アラートの扱い、独自スキャナー、費用、修正がうまくいかなかった場合も説明します。私たちがおすすめするのは、エージェントをパッチの作成者として扱うことです。リリースの承認は人が担い、アプリケーションに取り込む前に変更を理解する必要があります。

冒頭の図は、エージェントによる修正提案と、人によるマージ判断を分けて示しています。

最初は未対応のアラート全体ではなく、1件から始める

最初の成功には、自分で説明し、テストし、レビューできる小さな変更を選びましょう。プルリクエストとは、変更をプロジェクトのメインのコードに取り込むための提案です。ドラフトは、その提案がまだ準備中であることを示します。CodeQLはGitHubのコード解析エンジンで、脆弱性の可能性があるコードについてアラートを生成します。

大規模な整理に着手する前に、次の順序で進めます。

1. 自分が管理するリポジトリを選ぶ。 エージェントのセッションを始める前に、後述の利用対象条件、アクセスの承認、費用の責任者を確認します。
2. 先にCodeQL解析を確認する。 すでに解析が正常に動いている場合は、その設定を維持し、直近の成功した実行を確認します。新規に設定する場合は、リポジトリのSettings > Advanced Security > Code SecurityでCodeQL analysisを探し、Set up > Defaultを選びます。設定内容を確認してEnable CodeQLを選択し、解析が成功するまで待ちます。GitHubの設定手順、2026年10月18日確認
3. 適用されるポリシーに従ってAgentic Autofixを有効にする。 リポジトリの設定で、組織やエンタープライズによる禁止を上書きすることはできません。
4. デフォルトブランチの既存アラートを1件選ぶ。 Security and quality > Code scanningを開き、アラートを選んで、AssigneesからAssign to Copilotを選択します。GitHubのアラート操作手順、2026年10月18日確認
5. ドラフトのプルリクエストとセッションログを確認する。 差分を読み、関連テストを実行し、問題を報告した設定で再スキャンします。
6. 人によるレビューと必須チェックの完了後にマージする。 その後、更新されたデフォルトブランチの解析で、アラートの状態を確認します。

画面操作については、一般提供発表内のGitHub公式UIデモを参照してください。解説図が現在のすべての画面を再現していると思い込まず、公式の実例と自分のリポジトリを照らし合わせて進めましょう。

公開・非公開の自分のリポジトリで使えるか？

公開時の発表はエンタープライズの顧客を中心に説明しています。一方、GitHubの現在のアクセスに関するドキュメントは、GitHub.comの公開リポジトリや、GitHub Code SecurityまたはGitHub Advanced Securityを利用する組織所有のリポジトリも対象としています。Copilotライセンスは不要です。GitHubのアクセスに関するドキュメント、2026年10月18日確認

公開リポジトリで利用できても、エージェントのセッションが無料になるわけではありません。コントリビューターに試してもらう前に、リポジトリの利用資格と使用料金を分けて確認してください。

適用される最上位のポリシーから順に有効にする

エンタープライズ配下の組織では、まずエンタープライズのオーナーまたはセキュリティマネージャーが、Policies > Advanced Security > Agentic Autofixで機能を許可します。この許可だけでは有効になりません。続いて組織のオーナーまたはセキュリティマネージャーが、Settings > Advanced Security > Global settingsで有効にすると、対象リポジトリに設定が継承されます。リポジトリ管理者が無効化や再有効化を行えるのは、上位ポリシーで許可されている場合に限られます。独立した組織ではエンタープライズの手順を省き、対象となる個人の公開リポジトリではリポジトリの設定を直接使います。プレビュー利用者も再度有効化する必要があります。GitHubのポリシー設定手順、2026年10月18日確認

アクセス設定の図：許可、有効化、リポジトリごとの選択は別々の判断です。出典：GitHubのアクセスに関するドキュメント、2026年10月18日確認。

組織全体に展開する前に、無効のままにするリポジトリを明確にし、生成されたパッチを誰がレビューするか決めておきます。試験運用では、リポジトリの保守担当者1人とセキュリティレビュアー1人を組み合わせると進めやすくなります。アラート、期待する動作、レビュアー、予算責任者を記録し、放置されたドラフトが、事情を知らない誰かの責任にならないようにしましょう。

CodeQLが実際にコードを解析したことを確認する

デフォルト設定にはGitHub Actionsと、公開リポジトリまたはCode Securityのいずれかが必要です。有効化のスイッチだけでなく、選択された言語とクエリスイートを確認してください。既存の高度な設定が正常に動いているなら、安易に切り替えてはいけません。デフォルト設定は既存の構成を上書きし、既存のワークフローを無効にし、CodeQL解析APIからのアップロードをブロックします。GitHubのデフォルト設定ドキュメント、2026年10月18日確認

アラートを選ぶ前に、最新の解析結果を確認します。対象サービスが解析に含まれていたか、ビルドや依存関係が原因で解析に失敗していないかを調べてください。設定画面で有効と表示されることは、関連ファイルが正常に解析された証拠にはなりません。基準となる解析が信頼できない状態なら、エージェントに修正を頼む前に、その設定の問題を直します。

最初は、データベースの検索処理や特定の出力描画経路など、期待する動作が明確な、範囲の限られた問題を選びましょう。認可の全面的な再設計から始めるのは避けます。関連するアラートがなければ、デモのために運用中のリポジトリへ意図的に脆弱性を作ってはいけません。

割り当てからドラフトのプルリクエストまでに何が起きるか？

GitHubの説明では、エージェントは関連ファイルを調べ、修正を生成し、CodeQLを再実行して、必要に応じて修正を重ねてからドラフトのプルリクエストを作成します。提案には修正の概要と検証内容が含まれます。これがAgentic Autofixのワークフローであり、デフォルトブランチへ自動でマージされるわけではありません。GitHubの一般提供時のワークフロー説明、2026年10月15日

アラートを割り当てた後は、次の順序でレビューします。

1. 元の検出内容を読み直す。 信頼できない入力、機密性の高い操作、期待する保護を特定します。アラートの識別子と、報告に使われた設定も記録します。
2. 変更されたファイルをすべて読む。 無関係な変更、削除されたチェック、無効化されたテスト、新しい依存関係、エラー時の動作変更を確認します。
3. セッション内の検証記録を確認する。 完了したスキャンと、失敗したコマンド、検証できなかったという説明を区別します。セッション内で、またはプルリクエストのコメントでCopilotにメンションして、追加の修正を依頼できます。GitHubのセッションガイダンス、2026年10月18日確認
4. アプリケーションのテストと関連スキャナーを実行する。 適切な開発環境で、プロジェクトのドキュメントにあるテストコマンドを使います。見慣れないコードを実行する前に、セットアップスクリプトとワークフローの変更を確認してください。
5. 人による承認を求める。 動作、スキャン範囲、担当が未解決の間はドラフトを保留します。根拠をレビューできる状態になってから、レビュー可能な状態に切り替えます。

レビューの流れ：エージェントが作成したドラフトは中間成果物であり、アプリケーションの安全性の証明ではありません。出典：GitHubの発表とアラート解決ドキュメント。

GitHubのプルリクエストでは、Files changedで差分を、Checksで自動チェックの結果を確認できます。両方を使ってください。緑の完了表示だけでは、変更された権限チェックがアプリケーションのルールを引き続き守っているかは分かりません。GitHubのプルリクエストの概念、2026年10月18日確認

実践1：小さなデータベース検索を、動作の意味を変えずに修正する

ラベルで在庫品を検索する架空のPythonサービスを考えてみましょう。既存の実装は、受け取ったラベルを文字列整形でSQLに埋め込み、そのクエリの組み立て方をコードスキャンのアラートが指摘しています。役立つ修正は、句読点などの文字を個別に取り除こうとするのではなく、SQL文と値を分離するものです。

Pythonのsqlite3インターフェースを使った、より安全な実装例は次のとおりです。

def find_item(connection, label):
    return connection.execute(
        "SELECT id, label FROM inventory WHERE label = ?",
        (label,),
    ).fetchone()

プレースホルダーによって、値はSQLテキストと分けてバインドされます。Python公式のパラメーターバインドの説明、2026年10月18日確認に沿った方法です。これは架空の修正パターンであり、Agentic Autofixの出力や実地試験の報告ではありません。実際のサービスでは、具体的なクエリ、スキーマ、認可ルールをそれぞれレビューする必要があります。

この例では、通常のラベル、Maker's Kitのようにアポストロフィーを含むラベル、存在しないラベルを扱うテストを依頼します。期待される「行またはNoneを返す」という動作が維持されているか確認してください。その後、呼び出し元エンドポイントの既存のアクセスルールもテストします。パラメーター化クエリは、誰が在庫を閲覧できるかを決めるものではありません。

たとえば、「検索の動作は変えず、ラベルをデータとしてバインドし、アポストロフィーと存在しない品目の回帰テストを追加してください」というレビューコメントが役立ちます。警告を消すよう求めるだけでなく、維持すべき仕様を伝えています。受け入れる前に、実際のパッチを再スキャンしてください。

実践2：無関係な警告ではなく、関連するアラートをまとめる

架空のウェブサービスで、同じレスポンス描画ヘルパーに関するアラートが3件出ているとします。共通の修正1つで対処するのが適切か、一緒にレビューして判断します。GitHubでは、アラート一覧やセキュリティキャンペーンから未対応のアラートを最大25件選択できます。1回の割り当てで、1つのセッションと1つのプルリクエストが作成されます。GitHubの一括割り当て手順、2026年10月18日確認

この上限は処理能力の上限であり、推奨するバッチサイズではありません。同じ担当者が扱う関連した3件のほうが、認証、ファイル処理、データベースアクセスにまたがる無関係な20件よりレビューしやすい場合があります。割り当てる前に、影響を受ける各エンドポイントと、維持すべき通常動作を一覧にします。

このワークフロー例では、共有ヘルパーをレビューし、すべての呼び出し元をテストします。提案された修正が出力のエスケープ処理を変えるなら、1つの例が正しく見えるからといって承認せず、出力先それぞれの文脈を確認します。検出内容によってレビュアーやリリース日程が異なる場合は、作業を分けてください。未解決のアラート1件のために、どの修正に検証済みの根拠があるかが分からなくならないようにします。

実践3：独自スキャナーの結果は、その解析で確認する

Agentic Autofixの対象は、デフォルトブランチにある既存の未対応アラートのみです。プルリクエストや別ブランチにだけ出ているアラートは、この割り当てワークフローの対象外です。新しいプルリクエストで問題が発生した場合は、割り当て可能にするために脆弱なコードをマージせず、そのプルリクエスト内で修正してください。GitHubの対象範囲の説明、2026年10月15日

もう1つ境界があります。GitHubによると、エージェントの検証では、カスタムCodeQLクエリ、security-extendedのCodeQLクエリスイート、サードパーティーのコードスキャンアラートについて、修正を確認できません。組み込みの検証は、可能な範囲でコードスキャンのクエリスイートを再実行するものです。GitHubの検証上の制限、2026年10月18日確認

社内のデータ取り扱いルールを独自クエリで検査している架空の組織を考えてみましょう。エージェントがもっともらしいパッチを提案しても、レビュアーがその独自解析を実行し、結果を確認する必要があります。クエリのバージョン、設定、解析したリビジョン、結果を書き残します。デフォルトスイートの実行が成功しても、問題を報告したクエリの代わりにはなりません。

より厳密なスキャナーは有効のままにしてください。緑の状態表示を得るために検査範囲を狭めても、変わるのは測定条件であって、アプリケーションの安全性ではありません。必要な解析を再現できない場合は、提案を検証待ちにし、実行できる担当者を明示します。

Copilotライセンスが不要でも、請求がないわけではない

Agentic Autofixは、Code Security AI CreditsとGitHub Actionsの実行時間を消費します。GitHubの課金ドキュメントには、アクティブコミッターのライセンスが不要な公開リポジトリでも、AIクレジットを消費すると明記されています。請求先アカウントに対象の利用枠が付与されている場合は、含まれるAIクレジットを先に使い、その後の使用量が従量課金されます。クレジットが含まれないアカウントでは、最初から従量課金になります。GitHubのAIクレジット課金、2026年10月18日確認

組織のリポジトリでは、支払元の組織またはエンタープライズアカウントに費用が帰属します。広く有効化する前に、そのアカウントの利用枠とCode Security AI Creditsの予算を確認してください。発表では、Copilotの支払い方法の設定も必要とされています。これは、すべての利用者がCopilotライセンスを持つ必要があるという意味とは異なります。公開時のGitHubの課金要件、2026年10月15日

試験運用では、セッションの使用量、Actionsの使用量、レビュアーの時間、パッチを採用したかどうかを記録します。アラート1件の修正に固定料金を約束してはいけません。一括処理、修正の反復、採用に至らなかった提案にも費用の確認が必要です。作成されたプルリクエストを修正完了と数えるのではなく、採用した修正の費用を既存のワークフローと比較しましょう。

従来のCopilot Autofixは別の機能です。エージェントが調査してドラフトを作成する代わりに、1段階で変更案を提示し、その提案にはAIクレジットを消費しません。対応している場合は、Agentic Autofixが有効でなくても選択肢になります。GitHubによる比較、2026年10月18日確認

マージ前に、次の7つの問いに答える

私たちのレビューチェックリストでは、報告された弱点を取り除くことと、既存の動作を保つことの両方を重視します。

• 根本原因：警告を抑制するだけでなく、安全でない操作そのものを修正しているか？
• 範囲：無関係なリファクタリング、新しい依存関係、設定変更に妥当な理由があるか？
• 動作：正しい入力、不正な入力、エラー、権限の扱いが引き続き正しく動くか？
• テスト：元の問題を検出できる回帰テストがあるか？
• 解析：問題を報告したスキャナーが、必要な設定で提案リビジョンを解析したか？
• 承認：責任を持つ人が差分と、エージェントの未解決事項を確認したか？
• マージ後：デフォルトブランチの解析で、新たな検出を生むことなく、期待するアラート状態を確認できたか？

「検証できなかった」は承認ではなく、未完了の作業として扱います。GitHubによると、エージェントは検証できなかったことや、誤検知の疑いをプルリクエストに記載する場合があります。どちらの説明も、保守担当者の評価の代わりにはなりません。GitHubの可能な範囲での検証動作、2026年10月18日確認

ボタンが見当たらない、結果が正しくない場合は？

アラートは見えるのに、割り当てられないのはなぜですか？ デフォルトブランチの既存アラートであること、リポジトリの利用資格、機能の有効化、権限を確認します。割り当てには書き込み権限が必要です。設定がロックされている場合は、リポジトリのスイッチを何度も切り替えるのではなく、該当する管理者に確認してください。GitHubの割り当て前提条件、2026年10月18日確認

スキャンに問題がなければ、アプリの安全性は証明されますか？ いいえ。その解析と設定が対象にした問いに答えているだけです。業務ルール、認可、実行時の動作、未対応の検出事項には、適切なテストとレビューが引き続き必要です。

セッションが失敗したら、繰り返し試すべきですか？ まずログと提案差分を確認します。不足しているのが解析設定、テスト実行、プロジェクトの文脈、それとも修正内容そのものなのかを特定してください。次の試行の前に、具体的な訂正を伝えるか、根本にある設定を直します。新しい情報のない再割り当てを繰り返しても、問題解決の方針にはなりません。

誤検知の疑いがあるという判断を受け入れてよいですか？ 検出内容を独立して調査し、判断の根拠を記録してください。アラートを却下することと、脆弱なコードを修正することを混同せず、リスクを例外として受け入れるかどうかをエージェントの確信度に決めさせないようにします。

要点：修正案を受け取るところからレビューが始まる

Agentic Autofixは、調査、候補パッチ、実行できた検証をまとめて届けることで、有用な作業を前倒しします。実務上の利点は、脆弱性に気付いてから具体的な修正をレビューするまでの隔たりが縮まることです。最初の試行は範囲を絞り、スキャナーを維持し、誰が書いたかではなく根拠に基づいて採用を決めましょう。

出典

一次資料は2026年10月18日に確認しました。

本文中のリンクは、GitHubの10月15日の一般提供発表、現行のアクセスポリシー、Autofixの概念と制限、アラートの解決手順、CodeQL設定、課金ドキュメントを参照しています。ドキュメントは確認日時点のアクセス条件を示すもので、すべてのアカウントの設定を保証するものではありません。3つのワークフローは説明用の例であり、実地検証の結果ではありません。

レビュー記録の保管場所に：情報源のリンク、アラートの参照、テスト結果、判断をTelli.shにまとめて保管しましょう。Telli.shはメモを整理できますが、リポジトリのスキャンや修正の承認は行いません。Telli.shアカウントを作成。