PMのためのAIワークスペース：仕様書、リサーチ、説明資料を1つのツールで

PMの1週間で、AIが実際に役立つ場面

プロダクトマネジメントは、1つのカレンダーの上に4つの異なる仕事が乗っているようなものだ。大量に読み(フィードバック、チケット、書き起こし、分析データのエクスポート)、大量に書き(仕様書、進捗更新、ブリーフィング)、少し分析し(ファネル、コホート、アンケート結果)、常に人を説得している。それぞれが得意とするモデルは異なるため、1つのAI契約だけでは仕事の3分の2ほどしかカバーできず、残りが常に苦戦する原因になる。

PMの業務	最適なモデル	理由
PRDの文章、課題定義、進捗更新	Claude	長い論旨を保持でき、エンジニアが実際に読む文章を書く
フィードバックのテーマ分け、チケットのクラスタリング、構造化抽出	GPT	厳密な出力形式と一貫したカテゴリ分類が得意
ディスカバリー調査、競合スキャン、市場動向の把握	Gemini	最新のウェブ情報に強く、開けるソースを返してくれる
長い書き起こし、リサーチ資料、100ページの報告書	Gemini	100万トークンのコンテキストウィンドウで、資料全体を一度に扱える
仕様書のレビューとエッジケースの洗い出し	仕様書を書いていない別のモデル	書いた本人には見えないものを、別の読み手が拾う

これは何を作るべきかという判断の代わりにはならない。だが、材料がそろってから文章として形になるまでの距離を縮めてくれる。そこがPMの1週間で実際に時間が漏れている場所だ。モデルの切り替えコストも小さい。Whizi Proでは、Claude Sonnet 5の1メッセージは月2,000クレジットの割り当てのうち10クレジット、GPT-5.6 Lunaでの抽出は1クレジット、Gemini 3.7 Flashでの書き起こし読み込みは1メッセージ2クレジットで済む。

エンジニアに差し戻されないPRDの書き方

AIが書いた仕様書の多くは、同じ理由でつまずく。機能を説明しているだけで、決定を書いていないからだ。エンジニアリングチームが必要としているのは、顧客がなぜ大事かという段落ではない。状態、エッジケース、呼び出しが失敗したときに何が起きるかだ。それを明示的にプロンプトに入れると、出力の質が変わる。

プロンプト：まず課題定義から

PRDの課題定義セクションを書いてください。手元の根拠：[サポートチケット、分析データ、インタビューの引用を貼り付け]。解決策は提案しないでください。誰が、どのくらいの頻度でこの課題を抱えているか、現在はその代わりに何をしているか、それによって何が失われているか、解決した場合に何が変わると期待できるかを返してください。貼り付けた根拠に裏付けられていない主張には ASSUMPTION と明記してください。

プロンプト：仕様書の本体

これをエンジニアリングチーム向けの仕様書に変えてください。機能：[説明]。カバーすべきユーザー状態：[一覧]。返してほしいもの：受け入れ基準付きのユーザーストーリー、空、読み込み中、エラー、権限なしを含むすべての状態、依存先が利用できない場合の挙動、プロパティ付きの分析イベント、未解決の論点。私が述べていない要件は作らないでください。仮定したことは末尾の別セクションにまとめてください。

プロンプト：レビューパス

見積もり前にこの仕様書をレビューするスタッフエンジニアとして振る舞ってください。問題点だけを挙げてください。未定義の挙動、抜けている状態、矛盾する要件、隠れた移行作業、リファインメントで追加質問を生みそうな箇所です。仕様書自体は書き直さないでください。

この3つ目のプロンプトは、仕様書を書いていないモデルで実行しよう。チームがリファインメントで挙げるであろう質問を確実に事前に洗い出してくれる。それを先回りして答えておくかどうかが、20分で終わるグルーミングと50分かかるグルーミングの差になる。

生のフィードバックを優先順位付けできる形にする

プロダクトマネジメントにおいて最も費用対効果の高いAI活用は、書くことではない。400件のフィードバックを、行動につなげられる形で読むことだ。手作業でやれば半日かかる。モデルをうまく使えば20分で終わる。ただし品質は、カテゴリを固定して分類させられるかどうかにほぼ左右される。

プロンプト：1回目のテーマ分け

ここに生の顧客フィードバックがあります。テーマごとにまとめてください。各テーマについて、ラベル、件数、言葉遣いから読み取れる深刻度、そのまま正確にコピーした代表的な引用、そのテーマがバグ、不足している機能、使い勝手の問題、期待とのずれのどれに当たるかを返してください。言い回しが似ていても、根本原因が異なるテーマは統合しないでください。引用は言い換えないでください。フィードバック：[貼り付け]。

プロンプト：既存の分類軸に合わせた2回目のパス

同じフィードバックを、次のカテゴリだけを使って再分類してください：[既存の分類軸を貼り付け]。当てはまらないものは理由を添えてUNCLASSIFIEDに分類してください。カテゴリ、件数、割合の表を返してください。

