AI プロダクト要件定義書テンプレート：14 項目と記入例

「AI PRD」が意味する二つの仕事を分ける

プロダクト要件定義書、つまり PRD は、特定の判断に必要な問題、期待する成果、求める動作、対象範囲を説明する文書です。Atlassian のテンプレートには、目的、前提、要件、関連設計、未解決の問いが含まれています。PRD は機能一覧以上のものだと分かります。本記事の 14 項目は編集上の構成であり、業界で義務付けられた書式ではありません。Atlassian の PRD テンプレート

AI による執筆支援では、使用を許可された材料の整理をアシスタントに任せます。作る機能は、エクスポート形式の追加など、AI を使わないものでも構いません。ただし、不足する事実や相反する依頼を解決する責任はプロダクト側に残ります。流暢な文章は、顧客インタビューが実施された証拠にも、実装できる証拠にもなりません。

AI 機能の要件定義では、さらに出力の評価、評価用データ、失敗からの復帰、人との関わり、モデルや知識源の変更を扱います。プロンプトは実装への入力の一つであり、プロダクト全体の約束ではありません。選んだ例でモデルが良好な結果を出しても、権限、画面、運用が正しく機能するとは限りません。

本記事の題材は、社内のサポート返信作成機能です。担当者に閲覧権限がある現行のナレッジ記事から下書きを提案し、人が確認します。送信、返金、アカウント変更、ポリシー決定は行いません。この境界は開発者にも利用者にも見える必要があります。Microsoft HAX は、対応する仕事や領域への期待を明確にすることを勧めています。能力の説明は、実際の動作と一致していなければなりません。Microsoft HAX の能力説明ガイド

本文を書く前に、根拠・要件・決定を分類する

重要な記述には種類と安定した参照 ID を付けます。分類がなければ、「ある担当者が速い返信を望んだ」という話が「すべての顧客が 2 秒以内を求める」に変わり、いつの間にか開発上の確約になりかねません。

根拠台帳には資料 ID、日付、版、アクセス範囲、どの主張を支えるかを記録します。リンクが追跡に役立つのは、関連する内容を確認できる場合です。有効な文書 ID が付いていても、生成された主張をその文書が裏付けるとは限りません。

要件は、結果を確認できる形で書きます。NASA のチェックリストは、明確さ、一意の参照、追跡可能性、検証可能性を重視しています。こうした原則を活用しても、航空宇宙分野の手続きを SaaS の義務にする必要はありません。「速い」「安全」「正確」には、強い形容詞ではなく条件と評価方法が必要です。NASA の要件記述チェックリスト

AI プロダクト要件定義書の 14 項目

1. 文書の状態、責任者、求める承認

PRD ID、版、文書の管理者、プロダクトの責任者、必要なレビュー担当、今回求める判断を記載します。ドラフト、レビュー中、特定目的に対して承認済み、旧版、撤回を区別してください。誰も合意していない公開日を置くより、次に判断する日を明確にします。

例は P077、バージョン 0.3、状態はドラフトです。範囲を限定したサポート返信の構想と未解決の依存条件を確認するための文書です。プロダクト責任者が自動送信を対象外にすることへ同意しても、文書全体を承認したことにはなりません。承認には版と目的を記録し、その後の変更に無条件で引き継がせないようにします。

2. 要約：問題と提案する成果

誰が何に困っているか、何を終えたいのか、どのような変更を提案するか、なぜ今判断が必要かを説明します。アシスタントではなく検索改善や返信ライブラリを選んだとしても、要約の問題設定は成立するべきです。

架空の例では、サポート担当者は現行の許可された資料と照合できる返信案を必要としています。既存エディターの横に下書きと根拠を示し、送信は担当者が行う構想です。求める判断は、限定的な試行に向けてアクセス、評価、運用の未解決事項を詰めるかどうかであり、即時公開の許可ではありません。

3. 問題、根拠、反証

利用を許可された調査や業務記録から現行の仕事を説明します。発言、観察、推論を分け、含まれていない利用者と別の解釈も示します。現在の返信作成時間を測っていなければ、その不足を書き、改善率を作らないでください。

事例パケットの資料と操作の記録は教材として作成したもので、実際の顧客調査ではありません。実務の PRD には、使用を許可されたインタビュー記録や利用データを添え、それぞれが何を支えるか説明します。担当者が複数の記事を開くという事実だけで、生成型の返信機能が最善とは言えません。

