採用 · July 21, 2026 · 約8分

プロダクトマネージャーのためのプロンプトエンジニアリング

プロダクトマネージャーのためのプロンプトエンジニアリングとは、入力の小技ではなく、問題を適切にフレーミングし、モデルの誤った前提を見抜き、余分なスコープを削ぎ落とすことです。

← 「採用の5つのピラー：アセスメントが測定するもの」の一部

プロダクトマネージャーを採用するなら、AIフルーエンシーの問いはもはや避けられません。PMはモデルから最初のドラフト仕様書、優先順位付け、競合サマリーを数秒で引き出せます。そして誘惑的なのはその完成度の高さです。その洗練さこそが危険でもあります。モデルは静かに誤った前提の上に、自信満々で整ったドキュメントを作り上げます。そのまま出荷するPMは、その仕事が存在する唯一の目的をアウトソースしてしまっています。このガイドでは、プロダクトマネージャーのためのプロンプトエンジニアリングが実際に何を意味するか、なぜそれが入力スキルではなく採用シグナルなのか、そして正直にどう評価するかを取り上げます。これは職種別プロンプトエンジニアリングシリーズのプロダクトマネジメント編であり、AI Sandboxが最も明確に浮き彫りにするものの一つです。

プロダクトマネージャーが実際にAIを活用する場面

プロダクトマネージャーのためのプロンプトエンジニアリングは単一のタスクではなく、それぞれ固有の失敗パターンを持つ日常的な動作の集合です。PMは仕様書やPRDを書き、モデルはそれをスコープ過多にします。PMは競合リリースをまとめ、モデルは存在しない機能を幻覚します。PMはユーザーリサーチノートをテーマに合成し、モデルは最も重要だった矛盾する引用を平均化して消し去ります。PMは優先順位付けを下書きし、モデルはその背後にあるビジネスコンテキストを把握せずに自信満々なランキングを作り出します。いずれの場合も、モデルは機械的な作業を数秒で行い、PMが捉えるべきエラーを静かに取り込みます。

• 仕様書のドラフト：迅速ですが、スコープを作り出し、データモデルを推測する傾向があります。
• 競合サマリー：流暢ですが、実在しない機能や数字を記載する傾向があります。
• リサーチ合成：整っていますが、最も重要な洞察を含む外れ値を均してしまう傾向があります。
• 優先順位付け：決断力がありますが、PMのみが持つ戦略的コンテキストを把握できません。

共通しているのは、モデルは「よくわかりません」とは決して言わない、速くて自信満々なジュニアスタッフということです。PMの仕事は入力速度で競うことではなく、モデルが持ちえないコンテキストを提供し、モデルが知るはずのない部分を疑うことです。

プロンプトエンジニアリングがプロダクトスキルであって入力の小技でない理由

プロンプトエンジニアリングを構文の小技の集まり——魔法のフレーズ、ロールプレイの前置き、フォーマットの呪文——として語る声が多くあります。プロダクトマネージャーにとって、そのフレーミングは的を外しています。PMがモデルの周りで発揮する価値は、言葉遣いとはほぼ無関係で、判断力とほぼすべてが関係しています。どの問題を解くべきか、何を省くか、もっともらしい答えが実は間違っているのはいつかを知ること。それらは、AIがなくても強いPMと弱いPMを分ける本能と同じです。AIは単純にリスクを高めます。なぜなら、曖昧な思考を露わにしていた摩擦を取り除くからです。曖昧なブリーフはかつて白紙を生み出しましたが、今は進歩のように感じられる、洗練された、間違ったドキュメントを生み出します。

フレーミングがプロダクト思考である

優れたプロンプティングの半分はモデルを動かす前に起きます。問題・制約・成功指標を正確にフレーミングすることです。このフレーミングはプロンプトの小技ではなく、明文化されたプロダクト思考そのものです。モデルに鋭い問題文を与えれば有用なドラフトが返ってきますが、「保存フィルターの仕様書を書いて」と与えれば、モデルは空白を一般的な前提で埋め、あなたがそれを引き継ぐことになります。フレーミングが鋭ければ鋭いほど、ドラフトは有用になり、解きほぐすべき前提は減ります。これは良い職務記述書の背後にある規律と同じです。前に置く明確さが、その後のすべての品質を決定します。

