LangChain、チャットボットの再構築と教訓を公開

著者：ライアム・バッシュ（Liam Bush）

背景

どんな成功したプラットフォームにも、信頼性の高いサポートは不可欠です。しかし私たちは、自社のチームが技術的な質問への回答を探すために何時間も費やしていることに気づきました。この摩擦はエンジニアの生産性を低下させるだけでなく、ユーザーにとって致命的なボトルネックとなっていました。

そこで私たちは、自社が推奨するツールそのものを使ってこの課題を解決することを目指しました。それが LangChain、LangGraph、そして LangSmith です。当初、chat.langchain.com はプロトタイプとして構築され、明確に以下の 2 つの機能を果たすように設計されていました。

• 製品 Q&A: ユーザーや自社チームが、製品に関する質問に対して即座に権威ある回答を得られるようにする。
• 顧客向けプロトタイプ: LangChain スタックを使って、いかに洗練され信頼性の高いエージェントを構築できるかを示す、生きた事例として機能させる。

私たちは明確な意図を持っており、機能的な製品も作りました。しかし、告白しましょう：サポートエンジニアたちは、LangChain チャットボットを実際に活用していませんでした。ここから、私たちの本当の学びが始まりました。これが、私たちが自社のエージェントをどう改善したか、そして顧客が適応して使える本物の信頼性が高く、生産環境で使えるアプリケーションを構築するために何を学んだのかという物語です。

LangChain の Chatbot を再構築した理由と、そこから得た教訓

私たちのチームが「Chat LangChain」を積極的に活用していなかったのは、システムに不具合があったからでも、その価値を信じていなかったからでもありませんでした。ある時、「本番環境でストリーミング機能が動作しない」という問い合わせに対し、ドキュメントという唯一のリソースに頼るだけでは不十分だと感じたからです。誰もが知っている通り、ドキュメントは決して十分ではありません。

そこで彼らは独自のワークフローを構築しました。

• ステップ 1: docs.langchain.com のドキュメントを検索し、その機能が本来何を行うべきかを理解する。
• ステップ 2: support.langchain.com のナレッジベースを確認し、他のユーザーが同様の問題に直面したか、そしてそれがどのように解決されたかを確認する。
• ステップ 3: Claude Code を起動して実際のコードを検索し、コードが実際に何をしているかを検証する。

公式の物語はドキュメントで、現実世界の課題はナレッジベースで、真実はコードベースにある。

自動化を決断した理由

この 3 ステップの手順は非常に効果的でした。私たちは彼らが1日に何度もこれを実行している様子を目撃し、「このワークフローをそのまま自動化できないか？」と考えました。

そこで、複雑で多段階のタスクに取り組めるエージェントを構築するためのライブラリである内部 `Deep Agent` を開発しました。ドキュメント検索用、ナレッジベース検索用、コードベース検索用の 3 つの専門サブエージェントが連携し、それぞれが追加質問を行いながら結果をフィルタリングした上で、主要なオーケストレーターエージェントに洞察を渡す仕組みです。

主要なエージェントは、すべての情報を統合し、以下のような回答を生成します。

出力例：「サブグラフからのストリーミングを行うには、stream config で subgraphs: true を設定してください。これは LangGraph ストリーミングドキュメント に記載されています。また、「アップグレード後にトークンストリーミングが機能しない理由」に関するサポート記事（こちら?）で、この問題に対する具体的な解決策が説明されています。ネストされたエージェントからのトークンレベルの更新を取得するには、サブグラフのストリーミングを有効にする必要があります。実装は pregel/main.py の 3373-3279 行目 にあり、ここで subgraphs フラグがネストされたグラフの出力をストリームに含めるかどうかを制御しています。」

エンジニアたちはこの仕組みを高く評価しました。

複雑なデバッグ作業にかかる時間を週単位で大幅に短縮できたのです。エンジニアは本番環境の問題を説明するだけで、ドキュメントへの言及や既知の解決策の参照、そして重要なコード行への具体的な指針を含む包括的な回答を即座に受け取ることができました。