4. 対象者、仕事、対象外の状況

主要な役割、仕事、環境、言語、アクセス条件を定義します。操作する人と、出力から影響を受ける人を区別してください。例では担当者が作成機能を操作し、顧客は後で編集済みの返信を受け取る可能性があります。両者の関心は関連しますが、同じではありません。

初期対象の言語と製品領域を定め、補助担当、臨時職員、外部委託先を含むか決めます。架空の属性でペルソナを補ったり、全員がマウスを使うと仮定したりしないでください。スクリーンリーダーやキーボードだけでの操作が必要なら、要件と確認計画に最初から含めます。

5. 目標、指標、指標が支える判断

各指標にイベント定義、分子、分母、対象集団、期間、データ源、責任者、判断用途を付けます。利用行動、出力品質、遅延、費用、悪影響は別々に扱います。担当者がそのまま採用したことは行動の記録であり、事実の正しさや顧客満足を証明しません。

例では、対象リクエストのプレビュー到達率 85% 以上、確認済み下書きの無編集採用率 70% 以上、成功したプレビューだけの最近順位法 p95 が 8 秒以下、という探索的な目標を置きます。どれも検証が必要な架空の計画値で、業界標準ではありません。基準値や費用の根拠がなければ未解決のままにし、削減効果の主張へ変換しないでください。

6. 非目標と再検討の条件

意図的に除外する隣接機能を明記します。例では自動送信、返金承認、顧客アカウントの編集、操作者のアクセス範囲外の資料利用を行いません。実装上は送信できるままなら、「下書き」というラベルだけでは十分な境界になりません。

重要な除外には理由と再検討の条件を付けます。自動送信には別のリスク評価、運用設計、根拠、明確な許可が必要であり、プロンプト変更だけで公開範囲に入れてはいけません。非目標は明示的な範囲の判断であり、後で誰かに聞かれるまで放置した機能ではありません。

7. 範囲と一意に識別できる要件

各要件に安定した ID、求める結果、理由、優先度、依存条件、受け入れ確認への参照を付けます。機能の動作とレビュー担当者の作業を混同しないでください。独立して失敗し得る動作は、別要件または区別できる確認ケースに分けます。

実際の制約でない限り、モデルやデータベースを先に固定する必要はありません。「表示する事実のすべてが閲覧可能な現行資料で裏付けられる」は必要な結果です。「必ずモデル X を使う」だけでは、その結果が必要な理由を説明できません。選んだ方式で結果を満たせなければ、機能を狭めるか裏付けのない文を表示しないようにし、満たしたことにしないでください。

8. 操作体験、失敗状態、復帰

開始、読み込み、プレビュー、結果なし、アクセス拒否、タイムアウト、修正、終了を記述します。例では生成が失敗しても入力済みの文を残し、手作業を続けられる必要があります。動いていたエディターをエラー画面に置き換え、元の仕事まで不可能にしない設計にします。

Google の People + AI Guidebook は、エラーの定義や原因の理解、失敗後に利用者が前へ進む方法を扱います。モデル API だけでなく製品全体で考えてください。形式が正しくても違う仕事への回答なら、利用者にとっては問題です。Google PAIR の失敗と復帰のガイド

フォーカスを移動しない状態通知については、支援技術へ情報をどう伝えるかを指定します。W3C による WCAG 2.2 達成基準 4.1.3 の説明は、プログラムが識別できるステータスメッセージを扱います。追加された全段落を割り込み通知にするという意味ではありません。要件を書いた後も、適切な道具と担当者による実際の確認が必要です。W3C のステータスメッセージ解説

9. データ、連携先、AI 設定の境界

許可された入力、正本を管理するシステム、出力項目、資料の版、更新ルール、識別子、失敗時の動作を列挙します。現行の知識と廃止済み資料を区別し、検索結果なし、記事の矛盾、操作者が閲覧できない内容を取得した場合の動作を決めます。

AI 機能では、選択したモデルまたは候補、プロンプト版、検索設定、評価データの版、重要な生成設定も記録します。学習やファインチューニングを計画していないなら、不要な学習データ要件を追加する必要はありません。架空の PRD は本番モデルと連携方式を未選定としており、アクセス制御や根拠追跡がすでに動くとは主張できません。

10. セキュリティ、プライバシー、専門レビュー