残りの半分はドラフトをどう扱うかです。誤った前提を捉え、モデルが過剰に追加したスコープを削り、モデルが生み出したもっともらしい物語ではなく、実際のユーザーと指標に結果を根ざすこと。その組み合わせ——正確なフレーミングと懐疑的なレビュー——がプロダクトの現場でのAIフルーエンシーの姿であり、4Dフレームワークに直接マッピングされます。委任（Delegation、何をモデルに渡すかを知ること）、記述（Description、うまくフレーミングすること）、識別（Discernment、何が間違っているかを捉えること）、誠実さ（Diligence、行動する前に検証すること）。

プロダクトの現場に適用した4Dフレームワーク

「AIが得意」はインタビューで問うには曖昧すぎるため、AIフルーエンシーを構成要素に分解することが有効です。4Dフレームワークはそれを4つの観察可能な行動に分解し、それぞれがプロダクト業務にきれいにマッピングされます。委任（Delegation）とは、そもそも何をモデルに渡すかを知ること。強いPMはルーティンのドラフト作成やサマリーをAIに振り、判断の必要な判断を自分で行います。弱いPMはすべて手動でやるか、本来モデルに委ねるべきでない判断を委ねます。記述（Description）とは、すでに触れたフレーミング——問題をアウトプットが有用になるほど正確に述べる能力です。

識別（Discernment）とはPMにとって最も重要な筋力です。仕上がったように見えるドラフトを読み、成り立たない前提、作り出された機能、静かに変えられた指標を見つけること。誠実さ（Diligence）とは行動する前に検証する規律です。競合の主張を現実に照らして確認し、仕様書の前提を実際のデータモデルに照らして検証し、サマリーされたリサーチテーマを生のノートに照らして確認すること。ある候補者がひとつのDに強く別のDで弱いこともあり、4つすべてにわたるプロファイルが興味深いシグナルです。

• 委任（Delegation）：ルーティン作業をモデルに振り、判断の必要な判断を保持する。
• 記述（Description）：問題・制約・成功指標を正確にフレーミングする。
• 識別（Discernment）：他の人なら出荷してしまう間違っているが自信満々なアウトプットを捉える。
• 誠実さ（Diligence）：行動する前に主張を現実に照らして検証する。

実例：保存フィルター仕様書

保存フィルター機能の1ページ仕様書を頼む。弱いバージョンは曖昧に頼み、整った結果をそのまま出荷する。強いバージョンは実際の問題、ハードな制約——1スプリント、スキーママイグレーションなし——と成功指標を述べ、モデルに自身の前提を明示させます。ドラフトが、あなたが除外したばかりのマイグレーションを必要とするデータモデルを静かに前提にしているとき、PMがそれを捉えてソリューションを作り直します。同じモデル、同じ機能、違いはプロンプトの両側にいる人間だけです。

## TASK
Draft a one-page spec for saved search filters.

## CONTEXT
- Problem: power users re-apply the same 5 filters every day
- Constraint: ship in one sprint, no schema migration
- Success metric: % of searches that reuse a saved filter

## OUTPUT
Problem, non-goals, proposed solution, open questions.
Flag every assumption you make about our data model.

• 優れた例：問題と制約をフレーミングし、AIを使って素早くドラフトを作り、誤った前提を捉え、仕様書を実際のユーザーと指標に結びつける。
• 弱い例：AI生成の仕様書を、マイグレーションも含めてそのまま出荷し、プロダクト判断を一切重ねない。

優れた例がどれだけ言葉遣いと無関係かに注目してください。これをうまくやる候補者は、モデルにより良い呪文を唱えているのではなく、モデルが知るはずのない制約と、モデルが持ちえない懐疑心を持ち込んでいます。競合サマリータスクやリサーチ合成タスクに置き換えても同じパターンが成り立ちます。AIはもっともらしい成果物を生み出し、PMが加える価値はモデルが欠いていた特定のコンテキストや検証です。だからこそ、プロンプトのテンプレートでこれを偽ることはできません。テンプレートは簡単な半分であり、アウトプットが何を間違えているかについての判断こそが実際の仕事の半分です。

実際に効果のあるベストプラクティス

