AIエージェント本番運用 — 9社のアーキテクチャ・技術スタック総まとめ¶
出典: Findy Tools 特集「AIエージェント開発 — 9社のアーキテクチャと本番運用」 リンク: https://findy-tools.io/articles/ai-agent/258 読了メモ作成日: 2026-05-30
AIエージェントを本番運用する9社のエンジニアが、開発〜運用で直面した課題と解決策を共有した特集。「PoC は簡単だが本番は困難」が共通認識で、各社とも LLMの万能性に頼らず、決定論的ワークフロー・観測基盤・人間の判断を組み合わせて いる点が特徴。
各社の事例（技術スタック・作り方つき）¶
1. GMOペパボ — ロリポップ！AIサイトエージェント（Web自動生成）¶
- 課題: ウェブサイトの「良し悪し」を一意に判定できない
- 技術スタック: Next.js / ジョブキュー BullMQ / DB は MySQL / 可視化に Metabase
- 作り方・アーキテクチャ:
- 「ヒアリング → 構成設計 → デザイン選定 → コンテンツ生成」を決定論的ワークフローで実装し、定型処理を固定
- デザイナーによるヒューリスティック評価ループで品質を担保（自動判定できない領域を人手で補う）
- 入出力ログを MySQL に蓄積し Metabase で可視化
2. グリーホールディングス — イルカちゃん🐬（Slack情シス問い合わせBot）¶
- 課題: 既存プロセスを壊さずに人間とAIの協働を実現する
- 技術スタック: インフラ Cloud Run / 検索 Vertex AI Search / DWH BigQuery / LLM Gemini / 評価は LLM as a Judge
- 作り方・アーキテクチャ:
- 疎結合なAPI設計：「頭脳API」と「Slack Bot（BFF）」を分割
- マルチエージェント構成で統括役と専門家を役割分担
- 段階的導入（検証用チャンネル → 夜間稼働 → 本番）でリスクを抑制
- LLM as a Judge による日次の定量評価基盤を構築
- ペルソナ（イルカ）付与で利用者の心理的ハードルを低減
3. KDDIアジャイル開発センター — AIこーぽたん（社内ヘルプデスク）¶
- 課題: モデル呼び出しコストの急増
- 技術スタック: フレームワークは Mastra → Amazon Bedrock AgentCore へ移行 / エージェント基盤 Strands Agents / LLM は Claude Sonnet 4.5（統括役）＋ Nova 2 Lite（Specialist）/ 評価に Strands Agents Evals SDK
- 作り方・アーキテクチャ:
- マルチエージェント構成：Orchestrator（Claude Sonnet 4.5）が統括し、2体の Specialist（Nova 2 Lite）が定型タスクを実行
- 軽量モデルへの役割委譲で約55%のコスト削減
- Strands Agents Evals SDK で自動評価基盤を構築
4. KINTOテクノロジーズ — マルチエージェント型社内チャット基盤¶
- 課題: ツールの過剰呼び出し
- 技術スタック: 言語 Go / エージェント基盤 eino / LLM は Claude・Azure OpenAI・Vertex AI Gemini に対応 / 観測 Langfuse（セルフホスト）/ ツール連携 MCP
- 作り方・アーキテクチャ:
- eino の DeepAgents パターン：メインエージェントが計画し、複数サブエージェントに委譲
- think tool（内省用ツール） を組み込み、ツール過剰呼び出しを抑制
5. LayerX — Ai Workforce（エンタープライズ向けAIプラットフォーム）¶
- 課題: 機密情報をマスキングしながら、メタデータベースの観測を実現する
- 技術スタック: 観測基盤 OpenTelemetry + Datadog LLM Observability
- 作り方・アーキテクチャ:
- 「決定論的ワークフロー」と「Agentic Workflow」を両立
- Webアプリ観測と AIワークフロー観測を統合し、トレースベースで実行構造を可視化
6. ログラス — 財務分析AIエージェント¶
- 課題: 決定論と非決定論をどう組み合わせるか
- 技術スタック: インフラ ECS Fargate + AWS Bedrock / フレームワーク LangGraph / ベクトルDB ChromaDB / 観測 Langfuse（セルフホスト）
- 作り方・アーキテクチャ:
- 決定論×非決定論の組み合わせ：主要ユースケースを LangGraph の決定論的ワークフローで定義し、LLMが解く処理ステップを限定
- 各ノード出力をバリデーション
- SQL発行時にコメント情報でメタデータを充実させ精度を向上
7. NCDC — BizAIgent（業務支援AIアシスタント）¶
- 課題: AWSロックインの回避、応答時間
- 技術スタック: フレームワーク Strands Agents / モデル抽象化 LiteLLM / ツール連携 MCP
- 作り方・アーキテクチャ:
- 2層構成：メインエージェント（最終回答）とサブエージェント（ツール実行）を分離
- LiteLLM でクエリ複雑度に応じてモデルを動的切り替え
- 応答時間の上限を設定し、部分回答で対応
8. Sansan — Sansan AI エージェント（営業・マーケティング支援）¶
- 課題: 説明性（Explainability）の維持（応答の「なぜか」を示せるかが品質に直結）
- 技術スタック: Google Cloud エコシステム / DWH BigQuery / LLM Gemini 中心 / 観測 OpenTelemetry ベース
- 作り方・アーキテクチャ:
- マネージドサービス活用で車輪の再発明を回避（セッション・メモリはマネージド）
- FDE（Forward Deployed Engineer） がデータ品質補正とカスタマイズを反復し、説明性を担保
9. TOKIUM — AI経費承認¶
- 課題: LLMに全処理を委ねるとコスト膨張、精度も不安定
- 技術スタック: 観測基盤 Datadog APM
- 作り方・アーキテクチャ:
- 戦略：「初期はLLMで素早く価値を出し、知見が溜まったらロジックに切り替える」
- 「LLMで判定すべき領域」と「プログラムで判定すべき領域」を明確に分離（文脈解釈=LLM、定型処理=コード）
- Datadog APM で入出力をトレースし、検証サイクルを高速化
横断的な共通パターン¶
| 課題 | 共通する解決策 |
|---|---|
| 品質評価の難しさ（自動テスト不可） | ヒューリスティック評価、LLM as a Judge、Evals SDK で定量評価基盤を構築 |
| 観測性の欠如 | OpenTelemetry / Langfuse / Datadog による多層的トレース |
| コスト最適化 | マルチエージェント化、軽量モデル併用（Nova Lite 等）、「LLM vs コード」の役割分担 |
| 説明性の確保 | トレース、メタデータ充実、Human-in-the-Loop / FDE の組み込み |
技術選定の傾向（横断）¶
- エージェント基盤: Strands Agents（KDDI・NCDC）、eino（KINTO）、LangGraph（ログラス）、Mastra→Bedrock AgentCore（KDDI）
- 観測: Langfuse セルフホスト（KINTO・ログラス）、Datadog LLM Observability / APM（LayerX・TOKIUM）、OpenTelemetry（LayerX・Sansan）
- モデル抽象化／マルチクラウド: LiteLLM（NCDC）、複数LLM対応（KINTO）
- クラウド二大潮流: AWS Bedrock 系（KDDI・ログラス）と Google Cloud / Vertex AI・Gemini 系（グリー・Sansan）
自分のプロジェクトへの示唆¶
~/temporal-workflows/~/research-orchestrator：決定論ワークフロー（Temporal）× LLM の役割分担は本特集の中核パターンと一致。LLMが解くステップを限定し、定型処理はコード/ワークフロー側に寄せる設計が裏付けられる- 観測：Langfuse セルフホスト or OpenTelemetry ベースのトレースを早期に入れておくと評価ループが回せる
- コスト：Orchestrator に高性能モデル、Specialist に軽量モデル（Haiku / Nova Lite 等）という階層化が約55%削減の実績あり
作成: 2026-05-30 ／ 最終更新: 2026-06-16