AIエージェントが本番障害を起こす5つの設計盲点と対策

LLM（大規模言語モデル）を組み込んだ業務自動化ワークフローを設計しているエンジニアに向けた内容です。

デモ環境で3回テストして問題なく動いたAIエージェントが、本番環境に接続した途端に不安定になる事例があります。顧客が同じフォームを二重送信する、APIがタイムアウトする、AIが壊れたJSONを返す、webhook（外部サービスからの通知を受け取る仕組み）が再送されるといった状況です。これらはAIモデルの性能の問題ではなく、周辺システムの設計の問題として捉える必要があります。

AIエージェントのデモが成功することと、本番運用に耐えることの間には明確な技術的ギャップがあります。このギャップを埋めるための5つの設計判断を、非機能要件（性能・可用性・セキュリティなど機能以外の品質要求）の観点から整理します。

なぜデモは動くのに本番で壊れるのか

デモ環境と本番環境の最大の違いは、入力の多様性と障害の発生頻度です。

デモでは想定済みの入力しか与えません。本番では、ユーザーの予測不能な行動やネットワークの不安定さが常態化します。

たとえば「屋根が雨漏りしています。点検をお願いできますか」という自然文を、AIに分類させてCRM（顧客関係管理システム）にタスクを作る設計を考えます。デモでは正常系しか試さないため、AIの出力をそのまま信頼する設計でも問題は起きません。本番では、AIの誤分類や外部APIの遅延が重なり、意図しない動作を引き起こします。

設計判断1：AIに制御の全権を渡さない

よくあるアーキテクチャ上のミスは、AIモデルに「何をするか」と「どう実行するか」の両方を委ねてしまうことです。

安全な構成では、AIは解釈だけを担当し、実行の可否は決定的なコード（入力が同じなら必ず同じ結果を返す処理）が判断します。処理の流れは次のようになります。

顧客問い合わせ
  ↓
入力バリデーション
  ↓
AIによる分類
  ↓
スキーマ検証
  ↓
決定的なルーティング
  ↓
CRM / 通知
  ↓
ログ記録・モニタリング

AIモデルにCRMへの直接アクセス権を与えず、構造化された「推奨結果」だけを返させます。アプリケーション側がその推奨を検証してから、実際のアクションを実行する構成です。この分離により、モデルの予期しない出力が業務システムに直接影響する範囲を狭められます。

設計判断2：AIの出力は信頼できない外部入力として扱う

AIが返すJSONは、一見すると扱いやすいデータに見えます。しかし、モデルが想定外のカテゴリ値や、存在しないはずの操作（たとえば全レコード削除のような指示）を返す可能性はゼロではありません。

これはAPI連携の文脈でも馴染み深い原則です。外部から受け取るデータは、信頼せずに検証してから使うという考え方です。

PythonのPydantic（データ構造を定義して検証するライブラリ）を使うと、許可された値だけを受け付けるスキーマを定義できます。

from typing import Literal
from pydantic import BaseModel, ConfigDict, ValidationError

class InquiryClassification(BaseModel):
    model_config = ConfigDict(extra="forbid")
    category: Literal["roof_repair", "roof_estimate", "general_inquiry"]
    priority: Literal["normal", "high", "manual_review"]
    recommended_action: Literal["create_estimate_task", "notify_service_team", "manual_review"]

def validate_ai_output(raw_output: str):
    try:
        return InquiryClassification.model_validate_json(raw_output)
    except ValidationError:
        return None

検証に失敗した場合は、自動実行せずに人手でのレビューキューへ回します。許可されていない値や形式のレスポンスは「無効」として扱い、業務アクションのトリガーにしない設計が基本線です。AIは操作を提案できますが、その操作を許可するかどうかはアプリケーションが決めるという役割分担がポイントです。

設計判断3：webhookの再送が引き起こす二重実行

ここからはAI特有ではなく、分散システム全般に共通する可用性の課題です。

webhookを受信した側がCRMレコードを作成したものの、送信元への応答（ACK）が時間内に届かないケースがあります。送信元はタイムアウトと判断して再送し、結果として同じレコードが2回作られてしまいます。通知メールが二重送信されれば、顧客体験にも直接影響します。

この問題の対策が冪等性（べきとうせい、同じ操作を何度実行しても結果が変わらない性質）の担保です。具体的には、リクエストごとに一意なIDを発行し、すでに処理済みのIDであれば同じ処理を再実行せずに前回の結果を返す仕組みを組み込みます。決済APIの世界ではIdempotency-Keyヘッダーとして広く使われている概念で、AIエージェントのワークフローでも同じ発想がそのまま使えます。

既存のAPI設計・分散システムの知見との接続

ここまでの3つの設計判断は、実はAI特有の新しい概念ではありません。

「信頼境界の設計」「入力検証」「冪等性」は、マイクロサービス間連携やWebhook基盤の設計で既に確立されている非機能要件です。AIエージェントを導入するからといって、これらの原則を作り直す必要はなく、既存の設計パターンをAIの出力という新しい「信頼できない入力源」に適用するだけで対応できます。

違いがあるとすれば、LLMの出力は同じ入力に対しても毎回微妙に異なる結果を返す点です。従来のAPIは仕様通りに動けば決定的な出力を返しますが、LLMは確率的な性質を持ちます。そのため、スキーマ検証のような「出力の形式を保証する層」を、通常のAPI連携よりも厳格に設ける必要が出てきます。

AIモデルは「提案」を返す存在として扱い、実行の決定権は検証済みの決定的なコードに残す設計が、本番運用の安定性を左右します。

今日確認できること

自分のプロジェクトが該当するかどうかは、以下の観点でチェックできます。

AIの出力結果が、検証なしに外部システムへの書き込みやAPI呼び出しに直結していないか
AIのレスポンスに対して、許可された値のみを受け付けるスキーマ検証（Pydanticなど）を導入しているか
webhookや外部通知の受信処理に、一意なリクエストIDに基づく重複排除のロジックがあるか
検証に失敗したAI出力が、エラーログに残るだけでなく、人手のレビューフローに回る設計になっているか
プロンプトインジェクション（ユーザー入力に紛れ込んだ指示でAIの挙動を乗っ取る攻撃）を想定し、顧客からの自由入力をそのままAIへの指示として扱っていないか

該当する項目があれば、まずはAIの出力を受け取る箇所に検証層を1つ挟むところから着手できます。全体のアーキテクチャを作り直さなくても、入力バリデーション・スキーマ検証・冪等性キーの3点は個別に追加できる改善です。

まとめ

AIエージェントの本番障害は、モデルの精度不足よりも周辺アーキテクチャの設計不足から生まれることが多い構造です。

整理すると、確認すべきポイントは次の3点に集約されます。

AIには解釈と提案までを任せ、実行判断は決定的なコードに残す
AIの出力は外部からの信頼できないデータとして扱い、スキーマで検証する
webhookなどの再送に備えて、冪等性キーで重複実行を防ぐ

これらはAI導入のために新しく発明する必要のある技術ではなく、既存のAPI設計・分散システム設計の知見をAIという新しい変数に適用する作業です。まずは自分のワークフローの中で、AIの出力が直接アクションに繋がっている箇所を1つ洗い出してみるところから始められます。