SaaS開発をAIと2人で乗り切る方法｜RFPから発注、設計開始までの実話

マレーシア向けのコンテンツサービスSaaS。設計はこれから。仕様の詳細もこれから。そして納期は5月末。

普通の開発会社なら、この条件で受けない。いや、提案すらしない。

しかし私は受けた。PM1人と、AI社員（Claude Code）で。

この記事では、1年間の延期を経て発注に至るまでのリアルな経緯と、PM+AIの2人体制でSaaS開発に挑むための具体的な方法論を、包み隠さず公開します。

1年間の延期 ― RFPから発注までの実話

このプロジェクトは、2025年3月にRFP（提案依頼書）に回答したところから始まります。

約1年間、延期され続けました。

延期の理由はクライアント側の事情です。予算の調整、社内の意思決定、関係者の合意形成。大きな組織で新しいサービスを立ち上げるには、それだけの時間がかかります。

正直、「この案件は流れたかもしれない」と何度も思いました。しかし、クライアントの熱意は本物でした。1年かけてでも社内を通してきた。その覚悟に応える責任があります。

受託開発のリアル：「待つ」という仕事

RFPに回答してから発注まで1年。この間、何もしていなかったわけではありません。

• 3ヶ月に1回のペースでクライアントと状況確認
• 技術スタックの検討と最新化（待っている間にNext.jsのバージョンが上がった）
• 類似案件の知見を蓄積

受託開発において「待つ」ことは日常です。しかし、待っている間に次の案件を動かせるかどうかが、1人PMの生存戦略を分けます。私の場合、この待機期間中も複数案件を同時に進行していました。

無謀な納期 ― 4ヶ月が3ヶ月に

クライアントの最初の要望は3月ローンチ。2月に発注して3月に完成――さすがに不可能です。

私は6月末完成の線表を提案しました。そこそこの規模のSaaSを、設計からスタートして4ヶ月で完成させる。これでも相当攻めたスケジュールです。

そして「5月末をターゲットにしてほしい」と言われました。

4ヶ月が3ヶ月になった。しかも、設計はこれから。わかる人が見たら、無謀としか思わないでしょう。

なぜ「人を増やさない」のか ― 勝機の根拠

無謀に見えるこのプロジェクトに勝機を感じている理由は明確です。

1. コミュニケーションコストの排除

人を増やせば、仕様の共有、設計の伝達、コードレビュー、進捗確認――コミュニケーションコストが指数関数的に増えます。ブルックスの法則（人月の神話）が示す通り、短期プロジェクトへの人員追加は逆効果になりがちです。

AI社員なら、私が全体を理解し、指示を出すだけでいい。認識のズレも伝達ミスもありません。

2. 設計の一貫性

SaaSの品質は、設計の一貫性で決まります。複数のエンジニアが並行開発すると、どうしても設計思想がブレます。

私がすべての仕様と構造を理解し、AIに実装を任せる。設計の一貫性は、1人が全体を見ているからこそ保てます。

3. イテレーション速度

設計書を渡せば、実装は数時間で上がってくる。修正も即座にできる。人間チームでは「レビュアーの空き待ち」だけで半日〜1日かかる工程が、ゼロになります。

コスト面の現実

人間エンジニアの外注費は月30〜60万円（スキル・地域により変動）。3人体制なら月90〜180万円。一方、Claude CodeのAPI費用は月数万円〜十数万円程度です。コスト差は歴然ですが、これは「安かろう悪かろう」ではなく、構造的な効率差です。

GitHub Issue駆動のAI開発フロー ― この記事の核心

ここからが、この記事で最も伝えたい内容です。PM+AI体制でSaaS開発を回すための具体的なワークフローを、詳細に解説します。

全体像

機能定義 → Issue作成 → AI実装 → レビュー → テスト → マージ
  (人間)    (人間)      (AI)     (人間)    (人間+AI)  (人間)

Step 1: 機能をIssueに分解する（人間の仕事）

プロジェクトの全機能を、**1 Issue = 1機能（または1画面）**の粒度でGitHub Issueに分解します。

良いIssueの条件は以下の通りです。

• 目的が明確: 「なぜこの機能が必要か」が書かれている
• 完了条件が具体的: 「何ができたらDoneか」が定義されている
• 制約条件が明記: 使用技術、パフォーマンス要件、セキュリティ要件
• テスト条件が記載: どのテストが通ればOKか

## Issue例：ユーザー認証機能

### 目的
管理者がログインし、権限に基づいたコンテンツ管理を行えるようにする

### 完了条件
- メールアドレス + パスワードでログインできる
- JWT認証でセッション管理される
- ロール（admin / editor / viewer）で権限が分かれる

### 技術制約
- Next.js App Router + NextAuth.js
- パスワードはbcryptでハッシュ化
- トークン有効期限は24時間

### テスト条件
- 正しい認証情報でログイン成功
- 誤った認証情報でログイン失敗
- トークン期限切れで再認証要求
- ロール別のアクセス制御が機能する

ここが最も重要なポイントです。 Issueの品質がAI出力の品質を決めます。曖昧なIssueからは曖昧な実装しか生まれません。

Step 2: Claude Codeに実装を依頼する（AIの仕事）

Issueの内容をベースに、Claude Codeに実装を依頼します。ここでのコツは3つあります。

