Corpus2Skillは、社内マニュアルやFAQなどの文書コーパスを、LLMエージェントが自律的に探索できる「階層スキルツリー」へ変換するオープンソースソフトウェアです。本ページでは、その基本コンセプトと、前提となる従来RAG（検索拡張生成）の構造的な課題、そして「検索するな、ナビゲートせよ」という発想が生まれた背景を解説します。
Corpus2Skillの概要
Corpus2Skillは、GitHub上で公開されているオープンソースプロジェクト（dukesun99/Corpus2Skill）であり、論文「Don't Retrieve, Navigate: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG」（arXiv:2604.14572）の実装です。名前が示すとおり、「Corpus（文書コーパス）」を「Skill（エージェントスキル）」へ変換することが目的です。
処理は大きく2つのフェーズに分かれます。第一のフェーズはオフラインのコンパイルです。テキストやMarkdown、JSONなどの文書群を読み込み、埋め込みモデルによるベクトル化と再帰的なクラスタリングを行い、各クラスタの要約とラベルをLLMで生成して、階層的な「スキルディレクトリ」として書き出します。第二のフェーズはオンラインのサーブです。ユーザーからの質問を受けたLLMエージェントは、スキルツリーの最上位にある鳥瞰的な説明から読み始め、関連しそうなブランチへ段階的にドリルダウンし、最終的に根拠となる文書へ到達して回答を生成します。
ここで注目すべきは、サーブ時に検索システムが一切不要という点です。従来のRAGで必須だったベクトルデータベースや埋め込み検索エンジンは、コンパイル時にのみ使用され、運用時のランタイム構成要素はLLMだけになります。ナレッジ基盤の運用構成が劇的にシンプルになるため、インフラ管理の負担軽減を重視する企業のAI推進部門にとって魅力的な選択肢となります。
従来RAGが抱える構造的な課題
RAG（Retrieval-Augmented Generation：検索拡張生成）は、LLMに外部知識を与える標準的な手法として広く普及してきました。質問文をベクトル化し、類似度の高い文書チャンクを検索してプロンプトに挿入するというアプローチは、実装が比較的容易で、多くのエンタープライズQAシステムに採用されています。しかし、運用が進むにつれて構造的な限界も明らかになってきました。
論文「Don't Retrieve, Navigate」が指摘する最大の課題は、LLMが「検索結果の受動的な消費者」にとどまることです。従来RAGにおいてLLMは、検索エンジンが返してきた断片だけを見て回答を組み立てます。コーパス全体にどのような情報が存在するのか、いま見ている断片がナレッジ全体のどの位置にあるのか、まだ探索していない領域に何が残っているのかを、LLMは一切知ることができません。
この「全体が見えない」性質は、実務では次のような症状として現れます。第一に、質問の言い回しと文書の言い回しが乖離していると、意味的に関連する文書が検索で漏れてしまいます。第二に、複数の文書にまたがる横断的な質問では、必要な断片が一度の検索で揃わず、回答が不完全になります。第三に、検索が外れた場合にLLM自身がそれを認識できず、無関係な断片から誤った回答（ハルシネーション）を生成する危険があります。
もちろん、ハイブリッド検索やリランキング、クエリ書き換え、エージェント型RAGなど、これらの症状を緩和する改善手法は数多く提案されています。しかし、いずれも「検索エンジンが返す断片をLLMが受け取る」という基本構造は変わりません。Corpus2Skillは、この基本構造そのものを転換しようとする試みです。
運用の観点から見た従来RAGの負担
品質面だけでなく、運用面の負担も見逃せません。従来RAGを本番運用するには、ベクトルデータベースのクラスタ管理、埋め込みモデルのサービング、文書更新時のインデックス同期、検索品質の継続的なチューニングといった作業が発生します。ナレッジベースの規模が拡大するほど、これらのインフラは「QAシステムの裏側にあるもう一つのシステム」として重量化していきます。AI推進部門にとって、検索基盤の運用工数はRAG導入時に見積もりから漏れやすいコストの代表例です。Corpus2Skillがサーブ時の検索基盤を丸ごと不要にするアプローチは、この隠れたコストへの回答でもあります。
「検索するな、ナビゲートせよ」という発想
Corpus2Skillの中心思想は、論文タイトルそのものである「Don't Retrieve, Navigate（検索するな、ナビゲートせよ）」に集約されています。人間の専門家が社内ナレッジを探すときの行動を思い浮かべてください。優れた担当者は、キーワード検索を繰り返すのではなく、「この種の質問なら製品マニュアルの決済の章だ」というように、知識の全体地図を頭に入れたうえで、目的の場所へまっすぐ降りていきます。途中で違うと気づけば、一段戻って別の枝を調べ直します。
Corpus2Skillはこの行動をLLMエージェントに再現させます。コンパイル済みのスキルツリーは、最上位に「コーパス全体を数個のトピックに大別した鳥瞰ビュー」を持ち、下位に行くほど粒度の細かい要約が配置されています。エージェントは質問を受けると、まず鳥瞰ビューを読んで関連するトピックの枝を選び、徐々に細かい要約へとドリルダウンしていきます。選んだ枝が期待外れであれば、その枝を放棄して上位ノードへバックトラックし、別の枝を探索します。最終的にリーフノードで文書IDを特定し、全文を取得して回答の根拠とします。
このアプローチには、検索型にはない性質がいくつも備わっています。エージェントは常に「コーパス全体のどこを見ているか」を把握できるため、探索の抜け漏れに気づけます。要約の階層をたどるため、質問と文書の字面が一致しなくても、意味的なトピックの近さで目的地に到達できます。さらに、探索の過程そのものがログとして残るため、「なぜこの文書を根拠に選んだのか」という説明可能性の面でも優れています。
登場の背景と論文・OSSの位置づけ
Corpus2Skillが登場した背景には、LLMエージェント技術の成熟があります。近年のLLMは、ツールを呼び出しながら多段階の推論を行う「エージェント」としての能力が大きく向上しました。Anthropic社のSkills API（エージェントスキル）のように、エージェントへ手順書や知識を「スキル」として与える仕組みも整備されつつあります。Corpus2Skillのコンパイル出力が.claude/skills/規約に準拠し、Anthropic Skills API互換となっているのは、この潮流を直接に反映したものです。
もう一つの背景は、長大なコンテキストとプロンプトキャッシュの実用化です。スキルツリーの上位ノードはクエリをまたいで共通に読まれるため、キャッシュ機構と極めて相性が良く、後述するとおりWixQAベンチマークでは1クエリあたりのコストが約48%削減されたと報告されています。「ナビゲーションはコストが高いのでは」という直感的な懸念は、キャッシュの活用によって大きく緩和されるわけです。詳細は「コスト構造とプロンプトキャッシュ最適化」で解説します。
「スキル」という知識の受け渡し形式
Corpus2Skillの出力が「データベース」ではなく「スキル」である点は、単なる形式の話にとどまりません。スキルとは、エージェントが必要に応じて読み込み、行動の指針とする知識の単位です。ナレッジベースをスキル形式に変換するということは、検索システムに問い合わせる対象から、エージェント自身が携えて歩く知識へと、ナレッジの在り方を変えることを意味します。この転換により、QA以外のタスク——たとえば文書作成支援や手順の自動実行——でも、同じスキルツリーを知識源として流用できる可能性が開けます。
位置づけとしては、論文（arXiv:2604.14572）が理論とベンチマーク評価を提供し、GitHubのOSSがその参照実装を提供する関係です。なおOSSは現時点でWIP（開発途上）の早期リリースと明言されており、粗削りな部分が残ります。本番導入の前に、検証環境での試行と「適用判断」の確認をおすすめします。
- Corpus2Skillは文書コーパスを階層スキルツリーへ蒸留するOSSで、論文「Don't Retrieve, Navigate」の実装です。
- 従来RAGの課題は、LLMが検索結果の受動的消費者にとどまり、コーパス全体を見渡せないことにあります。
- サーブ時の構成要素はLLMのみで、ベクトルDBや検索エンジンの運用が不要になります。
まとめと次に読むページ
本ページでは、Corpus2Skillの基本コンセプトと従来RAGの構造的課題を確認しました。「検索するな、ナビゲートせよ」という発想は、単なるキャッチフレーズではなく、LLMを受動的な消費者から能動的な探索者へと役割転換させるアーキテクチャ上の転換です。そしてその転換は、サーブ時インフラの簡素化、説明可能性の向上、プロンプトキャッシュとの親和性という実務的なメリットを伴います。
よくある誤解にも触れておきます。Corpus2Skillは「RAGをすべて置き換える技術」ではありません。後述の汎化研究が示すとおり、雑多な事実断片の集合や更新頻度の極めて高いデータでは、従来の検索型が引き続き適しています。正しい理解は、「ナレッジの性質に応じて、検索型とナビゲーション型を使い分ける時代が来た」というものです。自社のナレッジのうち、目次が作れるほど構造化された部分がナビゲーション型の第一候補になります。
次のステップとして、文書コーパスがどのようにスキルツリーへ変換されるのかを知りたい方は「コンパイルパイプライン」へ、出来上がったツリーの構造とエージェントの動きを知りたい方は「スキルツリー構造とナビゲーション」へお進みください。既存のRAG基盤との比較から入りたい方には「従来RAG・エージェント型RAGとの比較」が最短の入り口になります。
