AIエージェントに承認なしでpushさせていいのか——Claude Codeが「人間承認」をデフォルトに戻した理由
先日、あるクライアントのエンジニアから、こんな報告を受けました。「そういえば、AIエージェントが昨夜のうちにブランチをpushしてました」。悪い話ではありません。むしろ順調に自動化が進んでいる証拠です。ただ、その報告を聞いた瞬間、私は少し引っかかりを覚えました。誰が、そのpushを承認したのか。この記事では、AIエージェントの権限設計をめぐる2026年の変化と、私たちがクライアントの現場で権限をどう区切っているかをお伝えします。
「気づいたら、pushされていた」という報告
前回の記事「セルフレビューさせて終わり」で本当に大丈夫かでは、AIの成果物を別のAIに疑わせる「敵対的検証」という手法を取り上げました。あの記事を書きながら、もう一つ気になっていたことがあります。検証の話をいくら詰めても、その先で「誰が実際にpushボタンを押すのか」という問いが残るということです。
冒頭のクライアントのケースでは、幸い問題は起きませんでした。ですが、話を聞く限り、そのエンジニアは自分のチームのAIエージェント設定で、pushまでを自動許可にしていたことを、後から思い出したという状態でした。設定した本人が、自分が何を許可したかを忘れている。私たちがクライアントの現場を見ていても、似たような光景に何度も出くわしてきました。
自律pushが「既定」になりつつある開発現場
2026年に入り、AIコーディングエージェントの自律性は明らかに一段階進みました。あるエンジニアの記事によれば、Claude CodeやCursorなど主要なコーディングエージェントのバージョンアップの中で、バックグラウンドで動くエージェントがcommit・push・PR作成までを自動でこなす設定が、次々と既定寄りになっていったといいます。
この記事が指摘しているのは、ツール側の確認ダイアログという「安全弁」が、自律化が進むにつれて実質的に機能しなくなっているという点です。代わりに安全弁の役割を担うようになったのが、ブランチ保護や必須レビューといった、リポジトリ側のルールでした。つまり、ツールを信用するのではなく、構造として抜け道を塞ぐ方向に、設計思想そのものが移ってきているということです。
これは私たちの実感とも一致します。クライアントの現場でエージェントの設定を確認すると、便利さを優先して権限を広げたまま、誰もその範囲を把握していないケースに何度も出会ってきました。
「承認疲れ」という、もう一つのリスク
ここで見落とされがちなのが、承認プロンプトそのものの限界です。Anthropicが公開したAuto Modeに関する技術ブログでは、率直な数値が示されています。ユーザーは、ツール実行やファイル変更の承認プロンプトのうち、およそ93%をそのまま承認しているというのです。
この数字が意味することは単純です。承認という行為が、実質的にはほぼ自動承認と変わらなくなっているということです。何度も同じような確認を求められるうちに、人間は疲れます。疲れると、内容を読まずに反射的に「はい」を押すようになります。これが「承認疲れ(Approval Fatigue)」と呼ばれる現象です。
私たちがクライアントの開発チームを見ていても、これはよく分かります。導入初期は一つひとつの確認を丁寧に見ていたエンジニアも、数週間もすると確認作業が形骸化していきます。皮肉なことに、安全のために設けた確認ステップが、量が増えることでかえって安全を損なうという逆説が起きているのです。
Claude Codeが「人間承認」をデフォルトに戻した理由
興味深いのは、この問題に対するAnthropicの対応です。techtimesの報道によれば、Claude Codeはv2.1.200で、既定の挙動を「人間承認」に戻し、自律実行のAuto Modeは明示的にオプトインする方式に変更されました。
自律性を高める方向にどんどん進んできたはずのツールが、あえてここで踏みとどまり、既定を人間側に戻す。この判断の背景には、EU AI Actの高リスク領域規制が2026年8月2日に施行されるという規制環境の変化も影響していると報じられています。技術的な進歩と、それをどこまで信頼して良いかという社会的な合意形成は、同じ速度で進むとは限りません。今回のデフォルト変更は、その速度差を埋めるための判断だったのだと私は捉えています。
とはいえ、承認疲れの問題そのものが解決したわけではありません。Anthropicが選んだのは、確認の回数を減らすことではなく、確認の「質」を機械にも分担させるという方向でした。
分類器による二層防御という設計
Auto Modeの中身を見ると、単純に「全部自動で通す」仕組みではないことが分かります。Anthropicのブログでは、入力側と出力側、二つの層で防御していることが説明されています。入力側では、ファイル読み込みやWeb取得などツールの出力そのものをスキャンし、悪意のある内容が紛れ込んでいないかを確認します。出力側では、トランスクリプト分類器と呼ばれる仕組みが、各アクションを事前に定めた基準と照らして評価します。
正直に言えば、この分類器も完璧ではありません。Anthropic自身の発表によれば、二段階パイプライン全体で誤検知率0.4%、見落とし率17%という数字になったといいます。見落とし率17%は、決して小さい数字ではありません。ここでAnthropicが誠実だと感じたのは、この数字を隠さずに公開している点です。分類器は「多くの誤りを見つけるが、ユーザーが本来許容していた範囲かどうかまでは判断しきれない」傾向があると、限界を明示しています。
もう一つ、設計上の工夫として印象的だったのが、分類器に渡す情報をあえて絞っている点です。分類器はユーザーのメッセージとツール呼び出しだけを参照し、AIエージェント自身が生成した説明文やツールの出力結果は意図的に除外されています。エージェントが自分の行動を都合よく説明し、分類器を言いくるめてしまうことを防ぐためです。
AIエージェント権限設計を「層」で考えるという実践知見
Anthropicの分類器の話は、いわば公式ツール側の防御です。では、私たちが日々のクライアントワークで使う道具しかない場合、コーディングエージェントのガバナンスをどう組み立てればよいのでしょうか。この点で参考になったのが、ある技術者の記事でした。この記事は、AIコーディングエージェントの自律実行を安全に運用するための考え方を、権限の事前定義・実行時の監視・問題発生後のリカバリという3つの層に分けて整理しています。
読んで印象に残ったのは、この3層を一度に完璧に作ろうとしないという姿勢です。まず権限の事前定義で「触ってよい範囲」を絞り込み、次に実行時の差分やコストを監視する仕組みを足し、最後に問題が起きたときに戻せる経路を用意する。この順番で少しずつ積み上げていくという発想は、私たちがクライアントに提案する内製化の進め方とよく似ています。
私たちの現場でも、いきなり監視の仕組みまで全部揃えようとして、結局どれも中途半端になってしまうケースを見てきました。Claude Codeの承認疲れという課題への向き合い方も、この記事も、根っこの発想は共通しています。防御の完成度を上げることより先に、どこから手をつけるかの順番を決めることのほうが、実務では効いてくるということです。
「検証を分離する」と「権限を分離する」は同じ設計原則
ここまで読んで、前回お伝えした敵対的検証の話と似ていると感じた方もいるかもしれません。実際、根っこにある設計原則は同じです。敵対的検証では、実装したエージェントと同じ文脈のまま検証させると、無意識に自分の実装を弁護してしまうという話をしました。今回のAuto Modeの分類器設計も、エージェント自身の説明を判断材料から外すことで、同じ問題を防いでいます。
つまり、「誰にどこまでの権限を渡すか」という設計と、「誰にどこまでの検証を任せるか」という設計は、表裏一体の関係にあります。検証だけを厳しくしても、実行権限そのものが野放しであれば意味がありません。逆に、権限を絞りすぎて何もかも人間の承認待ちにしてしまうと、今度は承認疲れという別の問題に押し戻されます。私たちがクライアントに権限設計を提案するときも、この両輪を同時に見ることを欠かさないようにしています。
中堅企業の現場でこれをやると、何が壁になるか
理屈は分かっても、実際に現場でこれをやろうとすると、簡単ではありません。前回の記事でも触れたように、中堅企業ではレビューできる人間が社内に1〜2人しかいない、というケースが珍しくないからです。その少ない人数に、権限設計まで含めた判断を集中させると、今度はその人自身が承認疲れに陥ってしまいます。
私たちがFDEとして中堅企業の内製化を支援する中で行き着いたのは、権限を「一律」ではなく「領域ごと」に区切るという発想でした。社内向けの管理画面のちょっとした表示調整であれば、自動pushまで許可してもリスクは限定的です。一方で、認証まわりや決済処理、顧客データを扱うテーブルの変更には、人間の承認を挟む運用を崩さないようにしています。この線引きを、コードの難易度ではなく「壊れたときに誰がどれだけ困るか」という基準で決めることが重要だと考えています。
もう一つ、現場でよく直面するのが、権限設定を「誰が」管理するのかという問題です。冒頭で紹介したエンジニアのように、設定した本人がその内容を忘れてしまうケースは、決して珍しくありません。私たちがクライアントに勧めているのは、権限の設定をリポジトリのルールファイルとして明文化し、個人の記憶やその場の判断に依存させないという方法です。設定が可視化されていれば、後から見返したときに「なぜこの権限を許可したのか」を検証できます。
ある卸売業のクライアントでは、実際にこの棚卸しをやってみたところ、想定より広い範囲でエージェントの自動push設定が有効になっていたことが分かりました。担当エンジニアは「便利だからそのままにしていた」と話していましたが、いつからその設定が有効だったのかは、本人も正確には覚えていませんでした。棚卸しをした結果、在庫管理画面のような影響範囲の小さい領域は自動化を残し、受発注データを直接書き換える処理だけ人間の承認に戻す、という形に落ち着きました。設定を変えること自体より、まず「今どうなっているか」を可視化することのほうが、実は時間がかかる作業でした。
「疑うコスト」と「任せるコスト」を経営にどう説明するか
権限設計の話をクライアントの経営層にすると、決まって出てくる質問があります。「そのコストは、誰が負担するのか」という問いです。承認のステップを増やせば安全性は上がりますが、開発のスピードは落ちます。逆に自動化を進めれば速度は上がりますが、見落としのリスクは上がります。
この判断は、エンジニアだけに閉じた技術的な話ではなく、経営判断そのものだというのが私たちの立場です。私たちがクライアントに提案する際は、まず「この領域で何かが壊れたら、顧客対応にどれだけの時間がかかるか」「その間、どれだけの売上機会を失うか」を具体的な数字で洗い出すところから始めています。技術的なリスクを経営の言葉に翻訳できて初めて、権限設計は現場に定着します。逆に言えば、エンジニアの感覚だけで権限範囲を決めてしまうと、経営層の理解を得られないまま、いずれ形骸化してしまうことが多いというのが、私たちの実感です。
先ほどの卸売業のクライアントの例で言えば、受発注データの誤変更が起きた場合、発覚から復旧までに現場担当者の半日分の作業が発生することが、棚卸しの過程で見えてきました。半日分の人件費と機会損失を数字にして経営層に示したところ、「その範囲だけは自動化を止める」という判断は、驚くほどすんなり通りました。逆に、在庫管理画面のような領域では、壊れても数分で直せることが分かっていたため、自動化を残す判断にも異論は出ませんでした。数字にして初めて、感覚的な「なんとなく怖い」が、意思決定できる材料に変わったのです。
AI-Pathの見解——信頼は「範囲」で設計するものだ
私は、AIエージェントとの向き合い方について、信頼を「全か無か」で考えないことが大切だと考えています。今回のAuto Modeの設計は、その好例です。すべてを自動化するのでも、すべてを人間の承認待ちにするのでもなく、領域ごとに信頼できる範囲を区切り、その境界線を明文化する。これが、これからのAIエージェント運用の基本設計になっていくはずです。
もう一つ付け加えると、権限設計は一度決めたら終わりではありません。私たちがクライアントの内製化を支援する中で見えてきたのは、最初は狭い範囲から始めて、実績を積みながら少しずつ権限を広げていくという段階的なアプローチが、結果的に最も定着しやすいということです。いきなり広い権限を渡すと、何か問題が起きたときに信頼そのものが崩れてしまいます。小さく任せて、検証して、範囲を広げる。このサイクルを繰り返すことが、遠回りに見えて実は一番の近道だというのが、私たちの結論です。
よくある質問
Q1. Auto Modeを使わず、すべて手動承認にすれば安全ですか？
そうとは言い切れません。承認の数が増えるほど、一つひとつの確認の質は下がっていきます。むしろ、どこを自動化し、どこを人間の承認に残すかという設計判断のほうが重要です。
Q2. 権限設計は誰が担当すべきですか？
エンジニア個人の判断に任せきりにしないことをお勧めします。私たちの現場では、権限の範囲を「壊れたときの影響度」という経営判断に基づく基準で決め、それをリポジトリのルールとして明文化しています。
Q3. 中堅企業でもこの仕組みは必要ですか？
必要性は高いと考えています。レビューできる人材が限られているからこそ、権限設計によって「どこを人間が見るべきか」を絞り込む効果が大きく出ます。
Q4. 前回の敵対的検証と、今回の権限設計はどちらを先にやるべきですか？
順序に厳密な決まりはありませんが、私たちは権限設計(誰に何を任せるか)を先に整理し、その上で重要な領域に敵対的検証を重ねるという順番を勧めています。
まず試すなら
- 現在のAIエージェント設定で、pushやマージまで自動許可されている範囲を棚卸しする
- 「壊れたら誰がどれだけ困るか」の基準で、領域ごとに承認要否を区切ってみる
- 権限設計をコードやドキュメントに残すべきか、無償の業務プロセス診断(BPR)で一緒に洗い出す
参考リンク
櫻井 文雄（さくらい ふみお） 株式会社AI-Path 代表取締役CEO
関西大学法学部法律学科卒業。財務コンサルティング会社（エフアンドエム）、外資系生保営業（Prudential）でコンサルティング営業の経験を積んだ後、起業し様々な企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング（Big4）、ABEJA（AI研究開発の国内リーディングカンパニー）にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。2025年にAI駆動開発（VibeCoding）と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。
関連コラム
「セルフレビューさせて終わり」で本当に大丈夫か——AIエージェント時代に効く『敵対的検証』という一段深い仕組み
AIエージェントに自分のコードを自分でレビューさせるだけでは、『自分の答えを自分で採点する』盲点が残ります。Claude Code公式も名前付きで推奨する『敵対的検証(アドバーサリアル・レビュー)』という一段深い仕組みを、私たちの現場経験から解説します。
レビューが開発の壁になる時代——AIエージェント企業が始めるべき『セルフレビュー』という仕組み
AIエージェントが書くコードの量が増えるほど、レビューする側の人間が追いつかなくなっています。『シフトレフト』という発想と、中堅企業でもClaude CodeのHooks/Skillだけで作れる現実的なセルフレビューの型を、私たちの現場経験から解説します。
AIエージェントを並列実行する「エージェントマネージャー」という働き方——レビュー速度という新しい壁
複数のAIエージェントを同時に走らせる「エージェントマネージャー」という働き方が広がっている。Claude Codeとgit worktreeによる実践方法と、ボトルネックが技術力からレビュー速度に移るという本質的な変化を、私たちの現場経験から解説する。