LiteLLM × LangGraph シリーズ全20回を振り返ってみる：読み方の推奨パスと実プロダクトレシピ集

はじめに

データ事業本部のkobayashiです。

LiteLLM × LangGraph シリーズ20記事を書きました。基礎の completion() 呼び出しから、エージェント協調・記憶管理・評価駆動開発・Guardrails、最後は A2A プロトコルでのエージェント間連携までを段階的に積み上げ、プロバイダー非依存な LLM アプリケーション開発の全体像 を1本の縦軸にまとめたシリーズです。本記事ではシリーズ全体を俯瞰し、各回の位置づけ・通底するテーマ・本番運用での重ねがけパターンに加えて、読み方の推奨パス・採用したモデル戦略・典型的なユースケースレシピ・シリーズで扱わなかったトピック を振り返ります。

各記事は 独立して動くサンプルコード が付いていて、uv pip install ... から python ... まで5分以内に手元で再現できる粒度を意識しました。本記事を読んで気になった機能から、対応する記事へ飛んで実機で試していただけると嬉しいです。

シリーズ全体の構成

LiteLLM によるプロバイダー非依存性と、LangGraph によるグラフベースの制御フローを軸に、LLM アプリケーション開発の全体像を 基礎 → エージェント → 記憶 → 入出力 → 評価・運用 → 応用 の6カテゴリに分けて段階的に積み上げました。

基礎編

1. LiteLLM 基本
   統一インターフェースで OpenAI / Anthropic / Gemini を切替。completion / embedding / image_generation / transcription を1つの API で扱う。
2. クラウド経由（Bedrock / Vertex AI / Azure）
   AWS Bedrock / GCP Vertex AI / Azure AI Foundry の認証パターン3種（環境変数 / 直接指定 / クラウドネイティブ認証）と呼び出し方法。
3. LangGraph 入門
   create_agent で ReAct エージェントを構築、StateGraph で任意のフローを定義。LiteLLM とのつなぎ込み。
4. RAG パターン
   シンプル RAG → HyDE → RAG-Fusion → Rerank → Corrective / Self / Adaptive / Agentic RAG まで段階的に実装。

エージェント編

5. マルチエージェント基礎（Supervisor / Hierarchical / Swarm）
   3パターンの協調設計を比較。エージェントごとに最適なモデルを割り当てるコスト最適化の利点。
6. Deep Research（Send API による並列研究）
   Send で複数サブクエリを並列起動 + Reflection ノードで不足を検出して動的に追加調査。
   • 番外編: Web 検索 API 比較（Linkup / Tavily / Parallel / Exa / Firecrawl）
     Deep Research の擬似検索を実物の Web 検索 API に差し替える。5サービスを @tool で共通インターフェース化して横並び比較。
7. Plan-and-Execute / Reflexion
   Planner / Executor / Replanner を分離。Reflection ループで自己批判しつつ MAX_ITERATIONS で暴走を抑止。

記憶編

8. Checkpoint・短期メモリ
   InMemorySaver / SqliteSaver / PostgresSaver で thread_id ごとに会話を分離、要約戦略でコンテキスト圧縮。
9. LangMem 長期メモリ
   セマンティック・エピソディック・プロシージャルの3種類の長期記憶を Store + Embedding で実装。

入出力編

10. Human-in-the-Loop
    interrupt() + Command(resume=...) で人間判断を挟む。基本停止 / ツール承認 / ステート編集の3パターン。
11. 構造化出力
    Pydantic スキーマで型安全な出力。OpenAI Strict mode で Optional を弾かれる落とし穴と回避策。
12. ストリーミング深掘り
    LiteLLM 素 / LangGraph stream / FastAPI + SSE の3階層。streaming=True を渡し忘れる落とし穴も解説。
13. MCP × LangGraph
    langchain-mcp-adapters でローカル stdio + リモート HTTP の MCP サーバーを束ねて1つのエージェントから利用。

評価・運用編

14. LangSmith
    環境変数だけで自動トレース、evaluate() でデータセット評価。LLM-as-judge を並列で走らせて表現ゆらぎを吸収。
15. DeepEval × LangGraph
    AnswerRelevancy / Faithfulness / Hallucination で応答品質を採点、assert_test で pytest CI に統合。
16. Guardrails・安全性
    入力フィルタ（インジェクション検知）/ PII マスク（Presidio）/ 出力 LLM-as-judge の3層構成。
17. フォールバック・コスト最適化
    fallbacks / Router / completion_cost / Prompt Caching で本番運用の可用性とコストを両立。
18. デプロイ
    FastAPI / Streamlit / Docker / LangGraph Platform の4パターン。本番では Postgres Checkpointer + シークレットマネージャー。

応用編

19. マルチモーダル
    Vision モデルへ画像入力。外部 URL 拒否を避けるため Base64 + data URL がデファクト。
