GitHub IssuesのAI自動変更を承認待ちにする方法｜信頼度・提案パネルの設定

GitHub Issues agent automationsで、AIが判断したラベル付与や担当者変更、Issueのクローズをいきなり反映させたくない場合は、リポジトリの自動化レベル（Automation level）を調整します。

既定の「Cautious」では、信頼度がHighの変更だけが自動適用され、MediumとLowは承認待ちになります。さらに、プロンプトで「直接適用せず提案する」と指示すれば、信頼度がHighでも提案パネルに保留できます。

この仕組みを使うと、単純なラベル付けは自動化しつつ、担当者変更やIssueのクローズだけを人間が確認するといった運用が可能です。ただし、承認機能はセキュリティ境界ではありません。実際の権限制御には、エージェントへ付与するツールとリポジトリ権限の制限が必要です。(GitHub Docs)

GitHub Issuesのエージェント自動化を承認・信頼度で制御する仕組み

GitHubは2026年7月23日、GitHub Issuesに対するエージェント自動化を制御する機能をパブリックプレビューとして公開しました。

中心となるのは、次の3つの仕組みです。

機能	内容	実務上の役割
Confidence	AIが各変更をHigh、Medium、Lowで評価する	自動適用するか、承認待ちにするかを判断する
Rationale	AIがその変更を提案した理由を記録する	管理者が判断根拠を確認できる
Approvals	変更を即時反映せず、提案として保留する	人間がAcceptまたはDeclineを選択できる

重要なのは、信頼度がIssue全体ではなく、個々の変更アクションごとに付く点です。

たとえば、同じIssueに対して次のような結果になる可能性があります。

AIが行う変更	信頼度の例	既定設定での処理
bugラベルを付ける	High	自動適用
優先度フィールドを変更する	Medium	承認待ち
重複Issueとしてクローズする	Low	承認待ち

このため、「ラベルは正しく付いたが、クローズ提案だけ保留されている」という状態も正常な動作です。(GitHub Docs)

自動適用と承認待ちはどう決まるのか

変更が自動適用されるかどうかは、主に次の2点で決まります。

1. リポジトリに設定された自動化レベル
2. プロンプトで直接適用を求めたか、提案を求めたか

処理の優先関係は次のとおりです。

条件	結果
信頼度がリポジトリのしきい値以上で、直接適用を指示	自動適用
信頼度がリポジトリのしきい値未満	承認待ち
プロンプトで「提案する」と明示	信頼度に関係なく承認待ち
対象外のアクション	この承認・信頼度機能では制御されない

つまり、リポジトリのしきい値を下回る変更は、プロンプトで直接適用するよう指示していても承認待ちになります。

反対に、しきい値を上回るHighの変更でも、プロンプトで「suggest」「提案として提示する」と指示すれば、自動適用されず提案パネルに送られます。(GitHub Docs)

リポジトリ管理者が自動化レベルを設定する手順

自動化レベルは、リポジトリ単位で設定します。

1. 対象のリポジトリを開きます。
2. リポジトリ上部の「Settings」を開きます。
3. 左側メニューの「Planning」にある「Agent suggestions for issues」を選択します。
4. 「Automation level」から運用に合ったレベルを選択します。
5. 「Save」をクリックします。

設定変更には、リポジトリの管理権限が必要です。

なお、自動化レベルの設定機能は段階的に展開されています。条件を満たしていても、「Agent suggestions for issues」がまだ表示されない場合があります。(GitHub Docs)

4つの自動化レベルと選び方

GitHub Issuesの自動化レベルには、次の4段階があります。

自動化レベル	動作	向いている運用
Full control	すべての変更を承認待ちにする	導入初期、重要リポジトリ、AIの判断精度を検証したい場合
Cautious	Highのみ自動適用し、それ以外を承認待ちにする	一般的な運用、初めて本番導入する場合
Balanced	定型的で明確な変更を自動適用し、曖昧な変更を保留する	AIの傾向を確認済みで、自動化範囲を広げたい場合
Full automation	基本的にすべて自動適用し、不確実と判定された変更のみ保留する	低リスクな処理に限定し、十分な監視がある場合

既定値は「Cautious」です。Highの変更だけが自動適用され、MediumとLowは提案として保留されます。

