CLAUDE LABEN
FORK — Claude Code 2.1.212で/forkの挙動が変わりました。会話を新しいバックグラウンドセッションへ複製し、作業を続けたまま並走できます。従来のセッション内サブエージェントは/subtaskに移りましたLIMITS — WebSearchの呼び出しがセッション単位で既定200回に制限されました。サブエージェントの起動も既定200回が上限で、暴走した検索・委譲のループを止められますMCPBG — 2分を超えるMCPツール呼び出しは自動的にバックグラウンドへ移り、セッションが固まらなくなりました。しきい値はCLAUDE_CODE_MCP_AUTO_BACKGROUND_MSで調整できますPLANFIX — プランモードがtouchやrmといったファイルを変更するBashコマンドを、許可プロンプトもcanUseToolコールバックも通さずに実行してしまう不具合が修正されましたSONNET5 — Claude Sonnet 5は導入価格として入力100万トークンあたり2ドル、出力10ドルで提供中です。8月31日を過ぎると3ドルと15ドルに戻りますIPO — Anthropicが早ければ10月の株式公開を視野に、引受銀行が投資家との面談を組み始めたと報じられていますFORK — Claude Code 2.1.212で/forkの挙動が変わりました。会話を新しいバックグラウンドセッションへ複製し、作業を続けたまま並走できます。従来のセッション内サブエージェントは/subtaskに移りましたLIMITS — WebSearchの呼び出しがセッション単位で既定200回に制限されました。サブエージェントの起動も既定200回が上限で、暴走した検索・委譲のループを止められますMCPBG — 2分を超えるMCPツール呼び出しは自動的にバックグラウンドへ移り、セッションが固まらなくなりました。しきい値はCLAUDE_CODE_MCP_AUTO_BACKGROUND_MSで調整できますPLANFIX — プランモードがtouchやrmといったファイルを変更するBashコマンドを、許可プロンプトもcanUseToolコールバックも通さずに実行してしまう不具合が修正されましたSONNET5 — Claude Sonnet 5は導入価格として入力100万トークンあたり2ドル、出力10ドルで提供中です。8月31日を過ぎると3ドルと15ドルに戻りますIPO — Anthropicが早ければ10月の株式公開を視野に、引受銀行が投資家との面談を組み始めたと報じられています
記事一覧/API & SDK
API & SDK/2026-04-21上級

エージェントに「承認ゲート」を差し込む — Claude API で Human-in-the-loop を本番運用する設計

自律エージェントの一部の判断だけを人間に委ねたい、という要件は本番になって必ず出てきます。承認ゲートを後付けで差し込み、中断・再開を正しく扱うための設計パターンを、動くコード付きで解説します。

human-in-the-loop2agent10approvaltool-use21production87

プレミアム記事

エージェントに権限を渡すと、たいていの場合は驚くほど上手く動きます。問題は、その「たいてい」をすり抜けた数パーセントで、取り返しのつかないことが起きることです。

私が最初に本番でエージェントを動かしたとき、一番怖かったのは「バグ」ではなく、「正しく動きすぎること」でした。送金 API も、メール送信も、データベースの DELETE も、ツール一覧に並べてしまえば Claude は必要だと判断したときに迷わず呼び出します。テストでは思い通りに動いていたフローが、実ユーザーのエッジケースで意図しない順序で実行され、気付いたときには顧客のメールボックスに誤った請求書が届いている、ということが起こり得ます。

ここではエージェントの一部の判断だけを人間に委ねる「Human-in-the-loop(HITL)」を、Claude API の標準的な tool_use / tool_result の往復に差し込むための本番設計を、動くコードとともに解説します。完全自律をあきらめるのではなく、「どこで止めて、誰に、どう見せるか」を最初に決めてから組むのが肝心です。

エージェントが「勝手に実行してしまう」前に考えるべきこと

HITL の設計を始める前に、まず「何を止めたいのか」を言語化してください。これは純粋に技術の話ではなく、事業リスクの話です。実際に私がレビューしてきたプロジェクトでは、ここを曖昧にしたまま「全ツール呼び出しに承認を付ける」ような実装をして、承認疲れで誰も中身を読まなくなる事故が起きがちです。

承認ゲートの設計軸は次の3つに集約できます。

  • 不可逆性: 送金、契約の締結、顧客への自動送信など「取り消せない」操作か
  • ブラスト半径: 影響が一人の内部ユーザーに閉じるのか、外部顧客に波及するのか
  • 金額・コンプライアンス閾値: 一定金額以上、あるいは個人情報を含む場合のみゲートを入れるのか

この3軸で「Red(必ず承認)/ Yellow(条件付きで承認)/ Green(自動実行)」を分類し、ドキュメントとして残してからコードに落とし込みます。Red は絶対に止める、Yellow は閾値ロジック、Green は通常実行、という役割分担にすると、レビューする人間側も「いま自分は何を判定しているのか」が明確になります。