20. A2A プロトコル
    公式 a2a-sdk の AgentExecutor で LangChain を包み、JSON-RPC message/send でエージェント間連携。

通底したテーマ

シリーズを通して一貫したのは「コードロジックを変えずにモデル・プロバイダーを差し替えられる」という LiteLLM の哲学です。ChatLiteLLM(model="...") の文字列を変えるだけで OpenAI ↔ Anthropic ↔ Gemini を行き来でき、LangGraph 側で組んだエージェント・グラフ・ノードはそのまま動きます。

最終回の A2A プロトコルでも、オーケストレータに openai/gpt-5-mini、翻訳エージェントに anthropic/claude-sonnet-4-6 を混在させましたが、A2A レイヤーが HTTP プロトコルであるため、エージェントロジックにはプロバイダー固有のコードが一切現れませんでした。プロバイダー差を吸収するレイヤーを介して、モデルとアプリケーションロジックを疎結合に保つ という設計思想は、LangSmith でモデル横断比較する場面でも、Guardrails で Worker / Judge を別プロバイダーに分ける場面でも、繰り返し効いてきました。

採用したモデル戦略

シリーズではモデルを役割（ロール）ごとに使い分けています。同じグラフの中でも、ノードごとに最適なモデルを割り当てるのが LiteLLM 構成の旨味です。

ロール	採用モデル	採用理由
エージェント本体（tool_use 中心）	openai/gpt-5-mini	安価・低レイテンシ・tool_use の安定性。create_agent のデフォルト用途に最適
文章生成・翻訳・要約・judge 役	anthropic/claude-sonnet-4-6	日本語の自然さ・指示追従の正確さ・長文の構成力で優位。LLM-as-judge の判定品質も高い
マルチモーダル（画像・音声）	openai/gpt-5.5 / gemini/gemini-2.5-flash	Vision / Audio 対応。Gemini はコストとマルチモーダル両立が魅力
Embedding	openai/text-embedding-3-small	RAG / LangMem の Store 用。安価で十分な検索品質
ガードレール judge	anthropic/claude-sonnet-4-6	Worker と別プロバイダーにすることで 同一バイアスを共有しないクロスチェック効果 が得られる
計画系（Plan-and-Execute の Planner）	openai/gpt-5.4 クラス	高品質な計画立案、出力構造の安定性

「Worker は安価モデル、Judge / 計画 / 統合は高品質モデル」という非対称構成が、品質を維持しながらコストを抑える定石です。completion_cost（記事⑰）で実測した結果、Claude Sonnet 4.6 は GPT-5-mini の 約3倍のコスト だったため、すべてのノードを Claude にする必要はなく、要所だけに使うのが合理的です。

本番運用は「重ねがけ」で完成する

各記事は独立した機能の紹介ですが、本番運用では 複数の機能を重ねて使う のが王道です。

• Router で複数モデルへの ロードバランシング
• fallbacks でプロバイダー障害時の 自動切替
• completion_cost で コスト追跡
• LangSmith で トレース可視化と評価駆動のモデル選定
• DeepEval で 応答品質メトリクス（回答関連性 / 忠実性 / ハルシネーション）
• Guardrails（入力フィルタ・PII マスク・出力 LLM-as-judge）で 安全性
• Checkpointer + HITL で 永続化と人間承認
• MCP でツールエコシステムを 横断接続
• Prompt Caching で長いコンテキストの コスト最大90%削減

これらをグラフのノード・コールバック・ミドルウェアとして組み込むことで、コスト効率・可用性・品質・安全性を同時に満たす LLM アプリケーションが組み上がります。

典型的なユースケースレシピ

シリーズで扱った機能を実プロダクトに落とし込むときの代表的な組み合わせを、3つのケースで示します。各レシピの番号は冒頭の構成表の記事番号に対応します。

A. 社内ナレッジ Q&A エージェント

社内ドキュメント・規程・FAQ を引いて、Slack や Teams からの質問に答えるアシスタント。

• 検索基盤: ④ RAG パターン（Adaptive RAG で質問タイプごとに検索戦略を切替）+ 番外編 Web 検索 API
• メモリ: ⑧ Checkpointer（PostgresSaver でユーザー横断のセッション継続）+ ⑨ LangMem（社員プロファイル・過去の質問傾向を長期記憶）
• 観測・評価: ⑭ LangSmith でトレース可視化、⑮ DeepEval で Faithfulness（情報源の事実性）を CI で検査
• 安全性: ⑯ Guardrails で PII マスク（社員名・取引先名・電話番号）と出力ガード
• デプロイ: ⑱ FastAPI + Docker、⑰ Router で複数モデルを束ねる
• モデル戦略: 通常応答は gpt-5-mini、ハルシネーション疑いがある回答は claude-sonnet-4-6 に再投げて検証

