プロダクトにAIを。 確率的なふるまいと向き合う。

PM Kansai Meetup #1
LT資料です

イベント情報はこちら: https://product-manager-kansai.connpass.com/event/378281/

Transcript

1. プロダクトにAIを。 確率的なふるまいと向き合う。 PM Kansai Meetup #1 | 2026-01-22 @sugit PM Kansai Meetup #1 - 2026-01-22 1
2. sugit（すぎっと） X(Twitter): @sugitlab TechBowl 取締役COO/CPO PM/Eng/研究/技術営業/マーケ/経営 (雑食) 滋賀在住のフルリモPM PM Kansai Meetup #1 - 2026-01-22 2
3. お友だち紹介 プルとリクです。よろしくね。 PM Kansai Meetup #1 - 2026-01-22 3
4. 会場のみなさんに質問です AIを使ってますか？ AI機能を開発してますか？ PM Kansai Meetup #1 - 2026-01-22 4
5. 普通の機能とAI機能って、考えることがちょっと違 うんですよね。 というのが、今日のメインテーマです。 PM Kansai Meetup #1 - 2026-01-22 5
6. いつもの機能（決定論） 入力A → 出力B（いつも同じ） 仕様をifで書ける 再現できるので、切り分けとテストが楽 AI機能（確率的） 入力A → 出力が揺れる（同じにならないことがある） 仕様が「条件」じゃなくて「許容ライン」になる 再現しづらいので、「説明できるか」が設計課題になる PM Kansai Meetup #1 - 2026-01-22 6
7. 確率的って、どこがそんなに厄介なの？ AIが入ると、要件・QA・運用がまとめて変わるよ PM Kansai Meetup #1 - 2026-01-22 7
8. たとえば、 チャットボット 「こんにちは」→ 返答が毎回少し違う（確率的） ボタンで画面遷移 → いつも同じ（決定論） レコメンド機能 「おすすめを選ぶ」：確率的 「詳細へ遷移する」：決定論 つまり、システムの中に確率的なパーツが混ざってくる。 PM Kansai Meetup #1 - 2026-01-22 8
9. レコメンド機能のイメージ TechTrain メンターレコメンド (開発中) 困っていること 相談内容プレフィルタ マッチング処理 閾値判定 メンターリストアップ メンター稼働OKチェック 相談データ整形 確率的なパーツ がシステムのどこに、どう入るかを認識する PM Kansai Meetup #1 - 2026-01-22 9
10. 確率的だと、なにが困る？ を具体的に PM Kansai Meetup #1 - 2026-01-22 10
11. 困りごと① 要件定義が変わる YES/NOで書けない（正解が1つに決まらない） 「どのくらい良ければOK？」を言葉にしないとチームが動けない PMとしてやること： 許容ライン / NG例 / 評価指標（スコア）をPRDに入れる PM Kansai Meetup #1 - 2026-01-22 11
12. 困りごと② 認識が揃わない PM「体験としてこのくらいならOK」 Eng「技術的にはこのレベル」 QA「不具合？仕様？判断できない」 PMとしてやること： OK/NGの“採点基準”を合意する（評価関数・チェックリスト） PM Kansai Meetup #1 - 2026-01-22 12
13. 困りごと③ トラブル時に説明できない 「この結果、あってる？」に即答できない 「前は違った」への切り分けが難しい PMとしてやること： 説明責任のためのログと「あとから追える仕組み」を設計する PM Kansai Meetup #1 - 2026-01-22 13
14. ここまでの結論 AI機能を入れた瞬間、システムの一部が確率的になる。 だからPMは、仕様をYES/NOで書くだけでは足りない。 評価・ガードレール・説明責任を設計する。 PM Kansai Meetup #1 - 2026-01-22 14
15. じゃあPMは、どう戦えばいいの？ 戦い方はあるよ。5つに分けると整理しやすい PM Kansai Meetup #1 - 2026-01-22 15
16. 私なりの戦い方（5つ） 1. 確率的なパーツの前後を決定論で挟む（ガードレール） 2. Human in the loop（人の目を入れる） 3. 評価関数（YES/NOではなく点数） 4. 丁寧なログ設計（説明責任） 5. 評価（テスト）のOps（定期検査） PM Kansai Meetup #1 - 2026-01-22 16
17. ① ガードレール：前後を決定論で挟む 入力の構造化（フォーム/選択肢/制約） 禁止ワード・ポリシーフィルタ 出力フォーマット固定（JSON/テンプレ） フォールバック（ダメなら"わからない" or 既存導線へ） 狙い：揺れても体験のボトムを守る PM Kansai Meetup #1 - 2026-01-22 17
18. ② Human in the loop：最終防衛ライン 全自動が常に正義ではない リスク・コストが高い領域ほど、人の確認を設計で入れる PM Kansai Meetup #1 - 2026-01-22 18
19. ③ 評価関数：OK/NGを“点数”にする 100点を目指さず、許容ラインを決める チームで同じ物差しを持つ 10点満点のラフな評価シートを作っておくイメージ 例. 検証セット20件で平均8.5点以上 重大NG（安全性0点）が1件でも出たらリリース停止 PM Kansai Meetup #1 - 2026-01-22 19
20. ④ ログ設計：説明責任のための最低限 いつ・誰が・何を入れて・何が返って・なぜそうなったか （例） 入力（匿名化） プロンプトのバージョン管理 モデルなど主要パラメータ 参照データ（RAGの検索クエリ/上位ドキュメントIDなど） 前提、規約の設計も丁寧に。 PM Kansai Meetup #1 - 2026-01-22 20
21. ⑤ 評価Ops：定期検査を運用に組み込む テスト用のデータをもっておく モデル更新・プロンプト更新・データ更新のたびに(自動)評価する体制 定期的に品質を観測し、変化に早く気づく 完璧を求めず、継続評価で品質を保つ PM Kansai Meetup #1 - 2026-01-22 21
22. まとめ PM Kansai Meetup #1 - 2026-01-22 22
23. 「AI時代のプロダクトマネージャーの仕事」 AI時代のプロダクトマネージャーは 確率的なふるまい に立ち向かわなければいけない AI機能は“確率的なパーツ”をプロダクトに持ち込む PMは「評価・ガードレール・説明責任」を設計する PM Kansai Meetup #1 - 2026-01-22 23
24. PM Kansai Meetup #1 - 2026-01-22 24
25. ありがとうございました PM Kansai Meetup #1 - 2026-01-22 25