Communityライティング&編集github.com

AI PRD: モデルシステムが実際に責任を負える要件を書く

プロダクトをディスカバリーから廃止まで運用する:ゲート付きテンプレート、PM カノンカード、AI なしでも動作する AI スキル。

AI PRD: モデルシステムが実際に責任を負える要件を書く とは?

このスキルは、AI システム(LLM、エージェント、モデル)向けの PRD(製品要件定義書)を、従来のエンジニア向け指示書ではなく、即興的に動作するシステムに対する制約条件として再構成します。主な目的は、あいまいな「~すべき」という記述を、具体的な評価セット(最低30~50ケース)、数値による合格閾値、および閾値未満の際の対応ルールに変換することです。また、エッジケース(必須拒否、必須エスカレーション、絶対に捏造してはいけない項目)を明示的なテーブルとして定義し、非決定性(同じ入力でも異なる出力が出ること)を文書化し、各ガードレールに責任者とテストを割り当てます。さらに、運用コスト、レイテンシ、モデルバージョン管理、テレメトリなどの運用ページも含みます。規制対象の製品(金融、データ)向けには、専用のバイト単位で正確なテンプレートとモジュールを使用し、要件を書き始める前にライセンス条件やスキームルールなどを完了する必要があります。出力は再構成された PRD と GAPS テーブルで構成され、数値条件のない要件、責任者やテストのないガードレール、所有者いないギャップがある場合は完了と見なされません。

対応✓Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add RizwanZafaris/product-manager-OS

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

AI PRD: モデルシステムが実際に責任を負える要件を書く は何をしますか?

AI システム向けの PRD は、従来とは異なるドキュメントです。あなたの要件はエンジニアへの指示ではなく、即興的に動作するシステムに対する制約条件です。このスキルは、その事実に基づいてドキュメントを再構成します。

このスキルが生成するファイル

使用すべきタイミング

  • LLM、エージェント、モデルが判断を下したり、ドラフトを作成したりする機能を仕様化する場合
  • 「AI は~すべき」という記述がある既存の PRD をレビューする場合
  • デモを、エンジニアリングチームが責任を負えるものに変える場合

このスキルが強制する5つのセクション

1. 受け入れ基準は評価セットであり、文章ではない

「エージェントは加盟店名を抽出するべき」は願望です。要件とは次のものです:

  • ラベル付けされたサンプルセット(初回リリースでは最低30~50ケース)
  • 数値で示された合格閾値(精度、再現率@k、または判定スコア)
  • 閾値を下回った場合のルール(「レビュー」ではなく「リリースブロック」)

ドラフト内の「すべき」のたびに、サンプルセットはどこにあるか、数値は何か、失敗ケースをセットに追加する責任者は誰か、を問いかけてください。答えを ../../templates/ai/eval-spec.md に記録してください。

2. エッジケースは付録ではなく仕様そのもの

ハッピーパスはモデルが無料で行うことです。このドキュメントの価値は境界部分にあります。以下のための明示的なテーブルを要求してください:

  • MUST REFUSE(必須拒否): システムが拒否する入力(範囲外、安全でない、修復不能なほど不明瞭)
  • MUST ESCALATE(必須エスカレーション): 人間にルーティングする条件。ルーティング先を指定。トリガーとタイムアウト動作は ../../templates/ai/human-approval-gates.md に記録
  • MUST NEVER INVENT(絶対に捏造してはいけない): 捏造が欠落よりも悪いフィールド(数値、名前、法的または規制上の記述、金額)。棄権ポリシーは ../../templates/ai/hallucination-controls.md に記録

3. 非決定性を文書化する

同じ入力から明日は異なる出力が生成される可能性があります。PRD は以下を明示する必要があります:

  • どの出力のバリエーションが許容されるか(言い回し?順序?フォーマット?)
  • どの出力が欠陥か(異なる判断、異なる数値、異なる拒否動作)
  • 再現性の姿勢:温度とシードのポリシー、およびログが任意の判断を再現するのに十分な情報をキャプチャしているかどうか

PRD がこれを明示しなければ、QA が後でバグトラッカーで怒りながら決めることになります。

4. ガードレールは責任者を持つ機能である

各ガードレールは ../../templates/ai/guardrails.md に行(名前、トリガー、動作、責任者、テスト)を持ちます。エージェント機能で最低限検討すべきセット:

  • 検証不能な出力ではフェイルクローズ(チェックできない=ユーザーに出荷しない)
  • 元に戻せない操作(送信、支払い、削除、投稿)の前に人間の承認
  • 支出とレートの上限、および上限時の動作を明示
  • 入力の分離:システムが読み取るコンテンツはデータであり、決して指示ではない
  • 監査証跡:何が、どの入力に基づき、どのモデルバージョンで判断したか

5. 運用ページ

  • 呼び出しあたりのコスト目標とアラート閾値
  • ステップあたりのレイテンシ予算
  • モデルバージョンの固定とアップグレード決定プロセス
  • テレメトリ:判断ごとに何がログに記録されるか、評価の実行場所(CI、プレリリース、本番サンプリング)、およびロールバックトリガー

規制対象ルート

汎用 PRD ツールは上記 5 セクションを記述して終了します。製品が金融またはデータ規制当局の管轄下にある場合は、このスキルのオーバーレイを記憶頼りに実行しないでください。代わりに、../../modules/regulated/templates/regulated-ai-prd-template.md のバイト単位で正確なテンプレートから開始し、../../modules/regulated/SKILL.md に従い、要件を書き始める前にセクション 0(ライセンス前提条件、スキームルール、データ居住地とベンダー条件、金融犯罪タッチポイント、コンプライアンス、監査証拠メトリクス)を完了してください。空のオーバーレイフィールドは、発見した人に先送りされた判断です。規制当局名、セクション番号、引用テキストは、そのモジュールまたはユーザーが提供する一次テキストからのみ取得してください。決して捏造しないでください。

ワークフロー

  1. コンテキストを分類する。規制対象:上記の規制対象ルートを進み、モジュールがカバーしないセクションについてはここに戻る。非規制対象:../../templates/definition/prd.md から開始する。
  2. PRD ドラフトを読む。白紙から始める場合は PM にインタビューする。
  3. すべての「すべき」ステートメントをセクション 1 の形式に書き換える。評価に変換できないものはリストアップし、それらはまだ要件ではないとフラグを立てる。
  4. 3 つのエッジケーステーブルを作成する。各テーブルに最低 5 行を求めること。空のテーブルはディスカバリーが完了していないことを意味する。
  5. 非決定性条項とガードレールテーブルを作成する。
  6. 1 ページの GAPS リストを作成する:元のドキュメントが決定論的な実装者を前提としていたすべての箇所を、爆発半径でランク付けする。

出力形式

5 つのセクションを含む再構成された PRD を返し、続いて GAPS テーブルを返す:

#ギャップ元の場所そのまま出荷した場合の爆発半径最小限の修正

出口ゲート

このスキルの出力は ../../os/STAGE-GATES.md のゲート 2 に供給されます。数値による合格条件が欠けている要件、責任者とテストが欠けているガードレール、または責任者と日付が欠けている GAPS 行が存在する限り、PRD は完了と報告しないでください。

関連スキル