AI・機械学習

AIエージェント本番運用6ヶ月で火を噴いた話｜マルチエージェント設計の失敗と今の構成

「エージェントが無限ループする」「コストが読めない」——本番投入から6ヶ月、痛い目を見続けて気づいたLangGraph・AutoGen・CrewAIの選び方と設計の落とし穴をまとめました。

AIエージェントLangGraphマルチエージェントLLM機械学習

先日、うちのチームでAIエージェントを本番投入してから約6ヶ月が経った。正直に言うと、最初の2ヶ月はほぼ毎週何かしら火を噴いていた。「エージェントが無限ループする」「コストが予測できない」「ツール呼び出しの順序がおかしい」……挙げればキリがない。でも今は、徐々にではあるけれど、安定して動くようになってきた。

6ヶ月で痛い目を見ながら学んだこと——特にマルチエージェント設計の落とし穴と、2026年時点で自分が「これが正解に近いかな」と思っている構成を、ここにまとめておく。以前 AIエージェント開発で痛い目を見た話 でも初期の失敗を書いたので、あわせて読んでもらえると経緯がわかりやすいと思う。

2026年のAIエージェントフレームワーク、結局どれを使うべきか

まず現在の選択肢を整理しておく。2026年に入ってフレームワーク戦国時代がある程度収束してきた印象がある。

フレームワーク最新バージョン特徴向いているユースケース
LangGraph0.3.xステートマシンベース、グラフ構造のエージェント制御複雑なワークフロー、ヒューマンインザループ
AutoGen0.4.xマルチエージェント会話フレームワーク、Actor Modelベースエージェント間会話、役割分担型タスク
CrewAI0.9.x役割ベースのチーム型エージェント、設定が簡単中規模タスク、チームメンバー型設計
Semantic Kernel1.x (GA)Microsoftが主導、.NET/Python両対応エンタープライズ、Azure連携
OpenAI Agents SDK2026.4.xOpenAI公式、シンプルなAPI設計OpenAIエコシステム完結、小〜中規模

うちのチームではLangGraphをメインに採用している。理由は単純で、「エージェントの実行状態をグラフとして可視化・制御できる」という設計思想が、本番運用のデバッグにめちゃくちゃ助かるからだ。最初はCrewAIのシンプルさに惹かれたんだけど、本番で複雑なロールバックが必要になったとき、状態管理の粒度が足りなくて詰んだ経験がある。

2026年4月にリリースされたOpenAI Agents SDK（旧Swarm）も検証中で、個人的にはHandoff機能のシンプルさが気に入っている。ただ、OpenAIモデル以外を使いたい場合の制約が正直しんどいので、本番メインには据えていない。ここは好み分かれるかも。

マルチエージェント設計パターンと実際の構成

うちのチームで運用しているのは、社内ドキュメント検索・要約・Slack通知を組み合わせた業務効率化エージェントだ。シンプルに聞こえるけど、実際は4つのエージェントが協調して動く結構複雑な構成になっている。

flowchart TB
    User([ユーザー入力]) --> Orchestrator
    
    subgraph AgentGraph["LangGraph マルチエージェント"]
        Orchestrator[Orchestrator Agent\n意図解釈・ルーティング]
        Retriever[Retrieval Agent\nRAG検索・ドキュメント取得]
        Summarizer[Summarizer Agent\n要約・回答生成]
        Notifier[Notifier Agent\nSlack/Teams通知]
        
        Orchestrator -->|検索タスク| Retriever
        Retriever -->|検索結果| Summarizer
        Summarizer -->|要約完了| Orchestrator
        Orchestrator -->|通知タスク| Notifier
        Orchestrator -->|HITL確認| HumanCheckpoint
    end
    
    HumanCheckpoint([ヒューマンチェックポイント\n高リスク操作時]) --> Orchestrator
    
    subgraph Tools["ツール群"]
        VectorDB[(Vector DB\nPinecone)]
        SlackAPI[Slack API]
        InternalAPI[社内API]
    end
    
    Retriever --> VectorDB
    Notifier --> SlackAPI
    Orchestrator --> InternalAPI

この構成にたどり着くまでに、2つの大きな失敗があった。

失敗1: フラットなマルチエージェントにした

最初は全エージェントが対等に会話するフラット構成にしていた。AutoGenのGroupChatっぽいやつ。「みんなで議論して最適解を出す」みたいな夢のある設計だったんだけど、実際には会話が収束せず、エージェントが互いの発言を打ち消し合って無限ループになるケースが頻発した。コスト爆発もこのころに体験した。

今はOrchestratorを中心に置いた階層型にしている。意思決定は必ずOrchestratorを経由して、他のエージェントはそれぞれの専門タスクに集中する設計。これだけでループ問題は9割解消した。地味だけど、この一手が一番効いた改善だったと思う。

失敗2: ヒューマンインザループを後付けにした

