より優れたモデルがエージェントを救うわけではない

今日、本番環境でエージェントを構築している誰もが同じ壁にぶつかったことがあるでしょう。モデル自体が制限要因となることは稀です。最先端のモデルは、必要な業務のほとんどに対応できる推論能力を持っています。問題が生じるのは、推論ステップに至るまでのプロセス全体です。エージェントはタスクを受け取り、情報が必要だと判断し、検索し、結果を取得・評価します。さらに情報が必要だと判断して再度検索し、読み込み、断片的な情報を組み合わせて部分的な像を構築し、ループします。モデルが回答を生成できる状態になる頃には、トークン数とレイテンシの予算のほとんどはすでに消費されてしまっています。

これが現在、エージェントインフラを定義するギャップです。この問題を中心に形成された分野が「コンテキストエンジニアリング」です。これは、クエリ実行時に生データから再構築させるのではなく、モデルが利用可能な知識としてデータを整形するアプローチです。

これらのコンテキストパイプラインを実装する際にチームがつまずくことが多く、特に実在する企業では、営業、法務、財務、サポート、研究開発、運用など、各ドメインに必要なコンテキストの形状が異なるため困難を極めます。ドメインごとに手作業で1 つずつコンテキスト層を構築する方法は、最初の 1〜2 つを超えてスケーリングできません。

私たちは過去 1 年間、この課題に取り組んできました。本稿の後半では、なぜこれが難しいのか、私たちが何を開発したか、そして次に何が来るべきだと考えているかを解説します。

具体的な例：市場インテリジェンスエージェント

投資会社における S&P 500 の 10-K 提出書類を分析する市場インテリジェンスエージェントを考えてみましょう。この質問は、エージェントが回答する必要のある数十の質問の一例です。

「NVIDIA、Microsoft、Walmart の各社について、それぞれの 10-K に開示された財政年度 2022 の自社株買い活動を比較してください。各企業について、(a) その財政年度における自社株買いのドル額と買戻し株式数、(b) 開示されている場合の当初プログラム承認規模および承認日、(c) 同社の財政年度末時点での残存承認枠を明記してください。」

このエージェントを実環境に導入するためには、コンテキスト層が以下の 4 つの要件を満たす必要があります:

• 精度: 正解であり、実行ごとに再現可能であること。70% の確率で正しいだけのカスレる（不安定な）エージェントは、実務上は機能しません。
• タスクレイテンシ: クエリは秒単位で完了し、数十秒や分単位ではなりません。
• トークンコスト: 1 回あたりのコストに上限があり、ワークフロー全体でエージェントの請求額が複利計算されることはありません。
• ガバナンス: フィールドレベルでの権限強制と、回答の出所を遡れる根拠ある出典情報の保証。

しかし、これら 4 つを同時に満たすことは、聞こえほど簡単ではありません。このようなエージェントワークロード向けのコンテキスト層を構築する際、チームは通常、1 つのチームを専任させ、数ヶ月にわたる反復作業を通じて、以下の 2 つのパターンのいずれかに注力します:

• Agentic RAG：10-K コーパスをチャンク化し、埋め込みを行い、ハイブリッド検索を利用する。エージェントにループ処理を行わせ、クエリを実行し、再ランク付けを行い、上位のチャンクを読み込み、回答に満足するまでループさせる。
• サンドボックス内のコーディングエージェント：ファイル一覧表示、ページ読み取り、grep 検索、全文書読込などのツールへのアクセスをエージェントに与え、ループ処理を行わせる。各 10-K ファイルを開き、資本収益セクションへ移動し、表を解析して回答を抽出する。

両方のアプローチは最終的に正しい答えに到達する可能性はあるが、実装するには通常、あまりにも遅く高価である。どちらも同じ根本的な課題を抱えている：各タスクに対してクエリ実行時に知識を組み立てさせようとしている点だ。Agentic RAG はエージェントにチャンクを渡し、回答をつなぎ合わせるよう求める。Agentic Sandbox はファイルを与え、検索、grep、解析を通じて回答へナビゲートするよう求める。これらのアプローチでは、作業の大部分が生データの取得と適切な文脈の構築に費やされ、推論にはほとんど使われない。

