AIエージェントがAPIを直接呼び出す時代に、「べき等性（idempotency）」の欠如がどれほど致命的かを考えたことがあるだろうか。人間がUIを操作するシステムではボタンの二度押し防止などフロントエンドが安全弁になっていた。しかしエージェントはUIを完全に無視し、ネットワークタイムアウトが発生するたびに同じAPIを自動再試行する。その結果、決済が二重に処理される「ゴーストアクション」が発生しうる。
この問題を整理するには、まず「LLMエージェント」がどのようにバックエンドと接続するかを把握しておく必要がある。近年注目されているMCP（Model Context Protocol）は、LLMがシステムの機能を「ツール」として発見・呼び出せるようにするプロトコルだ。たとえばClaudeのようなLLMがMCP経由で在庫確認APIを呼び出し、その結果をもとに発注処理を連鎖的に実行するといった使い方ができる。このとき呼び出し元はもはや人間ではなく、ループ制御を持つ自律的なプログラムである。
べき等性はセキュリティ境界として設計する
べき等性とは、同じリクエストを何度送っても結果が1回だけの実行と変わらない性質を指す。GETリクエストは本来べき等だが、決済や在庫確保といった「状態を変化させるエンドポイント」は意識的に設計しなければならない。
シード記事が示す構造では、APIゲートウェイ層で `X-Idempotency-Key` ヘッダを必須化し、同一キーの重複リクエストはバックエンドに到達させず、キャッシュした成功レスポンスを返す。エージェントが失敗ループから同じリクエストを投げても、実際の状態変更は1回しか起きない。Stripe APIがこのパターンを長年採用しているのは、まさに同様の理由からだ。SRE観点では、このキーのストレージ（RedisやDynamoDBなど）の可用性とTTL設計自体がSLOの対象になる。
# Redisでべき等キーを管理する最小構成例
# キーが存在しない場合のみ SET し、TTLを600秒に設定
redis-cli SET idempotency:<key> "<response_payload>" NX EX 600キャッシュが失われた場合の挙動を事前に定義しておくことも欠かせない。「キーが見つからなければ再実行する」のか「エラーを返す」のかをSLO設計のフェーズで決める。
ドメイン境界の分離とオブザーバビリティ
シード記事が「ドメイン主権（Domain Sovereignty）」と呼ぶ設計思想は、DDD（ドメイン駆動設計）のバウンデッドコンテキストと重なる。コアの業務ロジックを、呼び出し元がエージェントかモバイルアプリかに関わらず一切変えない、という原則だ。
これはオブザーバビリティ設計にも直接影響する。呼び出し元の種別（人間／エージェント／MCP）をトレースのスパン属性として記録しておくと、エージェントが引き起こしたエラーを人間起因のエラーと区別して集計できる。OpenTelemetryのスパンに `caller.type=agent` などのラベルを付与し、Grafanaのダッシュボードで分離して可視化するのが現実的なアプローチだ。エラーバジェット（SLOの許容誤り率）の消費をエージェントが急速に加速させていないか、という視点の監視が今後必要になる。
APIバリデーション層の肥大化もSREが意識すべき変化だ。人間向けUIがフロントエンドで弾いていた不正ペイロードを、エージェントは直接バックエンドに投げてくる。OpenAPIスキーマの厳格な運用と、スキーマ違反率をメトリクスとして収集する仕組みが、障害の早期検知につながる。
IaC（Infrastructure as Code）の観点では、べき等キーのストレージ、APIゲートウェイのレート制限設定、スキーマバリデーションの設定をTerraformやPulumiで宣言的に管理することで、エージェント対応のインフラ変更をレビュー可能な状態に保てる。
持ち帰れるポイントの整理
今回のテーマで実装・運用に関わるポイントを整理する。
- べき等キーの管理ストア（Redis等）をSLOの対象リソースとして明示し、TTLと障害時挙動を設計段階で決める
- 分散トレーシングのスパンに呼び出し元種別（人間／エージェント）を付与し、エラーバジェット消費を分離して監視する
- OpenAPIスキーマのバリデーション違反率をメトリクスとして収集し、アラートを設定する
- べき等キーストアやAPIゲートウェイのレート制限設定をIaCで宣言管理し、変更を差分レビュー可能にする
LLMエージェントの普及が進むにつれ、「エージェントが壊してもシステムが安全に止まれるか」という耐障害性の問いがより現実的になる。べき等性・ドメイン分離・トレーサビリティは目新しい技術ではないが、エージェントを消費者として迎える構造では、これらの設計精度が直接サービスの信頼性指標に現れてくる。