情報の流れとレビュー責任者を定義します。要求時と結果表示時の権限、ログ中の機微情報、保存、削除、アクセス変更の影響を扱います。仮名のアカウント番号や「非公開」設定だけをもって、すべての要件を満たす証拠としないでください。

例では、取得後から表示前までの間に担当者が記事のアクセス権を失う状況を明示します。この確認は架空の記録でも未実施であり、リリースを止める条件です。実際のプライバシー、セキュリティ、法的判断は環境に応じた専門家が担います。生成された PRD は適合性を認証せず、専門レビューにも代わりません。

11. 依存関係、制約、代替策

リリースに必要なシステム、チーム、データ、ベンダーとの取り決め、運用資源を列挙します。重要な依存先には責任者、現在の根拠、未解決条件、遅延の影響を付けます。変えられない制約と変更可能な好みを区別してください。

返信作成機能には、権限を反映した検索、承認された知識集合、安定した手動エディターが必要です。検索できなければ既存の手動作業へ戻り、社内の全資料へ無制限に検索範囲を広げてはいけません。費用の根拠がなければ事業性の判断は暫定とし、架空のトークン単価から予算を作らないようにします。

12. リスク、検知条件、残る判断

何が起こり得るか、どう気付くか、誰が対応するか、利用を続ける前に何が必要かを記述します。根拠のないポリシー説明、古い資料、権限外の開示、過信、サポート業務の中断などを含めます。対処用のチケットを作っただけでリスクが解消したとは言えません。

NIST AI Risk Management Framework は、AI の設計、開発、使用、評価を通じてリスクを検討するための任意の参照枠組みです。公式概要では AI RMF 1.0 が改訂中であることも示されています。参照版を記録してください。NIST を引用しても認証にはならず、対策が働く証拠にもなりません。NIST AI RMF の概要

13. 受け入れ証拠、公開条件、切り戻し

要件と実際のチェック、確認対象のビルドや設定、結果、未解決不具合を結び付けます。テスト名は結果ではありません。文書を確認した事項と動かして確認した事項を区別し、未実施を合格と混ぜないでください。

限定試行と対象拡大をそれぞれ誰が承認できるかを決め、停止条件、機能の無効化、サポート責任、手動への復帰を定義します。切り戻しても、送信済みの返信や開示済み情報を取り消せるとは限りません。機能フラグで全影響が元に戻ると仮定せず、外部に及んだ結果への対応も必要です。

14. 未解決事項と決定履歴

未解決の問いには担当者、必要な証拠、期限、先へ進めない範囲を付けます。一覧だけでなく関連する本文にも未決状態を残し、整った段落を確定事項と誤認されないようにします。

判断が変わったら、以前の選択、新しい選択、理由、承認者、影響する要件やテストを記録します。8 秒という目標を変えるなら、指標定義と理由も更新してください。今日の結果を合格に見せるために、昨日の基準を黙って書き換えてはいけません。旧版を残して判断を再現できるようにします。

記入例：文書が完成してもリリースは保留

根拠から要件、受け入れ確認までたどる

記入済みパケットには 7 要件と 8 件の架空のチェック記録があります。範囲を限定した教材であり、サポート製品の網羅的な検証計画でも、OpenMax で実行したテストでもありません。

KB-01 は請求先メールを変更できるのがワークスペース管理者だと示すだけで、24 時間以内の完了を約束していません。T03 の返信案は KB-01 を引用しながら、その期限を約束しています。リンクは存在しても主張に根拠がありません。資料 ID の有効性だけを確認する仕組みなら見逃します。

架空の記録では 5 件合格、1 件不合格、2 件未実施です。記載された全チェックが合格なのは RQ-01、RQ-03、RQ-04、RQ-05 の 4 要件で、全 7 要件のうち 4 件です。この小さな対応表の状態を示す数であり、実システムで要件を網羅的に検証した証明ではありません。

失敗した試行を隠さず指標を再計算する

別の架空の操作ログには 20 回の試行があります。14 回はプレビューに到達、4 回はタイムアウト、2 回はアクセス権でブロックされました。14 件のプレビューのうち処理結果があるのは 12 件で、8 件は無編集採用、3 件は編集、1 件は却下です。2 件は未確認です。このログと T01〜T08 は別集団なので、分母を混ぜないでください。

