LangGraph の構築：第一原理から設計するエージェントランタイム

![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbaa7ebf847dfe35ef1650_How-We-Built-LangGraph--1-.png) *By Nuno Campos* **要約:** 私たちは約 2 年前に、低レベルのエージェントフレームワークである LangGraph をリリースしました。すでに LinkedIn、Uber、Klarna といった企業が、本番環境で動作するエージェントを構築するためにこれを利用しています。LangGraph は、非常に人気のある LangChain フレームワークからのフィードバックに基づいて構築され、生産環境向けにエージェントフレームワークがどのように機能すべきかを再考したものです。私たちは AI エージェントにとって最適な抽象化レベルを探求し、最終的にはほとんど、あるいは全く抽象化しないという結論に至りました。その代わり、私たちは「制御」と「耐久性」に焦点を当てました。この投稿では、信頼性の高いエージェントを構築する過程で得た知見に基づき、LangGraph の設計原則とアプローチについて共有します。 LangGraph ALPHA ついに LangGraph 1.0 のアルファ版をリリースしました！ [今すぐお試しください](https://docs.langchain.com/oss/python/langgraph/overview?ref=blog.langchain.com) — 私たちは、2 年以上前に LangChain の非常に人気のあるチェーンやエージェントの再構築として [LangGraph](https://github.com/langchain-ai/langgraph?ref=blog.langchain.com) を開始しました。オリジナルの langchain オープンソースライブラリ（無数の GitHub イシュー、ディスカッション、Discord、Slack、Twitter の投稿）がリリースされて以来受け取ったすべてのフィードバックに対応するために、ゼロから始めることが最も柔軟性があると考えたのです。私たちが最も頻繁に耳にしたのは、「langchain は始めやすいが、カスタマイズやスケーリングは難しい」という点でした。**今回は、LangGraph を本番環境でエージェントを実行するために使用するものにするという目標を最優先しました**。トレードオフを迫られた際にも、人々が始めやすさよりも、本番環境での使用準備ができていることを優先しました。 この投稿では、LangGraph のスコープ設定と設計プロセスについて共有します。 - まず、従来のソフトウェア開発と比較してエージェント構築がどのように異なるかを解説します。 - 次に、これらの違いを必須機能に変換した方法について議論します。 - 最後に、これらの要件に対してフレームワークをどのように設計しテストしたかを示します。 その結果、エージェントの規模とスループットの両方にスケールする、低レベルで本番環境対応のエージェントフレームワークが生まれました。 ## エージェントに必要なものは何か？ 私たちが最初に問うた2つの質問は、「実際に LangGraph を構築する必要があるのか？」そして「既存のフレームワークを使ってエージェントを生産環境に導入できないのか？」でした。これらの問いに答えるためには、エージェントが過去のソフトウェアとどのように異なる（あるいは類似している）かを定義する必要がありました。私たちは多数のエージェントを自ら構築し、Uber、LinkedIn、Klarna、Elastic などのチーム [2024年の生産環境におけるトップ5の LangGraph エージェント](https://blog.langchain.com/top-5-langgraph-agents-in-production-2024/) と協力する中で、これらを3つの重要な違いに絞り込みました。 - より高いレイテンシ（遅延）は、ユーザーのエンゲージメントを維持することを困難にする - 失敗した長時間実行タスクのリトライは、コストが高く時間がかかる - AI の非決定論的な性質には、チェックポイント、承認、テストが必要である ## レイテンシ（遅延）の管理 LLM ベースのエージェントにおける最初の定義的特質かつ課題はレイテンシです。以前はバックエンドエンドポイントのレイテンシをミリ秒単位で測定していましたが、今ではエージェントの実行時間を秒、分、あるいは間もなく時間単位で測定する必要があります。 その理由は、LLM 自体が遅く、テスト時の計算リソース（test-time compute）が増えるにつれてさらに遅くなっているからです。また、望ましい結果を達成するために複数の LLM 呼び出しが必要となる場合が多く、ループするエージェントや、以前の出力を修正するための連鎖的な LLM プロンプトを使用することもあります。通常、LLM の呼び出しの前と後に非 LMM ステップを追加する必要があります。例えば、データベースの行をコンテキストに読み込んだり、LLM の呼び出しの正確性を確認するためのガードレールや検証器を作成したりする必要があるかもしれません。 これらの遅延は新しいものを構築することを可能にしますが、エンドユーザーを最後まで関与させ続ける必要があります。そこで、エージェントを構築する際に役立つと判断した 2 つの機能を見出しました。 - パラライゼーション（並列化）。エージェントに複数のステップがある場合、次のステップが前のステップの出力を必要としないときは、それらを並列で実行できます。ただし、本番環境でこれを確実に実行するには、並列ステップ間のデータ競合（data races）を避ける必要があります。 - ストリーミング。エージェントの実際の遅延をこれ以上短縮すると結果が悪化する場合、知覚される遅延（perceived latency）に頼ります。ここで鍵となるのは、エージェントが動作している間にユーザーに有用な情報を表示することです。これは進捗バーやエージェントが行った主要なアクションから、エンドユーザーに対して LLM のメッセージをトークン単位でリアルタイムにストリーミングするまで、あらゆる形態を取り得ます。 ## 信頼性の管理 LLM エージェントの遅延には、他の影響も伴います。ご存知の通り、ソフトウェアの不具合は避けられません。長時間実行されるエージェントほど失敗しやすく、実行時間が長いほど何かが間違える機会が増えるからです。 従来のソフトウェアで不具合が発生した場合、通常は再試行を行います。しかし AI エージェントの場合、それが最善のアプローチとは限りません。もしエージェントが 10 分間のうち 9 分目に失敗した場合、最初からやり直すのは非常に時間がかかり、かつ高コストになります。 そこで、リストにさらに 2 つの機能を追加する必要があると判断しました。 - タスクキュー。キューは、エージェントの実行をトリガーしたリクエストから切り離すことで、一般的な失敗原因の 1 つを排除します。必要に応じて、エージェントを信頼性が高くかつ公平に再試行するための基盤を提供します。 - チェックポイント機能。これは計算状態のスナップショットを中間段階で保存し、実際に失敗した場合の再試行コストを大幅に削減します。 ## 非決定性の LLM の管理 次に、LLM が持つ非決定性という性質が、さらに 2 つの課題を生み出します。従来のソフトウェアを書く場合、少なくともコードが何をするべきか、期待通りに構築した際にどのような結果が得られるかは把握できます。しかし、生成 AI はこれを明らかに変えてしまいます。 LLM では、入力も出力もどちらも開かれたものになります。ChatGPT を使用した経験がある方なら想像できるでしょう。前日に使ったのと同じプロンプトでさえ、異なる結果を生むことがありますし、同じ質問をさまざまな方法で問い合わせて類似の結果が得られることの容易さも実感できるはずです。 これが、LLM エージェントが以前の他のソフトウェアと比較して非常に強力である理由の大きな部分を占めていますが、一方で本番環境へ移行する際には課題も生じます。 開発中に実施するテストでは、ユーザーがエージェントをどのように利用するかという驚くべき多くのパターンを見逃す可能性が極めて高いです。ユーザーがエージェントとどう相互作用するか、あるいは LLM がどのように応答するかについて、すべてを事前に計画することは真に不可能です。したがって、本番環境へ移行する際には、さらに 2 つの機能が非常に有用となります： - Human-in-the-loop。AI エージェントの作業を中断して再開するツールを持つことで、それまでに完了した作業をやり直すことなく、あらゆる時点で介入・再開が可能になります。これにより、AI エージェントにとって不可欠な UX パターンが多数実現します。例えば、アクションの承認または拒否、次のアクションの編集、明確化のための質問、あるいは過去のステップからやり直すための「タイムトラベル」などが挙げられます。 - Tracing（追跡）。スケーラビリティに対応するためには、開発者はエージェントループの詳細内で何が起きているかを明確に把握できる必要があります。エージェントの入力、軌跡、出力を確認できなければ、ユーザーが何を求めているか、エージェントがそれをどう処理しているか、そしてユーザーが結果に満足しているかどうかを知ることはできません。 ## エージェント構築に必要な開発者の要件 これが、エージェントを実環境（プロダクション）へ移行する際に、開発者が最も必要とする 6 つの機能を絞り込んだ方法です。 - Parallelization（並列化）– 実際のレイテンシを削減するため - Streaming（ストリーミング）– 知覚されるレイテンシを削減するため - Task queue（タスクキュー）– リトライ回数を減らすため - Checkpointing（チェックポイント）– 各リトライのコストを削減するため - Human-in-the-loop – ユーザーと協働するため - Tracing – ユーザーがどのように利用しているかを学ぶため あなたが構築しようとしているエージェントにこれらの機能の大半が必要ない場合（例えば、ツールを持たず単一のプロンプトで動作する非常に短いエージェントである場合）、LangGraph や他のフレームワークは不要かもしれません。 これらの機能それぞれを構築することを検討する中で、私たちは開発者が、エンドユーザーにとって LLM アプリケーションの動作が明らかに遅くなるという代償を払ってまで、すべての機能を備えたフレームワークを採用することはないと気づきました。特にチャットボットとして展開されるエージェントにおいてはそうです。これが**低レイテンシ**を最終的な包括的な要件とする理由となりました。 次に、これらの機能を LangGraph にどのように組み込んだかについて解説します。 ## 2. なぜ LangGraph を構築するのか？ 存在意義に関する問いに戻りましょう。新しいものを構築すべきか、それとも LLM の登場以前に作られた既存のオープンソースフレームワークを採用すべきか。機能のリストを手にした今、その決断を下すのは非常に容易でした。 ## 新しいフレームワークが必要だった理由 既存のフレームワークは主に 2 つのカテゴリーに分かれていました： **DAG フレームワーク（Apache Airflow などによって普及）** これらは名前のみで除外せざるを得ませんでした。LLM エージェントはループ処理から大きな恩恵を受けるためです。つまり、LLM エージェントの計算グラフは循環的であり、DAG アルゴリズムでは扱えないからです。 **永続実行エンジン（Temporal などによって普及）** これらの選択肢はより近いものでしたが、最終的には LLM エージェントの設計以前に作られたものだったため、ストリーミングといった特定の機能が不足していました。さらに、これらのエンジンではステップ間に遅延が生じ、チャットボット開発者にとって顕著な問題となっていたのです。最後に、その設計上の理由から、履歴内のステップ数が増えるほどパフォーマンスが低下するという点があり、LLM エージェントがより長く複雑になるにつれて、これは良い賭けではないように思われました。 そこで結論として、LLM は十分に異なるため、新しい時代に対応させるには既存の生産インフラに新たなアイデアを注入する必要があると考えました。そこで私たちは LangGraph の構築に取り掛かりました。 ## 3. 私たちの設計哲学 LangGraph を設計するにあたり、2 つの主要な原則を掲げました。 - 私たちは AI の未来がどうなるか知りません。未来について仮定するほど少ないほど良いのです。1 年、2 年、3 年後に LLM（大規模言語モデル）を使って構築するとどのような姿になるのか、誰も本当に知りません。したがって、フレームワークの設計に組み込む仮定を少なくすればするほど、将来においてもその重要性は保たれます。私たちが組み込みたかった唯一の仮定とは、前述した認識、つまり LLM は遅く、不安定で、かつ開かれたものであるという事実です。 - それはコードを書くような感覚であるべきです。このフレームワークのパブリック API（アプリケーションプログラミングインターフェース）は、フレームワークを使用しない通常のコードを書くことと可能な限り近接している必要があります。開発者のコードに課すすべての要件は、非常に価値の高い機能を可能にするために正当化されなければなりません。そうでなければ、フレームワークを完全にスキップする誘惑の方が強すぎてしまいます。あらゆるコードフレームワークにとって最大の競合相手は、常に「フレームワークなし」です。 - これらの原則は、私たちが今に至るまで守り続けているいくつかの重要な設計決定に影響を与えました。 - まず、ライブラリのランタイムは開発者向け SDK とは独立しています。SDK は、開発者がエージェントを構築する際に使用する公開インターフェース（クラス、関数、メソッド、定数など）です。現在、私たちは 2 つの SDK を提供しています。1 つは StateGraph、もう 1 つは命令型/関数型 API です。ランタイム（私たちが PregelLoop と呼んでいます）は前述した各機能を実装し、各エージェント呼び出しに対して計算グラフを計画して実行します。この設計により、開発者向け API とランタイムを独立して進化させることが可能になります。例えば、SDK 側では命令型 SDK の導入や、共有状態を持たない最初の Graph インターフェースという当初の SDK の非推奨化が可能になりました。一方、ランタイム側では、過去 2 年間にわたって公開 API に影響を与えることなく多くのパフォーマンス向上を実装でき、より大胆なランタイムの変更の実験も可能になりました。これについては後ほど分散実行について触れる際に詳しく説明します。 - 次に、6 つの機能それぞれをビルディングブロックとして提供し、開発者がいつでも自らのエージェントで使用するものを選択できるようにしたかったのです。例えば、人間が関与するシナリオにおける中断/再開機能は、実際に必要とするまで邪魔になることはありません（これは、ノードのいずれかで interrupt() 関数を呼び出すように追加するだけで、非常に簡単です）。その結果、LangGraph は、最新のハイレベル抽象化にすべてを賭けるよう開発者を説得しようとする他のフレームワーク群の中で、ユニークな低レベルフレームワークとして位置づけられました。私たちはこれらの流行が来たり去ったりするのを何度も見てきましたが、LangGraph が依然として関連性を保ち続けているため、これまでの私たちのアプローチには満足しています。 ## 4. LangGraph ランタイム これらの点を踏まえ、LangGraph が私たちが望んだ 6 つの機能（並列化、ストリーミング、チェックポイント、人間をループに組み込む機能、トレーシング、タスクキュー）それぞれを実装する方法を見ていきましょう。 ## 離散的なステップを持つ構造化エージェント 私たちが下した他のすべてのアーキテクチャ上の決定に影響を与えている一つの考えがあります。それは「構造化エージェント」というアイデアです。コンピュータプログラムにより多くの構造を追加し、ある程度の柔軟性を引き換えに数々の新機能を獲得するという長い伝統があります。かつては、基本的な構築要素である [if 文や while ループ](https://en.wikipedia.org/wiki/Structured_programming?ref=blog.langchain.com) が新しい存在として登場しました。エージェントもまた、単一の大きな while ループを持つ一つの関数として直接記述することができます。しかし、そうすると、チェックポイント機能や人間をループに組み込む機能を実装する能力を失ってしまいます。（注：一部のサブルーチン（ジェネレーターなど）の実行を技術的に中断することは可能かもしれませんが、その実行状態は、異なるマシンで異なる時刻から再開できるポータブルな形式で保存することはできません。） ## 実行アルゴリズム エージェントを複数の離散ステップに構造化することを選んだら、その実行を組織化するための何らかのアルゴリズムを選ぶ必要があります。たとえ「アルゴリズムなし」と感じるほど単純なものであっても、それが LangGraph がローンチ前にスタートした地点でした。「アルゴリズムなし」を使う問題点は、一見シンプルに見えるものの、その場で適当に作り上げていくことになり、予期せぬ結果を招くことです（例えば、LangGraph の前身となる初期バージョンでは、並列ノード間で非決定論的な動作が生じるという課題がありました）。ループが必要であるため、通常の DAG アルゴリズム（トポロジカルソートとその関連手法）は適用できません。私たちは最終的に、[BSP](https://en.wikipedia.org/wiki/Bulk_synchronous_parallel?ref=blog.langchain.com) / [Pregel](https://dl.acm.org/doi/10.1145/1807167.1807184?ref=blog.langchain.com) アルゴリズムの上に構築することを選びました。これは、ループ（サイクル）を完全にサポートしつつ、決定論的な並列処理を実現するからです。 私たちの実行アルゴリズムは以下の通り動作します： - チャンネルはデータ（任意の Python/JS データ型）を含み、名前と現在のバージョン（単調増加する文字列）を持ちます - ノードは実行される関数であり、1 つ以上のチャンネルに購読しており、それらが変更されると実行されます - 1 つ以上のチャンネルが入力にマッピングされており、つまりエージェントへの開始入力がこれらのチャンネルに書き込まれるため、これらに購読されているすべてのノードがトリガーされます - 1 つ以上のチャンネルが出力にマッピングされており、つまりエージェントの戻り値は、実行が停止した時点でのこれらのチャンネルの値です 実行はループとして進行し、各反復では - 現在のチャンネルバージョンと各購読者が最後に確認したバージョンを比較することで、実行する 1 つ以上のノードを選択します - それらのノードを並列で実行します。この際、チャンネル値（つまり状態）の独立したコピーを使用するため、実行中に互いに影響し合いませ ん - ノードは実行中に状態のローカルコピーを変更します - すべてのノードが完了すると、各状態コピーからの更新がそれぞれのチャンネルに適用されます。これは決定論的な順序で行われ（これがデータ競合を防止する仕組みです）、その後チャンネルバージョンがインクリメントされます 実行ループは、実行すべきノードが残っていない場合（つまり、チャンネルと購読関係を比較した結果、すべてのノードが購読しているチャンネルの最新バージョンを確認済みである場合）か、開発者が設定できる定数値である反復ステップ数が尽きた場合に停止します。 ## フレームワーク機能の検証 これが、実装したかった 6 つの機能にどのように対応するかを見てみましょう。 - Parallelization. このアルゴリズムはデータ競走のない安全な並列化のために設計されており、ノード間の依存関係が許す限り自動的に並列実行を選択します。また、並列実行されるノードには隔離された状態のコピーを使用し、更新をどのノードが先に開始または完了したか（これは実行ごとに変わる可能性があります）に依存しない順序で適用します。これにより、各ノードの実行順序やレイテンシがエージェントの最終出力に影響を与えることがなくなります。LLM は非決定論的であるため、出力の変動が決してエージェントフレームワークのせいではないことを保証することは重要な特性だと考えました。これにより、問題のデバッグが格段に容易になります。 - Streaming. 構造化された実行モデル（つまり、計算が離散的なステップやノードに分割されるモデル）は、実行中を通じて中間出力や更新をエミットする機会を大幅に増やします。当社の実行エンジンでは、カスタム開発コードを必要とせずに、ノードの実行中およびステップ境界においてストリーミング出力を収集しています。これにより、LangGraph では 6 つの異なるストリームモード（values, updates, messages, tasks, checkpoints, custom）を提供できるようになりました。チャットボットであればメッセージストリームモードを使用し、長時間実行されるエージェントであれば更新モードを使用するといった具合です。 - Checkpointing. これもまた、構造化された実行が可能にするものです。私たちは、保存から任意の時間経過後にどのマシンでも再開可能なチェックポイント、つまり特定のマシンでプロセスを継続して稼働させることや、メモリ上に生データを保持することに依存しないチェックポイントを保存したいと考えています。これを実現するために、シリアライズされたチャネル値（デフォルトでは MsgPack にシリアライズされ、オプションで暗号化可能）と、そのバージョン文字列、および各ノードが最も最近に参照したチャネルバージョンの記録を保存します。 - Human-in-the-loop. 耐障害性を可能にする同じチェックポイント機能は、エージェントに対する「予期された中断」を実現するためにも使用できます。つまり、継続する前にユーザーや開発者からの入力を求めるために、エージェント自身が自ら中断できる能力を与えることです。通常この機能は、入力到着を待っている間もエージェントを実行し続けることで実装されますが、残念ながらこれは時間とボリュームの両面でスケーラビリティに欠けます。多数のエージェントが同時に中断されている場合や、返信までに数日（あるいは数ヶ月！）待ちたい場合は、実際の中断（チェックポイント機能によって同じ地点から再開可能にする仕組み）こそが唯一の解決策です。 - Tracing. 構造化された実行を使用するもう一つの優れた特性は、エージェントの実行中および事後に、その進捗を調査するための非常に明確なステップが得られることです。私たちは以前に最初の LLM オブザーバビリティプラットフォームとして LangSmith を構築していたため、LangGraph は当然ながらネイティブでそれと統合されています。今日ではまた LangGraph Studio も利用可能で、実行中のエージェントをデバッグできますし、より広い互換性のために OTEL トレースもエミット可能です。 - Task queue. これは LangGraph のような Python ライブラリの範囲外であったため、このニーズに応えるために LangGraph Platform を作成することになりました。 全体として、このアーキテクチャはエージェントに必要な 6 つの主要機能をすべて提供します。同時に、構造化されたアプローチとそれを探索するためのツールのおかげで、エージェントの作成とデバッグがより迅速になります。最後に、これは優れたパフォーマンスプロファイルで実現されており、エージェントの規模や本番環境での必要スループットに応じてスケールします—これについては次のセクションで詳しく説明します。 ## 5. パフォーマンス特性 前述した通り、開発者は信頼性を求めますが、レイテンシ（応答遅延）を犠牲にしてまで求めるわけではありません。そのため、私たちのアプローチがこれらのトレードオフに対してどのように機能しているかを検討する必要があります。LangGraph は、それを用いて構築するエージェントのあらゆる規模測定において非常に滑らかにスケーリングします。これは、エージェントがより長く、ステップ数が増え、中断が多くなり、状態サイズが大きくなるなど、ますます複雑化していく未来において、極めて有利な立場にあります。 LangGraph エージェントの実行は、その規模を制御する主要な変数によってどのように影響を受けるのでしょうか？ まず、最も一般的な LangGraph 開発者 SDK である StateGraph における主要な**サイズ変数**を列挙しましょう： - ノードの数（個々のステップ、通常は関数） - エッジの数（ノード間の接続。固定または条件付きのいずれか） - チャンネルの数（状態オブジェクト内のキー） - アクティブなノードの数（特定のステップで並列実行されるもの） - 呼び出し履歴の長さ（現在の呼び出しにおける過去のステップ） - スレッドの数（異なる入力とコンテキストに対する独立した呼び出し） 次に、LangGraph エージェントの呼び出しにおける主要な**瞬間**を列挙し、それぞれの変数に対してどのようにスケーリングするかを見ていきましょう： - スレッドの最新のチェックポイントからストレージへ転送し、それをシリアライズ解除して開始または再開する呼び出し - 次の実行ステップを計画する段階で、次にどのノードを実行するかを決定し、その入力を用意する - 現在のアクティブなノードを実行するステップで、各ノードのコードを実行し、チャネルやエッジへの書き込みを行う - 呼び出しステップを終了する段階で、各チャネルへの更新を適用（チャネルリデューサーの実行とチャネルバージョンのインクリメント）し、最新のチェックポイントを保存（シリアライズしてストレージへ転送）する なお、計画アクションが次に実行すべきノードを返さない場合、実行は単に停止するため、「呼び出し終了」というアクションは存在しない。 要約すると、各アクションの拡張性はエージェントサイズに対して以下のようになる： メトリック / アクション 呼び出し開始 ステップ計画 ステップ実行 ステップ終了 ノード数 O(n) O(1) O(1) O(n) エッジ数 O(1) O(1) O(n) O(1) チャネル数 O(n) O(n) O(n) O(n) アクティブなノード数 O(1) O(n) O(n) O(n) 履歴の長さ O(1) O(1) O(1) O(1) スレッド数 O(1) O(1) O(1) O(1) では、これらの中からいくつかをより詳細に確認しよう。まず、呼び出しを開始するプロセスから始める： - ノード数に対して線形にスケーリングします。各ノードには、その入力エッジの現在の状態を保持する 1 つの隠された制御チャネルが存在するためです。 - エッジ数に対して一定です。各宛先ノードにおけるすべてのエッジの状態が、単一の制御チャネルに集約されるためです。 - チャネル数に対して線形にスケーリングします。各チャネルには、その現在の値のシリアライズ表現が存在するためです。 - アクティブなノード数に対して一定です。この変数との関係はありません。 - ヒストリの長さに対して一定です。最新のスナップショットのみを取得し、それ以前のステップを再生する必要がないためです。 - スレッド数に対して一定です。スレッドは完全に独立しており、各呼び出しでは単一のスレッドのみが影響を受けるためです。 次に、次のステップの計画について： - ノード数は一定であり、前ステップ完了時に更新されたチャンネルのリストを保存することで、次のノードを計画する際に全ノードを反復処理する必要がなくなります - エッジ数も一定です。各ノードに対してすべてのエッジが単一のトリガーチャンネルに集約されるためです - チャンネル数は線形にスケーリングします。各ノードの入力を組み立てる際、現在設定されているチャンネルを確認するためにチャンネルを反復処理するためです - アクティブなノード数も線形にスケーリングします。このステップで実行する各ノードについて、その呼び出しに使用する入力と構成を組み立てるためです - 履歴の長さは一定です。すべての以前の書き込みを集約した最新のチェックポイントのみを扱うためです - スレッド数は一定です。スレッドは完全に独立しており、各呼び出しが単一のスレッドのみを対象とするためです 第三に、ステップの実行: - ノード数は一定であり、ステップ内でアクティブなノードのみがそのステップの実行に影響します - このステップでアクティブなノードのエッジ数に対して線形にスケーリングし、各アクティブなノードは自身の出力エッジすべてへ公開を行います - チャンネル数に対して線形にスケーリングし、各アクティブなノードについて、そのノードが値への更新を返したかどうかを確認します（辞書形式の戻り値を使用する場合は、これをチャンネル数に対して一定となるように最適化し、戻り値のキーのみを反復処理します） - アクティブなノード数に対して線形にスケーリングし、各アクティブなノードは並列で実行されます - 履歴の長さに対して一定であり、現時点では履歴を扱いません - スレッド数に対して一定であり、スレッドは完全に独立しており、各呼び出しは単一のスレッドのみを対象とするためです 最後に、ステップの完了について: - ノード数に対して線形にスケーリングします。各ノードには、その入力エッジの現在の状態を保持する 1 つの隠された制御チャネルが存在するためです。 - エッジ数に対して一定です。各宛先ノードにおけるすべてのエッジの状態が、単一の制御チャネルに集約されるためです。 - チャネル数に対して線形にスケーリングします。各チャネルはアクティブなノードからの書き込みで更新され、そのバージョン番号が増分されます。 - アクティブなノード数に対して線形にスケーリングします。各アクティブノードからの書き込みを収集するためです。 - 履歴の長さに対して一定です。すべての以前の書き込みを集約した最新のチェックポイントのみを扱うためです。 - スレッド数に対して一定です。スレッドは完全に独立しており、各呼び出しが単一のスレッドにのみ影響を与えるためです。 これらのパフォーマンス特性は、ライブラリの設計選択の結果であると同時に、過去 2 年間にわたって実施してきた多数のパフォーマンス最適化の成果でもあります。 ## はじめに 要約すると、LLM を使用して構築することの違いや、エージェントを本番環境で実行するために必要なものは何かについて、深く考察しました。これらの考えが LangGraph の構築と反復開発へとつながりました。LangGraph は制御と耐久性に焦点を当てており、これにより、あなたのエージェントが意図した通りに動作する可能性が最も高まります。 LangGraph についてさらに詳しく学び、ご自身のプロジェクトで試してみたい場合は、[ドキュメント](https://langchain-ai.github.io/langgraph/?ref=blog.langchain.com)へお進みください。 ## 関連コンテンツ ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cb92b0ec45aa6d7bc39a91_KEnsho.png) ケーススタディ LangGraph 観測可能性と評価 ## 信頼性の高い金融データ検索を解決するために、Kensho が LangGraph を用いて構築したマルチエージェントフレームワーク LangChain チーム 2026 年 3 月 26 日 4 分 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbaa08cd1956c2e4f9ff39_Remote-case-study.png) ケーススタディ LangChain LangGraph ## AI を活用して数千名の顧客をオンボーディングする Remote の LangChain と LangGraph の活用事例 LangChain チーム 2026 年 1 月 19 日 5 分 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbaa18703c727fd28ab4de_Vodafone-Italy---Oct-2025--1-.png) ケーススタディ LangGraph LangSmith ## Fastweb と Vodafone: LangGraph と LangSmith を用いた AI エージェントによる顧客体験の変革 LangChain チーム 2025 年 12 月 16 日 7 分 ## エージェントが実際に何をしているかを確認する LangSmith は、エージェントエンジニアリングプラットフォームであり、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるように支援します。

LangGraph の構築：第一原理から設計するエージェントランタイム

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト