RAGチャットボットはなぜ複雑な依頼の前で止まるのか?
企業向けRAGチャットボットは、質問を受けると文書を検索し回答を生成します。この一直線の構造が単線パイプラインです。「昨年第4四半期の実績データを探して、今年の戦略提案書のドラフトまで書いて」といった依頼は、検索もして数値も抜き出して文章も書かなければなりませんが、単線パイプラインにはこの流れを処理する経路自体がありません。
コンビニに水がなければ、人は地図を開いて隣のコンビニを探します。単線パイプラインは「ありません」と言って止まります。検索で答えが出なければ検索語を変えてやり直し、それでもだめならウェブ検索ツールに切り替える。行き詰まったら引き返すループと、状況に応じて道を変える分岐。この二つが知能の核心であり、これを設計する作業がオーケストレーションです。
LangChain・LangGraph・LangSmithはそれぞれ何を担うのか?
LangChainはLLMと対話するための標準部品の供給所です。プロンプトテンプレート、どのモデルを使ってもコードが変わらないモデル接続の抽象化、作業を順番に束ねるチェーン連結を提供します。ただしチェーンは依然としてAからBへ進む直線です。
LangGraphは制御フローの設計ツールです。ノードは検索・判断・回答といった作業単位、エッジはその間の道で、エッジに条件を付ければループと分岐になります。LangSmithは可観測性レイヤーです。AIシステムにCCTVを付けるように、全ノードの検索文書、プロンプト、中間判断を記録し、誤答の原因を遡って追跡でき、プロンプトやモデルを替えたときの性能変化を定量評価する根拠にもなります。この三つが揃って初めて一つのオーケストレーションシステムです。
税務相談の自動化にはなぜループと分岐が必要なのか?
顧客が「子どもに建物を贈与したいが税金はどうなるか」と尋ねると、担当者は贈与税の条文を探し、その顧客の過去の贈与履歴と累計贈与額を確認しなければなりません。この二つを突き合わせるのに一日1〜2時間を費やすことが珍しくありません。RAGチャットボット一つでは無理です。税法検索と履歴照会を行き来して総合判断する分岐が必要だからです。
フローチャートは、質問分類、税法検索、顧客履歴照会、十分性判断、回答生成の五つのノードで描かれ、根拠が足りなければ検索ノードに戻るループが入ります。誤答が法的責任につながる領域なので可観測性も必須です。「相続税及び贈与税法第53条を検索し、この顧客の2023年の事前贈与履歴を参照して回答した」という監査ログが自動で残らなければなりません。
非開発者はこの設計で何を担うのか?
三つです。どの税法文書を入れ、顧客履歴のどのフィールドをAIに見せるかを決めるデータオーナーシップ。業務ロジックをフローチャートに描くこと。税務の質問100問に模範解答を付けて評価セットを作ること。すべてコーディングではなくドメイン知識の領域です。ゴミデータを入れればゴミの答えが返ってきます。フローチャートが描ければ、コードに移すのはバイブコーディングがやってくれます。
オーケストレーションはいつ取り出すべきか?
API一回の呼び出しで済む仕事にLangGraphを付けるのは無駄です。複雑な道具を何にでも付ければ腕のいいバイブコーダーになれるわけでもありません。ループを回す必要があったり、条件によって仕事が分かれたりするほど複雑なとき、それがLangChain・LangGraph・LangSmithを取り出すタイミングです。AXの出発点は道具ではなく、業務の流れを描けるドメイン知識です。