手動設計されたコンテキストからコンパイル済み知識へ

このような問題に対する解決策はよく知られている：消費者がクエリごとに構造を導出させないことだ。データに対して、消費者が関心を持つ構造をすでにエンコードした*アーティファクト*として事前に整形し、それらを提供することである。

これは新しい話ではありません。知識グラフ、エンティティカタログ、セマンティックレイヤーは数十年も前から存在しています。データインフラの各世代は、常に同じ直感に基づいたある種のバージョンを提供してきました：方向付け作業を一度行い、その結果を保存し、下流の消費者が直接それを読み取れるようにするのです。コンテキストエンジニアリングは、この直感の最新バージョンであり、現在はダッシュボードではなくエージェントに適用されています。

破綻する場所：ドメインごとの運用化

難しいのは概念そのものではありません。それを運用化することです。

*一つの*ドメインのために優れたアーティファクトレイヤーを構築するには、洗練されたチームと数ヶ月にわたる反復が必要であり、どの特定のキュレーション戦略、検索設計、評価ハネス、ガバナンスフックを使用するかを決定する必要があります。複雑な点は、実際の企業には一つのドメインしかないわけではないということです。数十ものドメイン（例えば営業、カスタマーサポート、法務、財務、研究開発など）があり、それぞれが独自のデータ形状、スキーマ、方言、アクセスパターンを持っています。

数ヶ月にわたる反復を、エージェントを必要とするすべてのドメインで掛け合わせると、これらのパイプラインを構築するリソースはすぐに枯渇してしまいます。実際には、最も価値の高い一、二つのドメインのためにのみレイヤーが構築されるか、あるいは全く構築されないという結果になります。

これがアジェンシー（エージェント）時代の課題です。企業のすべてのドメインでエージェントが稼働し、すべてのエージェントに shipped するためのコンテキストエンジニアリングが必要となるのです。

新しい知識インフラストラクチャのカテゴリー

この問題は、コンテキスト層がドメインごとに手動調整・構築されるのではなく、ドメイン横断的に自動で動作する「インフラストラクチャとして機能する」新しいカテゴリーの知識インフラストラクチャを必要としていることを示しています。この層は既に存在しており、あなたはそれに対してプロビジョニングを行うものであり、新たなユースケースが発生するたびにゼロから再構築する必要はありません。

私たちは過去 1 年間、これを開発してきました。その名はPinecone Nexus。エージェント専用の知識エンジン（Knowledge Engine）です。

知識エンジンの内部構造

知識エンジンは、以下の 4 つのプリミティブ（基本要素）から構築されています。各要素は、下の要素を構成するものとの組み合わせによって成り立っています：

アーティファクト（Artifact）： 特定のタスクや成果のために構築された、型付けされ管理された情報の断片です。同じ 10-K データからでも、財務指標（収益、資本利得など）を必要とする市場インテリジェンスエージェントが取得するアーティファクトは、リスク要因の開示を必要とするコンプライアンスエージェントが取得するものとは異なります。それぞれの形状こそが、基盤となる表現を各エージェントの業務に最適化し効率的にする要素です。

コンテキスト（Context）： 特定の役割、チーム、またはワークフローのために設計された、アーティファクトの厳選されたセットです。アナリストの財務指標アーティファクトを、そのエージェントが必要とするナラティブセクション（MD&A、セグメント報告など）とバンドルしたものが、アナリストのコンテキストとなります。同様に、コンプライアンスチームにも独自のコンテキストが存在します。

知識。 企業内のすべてのコンテキストの集合体であり、アナリスト業務、コンプライアンス、M&A、ポートフォリオ監視などにおいてビジネスがどのように運営されているかを表します。知識に対するクエリは必要なだけ多くのコンテキストにまたがることができますが、ルーターはエンジン側で処理されます。

