AIプロダクトをつくる

一度も使ったことのないプロダクトの仕様を二日かけて書いた。代わりにやるべきだったことを記しておく。

2026-03-20

英語の原文から翻訳

私はAIを使った投資リサーチツールをつくってきた。複数セクターにまたがるサプライチェーン分析、自動化された仮説管理、敵対的なストレステスト、ひととおり全部だ。この二日間で、私のAIコーディングアシスタントと私が生み出したものは次のとおりである。

• 11本の仕様書(Prismaスキーマ、API契約、伝播アルゴリズムを合わせて1,400行超)
• 5つのインタラクティブなUIモックアップ
• 並列リポジトリ構築のための2つの自律ビルドプロンプト
• 38個のバグを見つけた3ラウンドの外部レビュー
• リサーチシステムの4度の書き直し

それでいて、私はこのプロダクトをまだ一度も使っていない。

愚痴を書いているのではない。仕様は本当によくできている。アーキテクチャは敵対的レビューを生き延びた。コードは今まさに二つのターミナルでビルドされている。だがリサーチパイプラインの書き直し3回目のあたりで、私は気づいた。暗闇の中で設計してきたのだ、と。あらゆる「発見」、つまりデータベースのパスのバグ、Googleニュースの品質の問題、偽のシードデータの問題、スリープ中のノートパソコンではcronが動かないという問題、そのどれもが、実際に使えば最初の10分で見つかっていたはずのものだった。

この文章は、最初からこう進めればよかったと思う枠組みである。

間違いのパターン

私がやったのはこうだ。

漠然とした着想
  → すべてを設計する
    → すべてを仕様化する
      → 仕様をレビューする
        → 仕様を直す
          → すべてをビルドする
            → 想像したとおりには動かないと気づく
              → 書き直す

着想から最初の実使用までの時間、数週間。ビルドする前に学んだ量、ほぼゼロ。

仕様は私が想像したものを捉えていた。私が必要としたものは捉えていなかった。この二つは別物であり、プロダクトを使わないかぎり見分けはつかない。

実際にうまくいくパターン

漠然とした着想
  → 中核のループを一度に組み上げる(2〜4時間)
    → それを自分で3日間使う
      → 実使用で足りなかったものを書き出す
        → 足りない部分をつくる
          → 1週間使う
            → ここで本当のプロダクトが何かが分かる
              → それを仕様化してビルドする

着想から最初の実使用までの時間、一回の午後。アーキテクチャに踏み込む前に学んだ量、肝心なことのすべて。

フェーズ0、三つの問い(30分)

漠然とした着想がある。設計してはいけない。仕様化してはいけない。コードエディタを開いてもいけない。三つの問いに答えよ。

Q1、最小単位の行動は何か。 このプロダクトで毎日やることになる、ただ一つのこと。壮大なビジョンではない。役に立つ最小のやり取りだ。

私のツールでいえば、「自分の投資仮説について朝のブリーフィングを読み、何か対応が要るかを決める。」

Q2、その行動を可能にするデータは何か。 最小限のデータ。完全なデータモデルではない。

「証拠つきの5〜10件の仮説と、それに紐づいた今日の関連ニュース。」

Q3、一回のセッションで『完了』はどう見えるか。 アプリを閉じるとき、何を成し遂げたか。

「どの仮説が今日強まったか弱まったかが分かり、対応したか、しないと決めたか、どちらかになっている。」

これらに明確に答えられないなら、その着想はまだ熟していない。考え続けよ。ビルドするな。

フェーズ1、一回で組み上げるプロトタイプ(2〜4時間)

明日の朝に実際に使えるものをつくれ。デモではない。モックアップではない。本物だと感じられる程度には本物のデータで、最小単位の行動を実行するツールだ。

ルール。

• 単一ファイルか単一ページ。アーキテクチャは要らない。
• データのハードコードでよい。自分で書いた本物の例を3〜5件入れたJSONファイルで十分だ。
• データベースなし。APIなし。認証なし。
• UIは醜くてよい。やり取りは本物でなければならない。
• 明日それを開いて、端から端まで「そのこと」を実行できなければならない。

私のツールなら、こうあるべきだった。手書きの投資仮説5件、その朝に見つけた本物のニュース見出し3本、そして各仮説を「補強する/弱める/無関係」と印づけるボタンを載せた単一のHTMLページ。決定はlocalStorageに保存する。合計のビルド時間、2時間。

