スキルツリー構造とナビゲーション

コンパイルパイプラインの出力である「スキルツリー」は、Corpus2Skillの心臓部です。本ページでは、ツリーを構成するファイルの役割と階層の設計、そしてサーブ時にLLMエージェントがどのようにツリーを歩いて文書へ到達するのか——ドリルダウンとバックトラックの実際の動きを解説します。

スキルツリーの階層構造

スキルツリーは、ルート（鳥瞰ビュー）→中間ブランチ→リーフ→文書という4層のイメージで捉えると理解しやすい構造です。ルートには、コーパス全体を数個（--max-topで上限指定、既定の目安は8個以内）のトップレベルスキルに大別した一覧が置かれます。各トップレベルスキルの配下には、より細かいトピックのブランチが続き、末端のリーフには「この話題について書かれた文書はこれ」という文書IDへの対応表が置かれます。

この構造の妙は、上に行くほど抽象的で短く、下に行くほど具体的で詳しいという要約の勾配にあります。エージェントは最初に短い鳥瞰ビューだけを読めばよく、関心のある枝についてだけ詳細を読み込みます。コーパス全体を読み込む必要も、全文書を検索する必要もありません。人間が本の目次から章、節へと読み進める行動と同じ構造です。

この設計は、LLMのコンテキストウィンドウという有限資源の使い方としても合理的です。コーパス全体を丸ごとコンテキストへ入れる方式は、コーパスが数百文書を超えた時点で物理的に不可能になり、可能な規模でも「大量の無関係情報の中から答えを探す」というLLMが苦手な状況を作ります。スキルツリーは、いま必要な粒度の情報だけを段階的にコンテキストへ供給することで、コンテキストを常に「質問に関係する情報が濃い状態」に保ちます。回答品質とコストの両方に効く、資源配分の仕組みと捉えることができます。

SKILL.md・INDEX.md・documents.jsonの役割

ツリーの各ノードは、ファイルシステム上のディレクトリとして実体化されます。中心となるファイルは3種類です。

• SKILL.md：そのノード（スキル）が扱う話題の説明文です。コンパイル時のSummarize段階でLLMが生成した要約が書かれており、エージェントが「この枝に降りるべきか」を判断する主要な材料になります。
• INDEX.md：子ノードへの案内板です。配下にどのようなサブトピックがあるかを、Label段階で生成された短いトピックラベルとともに一覧化します。
• documents.json：文書IDと文書本文の対応表です。リーフで特定した文書IDから全文を引くために使われます。

このディレクトリ構成は.claude/skills/規約に準拠しているため、Anthropic Skills APIのスキルとしてそのまま利用可能です。スキルの説明を読んで必要なものだけを深く読み込むというSkills APIの動作モデルと、スキルツリーの「抽象から具体へ」の勾配設計は、相互に噛み合うように作られています。汎用のMarkdownとJSONで実体化されているため、人間がエディタで開いて中身を検証・修正できる点も、運用上の大きな利点です。

ファイルとして開かれた構造は、デバッグのしやすさにも直結します。エージェントの回答が期待と違ったとき、探索ログに残るノードのパスをたどってSKILL.mdを開けば、「どの要約がエージェントを誤誘導したのか」を人間が直接確認できます。ベクトル検索で「なぜこのチャンクが上位に来たのか」を説明することの難しさと比べると、原因究明の透明性は段違いです。問題のノードを特定できれば、コーパス側の文書を改善して再コンパイルするという、根本からの改善サイクルが回せます。

ドリルダウンとバックトラックの動作

サーブ時のエージェントは、質問を受け取ると次のようなループでツリーを歩きます。まず現在地のSKILL.mdとINDEX.mdを読み、質問との関連が最も高そうな子ノードを選んで一段降ります（ドリルダウン）。降りた先の要約を読み、期待した内容であればさらに降り、リーフに到達したら文書IDを特定します。もし降りた先の内容が質問と噛み合わなければ、その枝を放棄して親ノードへ戻り（バックトラック）、次に有望な枝を選び直します。

