この記事をシェア
「見つからない」には理由がある
ある日、社内ヘルプデスクの自動化に取り組むエンジニアの佐藤さんは、頭を抱えていました。
導入したばかりの最新 RAG（Retrieval-Augmented Generation）システムが、ユーザーの「ドメインの設定方法を教えて」という質問に対し、あろうことか「ドメインの解約方法」のドキュメントを最上位に持ってきたからです。
「ベクトルの類似度は高いはずなのに、なぜ文脈を読み違えるんだ？」
これは RAG を本番で運用したことがある人なら、一度は通る景色だと思います。チャンクサイズを刻み直し、埋め込みモデルを差し替え、ベクトル DB を別製品に乗せ替え、リランカーを差し込み、プロンプトを書き直す。少しは改善するものの、ある一定の精度から先に進めない。私が現場でよく 「断片化の壁」 と呼んでいる現象です。
本記事ではまず、「なぜ RAG が頭打ちになるのか」を構造として整理したうえで、その別解として 2026 年に登場した Corpus2Skill の考え方を解説していきます。具体的な環境構築や Python コードによる実装手順は 後編：徹底実践ガイド にまとめていますので、まずは本記事で「どんな場面で効くのか／効かないのか」をつかんでいただければと思います。
この記事は、こんな現場のための話
Corpus2Skill は、すべての検索を置き換える銀の弾丸ではありません。ただ、ある種の現場に対しては、これまでの RAG では届かなかった精度を出してくれます。まずは「自分の現場に関係がある話なのか」を見極めるところから入りたいと思います。
向いている読者・ユースケース
- 社内文書検索を本気でやりたい情シス・社内 DX 担当：規程・通達・運用手順といった、章立てと条件分岐がはっきりある文書群を扱っている方。
- カスタマーサポート自動化を進めているプロダクトチーム：プラン・契約・課金・解約など、似た言い回しが大量に並ぶ FAQ／マニュアルを扱っている方。
- 金融・医療・公共など、規約や仕様書を厳密に追う必要がある業務：「なぜその回答になったのか」を相手に説明できる必要がある方。
- すでに RAG を本番投入しているが、精度の頭打ちに悩んでいる開発者：チャンクサイズ・埋め込みモデル・ハイブリッド検索といったチューニングを一通り試した方。
- AI エージェントに「複数手順を持つタスク」をやらせたいエンジニア：単発の質問応答ではなく、手順を追って意思決定するワークフローを組みたい方。
逆に、向かないケース
- 単純な一問一答 FAQ：質問と回答が 1 対 1 で対応している数十件規模のものは、素朴な RAG や全文検索でも十分です。スキルツリーを組む手間に対して得るものが薄くなります。
- 文書数が極端に少ないケース：百ページ未満であれば、コンテキストウィンドウに丸ごと入れてしまうほうが早く、正確で、運用も楽です。
- 最新ニュースやリアルタイム情報の検索：日々更新される時系列情報は、検索エンジンや RSS、あるいは外部 API の方が素直に扱えます。
- 非構造データ中心のユースケース：チャットログや SNS 投稿のように、章立ても階層もないテキスト群は、ナビゲーション型の強みが出にくい領域です。
言い換えると、Corpus2Skill が効くのは 「構造のある文書群」 × 「正確さが求められる業務」 という掛け算の領域です。逆側にあるものに無理に当てはめても、コンパイル時間と運用負荷の割に得るものが少なくなります。
RAG が行き詰まる 4 つの構造的な理由
「もっとチューニングすれば RAG でいけるのでは？」と感じる方も多いと思います。実際、ある程度までは確実に改善できます。ただ、ある一線を越えると、それは技術的な詰めの問題ではなく、RAG の設計思想そのものに由来する限界であることが見えてきます。ここで 4 つに整理してみます。
1. チャンク化の段階で、文書の構造が壊れる
RAG では文書を 500〜1,500 トークン程度のチャンクに分割するのが定石です。しかし、業務文書はそもそも章 → 節 → 項 → 例外規定といった階層構造を持っており、その骨格を残したまま「独立した断片の集合」に変換することはできません。
「第 3 章 2 項に従う」とだけ書かれた段落は、独立した一片としては何の意味も持ちません。それでもベクトル空間上では立派な一点として扱われ、たまたまトップヒットすれば、根拠の伴わないチャンクとして AI に渡ってしまいます。
2. 「似ている」と「正しい」を混同する
類似度検索は、文字どおり「文脈ベクトルが近いもの」を返す仕組みです。「ドメインを設定したい」と「ドメインを解約したい」は、ベクトル空間ではほとんど同じ方向を向きます。人間にとってはまったく逆の意図ですが、モデルから見れば登場する語彙が似ているだけで、トップヒットになりうるのです。
これはモデルが弱いという話ではなく、「類似度」という指標そのものが、「意図の一致」ではなく「表面的な近さ」を測るものでしかないという、もう少し根本的な話です。リランカーで部分的に補正はできますが、原理的な癖は残ります。
3. 複数手順・条件分岐に弱い
マニュアルや規程の本質は、しばしば「A の場合は B、ただし C のときは D」という分岐構造にあります。RAG はある瞬間に 1〜数チャンクを取ってくるだけなので、「分岐の上流にある条件文」と「分岐の下流にある操作手順」を同時に拾ってくる保証がありません。
結果として、片側だけが回答に反映され、もう片側が抜け落ちる、ということが起きます。サポート業務でいえば、「年額プランの解約手続き」を聞かれて月額プランの手順を返してしまう、というような典型的な事故がこのパターンです。
4. 根拠の説明が断片的になる
RAG が返してくれるのは、基本的に「ヒットしたチャンクの一覧」までです。それぞれがどの文書のどの位置にあるのか、文書全体のどの議論の流れの中に位置づけられているのか、までは答えてくれません。
エンタープライズ用途で「なぜこの結論なのか？」「どの規程の何条に基づくのか？」を問われる場面では、この説明の薄さがそのまま信頼性のリスクになります。ベクトルの数値を見せても、業務側の人間は納得しません。
言葉は「単語の袋」ではない — 文書構造という観点
もう少し抽象度を上げると、ここで起きているのは「言葉をどう扱うか」というモデリングの問題です。
RAG が暗黙のうちに前提にしているのは、「文書は単語（あるいは埋め込みベクトル）の集合として扱える」という発想です。チャンクごとに独立したベクトルを持たせ、その近さで検索する以上、文書を「点の集まり」として見ていることになります。
しかし実際の業務文書は、まったく違う性質を持っています。
- 章立て：何の話を、どの順序で扱うかを規定する骨格。「第 2 章 課金」「第 3 章 解約」のような章タイトルそのものが意味のスコープを切っています。
- 前提条件：「これは法人プランの場合に限る」「2025 年 4 月以降の契約に適用」など、上流で宣言される暗黙のスコープ。下流のチャンクだけ読んでも、適用範囲が分からないことがあります。
- 例外規定：「ただし〜は除く」という一文が、本文全体の意味を反転させることがある。RAG が本文だけを拾って例外条項を取りこぼすと、まったく逆の回答が出ます。
- 手順の連鎖：ステップ 1 → 2 → 3 と並ぶ操作群は、順序を保ったまま、抜けなく回答に出る必要があります。
- 参照と依存：「詳細は別紙 A を参照」「第 5 章を併せて確認のこと」など、他文書・他章への明示的なリンクを持っています。
これらはどれも、「ベクトル空間上の近さ」では表現しきれない情報です。Corpus2Skill が面白いのは、検索の前提を「点の集まり」から 「道筋のあるグラフ」 に切り替え、その道筋に沿ってエージェントを歩かせる、という発想を採っているところです。文書が本来持っている構造に沿って探索する、という意味で、人間が本棚で資料を当たる動きにかなり近いものになっています。
チューニングの頭打ち、その先にある選択肢
RAG を本番運用したことがある方は、おそらく次のようなチューニングを順番に試してきていると思います。
- チャンクサイズの調整（短くしたり、オーバーラップを増やしたり）
- 埋め込みモデルの差し替え（多言語モデル、ドメイン特化モデル、より大きいモデル）
- ベクトル DB の乗り換え、インデックスのチューニング、メタデータフィルタの追加
- BM25 とのハイブリッド検索、クロスエンコーダ系リランカーの導入
- クエリ書き換え（HyDE、ステップバック・クエリ、マルチクエリ）
- プロンプトに「ヒットしなかったら答えるな」「複数文書を矛盾なく統合せよ」と書き込む
どれも有効ですし、私自身もまずこの順で試します。ただ、ここまで詰めたうえで 「あと一段、業務で使える水準まで精度を上げたいのに、どう触っても上がらない」 という壁にぶつかったとき、考えるべきはチューニングの延長線ではなく、設計思想そのものを切り替える選択肢です。
Corpus2Skill はその候補のひとつです。「RAG を捨てる」というより、「RAG ではうまくいかない領域の手前に、別の道具を置く」と捉えるのが現実的だと思います。少なくとも、無限にプロンプトを書き直し続けるよりは、構造そのものを変えるほうが投資対効果がはっきりするケースがあります。
なぜ「ナビゲーション」が効くのか — Corpus2Skill の考え方
2026 年 4 月、論文 "Don't Retrieve, Navigate: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG"（Sun, Wei, Hsieh, 2026）が公開されました。ここで提案されているのが Corpus2Skill です。
名前のとおり、コーパス（文書群）を「スキル」へと蒸留（Distill）し、AI エージェントが自分で歩いて回答に到達できる地図に変換する、というアプローチです。仕組みは大きく 2 段階に分かれます。
地図を作る（Compile Time）
事前に文書全体を意味のかたまりごとにクラスタリングし、スキル階層（ツリー）として構築します。各ノードには「この階層は何の話を扱っているか」という要約と、下位ノードへのリンクが書かれます。本棚で言えば、書架の見出しと、その下の棚札にあたるものです。
このフェーズで効いてくるのが、章立てや前提条件といった文書本来の構造です。Corpus2Skill はチャンクをただ並べるのではなく、文書のまとまりをそのまま「歩ける階層」として残してくれます。
意志を持って歩く（Serve Time）
サーブ時には、AI エージェントが自分でこの地図を辿ります。「ドメインの設定について聞かれた → まず『カスタムドメイン』の階層へ → その下の『初期セットアップ』を確認しよう」というふうに、エージェント自身が次にどこへ行くべきかを判断しながら探索していきます。
これは、人間が分厚いマニュアルを読むときの動きにかなり近いです。まず目次を眺め、関係のありそうな章にあたりをつけ、章の頭の概要で前提条件を確認し、必要な節まで降りていく。Corpus2Skill はその動きを、そのままエージェントに置き換えているだけだとも言えます。
推論の透明性とバックトラック
この方式には、副次的な効果として 2 つの強みがあります。
- 推論の透明性：「どのスキル階層を通って、どのドキュメントに辿り着いたか」が足跡（ログ）として残ります。「なぜこの回答になったのか」を、ベクトルの数値ではなく、人間にも追える道筋として説明できるのは、エンタープライズ用途では大きな違いです。
- バックトラック：従来の RAG では、ヒットが「ハズレ」ならそこで終わりでした。Corpus2Skill のエージェントは、「この道は違うな」と判断したらツリーを逆戻りして、別のルートを試せます。一発勝負ではなく、思考のやり直しが効くのです。
WixQA など複数のベンチマークでは、Dense Retrieval や RAPTOR、Agentic RAG といった先行手法に対して、Corpus2Skill が安定して上回る精度を出していると報告されています。とはいえ、ベンチマークだけを根拠に決め打ちするのは危険なので、実際の効き目は次のチェックリストで自分の現場に当てはめながら考えるほうが現実的です。
導入を検討するかどうかのチェックリスト
「うちにも入れたほうがいいのか？」を判断するための、ざっくりしたチェックリストです。3 つ以上当てはまるなら、後編の実践編に進んで、実際に小さなコーパスで動かしてみる価値があると思います。
- 取り扱う文書が 数百ページ以上 あり、章立てや節構成がはっきりしている。
- 文書群の中に、「ただし〜の場合は除く」「〇〇プランに限る」といった条件分岐や例外規定が多い。
- すでに RAG を運用していて、類似度トップヒットが意図と逆の文書を引いてくる事例に心当たりがある。
- 業務上、AI の回答に対して 「根拠となった原文の場所」を提示する必要がある。
- サポート部門や法務・コンプライアンス部門から、回答の説明責任を強く問われている。
- チャンクサイズや埋め込みモデルのチューニングを一通り試したが、精度が頭打ちになっている。
- 1 回の質問に対して、複数の手順や条件を組み合わせた回答が必要になることが多い。
逆に、当てはまるのが 1〜2 個程度なら、いまの RAG をもう少しチューニングするほうが費用対効果は高いです。Corpus2Skill はコンパイル時にそれなりの計算コストと運用設計が要るので、効くべき領域にちゃんと当てて使うのが鉄則です。
RAG と共存させる — 棲み分けの考え方
誤解されやすい点を 1 つだけ補足しておきます。Corpus2Skill は RAG を駆逐するものではありません。むしろ、現実の導入では両者を併用するほうが素直なケースが多いです。
私が現場で考える棲み分けの目安は、こんなところです。
- RAG が向く領域：チャットログ・ナレッジ記事・ブログ・社外のドキュメントなど、章立てが薄く、量が多く、最新性が重要なもの。コストを抑えて広く浅く拾いたいケース。
- Corpus2Skill が向く領域：規程・マニュアル・仕様書・運用手順など、構造が明確で、誤答のコストが高く、根拠の説明が必要なもの。深く正確に答えたいケース。
- 両方使う構成：エージェントが入口でまず質問の性質を判定し、「規程・手順関連は Corpus2Skill、それ以外は RAG」とルーティングする。実装は地味ですが、効きます。
「全部置き換える」と考えると導入のハードルが上がりますが、「一番効くところに刺す」と捉えると、現実的なロードマップが描けます。最初は社内規程など、精度要求が高く・量も限られている領域に対象を絞って試すのがおすすめです。
2026 年、知識検索は「技術」から「技能」へ
少し大きな話で締めます。Corpus2Skill が面白いのは、単に精度を上げる仕組みであるという以上に、「AI に何を渡すか」という設計思想の転換を含んでいるところです。
これまでの RAG は、AI に「資料の切れ端」を渡していました。Corpus2Skill が渡すのは、「その分野を歩くための地図と作法」です。コーパスはもはや検索される対象ではなく、エージェントが実行可能なスキルとして蒸留される。文書が情報のかたまりから、技能の形に変わっていくイメージです。
「検索エンジンを作っているのではない。我々は自律的な専門家（エージェント）を育てているのだ」
もちろん、これがすべての現場の答えになるわけではありません。冒頭にも書いたとおり、Corpus2Skill が効くのは「構造のある文書群」×「正確さが求められる業務」の交点です。それでも、RAG のチューニングに行き詰まりを感じている人にとっては、考え方の引き出しを 1 つ増やしておく価値は十分にあると思います。
続く後編では、ここまで紹介した Corpus2Skill を実際に環境構築し、自分のデータでスキルツリーをコンパイルして動かすところまでを、Python のコードと一緒に手順書としてまとめました。あわせてどうぞ。
目次
- 「見つからない」には理由がある
- この記事は、こんな現場のための話
- RAG が行き詰まる 4 つの構造的な理由
- 言葉は「単語の袋」ではない — 文書構造という観点
- チューニングの頭打ち、その先にある選択肢
- なぜ「ナビゲーション」が効くのか — Corpus2Skill の考え方
- 導入を検討するかどうかのチェックリスト
- RAG と共存させる — 棲み分けの考え方
- 2026 年、知識検索は「技術」から「技能」へ
参考文献
- GitHub: dukesun99/Corpus2Skill
- 論文: "Don't Retrieve, Navigate: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG" (Sun, Wei, Hsieh, 2026)
関連キーワード
- Corpus2Skill
- RAG 代替技術
- 知識検索
- AI エージェント
- ドキュメントナビゲーション
- エンタープライズ検索
- WixQA ベンチマーク
- 推論の透明性
