LangChainとLangGraphでカスタムコーディングエージェントを作る

なぜカスタムエージェントが必要なのか——既成ツールの限界を突破する

Cline、Aider、OpenHandsなどの既成AIコーディングツールは優れているが、組織固有のワークフローや独自のコンテキスト管理ロジックを組み込むことには限界がある。例えば、自社の社内APIと深く統合したいケース、特定のコーディング規約チェックをエージェントのループに組み込みたいケース、複数のLLMを異なるタスクに使い分けるカスタムロジックを実装したいケースなどだ。こういった「既成ツールでは無理」という壁にぶつかったとき、LangChainとLangGraphが選択肢になる。

LangChainはLLMアプリケーション構築のフレームワークで、プロンプト管理、チェーン構築、ツール統合などの基盤を提供する。LangGraphはLangChainの上に構築されたグラフベースのエージェントオーケストレーションライブラリで、状態管理とループ制御を明示的に定義できる。「自分でエージェントを作る」となると難しく聞こえるが、LangGraphを使えば驚くほど短いコードでReActエージェントを実装できる。

ReActエージェントの基本実装——Think・Act・Observeを繰り返す

コーディングエージェントの基本パターンはReAct（Reasoning + Acting）ループだ。LangGraphを使ったReActエージェントの実装では、「Think」「Act」「Observe」の三つのノードをグラフとして定義する。「Think」ノードでLLMに現在の状況を分析させ次のアクションを決定する。「Act」ノードでコード実行、ファイル操作、検索などのツールを呼び出す。「Observe」ノードでツールの実行結果を状態に記録し、タスク完了判定を行う。

LangGraphの強みは、このグラフ構造が明示的なコードで定義されるため、デバッグが容易で状態の追跡が可能な点だ。既成ツールを使っているとAIの「思考プロセス」がブラックボックスになりがちだが、LangGraphではどのノードでどんな判断をしたかが完全にトレースできる。特定の条件（エラー発生、コスト上限到達など）に基づいて実行フローを動的に制御できる点も、本番運用での信頼性に直結する。

マルチエージェントグラフで専門特化チームを作る

LangGraphを使ったマルチエージェントシステムでは、複数のSpecialistエージェントとOrchestratorエージェントをグラフノードとして定義する。コーディングエージェントの例では、「コード生成エージェント」「テスト生成エージェント」「コードレビューエージェント」「ドキュメント生成エージェント」という4つのSpecialistと、タスクを分解して各Specialistに振り分けるOrchestratorを実装する。

実際に構築した経験から言うと、最初は2〜3エージェントのシンプルな構成から始めることをすすめる。「コード生成エージェント + レビューエージェント」という組み合わせだけでも、シングルエージェントより品質が上がることが多い。マルチエージェントは構成が複雑になるほど意図しない挙動が出やすいため、シンプルに保つことが品質の安定につながる。

本番運用はLangSmithなしでは始めるな

カスタムエージェントを本番で運用する際は、LangSmithによるトレーシングとモニタリングが不可欠だ。各エージェントの実行ステップ、LLMへの入出力、ツール呼び出しの記録がLangSmithダッシュボードで可視化されることで、問題の特定とデバッグが大幅に容易になる。プロンプトの改善効果をA/Bテストする機能も提供されており、エージェントの継続的な改善サイクルを支援する。

LangSmithなしで本番運用を始めると、「なぜかこの種のタスクで失敗する」という問題の原因特定に何日もかかることがある。最初からLangSmithを組み込んでおけば、問題が出た瞬間に「どのステップで何が起きたか」が分かる。コスト分析機能でモデル別・タスク別のAPI消費量も追跡できる。あなたがLangGraphでカスタムエージェントを作るなら、LangSmithの設定を最初のステップとして必ず入れてほしい。