プロダクトマネージャーのワークフローにおけるAI:役立つ場面、破綻する場面
いまやどのPMツールにも「AI」のトグルがついています。Notion AIはPRDの下書きを作成し、Linearはsprintを要約し、Productboardはフィードバックからテーマを抽出し、Jiraは受け入れ基準を書きます。トグルはどこにでもありますが、そこから出てくるものの大半はスロップ(粗悪な成果物)です。エンジニアが3週目には読まなくなるスロップな仕様書。実は核心だった奇妙な引用を一つ平らに潰してしまうスロップなリサーチ要約。誰も求めていない機能を自信満々にランク付けするスロップな優先順位付けです。
Notion AIのPRD下書きをJiraにコピー&ペーストするPMは、エンジニアリングチームが静かにPRDを読まなくなるPMです。私はこの1年で3つのチームでこれが起きるのを見てきました。パターンは同じです。PMの作業は速くなり、エンジニアリングチームは静かになり、6週間後に誰かが間違ったものをリリースします。顧客に一度も会ったことのないモデルが仕様書を書いたからです。
ですから、これが正直な枠組みです。AIはワークフローの退屈な中間部分のためのレバレッジツールです。あなたが実際に対価を得ている2つのこと、すなわち判断力と顧客の真実の代わりにはなりません。この記事の残りでは、現役PMの視点から、AIがどこで元を取り、どこで全く役に立たないのか、プレッシャー下でも崩れないワークフローのパターン、そしてスキルを鍛える30日プランを見ていきます。
AIが役立つ場面(毎日使うべき領域)
退屈な中間部分は確かに存在します。それは機械的な統合、下書き作成、スキャン、パターンチェックといった、PM業務の60%を占める部分です。AIはこれが得意ですが、手綱を短く握っておくことが条件です。
インタビュー記録の統合。 ここが最もROIの高い出発点です。GongやGrainの記録を取り出し、全文(要約ではなく全文)をClaudeに貼り付け、特定のテーマごとにグループ化した逐語的な引用を求めます。うまくいくプロンプトの構造はこうです。「この記録から価格に関する反論についての逐語的な引用を抽出してください。話者が複数いる場合はペルソナごとにグループ化してください。言い換えはしないでください。話者が言葉を濁している場合は、その濁しも含めてください。」最後の一文が重要です。モデルは自信に満ちた要約をデフォルトとするため、質感が失われてしまうからです。
仕様書の下書き。 自分で書いた構造化されたブリーフを与えれば、ユーザーストーリー、エッジケース、受け入れ基準の初稿を作成できます。ブリーフこそが仕事の本質です。下書きは単なるタイピングにすぎません。問題提起、データモデルの前提、既知の3つのエッジケースを与えれば、使える土台を吐き出してくれます。それでも半分は書き直すことになります。それで構いません。書き直さなかった半分の時間を節約できたのですから。
競合スキャン。 8社の競合のチェンジログをモデルに投入し、あなたのロードマップとの差分を尋ねます。彼らのリリースのうち、あなたも対象とする顧客セグメントに当たるものはどれかを尋ねます。これはかつて金曜日の半分を食いつぶしていた地味な作業です。いまでは20分で済み、残りの時間はそれにどう対応するかを決めることに使えます。これこそが本来の仕事です。
フェイクドアのバリエーション文案。 A/B testのためにランディングページの見出しを6本生成する。これは問題ありません。どのフェイクドアを実施するかという戦略を生成する。これは問題です。モデルは表層は得意ですが、選択は不得意です。表層のために使いましょう。
コホート分析の妥当性チェック。 SQLの結果テーブルを貼り付け、「ここに足りないものは何か、懐疑的なデータサイエンティストなら何に反論するか」と尋ねます。分析を求めているのではありません。あなたのコホートが汚染されていないか、期間の取り方がおかしくないか、フィルターが重要な母集団を除外していないか、という点に第二の目を求めているのです。これは初歩的なミスを拾ってくれます。その価値はあります。
AIが破綻する場面(毎回、自分でやるべきこと)
ここは大半の「PMのためのAI」記事が飛ばす部分です。ツールが売れないからです。しかしこここそが、2年後にあなたが仕事を続けられるかどうかを決める部分です。
問題のフレーミング。 「私たちは実際に何を、誰のために解決しているのか」という一文は、あなたの仕事です。常にそうです。モデルは、それまで読んできた他のあらゆるフレーミングと同じように流暢に聞こえるフレーミングを生み出します。あなたのフレーミングは、あなたの顧客、あなたのデータ、市場におけるあなたの瞬間に固有のものでなければなりません。もしあなたのフレーミングが、そのカテゴリーのどの企業にも当てはまりそうに読めるなら、仕様書の中で最も重要な一文を外注してしまったことになります。
優先順位付けの重み付け。 LLMが出すRICEやICEの数値は感覚です。reach(到達)の数値は、来四半期にどのセグメントを狙うかについてマーケティングと実際に交わした会話から生まれます。effort(工数)の数値は、テックリードとの10分間の会話から生まれます。confidence(確信度)の数値は、これについて実際に何人の顧客と話したかから生まれます。これらの数値はどれも、あなた固有のロードマップに関してモデルの学習データには存在しません。AIにスコアを生成させると、優先順位付けで最も価値の低い部分(計算)を自動化し、最も価値の高い部分(その入力値を生み出したトレードオフの会話)を飛ばしてしまうことになります。
顧客の真実。 生の記録を自分で読まずに、AIに12件のインタビューを3つのテーマに要約させてはいけません。モデルは中央値に向かって圧縮します。実際のインサイトはほぼ常に外れ値にあります。誰も言わなかったことを、あなたの前提を組み替えるような形で言った、たった一人の顧客です。圧縮は外れ値を殺します。記録を読みましょう。AIは引用の抽出に使い、結論の抽出には使わないことです。
スコープ削減に関する判断。 モデルは締め切り前にスコープを削るためのあらゆる選択肢を列挙できます。しかし、エンジニアが疲れ、デザイナーが守りに入り、GMが当初のコミットメントを望んでいるとき、その場をまとめることはできません。それはプロンプトの問題ではありません。「実際にその場にいなければならない」という問題です。
実際に機能するワークフローのパターン
私が毎週回しているいくつかのパターンです。どれも巧妙なものではありません。要点は、退屈で再現可能だということです。
インタビュー統合のためのGong/GrainとClaudeの組み合わせ。 正確なパターンはこうです。通話を録音します(セールスに紐づくディスカバリーコールならGong、純粋なリサーチならGrain)。記録の全文を取り出します。新しいClaudeの会話に貼り付けます。要約プロンプトではなく、厳密な抽出プロンプトを使います。モデルが浮かび上がらせた上位2〜3件の引用について、元の記録を読んで検証します。モデルが重要な部分を言い換えていたら、その出力を破棄し、より厳密な言葉で再プロンプトします。検証のステップこそが仕事です。これを飛ばすと、顧客が言っていないことを言ったと引用してしまい、ステークホルダーへの報告の場ではキャリアを終わらせかねない行為になります。
元を取れるプロンプトを、逐語的に紹介します。
あなたは顧客インタビューの記録から引用を抽出します。以下に記録を貼り付けます。あなたの任務は、話者が価格、予算、調達について言及している直接の引用をすべて取り出すことです。言い換えはしないでください。要約はしないでください。話者の言葉の濁し、つなぎ言葉、矛盾をそのまま保持してください。可能であればタイムスタンプ付きの箇条書きで返してください。関連する引用が存在しない場合は「引用は見つかりませんでした」と述べ、捏造しないでください。
「捏造しないでください」の一文が重要です。これがないと、モデルはもっともらしく聞こえる引用を幻覚します。
仕様書を加速するCursor。 これはエンジニアリングチームも使っている場合に限って有用です。Cursor(またはチームが採用しているAIペアコーディングツール)は、エンジニアが同じエディタでコードを書きながらあなたの仕様書を読んでいることを意味します。彼らが使っていてあなたが使っていなければ、あなたの仕様書は実際にコードが書かれる方法から乖離していきます。どちらも使っていないなら、それで構いません。従来のやり方で仕様書を書きましょう。罠は、PMが一人で使い、エンジニアリングチームも自分と同じように仕様書を体験していると思い込むことです。確認しましょう。彼らのワークフローに合わせましょう。
「AIが書いたPRD」の罠。 エンジニアは偽のPRDを即座に見抜きます。その兆候はこうです。汎用的なエッジケース(「ネットワーク障害を適切に処理する」)、正しく聞こえるが実際のデータモデルを外している受け入れ基準(「ユーザーは設定を保存できる」)、そして実際に製品を使うことから生まれる雑然とした具体性が怪しいほど欠けていること。嗅ぎ分けのテストはこうです。仕様書のすべての行をスタンドアップで弁護できないなら、スタンドアップの前に削除しましょう。
ドキュメントを出す前に回す価値のあるPRDの嗅ぎ分けチェックリストです。
- これを求めた顧客の名前を挙げ、その言葉を引用できるか?
- メモなしでホワイトボードにデータモデルを描けるか?
- 私のエッジケースは汎用的なものではなく、私たちの実際のエラー状態を参照しているか?
- 明示的に作らないものを少なくとも一つ、その理由とともに挙げたか?
- テックリードがこの仕様書を読んで、すでに知っていた以上のことを学べるか?
いずれかの答えがノーなら、その仕様書は薄すぎます。AIは助けになっていません。弁護できない下書きを出す手助けをしただけです。
ACEフレームワークのレンズ(任意)
戦略デッキを十分に読んでいれば、ACEフレームワークに出会うでしょう。Ingest(取り込み)、Analyze(分析)、Predict(予測)、Generate(生成)、Execute(実行)です。PMはAnalyzeとGenerate(統合と下書き作成)に最も近い位置にいます。この記事のレバレッジが存在するのはまさにそこです。Ingest(データの配管、ETL、埋め込みパイプライン)は通常データエンジニアリングに属します。Execute(人間を介さずに動くワークフロー自動化)は通常オペレーションやプラットフォームに属します。
これを暗記する必要はありません。しかし、AI機能があなたのロードマップに上った瞬間、エンジニアリングリードやデータチームがこれらの言葉を使うため、語彙を知っておく価値はあります。どのケイパビリティを購入し、どれを内製するのかをすでに理解していれば、会議を一つ省けるでしょう。
スキルを鍛える30日プラン
4週間。一度に一つのワークフロー。ツールの乱立はなし。要点は、締め切りのプレッシャー下でも信頼できる、再現可能な小さな動きのセットを築くことです。
第1週:一つのワークフローを選び、2回回す。 記録の統合が最もROIの高い出発点です。今週の顧客インタビューを一つ選びます。まず手作業で統合します。記録を読み、驚いたことを3つ書き留め、それを裏付ける逐語的な引用を列挙します。次に同じ記録を抽出プロンプトでClaudeに通します。比較しましょう。2つのことが学べます。モデルがどこで速度を加えるか、そして何を静かに落とすか、です。どちらも重要です。
第2週:自分のプロンプトライブラリを書く。 4〜6個のプロンプトを、共有ドキュメントでバージョン管理します。一つは記録の抽出用。一つはブリーフからの仕様書の土台作り用。一つは競合スキャン用。一つはSQLの妥当性チェック用。もしかしたら一つはフェイクドアの文案バリエーション用。それだけです。6個を超えるプロンプトがあるなら、使うのではなくツールを集めているだけです。各プロンプトには、明確な入力形式、明確な出力形式、そして出力を信頼する前に何を検証すべきかについての一行メモを添えるべきです。
第3週:チームメイト一人に見せる。 あなたのプロンプトを別のPMかテックリードに渡します。実際のタスクで一つ使ってもらいます。あなたが横で見張っていないと出力を再現できないなら、そのプロンプトは脆すぎます。脆いプロンプトは単一障害点です。あなたが病欠した日には、ワークフローが止まります。移転可能になるまでプロンプトを締めましょう。
第4週:監査。 2列です。左の列:今月AIが節約してくれたもの(時間、加速した意思決定、タイピングせずに済んだ下書き)。右の列:それがエンジニアリングとの、顧客との、あなた自身の判断との信頼において何を犠牲にしたか。正直になりましょう。あるプロンプトがエンジニアに突き返された仕様書を生んだなら、それを書き留めます。ある統合が、後で自分が拾った外れ値を見落としていたなら、それを書き留めます。役割を果たさなかったものは切ります。果たしたものは残します。これであなたには、感覚ではなくワークフローができます。
前四半期、私はあるディスカバリーサイクルでこのやり方の一種を試しました。第1週は疑っていました。第3週までにインタビュー統合の時間をおよそ半分に削りましたが、生の記録に照らして検証していないテーマ要約を危うくリリースしそうになった自分を捕まえました。第4週の監査では、統合プロンプトは残しました。「12件のインタビューをテーマに要約する」プロンプトは削除しました。これがそのスキルです。
静かな結びの主張
次の2年を制するPMは、最も多くのAIを使う人ではありません。最も長いツールスタックを持つ人でも、Notion上で最も多くスターがついたプロンプトライブラリを持つ人でもありません。AIがどこで機能しなくなるかを正確に知り、仕事のその部分を守る人です。問題のフレーミング。優先順位付けの重み付け。顧客の真実。締め切りのプレッシャー下での判断です。
それ以外はすべて使ってよい領域です。ツールを使いましょう。時間を節約しましょう。しかし、節約した時間は、モデルにはできない仕事の部分に使いましょう。顧客が実際に何を言っているのか本当に理解できるまで顧客と向き合うこと、その場で正しいスコープ削減のために戦うこと、チームの次の12週間を一貫させる仕様書の一番上の一文を書くことです。
それが仕事です。AIはてこであって、代わりではありません。
さらに詳しく
Principal Product Marketing Strategist