Corpus2Skillとは何か：Don't Retrieve, Navigateが変えるRAG後の知識ベース

特集「RAG疲れからの脱出：Corpus2Skillが示す検索しないAI知識基盤」第2回 公開予定：2026年5月14日 ／ 著者：野口真一

第1回からの接続：検索を疑う、という思想

前回はRAG疲れという運用症候群を定義しました。チューニングの延長線では解決しないこと、本質的なコストはトークン費用よりも組織と担当者の認知負荷であること、そして打開のためには「検索する」という前提そのものを疑う必要があること——ここまでが第1回の到達点です。

第2回となる本稿では、その「検索を疑う」設計思想を実装に落とし込んだ研究、Corpus2Skillを編集者の視点で読み解きます。論文タイトルは "Don't Retrieve, Navigate: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG"（Yiqun Sun, Pengfei Wei, Lawrence B. Hsieh, 2026）。GitHubでは dukesun99/Corpus2Skill として公開されています。

本稿では環境構築やコードの話はしません。それらは既存の実践記事に譲り、ここでは「なぜこの設計に意味があるのか」「日本企業のナレッジ運用に翻訳するとどう読めるのか」を、実務者の言葉で言い直していきます。Claude Skillsとの相性、WixQAベンチマークの読み方、向き不向き、既存RAGとの併用イメージ——RAG後の知識基盤を設計し直したい方への、編集的なガイドです。

Corpus2Skillを一言で説明する

Corpus2Skillを一言で言うなら、「文書コーパスを、LLMエージェントが歩ける階層的な目次に蒸留する技術」です。

従来のRAGは、文書群をベクトル空間上の点の集まりに変換し、質問に近い点を引いてきました。Corpus2Skillは違います。文書群を、

• 何の話を扱う領域なのか（要約）
• どの下位領域に分岐しているのか（リンク）
• どの末端ドキュメントを含むのか（インデックス）

を明示的に書き込んだMarkdownの階層に変換します。AIエージェントはこのMarkdownを読み、自分で次にどこへ降りるかを判断しながら、関連するドキュメントに到達します。

ここで起きている発想の転換を、少し丁寧に言葉にしてみます。RAGは、「人間が書いた文書を、機械が読みやすいベクトルにする」技術でした。Corpus2Skillは、「人間が書いた文書を、LLMが読みやすいMarkdownの目次にする」技術です。両者は同じ「前処理」のように見えて、まったく違うものを作っています。

ベクトルは数値であり、人間には読めません。Markdownの目次は、人間にも読めます。これは単なる可読性の話ではなく、「同じテキストを、人間とLLMの両方が同じインターフェースで扱える」ことを意味します。RAGが前提にしてきた「機械と人間のあいだの翻訳レイヤー」を、Corpus2Skillは捨てているのです。

Don't Retrieve, Navigate の意味

論文タイトルの "Don't Retrieve, Navigate" は、技術論というより思想の宣言です。直訳すれば「検索するな、ナビゲートせよ」。

ここで言う retrieval は、いわゆるRAGの retrieval です。質問をベクトル化し、コーパス側のベクトル集合から近いものを取り出す、一発勝負の動き。これに対して navigation は、エージェントが目次を読み、自分で次の階層を選び、必要なら戻って別の枝に行く、反復的・自己決定的な動きです。

retrieval と navigation の違いを並べてみます。

• retrieval は 一発勝負。navigation は やり直しが効く
• retrieval は 似たものを引く。navigation は 当てはまるものを選ぶ
• retrieval は エージェントが受け身。navigation は エージェントが主体
• retrieval は 足跡が残らない。navigation は どこを通ったかが残る

最後の点は特に重要です。エンタープライズ用途では「なぜその回答に至ったのか」を、ベクトル類似度の数値ではなく、人間にも追える道筋として説明できる必要があります。retrieval は「このチャンクが上位だったから」までしか答えられませんが、navigation は「まずこの章に入り、次にこの節を見て、根拠の本文に到達した」と返せます。

これは、社内のコンプライアンス、法務、医療、金融、公共調達といった「説明責任が強く問われる分野」では、決定的な違いになります。

LLMに断片ではなく地図を渡す

もう少し編集的な言い方をすると、Corpus2Skillが渡しているのは「地図」です。

RAGがLLMに渡すのは、本のページを破ってホチキスで留めた紙の束です。それぞれのページは確かに本文ですが、本全体のどこに位置するのか、前後にどんな議論があるのか、その章には例外規定が含まれていないか、まではわかりません。LLMは目の前の紙束だけを根拠に答えるしかありません。