知識エンジン。 上記すべてを構築し提供するシステムです。その中核となるのは「Context Compiler（文脈コンパイラ）」であり、これは自律型コーディングエージェントとして、各ドメイン向けのキュレーションおよびクエリコードの記述と調整を行います。ビルドループが完了すると、生データからアーティファクトを構築し、それらをコンテキストに構成して、各エージェントの KnowQL クエリを提供します。

これは、市場インテリジェンスエージェント向けに 10k-SEC 提出書類を使用してコンパイルされた、企業レベルのアーティファクトの例です。

文脈コンパイラ

文脈コンパイラは、知識エンジンの中核をなす自律型コーディングエージェントです。タスク最適化された「Context（文脈）」を構築するために、コーディングエージェントと以下の 3 つの要素を組み合わせた「アジェンシー・ハーネスパターン」を採用しています：

• ドメインごとに定義する評価セット（既知の正解を持つ代表的なタスク）と、それに対応するデータソース
• 文書処理、エンティティ抽出、チャンク化などの事前検証済みスキルからなるライブラリ。エージェントはこれらのスキルを組み合わせてソリューションを構築します。
• 各イテレーションの評価信号に対してスコアリングを行うフィードバックループ。

このプロセスでは、コーディングエージェントが artifact construction（アーティファクト構築）用の curate() 関数と knowledge retrieval（知識検索）用の query() 関数の 2 つを修正し、評価セットを実行します。その後、失敗信号を用いてコードを改良し、評価に合格するまでこれを繰り返します。最終的な出力は、そのドメイン向けに動作し調整された Context です。

このアプローチにより、検索の専門知識がなくても、あらゆるドメインの専門家（リトリバル背景を持たない方でも）がエージェント最適化された Context を作成できます。なぜなら、スキーマや検索ロジック、アーティファクトの形状を事前に指定する必要がないからです。Context Compiler は評価結果に基づいて、適切なアーティファクト構造、粒度、および構築戦略を自動的に発見します。新しいドメインの多くは、既存のスキルを新たな方法で組み合わせることで対応可能です。もし何かが明らかに適合しない場合は、ライブラリに新しいスキルを追加します。

初期設計パートナーとの共同作業において、この Compiler は数ヶ月ではなく数日で新しいドメイン向けの Context を提供しました。まだ複数のドメインやエッジケースでの測定は継続中ですが、初期の信号は有望であり、私たちはこのハルネスベースのアジェンティックアプローチが知識インフラストラクチャの未来の基盤になると信じています。

KnowQL

コンテキストが作成された後、次のステップはエージェントがそれを効果的に活用できることを保証することです。もしエージェントが段落レベルの自然言語クエリを発行し、戻ってきたテキストの塊を解析しなければならない場合、各呼び出しで時間とトークンを消費して再方向付けを行うことで、以前の失敗がそのまま再発します。私たちは、エージェントが必要なものを「宣言」し、正確で型付き、引用付きの応答を受け取るようなインターフェースを望んでいました。それが KnowQL（Knowledge Query Language）です。

「宣言的」という部分が中核的な設計原則です。SQL では、必要なもの（例：結合、フィルタ、投影）を記述し、エンジンが実行計画を選択します。KnowQL も同じ考え方をエージェントによる知識検索に適用したものです。エージェントは、必要な答えをどのような形状で、どのような制約条件下で求めるかを指定します。Knowledge Engine がどのコンテキストを検索し、どのアーティファクトを読み取り、それらをどのように構成するかを決定します。

KnowQL クエリは、エージェントの生産要件を満たすために 4 つのカテゴリを組み合わせて構成されます：