バックトラックの存在は、単純な「一発検索」との決定的な違いです。従来RAGでは最初の検索が外れると回復の機会がありませんが、ナビゲーション型では探索の失敗をエージェント自身が検知し、やり直せます。また、複数のトピックにまたがる質問では、一つの枝で文書を確保した後に別の枝も探索する、といった柔軟な動きも可能です。

具体例で考えてみます。「年間契約の途中で上位プランへ変更した場合、請求はどうなりますか」という質問を受けたエージェントは、鳥瞰ビューから「決済・請求」のスキルへ降ります。まず「返金処理」のブランチを覗くかもしれませんが、要約を読んで「これは解約時の話であり、プラン変更の話ではない」と判断すれば、親へ戻って「請求サイクル」のブランチを選び直します。プラン変更時の日割り計算を説明する文書に到達すれば、そのIDを控えて全文を取得します。検索エンジンなら「返金」「変更」などの語に引きずられて雑多な断片を返しがちな質問でも、トピックの階層をたどる探索なら文脈に沿った到達が期待できます。

文書取得と回答生成

リーフノードで根拠となりうる文書IDを特定したエージェントは、get_documentツールを呼び出してdocuments.jsonから文書全文を取得します。ここで初めて「原文」がコンテキストに入る点が重要です。ナビゲーション中にエージェントが読んでいたのは要約とラベルだけであり、回答の根拠は必ず取得した原文に基づきます。要約の伝言ゲームで事実が歪むことを防ぎ、回答のグラウンディング（根拠の裏付け）を確保する設計です。

また、チャンク分割された断片ではなく文書単位で全文を取得するため、手順書や規約のように前後の文脈が重要な文書でも、文脈の欠落が起こりにくくなります。取得した文書が複数あれば、エージェントはそれらを突き合わせて回答を構成し、どの文書を根拠にしたかを添えて返すことができます。この探索ログと根拠文書の明示は、エンタープライズ用途で求められる監査可能性・説明可能性に直結します。

回答できない場合の振る舞いも重要です。ツリー全体を探索しても該当する文書が見つからなければ、エージェントは「探索したがコーパスに情報がない」という状態を認識できます。従来RAGでは、検索が無関係な断片を返してもLLMはそれを材料に回答を試みてしまい、根拠のない回答が生まれやすいのに対し、ナビゲーション型では「見つからなかった」ことを探索の履歴として示したうえで回答を差し控える判断がしやすくなります。誤答が業務リスクに直結するエンタープライズQAでは、この「わからないと言える」性質が実運用の信頼性を支えます。

ツリー形状を決める設計パラメータ

ナビゲーションの効率は、ツリーの形状に大きく左右されます。形状を決める主なパラメータは、コンパイル時に指定する--p（分岐率）と--max-top（トップレベルスキルの最大数）、そして--compact（リーフインデックスの統合）です。分岐率を上げると木は浅く広くなり、少ない段数でリーフに到達できる一方、各ノードで読む選択肢が増えます。分岐率を下げると木は深く狭くなり、1ステップの判断は軽くなりますが、到達までの段数が増えます。

実務では、コーパスの規模とトピックの多様性に応じて調整することになります。小規模なコーパスであれば--compactでリーフインデックスを統合し、ナビゲーション段数そのものを減らす選択が有効です。パラメータの具体的な指定方法は「導入手順」で、探索ステップ数とコストの関係は「コスト最適化」で扱います。

形状調整の目安として、生成後のツリーで「リーフまでの平均段数」と「1ノードあたりの子の数」を確認する習慣をおすすめします。平均段数が5を超えるような深い木は探索コストがかさみ、逆に子が十数個も並ぶノードはエージェントの選択を難しくします。人間の目次設計と同じで、「一目で選べる選択肢の数」と「たどり着くまでのクリック数」の均衡点を探すことが、良いスキルツリーの条件です。