生成AIツール

GitHub Copilotの「支援付き承認」が一般提供に、安全な操作はAIが自動で許可

GitHubは10月26日、Copilotがコマンド実行やファイル・URLへのアクセスを求めた際に、別のAIモデルが安全と判断したものだけを自動で許可する「Assisted permissions」を一般提供にしました。CLI、Copilotアプリ、VS Codeが対象で、企業は既定モードや無効化を設定できます。

GitHubは2026年10月26日(米国時間)、GitHub Copilotのエージェントがコマンドの実行、ファイルパスへのアクセス、URLの読み込みを求めたときに、大規模言語モデル(LLM)がその要求を審査し、「明らかに安全」と判断したものは人の承認なしで進める「Assisted permissions(支援付き承認)」を一般提供(GA)にしました。対象はCopilot CLI、GitHub Copilotアプリ、VS Codeです。承認ダイアログを押し続ける手間と、すべてを許可してしまう危うさの中間を公式に用意した形で、エージェントを日常的に使う開発者と、その利用ルールを決める管理者の両方に関係します。

何が変わるのか

これまでCopilotのエージェントが手元で作業するときの選択肢は、実質的に2つでした。読み取り以外の操作のたびに人が承認する「手動」と、--allow-all(別名--yolo)のように確認を一切省く「無条件許可」です。今回の機能は、その間に3つ目のモードを置きます。

GitHubのドキュメントによると、処理の順番は次の通りです。まず、利用者や企業が設定した許可・拒否ルールと、すでに人が承認した内容が確認され、そこで許可済みの要求はモデルの審査なしで実行されます。残った要求のうち、コマンド・パス・URLに関するものをモデルが審査し、安全だと確信できれば自動で承認、確信できなければ従来どおり人に確認を求めます。審査が使えない、または判断できない場合は、そのセッションの通常の承認手順に戻ります。

Copilotの3つの承認モード
出典: GitHub Docs「Allowing safe commands to run without manual approval」(2026年10月時点)

有効化の方法はクライアントごとに異なります。CLIでは/permissionsから「assisted」を選び、Copilotアプリではモード選択の「Tool permissions」から「Assisted」を、VS Codeでは権限の選択メニューから「Assisted permissions」を選びます。

なぜ今この機能なのか

エージェントに長い作業を任せるほど、承認ダイアログの回数は増えます。回数が増えると人は中身を読まずに許可を押すようになり、最終的に無条件許可へ切り替えてしまいがちです。承認の手間を減らしつつ、危ない操作だけは人に回す仕組みが求められていました。

同じ発想の機能は他社にもあります。Anthropicは2026年3月、Claude Codeに分類用のモデルが承認を代行する「auto mode」を導入し、その仕組みと誤判定率を公開しています。実際の利用データでは、安全な操作を誤って止める割合は0.4%に抑えられた一方、行き過ぎた操作の見逃しは52件中17%ありました。製品も審査モデルも異なるため、そのままCopilotに当てはめることはできませんが、「モデルによる承認は見逃しがゼロにはならない」という目安にはなります。

GitHub自身もドキュメントで「モデルは誤ることがあり、危険な操作や意図しない操作を承認する可能性がある」「サンドボックスやアクセス制限の代わりにはならない」と明記しています。10月7日に一般提供されたローカルサンドボックスと組み合わせて使う前提の機能と考えられます。

押さえておきたい細かな仕様

審査に使うモデルはCopilotが選び、会話で選んだモデルとは異なる場合があります。そのモデルが使えないときは、セッションで使っているモデルで審査することがあります。自前のモデル提供元を設定している場合は、セッションのモデルで審査されます。審査がプレミアムリクエストを消費するか、対象プランはどれかは、changelogとドキュメントのいずれにも記載がありません。

モデルが審査するもの・しないもの
出典: GitHub Docs「Allowing safe commands to run without manual approval」(2026年10月時点)

注意したいのは、自動実行(autopilot)や非対話の実行では、人の承認が必要なまま残った要求は「拒否」として扱われる点です。拒否の理由はCopilotに返され、別のやり方を試させます。CIなどで動かす場合、処理が止まる代わりに迂回策を探す挙動になると考えられます。また、CLIで--assisted-approvalを指定しても--allow-all-pathsや--allow-all-urlsを併用するとパスやURLへのアクセスは無制限のままです。

日本の企業・開発者にとって

管理者側は、enterprise-managed settingsのpermissionsで挙動を決められます。disableBypassPermissionsModeを"disable"にすると無条件許可を禁止でき、disableAssistedPermissionsModeをtrueにすると支援付き承認を禁止できます。前者だけでは支援付き承認は止まらず、後者だけでは無条件許可は止まりません。新しいセッションの既定はdefaultMode("manual"/"assisted"/"allow-all")で指定でき、ポリシーで使えないモードが既定になっていると手動承認で始まります。

社内でCopilotを展開している企業にとっては、「無条件許可は禁止し、支援付き承認を既定にする」という中間の運用ルールが現実的な選択肢になると考えられます。ただ、審査モデルに送られる内容や保存期間はこのページでは説明されていないため、機密性の高いリポジトリでは確認してから広げるのが安全です。エージェントの予期しない行動については、OpenAI社内のコーディングエージェントが監視を無効化した事例も参考になります。

次にやることは3つです。

  • 管理者はpermissionsの3項目(無条件許可の禁止、支援付き承認の可否、既定モード)を社内方針として決める
  • 開発者は重要度の低いリポジトリで支援付き承認を試し、自動で通った操作と確認を求められた操作の境目を把握する
  • 自動実行やCIで使う場合は、ローカルサンドボックスと拒否ルールを先に設定し、承認待ちが拒否扱いになる前提でジョブを組む

出典

関連記事

生成AIツールの記事 →