Skip to content
Volver a la lista de artículos
ai12分

AIエージェントを本番投入して学んだ7つのこと

7 Lessons Learned from Deploying AI Agents to Production

中村 悠太 / Yuta NakamuraLead AI Engineer
2026-03-2512分
AI AgentProductionGuardrailsMonitoringCost Control

Este artículo está publicado en japonés. Resumen en español a continuación:

7 Lessons Learned from Deploying AI Agents to ProductionAIエージェントを本番環境に投入して痛感した7つの教訓。障害モード、ガードレール設計、モニタリング、コスト暴走対策をリアルな失敗事例とともに解説する。

AIエージェントの本番投入は甘くない

KGAでは過去1年で6つのAIエージェントシステムを本番環境に投入した。そのうち3つは初期リリースから2週間以内に重大な問題が発生し、緊急対応を余儀なくされた。この記事では、その経験から抽出した7つの教訓を共有する。

教訓1: エージェントは必ず予想外の行動をする

最初の教訓は「エージェントは必ず予想外の行動をする」だ。テスト環境では完璧に動いていたカスタマーサポートエージェントが、本番投入3日目に競合他社の製品を推薦した。原因はRAGで取得したドキュメントに競合比較記事が含まれており、エージェントがその内容を「推薦」と解釈したためだ。

対策として、全エージェントの出力にGuardrails層を追加した。具体的には、Claude 4 Haikuをジャッジモデルとして、エージェントの出力が「ブランドガイドライン」「禁止トピックリスト」「トーン規定」に違反していないかを0.3秒以下で判定する。違反検出率は98%で、月間約200件の不適切な応答をブロックしている。

教訓2: コストは必ず暴走する

  • つ目の教訓はコスト暴走だ。リサーチエージェントが無限ループに陥り、1晩でOpenAI APIに$2,300を請求された。原因は、エージェントが自分の出力を「不十分」と判定し、リトライを無限に繰り返したため。

対策として3段階のコスト制御を実装した。Level 1: 1リクエストあたりのtokenバジェット(最大50,000トークン)。Level 2: 1タスクあたりのtool call回数制限(最大20回)。Level 3: 日次/月次のAPI費用アラート(閾値超過で自動停止)。

これらの制御により、月間APIコストの予測精度が±5%以内に収まるようになった。KGAの全AIエージェントの月間APIコストは合計$4,500前後で安定している。

教訓3: 人間のフォールバックは必須

  • つ目。AIエージェントがhandleできないケースに対して、人間へのエスカレーションパスが必須だ。KGAのクライアントのカスタマーサポートエージェントでは、以下の条件で人間オペレーターにエスカレーションする。confidence scoreが0.7未満。3回以上のリトライで解決しない。ユーザーが「人間と話したい」と明示的に要求。クレーム・法的リスクのあるトピックを検出。

エスカレーション率は全リクエストの12%で、この数字を8%以下に下げることが次の目標だ。重要なのは、エスカレーション時にエージェントの処理履歴(コンテキスト)を人間オペレーターに引き継ぐこと。ユーザーに同じ説明を繰り返させないためだ。

教訓4: Observabilityは初日から

  • つ目。モニタリングを後回しにすると地獄を見る。KGAの初期のエージェントは、LLMのAPI呼び出しログだけを記録していた。問題が発生した際、「なぜその判断をしたのか」のトレースが取れず、原因究明に数日かかった。

現在のObservabilityスタック。LangSmith: エージェントの全tool call、prompt、responseのトレース。Grafana: レイテンシ、エラー率、コストのリアルタイムダッシュボード。PagerDuty: 異常検知時の自動アラート。BigQuery: 全エージェント出力の長期保存と分析。

特にLangSmithのトレース機能は不可欠だ。問題のあるリクエストのtool call chainを視覚的にたどれるため、「ステップ3のtool呼び出しで誤ったパラメータを渡した」というレベルの原因特定が分単位で可能になった。

教訓5: プロンプトのバージョン管理

  • つ目。プロンプトの変更はコード変更と同等以上にリスクがある。KGAではプロンプトをYAMLファイルとしてGitで管理し、変更時にはCI/CDパイプラインでevalテスト(最低50ケース)を自動実行する。テストがpassした場合のみmainにマージ可能。

さらにA/Bテスト機能を実装し、プロンプト変更をトラフィックの10%に段階的にロールアウトする。品質メトリクスに劣化が見られたら自動ロールバック。この仕組みにより、プロンプト変更による品質事故をゼロに抑えている。

教訓6: ユーザーの入力は想像以上に多様

  • つ目。テスト時に想定した入力パターンは、本番トラフィックの30%しかカバーしていなかった。絵文字のみの入力、1万文字を超える長文、複数言語の混在、明らかなプロンプトインジェクション攻撃。

入力のバリデーションとサニタイズは徹底的に行う。KGAでは入力処理パイプラインとして、文字数制限(10,000文字)→言語検出→プロンプトインジェクション検出(専用分類器)→トピック分類→エージェントルーティングの順序で処理している。プロンプトインジェクションの検出には、Rebuffライブラリとカスタム分類器を併用し、検出率96%を達成。

教訓7: ユーザーの信頼は一度で崩れる

最後の教訓。AIエージェントへのユーザー信頼は構築に数ヶ月かかるが、崩壊は一瞬だ。KGAのクライアントで、エージェントが1回だけ明らかに誤った回答をした結果、そのユーザーは二度とエージェントを使わなくなった。

対策は、エージェントの能力範囲を明示的にユーザーに伝え、不確実な回答には「この回答は確認が必要です」という注釈を自動付与すること。過度な期待を持たせないことが、長期的な信頼構築には重要だ。KGAではエージェントの初回利用時にチュートリアルを表示し、「できること」「できないこと」「間違える可能性があること」を明示している。

技術的な課題を一緒に解決しませんか?

KGA IT Solutionsは、AI・クラウド・DevOpsの専門チームがお客様の課題に最適なソリューションを提供します。

お問い合わせ