「最終判断は人間が」はもう解像度が低い——AIへの判断移譲が静かに完了していた2年間
「AIを使っても、最終判断は人間が行う」という言葉を、ここ数年でずいぶん聞いた。会議でも、ガイドラインでも、報道でも。
ただ、2026年10月時点でこの言葉を聞くと、どこかピントがずれている感覚がある。西尾泰和氏がScrapboxにまとめた記録を読んで、その違和感の正体がはっきりした。問題は「最終判断を人間がするかどうか」ではなく、「何が人間の判断を必要とするものか」という定義そのものが、もうAIに委ねられているという事実だ。
2年間で何が起きたか——判断移譲の年表
整理してみると、変化は急ではなかった。段階的に、ほとんど気づかれないまま進んだ。
2024年3月、起点はDevinとCursorだった。
Devin.aiの発表は「シェル・エディタ・ブラウザを与え、計画から実装・テストまで進めるAIソフトウェアエンジニア」という触れ込みだった。同時期にCursorも登場し、コードエディタにAIが組み込まれるようになった。それまでのGitHub Copilotは「AIが提案 → 人間が承認 → 編集」という流れだったが、ここからその構図が変わり始める。
2024年末、Cursorが「Yolo Mode」を導入した。
2024年12月17日、Cursor 0.44のアップデートで、エージェントがターミナルコマンドを自動実行できる「Yolo Mode」が導入された。YOLOは "You Only Live Once"（人生は一度きり）の略で、逐一の確認・承認を省いて実行するモードの名前として使われた。
西尾氏は当時の肌感をこう記している。「サンドボックスを作らずに生環境でターミナルコマンドを自動実行できるようにするのは流石にやばいだろ」。この感覚は多くのエンジニアに共有されていたと思う。ただ、そう感じながらも使い始めたユーザーも、無視できない数いた。
2025年2〜3月、Claude Codeが承認の概念を再設計した。
2025年2月24日のClaude Code v0.2.9には --dangerously-skip-permissions というフラグが登場した。この時点ではネット接続のないDocker環境に限定されていた。3月18日のv0.2.47では、Shift+Tabでファイル編集の自動承認を切り替える機能が追加された。「どんな編集をするか」を人間がレビューして承認するステップが、選択によって省略できるようになった。
2025年4月には、Codex CLIがSuggest／Auto Edit／Full Autoの3モードを公開。Full Autoはサンドボックス内限定だったが、同時に --dangerously-auto-approve-everything というフラグも存在した。同日、これを --yolo に改名する提案が出ている。2025年8月7日、それが実現した。
2026年、「承認するかどうかの判断」自体がAIへ移った。
ここが最も重要な転換点だ。
2026年3月24日、Claude CodeはAuto modeをチーム向けの研究プレビューとして公開した。実行前に分類器が危険性を判定し、許可できる操作を自動で通す——つまり「何を承認するか」を判定するのが、人間ではなく別のAIになった。
2026年4月23日、Codexアプリに「Automatic approval reviews」が登場。サンドボックス境界を越える要求を、作業担当とは別のエージェントが審査する仕組みだ。
そして2026年7月10日にClaude Code Auto modeが全ユーザー向けに一般提供され、8月14日にはPro・Max・Teamプランで新規セッションの既定がAuto modeへ変更された。AIによる承認判断が、「ユーザーが選んで有効にする機能」から「標準設定」になった瞬間だ。
なぜ人間は判断を手放したのか——速度の非対称性という構造問題
これを「ユーザーの怠慢」や「リスク感覚の麻痺」として片付けるのは、現象の表面しか見ていない。
根本にあるのは速度の非対称性だ。Audrey Tangは2025年9月にこう述べている。
As AI becomes a thousand, perhaps ten thousand times faster than us, we face a fundamental asymmetry. We become the garden; AI becomes the gardener.
（AIが人間より千倍、あるいは一万倍速くなるとき、根本的な非対称性に直面する。人間が庭になり、AIが庭師になる）
岡瑞起氏も同様の構造を指摘している。「エージェントが毎回人間を呼ぶと、人間の注意がボトルネックになる。めったに呼ばないと、人間は探索の行方に関わる機会を失う」。
これは技術的な問題ではなく、設計上のトレードオフだ。毎回承認を求めれば安全性は上がるが、処理が詰まる。承認を省けば速くなるが、人間の関与が薄れる。ユーザーは利便性を取った。それだけの話であり、同時に、その選択の積み重ねが現在地を作った。
「油断」ではなく「合理的選択」だった——この見方が重要な理由
ここからは見方だが、この一連の移譲は無秩序に起きたわけではない点に注目したい。
人間は、不可逆性の低い操作から順に手放した。
最初に手放したのは「コードの提案を受け入れるかどうか」という比較的軽い判断だった。次に「ファイルを書き換えるかどうか」——ただしGit管理下なのでロールバックできる。次が「ターミナルコマンドを実行するかどうか」——ただしDocker環境ならコンテナを捨てればいい。そして生環境へ、Yoloモードへ、と進んだ。
Git・Docker・サンドボックスという「安全弁」が存在したからこそ、「まあここまでならいいか」という判断が積み重なった。西尾氏の記録にも「ロールバックできるなら実害ない」「Docker環境が壊れるだけ」という肌感が丁寧に記されている。これは合理的な判断の連鎖だ。
問題は、その安全弁が効かない領域でも同じ感覚が持ち込まれるリスクだ。「Git管理されているから大丈夫」という感覚は、Git管理されていない本番データや外部APIへのアクセスには通用しない。
実務への示唆：「どこまで委ねるか」の設計が問われる
この流れを踏まえると、実務担当者に考えてほしいことが2点ある。
「承認を省く」と「判断を委ねる」は別物だと認識すること。
承認ステップを省略することと、「何を承認すべきか」の判断基準そのものをAIに委ねることは、まったく次元が違う。前者はUXの問題で、後者はガバナンスの問題だ。Claude Code Auto modeが「分類器が危険性を判定する」設計になっているのは、この区別を意識しているからだと思う。
重要なのは、「危険性の判定基準を誰が設計したか」だ。分類器の判定ロジックは公開されているか。どの操作が「安全」と分類されるかの基準を、利用者は確認したか。承認を省いた後に何かが壊れたとき、責任はどこにあるか。
「自動化範囲」を明示的に設計する組織だけが、この流れを制御できる。
現状、多くの組織はAIエージェントに何かを「任せている」が、「どこまでを任せているか」を明文化できていない。ツールの設定がデフォルトのままということは、ツールベンダーが決めた範囲を暗黙に受け入れているということだ。
2026年2月に逆瀬川氏が公開したスキル設計の考え方——「人間に質問する前に読み込ませ、自ら判断・検証させる」——は、エンジニアリング上の工夫というより、「どこで人間の関与を残すか」の設計思想だ。この設計を意識的に行っているチームと、デフォルト任せのチームでは、同じツールを使っていても運用リスクの種類がまったく異なる。
今後の論点：「人間が庭になる」社会に残る問い
西尾氏は冒頭でこう書いている。「2026年8月、『何が人間の承認を必要とするものか』という判断自体をAIに任せるようになっている」。
これは現時点での観測だが、次の問いはすでに見えている。
「承認すべきかどうかの判断」をAIが担うとき、人間は何を担うのか。作業も、実行も、承認判断も委ねた後に残るのは何か。おそらく「何のために動かすか」という目的設定と、「うまくいっていない」という異常検知の2点だ。ただしその異常検知も、AIが「問題ない」と判断し続ける環境では、人間が問題を認識するタイミングが遅れる。
Audrey Tangの比喩をもう一度使うと、人間が庭になるとき、庭師（AI）が何を育て、何を刈り取るかを決める。庭は意見を言えるか。言えるとしたら、どういう仕組みで。
「最終判断は人間が」という言葉の問題は、それが正しいか間違いかではない。「判断とは何か」「どこからが人間の判断か」を定義せずに使われている点だ。その定義が曖昧なまま、実態だけが先に動いていった——それが2024年から2026年にかけての2年間だった。
同種のニュースを今後見るときは、「何の承認を省いているのか」「省いた後の判断を誰が担うのか」「その判断基準は公開されているか」の3点を確認する習慣を持っておくと、話の実態が見えやすくなる。
