本を24倍に圧縮してエージェントに食わせる — book-to-skillと知識の新しい包装単位
本を24倍に圧縮してエージェントに食わせる — book-to-skillと知識の新しい包装単位
本を丸ごと読ませる代わりにエージェントが参照する形に再包装する — これは検索(RAG)の焼き直しなのか、それとも知識流通の単位そのものが変わる兆候なのか。
導入
7月30日、GitHubトレンド日間1位は virgiliojr94/book-to-skill だった — 1日1,421スター。このツールがやることは一文に要約できる。技術書・文書・知識資料をエージェントが使える「スキル(skill)」に変換し、元のPDFを丸ごとコンテキストに押し込むのに比べてトークン消費を24〜51倍減らす。
エージェントに膨大な参考文献を付けて使う実務者にとって、この数字は即座に意味を持つ。300ページの技術書を毎セッションのコンテキストに入れるのは、コスト的にも性能的にも持続不可能だ — まさに前日のHANDBOOK.mdが示したロングコンテキスト劣化の問題と正確に接する地点である。book-to-skillの提案は「全部入れるな、必要なものだけ取り出せるよう事前に構造化しろ」というものだ。
トークンコストを具体化すれば魅力が明確になる。300ページの技術書をおよそ15万トークンと見積もると、毎セッション全体を入れるのは入力コストだけでも負担で、しかも後半はぼやける。book-to-skillが約束する24〜51倍圧縮はこれを3千〜6千トークン規模の常時ロード可能なサイズに下げる。常にオンにしておく4Kトークンの核心と、クエリに応じて呼び出す1Kトークンの章 — この階層構造が「必要なものだけ」という原則をトークン会計に翻訳したものだ。
しかしこのツールがトレンド1位に上ったのは単にトークン節約のためではない。その裏には二つのより大きな問いがある。一つは技術的な問い — これは我々が数年使ってきたRAG(検索拡張生成)と何が違うのか。もう一つは法的な問い — 著作権のある本をエージェント用スキルに変換して配布するのは何を侵害するのか。本稿はその二つの問いを追う。
何をどう圧縮するのか
book-to-skillのパイプラインは三段階だ。この構造を理解すると、このツールがRAGとどこで分かれるかが見える。
第一に、抽出。 PDF・EPUB・DOCXからMarkdown・HTML・MOBIまで幅広いフォーマットを受け付ける。「技術」モードはDoclingで表とコードを保存しつつページあたり約1.5秒、「テキスト中心」モードはpdftotext/pypdfで即時処理する。ここまでは通常の文書パースだ。
第二に、分析。 ここで決定的な違いが出る。Claudeが文書の構造を分析して章(chapter)を検出し、原文を要約するのではなくフレームワークを合成(synthesize)する。リポジトリの表現を借りれば、スキルは「構造化された散文を推論ツールに変えたもの」であり、キーワードで検索可能なテキストではなく、事前抽出されたフレームワークと意思決定ルールだ。
第三に、出力。 成果物はスキルフォルダだ — 核心的なメンタルモデルと章インデックスを収めた約4Kトークンの SKILL.md、必要時にのみロードされる章別ファイル(各約1Kトークン)、そして glossary.md・patterns.md・cheatsheet.md のような参照レイヤー。エージェントはこのフォルダを丸ごと読まず、/book-slug topic-query の形で必要な断片だけを選択的にロードする。
この設計はRAGと表面的には似ているが哲学が違う。RAGは原文をチャンクに分割して埋め込み、クエリに類似するチャンクを検索してそのまま貼る — 知識の原型を保存しつつ検索時点で関連断片を探す方式だ。book-to-skillはその逆である。検索時点ではなく変換時点で、人(正確にはClaude)が本全体を読んでフレームワーク・決定ルール・チートシートに再構造化する。RAGが「探して貼る」なら、これは「あらかじめ消化して箇条書きに要約する」に近い。
24〜51倍という圧縮比はこの違いから来る。RAGは関連チャンクを原文のまま貼るのでチャンクサイズ分のトークンを使う。book-to-skillは原文を捨てて合成された構造だけを残すので圧縮比が劇的だ。代わりに失うものがある — 原文の正確な文言、ニュアンス、そして合成過程でClaudeが欠落させたり歪めたりした部分を事後に検証する方法だ。
二つの方式が排他的でない点も押さえておく価値がある。実務では階層を分けられる — 概念的な骨格と意思決定ルールはbook-to-skill式の合成スキルとして常時ロードし、正確な引用が必要な瞬間にはRAGで原文チャンクを引いてくるハイブリッドだ。スキルが「何をどこで探すか」の地図を提供し、RAGが「その地点の原文」を供給する役割分担である。実際、book-to-skillの章別ファイル構造は、この2段階照会 — まず索引、次に詳細 — を念頭に置いた設計として読める。
知識包装の新単位、そしてその代償
このツールの真の意味はトークン節約を超える。book-to-skillは知識の流通単位が「文書」から「エージェントが消費する構造」へ移動しつつあることを示す兆候だ。
技術的含意。 前日のHANDBOOK.mdの結果と重ねて読むと、このツールの論理が鮮明になる。HANDBOOK.mdは長い文書を丸ごと与えてもエージェントが従わないことを示した。book-to-skillは正反対の方向から同じ問題を攻略する — そもそも長い文書を丸ごと与えず、4Kトークンの核心とオンデマンドの章に分けて与えようというものだ。文書の実効密度を高める二つの処方のうち、HANDBOOK.mdが「核心ルールの再注入」を示唆したなら、book-to-skillは「事前構造化」を実装したことになる。Agent Skillsという開かれた標準を通じてClaude Code・Copilot CLI・Ampに広く挿さる点も、これが特定ベンダーの機能ではなくフォーマット競争の一候補であることを示唆する。
しかし代償は明確だ。合成圧縮は非可逆圧縮である。原文を捨ててClaudeの要約だけを残せば、その要約が間違っていたとき戻る原本がコンテキストにない。技術書の微妙な手がかり — 「ただし、Xの場合は例外」のような — がフレームワーク合成の過程で蒸発すれば、エージェントはその例外を永遠に知らない。これは「クエリ時点で原文チャンクを見る」RAGのほうがむしろ優れる地点だ。圧縮比と忠実度(fidelity)はトレードオフであり、book-to-skillはその軸の圧縮の極端に立っている。
法的含意。 ここが本当の地雷原だ。リポジトリはこの問題を正直に扱う — 変換器のコードはMITライセンスで、ツール自体は本の内容を含んで配布せず(処理はローカルで)、ユーザーが作った成果物はユーザー所有で学習ノートに準じるという立場だ。しかし同じ文書がすぐに警告する — 著作権のある著作物の生成されたスキルを再配布すれば侵害になりうる、と。
この境界線は思ったより微妙だ。個人が買った本を自分の学習用スキルに変換してローカルで使うのは私的利用に近い。しかしそのスキルフォルダをGitHubに上げたりチームに共有したりする瞬間、「学習ノート」と「二次的著作物の配布」の間の線を越える。合成要約が原文をどれだけ代替するか — つまり市場代替性 — がフェアユース判断の核心変数であり、24〜51倍圧縮されたフレームワークが原書購入を代替するなら、その防御は弱くなる。箇条書き要約だからといって著作権を逃れるわけではない。表現ではなく構造や選択・配列にも創作性が認められうるからだ。
この構図は見慣れている。LLM学習データ論争が正確に同じ軸を回っている — 著作物を大量に消化して作った成果物が原著作物の市場を代替するか。book-to-skillはその論争を個人規模に縮小して再現する。大手ラボの学習が数百万冊を消化することなら、このツールは一人が一冊を消化することだ。規模は違うが法理の争点 — 市場代替性と変形的利用 — は同一である。違いがあるとすれば、大手ラボは法務チームとライセンス交渉力を備えているが、GitHubにスキルを上げる個人はそうではない点だ。
同じ週のGitHubトレンドには deepfakes/faceswap も再び上がっていた。無関係に見えるが共通点がある — どちらも「技術的に可能なこと」と「法的・倫理的に許されること」の間隙に立つツールだ。book-to-skillの人気は、その間隙をユーザー各自が負えという免責の上に立っている。
実務者へ、そして知識生産者へ
このツールが投げかける実務的な問いを整理する。
消費者(エンジニア)の視点。 book-to-skillは社内文書・オープンライセンス資料・自分が買った参考書をローカルエージェント用に圧縮するのに即座に有用だ。ただし二つを守らねばならない。第一に、非可逆圧縮であることを忘れないこと — 正確性が重要な規程・APIスペックは合成要約ではなく原文参照やツールゲートで扱うべきだ(HANDBOOK.mdの教訓)。第二に、配布境界を守ること — 著作権のある本のスキルはローカルにとどめるべきで、共有リポジトリに上げる瞬間に侵害リスクが現実化する。
生産者(著者・出版社)の視点。 ここがより大きな変化だ。知識が「読まれる本」から「エージェントが参照するスキル」へ消費形態を変えると、著者の収益モデルと統制権が揺らぐ。一冊買ってスキルに変換すればそのチーム全体が原書なしで核心を使えるなら、販売単位と消費単位の乖離が大きくなる。逆に機会もある — 出版社が公式スキルフォーマットを自ら提供することだ。忠実度を統制した公認スキルを、著者が検収して配布するモデル。「エージェントが読む版」が紙の本・電子書籍に続く第三の判型になりうる。
展望シナリオ — 楽観的には、Agent Skillsが標準として定着し、出版社が公認スキルを販売する正式な市場が開き、忠実度と著作権が共に解決される。悲観的には、著作権本の非公式スキルがGitHubに氾濫し、大規模な侵害紛争が起きてツール自体が規制対象になる。現実的な中間値は、社内・オープン資料の圧縮という安全な用途で広く使われつつ、著作権資料の変換はグレーゾーンで個人利用として静かに続く — LLM学習データ論争が歩んできた道を縮小版で反復する — 状態だろう。
結論
リード質問に答えるなら、book-to-skillはRAGの焼き直しではなく、知識包装単位の移動を示す兆候だ。検索時点ではなく変換時点で知識を消化しておくこのアプローチは、ロングコンテキストの限界という実在する問題への合理的な対応であり、24〜51倍という数字がその魅力を証明する。しかしその圧縮は忠実度を代償に支払い、その再包装は著作権という未解決の地雷の上に立っている。
一冊の本を4Kトークンに消化するというのは驚異的な効率であり危険な単純化だ。二日にわたる二つのツール — HANDBOOK.mdとbook-to-skill — は実は同じコインの両面である。一方は長い文書をエージェントが従えないことを測定し、もう一方はならば文書を短く再包装しようと提案する。二つを重ねれば2026年夏のエージェント実務の核心的な問いが浮かび上がる — エージェントに何を、どれだけ、どんな形で与えるか。コンテキストは無限ではなく、無限のふりをしても後半はぼやける。
あなたが次にエージェントに食わせる知識は原文か、誰かの合成要約か — そしてその要約が見落とした「ただし、Xの場合は例外」をあなたはどう気づくのか。知識を圧縮する時代に、圧縮されていない原本へのアクセス権こそが新しい特権になるかもしれない。
出典: