Fable 5で設計・Codexで実装する爆速システム開発

この記事で分かること

「AI システム開発」「Claude Codex 開発」で検索している人が知りたいことは、たぶん「AIでシステムが作れるか」だけではありません。

なぜ1つのAIに丸投げすると迷走するのか。設計書はどう書かせればいいのか。CodexとClaude Code、どっちに何をやらせるのか。できあがったものが正しいかどうかを、コードが読めない自分がどう確認するのか。料金はどのくらい見ておけばいいのか。

最初に送るプロンプト

まずはこれです。Claude Codeを起動して /model でFable 5に切り替え、このプロンプトを貼ってください。要件のヒアリングから設計書12ファイルの生成まで、この1本で始まります。

[]の中だけ、自分の作りたいものに書き換えればOKです。

あなたはこのプロジェクトの設計担当です。
これから作りたいシステムの設計書一式を作ってください。
コードはまだ書きません。設計だけに集中してください。

作りたいもの:
[例: 複数のSNSアカウントの投稿ネタと下書きを、カレンダーで管理する社内ツール]

進め方:
1. まず要件ヒアリングをしてください。業務の流れ、使う人と人数、
   必要な画面、扱うデータ、権限の違い、絶対に外せない条件を、
   1問ずつ順番に質問してください。
   私が答え終わるまで、設計書を書き始めないでください。
2. ヒアリングが終わったら、doc/design/ フォルダに設計書を
   12ファイルに分割して作成してください。
   01-architecture.md      システム構成・技術スタック・環境変数
   02-roles-permissions.md ロールと権限・状態遷移
   03-screens.md           画面一覧・ルート・画面別の詳細仕様
   04-database.md          テーブル定義・データの関係図
   05-api.md               処理の設計・エラー設計
   06-security.md          認証・アクセス制御・秘密情報の扱い
   07-domain.md            このシステム固有の業務機能
   08-offline.md           オフラインなど特殊環境対応（不要なら「対象外」と明記）
   09-quality-testing.md   品質基準・テスト計画
   10-decisions.md         意思決定ログ（D-xx）
   11-current-state-gaps.md 現状と設計の差分（GAP-xx）
   12-design-system.md     デザインルール
3. 設計中に決めたことは、すべて 10-decisions.md に D-01 から番号を振って
   「決定 / 理由 / 出所（私の指示か、AIの推奨か）」の表で記録してください。
   AIの推奨で決めたものには★を付けて、後で私が確認できるようにしてください。
4. 既存のコードや資料がある場合は先に照合して、設計と現状のズレを
   11-current-state-gaps.md に GAP-01 から番号を振って記録してください。
5. 秘密のキー（APIキー、パスワード、顧客データ）は設計書に絶対に書かないでください。
   .envで管理する前提にして、設計書には変数名と取得方法だけを書いてください。

完成したら:
- doc/design/README.md に章構成の一覧と「読む順序」をまとめてください
- 私が確認すべき決定（★付きのD-xx）だけを一覧にして見せてください

途中で矛盾や不明点が出たら、勝手に進めず、
選択肢と推奨案を出して私に確認してください。

このプロンプトが何をしているのか、なぜこの形なのかを、ここから1つずつ分解して説明します。

Fable 5で設計・Codexで実装とは？AI分業の考え方

Fable 5で設計・Codexで実装とは、システム開発の「考える工程」と「手を動かす工程」を、別々のAIに分担させる開発スタイルです。

人間のチーム開発と同じ構図です。優秀な設計者が仕様書を書き、実装チームがそれに沿って作り、設計者がレビューする。この体制をAI2つで再現します。

「AIに作ってと言えば全部やってくれるのでは？」と思うかもしれません。実際、小さなツールなら1つのAIへの丸投げで動きます。でも画面が5枚を超え、権限が2種類を超え、データベースが絡んだ瞬間に、丸投げは高確率で迷走します。作るたびに仕様が変わり、直すたびに別の場所が壊れる。原因は、「何を作るか」がどこにも書かれていないからです。

だから先に設計書を作ります。設計書は、AIチームにとっての「正解の定義」です。