気づいたこと

ある時、誰もが抱く素朴な疑問が投げかけられました。「なぜ、この手法は私たちにとってうまくいくのに、公開されている Chat LangChain では同じように機能しないのか？」

これは正当な指摘でした。私たちの公開ツールは、ドキュメントを断片に分割し、埋め込みベクトルを生成してベクトルデータベースに保存していました。ドキュメントが更新されるたびに再インデックスする必要があり、ユーザーは回答を得られるものの、出典情報の扱いが不十分で、文脈も分断されていました。

私たちは無意識のうちに、うまくいっている仕組みをそのままコピーすることで、内部ではより優れたものを構築してしまっていたのです。このアプローチを公開製品にも持ち込むべき時でした。

再構築に取り掛かった際、すぐに2つの異なるアーキテクチャを組み合わせる必要があると気づきました。これらは、大きく分けて2種類の質問に対応するためのものでした。多くの質問はドキュメントやナレッジベースから回答できますが、残りの質問にはコードの基盤そのものの分析が必要となります。

新エージェントの構築方法

シンプルなドキュメント用：エージェントを作成する

chat.langchain.com のデフォルトモードとして、`createAgent`（`langchain` 内のエージェント抽象化）を採用しました。これは、速度を最優先する場合に最も適しているからです。

計画フェーズもオーケストレーションのオーバーヘッドもなく、ツール呼び出しと回答が即座に行われます。エージェントはドキュメントを検索し、必要に応じてナレッジベースを確認します。結果が不明確な場合はクエリを調整し、最終的に回答を返します。ドキュメントに関する質問のほとんどは3〜6回のツール呼び出しで処理でき、Create Agent はそれを数秒で実行します。

モデルオプション:

エンドユーザーには複数のモデルへのアクセス権限を提供しています。具体的には、Claude Haiku 4.5、GPT-4o Mini、そして GPT-4o-nano です。その結果、Haiku 4.5 はツール呼び出しにおいて極めて高速でありながら、高い精度も維持していることがわかりました。

createAgent と Haiku 4.5 を組み合わせることで、ほとんどの問い合わせに対して 15 秒未満のレスポンスを実現できています。これはドキュメント Q&A に求められる要件そのものです。

最適化のポイント:

私たちは `LangSmith` を活用して、すべての会話を追跡し、エージェントが不要なツール呼び出しを行っていた箇所を特定するとともに、プロンプトの改善を行いました。データによると、エージェントにより適切なフォローアップ質問ができるよう訓練すれば、ほとんどの質問は 3〜6 回のツール呼び出しで回答可能であることがわかりました。LangSmith の評価スイートを使えば、異なるプロンプト戦略を A/B テストでき、処理速度と精度の両面で改善度を測定できます。

この 30 秒のトレースには、7 つのツール呼び出しが含まれています。具体的にはドキュメント検索が 4 回、ナレッジベース記事の参照が 1 回、そして記事の読み込みが 2 回です。最終レスポンスをストリーミングするのにかかった時間は 20 秒です。

こちらで確認

コードによる回答を実現する：サブグラフを持つ Deep Agent

多くの質問に対しては、ドキュメントやナレッジベースの活用、既知の問題との照合といったリソースの利用に加え、コードベースを検索して実装の詳細を検証する必要がありました。

アーキテクチャ：

これらのタスクのために、私たちは 専門化されたサブグラフ を持つ Deep Agent を構築しました。一つは ドキュメント検索用、もう一つは ナレッジベース検索用、そして残りが コードベース検索用 です。

各サブエージェントは独立して動作し、フォローアップ質問を行い、情報をフィルタリングして最も関連性の高い洞察のみを抽出した上で、メインのオーケストレーターエージェントへ引き渡します。これにより、メインエージェントが文脈情報に埋もれるのを防ぎつつ、各ドメインの専門家が必要な限り深く掘り下げることが可能になります。

