社内ナレッジ検索は、チャンクを類似度で拾うRAG（Retrieval-Augmented Generation、検索拡張生成）が主流でした。この前提を「上位ディレクトリからエージェントが辿る」方式に置き換える論文が2026年に登場しました。
Yiqun Sun、Pengfei Wei、Lawrence B. Hsiehによる「Corpus2Skill: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG」（arxiv.org/abs/2604.14572、2026年4月16日公開、v4は8月26日、EMNLP 2026 Findings採択）は、コーパスをオフラインで階層スキル辞書に圧縮し、エージェントが要約を辿って必要な範囲だけ本文を読む設計を提示しました。
中心的な主張は、社内ナレッジは「検索する対象」ではなく「探索する対象」として設計すべき条件がある、という点です。ただし11データセット検証は5勝3分3敗で、万能ではない結果になっています。
RAGは、コーパスをチャンクに分割し類似度で拾う設計です。この設計は、階層構造や領域境界を陽に持たないため、企業ナレッジの位置関係が失われやすいという弱点があります。
論文が指摘する従来手法の課題は次のとおりです。
社内文書は、通常「事業→部門→プロダクト→仕様書」のような階層で人が管理しています。RAGは、この階層を無視して平坦なベクトル空間で扱うため、人が持つ探し方と乖離しやすい構造になっています。
Corpus2Skillは、事前処理とサーブ時処理を分離した二段構成です。
事前処理では、コーパス全体を対象に次を行います。
サーブ時には、LLMエージェントがこの階層を上から辿ります。
直感的な比喩は、社内Wikiでフォルダを辿る動きに近いものです。平坦なベクトル検索を廃止するのではなく、上位で領域を絞り、下位で本文に触れる二段構えにする発想です。
既存手法との差分は次の3点です。
実装コードは公式GitHub（github.com/dukesun99/Corpus2Skill）で公開されており、既存RAGスタックへの差し替え実験が可能です。
主要な比較軸を整理します。
| 比較軸 | 従来RAG系 | Corpus2Skill | 実務上の読み方 |
|---|---|---|---|
| 単一ドメイン、明確な分類軸 | 中～高 | 高 | 社内文書、製品ドキュメント、サポートFAQで優位 |
| オープンドメイン事実問合せ | 高 | 中 | 一般知識QAではRAG継続が合理的 |
| 均質な表データ | 中 | 低 | 表中心コーパスは階層化しづらく相性が悪い |
| 部門横断コーパス | 中 | 中〜高 | 領域境界が明確なほど探索型が効く |
論文は、単一のエンタープライズ顧客サポートベンチマークで単発検索dense、hybrid、hierarchical retrieval、agentic RAGの4系統に対し明確な改善を報告しました。
11データセットの総合評価では、5データセットで勝ち、3データセットで同等、3データセットで負けています。勝てた条件は「単一ドメイン」「復元可能な主題分類が存在する」の2つが揃うコーパスです。
負けた条件は次のように整理されています。
読み方として重要なのは、平均勝率ではなく「自社コーパスがどちら側か」を判定する視点です。エンタープライズ社内文書は前者に近く、一般消費者向けQAは後者に近い傾向があります。
論文が明示している限界は次のとおりです。
論文本文で扱われていない、実務上の注意点は次のとおりです。
「RAGを完全に置き換える」ではなく、「領域境界の明確なコーパスから段階的に切り替える」設計が現実的です。
自社に導入するかを判断する際は、以下を順に確認します。
次のケースでは、RAG継続が合理的です。
次のケースでは、探索型検討が合理的です。
導入形態としては、いきなり全面置き換えではなく、部門・領域単位でRAGとCorpus2Skillを並走させ、指標で切り替える段階導入が現実的です。
社内AIの現場では、「RAGを入れたが精度が伸びない」という相談が増えています。多くの場合、根本原因はコーパス側の階層設計と、AI側の検索設計が分離していることにあります。
Corpus2Skillの示唆は、AIモデルの改善よりも、コーパス側の階層を陽に持たせる設計が効くケースが存在するという点です。この論点は、社内文書ガバナンス、権限設計、部門横断ナレッジ運用と直結します。
Blackfordでは、DataRoidを含む社内データ基盤の設計を、次の観点で支援しています。
論文が主張するように、探索型が万能ではありません。自社コーパスがどちら側に属するかを判定する評価設計こそ、AI導入の初期段階で必要な投資です。DataRoid、DataRoid Cloudでは、この判定と段階導入を運用に載せるところまで支援します。
Q: Corpus2SkillはRAGを完全に置き換える技術ですか？
A: 論文の11データセット評価では5勝3分3敗であり、置き換えではなく用途別の選択肢として扱うのが妥当です。単一ドメインで分類軸が明確なコーパスでは優位ですが、オープンドメイン事実問合せや均質な表データではRAGが依然優位です。
Q: コーパスを更新した場合、階層要約はどう扱いますか？
A: 論文本文では大規模更新時のパイプラインは主題外ですが、実務では差分再構築の運用設計が必要です。更新粒度、再構築間隔、再構築中の応答方針を、社内ナレッジガバナンスと合わせて設計します。
Q: 中小企業でも導入は現実的ですか？
A: 導入前提は、コーパスに復元可能な階層が存在することです。社内Wiki、部門フォルダ、製品文書などの階層が既に運用されていれば、段階的な検討対象になります。まずは部門単位でRAGとの並走比較から始めるのが安全です。
Q: 実装コードは公開されていますか？
A: 論文の公式リポジトリはgithub.com/dukesun99/Corpus2Skillで公開されています。既存RAGスタックとの並走比較を、自社データで小規模に走らせられる状態です。
Corpus2Skillは、社内ナレッジを「検索するもの」ではなく「探索するもの」として設計する視点を提示しました。全ケースでRAGを上回るわけではありませんが、単一ドメインで分類軸が明確なコーパスでは有力な選択肢になります。
ただし、11データセットのうち3データセットで負けている事実は無視できません。AI側の手法を選ぶ前に、自社コーパスがどちら側かを評価する設計が先行するべきです。
社内AI導入で、RAG改善に頭打ちを感じている場合は、コーパス階層設計と評価パイプラインから見直す価値があります。判断に迷う場合は、業務課題と現行検索の指標を持ち込んで相談してください。