• インテント：質問、レスポンスの形状、および対象となるコンテキスト。これは複数のコンテキストにまたがって構成される場合があります。
• フィルター：表面で強制される決定論的述語とアクセス制御ポリシー。エージェントが見られるのは、その呼び出し元が許可されている範囲のみです。
• 出所：構築時にフィールドレベルの引用として返され、後から再構築されるものではありません。すべての値にはそのソースが含まれます。
• コントロール：バジェットエンベロープ（深さとレイテンシ目標）。コストはトークン数ではなく結果に明記されます。

前述の S&P 10-K に関する質問に対する KnowQL クエリでは、エージェントが発行するクエリは以下のようになります：

{

"ask": "NVIDIA、Microsoft、Walmart のうち、2022 会計年度の自社株買いを比較してください：買戻し額、元のプログラム規模、および残りの承認額。",

"ground": true,

"shape": {

"type": "object",

"properties": {

"companies": {

"type": "array",

"items": {

"type": "object",

"properties": {

"company_name": { "type": "string" },

"repurchased_usd_millions": { "type": "number" },

"program_size_usd_millions": { "type": "number" },

"remaining_usd_millions": { "type": "number" }

}

}

}

}

}

}

エンジンが 1 つの型付きレスポンスを返し、エージェントの唯一の推論ステップは、すべての方向付け作業がビルド時に完了しているため、その型付きレスポンスオブジェクトを比較することだけです。

知識検索の影響を測定する

Nexus の価値を実証するためには、エージェントのパフォーマンスに対する知識検索の影響を定量化する必要がありました。既存のほとんどの検索ベンチマークは、単にリコール（再現率）のみを孤立して測定しており、異なる検索戦略がエンドツーエンドの多段階エージェントループに対して与える影響を比較していません。

このギャップを埋めるために、KRAFTBench (Knowledge Retrieval Assessment Framework for Text) を作成しました。このハーンチス（評価枠組み）は、一貫したコンポーザーモデル（claude-sonnet-4-6）から生成された応答の精度、レイテンシ、トークンコストを、異なる検索メカニズム間で測定します。これにより、エージェントタスクにおける品質、レイテンシ、またはトークンコストの違いは、すべて検索に起因するものとして特定できます。テストされた3 つの検索メカニズムは以下の通りです：

• コーディングエージェント：Claude-sonnet-4-6 に、読み取り専用のファイルシステムツールキット（list_files, read_file, find_filecontent, find_filename）を少量提供します。インデックスは用意しません。

• エージェント型 RAG：ファイルをチャンク化して Pinecone ベクトルインデックスに埋め込みます。クエリ拡張、RRF 融合、top-k 検索を利用し、完了と判断するまでループ処理を行います。

• Pinecone Nexus：Context Compiler を用いて生成されたアーティファクトです。各質問ごとの形状は Claude によって導出され、KnowQL クエリとしてフォーマットされ、必要に応じて多段階質問に対するフォローアップ要求も含まれます。

これらのエージェントは、S&P 500 企業の 2022 年 SEC 提出書類から抽出された 493 の自由記述形式の 10-K ファイル（各ファイル約 500KB、合計約 245MB）に対してテストされました。各エージェントには、9 つのセクターと 10 の財務トピック（従業員数、収益、資本支出、資本還元、研究開発、買収、セグメント内訳など）にまたがる 150 の難問への回答が課されました。これらの質問は、3 つの難易度形状でタグ付けされています：マルチファクト（同一エンティティに関する 2 つ以上の事実を組み合わせる）、マルチカンパニー（2 つ以上のエンティティ間で比較する）、マルチステップ（事実 A を取得し、それに基づいて事実 B を導出する）。

各質問には 120 秒の時間制限と 1M トークンのトークン制限が課され、各エージェントは確定的な回答ができるか制限を超すまで反復処理を行います。最終的な回答は、評価セットの正解出力に対して LLM ジャッジ（Claude-sonnet-4-6）によって精度が評価されます。

私たちの発見