注意したいのは、公式ドキュメントが「CautiousはHighのみ自動」と明示している一方、Balancedについては「定型的で明確な変更」、Full automationについては「不確実としてフラグ付けされた変更のみ保留」という挙動ベースで説明している点です。

そのため、Balancedを単純に「Medium以上はすべて自動適用」と固定的に解釈するのは避けたほうが安全です。実際のIssueでテストし、どの変更が自動適用されるかを確認してから本番運用へ広げましょう。(GitHub Docs)

導入時はFull controlかCautiousから始める

初めて導入する場合は、次の順番が現実的です。

1. Full controlですべての提案を確認する
2. AIが付けるラベルやIssue typeの精度を確認する
3. 問題が少なければCautiousへ変更する
4. 定型処理に限定してBalancedを検討する

最初からFull automationを選ぶと、誤った担当者割り当てやクローズが、そのまま反映される可能性があります。

一方、すべてをFull controlにしたままでは承認作業が増え、自動化のメリットが薄れます。まずはCautiousを基準にして、高影響な変更だけを明示的に提案扱いにする構成がバランスを取りやすいでしょう。

特定の変更だけを必ず承認待ちにするプロンプト

リポジトリ全体の自動化レベルとは別に、プロンプトで「直接適用せず提案する」と指定できます。

たとえば、ラベルとIssue typeは自動化し、担当者変更とクローズだけを必ず承認待ちにする場合は、次のように指示します。

このIssueの内容を確認し、適切なラベルとIssue typeを設定してください。

担当者の変更とIssueのクローズは直接適用せず、
必ず提案として提示してください。

各変更について、判断理由を示してください。

このプロンプトでは、処理が次のように分かれます。

変更内容	処理
ラベル	リポジトリの自動化レベルと信頼度に従う
Issue type	リポジトリの自動化レベルと信頼度に従う
担当者	信頼度に関係なく承認待ち
クローズ	信頼度に関係なく承認待ち

より慎重に運用する場合は、次のようにすべてを提案扱いにできます。

このIssueをトリアージしてください。

ラベル、Issue type、フィールド、担当者、クローズに関する変更は、
すべて直接適用せず、提案として提示してください。

各提案には判断理由を含めてください。

ただし、プロンプトは権限制御ではありません。高影響な操作を確実に禁止したい場合は、プロンプトに書くだけでなく、エージェントへその操作に必要なツールを付与しないことが重要です。(GitHub Docs)

承認パネルで提案を確認する方法

信頼度がしきい値を下回った変更や、プロンプトで提案するよう指示した変更は、Issue上の承認パネルに表示されます。

承認パネルでは、次の情報を確認できます。

• 提案されている変更内容
• AIが示した信頼度
• その変更を提案した理由
• AcceptまたはDeclineの操作

確認手順は次のとおりです。

1. 提案が保留されているIssueを開きます。
2. 承認パネルに表示された変更内容を確認します。
3. RationaleでAIの判断理由を確認します。
4. 問題がなければ「Accept」を選択します。
5. 適用すべきでなければ「Decline」を選択します。

複数の提案がある場合は、個別に承認・却下できるほか、「Accept all」または「Decline all」で一括処理できます。

Acceptした変更はIssueへ直ちに反映されます。Declineした提案は、Issueを変更せずに破棄されます。(GitHub Docs)

一括承認は変更の種類を確認してから行う

一括承認は便利ですが、ラベル変更とクローズ提案が同じパネルに含まれている場合があります。

たとえば、次の3件が並んでいるとします。

1. bugラベルを追加
2. 担当者を特定の開発者へ変更
3. Issueを重複としてクローズ

ラベル付けだけを承認したい場合は、「Accept all」を使わず、個別にAcceptしてください。

特にクローズ、担当者変更、重要度フィールドの書き換えは、ラベル追加より影響が大きくなります。変更の種類が混在している場合は、個別承認を基本にすると誤操作を防ぎやすくなります。

has:suggestionsで承認待ちのIssueを検索する

提案が保留されているIssueは、検索修飾子のhas:suggestionsで抽出できます。

開いているIssueのうち、承認待ちがあるものを探す基本形は次のとおりです。

is:issue is:open has:suggestions