なぜ設計と実装でAIを分けるのか（得意分野と料金）

分ける理由は2つあります。得意分野と、お財布の事情です。

理由1: 得意分野が違う

理由2: 料金の構造が違う

ここが実務では一番効きます。

Fable 5のAPI料金は入力100万トークンあたり10ドル、出力50ドル。Opus 4.8の2倍、Sonnet 5の5倍です。サブスクプラン（Pro/Max/Team）では、2026年7月1日〜7月7日は週間利用枠の50%までFable 5を使える期間限定プロモーション中で、7月8日以降はUsage Credits（従量クレジット）での利用になります。しかも週間枠は他モデルとの合算なので、Fable 5の枠は貴重品です。実装のような大量出力の仕事に使うと、あっという間に枠が溶けます。

一方Codexは、ChatGPTの課金プラン（Plusなど）の枠内で使えます。つまりClaude側の枠を1トークンも消費せずに、実装の手数を確保できる。すでにChatGPTに課金している人なら、追加コストは実質ゼロです。

Codex自体をまだ入れていない人は、先にCodexのセットアップを済ませておいてください。この記事ではCodexが使える前提で進めます。

あわせて読む Codex CLIインストール完全ガイド｜初心者向け手順 実装の手になるCodexのインストールと初期設定。Mac・Windows対応、ChatGPT課金ユーザーにおすすめな理由も解説。

爆速システム開発の全体フロー6ステップ

全体の流れはこの6ステップです。STEP1・2・4がFable 5、STEP3・5がCodex、STEP6が人間の仕事です。

設計書の作らせ方｜12分割テンプレート

設計書とは、「何を作るか」「なぜそう決めたか」を、実装する人（AI）が迷わない粒度まで書いた文書のことです。

1ファイルの巨大な設計書にはしません。役割ごとに12ファイルへ分割します。これはhashshが普段の開発で実際に使って回している構成そのままです。

分割する理由は、後工程で「必要な章だけ読ませる」ためです。Codexにログイン画面を作らせる時は02と03と06を読ませればいい。DBを触らせる時は04と06。全部を毎回読ませると、AIの集中力（コンテキスト）を無駄遣いします。

題材は業務システムに限りません。例えばSNS分析ダッシュボードを作るなら、03-screens.mdに「アカウント別サマリー」「投稿一覧」の画面仕様を、04-database.mdに投稿データと集計値のテーブル定義を書く、という同じ型で進められます。作るものが変わっても、設計書の骨格は変わりません。

もう1つ大事なのが、README.mdに「読む順序」を書かせることです。「画面実装をする場合は03と05と02を併読」「何かを決め直したい場合はまず10を確認」のような案内があるだけで、CodexもFable 5も、そして未来の自分も迷わなくなります。

D-xx意思決定ログ｜決めたことを番号で記録する

12ファイルの中で一番効くのが、10-decisions.mdのD-xx意思決定ログです。

D-xxとは、開発中に決めたことに「D-01、D-02…」と通し番号を振り、決定の内容と理由をセットで表に記録していく運用のことです。例えばこんな形で書きます。

ポイントは3つです。

1つ目、理由を必ず書く。「なぜそう決めたか」が残っていると、後から「これ変えていい？」と迷った時に、当時の前提ごと判断し直せます。理由のない決定は、数週間後にはただの謎ルールになります。

2つ目、出所を分ける。人間が確定させた決定と、AIが推奨で決めた決定（★付き）を区別します。人間は★だけ確認すればいいので、レビューの負担が激減します。

3つ目、変更は書き換えではなく追記。決定を変える時は行を書き換えず、変更履歴として下に追記します。「一度D-08と決めたが、7月にこう変えた」という履歴自体が資産になります。

決定の数は、システムの規模によっては数十件になりますが、多くても問題ありません。番号と理由さえ揃っていれば、途中で仕様変更が入っても「新しいD-xxを追記して、関連する章を改定する」という最小の手数で設計書全体を最新に保てます。書き換えるのではなく積み上げる。これがD-xx運用の強さです。

