1. はじめに
1.1 無料枠、帰ってきました
Fable 5 が帰ってきた！！
6/9にGAして、6/12に輸出規制で止まって、6/30に規制解除、7/1に復活(公式声明)。ジェットコースターみたいな3週間でした。
そして今度は7/1〜7/7、週次利用枠の最大50%までFable 5が無料開放されています。Pro/Max/Team、一部のEnterprise premium seat対象。API利用はこの無料枠に含まれません。
Fableにコードを書かせるな。Fableには「何を書くべきか」を探させろ。
これが結論です。以降、その理由を潰していきます。
1.2 この記事で扱いたい問い
一言で言えば、「なぜ実装に投げるのは筋が悪いのか」。
もう少し具体的には以下です。
- なぜ分類器の誤爆が、実装タスクで特に効いてくるのか
- 実装以外に投げるとしたら、何が候補になるのか
この問いに答えていきます。
2. まず実装に投げたくなる
2.1 素朴に考えるとこうなりそう
50%も無料で使えるなら、一番トークンを食う作業、つまり実装に投げるのが得、と考えるのが自然です。
大規模リファクタ、複数日かかる機能実装、塩漬けの技術的負債の解消。どれも「時間はかかるけど手順は決まっている」タスクに見えます。50%枠をここに突っ込みたくなる。
でも、これは半分しか合ってません。
2.2 しかし分類器の誤爆で崩れる
分類器の誤爆で自走が途中で止まるリスクがある。 これが実装に投げるのを避けたい理由です。
詳しく見ていきます。
3. 分類器の誤爆というリスク
3.1 何が起きるのか
公式ヘルプによると、Fable 5は全リクエストに対してsafety classifierを実行しています。対象は3領域。
- 攻撃的サイバーセキュリティ技術
- 生物学系の内容
- モデル自身の思考過程の抽出
誤爆するとどうなるか。自動でOpus 4.8に切り替わり、以降の会話はOpusに固定される(手動で戻せます)。
3.2 直近のメッセージだけが見られているわけじゃない
ここが決定的です。このチェックは直近のメッセージだけじゃなく、memory・connector経由のコンテンツ・web検索結果・ファイルまで含めて全部見る、と公式に明記されています。
言い換えると、自分が何も書いていなくても、memoryの中身だけで誤爆しうるということ。
overnight run前提の使い方は「途中でモデルが差し替わらない」ことが大前提です。この仕組みは、その前提を静かに壊します。長時間自走させたいタスクほど、途中で止まるコストは高い。
3.3 探索させたいのに、探索自体が誤爆を呼ぶという皮肉
3つ目の対象、「モデルの思考過程の抽出」が地味に効いてきます。
公式プロンプトガイドは、"reasoning を出力させる/説明させる" 系の指示が reasoning_extraction という refusal カテゴリを誤発火させ、Opusへのフォールバックを増やすと明言しています。
この記事で後述する「探索・診断させる」使い方は、性質上「なぜそう判断したか説明して」という指示を書きたくなる場面が多いです。
素直に書くと、誤爆リスクを自分から上げることになる。reasoningの可視化が必要なら、モデルに説明させるのではなく summarized thinking blocks を読む設計にする必要があります。
推している使い方の足を、その使い方自体が引っ張る。地味に厄介な話です。
4. では何に使うべきか
分類器の誤爆リスクを型で整理するとこうなります。
実装タスク : 分類器領域に触れやすい & 途中で止まると被害が大きい -> Fableに投げると損しやすい
探索・診断タスク : 途中で多少止まっても被害が小さい -> Fableの強みと噛み合う
Fableの長期自走能力が本当に生きるのは、「何を実装すべきか自体が自明じゃない」フェーズです。具体的には:
- 技術的負債がどこに溜まっているか、コードベース全体を横断して洗い出す
- 複数の設計選択肢(TCA vs Riverpod、Repository層の切り方など)を、実際のコード規模・依存関係を踏まえて比較させる
- 「この機能を6ヶ月運用したらどこが壊れるか」を今のアーキテクチャから逆算させる
- 受託案件で要件が曖昧なとき、クライアントに聞くべき質問リストを、コードベースや既存ドキュメントから逆引きで作らせる
念のため断っておくと、この4つは公式ソースに載っている事例ではなく、ここまでの根拠から自分が導いた提案です。実装させるんじゃなく、探索・診断・計画させるタスク。
しかも一発の指示で終わらず、モデルが自分で仮説を立てて検証を繰り返す必要がある。
まさにovernight run向きです。
5. 指示の設計思想も実装向きじゃない
公式プロンプトガイドは、旧モデル向けに書いたskillsやプロンプトはFable 5には過剰に規定的すぎて、むしろ出力の質を落としうると明言しています。
デフォルトの挙動の方が優れているなら、古い指示は削除を検討しろ、と。
ガイド全体の構成を見ても、instruction-followingの強さ、意図(reason)を渡すことの有効性、境界(boundary)の明示、自己検証(self-verification)の4つが繰り返し出てくる柱になっています。
これは実装タスクとは相性が悪い。実装は具体的な手順・制約が多いほど安定しますが、Fableのような自律探索が得意なモデルにそれを与えると、過剰指示がノイズになります。
逆に「方針を考えさせる」タスクは元々指示がゆるくて済むので、Fableの強みと構造的に噛み合う。
6. 具体的な使い方の型
- いきなりビルドさせない。先に clarifying question で詰めさせる。 検証基準を先に言語化させてから着手させると、進捗の自己申告が信用できるようになります。
- 進捗捏造を防ぐ一文を必ず入れる(公式プロンプトガイドより、社内テストでほぼ完全に捏造報告を排除できたとされるブロック):
Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so explicitly.
Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that;
when something is done and verified, state it plainly without hedging.
- 投げるのは「積みタスクの中で一番重いやつ」に限定する。 週次枠の50%は有限です。トイタスクや日常のコーディングに溶かすのは機会損失。
7. おわりに
50%枠は「コードを書かせる」より「コードを書く前に決めるべきことを決めさせる」方に使う。これが自分の結論です。
実装は普段のワークフローに任せて、Fableには長期方針・技術的負債の棚卸し・意思決定の材料集めをやらせる。分類器の誤爆リスクという軸で見れば、実装より探索に向いていることは、わりと機械的に導けます。
この一週間の枠、実装に溶かして終わるにはもったいないと思います。