特定のリポジトリに限定する場合は、次のように検索します。

repo:ORGANIZATION/REPOSITORY is:issue is:open has:suggestions

現在自分に割り当てられているIssueに限定する場合は、次のように指定できます。

is:issue is:open has:suggestions assignee:@me

更新日時が新しい順に確認したい場合は、並び替え条件も追加できます。

is:issue is:open has:suggestions sort:updated-desc

has:suggestionsの検索結果を定期的に確認すれば、提案パネルを見落としたまま放置する事態を防げます。チーム運用では、この検索条件を共有し、日次または週次のトリアージ対象として扱うとよいでしょう。(GitHub Docs)

信頼度と承認の対象になる変更

公開時点で、信頼度、判断理由、承認の仕組みが適用されるのは、主に次のIssue属性です。

対象	具体例
Labels	bug、enhancement、documentationなどの付与
Fields	優先度、ステータス、分類用フィールドなどの変更
Issue type	Bug、Feature、Taskなどの設定
Assignees	ユーザーまたはエージェントの割り当て
Close	Issueのクローズ

この仕組みは、Issueに対するすべてのエージェント操作を制御するものではありません。

たとえば、次の操作は別に考える必要があります。

• Pull Requestの作成
• コードの変更やpush
• Issue以外のリポジトリ操作
• 人間が手作業で行う変更
• 承認機能の対象外となるエージェント操作

「Full controlにしたから、エージェントの全操作が承認制になった」と考えるのは誤りです。自動化レベルが制御するのは、対応しているIssue属性への変更に限られます。(GitHub Docs)

Copilot cloud agentで設定する場合

Copilot cloud agentのAutomationsを使う場合、信頼度と判断理由のための追加設定は基本的に不要です。

リポジトリの「Agents」タブからAutomationsを作成し、Issueを変更するためのツールを選択します。

基本的な作成手順は次のとおりです。

1. リポジトリの「Agents」を開きます。
2. 「Automations」を選択します。
3. 「Create new」をクリックします。
4. 「When an issue is created」などのトリガーを選択します。
5. トリアージ内容をプロンプトに記述します。
6. ラベル、フィールド、担当者など、必要なIssueツールだけを有効にします。
7. 自動化を保存します。
8. 「Run now」で動作をテストします。

エージェントが対応するIssue属性を変更すると、判断理由と信頼度が自動的に付与されます。しきい値未満の変更と、提案するよう指示した変更は承認パネルへ送られます。

Copilot cloud agentのAutomationsは、現時点ではプライベートリポジトリと内部リポジトリが対象です。パブリックリポジトリでは利用できません。また、Copilot cloud agentやAutomationsが組織またはリポジトリのポリシーで無効化されている場合も利用できません。(GitHub Docs)

GitHub Agentic Workflowsで利用する場合

GitHub Agentic Workflowsでも、Issue変更に判断理由と信頼度を付けられます。

既存のワークフローを利用している場合は、最初に拡張機能を更新します。

gh aw upgrade

Issueを変更するための出力は、ワークフローのfrontmatterにあるsafe-outputsへ設定します。

対象となる主な出力は次のとおりです。

safe output	操作
add-labels	ラベルを追加する
set-issue-type	Issue typeを設定する
set-issue-field	Issueフィールドを変更する
assign-to-user	ユーザーを割り当てる
assign-to-agent	エージェントを割り当てる
close-issue	Issueをクローズする

特定の出力に対して、判断理由と信頼度を必須にする例は次のとおりです。

safe-outputs:
  add-labels:
    issue-intent: true

issue-intent: trueを設定すると、その出力には判断理由と信頼度が必要になります。エージェントが必要な情報を出力しなかった場合、ワークフローは失敗します。

反対に、issue-intent: falseを設定すると、その出力では判断理由と信頼度のメタデータを使用しません。パブリックプレビュー中は仕様が変わる可能性があるため、既存ワークフローへ反映する前に最新の公式ドキュメントを確認してください。(GitHub Docs)

REST APIとGraphQL APIからも提案を作成できる

独自のGitHub Appや社内システムからIssueを更新している場合は、REST APIまたはGraphQL APIを通じて、次の情報を変更に付与できます。

