書籍・動画をSkillsに蒸留するOSS「cangjie-skill」の仕組み

Claude Code や Cursor の Agent Skills を運用していると、「読み終えた技術書の内容を Skill として社内で使い回したい」「1 時間超のオンライン講座から使える方法論だけを抜き出したい」といったニーズが自然に出てきます。ですが、単に PDF を要約するだけでは「トリガー可能な Skill」にはならず、いざ Claude Code から呼び出したくても粒度が合わないという壁にぶつかりがちです。

要約と Skill 化の間には「どの場面で、どんな入力条件のときに、何を返すか」を設計するギャップがあります。このギャップを人手で埋め続けるのは現実的ではなく、書籍・長尺動画のような密度の高いコンテンツを扱うほどコストが跳ね上がります。

こうした課題に対して、書籍・長尺動画・ポッドキャスト・講座などの長文コンテンツを、Agent から呼び出せる Skill 群へ「蒸留」するプロセスをフレームワーク化した OSS が kangarooking/cangjie-skill です。中核には RIA-TV++ と呼ばれる 7 段階のパイプラインが定義されており、姉妹プロジェクトの nuwa-skill・darwin-skill と組み合わせて 1 つのエコシステムを構成しています。

本記事では、cangjie-skill が何をする OSS なのか、RIA-TV++ 7 段階の中身、類似 OSS との住み分け、実運用上の留意点、そして自プロジェクトに導入すべきかの判断軸までを、リポジトリの README と SKILL.md に基づいて整理します。

cangjie-skillとは — 書籍・長尺コンテンツを蒸留するOSSの概要

cangjie-skill は、書籍・長尺動画・ポッドキャスト・講座・インタビューなど、体系的にまとめられた長文コンテンツから方法論を抽出し、Claude Code / Cursor などの Agent Skills として呼び出せる形へ蒸留するためのメタ Skill プロジェクトです。プロジェクトオーナーは kangarooking で、リポジトリ名は cangjie-skill（全て小文字ハイフン区切り）です。

リポジトリ基本情報は以下のとおりです（gh api /repos/kangarooking/cangjie-skill 取得値。2026 年 7 月 19 日時点）。

archived が false かつ fork が false であるため、本記事執筆時点でリポジトリはアクティブに更新されているオリジナルのプロジェクトです。ライセンスは MIT のため、社内利用・派生実装ともに一般的な OSS 利用の範囲で扱えます。最終 push が 2026-07-16 であり、直近でもメンテナンスが継続していることが確認できます。

cangjie-skill の位置づけを理解する上で重要なのが、姉妹プロジェクトとの役割分担です。README「生态」節と SKILL.md 末尾のエコシステム説明では、以下 3 つが 1 つのエコシステムを構成するとされています。

• nuwa-skill: 「人」を蒸留する。思考スタイルや表現の DNA を Skill として抽出（例: 特定人物 Skill、著述家 Skill）
• cangjie-skill（本リポジトリ）: 「書物・長文」を蒸留する。方法論・フレームワーク・原則を Skill として抽出
• darwin-skill: 「Skill 自体」を進化させる。評価 → 改善 → テスト → 保持または巻き戻しの改善サイクルを回す

なお、SKILL.md の「边界」節では「著者ロールプレイは対象外（そちらは nuwa-skill の役割）」と明確に線引きされており、単なる要約や書評とも異なる立ち位置であることが強調されています。cangjie-skill は「いつ・どの場面で・どう呼び出すか」がトリガー可能な形で Skill を生成する点が、要約ツールとの本質的な差異です。

cangjie-skillが解決する課題

README「解决什么问题」節では、cangjie-skill が解決を目指す課題として次のようなものが挙げられています。

• 多くの本を読んだが、実運用で活用しづらい
• 要約は「圧縮」であって、構造化された再利用にはならない
• 既存の読書方法論（アドラー式読書法・ツェッテルカステン等）は人間向けであり、Agent から呼び出せる形式には整理されていない
• 書籍単位で「使えるスキル群」を並列化された形で蓄積する仕組みが不足している

