Vol. 01
2026.06.11
2026.06.10 ZENN // TECH

仕様書は書けるし読める俺が、Fable 5に実コードだけ読ませて仕様書を逆算させた話

ORIGIN: ZENN.DEV READ ORIGINAL

さて、早速だが新しいClaudeのモデルについて話をしよう。
新しいものが好きだからだ。

冗談はさておき、Fable 5をこんな使い方するの下名くらいだと思うので所感を話したいと思います。

はじめに

野良の個人開発で、
設計は自分、仕様書を書いて、実装は全てAIに任せる「設計はえなどり、実装はAI」スタイルでアプリを作っている。お決まりのセリフである。

んで普段の開発フローは、

  1. アイデアを降ろす
  2. 壁打ちして仕様を決める
  3. SPEC.mdを書く
  4. Claude Code（or Codex）に投げて実装してもらう
    という流れになっている。

ただ、実装を進める上でドキュメントが追いつかなくなる問題は常に抱えている。自分アプリは自分で使うからね、自分が一番のデバッガーなので。。。

で今回、Fable 5がリリースされたので興味本位で試してみた。

コーディングはさせない。実コードを読ませて、仕様書を逆算させる。

つまり遊びである。

やったこと

プロンプトはシンプルに。

当リポの実コードだけ読んで、全機能・全仕様をMarkdownにまとめて。Mermaidも使って図解して。

渡したのはリポジトリ全体。だけど指示通り実コードのみ読んできた→（src/ / backend/ / src-tauri/）のみ。
既存のspec/docsはちゃんと省いた。
指示してないところは読まない。
GeminiはここでSPEC.md読んで「仕様書作りました！」とか言うからね。マジで。

何度も言うけど、それならOpusでもいいじゃん？ですね。

出てきたもの

  • アーキテクチャ図（Mermaidのgraph TB）
  • 起動シーケンス図（MermaidのsequenceDiagram）
  • 全タブ・全画面の機能仕様
  • 通信・認証仕様
  • セキュリティ仕様
  • APIエンドポイント一覧
  • ファイルシステムレイアウト
  • ビルド・配布の品質ゲート
  • 用語対応表
  • 既知の制約
    約1000行のMarkdownが誕生、Mermaidも指示通り作ってきた。

読んでみた感想

バカほどわかりやすい

自分で書いた仕様書より（当然）整理されているし、ぼやっと理解してたワークフローが可視化されてめちゃくちゃ助かる。

仕様書は書ける読める自分が、自分のアプリの仕様書を読んで本当の意味で自分のアプリを理解できた瞬間だったわ。
これはそこそこ重要な貴重なことだと思っている。

「AIが書いたものをそのまま使う」ではなく、「自分が理解するための道具として使う」という使い方として、今のところ一番しっくりきている。

既存仕様書との乖離

本来の目的だった乖離チェックも実施した。

Fable 5君曰く
「全体所見: 実装品質そのもの（セキュリティ境界・テスト・エラー処理・同意制）は規範に概ね忠実で、思想（Philosophy）からの本質的逸脱は見られない。最大の問題は**「実装が仕様書より 2〜3 周先に進んでおり、正典ドキュメント群が 2026-05-25〜27 で止まっている」**ことに集約される。docs/end の個別仕様は充実しているため、機能ごとの根拠は追えるが、正典（API_SPEC / REQUIREMENTS / DESIGN / UX_FLOW）だけを読んだ人は現在のアプリ像を把握できない。」

ドキュメントとコードのズレを人間が追うのは地味にしんどい作業なので、これは普通に助かった。

そして
Fable「軽量 VAE は「初回 VAE 復号が遅い問題」への合理的な既定だが、ローカル完結を明示する Philosophy のアプリが、ユーザーへの予告なしに HF へ接続する点は説明責任の穴になっている。最低限、設定/セットアップ画面での説明文と、レジストリ（リポジトリ ID 固定）の明文仕様化を推奨。」
と指摘してきた。

そう、先日ライセンス関係の記事を出した上でコレなので目も当てられない。早急にアプリの修正を行いたいと思う。

そして仕様駆動開発でアプリを作ってる気になってる、というのがよく分かった。痛感した。

まだまだ俺は バイブコーディング が辞められないのだと、ノリで追加するな機能を。（自戒）

そしてFable、仕様書を作っただけなのに既存Documentと比較し乖離を探させるタイミングで 実バグ まで探してきやがった。意味がわからない。

Fable 5の所感

消費が重い。マジで重い。

ただ、「やるべきことを実直にやる」モデルだという印象を持った。
Opusが途中でふわっとしがちな長いタスクでも、最後まで密度が落ちなかった。これは本当にすごい。

コードベース全体を体系的にスキャンして、構造化して出力する、という作業との相性はかなり良いと思う。絶対Opusで必要十分だと思うけど。
ただ、Opusでここまでのモノが出せるかという点が興味があるので、全く同じプロンプトで検証した結果、比較は別記事でやります。

だって消費重いし（大事なことなので以下略）。

まとめ

  • 実コードから仕様書を逆算させる用途に、Fable 5はよく合うがOpusでもよくね？感はある。なので比較してみたい。
  • コードが読めなくても、仕様書が読めれば理解できる出力が出てくるのはアツイ、Opusと比較してみたい。
  • 「AIに実装させる」以外の使い方として、「AIに読ませて自分が理解する」というアプローチもある→どのモデルにも言えることだが
  • ただ全く仕様書を書かないバイブコーダーにこそおすすめ、仕様書書いてる俺でコレなので。
  • 何故か実バグも見つけてくる
  • 6/22まではProプランで追加費用なしで使えるので、重いタスクを試すなら今、5時間上限は一瞬で枯渇したが。

この記事自体、勢いでFable 5が出た日に書いている。初日レポートとして参考になれば。

BACK TO WRITING