3 つのアプローチを比較するために、各エージェントの平均レイテンシ（x 軸）と平均精度（y 軸）をプロットし、バブルサイズで完了率を表しました。目指すべきは左上の領域です。すなわち、高速かつ高精度であることです。Nexus は、最も低いレイテンシで、最も高い精度と完了率を実現しました。また、トークンコストも大幅に低く抑えられており（RAG と比較して約 7 倍、コーディングエージェントと比較して約 80 倍）です。Agentic RAG はほぼすべての質問を完了しますが、精度は低く、レイテンシは約 1.7 倍になります。一方、コーディングエージェントは最も遅く、信頼性が最も低いものでした。精度は中程度ですが、レイテンシは約 4 倍で、トークン予算または制限時間（wall-clock cap）に達する前に完了できたのは質問の 63% だけでした。

完了率 | 平均レイテンシ | 平均精度 | 平均トークン数 | 平均ステップ数

---|---|---|---|---

Pinecone Nexus | 100% (150/150) | 22.7 秒 | 0.68 | 6,733 | 1.69

Agentic RAG | 98.7% (148/150) | 37.9 秒 | 0.41 | 349,103 | 7.77

コーディングエージェント | 62.7% (94/150) | 84.1 秒 | 0.58 | 528,301 | 14.77

最も困難な質問には、複数企業の比較や多段階の推論チェーンが必要とされるものが含まれており、各エージェントの失敗モードはトレース（traces）において明確に現れています。

• Pinecone Nexus は、複数エンティティの比較や多段推論を容易にするために、企業レベルの「ファクトシート」アーティファクトをコンパイルします。関連するアーティファクトのセットを見つけ、1 回のパスで回答を組み立てます。
• エージェント型 RAG（Retrieval-Augmented Generation）は各質問を複数のリクエストに分解しますが、意味的類似性のみで検索する場合、各リクエストは情報の欠落または部分的な返答しか行いません。
• コーディングエージェントは grep を使用してテキスト内のキーワードを特定しますが、フレーズは各ドキュメント内で複数回出現する可能性があり、どの言及が正しいかを判断する方法がありません。その結果、予算または時間が尽きるまで曖昧さを解消しようとしてトークンの大部分を費やしてしまいます。

これをより具体的に示すために、財務エージェントに投げかけた元の質問の経路を追ってみましょう：

「NVIDIA、Microsoft、Walmart のうち、各社の 10-K に開示された財政年度 2022 年の自社株買い活動を比較してください。各社について、(a) 財政年度中の自社株買いのドル額と買戻し株式数、(b) 開示されている場合の当初プログラム承認規模と承認日、(c) 同社の財政年度末時点での残存承認額を明記してください。」

コーディングエージェント： コーディングエージェントは、「share repurchase」または「Microsoft」または「Walmart」という広範な正規表現スキャンから始め、コーパス内のすべての 10-K で数百件の一致を検出します。エンティティ名でさらに絞り込むと一致件数が増え、すぐにコンテキストウィンドウを埋め尽くし、最終的に 1M トークンの制限に達します。

Agentic RAG: エージェントはまずクエリを 18 の事実へと分解し、各事実に対して返された上位 k 個のチャンクを検索・評価します。しかし、ドキュメント内で金額数値とチャンクが同一場所に配置されていなかったため、マイクロソフトとウォルマートの金額を見つけることができませんでした。その結果、データが存在するにもかかわらず、それらの数値を欠落していると誤ってマークしてしまいました。

Pinecone Nexus: 完全な質問と所望の構造化出力形式を受け取り、一発で完了させます。これは、Nexus が各企業の主要統計を要約したアーティファクト（成果物）を生成するためです。また、トークン使用量を最小限に抑えるため、構造化された応答結果を JSON オブジェクトとして提供しました。

今後数週間で、KRAFTBench に関する詳細な解説記事を公開し、この手法と結果をより詳しくご紹介します。このベンチマークへの共同参加に関心がある場合は、こちらからお問い合わせください。

ソースから知識へ：Box → Unstructured → Pinecone のネクサス