言い換えると、cangjie-skill は「本を読んで学ぶ」プロセスと「Agent が実行できる Skill 群を作る」プロセスの間にあるギャップを埋めるために設計されています。書評・書籍要約と cangjie-skill が生む成果物の違いは、以下のように整理できます。

• 書評・要約: 人間が「読む」ためのテキスト。再利用の際は再度読み込みが必要
• cangjie-skill の出力: Agent が「特定のシーンで呼び出す」ためのトリガー付き Skill。Claude Code などから条件一致時に自動的に参照される

日本語圏の技術書コミュニティで頻出する「積読を有効活用したい」「読了した書籍の知見を業務で再利用したい」といった悩みに対して、cangjie-skill は「読了本を Agent の実行可能資産に変える」というアプローチで応えるプロジェクトと言えます。

中核パイプライン RIA-TV++ の7段階

cangjie-skill の中核は、methodology/00-overview.md で定義されている RIA-TV++ という 7 段階パイプラインです。ここでは各段階の入力・処理・成果物を整理します。

RIA-TV++ という名前の意味

README「RIA-TV++ という名前の由来」節では、この名称は次のように分解されます。

• RIA: 趙周『これで読書は十分』の便箋読書法（Reading / Interpretation / Appropriation）。読んだ内容を実務に接続する読書法として中国語圏で広く知られている手法
• TV: Triple Verification（三重検証）。抽出した各ユニットを 3 つの観点で検証する工程
• ++: エージェント実行志向の拡張。E（Execution: 実行可能ステップ）と B（Boundary: 境界）を追加した拡張

つまり RIA-TV++ は「人向けの読書法である RIA を、三重検証と実行可能性の追加によって Agent 向けに拡張したもの」と理解できます。

段階 0: Adler 分析（全書理解）

モーティマー・アドラーの分析的読書法（アドラー式読書法）に基づき、対象コンテンツを「構造 / 解釈 / 批判 / 応用」の 4 ステップに分解して全体像を把握します。この段階の成果物は BOOK_OVERVIEW.md として保存され、後段の抽出処理で参照されます。

段階 1: 5 エージェント並行抽出

extractors/ 配下に定義された 5 種類の抽出プロンプト（フレームワーク / 原則 / 事例 / 反例 / 用語）を並列で走らせ、候補ユニット群を出力します。成果物は candidates/<type>.md として保存されます。単一のエージェントで抽出するのではなく、種類ごとに専門化した抽出器を並行で動かす点が特徴です。

段階 1.5: 三重検証（Triple Verification）

段階 1 で抽出された候補に対して、以下 3 つの検証を実施します。

• V1（クロスドメイン検証）: 原文中に独立した裏付けが 2 箇所以上あるか
• V2（予測力検証）: 未明示の質問に対して答えられるだけの一般性を持つか
• V3（独自性検証）: 常識的な内容に過ぎないものではないか

README の記述によれば、通常この三重検証を通過するのは候補の 25〜50% 程度に留まります。通過したユニットは verified.md に、落選したものは理由とともに rejected/ に監査用として保存されます。

段階 2: RIA++ 構築（6 段構造）

三重検証を通過したユニットを、以下 6 次元の構造として SKILL.md に整形します。

• R（原文引用）: 判断の一次ソースとなる原文抜粋
• I（自分の言葉での再構築）: Agent 側で扱いやすい抽象化
• A1（原典の事例）: 原文中に登場した具体例
• A2（未来のトリガーシーン）: 「どのような状況で呼び出すべきか」の明示
• E（実行可能ステップ）: 実行時のアクションを具体化
• B（境界と盲点）: 適用範囲と、してはならないケース

A2（トリガーシーン）と E（実行ステップ）が明示的に切り出されているため、Claude Code などから条件一致時に自動的に呼び出しやすい形式になります。

段階 3: Zettelkasten リンク

