「指示を絞る」より「判断を委ねる」——Fableの使い方が変わる

プロンプトエンジニアリングの常識は「具体的に書け」だ。条件を列挙し、例外を潰し、出力形式を固定する。それが正しいとされてきた。しかしClaude CodeチームのCat WuとThariq ShihiparがAIエンジニアリングカンファレンスのFireside Chatで示したのは、その逆だった。

Fable（およびOpus）に対しては、「どう動くべきか」を細かく規定するより、モデル自身の判断に委ねる方が良い結果を得られる——これが彼らの主張だ。

具体例はテストだ。「大きな機能変更のみ自動テストを書け、小さなコピーやデザイン変更ではテストを更新・実行するな」と書くことはできる。しかしそれより「テストを書くかどうかはFable自身が判断せよ」と一言告げる方が優れている、という。なぜか。条件の列挙は必ず漏れを生む。モデルが状況を読んで判断する方が、エッジケースへの対応が柔軟になる。

これは直感に反する。しかし考えてみれば当然でもある。熟練した職人に「包丁は45度で入れろ、力は3キロで」と指示するより「任せる」と言う方が、結果は良い。Fableはすでに十分な判断能力を持っている。問題は、細かい指示がその判断能力を上書きしてしまうことだ。

サブエージェントへの委任——Fableトークンを節約する実践プロンプト

Jesse Vincentが共有した関連Tipsは、よりコスト直結の話だ。Fableのトークンは高価であり、価格改定前の残り日数は限られている。小さなタスクにFableを使い続けるのは無駄だ。

解決策は「Fableに、小さなタスクは低コストモデルで処理させる」こと。そのためのプロンプトが以下だ。

For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent

これをClaude Codeに入力すると、モデルは自動的に `~/.claude/projects/name-of-project/memory/delegate-coding-to-subagents.md` にメモリファイルを保存した。その内容が興味深い。

モデル自身が「Why」を記述している。「実装作業はトップモデルを必要としない。判断・レビュー・統合はメインループに残す」。これはFableが指示の意図を正確に理解し、運用ルールとして内部化したことを示す。

ビフォーアフターで整理する。

Before（過剰指示型）:

小さなバグ修正はclaude-3-haiku、中規模の機能追加はclaude-3-sonnet、
大規模リファクタリングはFableを使え。テストの更新が必要な場合は…

After（判断委任型）:

For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent

後者は1文だ。しかしモデルはこの1文から「コスト効率」「タスク規模の自律判断」「サブエージェント活用」という三つの運用原則を導出した。これが「判断を委ねる」プロンプトの威力だ。

各単語が出力に与える影響

`use your judgement` という句が核心だ。これがなければ単なる「低コストモデルを使え」という命令になる。`judgement` を明示することで、モデルはタスクごとの文脈評価を自分の責任として引き受ける。

`appropriate` も重要だ。「安いモデル」ではなく「適切な低コストモデル」と指定することで、コスト最小化ではなくコストと品質のバランス最適化を求めていることが伝わる。

`subagent` という単語は、メインのFableループを温存する構造を明示する。Fableが直接コードを書くのではなく、別モデルを呼び出す設計を指示している。この1語で、アーキテクチャレベルの意図が伝わる。

ソースによれば、Fableはこのプロンプトを受けてメモリファイルに「judgment, review, and synthesis stay with the main loop」と記述した。これはモデルが「何をFableが担い、何を委任するか」の境界を自律的に定義したことを意味する。プロンプトには書いていない。モデルが推論した。

再現手順と結論

再現は単純だ。Claude Codeのセッション冒頭、または既存プロジェクトのコンテキストで上記プロンプトを1文入力する。モデルがメモリファイルを生成すれば、以降のセッションでも設定が引き継がれる。

テスト戦略についても同様だ。「テストを書くかどうかはあなたの判断に任せる」と一言添えるだけでよい。条件の列挙は不要だ。

筆者が注目するのは、この知見の汎用性だ。「細かく指示するほど良い」というプロンプトエンジニアリングの前提は、モデルの判断能力が低かった時代の産物だ。Fableクラスのモデルに対しては、指示の粒度を下げ、判断の余地を与える方が機能する場面が増えている。これは職人に「任せる」と言える信頼関係に近い。

再現したい読者へ。まず `use your judgement` の6語を自分のプロンプトに加えてみること。その前後で出力がどう変わるか、自分の目で確かめるのが最初の一手だ。