コードベース検索の強み：

コードベース検索サブエージェントは特に強力です。パターンマッチングを用いてプライベートリポジトリを検索したり、ファイル構造をナビゲートして文脈を理解したり、行番号精度で特定の実装を読み込んだりできます。

トレードオフ：

この深層エージェントアーキテクチャは実行に時間がかかります。複雑なクエリでは1〜3 分かかることもありますが、その徹底した回答の質には価値があります。初期の回答が核心から外れていると判断した場合、私たちは DeepAgent を活用します。

免責事項：このモードはローンチ時には一部のユーザーのみで有効化されており、数日後に一般公開されます。

ベクトル埋め込みから離れた理由

ドキュメント検索の標準的なアプローチ——ドキュメントを断片化し、埋め込みベクトルを生成してベクトルデータベースに保存し、類似度に基づいて検索する——という方法は、PDF などの非構造化コンテンツには適しています。しかし、構造化された製品ドキュメントでは、常に 3 つの問題に直面していました。

断片化が構造を壊す。ドキュメントを 500 トークンの断片に切り分けると、見出しやサブセクション、文脈情報が失われます。エージェントは「set streaming=True」という記述を引用するだけで、なぜ、いつ使うのかの説明がありませんでした。ユーザーは必要な情報を見つけるためにページ内を検索する必要がありました。

頻繁な再インデックス化。ドキュメントは 1 日に複数回更新されます。変更のたびに断片化、埋め込み生成、アップロードをやり直す必要があり、作業が滞っていました。

あいまいな引用元。ユーザーは回答を検証したり、情報の出所を追跡したりできませんでした。

突破口となったのは、私たちが解決すべき問題を間違えていたと気づいたことです。ドキュメントはすでに整理されており、ナレッジベースはカテゴリ分けされ、コードベースも探索可能です。私たちはより賢い検索手法を必要としていたのではなく、エージェントに既存の構造への直接アクセスを与える必要があったのです。 （原文の技術表記: "set streaming=True"）

より良いアプローチ：直接 API アクセスと賢いプロンプト設計

チャンク化や埋め込みを行わず、エージェントに実物を直接アクセスさせました。ドキュメントには Mintlify's API を使用し、すべての見出し、サブセクション、コード例がそのまま残された完全なページを返すようにしています。ナレッジベースについては、まずタイトルでサポート記事を検索し、最も有望なものだけを全文読み込みます。コードベースの検索では、LangGraph Cloud 環境にコードベース全体をアップロードし、ripgrep でパターンマッチングを行い、ディレクトリ構造を把握して必要な実装部分を抽出します。

エージェントは類似度スコアに基づいて情報を取得するわけではありません。人間が検索するように、キーワードを用いて絞り込み、追跡質問を行うのです。

ここが真の魔法が起きる場所です。単に「検索して結果を返せ」と指示するのではなく、十分な情報があるかどうかを批判的に検討するようプロンプトで促しています。結果が曖昧だったり不十分だったりすれば、エージェントはクエリを調整して再検索します。ドキュメントで概念に触れられているが説明がない場合は、その概念自体を特定して検索します。複数の解釈が可能であれば、最も関連性の高いものへと絞り込みます。

ツール設計：人間のワークフローに合わせる

我々のツールは、検索アルゴリズムの仕組みではなく、人間が実際にどのように検索するかというプロセスを模倣するように設計しました。

ドキュメント検索：断片ではなく完全なページを

ドキュメント検索ツールは Mintlify's API をクエリし、完全なページを返します。ストリーミングについて質問された際、エージェントが異なるセクションから得た3つのバラバラした段落を受け取るのではなく、人間が読むのと同じ順序で構造化された、ストリーミングに関するドキュメントページ全体を取得します。

