LangGraph 0.5 : エージェント開発 : エージェント・アーキテクチャ

by

LLM アプリケーションは LLM 呼び出しの前後に特定の制御フローを実装していますが、より複雑な問題を解決するために独自の制御フローを選択できる LLM システムを望む場合があります。エージェントは LLM を使用してアプリケーションの制御フローを決定するシステムです。

LangGraph 0.5 : エージェント開発 : エージェント・アーキテクチャ

作成 : クラスキャット・セールスインフォメーション
作成日時 : 07/07/2025

* 本記事は langchain-ai.github.io の以下のページを独自に翻訳した上で、補足説明を加えてまとめ直しています :

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

クラスキャット 人工知能 研究開発支援サービス ⭐️ リニューアルしました 😉

◆ クラスキャット は人工知能に関する各種サービスを提供しています。お気軽にご相談ください :

  • 人工知能導入個別相談会(無償)実施中！ [詳細]

  • 人工知能研究開発支援 [詳細]
    1. 自社特有情報を含むチャットボット構築支援
    2. 画像認識 (医療系含む) / 画像生成

  • PoC(概念実証)を失敗させないための支援 [詳細]

◆ お問合せ : 下記までお願いします。

  • クラスキャット セールス・インフォメーション
  • sales-info@classcat.com
  • ClassCatJP

 

 

LangGraph 0.5 : エージェント開発 : エージェント・アーキテクチャ

多くの LLM アプリケーションは LLM 呼び出しの前後にステップの特定の制御フローを実装しています。例えば、RAG はユーザ質問に関連するドキュメントの取得を実行してそれらのドキュメントを LLM に渡して、提供されるドキュメントのコンテキストに基づいてモデルの応答をさせます。

固定された制御フローをハードコーディングするかわりに、より複雑な問題を解決するために独自の制御フローを選択できる LLM システムを望む場合があります！これは エージェント の定義の一つです: エージェントは LLM を使用してアプリケーションの制御フローを決定するシステムです。LLM がアプリケーションを制御する多くの方法があります :

  • LLM は 2 つの潜在的なパス間でルーティングできます。

  • LLM は多くのツールのどれを呼び出すか決定できます。

  • LLM は、生成された回答が十分であるか、さらなるワークが必要か判断できます。

その結果、多くの様々なタイプの エージェント・アーキテクチャ があります、これらは LLM に多様なレベルの制御を与えます。

 

ルーター

ルーターは LLM が特定のオプションのセットから単一ステップを選択することを可能にします。LLM は通常は単一の決定を行うことにフォーカスし、限定的な事前定義済みオプションのセットから特定の出力を生成するので、これは、比較的制限されたレベルの制御を示すエージェントアーキテクチャになります。ルーターは通常はこれを達成するために幾つかの異なるコンセプトを採用しています。

 

構造化出力

LLM による構造化出力は、LLM が応答時に従う必要がある特定の形式やスキーマを提供することで機能します。これはツール呼び出しに似ていますが、より汎用的です。ツール呼び出しが通常は事前定義済み関数の選択と使用を伴う一方で、構造化出力は任意の形式化されたレスポンスに使用できます。この構造化出力を実現する一般的な方法は以下を含みます :

  1. プロンプト・エンジニアリング: システムプロンプトを通して特定の形式で応答するように LLM に指示します。

  2. 出力パーサー: 後処理を使用して LLM レスポンスから構造化データを抽出します。

  3. ツール呼び出し: 一部の LLM の組み込みツール呼び出し機能を活用して構造化出力を生成できます。

構造化出力はルーティングのために重要です、LLM の決定がシステムにより確実に解釈されて処理されることをそれらが保証するからです。Learn more about structured outputs in this how-to guide.

 

ツール呼び出しエージェント

ルーターは LLM が単一の決定を行うことを可能にする一方で、より複雑なエージェント・アーキテクチャは LLM 制御を 2 つの主要な方法で拡張します :

  1. マルチステップの意思決定: LLM は一つだけでなく、段階的に一連の決定を行うことができます。

  2. ツールアクセス: LLM はタスクを完遂するために様々なツールを選択して使用できます。

ReAct はこれらの拡張を組み合わせ、3 つのコアコンセプトを統合した、ポピュラーな汎用エージェント・アーキテクチャです。

  1. ツール呼び出し : LLM が必要に応じて様々なツールを選択して使用することを可能にします。

  2. メモリ : エージェントが前のステップから情報を保持して使用することを可能にします。

  3. プランニング : LLM が目標を達成するために他段階のプランを作成して従うように支援します。

