GitHub Copilotの権限確認をLLMが判定。安全な操作は承認なしで実行

📖 この記事で分かること

• Copilotの許可確認をモデルが判定する機能が一般提供に
• 対象はCopilot CLI・Copilotアプリ・VS Code
• 管理者はAllow AllとAssistedを別々に止められる
• GitHubは誤承認の可能性とサンドボックスの必要性を明記

💡 知っておきたい用語

• assisted permissions:Copilotが「このコマンドを実行してよいか」と聞く場面で、人の代わりにモデルが一次判定する仕組み。明らかに安全なものだけ自動で通し、残りは人に回す

最終更新日: 2026年10月27日

▶ 公式ページ

• GitHub Copilot assisted permissions are generally available(GitHub Changelog)
• Allowing safe commands(GitHub Docs)

何が変わったか

この記事のポイント

• GitHubが2026年10月26日、Copilotの「assisted permissions」を一般提供(2026年10月時点)
• コマンド実行・パスアクセス・URLを開く要求をLLMが評価し、明らかに安全なものは自動で進む
• 企業管理者はAllow All禁止とAssisted無効化を個別に設定でき、GitHubはサンドボックスの代替ではないとしている

GitHubは、Copilotが操作の許可を求めたときに LLM【エルエルエム】が要求を評価し、明らかに安全なものは自動で進める「assisted permissions」を一般提供しました。Copilotにエージェント的な作業を任せている開発者は、コマンドごとに承認ボタンを押す回数が減り、人が見るのは判定で安全と言い切れなかった要求だけになります。

対象は Copilot CLI【シーエルアイ】、Copilotアプリ、Visual Studio Codeの3つです。発表は2026年10月26日のGitHub Changelogで行われました。

判定の対象と挙動

評価の対象になるのは、Copilotが次の3種類の許可を求めた場面です。

• コマンドの実行
• ファイルシステム上のパスへのアクセス
• URLを開くこと

LLMがこれらを評価し、「明らかに安全」と分類した要求はそのまま進みます。それ以外は従来どおり利用者の承認が必要です。GitHubのドキュメントでは、モデルが安全だと確信できない場合、Copilotは手動承認のときと同じように承認を求めると説明しています。つまり判定が迷った場合は「止まる」側に倒れる設計です。

開発の場面に置き換えると、たとえばCLIでテストやビルドを繰り返し回させる作業で、Copilotが要求ごとに手を止める頻度が下がります。一方で、判定が安全と言い切れない操作は、これまでどおり利用者の確認待ちになります。

管理者が持つ制御

企業向けには、企業で管理する設定(enterprise-managed settings)で次の2つを個別に制御できます。

• 「Allow All」を禁止し、Assistedは使える状態に残す
• Assistedだけを無効にする

すべてを無条件に許可するAllow Allと、モデル判定を挟むAssistedを分けて扱えるため、「全許可は認めないが、判定つきの自動承認は認める」という中間の方針を組織として取れます。

気をつけること

GitHubは、この機能の限界をドキュメントで明確に書いています。assisted permissionsは確認の回数を減らすものの、Copilotの動作に対する利用者の責任はなくならないこと、そしてモデルが誤って危険な操作や意図しない操作を承認する可能性があることです。

さらにGitHubは、この機能がサンドボックスやアクセス制限の代わりにはならないとしています。認証情報や本番環境に届く端末でCopilotを動かしている場合、Assistedを有効にする前に、Copilotが触れられる範囲そのものを狭めておく必要があります。組織の管理者は、Allow AllとAssistedの扱いを現在の設定で確認しておくと、利用者側で意図しない全許可が使われる状態を避けられます。

編集部の見方

編集部は、組織での現実的な落とし所は「Allow Allは禁止し、Assistedは隔離された開発環境で使う」構成だと見ています。

• 根拠1: 管理者はAllow Allを禁止したままAssistedを残せるため、全許可と判定つき自動承認を分けて運用できます。
• 根拠2: モデルが確信できない要求は手動承認に戻る設計で、迷ったときに止まる側へ倒れます。承認疲れで中身を読まずに許可を押す運用よりは、人が見る要求が絞られる分だけ確認の質を保ちやすいと考えます。
• 根拠3: 一方でGitHub自身が誤承認の可能性を認め、サンドボックスの代替ではないと明記しています。判定を安全境界として扱う前提にはなっていません。

この見方が変わる条件は、判定の基準や誤判定の傾向がGitHubから具体的に示された場合です。どの種類の操作でどの程度判定が当たるのかが分かれば、隔離環境の外へ使う範囲を広げる判断材料になります。

よくある質問

Q: どの環境で使えますか?

A: GitHubの発表では、Copilot CLI、Copilotアプリ、Visual Studio Codeで一般提供されています。

Q: モデルが判断に迷った操作はどうなりますか?

A: GitHubのドキュメントによると、安全だと確信できない要求については、手動承認のときと同じように利用者へ承認を求めます。

Q: 組織でこの機能を止められますか?

A: 企業の管理者は、企業で管理する設定でAssistedだけを無効にできます。Assistedを残したままAllow Allだけを禁止することもできます。

まとめ

GitHub Copilotは、コマンド実行・パスアクセス・URLを開く要求をLLMが一次判定し、明らかに安全なものを自動で進める「assisted permissions」を一般提供しました。承認の手間は減りますが、GitHubは誤承認の可能性とサンドボックスの代替ではないことを明記しています。管理者はAllow AllとAssistedを分けて制御できるため、隔離環境と組み合わせた運用が前提になります。

【用語解説】

• Allow All: Copilotの許可要求を判定なしですべて許可する設定。assisted permissionsとは別に、管理者が禁止できる
• サンドボックス: プログラムが触れられるファイルやネットワークを限定した隔離環境。誤った操作が実行されても影響を閉じ込める
• enterprise-managed settings: 企業の管理者が組織全体のCopilotの挙動を一括で決める設定

引用元:

• [1] GitHub Copilot assisted permissions are generally available(GitHub Changelog)
• [2] Allowing safe commands(GitHub Docs)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。