GAP-xx差分管理｜設計と現状のズレを番号で潰す

もう1つの武器が、11-current-state-gaps.mdのGAP-xx差分管理です。

GAP-xxとは、「設計書ではこうなっているはずなのに、現状はこうなっている」というズレに「GAP-01、GAP-02…」と番号を振って一覧管理する運用のことです。

設計と現実は必ずズレます。途中から設計書を作った場合は既存コードとズレているし、実装が進めば「設計書に書いたけど実装が追いついていない部分」「実装で先に変えたけど設計書が古いままの部分」が生まれます。このズレを放置すると、設計書はただの飾りになります。

だからズレを見つけるたびに番号を振って記録します。例えばこんな形で書きます。

GAP-xxの運用ルールは2つだけです。

• 見つけたら即番号を振って記録する。その場で直せなくてもいい。記録されていれば消えない
• 解消したら「解消済み」と日付を書いて残す。行ごと消さない。「GAP-10は7月2日に解消」という履歴が、後のレビューの材料になる

見つけたGAPは、実装前に解消すべきもの、実装と並行で潰すもの、「V1ではこのままでよい」と判断して閉じるものに仕分けます。全部直すのではなく「直さないと決めて記録する」も立派な管理です。

Codexへの実装指示の書き方｜impl単位で区切る

設計書ができたら、いよいよCodexの出番です。指示の型はこれです。

doc/design/ の設計書一式を読んでから作業してください。
今回のタスクに特に関係するのは 03-screens.md、04-database.md、10-decisions.md です。

今回のタスクは impl-01 です。範囲はここまで:
[例: ログイン画面と認証まわりだけ。他の画面には触らない]

守ること:
- 設計書と違う実装をしたくなったら、勝手に変えず、理由を書いて提案する
- 10-decisions.md のD-xx（決定事項）に反する実装はしない
- 秘密のキーは.envから読む。コードに直書きしない

終わったら、実装レポートを1本書いてください。
内容: 実装した範囲 / 設計書どおりにできた点 /
設計書とズレた点とその理由 / 未実装の残り / 動作確認した方法

大事なポイントを3つ説明します。

一度に全部作らせない。impl単位で区切る

implとは実装タスクの単位のことで、「impl-01: 認証」「impl-02: 一覧画面」のように、システムを縦に切った小さなまとまりごとに実装を進めます。

理由は単純で、レビューできる大きさに保つためです。10画面を一気に作らせると、レビューも一気に10画面分になり、問題が絡み合って原因が追えなくなります。impl単位なら「impl-05だけがおかしい」と切り分けられる。小さなシステムでも、認証・一覧画面・詳細画面・管理画面くらいの粒度で区切るのがおすすめです。

実装レポートを書かせて往復する

Codexには毎回、実装レポートを書かせます。これが次のレビュー工程の入力になります。特に「設計書とズレた点とその理由」を書かせるのが重要で、Codex自身に自己申告させると、レビューで見るべき場所が先に分かります。

「勝手に変えるな、提案しろ」を明文化する

AIは善意で設計を「改善」しがちです。それ自体は悪くないのですが、黙って変えられると設計書が嘘になります。だから「変えたくなったら提案として書け」をルール化します。提案が妥当なら、D-xxに決定として追記してから実装させる。この一手間が設計書の鮮度を保ちます。

Fable 5にレビューさせる｜fix→reverifyのサイクル

Codexの実装が終わったら、Fable 5をレビュー担当（検問所）として呼びます。プロンプトはこれです。

doc/design/ の設計書と、今の実装コードの差分レビューをしてください。
Codexの実装レポートはここにあります: [レポートのパス]

やること:
1. 設計書の仕様と実装を照合し、ズレをGAP-xx形式で番号を振って一覧化する
2. 重大度を Critical / High / Medium / Low に分ける
3. 「実際に動かして実証できた問題」と「コードを読んだだけの推測」を
   区別して書く
4. 修正の推奨順を最後にまとめる

可能なら実際にビルドして画面を動かし、重大な問題は再現手順付きで
レポートに残してください。

