生成AIやAIエージェントを使えば、要件をもとに設計書を作成し、その設計書からプログラムやテストコードまで生成できるようになってきました。

ここで疑問になるのが、「AIが直接コードを書けるなら、これまでのような設計書は必要なのか」という点です。

結論から言えば、AI駆動開発でも設計情報は必要です。

ただし、設計書の役割は変わります。

人間の開発者へ実装方法を伝えるためだけではなく、AIが何を前提として次の成果物を作るのかを決める基準として、設計情報を管理する必要があります。

そのためPM・PLが考えるべきなのは、「設計書をAIに書かせる方法」だけではありません。

どの情報から何を作り、その成果物を次の何に利用するのか。設計内容が正しいことを誰が確認するのか。AIによる設計・レビューの精度をどう改善していくのか。

AI駆動開発では、こうした設計情報全体の流れと品質を管理することが重要になります。

AI駆動開発でも設計書が不要になるわけではない

AIを使った開発では、「要件をAIへ渡せば、そのままコードを作れるのではないか」と考えることがあります。

小規模な試作であれば、それでも動くものを作れる場合があります。

しかし、複数の画面やAPI、バッチ、データベース、外部システムなどが関係する業務システムでは、機能ごとにAIへ個別指示を出すだけでは、システム全体の統一性を保つことが難しくなります。

例えば、認証方式、権限管理、エラー処理、ログ出力、データアクセス方法などが機能ごとに異なれば、個々のプログラムは動いていても、システムとしては保守しにくい状態になります。

そのため、AI駆動開発でも設計情報は必要です。

ただし、従来と同じ形式のWordやExcelの設計書を大量に作ることが目的ではありません。

Markdown、設定ファイル、API定義、データモデル、開発ルールなど、AIが参照しやすい形で管理しても構いません。

重要なのは形式ではなく、AIと人間が共通して参照する「正しい設計情報」が存在することです。

AI駆動開発全体のプロジェクト管理については、「AI駆動開発でプロジェクト管理はどう変わる？PMが見直すべき管理ポイント」でも解説しています。

設計書を作る前に「設計情報のグランドデザイン」を作る

AI駆動開発で最初に行いたいのが、個々の設計書を書くことではありません。

まず、プロジェクト全体で必要となる設計成果物と、その情報の流れを整理します。

これを本記事では「設計情報のグランドデザイン」と呼びます。

考えるポイントは単純です。

何をインプットとして、何を作り、その成果物を次の何に利用するのか。

この関係を最初に整理します。

例えば、次のような設計情報の流れが考えられます。

主な入力作成する成果物主な出力次に利用する工程・成果物
要件定義・非機能要件共通設計システム共通ルール各機能の設計
共通設計・機能要件機能設計画面・API・処理仕様プログラム生成
機能設計・データ設計実装プログラム単体・結合テスト
要件・設計書テスト設計テストケーステスト実施
設計標準・各設計書AIレビュー指摘・確認結果設計修正・承認

この関係を整理しておくことで、「この設計書は何のために存在するのか」が明確になります。

反対に、この整理をしないまま「AIに基本設計書を書かせよう」「次は詳細設計書を作らせよう」と進めると、似た情報が複数箇所へ書かれたり、必要な情報がどこにも定義されなかったりします。

AIを使うからこそ、最初に情報構造を設計しておく必要があります。

共通設計を先に決めてから機能設計へ進む

特に重要なのが、各機能に共通する設計ルールを先に決めておくことです。

例えば、画面デザインの基本ルール、入力チェック、エラー処理、ログ出力、認証・認可、APIの作り方、データアクセス、トランザクション制御などです。

これらを各機能の設計時に毎回AIへ考えさせると、機能ごとに異なる方式が採用される可能性があります。

先に共通設計を確立し、

「このプロジェクトでは、このルールに従って機能設計を作成する」

という状態にしてから、AIへ個別機能を設計させます。

PMとして重要なのは、個々の設計書の作成状況だけを見るのではなく、機能設計の基準になる共通設計が十分に整備されているかを確認することです。

AIは上流の誤りも次の成果物へ引き継ぐ

AIを使うと、設計書からコード、設計書からテストケースといった成果物の連鎖を高速化できます。

これは大きなメリットですが、同時に注意すべき点があります。

上流成果物に間違いや不足があれば、その内容も下流成果物へ引き継がれる可能性があることです。

例えば、受注管理システムで、

「一定金額以上の受注は与信確認を行ってから確定する」

という業務ルールがあるとします。

しかし機能設計書から与信確認の処理が抜けていたとします。

AIがその設計書をもとにプログラムを作れば、与信確認を行わない処理を作成する可能性があります。

さらに同じ設計書からテストケースを作れば、与信確認を行わないことを前提としたテストが作られる可能性もあります。

結果として、

設計書
→ プログラム
→ テストケース

の内容はきれいに一致しており、テストも正常終了しているのに、業務システムとしては間違っている、という状態が発生します。

ここで重要なのが、

「成果物間で整合していること」と「内容が正しいこと」は別である

という点です。

