LangGraph で 3 年間のグラフ工学の知見

今週末、この ツイート をきっかけに「グラフエンジニアリング」という言葉が注目されました。

これは、プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング、ループエンジニアリングに続く、X（旧 Twitter）の AI コンテンツファクトリーから生まれた最新の用語です。これらを単なる流行語だと片付けたくなるのも無理はありませんが、これらの言葉が存在し、広まっているのには理由があります。それらは、開発者が直面する現実的な課題や設計上の判断を的確に表しているからです。

結局のところ、LLM（大規模言語モデル）の力を活用して実用的な成果を出すことが目標です。プロンプトを使うか、エージェントやループ、あるいはグラフを採用するかは、あくまで実装の詳細の問題に過ぎません。LLM を使って作業をさせるのがなぜこれほどまでに難しいのか、そしてなぜこれほど多くの用語が生まれるのかといえば、LLM は新しいタイプの「非堅牢で非決定論的なソフトウェア」だからです。私たちは常に、これを動かすための新たな戦略を試しており、その結果として新しい流行語が生まれていくのです。

流行語の喧騒を置いておいても、「グラフエンジニアリング」、つまりエージェントシステムをグラフとして表現することは、LLM の力を引き出す非常に合理的な方法です。具体的には、開発者であるあなたが「このシステムはこうあるべきだ」という先入観や設計思想を、より制約されたパスに反映させることができます。これは LLM の判断だけに頼るのではなく、人間が制御できる道筋を設けることを意味します。つまり、エージェントに特定の経路をたどらせたい場合など、振る舞いをより厳密にコントロールできるようになるのです。

この直感こそが、3 年前に LangGraph の構築へと繋がりました。これは、このようなエージェント型システムを構築するためのフレームワークとして設計されたものです。

現在、LangGraph は月間 6,500 万回以上ダウンロードされており、スタートアップから大企業まで幅広く利用されています。

数ある他のエージェントフレームワークと比較して、LangGraph が人気を集めた理由は、決定論的なパスとエージェント型のステップの間に適度なバランスを保っている点にあります。

グラフとしてエージェントを構築する中で、私たちは数年にわたり多くのことを学びました。

エージェントをグラフとしてモデル化する

グラフを用いることで、エージェントが従うワークフローを具体的に定義できるようになります。

LangGraph において ノード は実際に処理を行います。ノードは決定論的なコード、1 つの LLM（大規模言語モデル）呼び出し、ツール呼び出し、あるいは内部ループを持つ完全なエージェントそのものになり得ます。

エッジ は次に何が起こるかを定義します。エッジには決定論的なものと、ノードの結果や現在の状態、外部からのシグナルに基づいて分岐する条件付きのものがあります。

これは状態機械（ステートマシン）と考えることができます。グラフがワークフローを定義し、その中を移動する状態と、ステップ間の遷移を記述します。

エージェントをグラフで表現すべきタイミング

現実世界のエージェントワークフローには、予測可能な構造が存在します。サポートエージェントはまず課題を分類し、その後回答するかエスカレーションするかを決めます。コーディングエージェントも、変更案を提案する前にリポジトリを検査します。コンプライアンスワークフローでは、外部アクションを実行する前に承認が必要です。

グラフを使えば、こうした構造を直接記述できます。どのパスが有効か、モデルが選択できる箇所はどこか、そしてモデルに毎回正解を期待するのではなく、システム側で決定論的な振る舞いを強制すべき箇所はどこかを明確に定義できるのです。

システムをグラフとして表現することは、そのシステムがどのように動作すべきかという世界知識をコードに埋め込む行為です。プロンプトがドメイン知識を含み、汎用的な ChatGPT とは異なるエージェントを構築するのと同様に、これらの「認知アーキテクチャ」も同様の役割を果たします。

例えば、検索に 3 つのサブエージェントを活用するナレッジベースエージェントを考えてみましょう。コードやイシュー、プルリクエストには GitHub エージェント を、社内ドキュメントやウィキには Notion エージェント を、関連スレッドには Slack エージェント を使います。このワークフローは「分類」「検索」「統合」という 3 つの固定ステージで構成されます。

こうしてコードとモデルの推論が連携します。価値を生む箇所ではモデルに推論を任せ、それ以外はコードが処理する。その結果、エージェントはより安価で高速になり、予測可能性も高まります。

グラフを使うべきでないケース

タスクによっては、本質的にエージェント性が強く求められるものがあります。そのような場合、決定論的なパスに無理やり当てはめるのは逆効果です。システムをグラフとして表現するのではなく、エージェント・ハーネス（例：Deep Agents）を活用すべきです。

