Fableを使っても、最初から正しい仕様書は書けない

この記事は、Anthropic の Thariq Shihipar による、エージェントが未知の未知（Unknown Unknowns）を発見することについてのブログ投稿を引用しています。地図と地形の比喩を用いて、未知を4つのタイプに分類しています。すなわち、既知の既知（known knowns）、既知の未知（known unknowns）、未知の既知（unknown knowns）、そして未知の未知（unknown unknowns）です。一気に書かれた仕様書は既知の既知しかカバーしておらず、残りは地形を踏破して初めて明らかになります。著者は、仕様書はドラフトを作成し、エージェントに探索させ（コードや MCP 経由のナレッジベースを読む）、新しい詳細が浮上するたびに書き直すべきだと主張しています。この反復プロセスにより、最終的に仕様書が現実と一致するようになります。この記事は SpecBuddy を宣伝しています。これは、OpenCode、Claude Code、Codex と連携し、将来 OpenSpec をサポートする予定の無料の JetBrains プラグインです。