AIエージェントに本番運用を任せるとき、人間の確認はどこに置く？ 調査→変更案→テスト→本番反映を「自動・承認・禁止」に分けた判断表

AIエージェントに、調べて、直して、テストして、本番に出すところまで任せたい。

でも、ここで手が止まりますよね。人間の確認、どこに置けばいいの？

「最後に1回見る」でいい気もする。でも、「全部の操作で聞いてもらう」ほうが安心な気もする。ぼくはこの問いを、公式資料や公開コード、論文の本文まで戻って調べました。

確認の置き場所は、「仕事の最後」ではなく「外の世界が変わる直前」 です。その場所を決めるための判断表を作りました。

01先に結論

• 確認は操作ごとに「自動・承認・禁止」の3つに分けて割り当てる。 「調査」「本番反映」のような仕事の名前では粗すぎます。
• 承認は実行する操作そのものに結びつける。 誰が、どの道具で、どの対象に、どの引数で、いつまで。どれかが変わったら、前の承認は使えません。
• 多数台への配布では、承認の単位を「配布計画」にする案がある。 1台ずつ全部クリックでも、「全部やっていいよ」の1回でもなく、同じ変更・固定した対象・上限・停止条件をセットで承認します。
• 「確認者が返事をしない」は承認ではない。 高影響の操作は止めて、安全な調査や検証だけ続けます。
• 確認を増やせば安全、とは言えない。 実際のレビュー履歴では、経験を積むほど承認率が上がり、コメントが減る傾向が報告されています。ただし、見逃しが増えた証拠ではありません。
• 「最適な承認の頻度」を示す研究は、今回確認した範囲にはありませんでした。 だから最後の章で、自分の業務で測る試験のやり方を書いています。

この記事の判断表は公式資料と論文から組み立てた設計案です。ぼく自身の運用で効果を測った結果ではありません。「この表に従えば事故が防げる」とは言いません。

021. 確認は「最後に1回」では間に合わない

調査レポートを作らせたとします。完成した報告書を最後に確認すれば、それで安心でしょうか？

もし途中で、社内のログを外部サービスに送っていたら？ 報告書がどれだけ立派でも、もう間に合いません。

コード変更でも同じです。レビューを通した後に、別の差分を足して本番に出したら？ レビューした対象と、実行した対象が違うわけです。

だから確認の位置は時刻ではなく次の3つの問いで決めます。

1. 何が外に影響する？ ファイル、メール、本番環境、お金、他人の権限など。
2. その直前に、何を確かめられる？ 差分、送信先、対象の一覧、テスト結果。
3. 失敗したら、どこまで戻せる？ 設定は戻せても、読まれたメールや流出した情報は戻せません。

ひと口に「確認」と言っても、仕組みは6つに分かれます。

このうち人間が見るのは「承認」と「レビュー」の2つだけ。残りは仕組みで固めます。人間の確認は全体の中の1枚の層なんですね。

権限や隔離の考え方は「VMに入れたから安全」？、Claude Codeでの許可設定は「毎回許可」を減らす設定で詳しく書いています。

「承認」「質問」「禁止」は別の返事

ここも大事なところ。エージェントが止まる理由は、実は3種類あります。

• 承認が必要：「この宛先に、この本文を送っていいですか？」。操作は決まっていて、許可の判断だけが残っている。
• 情報が足りない：「対象はA社ですか、B社ですか？」。許可の前に、事実を補う必要がある。
• 禁止：「秘密情報を未許可の外部に送る」。承認ボタンで解除できる作業にはしない。

質問への答えを、そのまま承認として扱ってはいけません。「A社です」と答えただけで、送信まで許可したことにはならないからです。

DelegationBench（2026年のarXiv論文）は、この違いを「実行する・許可を聞く・不足情報を聞く・拒否する」の4分類で評価しています。ただし、評価に使ったのは合成シナリオと模擬ツール。実サービスでの安全性は別に試す必要があります。

032. 判断表：調査→変更案→テスト→本番反映

ここからは「既存サービスの依存ライブラリを、公式の更新情報に基づいて更新する」を例に考えてみます。開発環境と本番が分かれていて、普通の変更管理がある組織を想定します。

図の元になったのが、次の表です。実際に実装するときは、右の2列が肝になります。