@tool
def SearchDocsByLangChain(query: str, page_size: int = 5, language: Optional[str] = None) -> str:
    """Search LangChain documentation via Mintlify API"""
    params = {"query": query, "page_size": page_size}
    if language:
        params["language"] = language
    response = requests.get(MINTLIFY_API_URL, params=params)
    return _format_search_results(response.json())

しかし、私たちはここで止まりません。初期の結果が実際に質問に答えているかを評価するようエージェントにプロンプトを与えます。「これは適切なセクションか？明確化する必要がある関連概念はないか？より具体的な検索用語の方が良いのではないか？」

エージェントには4〜6回のツール呼び出しの予算があり、回答する前に理解を深めるために戦略的にそれらを活用することを促しています。

実際の運用では、以下のような流れになります。

ユーザーが「エージェントにメモリ機能を実装するにはどうすればよいですか？」と質問します。

エージェントは「memory」というキーワードで検索し、チェックポイント（checkpointing）、会話履歴、Store API に関する結果を取得します。しかし、その中から適当に一つを選ぶのではなく、この質問には曖昧さがあることに気づきます。「メモリ」には、スレッド内で会話の状態を永続化することと、複数の会話間で事実情報を保存することの二つの意味が含まれるからです。

そこでエージェントは、「checkpointing」というキーワードで再度検索し、スレベルでの永続化に焦点を絞り、サポート記事「LangGraph でチェックポイントを設定するには？」を開きます。しかし、この記事にはクロススレッド（跨スレッド）メモリに関する記述がないことを認識します。

そのため、残りのギャップを埋めるために、「store API」で検索を実行します。 （原文の技術表記: "memory"、"checkpointing"、"store API"）

最終回答では、会話履歴のチェックポイント機能と長期記憶のための Store API について、サポート記事およびドキュメントへの正確な引用を交えて解説しています。

この反復的な検索プロセスは Create Agent を使用すれば数秒で完了しますが、応答の質を根本的に変えるものです。エージェントは単に情報を取得するだけでなく、ユーザーが本当に必要としているものを推論しているのです。

ナレッジベース検索：スキャンしてから読み込む

私たちが構築したナレッジベース（Pylon 搭載）の検索機能は、人間がナレッジベースを利用する方法に合わせて2 つのステップで設計しました。

まずエージェントは記事タイトルを数十件取得し、それらをスキャンして関連性がありそうなものを選別します。その後、選んだ記事のみを完全に読み込みます。

@tool
def search_support_articles(collections: str = "all", limit: int = 50) -> str:
    """Step 1: Get article titles to scan"""
    articles = pylon_client.list_articles(collections=collections, limit=limit)
    return json.dumps([{
        "id": a["id"],
        "title": a["title"],
        "url": a["url"]
    } for a in articles])

@tool
def get_article_content(article_ids: List[str]) -> str:
    """Step 2: Read the most relevant articles"""
    articles = pylon_client.get_articles(article_ids)
    return "\\n\\n---\\n\\n".join([
        f"# {a['title']}\\n\\n{a['content']}\\n\\nSource: {a['url']}"
        for a in articles
    ])

なぜこのアプローチが有効なのか：

これにより、エージェントが情報に埋もれてしまうのを防ぎます。30 件の完全な記事をコンテキストウィンドウに渡すのではなく、実際に重要な 2〜3 件に絞り込み、それらを徹底的に読み込んで主要な洞察を抽出するのです。

プロンプトでもこの方針を強化しています。「量よりも質を重視し、必要に応じて検索範囲を狭め、質問に直接答える情報だけを返すこと」です。

コードベース検索：検索、ナビゲーション、検証

ここが私たちの Deep Agent が真価を発揮する場所です。

エージェントには、冒頭で示したワークフローと同じパターンを持つ 3 つのツールを与えました。これはエンジニアたちが Claude Code を使用する際に従っているのと同じ手順です。