架空のログから言えるのは「確認済み下書きの約 3 分の 2 が無編集で採用された」です。「依頼の約 3 分の 2 を自動解決した」とは言えません。採用は正しさの証明ではなく、下書き専用の製品は送信も解決も自動化していません。

成功した 14 回のプレビュー時間は、2、3、3、4、4、4、5、5、6、6、7、8、9、12 秒です。最近順位法として、昇順の値から p×n を切り上げた位置を選ぶと定義すると、p50 は 7 番目の 5 秒、p95 は 14 番目の 12 秒です。これは成功したプレビューだけの遅延です。4 回のタイムアウトはそれぞれ 20 秒で、別途見える状態に残します。12 秒を全試行の p95 と呼び替えてはいけません。

実際に満たした条件から公開を判断する

これらは架空の計画値で、どのサポートチームにも勧める既定値ではありません。重要なのは判断の整合性です。整った文書や複数の合格で、リリースを妨げる不具合は相殺できません。例の結論は HOLD：リリース保留であり、現実の準備状況や性能は推定しません。

アシスタントと PRD を一項目ずつ作成・確認する手順

1. 根拠パケットを準備する。 許可された資料と既存の決定を集め、安定した ID と利用範囲を付けます。調査不足を記録し、アシスタントに根拠を作らせないでください。
2. 一度に一項目を起草する。 その項目の問い、許可資料、出力形式を渡し、根拠 ID と不確実性を求めます。責任者が明確な空欄は、架空の回答より役立つことがあります。
3. 各役割から疑問を出す。 プロダクトは問題と範囲、デザインは体験、開発は実現可能性、データや専門担当は評価と情報の扱いを確認します。実在する責任分担であり、AI に役を演じさせた擬似承認ではありません。
4. 参照を両方向にたどる。 要件から元の必要性や決定へ戻り、受け入れ証拠へ進みます。正常例だけでなく失敗と未実施も確認し、有効な参照と裏付けのある主張を区別します。
5. 判断対象の版を固定する。 誰が、何を、どの目的に承認したかを記録します。モデル、知識集合、権限ルール、重要要件の変更時は、影響する証拠を特定し、必要な再レビューを求めます。

動作をさらに具体化するにはユーザーストーリーの受け入れ条件ガイド、未解決リスクの整理にはプロジェクトリスク台帳テンプレートが使えます。いずれも PRD を補うもので、意思決定者の代わりではありません。

根拠を維持できる最も軽い方法を選ぶ

手動の文書とレビュー： 小さな変更で資料が少ない場合に向きます。大切なのは意味を決めることであり、14 個の見出しを埋めることではありません。短い文書でも決定日と要件 ID を残します。

既存の共同編集ツール： チームが使うコメント、履歴、課題リンクを活用します。承認が何を対象にするか、添付更新後も追跡できるかを確認してください。共有ページの URL だけでは、特定版の承認記録になりません。

スクリプトやノーコードの確認： 要件 ID の重複、参照漏れ、無効なリンク、必須項目の不足を検出できます。ただし、製品が必要か、ポリシーの解釈が正しいかは判断できません。

エージェントによる起草支援： 許可資料が分散し、構造化した初稿で事務作業を減らせるときに適しています。候補要件、前提、決定を区別し、PRD を書くためだけに元データの変更、顧客連絡、リリースの権限を渡さないでください。

継続的なプロダクト運用： 規模が増したら入力の版管理、評価責任者、変更通知、再レビュー条件を加えます。意味のある設定変更後も旧証拠が有効か確認します。作成文書が増えたことは判断品質の向上を示しません。

OpenMax が支援できる範囲と、確認が必要な点

公式文書が実際に示していること

OpenMax の AI プロダクトマネージャー文書には、問題の根拠、ユーザーストーリー、AI 特有の受け入れ基準、入出力、評価データ、公開条件、未解決事項を求める PRD 作成プロンプトがあります。関係者のサインオフ用チェックリストも出力要求に含まれています。起草の参考になることは確認できますが、実環境で承認を強制する、版履歴を管理する、全要件をテストへ接続する能力の証明ではありません。OpenMax AI プロダクトマネージャー文書

承認済みと扱わず、資料を限定したドラフトから始める

まず架空のパケットを使います。要約の前に、根拠表、7 要件、未解決の公開条件を作らせ、記入例と照合してください。KB-01 から 24 時間という期限を作ったり、未実施を合格にしたりしたら、作業を止めて手順を修正します。