AIは与えた設計情報を強い前提として成果物を作ります。また、情報が不足している場合には、もっともらしい内容を推測して補うこともあります。

だからこそ、AIが後工程を高速化するほど、上流成果物の品質が重要になります。

PMは「AIが作ってくれるから設計工程を短縮する」と単純に考えるのではなく、どの成果物を次工程の正として扱うのか、その成果物をどの時点で品質確認するのかを決める必要があります。

設計書レビューはAIと人間で役割を分ける

AI駆動開発では、レビューにもAIを活用できます。

特にAIが活用しやすいのが、複数の文書やルールを比較して整合性を確認する作業です。

一方、すべてをAIレビューだけで済ませるのは適切ではありません。

設計レビューには、大きく分けて「整合性の確認」と「内容の妥当性確認」があります。

レビュー観点AIを活用しやすい人間の確認が重要
要件と設計書の記載漏れ○○
共通設計への準拠○○
項目名・型・桁数の不一致○△
API間の項目不整合○△
命名規則や記載ルール違反○△
業務ルールそのものの正しさ△○
実際の業務運用で成立するか△○
例外業務への対応△○
顧客固有の判断や慣習△○
ユーザーにとって使いやすいか△○

例えば、「要件定義書には項目があるのに画面設計書には存在しない」といった差分は、AIが比較しやすい領域です。

共通設計に「すべての更新処理で監査ログを出力する」と書かれているのに、一部の機能設計で監査ログが定義されていない、といった確認にも向いています。

一方、

「そもそもこの業務ルールで正しいのか」

という判断には、その会社の業務知識が必要です。

これは人間でも、業務知識のない人がレビューすれば見逃します。

そのため「AIか人間か」という単純な分け方ではなく、

何を、誰が、どの観点で確認するのか

をレビュー計画として決める必要があります。

AIレビューそのものも確認する

もう一つ注意したいのが、「AIにレビューさせたから確認済み」と考えないことです。

AIレビューにも見逃しや誤検出があります。

そのため、AIレビュー結果の一部を人間が定期的に確認し、本当に期待した観点でレビューできているかを評価します。

人間レビューでAIが見逃した問題が見つかった場合は、その問題を単に修正して終わらせません。

「なぜAIは検出できなかったのか」

まで確認します。

ここから、次に説明するSkillの改善につなげます。

設計書を作るAIの「Skill」も品質管理する

AI駆動開発では、毎回長いプロンプトを書いて設計書を作るよりも、設計方法やレビュー方法を再利用可能な形にしておくほうが効率的です。

本記事では、このような「AIへ特定の作業を行わせるための指示、手順、ルール、参照資料、テンプレートなどをまとめた仕組み」をSkillと呼びます。

現在のAI開発環境でも、Skillsは特定タスクを繰り返し実行するための再利用可能なワークフローとして利用されています。

しかし、Skillを一度作れば終わりではありません。

設計書を作成するSkillやレビューするSkill自体も、プロジェクトの品質管理対象として扱う必要があります。

Skillの品質が低ければ同じ問題を繰り返す

例えば「画面設計書作成Skill」が、権限設計を確認する手順を持っていなかったとします。

一つの画面で権限の考慮漏れが発生したため、人間が設計書を修正したとしても、Skillを修正しなければ、次の画面でも同じ問題が発生する可能性があります。

従来であれば、担当者へ「次から気をつけてください」と共有していたような内容を、AI駆動開発ではSkillや設計標準へ反映できます。

つまり、

人間が発見した問題をAIの作業ルールへ還元する

ことができます。

ここまで行うことで、AI利用が単なる作業効率化ではなく、プロジェクト全体の品質改善につながります。

Skillは「作って終わり」ではなく改善サイクルを回す

設計・レビューSkillの改善は、次のような流れで行います。

問題を発見する → 原因を分類する → Skillや参照情報を修正する → 過去のケースで再テストする → 実際の成果物で確認する → 新しい問題を再び反映する

例えば、人間レビューで「例外処理の設計漏れ」が何度も見つかったとします。

まず、その原因を確認します。

AIへの指示に例外処理の確認が書かれていないのであれば、設計Skillへ確認手順を追加します。

共通設計自体にルールが存在しないのであれば、Skillではなく共通設計を修正します。

AIがルールを参照しているにもかかわらず正しく適用できていないのであれば、具体例やチェック条件を追加します。

このように、問題の原因によって修正対象を分けることが重要です。

何でもプロンプトへ追記すると、指示だけが肥大化し、管理しにくくなります。

過去の不具合をSkillのテストケースとして残す

Skillの改善で特に有効なのが、過去に発生した問題をテストケースとして残すことです。

例えば、過去に次のような問題があったとします。

「更新画面で権限チェックが抜けていた」

この問題を修正しただけで終わらせず、権限チェックが必要な設計例をSkillの評価ケースとして保存します。

Skillを変更したときには、過去の評価ケースを再度実行します。

新しいルールを追加した結果、以前できていたチェックができなくなることもあるためです。

これはプログラム変更後に回帰テストを行う考え方と同じです。

AIのSkillにも回帰テストを行う