生成された Skill 群の間で、依存・対比・組合せなどの関係性を抽出し、Skill 一覧と参照グラフを持つ INDEX.md（mermaid の引用グラフ付き）と、全書共有の術語辞書 GLOSSARY.md を生成します。ツェッテルカステン（カード式知識管理）の考え方を Skill 群に適用し、Skill が単発ではなくネットワークとして参照可能になります。

段階 4: ストレステスト

各 Skill に対して、以下 3 分類のテストプロンプト（5〜10 件）を設計します。

• 応調用: 呼び出されるべき状況
• 不応調用（囮）: 呼び出されてはならない紛らわしい状況
• 境界曖昧: 判定が難しい境界ケース

これらのテスト結果は test-prompts.json と test-results.md として保存されます。特筆すべきは、test-prompts.json が姉妹プロジェクト darwin-skill 互換のフォーマットで出力される点で、cangjie の出力をそのまま darwin に接続してさらに Skill を進化させることが可能な設計になっています。テストで不合格となった Skill は段階 2 に戻して作り直す仕組みです。

段階 5: デリバリー

テストに合格した Skill 群を、読者向けの精華長文である DIGEST.md としてまとめ、~/.claude/skills/ などにコピーまたはシンボリックリンクして呼び出し可能な状態に整えます。ここまで来ると、Claude Code などのエージェントは対応するシーンで自動的に Skill を参照できるようになります。

生成物とリポジトリ構造

RIA-TV++ を書籍 1 冊に適用すると、SKILL.md の「输出结构」節に記載された以下のような成果物ツリーが生成されます（原文の抜粋・改変なし。出典: SKILL.md）。

books/<book-slug>/
├── PIPELINE_STATE.md          # 現在段階と各 Skill 進捗（断点復旧用）
├── BOOK_OVERVIEW.md           # 段階 0: 骨格・解釈・批判・応用
├── verified.md                # 段階 1.5: 三重検証を通過したユニット
├── INDEX.md                   # 段階 3: Skill 一覧と参照グラフ
├── GLOSSARY.md                # 段階 3: 全書共有の術語辞書
├── DIGEST.md                  # 段階 5: 読者向け精華長文
├── candidates/                # 段階 1: 生の候補プール（監査用）
├── rejected/                  # 段階 1.5 で落選したユニット + 理由（監査用）
├── <skill-slug>/
│   ├── SKILL.md               # R / I / A1 / A2 / E / B の 6 段構造
│   ├── test-prompts.json      # darwin-skill 互換
│   └── test-results.md        # 段階 4 の合格率と失敗分析

段階 1 の生候補と段階 1.5 の落選ユニットが candidates/ と rejected/ として残される点は、監査可能性の観点で重要です。「なぜこの Skill が採用され、あの候補は落選したのか」を後から検証できるため、社内で導入する際の透明性が担保されます。

リポジトリ本体のディレクトリ構成も、この方法論を反映した形になっています。README「仓库结构」節および実際のディレクトリを参照すると、主要な構成要素は次のとおりです。

• SKILL.md: メタ Skill 本体（本プロジェクトの完全実行仕様）
• methodology/: RIA-TV++ 各段階の方法論ドキュメント（00-overview.md から 07-stage5-deliver.md）
• extractors/: 段階 1 の 5 種類抽出器プロンプト（framework / principle / case / counter-example / glossary）
• templates/: 各段階の出力テンプレート（BOOK_OVERVIEW.md.template、DIGEST.md.template、INDEX.md.template、SKILL.md.template、test-prompts.json.template）
• README.md / README.en.md / README.ja.md: 中英日 3 言語の README
• LICENSE: MIT

各段階の方法論が個別ドキュメントとして分離されているため、パイプラインの一部だけを参考にして自組織の Skill 生成プロセスに組み込むといった使い方もしやすい構造です。

生成済み Skill パックの一部として、README「已生成的 skill packs」節では以下のような例が挙げられています。

