ai-product-canvas

AI プロダクトキャンバススキル

データ、モデル、評価、責任ある AI のための追加レイヤーを設けつつ、あらゆるプロダクトの意思決定と同じ厳密さで AI プロダクトを定義します。このキャンバスは、AI プロダクトで最もよくある失敗、つまり技術的には印象的でも実際の問題を解決しない機能を構築してしまうことを防ぎます。

最初に確認する AI プロダクトのアンチパターン

構築を始める前に、以下のいずれかに該当する場合は注意してください。

• ❌ ユーザーの問題を定義せずに「既存機能に AI を追加すべき」と考えている
• ❌ 構築開始前に精度目標が定義されていない
• ❌ モデルが間違えた場合の対応計画がない
• ❌ 人によるレビューやフォールバックのない、ユーザー向けの AI 出力
• ❌ 学習データのバイアスや品質が監査されていない
• ❌ 評価指標がない — 「見ればわかるはず」と考えている

---

AI プロダクトキャンバスの出力形式

AI プロダクトキャンバス — [機能名] — [日付]

PM オーナー： [名前] ML／AI リード： [名前] ステータス： 発見／設計／構築／評価／公開中

---

1. 問題の定義

解決するユーザーの問題：

[ユーザーはどのような具体的な状況にいますか？どのような用事を済ませようとしていますか？]

なぜ AI なのか？

[この問題に、決定論的な解決策ではなく AI が必要なのはなぜですか？答えが「できるから」であれば、ここで止めてください。]

ユーザーにとっての成功とは：

[AI 機能が適切に動作したとき、ユーザーはどのような結果を得ますか？]

---

2. AI のアプローチ

タスクの種類：

• 分類
• 生成（テキスト、画像、コード）
• 要約／抽出
• 推薦
• 検索／取得
• 予測／予報
• 会話／エージェント

モデルのアプローチ：

• LLM API（GPT-4、Claude、Gemini など）— 指定：［モデル名＋バージョン］
• 独自データでファインチューニングしたモデル
• ゼロから学習させたカスタムモデル
• RAG（検索拡張生成）
• 埋め込み＋ベクトル検索

選択したアプローチの根拠： [代替案ではなく、これを選ぶ理由]

---

3. データ要件

データの種類	ソース	量	品質の状態	バイアスのリスク
[学習データ]	[入手元]	[量]	[監査状況]	H/M/L
[評価データ]	[入手元]	[量]	[監査状況]	H/M/L

データの不足： [不足しているものと、それを入手する計画] プライバシーに関する考慮事項： [学習データまたは推論データに個人識別情報（PII）が含まれているか] データの所有権： [このデータを所有していますか？学習に使用できますか？]

---

4. 評価フレームワーク

主要指標： [成功を定義する数値 — 正解率、F1、BLEU、ユーザー評価、タスク完了率] 最低許容しきい値： [X を下回る場合、機能を公開しない] 人による評価計画： [人がモデルの出力をどのようにレビューしますか？サンプリング率は？レビューパネルは？]

評価の種類	方法	頻度	担当者
オフライン（公開前）	[テストセット、ベンチマーク]	公開前	ML リード
オンライン（公開後）	[A/B テスト、ユーザーフィードバック]	毎週	PM＋ML
敵対的評価	[レッドチーム、エッジケース]	公開前	安全性レビュアー

---

5. ユーザー体験の設計

AI の出力をどのように提示しますか？

• 出力をそのままユーザーに表示（高い信頼が必要）
• AI が支援し、ユーザーが確認
• ユーザーが採用／拒否できる提案
• 監査ログを伴うバックグラウンド処理

信頼度と不確実性への対応：

• 信頼度が低い場合、どうなりますか？［代替案を表示、確認を求める、手動対応にフォールバック］
• 不確実性をユーザーにどのように伝えますか？［UI パターン］

フォールバック計画：

• モデルが失敗する、またはエラーを返す場合：［具体的なフォールバック動作］
• 精度がしきい値を下回った場合：［緊急停止スイッチまたは段階的縮退の計画］