Corpus2Skillが渡すのは、目次と章扉の集まりです。「この章は何を扱う」「ここに条件分岐がある」「詳細は次の階層へ」というメタ情報が、最初からLLMに見えています。エージェントは目次を眺め、必要な章まで自分で降り、最後に本文を読みます。

これは、人間が初めて分厚い社内規程に出会ったときの動きと完全に一致します。表紙を見て、目次をめくり、関係しそうな章にあたりをつけ、章の冒頭でスコープを確認し、必要な節まで降りていく。Corpus2Skillはこの行動様式を、そのままエージェントに実行可能なフォーマットへ翻訳しているだけです。

技術として何が新しいかと言われれば、特別新しい要素はありません。新しいのは、LLMを「ユーザーの代理人」ではなく「文書を読む人」として扱うという、役割の置き直しです。LLMに必要なのは、機械可読のベクトル空間ではなく、人間が読むのと同じ目次でした。

SKILL.md / INDEX.md は何を変えるのか

Corpus2Skillのコンパイル結果として生成される SKILL.md と INDEX.md という2種類のファイルについて、技術的な解説ではなく、運用者から見た意味を整理しておきます。

• SKILL.md：「ここでは何を扱っているか」「下にはどんな分岐があるか」が書かれた、章扉と目次を兼ねたファイル
• INDEX.md：実際のドキュメントIDが並ぶ、末端の索引ファイル

この2種類のファイルが意味するのは、コーパスが「LLM用の不透明なベクトル」ではなく、「人間も読めるMarkdownのドキュメント階層」として存在するということです。

これがなぜ重要かというと、運用の現実が変わるからです。

まず、変更管理がGitに乗ります。SKILL.mdとINDEX.mdは普通のテキストファイルですから、差分はgit diffで読めます。レビューもMarkdownエディタでできます。RAGのベクトルDBでは「どの差分が精度に影響したか」が原理的に追いにくいのに対して、Corpus2Skillでは「この章の要約をこう書き直したら、この質問の応答がこう変わった」が、人間の言葉でレビューできます。

次に、業務担当者がレビューに参加できます。法務、コンプライアンス、サポート、情シスといった、ベクトルDBには関与できなかった人たちが、Markdownの目次なら読めて、コメントを返せます。「この章のスコープ説明、正確じゃないので直してください」が、PR上の議論になる。AIプロジェクトを、AI担当者だけに閉じない構造にできるのです。

最後に、監査ログがつながります。エージェントがどのSKILL.mdを読み、どのINDEX.mdに到達し、どのドキュメントを根拠としたか——この経路は、ファイルパスとして自然に残ります。「なぜこの回答になったのか」を、テキストの足跡として後から説明できる。これは規制業種においては、技術的な精度向上よりも重い価値です。

なぜClaude Skillsと相性がよいのか

Corpus2Skillの設計が、Anthropic Claudeの Skills 機構と相性がよい理由を、編集的に説明しておきます。

Claude Skillsは、Markdownで書かれた振る舞いのテンプレートをClaudeに読み込ませる仕組みです。SKILL.md というファイル名は、まさにこのSkills仕様から来ています。ClaudeはMarkdownを読み、その中の指示や構造に従って次の行動を決めます。

つまり、Corpus2Skillが出力するMarkdown階層は、Claude Skillsがネイティブに扱えるフォーマットそのものです。RAGのように「ベクトル検索→トップN取得→プロンプトに埋め込み→LLM呼び出し」という4段のパイプラインを、Corpus2Skill + Claude Skills の構成では「Markdownを順に読みながらツリーを降りる」というひとつの動きにまとめられます。

これが意味するのは、パイプラインが消えるということです。ベクトルDBもリランカーも、ハイブリッド検索のチューニングも、原理的に存在しなくなる。前回扱った「chunking疲れ」「embedding疲れ」「vector DB疲れ」「reranking疲れ」が、まとめて発生しない設計に切り替わります。

もちろん、別の重さは出てきます。コンパイル時の計算コスト、ツリーの構造設計、要約の品質管理、更新時の再蒸留。RAGの疲れがCorpus2Skillに置き換わると、悩むべき場所も置き換わります。ただし悩むべき場所が「コードと数値」から「Markdownと文章」に変わることは、組織にとってはまったく違う体験です。文章はレビューしやすく、属人化しにくく、業務担当者を巻き込みやすい。これは、運用のしやすさという意味で本質的な違いです。

WixQAの結果をどう読むべきか

論文では、WixQAというベンチマークでCorpus2SkillがDense Retrieval、RAPTOR、Agentic RAGを各種品質指標で上回ったと報告されています。数字が出てくると、すぐに「Corpus2SkillはRAGより精度が高い」と短絡したくなるのですが、私の読み方はもう少し慎重です。

