CLAUDE LABEN
SUNSET — 旧 Workbench と実験的プロンプトツール API の廃止は明日8月17日です。残り1日となりましたLATEST — 最新は8月15日の v2.1.233 です。GitLab のマージリクエスト URL が --worktree と claude agents で扱えるようになり、MR は !N 形式で表示されますSECURITY — Windows で NT の \??\ デバイスプレフィックスを含むパスが UNC 検証をすり抜ける問題が直りました。NTLM 資格情報が漏れる経路が塞がれていますTODO — Opus 4.8・Sonnet 5・Fable 5・Mythos 5 以降では TodoWrite と Task 系ツールが既定で無効になりました。CLAUDE_CODE_ENABLE_TODO_TOOLS=1 で戻せますFORK — 8月14日の v2.1.232 で subagent_type: 'fork' が既定になり、会話全体とプロンプトキャッシュをそのまま引き継げるようになっていますMENTION — プロンプトで @ を打つと別のセッションを名前で呼び出せます。SendMessage がそのセッションへ直接届きますSUNSET — 旧 Workbench と実験的プロンプトツール API の廃止は明日8月17日です。残り1日となりましたLATEST — 最新は8月15日の v2.1.233 です。GitLab のマージリクエスト URL が --worktree と claude agents で扱えるようになり、MR は !N 形式で表示されますSECURITY — Windows で NT の \??\ デバイスプレフィックスを含むパスが UNC 検証をすり抜ける問題が直りました。NTLM 資格情報が漏れる経路が塞がれていますTODO — Opus 4.8・Sonnet 5・Fable 5・Mythos 5 以降では TodoWrite と Task 系ツールが既定で無効になりました。CLAUDE_CODE_ENABLE_TODO_TOOLS=1 で戻せますFORK — 8月14日の v2.1.232 で subagent_type: 'fork' が既定になり、会話全体とプロンプトキャッシュをそのまま引き継げるようになっていますMENTION — プロンプトで @ を打つと別のセッションを名前で呼び出せます。SendMessage がそのセッションへ直接届きます
記事一覧/API & SDK
API & SDK/2026-06-02上級

自律エージェントの破壊的操作に事前条件・事後条件の契約ゲートを付ける

スキーマも型も通るのに中身が壊れている——自律エージェントのもっともらしい失敗を、事前条件・事後条件の契約ゲートで止める設計です。tryGuard・commitGuard・rollbackの構造、TypeScriptでの実装、スナップショットによる安全な巻き戻し、既存エージェントへの後付け手順まで紹介します。

Claude Agent SDK13自律エージェント4アーキテクチャ7信頼性5設計5

プレミアム記事

自律エージェントを本番で走らせていて、いちばん肝を冷やすのは、エージェントが「もっともらしく」失敗するときです。クラッシュしてくれたほうがまだ救いがあります。ところが Claude のような言語モデルは、間違った内容を、自信たっぷりに、整った形式で出力します。スキーマは通る。型は合う。ログを見るかぎり成功している。それなのに、書き込まれた中身が壊れている。これがいちばん厄介な失敗の形です。

私は2014年から複数のアプリとサイトを個人で運用していて、ここ数年は記事の更新やデプロイの一部を自律エージェントに任せています。最初に組んだ素朴な仕組みでは、エージェントに git へ push させると、週に1〜2回は壊れた状態が本番に出ていました。リンク先が存在しない、日英の記事数が食い違う、設定ファイルの整合性が崩れている。どれも「プロンプトをもっと丁寧に書けば防げる」と思いがちな失敗です。でも、いくらプロンプトを磨いても、すり抜けはゼロになりませんでした。

結論から言うと、効いたのはプロンプトの改善ではなく、エージェントの書き込み操作を決定論的なゲートで物理的に挟むことでした。この設計を「契約ゲート(Contract Gate)」として一般化し、Claude Agent SDK のツール呼び出しに後付けできる形で、実装まで順に見ていきます。

