RAG代替としてのCorpus2Skill：GraphRAG・RAPTOR・Agentic RAGとの比較と導入戦略

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

第2回からの接続：思想を、現場の選択に落とす

第1回で「RAG疲れ」という運用症候群を定義し、第2回でCorpus2Skillという別解の思想を編集者の視点で読み解きました。残る第3回は、もっとも実務的な問いを扱います。「結局、自分たちはどれを選べばよいのか」です。

2026年現在、RAGの限界を超えるとされる技術は急速に増えました。GraphRAG、RAPTOR、Agentic RAG、Dense RAG、Hybrid RAG、そして本特集で扱っているCorpus2Skill。それぞれにベンチマークと信奉者がいて、それぞれの主張は概ね正しい——というのが厄介なところです。本稿では、これらを「機能の一覧表」として並べるのではなく、現場でどう選び分けるかの実務者目線で比較します。

最後に、PoC設計、ハイブリッド構成案、導入判断表、そして2026年以降のAI知識基盤の方向性を、私の現場感覚として置いて、本特集を締めくくります。

RAG代替技術が増えている理由

そもそも、なぜ2025〜2026年にかけてRAG代替技術が一斉に出てきたのか。背景を整理しておきます。

第一に、LLMのコンテキスト長が一気に伸びたことです。Claude OpusやGeminiが100万トークン級のコンテキストを扱えるようになり、「大量のチャンクを賢く詰める」という従来のRAGの問題設定そのものが、ハードウェアの進化で半分くらい消えました。

第二に、LLMの推論コストが劇的に下がったことです。2024年から2026年で、入力トークン単価は1桁安くなっています。「LLMに何回も問い合わせる」ことが現実的になり、Agentic RAGやCorpus2Skillのような反復型アプローチが成立します。

第三に、prompt cachingの普及です。Anthropic、OpenAI、Googleがいずれもキャッシュ機構を提供し、「一度読んだ大きなコンテキストを安く再利用する」運用が当たり前になりました。これにより、Corpus2Skillのように同じスキルツリーを何度も読むアーキテクチャが、コスト的に持続可能になりました。

第四に、これが第1回で扱った話ですが、RAG運用が「疲れる」という認識が広まったことです。チューニングしても上がらない、という現場の声が、技術コミュニティの問題意識を一段押し上げました。

つまり、RAG代替技術が増えたのは、単に新しいアルゴリズムが発明されたからではなく、LLM側の進化と運用側の疲弊が同時に来たことの帰結です。比較を始める前提として、この背景を共有しておきます。

Dense RAG / Hybrid RAGとの比較

まずは、もっとも基本的な比較対象である、いわゆる「素朴なRAG」との関係を整理します。

Dense RAGは、ベクトル類似度のみで検索を行う、もっとも原型に近いRAGです。実装は単純で、コストも低い。文書数が中規模で、ドメインが安定していて、章立てが薄いコーパスに向きます。社内ナレッジ記事の検索、ヘルプデスクの一次回答、社外ブログ検索など、「広く浅く拾えれば十分」な領域で今でも有効です。

Hybrid RAGは、Dense（ベクトル類似度）とSparse（BM25等のキーワード一致）を組み合わせた検索です。製品名・コード・固有名詞・略語など、ベクトルでは寄せにくい固有表現を含むコーパスで威力を発揮します。Dense単体で取りこぼす「正確な単語マッチ」を補えます。実装複雑度はDenseより上がりますが、現実のエンタープライズ検索ではほぼ必須と言ってよい構成です。

Corpus2Skillとこの2つの比較で重要なのは、「コーパスが構造を持っているか」という軸です。

• 構造が薄い：チャットログ、議事録、ブログ、SNS、ナレッジ記事 → Dense / Hybrid RAGの領域
• 構造が濃い：規程、マニュアル、仕様書、約款、SOP → Corpus2Skillの領域

ここを混同すると、構造の濃いコーパスにDenseを当てて疲弊するか、構造の薄いコーパスにCorpus2Skillを当ててコンパイルコストが釣り合わなくなります。最初の判断軸は、技術選定ではなく、コーパスの性質をどう見立てるかです。

RAPTORとの比較

RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval）は、文書群を再帰的に要約しながら木構造を作り、抽象度に応じた階層から検索する手法です。抽象的な問いには上位の要約層、具体的な問いには末端の本文層を返します。