• buffett-letters-skill: バフェット 1957-2023 株主への手紙 → 20 Skills
• mao-selected-works-skill: 毛沢東選集第 1〜5 巻 → 25 Skills
• huangdi-neijing-skill: 黄帝内経 素問 + 霊枢 → 22 Skills
• viral-copywriting-skill: 『爆款文案』 → 14 Skills
• ai-for-everyone-skill: Andrew Ng『AI for Everyone』動画課程 → 25 Skills

書籍だけでなく、長尺動画コンテンツ（例: ai-for-everyone-skill）にも同じパイプラインが適用されている点は、cangjie-skill が「テキスト化された長文コンテンツ全般」を対象とすることの実例と言えます。生成例のうち buffett-letters-skill は独立したリポジトリとして公開されており、実際にどのような成果物ツリーが出力されるかを確認できます。

類似OSSとの違い — nuwa-skill / darwin-skill との住み分け

cangjie-skill を検討する際に必ず登場するのが、同じ作者エコシステムの nuwa-skill と darwin-skill です。SKILL.md の「与 nuwa-skill / darwin-skill 的生态定位」節に基づいて 3 者を比較すると、以下のように整理できます。

3 者比較

nuwa-skill は「人を蒸留する」プロジェクトなのに対し、cangjie-skill は「書物・長文を蒸留する」プロジェクトです。SKILL.md の「边界」節には「NOT for role-playing as the author (that is nuwa-skill's job)」と明記されており、たとえば「バフェットのように話す Skill」を作るのは nuwa-skill、「バフェットの株主への手紙から投資判断の方法論を Skill として切り出す」のは cangjie-skill、という役割分担になります。

darwin-skill は Skill を新規に生成するのではなく、既に存在する Skill の性能を評価し、改善案を作り、テストで検証して、良ければ保持・悪ければ巻き戻すという改善サイクルを回すプロジェクトです。cangjie が生成した Skill を darwin に流し込んで継続的に磨いていくという連携が、test-prompts.json の互換フォーマットによって成立します。

既存 Skill の選定・導入ガイドとの違い

もう一つ、cangjie-skill を評価する際に区別しておきたいのが「既存 Skill の選定・導入」に関するリソースとの違いです。cangjie-skill はあくまで長文コンテンツから「新規 Skill を生成するためのフレームワーク」であり、既に公開されている Claude Code Skill 群から自社の用途に合うものを選定・導入するプロセスとは目的が異なります。既に用意された Skill をどう選び、どう自環境に組み込むかを整理して確認したい場合は、Claude Codeスキルおすすめ厳選｜用途別の選び方と導入手順【2026年版】を先に押さえておくと、cangjie-skill で「自作すべき Skill」と「既存 Skill で足りる領域」の切り分けがしやすくなります。

cangjie-skill が選ばれる典型シーン

以下のようなシーンでは、cangjie-skill が選択肢に入りやすくなります。

• 特定の書籍・講座・ポッドキャストから、Agent が業務中に呼び出せる方法論 Skill を作りたい
• 単一の要約ではなく、複数の Skill が相互参照可能な「Skill パック」として整備したい
• 「呼び出すべきシーン」「境界」まで含めた品質担保を Skill 生成プロセスに組み込みたい
• 将来 darwin-skill と組み合わせて Skill の継続改善サイクルを回したい

一方、以下のケースでは cangjie-skill 単体は最適解になりません。

• ある人物の口調・思考スタイルを模倣した Skill を作りたい → nuwa-skill が該当
• 既にある Skill の性能を上げたい → darwin-skill が該当
• コンテンツを人間が読むための要約が欲しいだけ → 通常の要約ツールで十分

単純要約や書評との違い（境界）

Notion AI やその他の要約ツール、あるいは書評サイトと比較したときの cangjie-skill の特徴は、「Agent 実行を前提とした構造化」にあります。要約ツールは「人間が読む圧縮テキスト」を返すのに対し、cangjie-skill は「Agent が特定シーンで呼び出せる 6 段構造の Skill 群」を返します。RIA++ 構造の A2（トリガーシーン）と E（実行ステップ）が明示されるため、生成物はそのまま Claude Code の Skill として動作させることを想定した形になっています。

品質レッドラインと運用上の留意点

SKILL.md の「质量红线」節では、以下いずれかに違反する場合は出力をブロックすると定義されています。

1. 全 Skill が三重検証を通過していること
2. 各 Skill に R / I / A1 / A2 / E / B の 6 段が完備されていること
3. 原文引用は 1 段落あたり中国語 150 字以内、英語 100 語以内であること
4. 各 Skill に test-prompts.json があり、囮テストを含むこと（かつ最低 1 件は同書の兄弟 Skill 混同シナリオ）
5. description フィールドが具体的なトリガー条件を明示していること（「X についての Skill」といった曖昧表現は不可）

これらは「魔法のように動く自動蒸留」ではなく、「品質担保のためのハードルを内包した蒸留パイプライン」であることを示しています。特に 5 番目の要件は、生成された Skill が実運用で誤呼び出しを起こしにくくするための重要な制約です。

運用上の留意点として、README や SKILL.md からいくつか押さえておくべき点があります。

• 入力にはテキスト化された長文が必要: 動画・ポッドキャストを扱う場合、まず字幕や文字起こしの取得が前提となります。cangjie-skill 自体が音声・映像を直接処理するわけではありません
• 初回は 1 冊から: 段階 1〜4 は各種検証・テストを含むため、いきなり大量のコンテンツを流し込むのではなく、まず 1 冊で品質を確認するステップが推奨されています
• 監査ログが保存される: candidates/ と rejected/ が残るため、「なぜこの Skill が採用されたか」を後追いで検証できます。社内での説明責任がある環境ではこの点が重要になります

導入・活用の判断軸（まとめ）

cangjie-skill は、書籍や長尺動画などの長文コンテンツから、Claude Code などの Agent が呼び出せる Skill 群を蒸留する OSS です。中核の RIA-TV++ パイプラインは、アドラー式読書法・便箋読書法・ツェッテルカステンといった既存の読書方法論を、三重検証と実行可能性の観点で Agent 向けに拡張したものです。

導入を検討する際の判断軸を、記事全体の内容から整理すると次のようになります。

cangjie-skill が向く場面:

• 手元の書籍・講座・ポッドキャストから、Agent が呼び出せる方法論 Skill を作りたい
• Skill パックとして相互参照可能な形式で整備したい
• 監査可能性（candidates/ / rejected/ に生候補が残る）を重視する運用がしたい
• 将来的に darwin-skill を組み合わせて Skill の継続改善サイクルを構築する見込みがある

cangjie-skill が向かない場面:

• 人の話し方・思考スタイルの模倣が主目的（この場合は nuwa-skill）
• 既存 Skill の性能改善が主目的（この場合は darwin-skill）
• 人間が読む要約テキストがあれば十分（通常の要約ツールで足りる）
• 音声・映像コンテンツのテキスト化基盤が用意できていない

メンテナンス状況の観点:

本記事執筆時点で、cangjie-skill は Stars 3,692 / Forks 529、最終 push が 2026-07-16 であり、archived / fork のいずれでもありません。ライセンスは MIT で、日本語 README も用意されています。中国語圏発のプロジェクトではあるものの、README が中英日 3 言語で整備されている点は、日本の技術チームで扱う上でハードルを下げる要素です。

エコシステムとしての nuwa-skill / darwin-skill / cangjie-skill を俯瞰した上で、自プロジェクトの目的（人を模倣したいのか、方法論を抽出したいのか、既存 Skill を磨きたいのか）を明確にすることが、最初の判断のポイントになります。まずは公式リポジトリの README.ja.md と SKILL.md で方法論の全体像を確認し、小さなコンテンツ 1 つでパイプラインの流れを追ってみるところから始めるとよいでしょう。