LangChainとは何か・特定のモデルに縛られない「共通の型」という発想

Hugging Faceの記事では「モデルを作る会社」と「モデルの置き場所を提供する会社」の違いを見てきましたが、LangChainはさらに別の軸の存在です。ここまで見てきたGitHub Copilot・Cursor・Ollama・OpenAI API・Hugging Faceは、どれも「モデルそのもの」か「モデルを動かす場所」の話でした。LangChainはそのどちらでもなく、どのモデルを使うにしても共通の書き方で組み立てられるようにする、オープンソースのライブラリです。この「モデルの外側にある土台」という立ち位置を知らないと、LangChain自体が何かを考えて答えを返していると誤解してしまいます。

LangChain自身は何も答えを生成していない

「LangChain」という名前だけを見ると、OpenAIやAnthropicと同じようにAIモデルを開発している会社だと思うかもしれませんが、実態は違います。LangChainは2022年10月24日、Harrison Chase氏によって公開された、わずか800行ほどのPythonパッケージから始まったオープンソースのライブラリです。ChatGPTが世に出るより1か月ほど早いタイミングでの公開でした。LangChain自身は文章を生成する機能を持たず、実際に応答を作っているのはOpenAI API・Anthropic・Ollamaで動かしているモデルなど、外部のモデルです。LangChainの役割は、プロンプトの組み立て・複数ステップの連結・出力の後処理といった「配線」を、どのモデルを使っても同じ書き方でできるようにする点にあります。

# init_chat_modelを使うと、モデルを文字列だけで差し替えられる
from langchain.chat_models import init_chat_model

# provider名とmodel名を変えるだけで、呼び出し側のコードは変えずに済む
model = init_chat_model("gpt-4.1", model_provider="openai")
# model = init_chat_model("claude-sonnet-4", model_provider="anthropic")  # ← 差し替え例

response = model.invoke("配列の合計を求める関数をPythonで書いて")
print(response.content)
🎯 読み解きポイント:自分では戦わず、依頼内容を見て適任の傭兵に取り次ぐギルドの受付

ハクスラゲームのギルド受付でたとえると、LangChainは受付そのものです。受付自身は戦闘に参加せず、プレイヤーが出した依頼書(プロンプト)を見て、今契約している傭兵(OpenAIのモデルやAnthropicのモデルなど)の中から取り次ぐ相手を選びます。傭兵を別の傭兵に乗り換えたいときも、受付に出す依頼書の書式(呼び出し方)は変わりません。実際に依頼をこなすのは常に傭兵側で、受付は取り次ぎに徹しているという役割分担が、LangChainとモデルの関係そのものです。

LangChain 共通の呼び出し方(取次窓口) OpenAI API Anthropic Ollama(ローカル) 実際に応答を生成するのは常にモデル側。LangChainは取り次ぐだけ

複雑なエージェントの制御は、姉妹プロジェクトのLangGraphに役割が移った

チェーンを連結するだけの初期のLangChainのイメージのまま、「自律的に何度もツールを呼び出すエージェントも、当然LangChain単体の仕組みで作るものだろう」と思うかもしれませんが、2025年時点でこの前提は更新されています。ループや条件分岐、失敗時のやり直しを伴う複雑なエージェントの制御は、姉妹プロジェクトのLangGraphが担う設計へと役割分担が進みました。LangGraphはグラフ(状態遷移図)としてエージェントの流れを組み立てる仕組みで、処理の途中でサーバーが再起動しても状態を失わずに再開できる永続実行や、要所で人間の承認を待ってから先へ進める仕組みを標準で備えています。2025年10月にはLangChain・LangGraphの双方が揃って1.0の正式版に到達し、LangChain自身のエージェント機能もLangGraphのランタイムを土台に組み直されました。

# LangGraphによるエージェント制御のイメージ(状態を持った分岐フロー)
状態: { 質問, これまでの調査結果 }

ノード「調べる」 → ツールを実行 → 結果を状態に追加
   ↓
判定「情報は十分か?」
   ├─ 不十分 → もう一度「調べる」ノードへ戻る(ループ)
   └─ 十分   → ノード「人間の承認を待つ」で一時停止
                  ↓ (承認)
              ノード「最終回答をまとめる」
🎯 読み解きポイント:オートセーブ付きで分岐する討伐依頼と、要所にあるギルドマスターの承認関門

LangGraphが扱うエージェントの流れは、オートセーブ機能付きで枝分かれする討伐依頼のクエストに近い感覚です。調査を進める途中で通信が切れても、直前のセーブポイント(状態)から再開でき、最初からやり直しにはなりません。さらに要所には「ここから先はギルドマスターの承認が要る」という関門が用意されていて、重要な判断を勝手に進めさせず、人間が確認してから次のノードへ進める仕組みになっています。単純に一本道を進むだけだった頃のチェーンに比べ、枝分かれと再開性、承認の関門が加わったのがLangGraphの立ち位置です。

よくあるはまりポイント:1回きりの単純な呼び出しにまでLangChainを持ち込んで、逆に手間が増える

複数ステップの連結やモデルの差し替えに強いLangChainを導入すれば、どんな規模のタスクでも見通しが良くなるはずだと思うかもしれませんが、実務者の間では逆の声も多く上がっています。単純に1回APIを呼んで結果を受け取るだけのタスクにまでLangChainの各種クラスを持ち込むと、「些細な変更を1つ加えるだけなのに、5層の抽象化を経由しないとたどり着けない」といった不満につながりやすく、エラーが起きたときもLangChain内部のコードを指すメッセージが表示され、本当の原因までたどり着きにくくなります。LangChainが本来解決したいのは「複数のモデルを差し替えたい」「複数ステップを連結したい」「エージェント的なループを組みたい」といった課題であり、そこに直面する前から先回りして導入すると、単純なタスクの上に不要な抽象化の層を積み上げることになります。

あわせて知っておきたい用語
チェーン(Chain)
プロンプトの組み立て・モデル呼び出し・出力の後処理など、複数の処理ステップをひとつなぎにしたもの。LangChainの名前の由来
LangGraph
ループ・分岐・永続実行・人間の承認を伴う複雑なエージェント制御を担う姉妹プロジェクト。2025年10月にLangChainと共に1.0に到達
init_chat_model
provider名とmodel名を文字列で指定するだけで、呼び出し側のコードを変えずにモデルを差し替えられる共通の初期化関数
💡 ワンポイントアドバイス:まず素のAPI呼び出しで組み、必要になってからLangChainを足す

新しく何かを作り始めるときは、最初から複数ステップの連結やモデルの差し替えを見込んでLangChainを導入するのではなく、まず対象のAPIを直接呼び出す形で小さく組んでみてください。実際に「モデルを差し替えたくなった」「処理を複数ステップに分けたくなった」という場面に直面してから導入する方が、不要な抽象化の層を抱え込まずに済みます。

モデルの外側にある「つなぐための土台」という立ち位置が掴めたら、他のAIコーディングツールとも見比べてみると理解が深まります。(シリーズ一覧・GitHub Copilot・Cursor・Ollama・OpenAI API・Hugging Face・Anthropic API・Zed・Devin・Gemini CLI)