AIを使うプロダクト開発｜PdMが押さえるべき設計・実装・検証の型

「AIを使えば効率化できるはず」──そう思ってPoCを始めたPdMは多いのではないでしょうか。

私自身、最初にAI導入を検討したときは、正直“夢を見ていた”と思います。社内には「ChatGPTを組み込めば回答業務が自動化できる」「問い合わせはAIで十分」といった期待が溢れ、PoC（概念実証）もスピーディに立ち上がりました。ところが、間もなくわかったのは、「AI導入＝価値提供」ではないという厳然たる現実です。精度が上がっても、ユーザーは必ずしも幸せにならない。求められていたのは、AIの有無ではなく“いつ・どの文脈で・どの粒度で介入するか”の設計でした。

AI導入が失敗する理由は「設計」より前にある

どこからAIを使うか──この問いに飛びつく前に、まず押さえるべきは「体験の構造」です。ユーザーがどんな場面で戸惑い、どんな瞬間に安心を求め、どの単位の作業に時間を奪われているか。ここを見誤ると、AIは“賢いのに使われない”存在になります。

例えば、FAQチャットのAI化を検討したとき、ユーザーは「回答の速度」よりも「自分の状況を理解された感覚」を求めていました。つまり、情報の正確さ以上に、文脈理解と提示タイミングが重要だったのです。PdMの仕事は、AIの実装ではなくAIが活きる環境の設計にあります。

PoCで終わらせない「3つの型」──深掘り

生成AIを扱うPdMには、①観察の型／②設計の型／③検証の型が必要です。以下では、それぞれを「なぜ必要か」「価値」「どうやるか」「よくある失敗」「現場の具体」の順で掘り下げます。

① 観察の型：AI導入前に“どこで何が奪われているか”を定量×定性で捉える

なぜ必要か：AIは“なんでも屋”ではありません。間違った地点に置けば、速くても邪魔になります。観察は、AIの出番を誤らないための前提作業です。ユーザーが時間を奪われている箇所は、必ずしも作業時間の長い場所ではなく、「迷いが生まれる分岐点」や「手戻りが発生する境目」に潜みます。ここを取り逃すと“自動化したのに体験は軽くならない”という矛盾が起きます。

価値：観察は、AI導入のROIを事前に見立てる材料になります。投入前から「どの秒数（体験単位）を減らすか」「どの誤入力（品質単位）を減らすか」を言語化できれば、PoCの評価軸がブレません。結果としてPoC疲れ（やって終わり）を避け、施策の優先度付けが明確になります。

どうやるか：定量では、ファネル分解（到達→入力→確認→送信→完了）、各段の滞留・離脱・やり直し率、滞在の偏り、検索クエリやFAQ閲覧ログの遷移を見ます。定性では、シンクアラウド面談、画面録画の実況レビュー、問い合わせの“言い換え”収集、現場メンバーのヒアリング。“迷い語彙”（例：「どれを選べば」「これは必要？」）を辞書化し、迷いが生じるタイミングのトリガー（項目名、行間の説明不足、専門用語）をマークします。

よくある失敗：サンプル数は多いのに、分岐の瞬間を見ていない。平均滞在時間や満点NPSだけでは、AIの出番は見えません。もう一つは、ログ設計が粗く、迷いの痕跡（再入力／同一画面往復）が拾えていないことです。

現場の具体：入力フォームの支援では、再入力の起点項目と同一画面往復を取ります。CSチャットなら、1発目の意図（高頻度カテゴリ）と最終解決に辿り着いたルートを突き合わせます。観察の成果は、後述の「設計の型」でAIを置く場所（入力補助／意図認識／要約／提案）に直結します。

② 設計の型：AIの“役割と境界”をはっきり決める

なぜ必要か：AIは強力ですが、やりすぎると体験を壊します。人が主役の場面にAIが前面に出ると不信感が生まれ、逆にAIが主役の場面で人が割り込むとスピードが落ちます。設計の型は、誰がどこまでを明確にし、AIを“適材適所”に置くための思考枠組みです。

価値：役割と境界を定義すると、保守容易性と安全性が上がります。例えば、LLMの出力がUIに直結せず必ずポリシー層を通るようにすれば、ハルシネーションやトーン逸脱の影響範囲を限定できます。結果として現場に安心感が生まれ、導入後の内製スピードが上がります。

どうやるか：AI適用レイヤーを以下の4つに分け、各レイヤーの入出力と責任境界を設計します。

• Input支援：意図認識、フォーム補完、言い換え。人が主語で、AIは手元の補助。
• 推論・生成：要約、類似検索、文脈統合、意思決定の根拠整理。AIが中盤を支える。
• ツール呼び出し：外部API連携、計算、DB検索、ワークフロー実行。AIはオーケストレータ。
• 出力の監査・提示：ガードレール、根拠表示、信頼スコア、編集の余地。人が最終責任。

