LangChainとは？できること・使い方・実践例をエンジニア目線で解説
LangChainとは何か——ざっくり言うと「LLMアプリの接着剤」
LangChain、名前だけは聞いたことあるけど結局何なの？という人が多いと思います。
一言で言えば、LLM（大規模言語モデル）を使ったアプリケーションを効率的に作るためのフレームワークです。Pythonが最もメジャーですが、TypeScript/JavaScript版もあります。
「え、OpenAIのAPI直接叩けばいいんじゃないの？」と思うかもしれません。確かに、単純なチャットボットならAPI直叩きで十分です。でも実際のプロダクトでは、外部データを検索して回答に含めたい、複数のステップを連続実行したい、会話の履歴を管理したい……といった要件が次々出てきます。
これを毎回ゼロから実装するのは正直しんどい。LangChainはそういう「よくあるパターン」をモジュール化してくれるライブラリです。
Harrison Chaseが2022年にオープンソースで公開して以来、GitHubスター数は2026年3月時点で10万超え。LLMアプリ開発のデファクトスタンダードと言っても差し支えない存在になりました。
LangChainのコアコンセプト——まず4つ押さえればOK
1. Chain（チェーン）：処理を数珠つなぎにする仕組み
LangChainの名前の由来でもある中核概念です。「プロンプトを組み立てる → LLMに送る → 結果をパースする」みたいな一連の処理をChainとしてまとめられます。
最近のLangChainではLCEL（LangChain Expression Language）という書き方が推奨されていて、パイプ演算子（ | ）でChainを直感的に組めます。うちのチームでも最初は従来のChain記法で書いていたんですが、LCELに切り替えてからコードの見通しが格段に良くなりました。
2. Agent（エージェント）：AIが自律的にツールを使う
Agentは「LLMが自分で判断してツールを選んで実行する」仕組みです。例えば「東京の天気を調べてからそれに合った服装を提案して」と頼むと、まず天気APIを叩いて、その結果をもとに回答を組み立てる——みたいなことを自動でやってくれます。
LangChainのAgent実装はReActパターン（Reasoning + Acting）がベースで、「考える → 行動する → 観察する → また考える」のループを回します。
ただし正直に言うと、Agent は万能じゃない。複雑なタスクだと途中で脱線することがあります。うちでは本番運用するときは、ステップ数に上限を設けたり、各ステップの出力をログに残してモニタリングする仕組みを必ず入れています。
3. Memory（メモリ）：会話の文脈を保持する
チャットアプリを作るとき必須になるのがMemory。LangChainにはいくつかのMemory実装があります：
- ConversationBufferMemory：会話をそのまま全部保持。シンプルだけどトークン消費が大きい
- ConversationSummaryMemory：会話をLLMで要約しながら保持。長い会話に向いている
- ConversationBufferWindowMemory：直近N回のやり取りだけ保持。コスパ重視ならこれ
クライアントさんの社内チャットボット案件では、ConversationSummaryMemoryを採用しました。1回の会話が長くなりがちな業務系だと、全履歴を保持するとトークン上限にすぐ引っかかるんですよね。
4. Retriever（リトリーバー）：外部データを検索してLLMに渡す
RAG（Retrieval-Augmented Generation）の「R」の部分を担当するコンポーネントです。社内ドキュメントやFAQをベクトルDBに入れておいて、ユーザーの質問に関連する情報だけを取り出してLLMに渡す——という流れの「取り出す」部分です。
対応しているベクトルDBが本当に多くて、Pinecone、Weaviate、Chroma、FAISS、pgvector……ざっと20以上。プロジェクトの規模に合わせて選べるのがありがたいです。
LangChainで実際に何が作れるのか——具体例3つ
実践例1：社内ドキュメント検索RAGシステム
うちが一番よく受ける案件がこれです。社内のマニュアルやナレッジベースをRAGで検索可能にするシステム。
構成としてはこんな感じ：
とあるメーカーさんの事例では、社内規定のPDF約300ファイルをRAG化したところ、問い合わせ対応時間が平均12分から2分に短縮されました。
ハマりポイント：チャンクの分割サイズが適切じゃないと回答精度がガクッと落ちます。最初は1000トークンで始めて、実際のQ&Aを見ながら調整するのがおすすめ。
実践例2：営業支援AIエージェント
LangChainのAgent機能を使って、営業チーム向けのリサーチアシスタントを作ったケースです。
企業名を入力すると、以下を自動で実行します：
- 企業の公式サイトをスクレイピングして事業概要を取得
- 直近のニュースリリースを検索
- 業界レポートのDBから関連データを引っ張る
- 上記を統合して1ページの企業概要レポートを生成
所要時間は従来の手作業で60〜90分だったのが、約8分で完了するようになりました。営業担当4名のチームで月あたり約40時間の工数削減です。
実践例3：カスタマーサポートの自動応答システム
FAQベースの単純なボットではなく、注文状況の確認やキャンセル処理まで自動化したシステムです。
LangChainのToolsとして以下を定義しました：
- 注文DB検索ツール
- 在庫確認ツール
- キャンセル処理ツール（金額上限付き）
- エスカレーションツール（人間のオペレータに引き継ぐ）
結果として、全問い合わせの約72%をAIが一次対応完了。ただし「完全自動化」は目指さず、判断が必要なケースは素直にエスカレーションさせる設計にしたのがポイントです。AIが無理に対応しようとして顧客体験を損ねるのが一番まずい。
LangChain vs 他のフレームワーク——正直な比較
LangChain vs LlamaIndex
LlamaIndexはRAGに特化したフレームワークです。「とにかくRAGだけ作りたい」ならLlamaIndexのほうがシンプルに書けることが多い。一方で、Agentやツール連携を含む複雑なアプリを作るならLangChainのほうが柔軟です。
うちでは「RAGメインの案件ならLlamaIndex、それ以外はLangChain」と使い分けています。
LangChain vs Semantic Kernel
Microsoft製のフレームワークで、Azure OpenAI Serviceとの親和性が高い。C#やJavaでの開発が主力の企業ならSemantic Kernelのほうがフィットする場合があります。ただしコミュニティの規模はLangChainが圧倒的に大きいので、情報量やプラグインの充実度ではLangChainに軍配が上がります。
LangChain vs 素のAPI直叩き
「LangChain重すぎない？」という声は正直あります。抽象化レイヤーが多い分、学習コストは発生するし、ライブラリのアップデートが頻繁で破壊的変更も少なくない。
判断基準としては：
- プロトタイプや検証：LangChain推奨。爆速で動くものが作れる
- シンプルなチャットbot：API直叩きで十分
- 本番プロダクト（複雑）：LangChain or LangGraph（LangChainの上位フレームワーク）
LangChainの始め方——最短ルート
Step 1：インストール
Python環境があればpipで一発です：
pip install langchain langchain-openai
OpenAI以外のモデル（Claude、Geminiなど）を使う場合は、対応するパッケージも入れます：
pip install langchain-anthropic（Claude用） pip install langchain-google-genai（Gemini用）
Step 2：最初のChainを作る
まずは一番シンプルなChainから始めましょう。プロンプトテンプレートとLLMを組み合わせるだけです。ChatPromptTemplateでテンプレートを作り、ChatOpenAI()でモデルを指定して、LCELのパイプ（ | ）でつなぐ。出力パーサーを末尾に付ければ、レスポンスの文字列だけ取り出せます。
Step 3：RAGを追加する
テキストファイルやPDFを読み込んで、ベクトルDBに入れて、検索Chainと組み合わせる——この流れが鉄板です。最初はChromaDB（ローカルで動くベクトルDB）で試すのがラクです。
Step 4：Agentに挑戦する
基本的なChainとRAGが動いたら、次はAgent。create_tool_calling_agent関数を使えば、ツール定義を渡すだけでReActエージェントが動きます。
LangChainを使うべきケース・使わないほうがいいケース
使うべき：
- RAGシステムを作る（最も得意領域）
- 複数のLLMやツールを組み合わせるアプリ
- プロトタイプを素早く作りたい
- チームに Python エンジニアがいる
使わないほうがいい：
- 「Hello World」レベルの単純なチャットbot（大げさすぎる）
- リアルタイム性が極めて重要なシステム（抽象化レイヤーのオーバーヘッドが気になる場合）
- フレームワークに依存したくない長期プロジェクト（APIの破壊的変更リスク）
まとめ
LangChainは「LLMアプリを作るときの標準ツールキット」として、2026年の今も確固たるポジションにあります。完璧なフレームワークではないし、学習コストもそれなりにかかりますが、一度覚えれば開発スピードが段違いに上がるのは間違いない。
うちでも受託開発の約7割でLangChainを使っていますが、案件によってはLlamaIndexやAPI直叩きも普通に使います。大事なのは「何を作りたいか」から逆算して技術を選ぶこと。フレームワークに振り回されず、目的に合ったものを選びましょう。
Written by
Swaaab編集部
広島を拠点に、AI開発・DX支援・Web制作を手がけるSwaaab株式会社の編集チーム。現場で得た知見をもとに、実践的な情報を発信しています。