Every
「何を聞けばいいかわからない」ときこそ Fable を使え
要点
- Fable（Claude の最上位モデル）が週次利用枠から従量課金へ移行するタイミングで、Every 編集部が「Fable を使うべき場面」を再定義。タスクの大きさではなく「不確かさの量」で使い分けを判断せよという立場
- Rumsfeld の「既知の未知 / 未知の未知」フレームを援用：書き下ろさなくても本人が見れば気づく基準（unknown known）と、そもそも問いとして立てられていない前提（unknown unknown）の両方を Fable が炙り出す
- Every CEO の Dan Shipper は5週間かけたコピー編集実験で Fable に「自分で結論を出せ」と指示。Fable は測定対象の目標設定自体が未検証だったと発見し、5週間の作業の前提を崩した
- 高価なモデルは「問いを文書化するマシン」としても機能する。Fable が手順を記述し、安価なモデルが次回以降を実行するという2層設計が実用フローとして提示されている
- Bridgewater AIA Labs が Qwen3-235B をファインチューニングし、金融6タスクで全フロンティアモデルを上回りながらコストは 13.8 分の1を達成。定型タスクへの特化モデルの有効性を裏付けるデータとして掲載
編集部の考察
Dan Shipper が Fable に任せた5週間のコピー編集実験で起きたことを、AI の使い方の問題として読むのは浅い。Fable が炙り出したのは「何を測定するか」の定義自体が未検証だったという事実であり、5週間分の実行がその前提ごと崩れた。これは今、AI 全社導入済みの組織で静かに大規模化している構造問題だ。チームが高速で実行できるようになった分、「誤った問いへの正確な答え」が大量生産されるリスクが比例して高まる。KPI 設計の段階でズレていた施策が数ヶ月走り続け、振り返ると「そもそも計測対象が間違っていた」——そのサイクルが AI によって加速する。
この文脈でいえば、Fable（または同等の高性能モデル）の本来の使いどころはスピードの向上ではなく「実行前の問い直し」に当てることだ。Bridgewater が 1/13.8 のコストで金融タスクを自動化できたのも、「何を解くか」が先に固まっていたから成立した話であり、前提が曖昧なまま安価モデルに量産させても同じ結果は出ない。自社で今すぐ確認できる問いは「直近半年の AI 活用プロジェクトのうち、実行前に『これは正しい問いか』を最上位モデルで検証したケースが何割あるか」だ。その数字が低いなら、Fable への投資評価軸を「コスト削減」ではなく「誤った実行を事前に止めた件数・工数」に置き換えるべきだ。
原文より
“Use a cheaper model when the goal, constraints, and definition of good are settled. Reach for Fable when the map is still incomplete.”
本記事は原文ニュースレターの独自キュレーション・考察であり、翻訳ではありません。引用部分の著作権は原著者に帰属します。