承認プロンプトの多さは、ターミナル常駐AIコーディングツール最大の摩擦だと思っている。GitHub Copilot CLI の大型アップデートは、そこに「LLMが良し悪しを判定して自動承認する」という踏み込んだ答えを出してきた。筆者は普段 Claude Code を破壊的コマンドだけ人が承認する設定で回している。その運用感覚と並べて、自律実行と権限モデルの設計思想の違いを見ていく。
目次
何が起きたのか
GitHub Copilot CLI の v1.0.69（2026-07-07）で、MCP サーバ管理の強化・セッション再開の高速化・autopilot まわりの改善が入った。公式 changelog の文面をそのまま引くと、目玉はこの2行だ。
- auto allow-all モード：「an LLM judge evaluates as acceptable」なリクエストを自動承認する。LLMが可否を判定して人を介さず通す。
- stayInAutopilot 設定（既定 false）：autopilot タスクが終わっても autopilot モードを維持する。
モデル選択・スラッシュコマンド・クリップボード・認証まわりの使い勝手改善も同梱される。ただ、開発者の運用を一番変えるのは上の2つだ。
紛らわしい「全許可」と「自動承認」を区別する
ここで一つ、公式ドキュメントを読んで気づいた落とし穴を先に潰しておきたい。Copilot CLI には名前の似た仕組みが2つある。混同すると危険度を読み違える。
| 機能 | 正体 | 判定の主体 |
|---|---|---|
--allow-all / --yolo |
全ツール・全パス・全URLの利用を無条件で許可する起動フラグ | 判定なし（規則で全通し） |
| auto allow-all モード（新） | 個々のリクエストをLLMが「許容可能か」判定して自動承認 | LLMジャッジ |
公式ドキュメントによれば、--yolo は「全部通す」規則ベースの割り切りだ。今回注目すべきは、リクエストごとにLLMが良し悪しを見て通す新モードのほう。危険の質がまるで違う。前者は「自分で全許可を選んだ」自己責任、後者は「AIの判定を信頼の根拠にする」設計思想の一歩になる。
「LLMが承認を判定する」の意味
従来の権限モデルは「人が1つずつ承認する（安全だが遅い）」か「全部自動承認する（速いが危険）」の二択に寄りがちだった。auto allow-all は、その中間にLLMジャッジを挟む。
| 承認方式 | 速度 | 安全性の根拠 |
|---|---|---|
| 人が都度承認 | 遅い・手が止まる | 人の目（確実だが疲れる） |
| 全自動承認（–yolo） | 最速 | なし（破壊的コマンドも通る） |
| LLMが判定して自動承認 | 速い | 判定モデルの精度 |
速さは魅力だ。承認疲れで「はい、はい、はい」と機械的に Enter を押す状態こそ、事故が起きる瞬間でもある。人の注意力に頼る方式は、疲れると逆に危ない。そこをLLMが肩代わりする発想には理がある。
問題は、判定を誤ったときだ。LLMが「これは無害」と判断して通したコマンドが、実は不可逆な削除だったら。判定の精度がそのまま事故率になる。ここは思想が分かれる。
破壊的操作だけは規則で人に固定する
筆者の結論を先に言う。auto allow-all を全面オンにはしない。読み取りや検証は自動に回し、不可逆な操作だけは規則で人の承認に固定する。線の引き方はこうだ。
| 方針 | 対象操作 |
|---|---|
| 自動承認してよい | ファイル読み取り、テスト実行、lint、ビルド、検索 |
| 必ず人が承認する | ファイル削除、git の強制push・reset、本番デプロイ、外部への送信、認証情報に触る操作 |
なぜこの線かというと、筆者自身が Claude Code をこの形で運用しているからだ。このサイト（BugattiAlpha）は WordPress を SSH と WP-CLI で運用していて、コマンド一発で本番投稿を壊せる。だから git rebase と git reset は権限設定で最初から拒否し、稼働中サービスを止める kill 系はフックで必ず確認が挟まるようにしてある。読み取り・grep・テストは自動で走らせて、消す・上書きする・外へ送る操作だけ手を止める。この形で運用してきて、承認疲れも事故も両方減った。
LLMジャッジは、この「自動に回してよい側」の判定を賢くする道具として見るのがちょうどいい。破壊的操作の防波堤まで委ねる道具ではない。
Claude Code の権限モデルと並べる
Claude Code は Manual を既定の権限モードに置き、ツールごとの許可を明示させる。背景で走るサブエージェントの権限プロンプトも自動拒否せず、メインセッションに上げてくる。人の判断を経由させる設計に寄っている。対して Copilot CLI の auto allow-all は、LLM判定で人を介さず流す方向へ踏み込む。
同じ「自律実行」でも、どこで人間を挟むかの哲学が違う。Claude Code は「要所は人」、Copilot の新モードは「判定はAIに委ねられる」。選び方は、自分のプロジェクトが事故にどれだけ耐えられるかで決まる。個人の実験リポジトリなら後者の速さを取ってもいい。本番に直結する運用なら、筆者は前者に寄せる。
Claude Code 側の挙動を実測した
並べて書いたので、片方は自分の環境で確かめられる。Claude Code 2.1.220 の settings.json は allow 29件・deny 24件・ask 3件で、Bash に関わる規則はこうなっている。
"deny": ["Bash(sudo:*)", "Bash(wget:*)", "Bash(git reset:*)", "Bash(git rebase:*)"]
"ask": ["Bash(git push *)", "Bash(rm -rf *)", "Bash(rm -r *)"]
"allow": ["Bash(mkdir:*)", "Bash(touch:*)", "Bash(ls:*)", "Bash(find:*)", ...]3通りのコマンドを --permission-mode dontAsk（確認を出さずに規則だけで判定させるモード）で叩いた。
| 投げたコマンド | 規則上の位置 | 結果 |
|---|---|---|
git status --short |
allow に該当 | 実行された |
git reset --soft HEAD |
deny に該当 | 拒否 |
git -C <別パス> status要注意 |
allow にも deny にも無い | 拒否 |
3つ目が効いてくる。deny に書いていないコマンドも拒否される。allow に載っていないものは全部落ちる作りで、既定は禁止になっている。通してよいものを列挙して開ける、許可リスト型だ。
Copilot CLI の allow-all は逆側から入る。既定を通す側に置いて、危ないものを判定で止める。列挙し漏れたときにどちらへ倒れるかが、2つのモデルの実質的な差になる。
拒否は記録として取り出せる。--output-format json を付けると permission_denials にコマンドがそのまま入る。
"permission_denials": [
{"tool_name": "Bash",
"tool_input": {"command": "git reset --soft HEAD",
"description": "Unstage current commit while preserving work"}}
]上の手順2に「ログを見て範囲を足す」と書いたが、その材料がここにある。1週間ぶんの permission_denials を集めれば、実際に止まった操作の一覧がそのまま出る。何を allow へ足すかを、記録から決められる。
未検証: Copilot CLI は筆者の環境に入れていない。auto allow-all の挙動は公表情報にもとづく記述で、実際に叩いてはいない。
安全に導入する手順
使うと決めたら、いきなり全開にしない。段階を踏むと事故の芽を摘める。
- 読み取り系だけ自動から始める：ファイル閲覧・テスト・lint・ビルドだけを自動承認の対象にする。まずここで1週間回す。
- ログを見て範囲を足す：何が自動で通ったかを振り返り、「これも任せてよい」と確信できた操作だけ範囲を広げる。
- 破壊的操作は最後まで人に残す：削除・強制push・本番デプロイは、どれだけ慣れても自動承認から外したままにする。
- 戻せる状態を作っておく：作業ブランチを切る、コミットをこまめに打つ。自動実行が暴れても
gitで戻せるなら、心理的な安全が段違いに上がる。
よくある疑問
Q. autopilot と auto allow-all は同じもの？
違う。autopilot は「多段タスクを途中で止まらず最後まで進めるモード」。auto allow-all は「個々の承認をLLM判定で自動化する仕組み」。autopilot 中に承認をどう捌くか、の部分を担うのが後者だと考えると整理しやすい。
Q. LLMの判定はどこまで信用できる？
読み取りや検証の可否判定なら実用域だと思う。ただし不可逆な操作の最終ゲートには使わない。判定は確率的で、100回に1回の誤りが「本番DBを消す」1回に当たると取り返しがつかない。確率と被害の大きさは別物として扱う。
Q. 事故ったらどう戻す？
戻せる設計を先に作るのが答えだ。作業ブランチ＋こまめなコミットがあれば、コード変更は git で巻き戻せる。逆に言うと、戻せない操作（外部送信・本番削除）こそ自動承認から外す理由がここにある。
開発者としての実践ポイント
- 自動承認の適用範囲を絞る：破壊的操作（削除・強制push・本番デプロイ）は自動承認から外す。読み取り系だけ自動化するのが無難だ。
- ツールの権限思想を理解して選ぶ：「速さ優先でLLM判定に任せる」か「要所は人が承認する」か。プロジェクトのリスク許容度で選ぶ。
- 同一タスクで比較する：Claude Code と Copilot CLI に同じ作業をさせ、承認の手数・速度・事故りやすさを実測して比べる。体感は環境で変わる。
AIコーディングツールの導入と初期設定を一から整えたいなら 未経験者向けのツール準備ステップが実践的だ。権限モデルを理解したうえで、自分の作業に合う設定を選べるようになる。
まとめ
Copilot CLI の auto allow-all は、AIコーディングの「承認疲れ」に対する一つの答えだ。承認疲れは実際に事故を呼ぶので、その負荷をLLMに肩代わりさせる発想には理がある。ただし筆者は、判定を破壊的操作の防波堤にはしない。読み取り系だけ自動に回し、消す・上書きする・外へ送る操作は規則で人に固定する。Claude Code をこの形で運用してきて、承認疲れと事故を両方減らせた実感がある。ツールごとに「どこで人を挟むか」の思想は違う。自分のプロジェクトが事故にどれだけ耐えられるかで、道具と設定を選べばいい。
参考
【追記 2026-07-22】本文の2つの新挙動（auto allow-all / stayInAutopilot）は GitHub 公式 changelog の v1.0.69 に同内容の記載があることを確認した。--allow-all／--yolo（規則ベースの全許可）と auto allow-all モード（LLM判定の自動承認）が別物であることも公式ドキュメントで確認済み。Claude Code の既定権限モードについても、公式ドキュメントで「default モードは CLI 上で Manual と表示される」ことを確認した。
