AI時代のいまさらPDCAサイクルが最強だった話

「PDCAサイクル」と聞いて、心が躍る人はあまりいないと思います。研修資料の最初のページに出てくる、あの図。Plan、Do、Check、Action。正直に言えば、私自身も30年のIT人生の中で「PDCAを回しましょう」という言葉を、何百回も聞き流してきました。

ところが、です。AIエージェントによるシステム開発にこの「いまさら感のある」PDCAサイクルを本気で組み込んでみたところ、開発スピードと品質が同時に跳ね上がるという、教科書どおりすぎて拍子抜けする結果になりました。本記事では、私が運用しているSaaS開発フレームワークの紹介と、それをPDCAで進化させた仕組み、そして仮想プロジェクトを題材にした「AIが品質を蒸留していく様子」のドキュメンタリーをお届けします。

1. 土台となるSaaS開発フレームワーク

まず土台の説明をさせてください。私は普段、Claude Code上に構築した自作の「SaaS開発フレームワーク」でシステム開発をしています。一言でいえば、コンピュータの中に仮想のシステム開発会社を作る仕組みです。実案件であるkupo-radar.jp（クポ活レーダー）の開発記事でも紹介しましたが、改めて骨格だけまとめます。

1.1 28エージェント＋14 Skill の組織構成

ユーザー（私）はAIのproject-manager（PM）とだけ会話します。PMが意図を解釈し、必要な専門エージェントを起動し、結果を要約して報告する「PMゲートウェイ・アーキテクチャ」です。開発はウォーターフォール型のSDLC 14フェーズで進み、要件定義からE2Eテスト、トレーサビリティ監査までがほぼ自動で連結されます。

1.2 従来の仕組み：レビューは「一発勝負」だった

このフレームワークにはもともと、各作業フェーズの直後にレビューフェーズが配置されていました。要件定義の後に要件レビュー、外部設計の後に外部設計レビュー、という具合です。ただし従来のレビューは本質的に「一回きりの関所」でした。レビュアーが指摘を出し、作成者が直し、PMが「直りました」と判断したら次へ進む。この「直りました」の判断が、実は曖昧だったのです。

人間の組織でもよくある話ですが、指摘事項を「対応した」ことと、成果物の品質が「基準に達した」ことは別物です。指摘への対応が新たな矛盾を生むこともあれば、レビュアーが一周目で見落とした問題が直しの過程で顕在化することもあります。一発勝負のレビューはそれを捕まえられません。

2. PDCAサイクルをゲートに組み込む

2.1 なぜ「いまさら」PDCAなのか

PDCAサイクルが製造業の品質管理（デミング・サイクル）から生まれた手法であることは有名です。そして「PDCAはもう古い、これからはOODAだ、アジャイルだ」という言説も、ここ10年で何度も聞きました。私もそう思っていた側です。

しかしPDCAが現場で機能しなかった理由を冷静に分解すると、手法自体の欠陥ではなく「人間が回すにはコストが高すぎた」ことに尽きます。

• Checkが形骸化する — 自分の成果物を客観的に採点できる人は稀で、第三者レビューは日程調整だけで数日かかる
• Actionが心理的に重い — 一度「完成」と言ったものを作り直すのは、人間にとって苦痛でしかない
• ループの時間コストが高い — 2周目、3周目を回す工数は、たいてい予算に入っていない

AIエージェントは、この3つの制約をすべて無効化します。レビュアーは数分で起動でき、何度ダメ出しされても機嫌を損ねず、3周目のループも限界費用はAPI利用料だけ。PDCAを回すコストがほぼゼロになった瞬間、PDCAは教科書に書いてあるとおりの威力を発揮し始めたのです。

2.2 フェーズ内PDCAループとゲートの設計

進化版フレームワークでは、要件定義・設計（外部/内部）・テスト計画・実装・テストの各フェーズの内部に、次のPDCAループを設けました。

そして肝心のゲートルールはこれだけです。

3周での人間エスカレーションは無限ループ防止であると同時に、「AIだけでは決められない問題が潜んでいる」ことを検知するセンサーでもあります。経験上、3周で収束しないのはたいてい要件そのものに矛盾があるケースで、これは人間が決めるべき事項です。

重要なのは、ループの履歴（採点の推移、指摘と対応の記録）がすべてdocs/配下にPDCAログとして残ることです。後続フェーズのエージェントはこのログを参照できるため、「設計フェーズで2回指摘された高齢者向けUI要件」のような文脈が、実装やテストにそのまま引き継がれます。

3. ドキュメンタリー：仮想プロジェクト「まわらんばん」

ここからが本題です。この仕組みが実際にどう動くのか、仮想プロジェクトを題材にドキュメンタリー風に追ってみます。題材は町内会の回覧板をデジタル化するSaaS「まわらんばん」。高齢者も使えること、班長さんの負担軽減、自治会単位の低額課金、という「言うは易し」の典型のような案件です。

