モデルを使う方法は一つではない

前の節では、LangChainを「モデルと情報・機能をつなぐ仕組み」と説明しました。この節では、その仕組みを使う理由を、ほかの選択肢と比べて整理します。まず「生成モデルを使うこと」と「LangChainを使うこと」を分けて考えます。

ライブラリは、再利用できるプログラムの部品をまとめたものです。モデル提供会社のAPIを扱いやすくする専用の部品集は、SDKと呼ばれます。提供会社のSDKからモデルを直接利用する方法も、LangChainを通して利用する方法もあります。LangChainは、異なるモデルや周辺の処理を共通の考え方で組み合わせるための選択肢です。

たとえば、決まったモデルに一種類の文章を渡して要約を得るだけなら、直接APIを使う小さな処理で十分なことがあります。LangChainを使うと部品の整理や拡張がしやすくなる一方、LangChain自体の概念や、組み合わせる部品も学ぶ必要があります。どのアプリケーションにも無条件に必要なもの、という位置づけではありません。

複数のモデルを比較したい、資料検索を組み込みたい、会話やツールを同じ枠組みで扱いたい、といった場面では、共通の部品が役立ちます。「モデルの生成能力を増やすため」ではなく、「モデルを使う処理を組み立て、変更しやすくするため」と理解すると、導入の理由が明確になります。

LangChainが共通化する範囲

モデル提供会社ごとに、接続方法や応答の形式、追加機能は異なります。LangChainはモデルの呼び出し方やメッセージの表現などをそろえ、アプリケーション側が同じ考え方で扱えるようにします。このような部品の使い方や情報の受け渡しの取り決めを、インターフェースと呼びます。入力は部品へ渡す情報、出力はその部品から受け取る結果です。

ただし、共通の呼び方があることと、すべてのモデルが同じ能力を持つことは別です。あるモデルで使えるツール呼び出しや構造化出力が、別のモデルでは同じように動かない場合があります。入力できる量、応答速度、料金、対応するデータ形式も変わります。モデルを差し替える際には、接続だけでなく、利用している機能と回答の品質も確認します。

共通化は、差異を消す魔法ではありません。共通部分をそろえることで、何が差し替え可能で、何が提供会社固有なのかを見分けやすくする仕組みです。

LangChain・LangGraph・LangSmithの違い

LangChainは、モデルに指示を渡し、資料やツールと組み合わせるための中心の部品を提供します。モデルに次のツールの選択を任せる構成は、エージェントと呼ばれます。今は「どの機能を使うかをモデルが選べる」と捉え、詳しい動きは第5章で学びます。

LangGraphは、「資料があれば回答し、足りなければ追加の確認へ進む」など、処理の手順や途中の情報を細かく管理するための関連フレームワークです。LangChainのエージェントを動かす土台にも使われています。最初はLangChainから利用でき、独自の複雑な手順が必要になった段階で、LangGraphを直接扱う選択肢があります。

LangSmithは、モデルを使った処理の記録を観察したり、テスト用データで品質を比較したりするための関連サービスです。何をモデルへ渡したか、どのツールを利用したか、どこで時間や費用がかかったかを調べる役割があります。LangChainを使うための必須契約ではなく、評価や運用の際に組み合わせられます。

名前この教材での捉え方
LangChainモデルと情報・ツールを組み合わせる中心の部品
LangGraph複雑な状態と実行経路を明示的に制御する仕組み
LangSmith処理を観察し、品質を評価・比較する仕組み

周辺技術は、必要になってから関連づける

検索に使う保存先や、外部の機能を接続する仕組みなど、周辺の技術もあります。まずは、何を解決するために必要になるかを理解してから、その名前を覚えれば十分です。LangChainで何かを作るために、関連する製品を一度にすべて用意する必要はありません。

周辺技術を先に大量に学ぶより、必要になる場面に沿って学びます。検索を扱う第4章では資料の保存・取得の部品を、ツールを扱う第5〜6章では外部の機能とのつなぎ方を説明します。まずは、この節のLangChain・LangGraph・LangSmithの三つの役割を押さえてください。

古い教材を読むときの注意

LangChainは更新が続いており、古い教材と現在の公式資料で、部品の名前や組み合わせ方が違うことがあります。バージョンは、ソフトウェアの版を示す番号です。本教材は、確認時点の1.x系の公式資料に沿って説明します。古い名前を最初から覚える必要はありません。

一方、指示を渡す、会話を入力に含める、関連資料を検索する、ツールの結果を受け取る、という考え方は、名前が変わっても理解の土台になります。最初はAPI名の暗記よりも、各部品の役割を理解することを優先します。次の章では、その土台になる生成APIの入出力を説明します。