LangGraphが渡すのは、設計図

Posted at 2026-08-30

自分で作ったエージェントに、「なぜ今その処理をしたのか」を説明できなくなったことがあります。

指示を渡せば、検索し、道具を使い、文章を返す。それらしく動いていました。ところが妙な寄り道をしたとき、どこで判断が変わったのかを追えません。賢いのに、手綱がない。正直、その状態を本番へ出すのが怖くなりました。

2026年、AIエージェントを動かすこと自体は難しくなくなりました。次に問われるのは、失敗したときに追えるか、途中から再開できるか、人が止められるかです。デモでは隠れていた運用の条件が前へ出ています。

動くのに御せないエージェントと、失敗しても追跡・再開できるエージェントを分けるものは何か。僕の答えは、モデルではなく設計図です。LangGraphが、暗黙の処理をどう外へ出すのかを順に見ます。

丸投げした処理は、成功している間しか説明できない

一つのモデルへ目標と道具を渡し、あとは任せる。デモを作るなら速い方法です。ただし、途中の判断がモデルの中へ隠れます。

検索結果が悪かったのか、結果の評価を誤ったのか、別の道具を選ぶべきだったのか。最終出力だけを見ても区別できません。

モデルが多くのことを判断できるほど、取り得る経路は増えます。これは能力である一方、観測する側には複雑さです。

LangGraphの基本は、処理をノード、処理間の移動をエッジ、途中で共有する情報をStateとして表すことです。

「検索する」「要約する」「検証する」のような処理をノードにします。あるノードが終わった後、次にどこへ進むかをエッジでつなぎます。

前の処理の結果を次へ渡すには、状態が必要です。質問、検索結果、検証結果、承認状態などをStateに置きます。

ノードを細かくしすぎると図が読めなくなり、大きくしすぎると失敗点が隠れます。僕は「失敗したとき、一つの理由で説明できるか」を境界にしています。

処理が短く、分岐も少なく、途中再開も不要なら、通常のループで十分です。LangGraphを使うことが目的ではありません。

LangGraphの公式資料では、グラフの状態をチェックポイントとして保存し、人の確認、再開、障害からの復帰に使えると説明されています。

送信、削除、費用が大きい操作など、AIだけで決めたくない場所があります。そこへ割り込みを置き、状態を保存したまま人の判断を待つ。承認、修正、却下の結果を受けて再開します。

経路だけを記録しても、なぜ分岐したかは説明できません。反対に、最終状態だけを残しても、どの処理が値を変えたかわかりません。

途中の状態が保存されていれば、成功した処理をすべて繰り返さず、最後に確定した地点から再開できます。長い調査や複数の道具を使う処理では、費用と時間の違いが大きくなります。

人の確認や障害から再開するとき、ノードの先頭から処理が再実行される場合があります。送信、課金、削除のような副作用を持つ処理では、同じ操作が二度起きない設計が必要です。

最初から全社の業務をグラフへ載せる必要はありません。判断が必要だが、手順は描ける仕事を一つ選びます。

問い合わせの一次対応なら、受け取る、調べる、回答案を作る、人が確認する、返す。社内文書の質問なら、問いを整理する、検索する、十分か判断する、回答する。

最初の一枚には、次を書きます。

一枚を描いたら、コードを書く前に次を確認します。

冒頭の問いに戻ります。動くのに御せないエージェントと、失敗しても追跡・再開できるエージェントを分けるものは何か。

処理、遷移、状態、停止、人の判断を、設計図として外へ出せているかどうかです。LangGraphが渡すのは、モデルの賢さではありません。暗黙のループをノードとエッジへ変え、戻り場所を持たせるための紙です。

僕はあの「なぜ今それをしたのか」を説明できなかった失敗から、実装前に一枚描くようになりました。賢いモデルを選ぶ前に、通ってよい道と人へ戻す場所を決めます。

同じようにエージェントの設計図を描いている方がいれば、最初のノードをどこへ置いたか、コメントで知見を交換できるとうれしいです