一言で言うと
Django（有名な Web アプリの土台ソフト）の共同創設者 Simon Willison が、Fable 5 を2日間使った感想として relentlessly proactive（とどまることなく能動的）と表現しました。スクロールバーの表示バグを調べるよう頼み、スクリーンショット1枚を渡して席を外したところ、戻ると AI が独自の手順で画面撮影・テストページ作成・プログラムの書き換え・データ受け取り用サーバー構築まで進め、調査がほぼ完結していました。最終的な修正は2行の CSS だった、とも Willison は書いています。
Fable 5 と Opus 4.8 は何が違うか
Anthropic のモデルは、これまで Haiku（速い）・Sonnet（バランス）・Opus（難しい仕事向け）の3段階で、Opus 4.8 が最上位でした。Fable 5 はその上に置かれた新世代「Mythosクラス」の、初めて一般公開された版です。
性能の違い（数字で見ると）
コーディングの実力テスト SWE-Bench Pro では、Fable 5 が 80.3%、Opus 4.8 が 69.2% と報じられています。Anthropic の説明では、差が大きく出やすいのは短い質問ではなく、何手もかかる長い調査や大規模なコード作業です。Stripe が5,000万行のコード移行を1日で終えた、といった事例はこのタイプに当たります。
使い心地の違い（今回の体験で見えるところ）
- Opus 4.8 … 頼まれた作業を丁寧にこなす従来の最上位モデル。今回は Fable が開いた手順を引き継ぎ、最後の修正まで仕上げた
- Fable 5 … 目標に向けて手段を自ら考え、組み合わせる。画面撮影の仕組みを自作、サーバーを立てるなど、頼まれていない手順を次々試した
- 安全面 … Fable 5 は制限が強く、限界に達すると Opus 4.8 へ自動切り替え
- 価格 … Fable 5 は Opus 4.8 の約2倍。今回のセッションは通常料金なら約12ドル相当、と Willison が試算
今回のセッションは、Fable 5 が突破口を開き、Opus 4.8 が仕上げた構図でした。Willison の評価「現状のフロンティアモデルの課題は、できないタスクを見つけること」は、Fable 5 が「できない」と言われがちな複雑な現場調査を、人が席を外しているあいだにほぼ完走した、という意味で読めます。
何が起きているのか
Willison が開発している Datasette（データ閲覧用の Web アプリ）に、スクロールバーが正しく表示されないバグがありました。Claude Code にスクリーンショット1枚を渡し、「依存関係から原因を探して」と伝えただけで、あとは席を外しました。
通常の AI コーディング支援は、ファイルを読む・コードを書く・コマンドを実行する、といった範囲にとどまることが多いです。ブラウザを勝手に開く、画面上の操作を自動化する、手元のサーバーを立てる——こうした行動は、ユーザーが明示的に頼まない限り行わないのが普通です。
Willison が席を外している数分間に、Fable 5 は次のことを自ら行いました。
- 画面の自動撮影: Mac 上のウィンドウ一覧から Safari を見つけ、画面キャプチャ用のコマンドでスクリーンショットを保存
- バグ再現用ページの作成: 調査対象のバグを再現するテスト用の HTML ページを一時フォルダに作り、Safari で開いて確認
- アプリ本体の書き換え: 調査したい画面は、クリックかキーボード操作でしか開けない設計だった。Fable は Datasette のテンプレート（画面の設計ファイル）を直接編集し、ページ読み込み後にショートカットキー「/」を自動で押す仕組みを埋め込んだ
- データ受け取り用サーバーの起動: ブラウザ上で測った数値を AI 側に渡すため、手元の PC 上に小さな Web サーバーを立て、ブラウザから測定データを送る仕組みを自作
一連の作業の途中で、Fable 5 は安全制限に達し、Opus 4.8 へ自動で切り替わりました（前述のとおり、Fable が試した手順を Opus が引き継いで完了）。
Willison の総評は、「Fable は多くの手法を知っており、目標達成のためにほぼ何でも試す」というものです。
AI業界の文脈では
注目すべきは、「バグを直して」という目的に向けて、頼まれていない手段を次々と組み合わせた点です。スクリーンショットを撮れと言っていないのに撮影手段を開発し、サーバーを立てろとも言っていないのにサーバーを構築しました。
上位モデルが限界を検知して下位モデルに引き継ぐ動きも特徴的です。1つのモデルが最後まで完結するのではなく、モデル同士が連携して作業を終わらせる設計が、実務で機能している例です。
私の見立て
「relentlessly proactive」は称賛でも批判でもなく、現状の正確な描写だと思います。
ユーザーから見ると、席を外しているあいだにブラウザが開き、自分のアプリの設計ファイルが書き換えられ、手元のサーバーが起動していたことになります。結果としてバグは直りましたが、何が行われたかは、セッション後に自分で確認しなければ分かりません。
AI エージェントの議論は「何ができるか」から「何をどこまで許可するか」へ移りつつあります。Fable 5 のこの挙動は、その問いを日常的な開発作業の中で突きつけた事例です。
→ 何が変わるか: コーディング向け AI が「頼まれた範囲」を超えて手段を自律的に組み合わせる挙動が、高性能モデルで一般的になりつつあります。開発者にとって「エージェントが今何をしているか」を把握することが、新たな習慣になります。
→ 何をすべきか: Claude Code や Cursor などの AI コーディングツールを使う場合、作業後に「今回使った手順をまとめて」と AI に報告させると、何が変更されたか追いやすくなります。業務で導入する企業は、AI が触れるファイル・ネットワーク・ブラウザの範囲を事前に決めておくことが重要です。