著者 Fable methodで任意のモデルに手順を移す方法
fable-methodはClaude Fable 5の作業習慣をagent skill化したリポジトリです。各ファイルの役割、他モデルへ移せる要素、VPSでのA/Bテスト方法を、v1.0.0からv1.4.0の差分とともに確認します。
Fable method が実際に主張していること
Fable method は、1 つのモデルの作業習慣を順序付きの手順として記録し、別のモデルが同じ手順を実行できるようにする、小規模な agent skill の集合です。リポジトリは Sahir619/fable-method で、ライセンスは MIT です。リポジトリ自身による 1 行の説明は、「Claude Fable 5 がどのように動作したかを、任意のモデルが実行できる skill に凝縮し、その有効性を検証する eval を備えたもの」です。検証する価値があるのは、この文の後半です。
特定のモデルがどのように推論したかをテキストファイルが本当に記録できているかどうかは、Anthropic の外部にいる人には確認できません。一方、そのテキストファイルを読んだ安価なモデルの動作が変わるかどうかは、1 台の VPS 上で午後の時間があれば自分で確認できます。以下で行う測定の目的はそこにあります。同じタスクを 2 回、method を使う場合と使わない場合で実行し、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つのスキルがありますが、シェルインストーラーがコピーするのは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では、新しいルーティングゲートが追加され、方式自体が変更されています。2026年8月時点で、v1.4.0が最新のタグです。制御実行で読み込んだルールのバージョンとテスト実行で読み込んだバージョンが異なる場合、何も測定できていません。
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 と入力します。」
fable-domain は、落とし穴を検出するフィクスチャとスモーク評価を含む、ドメイン用アダプターバンドルを生成します。8 つのアダプターが提供されています。マーケティング、リサーチ、データ分析、ビジネスと運用、財務、法務とコンプライアンス、デザインと UX、DevOps です。医療および臨床業務については、意図的にアダプターが用意されていません。
どの部分を別のモデルへ移植でき、どの部分を移植できないか
このリポジトリでは、AGENTS.md がこの点を直接説明しています。冒頭には次のように書かれています。「あらゆるコーディングエージェントまたはハーネス（Codex、Cursor、aider、素の system prompt）向けの移植可能なバージョンです。SKILL.md と同じ方法で使用します。このファイルをエージェントの指示に貼り付けるか、AGENTS.md としてリポジトリのルートに配置してください。」約 2,600 語で、同じゲート、手順、モードを含みます。リポジトリのルートに指示ファイルを置く運用をすでに採用している場合は、AGENTS.md と HUMAN.md の規約で、そのファイルの配置場所と読み手が定義されています。
2 つの部分はそのまま移植できます。手順の本文は、モデル固有のコードを含まない順序付きプロンプトです。そのため、指示に従えるモデルであれば実行できます。また、このリポジトリの主張では、効果はモデルのランクに反比例します。判定部分も、エージェントが shell とリポジトリを利用できれば移植できます。実行する内容はすべて git diff と、読者自身も実行できるコマンドの再実行だからです。
1 つの部分は、そのままでは移植できません。fable-loop は、ハーネスが並列のサブエージェントを起動し、それぞれを異なるモデルへ割り当てられることを前提としています。サブエージェントを利用できないエージェントでは、これらの段階を 1 つのモデルで順番に実行します。その結果、設計の根拠だった並列処理とコスト削減が失われます。残るのは、追加の用語を伴う fable-method です。
ハーネス固有で、見落としやすい点が 2 つあります。/fable-method トリガーは Claude Code のスラッシュコマンドです。そのため、別のハーネスでは、この方法を説明して呼び出します。また、SKILL.md の frontmatter description により、タスクに一致した場合だけエージェントが本文を読み込めます。つまり、インストール済みの skill は実行されるまで、ほとんどコストがかかりません。代わりに AGENTS.md を system prompt に貼り付けると、1 行の typo 修正でも refactor でも、送信するすべてのリクエストに 2,600 語が含まれます。これは実際のコスト差であり、skill のパッケージ化が存在する主な理由です。
VPS で A/B テストする方法: 同じタスクを 2 回実行する
どちらの実行も相手側の編集を参照できないように、同一内容の作業コピーを 2 つ用意します。YOUR_ORG/YOUR_REPO はテスト対象のリポジトリに置き換えてください。2 つのクローンは同じコミットから作成する必要があります。
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 を指定して対照条件を実行します。この指定により、フック、スキル、プラグイン、CLAUDE.md の自動検出がスキップされます。このフラグが対照条件を成立させます。先にインストールしたスキルが入り込むことがないためです。Bare モードではサブスクリプションのログイン情報を使用しません。そのため、先に 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.jsonl方法条件では、同じコマンドにフラグを 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同じバイナリ、同じモデル、同じツール、同じ開始時点のツリーを使用します。異なるのは 1 つのフラグだけです。これが、比較を意味のあるものにする唯一の方法です。
この設計で測定できるのは方法のテキストです。スキルのパッケージ化は測定対象ではなく、別の検証課題です。パッケージ化を測定するには、--bare を外し、前述の手順でスキルをインストールします。そして、スキル名をプロンプト文字列に入れます。ユーザーが呼び出すスキルは print モードで展開されるためです: claude -p "/fable-method $task"。表示上の動作が同じでも、システムプロンプトを使う条件とはコストの傾向が異なると考えてください。
手順数とコストの集計
どちらの実行でも、JSON イベントのストリームが書き込まれます。最後の行は、最終テキスト、コスト、セッションメタデータを含む result メッセージです。これを 1 回だけ表示して、周辺の処理をスクリプト化する前に内容を確認してください。フィールド名は Claude Code のリリースによって変わります。
tail -1 ~/ab/control.jsonl | jq .実行ごとのコストはこの行から取得します。比較する数値はこれです。
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これを両方のファイルに対して実行します。合計値よりも、差の形状から多くのことが分かります。手法を使った実行で、より多くのファイルを読み、編集が少なかった場合、その手法が求める動作をしているということです。これが選択したトレードオフです。同じ編集量でコストが 40% 多い場合、そのタスクでは何も得られていません。
数値について、2 点注意してください。1 点目は、~/.claude/projects/ 配下のセッション記録から output_tokens を合計して、総コストとみなさないことです。これらのメッセージごとの使用量ブロックはストリーミング中に取得されたスナップショットであり、過小集計されるという報告があります。信頼すべき数値は result 行です。2 点目は、各方式を 1 回だけ実行した結果は一例にすぎないことです。差を信頼する前に、同じタスクで各方式を 3 回または 4 回実行してください。同じタスクで同じエージェントを 2 回実行しただけでも、結果には差が生じます。支出を長期的に確認するには、Claude Code の支出を追跡するツール と Claude Code がトークンを数える方法 を参照してください。キャッシュ関連の行が、単純な集計値を大きく左右する理由が分かります。
無人で実行している間、エージェントが重要な対象へアクセスできないようにしてください。VPS 上で Claude Code を安全に実行する方法 では、ユーザーアカウントと権限フラグについて説明しています。
リポジトリ独自の評価を正直に読む
README の見出しには、「15 回の評価ラウンド、260 回を超えるエージェント実行、差分比較と実行によって検証するブラインド LLM 判定」とあります。これは、ほとんどの skill リポジトリが公開する根拠を大きく上回ります。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 を基盤にしています）。合成 fixture。研究上の ground truth は実行日時点のものに限られます」。さらに明確に、「このログは手法の編集をテストするためのものであり、ベンチマークと誤解してもらうためのものではありません」と説明しています。
この点は評価できます。独自の n を公開し、判定に使うモデルとベースラインが同じであるという問題まで明示する作者は、この分野の標準より誠実です。数値は、作者が実際に実行し、失敗を残したことの根拠として読んでください。自分のコードベースについて判断するには、自分で A/B テストを行う必要があります。
README は、この手法が効果を発揮しない範囲についても明確に述べています。ここが最も有用な段落です。十分な能力を持つモデルで通常の小さなタスクを実行しても、改善は記録されていません。また、「この手法でモデルの知識を最新にすることはできない。知識集約型の調査では、bare frontier が勝る」と説明しています。さらに、価値があるのは「罠（権威間の矛盾、完了していないのに完了したという主張、性能の低い executor、監視されていない実行）であり、どの場面でも有効なわけではない」と位置付けています。強力なモデルで小さな編集を行い、あなた自身が監視しているなら、改善はまったく測定できないと考えてください。より安価なモデルを監視なしで実行する場合は、そこでは差が現れるはずです。そのため、Opus、Sonnet、Haiku のどれを選ぶか も同じ判断の一部になります。
パッケージングが形だけになっている箇所
指摘すべき点は4つあります。ただし、どれもリポジトリを試さない理由にはなりません。
説明が証拠を上回っています。「Claude Fable 5 がどのように動作したか」という表現は、Anthropic の外部にいる人には検証できないモデル内部についての主張です。しかも、リポジトリ自身の中心的な一文がこの主張を弱めています。「品質を決めるのはモデルではなく、構成、証拠、そして誠実さです」。品質が構成にあるなら、出所に関する説明は飾りです。手順はそれ自体で成立しており、由来を示す物語は必要ありません。
4つのスキルという構成は、内容が必要とする範囲を超えています。fable-loop は、オーケストレーションを加えた形で fable-method の大部分を繰り返しています。また、サブエージェントを使えないハーネスでは fable-method に戻ります。両方をインストールする前に、2つのファイルを並べて確認してください。
8つのドメインアダプターは、評価で扱われていない範囲まで広げています。ログ内に登場するのは8つのうち2つだけです。round 9 に marketing、round 12 に devops が登場します。finance、legal、design、data のアダプターには、それぞれ対応する round がありません。自分の分野向けのアダプターが良い可能性はあります。ただし、それは作者の草稿であり、トラップ用フィクスチャを通過したものではありません。
さらに、インストーラーは何を提供するかについてリポジトリと一致しておらず、4つのスキルのうち3つだけを ~/.claude/skills にコピーします。この問題自体は小さいものです。しかし、これはパッケージングがレビューより速く進んだことを示す種類の差異です。一度にどの程度採用するかを決める際には、この点を覚えておく価値があります。
残すものが他にない場合でも残すべきもの
ブランド要素を取り除いても、実行するエージェントに関係なく、4 つのルールは単独で機能します。
- 承認の引用。取り消せない操作や外部に影響する操作には、ユーザー自身の言葉を
AUTH:行として明記したものが必要です。引用を見つけられないエージェントは操作を実行しません。 - 双方向の確認。欠陥を修正した後、プロジェクト全体を検索して同じ誤った構造がないか確認し、件数を報告します。件数が 0 の場合も含みます。
- 観測による検証。壊れたビルドの上に対象を絞ったチェックが成功していても、検証は失敗です。合格とはみなしません。
- 結果を優先した報告。スキップした項目や未検証の項目は、黙って省略せず、注意事項として明記します。
この 4 つはコストをかけずに導入でき、準拠しているかを grep で確認できます。まずここから始め、上記の harness で測定してください。そのうえで、リポジトリの残りの要素にコンテキスト予算の一部を割く価値があるか判断します。作業方法ではなく、プロジェクトの常設コンテキストをエージェントに与える場合は、エージェントが編集前に読む DESIGN.md を組み合わせるとよいでしょう。
FAQ
Fable method は Claude 以外のモデルでも機能しますか？
method の本文は機能します。モデル固有のコードを含まない順序付きプロンプトであり、repo には Codex、Cursor、aider、または通常の system prompt で使える移植用コピーとして AGENTS.md が含まれています。移植できないものが 2 つあります。/fable-method と /fable-judge は Claude Code の slash command なので、別の環境では method の内容を説明して呼び出します。また、fable-loop は異なるモデル上で並列の subagent を起動できる harness を前提としています。これがない場合は直列で実行され、追加の手順を伴う fable-method になります。
これらの skill を実行すると、token の消費量は増えますか？
はい。増加量は読み込む方法によって異なります。skill としてインストールした場合、本文は説明がタスクに一致したときだけ読み込まれるため、無関係なリクエストでの消費量はほとんど増えません。system prompt に貼り付けた場合は、約 2,600 語の AGENTS.md がすべてのリクエストに付加されます。実行自体の消費量も増えます。method は編集前の状況把握、判断前の根拠収集、実際の検証を求めるためです。実際に測定してください。両方の条件で同じタスクを --output-format json とともに実行し、total_cost_usd フィールドを比較します。
どのバージョンの fable-method をインストールすべきですか。また、なぜ固定するのですか？
インストール前に git checkout v1.4.0 を実行してください。その tag の日付は 2026-07-15 で、2026 年 8 月時点でも最新でした。repo はその前の 9 日間に 5 回の release を公開しており、v1.4.0 では routing rules 自体が変更されています。測定中に main を追跡すると、control run と test run で異なる指示を読み込む可能性があり、比較が無意味になります。結果と一緒に tag を記録してください。
repo の eval は信頼できる benchmark ですか？
作者自身が述べているとおり、method の変更履歴として扱ってください。作者は「この log は method の編集内容をテストするためのものであり、benchmark と誤解してもらうためのものではない」と説明しています。制限事項はファイルの先頭に記載されています。各 cell の実行回数は 1 から 4 回、fixture は synthetic で、LLM judge には baseline としても使われる同じ frontier model が使用されています。各 round は実際に行われており、失敗した実験も残されています。これは多くの repo が公開している情報を上回ります。ただし、ここでの結果は自分の codebase で何が起きるかを測定するものではありません。そのため、2 条件の比較を自分で実行してください。