このプロンプトの肝は3番です。「コードを読んだ感想」と「動かして確認した事実」を分けさせると、レビューの信頼度が一気に上がります。

レビューでは実際に動かして確認させると、コードを眺めるだけでは見つからない不具合まで拾えます。例えば「画面上は保存できたように見えるのに、データが正しく残っていない」タイプの不具合は、実際に画面を操作してDBの中身まで確認しないと表面化しません。動かした証拠と再現手順がセットになった指摘が返ってくるようになると、人間のシニアエンジニアのレビューとほぼ同じ働きです。

fix→reverifyまでが1サイクル

レビューが出たら、レポートをそのままCodexに渡して修正させます。

レビューレポート [パス] の Critical と High を修正してください。

守ること:
- 指摘された箇所だけを直す。関係ない場所のリファクタリングはしない
- GAP番号ごとに「何をどう直したか」を修正レポートに書く
- 設計書側の変更が必要だと思ったら、勝手に変えず提案として書く

修正が終わったら、Fable 5に同じ手順でもう一度検証（reverify）させます。「修正しました」を信用せず、レビュー時と同じ操作を再実行させて、全項目パスを確認して初めてそのサイクルが閉じます。

hashshの実例｜このブログシリーズの制作

机上の空論ではない証拠として、hashshで実際に回している例を紹介します。

注意点と落とし穴

この方法は強力ですが、ハマりどころもあります。先に潰しておきます。

設計書なしでCodexに丸投げしない

一番多い失敗です。設計書を飛ばして「いい感じの予約システム作って」とCodexに投げると、最初の1時間は快調に見えて、その後必ず迷走します。仕様の判断を全部AIの気分に任せているので、直すたびに別の何かが変わる。丸投げで動くのは小さなツールまで、と割り切ってください。

設計書が古いまま実装が進むズレに注意

実装中に仕様は必ず変わります。その時に設計書を直さないと、「設計書とコードのどっちが正しいのか誰にも分からない」状態になります。対策はこの記事で書いたGAP管理です。ズレたら即GAP-xxで記録、変更が確定したらD-xxに追記して設計書を更新。「設計書が常に正」を保てるかが、このやり方の生命線です。

秘密情報を設計書に書かない

動作確認は人間も必ずやる

Fable 5のレビューは優秀ですが、「業務としてこの動きで正しいか」までは保証しません。現場の人がスマホで使った時に指が届くか、入力が面倒すぎないか。最後は必ず自分の手で触ってください。AIのreverify全パス＋人間の実機確認、の二段構えが完成条件です。

うまく回らない時のエラー対処

Codexが設計書を無視して独自実装を始める

症状: 設計書を渡したのに、画面構成やデータ構造が設計書と違うものができてくる。

原因: 指示に「設計書を読め」しか書いておらず、今回のタスクに関係するファイルを指定していない。設計書が長すぎて肝心の部分が読み飛ばされている。「守ること」が明文化されていない。

確認すること: 実装指示に、読むべき設計書ファイルを名指しで書いたか。「D-xxに反する実装はしない」「変えたい時は提案する」のルールを入れたか。

対処: 指示の型をこの記事の「Codexへの実装指示」に差し替え、関連ファイルを名指しする。すでにできてしまった分は、Fable 5に「設計書との差分をGAP-xxで洗い出して」とレビューさせ、差分一覧をCodexに渡して設計書側に寄せる修正をさせる。

実装が途中で止まる・迷走する

症状: Codexが長時間動いた末に中途半端な状態で止まる。または同じ修正を行ったり来たりする。

原因: 1回のタスクが大きすぎる（impl単位で区切っていない）。設計書に決まっていない部分があり、AIが判断を保留したまま進んでいる。

確認すること: 今回の指示の範囲が「1〜2画面」「1機能」程度に収まっているか。止まった箇所に対応する設計書の記述があるか。

対処: タスクをimpl単位に割り直して範囲を明示して再指示する。設計書に穴があったら、Fable 5と相談して決定を作り、D-xxに追記してから再開する。迷走したセッションは深追いせず、新しいセッションで「現状の整理」から始める。

