採用 · July 21, 2026 · 約7分

プロダクトマネージャーのためのプロンプトエンジニアリング: AIが草案を書き、判断が決める

PMはAIから数秒で仕様書の草案を得られる — リスクはそれをそのまま出荷することだ。真のスキルは問題を的確にフレーミングし、次に欠陥のある前提を見抜き、過剰に盛り込まれたスコープを削ぎ落とすことにある。具体例と評価方法を交えた実践ガイド。

← 「The five pillars of a hire: what great assessments actually measure」の一部

プロダクトマネージャーは、仕様書の初稿、優先順位付け、競合サマリーをAIから数秒で得られる。魅力的なのはそれがいかに完成して見えるかという点だ。危険なのもまさに同じ点だ。モデルは、静かに間違った前提の上に、自信たっぷりで整った書式のドキュメントを作り上げる — そしてそれをそのまま出荷するPMは、この仕事が本当に存在する理由そのものを外部委託してしまっている。これは当社の役割別プロンプトエンジニアリングシリーズにおけるプロダクトマネジメント編であり、AI Sandboxが最も明確に浮かび上がらせるものの一つだ。

フレーミングこそがプロダクト思考だ

優れたPMのプロンプティングの半分は、モデルが実行される前に起きる: 問題、制約、成功指標を的確にフレーミングすることだ。そのフレーミングはプロンプトの小技ではない — それは明示化されたプロダクト思考そのものだ。モデルに鋭い問題定義を与えれば有用な草案が返ってくる。「保存フィルターの仕様を書いて」と与えれば、モデルは汎用的な前提で隙間を埋める。もう半分は、その草案をどう扱うかだ: 欠陥のある前提を見抜き、モデルが過剰に盛り込んだスコープを削り、実際のユーザーと指標に根ざさせる。それがPMの席におけるAIフルーエンシーだ。

具体例で見る

保存フィルター機能の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を使い、決定のためには決して使わない。それは白紙の治療薬であって、ユーザー、スコープ、トレードオフに関する判断の代替ではない。
• あらゆる主張を現実に根ざさせる。仕様を、モデルが生成したもっともらしい物語ではなく、実際のユーザー行動と指標に結びつける。

よくある失敗パターン

• 草案をそのまま出荷: 整った書式のドキュメントを、よく考え抜かれたものと取り違える。
• 曖昧なフレーミング: 問題定義も制約もないため、モデルが自ら勝手に作り出す — そしてあなたがそれを引き継ぐ。
• デフォルトでのスコープクリープ: 実際の問題まで削り込むのではなく、モデルが過剰に盛り込んだ機能を受け入れてしまう。

当社の評価方法

ケーススタディのスライドデッキでは、誰かがAIの草案の中の欠陥のある前提を見抜けるかどうかは分からないし、AIを禁止することはPMがすでに後にした作業フローをテストすることになる。候補者に、実際に使うツールを備えた現実的なプロダクトタスクを与え、その上に重ねる判断を観察する — それがまさにAI Sandbox評価が行うことであり、AIフルーエンシーが一つの柱として採点される方法だ。完全なプロダクトマネージャー評価が何をカバーするか、なぜこれがAIネイティブ採用における誠実なテストなのか、あるいは役割に合わせた評価が組み立てられる様子を見ることができる。

AIはすべてのPMに速い初稿を与える。雇う価値のある者は、その草案を思考の終わりではなく始まりとして扱う — そしてその違いは、彼らが見抜く前提に表れる。