汎用的な深層調査（deep research）はその好例です。調査エージェントは、計画立案、委任、検索、読解、統合といったタスクを事前に特定しにくい方法で実行する必要があります。私たちは当初、事前定義された LangGraph ワークフローを用いて深層調査を実装していましたが、よりエージェント性の高いコア・ループへと移行しました。

人気のある深層調査の実装である GPT Researcher も同様の転換を行いました。グラフ形状のマルチエージェント・パイプラインを Deep Agents に置き換え、計画や委任、コンテキスト管理といった機能をハードコードされたグラフから、ハーネス内で自律的に発生する形へと変更したのです。

LangGraph の構築から得た教訓

私たちは過去 3 年間、グラフで駆動されるエージェントの構築に取り組んできました。その過程で得られた知見をいくつか紹介します。

第一に、エージェント用のグラフは通常、有向非巡回グラフ（DAG）ではありません。

実運用におけるエージェントには、ループ処理が不可欠です。失敗したツール呼び出しの再試行、ユーザーからの不足情報への問い合わせ、検証後の回答修正、十分な文脈が揃うまでのツール連続呼び出し、そして人間の入力を待ってから再開する一時停止など、これらはすべてループの一部です。ループはエージェントシステムの核心部分であり、そのためシステムは必ずしも有向非巡回グラフ（DAG）である必要はありません。

第二に、ループは単純なグラフです。

Loop engineering はグラフの代替案というよりも、むしろその簡易版と言えます。David Khourshid 氏も指摘している通り As David Khourshid put it、ループとは単に有向で循環するグラフのことです。実際、シンプルなエージェントループを基盤とする LangChain フレームワークも、LangGraph 上に構築されています。

第三に、動的な遷移が重要です。

すべてのエッジを事前に定義する必要はありません。あるノードが実行時に処理量を決定するケースもあるからです。マッピングとリダクション（Map-reduce）は古典的な例で、入力を分割して各ピースをワーカーに送り、結果を結合します。この場合のワーカー数は入力によって変動するため、事前にその数を把握することはできません。

LangGraph は Send を用いてこれに対応し、ノードが静的にすべての遷移を定義するのではなく、実行時に下流のノードへ動的に作業をルーティングできるようにしています。

これは重要です。有用なエージェントシステムは、既知の構造と実行時の可変性を組み合わせているからです。

「研究では情報を収集して統合すべきだ」ということは知っていても、実際に何件のソースが必要かはわからないかもしれません。「スーパーバイザーがワーカーにタスクを委任するべきだ」という原則は知っていても、どの特定のワーカーを使うかはタスクが始まるまでわかりません。グラフ構造にも、実行時の柔軟性が求められます。

何が本当に新しいのか

エージェントシステムをグラフとして表現すること自体は古くからあり、すでに3年間行われています。「グラフエンジニアリング」という新たな波の中で、いったい何が変わったのでしょうか？

寛容に解釈すれば、変化したのは「ノード内に何を詰め込めるか」です。初期の頃は、ノードは決定論的なコードか、LLM（大規模言語モデル）への単一呼び出しに限られていました。しかし現在では、エージェント自体が信頼性を持って実務を任せるのに十分になったため、ノードには「エージェントの実行全体」を含めることが可能になりました。つまり、LLM の呼び出しを調整するだけでなく、エージェント自体をオーケストレーションしているのです。

コーディングエージェントはこの好例です。現在、生産環境で最も効果的で影響力のあるエージェントの一つであり、それをより大きなグラフのノードとして埋め込むというパターンが、ようやく実用的なものとなりました。

例えば、Slack 上のリクエスト（以下参照）をドキュメント作成エージェントが受け取り、

レビュー待ちのプルリクエストとして出力するケースがあります。

このグラフの各ノードは、決定論的から自律的なまでのスケール上で異なる位置に存在します。

• 固定ステップ：スラック処理と線形演算は、事前に定義されたコードと API 呼び出しによって実行されます。
• モデルステップ：分類器と合成ステップでは、ツールを使用せず単一の LLM（大規模言語モデル）呼び出しが行われます。
• エージェントステップ：リファレンスドキュメント用エージェントとコンセプトドキュメント用エージェントは、それぞれのコードベースにおいてより自由度の高い作業を遂行します。

このように決定論性と自律性を組み合わせることで、ドキュメント作成エージェントは予測可能かつ強力でありながら効率的に動作するのです。

大きな視点

グラフエンジニアリング自体は新しい概念ではありません。これは信頼性の高いエージェントを構築するための確立されたアプローチの最新の名前です。

これは ループエンジニアリング や ハネスエンジニアリング の背後にある考え方と同じで、各ステップにおいてモデルの推論を適切な場所に、適切なコンテキストとともに配置するアプローチです。

グラフエンジニアリングを試してみたい場合は、LangGraph をぜひお試しください。