実装が設計書とズレたまま進んでいた

症状: 何implか進んだ後で、初期の実装が設計書と食い違っていたことに気づく。

原因: implごとのレビューを飛ばして先に進んだ。Codexが「良かれと思って」変えた部分が報告されていなかった。

確認すること: 実装レポートに「設計書とズレた点」の欄があるか。前回のレビューはいつか（impl何個分レビューを飛ばしたか）。

対処: いったん実装を止めて、Fable 5にフルレビューを依頼し、ズレを全部GAP-xxで一覧化する。GAPを「実装を直す」「設計書を直す（D-xx追記）」「V1ではこのまま」に仕分けする。以後は「implごとに必ずレビュー」をルール化する。

レビューで指摘した箇所が直らない・別の場所が壊れる

症状: fixを指示したのに同じ指摘が再検証で再発する。または修正のたびに別の機能が壊れる。

原因: 修正指示が「レポートを見て直して」だけで、対象と優先度を絞っていない。「関係ない場所を触らない」の縛りがなく、修正のついでに広範囲を書き換えている。

確認すること: fix指示にGAP番号・重大度の指定があるか。修正レポートに「何をどう直したか」が番号ごとに書かれているか。

対処: fix指示を「CriticalとHighのみ」「指摘箇所以外は触らない」の形に直す。reverifyは前回と同じ手順で再実行させ、パスするまでサイクルを閉じない。2回直らない指摘は、Fable 5に「なぜ直らないのか」の原因分析だけを先にさせる。

Fable 5の週間枠が切れた

症状: 設計やレビューの途中で、Fable 5の利用枠が上限に達して使えなくなった。

原因: Fable 5に実装のような大量出力の仕事までやらせて、枠を使い切った。週間枠が他モデルとの合算（内数）であることを見落としていた。

確認すること: Fable 5を使っていた作業のうち、Codexや下位モデルに回せるものがなかったか。枠のリセットタイミングと、Usage Credits（従量クレジット）の残り。

対処: 実装・単純な修正・調べ物はCodexやSonnet 5に寄せて、Fable 5は設計とレビューだけに絞る。枠が戻るまでの間は、レビュー待ちのfixをCodex側で進めておく。急ぎならUsage CreditsやAPIでの利用を検討する。料金は事前に公式ページで確認する。

設計書に秘密情報を書いてしまった

症状: 設計書やテストデータに、APIキーや実在の顧客情報が入っていることに後から気づいた。

原因: ヒアリング中に実データをそのまま貼ってしまった。「設計書には変数名だけ」のルールを最初のプロンプトに入れていなかった。

確認すること: 設計書・実装レポート・テストデータの中に、キーの値、実在の名前・住所・電話番号がないか。そのファイルがGitなどの履歴に残っていないか。

対処: 該当箇所を変数名・ダミーデータに置き換える。履歴に残っている場合は、書かれてしまったキーを無効化して再発行する。以後は最初のプロンプトに「秘密情報は設計書に書かない」を必ず入れる。

AIに聞くためのプロンプト集

システムを作りたいので、要件の壁打ちに付き合ってください。

作りたいもの: [例: 店舗の予約をLINEから受け付けて一覧管理したい]
使う人: [例: お客さん、店舗スタッフ、オーナーの3種類]
今の困りごと: [例: 電話予約の聞き間違いとダブルブッキング]

まだ設計書は書かないでください。
私の説明の曖昧な部分、決まっていない部分を質問で洗い出して、
「決まったこと」「決める必要があること」の2つの一覧にしてください。

doc/design/ に設計書一式があります。
私はコードが読めない非エンジニアです。

この設計書の中で、人間の私が必ず確認・判断すべき箇所だけを
優先度順に挙げてください。
特に 10-decisions.md の★付きの決定は、1件ずつ
「何を決めたか」「もし間違っていたら何が起きるか」を
専門用語を使わずに説明してください。

doc/design/ の設計書一式を読んでから作業してください。
今回のタスクに特に関係するのは [03-screens.md と 04-database.md] です。