Corpus2SkillとRAPTORは、「階層を作って使う」点でよく似ています。実際、初見ではほぼ同じ発想に見えると思います。ただ、決定的に違うのは「使い方」です。

• RAPTOR：階層は検索の対象。要約層と本文層をretrievalの選択肢として扱い、似たものを引いてくる
• Corpus2Skill：階層はナビゲーションの地図。エージェントが目次を読み、自分で次にどこへ行くかを決めながら降りる

つまりRAPTORは、retrievalの精度を上げるために階層化を導入した手法です。最後の動きは、依然として「ベクトル類似度で似たものを引く」検索です。これに対してCorpus2Skillは、retrievalそのものを捨ててnavigationに置き換えています。

実務的な選び分けとしては、

• RAPTOR：既存のDense/Hybrid RAGをそのまま運用しつつ、抽象度の異なる問いにも対応したい場合の中間ステップ
• Corpus2Skill：retrievalのチューニング地獄から完全に降りたい、Markdownベースで業務担当者を巻き込みたい場合の本格移行

私の感覚では、「既存のRAGがある程度動いているが、もう少しだけ抽象度の高い問いも拾いたい」ならRAPTORが堅実な追加投資、「もう retrieval というモデル自体に疲れた」ならCorpus2Skillへの設計転換、という選び方になります。

GraphRAGとの比較

GraphRAGは、Microsoft Researchが提唱した、文書からエンティティと関係を抽出してナレッジグラフを構築し、グラフを辿って検索する手法です。「Aという人物は、Bという組織に所属し、Cという案件を担当している」といったエンティティ間の関係を、明示的なグラフとして保持します。

GraphRAGが強いのは、「人・組織・案件・製品といったエンティティをまたぐ問い」です。例えば「Cの案件に過去関わったすべての人物を、所属組織別に整理して」のような問いは、Denseで断片を引いてもまとめきれません。グラフを辿って初めて答えに到達します。

Corpus2SkillとGraphRAGの違いは、「文書構造を使うか、エンティティ関係を使うか」です。

• Corpus2Skill：文書の章立て・節構成という縦の階層を活用
• GraphRAG：文書を横断するエンティティ関係という横のネットワークを活用

両者は競合というよりは補完関係にあります。社内規程をCorpus2Skillで階層化しつつ、組織図・人事情報・案件履歴はGraphRAGでグラフ化する、という併存設計は十分にあり得ます。

ただし、GraphRAGはエンティティ抽出と関係抽出の品質が、結果のすべてを決めます。コンパイルコストはCorpus2Skill以上に重く、メンテナンスも質が高いコーパス管理者を要します。「グラフを作ること」自体が新しい運用負荷になる点は、導入前に冷静に見積もる必要があります。

私の現場感覚では、GraphRAGはBI的な問いや調査・分析タスクに向き、Corpus2SkillはQA・ヘルプデスク・コンプライアンス的な問いに向く、という棲み分けで考えています。

Agentic RAGとの比較

Agentic RAGは、LLMエージェントが検索ツールを自律的に呼び出し、必要に応じて複数回retrievalを行いながら回答を組み立てる手法です。「最初の検索結果が不十分だったら、別のクエリで再検索する」「複数のドキュメントを比較する」といった、人間の調査行動に近い動きをします。

ここまで読んで気づいた方もいるかもしれませんが、Agentic RAGとCorpus2Skillは、エージェントの自律性という点ではかなり近いです。違いは、エージェントが扱う「世界」の形にあります。

• Agentic RAG：エージェントはフラットなretrieval空間を相手に、クエリを工夫しながら何度も検索する
• Corpus2Skill：エージェントは事前に蒸留された階層的Markdownを相手に、目次を読みながら降りる

Agentic RAGは、コーパスを事前に構造化しないため、汎用性が高く、柔軟です。ただし、毎回のretrievalにベクトル検索とLLM呼び出しのコストがかかり、何ターン回しても根本的な検索の限界（類似度の罠）は解消しないという弱点を引きずります。エージェントが賢くなることで、ある程度カバーはできますが、検索が原理的に外している場合の救済には限界があります。

Corpus2Skillは、事前のコンパイルコストを支払う代わりに、サーブ時の各ターンは「Markdownを読むだけ」になります。ベクトル検索のレイヤーが存在しないので、類似度の罠そのものが発生しません。一方で、コンパイル時の階層設計が悪いと、エージェントが最初から間違った枝に降りる「navigation miss」というCorpus2Skill固有の失敗パターンがあります。

