SaaS開発をPM1人×AIで乗り切る｜1ヶ月で209画面を実装した現実

前回の記事で「挑戦は始まった」と書いてから、ちょうど1ヶ月。

209画面。約800機能。テーブル75本。APIルーター75超。PM1人とAIで、1ヶ月。

これが現在地です。予定通りではありません。予定より前倒しです。

ただし、その代償もあります。今回は成果も課題も隠さない、戦場からの中間報告をお届けします。

1ヶ月の進捗 ― 予定と現実

vol1で示したロードマップと、実際の進行を比較します。

約1ヶ月前倒し。 5月リリース要請に対して、テストフェーズの時間を確保できる見通しが立ちました。

ただし「前倒し＝余裕がある」ではありません。クライアントから「5月リリースを前提にスケジュールを組んでほしい」と言われた時点で、テスト前倒しのトレードオフが発生しています。設計品質を削ってスピードを取った箇所もあります。この点は後述します。

数字で見るAI開発の実態

1ヶ月の開発で積み上がった数字を、そのまま出します。

成果物

開発プロセス

4000ターンという数字は、「AIが1回で完璧なコードを出す」わけではないことを如実に示しています。1機能あたり平均2〜3回の修正サイクルが発生する。指示の精度が高くても、エッジケースやビジネスロジックの微妙なニュアンスで手戻りが起きます。

ただし、この修正サイクルが「AIだからこそ回せる」速度であることも事実です。人間エンジニアに同じ量の修正を依頼したら、コミュニケーションコストだけで数倍の時間がかかります。

vol1の予測を検証する

vol1で「このプロジェクトが失敗するとしたら」と挙げた4つのリスク。1ヶ月後の答えを正直に書きます。

1. 要件の曖昧さ → 的中

「こういう感じで」「変更できるようにしておいて」——この手のリクエストは1ヶ月間、定期的に飛んできました。

序盤はある程度受け入れました。設計段階で柔軟性を持たせることは合理的だからです。しかし、実装フェーズの終盤に入った今、曖昧な要件は断る必要が出てきています。 「変更できるようにしておいて」の裏にある工数を、クライアントに具体的な数字で説明し、優先順位を一緒に決める。この交渉がPMの仕事です。

AIは交渉してくれません。ここは完全に人間の領域です。

2. AIのハルシネーション → 的中

一見正しく見えるが微妙に間違っている実装——これは日常的に発生しました。

対策として実施したのは以下の2つです。

• エージェントスキル分割: 開発用・レビュー用でエージェントの役割を分離し、実装したエージェントとは別の視点でチェック
• ダブルファクトチェック: AIのレビュー結果を人間が再確認する二重チェック体制

効果はありました。が、根本解決には至っていません。 ハルシネーションの発生確率を下げることはできても、ゼロにすることは現時点のAI技術では不可能です。最後の品質保証は、人間の目が必要です。この問題への詳しい対処法はAI活用で痛感した失敗と教訓でも解説しています。

3. コンテキスト管理の限界 → 的中

プロジェクトが大きくなるにつれ、AIに渡す文脈情報の管理は確実に重くなりました。

対処として「Skills分解」を導入しました。プロジェクト全体のコンテキストを一度に渡すのではなく、機能領域ごとにSkillsファイルとして分割し、必要な文脈だけをAIに渡す方式です。

さらに、開発フェーズが変わるたびに（設計→実装→テスト）、Skillsの内容を月1回見直すルールを設けました。古い文脈が残っていると、AIが過去の仕様に基づいた実装をしてしまうためです。

完璧ではありませんが、破綻は防げています。

4. PM自身の体力 → 的中

朝7時から深夜2時。休日なし。1ヶ月間。

これが率直な稼働実態です。経営者だから成立しているだけで、従業員にこの働き方を求めることは不可能ですし、求めるべきでもありません。

体力面での学びは明確です。AI開発は「楽になる」のではなく、「1人で回せる量が増える」だけ。 総労働量が減るわけではありません。むしろ、AIが高速に実装を上げてくるので、レビューと判断のサイクルが途切れません。

GitHub Issue駆動は機能したか

