7月28日、LangChainが「How LangChain Built an Agent-First Data Stack」と題した記事を公開した。LangChain社内のデータチームがHexやdbt（データ変換・モデリングツール）を活用してエージェントファーストなデータスタックを構築した経緯と、その具体的な設計方針について詳しく紹介されている。

3人チームの40倍の問い合わせをさばくデータエージェント

LangChainは過去1年間で、社内データスタックを従来型のBIツール中心の構成から、AIエージェント活用を前提とした設計に刷新した。

その結果は数字に出ている。自社のデータエージェントは、3人のデータチームが直接対応できていた量の約40倍の問い合わせを処理するようになった。直近30日間では、エージェントアクセス権を持つユーザー（全社の約3分の1）のほぼ100%が実際にデータエージェントを利用し、期間中の会話数は約2,200件、1ユーザーあたり月平均23会話に達している。

なぜBIツール中心の構成を捨てたのか

移行前は、ほぼすべてのデータ依頼がデータチームを経由していた。当時、そのチームは1人だった。

既存のBIツールは定型レポートには使えたが、探索的な分析を他者と共有したり、データチーム外の人間が自分でアクセスしたりするのは難しかった。「質問 → データチームが翻訳 → クエリ作成 → 検証 → 回答」というサイクルが繰り返され、データチームは1回限りの依頼対応に追われていた。

社内には多様なニーズがあった。ダッシュボードが欲しい人、ノートブックとSQLを使いたい人、データの在処を知らなくても会話形式で答えを得たい人。LangChainはこれらを一つのツールで賄うことを選び、**Hex** を採用した。ダッシュボード、ノートブック、会話型分析をすべて一つのワークスペースで扱える点が決め手になった。

移行は6週間で完了し、旧BIツールから100%移行した。現在、全社員が何らかの形でHexを使っており、約70%が読み取り専用アクセス、約30%がエージェントアクセスを持つ。

エージェントへのアクセス経路は複数用意されている。

• Hex UI（ThreadsやノートブックのUI）
• Slack
• CLI
• MCP
• LangSmith Fleet（MCPおよびCLI経由）

「エージェントはすでに使っている場所で使えるときに最も価値がある」というのがLangChainの考え方だ。

エージェントの精度を決める「コンテキスト設計」

この記事で最も実用的なのが、エージェントに何を読ませるかというコンテキスト設計の話だ。SQLを生成できるだけでは不十分で、ビジネス上の解釈が正しくなければ答えとして使えない。LangChainはコンテキストを以下の5層で管理している。

1. dbtのモデル定義

dbt（データウェアハウス上でSQLベースの変換・テストを管理するオープンソースツール）のテーブル・カラム定義に、ビジネス上の意味を書き込む。

曖昧な定義の例：

account_status: アカウントのステータス。

良い定義の例：

account_status: Salesforceにおけるアカウントのライフサイクルステータス。Activeは有効な有料契約があることを意味する。Churnedは過去に有料契約があり終了したことを意味する。Prospectはまだ顧客になっていないことを意味する。顧客レポートでは、分析が明示的にチャーンや見込み顧客を含む場合を除き、Activeでフィルタリングすること。

このような定義があることで、エージェントは技術的に正しいが業務的に間違った解釈をしにくくなる。

2. セマンティックモデル

ARR、パイプライン、アクティブ利用率、顧客ヘルスといった繰り返し参照されるメトリクスを定義する層。セマンティックモデルとは、生のテーブル定義とは別に「ビジネス指標の計算ロジック」を一元管理する仕組みで、エージェントがメトリクスのロジックを毎回推測せずに済む。セマンティック層は、土台のデータモデリングが整っていてこそ機能する、と記事では強調されている。

3. ワークスペースガイド（業務コンテキスト）

テーブルやメトリクス定義には収まりきらないビジネスルールを、自然言語で記述する。Hexのワークスペースガイドとして管理し、GitHubリポジトリと同期することでバージョン管理とレビューを可能にしている。

記述内容の例：

• GTM週次レポートにおけるパイプラインの定義
• あるメトリクスの正式なダッシュボードはどれか
• 異なるデプロイタイプにまたがる製品利用の解釈方法
• 顧客ヘルス分析時に適用すべきフィルター

4. エンドースメント（信頼シグナル）

同じ概念に複数のテーブルやダッシュボードが存在する場合、エージェントがどれを参照すべきかを判断するための「お墨付き」の仕組み。エンドースメントを付けられるのはデータチームのみで、変更時にはレビューが必要。「すべてにエンドースメントがあれば意味がなくなる」という原則のもと、絞り込んで運用している。

5. GitHubのdbtリポジトリ

エージェントはdbtリポジトリも参照でき、あるフィールドがどのSQLロジックで生成されているかをトレースできる。技術的なユーザーが検証やデバッグを行う際に特に有効とされている。

フィードバックループで継続改善

コンテキスト設計はワンショットでは終わらない。LangChainはHexのContext Studioを使って会話ログを観測し、頻出する質問パターン、エージェントが詰まるメトリクス、コンテキストのギャップを継続的に把握している。自前でデータエージェントを構築しているチーム向けにはLangSmithを活用する選択肢も紹介されている。

改善ループの構造は以下のとおりだ。

1. ユーザーがHex・Slack・CLI・MCP・LangSmith Fleet経由で質問
2. エージェントがdbt定義、セマンティックモデル、ワークスペースガイド、エンドースメント、ダッシュボード、GitHubのコンテキストを参照して回答
3. オブザーバビリティツールがギャップ、警告、繰り返しトピックを可視化
4. データチームがパターンを確認
5. モデル、定義、ガイド、メトリクス、エンドースメント、ダッシュボードを更新
6. エージェントの回答精度が向上

今後の方針

記事の末尾では、今後取り組む課題として以下が挙げられている。

• 評価（evals）の導入：メトリクス定義やガイドを変更したときに、実際にエージェントの回答が改善されたかを測定できる仕組みを整備する。コンテキスト管理をソフトウェア開発に近い形（変更→テスト→リリース）で運用することが目標だ。
• コンテキスト更新の自動化：オブザーバビリティで見つかったギャップを、dbt定義やワークスペースガイドの更新に結びつけるプロセスを省力化する。

まとめ

LangChainが強調するのは一点だ。エージェントアクセスはデータモデリングの重要性を下げるのではなく、むしろ高める。カラムの定義が曖昧なら、エージェントも人間と同じように迷う。コンテキストへの投資は高レバレッジであり、「業務上の意味」を書き込む作業が精度を決める。

この事例が示す実践的な示唆は、ツール選定よりも先にコンテキスト設計の方針を固めることだ。dbtのカラム定義の粒度、セマンティック層で一元管理するメトリクスの範囲、ワークスペースガイドに何を書き自然言語で記述するか——これらの判断はエージェント導入後も継続的にチームの運用負荷に直結する。既存のデータ基盤にエージェントを乗せることを検討しているチームにとっては、自社のdbtモデルやメトリクス定義の「業務的な意味の充実度」を棚卸しする起点として参照価値が高い。

詳細はHow LangChain Built an Agent-First Data Stackを参照していただきたい。