本番環境のエージェント:4つのリアルなケーススタディ
本番環境のエージェント:4つのリアルなケーススタディ
エージェントのデモは印象的だ。しかし実際の本番デプロイは混沌としている。「自分のラップトップでは動く」と「本番で稼働する」の間には、エッジケース、予想外のコスト、そしてどんなチュートリアルも教えてくれなかった障害モードが山積みになっている。
華やかなデモは誰でも見たことがある。エージェントがフライトを予約し、レポートを書き、バグを起票する——すべて2分間の画面収録で。しかし映らないのは、初週40%のエスカレーション率、1クエリあたり12ドルのAPI料金、そしてデータ破損を「修正」しようとして悪化させたエージェントだ。
この4つのケーススタディはその溝を埋める。実際のアーキテクチャ、実際の数字、本番デプロイからの実際の失敗が含まれている。各ケーススタディは独立して読めるよう設計されている——4つすべて読んでもよいし、自分のユースケースに合うものだけ読み飛ばしてもよい。
学べること:
- 各システムがどのように設計され、なぜそうなったか
- 何がうまくいき、何が派手に失敗したか
- 精度、コスト、レイテンシ、ヒューマンオーバーライド率などの具体的な指標
- あらゆるドメインに応用できる学び
ケーススタディ1:カスタマーサポートトリアージエージェント
問題
中規模のSaaS(Software as a Service)企業では、毎日500件以上のサポートチケットが届く。ティア1対応——パスワードリセット、請求に関する質問、既知のバグの回避策——がサポートチームの時間の約60%を消費している。難しい問題を解くべきエンジニアが、同じ10個の質問に対してコピーペーストで回答しているのだ。
ビジネス目標は明確だった。顧客満足度を落とさずに、ティア1対応を自動化すること。
アーキテクチャ
┌─────────────────────────────────────────────────┐│ Incoming Ticket │└──────────────────────┬──────────────────────────┘ │ ▼ ┌────────────────┐ │ Router Agent │ │ (Intent Class.)│ └──┬───┬───┬──┬─┘ │ │ │ │ ┌────────┘ │ │ └────────┐ ▼ ▼ ▼ ▼ ┌─────────┐ ┌────────┐ ┌──────┐ ┌──────────┐ │ Billing │ │Technical│ │Account│ │ Feature │ │ Handler │ │ Handler │ │Handler│ │ Request │ └────┬────┘ └───┬────┘ └──┬───┘ └────┬─────┘ │ │ │ │ └──────────┴────┬────┴───────────┘ ▼ ┌──────────────────┐ │ Confidence Check │ │ ≥ 0.85 → Reply │ │ < 0.85 → Human │ └──────────────────┘ツールと統合:
- チケットシステムAPI(Zendesk)によるチケットの読み取りと返信
- ナレッジベース検索(ヘルプ記事のベクターストア)
- 顧客データ参照(アカウントステータス、サブスクリプションティア、最近のインタラクション)
主な設定:
router_agent: model: gpt-4o-mini system_prompt: | You are a support ticket classifier. Classify into exactly one category: billing, technical, account, feature_request. Return JSON: {"category": "...", "confidence": 0.0-1.0, "summary": "..."} temperature: 0.0
handler_agents: escalation_threshold: 0.85 max_knowledge_base_results: 5 response_tone: "professional, empathetic, concise"結果
| 指標 | 導入前 | 導入後 | 変化 |
|---|---|---|---|
| 人間の介入なしで処理されたティア1チケット | 0% | 70% | +70% |
| 平均応答時間 | 4時間 | 3分 | -98.75% |
| 顧客満足度(CSAT) | 4.2/5 | 4.1/5 | 有意な変化なし |
| エスカレーション率 | N/A | 15%(チューニング後) | — |
| チケット1件あたりのコスト(サポート人件費) | $8.50 | $2.40 | -72% |
失敗したこと
初週の過剰エスカレーション。 初期のエスカレーション率は40%だった。ルーターエージェントが過度に慎重で、曖昧な表現を含むチケットはすべて人間に回された。修正策:信頼度の閾値を0.95から0.85に下げ、ルータープロンプトに境界線上のチケットのfew-shotサンプルを追加した。
請求のエッジケース。 部分払い戻し、紛争中の請求、マルチアカウント請求には、繊細な人間の判断が必要だった。エージェントは、ポリシーが部分払い戻しのみを許可している場面で全額払い戻しを提示することがあった。修正策:金銭を伴う請求アクションにはハードコードされたルールを設定した。エージェントはポリシーを説明できるが、20ドルを超える金融アクションは人間の承認なしには実行できない。
ナレッジベースの鮮度問題。 エージェントが、2ヶ月前に変更されたUIフローを説明するヘルプ記事を引用した。顧客がその手順に従って混乱し、怒りながらエスカレーションしてきた。修正策:自動鮮度チェックを導入した。90日以内に更新されていない記事にはフラグが立ち、古いコンテンツを引用する際はエージェントが免責事項を追加する。
学んだこと
- 最も簡単なカテゴリから始める。 FAQスタイルのアカウント質問が最も自動化率が高かった。請求は最後だった。
- 解決率だけでなく顧客満足度を測定する。 不満を持つ顧客のチケットを解決しても成功ではない。
- ナレッジベースの鮮度はエージェントの品質と同じくらい重要だ。 世界最高のエージェントも、古いドキュメントは補えない。
ケーススタディ2:リサーチ&レポート生成エージェント
問題
あるコンサルティングチームは、複数のデータソース(ニュースAPI、金融データベース、社内文書)から市場調査レポートを毎週8〜12時間かけてまとめている。レポートの構成は一定だが、データ収集は退屈でミスが起きやすい。アナリストはほとんどの時間を収集に費やし、分析に割けていない。
アーキテクチャ
┌────────────────────────────────────┐│ Research Brief (User) │└──────────────────┬─────────────────┘ ▼ ┌──────────────────┐ │ Orchestrator Agent│ │ (Task Decomposer)│ └──┬──────┬──────┬─┘ │ │ │ ┌──────┘ │ └──────┐ ▼ ▼ ▼┌──────────┐ ┌──────────┐ ┌───────────┐│ News │ │ Financial│ │ Internal ││ Worker │ │ Worker │ │ Doc Worker│└────┬─────┘ └────┬─────┘ └─────┬─────┘ │ │ │ └──────┬──────┴─────────────┘ ▼ ┌───────────────┐ │Synthesis Agent│ │(Report Writer)│ └───────┬───────┘ ▼ ┌───────────────┐ │ Review Agent │ │(Verification) │ └───────┬───────┘ ▼ ┌───────────────┐ │ Final Report │ │ (w/ Citations)│ └───────────────┘ツールと統合:
- ニュースAPI(NewsAPI、Google News)による最新情報や業界カバレッジ
- 金融データAPI(Alpha Vantage、社内データウェアハウス)による市場データ
- 社内文書検索(過去レポートやクライアントブリーフのベクターストア)
- 構造化出力生成(Markdown → PDFパイプライン)
主な設定:
orchestrator: model: gpt-4o decomposition_strategy: "parallel_by_source" max_sub_tasks: 8
synthesis_agent: citation_requirement: "Every factual claim MUST include [Source: ...] inline" output_format: "structured_markdown" sections: - executive_summary - market_overview - competitive_landscape - financial_highlights - risks_and_opportunities - appendix_sources
review_agent: checks: - contradiction_detection - citation_verification - data_recency (max_age_days: 30) - completeness (all_sections_present: true)結果
| 指標 | 導入前 | 導入後 | 変化 |
|---|---|---|---|
| レポート生成時間 | 8時間 | 45分+30分レビュー | -84% |
| 引用精度 | 約75%(推定) | 92%( |
関連記事
- エージェントのエラー回復:本番環境の信頼性のための5つのパターン
- マルチエージェントパターン:オーケストレーター、ワーカー、パイプライン
- 自律型エージェントシステムのデバッグと可観測性
- AIエージェントのキャッシュ戦略:品質を落とさずコストを削減する
- ツール使用パターン:信頼性の高いエージェント-ツールインターフェースの構築