vol1で推したGitHub Issue駆動のワークフロー。1ヶ月の実戦投入で見えたことを報告します。

結論: 基本的には計画通り機能しました。

Issue単位で機能を管理し、Claude Codeに実装を依頼し、レビューしてマージする。このサイクル自体は安定して回りました。

ただし、想定と異なった点が2つあります。

修正サイクルの多さ

1機能あたり2〜3回の修正が必要という実態は、vol1の想定（1〜3回で収束）の上限に近い数字です。結果として4000ターン超。効率が良いかは正直微妙です。

しかし、「効率の良し悪し」ではなく「AIだからこそ回せる量」という視点で見ると、評価は変わります。人間チームで同じ量を同じ速度で修正するのは不可能です。

デグレの発生

ある機能の修正が、別の機能に影響を与えるデグレーション（退行）が発生しました。特に、共通コンポーネントの変更時に顕著です。

AIは「今修正している箇所」には集中しますが、「修正の影響範囲」の把握は人間の指示が必要です。影響範囲の特定と、修正後の横断テストが今後の改善ポイントです。

ドキュメントと実装の乖離

もう1つ見えた課題が、ドキュメント上の数字と実装の数字がズレる問題です。

画面数に至っては、ドキュメント内で237と244が混在し、実装ベースでは209。AIが高速に実装を進める分、ドキュメントの更新が追いつかないのです。

これは「ドキュメントを書く暇がない」のではなく、変更のスピードがドキュメント管理の仕組みを超えているという構造的な問題です。Issue駆動で機能は管理できても、全体像の把握にはドキュメントの鮮度維持が不可欠。ここも今後の改善課題です。

Agent Teamsが変えたもの

このプロジェクトの速度を大きく引き上げた要因が、Agent Teamsです。

Agent Teamsとは、複数のAIエージェントを同時に動かし、並行開発を行う仕組みです。詳しくはClaude Code Agent Teamsの実践ガイドをご覧ください。

並行開発の威力

従来のAI開発は「1つのタスクが終わったら次」の直列処理でした。Agent Teamsでは、以下を並行して進められます。

• フロントエンド: 画面の実装
• バックエンド: APIの実装
• スキーマ設計: テーブル定義とバリデーション

スキーマの変更が自動的にフロント・バックの両方に波及する連携が特に強力でした。人間チームなら「スキーマ変えたのでフロント側もお願いします」という伝達が必要な場面で、AIエージェント間では即座に反映されます。

スキル別エージェント分割

エージェントの役割を明確に分けたことも効きました。

• 開発エージェント: コーディングに専念
• レビューエージェント: セキュリティ・品質チェックに専念

同じAIに「作って、チェックして」を頼むより、役割を分離した方が品質が上がります。人間のチームでも「開発者と別の人がレビューする」のは常識ですが、AIでも同じことが言えます。

Agent Teamsのリリースタイミング

正直に言えば、Agent Teamsのリリースタイミングが重なったこと自体が幸運だった。半年前なら、同じ結果は出せなかったと思います。

「AI丸投げ」と商用開発の決定的な違い

この記事で最も伝えたいことを書きます。

YouTubeやセミナーで「AIでアプリが作れる」「ノーコードで起業できる」という情報が溢れています。嘘ではありません。デモレベルのアプリなら、確かにAIで作れます。

しかし、収益を担う商用システムの開発は、全く別物です。

コーディングだけがAIの守備範囲

この1ヶ月で明確になったのは、AIに委託できるのはコーディングだけということです。

それ以外の全て——要件定義、クライアントとの交渉、設計判断、品質の最終確認、スケジュール管理、リスク判断——は人間がやるしかありません。

「AIでアプリが作れる」は正確には「AIでコードが書ける」です。アプリを作るために必要な工程の中で、コーディングは一部に過ぎません。

言語化レベルが一段階上がる

人間のエンジニアに仕事を頼む場合、ある程度の「察し」が期待できます。「ユーザー一覧画面お願いします」で、経験のあるエンジニアならソート機能やページネーションを当然含めてくれるでしょう。

AIには察しがありません。「ユーザー一覧画面」とだけ言えば、本当にただの一覧が出てきます。