選び分けとしては、

• Agentic RAG：コーパスが頻繁に更新される、構造化のコストを払えない、ベクトル検索の資産がすでにある
• Corpus2Skill：コーパスが安定している、構造化に業務担当者を巻き込める、ベクトル検索から降りる覚悟がある

という感じになります。

Corpus2Skillが勝ちやすい領域

ここまでの比較を踏まえて、Corpus2Skillが勝ちやすい領域を再整理しておきます。第2回で挙げた「向いている企業ナレッジ」と重なりますが、比較記事として明示しておく価値があります。

• single-domain × atomic-document：単一ドメインで、一文書一トピックに整理されたコーパス
• 章立て・節構成がドキュメント側に明示されている：規程、マニュアル、SOP、約款
• 条件分岐と例外規定が頻出する：法務、税務、保険、医療、金融
• 回答に出典の追跡可能性が求められる：監査、コンプライアンス、訴訟対応
• コーパスの更新頻度が中程度（週次〜月次程度）：蒸留コストが運用に乗る
• 業務担当者がレビューに参加できる：Markdownの目次を読める法務・人事・現場が組織内にいる

特に最後の点は、技術的なフィットだけでなく組織的なフィットとして重要です。Corpus2Skillの強みは「Markdownで階層を作る」ことにあるので、その階層を業務担当者がレビューできる組織でなければ、本来の価値の半分以上が現場に届きません。

Corpus2Skillが負けやすい領域

公平を期して、Corpus2Skillが負けやすい領域も明示します。これは特集として中立性を保つ上で、絶対に外せない部分です。

• open-domain × extractive pool：多ドメインを横断し、広く浅く抽出するタイプの問い
• コーパスが日次以上の頻度で更新される：再蒸留コストが運用に乗らない
• エンティティ関係が主体の問い：「誰が」「いつ」「どこで」を横断で集めたいタスク → GraphRAGが向く
• コーパスが極端に小さい（数十〜百ファイル）：LLMコンテキストに丸ごと入る規模では、蒸留が過剰
• コーパスがそもそも階層を持たない：チャットログ、SNS、メール、議事録のような断片群
• API/Skillsへの依存を許容できない組織：オンプレ完結が必須の場合、別途検討要

最後の点は、論文中でも触れられている API/Skills依存の話と接続します。Corpus2Skillの実装はClaude Skillsを前提に組まれているため、Anthropic APIへの依存が発生します。完全オンプレでLLMを運用する組織では、SKILL.mdを読めるOSS LLMエージェントを別途用意するか、設計を変える必要があります。

また、Corpus2Skill自体が early release / Work in Progress の位置づけであることも、押さえておきたい事実です。論文中でも以下の限界が明示されています。

• compile cost：階層蒸留に相応の計算と時間がかかる
• API/Skills依存：商用LLMのSkills機構に依存する
• hard single-path clustering：文書が複数領域に跨る場合、単一パスに押し込まれる
• navigation miss：階層設計が悪いと、エージェントが最初から間違った枝に降りる
• partial navigation：必要な情報の一部だけを拾って終わる
• synthesis error：複数枝の情報を統合する際の誤り
• 更新運用：コーパス更新時の再蒸留と差分管理

これらは現時点での既知の弱点であり、2026年現在は活発に改善が進んでいる領域でもあります。「銀の弾丸ではない」ことは、導入判断の最初の前提として置いておくべきです。

PoC設計：まず何を試すべきか

実務的に「導入を検討したい」となったとき、最初のPoCをどう設計するか。私が現場で勧める手順を、3ステップで整理します。

ステップ1：コーパスを1ドメインに絞る

最初のPoCで、複数ドメインの文書群をまとめて投入するのは厳禁です。Corpus2Skillはsingle-domain × atomic-documentで強みが出る技術なので、もっとも構造化されたドメインを1つ選ぶところから始めます。私の推奨は、社内規程（就業規則、ISMSポリシー、内部統制関連）か、運用マニュアル（システム運用SOP、業務手順書）です。

ステップ2：評価データセットを20〜50件、業務担当者と作る

エンジニアだけで評価データを作ると、ほぼ確実に「実際のユーザーが聞かない質問」のセットになります。業務担当者を巻き込み、「直近3ヶ月で実際に問い合わせがあった質問」を20〜50件、原文に近い形で集めるところから始めてください。少数でも、本物の質問は技術評価より遥かに価値があります。

