「AIに丸投げ」でも「全部人力」でもない——企画から公開までを人と複数AIで分担する設計図

ある事業責任者が「AIに要件を伝えたのに、出てきた画面がイメージと違う」と嘆いていました。原因はAIの能力ではなく、役割分担の設計が無かったことでした。一人のAIに企画も設計も実装もレビューも押し付ければ、責任の所在が曖昧になり、抜け漏れは誰も気づきません。人間の組織で「一人に全部やらせない」のと同じ発想が、AI活用にも必要です。

この記事の主張:AIは「一人」ではなく「チーム」として配置する

本記事の主張はシンプルです。AIを1つの万能アシスタントとして使うのをやめ、企画・設計・実装・レビュー・テストという工程ごとに別々の役割として分担させること。そして人間(PM・事業責任者)は「作業者」ではなく「意思決定者・受け入れ判定者」に回ることです。

この構成にすると、各工程の成果物が明確になり、AI同士が互いの出力をチェックし合う仕組みが作れます。結果として、冒頭のような「イメージと違うものが出てくる」事故を減らし、非エンジニアでも品質をコントロールしやすくなります。

なぜ今、この問題が起きているのか

生成AIの性能が上がり、「日本語で頼めば動くものが出てくる」段階に入りました。すると多くの現場で、企画から実装まで一つの会話ウィンドウに全部詰め込む使い方が広がっています。

しかしこれは、人間の組織に例えれば「一人の新人に企画・設計・開発・品質保証を同時にやらせ、しかも誰もレビューしない」状態です。AIは指示された範囲を器用にこなしますが、工程間の整合性や、前提の抜け漏れを自分から指摘することは苦手です(筆者の実務観察による意見)。だからこそ、工程を分けて役割を与える設計が効いてきます。

現場では何が起きているのか

変化1:企画と実装の「伝言ゲーム」が消える

従来は「PMが仕様書を書く→エンジニアが読んで実装する」という人から人への伝達で、解釈のズレが生まれていました。AIに工程を分担させると、前工程の成果物(例:要件定義書)をそのまま次工程のAIへ渡せるため、人を介した伝言ゲームが減ります。

変化2:レビューを「後回しにしない」文化が生まれる

人間の現場では、レビューは忙しさで省略されがちです。一方、AIをレビュー担当として常設すれば、設計や実装が出てくるたびに機械的にチェックが走ります。ある小規模開発チームでは、レビュー専用AIに「セキュリティ観点で問題点を列挙」と役割を固定したところ、人間が見落としていた入力チェック漏れを複数拾えた、という報告があります(事例、規模は小さく一般化には注意)。

変化3:非エンジニアが「判定者」として関与できる

これまで画面やシステム内部の話は「エンジニアに任せるしかない」領域でした。工程ごとにAIが人間向けの説明つきで成果物を出すため、PMが各段階で「これで進めてよいか」を判断できるようになります。専門知識より「事業として正しいか」を問う力が重要になります。

従来の方法では対応できない理由

「優秀なAIを1つ選べばいい」という発想では、なぜ不十分なのか。理由は3つあります。

• 検算が効かない:同じAIが作ってレビューすると、自分のミスに気づきにくい。人間でも自己校正が甘くなるのと同じ構造です。
• 工程の成果物が残らない:一つの会話で進めると、企画・設計・実装が混ざり、後から「なぜこの設計にしたか」を追えません。
• 責任の切り分けができない:問題が起きたとき、企画のズレなのか実装のバグなのか特定できず、改善の打ち手が決まりません。

工程を分けることは、単なる作業分割ではなくトレーサビリティ(何をどう決めたかを追える状態)の確保でもあります。

役割分担の全体像

図: 人と複数AIの役割分担(横軸=工程、縦軸=担当)

| 工程 | 主担当 | 人間(PM)の役割 | 成果物 |

|------|--------|----------------|--------|

| 企画 | 企画AI | 事業ゴール・制約を提示、採否を判定 | 要件定義書 |

| 設計 | 設計AI | 優先度・スコープを決定 | 画面設計・データ設計 |

| 画面 | UI-AI | ブランド・使いやすさを判断 | 画面仕様・文言 |

| システム内部 | 実装AI | 予算・納期の制約を確認 | 実装コード |

| レビュー | レビューAI | 指摘の重要度を判断 | 指摘リスト |

| テスト | テストAI | 合格基準を決定 | テスト結果 |

ポイントは、人間が全工程に「判定者」として1回ずつ登場することです。作業はAIに任せ、人間は「進める/戻す」の意思決定に集中します。

企画から公開までの流れ

```mermaid

%% 用途: 人と複数AIによる開発フロー(企画から公開まで)

flowchart TD

A[事業ゴール・制約<br/>人:PM] --> B[企画AI<br/>要件定義書を作成]

B --> C{人:PMが採否判定}

C -->|差し戻し| B

C -->|承認| D[設計AI<br/>画面・データ設計]

D --> E[UI-AI<br/>画面仕様・文言]

E --> F[実装AI<br/>システム内部を構築]

F --> G[レビューAI<br/>設計・実装をチェック]

G --> H{人:PMが指摘の<br/>重要度を判断}

H -->|修正が必要| F

H -->|OK| I[テストAI<br/>動作・不具合を検証]

I --> J{人:PMが<br/>合格基準で判定}

J -->|不合格| F

J -->|合格| K[公開]

```