最初は「エージェントに全部やらせたい」という気持ちが強くて、ヒューマンインザループ（HITL）を軽視していた。でも社内APIを操作するタスクでエージェントが誤った操作をしたとき、ロールバックに丸1日かかった。それ以来、高リスクな操作の前には必ずHITLチェックポイントを挟んでいる。

LangGraphのCheckpointは本当によくできていて、中断・再開がスムーズ。こういう経緯があるので、SLO設計とエージェントの可観測性は早めに整備しておくことを強くすすめる。

コスト管理、これが一番頭を悩ませた

AIエージェント開発でみんな最初に詰まるのがコスト管理だと思う。マルチエージェントはLLM呼び出しが多段になるので、シンプルなチャットと比べてコストが5〜10倍になることがざらにある。

うちの環境での実測値を共有する。タスクの種類によって使用モデルを切り替える戦略にしている。

xychart-beta
    title "エージェントタスク種別ごとの月次APIコスト（万円）"
    x-axis ["Orchestration", "Retrieval", "Summarization", "Notification", "合計"]
    y-axis "コスト（万円）" 0 --> 50
    bar [12, 8, 18, 3, 41]

Summarizationが一番高いのは、長文ドキュメントを扱うことが多いから。これをGPT-4oからGemini 1.5 Proに切り替えたことで、同品質でコストを約35%削減できた。正直まだ最適化の余地はあると思っているけど、品質とのトレードオフで今はここで落ち着いている。

実装側では、LangSmithのトレーシングとコスト追跡を組み合わせて、タスクごとの詳細なコスト可視化をしている。

from langchain_core.callbacks import LangChainTracer
from langsmith import Client
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator

# ステート定義
class AgentState(TypedDict):
    messages: Annotated[list, operator.add]
    task_type: str
    cost_budget: float
    current_cost: float
    result: str

# コスト監視ノード
def cost_guard(state: AgentState) -> AgentState:
    """コスト上限チェック。超過したらエスカレーション"""
    if state["current_cost"] > state["cost_budget"]:
        raise ValueError(
            f"Cost budget exceeded: {state['current_cost']:.4f} > {state['cost_budget']:.4f}"
        )
    return state

# Orchestratorノード（モデル選択ロジック含む）
def orchestrator_node(state: AgentState) -> AgentState:
    """
    タスク種別に応じてモデルを動的選択。
    高精度が必要なSummarizationはGPT-4o、
    それ以外は軽量モデルで対応。
    """
    task = state["task_type"]
    
    model_map = {
        "summarization": "gemini-1.5-pro",     # コスト重視
        "orchestration": "gpt-4o-mini",         # 速度・コスト重視
        "retrieval_query": "gpt-4o-mini",       # 軽量タスク
        "notification": "gpt-4o-mini",          # 定型タスク
    }
    
    selected_model = model_map.get(task, "gpt-4o")
    
    # 実際のLLM呼び出しはここで行う（省略）
    return {
        **state,
        "messages": state["messages"] + [
            {"role": "system", "content": f"Selected model: {selected_model} for task: {task}"}
        ]
    }

# グラフ構築
def build_agent_graph() -> StateGraph:
    graph = StateGraph(AgentState)
    
    graph.add_node("cost_guard", cost_guard)
    graph.add_node("orchestrator", orchestrator_node)
    # 他のノードは省略
    
    graph.set_entry_point("cost_guard")
    graph.add_edge("cost_guard", "orchestrator")
    
    return graph.compile()

コスト予算をStateに持たせてguardノードで監視するパターンは、最初からやっておけばよかった設計の筆頭。本番で予算超過アラートが飛んでから気づくのは、精神的にも体力的にもしんどい。

信頼性・可観測性の整備が本番品質を決める

エージェントのデバッグはLLMの非決定性があるので、通常のサービスより格段に難しい。「なぜこのツールを呼んだのか」「なぜここで止まったのか」がトレースなしだと全く追えない。

観測体制として今やっていることは3つある。LangSmith でトレーシング・コスト・レイテンシをタスク単位で可視化、Prometheus + Grafana でエージェント実行のメトリクスを外部監視、そして構造化ログでエージェントの各ノード実行をJSON形式で記録——この3点セットがないと、正直デバッグがギャンブルになる。

xychart-beta
    title "エージェント応答品質スコア推移（月次平均）"
    x-axis ["2025-11", "2025-12", "2026-01", "2026-02", "2026-03", "2026-04"]
    y-axis "品質スコア（0-100）" 50 --> 100
    line [62, 68, 74, 80, 85, 88]

最初の2ヶ月は品質スコアが60台で、ユーザーからのフィードバックもかなり厳しかった。改善が加速したのは、LangSmithでのトレース分析を週次レビューに組み込んでから。「このタスクパターンで精度が落ちる」が数値で見えるようになって、改善の優先順位が立てやすくなった。週次レビューに入れるまでは「なんか動いてるっぽいけど不安」みたいな状態が続いていたので、これは早めにやっておくべきだったと反省している。