3.0 シーン0：オーナーが入力したのは、たったこれだけ

ある晩、私がClaude Codeに入力したプロンプトはこれだけでした。

これを受けたPMは、Phase 1（要件定義）のPDCAループを開始します。以降、私は基本的に報告を受け取るだけです。

3.1 シーン1：要件定義 — 1周目74点からの巻き返し

Plan。まずrequirements-architectとrequirements-reviewerが、評価基準を先に合意します。ここが従来との最大の違いです。「何を持って要件定義の合格とするか」を、書き始める前に決めるのです。

【Phase 1 評価マトリクス（合意済み）】
- 完全性（30点）: ペルソナ全員の利用シーンが網羅されているか
- 整合性（20点）: 要件同士・料金モデルと機能の矛盾がないか
- 実現可能性（20点）: 技術スタック（Tier A: Vercel+Supabase）で実装可能か
- 測定可能性（15点）: 各要件が受入条件の形で書かれているか
- 運用現実性（15点）: 紙併用・引き継ぎなど現実の運用に耐えるか
合格ライン: 90点 / Critical指摘ゼロ

Do。requirements-architectが要件定義書v0.1を作成。機能要件23項目、非機能要件8項目。ここまで約12分。

Check。requirements-reviewerの採点結果が返ってきます。

Action。ここでPMが面白い動きをします。指摘のうち自力で解決できるもの（アクセシビリティ基準はWCAG 2.1 AA準拠を採用して数値化する、など）は即座に修正計画に落とす一方、AIが勝手に決めてはいけないことを3つの質問として私に返してきたのです。

私が「全部OK。代理既読はいいアイデア」と返すと、2周目のDo→Checkが回り、92点・Critical 0件。ゲート通過です。1周目で出た「曖昧さ」が、具体的な数値基準と運用ルールに置き換わっていく様子は、まさに蒸留の1回目という感じでした。

3.2 シーン2：外部設計 — 86点で止めない、という思想

設計フェーズで印象的だったのは2周目です。external-designerが画面設計とAPI設計を作り、1周目のCheckは68点。「高齢者向け」と言いながらコントラスト比4.5:1未達の配色が3画面、タップ領域44px未満のボタンが7箇所、という手厳しい指摘でした。要件定義でWCAG基準を数値化していたからこそ、レビュアーは機械的に検証できたわけです。

Actionを経て2周目は86点。人間のプロジェクトなら「もう十分でしょ、進めよう」となる点数です。私も正直「86点なら…」と思いました。しかしゲートは通しません。残っていた指摘はこうです。

3周目で93点。後から振り返ると、この「班長の月中交代」は実装後に発覚していたら設計からやり直しになっていた類いの問題です。86点で妥協していたら、と思うとゾッとします。閾値を「だいたい良さそう」という人間の感覚ではなく、固定の数値ゲートにしておくことの価値はここにあります。

3.3 シーン3：テスト計画 — 異常系は「現実」から湧いてくる

test-plannerが作ったテスト計画の1周目は81点。指摘の中心は異常系の薄さでした。

3つ目の指摘に注目してください。レビュアーは前フェーズのPDCAログを読み、「設計で揉めた箇所＝リスクの高い箇所」としてテストの厚みを要求しているのです。ループの履歴が品質情報として後続に流れる。この連鎖が、フェーズ間の知識の断絶を防ぎます。2周目93点で通過。

3.4 シーン4：実装 — CheckはレビュアーAIだけじゃない

実装フェーズ（Phase 11）のPDCAは少し毛色が違います。Checkの主役が、レビューエージェントに加えて機械的な検証になるからです。implementation-workerがタスクを自動分割して実装し、testerが並走でユニットテストを書く。Checkでは次が全部走ります。

【Phase 11 Check の構成】
1. 機械検証: tsc --noEmit / eslint / ユニットテスト＋カバレッジ80%以上
2. implementation-reviewer: 設計書との突合・セキュリティ観点レビュー（採点）
3. PDCAログ突合: 設計・テスト計画で指摘された箇所の実装漏れチェック

1周目のCheckは、型エラー2件とカバレッジ73%で機械検証の段階で差し戻し。採点以前の問題です。2周目でレビュアー採点87点——惜しくも不合格。指摘は「代理既読のAPIに、班長以外が叩けてしまう認可漏れ」という、まさにCriticalな1件でした。3周目で95点・Critical 0件、通過。

ここで強調したいのは、認可漏れを見つけたのが「実装の3日後」ではなく「実装の40分後」だったことです。ループが速いということは、欠陥の発見が新鮮なうちに行われるということでもあります。