WixQAはWixの実コーパスをベースにした、企業内QAの色合いが強いベンチマークです。論文中でも明示されている通り、Corpus2Skillが優位を取りやすいのは、

• single-domain corpus（単一ドメインの文書群）
• atomic-document corpus（一文書一トピックに整理された文書群）

という条件下です。逆に、open-domain（多ドメインを横断する）や extractive pool（広く浅く抽出する）タイプの問いでは、フラットなretrievalが有利な場面もあると述べられています。

つまり、WixQAの結果は「RAGは終わった」のような全面的な勝利宣言ではなく、「特定のコーパス特性に対しては、構造化のほうがフラット検索より強い」という、限定された主張として読むべきです。これは、現場の意思決定にとってはむしろ重要な情報で、「うちのコーパスはsingle-domainでatomicか？」という問いを立てることが、Corpus2Skill導入判断の出発点になります。

社内規程、運用マニュアル、サポートFAQ、製品仕様書——これらはたいてい single-domain で atomic に近い性質を持ちます。一方、ニュース横断検索、リサーチ用途の論文プール、SNSログ分析、雑多なナレッジ記事の混在は、open-domain で extractive 寄りです。後者にCorpus2Skillを当てても、RAGに対して優位を取りにくいことは、ベンチマークの読み方からも予想できます。

RAG代替ではなくRAG後の設計思想

ここまでの話を踏まえて、私はCorpus2Skillを「RAG代替技術」と呼ぶことに、少し違和感を持っています。代替というより、RAG後の設計思想と呼ぶほうが正確だと思います。

代替という言葉には「同じ問題を、別の道具で解く」というニュアンスがあります。しかしCorpus2Skillが解いているのは、RAGとは少し違う問題です。

• RAGが解こうとした問題：「LLMのコンテキストに、関連する断片だけを効率的に詰める」
• Corpus2Skillが解こうとしている問題：「LLMに、ドメイン全体の構造を歩かせる」

両者は重なる部分も大きいですが、目的関数が同じではありません。Corpus2Skillは、検索精度を上げるための新しいretrievalアルゴリズムというより、「そもそも検索ではなく、LLMに文書ドメインを技能として与える」という、上位のアーキテクチャ提案です。

この立場の違いは、導入の議論にも影響します。RAG代替として捉えると「既存のRAGをCorpus2Skillに置き換えるか？」というゼロイチの議論になりますが、RAG後の設計思想として捉えると「現在のRAGパイプラインを、エージェントが歩けるMarkdownの目次でラップする」という、段階的な導入の絵が描けます。これは第3回で扱う、ハイブリッド構成の話につながります。

向いている企業ナレッジ

Corpus2Skillが向いている企業ナレッジを、第1回の「RAG疲れの定義」と接続しながら整理します。

• 章立てがはっきりしている文書群：社内規程、ISMS関連文書、コンプライアンスマニュアル、内部統制ドキュメント
• 条件分岐と例外規定が多い文書群：プラン約款、契約書ひな型、保険商品設計書、税務マニュアル
• 手順の連鎖がある文書群：システム運用手順書、業務オペレーションマニュアル、現場SOP（標準作業手順書）
• 複数文書の参照関係がある文書群：仕様書、設計書、API仕様、規程と細則のセット
• 回答に出典の正確性が求められる文書群：医療プロトコル、法務文書、公共調達仕様書

これらに共通するのは、「文書がもともと階層を持っている」ことです。Corpus2Skillの強みは、その階層を壊さずにエージェントに渡せることにあります。逆に言えば、もともと階層を持たない文書群には、Corpus2Skillの強みが出ません。

日本企業のナレッジは、欧米企業に比べて「規程・通達文化」が強いという特徴があります。本社からの通達、業務マニュアル、稟議規程、就業規則、ISMSポリシー——いずれも階層と条件分岐に満ちた文書群です。これらは、Corpus2Skillのフィット領域そのものだと言ってよいと思います。

向いていないケース

公平を期して、向かない領域も明示しておきます。

• チャットログやSNS投稿の集合：階層構造を持たない、フラットな短文の集積
• 時系列ニュース・最新情報の検索：日次で更新されるコーパスは、コンパイルコストが運用に合わない
• 百ページ未満のごく小さな文書群：LLMのコンテキストに丸ごと入る規模では、ツリーを組む手間に対して得るものが薄い
• 一問一答のFAQで構造化が不要なケース：素朴な全文検索やキーワードマッチで十分
• 異種混合の文書群（規程＋議事録＋SNS＋メール）：単一の蒸留階層を組みにくく、ドメインごとに分けたほうがよい