• 正確にフレーミングする。問題・制約・成功指標を前置きする——フレーミングが鋭ければ鋭いほど、ドラフトは有用になり、解きほぐすべき一般的な前提は減る。
• モデルに自身の前提を明示させる。それにより、洗練されたドキュメントに埋もれる前に、静かに誤った前提が表面化する。
• AIはドラフトに使い、決断には使わない。白紙の回避策であり、ユーザー・スコープ・トレードオフに関する判断の代替にはなれない。
• すべての主張を現実に根ざす。仕様書を、モデルが生み出したもっともらしい物語ではなく、実際のユーザー行動と指標に結びつける。
• 拡張ではなく削減する。最初のドラフトは積み上げる最小値ではなく、削り落とす最大値として扱う。

よくある失敗パターン

• ドラフトの出荷：整ったフォーマットのドキュメントを、よく考えられたものと混同する。
• 曖昧なフレーミング：問題文も制約も与えないため、モデルが自分で作り上げ、あなたがそれを引き継ぐ。
• デフォルトのスコープクリープ：実際の問題に削り落とさずに、モデルが過剰に追加した機能を受け入れる。
• 流暢なナンセンス：PMが個人的に検証できない領域での自信満々な回答を信頼する。

インタビューで注目すべきシグナル

ライブタスクを実施できない場合でも、会話で同じ行動を探ることができます。AIが生み出したものを使わなかった最後の経験を語るよう候補者に求め、欠陥を捉えた本物の話を聞きましょう——ツールへの曖昧な賛辞ではなく。最近のプロンプトをどうフレーミングしたか、モデルに前提を明示させたかを聞きましょう。サマリーや競合の主張が間違っていたとき、何をしたかを聞きましょう。テルは具体性です。強いPMは捉えた正確な前提とそれがなぜ重要だったかを説明し、弱いPMはどれだけすべてが速くなったかを説明します。懐疑心のない速さは注目すべき答えです。なぜならそれはたいていエラーが出荷されていることを意味するからです。

シニアリティによってシグナルがどう変わるか

バーは役職とともに上がります。ジュニアPMがAIを使ってクリーンな最初のドラフトを作り、メンターのフィードバックに照らして確認するのは、仕事をうまくやっています。シニアPMは促されることなく前提を捉え、どのモデルのアウトプットを信頼してよく、どれにはドメインエキスパートが必要かを知り、チームが下流でモデルの推測ではなく明確さを引き継ぐようにフレーミングを形作ることが期待されます。失敗パターンも規模が大きくなります。ジュニアの確認されていないドラフトはレビューサイクル1回分のコストですが、シニアの流暢だが間違った戦略メモは四半期のロードマップを誤った方向に導きます。だからこそ、シニア採用のインタビューでは、AIフルーエンシーをより軽視するのではなく、より重視すべきです。

プロダクトマネージャーのプロンプトエンジニアリングをどう評価するか

ケーススタディのスライドデッキは、誰かがモデルのドラフトにある誤った前提を捉えられるかを教えてくれません。AIを禁止することは、PMがすでに離れたワークフローをテストするだけです。だから正直なアプローチは、候補者に実際に使うツールを使った現実的なプロダクトタスクを与え、その上に重ねる判断力を観察することです。それがAI Sandbox評価の行うことであり、ドキュメントではなく行動をスコアリングします。それはより広い全体像の中にあります。AIフルーエンシーは、認知・ドメイン・状況判断・行動シグナルとともに、私たちが完全な評価の柱として扱う5つの測定可能な次元のひとつです。

AIフルーエンシーが比較可能なスコアになる具体的な仕組みについては、AIフルーエンシーが柱としてどう評価されるかをご覧ください。プロンプトエンジニアリングがより広い役割にどう位置づけられるかについては、プロダクトマネージャー採用ガイドをご覧いただくか、プロダクトマネージャー評価の全体像をご覧ください。ワークサンプルタスクがこの点でなぜインタビューより優れているかを理解したい方は、役割に合わせた評価の作成をご覧ください。

AIはすべてのプロダクトマネージャーに素早い最初のドラフトを与えます。採用に値する人材は、そのドラフトを思考の終わりではなく始まりとして扱います——その違いは、彼らが捉える前提に表れます。