AskData の内部：トークン消費量を 90% 以上削減した方法

データは、製品がどのように進化し、企業がどのように意思決定を行うかを裏付けるものです。しかし、データウェアハウスから素早く、正確に、適切なビジネスコンテキストを組み込んで回答を引き出すことは、実際にはそれほど難しいことではありません。 Pinecone がマルチプロダクト・マルチチャネルの事業へと成長するにつれ、静的なダッシュボードだけでは不十分になりました。パイプラインの健全性、リテンションリスク、製品採用率、収益ミックスなど、実際の意思決定を駆動する質問は、事前に構築されたビューにきれいに収まることはめったにありません。アナリストがボトルネックとなり、アドホックな質問が行われず、意思決定は陳腐な数値や勘に頼るものになっていました。 そのギャップを埋めるために、私たちは AskData を構築しました。これは、当社の事業が実際にどのように運営されているかという蓄積された知識に基づいて、データウェアハウスを検索し推論を行う社内 AI データエージェントです。この知識は、Slack のスレッド、通話の書き起こし、CRM レコード、請求システム、内部文書などに散在しています。構造化されたウェアハウスデータとともにこれらすべてを表面化することが、単なるクエリ実行ツールと、人々が実際に信頼するエージェントとの決定的な違いとなります。 2026 年 5 月、私たちは AskData を [Pinecone Nexus](https://www.pinecone.io/blog/knowledge-infrastructure-for-agents/) の上に再構築しました。その結果、トークン使用量は 92% 以上減少し、クエリの実行ターン数は 78% 削減されました。 これが、私たちがどのようにそこに到達したかの物語です。 ## 最後の 1 マイルは知識の問題である Pinecone のデータスタックは、非常に標準的なセットアップです。イベントは BigQuery に着地し、[dbt](https://www.getdbt.com/) がそれらを変換します。マートテーブルがダッシュボードの基盤となります。 パイプラインは機能し、ダッシュボードも機能しています。課題は最後の 1 マイル、つまりビジネス用語で表現された質問を、適切なテーブル、適切な列、適切なフィルター、そして適切な注意書きへと翻訳する点です。しかもそれをスケーラブルに実現する必要があります。 これはデータの問題ではなく、知識の問題です。 データはウェアハウス内に存在します。しかしデータの意味はどこか別の場所にあります。ARR における標準的なビューはどれですか？各指標にはどの程度のラグがありますか？除外すべきアカウントはどれですか？先四半期に定義が変更されたのはいつでしょうか。これらの情報はスキーマの検査からは発見できません。 毎日ウェアハウスで作業するアナリストにとっては、これはまた平凡な一日に過ぎません。しかしそれ以外のすべての人にとって、セルフサービスのコストはあまりにも高く、ほとんどのアドホックな質問自体が行われることはありません。意思決定は古くなったダッシュボードや勘に頼って行われます。アナリストはあらゆるクロスファンクショナルな質問に対するボトルネックとなってしまいます。 それが AskData が埋めなければならなかったギャップです。 ## V0 — Claude/Cursor に投げ込んで、結果を見てみる 明白な出発点は、一連のツールを BigQuery、dbt、そしていくつかの社内ドキュメントに接続し、それらをローカルのコーディングエージェントである Claude や Cursor などに直接手渡すことでした。多くの内部ユーザーが 2025 年後半にこの試みを行いました。 エージェントループ自体には問題がありませんでした。各セッションで人手によって十分なビジネスコンテキストを提供されれば、コーディングエージェントは SQL を読み取り、変換について推論し、指標の定義を十分に正確に再現できました。問題はそれ以外のすべてでした。 **同じ質問でも、異なる回答。** 同じ質問を二人のユーザーが投げれば、出力される SQL やフィルタ、そして数値はそれぞれ異なります。意思決定を促し、共通認識を形成するために報告すべき重要なビジネス指標について、エージェントの回答が一貫性を欠けば、意思決定は停止します。「ARR の意味とは何か」という問いに対する唯一つの正解が必要であり、一人が指摘した修正点を次の人に即座に伝える仕組みも必要でした。一貫性と再現性を実現できる、集中型の知識管理とエージェント制御基盤を構築する必要がありました。 **共有された学習の欠如。** ユーザーが投げかける質問は、「先月の収益はいくらか」から「なぜこのアカウントがリスクにあるのか、そしてどう対処すべきか」という説明まで多岐にわたります。これらの質問には、非常に異なるレベルの推論と知能が求められます。どのモデル階層をどの種類の質問に割り当てるべきかを判断するのは、一度きりの作業として誰もが実行できるような単純な仕事ではありません。 **フィードバックループの欠如。** 集中型のツールリングが存在しないため、回帰テストを実行する評価環境も、本番環境での観測性（observability）も、またどの質問がエージェントを混乱させているかを示すシグナルも存在しませんでした。 **セッションごとの方向付けコスト。** 新しいセッションは毎回「コールドスタート」します。スキーマだけではビジネス上の意味を担えないため、エージェントは各質問ごとに、構造化されていないコンテキスト（dbt コード、Slack のスレッド、アナリストのメモ、クエリ履歴）から盲信的に探索し始めなければなりません。回答する前にトークンを浪費して方向付けを行う必要があるのです。 ## AskData V1: 知識層の構築 エージェントループは難しい部分ではありませんでした。難しかったのは、SQL の上にあるレイヤー、つまり SQL の数式や数値がビジネスにおいて実際に何を意味するかを保持するレイヤーです。 従来の「セマンティックレイヤー」はスキーマとメトリック定義を保持しますが、構造化データの手動で維持される記述であり、次第にビジネスとの同期がずれていきます。私たちが求めたのは、なぜそのメトリックが特定の定義を持つのか、そしてその定義が最後にいつ変更されたのかを説明する、Slack や Gong、dbt のコメント、ドキュメントといった非構造化コンテキストを保持する「知識層」でした。 この知識層は、人々が質問する方法と SQL がロジックを表現する方法の間の語彙のギャップを埋めなければなりませんでした。生の dbt SQL では機能しませんでした。SQL は変換を符号化しますが、意味を符号化するわけではありません。「月間アクティブな組織数はどれくらいか」という問いは、is_active フラグに対する count(distinct …) 式とはほとんど共通点のないベクトルとして埋め込まれます。 「ARR の傾向はどうですか」や「今月サービスに障害はありましたか」といったビジネス質問において、関連するウェアハウステーブルを記述した LLM 要約のマークダウンは、同じテーブルを定義または照会する生の SQL と比較して、少なくとも 2 倍高いコサイン類似度を示しました。同じデータでも、語彙が異なります。埋め込みモデルだけではこのギャップを埋めることはできませんでした。 そこで知識記事の作成を始めました。最初は数件の高品質な手書きの markdown ファイルから始まり、次に dbt モデルとクエリログからさらに生成するスクリプト、そしてギャップを調査して編集案を提案することだけが役割である Curator エージェントが登場しました。V1 が安定した時点では、KB（知識ベース）は 234 の markdown ファイル（計 18,000 行）となり、**Pinecone Assistant**によって提供されていました。さらに 5 つの追加的な検索面（Slack スレッド、Gong 通話、履歴 SQL、dbt ソース）が、統合された推論機能を持つ**Pinecone ベクトルインデックス**上で稼働していました。ホスト型の埋め込みと再ランク付けにより、管理すべき埋め込みパイプラインは不要となり、検索基盤全体を Pinecone がエンドツーエンドで担っていました。これに供給する 5 つの ETL パイプラインは、「毎日実行される」状態を超えて最適化されていませんでした。 V1 は #ask-data でローンチされました。3 ヶ月後の状況： **統計** **値** 回答された質問数 3,690 アクティブなスレッドを持つ Slack チャンネル数 40 フォローアップ実行（連鎖的な会話） ~49% 1 回の実行あたりの平均 SQL クエリ数 2.2 1 日あたりの質問数（5 月 11 日） 191 驚きだったのはボリュームではありませんでした。それは**49% のフォローアップ率**です。人々はデータと対話をしていました：スコープの調整、結果の詳細な掘り下げ、コホートの比較などです。質問する際のハードルが下がり、小規模な質問のロングテールが現れ始めました。これは BI ツールがドリルダウンやその他のアドホック探索プリミティブを用いて何年もかけて埋めようとしてきたギャップです。 **基本を正しくこなす 24/7 のデータ分析エージェントは、企業の意思決定の方法を根本から変えます。** ## V1 が限界に達した地点 検索基盤は Pinecone をエンドツーエンドで使用していましたが、エージェントから見たその姿は決して統一されたものではありませんでした。 V1 が安定する頃には、システムは以下のように成長していました： - 2 つのエージェント（DataAgent と Curator）にまたがる 22 のツール。 - 6 つの専用検索面（Pinecone Assistant、3 つの Pinecone インデックス、dbt ファイル読み取り、履歴 SQL 検索）。 - Slack、Gong、BigQuery ログを毎日 Pinecone に同期させる Airflow コードが 1,300 行。 - 234 のファイルにわたる 18,000 行の手動キュレーション済み Markdown を維持する Curator コードが 2,200 行。 - エージェントと共に成長したシステムプロンプト。これは、search_kb と search_slack、search_query_logs、grep_dbt の使い分け方、それら間での重複排除方法、リテラルな grep に一致しない dbt の ref() マクロの扱い方を説明するものでした。 各バックエンドは独自のクライアント、スキーマ、埋め込み戦略、リトライロジック、ETL パイプラインを持っていました。KB が自己維持できないため Curator は存在しました。それらの部品を統合して一貫性のあるものへと組み上げる層は底部に存在せず、クロスソース間の合成は、クエリ実行時にエージェントによって、すべての質問に対して行われていました。 そのコストはトークンの使用履歴に現れました。複数の部分からなる質問（「1 月に資格認定された機会の総パイプライン金額、機会数、加重パイプラインはいくらか」）には 9 ステップかかり、約 240,000 トークンを消費しました。エージェントは知識ベース検索へ分散し、292 カラムのスキーマ JSON をコンテキストに投入し、正しい日付カラムを見つけるために再検索を 2 回行い、語彙を知るために DISTINCT クエリを実行し、ようやく 4 回目の試みで SQL が正しく生成されました。この 9 ステップのうち 7 つは、実際の分析が始まる前に「どのテーブルか、どのカラムか、どのフィルターか」という方向付けに費やされていました。 コンパイラが実行のたびにソースを再構文解析することはありません。知識層が基盤に存在しない場合、エージェントインフラストラクチャはまさにそれを行っていました。 それが Nexus が解決すべき課題でした。 ## Nexus として備えるべきもの Pinecone Nexus は V1 と並行して設計されており、AskData が最初にサポートするワークロードとなりました。V1 の痛みから直接寄せられたいくつかの要望があります： **一つのキュレーションパイプライン、多数のソース。**構造化データ、半構造化データ、非構造化データのすべての入力を受け取り、エージェントが 1 回の呼び出しで活用できるタスク固有のビューとアーティファクトを生成する、単一の管理システムです。AskData の場合、これは自然言語から SQL への意味変換（どのテーブルか、どのカラムか、どのパターンか）を指します。ETL パイプラインが 5 つあるわけでも、検索表面が 5 つあるわけでもありません。1 つだけです。 **適応型知識表現。** アーティファクトのスキーマと表現は、事前に人間が設計する必要はありません。タスクに応じて有機的に進化し、固定されたオントロジーや手書きのテンプレートではなく、評価信号とソースデータによって駆動されるべきです。 **人間をループに組み込んだ知識更新。** Curator エージェントの実際の役割（ギャップの調査、編集案の提案、レビューの取得）は、Nexus においても別個のエージェントとして存続するのではなく、ファーストクラスのフィードバックメカニズムとして継承されなければなりませんでした。 Nexus はこれらの要件に対して実装されました。アーキテクチャとプリミティブ（Context Compiler、KnowQL、およびその他）はそれ自体が物語の一部であり、詳細については [Nexus の深掘り](https://www.pinecone.io/blog/knowledge-infrastructure-for-agents/) をご覧ください。 ## 移行プロセス 移行は評価基準の定義から始まりました。Nexus のビルドループにおいて明確な検索結果が必要だったからです。V1 では明確な契約が存在せず、エージェントが単に 6 つのツールからコンテキスト拡張を駆動し、それらを自身で結合していました。 私たちは V1 の本番環境のトレースから評価セットを構築しました。各質問には完全な呼び出しログが含まれており、エージェントがどのツールを発火させたか、各ツールの戻り値、そして最終的に SQL を記述するために使用されたチャンクが記録されています。各質問に対して、エージェントが最初の試行で正しい SQL を取得できたであろう最小限のコンテキストペイロードを抽出しました。これらのペイロードが評価セットにおける期待される出力となりました。この評価セットは、Nexus のビルドループが最適化を目指す対象です。 Sample Eval Question: 翻訳全文 私は、ある月におけるエンタープライズプラン顧客とスタンダードプラン顧客から生じた最低料金収益の分析を行うための正しい BigQuery SQL クエリ（SQL）を作成するために、包括的なコンテキストを必要としています。 関連する情報をすべて構造化された Markdown 形式で返してください： 1. **テーブル**: 使用するべきテーブル（analytics.table_name のような完全名称） 2. **主要カラム**: 役割とともに必要なすべてのカラム 3. **方法論**: SQL スニペットを含む計算ロジック 4. **アンチパターン**: 誤った例と正しい例を伴う一般的なミステイク 5. **除外/フィルタ**: 必須の WHERE クラース 網羅的に記述してください。SQL コードブロックを含めてください。このコンテキストが SQL の正しさを直接決定します。 計画は単純明快でした：異なる検索目的を担う2つのNexus Contextsを構築することです。1つはセマンティック層（スキーマ、dbt ソース、SQL パターン）用、もう1つは顧客コンテキスト（Slack スレッド、Gong 通話の文字起こし）用です。 6 つの検索ツールを 2 つに置き換えてください：search_semantic_layer と search_customer_context です。Curator エージェントを削除し、その KB（知識ベース）修正機能を、Nexus へ修正を送って知識を更新する単一の semantic_layer_feedback ツールに置き換えてください。ETL を再設定して、レガシーの Pinecone インデックスごとに専用のカスタムパイプラインを用意するのではなく、最小限の前処理と変換で Nexus Contexts にフィードソースを供給するようにしてください。 3 週間後、V2 は回帰セットにおいて V1 と完全に同等の性能に達しました：**両者とも 68.3%**です。このセットは 14 のビジネスドメインにわたる 101 の質問で構成されており、AskData を内部ベンチマークするために使用する、文脈が重く難しいケースに重点を置いています。今回の移行の目的は精度を上げることではありませんでした。目標は、予算の僅かな一部で同等の精度を達成し、その基盤となる Nexus を検証することでした：より少ないトークン、より少ないコード、そしてこのようなシステムを最初に構築するための所要期間が大幅に短縮されることです。 私たちはさらに 3 つ目のベースラインも測定しました：dbt リポジトリを指し示され、bq CLI を与えられた、新鮮な Claude Code セッションです。KB も Nexus も AskData ツール類もありません。 14 のドメインにわたって層別化された 20 の質問において、これは V1/V2 と同等の精度（68.3%）を達成しました。しかし、その代償は大きかったのです：質問あたり平均入力トークン数は約 625K（V2 の約 16 倍）、対話ターン数は 21（V2 の約 4.6 倍）、質問あたりのコストは$0.35（キャッシュを正規化した場合、V2 の約 5 倍）でした。この「方向転換税」は現実的なものです。有能なコーディングエージェントであっても正解を見つけることはできますが、各質問ごとに生 SQL から文脈を再構築することが、そのコストを生む原因なのです。 **指標****V0（Claude Code 生）**`**V1****V2****V0 → V2** 質問あたりの平均入力トークン数〜625,28764,00839,595**-93.7%** 質問あたりの平均ターン数〜214.54.6**-78%** 質問あたりの平均コスト$0.35$0.20$0.07**-80.2%** ## 数字が実際に意味するもの ステップごとの視点こそが、構造的な変化の現れる場所です。 V1 では、検索後の最初の LLM コールは平均して約 10,000 の入力トークンを要し、p25〜p90 の範囲も広かったです。すべての質問に対して、連結された検索チャンクのサイズが異なる山のようなコンテキストが与えられていました。一方 V2 では、同じコールで平均 6,000 トークンとなり、範囲は非常に狭くなりました。すべての質問に焦点を絞った一貫したコンテキストが提供されます。ステップ 3 になると、V1 は 21,000 トークンに対して V2 は 10,500 トークンでした。この複合的な効果が、入力トークンの 38% の削減につながっています。 出力トークンは 22% 増加しました。エージェントは実行ごとに SQL をより多く記述するようになりました（平均 1.8 クエリに対し、V1 は 1.3）。これは、予算を方向付けに費やすのではなく、すぐに SQL を記述できるコンテキストを持っていたためです。 **単純な照会**: 日次収益ランキングに関する質問。V1 では 4 ステップで 74,000 トークンを消費しました：3 つの並列検索により 10,000 トークンの生 KB が注入され、get_schema コールが 478 カラムの JSON を返した結果、SQL 実行前にコンテキストは 30,000 トークンを超えました。一方 V2 では 3 ステップで 11,000 トークンを消費しました：search_semantic_layer が、正確な列名、日付カラム、内部組織を除外するためのフィルタ、末尾ウィンドウ変種に関するアンチパターン警告、および例クエリを含む 1,200 トークンの要約を返します。get_schema は不要でした。同じ回答に対して予算は 7 分の 1 です。 **マルチステップパイプライン質問**: 以前のピポラインに関する質問。V1: 240,000 トークン、9 ステップ、データモデルの発見に 4 回の SQL 試行が必要でした。V2: 35,000 トークン、5 ステップ、2 回の SQL 試行。Nexus はステップ 0 で正しいマートテーブルを直接特定し、加重パイプライン数式（weighted-pipeline formula）を提供し、適切なステージフィルタも付与しました。1 つの SQL がタイプミスで失敗しましたが、エージェントが修正しました。 **非構造化コンテキスト認識**: SQL のみでは回答できない質問のクラスがあります。「なぜこのアカウントの利用量が減少しているのか？」という問いです。スキーマベースのセマンティックレイヤー（semantic layer）であればクエリは正しく実行できますが、真の説明は非構造化ソースにあります。search_customer_context は、サポートスレッドと Gong の通話記録を提示し、アカウントがポッドからサーバーレスへの移行途中にあること、そして実際の利用量減少は健全で予期されたものであることを示します。*構造化された数値だけでは異常を示唆しますが、非構造化ソースがビジネス上の意味を文脈化します。* ## 削除こそが重要である Curator エージェント（2,194 ライン、9 つのツール、独自のシステムプロンプト）は消滅しました。234 件の手動キュレーションされた KB ファイルは Nexus のキュレーションアーティファクトとなりました。KB 生成スクリプトは Nexus のビルドプロセスに置き換えられました。Airflow ETL はレガシーな Pinecone インデックスの代わりに、Nexus コンテキスト（Contexts）を供給するために再利用されました。3 つのリポジトリ全体で 25,000 ラインが削除されました。エージェント自体も小型化され、ツールの数は 22 から 10 に減少しました。 私たちが撤廃した主な点は以下の通りです： **一度コンパイルすれば、何度も読み込める。** クエリ実行時の合成からコンパイル時への移行により、入力トークンの削減率が 38% に達しました。Nexus はエージェントにブリーフィングを提供するために約 8,000 トークンを一度だけ使用しますが、これにより後続の処理で約 24,000 トークンが節約されます。およそ 3:1 の比率です。 **ツールを減らし、エージェントを強化する。** エージェントの意思決定ツリーにおいて、公開される各ツールは分岐点となります。6 つのツールを 2 つに集約することで、入力トークンのばらつきが約 4 倍削減されました。選択肢が減り、より良い選択が可能になり、実行あたりの SQL が増加します。 **キュレーションは反復的に行われ、エージェントもそのプロセスに参加する必要があります。** 単発の構築では、数ヶ月にわたる人間の熟練による改良には及びません。漸進的なキュレーションとエージェント主導のフィードバックにより、Nexus は知識ベース（KB）が持っていたのと同じ品質向上のラッチ効果を得ています。 **構造化データは「何が」を伝え、非構造化データは「なぜ」を伝えます。** ウェアハウスは数値を提供しますが、その背後にあるビジネス上の理由（例えば、ある指標がなぜ低下したのか、ARR は実際にどのように定義されているのか）は非構造化ソースに存在します。AskData の精度は、これらの非構造化ソースを第一級の入力として扱い、データの知識層を構築することによって実現されました。 V1 では、有能な社内データエージェントの実現可能性と、それが企業の意思決定のあり方を変えることが証明されました。V2 では、管理された知識層（knowledge layer）の下に構築することで、そのエージェントの構築と維持が数ヶ月にわたる個別プロジェクトである必要がないことが証明されました。精度は同じまま、トークン使用量は 3 分の 1、コードも簡素化されています。 ## 自分自身で構築する この手法を試せるデモを公開しました。 [nexus-analyst-demo](https://github.com/pinecone-io/nexus-analyst-demo) は、エージェントの簡易版であり、1 つのリポジトリ内に 2 つのエージェントが含まれています。 - agent-nexus/ は Nexus バージョンです。検索ツールは 1 つ（nexus_query）のみで、エージェントが Nexus コンテキストに対して自然言語で質問し、集約されたブリーフを取得します。 - agent-classic/ はベースラインです。単純な Pinecone ベクトルインデックス上で 3 つの検索ツール（search_schema, search_docs, search_notebooks）を使用し、手動によるチャンク分割とソースごとのフィルタリングが行われます。これは移行前の AskData のおおよその形状に相当します。 それ以外では両エージェントは同一です：同じループ、同じ SQL エグゼキューター、同じチャートおよびファイルツール、そして同じ Gemini 推論を使用しています。唯一の違いは検索基盤（retrieval substrate）のみです。 コンパニオンリポジトリ [nexus-analyst-demo-ingest](https://github.com/pinecone-io/nexus-analyst-demo-ingest) はデータ側の役割を担います。ここでは、ナレッジレイヤーのために Nexus をどのように準備したかを示しています。架空の SaaS 企業である Acme から、構造化された倉庫データと非構造化された組織知識（Slack のスレッド、Gong スタイルのトランスクリプト、ランブック、ポストモーテム）を組み合わせて Nexus コンテキストを構築します。 2 つのスクリプトが並列して配置されています。`upload_to_nexus.py` は、ソースデータ、評価セット、および `build.md` を用いて Nexus コンテキストをエンドツーエンドで構築し、`index_pinecone.py` は同じソースデータをチャンク化して、クラシックなエージェント用のプレーンな Pinecone インデックスを作成します。両方のパイプラインが 1 つのリポジトリ内に収められています。Nexus 側のコードは、接着剤的な処理を含めても 1,000 行未満です。ソースごとの ETL（Extract-Transform-Load：データ抽出・変換・読み込み）を調整する必要もなく、チャンキング戦略の最適化や埋め込みモデルの選定も不要です。Nexus にソースデータ、評価セット、ビルド仕様を手渡すだけで、コンテキストコンパイラが残りの処理を行います。 30 問の難易度の高い多段階質問（シグナ値の罠、スキーマドリフト、Acme の倉庫を跨ぐクロスソース結合など）からなる評価セットを用いて両エージェントを実行し、その差を直接的に浮き彫りにします。 実際に試したい場合は、[https://nexus-analyst-web.vercel.app/](https://nexus-analyst-web.vercel.app/) でライブデモを確認できます。質問を選択すると、ベースラインのエージェントが呼び出しごとに複数の検索を組み合わせて文脈を再構築する様子と、Nexus エージェントがそれを 1 回の処理で完了させる様子を比較してご覧いただけます。 もし、ご自身の内部システム向けにこのようなものを構築したい場合は、[Pinecone Nexus の早期アクセスに登録](https://www.pinecone.io/lp/nexus-ea-structured-data/)してください。

AskData の内部：トークン消費量を 90% 以上削減した方法

背景や根拠まで確認しますか？

調べる

選ぶ

サイト