ここで重要なのは、「向かないからRAGが正解」とは限らない点です。フラットな短文集はそもそも全文検索でよいかもしれませんし、最新ニュースは検索エンジンAPI連携のほうが素直です。Corpus2SkillはRAGの単純な置き換えではないので、「Corpus2Skillが向かない」と「RAGが向く」は同じ意味ではありません。

既存RAGとの併用イメージ

現実の企業では、既存のRAGがすでに動いている、というケースが圧倒的に多いはずです。それを全廃してCorpus2Skillに置き換えるのは、移行コストの観点から非現実的です。私が現場で提案するのは、ハイブリッド構成です。

イメージとしては次のような棲み分けになります。

1. 入口でエージェントが質問の性質を判定
2. 規程・マニュアル・仕様書系の質問 → Corpus2Skillで階層を辿る
3. ナレッジ記事・議事録・SNS・チャットログ系の質問 → 既存のRAGで類似検索
4. 最新ニュース・社外情報の質問 → 検索エンジンAPI連携

これは、第1回で触れた「chunking、embedding、vector DBのチューニング地獄からの段階的脱出」とも整合します。重要な領域（規程、コンプライアンス、説明責任を伴う回答）をCorpus2Skillに移し、軽い領域（ナレッジ記事、雑多な検索）は既存RAGに残す。重さの仕分けとして捉えるとよいと思います。

設計上、Corpus2SkillはClaude Skillsとして組まれるため、エージェントから見れば「Skillsを呼ぶ」というひとつの動きに統一されます。RAG側もエージェントから見ればツールとして見えるので、入口のエージェントが両方を扱うアーキテクチャは技術的に素直です。

まとめ：検索ではなく、技能を渡す

第2回をまとめます。

• Corpus2Skillは、文書コーパスをLLMが歩ける階層的Markdownに蒸留する技術である
• "Don't Retrieve, Navigate" は技術論ではなく思想の宣言であり、検索とナビゲーションの違いを言語化している
• LLMに渡すのは断片ではなく、目次と章扉と末端索引で構成された地図である
• SKILL.md / INDEX.md は人間が読めるため、Git差分・業務担当者レビュー・監査ログにそのまま接続できる
• Claude Skillsとはネイティブに相性がよく、RAGパイプラインそのものが消える設計が可能になる
• WixQAの結果は「single-domain × atomic-document corpus」での限定された優位として読むべきである
• Corpus2SkillはRAG代替ではなく、RAG後の設計思想である。既存RAGとはハイブリッドで併用できる

第3回では、ここで触れたハイブリッド構成と、GraphRAG、RAPTOR、Agentic RAGなど他のRAG代替技術との比較、そして実際にPoCをどう設計するかという、導入判断の編に踏み込みます。

想定SEOキーワード

• 主要：Corpus2Skill／Don't Retrieve, Navigate／Claude Skills RAG／Claude Skills vs RAG
• 副次：検索しないAI知識基盤／ナビゲーション型RAG／エージェント型知識探索／SKILL.md INDEX.md
• 比較系：WixQA ベンチマーク／企業ナレッジ AI／社内文書 検索 Claude／RAG 後 設計
• 派生：Corpus2Skill 仕組み／Corpus2Skill 思想／Corpus2Skill 向き不向き

内部リンク候補

• 特集第1回：/blog/feature/rag-fatigue/01.html（仮）
• 特集第3回：/blog/feature/rag-fatigue/03.html（仮）
• /blog/2026-04-29-corpus2skill-zenpen.html（前編：構造的限界）
• /blog/2026-04-29-corpus2skill-kouhen.html（後編：実装手順 ← 本稿で触れない部分の補完先）
• /glossary/（用語集：Claude Skills／RAG／エージェント／ベクトルDB の項目）
• /services.html#ai（AI導入コンサルティング）
• /portfolio.html（社内ナレッジAI導入実績）

既存記事との差別化メモ

• 既存前編はCorpus2Skillの概念紹介を「RAG限界の解決策」として提示しているが、本稿は「RAG後の設計思想」として位置づけ直し、代替か後継かという思想的議論を独自に展開
• 既存後編はSKILL.md / INDEX.mdの構造を実装観点で記述しているが、本稿は「Git差分・業務担当者レビュー・監査ログ」という運用観点で再解釈し、組織レベルの意味づけを与える
• Claude Skillsとのネイティブな相性、およびそれによりRAGパイプライン自体が消える可能性は、既存2記事のいずれにも書かれていない特集第2回の独自論点
• WixQAの結果について「single-domain × atomic-document」という限定条件を明示し、過度な勝利宣言を避ける編集姿勢を打ち出すことで、特集記事としての中立性を担保
• 既存記事は最後に「導入判断は読者に委ねる」で締めるが、本稿は第3回への接続として「ハイブリッド構成」を予告し、特集の連続性を確保