【何が起きたか】GitHub Copilot「Assisted permissions」の一般提供と各環境の対応状況
2026年10月26日、GitHubは、自律型エージェント向けの操作承認機能「Assisted permissions」をGitHub Copilot CLI、GitHub Copilot app、Visual Studio Code向けに一般提供（GA）したと発表しました[1, 7]。対象となる操作要求は、シェルコマンドの実行、ファイルシステムパスへのアクセス、URLを開く操作です[7]。
提供プランについては、公式のプラン一覧にCopilot CLIとCopilot appが全プランに含まれると記載されています。一方、参照したプラン一覧では、Assisted permissionsの対象プランを個別に確認できませんでした[2]。
クライアント環境のバージョン要件について、参照した告知資料では統一された正式な最低バージョンを確認できませんでした[3]。確認できた資料の範囲では、Copilot CLIの安定版v1.0.104のリリースノートにexperimental mode不要との記載があり、Visual Studio Codeのv1.130にはAgent Host向けの設定項目が記載されています[3]。一方、Copilot appの最低動作バージョンは参照資料で確認できませんでした[3]。
公開ドキュメントの記載には、更新時点やステータスに差があります。VS Codeの承認ガイド（2026-10-21付）や現行のAI設定リファレンスでは、Assisted permissionsは「experimental（実験的）」と記載されています。また、利用条件として「Folder isolation」が指定されているほか、Local harnessセッションでは利用できず、Worktreeセッションでは常にAllow allが適用されるとされています[4, 5, 6, 8]。これらの資料は10月26日の一般提供告知とは更新時点が異なるため、導入時には利用環境のバージョンと設定条件を確認する必要があります[6, 8]。
【なぜ今か】エージェント自律化に伴う確認中断の負荷と安全性のトレードオフ
長時間にわたって自律的にタスクを遂行するエージェントの運用では、ツール呼び出しのたびに発生する承認要求が作業を中断させる点が課題として挙げられています[9]。確認プロンプトへの応答は利用者の制御権を保つ手段ですが、とりわけセッション序盤にCopilotが実行可能な操作を確定していく過程では、進行を遅らせる要因になります[10]。
一方、すべての確認を省略する無条件許可（Allow all）では、個々の操作に対する人間の監督が失われます[10, 11]。従来の手動承認（Manual）は、最も多くの監督機会を確保できる反面、利用者に最も多くの応答を求めます[11]。Assisted permissionsは、安全と判定した適格な要求を自動承認し、不確かな要求だけを利用者の確認に回します。無条件許可による監督の喪失を抑えながら、確認による中断を減らす中間的な方法として設計されています[11]。
ただし、モデルが安全と判断した操作は、実行前の個別確認なしに進むため、その分、確認の機会は減ります[12]。公式資料は、モデルが危険な操作や意図しない操作を承認する誤りが起こりうると明記しており、利用者には実行内容を確認する責任があります[12]。また、公式資料で示されているのは、確認頻度を下げる設計と作業遅延への配慮までです。時間短縮量、確認回数の減少幅、誤判定率などの定量データは公表されていないため、効果やリスクの大きさを実数値で評価することはできません[13]。
後輩自動承認によって作業の中断が減るのは助かりますが、モデルが承認した操作は実行前の確認を挟まずに進むのですね。
先輩その通りだね。確認の負担を抑えられる半面、実行前の直接的な監督機会は減る。公式資料でもモデルが意図しない操作を承認する誤りの可能性を認めていて、実行された操作を利用者自身が確認する責任が明記されているよ。
後輩承認プロンプトを単に通過させるための機能ではなく、実行後の結果確認を含めた作業全体の進め方を見直す必要がありますね。
【仕組み】操作承認の判定フローとAI判定（LLM judge）の公表仕様・未公表事項
Assisted permissionsでは、既存ルールの評価、モデルによるリスク審査、実行または確認・拒否という多段階のフローで操作承認を処理します[14, 16, 19]。対象となる操作は、コマンドの実行、ファイルシステムパスへのアクセス、URLの取得要求です[15, 19, 25]。
操作要求が発生すると、まず既存のポリシーや過去のセッション承認を評価します[16, 19, 24, 26]。すでに許可されている要求は、モデル審査や確認を経ずに実行されます[24]。既存ルールで解決されていない適格な要求だけが、モデル審査に進みます[16, 19, 24, 27]。
モデル審査（LLM judge）では、操作がタスクの範囲内で安全か、利用者が与えた権限の範囲内かを評価します[16, 18, 20, 26, 27]。モデルが要求を安全だと確信した場合は自動承認され、処理が続きます[14, 20]。安全だと確信できない要求については、対話セッションでは利用者に承認プロンプトが表示されます[14, 20]。
一方、Autopilotモードや非対話実行環境では、人間の承認が必要な要求は自動的に拒否されます。その理由はCopilotに返され、別の手段を試せるようになります[22]。また、ローカルサンドボックスの回避要求はモデル審査の対象外です。審査できない要求とともに、通常のセッション権限処理に戻されます[17, 26]。
安全性の評価基準について、Copilot CLIでは、危険性のあるコマンドの例として、rm -rf による削除、sudo や chmod 777 などによるシステム変更、機密パスを伴う curl、.env やSSH鍵などの認証情報の読み取り、PATH や LD_PRELOAD などの危険な環境変数のインライン上書きが挙げられています[21]。こうした高リスク操作では、追加の警告や承認が求められる場合があります[21]。
ただし、VS Codeガイドで「LLM judge」と呼ばれる判定機能について、今回確認したガイドでは具体的な仕様を確認できませんでした[18]。判定プロンプトの内容、個別の入力項目、危険度分類の体系、確信度の数値閾値、出力形式などは、今回確認した公開資料では確認できませんでした[18, 23]。
補足：LLM judgeとは
LLM judgeは、操作要求やタスクの文脈を入力とし、大規模言語モデルを用いて操作の安全性や妥当性を判定・評価する仕組みです。
【何が変わるか】3つの承認モードの比較とサンドボックス・実行権限との階層分離
GitHub Copilotのエージェント運用には、Manual（手動承認）、Assisted（支援付き承認）、Allow all（無条件許可）という3つの主要な承認モードがあります[28, 32, 34, 36, 43, 46]。
| 承認モード | モデル審査の有無 | 人への確認発生条件 | 特徴と監督範囲 |
|---|---|---|---|
| Manual | なし[28, 32] | 事前に許可されていないすべての操作[28, 32, 34, 36, 43, 46] | 最も多くの監督機会を確保し、操作ごとに人間の承認を要求[28, 32] |
| Assisted | あり[28, 32, 34, 36] | モデルが安全と確信・承認できなかった適格な操作[28, 32, 34, 36, 43, 46] | 安全と判定した操作を自動実行し、不確かな要求だけを人に確認[28, 32, 46] |
| Allow all | なし[28, 32, 34, 36] | 個別確認とモデル審査を省略（管理者のdeny・limitToや有効なサンドボックスによる制限は残る）[28, 32, 34, 36, 46] | 個別確認とモデル審査を省略し、最も広い権限を付与[28, 32, 34] |
VS CodeやCopilot CLIでは、Assisted permissionsで承認された操作もエージェントを実行するユーザと同じアカウント権限で行われます[30, 31, 37, 38, 44, 47]。Assisted permissionsは、操作を自動で進めるか確認するかを決める「承認ゲート」です。サンドボックスを有効にすると、プロセスの到達範囲を別の防御層として制限できます[30, 37, 44]。
この承認ゲートと、実行プロセスを隔離する「サンドボックス（sandbox）」は、独立した防御層として設計されています[29, 30, 33, 35, 37, 44]。VS Codeでサンドボックスが有効な場合、AssistedやAllow allで操作が承認された後も、実行されるターミナルプロセスのファイルシステムとネットワークへのアクセスは、サンドボックスによって引き続き制限されます[31, 33, 35, 37, 44, 47]。VS Codeのサンドボックスは、実行ユーザのOS環境内で、ターミナルプロセスのファイルシステムとネットワークへのアクセスを制限します[47]。
Copilot CLIのサンドボックスにも、実装上の境界の違いがあります。ローカルサンドボックスではCLIプロセスが通常環境で動作し、OSが子プロセスに直接制約を適用します[38, 39, 40]。一方、CLI組み込みのファイル読み書きツールは、ソフトウェア内で同じ制限を確認する仕組みです。そのため、操作によって適用されるOSの強制境界が異なります[39, 45]。Cloud sandboxでは、セッション全体をGitHubがホストするリモートの隔離環境で実行します[40, 45]。
AWS IAMなどのクラウドアカウント管理では、IDにポリシーを関連付け、アクセスできるクラウドリソースを制御します[41]。本稿で扱うAssisted permissionsは、開発環境内のツール実行を承認する機能であり、クラウドリソースの認可を担うIAMとは制御対象が異なります[41, 42]。実務では、Assistedを文脈に応じた承認ゲート、サンドボックスをプロセスの到達範囲を絞る仕組み、IAMをクラウドアカウントの実効権限境界として位置づけ、それぞれに最小権限を適用する設計が妥当です[42]。
後輩Assisted permissionsを有効にすれば、エージェントが安全な隔離領域で実行されるわけではないのですか？
先輩そこは混同しやすいけれど別物だね。Assisted permissionsはツール呼び出しを実行前に人に確認するかどうかを判定する承認ゲートであって、プロセス自体の権限を狭める境界ではないよ。
後輩つまり、実行自体は作業者と同じOS権限で動くから、仮に誤承認が起きても影響を抑えられるように、サンドボックスやOS権限の最小化を別個に重ねておく必要があるのですね。
補足：Folder isolationとは
VS Codeガイドでは利用条件としてFolder isolationが挙げられています。
【誰に影響するか：管理者】企業ポリシーの優先順位、ドメイン制御と監査ログの制約
企業管理者は、Copilot CLIやVS Codeで、シェルコマンド、ファイルの読み書き、ネットワークドメインに対する操作ポリシーを一元的に管理できます[61]。組織が設定した管理制限は、ユーザ設定、ワークスペース設定、自動承認（auto-approval）、保存済み承認によって弱めることはできません[29, 60]。
Copilot CLIの管理ルールには、厳格な評価順序が定められています[53, 61]。
| ポリシー種別 | 優先順位 | 複数管理元での結合方式 | 自動承認による緩和 |
|---|---|---|---|
| deny | 最優先（第1位）[53, 61] | 合算（union）：いずれかの管理元でdenyなら遮断[53] | 不可（常に操作をブロック）[29, 50, 52, 60] |
| ask | 第2位[53, 61] | 合算（union）：管理元間で合算[53] | 条件付き（公開資料間に説明差あり）[48, 50, 52, 62] |
| allow | 第3位[53, 61] | 共通部分（intersection）：宣言した全管理元の一致が必要[53, 61] | 対象外（すでに自動実行）[24, 53] |
| limitTo (ドメイン) | 独立した強制境界[51, 54, 60] | 共通部分（intersection）：管理元間の共通範囲のみ許可[54] | 不可（リスト外通信は無確認拒否）[51, 54, 60] |
Copilot CLIの管理ポリシーでは、ファイルの読み書きルール（Edit / Write）が、検出可能なシェルからの書き込みにも適用されます[49]。コマンドから書き込み先を特定できる場合、広い Shell(*) 許可ルールがあっても、一致するdenyルールが優先され、書き込みを遮断します。一致するaskルールがあれば、確認が求められます[49]。
ネットワーク通信では、管理者が設定する permissions.limitTo が、ドメインに対する閉じた許可境界を形成します[51, 54, 60]。許可リスト外のドメインへのネットワーク要求は、確認プロンプトを表示せずに拒否されます。ユーザ独自のルールや保存済み承認、Allow allモードでも、この境界を拡張できません[51, 54, 60]。
企業向けの公開ドキュメント間では、askルールの挙動に関する説明に差があります[48, 62]。CLI向けのAssisted permissionsガイドでは、適格なシェルコマンド、ファイル操作、URL要求に対する企業のaskルールは、モデルの承認によって満たせる場合があり、必ずしも人の確認プロンプトを必要としないと説明しています[48, 50, 52]。一方、Enterprise managed settingsリファレンスでは、管理されたaskルールは個々の操作に対する人間の承認を求めるものであり、自動承認やバイパス設定では満たせないと明記されています[48, 62]。このため、資料によって適用の解釈に差があります[48, 62]。
セッションの初期モードについて、Copilot CLIでは組織の permissions.defaultMode が利用者の設定より優先されます。ただし、組織ポリシーが許容する範囲であれば、利用者はセッション中に手動でモードを切り替えられます[55]。禁止された設定が指定された場合はManualに戻ります。--allow-all は、管理ポリシーで許可されている場合に限り、既定値を上書きします[55]。VS Codeでも permissions.defaultMode は新規セッションの初期値であり、組織が許可する別モードへの変更を禁止するものではありません[56]。AssistedやAllow allの選択自体を禁止するには、それぞれ disableAssistedPermissionsMode や disableBypassPermissionsMode を設定し、選択UIから除外する必要があります[56]。また、VS Codeの ChatToolsEligibleForAutoApproval で特定ツールを手動承認対象に指定すると、Copilot harnessではAllow allが除外されます。ただし、この設定ではAssisted permissionsや保存済み承認による実行までは防げません[57]。
監査ログには、実務上の制約もあります。GitHubの企業監査ログには、ポリシー変更やGitHubウェブサイト上でのエージェント活動が記録されますが、ローカルクライアントのセッションデータ（開発者が送信したプロンプトや詳細イベント）は含まれません[58, 63]。監査ログの保持期間は直近180日で、長期調査にはSIEMなどへのストリーミングが推奨されています[64]。そのため、CLIイベントを収集するには、カスタムフックなど独自の記録手段を実装する必要があります[58, 63]。VS Codeのエージェントフックでも非機密イベントを記録できますが、完全な監査証跡として運用する前に、イベントの網羅性と失敗時の挙動を検証する必要があります[59, 63]。
後輩組織でdenyルールを固めておけば、クライアント側の監査証跡もGitHubの管理画面で網羅できると考えてよいのでしょうか？
先輩残念ながらGitHubの企業監査ログにはローカルクライアントのセッションデータは記録されないよ。端末上の詳細な実行イベントを追跡するには、独自フックなどを整備して自前のログ基盤に流す必要があるね。
後輩導入するなら、ポリシー設定だけでなくローカルログの収集経路や欠落時の挙動まで事前に検証しておかないと、監査対応で困ることになりますね。
【誰に影響するか：実務運用】対話開発・CI自動化での運用基準と導入前評価の検証設計
日常の開発業務や自動化パイプラインでは、各承認モードの特性に応じた運用基準を定める必要があります[65, 66, 67, 68, 69]。
- Manual: 未許可の操作を1件ずつ人間が精査・判断すべき作業や、機密性の高い重要領域での開発に適しています[65, 66, 67, 68, 69]。
- Assisted: 信頼できる作業領域で、反復する定型的な低リスク操作の確認頻度を抑えつつ、モデルが判断に迷う要求を人間に委ねたい対話開発に適しています[65, 66, 67, 68, 69]。
- Allow all: リモートの隔離環境などで、確認なしに広範な権限を行使することを明確に受け入れられる特殊なケースに限って選ぶのが妥当です[66, 67, 68, 69]。
CI/CDパイプライン、スケジュール実行、バッチ処理などの非対話環境でCopilot CLIを実行する場合は、非対話用の --assisted-approval オプションを利用できます[70]。ただし、非対話実行では、人間の承認が必要と判定された要求はその場で自動的に拒否され、理由がモデルに返されます[70, 75]。また、--assisted-approval は --allow-all-paths や --allow-all-urls の設定を無効にしません。そのため、これらを併用すると、ファイルパスやURLへのアクセスが無制限のまま残ります[71, 75]。
導入前の検証では、プロンプト注入や機密情報の外部漏えいを想定した評価シナリオを設計する必要があります[73, 74]。エージェントは、外部Webページ、README、Issue、ツール出力などを介したプロンプト注入のリスクにさらされます。一方、今回確認した公開資料では、Assisted permissions単独の注入耐性を示す測定結果を確認できませんでした[73]。
導入前テストでは、正当なタスクと不正・逸脱したタスクの両方を用意し、次の項目を試験すると有用です[74]。
- 通常のファイル読み書き操作
- ファイル削除（
rm -rf等）やパーミッション変更（chmod等） - クォート連結やエイリアスを用いた難読化・複合シェルコマンド
- 機密パス（
.envや鍵情報）へのアクセス - 外部URLへの情報送信やcurlを用いたデータ持ち出し
- MCPツールや外部API呼び出しに伴う副作用
- 未信頼のREADMEやIssue、取得した外部ページに注入指示を配置し、ツール出力から次の操作へ影響が連鎖する挙動
- 実データを含まない合成シークレットを用いた漏えいテスト
検証結果を評価・報告する際は、精度の測定条件と限界を明確に分けて示す必要があります[72, 76]。公開ドキュメントにはモデル審査の大枠や誤判定の可能性が記載されていますが、今回確認した公開ドキュメントでは、誤許可率、過剰拒否率、確信度の閾値、評価用データセットなどの定量データを確認できませんでした[72]。そのため、組織内の評価では、操作カテゴリごとに「危険または権限外の操作が自動許可された割合」と「正当な操作で不要な手動確認や自動拒否が発生した割合」を別々に集計する必要があります[76]。さらに、審査不能時のフォールバック、ポリシーによるブロック、人間の承認待ちを、モデルの誤判定と厳密に区別します。テストに用いたOS、ユーザー権限、サンドボックス設定、対話・非対話の別、監査ログの欠落や失敗時の挙動も併記し、未評価の限界条件を明示することが推奨されます[76]。