@tool
def search_public_code(pattern: str, path: Optional[str] = None) -> str:
    """Step 1: Find code matching a pattern"""
    cmd = ["rg", pattern, str(path or search_path)]
    return subprocess.run(cmd, capture_output=True, text=True).stdout

@tool
def list_public_directory(path: str, max_depth: int = 2) -> str:
    """Step 2: Understand the file structure"""
    cmd = ["tree", "-L", str(max_depth), str(path)]
    return subprocess.run(cmd, capture_output=True, text=True).stdout

@tool
def read_public_file(file_path: str, start_line: int = 1, num_lines: int = 100) -> str:
    """Step 3: Read the actual implementation"""
    with open(file_path, "r") as f:
        lines = f.readlines()
    return "\\n".join(lines[start_line-1:start_line-1+num_lines])

仕組み：

まず、ripgrep を使ってコードベース内から該当するパターンを検索します。次にディレクトリ構造をリスト化し、ファイルの整理方法を把握します。最後に、関連するセクションに焦点を当てて特定のファイルを読み込み、行番号付きで実装内容を返します。

実際の事例:

あるユーザーが、本番環境でストリーミングトークンの処理が停止していると報告しました。ドキュメントサブエージェントは、ストリーミング設定にはバッファ設定が含まれていることを特定し、ナレッジベースサブエージェントはアップグレード後のトークンストリーミングに関する問題についてのサポート記事を検索して提示します。

しかし、実際の実装を発見したのはコードベースサブエージェントです。このエージェントは "streaming buffer" を検索し、callbacks/streaming.py へ移動して、デフォルトのバッファサイズがハードコーディングされている 47〜83 行目 を返しました。

これが、真の問題を解決するための深い調査の一例です。

違いは何でしょうか？ Deep Agent は 3 つのドメインすべてで並列に動作し、中間結果を統合して一貫性のある回答を生成できます。

Deep Agent とサブグラフがコンテキストオーバーロードをどう解決するか

当初、Deep Agent を単一のシステムとして構築し、すべてのツールへのアクセス権を持たせた際、発見した情報をすべて出力していました。メインエージェントは一度に 5 つのドキュメントページ、12 のナレッジベース記事、そして 20 のコードスニペットを受け取ることになります。

その結果、コンテキストウィンドウが爆発的に膨れ上がり、最終的な回答は無関係な詳細で肥大化するか、あるいは肝心な洞察を見失うことになりました。

そこで私たちは、専門化したサブグラフを用いてシステムを再構築しました。

仕組みは以下の通りです：

各サブエージェントは独立して動作します。それぞれのドメインを検索し、曖昧さを解消するためのフォローアップ質問を行い、結果をフィルタリングして、回答に必要な本質的な事実、出典、文脈のみであるゴールデンデータを抽出します。

オーケストレーターとなる主要なエージェントが、生きた検索結果を直接見ることはありません。各ドメインの専門家が精査した洞察のみを受け取ります。プロンプト付きの完全なトレースは **こちら で確認できます。

なぜこれが重要なのか：

ドキュメント担当のサブエージェントは 5 ページ分の資料を読み込んでも、最終的に返すのは重要な 2 パラグラフだけかもしれません。ナレッジベース担当のサブエージェントが 20 件の記事タイトルをスキャンしても、関連する要約 3 つだけを返すこともあります。コードベース担当のサブエージェントが 50 ファイルを検索しても、行番号付きの実装部分のみを抽出して返します。

主要なエージェントは、これらを統合して包括的な回答を作成できる、クリーンで厳選された情報を受け取ることになります。

本番環境への対応

洗練されたエージェント設計であっても、実際のユーザーとの接触に耐えさせるには、生産インフラが不可欠です。プロンプトを煩雑にする運用上の課題を処理するために、モジュール化された ミドルウェア を構築しました。

middleware = [
    guardrails_middleware,      # Filter off-topic queries
    model_retry_middleware,     # Retry on API failures
    model_fallback_middleware,  # Switch models if needed
    anthropic_cache_middleware  # Cache expensive calls
]