ソート条件、フィルタ項目、ページネーションの仕様、表示カラム、権限による表示制御、空データ時の表示——すべて言語化する必要があります。この「言語化コスト」は、人間→人間のコミュニケーションより確実に高いです。

裏を返せば、言語化能力が低い人がAI開発をやると、品質が著しく下がるということです。

前提として必要な能力

AI開発を成功させるために最低限必要なのは以下です。

• PMスキル: 要件定義、スケジュール管理、リスク管理、ステークホルダー管理
• 設計スキル: データベース設計、API設計、アーキテクチャ設計の経験
• コミュニケーション能力: クライアントとの交渉、要件の曖昧さを解消する質問力
• 解像度の高さ: 「こういう感じ」を実装可能な仕様に落とし込む具体化能力

これらがない状態で「AIにアプリを作らせる」のは、設計図なしで建築業者に家を建てさせるようなものです。建つかもしれませんが、住みたい家にはなりません。

FDE的な動き方

私がこのプロジェクトで実践しているのは、Palantirの**FDE（Forward Deployed Engineer）**的な動き方です。クライアントの現場に入り込み、ビジネスの文脈を理解した上で技術を適用する。

AIは強力なツールですが、ビジネスの文脈を理解しているのは人間だけです。現場を知らずにAIにコードを書かせても、ビジネス価値のあるシステムにはなりません。

ここまでの学びと今後

設計品質のトレードオフは避けられない

前倒し進行の代償として、設計の完成度を妥協した箇所があります。特に、将来の拡張性よりも現在の要件充足を優先した判断が複数あります。

これは「間違い」ではなく「トレードオフ」です。納期というビジネス制約の中で、どこまで設計品質を保つかの判断がPMの仕事です。

AI開発の工数 ≒ 通常開発の工数

「AIを使えば工数が減る」と思われがちですが、実感は異なります。

AI開発の総工数は、通常開発とほぼ同等です。ただし、その工数を「AIが吸収する」ことで、人間1人でも回せるようになる。工数が消えるのではなく、担い手が変わるのです。

人間チーム5人×3ヶ月の工数を、人間1人+AI×3ヶ月で処理している——イメージとしてはこちらが正確です。

短期集中型のルール設計

3ヶ月という短期プロジェクトでは、開発ルールも短期集中型に最適化する必要があります。

• コーディング規約は最初に厳密に定義し、途中変更しない
• Issueテンプレートを標準化し、記載漏れを防ぐ
• スプリント単位ではなく、日次で進捗を確認する
• 「完璧」より「動く」を優先し、テストフェーズで品質を担保する

4月以降の展望

4月からテストフェーズに突入します。ここからが本当の勝負です。

• 結合テスト: 209画面×800機能の横断テスト
• パフォーマンス検証: 本番環境（AWS）での負荷テスト
• セキュリティ検証: 認証・認可・入力バリデーションの最終確認
• バグ修正: デグレを含む不具合の洗い出しと修正

開発フェーズの速さが、テストフェーズの品質に直結するのか、それとも速さの代償としてテストフェーズが長引くのか。この答えはvol3でお伝えします。

まとめ：戦場からの中間報告

vol1で「挑戦は始まった」と書きました。1ヶ月後の現在地は「戦場の真っ只中」です。

数字だけ見れば順調です。209画面・約800機能・テーブル75本を1ヶ月で実装し、予定より前倒しで進行しています。

しかし、その裏には朝7時から深夜2時までの稼働、デグレとの戦い、設計品質のトレードオフ、そして「AIは魔法ではない」という現実があります。

AIはコーディングを吸収してくれる。だが、人間の解像度・判断・体力が全てを決める。

これが1ヶ月の戦場で得た、最も正直な結論です。

次回vol3では、テストフェーズの実態と5月リリースに向けた最終局面をお届けする予定です。設計品質のトレードオフがテストフェーズでどう跳ね返ってくるのか——正直に報告し続けます。

---

PMBOK-AIの基本概念についてはPMBOK-AIとはを、AI社員の実績データはAI社員の実稼働データはこちらをご覧ください。Agent Teamsの詳しい活用法はClaude Code Agent Teamsの実践ガイドで解説しています。

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