1. Issueのリンクをそのまま渡す: 口頭で説明し直さない。Issueが設計書の役割を果たす
2. 既存コードのコンテキストを与える: プロジェクトの構成やコーディング規約を事前に設定
3. テストも同時に書かせる: 「テストなしの実装は受け取らない」をルールにする

Step 3: レビューとフィードバック（人間の仕事）

AIの出力を100%信頼してはいけません。必ずレビューします。

チェックポイントは以下の通りです。

• 設計意図との整合性: 仕様を満たしているか、過不足ないか
• セキュリティ: 入力バリデーション、認証チェック、SQLインジェクション対策
• エッジケース: AIが考慮していない境界条件がないか
• 可読性: 他の開発者（将来の自分含む）が理解できるコードか

問題があればフィードバックし、AIに修正させます。このサイクルは通常1〜3回で収束します。

Step 4: テスト確認とマージ（人間 + AI）

テストが全て通ることを確認し、mainブランチにマージします。CIパイプラインでの自動テストも併用します。

このフローの本質

このフローの核心は、人間がWhat（何を作るか）とWhy（なぜ作るか）に集中し、AIがHow（どう作るか）を担当するという分業にあります。

PMの仕事は「正しいものを定義すること」に集約され、「正しく作ること」はAIが担う。この分業が機能するからこそ、1人+AIでSaaS開発が成立するのです。

人間とAIの役割分担

改めて整理します。

人間（PM）が担当すること

• 要件定義・仕様確定
• テーブル設計・データ構造の設計
• 全体のアーキテクチャ設計
• クライアントとのコミュニケーション
• 品質の最終判断
• プロジェクト全体のコントロール

AI（Claude Code）が担当すること

• 詳細設計書の作成支援
• コーディング・実装
• テストコードの生成
• コードレビュー（セキュリティチェック含む）
• ドキュメント生成

AI社員の具体的な稼働実績についてはAI社員の実稼働データはこちらをご参照ください。

3ヶ月のロードマップ

現時点で想定しているロードマップです。

2月〜3月：設計フェーズ

• 要件の最終確定
• テーブル設計
• アーキテクチャ設計
• 主要機能の詳細設計
• プロトタイプの構築

3月〜4月：コア機能開発

• 認証・ユーザー管理
• コンテンツ管理の中核機能
• 管理画面の基本構築

4月〜5月：機能拡充とテスト

• 残りの機能実装
• 結合テスト
• パフォーマンス改善
• バグ修正・品質向上

5月末：納品

正直、このスケジュールは一切の余裕がありません。 設計が遅れれば開発が遅れ、開発が遅れればテストが削られる。ドミノのようにすべてが連鎖します。

だからこそ、設計フェーズの品質が全てを決めます。 ここで手を抜けば、後半で確実に崩壊します。

AIだけでは越えられない壁

楽観的なことばかり書いてきましたが、正直に書きます。

このプロジェクトが失敗するとしたら、以下の理由です。

• 要件の曖昧さ: クライアントの「こういう感じで」が、実装可能な仕様に落とし込めない
• AIのハルシネーション: 一見正しく見えるが、ビジネスロジックが微妙に間違っている実装を見逃す
• コンテキスト管理の限界: プロジェクトが大きくなるにつれ、AIに渡すべき文脈情報の管理が破綻する
• PM自身の体力: 1人で全工程を見るのは、精神的にも体力的にもハードである

特に3番目は深刻です。AIは人間と違い、「先月の打ち合わせで決まったこと」を自動的には覚えていません。PMBOK-AIのドキュメント管理プラクティスで対処しますが、プロジェクト規模が大きくなるほどこの課題は重くなります。

現在進行中のプロジェクトから得た学び

このプロジェクトはまだ始まったばかりですが、設計フェーズに入った時点で既にいくつかの学びがあります。

1. Issueの書き方で実装品質の8割が決まる: 雑なIssueからは雑なコードしか出てこない。Issue作成に時間をかけることは、結果的に開発速度を上げる
2. AIへの「丸投げ」は必ず失敗する: 「認証機能作って」ではなく、技術選定・制約条件・テスト条件まで定義して初めてまともな出力が得られる
3. 設計判断は人間がやるべき: テーブル設計やAPI設計をAIに任せると、一見合理的だが長期的に破綻する構造になりがち。ここは人間の経験が必要

これらの学びは、プロジェクトの進行とともに更新していく予定です。

このプロジェクトで証明したいこと

このプロジェクトは、単なる受託開発ではありません。

PMBOK-AIが、実際の商用プロジェクトで通用するかどうかの実証です。

• PM1人 + AIで、SaaS規模のシステムを本当に作れるのか
• 3ヶ月という短納期を、AIの力で乗り切れるのか
• 品質を保ちながら、速度を出せるのか

成功すれば、PMBOK-AIの有効性を実績で証明できます。失敗すれば、その失敗も含めて報告します。隠すことに価値はありません。

まとめ：挑戦は始まった

1年間待った案件が、ついに動き出しました。

設計未確定。5月末納期。PM1人。武器はAI。

GitHub Issue駆動の開発フローで、この無謀なスケジュールに立ち向かいます。このプロジェクトの進捗は、今後もブログで報告していきます。

PMBOK-AIの基本概念についてはPMBOK-AIとはを、AI社員の実績データはAI社員の実稼働データはこちらをご覧ください。AI開発での失敗と教訓はAI活用で痛感した失敗と教訓で解説しています。

プロジェクトマネジメントやAI開発についてのご相談はお問い合わせからお気軽にどうぞ。