Nexus を実際のエンタープライズデータで使用するために、重要なスタックの一部を所有する 2 つのエコシステムパートナーと統合しました。1 つはBoxで、ソースドキュメントとその権限が保管される場所です。もう 1 つはUnstructuredで、生のフォーマット（PDF や Word ドキュメント）を Nexus が直接消費できる構造化フォーマットに正規化する役割を果たします。

例として、Box に保存された CUAD データセット の契約書群を検証する法的レビューエージェントが、以下の質問をしたいとしましょう：

「固定の初期期間はあるが自動更新メカニズムがなく、延長には当事者が積極的に交渉する必要がある契約はどれか？」

Box（ソース）： 契約書は、非競争条項、商業契約、承認書など、指定された Box フォルダに保存されます。アクセス制御リストを含むファイルメタデータにより、権限が尊重されるように保証されています。契約書の維持と更新は法務チームの責任です。

構造化されていないデータ（パース）: Unstructured は Box の API を通じて接続し、各ファイルの内容とファイルメタデータ（ACLs を含む）をキャプチャします。法的契約書から主要なドキュメント要素、テーブル、エンティティ（parties\verb|parties|, agreement_date\verb|agreement_date|）を抽出し、ユーザーがアクセス権限を持つ契約書のみを表示できるようにするために、ファイル許可メタデータ（permission_data\verb|permission_data|）を渡します。

Pinecone Nexus（ナレッジエンジン）: Unstructured によるパース結果がソースとして取り込まれ、抽出されたデータに対して Context Compiler が実行されます。その生成物の一つは、異なる契約書にわたる契約更新条項を集約したテーブルであり、これにより Nexus は複数のエンティティを検索するのではなく、単一のアーティファクトを取得することで質問に応答できます。クエリを構成する際、ユーザーがアクセス権限を持つ契約書のみに応答するようにするために、ファイル許可メタデータをフィルターとして渡します。

このシンプルな例は、Nexus が既存のデータパイプラインとどのように連携するかを示しています：Box が真偽情報のソースおよびファイル権限を管理し、Unstructured が解析と抽出を担当し、Nexus がアーティファクト層とクエリ表面を担います。同じ契約である Context は、法務部門向けの契約レビューエージェント、営業部門向けの更新リスクエージェント、GC 事務所のコンプライアンスエージェントなど、Box にある同一のソースコンテンツから構築された多様なエージェントに対してサービスを提供できます。

新しいカテゴリであり、より優れたパイプラインではない

本記事では、能力のあるモデルとそれらを支えるインフラストラクチャとの間のギャップについて言及しました：エージェントの努力の大部分は推論ではなく、状況把握（orientation）に費やされています。このギャップが、エージェントを大規模に導入できるかどうかを決定し、これを埋めるには新しいカテゴリのインフラストラクチャが必要です。

そのカテゴリとは知識エンジンです。私たちは、企業のあらゆるドメインがエージェントによって稼働し、各エージェントが自身のために設計されたコンテキストを必要とする未来へと進んでいます。ドメインごとに手作業で 1 つずつコンテキスト層を構築することはスケーラブルではなく、この需要に対応する唯一の方法は、インフラストラクチャ自体が自律的（agentic）であることです。Nexus はそのビジョンの具現化であり、Pinecone が長年構築してきた検索基盤上で動作する自律的な「コンテキストコンパイラ」です。エージェントが必要とする精度、レイテンシ、コストのために共同設計されています。

私たちは Pinecone を立ち上げる際、単一のミッションを掲げました：*AI に知識を持たせること*です。Nexus によって、そのミッションは具体化されます：あなたの企業のあらゆるチームに所属するすべてのエージェントが、自身のためにコンパイルされた知識（Knowledge）に基づいて動作します。

Pinecone Nexus Early Access

Nexus は本日、限られた数のデザインパートナー向けに早期アクセス版として利用可能です。次世代のエージェントを支える知識エンジンとの共同設計に関心がある方は、Nexus 早期アクセス に応募してください。