ステップ3：同じコーパス・同じ評価セットで、既存RAGとCorpus2Skillを並走させる

PoCで一番やってはいけないのは、Corpus2Skill単独のスコアを見て「使えそう／使えなさそう」と結論することです。必ず、既存RAGと並走比較してください。

比較項目は、

• 回答精度（正解率、根拠ドキュメントのリコール）
• 回答の根拠の説明可能性（人間が追える経路かどうか）
• レスポンス時間
• 1問あたりのコスト（prompt caching込みで）
• 業務担当者の主観評価（「これなら社員に出せる」と思えるか）

の5項目が最低限です。とくに最後の主観評価を軽視すると、技術的に「同等」な結果でも、現場が受け入れない結論に直面します。

ハイブリッド構成案

PoCで効果を確認したら、本番ではハイブリッド構成が現実的です。Corpus2Skill単独で全社のAI知識基盤を組むより、第2回でも触れたように、領域ごとに技術を使い分けるほうが運用が安定します。

私が現場で提案する典型的なハイブリッド構成は、以下のような形です。

1. 入口にルーティングエージェント：ユーザーの質問を受け取り、性質を判定する
2. 規程・マニュアル・コンプライアンス系 → Corpus2Skill（Markdown階層ナビゲーション）
3. ナレッジ記事・ブログ・議事録系 → Hybrid RAG（Dense + BM25）
4. エンティティ関係を問うタスク → GraphRAG（必要なら段階導入）
5. 最新ニュース・社外情報 → 検索エンジンAPI連携（Google Custom Search、Brave Searchなど）

ここで重要なのは、ルーティングエージェント自体もClaudeで組み、判断ルールをMarkdownで書くことです。これにより、ルーティングロジックも業務担当者がレビューできる対象になります。「コンプライアンス系の質問だが、最近の通達を含むものは、規程ツリーと社内通達RAGの両方を確認すること」のような業務知識を、Markdownの判断指示として残せます。

このハイブリッド構成の利点は、段階的に移行できることです。最初は全部の質問を既存RAGに通しておき、Corpus2Skillで蒸留した規程ドメインの質問だけをそちらに振る。効果が出たら次のドメインを蒸留して、ルーティングルールに追加する。1年がかりで、徐々にCorpus2Skillの担当領域を広げていく、というロードマップが描けます。

導入判断表

最後に、現場での意思決定に使える簡易判断表を置いておきます。コーパスの特性に対して、どの技術を第一選択にすべきかの目安です。

これはあくまで第一近似であり、実際にはコーパスの規模、更新頻度、組織の技術成熟度、コスト制約などで変わります。「自社のコーパスはどこに置くか」を、技術者だけでなく業務担当者と一緒に議論することが、判断表を意味あるものにする条件です。

2026年以降のAI知識基盤の方向性

最後に、本特集の締めくくりとして、2026年以降のAI知識基盤がどこに向かうかについて、私の予想を残しておきます。

第一に、「retrieval一辺倒の時代は終わる」と思います。Corpus2SkillもGraphRAGもRAPTORもAgentic RAGも、それぞれに違うアプローチですが、共通しているのは「retrievalの賢さだけでは足りない」という認識です。検索は数ある道具のひとつに戻り、ナビゲーション、グラフ走査、階層要約、反復調査が並列の選択肢として整理されていきます。

第二に、「コーパスの前処理が、AI戦略の中心になる」と思います。RAGの時代、コーパスの前処理は「ベクトル化して放り込む」というほぼ自動の作業でした。これからは、コーパスをどう蒸留するか、どう階層化するか、どう関係を抽出するかが、各社のAI差別化の本丸になります。「LLMにどう渡すか」が、「どのLLMを使うか」より重い意思決定になっていきます。

第三に、「Markdownが標準的なAIインターフェースになる」と思います。Claude Skillsをはじめ、各社がエージェントに対するインターフェースをMarkdownで揃え始めています。コードでもベクトルでもなく、人間が読み書きできるMarkdownを、LLMと業務担当者の共通言語にする流れです。Corpus2Skillはその一例ですが、同じ思想はエージェントの行動定義、ワークフロー記述、業務手順の自動化など、隣接領域に広がっていくと思います。

