1人でAIチームを作る方法（PM・エンジニア・レビュアー）
はじめに
生成AIでコードを書くのが当たり前になってきましたが、使えば使うほど難しさも感じます。
- AIにコードを書かせたけど、微妙に意図とズレている
- 仕様が曖昧なまま実装に入って、手戻りが増えた
- 結局、自分で全部レビューしていて楽になった実感がない
自分もずっとこの状態でした。便利ではあるけれど、「思ったより楽にならないな」と感じていたんですよね。
あとから振り返ると、原因はシンプルでした。AIを毎回「なんでもやってくれる1人のエンジニア」として使っていたんです。
実際の開発では、要件を整理する人、実装する人、レビューする人が分かれています。同じ考え方で、AIにも役割を分けて頼むようにしたら、出力のブレがかなり減りました。
この記事では、自分が普段やっている「AIを3役に分けて回す方法」を、できるだけ実践寄りにまとめます。
先に結論
AIに1つの長いプロンプトで全部やらせるのではなく、PM → エンジニア → レビュアーの3段階に分けて渡す。
自分がやるのは、前の工程の出力を次の工程に渡すことが中心です。
全体像
AIに割り振る役割は3つ。
| 役割 | やること | AIが得意な理由 |
|---|---|---|
| PM | 要件整理・仕様化 | 情報の構造化・抜け漏れ洗い出しが得意 |
| エンジニア | コード実装 | コード生成・定番パターンの適用が速い |
| レビュアー | 品質チェック | 批判的な視点での分析・パターン検出が得意 |
難しいことはなくて、この3つを順番に回すだけです。
① PM（要件整理）
最初にいちばん大事なのは、いきなりコードを書かせないことです。
ここを飛ばすと、あとで「あれも必要だった」「その前提で作ってほしかった」が一気に出てきます。
雑に頼んだ場合 vs 役割を与えた場合
| 雑に頼んだ場合 | PM役として依頼した場合 | |
|---|---|---|
| プロンプト | TODOアプリを作って |
下記参照 |
| 起きること | 仕様の解釈がAI任せでブレる | 出力が構造化されて具体的になる |
| 次工程への影響 | 手戻りが増える | そのままエンジニア工程に渡せる |
PM役へのプロンプト例
あなたはプロダクトマネージャーです。
TODOアプリを開発したいので、以下を整理してください。
- 必要な機能一覧
- ユースケース
- 技術要件
- 簡単な画面構成
できるだけ具体的に書いてください。
ポイント
- 「あなたは〇〇です」で役割を明示し、AIの応答トーンを固定する
- 欲しい出力項目を箇条書きで並べると、抜け漏れが減る
- 「具体的に」と付けるだけで、ふわっとした回答を抑制できる
② エンジニア（実装）
PM役の出力ができたら、それをそのまま次のプロンプトに貼って実装を頼みます。
ここで自分の言葉に言い換え直さないのがコツです。せっかく整理した仕様に、余計な解釈を混ぜないためです。
エンジニア役へのプロンプト例
あなたは優秀なソフトウェアエンジニアです。
以下の仕様をもとに実装してください。
（PMの出力を貼る）
条件：
- 可読性の高いコード
- コメントを適切に付ける
- ベストプラクティスを使う
ポイント
- PM工程の出力をそのまま渡すことで、自分の解釈によるブレが入らない
- 「可読性」「ベストプラクティス」のような制約を足すと、生成コードの品質が安定する
③ レビュアー（品質チェック）
個人的には、この工程がいちばん効きます。
AIはコードを「書く」ときより、「読む」側に回したときのほうが安定して鋭いことが多いです。自分で書いたコードを別人格のAIに読ませるだけでも、見落としていた点がかなり出てきます。
レビュアー役へのプロンプト例
あなたは厳しいコードレビュアーです。
以下のコードをレビューしてください。
- 問題点をすべて指摘
- 改善案を提示
- バグの可能性
- パフォーマンス観点
遠慮せず厳しめにレビューしてください。
ポイント
- 「厳しめに」と明示しないと、AIは当たり障りのないコメントで済ませがち
- 観点（バグ・パフォーマンス等）を指定すると、レビューの網羅性が上がる
実際の流れ
TODOアプリを例にすると、やり取りはこんな感じになります。
要するに、自分は「全部を自分で考えて書く人」ではなく、流れを設計して、必要なタイミングでAIを切り替える人になります。
この形にすると、1回ごとの依頼が短くなるので、プロンプト自体も扱いやすくなります。
なぜ効くのか
使っていて特に効くと感じるのは、次の3つです。
| # | 理由 | 補足 |
|---|---|---|
| ① | コンテキストが整理されてから実装に入る | いきなり書かせると前提が曖昧なまま進む。PM工程を挟むだけで防げる |
| ② | AIの得意/不得意に合わせた分担になる | 構造化・生成・批判はそれぞれ別の能力。1プロンプトに混ぜると中途半端になりやすい |
| ③ | 実務の開発フローと同じ構造 | 普段のチーム開発で回しているプロセスなので、勘所がそのまま使える |
応用：さらに精度を上げるには
役割を増やす
基本の3役だけでも十分回せますが、慣れてきたら専門家を足すとさらに使いやすくなります。
たとえば、セキュリティやテストの観点だけ別ロールに切り出すと、レビューの粒度がぐっと上がります。
| 追加ロール | やること | プロンプト例（抜粋） |
|---|---|---|
| セキュリティ担当 | 脆弱性チェック | 「セキュリティエンジニアとして、OWASP Top 10の観点でレビューしてください」 |
| テスト担当 | テスト設計・作成 | 「QAエンジニアとして、単体テストと結合テストを設計してください」 |
| ドキュメント担当 | 仕様書・README作成 | 「テクニカルライターとして、API仕様書を作成してください」 |
制約を足す
もう1つ効くのが、制約を明示することです。
AIは自由度が高いほど気持ちよく広げてくれますが、実務ではその広がりがノイズになることもあります。使いたい言語や設計方針、テストの有無を最初に書いておくとかなり安定します。
追加制約の例：
- TypeScriptで書く
- 関数型で実装
- テストコード必須
やりがちな失敗
| やってしまうこと | 何が起きるか | 回避策 |
|---|---|---|
| 1回のプロンプトで完成させようとする | 仕様もコードもレビューも混ざって中途半端になる | ステップを分けて、1回1役割に絞る |
| 役割を指定しない | AIの応答トーンが定まらず、出力がブレる | 「あなたは〇〇です」を冒頭に書く |
| レビュー工程を飛ばす | バグや設計上の問題が残ったまま進む | 面倒でも最低1回はレビュアーを通す |
最初のうちは、全部をきれいに回そうとしなくて大丈夫です。
まずは 実装させたあとにレビュアー役を1回通す だけでも、かなり変わります。
図5. やりがちな失敗の比較図
「悪いやり方」と「良いやり方」を左右比較にすると、読者がすぐ真似しやすくなります。
まとめ
やっていることはシンプルで、PMで整理 → エンジニアで実装 → レビュアーでチェックを回しているだけです。
特別なツールやプラグインがなくても、この考え方自体はそのまま使えます。1人開発で「結局ぜんぶ自分で見てるな」と感じているなら、まずはレビュアー役だけでも試してみるのがおすすめです。
おわりに
このやり方を日常的に使うようになってから、AIとの付き合い方がかなり変わりました。
特に印象的なのは、レビュアー役にしたときに、自分では見落としていた前提や雑な実装をちゃんと拾ってくれることです。書かせるだけより、読ませるほうがうまくハマる場面は多いなと感じています。
もし普段やっている工夫があれば、ぜひコメントで教えてください。自分もまだ試行錯誤中なので、いろいろ知れたらうれしいです。