Week:01｜AIと1人でMVP設計を回した最初の1週間

はじめに

2026年1月末、新しいプロダクトの開発をスタートした。
チームメンバーは自分1人と、AIだ。

この記事は、プロジェクトの最初の1週間（Week 01: 1/28〜2/05）で何をやり、何が起き、何を感じたかを俯瞰的にまとめたものだ。技術的な深掘りは後続の記事に譲り、ここでは全体像を伝えることに集中する。

なぜこのプロダクトを始めたか

以前のプロジェクトが一区切りついた後、個人で温めていた構想があった。アイデア自体はずっと頭の中にあったが、1人で開発を回す現実的なイメージが持てずにいた。

転機になったのは、AIツールの進化だ。「1人でもプロダクトの初期設計を高い精度で回せるのではないか」という手応えがあった。プロジェクトとしてスタートできる体制も整い、開発に踏み切った。

最初の1週間でやったこと

時系列ではなく工程単位で振り返る。

要件整理

プロダクト全体の仕様書（spec.md）を作成し、MVP-Aだけでなく将来のMVP-Bも視野に入れた設計方針を固めた。最初から「あとで壊さなくていい構造」を意識した。

画面構成

画面仕様書（screens.md）を作成し、全画面の要素・遷移タイプを定義した。FigmaでワイヤーフレームとプロトタイプもMVP-A全画面分を整備した。

データ設計

Firestoreのデータモデリングを行い、ER図とセキュリティルールまで落とし込んだ。Item/Chapter分離設計やfan-outタイムライン設計など、スケーラビリティを考慮した構成にしている。

開発環境構築

Figma MCPの連携、トークン管理、課題管理の仕組みを構築した。Claude CodeとFigmaをつなぎ、仕様とデザインを横断的に扱える環境を整えた。

AIを使った仕様レビュー

spec.md、screens.md、er-diagram.md、firestore-rules.md、Figmaの5つの資料を横断的に突き合わせ、矛盾や漏れがないかをAIでレビューした。Claude Codeだけでなく、ChatGPTにも細かい処理のレビューを依頼し、AI間でのキャッチボールで仕様精度を上げた。

想定外だったこと

データ設計に想像以上の時間を使った

1週間のうち半分はデータモデリングに費やした。一度に作り上げるのではなく、画面間の操作イメージを膨らませながらデータ構成を反芻し続けた。アプリのコンセプトをAIに理解してもらい、ケーススタディや画面間の振る舞いから構成を検討するプロセスは、想像以上に密度が高かった。

ただ、この時間は無駄ではなかった。結果として、MVP-Aだけでなく将来の拡張にも耐えうる汎用的なデータ構造ができた。

MCPなどツール周りの制約

Figma MCPは「Claude CodeからFigmaの情報がすべて読み書きできる」と思っていたが、実際にはかなり制約があった。プロトタイプ情報は読み取れず、ワイヤーフレームの直接作成もできない。結局、SVGファイルをClaude Codeで生成してFigmaにドラッグ&ドロップする方法を取った。

事前に制約を調べてから着手すべきだったのは反省点だが、MCPでできること・できないことが明確になったのは収穫だった。

AIを"設計相棒"として使うようになった

当初はAIを「実装を補助してくれるツール」として捉えていた。しかし実際に使い始めると、仕様の矛盾を指摘してくれたり、データ設計の代替案を提示してくれたり、複数ドキュメントの整合性を横断チェックしてくれたりと、"設計パートナー"としての役割の方が大きかった。

以前ベトナムのオフショア開発でPMをやった経験があるが、手戻りが多く求める成果物が満足にできず、やり取りだけが膨らんで大変だった。AIとの協業はスピードも成果物のクオリティも段違いだった。

今の率直な所感

初期設計は思った以上に重要だった。 1人開発だからこそ、最初にドキュメントを整備し、AIと一緒にレビューを回す意味がある。後から「あの設計どうだったっけ」と迷わないための投資だ。

1人開発だからこそ、ログを残す意味がある。 チームなら会話の中で共有される文脈も、1人だと消えていく。週次ログを書くことで、意思決定の背景を自分自身に対して残している。そしてこのログがあるから、こうして記事にも起こせる。

再現性の手応えがある。 正直、1週間でここまでできたことに驚いている。仕様書、画面仕様、ER図、セキュリティルール、ワイヤーフレーム、プロトタイプ。チームで取り組んでいたらこの半分もできなかったであろう物量だ。まだ始まったばかりだが、「AIと1人で回すプロダクト開発」は再現可能な手法になり得ると感じている。