今回のタスクは [impl-01] です。範囲: [ログイン画面と認証まわりだけ]

守ること:
- 設計書と違う実装をしたくなったら、勝手に変えず理由を書いて提案する
- 10-decisions.md のD-xxに反する実装はしない
- 秘密のキーは.envから読む。コードに直書きしない

終わったら実装レポートを書いてください。
内容: 実装した範囲 / 設計書どおりの点 / ズレた点と理由 /
未実装の残り / 動作確認した方法

doc/design/ の設計書と今の実装コードの差分レビューをしてください。
Codexの実装レポート: [パス]

1. ズレをGAP-xx形式で番号を振って一覧化する
2. 重大度を Critical / High / Medium / Low に分ける
3. 実際に動かして実証できた問題と、コードを読んだだけの推測を区別する
4. 修正の推奨順を最後にまとめる

可能なら実際に画面を動かして、重大な問題は再現手順付きで残してください。

レビューレポート [パス] の Critical と High を修正してください。

- 指摘された箇所だけを直す。関係ない場所のリファクタリングはしない
- GAP番号ごとに「何をどう直したか」を修正レポートに書く
- 設計書側の変更が必要だと思ったら、勝手に変えず提案として書く

修正が終わったら教えてください。別のAIに再検証させます。

AIでのシステム開発が途中で止まっています。状況を整理してください。

作っているもの: [概要]
今の進み具合: [例: impl-03まで完了、impl-04のレビューで指摘が直らない]
直近でやったこと: [例: fixを2回指示したが同じ指摘が再発]
出ているエラーや症状: [画面に出ている範囲でOK。秘密の文字列は貼らない]

原因の候補を可能性が高い順に挙げて、
「次にやるべきこと」を1つだけ提案してください。

AI開発の役割分担を見直したいです。

契約中のプラン: [例: Claude Pro と ChatGPT Plus]
今Fable 5にやらせていること: [例: 設計、実装、レビュー全部]
週間枠の状況: [例: 週の半ばで上限に達しがち]

Fable 5にしかできない仕事と、CodexやSonnet 5に回せる仕事を仕分けて、
枠が週の最後まで持つ配分を提案してください。
料金の最新情報は公式ページで確認するので、考え方だけでOKです。

AI分業システム開発の実務事例12選

「システム開発」と聞くと大げさですが、この分業が効くのは大規模開発だけではありません。AI駆動倶楽部の考え方は「AIで作る / AIでバズる / AIで運営する」。運営はhashshnet（はしもとかずや）です。SNS運用の道具から社内の業務システムまで、実務で狙い目の12例を挙げます。

なおSNS系ツールは、下書き・管理・分析までをシステム化するのがおすすめです。投稿そのものの完全自動化はアカウント停止のリスクがあるため、公開ボタンは人間が押す設計にしてください。バズ投稿の分析自体をFable 5にやらせる手順はFable 5でバズリサーチ｜XとYouTubeの分析手順にまとめているので、リサーチの型ができたら、この記事の方法でツール化すると運用が楽になります。

共通するのは、どれも「外注すると数十万〜数百万円、既製サービスだと微妙に業務に合わない」ゾーンだということです。設計書ベースのAI分業は、まさにこのゾーンの選択肢になります。

よくある質問

まとめ

AI開発の質は、モデルの賢さより「体制」で決まります。

設計の頭脳と実装の手を分ける。決定はD-xxで、ズレはGAP-xxで番号管理する。この2つを守るだけで、「AIに作らせたけどぐちゃぐちゃになった」から「AIチームで開発が回る」に変わります。

あわせて読む Claude Fable 5とは？できることを初心者向け解説 設計の頭脳になるFable 5というモデル自体を知りたい人へ。できること、料金、注意点を初心者向けに解説。

あわせて読む Claude Fable 5完全マスターガイド｜10記事の歩き方 Fable 5シリーズ全体のまとめ。理解から導入、実務活用、開発、収益化まで、目的別の読む順番つき。

更新履歴

• 2026-07-03: 事例記述を整理。実務事例12選にSNS系ツールの例を追加。
• 2026-07-02: 記事公開。