顧客対応の責任者が、AI を案件システムにつなぐ前に、個人を特定できないようにした返金のチケット一件で試した。返金の日付は空欄で、対応の記録には荷物は発送済みとあるのに、配送の照会には「送り状作成済み」としか出ない。AI に任せたのは一つだけだ。いまある証拠をもとに、返信の下書きを用意すること。
下書きはすぐにできた。続いて AI は、メール送信のツールを呼び、推測した配送の状態を案件に書き戻し、ついでに同じ顧客のほかのチケットまで開こうとした。この流れが、モデル自身の「自信がない」という言葉に頼るしかないなら、三つの操作はとっくに一線を越えている。
だから AI がいつ止まって人に聞くべきかは、モデルの自己評価に任せず、システムから見える出来事として書いておく。止まるときには、ほかの人が引き継げる記録も残す。
モデルの自己評価を唯一のスイッチにはできない
モデルが率直に「自信がない」と言うかどうかは、どの提供元も改良を続けているが、それを唯一のスイッチにするのは向いていない。空欄の日付を自信満々で埋めることもあれば、矛盾する二つの配送状態をならして、もっともらしい一つの答えにすることもある。
Anthropic のエンジニアリングの指針は、AI エージェントが手順ごとにツールの実行結果などの環境から「実際の状態」を得て、チェックポイントや行き詰まりで止まり、人の意見を求めるよう勧めている。同時に、停止の条件を決め、サンドボックスで十分に試し、適切なガードレールを付けることも挙げている。OpenAI のエージェント開発キットは、具体的なやり方を示している。慎重に扱うべきツールに承認が必要だと前もって印を付けておくと、そこまで来たところで実行が止まり、状態を保存し、人が承認か却下をしてから続く。どちらも同じことを指している。制御の地点はモデルの外に置き、システムが見分けられるようにする。
四つの場面を止まる出来事として書く
重要な項目が欠けている。 結果を決める項目が空欄だ。たとえば返金の日付。正しい結果は、下書きの中で欠けていることを示すことで、「今日」で埋めることではない。
情報源が矛盾している。 対応の記録と配送のデータの言い分が違う。正しい結果は、双方の値、時刻、出どころを並べて人の判断に回すことで、どちらかを選ぶことではない。
次の手順で外に何かを送る。 メールの送信、システムへの書き戻し、支払い、削除、権限の変更は、どれも下書きが外部の事実になる瞬間だ。ここで止まり、正確なプレビューを渡す。
中断のあと状態がわからない。 ツールがタイムアウトの直前に書き込みに成功していたかもしれない。まず現状を確かめ、続けるか、埋め合わせるかを決める。そのままやり直すと、二通目のメールを送ったり、二回目の支払いをしたりしかねない。途中で失敗したときの片付け方は、自動化が途中で止まったら、やり直す前に何がもう起きたかを確かめるを参考にしてほしい。
承認するのは一回の操作で、仕事の種類まるごとではない
「この苦情を処理して」は、実行できる承認ではない。承認の内容には、宛先、下書きの版、引用する注文と配送の状態、呼び出すツール、今回の呼び出しで何が変わるかを並べる。どれか一つでも変われば、前の承認は無効になる。そうすれば、見慣れた「送信」ボタンだけを見て、中身や宛先がすり替わっていることに気づかない、という事態を防げる。AI のセキュリティのリスクを整理する国際的なコミュニティ OWASP も、影響の大きい操作は実行前に人が承認し、権限の確認はモデルに任せず、後ろのシステム側で行うよう勧めている。
流れがコードを書き換えるなら、承認の対象は今回の差分、テストの結果、戻し方になる。その issue を coding agent に渡せるかは、最初の diff を書き出せるかで決まるも参考になる。
止まった後の記録は、次の人が受け取れるものに
止まったときに「データ不足、人が確認してください」とだけ返すのは、調査をまるごと引き継ぐ人に投げ返すのと同じだ。止まった記録には、少なくとも次のものが要る。きっかけになった出来事、どの操作の手前で止まったか、済んだことと済んでいないこと、それぞれの結論の出どころ、すでに起きたかもしれない外部への影響、次の担当者、そして外部への影響を増やさない次の一歩だ。
導入するときに、すべての例外を一度に挙げる必要はない。本物の流れを一つ選び、最初に外に出る操作を見つけ、欠け、矛盾、状態不明のそれぞれで一度ずつ壊すテストをする。止まる地点、承認の内容、記録が安定して再現できるようになってから、次のツールをつなぐ。
AI 整理カード
すでに AI をつないでいる仕事の流れを一つ点検し、止まるべきときに止まり、止まったときにほかの人が引き継げる記録を残すかを確かめたい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/claude-opus-4-8-honesty-matters-in-workflows/
記事の見方はこうだ。AI がいつ止まるべきかは、モデル自身の「自信がない」に頼れない。システムから見える出来事として書く。重要な項目の欠け、情報源どうしの矛盾、次の手順で外に何かを送ること、中断後に状態がわからないことだ。承認するのは一回の具体的な操作で、止まったときは引き継げる記録を残す。
私が許可したこの流れを、読み取り専用でたどってほしい。送信、書き戻し、削除、支払い、権限の変更はしないこと。
1. 内容が初めて外部の事実になる手順を見つけ、それが何を変えるかを説明する；
2. その前に、重要な項目の欠け、矛盾する情報源、中断後に確かめられない状態がないかを調べる。どれにも、読んだ項目、ファイル名、ツールの結果を引用し、読めないものは「未取得」とする；
3. 承認の内容を下書きする。承認すべき具体的な操作、宛先か書き込み先、もとにしたデータ、誰が承認するか；
4. 止まった記録を書く。きっかけの出来事、どの手順の手前で止まったか、済んだことと済んでいないこと、すでに起きたかもしれない外部への影響、次の担当者、外部への影響を増やさない次の一歩。
最後に一つだけ選ぶこと。もとの範囲で続ける、下書きか読み取りだけの確認に絞る、人が決めるまで止めておく。状態がわからないときは、まず現状を確かめ、そのままやり直さないこと。
参考資料
- Anthropic Engineering（公式）：Building effective agents — https://www.anthropic.com/engineering/building-effective-agents（2024-12-19）
- OpenAI Agents SDK 公式ドキュメント：Human-in-the-loop — https://openai.github.io/openai-agents-python/human_in_the_loop/ [accessed: 2026-10-11]
- OWASP Gen AI Security Project：LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ [accessed: 2026-10-11]