この流れの肝は、AIが作った成果物を別のAIと人間がダブルでチェックする関門(◇の判定ポイント)があることです。関門を通らないと次工程に進めない設計にすることで、品質が担保されます。

そのまま使える「役割分担プロンプト」テンプレート

各工程のAIに「役割」を固定するためのプロンプトです。会話ごとに、または別々のAIツールに貼り付けて使えます。

```markdown

用途: 各工程のAIに役割を固定するシステムプロンプト

使い方: 〈〉部分を自社の内容に置き換え、工程ごとに別会話で使用

【企画AI】

あなたは要件定義の専門家です。以下の事業ゴールから要件定義書を作成してください。

• 事業ゴール:〈例:リピート率を上げる会員向けお知らせ機能〉
• 制約:〈予算・納期・既存システム〉
• 出力:機能一覧/優先度(高中低)/対象外の明記/前提の確認質問

※不明点は勝手に決めず、必ず質問として列挙すること。

【レビューAI】

あなたは第三者レビュアーです。以下の成果物を批判的に点検してください。

自分で作り直さず、指摘のみを行います。

• 観点:要件との不一致/抜け漏れ/セキュリティ/使いやすさ
• 出力:指摘を「重要度(高中低)+根拠+改善案」の表で列挙

※「問題なし」と書く前に、必ず3つ以上の観点で検証した過程を示すこと。

【テストAI】

あなたはQA担当です。以下の要件に対するテスト項目を作成し、結果を判定してください。

• 出力:テスト項目/期待結果/実際の結果/合否

※正常系だけでなく、異常系(空欄・不正な値・大量データ)を必ず含めること。

```

※で始まる制約が重要です。AIは放っておくと「問題なし」で済ませがちなので、検証の過程を強制することで品質が上がります(筆者の実務での意見)。

経営・組織に与える影響

この分担構成は、開発のやり方を超えて組織のあり方を変えます。

• 意思決定:PMが「作れるか」ではなく「作るべきか」に集中でき、判断の質が上がる。
• 採用・人材:必要なのは全工程を一人で書ける人材より、AIの成果物を評価・判定できる人材。専門スキルより「良し悪しを見抜く目」の価値が上がる。
• 教育:新人が各工程のAI出力を「なぜこの指摘が妥当か」と学ぶことで、実務を早く体得できる可能性がある(推測)。
• 品質管理:関門(判定ポイント)を制度化することで、属人的なレビューを仕組みに変えられる。
• 責任分担:工程ごとに成果物が残るため、問題発生時に「どの工程で何を決めたか」を追える。

一方で注意点もあります。最終責任は人間が負うという原則を崩してはいけません。AIが承認したから、ではなく、人間が判定したから進める、という建て付けを守る必要があります。

企業は何から始めるべきか

1. 1つの小さな機能で試す:いきなり全社導入せず、影響の小さい機能で分担フローを回してみる。

2. 判定ポイントを2つだけ決める:最初は「企画承認」と「公開判定」の2関門から。慣れたらレビュー・テストを追加する。

3. 成果物の置き場を決める:要件定義書や指摘リストをどこに残すか(共有フォルダ等)を先に決める。追えることが品質の土台。

4. 役割プロンプトを社内資産にする:上記テンプレートを自社版に育て、誰が使っても同じ品質が出る状態を目指す。

5. 人間の「判定基準」を言語化する:何をもって合格とするかを事前に決める。基準が曖昧だと関門が機能しない。

まとめ

AIは「一人の万能アシスタント」ではなく「工程ごとの役割を持つチーム」として配置する——これが本記事の主張です。人間(PM・事業責任者)は作業から降り、各工程の関門で「進める/戻す」を判定する意思決定者に回ります。

まず最初の一歩は、小さな機能を1つ選び、「企画承認」と「公開判定」の2つの関門を置いて流してみること。ここから、あなたの組織に合った分担図が育っていきます。

実践チェックリスト

• [ ] 企画・設計・実装・レビュー・テストを別々の役割として分けたか
• [ ] 各工程の成果物(要件定義書・指摘リスト等)を残す場所を決めたか
• [ ] 人間が判定する関門を最低2つ設けたか
• [ ] レビューAIと実装AIを同じ会話にせず、分離したか
• [ ] 役割プロンプトに「検証過程を示す」制約を入れたか
• [ ] 合格基準(何をもってOKか)を事前に言語化したか
• [ ] 最終責任は人間が負う建て付けになっているか

次に読む記事

• 基礎:「生成AIとは何か——非エンジニアのためのできること・できないこと入門」
• 実践:「レビューAIを使いこなす:『問題なし』と言わせない指示の書き方」
• 発展:「AIエージェントの自律実行と人間の承認ゲート設計——ガバナンスの作り方」

よくある質問

Q. 複数のAIツールを契約する必要がありますか?

A. 必須ではありません。1つのツールでも、会話(セッション)を工程ごとに分ければ役割分担は実現できます。重要なのはツールの数ではなく、工程と成果物を分けることです。

Q. 非エンジニアでもレビューやテストの判定ができますか?

A. できます。判定の中身は「事業として正しいか」「使う人が困らないか」が中心で、技術的な妥当性はレビューAIが指摘します。人間は指摘の重要度と、事業への影響を判断する役割です。

Q. AI同士のチェックは本当に信頼できますか?

A. 万能ではありません。AI同士のチェックは見落としを減らす仕組みであって、ゼロにはできません。だからこそ最終判定は人間が行い、重要な機能では実際の利用者テストを併用することを推奨します。