アプリケーション全体の中にLangChainを置く

LangChainを使った処理は、アプリケーションの一部分です。利用者の質問を受け取り、認証や入力条件を確認し、必要なモデル処理を行い、結果を画面へ返す流れの中に組み込みます。Web画面やログインをLangChain自体がすべて提供するわけではありません。

社内規程の案内を例にすると、画面と利用者の認証、資料の管理、検索、モデルへの入力、生成、出典付きの表示、実行の記録という役割があります。このうちLangChainは、モデルや検索、ツールを組み合わせる処理を支えます。どこまでをLangChainで扱い、どこからを通常のアプリケーションで扱うかを分けると、構成を単純にできます。

同じ出張相談を、第1節からの流れで振り返ると、入力の構成は第4節、会話の継続は第7〜8節、規程の参照は第9〜12節に当たります。申請状況の照会まで選ばせるなら第13〜14節、人の確認を必ず挟むなら第15〜16節の仕組みを組み合わせます。すべてを使う必要はなく、必要な仕事から部品を選びます。

モデルに任せる部分を、小さく明確にする

確定した計算、本人の権限、資料の版、申請が登録済みかどうかは、可能な限り確定したデータや処理で確認します。質問の言い方を理解する、資料を読みやすい説明へ変える、必要な機能を選ぶ、といった部分にモデルを利用します。すべての判断を生成に置き換える必要はありません。

たとえば、規程に載っている金額の説明を自然な文章へすることと、支給可能な金額を確定することは別です。前者へモデルを利用する場合でも、後者の業務ルールは確定した処理へ置けます。LangChainは、生成と通常の処理を組み合わせるために利用できます。

変更できる場所と、確認すべき場所を明確にする

モデルを差し替えるときは、呼び出し方だけでなく、構造化出力やツール利用の対応、回答品質、時間、費用を確認します。検索を変更するときは、資料の版、Embeddingの互換性、候補の取得方法も影響します。共通のインターフェースがあることで変更箇所を分けやすくなりますが、評価を省略できるわけではありません。

LangChain本体、接続用の連携ライブラリ、LangGraphなどのバージョンも、動作の条件になります。更新時には、同じ評価データを使って、出力や経路が意図せず変わっていないかを比較します。古いサンプルにあるAPI名を、そのまま現在の組み合わせへ移すことは避けます。

失敗、上限、再試行の意味をそろえる

外部APIが一時的に応答しない、利用上限へ達する、資料が見つからない、必要な項目を抽出できない、といった状態は起こり得ます。それぞれ、再試行する、利用者へ不足を尋ねる、回答を保留するなど、適切な扱いが異なります。

fallbackは、主な処理が利用できないときに代わりの方法へ切り替える構成です。別のモデルへ切り替える場合も、そのモデルが必要なツールや出力形式に対応しているかを確認します。また、外部へ変更を加える操作を再試行する場合は、二重実行を防ぐ必要があります。単に「失敗したらもう一度」では不十分です。

実行の上限は、一回のモデル生成だけでなく、エージェント全体の回数や時間にも設定します。利用者には、回答できたのか、情報が不足したのか、上限や障害で止まったのかを区別して伝えます。

結果が期待と違う場合と、処理を実行できなかった場合も分けます。通信が成功していても、回答が資料と矛盾していれば品質の問題です。通信の障害なら再試行が有効な場合がありますが、根拠が資料に無い問題を同じ入力で繰り返しても、根拠が増えるわけではありません。第19節の記録と評価が、対応を選ぶ材料になります。

利用者へ提供し、継続して使えるようにする

作った処理を、利用者が使える場所で動かせるようにすることをデプロイと呼びます。LangChainの処理をWebサービスなどから呼び出し、結果を画面へ返す構成も作れます。LangChainを組み込むことと、サービスを動かす場所・利用者のログイン・保存先を用意することは、役割が異なります。

運用は、提供した後も状態や品質を確認し、資料や部品を更新しながら使える状態を保つことです。資料が改訂されたら検索対象を更新し、モデルやライブラリを変更したら同じ評価基準で比べます。利用者へ公開した後も、どの情報・どの版に基づいて答えたかを追えることが大切です。

情報と権限は、入力の前から管理する

秘密のキーやデータベース接続情報は、モデルへ渡すプロンプトに含めるものではありません。利用者が参照できない資料は、検索の候補やツールの結果としても渡さないようにします。外部の文書に書かれた指示で、アプリケーションの権限や実行方針が変わらない設計が必要です。

第7節の認証・認可の区別に戻ると、ログインした本人かを確かめた後で、その人が読める資料や実行できるツールの範囲を確認します。LangChainの生成処理へ情報を渡す前と、外部の操作を実行する前の両方で、その範囲を保つ必要があります。

LangChainにはmiddlewareを利用した検査や制御を組み込めますが、それだけで認証、認可、機密保護のすべてが完成するわけではありません。検索対象、ツール、状態の保存先、トレースの記録先まで含めて、情報の流れを考えます。

基本から応用までのつながり

LangChainの基本は、モデルへ何を渡し、どんな形で受け取るかです。会話は過去の情報を入力へつなぎ、RAGは検索した情報を入力へつなぎ、ツールは外部の機能へつなぎます。エージェントは、その利用を状況に応じて選ぶ構成です。LangGraphは状態と経路を制御し、LangSmithは観察と評価を支えます。

実装へ進む際は、まず一回のモデル呼び出しや固定したRAGなど、目的を満たす小さな構成から始められます。途中の判断が必要になればエージェントへ、独自の手順が必要になればLangGraphへと広げます。どの部品を増やすかを、名前の新しさではなく、解決したい問題から選べることが、このカリキュラムで目指す理解です。