「AIエンジニアがLangChainを推奨しない理由」への反駁

はじめに

最近LangChainエージェント開発講義という書籍を翔泳社より出しましたが執筆校閲完了後にメジャーバージョンアップがあり読者の方が苦労をされており、その対応に追われています。この場を借りてご不便をお詫びいたします。最新でどうなるのかなど今後改訂できればと思います。そんな最中、更に追い打ちをかけるようにLangChain批判の記事がバズっており、本をせっかく手に取ってくださった読者の方が悲しむであろうと思い、本記事を書きます。批判記事を書いた方へは特に何の恨みもありませんし、深く技術理解されており素晴らしいと思います。 実際、LangChainへの批判記事は丁寧にソースコードを読み込んでおり、技術的な誠実さがあります。しかし、いくつかの点で事実誤認、文脈の欠落、そして比較の不公平さがあり、読んだ方のLangChainへの不当な低評価につなかまることも予想されます。本稿ではそれらを指摘します。

1. 「773行のラッパー」という数字のミスリード

事実の確認

記事は「5行→3行の短縮のために773行のラッパー」と主張しています。しかし、この773行の内訳を記事自身が示しています：

反論

ドキュメントとdocstringを「ラッパーの重さ」としてカウントするのは不公平です。

OpenAI SDKのopenai/resources/embeddings.pyも同様に詳細なdocstringと型定義を含んでいます。これは良いライブラリの証拠であり、批判対象ではありません。

また、length-safe embedding機能は実際に本番環境で価値があります：

• OpenAIのembedding APIには8,191トークンの制限がある
• ユーザーがチャンク済みのテキストを渡しても、稀に制限を超えることがある
• LangChainはこれを自動的にハンドリングし、サイレントに失敗することを防ぐ

記事は「チャンク済みなら不要」と主張していますが、エッジケースでの安全性を提供しているのです。

2. 「30個のパラメータ vs 12個」の比較の不公平さ

事実の確認

記事はLangChainの30パラメータとOpenAI SDKの12パラメータを比較しています。

反論

この比較は不公平です。なぜなら：

1. Azure OpenAI対応パラメータ（openai_api_version, openai_api_type, deployment）
2. OpenAI SDKでAzure OpenAIを使う場合、openai.AzureOpenAIという別クラスを使う必要がある

3. LangChainは1つのクラスで両方対応している

4. tiktoken関連パラメータ

5. これはlength-safe機能のためのオプション
6. 使わないならデフォルトのまま触らなくてよい

実際に最小限の使用で必要なパラメータは1つだけ：modelです。

# これだけで動く
emb = OpenAIEmbeddings(model="text-embedding-3-small")

「30個ある」ことと「30個使う必要がある」ことは別です。

3. 「chunkingは自前実装になる」への反論

記事の主張

品質を詰めると、最低でもこの程度の前処理は自前で書くことになります。

反論

これはLangChainの問題ではなく、RAGの本質です。

記事が示した日本語PDF正規化のコード：

def normalize_japanese_pdf_text(text: str) -> str:
    text = text.replace("\u3000", " ")
    # ...

これはどのフレームワークを使っても必要な処理です。OpenAI SDK直利用でも、LlamaIndexでも、自前実装でも同じです。

むしろLangChainは：

• RecursiveCharacterTextSplitter - 汎用的なチャンカー
• MarkdownHeaderTextSplitter - 見出しベースの分割
• SemanticChunker - 意味的な境界での分割

など、カスタマイズ可能なビルディングブロックを提供しています。

「自前実装が必要」という批判は、フレームワークが100%の処理を代行すべきという誤った期待に基づいています。

4. langsmith依存についての文脈

事実の確認

langsmithがlangchain-coreの必須依存であることは事実です。

反論

これには理由があります：

1. トレーシングはプロダクションLLMアプリの必須要件
2. LLMアプリのデバッグは従来のアプリより難しい
3. 入出力のログ、レイテンシ、トークン使用量の追跡が必要

4. langsmithはこれをゼロコンフィグで提供

5. 使わないなら無視できる

6. LANGCHAIN_TRACING_V2=false（デフォルト）なら何もしない

7. 依存としてインストールされても、APIコールは発生しない

8. 他の選択肢への統合も可能

9. LangChainはOpenTelemetry、Datadog、その他のオブザーバビリティツールとも統合できる

依存が存在することとその依存が害を与えることは別です。

5. 「SDK直利用で十分」という主張への反論

記事の前提

AI がコードを書いてくれる時代に、「5行を3行にする」ためだけに18パッケージと773行のラッパーを背負う理由は薄いはず

反論

LangChainの価値は「行数削減」ではありません。

実際の価値：

1. LCEL（LangChain Expression Language）による合成可能性 python chain = prompt | llm | output_parser # ストリーミング、バッチ処理、非同期が自動で動く

2. 120以上のインテグレーション

3. ベクトルストア：Pinecone, Weaviate, Qdrant, Chroma, pgvector...
4. LLM：OpenAI, Anthropic, Google, Cohere, Bedrock...

5. 同じコードで切り替え可能

6. LangGraphによるステートフルなエージェント

7. 記事はRAGに焦点を当てていますが、エージェント構築では複雑性が爆発的に増す

8. LangGraphはグラフベースのワークフローを提供

9. LangSmithによる本番運用

10. プロンプトのバージョン管理
11. A/Bテスト
12. 評価フレームワーク

SDK直利用で「Hello World」は書けます。しかし、本番環境で運用するアプリケーションはそれだけでは足りません。

6. 依存サイズの比較について

事実の確認

反論

15MBの差は2026年の開発環境では無視できるレベルです。

比較のために： - pandas : ~50MB - numpy : ~20MB - tensorflow : ~500MB - pytorch : ~800MB

15MBの差がプロジェクトの成否を分けることはありません。

もしサイズが本当に問題なら、langchain-coreだけを使い、langchain本体を入れない選択肢もあります。

7. 記事が触れていない重要な事実

LangChainのエコシステム規模

• GitHub Stars: 100,000+
• 月間PyPIダウンロード: 3,000万+
• ドキュメントの訪問者: 月間300万+
• コントリビューター: 3,000+

これだけの規模で使われているのは、実際に価値を提供しているからです。

大企業での採用実績

• Elastic, Notion, Replit, Robinhood, Morningstarなど、数千社が本番で使用
• これらの企業は「773行が重い」と感じていません

LangGraphの台頭

記事は「Agent構築は別途検討」と述べていますが、LangGraphは現在最も活発に開発されているエージェントフレームワークです。RAGだけでLangChainを評価するのは片手落ちです。

結論

批判記事は以下の点で価値があります： - ソースコードを実際に読んでいる - 実測データを提供している - 特定のユースケース（シンプルなRAG）での判断基準を示している

しかし、以下の点で不公平または不正確です：

1. ドキュメント行数を「重さ」としてカウント
2. オプションパラメータを「複雑さ」として批判
3. 依存サイズを2026年の文脈で過大視
4. LangChainの主要な価値（LCEL、LangGraph、LangSmith）を評価対象外に
5. エコシステムの規模と採用実績を無視

LangChainは「初手で入れる標準」ではないかもしれません。しかし、「推奨しない」と断言するのは、フレームワークの提供する価値の全体像を見ていない判断です。

適切な判断は： - シンプルなプロトタイプ → SDK直利用も選択肢 - 複数プロバイダー対応、エージェント、本番運用 → LangChainを検討

ツールは目的に応じて選ぶものだと思います。 以上。