非エンジニアPMでも“作れる”時代：Cursor×Claudeでプロダクト開発の型を手に入れる
「コードが怖い」「レビューなんて無理」——それでも、PMが“自分で”プロダクトを形にできる時代が来ています。MetaのPMで、技術バックグラウンドがほぼゼロだというZevi Arnovitzは、Cursor＋Claude Codeを中心に、非エンジニアでも実用プロダクトを作り切るための“型”を作りました。彼の目標はシンプルです。「人が彼を褒めて終わるなら失敗。PCを開いて作り始めたら成功」。
1. 「非エンジニアPMでも作れる」時代の本質
AIがコードを書くこと自体は、もはや珍しくありません。問題は、Zeviが言うように「AIが書いたコードをどうレビューするか」に移っています。
ここで重要なのは、AIを“魔法の自動化”ではなく、役割分担されたチームとして扱うこと。Zeviは、AIモデルを擬人化して、得意領域に投げ分けます（例：Claude＝議論と設計、Gemini＝UI、別モデル＝難バグ）。この「分業」発想が、非エンジニアの怖さを一段下げます。
2. Zevi式ワークフロー：6ステップで“暴走”を防ぐ
2-1. スラッシュコマンドで“作業の型”を固定する
Zeviの中心テクは、Cursor内で使える/commands（スラッシュコマンド）。繰り返し作業を「再利用できる指示書」として保存し、/create issue のように呼び出します。
2-2. 6ステップ（Issue→探索→計画→実装→レビュー→ドキュメント）
彼の流れはざっくり次の通りです。
Create Issue：思いつきをLinearのIssueに一瞬で落とす（“今は作らないが忘れない”）
Exploration phase：AIにコードベースを読ませ、仕様・影響範囲・曖昧点を質問させる
Create plan：合意した内容をMarkdownの実装計画にする（タスク分解・意思決定ログ）
Execute：計画に沿って実装（CursorのエージェントやComposer等を活用）
Review / Peer review：自己レビュー＋別モデルレビューを突き合わせる
Update docs：失敗原因をドキュメント・プロンプトに反映して再発防止
この順番の価値は、AIの“早とちり実装”を抑え、「設計→実装」へ強制的に戻す点にあります。Cursor側も「まず計画を作り、レビューしてから実行」という思想をドキュメントで強調しています。
3. “レビューできない問題”の解き方：モデル同士に殴らせる
非エンジニア最大の壁は、やはりレビューです。Zeviはここを、「複数LLMで相互監査」に置き換えます。Claudeに/self reviewさせ、さらに別モデルにも同じブランチをレビューさせ、結果をまとめて「peer review」コマンドで統合。
ポイントは、“指摘を鵜呑みにしない”設計です。Dev lead（主担当AI）に「他チームのレビューが来た。妥当性を反証するか、直せ」と命じる。これは、人間の開発組織で起きるレビュー文化の模倣で、AIのハルシネーションも相殺しやすい構造です。
4. ツール連携の鍵：MCPで“作業場所”をつなぐ
Zeviの例では、AIがLinearにIssueを作るなど、外部ツールに触れます。ここで出てくるのがMCP（Model Context Protocol）。Claude Codeが外部ツールやデータソースへ安全に接続するための標準で、「AIにUSB-Cを刺す」比喩で説明されます。
つまり、AIが賢くなるだけではなく、AIが“仕事をする手”を持つ。これが「非エンジニアでも回るワークフロー」を現実にします。
5. 非エンジニアPMが明日から使える実践ルール
最後に、会話全体から抽出できる“安全運転のコツ”を、行動に落とします。
最初は「会話」から始める：いきなりIDEではなく、プロジェクト機能等で“疑問を全部投げる場所”を作る（怖さを減らす）
計画ファイル（Markdown）を必ず残す：AI実装のブレを抑え、モデルを切り替えても引き継げる
レビューは多重化する：自分が見れないなら、モデルの多様性でカバーする
失敗したら“ポストモーテム→プロンプト更新”：うまくいった後こそ、原因を言語化して型を強化する
結論
Zeviのやり方は、「非エンジニアでも天才になれる」話ではありません。むしろ逆で、天才っぽさを排して、再現可能な手順に落としたのが本質です。
あなたがPMなら、次の一歩はこれで十分です——“作りたい機能”を1つ決めて、Issue→探索→計画の3ステップだけ回す。 それだけで、AIは「暴走するコーダー」から「一緒に考える開発チーム」へ変わり始めます。