• 判断理由
• High、Medium、Lowの信頼度
• 直接適用せず提案として保存する指定

REST APIでは、Issue変更に関連するパラメータとして、rationale、confidence、suggestが用意されています。suggestを有効にした変更は即時適用されず、人間のレビューを待つ提案として保存されます。

ただし、利用できるパラメータや指定位置はエンドポイントによって異なります。実装時は、使用するIssue更新APIの最新スキーマを確認してください。(GitHub Docs)

承認機能はセキュリティ境界ではない

GitHubは、Approvalsをワークフロー上の利便機能であり、セキュリティ制御ではないと明記しています。

承認待ちの仕組みは、サーバー側でエージェントの書き込みを強制的に遮断するものではありません。Issueを変更する権限を持つエージェントは、提案として保存せず、REST APIやGraphQL APIなどを通じて変更を直接適用できる場合があります。(GitHub Docs)

プロンプトだけで操作を禁止しない

次のようなプロンプトを書くだけでは、強制力のある禁止にはなりません。

Issueを絶対にクローズしないでください。

AIが指示に従うことは期待できますが、これは権限制御ではありません。

Issueをクローズさせる必要がない場合は、エージェントにクローズ用のツールを付与しない構成にしてください。

必要なツールだけを付与する

Copilot cloud agentのAutomationsでは、作成時にエージェントが利用できるツールを選択します。

ラベル付けだけを行う自動化であれば、担当者変更、コードpush、Pull Request作成などのツールまで付与する必要はありません。

基本方針は次のとおりです。

自動化の目的	付与する操作
Issue分類	ラベル、Issue type
優先度整理	ラベル、フィールド
担当者候補の提案	担当者変更を提案扱いにする
重複Issue検出	ラベル付与とクローズ提案
完全な自動クローズ	十分に限定された条件と監視がある場合のみ

GitHubも、タスクに必要なツールだけを選択するよう案内しています。承認パネルを安全対策の代わりにせず、権限とツールを最小限にしてください。(GitHub Docs)

設定項目が表示されない場合の確認ポイント

「Agent suggestions for issues」や「Automation level」が見つからない場合は、次の項目を確認します。

段階的なロールアウト中ではないか

自動化レベルの設定機能は段階的に展開されています。対象条件を満たしていても、まだリポジトリへ反映されていない可能性があります。

リポジトリの管理権限があるか

自動化レベルはリポジトリ設定から変更するため、一般の読み取り権限や書き込み権限では表示されない場合があります。リポジトリ管理者に確認してください。

Copilot cloud agentが有効か

組織のポリシーでCopilot cloud agentが無効化されていると、Automationsを利用できません。Copilot BusinessまたはEnterprise環境では、組織管理者側の設定も確認します。

リポジトリが対象範囲か

Copilot cloud agentのAutomationsは、現時点ではプライベートまたは内部リポジトリで利用できます。パブリックリポジトリにはAutomations UIが表示されません。

パブリックプレビューであることを考慮する

信頼度、判断理由、承認機能はパブリックプレビューです。画面名称、設定項目、対応アクションは今後変更される可能性があります。(GitHub Docs)

実務でおすすめの設定

最初の設定としては、次の構成が扱いやすいでしょう。

項目	推奨設定
Automation level	Cautious
ラベル	しきい値に応じて自動適用
Issue type	しきい値に応じて自動適用
フィールド	重要度によって自動または提案
担当者	原則として提案
クローズ	原則として提案
承認待ち検索	is:issue is:open has:suggestions
エージェントのツール	必要最小限

まずCautiousで運用し、Highのラベル付けやIssue type分類が安定していることを確認します。

担当者変更とクローズは、プロンプトで必ず提案するよう指定してください。承認待ちのIssueはhas:suggestionsで定期的に確認します。

そのうえで、自動適用しても問題が起きにくい定型処理だけをBalancedへ広げます。Full automationは、操作対象が限定され、誤変更をすぐ発見・修正できる場合に限って検討するのが安全です。

GitHub IssuesのAI自動化では、単に「自動化するか、しないか」の二択にする必要はありません。低リスクな変更は自動適用し、高影響な変更だけを人間の判断へ戻すことで、作業負担と誤変更リスクの両方を抑えられます。