Method

Spec-First Solo Build

コードを自分で書かずに、基準を決めてAIに指示し、プロダクトをリリースまで導く方法

Spec-First Solo Build の進め方を要約

このページは、私が実際に守ってきた作業ルールを1つの方法論にまとめたものです。宣伝文ではなく、すべてのプロジェクトで繰り返している手順です。以下のテンプレートは公開用の骨子です。プロジェクトごとの実際の抜粋は、各ケーススタディの「AIへの指示プロセス」に掲載しています。

(01)

フレームワーク：ゼロからリリースまでの7ステップ

Fig. ai-workflow-01

企画からリリースまで — 指示・確認・修正のループ

01アイデア課題の定義

02企画・基準画面・構成・「こう動くべき」を文書に

03AIに指示目的・基準・制約を一段階ずつ

04実行・確認プレイ・ビルド・ログで基準と照合

05Shipセキュリティ・データ点検後、ストアとWebへ

基準から外れたら原因を指摘して再指示 · 繰り返し

コードは自分で書かず、基準を決めてAIに順番に指示し、自分で動かして修正します。3↔4は基準を満たすまで繰り返します。

01
ルールと設計を先にドキュメントで決める
私はコードを直接読まないため、品質を守る最初の防衛線はルール文書です。プロジェクトごとに作業の進め方・禁止事項・検証基準をルール文書に固定し、各セッションに読ませたうえで「現在の段階を教えて」と言って認識を合わせます。
02
デザイン／UIとデータをすべて先に揃えてから作る
同時に進めると混乱するため、画面とデータを先に確定させます。（例：デザインツールで全画面を書き出してから、コードに組み込む。）
03
小さな単位で指示し、自分で動かして検証する
「できました」で終わらせず、スマートフォンやシミュレーターで動かし、**自分の目で**確認します。
04
基準とベンチマークは点数ではなく言葉で伝える
品質はリファレンス（大手企業のアプリ）とトーンで指定し、実装は任せます。
05
間違いを見抜き、方向を修正する
もっともらしい成功を疑い（「これ、ハードコードじゃないよね？」）、行き詰まったらすぐに動く方法へ切り替えます（見せかけを許さない、現実的な方針転換）。
06
AIの自己申告を信じず、証拠で検証する
「記憶」ではなく、実際のコード・成果物・別の入力で再確認します。
07
引き継ぎ文書で文脈を残し、複数のAIをチームとして動かす
アカウントやコンテキストが変わっても文脈が途切れないよう文書化し、マルチセッションの作業では1つのセッションをPMに任命します。

Spec-First Solo Build — 先にルールと基準を書き、リリースまでAIに作らせ、確認し、修正させる。

ステップ3〜6は一度で終わりではなく、指示 → 確認 → 修正を繰り返します。

(02)

原則

01
推測しない
1回目の修正で直らなければ、2回目の前に公式ドキュメントや類似事例を調べます。
02
作る前に見せる
新しい画面や構造は、まずモックアップやデザインでレビューしてから作ります。
03
変更前に影響を説明させる
副作用や波及する問題を先に説明させ、承認後にのみ変更します。
04
値が最後まで流れることを確認する
フィールドやパラメータを追加したら、定義だけでなくすべての呼び出し箇所を直し、提出前に生成されたコードを読み直します。
05
「間違いが許されない」領域は、基準を文書に書く
ミスが致命的な領域（セキュリティ、給与計算）では、コードより先に設計書を作ります。
06
失敗を原則に変える
1つの損失や障害から、再発を防ぐルールを1つ引き出します。（「変更前に承認を取る」ルールは、初期のトレーディングボットでの失敗から生まれました。）
07
ドキュメントとコードを同期させる
リリースのたびに、ドキュメント上の数値を実際のコードと照合します。AIが書いたドキュメントはずれやすいため、照合を習慣にしています。

(03)

プロンプトテンプレート（骨子）

繰り返し使っている指示のうち、公開しているのは骨子のみです。実際に成果につながった細かな条件・順序・合格基準は、面接や協業の場で共有します。プロジェクトごとの短い抜粋（1〜2文）は、各ケーススタディの「AIへの指示プロセス」に掲載しています。

