Fable 5 が登場した時点で、AIの進化は新しいフェーズに入った。Anthropic のエンジニア Thariq Shihipar が THE DECODER への寄稿で明かすのは、もはや「モデルの性能を上げること」が課題ではなく、「開発者が自分の知識ギャップに気付くこと」こそが次のボトルネックであるという指摘だ。

なぜ Fable 5 では「ユーザーの盲点」が課題なのか

これまでのプロンプティングの制限は、モデルの能力の限界だった。何か聞いても「難しい」と諦め、別のやり方を試す——その繰り返しだ。

ところが Fable 5 レベルのモデルになると、状況が逆転する。モデルは開発者が期待するより圧倒的に強力だ。だからこそ、開発者の側の問題が浮き彫りになる。

Shihipar が指摘する「ブラインドスポット」とは、プログラマーが自分で気付いていない暗黙知のことだ。例えば：

  • 「この機能はこうあるべき」という無意識の前提
  • 実装の細かい制約や裏ルール
  • チーム内でだけ通用する慣例

これらを Fable 5 に明確に伝えないと、モデルは「一般的な実装」を提案してしまう。その結果、開発者は「なぜこんな実装になってるんだ」と驚くことになる。

実践的な2つの技法

1. ブラインドスポットパス（Blindspot Pass）

実装を Fable 5 に任せる前に、一度自分で書いてみる。そしてその過程で、自分がどんな判断をしているのかを意識的に言語化する。

例えば、単なる「API エンドポイントを作ってください」ではなく、以下のように詳しく説明する必要がある：

  • エラーハンドリングはどんな仕様か
  • ユーザーが 404 を得たときはどう振る舞うべきか
  • キャッシュはどこに入るか、どの程度有効か

Shihipar が推奨するのは、このプロセスを意図的に何度も繰り返すことだ。1回目の「ブラインドスポットパス」では不完全な指示を出し、モデルの出力を見て「あ、ここまで言わないといけないんだ」と気付く。それを 2 回目のプロンプトに反映させる。

2. 構造化インタビュー（Structured Interview）

もう一つの方法が、モデルとの対話を構造化することだ。

開発者は Fable 5 に対して、システマティックな質問を投げかける：

  • 「このコンポーネントの責務は何か」
  • 「どんな入力が想定されるか」
  • 「予期しない入力が来たときはどうする」
  • 「パフォーマンス上の制約は何か」

こうした質問を重ねることで、自分の知識ギャップが浮き彫りになる。そしてその過程で、モデルは「あなたが実は求めているもの」を理解し始める。

プログラマーにとって何が変わるか

Fable 5 の登場は、単なる「高性能なモデルが使えるようになった」という話ではない。

これは、開発プロセス自体の根本的な変化を迫るものだ。これまでは：

  1. 仕様を書く（人間）
  2. 実装する（人間）
  3. テストする（人間）

という流れが、以下に変わる：

  1. 仕様を明確にする（人間が自分の暗黙知を言語化）
  2. 実装を提案させる（Fable 5）
  3. 結果を検証して、仕様の漏れを発見（人間）
  4. 1 に戻る（反復）

つまり、開発者の役割が「コードを書くこと」から「要件を正確に定義すること」へシフトするということだ。

逆に言えば、要件定義が曖昧なままプロジェクトを進めていた開発チームにとって、Fable 5 は「暗黙知が露出する鏡」になる。

実装前に「自分たちは何を本当に必要としているのか」を知ること

Shihipar の主張の要点は、決して複雑ではない：

AIモデルが強くなったからこそ、人間側の要件定義がより厳密に問われるようになった。

ブラインドスポットパスと構造化インタビューは、その厳密さを達成するための方法論だ。面倒に見えるかもしれないが、これを飛ばして Fable 5 に丸投げすれば、却って手直しが増えることになる。

新しい時代のプロンプティングは、モデルに「何をしてほしいか」を伝える前に、自分たちの「本当の要件」に向き合うことから始まる。