個人でSaaSプロダクトを作ろうとしているエンジニアや、副業・週末開発でMVP（実用最小限の製品）を検証したい方に向けて、AIコーディングツールを使った開発の分業設計を整理します。
2026年4月から5か月間、週4回・1回3〜4時間という限られた時間で、Cursor（AIコーディング機能を統合したエディタ）の月額20ドルのプランのみを使い、SaaS「RetroPoint」をMVPから本番リリースまで一人で運用した事例があります。500以上のコミット、61の開発フェーズ、7つのモジュールが本番稼働に至ったという規模感は、個人開発の時間対効果を考えるうえで具体的な参考値になります。
何が注目に値するか
注目すべきは開発速度そのものより、なぜその速度が出せたかという設計の部分です。
この事例では、デザインだけは2022年に外部デザイナーへ発注済みでした。レトロスペクティブ（振り返り会議）モジュールの画面が先にあり、そこから視覚言語（配色やコンポーネントの使い方といったデザインの一貫したルール）を抽出。Claude Design（Anthropicが提供するデザイン生成支援機能）と複数のAIモデルを使い、残り6モジュールへ同じ視覚言語を展開しています。
つまり「ゼロから一人で全部作った」のではなく、既存の設計資産をAIに引き継がせて量産した、という構造です。個人開発でAIツールを使う際、最初に何を人間が固め、何をAIに横展開させるかという分業設計が、速度を左右する要因になっていることが読み取れます。
技術的な仕組みを段階的に見る
なぜ既存ツールを組み合わせず自作したのか
開発の動機は「バラバラな業務ツールの統合」でした。
レトロスペクティブ、Planning Poker（見積もり手法の一種）、OKR（目標管理フレームワーク）、1on1、人事評価など、チーム運営に必要な機能はそれぞれ専用ツールが存在します。しかし各ツールの結果を横断的につなぐ手段がなく、チームリーダーが手作業で文脈をつなぎ直す負担が課題でした。
さらにツール提供元の料金体系やアクセス条件が変わるリスクもあり、蓄積した会議履歴を失いかねない状況もあったといいます。これは日本のチームでも起こりうる話で、SaaSベンダーの価格改定や仕様変更で、議事録や振り返りの蓄積が事実上ロックインされる懸念は珍しくありません。
モジュール設計とAIアシスタントの権限範囲
本番稼働している7モジュールは、レトロスペクティブ（19種のフレームワーク内蔵）、Planning Poker、OKR、1on1、人事評価、通常会議、休暇・誕生日カレンダーです。
設計上の工夫として、未接続のモジュールはメニューに表示されません。使わない機能でUIが煩雑にならない設計です。また参加者は招待リンクからアカウント登録なしでボードに参加でき、主催者のみアカウントが必要という非対称な認証設計になっています。
AIアシスタントの役割も明確に制限されています。議題の整理、要約作成、次のアクション案の提示までは自動化しますが、実際の適用（担当者への割り当てやタスク化）は人間の承認を経てから実行されます。AIエージェントに何を任せ、何を人間の確認ゲートに残すかという設計判断は、業務系SaaSでAI機能を組み込む際の共通課題であり、この線引きは参考になる基準です。
技術スタックと関連技術との比較
採用スタックはバックエンドがPython 3.12とFastAPI（非同期処理に強いWebフレームワーク）、データ層はPostgreSQL 16をSQLAlchemy 2.0とAlembic（マイグレーション管理ツール）で操作しています。
レイヤー構成はapi・service・repository・adaptersという一般的な4層構造で、特別な独自アーキテクチャではありません。リアルタイム更新はWebSocketではなくSSE（Server-Sent Events、サーバーからの一方向ストリーミング）を採用しており、ボード更新のような「サーバーから通知するだけで十分な用途」であればSSEの実装コストの低さが選ばれた理由と推測できます。
フロントエンドはReact 18とTypeScript、ビルドはVite。ドラッグ&ドロップはdnd-kit、リッチテキストはTipTap、グラフ描画はEChartsです。インフラはDocker Compose、GitLab CI、Ubuntu上のVDS（仮想専用サーバー）とnginxという、個人開発でも運用しやすい構成にまとまっています。
この構成は特別に新しいものではなく、Next.jsやSupabaseを使うモダンな個人開発スタックと比べると、むしろ手堅い選択です。裏を返せば、速度の源泉は技術選定の目新しさではなくAI活用の分業設計にあった、という見方ができます。
読者への影響と今日確認できること
個人開発やスモールチームでAIコーディングツールの活用を検討しているなら、次の点を確認してみると設計の参考になります。
- デザイン資産の有無: 既存のUIデザインやコンポーネントがあれば、Claude DesignのようなAI支援デザイン機能に「この視覚言語を別画面へ展開して」と指示できるか試す価値があります
- AIの権限境界: 自分のプロダクトでAI機能を組み込む場合、「提案まで」か「実行まで」かの境界をどこに引くか、承認フローの設計を先に決めておく
- モジュール単位の段階公開: 機能をモジュール化し、未使用機能をメニューから隠す設計は、個人開発でスコープを絞りながら育てる際に転用しやすい考え方です
- SPAのSEO対応: React Router主体のSPA（シングルページアプリケーション）では検索クローラーが空のdiv要素しか取得できない問題が起きるため、ビルド時のプリレンダリングやSSR（サーバーサイドレンダリング）の要否を早めに検討する
自分のプロジェクトが該当するか判断する材料として、まず「デザインや仕様の一部だけでも固まった資産があるか」を棚卸ししてみるのが出発点になります。資産があれば、それを起点にAIへ横展開を指示する設計を試せますし、資産がなければ、最初の1モジュールを人間主導で丁寧に作り込むフェーズが必要、という判断につながります。
まとめ
個人開発でAIコーディングツールを使う際は、速度そのものより「何を人間が最初に固定するか」の設計が結果を左右します。
- 既存のデザインや仕様の一部資産を、AIモデルへの横展開の起点にできないか棚卸しする
- AIアシスタントに任せる範囲と、人間の承認を必須にする範囲を先に線引きする
- 技術スタックは目新しさより保守しやすさを優先し、SSEやDocker Composeのような手堅い選択肢を検討する
- SPA構成を採る場合は、公開前にSEO面でのプリレンダリング要否を確認する
まずは自分の手元にある「中途半端に終わっている資産」を洗い出すところから始めてみるとよさそうです。