私が実際にやったこと。15テーブルのデータベーススキーマ、4エージェントのパイプライン、減衰係数つきの伝播エンジンを設計した。プロダクトを一度でも使う前に。

フェーズ2、3日間のテスト(3日、1日15分)

プロトタイプを3日間、毎日使え。本当に使うのだ。「眺めて、使うところを想像する」ではない。起きて、開いて、そのことをやる。

各セッションのあとに、ちょうど3つ書け。

1. 実際にやったこと(やろうと計画したことではない)
2. 足りなくて別のツールに手を伸ばさせたもの
3. 一度も触らなかったもの

3日後には9つの観察が手に入る。これらはどんな仕様書よりも価値がある。次のものを明らかにするからだ。

• 本当のワークフロー(想像したものとは別の)
• 本当のデータ要件(理論上は完全なモデルとは別の)
• 不可欠に思えたが実はそうでない機能

プロトタイプを3日使えば、私はこう学んでいたはずだ。

• 朝の流れは30分ではなく5分で済む。5分のために設計せよ。
• どの日も気にかけるのは2〜3件の仮説だけだ。22件並べるのはノイズである。
• 敵対的に問いを突きつける機能は、コーヒーの前には煩わしい。夜に回せ。
• データの品質は、データの自動化よりはるかに重い。SEC提出書類からの本物の発見一つは、スクレイピングした見出し12本に勝る。
• トレードの操作は、シグナルからワンクリックで届くべきで、別ページに埋もれていてはならない。

仕様を一行も書く前に、私は機能の半分を削っていただろう。

フェーズ3、アーキテクチャの決定(2〜4時間、一つの文書)

ここでプロダクトが何かが分かっている。想像したものではなく、体験したものが。理論上のワークフローではなく、本当のワークフローを軸にアーキテクチャを設計せよ。

文書を一つ書け。 それはこれを扱う。

1. 毎日のループ。何が、どの順で、何分で起きるか、ちょうどそのとおりに
2. データモデル。毎日のループに要るテーブルだけ
3. ビルドの順番。最もよく使うものに基づいて、何から先につくるか

ビルド順のルール、表示よりデータが先。 私は、それを表示するデータを生み出すリサーチシステムをつくる前に、美しいUI画面を5つつくった。何週間ものあいだ、アプリはでっち上げの数字の見事な可視化を見せていた。本物の数字を生み出すシステム、つまりSEC提出書類を取得し、実際の10-K開示に照らしてエッジの重みを検証するシステムは最後に来て、4度の書き直しを経た。「本物のデータ」が実際に何を意味するのかを、私は発見し続けたからだ。

データが間違っていれば、UIはどうでもいい。データパイプラインを先につくれ。

仕様ではなく、アーキテクチャをレビューせよ。 レビュアー一人が君のデータモデルと毎日のループに20分かけるほうが、レビュアー三人が数百ページの仕様を読むより多くを見つける。私の場合、三つの独立したレビューが同じ根本的な欠陥に収斂した。複雑なシステムの問いへの答えを、決定論的に計算された答えをただ語らせるだけにすべきところで、私はAIにその答えを計算させようとしていたのだ。20分のレビューが、何週間もの内部反復では決して見つからなかったものを見つけた。

フェーズ4、AIとビルドする(Claude Codeで1〜2週間、なしで4〜6週間)

ここでAIコーディングツールが計算式を変える。単独の開発者にかつて数か月かかったことが、いまや数日で済む。だがこの速度の乗数は、フェーズ1〜3の規律をより重要にする。減じはしない。

理由はこうだ。間違ったものを3か月ではなく3日でつくれるなら、それが間違いだとより速く知る必要がある。プロトタイプ先行のやり方は、ゆっくり慎重に進めることではない。自分のビルド速度に見合うほど速く学ぶことだ。

Claude Codeでのビルド順はこうだ。

鍵となる原則、4日目から毎朝使え。 ビルドと使用を同時にやるのだ。毎朝が、その午後に何をつくるかを明かす。15日目には、プロダクトは想像ではなく、10日以上の実使用によって形づくられている。