---

6. 責任ある AI のチェックリスト

• トレーニングデータのバイアス監査を完了している
• 属性グループごとの公平性を評価している（ユーザーグループによってパフォーマンスに差がありますか？）
• ハルシネーション／作話のリスクを評価し、軽減している
• ユーザーが AI の出力を確認し、修正できる
• オプトアウトの仕組みがある（ユーザーは AI 機能を無効にできますか？）
• 該当する場合、出力の生成元を確認できる（ユーザーは AI が生成したことを把握できますか？）
• ユーザーの同意なく、個人情報（PII）を使用していない
• 規制に関するレビューを完了している（GDPR、AI Act、業界固有の規制）
• モデルカード／ドキュメントを作成している

---

7. リリースとモニタリング計画

段階的な展開：［ユーザーの割合、段階的に拡大する基準］ モニタリング指標：

• モデルのパフォーマンス：［指標＋アラートしきい値］
• AI 出力に対するユーザーの反応：［受け入れ率、上書き率、フィードバックスコア］
• エラー率：［推論失敗の割合］
• レイテンシ：［P95 の目標値］

モデルの更新頻度：［モデルの再トレーニングまたは更新の頻度］ ドリフト検出：［本番環境でモデルのパフォーマンスが低下したとき、どのように検知しますか？］

---

ガイドライン

• 「なぜ AI なのか？」の項目を省略しないでください。これは AI 製品開発で最も重要な問いです。
• フォールバック UX は必須です。AI が失敗したときの挙動が、製品の信頼性を左右します。
• 責任ある AI のチェックリストは、リリース後ではなく、リリース前に完了させてください。
• 成功指標にはレイテンシを含めてください。AI の応答に 5 秒かかるなら、何もないほうがよい場合が少なくありません。
• まずは人間が介在する設計から始め、精度が実証されてから自動化することをおすすめします。

必須入力

与えられた情報をもとに作業してください。以下の項目が不足している場合でも、完全な出力を作成してください。不足箇所は妥当な仮定で補い、(仮定、要確認) と記して、最後に仮定を列挙してください。中心となる題材そのものが不足している場合（書く対象が何もない場合）に限り、最初に質問してください。

• 機能または製品の説明（AI が何をする想定なのか）
• ユーザーの課題（AI がユーザーのどの課題を解決するのか）
• 利用可能なデータ（どのようなトレーニング／推論データがあるのか）
• ML／AI の責任者（技術的な実装を誰が担当するのか）

アンチパターン

• 「なぜ AI なのか？」という問いを省略しないでください。答えが「AI を使いたいから」であれば、いったん立ち止まり、まずユーザーの課題を軸に考え直してください。
• 正確性のしきい値を定めずにリリースしないでください。「十分に良い」はしきい値ではありません。構築を始める前に数値を設定してください。
• AI が生成した出力を、あたかもシステムの確定情報であるかのように隠す UX を設計しないでください。ユーザーが必要に応じて上書きできるよう、AI が関与していることを知らせてください。
• 責任ある AI のチェックリストをリリース後まで先送りしないでください。バイアスやプライバシーの問題は、設計段階よりも本番環境で修正するほうがはるかに困難です。
• モデルのレイテンシをリリース後に最適化すればよい問題として扱わないでください。1 秒のルールベース応答を置き換えるのに AI の応答が 6 秒かかるなら、それは機能追加ではなく性能の後退です。

品質チェック

• 「なぜ AI なのか？」に明確に答えている（「使えるから」ではない）
• 構築を始める前に、許容できる最低限の正確性のしきい値を定めている
• モデルの失敗や信頼度の低い出力に対するフォールバック UX を指定している
• 責任ある AI のチェックリストを完了している（リリース後まで先送りしていない）
• モニタリング計画に、モデルのパフォーマンスとユーザーの反応の両方の指標が含まれている

トリガーフレーズの例

• 「AI を活用した機能を構築する。」
• 「LLM の統合を評価する。」
• 「AI 製品を設計する。」
• 「AI を導入する準備ができているか評価する。」