LangChainとは？
v1.0で何が変わったか・使い方・
RAG実装まで完全解説【2026年】
LangChainは2025年10月22日にv1.0が正式リリースされ、それ以前の解説記事・チュートリアルの大半が使えなくなった。主役だった
Chainやcreate_react_agentはcreate_agentに統合され、新たにミドルウェア機構が入った。この記事では「v0.x時代の情報」と「v1.0以降」を明確に切り分けたうえで、基本概念・RAG実装・LangGraphとの使い分けまでを解説する。
1. 結論——今から学ぶなら何を押さえるべきか
先に3行でまとめる。
Chainからcreate_agentへ。ネット上のv0.x時代のコードはそのままでは動かないものが多い2. LangChainとは何か——3層エコシステムで理解する
LangChain（ラングチェーン）は、大規模言語モデル（LLM）を使ったアプリケーション開発のためのオープンソースフレームワークだ。PythonとTypeScriptの両方に対応している。
単体で理解しようとすると混乱しやすいので、まず3つのレイヤーで全体像を掴むのが近道だ。
LangChain
モデル・プロンプト・検索・ツールを共通インターフェースで扱う。エージェントを組み立てる部分を担う
LangGraph
複雑なワークフローをグラフ構造で表現・実行・管理する。条件分岐やループ、人間の承認を挟む処理はここ
LangSmith
エージェントの動作を監視し、性能を評価する商用プラットフォーム。本番運用の可観測性を担う
何を解決するフレームワークなのか
LLMを使ったアプリを素で書くと、次のような面倒が発生する。
- OpenAI・Anthropic・Googleでそれぞれ API の書き方が違う
- モデルを乗り換えるたびにコードを書き直す必要がある
- PDFやWebページを読み込んで検索可能にする処理を毎回自作する
- ツール呼び出し（Function Calling）のループ処理を毎回書く
LangChainはこれらを共通の部品として提供する。モデルを1行変えるだけでOpenAIからAnthropicに乗り換えられる、というのが分かりやすいメリットだ。
用途に応じたモデルの選び方はAIモデルの使い分け方｜タスク別おすすめLLM、API料金を抑える考え方はAIコスト最適化完全ガイド｜企業のAI利用料削減方法と事例で整理している。
3. 【重要】v1.0で何が変わったか
2025年10月22日、LangChainとLangGraphが揃ってバージョン1.0として正式公開された。ここが学習コストを大きく左右するポイントなので、詳しく扱う。
変更点①：create_agentへの統合
v0.x時代、エージェントを作る手段は複数あり、しかも一部はLangGraph側のcreate_react_agentを使う必要があった。v1.0ではこれらがlangchain.agents.create_agentに統合されている。
from langchain.agents import create_agent
agent = create_agent(
model=”anthropic:claude-sonnet-4-5″,
tools=[search_tool, calculator_tool],
prompt=”あなたは丁寧なリサーチアシスタントです。”,
)
result = agent.invoke({“messages”: [{“role”: “user”, “content”: “調べたい内容”}]})
モデル・ツール・プロンプトを渡すだけで、内部のエージェントループ（モデル呼び出し→ツール実行の繰り返し）は自動管理される。v0.xで必要だったループ処理の記述が不要になった。
変更点②：ミドルウェア機構の追加
v1.0の目玉がこれだ。実行の各段階にフックを挟めるようになった。具体的には次のような処理を差し込める。
- ツール実行の前に人間の承認を挟む
- モデルに渡す前に個人情報を自動マスクする
- 実行前後にログ・監査記録を残す
- 特定条件でリトライ・フォールバックする
変更点③：旧APIの分離
v0.x時代のクラス群の多くは@langchain/classic（Pythonではlangchain-classic）へ移された。importパスの変更が必要になるため、既存プロジェクトの移行では公式の移行ガイドを必ず参照してほしい。
| 項目 | v0.x | v1.0以降 |
|---|---|---|
| エージェント構築 | 複数の方法が混在（create_react_agent等） | create_agentに統合 |
| カスタマイズ | コールバック等で個別対応 | ミドルウェア機構で標準化 |
| 旧クラス群 | langchain本体に同梱 | langchain-classic に分離 |
| LangGraphとの関係 | 機能が一部重複 | 構築＝LangChain／実行＝LangGraph に整理 |
4. 基本概念——押さえるべき5つ
① Model（モデル）
OpenAI・Anthropic・Googleなど各社のLLMを共通のインターフェースで呼び出す層。model="anthropic:claude-sonnet-4-5"のように文字列で指定でき、乗り換えが容易。ローカルLLMを使う場合はローカルLLMの始め方｜LM StudioでQwen3.6/GLM/Gemma 4を動かすも参考にしてほしい。
② Prompt（プロンプト）
テンプレート化した指示文。変数を埋め込んで動的に組み立てられる。同じプロンプトを複数箇所で再利用できる。
③ Tool（ツール）
LLMが呼び出せる外部関数。Web検索・データベース照会・APIコールなどを定義しておくと、モデルが必要に応じて自律的に呼ぶ。MCPサーバーをツールとして接続することも可能で、この仕組みはGitHub MCPとは？できることやMCPサーバーの導入・使い方で解説している考え方と地続きだ。
④ Retriever（検索器）
ベクトルストアから関連文書を取得する部品。RAG（検索拡張生成）の中核になる。
⑤ Middleware（ミドルウェア）
v1.0の新概念。実行の各段階に処理を差し込む。人間承認・PIIマスキング・ログ記録などをここで実装する。
5. インストールと最小構成
pip install langchain langchain-anthropic
# 環境変数にAPIキーを設定
export ANTHROPIC_API_KEY=”your-api-key”
最小の動作確認は次の通り。
model = init_chat_model(“anthropic:claude-sonnet-4-5”)
response = model.invoke(“LangChainを一言で説明してください”)
print(response.content)
6. RAGを実装する——最小コード
LangChainが最も使われている用途がRAG（Retrieval-Augmented Generation／検索拡張生成）だ。社内文書をLLMに参照させて回答させる仕組みで、社内ヘルプデスクやFAQ自動応答の基盤になる。
RAGの処理フロー
実装コード
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_anthropic import ChatAnthropic
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
# 1. 読み込み
docs = PyPDFLoader(“company_handbook.pdf”).load()
# 2. 分割（チャンクサイズと重なりが精度を左右する）
splitter = RecursiveCharacterTextSplitter(
chunk_size=800,
chunk_overlap=100,
)
chunks = splitter.split_documents(docs)
# 3. ベクトル化して保存
vectorstore = FAISS.from_documents(chunks, OpenAIEmbeddings())
retriever = vectorstore.as_retriever(search_kwargs={“k”: 4})
# 4-5. 検索して回答生成
model = ChatAnthropic(model=”claude-sonnet-4-5″)
def answer(question: str) -> str:
found = retriever.invoke(question)
context = “\n\n”.join(d.page_content for d in found)
prompt = f”””以下の資料のみを根拠に、質問に答えてください。
資料に記載がない場合は「資料に記載がありません」と答えてください。
【資料】
{context}
【質問】
{question}”””
return model.invoke(prompt).content
print(answer(“有給休暇の申請手順を教えてください”))
チャンク設計のコツ
| 設定 | 目安 | 効果 |
|---|---|---|
| chunk_size | 500〜1000文字 | 小さすぎると文脈が切れ、大きすぎるとノイズが増える |
| chunk_overlap | chunk_sizeの10〜20% | チャンク境界で文意が途切れるのを防ぐ |
| 検索件数（k） | 3〜5件 | 多すぎるとコンテキストが膨らみコストが増える |
7. ミドルウェアで実運用に耐える設計にする
ここがv1.0で最も実務価値の高い部分だ。PoC（試作）と本番運用を分けるのは、たいてい「止める仕組み」があるかどうかで決まる。
ユースケース①：ツール実行前に人間の承認を挟む
メール送信・DB更新・外部への発注など、取り返しがつかない操作はAIに単独で実行させるべきではない。ミドルウェアでツール実行前にフックを設け、承認を待つ設計にする。
ユースケース②：個人情報のマスキング
ユーザー入力に氏名・電話番号・メールアドレスが含まれる場合、モデルに渡す前に自動でマスクする。外部APIに機密が流出するリスクをアプリ層で構造的に防げる。この論点はObsidianの中身、Claudeの学習に使われる？情報漏洩リスクを徹底検証とも通じる。
ユースケース③：監査ログの記録
「いつ・誰の指示で・AIが何を実行したか」を残す。規制業界での導入や、社内監査への対応で必須になる。
8. LangChainを使うべきケース・使わないべきケース
- 複数のLLMプロバイダを切り替える可能性がある
- 社内文書を使ったRAGを自社で構築したい
- ツール呼び出しを含むエージェントを作る
- 人間承認・PIIマスキングを組み込む必要がある
- PythonまたはTypeScriptで開発するチームがある
- 処理内容を完全に自社でコントロールしたい
- 単純なチャットボット1本だけ（APIを直接叩くほうが速い）
- 社内にPython/TSを書ける人がいない
- ノーコードで完結させたい（Difyなどが適切）
- 学習コストをかけずに今週中に出したい
- 条件分岐やループが複雑（LangGraph単体を検討すべき）
⚠️ 「とりあえずLangChain」は失敗しやすい
OpenAI APIを1回叩くだけの処理にLangChainを挟むと、抽象化のレイヤーが増えてデバッグが難しくなるだけだ。LangChainが効くのは「複数のモデル・複数のツール・複数のステップ」が絡む場合に限られる。要件がシンプルなら、素のAPI呼び出しのほうが保守しやすい。
ノーコードで済ませたい場合の代替
コードを書かずにRAGやエージェントを構築したい場合は、Difyのようなノーコード基盤が現実的だ。詳しくはDifyとは？使い方・料金・導入方法を解説、業務システムとの連携中心ならZapierとは？使い方・料金・自動化の始め方も選択肢になる。
9. 料金——OSSは無料、有料なのはどこか
| 対象 | 料金 | 備考 |
|---|---|---|
| LangChain（OSS） | 無料 | MITライセンス系のOSS。ライブラリ自体に費用はかからない |
| LangGraph（OSS） | 無料 | 同上 |
| LLM API利用料 | 従量課金 | 実際のコストの大半はここ。OpenAI・Anthropic等への支払い |
| LangSmith Developer | 無料 | 個人・小規模の可観測性プラットフォーム |
| LangSmith Plus | $39/月〜 | チーム利用向け |
| LangSmith Enterprise | カスタム | 大規模組織向け |
10. よくある質問
LangChainでのRAG構築は、コードを書くこと自体より「どの業務に適用するか」「どこで人間が止めるか」の設計で成否が分かれます。技術選定からミドルウェアを含む運用設計まで、LIFRELLのAIマーケティング相談をご活用ください。各種AI・SaaSツールを実際に有料契約して検証している立場から、現場目線でサポートします。
社内での生成AI定着から着手したい場合は生成AIeラーニング研修おすすめ完全ガイドもご覧ください。