この2段階の構造が重要だ。1回目のパスでデータに実際に何があるかがわかる。2回目のパスで前四半期と比較できる形になる。それこそが、単に興味深いだけでなく、優先順位付けの議論で実際に使える結果にする理由だ。

何を依頼するか	何が得られるか	何に向いているか
件数付きのテーマ	課題領域のランキング	ロードマップへの入力、四半期計画
引用のみ	編集されていない顧客の生の言葉	コピー、ポジショニング、経営層への説得
深刻度と頻度の分割	痛みと件数の2軸マトリクス	何を先に直すかの判断
矛盾点	セグメント間で正反対の要望がある箇所	見せかけの合意を早期に発見する

最後の行は常設プロンプトにしておく価値がある。このフィードバックの中で、異なるユーザー同士が両立しないことを求めている箇所はどこですか。セグメント名とトレードオフを挙げてください。 テーマ一覧は意見の対立を平坦にしてしまいがちだが、データの中で最も有用なのはたいてい対立そのものだ。

ディスカバリー、競合、そしていつも時間がないリサーチ

ディスカバリーは、リリースが遅れたときに真っ先に削られる仕事だが、まさにそのときこそ悪い判断のコストが最も高い。モデルによる調査支援は顧客と話すことの代わりにはならないが、判断材料を持たずに意思決定に臨む言い訳は確実になくしてくれる。

プロンプト：競合分析

[競合]が[達成したいジョブ]をどう扱っているかの分析をまとめてください。カバーすべき点：自社の言葉で語られている彼らのポジショニング、ヘルプセンターに記載されているフロー、公開されている価格、直近12か月の変更点とその日付、公開レビューに見られる不満のテーマ。すべての主張にURLを添えてください。企業自身が述べていることと、第三者が観察していることを分けてください。

プロンプト：インタビューの統合

これらのインタビューの書き起こしを読んでください。返してほしいもの：ユーザーが達成しようとしているジョブ、彼らが編み出した回避策、正確な引用付きで不満を表明した瞬間、ユーザーが語ったことと実際の行動が矛盾している箇所。書き起こしの範囲を超えて一般化しないでください。あるパターンが3件未満のインタビューにしか現れない場合は、パターンではなく単一の観察として明記してください。

この最後の制約は、PMが最も忘れがちなものだ。モデルはきれいなパターンを作りたがる。2件のインタビューから作られたきれいなパターンが、存在しない顧客にロードマップを合わせてしまう原因になる。どの主張にも件数を添えて求めよう。

経営層向けの説明資料とローンチ告知

同じ内容を4つの高度で存在させなければならない。エンジニアリング向けの仕様書、チーム向けの進捗更新、経営層レビュー向けの一段落、そして顧客向けのローンチ告知だ。高度の間を書き直す作業は、この仕事の中で最も機械的で、最も他者に任せやすい部分でもある。

プロンプト：高度の変換

これを[対象読者]向けに書き直してください。彼らが気にしているのは[具体的な関心事]です。この製品領域について[レベル]の前提知識があります。事実に関する主張はすべて変えないでください。長さ：[制約]。背景よりも先に、決定や結果から始めてください。原文：[貼り付け]。

プロンプト：経営層向けの一段落

この進捗更新を、一度しか読まない経営層向けに120語に圧縮してください。構成：何が変わったか、コミットした指標にとってどんな意味があるか、彼らから何が必要か、注意を払う価値のある唯一のリスク。測定されていない形容詞は使わないでください。

プロンプト：事前検死

このローンチが6か月後に失敗したと仮定してください。以下の計画にある内容だけを使って、可能性の高い順に3つの説明を書いてください。それぞれについて、早期に観察できる兆候を挙げてください。計画：[貼り付け]。

この4つの高度をすべて同じWhiziのスレッド内に保っておこう。ローンチ告知は仕様書やフィードバック分析の文脈を引き継ぐので、読み手が変わるたびに機能をゼロから説明し直す必要がなくなる。

AIがプロダクトマネージャーを特に誤らせる場面

この仕事では、他の職種以上に重要になる失敗パターンが3つある。

捏造された引用。 ソースの文章にモデルを固定せずに代表的な引用を求めると、どの顧客も言っていないもっともらしい一文が返ってくることがある。必ず引用は正確にコピーし、言い換えないでくださいと指示し、スライドに載せる前にそのうち3件を生データと突き合わせて確認しよう。

少数サンプルへの過信。 モデルは8件のサポートチケットも800件と同じ確信度でテーマ分けしてしまう。すべてのテーマに件数を求め、数件程度の事例はシグナルではなく観察として扱おう。

ロードマップ演劇。 バックログの優先順位付けをモデルに依頼すると、チケットの文言以外には何の根拠もない自信満々のランキングが返ってくる。モデルには戦略も、リソースの余力も、技術的負債も、来四半期に成約する案件も見えていない。トレードオフを整理させるためには使ってよいが、判断そのものを任せてはいけない。