提供された根拠と決定だけを使い、指定した PRD 項目を起草してください。資料 ID、版、限界を保ち、事実、提案要件、前提、未解決の問いを分けてください。インタビュー、見積もり、承認、テスト結果を作らないでください。裏付けのない記述とルールの矛盾を示してください。レビュー用ドラフトのみを作成し、元システムの変更、顧客連絡、範囲承認、機能公開は行わないでください。

実務で使う前に、ツールのアクセス、データの扱い、連携先の動作を責任者と確認します。制限を記したプロンプトは、実装されたアクセス制御の代わりにはなりません。実資料と照合できるまで、最小限の仕事にとどめてください。

より単純な方法が適している場合

根拠が明確で小規模な変更なら、既存の文書へ直接書けば十分です。関係者間の意見の不一致が問題なら、生成文書を増やしても分岐点を美しく言い換えるだけかもしれません。専門承認や基準値が不足しているなら、次の仕事は証拠を得ることであり、PRD を完成したように見せることではありません。

記入済み PRDで確認方法を合わせ、空のテンプレートを一つの実際の判断へ適用します。必要な責任者が判断するまではドラフトのままにしてください。

文書を仕上げた後も残すべき限界

テンプレートは需要、技術的実現可能性、適合性を証明しません。14 項目が完成していても、解くべき問題が違う可能性があります。例の 20 回の操作と 8 件の確認は架空の学習材料であり、母集団の推定、因果的な改善、費用削減、実際のリリース判断を支える証拠にはなりません。

モデルの出力は入力、設定、資料更新で変わり得ます。生成文を一つの正解文と完全一致させる条件は狭すぎる場合があり、「良さそう」という感想だけでは弱すぎます。変わってはいけない要素、評価方法、失敗の扱いを定義します。人による確認にも能力と誤りの限界があり、担当者の名前を置いただけでは全出力を注意深く読める証明にはなりません。

実際のプライバシー、セキュリティ、アクセシビリティ、法的事項には、適切な専門家と証拠が必要です。権威があるように見せるため、架空の監修者経歴、擬似承認、想像上の顧客コメントを加えないでください。必要なレビューが未了なら、その状態と判断への影響を明示します。

よくある質問

AI で文書を書くためですか、それとも AI 製品のためですか？

両方に使えますが、区別が必要です。どの PRD でも許可資料を用いた AI 起草支援は可能です。機能自体が AI を使う場合は、モデルの動作、評価、データ、失敗要件も記入します。既存モデルを呼ぶだけの製品へ、無関係な学習項目を増やす必要はありません。

PRD はどのくらいの長さが必要ですか？

具体的な判断、要件の追跡、結果の評価に足りる長さです。小変更なら短く、複雑で影響の大きい機能なら根拠資料や専門的な詳細を関連付けます。ページ数や文字数自体は品質の合否基準ではありません。

不足する指標や見積もりをアシスタントに埋めさせてもよいですか？

議論用の案と明示して提案させることはできます。ただし、基準値、費用、顧客調査、開発見積もりの不足を事実へ変えてはいけません。確約に使う前に、未確認事項の責任者と解決計画を決めます。

PRD が承認されたら公開できますか？

必ずしもそうではありません。承認は特定版の調査や実装だけを対象とすることがあります。公開には、定義した証拠、阻害要因の解消、運用準備、権限のある判断が別途必要です。架空の例では公開保留が正しい状態です。

PRD でモデルとプロンプトを永久に固定する必要がありますか？

ありません。必要な動作と本当の制約を定義し、どの実装設定に証拠が対応するかを記録します。モデル、プロンプト、検索データ、権限動作が変われば、旧結果を自動継承せず再評価が必要になる場合があります。

出典、改訂方法、次の作業

公式資料の確認日は 2026 年 9 月 4 日です。本改訂では、AI 起草支援と AI 機能を区別し、内容を追跡できる架空の PRD、資料と要件と確認の対応、操作指標ごとの分母を追加しました。14 項目の構成と教材は独自の編集内容です。実顧客調査、OpenMax の実行、連携試験、専門家の承認は主張していません。

次の PRD では一つの判断を選び、利用を許可された根拠を固定し、進むかどうかに関わる項目から書いてください。要約を整える前に、未根拠、不合格、未実施を読みます。役立つ PRD は、誰が次に何を判断するかを明確にします。公開ではなく、証拠を待つという結論でも同じです。