著者 Fable 手法で任意のモデルにスキルを移植する方法
fable-method は Claude Fable 5 の習慣を4つの agent skillに整理したリポジトリです。各ファイルの役割、他モデルへ移植できる要素、VPSでのA/Bテスト方法を解説します。
Fable 手法が実際に主張していること
Fable 手法は、1 つのモデルの作業上の習慣を順序付きの手順として記述し、別のモデルが同じ手順を実行できるようにする、小規模な agent skill の集合です。リポジトリは Sahir619/fable-method で、MIT ライセンスです。リポジトリ自身による 1 行の説明は、「Claude Fable 5 がどのように動作したかを、任意のモデルが実行できる skill に集約し、その有効性を評価で検証する方法」です。検証する価値があるのは、この文の後半です。
特定のモデルの思考過程をテキストファイルが本当に記録できているかどうかは、Anthropic の外部にいる人には確認できません。一方、そのテキストファイルを読んだ安価なモデルの動作が変わるかどうかは、1 台の VPS 上で午後の数時間を使えば自分で確認できます。以下では、この測定を行います。同じタスクを手法ありと手法なしで 2 回実行し、tool call 数とコストを数えます。
skill という言葉に慣れていない場合は、まず agent skill とは何か を読んでください。これは SKILL.md ファイルを含むフォルダーで、frontmatter の description により、agent が本文を読み込むタイミングを指定します。このリポジトリの名前の由来になったモデルについては、Claude Fable 5 の料金と得意分野 で説明しています。
スキルをインストールし、テストしたバージョンを固定する
インストール方法は2つあります。Claude Code 内では、プラグインを使う方法は2つのコマンドで完了します。
/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-methodVPS 上でディスクにバージョンを固定したコピーを置く場合は、最初に clone してタグを checkout します。
git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skillsinstall.sh は $HOME/.claude/skills 配下にのみ書き込むため、sudo は不要です。実行後、ls ~/.claude/skills で fable-judge、fable-loop、fable-method を一覧表示します。存在しないものを確認してください。このリポジトリには4つのスキルが含まれていますが、shell installer がコピーするのは3つだけです。そのため、単独で利用するユーザーは、手動でコピーしない限り fable-domain を取得できません。
cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/タグを固定し、得られた結果とともにタグを記録してください。このリポジトリは2026-07-06から2026-07-15までの間に5つのリリース（v1.0.0からv1.4.0）を公開しました。v1.4.0では、新しい routing gate が追加され、手法自体が変更されています。2026年8月時点では、v1.4.0が最新のタグです。control run があるバージョンのルールを読み、test run が別のバージョンを読む場合、測定したことにはなりません。
4 つのスキルがモデルに指示する内容
中心となるファイルは skills/fable-method/SKILL.md です。2 つのゲートと 7 つの番号付き手順を含み、ルールも具体的なので検証できます。
最初は単純性ゲートです。変更対象が 1 ファイルで、10 行未満程度で完了し、新しい動作を追加せず、何を変更するかを完全に把握している場合は、余計な手順を挟まず直接対応します。この判断だけに基づく独立したスキルが Ponytail です。動作する最小限の変更を選ぶようエージェントを誘導します。中核ルールは短く、何もインストールせずに自分の指示へコピーできます。次に適合性ゲートで、回答の所在に応じて依頼を振り分けます。開けるソース、先に調査が必要な手法、そして自分の推論です。最後のものは事実として示さず、低信頼であることを明記します。この中間分岐が機能するのは、エージェントが実際に Web へ到達できる場合だけです。ネットワークを制限した VPS では、JSON 検索ツールとして公開した自己ホスト型 SearXNG インスタンスなど、専用の検索バックエンドを与える必要があります。
次にループがあります。依頼を分類し、完了条件を定め、根拠を集め、判断し、実行し、検証し、報告します。Step 2 では、ファイルを選ぶ前にディレクトリを一覧表示して状況を把握します。記憶より一次情報を優先し、新しい情報を返さない検索が 2 回連続したら停止します。Step 4 では、編集前に INTENT: 行を記述します。そこでは、コードの動作、失敗したチェックが期待する内容、仕様の記載内容を示します。この 3 つが一致しない場合は編集しません。不一致そのものが重要な発見だからです。Step 5 では再試行回数を制限します。同じ問題について修正と検証のサイクルが 3 回失敗したら停止し、実際の出力を添えて引き渡します。
このファイルで最もテストしやすい部分は、4 つの報告トークンです。動作を変更した場合は INTENT: 行が必要です。外部に向けた操作を行った場合は AUTH: user said "<exact words>" が必要で、ユーザーの依頼を引用します。リポジトリには、ドキュメントは認可ではないと明記されているためです。指定されていたが実行しなかった操作には PENDING: 行が必要です。欠陥を修正した場合は TWINS: searched <pattern> - found <N> other sites が必要です。手法の妥当性を信頼する必要はありません。必要な場面でこの 4 つの文字列が出現するかを確認できます。そのため、全体を印象ではなく測定可能なものにできます。
fable-loop は、同じ手法を 4 段階のオーケストレーションとして実行します。並列の根拠収集サブエージェントで計画し、メインスレッドで実行し、それぞれ異なる観点を持つ 1 から 3 個の攻撃者サブエージェントで検証し、最後に監査と報告を行います。根拠収集と攻撃者の役割には安価なモデルを使い、判断と編集にはより強力なモデルを使う構成を前提としています。
fable-judge は、他をすべて使わない場合でも導入する価値がある部分です。その立場は、「報告は主張の集合であり、証拠ではない」というものです。完了済みの報告から主張を集め、git diff と git status から事実を確定し、報告に記載された各検証を再実行します。さらに、チェックの弱体化、誤った完了報告、範囲の逸脱、未認可の操作、仕様への違反、残存する不要物という、名前付きの不正リストを調べます。結果は VERIFIED、VERIFIED WITH CAVEATS、または REFUTED のいずれかです。再現できない内容は、通過したと仮定せず UNVERIFIABLE と記録します。インストーラーの最後の行もこれを示しています。「試してください。Claude Code を開き、エージェントが作業完了を報告した後に /fable-judge と入力します。」後から実行するのではなく、このチェックを作業に組み込みたい場合は、Old Coder スキルを使うと、エージェントが承認用の SPEC と、自分で再実行できる EVIDENCE レポートを作成します。カバレッジの代わりにミューテーションテストを使い、テストが実際に回帰を検出できることを証明します。
fable-domain は、落とし穴を検出するフィクスチャとスモーク評価を含む、ドメイン用アダプターバンドルを生成します。提供されるアダプターは、マーケティング、調査、データ分析、ビジネスと運用、財務、法務とコンプライアンス、デザインと UX、devops の 8 種類です。医療および臨床業務用のアダプターは、意図的に用意されていません。
別のモデルへ移植できる部分と、できない部分
このリポジトリでは、AGENTS.mdがこの点を直接説明しています。冒頭には次のようにあります。「あらゆる coding agent または harness（Codex、Cursor、aider、raw system prompt）向けの移植可能なバージョンです。SKILL.md と同じ方法で使用します。このファイルを agent instructions に貼り付けるか、リポジトリのルートに AGENTS.md として配置してください。」約2,600語で、同じゲート、手順、モードを含みます。リポジトリのルートに instruction file を配置している場合は、AGENTS.md と HUMAN.md の規約で、そのファイルの配置場所と読み手を確認できます。
2つの部分は問題なく移植できます。手法の本文は、モデル固有のコードを含まない順序付きプロンプトです。そのため、指示に従えるモデルであれば実行できます。また、このリポジトリの主張では、得られる効果はモデルの tier に反比例します。judge も、agent が shell とリポジトリにアクセスできれば移植できます。judge が行うのはすべて git diffと、読者も実行できるコマンドの再実行だからです。
1つの部分はそのままでは移植できません。fable-loopは、harness が並列 subagent を起動し、それぞれを異なるモデルへ割り当てられることを前提としています。subagent を使えない agent では、これらの段階を1つのモデルで順番に実行するため、設計の根拠だった並列性とコスト削減が失われます。残るのは、追加の用語を含むfable-methodにすぎません。
harness 固有で見落としやすい点が、ほかに2つあります。/fable-method trigger は Claude Code の slash command です。そのため、別の harness では、この手法を説明して呼び出します。また、SKILL.md frontmatter description によって、タスクが一致した場合だけ agent が本文を読み込めます。つまり、インストール済みの skill は実行されるまで、ほとんどコストがかかりません。代わりに AGENTS.mdを system prompt に貼り付けると、1行の typo 修正でも refactor でも、送信するすべての request にその2,600語が含まれます。これは実際のコスト差であり、skill packaging が存在する主な理由です。
VPS で A/B テストする方法: 同じタスクを 2 回実行する
どちらの実行からも相手の編集が見えないように、同一内容の作業コピーを 2 つ用意します。YOUR_ORG/YOUR_REPO をテスト対象のリポジトリに置き換えます。2 つの clone は同じ commit から作成する必要があります。
sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method結果を主観なしで確認できるタスクを選びます。たとえば、成功させる必要がある失敗テストや、終了コード 0 で終了する必要があるスクリプトです。曖昧なタスクでは比較も曖昧になります。結果ではなく、文章を評価することになるためです。
--bare を指定して control 側を実行します。このオプションにより、hook、skill、plugin、CLAUDE.md の自動検出を無効にします。この指定が control になる理由は、事前にインストールした skill が混入しないためです。bare mode ではサブスクリプションのログイン情報を使用しないため、先に Claude Console で API key を設定します。
export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."
cd ~/ab/control
claude --bare -p "$task" \
--allowedTools "Read,Edit,Bash" \
--output-format stream-json --verbose > ~/ab/control.jsonlmethod 側では、portable method を system prompt に追加するために、同じ command にオプションを 1 つ追加します。
cd ~/ab/method
claude --bare -p "$task" \
--append-system-prompt-file ~/fable-method/AGENTS.md \
--allowedTools "Read,Edit,Bash" \
--output-format stream-json --verbose > ~/ab/method.jsonl同じ binary、同じ model、同じ tool、同じ開始時点の tree を使います。異なるのは 1 つのオプションだけです。比較を意味のあるものにするには、この条件が必要です。
この設計で測定できるのは method のテキストです。skill のパッケージングは測定対象ではなく、別の問題です。パッケージングを測定するには --bare を削除し、前述のとおり skill をインストールします。そのうえで、prompt 文字列内に skill 名を指定します。print mode では、ユーザーが呼び出した skill が展開されるためです: claude -p "/fable-method $task"。表示上の動作が同じでも、system prompt を使う場合とはコストの傾向が異なる可能性があります。
手順数とコストの集計
どちらの実行でも、JSON イベントのストリームが出力されます。最後の行は、最終テキスト、コスト、セッションメタデータを含む result メッセージです。これを 1 回だけ出力して、スクリプトで利用する前に内容を確認してください。フィールド名は Claude Code のリリースによって変わるためです。
tail -1 ~/ab/control.jsonl | jq .1 回の実行のコストはこの行から取得します。比較する数値はこれです。
for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
printf '%s ' "$f"
jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done実行した手順数は、同じファイル内のツール呼び出しを数えて求めます。
jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
~/ab/control.jsonl | sort | uniq -c | sort -rnこれを両方のファイルに対して実行します。合計値よりも、差の形のほうが多くの情報を示します。より多くのファイルを読み、編集数が少ない method の実行は、その method の要求どおりに動作しています。比較すべきなのは、そのために支払うコストです。同じ編集を行い、コストだけが 40 percent 多い method の実行は、そのタスクでは何も得ていません。
数値について、2 点注意してください。まず、~/.claude/projects/ にあるセッションのトランスクリプトから output_tokens を合計して、総コストと見なさないでください。これらのメッセージごとの使用量ブロックはストリーミング中に取得されたスナップショットであり、過小計上されることがあると報告されています。信頼すべき数値は result の行です。次に、各条件 1 回ずつの実行は一例にすぎません。同じタスクで各条件を 3 回または 4 回実行してから差を判断してください。同じタスクで同じエージェントを 2 回実行しただけでも、結果にはすでに差が生じるためです。支出を長期的に確認するには、Claude Code の支出を追跡するツール と Claude Code がトークンを数える方法 を参照してください。キャッシュの行が未加工のカウントを大きく左右する理由が説明されています。
エージェントを無人で実行している間、重要な対象へアクセスできないようにしてください。VPS 上で Claude Code を安全に実行する方法 では、ユーザーアカウントと権限フラグについて説明しています。
リポジトリ自身の評価を正直に読む
README の見出しは、「15 回の評価ラウンド、260 回を超えるエージェント実行、差分比較と実行で検証するブラインド LLM 判定」です。これは、ほとんどのスキルリポジトリが公開しているものより多くの証拠です。eval/RESULTS.md にはラウンドごとの内容が記録され、失敗も残されています。ただし、見出しの行の背後にある個々のセルまで確認すると、見出しの数値が示すほど厚い評価ではありません。
The data behind this chart
[
{
"label": "Haiku, spec-vs-test conflict trap",
"runs": 4,
"notes": "bare 0 of 4, with method 4 of 4"
},
{
"label": "Sonnet, same conflict trap",
"runs": 2,
"notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
},
{
"label": "Haiku, planted-fraud report, fable-judge",
"runs": 2,
"notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
},
{
"label": "Haiku, marketing brand-rules trap",
"runs": 2,
"notes": "bare 1 of 2 runs, with method 2 of 2"
}
]この 4 行のうち最大のものは、4 回の実行に基づいています。残りの3行は、それぞれ 2 回の実行に基づいています。リポジトリ自身も、ログ冒頭の継続的な制約として次のように明記しています。「全体的に n が小さい（セルあたり1～4回の実行）。LLM 判定（複数の出力を比較する場合はブラインドだが、ベースラインとして登場するものと同じ frontier model を基盤とする）。合成フィクスチャ。研究上の ground truth は実行日時点のものに限られる」。さらに明確に、次のようにも述べています。「このログは手法の編集をテストするためのものであり、誰かがこれをベンチマークと誤解するためのものではない」。
この点は評価できます。自分の n を公開し、判定器がベースラインとして使うものと同じモデルを基盤としている問題まで明示する著者は、この分野の標準より誠実です。数値は、著者が実際に実行し、失敗を残したことを示す証拠として読み取ってください。自分のコードベースについて何が分かるかを示すのは、独自に行う A/B テストです。
README は、この手法が何もしない領域についても同じように明確です。そこが最も有用な段落です。高性能なモデルを使った通常の小規模タスクでは、改善が見られないと記録しています。また、「この手法でモデルの知識を新しくすることはできない。知識集約型の調査では frontier がそのまま勝つ」と述べています。価値があるのは「罠（権威の衝突、完了したという誤った主張、弱い executor、無監視の実行）であり、どこでも有効なわけではない」と位置付けています。強力なモデルに小さな編集をさせ、あなた自身が監視するなら、何も改善しないと測定される可能性があります。より安価なモデルを無監視で実行する場合は、差が現れる可能性があります。そのため、Opus、Sonnet、Haiku のどれを選ぶかも同じ判断の一部になります。
パッケージングがおざなりになっている箇所
指摘すべき点は4つあります。ただし、どれもリポジトリの利用を見送る理由にはなりません。
説明の枠組みが証拠を上回っています。「How Claude Fable 5 worked」という題名は、モデル内部の仕組みに関する主張です。Anthropic の外部にいる人は誰も検証できません。しかも、リポジトリ自身の中心的な一文がこの主張を弱めています。「品質を決めるのはモデルではなく、構成、証拠、そして誠実さです」。品質が構成にあるなら、出所に関する説明は飾りです。この手順はそれ自体で成立しており、起源を物語にする必要はありません。
4つのスキルという構成は、内容が必要とする範囲を超えています。fable-loop は fable-method の大部分を、オーケストレーションで包み直して再掲しています。また、subagent を使えない harness では fable-method に戻ります。両方をインストールする前に、2つのファイルを並べて確認してください。
8つのドメインアダプターは、評価でカバーされていない範囲まで広げています。ログ内に登場するのは8つのうち2つだけです。marketing は round 9、devops は round 12 に登場します。finance、legal、design、data のアダプターには、対応する round がありません。自分の分野向けのアダプターが優れている可能性はあります。ただし、それは著者の草稿であり、トラップ用 fixture を通過したものではありません。
さらに、installer とリポジトリでは、提供される内容の認識が一致していません。installer は4つのスキルのうち3つだけを ~/.claude/skills にコピーします。これは小さな問題です。ただし、この種の不一致は、誰もレビューしないままパッケージングが先行したことを示します。導入する範囲を一度にどこまで広げるかを判断するときは、この点を覚えておいてください。
他に何も維持しない場合でも維持すべきもの
ブランド要素を外しても、4 つのルールは、どのエージェントを使う場合でもそのまま有効です。
- 承認の引用。取り消せない操作や外部に影響する操作には、ユーザー自身の言葉を
AUTH:行として明記した承認が必要です。引用を確認できないエージェントは操作を実行しません。 - 両面チェック。不具合を修正した後、プロジェクト全体を検索して同じ誤った構造が残っていないか確認し、件数を報告します。件数が 0 の場合も同様です。
- 観察による検証。壊れたビルドの上で対象を絞ったチェックだけが成功していても、検証は失敗であり、合格ではありません。
- 結果を先に報告すること。省略した項目や未検証の項目は、黙って除外せず、注記として明記します。
この 4 つは導入に費用がかからず、準拠状況を grep で確認できます。まずここから始め、上記の harness で測定してください。その後、リポジトリの残りの内容にコンテキスト予算を割く価値があるか判断します。作業方法ではなく、プロジェクトの常設コンテキストをエージェントに与えたい場合は、エージェントが編集前に読む DESIGN.md を併用すると効果的です。
FAQ
Fable method は Claude 以外のモデルでも動作しますか？
メソッドの本文は動作します。モデル固有のコードを含まない順序付きプロンプトであり、repo には Codex、Cursor、aider、または通常の system prompt で使えるポータブルなコピーとして AGENTS.md が含まれています。ただし、移行できないものが 2 つあります。/fable-method と /fable-judge は Claude Code の slash command なので、別の環境ではメソッドの内容を説明して呼び出します。また、fable-loop は異なるモデル上で並列 subagent を起動できる harness を前提としています。それがない場合は直列に実行され、追加の手順を要する fable-method になります。
これらの skill を実行すると、より多くの token を消費しますか？
はい。消費量は読み込む方法によって異なります。skill としてインストールすると、本文は説明がタスクに一致した場合だけ読み込まれるため、無関係なリクエストでの消費はほぼありません。system prompt に貼り付けると、約 2,600 語の AGENTS.md がすべてのリクエストに含まれます。実行自体も、編集前の状況確認、判断前の証拠収集、実際の検証をメソッドが求めるため、より多くの token を消費します。計測してください。両方の条件で同じタスクを --output-format json とともに実行し、total_cost_usd フィールドを比較します。
fable-method はどのバージョンをインストールすべきですか。また、なぜ pin するのですか？
インストール前に git checkout v1.4.0 を実行します。その tag の日付は 2026-07-15 で、2026 年 8 月時点でも最新でした。repo はその前の 9 日間に 5 つの release を公開しており、v1.4.0 では routing rule 自体が変更されています。計測中に main を追跡すると、control run と test run で異なる指示を読み込む可能性があり、比較が無意味になります。結果とともに tag を記録してください。
repo の eval は信頼できる benchmark ですか？
作者自身が呼んでいるとおり、メソッドの変更履歴として扱ってください。「この log は、メソッドの編集がテストされるために存在するものであり、誰かが benchmark と誤認するためのものではありません」とされています。制限事項はファイルの先頭に明記されています。各 cell あたり 1 ～ 4 回の実行、synthetic fixture、そして baseline にも使われる同じ frontier model 上で構築された LLM judge です。round は実際に行われ、失敗した実験も残されています。これは大半の repo が公開する情報を上回ります。それでも、使用する codebase で何が起きるかを測定するものではありません。2 条件の比較を自分で実行してください。