なぜ「AIに気をつけてもらう」設計は破綻するのか

多くのエージェント実装は、安全性をプロンプトに委ねています。「壊れたデータを書かないでください」「push する前に整合性を確認してください」といった指示です。これは一見うまくいくのですが、本質的に確率的な防御です。モデルは毎回少しずつ違う判断をします。99%守れても、1日に何十回も走らせれば、残りの1%は確実に表に出てきます。

ここで思い出してほしいのが、ソフトウェア工学で古くから知られている「契約による設計(Design by Contract)」です。関数に事前条件(呼び出してよい状態)と事後条件(呼び出し後に保証される状態)を定め、満たされなければ実行そのものを止める考え方です。自律エージェントのツール呼び出しは、まさにこの契約が必要な場所です。エージェントが何を考えていようと、書き込みの前後で機械が不変条件を検査し、破れていたら適用させない。判断の主体をモデルから決定論的なコードに移すわけです。

公式ドキュメントの多くは canUseTool のような許可フックを「人間の承認を挟む」用途で説明します。けれど実運用でいちばん効くのは、人間を挟むことではなく、人間もモデルも介在しない決定論的な検査を挟むことでした。人間の承認は夜間バッチでは機能しませんし、モデルの自己検査は前述のとおり確率的です。

契約ゲートの構造:tryGuard・適用・commitGuard・rollback

契約ゲートは、ひとつの破壊的操作を次の4段で包みます。

  1. tryGuard(事前条件) — 操作してよい状態かを検査する。破れていたら操作を実行せず拒否する。
  2. snapshot(巻き戻し点) — 操作前の状態を記録する。
  3. apply(適用) — 実際の書き込みを行う。
  4. commitGuard(事後条件) — 書き込み後の状態が不変条件を満たすか検査する。破れていたら snapshot まで rollback する。

ポイントは、事後条件で「適用してみてから検査し、ダメなら巻き戻す」という流れを持つことです。事前条件だけでは「適用した結果どうなるか」までは検査できません。たとえば「日本語記事と英語記事の本数が一致していること」という不変条件は、ファイルを書いた後でなければ確かめられません。だからこそ、適用と検査と巻き戻しを一体で扱う必要があります。

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

この記事の続きを読む

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

この記事で得られること
ツール呼び出しを tryGuard・適用・commitGuard・rollback の4段で挟む契約ゲートの完全な TypeScript 実装
事前条件と事後条件に「何を書いてよくて何を書いてはいけないか」の判断基準(決定論的に検査できる不変条件だけを置く)
スナップショットと冪等な巻き戻しでロールバックを安全にする具体パターンと、実運用で弾けた失敗の内訳
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

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

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

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

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

関連記事

API & SDK2026-07-08
無人エージェントの挙動変更を、フィーチャーフラグで少しずつ試す設計
無人で走るエージェントのプロンプトや挙動を一度に全変更すると、劣化が朝まで見えません。フィーチャーフラグで一部の実行にだけ新挙動を割り当て、品質を見てから広げる設計と、決定論的バケット・自動ロールバック・監査証跡の実装を紹介します。
API & SDK2026-06-28
ツール呼び出しは成功しているのに前進しない — 無人エージェントの停滞を検知して止める設計
エラーは出ていないのに同じ手を繰り返し、予算だけが溶けていく。無人エージェントの『成功し続ける停滞』を、行動フィンガープリントと進捗オラクルで検知して安全に止める設計をPythonの実装つきでまとめました。
API & SDK2026-06-25
前の実行が終わらないうちに次が走り出すとき — リースとフェンシングトークンで定期エージェントの多重起動を抑える
毎朝の定期実行が前回の処理を追い越して二重に走り出す問題を、リースとフェンシングトークンで抑える設計を解説します。素朴なロックが破れる瞬間の分析から、任意ストア上の最小リース実装、副作用直前のトークン検証、上限付きキャッチアップまで、運用で固めた既定値とともに実装コード付きで整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →