はじめに
「PMの次のスキルはプロンプトではない」と聞くと、身構えるかもしれません。
プロンプトを工夫してきたのに、それが要らなくなるのか、と。
でも、なくなるわけではありません。磨く場所が、毎回のプロンプトから「何度も使う判断の型」へ移るだけです。
この「ループ・エンジニアリング」という考え方を、プロダクトマネージャー（PM）の仕事に当てはめるのが本記事です。
きっかけは、Google の Senior AI Product Manager である Shubham Saboo 氏（@Saboo_Shubham_）が書いた「Loop Engineering for Product Managers」という記事でした。
PMが磨くべきは毎回のプロンプトではなく、「プロダクト判断を反復させるシステム」だ、という主張です。
読むと得られるものは、次の3つを想定しています。
- PMにとっての「ループ」とは何か、なぜプロンプト改善では足りないかが分かる
- ループを構成する5つの要素と、PMでの具体例が分かる
- 顧客リサーチやPRDレビューを、最初の小さなループに落とす手順が分かる
対象読者は、生成AIを業務で使うPM・プロダクト寄りの方です。
ループの前提知識は不要で、この記事だけで読めるように書いています。
本記事は Shubham Saboo 氏の記事を出発点に、筆者の理解と実運用を加えて書き起こしたものです。
元記事の主張の紹介には引用（>）を使い、それ以外は筆者の解釈です。
図は元記事の図版を Mermaid で描き直しています。
構成・文章の見直しと図の再現には生成AI（Claude）を併用し、内容は筆者が検証しました。
外部の人物の発言やツールの仕様は、元記事の記述に依拠しています（独自の裏取りはしていません）。
先に結論（この記事の要点）
- PMの次のスキルもプロンプト・エンジニアリングではなく、ループ・エンジニアリングだ、という主張です。
- PMが磨く対象は「毎回のプロンプト」ではなく、判断を形づくる再利用可能なアーティファクトです。PRDレビュー基準、顧客コール要約器、評価ルーブリック（採点基準表）などが該当します。
- 放っておくとアーティファクトは静かに劣化します。モデルが悪くなるのではなく、設定や指示が少しずつズレていくのです。
- ループの5要素（トリガー / アクション / 証明 / メモリ / 停止条件）はPMでも同じです。違うのは「証明」の中身が、自動テストの合否ではなくプロダクト判断になることです。
- 最初の一手は戦略ではなく、繰り返しが多くて証拠が揃うプロダクトオペレーションから始めます。
ループの共通骨格（5要素）
まず、ループという言葉の中身をそろえます。
ループとは「プロンプトを与える→出力を読む→完了か判定する→未完なら再投入する」を自動で回す小さな仕組みです。
そして、どんなループも次の5要素で説明できます。
- トリガー: いつ始まるか
- アクション: 何をするか
- 証明（proof）: 良くなったとどう分かるか
- メモリ: 学びをどこに保存するか
- 停止条件: いつ終わるか
この骨格は、エンジニアの作業（PRのお守り、CI修正、デプロイ検証）でも、PMの作業（顧客リサーチ、PRDレビュー、週次の状況把握）でも変わりません。
本記事では、この5要素をPMの仕事に当てはめていきます。
なぜPMに「ループ」なのか
最初に、元記事のいちばんの主張を引用します。
PMに次に求められるスキルはプロンプト・エンジニアリングではない。ループ・エンジニアリングだ。 — Shubham Saboo 氏（
@Saboo_Shubham_）
ここで誤解しやすい点を押さえておきます。
これは「プロンプトを書く力が不要になる」という話ではありません。
プロンプトはタスクを1回こなすのを助けます。
ループは、タスクの遂行のされ方を毎回形づくる「アーティファクト」を改善します。
ここでのアーティファクトとは、判断の質を左右する「再利用可能な部品」のことです。
PRDレビュー基準、顧客コール要約器、評価ルーブリック（採点基準表）、ローンチ・チェックリストなどが当てはまります。
毎回ゼロから書くプロンプトと違い、残して育てていく対象だと考えると分かりやすいです。
仕事の階層が一段上がる、という構図です。
プロンプト改善では解けない「アーティファクトのズレ」
ここで言う「ズレ」とは、アーティファクトが少しずつ当初の意図から外れていくことです。
元記事では「ドリフト（漂流）」と呼ばれています。
エンジニアの場合、少しずつ崩れていったのは CLAUDE.md やレビュー用スキルでした。
PMの場合も同じことが起きます。
PRDレビューの基準が少しずつ厳しくなります。
リサーチ用の指示が過去案件の都合を引きずります。
ローンチ・チェックリストが膨れ、エージェントが半分を無視します。
評価基準を変えたのに、いつ・なぜ変えたか忘れます。
そして1か月後、「最近エージェントの出すPRDの質が落ちた」と感じます。
元記事は、この感覚の正体を次のように言い切ります。
モデルが劣化したのではない。アーティファクトが少しずつズレていき、それを誰も見張っていなかったのだ。 — 同記事より要約
ここが、PMにとってのループ・エンジニアリングが解く問題です。
1つのプロンプトを良くすることではなく、判断を形づくるアーティファクト群が、朽ちるのではなく改善し続けるようにすることです。
PMループの5要素を、サイクルとして見る
元記事は、PMのループを1枚のサイクル図で示しています。
中心には「再利用可能なAIアーティファクト（一度きりのプロンプトではない）」が置かれます。
そのまわりを、変更→実行→評価→採否→学びの保存→次バージョン、と回します。
この6ステップは、先の5要素（トリガー・アクション・証明・メモリ・停止条件）を実際に回す手順そのものです。
なかでもPMで特に重いのは「証明」と「メモリ」の2つだと感じました。
エンジニアの証明は、自動テストの合否で機械的に出せます。
PMの証明は「このアーティファクトは、既知のプロダクト判断に照らして良くなったか」です。
ここを機械任せにできないからこそ、後述する「評価（eval）」がPMの新しい仕事になります。
ループの解剖図: 5つの部品を具体例で
サイクル図は「どう改善するか」でした。
次は「ループが何でできているか」を分解します。
5要素は直列につながり、証明が通らなければ停止へ抜けます。
PMの作業に当てはめると、それぞれは次のようになります。
| 部品 | PMでの具体例 |
|---|---|
| トリガー | 新しいPRDが来た / 週次リサーチの始動 / 実験が結果報告に達した |
| アクション | 要約する / 比較する / レビューする / 採点する |
| 証明 | 実際の問題を捉えた / 証拠が強くなった / 根拠のない主張が減った |
| メモリ | GitHubコミット / 意思決定ログ / 週次プロダクトメモ |
| 停止条件 | 変化がない / 新しいシグナルがない / 証拠が薄い / 人の判断が要る |
5要素の中でいちばん抜けやすいのが停止条件です。
止まれないループは、走らせっぱなしにできず、付きっきりで世話をするループになります。
PMのループも、新しいシグナルが無い・証拠が薄い・人の判断が要るときは、素直に止まってよいのです。
実例で見る: simple → better → loop
ここからは、元記事の具体例で見ていきます。
顧客リサーチを題材に、3段階で考えます。
- simple（その場限り）: エージェントに「これらのコールを要約して」と頼みます。1回は役立ちますが、次回は良くなりません。
- better（アーティファクト化）: チームが重視する観点（ペインポイント、回避策、緊急度、反論、プロダクトギャップ、正確な引用）を知っている「要約器」を用意します。
- loop（毎週回す）: その要約器を毎週使い、新しいコールを過去テーマと比較し、繰り返し・新規・証拠の薄さをフラグします。要約がニュアンスを取りこぼしたら要約器を直します。次回が良くなります。
PRDレビューも同じ3段階です。
「このPRDをレビューして」（simple）から、「チームの品質基準を知っているレビュー用アーティファクト」（better）へ。
さらに「そのアーティファクトが本当に良いフィードバックを出しているかを検証する」（loop）へ進みます。
検証では、たとえば次を問います。
- 曖昧な問題を捉えているか
- 本物の証拠を求めているか
- 欠けている指標を指摘しているか
- 無意味な揚げ足取りを避けているか
- プロダクトの意図を保っているか
答えが落ちてきたときに直すのは、プロンプトではなくアーティファクトの側です。
ここで元記事の一文がきれいに効きます。
答えが落ちてきたら、直すのはプロンプトではなくアーティファクトだ。 — 同記事より要約
言い換えると、「プロンプトをチューニングする」から「ループをチューニングする」への移動です。
PMの場合、その「ループの中身」がプロダクト判断を持ったアーティファクトになる、という違いがあります。
最初のループ: 週次プロダクトシグナル
元記事は「最初に戦略を決めるループを作るな」と明確に勧めています。
戦略は広すぎ、主観的すぎ、間違えやすすぎるからです。
代わりに、繰り返しが多く証拠が揃うプロダクトオペレーションから始めます。
具体例が「週次プロダクトシグナル・ループ」です。
毎週、顧客コール・サポートチケット・営業メモ・実験結果・分析・出荷した変更・未解決のエスカレーションを読み、1つのメモを生みます。
このメモは、ありきたりの要約ではいけません。
繰り返されるシグナルと、孤立したノイズを切り分ける必要があります。
正確な顧客の言葉を含め、先週からの変化を示し、証拠の薄い箇所を指摘します。
そして、どのロードマップ上の仮説が強まり・弱まり・変わらなかったかを述べます。
レビューして、取りこぼしがあればアーティファクトを更新します。
元記事の表現を借りると、数週間で役に立ち始め、数か月後にはロードマップ会議の前に必ず見るものになります。
ここで効いてくるのが、5要素の最後にある停止条件です。
新しいシグナルが無い、証拠が薄すぎる、PMの判断が要る、というときは、ループは素直に止まってよいのです。
いちばんの核心: 目利きには証明が要る
ここが、PMにとって最も視点が変わる部分でした。
PMは昔から、良し悪しを見抜く「目利き」に頼ってきました。
PRDを読んで問題が曖昧だと感じ取れます。
顧客の引用が引き伸ばされすぎていると見抜けます。
ローンチ計画が依存関係を「無いふり」していると察知します。
この判断力は、ループでも消えません。
むしろ、判断が中心に来ます。
元記事は、PMの仕事を次の一行に凝縮しています。
「正しい」とは何かを定義し、それが満たされたときにそう言えること。 — 同記事より要約
問題は、これを推測せずにどうやるかです。
答えが「評価（eval）がPMの仕事になる」でした。
ここで効くのが「検証役」、つまり成果物を独立して採点する役割です。
エンジニアが検証役にテストを使ったように、PMは検証役に「既知の良し悪しの例」を使います。
巨大なベンチマークは要りません。
手元の例から始められます。
採用面接にたとえると、「良い回答」と「困る回答」の見本を先に用意し、それに照らして判断するのに似ています。
- 強いPRDを3本、弱いPRDを3本用意します。レビュー用アーティファクトを当て、本当のギャップを捉えたか、揚げ足取りを避けたか、プロダクトの意図を保ったかを見ます。
- 顧客コールを10件用意します。要約が実際の要点を捉えたか、強いシグナルと一度きりのノイズを区別したかを見ます。
問うのは「エージェントは賢そうに聞こえたか」ではありません。
「このアーティファクトは、既知のプロダクト判断に照らして良くなったか」です。
これは、いわゆる「誤green」のPM版だと感じました。
テストが緑（green）でも本番経路を通っていなければ意味がないように、要約が流暢でも判断を捉えていなければ意味がありません。
検証役の設計が緩いと、PMのループも「それっぽいが間違っている」をすり抜けます。
ループにはメモリ層が要る ― GitHubが「プロダクトの記憶」になる
アーティファクトを評価し始めると、学びの置き場が要ります。
チャットでプロンプトを変え、指示をファイルに貼り、ルーブリックを微調整し、例を足す。
出力は変わるのに、履歴は消えます。
数週間後、なぜエージェントがそう振る舞うのか誰も分からなくなります。
ここで効くのが、5要素の「メモリ」です。
元記事は、その置き場としてGitHubを勧めます。
PMがエンジニアになるためではなく、業務を形づくるアーティファクトのバージョン履歴が要るからです。
GitHubに置くと、次が手に入ります。
- アーティファクトが良くなったら、そのコミット
- 悪くなったら、その差分（diff）
- ルーブリックが変わったら、その理由
- ローンチ・チェックリストが本物のブロッカーを捉えたら、次回への学び
元記事の言葉では、リポジトリが「プロダクトの記憶」になります。
ストレージは最新版だけを保持しますが、メモリは全てのバージョンを保持します。
だからループは、ゼロからやり直すのではなく、少しずつ賢くなります。
壊れどころと、権限を与えすぎない原則
PMのループは、たいてい単純な理由で壊れます。
トリガーが曖昧、入力が雑然、アーティファクトが長すぎる、証明が主観的、学びの置き場が無い、停止条件が弱い。
PMループでやってはいけない3つ（と、その防ぎ方）
- 証明を主観のままにする → 強い例・弱い例で「良し悪し」を先に定義する。
- 停止条件を決めない → 「新しいシグナルが無い／証拠が薄い」など止めどきを書く。
- 早すぎる権限委譲 → まずは「判断を補助するループ」に限定し、決定は人が下す。
そして、もう1つの罠があります。
早すぎる段階で、ループに権限を与えすぎることです。
戦略を変えられる、顧客にメッセージを送れる、ロードマップを更新できる、レビューなしにプロダクト上のコミットメント（約束ごと）を決められる、というループです。
そんなループから始めてはいけない、と元記事は釘を刺します。
最初は「あなたが下す判断を補助するループ」から始めます。
ループは顧客の証拠を要約できますが、戦略を単独で決めるべきではありません。
ループはPRDをレビューできますが、プロダクトリーダーになるべきではありません。
ループはリスクの高いローンチをフラグできますが、文脈なしにトレードオフを決めるべきではありません。
元記事の印象的な一文が、この姿勢をよく表しています。
ループを作れ。だがPMであり続けろ。 — 同記事より要約
ここがいちばん難しい: 「正しい」を言葉にする
ここからは、記事を書きながら自分がいちばん引っかかった点です。
PMループの肝は「証明」だと書きました。
ところが、いざ証明を作ろうとすると、最初の一歩で詰まります。
「良いPRD」「良い顧客要約」とは何か、を言葉にする作業が重いのです。
ふだんは感覚で「これは弱い」と判断できます。
その感覚を、強い例・弱い例という形で外に出す段になると、急に手が止まります。
元記事の「正しいとは何かを定義し、満たされたと言えること」が、口で言うほど簡単でない理由がここにありました。
ただ、この「重さ」自体に価値があると感じています。
強い例と弱い例を数本ずつ選ぶだけでも、暗黙だった品質基準が言葉になります。
言葉になった基準は、人にもエージェントにも渡せます。
ここで、メモリ層の話がもう一段効いてきます。
基準をバージョンで残すと、「なぜこの判断にしたか」がチームの共有財産になります。
口頭の合意は数週間で薄れますが、コミットされた基準は残ります。
私見ですが、PMにとってのループ・エンジニアリングの本丸は、自動化そのものより、この「判断の言語化とバージョン管理」にあると考えています。
ツールは後からでも替えられます。
替えがききにくいのは、何を正しいとするかという基準そのものです。
ここは筆者の意見です。
プロダクトや組織によって「正しさ」の置き方は変わります。
断定ではなく、1つの見方として読んでいただければと思います。
PMがループを始めるための骨組み
最後に、小さく始める手順を自分の言葉で整理します。
複雑にする必要はありません。
- 繰り返すプロダクト作業を1つ選ぶ: 戦略ではなく、顧客リサーチや週次の状況把握など、定型から始めます。
- 5要素を1枚に書く: いつ始まるか、何を入力に、どのアーティファクトが導き、何をして、良い出力とは何か、学びをどこに保存し、いつ止まるか。
- 証明を「既知の例」で固定する: 強い例・弱い例を数個用意し、アーティファクトを当てて判定します。
- メモリ層を決める: アーティファクトのバージョン・評価結果・意思決定ログを、履歴が残る場所に置きます。
- 人間が持つ判断を明記する: ループに何を任せ、何を任せないかを最初に決めます。
順番にも意味があります。
特に「3. 証明」と「5. 人間の判断」を先に決めると、的外れな自動化と、権限の与えすぎを同時に防げます。
仕事はどう変わるか
PMの仕事は、長らく「翻訳」でした。
顧客の痛みを要件へ。事業目標をロードマップへ。エンジニアリングの制約をトレードオフへ。
その仕事は今も残ります。
ただ、その上に新しい層が乗りました。
プロダクト判断を「反復させるシステム」を設計する層です。
アーティファクトを作り、バージョンで管理し、評価が要るときに評価し、差分を見て改善します。
元記事は、エンジニア側で先に起きた変化を引き合いに出します。
Claude Code を作った Boris Cherny は、もうプロンプトを書かず、ループを書き、そのループがプロンプトをする、と語ったと紹介されています。
同じ移行が、PMの仕事にも広がる、という見立てです。
エンジニアの世界では、これは「コードを書くシステムを書く」と表現されてきました。
PM版は「プロダクト判断を反復させるシステムを設計する」だと整理できます。
まとめ
PMのループ・エンジニアリングは、「プロンプトを書く」から「プロダクト判断を反復させるシステムを設計する」への一段の引き上げです。
磨く対象は毎回のプロンプトではなく、判断を形づくる再利用可能なアーティファクトでした。
ループの5要素はどの領域でも共通で、PMでの違いは「証明」が自動テストの合否ではなくプロダクト判断になる点です。
だからこそ、評価（eval）がPMの新しい仕事になり、メモリ層が「プロダクトの記憶」になります。
元記事の言葉を借りれば、最高のPMは最も長いプロンプト集を持つ人ではありません。
プロダクト業務のどこを耐久的なループにし、どのアーティファクトに導かせ、どの判断を人間に残すかを知る人です。
私自身がいちばん難しいと感じたのは、自動化そのものより「何を正しいとするか」を言葉にしてバージョンで残すことでした。
まずは週次の状況メモを1つ、5要素（いつ・何を・どう判定・どこに残す・いつ止める）に当てはめるところから始められます。
次は、ループを自分でゼロから書かずに使える「Loop Library」を紹介する記事もあります。
参考文献
- Shubham Saboo (
@Saboo_Shubham_), "Loop Engineering for Product Managers"（本記事の出発点となった元記事） - 関連記事（エンジニア向けのループ入門）: https://qiita.com/nogataka/items/60c1a9ba6b2cdebacc1f
本記事の構成・文章の見直しと図の再現には生成AI（Claude）を併用しました。解釈・実践内容は筆者によるものです。検証した範囲は元記事との照合と筆者の環境での実践部分で、外部の発言やツール仕様は元記事に依拠しています。