各レイヤーの役割：

ガードレールは、本題から外れたクエリをフィルタリングし、エージェントが LangChain に関する質問に集中し続けるようにします。

リトライミドルウェアは、一時的な API 障害を適切に処理するため、ユーザーが意味不明なエラーメッセージを見ることはありません。

フォールバックミドルウェアは、モデルの利用不可時に Haiku、GPT-4o Mini、Gemini Nano の間で切り替えます。

キャッシング機能により、同一のクエリに対する結果を再利用することでコスト削減を実現します。

これらのレイヤーはユーザーには見えませんが、信頼性を支えるために不可欠です。これらによってエージェントは推論に集中でき、インフラ側が障害対応、コスト最適化、品質管理を担当します。

エージェントをユーザーへ届ける

優れたエージェントを開発することは戦いの半分だけです。残りの半分は、それを「高速で賢く」感じる形でユーザーに届けることです。

私たちは、ストリーミングと状態管理の複雑さをすべて処理するために LangGraph SDK を活用しています。

ユーザーのスレッド読み込み:

Chat LangChain が開かれると、LangGraph SDK を使って会話履歴を取得します：

const userThreads = await client.threads.search({
  metadata: { user_id: userId },
  limit: THREAD_FETCH_LIMIT,
})

各スレッドにはユーザー ID がメタデータとして保存されるため、セッションを跨いても会話は非公開かつ永続的に保持されます。フィルタリング処理は LangGraph SDK が自動で行います。

リアルタイムでのレスポンスストリーミング:

ユーザーがメッセージを送信すると、LangGraph SDK が生成過程でレスポンスをストリーミングします：

typescript

const streamResponse = client.runs.stream(threadId, "docs_agent", {
  input: { messages: [{ role: "user", content: userMessage }] },
  streamMode: ["values", "updates", "messages"],
  streamSubgraphs: true,
})

for await (const chunk of streamResponse) {
  if (chunk.event === "messages/partial") {
    setMessages(prev => updateWithPartialContent(chunk.data.content))
  }
}

ユーザーに見えるもの：

3 つのストリームモードにより、エージェントの思考プロセス全体を確認できます。

• messages — エージェントが記述する過程でトークンが順次表示される
• updates — ツール呼び出しを通じて、エージェントが何を探しているかがわかる
• values — 処理完了後の最終的な完全な状態

ユーザーは、エージェントが思考し、ドキュメントを検索し、ナレッジベースを確認し、トークン単位で回答を構築する様子をリアルタイムで見ることができます。読み込みスピナーは一切表示されません。

会話の履歴管理

同じ thread_id をメッセージ間で共有すれば、LangGraph のチェックポインタが自動的に残りの処理を担当します。これは会話履歴の保存、各ターンごとの文脈取得、そしてセッションをまたぐ状態維持を行います。TTL（有効期限）は7日に設定しています。これだけです。

結果

新システムを導入して以来、劇的な改善が見られています。

パブリック版の Chat LangChain では、ユーザーが15 秒未満で回答を受け取れるようになり、正確な引用も付与されます。関連するドキュメントページやナレッジベース記事に直接リンクしているため、回答を即座に検証可能です。また、ドキュメント更新時に数時間かけて再インデックスする必要もなくなり、自動的に追従するようになりました。

社内では、サポートエンジニアが最も複雑なチケット処理に Deep Agent を活用しています。このエージェントはドキュメントを検索し、既知の問題と照合し、さらにプライベートなコードベースを深く掘り下げて、実際に何が起きているのかを説明する実装詳細を見つけ出します。このエージェントはエンジニアを置き換えるものではなく、彼らの能力を増幅させるものです。調査業務を代行することで、エンジニアは問題解決に集中できます。

重要な教訓