Claude Codeがなければこれを4〜6週間に伸ばせ。だが原則は同じだ。中核のループが動いたらすぐに、ほかのすべてが欠けていても、使え。

うまくいくビルドプロンプトのパターン。

200行の仕様をAIに渡して「全部つくれ」と言うな。各ステップに検証をつけて、明確な手順を与えよ。

ステップ1、データモデルをつくる。検証、これら5つのクエリが正しいデータを返す。
ステップ2、APIをつくる。検証、これら3つのcurlコマンドが期待どおりのJSONを返す。
ステップ3、UIをつくる。検証、これらのビジュアルテストが通る。

各ステップには、AI自身が確認できる完了の定義がある。AIは通過したステップごとにコミットし、先へ進む。何かが壊れたとき、その被害範囲は全体のビルドではなく、一つのステップにとどまる。

フェーズ5、最初の本物の一週間(1週間、以降は継続)

毎日使え。テストではなく、使うのだ。各セッションのあとにこう書け。

• かかった時間
• とった行動
• データの品質(見たものを信じられたか)
• やりたかったができなかったこと

一週間後にはこれが分かる。毎日使うもの(残す、磨く)、一度だけ使ったもの(残す、磨かない)、一度も触らなかったもの(削る)、そして足りていないもの(次のスプリント)。

メタなルール

これらを書き留めるのは、私がそのすべてに背いて代償を払ったからだ。

1、仕様より先にプロトタイプ。 2時間のプロトタイプは2日の仕様より多くを教える。仕様は想像したものを捉える。プロトタイプは必要なものを明かす。

2、表示よりデータ。 データが間違っていれば、UIはどうでもいい。それを表示するインターフェースより前に、信頼できるデータを生み出すパイプラインをつくれ。

3、保守より先にブートストラップ。 維持すべき品質あるデータを手にする前に、データ品質を維持するシステムをつくるな。初期データを正しく揃え、手作業か自動のディープリサーチで揃えてから、毎日の手入れを自動化せよ。

4、毎日の使用への最短経路を使え。 プロダクトを使っていない日は、暗闇の中で設計している日だ。

5、想像ではなく経験から機能を削れ。 何が不要かは考えても分からない。プロダクトを1週間使い、一度も触らなかったものに気づくことで分かる。

6、文書ではなく、アーキテクチャをレビューせよ。 致命的な欠陥は、UI仕様ではなく、データモデルと毎日のループに棲んでいる。

7、自分が間違っているところを示せ。 これはプロダクトにもプロセスにも当てはまる。私のビルドで最も価値ある瞬間は、三人のレビュアーが独立に同じアーキテクチャの欠陥を見つけたときだった。私は何日も間違った設計を反復していた。外の目はそれを数分で見つけた。準備が整う前にレビューを求めよ。

タイムライン

0日目(夕方):     Q1/Q2/Q3に答える。詰まったら一晩寝かせる。
1日目(午後):     一回で組み上げるプロトタイプ。1ページ。それなりに本物のデータ。
2〜4日目(朝):    毎日使う。1日15分。観察を3つ書く。
5日目(午後):     1ページのアーキテクチャ文書。データモデル+ループ+順番。
5日目(夕方):     レビュアー一人、20分。「どこが壊れるか。」
6〜8日目:         データパイプラインをつくる。本物のデータ。検証する。
9〜12日目:        毎日のループのUIをつくる。つくりながら毎朝使う。
13〜15日目:       使うものを磨く。使わないものを削る。

15日間。ビルドのフェーズでClaude Codeか同種のAIツールを使う前提だ。なければ6〜15日目を3倍にせよ。フェーズ0〜4のタイムラインは変わらない。あれは思考と使用であって、コーディングではないからだ。

どのステップでも、自分が何をつくっているかが分かっている。ずっと使ってきたからだ。不意打ちはない。書き直しはない。一度も触らない機能についての仕様書もない。

次は何を変えるか

私のツールは今まさにビルドされている。たぶん動くだろう。仕様は敵対的レビューを生き延び、アーキテクチャは健全で、これを書いているあいだもコードは二つの並列ターミナルで実行されている。だが私は、一回の午後でプロトタイプにできたはずのプロダクトの仕様を二日かけて書き、三度のレビューより三度の朝の使用から多くを学んだ。

次のプロジェクトでは、一つのHTMLファイルと一杯のコーヒーから始める。