第四に、「AI知識基盤の運用が、組織内で民主化される」と思います。RAGの時代は、ベクトルDBの面倒を見られる人だけがAI基盤を触れました。これからは、Markdownを読み書きできる人なら、業務担当者でも知識基盤に貢献できます。情シスやAIエンジニアの専有物だった知識基盤が、業務側に開かれるということです。これは、組織のAI活用の天井を、本質的に押し上げます。

結びに：RAG疲れの先に見えてきたもの

3回にわたる特集を終えるにあたって、最後にひとつだけ書いておきたいことがあります。

「RAG疲れ」という言葉は、技術的な敗北宣言ではありません。むしろ、LLMと知識基盤の関係について、もう一段考え直すべき時期に来たという合図です。Corpus2Skillはその合図に対するひとつの答えで、唯一の答えではありません。GraphRAGも、RAPTORも、Agentic RAGも、それぞれに違う形でこの合図に応答しています。

選ぶべきは、流行りの技術ではありません。自分たちのコーパスの性質を見極め、自分たちの組織が運用できる形を選ぶことです。本特集が、その選択の助けになれば幸いです。

検索しないAI知識基盤、ナビゲーション型RAG、エージェント型知識探索——いずれも、まだ完成形ではありません。2026年は、これらが本格的に企業導入される最初の年になると思います。野口真一としても、現場での導入支援を通じて、引き続き知見をアップデートしていきます。ご相談やフィードバックは、いつでも歓迎です。

想定SEOキーワード

• 主要：RAG 代替／RAG 代替 比較／GraphRAG／RAPTOR／Agentic RAG／Dense RAG／Hybrid RAG
• 副次：Corpus2Skill 比較／Corpus2Skill 導入／Claude Skills vs RAG／RAG ハイブリッド構成
• 比較系：GraphRAG vs Corpus2Skill／RAPTOR vs Corpus2Skill／Agentic RAG vs Corpus2Skill
• 導入判断系：RAG 選び方／企業 AI 知識基盤／社内文書 AI 比較／RAG PoC 設計
• 先取り：検索しないAI知識基盤／ナビゲーション型RAG／エージェント型知識探索／2026 AI 知識基盤

内部リンク候補

• 特集第1回：/blog/feature/rag-fatigue/01.html（仮、RAG疲れの定義）
• 特集第2回：/blog/feature/rag-fatigue/02.html（仮、Corpus2Skillの思想）
• /blog/2026-04-29-corpus2skill-zenpen.html（前編：技術的限界）
• /blog/2026-04-29-corpus2skill-kouhen.html（後編：実装手順）
• /blog/2026-03-27-rag-cost-reduction.html（RAGコスト削減）
• /blog/2025-07-01-vector-database-rag.html（ベクトルDBとRAG入門）
• /services.html#ai（AI導入コンサルティング）
• /portfolio.html（社内ナレッジAI導入実績）
• /glossary/（用語集：GraphRAG／RAPTOR／Agentic RAG／Claude Skills）
• /contact.html（無料技術相談）

既存記事との差別化メモ

• 既存前編は「RAG限界 → Corpus2Skill」という単線で扱っているが、本稿はGraphRAG、RAPTOR、Agentic RAG、Dense/Hybrid RAGとの並列比較で多角化し、検索意図「RAG 代替 比較」を真正面から拾う
• 既存後編は実装手順（コマンド・コード）に特化しているが、本稿はコードを一切出さず、PoC設計・ハイブリッド構成・導入判断表という意思決定レイヤーに特化し、役割を明確に分離
• 「Corpus2Skillが負けやすい領域」を明示し、論文中のlimitation（compile cost、navigation miss、partial navigation、synthesis error、API/Skills依存、hard single-path clustering）を編集者として中立に扱う姿勢を打ち出した。既存2記事ではここまでの弱点列挙はしていない
• 導入判断表（8コーパスタイプ × 第一選択／第二選択／備考）は、本特集の現場向け資産として独自に作成。検索意図「RAG 選び方」「企業 AI 知識基盤」を直接回収
• 「2026年以降の方向性」4点（retrieval一辺倒の終焉／前処理の戦略化／Markdownの標準化／知識基盤の民主化）は、特集の締めくくりとしての未来予想として独自の編集論点
• 既存記事のCTA構造（無料相談）を踏襲しつつ、特集連載の「結びに」として明示的に第1回・第2回からの読み筋を引き継ぐ構成にした