A. アイデア評価 — 恣意的な点数ではなく、実際の事例に基づく

課題の再定義 → 類似事例の調査 → 成功／失敗パターンの比較
→ 根拠に基づくスコアカード → アイデアの導出 → まとめ（上位案＋リスク＋次のアクション）
[各ステップの基準・件数・合否ルールは非公開]

B. 機能実装の指示

[目的] …   [基準] こう動くこと／こうではないこと   [制約] 技術スタックとポリシー（ドキュメントで確認済み）   [確認] 私がチェックする点

C. バグ修正の指示

[症状] …   [まず] 原因から — 調査と仮説   [修正前に] 影響を説明 → 承認後に変更

(04)

エラーの見つけ方

01
症状を事実として伝える
何が、いつ、どの画面で起きたかを、再現できる形でAIに伝えます。
02
原因が先、推測しない
公式ドキュメントや類似事例を調べ、原因の仮説を立てます。
03
1回目の修正が外れたら、止まる
2回目の前に改めて調べ、同じ推測を繰り返しません。
04
値が最後まで流れることを確認する
修正後、すべての呼び出し箇所と生成されたコードを読み直します。
05
再発を防ぐルールを残す
作業原則や設計基準として記録します。

実際のデバッグ事例（症状 → 指示 → 失敗 → 解決）は、各プロジェクトの「問題解決の記録」に掲載しています。

(05)

失敗から得た教訓

Mistake
トレーディングボットを過信 → 損失
✓ Lesson
変更前に影響を説明させ、承認を取る（現在もすべてのプロジェクトで適用）。
Mistake
AttenNFC：AIが生成したコードが基準に届かない
（給与変数が9つ中5つのみ、APIの不一致、GPSのハードコード）。
✓ Lesson
AIの出力を基準と照合し、ずれていれば書き直しを指示する。書き直し後、`flutter analyze` で問題ゼロを確認しました。
Mistake
MECHOOSE：初期の画面構造が1ファイルに詰め込まれていた
✓ Lesson
分離の基準を最初に決めておくと、後の変更コストが下がる。

(06)

数字で見る作業量（概算）

claude.ai の会話 149件 · ユーザー指示約9,002回（2026年2月〜10月、約8.5か月）— 個人的な会話やポートフォリオ外の会話も含む総活動量です。
5つのプロダクトがリリース／デプロイ段階に到達（THE HOUSE、MECHOOSE、Momento、Money Navigation、MemoHub）。うち2つが稼働中（MECHOOSE、MemoHub）。
1つの会話での最多指示数：THE HOUSE、696回。

数値は記録に基づく概算です（会話のプロジェクト別分類はタイトル・キーワードによる推定です）。

(07) Honest

Honest Review

開発者が作っていたら？強み · 同等 · 次のステップ

強み同等次のステップ（改善中）

THE HOUSE
強み3同等4改善中5
↗ テストと自動化 — 自動テスト・CIは未導入
改善計画 → 購入・セーブ処理のテストとCI、モジュール分割、プライベートGit、一般公開前のサーバー側購入検証
MECHOOSE
強み3同等4改善中4
↗ テストと自動化 — テスト・CI・lint・型チェックは未導入
改善計画 → まず決済処理にテストとCIを導入、バックエンドをドメイン単位で分割、注文・決済を正式なテーブルへ移行、エラーアラートを追加
Momento
強み3同等4改善中5
↗ テストと自動化 — テストはマッチングエンジンのみ
改善計画 → 本番スキーマをリポジトリに固定、主要フローのテストとCI、サーバー側の購入検証、AndroidをiOSと同等に
AttenNFC
強み2同等3改善中4
↗ 機能の完成度 — 実装は設計の約10〜15%
改善計画 → 検証済みの打刻1往復をエンドツーエンドで完成させ、その後、画面の実装に合わせてテスト・CI・翻訳・ラベルを追加
AI動画ストリーミングプラットフォーム
強み4同等3改善中3
↗ テストとバージョン管理 — テストなし、gitなし
改善計画 → まずプライベートGitと決済テスト、その後CI・監視・バックアップ・ロールバック