RAGチャットボットはなぜ複雑な依頼の前で止まるのか?
企業向けRAGチャットボットを作ると、すぐに限界が見えてきます。質問を受けて文書を検索し、回答を生成する——この一直線の構造が単線パイプラインです。「昨年第4四半期の実績を探して、今年の戦略提案書のドラフトまで書いて」といった依頼を前にすると、検索して答えるだけのパイプラインには、その仕事を実行する経路自体がありません。
ループと分岐はなぜ知能の核心なのか?
コンビニに水がなければ、人は地図を開いて隣のコンビニを探します。単線パイプラインは「ありません」と言って止まります。検索で答えが出なければ検索語を変えてやり直し、それでもだめなら別のツールに切り替える——行き詰まったら引き返すループと、状況に応じて道を変える分岐、この二つが知能の核心であり、これを設計する作業がオーケストレーションです。
役割は三つに分かれます。LangChainはLLMと対話する標準部品を、LangGraphはループと分岐を描く制御フローを、LangSmithはシステム内部を見通す可観測性を担います。三つが揃って初めて一つのオーケストレーションシステムになります。
可観測性がなければ何を失うのか?——税務相談の自動化
可観測性はしばしば軽視されますが、これがなければAIが出した答えの根拠を遡って追跡できません。税務相談を例にとると、担当者は税法の条文と顧客の贈与履歴を調べるのに一日1〜2時間を費やします。この業務を自動化するには、税法検索と履歴照会を行き来する分岐が必要です。
しかも誤答がそのまま法的責任になる領域なので、どの条文とどの履歴を根拠にそう答えたのかという監査ログまで残さなければなりません。この根拠を残すことこそが可観測性であり、LangSmithが担う役割です。
非開発者はこの設計で何を担うのか?
この設計における非開発者の役割は、思ったより大きいものです。どのデータを入れるかを決めるデータオーナーシップ、業務ロジックをフローチャートに描くこと、質問100問と模範解答で評価セットを作ること——すべてコーディングではなくドメイン知識の領域です。フローが描ければ、コードに移すのはバイブコーディングがやってくれます。
ただし、API一回で済む仕事にオーケストレーションを付けるのは無駄です。ループと分岐が必要なほど業務が複雑なときに取り出す道具です。AXの出発点は道具ではなく、業務の流れを自ら描けるドメイン知識です。