AI開発会社から届いた提案書の技術構成欄に「LangChain」という文字を見つけて、そのまま読み流していないでしょうか。
求人票の応募要件に同じ単語が並んでいて、何を指しているのかわからないまま検索した人も多いはずです。
この2年でLLM（Large Language Model：大規模言語モデル）の業務活用が一気に実務へ降りてきました。
その結果、社内チャットボットや文書検索の提案にLangChainという単語が登場する場面が増えています。
背景の技術を知らないまま提案書の妥当性を判断するのは、非エンジニアにとって荷が重い作業です。
この記事では、業務自動化の構築で使っている判定基準をもとに、LangChainが何をする技術か、LangGraphとの関係、提案書や求人票でこの語を見たときに確認すべき点を整理しています。
LangChainとは何をするためのフレームワークか？
LangChainは、LLMを単体で使うだけでは足りない機能を補い、実用的なAIアプリケーションを組み立てるためのオープンソースのフレームワークです。
フレームワークとは、ゼロからプログラムを書く代わりに、あらかじめ用意された部品を組み合わせて開発を進めるための土台を指します。
LLM単体では、最新の社内情報を答えられない、会話の途中の内容をすぐ忘れる、複数の処理を自動で連携できないといった制約があります。
この制約を補う部品一式を用意しているのが、LangChainという位置づけです。
何ができるのか
LangChainが提供する機能は、大きく4つに分かれます。
- RAG（Retrieval-Augmented Generation：検索拡張生成）は、社内マニュアルやFAQといった外部データを検索してから回答を生成する仕組みです。
- メモリは、直前のやり取りだけでなく会話全体の文脈を保持し、チャットボットが同じ質問を繰り返さずに済むようにする機能です。
- チェーンは、要約してから翻訳する、検索してから整形するといった複数の処理を1つの流れとして連結します。
- エージェントは、LLMが状況に応じてWeb検索や社内システムの呼び出しといった複数のツールから必要なものを選び、実行する仕組みです。
たとえばRAGでは、就業規則のPDFを読み込ませておけば、社員からの『有給休暇は何日残っているか』という質問に、規則の該当箇所を踏まえて答えられるようになります。
RAGがどういう仕組みで外部データを検索してから回答しているのかは、次の記事で詳しく整理しています。
なぜLLM単体でなくLangChainが必要なのか
ChatGPTのようなLLMを単体でAPI経由で呼び出すだけでも、簡単な質問応答は作れます。
ただし、社内データとの連携や複数ステップの処理、会話の記憶を自前で実装しようとすると、データの検索方法や文脈の保持方法をすべて自社で設計する必要が出てきます。
LangChainは、こうした処理でよく使われる部品をあらかじめ用意しています。
そのため、社内チャットボットやドキュメント検索システムのように複数の機能を組み合わせるアプリケーションほど、導入効果が出やすいという特徴があります。
一方、決まった質問に決まった答えを返すだけのシンプルなFAQボットなら、LLMのAPIを直接呼び出すほうがかえって構成はシンプルです。
"LangChain is an open source framework with a pre-built agent architecture and integrations for any model or tool, so you can build agents that adapt as fast as the ecosystem evolves."
（訳）LangChainは、あらかじめ構築されたエージェントアーキテクチャと、あらゆるモデル・ツールとの連携機能を備えたオープンソースのフレームワークであり、エコシステムの進化に合わせて適応するエージェントを構築できる。
出典： LangChain公式サイト
前述の『よく使われる部品をあらかじめ用意している』という特徴を、公式サイト自身が最初に掲げていることがわかります。
LangChainとLangGraphはどう違うのか？
提案書や求人票では、LangChainと並んでLangGraphという語が出てくることがあります。
LangGraphはLangChainの上に構築された拡張フレームワークで、両者は対立関係になく、互いを補い合う関係にあります。
LangChainが得意とするのは、データ取得や要約のように処理の順序が決まった線形のワークフローです。
一方LangGraphは、条件分岐やループ、途中の状態を保持したまま処理を進める動的なワークフローに向いています。
LangChain（線形）とLangGraph（状態管理）の作り分け
LangChainは、チェーンという一方向にしか進まない処理の流れでワークフローを表現します。
質問を受け取り、関連文書を検索し、回答を生成するという一直線の流れであれば、LangChainだけで十分です。
LangGraphは、処理の単位であるノードと、ノード同士のつながりを表すエッジ、そして全体で共有される状態を使ってグラフを構築します。
この仕組みにより、一度出した回答をやり直す、複数のAIエージェントが協調して動く、人による承認を挟んでから処理を再開するといった、後戻りや分岐のあるワークフローを組めます。
両者の違いを整理すると、次のようになります。
| 項目 | LangChain | LangGraph |
|---|---|---|
| 処理の流れ | 線形（一方向に進む） | グラフ（分岐・ループが可能） |
| 得意な業務 | 検索して答える・要約して整形する | 承認待ち・条件分岐・複数エージェントの協調 |
| 状態管理 | 限定的 | 明示的で堅牢 |
どちらを使うべきかの判断基準
判断基準は、処理の途中で『前のステップに戻る』『人の判断を待つ』必要があるかどうかです。
社内マニュアルを検索して答えるだけのFAQボットや、文書を要約して整形するだけの定型処理であれば、LangChainの線形構成で足ります。
一方、問い合わせ内容によって対応する部署のエージェントを切り替える、承認が必要な処理で人の確認を待ってから次に進むといった業務があります。
このように条件で処理が分岐する業務は、LangGraphの導入を検討する対象になります。
提案書の技術構成にLangGraphの名前がなくても、業務内容が分岐や後戻りを含むなら、それだけで設計の見直しを求める理由になります。
提案書や求人票でLangChainと書かれていたら何を確認すべきか？
提案書や求人票にLangChainと書かれているとき、非エンジニアが技術の中身を評価する必要はありません。
確認すべきは、その技術が自社の業務内容に対して妥当な選び方をされているかどうかです。
LangChainを解説する記事の多くは機能の説明で終わり、外注や採用の判断に使える確認ポイントまでは踏み込んでいません。
ここでは、提案書を読む側が具体的に何を尋ねればよいかを3点に絞って整理します。
確認① 何の機能を使っているか
最初に確認すべきは、RAG（外部データを検索してから答える）とエージェント（自律的にツールを選んで実行する）のどちらを指しているかです。
社内マニュアルの検索チャットボットであればRAGが中心のはずで、複数システムを横断する自動化であればエージェントが中心のはずです。
提案書の説明が『AIが自動でやります』のような曖昧な表現にとどまっている場合は、どの機能を使うのか具体的な説明を求めます。
尋ね方は『この構成はRAG中心ですか、エージェント中心ですか』とそのまま聞けば足ります。
というのも、RAG中心なら参照データの整備が、エージェント中心なら誤操作が起きたときの影響範囲の確認が、それぞれ導入前に詰めるべき論点になるからです。
この質問への回答が要領を得ない場合は、外注先自身が構成を整理できていない可能性も含めて、提案の成熟度を測る材料になります。
エージェントがツールを選んで実行する仕組みそのものは、次の記事で整理しています。
確認② LangGraphが必要な複雑さか
次に確認すべきは、業務フローの中に分岐や後戻りがあるかどうかです。
承認待ちや条件分岐がある業務にLangChainの線形構成だけで対応しようとしていると、想定外のパターンが発生したときに処理が破綻しやすくなります。
逆に、単純な検索応答にLangGraphのような複雑な仕組みを持ち出している場合は、必要以上に工数と運用コストがかかっている可能性があります。
判断に使うのは、対象業務の流れを書き出したときに『上長の承認を待つ』『金額によって担当者を変える』のような分岐が入るかどうかという単純な目安です。
分岐があるのに提案書がLangChainのみで構成されている場合は、分岐や後戻りの処理をどう実装するのかを確認し、回答にLangGraphや同等の状態管理の説明が出てくるかを見ます。
確認③ 保守・運用コストの考え方
LangChainは開発が活発なフレームワークで、機能追加やAPIの仕様変更が高い頻度で行われています。
バージョンアップのたびに動作確認や修正が必要になるため、導入後の保守を誰がどのくらいの頻度で行うのかを、契約時点で確認しておく必要があります。
確認すべきは初期構築費用だけでなく、バージョンアップ対応や監視にかかる運用工数です。
具体的には、バージョンアップ対応の費用が月額保守に含まれるのか都度見積もりなのか、障害が起きたときの対応窓口と体制はどうなっているのか、の2点を契約前に文面で確認します。
ここが提案書に書かれていない場合は、追加で質問する価値があります。
こうした運用・保守の考え方は、LLMOpsという枠組みで整理されています。
判断に迷う場合は、 個別相談 で提案書の内容を一緒に整理することもできます。
LangChainが向く場面・向かない場面は？
LangChainが向くかどうかを分けるのは、業務の種類そのものより、外部データや複数ステップの処理を組み合わせる必要があるかどうかです。
単発の質問応答であればLLM単体で十分なことが多く、社内情報を踏まえた回答や複数の処理を連携させる場面でLangChainの効果が出やすくなります。
以下では、向く場面と向かない場面を具体例で整理します。
向く場面（具体例）
向く場面の代表例は、社内の問い合わせに答えるFAQチャットボットです。
次のケースは実在の案件ではなく、規模感を伝えるための想定例です。
従業員160名規模の不動産管理会社で、就業規則や経費精算のルールをまとめた社内文書をRAGの仕組みで検索させ、問い合わせ対応の一次窓口として使う構成を想定してみます。
このように、社内文書という外部データを参照しながら回答する用途は、LangChainの機能がそのまま活きる典型例です。
実際にこの種の構成を動かしたところ、参照データの整備状況によって回答の精度が大きく変わることも確認できています。
社内文書の更新が止まっていたり、部署によって表記ルールがばらばらだったりすると、いくら仕組みを整えても回答の質は上がりません。
このため、LangChainの導入検討と同時に、参照元データの整備担当を誰にするかも決めておく必要があります。
向かない場面（向かない条件）
向かない場面は、参照する外部データがなく、決まった質問に決まった答えを返すだけのシンプルなボットです。
この場合はLLMのAPIをそのまま呼び出すほうが構成をシンプルに保て、依存関係や運用コストを抑えられます。
また、社内に保守を担当するエンジニアがおらず、外注先が撤退した後に誰も面倒を見られない体制の場合も、頻繁なアップデート対応が前提になるLangChainの構成は向きません。
提案書のLangChainという表記だけで判断に迷っていませんか
「何の機能を使っているのか説明を受けても理解できない」「LangGraphとの違いを聞かれて答えられない」「保守費用の妥当性がわからない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、AI業務自動化に関するお悩みをお伺いする 無料の個別相談 を実施しています。
よくある質問
Q. LangChainは無料で使えますか？
LangChain自体はオープンソースのため無料で利用できます。
ただし、内部で呼び出すLLM（ChatGPTやClaudeなど）のAPI利用料は別途発生します。
提案書の見積もりに、LangChainのライセンス費用ではなくLLMのAPI利用料が含まれているかを確認します。
Q. LangChainを使うのにプログラミングの知識は必要ですか？
必要です。
LangChainはPythonまたはTypeScriptで利用するフレームワークで、開発にはプログラミングの知識が前提になります。
非エンジニアが直接コードを書いて操作することは想定されておらず、外注またはエンジニア採用が基本の使い方です。
Q. 提案書にLangChainではなくDifyやMakeと書かれていた場合はどう考えればいいですか？
DifyやMakeは、コードを書かずにLLMアプリケーションを組み立てられるノーコード・ローコードのツールで、LangChainとはカテゴリが異なります。
LangChainは開発者向けのフレームワーク、DifyやMakeは非エンジニアでも扱える構築ツールという位置づけの違いがあります。
どちらが適切かは、社内に保守できるエンジニアがいるかどうかで判断します。
Q. LangGraphに移行すると費用は増えますか？
案件ごとの複雑さによって変わるため、一律には言えません。
分岐や後戻りが多い業務ほど設計・実装の工数が増える傾向はありますが、金額は個別の見積もりで確認する必要があります。
提案書に移行の要否が書かれていない場合は、その判断根拠を尋ねます。
Q. 社内にエンジニアがいない場合、LangChainベースの提案は避けるべきですか？
避けるべきとは限りませんが、保守体制の確認が前提になります。
外注先が継続的な保守契約を提供しているか、バージョンアップ時の対応窓口があるかを事前に確認します。
保守体制が明確でない場合は、運用コストが低いシンプルな構成への変更を提案してもらう選択肢もあります。