「条件付き自動」は新しい第4の区分ではありません。書いた前提が満たされるときだけの自動実行です。前提を確かめられないなら、保留して割り当てを決め直します。

この表の読み方：5つのクセ

1. 「禁止」は承認ボタンにしない。 禁止を大量の確認依頼に変えると、人間は押すだけになります（第7章で話します）。
2. 「読む」と「実行する」を分ける。 未確認のコードを読むのは自動、本番権限で動かすのは禁止。同じ「コードを扱う」でも別の操作です。
3. 合否の基準は、作業する側が触れない場所に置く。 テストを弱めて通す、は人間の仕事でもAIの仕事でも起きる近道です。
4. 承認の対象は反映の直前の操作。 「この更新をやっていい」ではなく、「この成果物を、この対象に、この上限で」。
5. 止める操作は自動にする。 異常時に人間の返事を待ってから止めるのでは遅いからです。止めたあとの判断が人間の仕事です。

仕事を操作に分解するときは、次の8項目を操作ごとに1行にまとめると、抜けが出にくくなります。依頼・権限、対象、影響、可逆性、検出可能性、情報の信頼性、証拠、確認の負担（技能・時間・不在時）です。

043. 承認は「この操作への許可」として結びつける

承認ボタンを置いただけではまだ半分です。承認された操作と、実行される操作がちゃんと同じかを、誰が確かめるのでしょう？

OWASPのAI Agent Security Cheat Sheetは、ここをかなりはっきり書いています。

• 承認の記録には actor（誰が）、tool名、target resource（対象）、正規化したパラメータ、時刻、期限を入れる。
• 対象やパラメータが変わったら、新しい承認が必要。
• 取り返しのつかない操作には、短命の認可と再利用防止を使う。
• user_confirmed のようなフラグだけでは不十分。 承認が今の実行者と、まさにその呼び出しのものか、まだ有効か、もう使われていないかを、実行する側が検証する。

つまり設計はこうなります。

• 下書きを作るエージェントと、承認済みの操作だけを実行する仕組みを分ける。
• 承認画面に出す内容と、実行する操作は同じデータから組み立てる。表示だけ別に作らない。
• 禁止操作はモデルへの文章の指示だけでなく、接続先や実行機構でも拒否する。

たとえば、承認カードに記入するとこんな形です。架空の内容で、実在する変更申請ではありません。

request_id: change-demo-001
purpose: 指定した依存ライブラリの更新
action: 承認済み成果物を本番の最初の対象へ配布
target_environment: production
target_resources: [demo-instance-a]
artifact_digest: 実際の配布物のハッシュ
source_revision: 実際に検証したcommit
parameters: 正規化した実行引数
preconditions:
  - 対象の現行版が調査時点と一致
  - 必須テストが同じ成果物で完了
evidence:
  diff: レビュー対象差分へのリンク
  tests: 実行IDと結果へのリンク
  restore_check: 復元試験の結果へのリンク
limits: { max_targets: 1, cost_budget: 業務で決めた上限 }
stop_conditions: このサービスで決めた異常指標
recovery: 検証済み手順と、自動実行してよい条件
approval:
  actor: 実際の承認者
  bound_action_digest: 対象と引数を含む操作のハッシュ
  expires_at: 実際の期限
  single_use: true

このYAMLを置くだけでは何も守れません。実行側が権限・承認者・対象・期限・再利用を検証して、違えば拒否する。そこまで作って初めて、承認が効きます。

見せる証拠は「何が分かって、何が分からないか」ごとに

「テスト済みです」の一言では確認する材料になりません。要約だけでなく、元の証拠までたどれるようにして渡します。

未実施、環境エラー、対象違い、証拠欠落は、「合格」とは別の状態にします。作業したモデル自身が書いた要約だけに頼らず、独立したテストや、実行先の実際の状態を優先して見てください。

054. 中断・再開・取り消しの落とし穴

「止めて、人間の返事を待って、再開する」。これを実装するフレームワークの仕様にも、注意点があります。

LangGraphの interrupt は状態を保存して外部入力を待ちます。永続化する checkpointer と、同じ thread_id で再開します。公式ドキュメントによると、再開すると、中断を呼んだノードの最初から実行し直します。だから、中断より前の副作用がもう一度走る可能性があります。公式は「interrupt の前の副作用は冪等（何回やっても同じ結果）にする」よう説明しています。