プロンプト設計についても触れておきたい。うちのチームでは各エージェントのシステムプロンプトをバージョン管理して、A/Bテスト的に改善を重ねている。プロンプト設計の話は プロンプト設計はセンスじゃない——チーム運用2年で見えた構造化の話 に詳しく書いたので参照してほしい。

あと、RAGとエージェントを組み合わせる場合は、検索品質がエージェント全体の品質を左右する。RAG本番2年で「なんか惜しい」を乗り越えた話 で書いたチャンキング設計はエージェント文脈でも完全に当てはまる内容なので、こちらも合わせてどうぞ。

2026年の設計トレンドと今後の展望

最近気になっているのが、メモリ管理の標準化とAgent-to-Agent (A2A) プロトコルの動向だ。

Googleが2026年初頭に公開したA2Aプロトコルは、異なるフレームワーク間でエージェントが協調するための標準仕様で、OpenAI・Anthropicも追従する動きがある。うちではまだ本番投入していないけど、今後マルチベンダーでエージェントを組み合わせるなら無視できない仕様になりそう。個人的には「ようやくここに来たか」という感じで、早く成熟してほしい。

メモリ管理については、MemGPT系のアプローチが成熟してきた感がある。長期記憶・短期記憶・エピソード記憶を明示的に分けて管理する設計は、長期間のタスク継続が必要なエージェントには効果的だった。うちのユースケースだと短期記憶だけで事足りているので、まだ本番適用はしていないけど。

flowchart LR
    subgraph MemoryLayer["メモリ管理レイヤー（検討中）"]
        WM[ワーキングメモリ\n今のコンテキスト]
        EM[エピソードメモリ\n過去タスク履歴]
        SM[セマンティックメモリ\nナレッジベース]
    end
    
    subgraph AgentCore["エージェントコア"]
        Agent[Orchestrator\nAgent]
    end
    
    subgraph Storage["ストレージ"]
        Redis[(Redis\nWM用)]
        VectorDB[(Vector DB\nEM/SM用)]
    end
    
    Agent <--> WM
    Agent <--> EM
    Agent <--> SM
    WM --> Redis
    EM --> VectorDB
    SM --> VectorDB

この辺はまだ検証中で、本番でどう設計するかを絶賛悩んでいる段階。エージェント間の記憶共有をどこまでやるかは、セキュリティ（誰のメモリを誰が参照できるか）と品質のトレードオフがあって一筋縄ではいかない。

皆さんのチームではエージェントのメモリ管理をどう設計してます？XとかZennで知見を共有してくれると嬉しい。

まとめ

6ヶ月のマルチエージェント本番運用から得た知見を整理するとこうなる。

  1. フラット型より階層型オーケストレーション：Orchestratorを中心に置く設計がループ・コスト爆発の防止に直結した
  2. HITLは最初から設計に組み込む：高リスク操作の前にヒューマンチェックポイントを置くのは後付けでは本当に辛い
  3. コスト監視はStateレベルで実装する：タスク種別ごとのモデル選択とガード処理で想定外のコスト超過を防げる
  4. LangSmithなどのトレーシングは非交渉：LLMの非決定性によるデバッグにはトレースが命綱
  5. A2AプロトコルとMemGPTは今から追っておく価値あり：2026年後半〜2027年に向けてスタンダードになる可能性が高い

次に何から手をつければいいか迷っている人には、LangGraph + LangSmithでローカル環境に最小構成のエージェントを立てて、コストとトレースの可視化から始めるのをすすめる。OpenAI Agents SDKの公式チュートリアルとLangGraphのHandoffパターンを比較してみると、設計思想の違いが肌感覚でわかってくるので、両方触ってみるのも面白い。本番を想定するなら、最初から予算ガードとHITLチェックポイントを仕込んでおくと後で絶対後悔しない。

AIエージェントは「動かすこと」自体はすぐできるけど、「本番で安定させること」の難易度が段違いに高い。でもその分、うまくいったときの業務インパクトは大きくて、うちのチームでは月50時間くらいの手動作業が自動化できた。まだ道半ばだけど、一緒に試行錯誤していきましょう。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

AI・機械学習

AIエージェント本番運用で学んだ痛い失敗｜プロンプト忘却とメモリ地獄の脱出記

AI・機械学習

LoRAファインチューニングを本番投入して6ヶ月——失敗だらけで学んだQLoRA・DoRA・学習率の現実

AI・機械学習

AIエージェント開発で痛い目を見た話｜2026年の実装課題と解決策

AI・機械学習

ベクトルDB本番1年で学んだ、Embedding戦略の地味で重い落とし穴

AI・機械学習

RAG本番2年で「なんか惜しい」を乗り越えた話——2026年の現実的な構成

AI・機械学習

RAG本番運用1年で痛感したこと｜チャンキングで半分決まるという現実

← 記事一覧に戻る