7月22日、LangChainが「3 Years of Graph Engineering with LangGraph」と題した記事を公開した。グラフ構造でAIエージェントを設計する「グラフエンジニアリング」の本質と、LangGraphの3年間の開発で得た実践的な知見が詳しくまとめられている。

「グラフエンジニアリング」という言葉の登場

プロンプトエンジニアリング、コンテキストエンジニアリング、ループエンジニアリング——X（旧Twitter）のAIコミュニティは次々と新しい用語を生み出す。今週末話題になったのが「グラフエンジニアリング」だ。

バズワードの是非はともかく、LangChainはこのアプローチを3年前からすでに実践してきた。LangGraphは現在、月間6,500万ダウンロードを超え、スタートアップから大企業まで幅広く採用されている。

グラフがエージェント設計に向いている理由

LangGraphにおけるグラフの構成要素は2つだ。

• ノード（Node）：実際の処理を担う。決定論的なコード、単一のLLM呼び出し、ツール呼び出し、さらには内部ループを持つフル機能のエージェントも配置できる。
• エッジ（Edge）：次の処理への遷移を定義する。固定の遷移と、ノードの出力や状態に基づく条件分岐の両方が使える。

このモデルの本質はステートマシンだ。LLMに全ての判断を委ねるのではなく、「ここはモデルが考える場所」「ここはコードで確実に処理する場所」を明示的に分離できる。

実際のユースケースとして記事が示すのが、3種のサブエージェント（GitHubエージェント、Notionエージェント、Slackエージェント）を束ねるナレッジベースエージェントだ。ワークフローは「分類 → 検索 → 統合」の3段階に固定されている。

モデルは価値を発揮できる箇所だけで推論し、残りはコードが処理する。結果としてコストが下がり、速度が上がり、挙動が予測しやすくなる。

3年間の開発で得た知見

エージェントのグラフはDAGにならない

DAG（有向非巡回グラフ）——要するにループのない一方向グラフ——は多くのワークフローエンジンの前提だが、本番エージェントにはループが不可欠だ。失敗したツール呼び出しのリトライ、追加情報の要求、検証後の回答修正、ヒューマンインザループでの一時停止と再開……これらはすべてサイクルを必要とする。

ループエンジニアリングはグラフの代替ではなく、グラフの単純な形の一つに過ぎない。注目すべきは、LangChainフレームワークが提供するシンプルなエージェントループ自体も、内部実装はLangGraphの上に構築されているという点だ。つまりLangGraphはLangChainエコシステムの外側にある別レイヤーではなく、LangChain自身の基盤として採用されている。バズワードとして消費されるには足りない、実績と信頼の裏付けがそこにある。

動的なエッジ遷移が重要になる

すべてのエッジを事前定義できるとは限らない。マップリデュースがその典型例だ。入力を複数の断片に分割し、それぞれワーカーに渡して結果を統合する処理では、ワーカー数が入力に依存するため事前に決められない。

LangGraphはこれをSend APIで解決している。ノードが実行時に1つ以上の下流ノードへ動的にルーティングできる仕組みだ。「リサーチはファンアウトして統合する」という構造は決まっていても、ソースが何件になるかは実行時までわからない——そういった構造の既知性とランタイムの可変性が混在するケースに対応する。

グラフを使うべきでない場面もある

決定論的なパスへの無理な押し込みが逆効果になるケースもある。記事が例に挙げるのはディープリサーチだ。計画・委任・検索・読解・統合が流動的に絡み合うタスクは、事前にパスを定義しにくい。

LangChain自身も初期のディープリサーチをLangGraphのワークフローで構築していたが、後によりエージェントハーネス寄りのコアループに移行した。GPT Researcherも同様に、グラフ型のマルチエージェントパイプラインからDeep Agentsへ切り替えている。

今、何が変わったか

グラフ構造でエージェントを設計すること自体は新しくない。変わったのはノードの中身だ。

初期のノードは決定論的なコードか単一のLLM呼び出しだった。現在はエージェント自体が十分に信頼できるレベルに達したため、ノードの中にフル機能のエージェントを埋め込むパターンが現実的になった。コーディングエージェントはその好例だ。

記事が示すドキュメント管理エージェントの例では、Slackのリクエストからレビュー可能なプルリクエストを生成するワークフローを以下の構成で実現している。

• 固定ステップ：SlackやLinearの操作はAPIコールで処理
• モデルステップ：分類と統合はツールなしの単一LLM呼び出し
• エージェントステップ：リファレンスドキュメントと概念ドキュメントの更新は、それぞれのコードベースに対してオープンエンドに動作するエージェントが担当

この決定論とエージェント性の混在こそが、予測可能性・性能・効率のバランスを生む設計の核心だ。

詳細は3 Years of Graph Engineering with LangGraphを参照していただきたい。