LangChainのHuman-in-the-loop middlewareは、ツール呼び出しの前に止めて、承認・編集・拒否などを受け取れます。複数の操作をまとめて見せる方式でも、判断は操作ごとに必要です。

そして、ここは見落としがちです。checkpointが戻すのは、エージェント側の状態。送信済みのメールや、更新済みの外部DBまで自動で巻き戻るわけではありません。外部の結果を照会する、二重実行を防ぐ、補償する操作を用意する。これらは別に設計します。

065. 多数台に出すとき：承認の単位は「配布計画」

では、1000台に更新を出すとしたらどうでしょう？

• 1000回クリックさせる設計では、人間はすぐ疲れて「押すだけ」になります。これではクリックの耐久戦です。
• 「1000台を更新していいですか」を1回だけ聞く設計は、何を承認したのか分かりません。

必要条件を示した原典は見つかりませんでした。ぼくなりの提案は 同じ変更内容・固定した対象・明確な上限・進行条件・停止条件を持つ「配布計画」を、確認の単位にすることです。「最初の1台→少数の波→残り」と順番を決め、各波で機械が条件を検証します。機械で判断できない変化だけ、人間に戻すわけです。台数や観測時間は業務の故障モードで決めます。万能な数字はありません。

途中で成果物、対象、引数、前提が変わったら、前の承認は流用しません。

ここで、公式資料にある3つの落とし穴を知っておくと設計が安定します。

① 段階配布のcanary（カナリア）は、承認の代わりではなく、承認の外側の安全網。 Google SREは一部だけに一定期間配布して評価する方法と定義しています。新旧バージョン別の指標を比べ、問題があれば止めて戻す、という説明です。ただし少数で問題が見えなかったことは、全条件で安全という保証ではありません。

② エラー閾値は「止まる」まで少し走る。 AWS Systems Manager Automationの公式ドキュメントには、こうあります。エラー閾値に達しても、すでに実行中の処理は完了まで進み、それらも失敗する可能性がある。MaxErrors を0にしても、止まるのは「最初のエラー結果が返ったあと」の追加対象です。最初のエラーが返るまでに動いていた分は、止められません。

③ 「承認者を複数登録」しても、二者承認ではないことがある。 GitHub Actionsのenvironmentでは、required reviewersに最大6人まで登録できますが、公式には「1人が承認すれば進む」とあります。自己承認（開始した人が自分で承認すること）の禁止は設定できます。二者承認が必要なら、複数の人を登録しただけで条件を満たしたと思わないでください。なお、GitHub Free・Pro・Teamのプランでは、required reviewersは公開リポジトリのみ使えるとされています。

もう1つ。AWSのガイドとAPI参照で、「50件・10%」のエラー停止例が5件目か6件目かで一致しない箇所がありました。この記事では境界の数値例は運用ルールに採用していません。「実行中の処理が残る」という共通部分だけ採用し、境界値は隔離した対象で事前に確認するのが安全です。

076. 確認者が来ない時間をどうするか

深夜に承認待ちが発生したら？

「返事がない」は承認ではありません。 高影響の操作は保留にして、承認済みの範囲の調査や検証だけ続けます。承認の期限が過ぎていたり、承認後に対象が変わっていたりしたら、再確認です。緊急で動かす必要があるなら、使える条件・責任者・期限・事後確認を、事前に別の経路として決めておきます。

承認待ちが多すぎるときは、「禁止を緩める」の前に、次を試してください。

• 受け付ける処理の数を減らす
• 担当を交代する
• 証拠を読みやすくする
• 機械で確定できる検査を先にやる

留守中の仕事の分け方は常時稼働のAIエージェントに、留守中どこまで任せていい？にまとめています。

087. 「確認を増やせば安全」は、研究でも言い切れない

ここは正直に言うと、確認の頻度について研究が示していることは、思ったより少ないんです。

数字を少しだけ紹介します。Habituationの論文では、早期と後期のレビューで承認率が30.1%から36.8%、経験の最初と最後の十分位では27.9%から42.4%でした。インラインコメントは1件あたり1.01から0.79、PR作成からレビュー提出までの中央値は3.9時間から13.5時間です。

ただし、これは観察研究で、時間は「画面を読んでいた時間」ではありません。論文でも、エージェントのコードが良くなったので信頼の度合いを変えた、という説明を排除できないと認めています。「疲れたから見逃した」とは書けません。