このアーキテクチャはより複雑で柔軟なエージェントの動作を可能にし、単純なルーティングを超えて、他段階による動的な問題解決を可能にします。元の 論文 とは異なり、今日のエージェントは LLM の ツール呼び出し 機能に依存して メッセージ のリスト上で動作します。

LangGraph では、事前構築済み エージェント を使用してツール呼び出しエージェントを開始できます。

 

ツール呼び出し

ツールは、エージェントが外部システムとやり取りすることを望む場合に常に有用です。外部システム (e.g., API) は、自然言語ではなく、特定の入力スキーマやペイロードを必要とする場合が多いです。API を例えばツールとしてバインドする場合、必要な入力スキーマをモデルに認識させます。モデルは、ユーザからの自然言語入力に基づいてツールを呼び出すことを選択し、ツールの必要なスキーマに準拠した出力を返します。

多くの LLM プロバイダーはツール呼び出しをサポート しており、LangChain の ツール呼び出し I/F は単純です : 任意の Python 関数を ChatModel.bind_tools(function) に単純に渡すことができます。

 

メモリ

メモリ はエージェントにとって重要で、問題解決の多段階に渡り情報を保持して活用することを可能にします。異なるスケールで動作します :

  • 短期メモリ : エージェントがシークエンスのより早期のステップで獲得した情報にアクセスすることを可能にします。

  • 長期メモリ : エージェントが (会話の過去のメッセージのような) 以前のインタラクションから情報を思い出すことを可能にします。

LangGraph はメモリ実装に対する完全な制御を提供します :

  • 状態 (State) : 保持するメモリの正確な構造を指定するユーザ定義のスキーマ。

  • チェックポインタ : セッション内の様々なインタラクションに渡りステップ毎に状態をストアするメカニズム。

  • ストア : セッションに渡るユーザ固有またはアプリケーションレベルのデータをストアするメカニズム。

この柔軟なアプローチは特定のエージェント・アーキテクチャのニーズに合わせてメモリシステムをカスタマイズすることが可能です。効果的なメモリ管理は、コンテキストを維持し、過去の経験から学習し、そして時間につれてより多くの情報に基づく決定を行うようにエージェントの機能を強化します。For a practical guide on adding and managing memory, see Memory.

 

プランニング

ツール呼び出し エージェント では、LLM は while-ループ内で繰り返し呼び出されます。各ステップで、エージェントはどのツールを呼び出すか、それらのツールへの入力は何かを決定します。それからそれらのツールが実行され、出力は観測値として LLM にフィードバックされます。エージェントがユーザの要求を解決するに十分な情報を持っていて、それ以上のツールの呼び出しに価値がないと判断した場合、while ループは終了します。

 

カスタム・エージェント・アーキテクチャ

(ReAct のような) ルーターとツール呼び出しエージェントが一般的である一方、エージェントアーキテクチャのカスタマイズ が特定のタスクに対してより良いパフォーマンスに繋がる場合も多いです。LangGraph はカスタマイズされたエージェントシステムを構築するための幾つかの強力な機能を提供しています :

 

Human-in-the-loop

人間の関与は、特に機密性の高いタスクに対して、エージェントの信頼性を大幅に強化できます。これは以下を含みます :

  • 特定のアクションの承認
  • フィードバックを提供してエージェントの状態を更新する
  • 複雑な意思決定プロセスでガイダンスを提供する

完全な自動化が実現不可能または望ましくない場合、human-in-the-loop パターンは重要です。Learn more in our human-in-the-loop guide.

 

並列化

並列処理は、効率的なマルチエージェント・システムと複雑なタスクに対して不可欠です。LangGraph は Send API を通して並列化をサポートし、以下を可能にします :

  • 複数の状態の concurrent 処理
  • map-reduce ライクな演算の実装
  • 独立したサブタスクの効率的な処理

For practical implementation, see our map-reduce tutorial

 

サブグラフ

サブグラフ は、特に マルチエージェント・システム において、複雑なエージェントアーキテクチャを管理するために不可欠です。以下を可能にします :

  • 個々のエージェントに対する独立した (isolated) 状態管理
  • エージェントチームの階層的組織 (organization)
  • エージェントとメインシステム間の制御された通信

サブグラフは状態スキーマ内のオーバーラップするキーを通して親グラフと通信します。これは柔軟で、モジュール化されたエージェントデザインを可能にします。For implementation details, refer to our subgraph how-to guide.

 

リフレクション

リフレクション・メカニズムは以下によりエージェントの信頼性を大幅に向上させます :

  • タスクの完成度と正確性を評価
  • 反復的な改良のためのフィードバックの提供
  • 自己修正と学習を可能にする

 

以上