よくある誤解 — 「全部確認してもらえば安全」ではない

承認ゲートを付ければ付けるほど安全になる、というのは直感的には正しく見えますが、本番では逆に事故を増やします。人間は単調な承認依頼を何度も受けると、内容を読まずに承認するようになります。これは「rubber stamping」と呼ばれる古典的な問題で、航空業界や医療で繰り返し観察されてきました。

私の経験則では、1日あたり5件を超える承認依頼が常態化したチームでは、承認者の熟読率が急激に下がります。ゲートを減らす勇気と、Yellow の閾値設計が本番運用の質を決めます。最初の設計時に「このゲートを毎日何件発動させる想定なのか」を見積もり、想定を超えたら閾値を緩めるか、自動化のロジックを追加する判断が必要になります。

承認ゲートを入れる5つの場所

エージェントのライフサイクルのどこに承認ゲートを入れるかで、実装の複雑さと安全性のバランスが決まります。私は次の5つの場所を候補に挙げ、プロジェクトごとに最適な組み合わせを選んでいます。

1. ツール呼び出しの直前(最も一般的)

Claude が tool_use ブロックを返した直後、実際にツールを実行する前にゲートを入れます。入力パラメータを人間が見て、問題なければ実行、問題があれば拒否・修正のメッセージを返します。実装が最もシンプルで、個別のツールごとに「Red/Yellow/Green」を細かく制御できます。

2. ツール実行結果の返却前

ツールを実行し結果を取得したあと、その結果を Claude に返す前にチェックするパターンです。たとえば DB 検索の結果に個人情報が含まれていないかをフィルタしてから Claude に渡します。Claude がその情報を使ってさらなる判断をする前に遮断できるため、プライバシーや情報漏洩のリスクが高い用途に向いています。

3. 特定のパラメータ値に応じた動的ゲート

送金ツールで「1万円未満は自動、それ以上は承認必須」のように、ツール自体は承認不要でも特定の引数のときだけゲートを発動させます。最も運用負荷とのバランスが取れる設計です。私が新規案件で最初に提案するのは、ほぼ必ずこのパターンです。

4. セッション開始時の計画レビュー

Claude に一度「計画だけ」を立てさせ、その計画を人間がレビューしてから実行を開始します。長時間エージェントや重要な業務プロセスで有効ですが、Claude がセッションの途中で新しいツールを呼ぼうとしたときの扱いを別途設計する必要があります。

5. 異常検知時のフォールバックゲート

普段は完全自律で動き、エラーレートや予期せぬツール呼び出しパターンを検知したときだけ人間に介入させる、受動的なゲートです。監視メトリクスとの統合が前提になるため実装コストは高めですが、自動化率を落としたくないプロジェクトでは採用する価値があります。

プロジェクトの最初は「3(動的ゲート)」から始めるのが最も失敗が少ないというのが私の経験則です。1 と 2 は実装が単純ですが承認疲れを誘発しやすく、4 と 5 は設計が複雑です。あとから 1 や 5 を追加していく方が、運用データがある分だけ閾値設計の精度が上がります。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
自律エージェントで「勝手に実行されると困る操作」を見つけられず困っていた人が、承認ゲートを入れる5つの場所と判断軸を持てるようになる
tool_use と tool_result の往復を中断・再開する実装パターンを習得し、Slack 承認・メール承認と Claude API をつなぐ具体的なコードを手に入れられる
権限エスカレーション・二重実行・期限切れなど本番特有の事故を防ぐ監査ログとタイムアウト設計を理解でき、コンプライアンス要件に耐える構成に仕上げられる
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

API & SDK2026-07-09
出力は同じ、道筋は違う — エージェントの軌跡を不変条件で守る
既定モデルが入れ替わっても最終出力は正しいまま、ツール呼び出しの道筋だけが静かに変わることがあります。実行トレースを記録し、不変条件で機械的にアサートする軌跡回帰ハーネスを実装コードと実測値で整理しました。
API & SDK2026-06-29
Claude API の Context Editing を入れたらエージェントが同じ調査を繰り返したとき — クリア境界とキャッシュ無効化を計測する運用メモ
Context Editing でツール結果を自動クリアしたら、エージェントが直前に読んだ内容を忘れて同じツールを呼び直し、キャッシュも毎回壊れてコストが上がった。沈黙する劣化を計測ログで切り分け、trigger・keep・clear_at_least を実測で決める運用メモです。
API & SDK2026-06-22
pause_turn の継続ループに上限を入れる — 無人で長時間サーバーツールを安全に回す
web_search や code execution など長時間サーバーツールを使うと返ってくる pause_turn を、無人運用で安全に継続する設計をまとめました。4種類の stop_reason を1ループで分岐し、継続回数と時間に上限を入れ、セグメントを跨ぐ usage を数える実装まで扱います。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →