Skills 静的注入 96.0% vs RAG 都度検索 87.3%——精度で選ぶ前に見る請求書

エージェントに社内知識を渡す方法は二つあります。必要になったら取りに行かせるか、 最初から渡しておくか。松尾研究所が 135 回の実測でこの二つを比べた結果、静的注入が 96.0%、都度検索が 87.3% でした。 ただし静的注入した分は毎リクエスト課金されます。

精度で決める話に見えて、実は請求書の話でもある。そして同じ実験には、精度の数字より 重要かもしれない別の数字が入っています。

実験を数字どおりに読む

まず何が測られたのか。15 課題 × 3 条件 × 3 試行 = 135 の回答です。

（原文どおり、入力トークンは平均、応答時間は中央値。指標が揃っていない点は そのまま引き継ぎます。）

静的注入は都度検索に対して精度で 8.7 ポイント上、応答時間 36% 短縮、 平均入力トークン 78% 減。一見すると全項目で勝っています。

そして請求書の観点で最も効くのは、実は一番上の行との比較です。何も渡さない条件 （41.9k）と Skills（48.6k）の差は 6.7k トークンしかない。 正答率は 33.0% → 96.0%。 知識を渡すこと自体が高いわけではない——高くなるのは渡し方のほうです。

ここで止まらないでください。同じ記事は、Skills 条件でも回答の 15.6% が critical 項目を 1 件以上落としていると報告しています（原文の Critical failure rate の定義がこれ—— 分母は項目ではなく回答で、1 件でも落とせばその回答は失敗として数えます）。 96.0% という総合値の裏に、この内訳がある。 著者はこの区別のために評価設計そのものを作り直しています——一問一答型では測れないと判断し、 自由回答型 + 項目別 Rubric に切り替え、さらに critical 項目を分離した。 「文章は整っているが実行すると危険な回答」を、正答率という一つの数字に溶かさないためです。

この設計判断のほうが、96.0% という数字より応用が利きます。総合正答率だけ見ていると、 最も避けたい失敗が最も見えにくい。

何が測られていないか

著者は限界を自分で明示しています。引用する側がこれを落とすと、数字の意味が変わります。

• 統計的検定は行っていない。 135 回は手法差の傾向を見るには有用でも、 信頼区間や有意差の議論はされていません。33.0 / 87.3 / 96.0 は観測値であって、 母集団の推定値として提示されたものではない。
• この組織のドメイン固有の数値であり、一般化された精度ではありません。 自社で同じ差が出る保証はない。
• 測っているのは回答の質で、作業の成否ではない。 原文は「実際に経費申請を作成した、 権限を変更した、リポジトリを移行した、といった業務結果は測っていません」と明記し、 15 件という規模も「チームの業務全体を網羅する規模ではありません」としています。 採点自体も LLM に行わせており（LLM-as-a-judge）、ドメイン専門家のレビューは入っていません。

つまりこの実験が示したのは「Skills が正解」ではなく、「この条件下でこの差が観測された」 です。持ち帰るべきは数字ではなく、測り方のほうだと思います。

静的注入の請求書

ここからがゲートウェイ側の話です。

静的注入が入力トークンを 78% 減らしたのは、Notion 都度検索が検索結果を丸ごとコンテキストに 積んでいたからで、注入そのものが安いからではありません。注入した知識は毎リクエスト 入力トークンとして課金されます。 呼び出し回数が増えれば、固定費が回数分だけ掛かる。

だから二つの方式の損益分岐は、精度ではなく呼び出しパターンで決まります。

最後の二行が実務では効きます。少し補足すると——多くの API にはプロンプトキャッシュが あり、リクエストの先頭から一致する部分を再利用すると入力トークンが割引されます （割引率と有効期間は各社の公式ページを参照）。効くのは「先頭から」という条件で、 ここに二つの方式の差が出ます。静的注入はコンテキストの先頭が毎回同じになるので一致しやすく、 都度検索は検索結果が毎回違うので先頭が崩れる。

だからキャッシュヒット率次第で、注入の固定費は実質的に大きく下がります。 逆にヒットしなければ、78% 削減した入力トークンを毎回定価で払うことになる。同じ構成でも 請求額が変わるのはここです。ヒット率は各社のレスポンスに含まれるトークン内訳 （キャッシュ読み出し分が別項目で返る）から集計できます。