• ユーザーのワークフローに従う: 既存の成功したプロセスを再発明する必要はありません。最も優秀なユーザー（または社内エキスパート）がすでに活用しているワークフローを自動化しましょう。LangChain の場合、これは「ドキュメント」「ナレッジベース」「コードベース」の 3 ステップという儀式を再現することを意味します。
• ベクトル埋め込みが適切か評価する: 製品マニュアルやコードのような構造化されたコンテンツでは、ベクトル埋め込みを使用すると文書構造が崩れ、あいまいな出典指定につながり、頻繁な再インデックス化が必要になります。ベクトル埋め込みは、非構造化データや短いブロック、クラスタリング用途においては非常に優れた手法です。
• エージェントに構造への直接アクセスを与える: このアプローチにより、エージェントはコンテンツの既存構造に対して API を介して直接アクセスできるようになります。これによって、人間のようにキーワード検索を行い、必要に応じて絞り込むことが可能になります。
• 検索よりも推論を優先する: ツール設計では人間のワークフローを模倣します。記事タイトルをスキャンしてから本文を読み込み、コードについてはパターンマッチングやディレクトリナビゲーションを活用します。また、初期の結果が曖昧な場合はフォローアップ質問を行い、クエリを洗練させるようエージェントに指示を出しましょう。これにより、ユーザーの真のニーズに応える最終回答を得ることができます。

複雑な多領域の質問に対処するには、Deep Agent（ディープエージェント）と専門的なサブグラフを活用してコンテキストを管理することが重要です。これにより、主要なオーケストレーターエージェントが生の検索結果に埋もれるのを防ぎます。各サブエージェントは、自らのドメインから「ゴールデンデータ」のみをフィルタリング・抽出し、洗練された洞察だけを上位のオーケストレーターへ伝達します。

また、本番環境で安定稼働させるには堅牢なミドルウェアが不可欠です。エレガントなエージェント設計であっても、信頼性を担保するにはインフラが伴う必要があります。ガードレール（話題外のリクエストをフィルタリング）、リトライ（API 失敗時の再試行）、フォールバック（モデルの切り替え）、そしてキャッシュ機能を持つモジュール型のミドルウェアを実装することが、本番レベルの信頼性、コスト最適化、品質管理のために必要です。

次のステップ

パブリックコードベースの検索機能（今後数日以内に公開予定）—— ドキュメントやナレッジベースでは不十分な場合、エージェントはパブリックなリポジトリを検索し、実装内容を確認して正確な行番号を引用します。

実際に試してみましょう

Chat LangChain は現在 chat.langchain.com で利用可能です。最速のレスポンスを得たい場合は Claude Haiku 4.5 を、異なるモデルのパフォーマンスを確認したい場合は GPT-5 Mini や GPT-5 Nano を試してみてください。

議論に参加しましょう

速度と深さのバランスを取るエージェント構築は容易ではなく、私たちはまだ学び続けています。同様の課題に取り組んでいる方は、発見したことをぜひ共有してください。

LangChain のコミュニティに参加するには、フォーラム で議論するか、Twitter をフォローしてください。

チームやコミュニティからの最新情報は、ニュースレター購読でお届けします。

関連記事

ケーススタディ

LangGraph

LangSmith

チュートリアルとハウツーガイド

LangGraph と LangSmith を活用した Lyft のカスタマーサポート向けセルフサービス AI エージェントプラットフォームの構築事例

Akshay Sharma 著

2026 年 5 月 27 日

10 分

LangSmith

エージェントアーキテクチャ

ディープエージェント

チュートリアルとハウツーガイド

エージェント改善のための AI エージェント「LangSmith Engine」の構築プロセス

Palash Shah 著

2026 年 5 月 19 日

17 分

企業ニュース

LangSmith

Interrupt でリリースしたすべての機能

Jacob Talbot

2026 年 5 月 14 日

11 分

エージェントの実際の動作を確認する

LangSmith は、開発者がエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるためのエージェントエンジニアリングプラットフォームです。