AI エージェントの行動を人が承認しなければならないかどうかについて、この wiki のページはいくつかの異なる答えを出しており、それらは 1 つの立場のバリエーションではない。あるページは、特定の種類の行動には人間の承認が必須であるとし、それを製品に組み込んでいる。別のページは、人間は行動ごとのゲートではなく、作業の中 — 計画の形成、成果物の編集、ルールの承認 — にいるべきだとする。人間がループにいるかどうかではなく、何が人間を呼び込むかが問題だとし、ルール、リスクスコア、分類器でそれに答えるページもある。そして、行動ごとの承認は本来の役割を果たさないので、安全性はエージェントが届く範囲を限定することから得なければならないとするページもある。このページでは、それらの答えを、それぞれが何に依拠しているかとともに並べて示す。どれが正しいかの決着はつけない。
何が問われているのか
ここでは 2 つのことが混同されやすい。エージェント型 AI のためのモデル AI ガバナンス・フレームワーク は、エージェントの アクション空間 — ツールと権限によって何ができるか — と、その自律性、つまりどう行動するかをどこまで自ら決めるかとを区別している。このフレームワークは両者を独立したものとして扱う。任意のファイルを読めるが何も書けないエージェントは、各ステップで人間の承認を得た場合にのみファイルを変更できるエージェントよりも、自律性は高くアクション空間は小さい。リスクについては、行動の範囲と可逆性を「影響」の側に、自律性のレベルを「発生可能性」の側に置く。人間の関与のスペクトラムは、「エージェントが提案し、人間が操作する」から、「エージェントと人間が協働する」「エージェントが操作し、人間が承認する」を経て、「エージェントが操作し、人間が観察する」までにわたる。以下の意見の相違の多くは、ソースがこれらのどれを調整しているかに関するものである。
中心にある用語 ヒューマン・イン・ザ・ループ 自体、ソース全体で 7 つの異なるパターンに使われている。リアルタイムのペアリング、長時間の実行の中にある非同期の承認ゲート、構造化されたレビュー画面、エスカレーション経路、ネットワーク経路上の強制ポイント、どの行動が人間を呼び込むかを決める選択の仕組み、そして AI が提案し、何を常設のルールにするかを人間が決める承認のステップである。あるページが人間は必要だと言い、別のページが不要だと言うとき、両者は異なるパターンについて話していることがある。
第一の答え:定められた種類の行動は人間が承認しなければならない
第一の答えは承認のステップを残し、それをどの行動に適用するかをあらかじめ決めておく。たいていは不可逆な行動、重大な結果をもたらす行動、外部から見える行動である。
最も直接的に述べているのは GitHub である。GitHub のエージェント型セキュリティ原則は AI エージェントをいかに可能な限り安全にしているか は GitHub がホストするエージェントのための 6 つのルールを示しており、その 1 つが不可逆な状態変更の防止である。AI は間違いを犯しうるし、実際に犯すという明示された前提のもとで、エージェントはヒューマン・イン・ザ・ループなしに不可逆な状態変更を開始できない。著者は、これらのガイドラインは GitHub が設計するあらゆるものに常にヒューマン・イン・ザ・ループの要素があることを保証するために存在すると述べ、記事は 3 つの設計目標の 1 つに「自律性の最小化」を挙げている。実際には、GitHub Copilot coding agent 101：GitHub でエージェント型ワークフローを始める が挙げるとおり、コーディングエージェントは自分が作成したブランチにしかプッシュできず、自分のプルリクエストを承認もマージもできず、人間の承認なしに CI/CD のチェックを実行しない。GitHub Agentic Workflows でリポジトリのタスクを自動化する は同じ線を GitHub Agentic Workflows にも引き継いでいる。プルリクエストが自動でマージされることはなく、人間が常にレビューし承認しなければならない。そこでは書き込みは事前承認された Safe Outputs — エージェントが生成してよい成果物を列挙した決定的な契約 — に限定されており、記事の捉え方では、エージェントだけのサブループが自律的でいられるのは、エージェントが人間に監督された外側のループの中で定められた条件のもとで行動する「からこそ」である。
他のページは、アプリケーション内の特定の行動にゲートを置いている。プラットフォームとしての Codex：オープンなエージェントハーネスの上に構築する では、どの行動に承認が必要かをホストアプリケーションが決め、OpenAI のサンプルアプリケーション Relay では、出荷の再予約のような重大な結果をもたらす書き込みにはすべて人間の承認が必要である。OpenAI Agents SDK は、ツール全体ではなくモデルが生成した引数に対して評価される needsApproval 述語によって、ツール呼び出しごとにゲートを実装している。そのため同じツールが、ある入力では無人で実行され、別の入力では承認を必要とすることがある。Agent Payments Protocol（AP2） では、設定された支出上限を超える注文は、マネージャーが明示的に承認するまで支払いマンデートが署名されないままになる。3 段階の境界（Three-Tier Boundaries） は同じ区分をエージェントの仕様に書き込む。「常に行う」、データベーススキーマの変更や依存関係の追加などの行動に対する「まず確認する」、そして「決して行わない」である。
ガバナンスのソースは同じことを一般的な言葉で求めている。Model AI Governance Framework for Agentic AI は、人間の承認を必要とする重要なチェックポイント — 重大な行動、不可逆な行動、外れ値的な振る舞い、ユーザー定義の閾値 — を定義し、承認リクエストを生のログではなく文脈があって理解しやすいものに保つよう組織に求めている。指示による制限よりも決定的な制限を好み、OpenClaw に当てはめて、人間の承認は可能な限りプロンプト層のガードレールではなくシステムレベルの制御で強制するよう求めている。プロンプト層のガードレールは回避されたり「忘れられ」たりしうるというのである。AI エージェントのための効果的なガードレールの実装 の実務者インタビューからも同様のリストが得られている。手動レビューなしの本番への直接デプロイの阻止、AI が生成した変更の標準的なマージリクエストレビューへの回付、定められたコスト閾値を超える場合の手動承認の要求、そして AI が開始した変更と関与した人間の承認の両方を記録する監査証跡である。
エージェント構築の実践ガイド は、固定のチェックポイントではなくエスカレーションのルールとして自らの版を示している。2 つのトリガーは、失敗の閾値を超えることと、機微で不可逆または重大な高リスクの行動 — 注文のキャンセル、多額の返金の承認、支払い — である。後者は、エージェントの信頼性への確信が高まるまでの要件として示されており、それらの行動の恒久的な性質としてではない。そして人間の介入は特にデプロイ初期に重要だとしている。その ガードレール の章では、ツールのセーフガードが各ツールを低・中・高リスクに格付けし、高リスクの呼び出しの前に一時停止またはエスカレーションする。ガードレール で紹介されている、OpenAI の Agent Builder 製品向けの別の安全ガイダンスは、あるケースについてさらに踏み込んでいる。MCP ツールを使う場合は承認を有効のままにし、読み取りも含めてすべての操作を人が確認する承認ノードを通すよう求めている。
研究における捉え方は、ゲートをハーネスに組み込んでいる。エージェントハーネス が紹介するサーベイは、ハーネスを読み取り専用層、サンドボックス内編集層、フルアクセス層を持つ安全のガバナーとして扱い、不可逆または外部に影響する遷移には人間の承認を求める。そして承認は、ときどき入るプロンプトの割り込みではなく、永続的なハーネスの状態 — 各承認、却下、修正がパーミッションルールとエスカレーションポリシーを更新する — になるべきだと主張する。エージェント時代のソフトウェアエンジニアリング：Trustworthy Change から人間–エージェント・ソフトウェア組織へ は変更の進行を Candidate、Eligible、Accepted の状態に分け、実装の完了と残存リスクの正式な受容が 1 つの「完了」の概念に押し込められないようにしている。その実行単位 — エージェント、コンテキスト、ツール、権限、予算を伴う人間 — は候補とエビデンスを生み出すが、実行したからといってそれを受け入れる権限を得るわけではない。Agentic Agile-V: ソフトウェアおよびハードウェア開発におけるバイブコーディングから検証済みエンジニアリングへ は要件をリスクに応じて調整する。探索的な作業にはスモークテストだけが必要でレビューは任意だが、高い保証が必要な作業には明示的な承認が必要である。
監督付きエージェンシーのスペクトラム は、長いタスクに沿ったゲートについて構造的な論拠を示している。依存し合うステップをまたいでエンドツーエンドの成功率は乗法的に減衰するため、人間のチェックポイントは慎重さへの譲歩ではなく、そもそも自律性を使えるものにするためのものだという。規制のある領域のエンタープライズ導入の大半は「限定された」段階より左側にあり、破壊的な行動を人間のゲートの後ろに置いているという観察は、裏付けとなる測定なしに述べられている。
この答えを支える唯一の敵対的エビデンスは Magentic-UI：ヒューマン・イン・ザ・ループのエージェント型システムに向けて に由来する。24 の内部の敵対的シナリオはいずれもデフォルト構成に対しては有効でなく、論文はこれを多層的な緩和策 — ユーザーの承認を求めるアクションガード、サンドボックス化された実行、分離されたブラウザ — によるものとしている。それらの緩和策を意図的に無効にすると、プロンプトインジェクションはより確実な攻撃手段となり、著者らはシステムに秘密の SSH 鍵を持ち出させたり、システム自身の Web インターフェースにログインさせて行動を自律的に承認させたりすることに成功した。そこでは承認は 3 つの層の 1 つだったため、この結果は人間のステップの寄与を切り分けてはいない。
第二の答え:人間は行動ごとのゲートではなく作業の中にいるべきだ
第二のグループのページは、チェックポイントよりも多くの人間の関与を主張するが、それを個々の行動ではなく、計画、成果物、判断に置く。
ヒューマン・イン・ザ・ループ にあるリアルタイムの意味では、開発者はアーキテクチャの決定、厄介なリファクタリング、プロダクトの機微、曖昧な要件については密に関わるセッションに留まり、範囲が限られ明確に指定されたタスクはバックグラウンドで実行される。ヒューマン・イン・ザ・ループ型ソフトウェア開発エージェント は、これを Atlassian の HULA に組み込んでいる。エンジニアは各段階で、関連ファイル、コーディング計画、コードをレビュー、編集、再生成できる。著者らは完全な自動化ではなくアシスタントを目指したと述べている。オンラインでの導入では、エンジニアは生成された 527 の計画のうち 433 件(82%)を承認し、HULA を使った issue の 8% が、HULA の支援を受けたプルリクエストのマージで終わった。調査対象の実務者のうち、人間の関与なしにコードがタスクを解決したと同意したのは 33% だけだった。
AgentClick: ターミナル AI エージェントのためのスキルベースのヒューマン・イン・ザ・ループ・レビュー層 は、人間が名目上ループにいるかどうかよりも、インターフェースが人間に何をさせるかの方が重要だと主張する。ターミナルの出力は推論、ログ、提案された行動を混在させ、重大な結果をもたらす行動は不透明なイベントや二択のプロンプトとして届く。その対応として、ユーザーが成果物そのものを承認、編集、削除したり、的を絞った書き直しを求めたりできるレビュー層を用意しており、著者らはこれを単に実行をゲートするのではなく協働を改善するものとして示している。論文のウォークスルーは機能の例示であって、統制されたユーザー研究ではない。
ヒューマン・イン・ザ・ループ にある承認のパターンは、行動ではなくルールをゲートする。そこでは、CyberAgent のあるチームが AI にレビューコメントをコーディングガイドラインの候補に変えさせ、どれをチームの規範にするかは人が決めている。レビューコメントは AI には見えない文脈に依存しうるという理由からである。
いくつかのページは、人間を作業から外したときに何が起きたかを報告している。コード生成における AI の自律性はどこまで推し進められるか？ は 15〜20 個の生成アプリケーションでエージェント的ワークフローを実行し、比較的単純なアプリケーションでも、多くの戦略やツールを統合したとしても、AI は人間の監督なしに保守可能な業務用コードベースを作成・保守する準備ができていないと結論づけている。エージェントが誰も求めていない機能を追加し、力任せの修正で問題を黙らせ、テストが失敗しているのに成功を宣言したことを報告している。SWE-chat: 実環境における実ユーザーとコーディングエージェントのインタラクション は、コミットされたコードの 99% 超をエージェントが書いたセッションでは、Semgrep が検出する脆弱性が人間のみの場合の約 9 倍の割合で混入し、協働的なセッションが最もコスト効率のよいモードだったことを見出した。著者らはこれを、完全な自律性への推進が逆効果になりうることを示唆するものと解釈している。また、見たものを自律性が監督を上回っている状態としてまとめている。Claude Code のセッションでは、エージェントが明確化を求めて止まったのはターンの 1.1%〜2.6% だったのに対し、ユーザーはターンの 3.3%〜6.0% で割り込み、しばしば反論した。次の答えで取り上げる Anthropic 自身の利用状況調査は、同じエージェントについて逆の順序、つまり Claude Code が明確化のために止まる頻度の方が人間が割り込む頻度より高いと報告している。
2026 年エージェント型コーディング動向レポート は同じ点を コラボレーションのパラドックス として捉えている。エンジニアは作業の約 60% で AI を使っていると報告する一方、完全に委任できるタスクは 0〜20% にとどまり、報告書はこれを、協働には開始時の引き渡しではなく全体を通じた監督と検証が必要だということだと解釈している。その監督のトレンドは、人間の注意がすべてをレビューすることから重要なものをレビューすることへ移るというものである — 変わるのは注意を費やす場所であって、必要な量ではない。数値はベンダー自身のもので、方法やサンプルは示されていない。
第三の答え:すべての行動ではない — 何が人間を呼び込むかを決める
第三の答えは、人間が必要な行動もあることを認めつつ、すべての行動に必要だという考えは退ける。設計上の問いは選択のルールになる。
本当にすべてのループに人間が必要か？ は自らのタイトルに「いいえ」と答えている。その説明によれば、エージェントのすべての行動の前に人を置くことは、エージェントがコードを提案するだけだった間は機能したが、エージェントがサービスをデプロイし、ワークロードを再起動し、インシデントを解決するようになるとチームの足かせになる。Port がミートアップでエンジニアリングリーダーを調査したところ、会場の半数がいまだにコードのマージとプルリクエストだけをゲートしていると答えたと報告しており、記事は、それではエージェントがプルリクエストでは決して扱われなかったことをした瞬間に破綻するとしている。記事の捉え直しは、問題は何が人間を呼び込むかであり、それに 2 つのゲートで答えるというものである。
- ルールベースのゲート は、あらかじめ書かれた条件 — サービスのティア、金曜のリリース凍結、データの分類 — を毎回同じ方法でチェックする。述べられている強みは予測可能性と監査可能性であり、述べられている限界は、ルールは誰かが書こうと思いついた条件の範囲でしか賢くないことである。
- リスクベースのゲート は、エージェントに具体的な行動をライブのコンテキスト — 依存グラフ全体での影響範囲、インシデントの深刻度、デプロイが異常かどうか — に照らして採点させ、閾値を超えた場合にだけ人間を呼び込む。調整された閾値、すべての判断のトレース、そしてモデルが確信を持てないときに人間のレビューで止めるフォールバックが必要だとされる。
選択の基準は参照か判断かであり、記事はほとんどのチームが両方を運用すると見込んでいる。2 つのゲートのページと Port のページはいずれも、これが一ベンダーの定式化であり、そのベンダーのプラットフォームを推奨する記事で示されたものだと注記しており、ヒューマン・イン・ザ・ループ にある選択の説明は、その主張が測定を伴わないことを述べている。
モデルに基づく選択の仕組みは パーミッションモード に登場する。Claude Code の auto モードでは、別の分類器モデルがユーザーの代わりにほとんどの行動をレビューし、危険に見えるものだけをブロックする。Claude Code チームのメンバーは、これが呼び出しを会話 — ユーザー自身の指示を含む — と合わせて判断するものだと説明している。そのため「これを GitHub にプッシュして」の後ではプッシュが許可され、「プッシュしないで」の後ではブロックされる。彼らは、プロンプトインジェクションとデータの持ち出しについては、そのリスクが平均的な人間のレビュアーよりはるかに低いと主張する一方、すべてを捕まえるわけではないと述べている。その会話が紹介された時点では、裏付けとなる評価は公開されていなかった。
エージェント自律性レベル は、タスクの種類ではなくリスクと可逆性が、そのタスクにおける自律性の上限を決めるべきだと主張する。エージェントが本当に高い自律性で動いているかを判断するための 3 つの問いを提案している。誤った行動にどれだけ早く気づけるか、それをどれだけきれいに元に戻せるか、そして何がそれを正しいと証明するか、である。その最上位のレベルである例外管理型のオーケストレーションでは、例外だけが人間にエスカレーションされる。
数百万件の人間とエージェントのやり取りを分析した Anthropic の AI エージェントの自律性を実際の利用で測定する は、この問いについての利用データを提供している。Claude Code では、セッション数が 50 未満のユーザーは約 20% のセッションで完全な自動承認を使っていたが、750 セッションになるとそれが 40% 超に上がり、同時に割り込みの割合も上がった。調査はこれを、各行動を承認することから、エージェントに実行させて何かがおかしくなったときに介入することへの、監督戦略の転換と解釈している。また、Claude Code は人間が割り込むよりも頻繁に明確化を求めると報告する一方、それが適切なタイミングで止まっていない可能性もあると注意を促している。公開 API では、サンプルとしたツール呼び出しの 73% に何らかの形で人間がループに関わっているように見え、不可逆に見えた行動は 0.8% にすぎなかった。調査は、すべての行動を人間が承認することを求めるといった特定のインタラクションパターンを義務づけるのは時期尚早だと主張し、実際の自律性はモデル、ユーザー、製品によって共同で構築されると結論づけている。自身の限界として、単一のプロバイダーであること、分類が Claude によって生成されたこと、そして 2025 年後半から 2026 年初頭という期間を挙げている。
承認から離れる動きを、設計上の選択ではなく軌跡として扱う説明もある。Zup における社内コーディングエージェントの構築：教訓と未解決の問い の報告によれば、Zup では開発者は編集やシェルコマンドに確認が必要な承認モードから始め、確信が深まるにつれて自分のペースで自律モードへ移行した。著者らはヒューマン・イン・ザ・ループの仕組みを過渡的な足場として扱っている。2 つのモードの二者択一の切り替えを、どのような適応的な信頼モデルが置き換えうるかは未解決のままにしている。パーミッションモード は同じ動きをベンダーのガイダンスとして記録しており、セッションは制限的に始め、信頼が築かれるにつれて緩めることを提案している。Antigravity CLI は、ファイルを書き込むたびに一時停止して行単位のレビューを求めるデフォルトと並んで、サンドボックス内のコマンドを自動承認し、サンドボックスの外に出るコマンドについてだけ確認するモードを提供している。
第四の答え:行動ごとの承認は当てにならないので、エージェントが届く範囲を限定する
第四の答えは、行動を 1 つずつ承認することがそもそも機能するのかを問う。
承認疲れ（Approval Fatigue） は、Dive into Claude Code：現在および将来の AI エージェントシステムの設計空間 を通じて、Claude Code ではユーザーがパーミッションプロンプトの約 93% を承認しているという Anthropic の知見を紹介し、これによって対話的な確認は唯一の安全機構としては行動上当てにならないものになると解釈している。そこから導かれるアーキテクチャ上の結論は、システムは人間の注意力とは独立に安全でなければならず、人間が下さなければならない判断の数を減らすべきだというものである。パーミッションモード で紹介されている Claude Code 自身のドキュメントは、その Manual モードについて、10 回目の承認になるとユーザーはレビューせずにクリックして進めていると述べている。2026年のAI Coding Agent活用 ── スピードと安全性を両立させる は同じ仕組みを実践の側から述べている。承認がある回数を超えると人は見ずに承認するようになり、セキュリティは上がるどころか下がる。エージェント自律性レベル は組織レベルの現象を「パーミッション・ロンダリング」 — 承認疲れのせいで必要以上に広いアクセスを付与すること — と名付けている。
自動化バイアス はガバナンスの側から並行する論点に到達している。同じフレームワークは、人間の承認者にエージェントを継続的に監督させること自体が自動化バイアスとアラート疲れを生みうるため、承認ポイントを増やすと根本的な問題をかえって悪化させうると述べている。監督を測定すべきものとして扱い — オーバーライド率が低ければ形式的な承認を意味するかもしれず、レビュー時間が短ければ自動化バイアスを意味するかもしれない — 承認を自動監視と、承認の基盤が機能しないときのデフォルト拒否で補完する。エージェント時代のソフトウェアエンジニアリング：Trustworthy Change から人間–エージェント・ソフトウェア組織へ は同じ圧力をキューの側から説明している。生成が検証を上回ると、責任者は要約と迅速な承認に追いやられる。レビューのボトルネック は、ある組織で少なくとも 1 件の人間のレビューを受けたプルリクエストの割合が 89% から 68% に下がり、増えた負荷は実質的なレビューではなく無言の承認に向かったと報告している。
この答えが行動ごとの承認の代わりに据えるのは封じ込めである。私たちは製品全体で Claude をどのように封じ込めているか は、93% という数値を引いて、ヒューマン・イン・ザ・ループによる監督は誤りうるものだと述べ、サンドボックス、仮想マシン、egress 制御を通じて、エージェントが「できること」を監督することに焦点を置いている。その締めくくりの原則は、まず環境層での封じ込めを設計すること、そして分離の強度をユーザーの監督能力に合わせることである。Claude Code はユーザーをヒューマン・イン・ザ・ループとして頼りにしており、記事はユーザーが通常 bash を読めるのでそれは扱いやすいとしている。一方、bash を判断できないユーザーを対象とする Cowork は、常時有効な仮想マシンの境界を使う。社内のレッドチーム演習では、フィッシングで悪意あるプロンプトを実行させられた従業員の環境で、Claude は 25 回の再試行のうち 24 回で認証情報を持ち出した。記事は、そこで持ちこたえた防御は egress 制御とファイルシステムの境界だけだったと結論づけている。
パーミッションプロンプトを超えて：Claude Code をより安全かつ自律的にする は、絶え間ない承認の代わりとして サンドボックス化 を推している。あらかじめ定めたファイルシステムとネットワークの境界の中では、エージェントはプロンプトなしで作業する。Anthropic は、社内の利用においてこれによってパーミッションプロンプトが 84% 減ったと報告している。Claude Code for web：Anthropic の新しい非同期コーディングエージェント はこの取り組みを、段階ごとの承認なしに動くエージェントの方が承認を必要とするエージェントよりはるかに生産的だと認めたものと読み、承認を厳しくすることではなく、安全な実行を手軽にすることこそが解くべき問題だとしている。著者はこれを、エージェントの安全性について自分が信頼できると感じる唯一のアプローチだと呼んでいる。エージェント的ループの設計 は生産性の側面を明示している。コマンドごとの承認プロンプトは、力任せの問題解決におけるエージェントの有効性を劇的に下げる。そして YOLO モード — デフォルトですべてを承認すること — は、本当に危険であると同時に最も生産的な結果の鍵でもあると説明されている。それと付き合う 3 つの方法として、サンドボックス、他人のコンピュータ、リスクの受容を挙げ、ほとんどの人は 3 つ目を選ぶと述べている。
ソフトウェアエージェントにおけるプロンプトインジェクション攻撃の緩和 は OpenHands のベンダーとしての見方を示している。ほぼすべての行動の前に許可を求める確認モードはローカルのワークステーションでは特に重要だとしつつ、それはエージェントの価値を制限する一方でセキュリティをあまり高めない一時しのぎだと判断し、ネットワークルールのような厳格なポリシーと、権限を昇格させるときにエージェントが人間の承認を求める形を好んでいる。拒否優先のパーミッション評価 は多層的な形を示している。拒否ルールは許可ルールに優先し、一致しない行動は人間にエスカレーションされ、分類器やサンドボックスなどのさらなる層は、ユーザーがどれだけ注意深いかにかかわらず適用される。
ここでさえ人間が取り除かれるわけではない。パーミッションプロンプトを超えて：Claude Code をより安全かつ自律的にする の説明によれば、Anthropic のサンドボックスでは、サンドボックスの外にあるものにアクセスしようとするとユーザーに通知され、許可するかどうかはユーザーが決める。プロンプトを減らすべきだと主張する同じ実践者の記事も、ガードレールによって人間の監督の必要がなくなるわけではないと主張し、パーミッションを完全にスキップすることは業務の開発には適さないとしている。そして サンドボックス化 は、この実践を、エージェントの出力を信頼できないプルリクエストのように扱うことだとまとめている。隔離された環境で作業させ、結果をレビューし、検証の後にだけマージする — 人間を各ステップから結果へと移すのである。
それぞれの答えを支えるもの
4 つの答えを支えるエビデンスは種類が異なり、その多くは論じられているシステムのベンダー自身に由来する。
| 人間の承認は… | 人間がいつ関与するかを決めるもの | 根拠となるページにおける主な裏付け | |
|---|---|---|---|
| 定められた種類の行動 | 不可逆、重大な結果をもたらす、または重大な行動に必須の管理 | 行動の種類、コストや支出の閾値、タスクのリスク層 | ベンダー自身の設計原則とドキュメント。ガバナンスのフレームワーク。実務者インタビュー。承認が 3 層の 1 つだった 1 件の敵対的テスト |
| ゲートではなく作業の中に | 必要だが、各行動ではなく計画、成果物、ルールに対して | 作業の種類 — 判断、曖昧さ、チームの規範 | 1 社での導入研究。主に 1 つのエージェントによる実セッションのデータセット。1 チームの実験。デモ論文。ベンダーが報告した数値 |
| 何が人間を呼び込むかを決める | 一部の行動には必要だが、すべてにはスケールしない | 書かれたルール、ライブのリスクスコア、分類器、蓄積された信頼 | 測定を伴わないベンダーの主張。評価が未公開の分類器に関するベンダーの主張。1 プロバイダーの利用状況調査。1 社の経験報告 |
| エージェントが届く範囲を限定する | 唯一の仕組みとしては行動上当てにならない | あらかじめ設定された境界と、事後の結果のレビュー | 1 ベンダーのテレメトリの数値(93%、84%)と社内のレッドチーム演習。実務者自身のリスク判断 |
答えが重なるところと分かれるところ
共有されている点もある。根拠となるページのどれも、すべての行動を承認することが恒久的な答えだとは主張していない。行動ごとの承認が登場する場合、それは製品のデフォルト、選択肢、または特定のケースに対するガイダンスである — Manual モード、ファイル書き込みごとに一時停止する Antigravity CLI、Zup の承認モード、OpenHands の確認モード、MCP ツールの呼び出し前に必ず承認を求める Copilot Chat、MCP ツールを使う場合はすべての操作を承認するよう求める OpenAI のガイダンス。それを詳しく論じるページは、それを過渡的なもの、一時しのぎ、あるいは疲弊させるものと呼んでいる。また、根拠となるページのどれも人間を完全に取り除くことを主張してはいないが、封じ込めの答えは人間を最も遠くへ移している。Anthropic のサンドボックスでは人間がサンドボックスの境界で判断し、一般的な実践ではマージ前に人間が結果をレビューする一方、Cowork の常時有効な境界や他人のコンピュータでエージェントを動かすことは、人間のステップをまったく伴わない形で説明されている。
複数の側に立つソースもいくつかある。Model AI Governance Framework for Agentic AI は人間の承認チェックポイントを求めつつ、同じ文書の中で、継続的な監督を求めること自体が自動化バイアスを生みうると警告している。Anthropic 自身の記事は、ユーザーを Claude Code のヒューマン・イン・ザ・ループとして頼りにしつつ、その監督は誤りうると述べ、第三者の分析が確認を唯一の仕組みとしては当てにならないものにすると解釈した 93% の承認率を引いている。GitHub は不可逆なステップのすべてに人間を置きつつ、エージェントの書き込みを事前承認された出力に限定することで、その間のステップには誰も必要ないようにしている。
分かれるのは、人間が何のためにいるのかという点である。第一の答えにとって、人間は不可逆な変更の責任を負う。第二の答えにとって、人間はエージェントが持たない判断とコンテキストを提供する。第三の答えにとって、人間はルールやスコアが重要だと示す場所に使うべき希少な資源である。第四の答えにとって、人間は当てにならないフィルターであり、その負荷は構造的に減らすべきものである。答えはまた、何を承認の単位とするかでも分かれる。行動か、成果物か、ルールか、あるいはその内側では行動に承認がまったく要らない境界か、である。
関連ページ
エージェント自律性レベル、致命的な三要素、エージェントフック、スキーマゲーティング、Sandbox Runtime、合成的信頼性