Corpus2Skillの仕組みと
「遅くて高い」ジレンマ

第1章では、従来のRAGが文書を数百文字のチャンクに切り分け、ベクトル検索で近い断片だけを拾うことで「文脈の断片化」を起こす問題を見ました。RAGを速くしたい、安くしたいという要望は切実ですが、断片化を抱えたまま検索だけを高速化しても、誤答の速度が上がるだけです。

この章で取り上げるCorpus2Skill（コーパス・トゥ・スキル）は、断片化そのものを設計から取り除く試みです。仕組みを順に分解し、そのうえで実運用を阻んでいた「遅くて高い」というジレンマの正体を確かめます。このジレンマの構造を理解すると、「RAG Jev」で検索してたどり着いた読者が本当に探している答え、つまりJevをどこに組み込むべきかが見えてきます。

Corpus2Skillとは何か

Corpus2Skillは、論文「Corpus2Skill: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG」（Yiqun Sun、Pengfei Wei、Lawrence B. Hsieh）で提案された検索アーキテクチャです。2026年4月にarXivで初版が公開され、8月の第4版を経てEMNLP 2026 Findingsに採択されています。実装はMITライセンスのOSSとしてGitHubで公開されています。

最大の特徴は、ベクトルデータベースもBM25の索引も使わない点です。代わりに、文書の集まり（コーパス）を人間が目次をたどるように探せる階層フォルダ、すなわち「スキルツリー」へ事前に変換します。論文の副題にある「Navigable（探索可能な）」という語が示すとおり、検索エンジンに断片を探させるのではなく、AIエージェント自身に地図をたどらせる発想です。

オフラインで知識を「コンパイル」する

Corpus2Skillの処理は、事前準備のオフライン・コンパイルと、質問のたびに動くオンライン・サーブの2段に分かれます。まずコンパイル側から見ていきます。

6段階のパイプライン

コンパイラは、テキスト・Markdown・JSON・JSONL形式の文書を読み込み、次の6段階でスキルツリーを組み立てます。詳細は当サイトの「コンパイルパイプライン」で解説していますが、要点は「似た文書を束ね、束ごとに要約と見出しを付け、フォルダとして書き出す」ことです。

ここで見落としやすいのは、Embed段階で埋め込みモデル（既定はQwen/Qwen3-Embedding-0.6B）を使っている点です。ベクトルを捨てたわけではなく、ベクトルは地図を作る測量にだけ使い、道案内には使わないという役割分担になっています。要約と見出しの生成には既定でclaude-sonnet-4-6が呼ばれます。

実行コマンドと主なパラメータ

コンパイルはCLIの1コマンドで実行します。ツリーの形を決める主要パラメータは分岐率と最上位スキル数です。

# 文書ディレクトリをスキルツリーへコンパイル（分岐率10）
python -m corpus2skill --input ./docs --output ./compiled_output --p 10

# 自社QAセット（JSONL）で品質とコストを評価
python -m corpus2skill.eval --output-dir ./compiled_output \
    --qa ./qa.jsonl --output eval_results.json

出力されるフォルダ構造

コンパイル結果は .claude/skills/ 配下に、人間がエディタで開けるMarkdownとJSONとして出力されます。社内規程を例にすると、次のような構造になります。

.claude/skills/
├── SKILL.md                 # 鳥瞰ビュー：全体の地図
├── hr-labor/                # 人事・労務スキル
│   ├── SKILL.md             # 何に答えられる枝かの要約
│   ├── INDEX.md             # 子ノードの一覧
│   ├── leave/               # 休暇
│   │   └── INDEX.md         # 文書IDとタイトルの一覧
│   └── travel-expense/      # 出張・旅費
│       └── INDEX.md
├── it-systems/              # IT・システムスキル
│   └── ...
└── documents.json           # 原文全文（チャンク分割なし）

SKILL.mdは、たとえば次のような短い文書です。探索するAIにとっては、本の章扉に書かれた「この章で扱うこと」に相当します。

---
name: travel-expense
description: 国内・海外出張の旅費、宿泊費、日当、精算手続きに関する規程
---
## この枝で答えられる質問
- 役職別の宿泊費上限、日当の金額
- 出張申請と事後精算の手順、必要書類
- 例外規定（役員の実費精算、災害時の特例など）

## 含まれる文書
INDEX.md を参照（旅費規程 本則・細則、精算マニュアル ほか）

文書そのものは一切チャンクに切られず、documents.json に手付かずのまま保存されます。ツリーは要約と見出しだけで組まれた「目次」であり、本文の置き場所とは分けられています。この分離が、次に見るサーブ時の高い事実性を支えます。なお、この構造は .claude/skills の規約に沿っているため、AnthropicのSkills APIへそのまま載せることもできます。

オンラインで目次をたどる

質問が届くと、LLMエージェントはスキルツリーの上から順に目次を読み進めます。動きは、人が分厚い規程集で答えを探すときとほぼ同じです。

