Mobile Study: Part 1/4: 本番環境でのAIエージェント構築：設計からスケールまで

2026年3月14日土曜日

Part 1/4: 本番環境でのAIエージェント構築：設計からスケールまで

はじめに

2026年現在、AIエージェントをプロトタイプとして動かすことは容易になった。しかし、本番環境で安定的に運用し、スケールさせることはまったく別の話だ。レスポンスのレイテンシ、UI設計の限界、インフラの複雑さ――これらの課題を乗り越えなければ、エージェントはデモ止まりになる。

このシリーズでは全4回にわたり、AIエージェントを本番レベルに引き上げるための設計原則と実装手順を解説する。Part 1では、設計の基礎と、現場で頻発する落とし穴を取り上げる。

AIエージェントが本番で失敗する理由

1. レイテンシの非決定性

開発中は気づきにくいが、LLMへのAPIコールは時間帯やサーバー負荷によって応答速度が大きく変動する。実際に、Claude AIを使ってコードレビューを行っているエンジニアが、夜9時以降にレスポンスが著しく遅くなる現象を観測・報告している [Source: https://dev.to/jeffrin-dev/claude-ai-gets-weirdly-slow-after-9-pm-i-noticed-it-while-reviewing-code-4gia]。

これは単なる個人の体験談ではなく、本番設計における重要なインプットだ。エージェントがユーザーの操作をブロックする同期処理に依存している場合、こうした変動が即座にUXの劣化につながる。

対策として、エージェントの処理を非同期キューに乗せ、UIはストリーミングレスポンスで部分的に更新する設計が有効だ。

// 非同期ストリーミングの基本パターン async function streamAgentResponse(   prompt: string,   onChunk: (chunk: string) => void ): Promise<void> {   const response = await fetch('/api/agent', {     method: 'POST',     body: JSON.stringify({ prompt }),     headers: { 'Content-Type': 'application/json' },   });    const reader = response.body?.getReader();   const decoder = new TextDecoder();    if (!reader) return;    while (true) {     const { done, value } = await reader.read();     if (done) break;     onChunk(decoder.decode(value));   } }

2. LLMにUIコード生成を任せてはいけない

エージェントのUI構築において、LLMにReactコンポーネントをその場で生成させるアプローチを取るチームは多い。しかしこれは根本的な設計ミスだ。ネストされたコンポーネント構造をLLMが生成すると、ハルシネーション（事実と異なるコードの生成）が頻発し、レンダリングエラーが本番環境を汚染する。

この問題を「Hallucination Tax（ハルシネーション税）」と呼び、15kbのフラットなJSONストリーミングエンジンで解決したチームの事例がある [Source: https://dev.to/wisethewizard/why-asking-llms-to-generate-reactnested-code-is-a-dead-end-for-agent-ui-2821]。要点は、LLMにはデータ構造の決定だけを委ねて、レンダリングロジックは静的なコンポーネントライブラリに分離するという設計だ。

// LLMが返すフラットなJSON構造の例 {   "components": [     { "type": "heading", "level": 2, "text": "分析結果" },     { "type": "table", "data_ref": "result_set_1" },     { "type": "button", "label": "詳細を見る", "action": "expand_details" }   ],   "data": {     "result_set_1": { "columns": ["指標", "値"], "rows": [["精度", "94.2%"]] }   } }

この構造であれば、LLMが出力したJSONをそのままバリデーションにかけ、既存のコンポーネントにマッピングするだけで安全にレンダリングできる。

本番設計の3つの原則

原則1: エージェントをステートレスに保つ

エージェント自体がセッション状態を持つと、スケールアウト時にスティッキーセッションが必要になり、水平スケールの妨げになる。会話履歴やコンテキストは外部ストア（RedisやDynamoDB）に持たせ、エージェントは毎リクエストでそれを読み込む設計にする。

原則2: ツール呼び出しをべき等にする

エージェントがAPIや外部サービスを呼び出す際、ネットワーク障害によるリトライで二重実行が発生しうる。ツール実装には必ずべき等キー（idempotency key）を導入し、同一リクエストの重複実行を防ぐ。

原則3: 観測可能性をday 1から組み込む

エージェントの処理はブラックボックスになりやすい。外部委託やマイクロサービス化と同様、内部が見えない状態では障害調査が困難になる。各ツール呼び出しのレイテンシ、LLMへの入出力トークン数、エラー種別を構造化ログとして出力し、最初からトレーシングパイプラインに乗せる。

// 構造化ログの例 logger.info('agent_tool_call', {   tool_name: 'search_knowledge_base',   input_tokens: 512,   latency_ms: 340,   status: 'success',   trace_id: context.traceId, });

まとめとPart 2への接続

Part 1では、本番AIエージェントが直面する主要な落とし穴として「レイテンシの非決定性」と「UI生成のハルシネーション問題」を取り上げ、その対策となる設計原則を整理した。

Part 2では、これらの原則を踏まえた上で、エージェントのツール設計と外部APIとの安全な統合パターンを具体的なコードとともに解説する。エラーハンドリング戦略とサーキットブレーカーパターンの実装が中心になる。

Category: 開発 | Tags: AIエージェント, ソフトウェアアーキテクチャ, TypeScript

Mobile Study