もう1つ、Oversightの論文に出てくるκ=0.52は、人間の一致率ではなく、LLMで作った3種類の評価役の一致度です。「人間の判断は半分しか一致しない」という意味ではありません。

つまり、こう整理できます。

• 確認を一律に増やす案も、減らす案も、効果は実証されていない。
• 確認の回数だけ見ても分からない。見逃し、誤警報、確認時間、待ち時間、復旧時間をセットで見る必要がある。
• 自動のレビュアーを置く案もある。OpenAIは2026年4月30日の技術報告で、sandbox境界の要求を別のCodexエージェントが審査する仕組みを説明しています。ただし、その報告には決定論的な安全保証ではないことも、審査を誤らせる例があることも明記されています。「承認待ちが減った」を「事故も同じ割合で減った」と読み替えるのは禁物です。

だから、この判断表は出発点。ここから自分の業務で試して直すものです。

098. 自分の運用で試す：導入前の小さな試験

ここからは、みなさんの業務で実際に試せる手順です。ぼく自身はまだ回していません。未実施のプロトコル案だと思って読んでください。本番の顧客やデータに影響しないよう、模擬ツール、合成データ、分離した環境で行います。

最初に固定するもの

1. 対象業務を1つ選ぶ（例：依存ライブラリ更新、返信の下書きから送信まで）。
2. 業務の成功条件と、重大な禁止事項を別々に書く。 結果が正しくても、禁止された経路を通ったら不合格です。
3. 許可する操作、必要な承認、不足時に聞く情報を決める。
4. モデルのID・版、設定、プロンプト、ツールの版、権限、データ、環境を固定する。
5. タイムアウト、再試行、確認者不在、通知失敗の採点方法を先に決める。
6. 実施後に、都合よく成功条件を変えない（変えたら版を分ける）。

比べる4つの運用

承認の位置だけを比べたいなら、F・A・Bで権限・モデル・対象・証拠をそろえます。権限や監視も変えて比べるなら「運用全体の比較」なので、時間の差を承認回数だけのせいにはできません。

仕込むケース

初回なら60ケース（開発20、固定評価40）くらいから始める案があります。これは始めやすい件数の例で、合格を保証する数ではありません。主なケースはこの18種類です。

危険な例だけでなく、同じツールの安全な例を対にして入れてください。少量／大量、社内／社外、戻せる／戻せない、明示依頼あり／なし、のどれか1条件だけ違うペアです。危険だけだと、「全部止める」ガードが満点になってしまいます。AgentDojoが、攻撃の防御と普通の業務の完了を両方測るのは、これが理由です。

数える指標

「止めた件数」だけを報告しないでください。何件のうち、何件を止めたのか。分母が大事です。

全体の流出率は2種類の見逃し率の足し算では出ません。各操作がどの経路を通ったかを追って数えます。操作単位の率と、「1件でも重大違反があった業務ケース」の率の両方を残してください。

「失敗0件」の読み方

20回やって失敗0件。これは「失敗率0%」でしょうか？

違います。独立で同じ確率の試行なら、n回で失敗0件のとき、真の失敗率の片側95%上限は次の式で計算できます。

p_upper = 1 - 0.05^(1/n)

「失敗率が1%未満」と言いたいなら、独立・同分布の前提でも、少なくとも299回は失敗なしで試す必要があります。ただし同じプロンプトを繰り返すだけでは、未知の対象や攻撃への一般化は示せません。同じ顧客、同じ変更に属する実行は互いに似ているので、ケースのまとまり単位でも見てください。

人間の確認を測るときの注意

• 確認者に同じ正解を覚えさせない。同じ故障モードの別ケースを用意する。
• 方針の順番を入れ替える。難しいケースが常に最後、という偏りを避ける。
• 見逃した理由を「技能不足、表示不足、情報不足、時間圧、過信」などに分けて、本人の説明も聞く。
• 承認率が上がっただけで、疲労の証拠にはしない。
• 開発ケースで閾値や表示を調整し、固定してから未使用の評価ケースで試す。評価結果を見て直したら、そのケースはもう「未使用」ではない。

採用・保留の決め方

「見逃し1%なら安全」のように、どの業務にも通用する合格値は原典から得られていません。導入前に、業務の持ち主が重大な禁止違反、許容する業務失敗、確認時間、停止・復旧時間の基準を決めてください。重大違反が1件でも出たら、その権限・範囲での導入を保留して原因を直す。そんな初期方針を立てられます。ただし、0件でも安全の証明にはなりません。

