この記事のポイント
- GitHub CopilotのAssisted permissionsが一般提供となり、CLI・アプリ・VS Codeで使えます。
- 操作をモデルが評価し、明らかに安全と判定したものを自動承認します。それ以外は人の確認を残します。
- 企業管理者は全許可モードの禁止や既定モードを設定できます。Assisted自体を無効にすることも可能です。
GitHub Copilotの権限確認を担う新モード「Assisted permissions」について、GitHub公式のリリースノートをもとに整理します。CLI・アプリ・VS Codeの3つで使えるようになった新しい権限の仕組みが、企業での導入判断にどう関わるかを見ていきます。
操作をモデルが評価し、一部を自動承認
Copilotがコマンドを実行したり、ファイルやURLへアクセスしたりする際は、操作をどこまで任せるかを権限モードで管理します。GitHub公式のリリースノート(2026年10月26日付)によると、大規模言語モデル(ひとことで言うと、人が読む自然な文章を理解して判断するAI)が各リクエストの安全性を判定し、明らかに安全と判断した操作だけ確認なしで自動的に進める「Assisted permissions」モードが、GitHub Copilot CLI・GitHub Copilotアプリ・Visual Studio Codeの3つで一般提供(GA)になりました。モデルが操作ごとに評価することが、このモードの特徴です。
設定方法と、変わらない部分
切り替え方はクライアントごとに異なります。CLIでは/permissionsコマンドを実行して「assisted」を選択、Copilotアプリではモードピッカーを開いて「Tool permissions」から「Assisted」を選択、VS Codeでは権限ピッカーから「Assisted permissions」を選ぶだけです。明らかに安全とは判定されなかった操作は、利用者の確認を求めます。自動承認はモデルの判定に基づくため、操作の安全性そのものを保証する仕組みとして扱わないことが大切です。
企業管理者が設定できること
組織でCopilotを導入している場合、管理者側の権限ポリシーとして「全許可(Allow All)を禁止しつつAssistedは使わせる」設定や、「Assisted自体を無効にする」設定、「新規セッションの既定の権限モードを指定する」設定が用意されています。指定した既定モードが利用できない・禁止されている場合は、セッションは従来どおり手動承認から始まるため、既存の運用を急に崩すことなく段階的に試せるのが実務上のポイントです。
まとめ
情報システム部門とCopilot導入チームの間では、使っている開発環境と、組織として許可する権限モードを確認してから試す、という進め方も選択肢になります。あわせてGitHub CopilotのモデルポリシーをAPIで一括管理できるようになった話も参考にすると、操作の承認ルールと利用モデルの設定を区別して整理できます。
確認待ちを減らすことに加え、どの操作を人が確認する運用にしたいかを考えるとよいでしょう。既定値だけでなく、利用者が選べるモードも含めて方針を合わせることが判断の軸になります。
※ 2026年10月時点の情報です。