この4層に、ポリシー層（安全・禁止・言い回し）とナレッジ層（根拠データ、RAGの索引）を横断させます。UIは“AIの提案を受け取りやすい余白”を確保し、強制ではなく選択可能に。価値提供型PdMの設計図 の考え方と整合します。

よくある失敗：万能エージェントを作ろうとして、全シナリオを一人のAIに背負わせること。結果として、トーンや制約が混線し、保守が破綻します。現場では、複数の“小さな役割AI”を協調させる方が安定します。

現場の具体：オンボーディングでは、AIが初稿を自動生成し、担当者が仕上げる“二人三脚”にします。問い合わせ対応では、AIが候補回答＋根拠リンクを提示し、オペレータが選択。どちらも「提案→選ぶ」に寄せることで、負担は減りながら主導権は人に残ります。

③ 検証の型：精度だけでなく“使われ方とタイミング”を検証する

なぜ必要か：LLMは非決定的です。オフライン指標が良くても、プロダクトの中で価値が出るとは限りません。検証の型は、「正しく機能するか」から「正しいタイミングで使われるか」へ評価軸を拡張します。

価値：投入・撤退の判断がクリアになり、“便利だけど邪魔”を避けられます。タイミング検証が通ると、AIは自然に利用され、体験全体のストレスが減ります。

どうやるか：評価指標は「出力の品質」だけでなく、「介入の適切さ」と「体験の連続性」を含めます。例として、提示頻度の最適化（出しすぎ抑制）、人へのエスカレーション率、AI提案経由の完了率、再編集の発生率など。実験は小さく素早く、ログ粒度（入力の迷い、意図の揺れ、ツール呼び出しの失敗など）を先に決め、カナリア→A/Bの順で進めます。

よくある失敗：“常時オン”でAIを出し続け、ユーザーが学習してしまうこと。人は“余計な提案”に早く飽きます。介入は「困り」のシグナル（滞留、往復、削除→再入力）をトリガーに、必要十分だけ提示します。

現場の具体：フォームでのAI補助は、曖昧語の入力時や、同一フィールド3回以上の修正時にのみ出す。CSでは、FAQ既読→再質問のパターンのみに候補文を提示し、最初から全面AI対応にしない。これだけで体験の“押し付け感”が減り、自然に使われます。

現場で機能するAI設計の手順

導入の前に、以下の3ステップで“体験の土台”を固めてから実装に入ります。

1. 観察の型を回す：ファネル／再入力／往復／迷い語彙の辞書化。AIの出番となる「分岐点」を確定。
2. 設計の型で役割分担：Input支援／推論・生成／ツール呼び出し／出力監査。ポリシー層・ナレッジ層を横断設計。
3. 検証の型でタイミング評価：提示頻度・エスカレーション・提案経由完了・再編集の4象限で実験。

この順番を崩さないだけで、PoCで終わらずプロダクトに根付く確率が一気に上がります。

実務で使うログ雛形（観察→設計→検証の循環）

{
  "ts": "ISO8601",
  "userId": "hashed",
  "intent": "分類（例：入力補助/確認/問い合わせ）",
  "ui_state": {"page":"id","field":"name","attempt":2},
  "signals": {"hesitation": true, "back_and_forth": 1},
  "ai": {
    "invoked": true,
    "tools": ["search","calc"],
    "confidence": "low/med/high",
    "policy_flags": ["tone_adjusted"]
  },
  "result": {"completed": true, "handoff": "human/none"},
  "notes": "迷い語彙：どれ/必要？ など"
}

PoC疲れを防ぐためのアンチパターン

• “AIを前面に”の思い込み：常時オンの提案は、現場で摩耗を生むだけ。
• 万能エージェント幻想：一体で全部やらせるより、小さな役割AIの協調で安定させる。
• オフライン精度主義：プロダクト内の使われ方とタイミングを見ないと、体験価値は上がらない。
• ログ後付け：検証の指標が曖昧なまま実装し、後から評価不能に陥る。

まとめ：PdMがAIを“使う側”で終わらせない

生成AIは魔法ではありません。けれども、観察→設計→検証を一貫して回すと、AIは“道具”から“チームの一員”へと変わります。介入ポイントは小さく、役割は明確に、検証はタイミング重視で──これが、PoCで終わらせないための現場の型です。

次回は、PdMが実務で使うべき生成AIツール群を、フェーズ別（発見／設計／実装／運用）に整理して解説します。

内部リンク：価値提供型PdMの設計図