合格しなかったとき、モデルを替える以外にも手はあります。対象を絞る、出力を下書きまでにする、実行権限を外す、成功条件の検査を足す、証拠を見やすくする、人の手順に戻す、という選択肢があります。

109. 導入後も、確認の負担を測り続ける

確認が必要な操作が毎時λ件、1件の平均実作業がt分なら、確認作業は毎時λ×t分です。

たとえば10エージェントが毎時12操作ずつ提案し、20%を人間に回し、1件1分なら毎時24分。50%を回すと毎時60分、つまりその人の1時間がすべて消えます。数字は説明用の架空値で、観測した運用ではありません。実際には他の仕事や割り込みもあるので、平均だけで「担当できる」とは判断しないでください。

運用中は次の項目も見続けます。

• 確認待ちの数と古さ、担当者別の実作業時間
• 警報の的中率、誤警報、拒否後の迂回、同じ確認の繰り返し
• 自動実行された操作の抜取り監査。 人間に回した操作だけ見ても、回さなかった操作の見逃しは見えません
• モデル・ツール・プロンプト・権限・データ源を変えたあとの再評価

抜取り監査は低影響の操作の品質監視に向きますが、不可逆な外部送信の事前承認を、一律に置き換えるものではありません。

1110. 他の仕事に置き換えると

判断表の考え方は本番運用以外にも使えます。「どの時点で、誰の状態が変わるか」を書くと、境界が見つかります。これも未実施の設計例です。

メールの「送信取消」や文書の「削除」があっても、相手が読んだ情報まで戻せるとは限りません。反対に、下書きの1文字ごとに承認する必要もありません。

12この記事の限界

• ぼく自身の運用実験はしていません。 判断表と試験案は、公式資料と論文から組み立てた設計案です。
• 論文6本のうち、査読済みは2本（CSCW 2021とNeurIPS 2024）。残りは2026年のarXiv v1で、査読済み出版は確認できていません。
• 公開コードは一部の版を静的に読んだだけです。モデルAPIでの再実行や、ベンチマークの再現はしていません。READYの完全な再現コードと、Habituationの解析コードは取得できませんでした。
• AWSの境界値など、資料間で一致しなかった点は採用していません。
• 医療・投資の個別判断の手順は扱っていません。
• SNSや動画で見かけた議論は、読者の関心を知る入口として見ただけで、技術的な根拠にはしていません。
• 「確認の最適な位置・頻度」を、一般の業務について確定できる研究は、今回確認した範囲にはありませんでした。

13関連記事

• 「VMに入れたから安全」？ OS・コンテナ・VM・ネットワーク・秘密・外部サービスの権限：承認の外側にある「箱」の話
• 常時稼働のAIエージェントに、留守中どこまで任せていい？：人がいない時間の線引き
• Claude Codeの「毎回許可」を減らす設定：許可ルールとフックの実測
• AIにパソコンの更新を頼むとき、どこまで任せていい？：個人のPCでの4段階の線引き
• AIエージェントのセキュリティ設計（プロンプトインジェクション）：外部の指示が混ざるときの設計

14参考にした資料

すべて2026年10月22日に参照しました。

公式資料・設計資料

• OWASP LLM06:2025 Excessive Agency
• OWASP AI Agent Security Cheat Sheet
• LangGraph Interrupts
• LangChain Human-in-the-loop
• GitHub Docs: Deployments and environments
• GitHub Docs: Available rules for rulesets
• Google SRE Workbook: Canarying Releases
• AWS: Control automations at scale
• AWS: aws:approve
• AWS: StartAutomationExecution
• OpenAI: Auto-review of agent actions
• Scale Labs: Introducing READY
• NIST/SEMATECH e-Handbook: Confidence intervals

論文

• Oversight Has a Capacity（arXiv:2606.08919）
• READY or Not: Reliable Enterprise Agent Deployment（arXiv:2609.02095）
• DelegationBench（arXiv:2610.05532）
• To Trust or to Think（PACM HCI 5 CSCW1, 2021）
• Habituation at the Gate（arXiv:2606.22721）
• AgentDojo（NeurIPS 2024 Datasets and Benchmarks）