3.5 シーン5：テスト — 実ブラウザE2Eとトレーサビリティの最終蒸留

最後はE2Eテスト（Phase 12）と要件トレーサビリティ監査（Phase 13）です。e2e-usecase-testerがPlaywrightで実ブラウザを操作し、「自治会の新規登録 → 班の設定 → 回覧の作成 → 既読 → 班長交代 → 退会とCSVエクスポート」までのユースケースを通します。

仕上げのrequirement-traceability-auditorのCheckで、こんな指摘が出ました。

要件定義のPDCAループの中で「後から追加された要件」が、最終フェーズの監査で拾われる。各フェーズのループだけでなく、フェーズを跨いだ大きなループ（要件 ⇄ テスト）が閉じていることを確認して、ようやく全ゲート通過です。

4. 品質はどう担保されたのか：数字で振り返る

「まわらんばん」の全フェーズのループ実績をまとめると、こうなります。

注目してほしいのは、太字にした2つの欠陥です。「班長の月中交代」と「代理既読の認可漏れ」。前者は出荷後ならクレームと手戻り、後者はセキュリティインシデントに直結します。どちらも一発勝負のレビューでは1周目に出てこなかった指摘でした。2周目以降のレビューは、修正された成果物を「前回と違う角度」から見るため、初回に埋もれていた問題が浮かび上がってくるのです。

これが私が「蒸留」と呼んでいる現象です。1回のレビューは粗いろ過にすぎません。しかしループのたびに不純物（曖昧さ、矛盾、漏れ）が取り除かれ、濃度の高い成果物だけが次のフェーズに流れていく。そして各フェーズのゲートが90点を保証しているため、後工程は前工程の品質を疑うコストを払わなくてよい。ウォーターフォールの最大の弱点である「後戻りの高コスト」を、フェーズ内ループが先回りして潰してくれるわけです。

5. で、スピードはどうなのか

「そんなに何周もして、遅くならないのか」と思われるかもしれません。実感は逆です。

• 1周のループは数分〜数十分で回る。人間のレビュー会議のような日程調整が存在しない
• ループは私が寝ている間も回る。私が払うコストは、朝に報告を読んで判断を返すことだけ
• 手戻りが「フェーズ内の小さなループ」に閉じ込められるため、「実装後に設計からやり直し」という最悪の時間泥棒が消える

「まわらんばん」規模（機能要件23項目）の場合、要件定義からE2E完了までの実時間は2日強。私が費やした正味の時間は、判断と報告確認で合計1時間程度です。品質を上げるためにループを増やしたのに、トータルの開発期間はむしろ短くなる。PDCAの教科書には昔からそう書いてあったのですが、回すコストがゼロに近づいて初めて、それが本当だったと体感できました。

6. 運用して分かった注意点

良いことばかり書いてきたので、ハマりどころも正直に書いておきます。

6.1 評価基準を先に固めないと、点数がインフレする

Planで評価マトリクスを合意せずにCheckさせると、レビュアーAIは「全体的によく書けています、88点」のような雰囲気採点をしがちです。観点と配点を先に固定し、「観点ごとに減点理由を列挙してから合計せよ」と縛ることで、採点が安定します。

6.2 ループ上限とエスカレーションは必須

閾値だけ設定してループ上限を設けないと、要件そのものに矛盾がある場合に「修正→別の指摘→修正→最初の指摘が再発」という振動が起きます。3周で人間に上げるルールは、コスト管理ではなく問題の種類を仕分けるための仕組みとして機能しています。

6.3 レビュアーと作成者は必ず別エージェントにする

同じエージェントに「作って、自己評価して」とやらせると、採点は確実に甘くなります。レビュー系エージェントを読み取り専用ツールに制限して独立させているのは、このためです。人間の組織で「自己レビューだけで出荷しない」のと同じ原則が、AIにもそのまま当てはまります。

7. まとめ：古い手法×新しい実行環境

PDCAサイクルは、何も新しくありません。70年前からある品質管理の基本です。しかし「Checkを他者が定量的に行い、納得いくまでActionを回す」という教科書どおりの運用は、人間のコスト構造では実現できませんでした。だから形骸化し、「古い」と言われるようになった。

AIエージェントは、その実行コストをほぼゼロにしました。変わったのは手法ではなく実行環境です。枯れた方法論ほど、AIという新しい実行環境の上で本来の設計性能を発揮する——これが今回の一番の学びです。ウォーターフォールしかり、PDCAしかり。「いまさら」と笑われてきた教科書たちを、AI時代にもう一度開き直す価値は十分にあると思います。

このフレームワークの実案件への適用例は、kupo-radar.jp開発ノウハウの記事で詳しく紹介しています。「自社の開発プロセスにも品質ゲート付きのAI開発を導入できないか」といったご相談は、下記の無料相談からお気軽にどうぞ。