著者 fable-methodの使い方と他モデルでの検証方法
fable-methodはClaude Fable 5の習慣を4つのagent skillsに整理したrepoです。各ファイルの役割、3つしか導入しないinstallerの注意点、VPSでmethod有無を比較する手順を解説します。
Fable method が実際に主張していること
Fable method は、1 つのモデルの作業習慣を順序付きの手順として記述し、別のモデルでも同じ手順を実行できるようにする、小規模な agent skills の集合です。リポジトリは Sahir619/fable-method で、MIT ライセンスで公開されています。リポジトリ自身による 1 行の説明は、「Claude Fable 5 の動作を、どのモデルでも実行できる skills に凝縮し、それを検証し続ける eval も備えたもの」です。検証する価値があるのは、この文の後半です。
テキストファイルが特定のモデルの思考方法を本当に記録できているかどうかは、Anthropic の外部にいる人には確認できません。一方、そのテキストファイルを読ませたときに、より安価なモデルの動作が変わるかどうかは、1 台の VPS で半日あれば自分で確認できます。以下で測定するのはこの点です。同じタスクを method ありと method なしで 2 回実行し、tool calls とコストを数えます。
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 を一覧表示します。存在しないものを確認してください。この repo には4つのスキルがありますが、shell installer がコピーするのは3つだけです。そのため、単独で利用する場合、手作業でコピーしない限り fable-domain は取得されません。
cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/タグを固定し、得られた結果の横にタグを書き留めてください。この repo は 2026-07-06 から 2026-07-15 の間に5つのリリースを公開しました。v1.0.0 から v1.4.0 までです。v1.4.0 では、新しい routing gate が追加され、方式自体が変更されました。2026年8月時点では、v1.4.0 が最新のタグです。制御実行で読み込むルールのバージョンと、テスト実行で読み込むバージョンが異なる場合、測定結果には意味がありません。
4 つのスキルがモデルに指示する内容
中核となるファイルは skills/fable-method/SKILL.md です。2 つのゲートと 7 つの番号付き手順が含まれており、規則が具体的なので、内容を検証できます。
最初に簡易性ゲートがあります。変更対象が 1 ファイルで、作業が約 10 行以内に収まり、新しい動作を追加せず、変更箇所を正確に把握している場合は、余計な手順を挟まずに直接対応します。次に適合性ゲートがあります。依頼を、開いて確認できるソース、先に調査が必要な手法、自分の推論に振り分けます。自分の推論は、事実として示さず、確信度が低い情報として明示する必要があります。
続いてループがあります。依頼を分類し、完了条件を定義し、証拠を集め、判断し、実行し、検証し、報告します。手順 2 では、ファイルを選ぶ前にディレクトリを一覧表示して状況を把握し、記憶より一次情報を優先し、新しい情報が得られない検索が 2 回連続したら停止します。手順 4 では、編集前に INTENT: 行を書きます。この行には、コードの動作、失敗したチェックが期待する内容、仕様の記載内容を示します。この 3 つが一致しない場合は、編集してはいけません。その不一致自体が重要な発見だからです。手順 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 は、トラップ用フィクスチャとスモーク評価を含むドメインアダプターバンドルを生成します。提供されるアダプターは、マーケティング、調査、データ分析、ビジネスと運用、財務、法務とコンプライアンス、デザインと UX、DevOps の 8 種類です。医療および臨床業務向けのアダプターは、意図的に用意されていません。
別のモデルへ移植できる部分と、できない部分
リポジトリは、これを AGENTS.md で直接説明しています。冒頭には次のようにあります。「Codex、Cursor、aider、raw system prompt など、あらゆるコーディングエージェントまたはハーネス向けの移植可能なバージョンです。SKILL.md と同じ方法で使用します。このファイルをエージェントの指示に貼り付けるか、リポジトリのルートに AGENTS.md として配置してください。」約 2,600 語で、同じゲート、手順、モードを含みます。リポジトリのルートに指示ファイルを置く運用をすでに採用している場合は、AGENTS.md と HUMAN.md の規約で、そのファイルの配置場所と読み手を確認できます。
2 つの部分は、そのまま移植できます。手順の本文は、モデル固有のコードを含まない順序付きプロンプトです。そのため、指示に従えるモデルであれば実行できます。また、リポジトリが示す主張では、得られる効果はモデルの階層に反比例します。judge も、エージェントがシェルとリポジトリを利用できれば移植できます。judge が行うのはすべて git diff と、読者自身も実行できるコマンドの再実行だからです。
1 つの部分は、そのままでは移植できません。fable-loop は、ハーネスが並列のサブエージェントを起動し、それぞれを異なるモデルへ割り当てられることを前提としています。サブエージェントを利用できないエージェントでは、これらの段階を 1 つのモデルで直列に実行することになります。その場合、設計の根拠となった並列性とコスト削減が失われます。残るのは、追加の用語を加えた fable-method です。
ハーネス固有で見落としやすい点が、ほかに 2 つあります。/fable-method のトリガーは Claude Code のスラッシュコマンドです。そのため、別のハーネスでは、この方法を説明して呼び出します。また、SKILL.md の frontmatter description によって、タスクに一致した場合だけエージェントが本文を読み込めます。つまり、インストール済みの skill は実行されるまで、ほとんどコストがかかりません。代わりに AGENTS.md を system prompt に貼り付けると、1 行のタイプミス修正でもリファクタリングでも、送信するすべてのリクエストに 2,600 語が含まれます。これは実際のコスト差であり、skill のパッケージ化が存在する主な理由です。
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 の自動検出がスキップされます。この flag が 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 側では、同じ command に flag を 1 つ追加します。これにより、portable method が system prompt への追加情報として読み込まれます。
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 つの flag だけです。比較を意味のあるものにするには、これが唯一の方法です。
この設計で測定できるのは method のテキストです。skill の packaging は測定対象ではありません。これは別の問題です。packaging を測定するには --bare を外し、前述の手順で skill をインストールします。そのうえで、skill 名を prompt string に含めます。print mode では、ユーザーが呼び出した skill が展開されるためです: claude -p "/fable-method $task"。表示上の動作が同じでも、system prompt を使う方法とはコストの傾向が異なる可能性があります。
手順数とコストの集計
両方の実行で、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 点注意してください。まず、~/.claude/projects/ のセッショントランスクリプトに含まれる output_tokens を合計して、全体の値と見なさないでください。メッセージごとの使用量ブロックはストリーミング中に取得されたスナップショットであり、過少計上されるという報告があります。信頼すべき値は result の行です。次に、各手法を 1 回ずつ実行しただけでは、単なる事例にすぎません。同じタスクで各手法を 3 回または 4 回実行してから差を判断してください。同じエージェントを同じタスクで 2 回実行しただけでも、結果にはすでに差が生じるためです。長期的な支出の把握については、Claude Code の支出を追跡するツール と Claude Code がトークンを数える方法 で、キャッシュの値が生のカウントを大きく左右する理由を確認できます。
エージェントを unattended で実行している間、重要な対象へアクセスできないことを確認してください。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 判定（複数の出力を比較する場合はブラインドですが、ベースラインとして使われるものと同じフロンティアモデルに基づく）、合成フィクスチャ、研究上の正解は実行日時点のものに限られる」。さらに直接的に、「このログは手法の編集をテストするためのものであり、ベンチマークと誤解してもらうためのものではない」と説明しています。
この点は評価できます。独自に n を公開し、判定器がベースラインとして使うものと同じモデルに基づいているという問題まで明示する著者は、この分野の通常よりも正直です。これらの数字は、著者が実際に実行し、失敗を残したことを示す根拠として読んでください。自分のコードベースについて教えてくれるのは、自分で行う A/B テストです。
README は、この手法が何もしない場面についても明確に説明しており、そこが最も有用な段落です。性能の高いモデルによる通常の小規模タスクでは、向上が確認されなかったと記録しています。また、「この手法でモデルの知識を新しくすることはできない。知識集約型の調査では、単体のフロンティアモデルが勝る」と述べています。さらに価値があるのは「罠（権威情報の衝突、完了していない作業を完了したとする主張、弱い実行器、監視されない実行）であり、どの場面でも有効なわけではない」と位置付けています。高性能なモデルに対して自分が監視しながら小さな編集を行わせているなら、測定できる差はまったくないと考えてください。より安価なモデルを監視なしで実行しているなら、差が現れるのはその場面です。そのため、Opus、Sonnet、Haiku のどれを選ぶかも同じ判断の一部になります。
パッケージングがカーゴ・カルト化している箇所
指摘すべき点は4つあります。ただし、どれもリポジトリを試さない理由にはなりません。
説明の枠組みが証拠を上回っています。「How Claude Fable 5 worked」という表現は、Anthropic 以外の誰も検証できないモデル内部の仕組みに関する主張です。しかも、リポジトリ自身の中心的な一文がその主張を弱めています。「品質を決めるのはモデルではなく、構成、証拠、誠実さです」。品質が構成にあるなら、出所に関する説明は飾りです。この手順はそれ自体で成立しており、起源神話を必要としません。
4つのスキルは、内容に対して表面的な構成です。fable-loop は fable-method の大部分を、オーケストレーションで包み直して再掲しています。また、サブエージェントのないハーネスでは fable-method に戻ります。両方をインストールする前に、2つのファイルを並べて確認してください。
8つのドメインアダプターは、評価で扱われていない範囲まで広げています。ログ内に登場するのは8つのうち2つだけです。marketing はラウンド9、devops はラウンド12に登場します。finance、legal、design、data のアダプターには、それぞれ対応するラウンドがありません。自分の分野向けのアダプターが有用な可能性はあります。ただし、それは作成者の草稿であり、トラップ用フィクスチャを通過したものではありません。
さらに、インストーラーとリポジトリでは、提供される内容の認識が一致していません。インストーラーは4つのスキルのうち3つを ~/.claude/skills にコピーします。この差は小さなものです。しかし、パッケージングがレビューより速く進んだことを示す種類の差でもあります。導入範囲を一度にどこまで広げるか決める際には、この点を覚えておいてください。
他を何も残さない場合でも残すべきもの
ブランド要素を取り除いても、どのエージェントを実行するかに関係なく、4 つのルールは単独で機能します。
- 承認の引用。取り消せない操作や外部に影響する操作には、ユーザー自身の言葉を
AUTH:行として明記した承認が必要です。引用を確認できないエージェントは操作を実行しません。 - 双子の確認。欠陥を修正した後、プロジェクト全体を検索して同じ誤った構造がないか確認し、件数を報告します。件数が 0 の場合も報告します。
- 観測による検証。壊れたビルドの上で対象を絞った確認だけが成功していても、検証は失敗です。合格とはみなしません。
- 結果を優先した報告。実行しなかったことや未検証のことは、黙って省略せず、注意事項として明記します。
この 4 つは導入に費用がかからず、準拠状況を grep で確認できます。まずここから始め、上記のハーネスで測定してください。その後、リポジトリの残りの部分にコンテキスト予算を割く価値があるかを判断します。作業方法ではなく、プロジェクトの常設コンテキストをエージェントに与えたい場合は、エージェントが編集前に読む 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 条件の比較を自分で実行してください。