更新については、原文の運用がそのまま答えになっています。Skills は手動更新せず、 Notion から別の AI Agent が自動生成する。 静的注入を選ぶということは、 生成パイプラインを一本持つということです。この運用コストは精度の表には出てきません。

工程ごとにモデルを分ける、というもう一つの解き方

同じトレードオフをコスト側から解いた例が、同じ週の Docker Agent 採用記にあります。 「どこで払うか」の判断は、知識の渡し方だけでなく工程の分け方にも現れる——という話です。

十数体構成のエージェントチームで、モデルは二段階に振り分けられています。設計・実装などの 重い工程は gemini-3-flash（main）、抽出・レビュー・定型処理は gemini-3.1-flash-lite （lite）。著者の言葉が的確です。

十数体規模になると、この差がそのまま API 料金の差になります

もう一つ、本稿の主題に直結する設計がこの構成にあります。進捗を tasks ツールへ 外部化し、コンテキストが切れても list_tasks で復帰できるようにしている点です。

コンテキストを外に出す設計は、そのままトークン費用の設計でもあります。 進捗を context に載せ続ければ毎回払う。外部ツールに置けば、必要なときだけ取りに行く。 これは冒頭の「毎回取りに行くか、先に渡しておくか」と同じ判断を、別のレイヤーで 行っているだけです。

ツール一覧そのものが課金対象になる

MCP のロードマップも同じ問題を 別角度から挙げています。ツールを大量に繋ぐと、ユーザーが質問する前にモデルがカタログ全体分を 支払うことになる、という問題設定です。

現場の対処は既に出ていて、HN のスレッドでは OpenAPI の tag で分類して 1 回に最大 10 endpoint だけ返しページングする方法や、 専門サブエージェントに部分集合だけ持たせる方法が挙がっています。どちらも 「全部渡す」をやめる方向で、本稿の二択と同じ構図です。

なお、ゲートウェイ実装の側から同じロードマップを読んだ記事を英語版で出しています—— The new MCP roadmap hands two jobs to your gateway。 こちらは前段のインフラが何を引き受けるかの話で、本稿とは切り口が違います。

ゲートウェイから見た三つの計測点

「Skills が正解」でも「RAG が正解」でもない、というのが結論です。測らないと分からない。 そして多くのチームは今それを測れていない。

測るべきは三つ。

1. 注入トークン量 — リクエストあたり、固定で乗っている分は何トークンか。 これが分からないと、静的注入の固定費が見積もれません。
2. キャッシュヒット率 — 注入分がキャッシュに乗っているか。ここが低いまま静的注入を 選ぶと、方式のメリットを払い出してしまいます。
3. モデル別コスト — 工程ごとに分けているなら、その内訳。分けた効果は内訳がないと 確認できません。

この三つはアプリケーション側からは見えにくく、ゲートウェイ層には全リクエストが通ります。 PiRouter では 1 と 3（注入トークン量・モデル別コスト）をリクエスト単位で計測可能にする 設計として進めています。2 のキャッシュヒット率は正直に言って難しく、まだそこまで 行っていません——理由は供給側にあって、キャッシュの粒度も有効期間も返し方も各社バラバラ だからです。横断で一つの「ヒット率」にまとめると、数字は出ますが比較できない数字になる。 現在の機能はドキュメントを参照してください。

ただし、この三つを測るのに専用の仕組みは要りません。ログにトークン内訳が出ているなら、 今日から集計できます。先に測って、それから方式を決める——順番が逆になっているチームが 多い、というのがこの記事の本題です。

まとめ

135 回の実測は良いデータですが、読み方には三つの注意が要ります。統計的検定を経ていないこと、 ドメイン固有であること、作業完了型は未評価であること。そして総合 96.0% の裏で、 6 回に 1 回近い回答が、安全性に関わる項目を落としている。

そのうえで、静的注入を選ぶなら請求書側の準備が要ります——注入分は毎回課金され、 キャッシュヒット率が実質コストを決め、更新には生成パイプラインが要る。 精度の表には出てこない三つです。

関連記事：エージェントに渡す鍵の形（同じエージェント運用でも、 こちらは認可の話）。