B. コードレビュー / 開発支援エージェント

PR の差分を読み、レビューコメント生成・テスト実行・修正提案までを担う開発者向けエージェント。

• コア: ③ LangGraph + ⑥ Deep Research（差分の影響範囲を並列調査）+ ⑦ Plan-and-Execute（修正を計画→実行→再評価）
• ツール接続: ⑬ MCP（GitHub / 内部 Issue / Linter / コード検索を MCP サーバー化して横断接続）
• 承認フロー: ⑩ HITL（マージ前に人間レビューで Command(resume=...) ）
• 構造化: ⑪ 構造化出力（レビュー指摘を severity / file / line の Pydantic スキーマで返す）
• 観測: ⑭ LangSmith で「どのレビュアーモデルが検出率高いか」を experiment で並列比較
• モデル戦略: 計画は gpt-5.4、コード解析・修正提案は claude-sonnet-4-6、ファイル列挙など雑多な処理は gpt-5-mini

C. マルチテナント SaaS の翻訳・要約 API

外部顧客向けに翻訳・要約 API を提供するサービス。複数テナントが同居し、利用量・トーンを切り替える。

• エージェント分離: ⑳ A2A プロトコル（翻訳 / 要約 / 校正をそれぞれ独立 A2A サーバーにし、オーケストレータから委譲）
• 入出力: ⑫ ストリーミング（Web UI への SSE 配信）+ ⑲ マルチモーダル（画像内テキストの抽出 → 翻訳）
• 認証・テナント: ⑳ A2A の CallContextBuilder で API キー → テナント ID 解決、ユーザー単位のコスト集計と監査ログ
• 本番運用: ⑰ Router で fast/smart エイリアス + fallbacks、Prompt Caching でテナント別のシステムプロンプトを使い回し
• 品質: ⑮ DeepEval で 多言語の品質メトリクス を CI 走行
• モデル戦略: 翻訳の Worker は claude-sonnet-4-6、ルーティング・スキル選択は gpt-5-mini、コスト計測は completion_cost でテナント別に集計

レシピは固定的なものではなく、各社のリスク許容度・予算・運用体制に応じて要素を組み替えて使う土台と考えてください。

シリーズで扱わなかったトピック

今後の発展先として以下のテーマが残っています。

• LangGraph Functional API: グラフを宣言的に書く @entrypoint / @task 形式の API。本シリーズは StateGraph ベースで統一したため触れていません。
• Agent Observability の OSS スタック: Phoenix（Arize）/ OpenTelemetry での自前ホスティング型の観測。本シリーズは LangSmith に絞りました。
• RAG 評価フレームワーク（RAGAS）: Faithfulness / Context Recall / Answer Relevancy を RAG パイプライン専用で評価。⑮ DeepEval と相補的。
• LangGraph Studio: グラフの ビジュアルデバッガ。本シリーズはコード中心だったため、UI 検証ツールには触れていません。
• マルチエージェント間のメッセージング詳細: ⑳ A2A は外部公開向けでしたが、社内のエージェント・バス（pub/sub やイベントソーシング）は別軸です。
• エージェントのオンライン学習・自己改善: 本シリーズは静的な構成が中心でした。LangMem の prompt_optimizer（記事⑨）でプロシージャル記憶を更新する例が最も近いです。

これらも今後ブログ記事として扱っていく予定です。

まとめ

LiteLLM × LangGraph シリーズ全20回を、構成 / 読み方の推奨パス / 通底するテーマ / モデル戦略 / 重ねがけ運用 / ユースケースレシピ / 残った課題 の7軸で振り返りました。

シリーズ全体を貫いた発見は、「プロバイダー差を吸収するレイヤー（LiteLLM）と、グラフベースの制御フロー（LangGraph）を別々に持つ」 という分業の力強さでした。Worker と Judge を別プロバイダーに分ける、計画と実行で別モデルを使う、エージェント間連携を A2A の HTTP レイヤーで切り出す——どれも同じ「疎結合に保つことで選択肢を残す」という哲学の応用です。本番運用では Router / fallbacks / completion_cost / LangSmith / DeepEval / Guardrails / Checkpointer / MCP / Prompt Caching を 重ねがけ して、コスト・可用性・品質・安全性を同時に満たすパイプラインに育てていくことになります。

各記事のサンプルコードは独立して動かせるので、レシピや推奨パスを参考に、関心のある記事から手元で試していただけると嬉しいです。LLM・LangGraph・関連 SDK は今後も急速に進化しますが、「プロバイダーに縛られない設計」という基本線は当面不動だと考えています。本シリーズが、長く使えるアーキテクチャの選択肢を増やす一助 になれば幸いです。

最後まで読んでいただきありがとうございました。