と考えると分かりやすいでしょう。

AIの精度を感覚だけで評価しない

「最近AIの精度が上がった気がする」という感覚だけでは、プロジェクトとして管理できません。

設計生成Skillであれば、例えば人間が修正した件数、設計標準への違反件数、必須項目の漏れ、再作成が必要になった件数などを確認できます。

レビューSkillであれば、人間が発見したのにAIが見逃した問題、AIが指摘したが実際には問題ではなかった項目、同じ種類の問題を継続して検出できているか、といった観点を確認できます。

必ずしも最初から複雑な指標を作る必要はありません。

まずは、

「人間がどこを修正したか」
「AIが何を見逃したか」

を記録するだけでも、改善材料になります。

PMが管理する対象は「成果物」から「生成プロセス」へ広がる

従来のプロジェクトでも、PMは設計書の進捗やレビュー状況を管理してきました。

AI駆動開発でも、それは変わりません。

しかし、管理対象は少し広がります。

例えば、設計書の完成状況だけではなく、次のような状態を確認します。

PMが確認する対象確認する内容
設計情報の構造何を入力として何を作るか明確か
共通設計機能設計前に共通ルールが定義されているか
正となる成果物AIが何を基準として次工程を進めるか明確か
AIレビューどの観点をAIが確認するか決まっているか
人間レビュー業務・妥当性を誰が確認するか決まっているか
Skill誰が管理し、どのバージョンを利用するか明確か
Skill評価見逃しや人間修正を記録しているか
改善発見した問題をSkillや設計標準へ反映しているか

ここまで管理することで、AIが大量の成果物を短時間で作るようになっても、開発プロセスをコントロールしやすくなります。

PM自身がSkillを作成する必要はありません。

しかし、

「現在使っているSkillはどのルールを前提としているのか」
「誰が品質を確認しているのか」
「問題が見つかったとき、どこへフィードバックするのか」

は把握しておく必要があります。

AIを使った開発では、AIも開発プロセスの一部です。

そのため、AIへ仕事をさせる仕組み自体を管理することもプロジェクト管理の一部になると考えるとよいでしょう。

よくある失敗は「AIに作らせること」から始めてしまうこと

AI駆動開発で起こりやすい失敗の一つが、とにかくAIへ成果物を作らせることから始めてしまうことです。

要件定義書を渡して「基本設計書を作ってください」と指示すれば、それらしい設計書は作成できます。

しかし、

その設計書は何を目的としているのか。
どの共通設計に従うのか。
次に何を作るための入力になるのか。
どの項目を人間が確認するのか。

が決まっていなければ、成果物が増えるほど管理が難しくなります。

AIによって文書を作る速度が上がるため、問題に気づいたときには大量の設計書やコードへ同じ誤りが展開されていることも考えられます。

AI駆動開発では、

「まずAIを使う」のではなく、「まずAIが作業できる仕組みを設計する」

ことが重要です。

AI駆動開発の設計管理は5つのステップで始める

実際のプロジェクトへ導入する場合、いきなりすべてを自動化する必要はありません。

まず、設計成果物の関係を整理します。どの情報から何を作り、その成果物が次の何に使われるのかを書き出します。

次に、共通設計を整備します。個別機能ごとにAIへ判断させてはいけないルールを先に固定します。

そのうえで、設計書を作成するSkillを用意します。入力情報、参照する設計標準、出力形式、確認項目を明確にします。

続いてレビューをAIと人間に分けます。機械的な整合性確認はAIを活用し、業務妥当性やプロジェクト固有の判断は人間が中心となって確認します。

最後に、人間が修正した内容やAIが見逃した問題を記録し、Skillと設計標準へフィードバックします。

このサイクルを回すことで、設計作業そのものだけでなく、設計を作る仕組みの品質を高めていくことができます。

まとめ

AI駆動開発になっても、設計書や設計情報が不要になるわけではありません。

むしろ、AIが設計から実装、テストまで短時間で進められるようになるほど、上流で何を正として与えるのかが重要になります。

最初に行うべきことは、個別の設計書をAIに作らせることではありません。

何をインプットとして、何を作り、その成果物を次の何に利用するのかという設計情報のグランドデザインを作ることです。

また、AIによるレビューでは成果物間の整合性確認を積極的に活用できますが、「内容そのものが正しいか」は別問題です。

業務ルールや顧客固有の事情などは、人間による確認が欠かせません。

そして、AI駆動開発ではもう一つ重要な管理対象があります。

それが、設計書を作成したりレビューしたりするSkillです。

人間レビューで発見した問題をSkillへ反映し、過去の問題をテストケースとして残し、継続的に改善していく。

AIを一度導入して終わりにするのではなく、

設計情報 → AIによる生成 → AIレビュー → 人間レビュー → Skill改善

というサイクルをプロジェクトとして作ることが重要です。

AI駆動開発でPMが管理するのは、完成した設計書だけではありません。

正しい設計情報から、正しい成果物を継続して作れる開発プロセスそのものを管理する。

これが、AIを前提とした設計管理でPM・PLが押さえておきたいポイントです。