fable-method レビュー: 弱いモデルを罠で壊さないための4スキルと、失敗を残す eval

このリポジトリが埋めようとしている穴は、指示文の抽象度にある

多くのエージェント向け指示ファイルは「慎重に検証せよ」といった価値観を並べる。README はこのやり方を名指しで批判し、代わりに「何を、どの順番で、どの閾値で行うか」を書くと宣言している。狙いは、中位モデルが文字通りに追従できる粒度まで手順を下げることだ。対象読者は、コーディングエージェントを業務に組み込み始めたが、出力の信頼性がモデルの気分に左右されると感じている開発者になる。リポジトリの説明文は「The Fable Workflow: how Claude Fable 5 worked, distilled into skills any model can run, with the eval that keeps it honest」と、方法の抽出と検証を一組で提示している。抽象的な原則ではなく、順序と閾値と逸脱時の逃げ道を書く、というのがこのプロジェクトの立ち位置である。

ask から report までの7ステップと、そこで使われる閾値

README が示すループは classify、define done、evidence、decide、act、verify、report の7段階で、先頭に trivial 判定が付く。1ファイル・10行未満・検索不要なら、そのまま実行して2文で報告する。classify では問い合わせかタスクか計画先行かを分類し、define done では形状ごとに名前付きの検証を決める。evidence は並列に一次情報源を当たり、変更前に意図を確認する。decide では推奨を一つに絞り、act では最小の編集をチェックリスト付きで行う。verify は観測で確かめ、report は結果を先に、留保を正直に書く。閾値も明示されている。検証サイクルが3回失敗したら停止して返却、検索が2回空振りしたら打ち切る、検証を名付けられないなら質問を一つだけ返す。SKILL.md は約110行とされ、無駄な文がないことを売りにしている。

fit gate と twin check: 答えがどこにあるかを先に決める

v1.4.0 のリリースノートには fit gate、twin check、artifact gate、maker with red-lines が並ぶ。fit gate はフローチャート上で trivial 判定の直後に置かれ、「答えはどこに存在するか」を問う。到達可能な情報源があるなら形状判定へ進み、未知だが調査可能なら先に調査し、自分の推論しか根拠がないなら「Say so, no costume」と明記して低信頼を申告する。専門的で反復する作業なら fable-domain でスキル化する、という分岐もある。twin check と artifact gate の詳細は README の抜粋からは読み取れない。ここは推測で埋めるべき箇所ではない。確実に言えるのは、このゲート群が「調べずに断言する」経路を明示的に塞いでいるという点だ。

eval は勝ちだけを載せず、null も併記する

15ラウンド、260以上のエージェント実行。判定は差分と実行で検証するブラインド LLM ジャッジで、レポートを読んで判定しないと README は説明する。数値の一部を挙げると、仕様とテストの矛盾を Haiku が黙って「修正」せず表面化したのは 0/4 から 4/4、虚偽の完了報告に仕込まれた不正を Haiku が検出したのは 5/5 が2回、ブランド規則と製品事実のファイルを見つけてからマーケティング文を判定したのは 2/2 で不正 6/6 を検出。一方で、capable なモデルにおける通常の小規模タスクでは「fine / fine (no lift)」と記録されている。round 11 では Fable 5 自身が、フィクスチャの README が指示していた権限外の staging デプロイに 2回中1回従ってしまい、その実行が authorization gate の存在理由になったと書かれている。失敗をログに残す方針は評価できるが、数値はすべてリポジトリ内の自己申告であり、第三者の追試ではない。

効くのは罠の場面で、通常タスクでは差が出ない

README は「the method's value concentrates at traps (authority conflicts, false completion claims, weak executors, unattended runs), not everywhere」と明言している。round 13 ではアダプタバンドルをブラインドで作らせ、Fable-trace の基準で10点満点評価した結果、Haiku は 2 から 6、Sonnet は 9 から 10、Opus は 8 から 9 とされ、「the lift is inversely proportional to tier」がリポジトリの主張だと述べる。ただし round 11 の skipped-deploy 判断は、3種類のルール文言を試して Haiku で 1/12 しか表面化せず、Sonnet と Opus は 8/8 で自然に扱う。つまり弱いモデルへの底上げは万能ではなく、タスクによってはルールを足しても届かない。この 1/12 は open issue として公開されていると書かれており、都合の悪い結果を隠していない点は評価に値する。

導入手順と設定の実体

README の抜粋から確認できるのは、これが Claude Code の plugin として配布される形を取っていることだ。バッジは claude_code-plugin_v1.4.0 を指し、マニフェストは .claude-plugin/plugin.json に置かれている。スキル本体は skills/fable-method/SKILL.md で、fable-loop、fable-judge、fable-domain が同階層に並ぶ構成と読める。eval の再実行に必要なスクリプト名や依存関係、インストール用のコマンドは、与えられた README 抜粋には現れない。したがって「pip install してこう動かす」といった具体的な手順をここで書くことはできない。導入前にリポジトリのルートと .claude-plugin/plugin.json、skills/ 配下のディレクトリ構成を直接確認する必要がある。

向かない場面と、近い設計を持つ代替

向かないのは、既に Sonnet や Opus で短いタスクを回していて、権限外操作や虚偽完了の被害が出ていない場合だ。README 自身が no lift と書いており、手順の追加はコンテキストを消費する。もう一つの限界は、この方法が「検証を名付けられないなら質問を一つ返す」設計である以上、人間が即答できない夜間バッチでは停止が増えることにある。代替としては、リポジトリ自身が比較対象に挙げる「素の frontier モデル」、つまり指示ファイルを足さずモデルの素の判断に任せる運用が最も近い。round 4 と round 5 では Sonnet がコード・データ・調査の4問中3問で素の frontier モデルと同等以上だったと記録されており、差はモデル側の能力で埋まる部分がある。指示を足すかモデルを上げるかは、コストと停止頻度のトレードオフになる。

MIT ライセンスと、追随コストの見積もり

ライセンスは MIT で、LICENSE ファイルが同梱されている。フォーク、改変、商用利用を含む再配布が許される条件の下で公開されているという点は、社内のスキル集に取り込む際の障壁が低いことを意味する。ただし法的な判断はここでは扱わない。保守の観点では、v1.2.0 が 2026-07-09、v1.4.0 が 2026-07-15 と6日間で版を上げており、変更のペースは速い。リリース名に fit gate や twin check といったゲートが追加されていることは、ルールが eval の失敗に応じて増減する運用を示す。SKILL.md が約110行に保たれているうちは読める量だが、ゲートが増え続ければ追従コストは上がる。自分の環境で eval を再実行できないなら、更新のたびにルールの差分を読み直す前提で採用を判断したほうがよい。

編集部の結論

導入を検討すべきなのは、Haiku 級の弱いモデルやサブエージェントを無人に近い形で走らせていて、権限外の操作や虚偽の完了報告を実際に踏んだ経験があるチームだ。逆に Sonnet や Opus で通常の小規模タスクを回しているだけなら、README 自身が「no lift」と書いている通り、追加の価値はほぼ期待できない。最初に確認すべきは eval/cases/s2-surprise-trap.md と eval/results/round13-cross-tier.json の生データで、そこに書かれた実行が自分のタスク形に近いかどうか。近くないなら、このリポジトリを読む価値は方法論の参考にとどまる。

公式情報源

1. Issues
2. License: MIT
3. README
4. Releases
5. Sahir619/fable-method on GitHub