1. 俯瞰する：最上位のSKILL.mdで全体の地図を読み、「出張の宿泊費」なら人事・労務の枝が有望だと判断します。
2. ドリルダウンする：その枝のINDEX.mdを読み、さらに「出張・旅費」へ降ります。
3. バックトラックする：降りた先の要約が質問と噛み合わなければ、親へ戻って別の枝を選び直します。
4. 原文を取得する：末端のINDEX.mdで文書IDを特定し、get_documentで原文全文を読み込んでから回答を書きます。

なぜ「ただし書き」を落とさないのか

第1章の例を思い出してください。「国内出張の宿泊費は一律1万円」という第1項と、数ページ離れた「ただし役員は実費精算」という第5項です。ベクトル検索は質問と似たチャンクを拾うため、第1項だけが選ばれ、第5項が捨てられる危険がありました。

Corpus2Skillでは、探索中のAIが読むのは要約と見出しだけで、最後に取り出すのは旅費規程という文書の全文です。第1項と第5項は同じ文書の中にあるので、両方が必ずAIの目に入ります。断片の「近さ」ではなく、文書という意味のまとまりで根拠を渡すことが、事実性の高さの源泉です。論文でも、企業のカスタマーサポート型ベンチマークで、密ベクトル・ハイブリッド・階層型・エージェント型の各RAGを回答品質と根拠性（グラウンディング）の両方で上回ったと報告されています。

得意なコーパス、不得意なコーパス

ただし万能ではありません。論文の11データセットを使った比較では、フラット検索に対して5勝3分3敗でした。著者自身が「コーパスの探索は検索の普遍的な代替ではない」と明記しています。

社内ナレッジベースやサポート用FAQの多くは、最初の行に当てはまります。つまり、社内AI検索やナレッジベースのチャット回答を作りたい読者にとって、Corpus2Skillは有力な選択肢です。適用判断の詳細は「エンタープライズ活用と適用判断」も参照してください。

致命的な弱点「遅くて高い」

精度の面では理想に近いCorpus2Skillにも、実運用を阻む壁がありました。探索にかかる時間と費用です。

探索の1歩ごとに文章生成AIが動く

図2の矢印の1本1本は、LLMへの1回の問い合わせです。エージェントは目次を読み、「次は出張・旅費の枝を開く」というツール呼び出しの文を生成します。文章生成型のLLMは、トークンを1つずつ順に予測して出力する自己回帰生成で動くため、短い命令文でも、入力の読み込みと生成に一定の時間がかかります。

しかも探索は直列です。次にどの枝を開くかは、いま開いた目次を読まないと決まりません。3階層を降り、1回引き返し、文書を取得して回答を書けば、LLMの往復は少なくとも5〜6回になります。1回ごとの待ち時間がそのまま積み上がります。

1回あたりの応答時間は、モデル、入力の長さ、混雑状況で大きく変わるため、上の表はあくまで構造を示すための試算です。それでも、待ち時間がステップ数に比例して伸びること、複雑な質問では利用者が数十秒待たされうることは読み取れます。チャット画面で十数秒の無反応が続けば、利用者は離脱するか、同じ質問を送り直してしまいます。

費用も探索の深さに比例する

費用面も同じ構造です。探索の各ステップでは「これまで読んだ目次＋新しい目次」を毎回入力として送るため、入力トークンが累積的に増えます。論文がWixQAベンチマークで報告した1クエリあたりの費用は、プロンプトキャッシュなしで0.172ドル、キャッシュありで0.089ドルでした。1ドル150円で換算すると、それぞれ約26円と約13円です。

キャッシュ有効時は入力の約70%が通常の1/10の料金で読まれ、費用はほぼ半減します（詳しくは「コスト構造とプロンプトキャッシュ」）。それでも論文自身が「中程度のコスト増」と認めているとおり、検索1回と生成1回で済む単純なRAGに比べれば、探索のぶんだけ割高になります。問い合わせが日に数千件規模になると、この差は無視できません。

探索は「選ぶだけ」の作業

ここで、探索の各ステップでAIが実際に何をしているかを見直してみます。目次に並ぶ8個や10個の枝から1つを選ぶ。候補の文書リストから、回答に必要なものに印をつける。引き返すかどうかを決める。どれもあらかじめ決まった有限の選択肢から選ぶ判断であり、自由な文章を書く必要はありません。

にもかかわらず、従来の実装では、文章を書くために作られた重厚なLLMに、ツール呼び出しの文を生成させて選択させていました。本来は一瞬で済むはずの「選ぶ」作業に、「書く」ための機構を使っていたことになります。これが遅さと高さの根本原因です。

表のとおり、文章生成が本当に必要なのは最後の1工程だけです。そこで浮かぶ問いが、「選ぶ工程だけを、選ぶことに特化したAIに任せられないか」です。

この問いに正面から答えるのが、TypeSafe AIが2026年9月に早期アクセスを始めた判断特化型モデル「Jev」です。Jevは文章を生成せず、選択（choice）・採点（score）・Yes/No判定（noul）の答えだけを確率付きで返します。ベンダー公表のレイテンシは70〜500ミリ秒で、出力トークンは課金されません。

次の第3章では、Jevとはどのようなモデルなのか、なぜ速く安いのか、そして弱点はどこにあるのかを、公開情報と当編集部の利用経験から詳しく見ていきます。