feature-risk-assessment

機能リスク評価

案件のコンテキスト

案件のコンテキスト。 実務レベルの CLAUDE.md で ## Matter workspaces を確認します。Enabled が ✗（社内ユーザーのデフォルト）の場合、この段落の残りはスキップしてください。スキルは実務レベルのコンテキストを使用し、案件の仕組みは表示されません。有効で、アクティブな案件がない場合は、「どの案件についてですか？ /product-legal:matter-workspace switch <slug> を実行するか、practice-level と入力してください」と尋ねます。案件固有のコンテキストと上書き設定を把握するため、アクティブな案件の matter.md を読み込みます。出力は案件フォルダー ~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/ に保存します。Cross-matter context が on でない限り、別の案件のファイルは読み込まないでください。

---

目的

ローンチレビューは広範囲を扱います。こちらは掘り下げます。単一の問題について、表の1行では不十分な場合——目新しい AI 機能、子ども向け製品、規制当局が積極的に注目している事案など——このスキルで独立した評価書を作成します。

ローンチのたびに必要なわけではありません。ほとんどの場合、必要ありません。「PIA 完了、リリース」で済ませるのが適切なレベルの精査ではない、10％のケースを対象とします。

実行するタイミング

• ローンチレビューで、評価基準表にないパターンが見つかった（目新しい）
• ローンチレビューで、**「通常はブロック」**のカテゴリに該当するものが見つかった
• GC または経営陣から「ここにはどんなリスクがあるか」と尋ねられ、一言以上の回答を求められた
• 機能が規制当局の注目を集めている分野（AI、子ども、生体認証、健康）に関わる
• 法務以外の関係者が懸念しており、体系的な回答が役立つ

いずれにも当てはまらない場合は、ローンチレビューで十分です。書類を作ること自体を目的にしないでください。

構成

1. 評価対象

1段落で記載します。機能の内容、その新しさ、全面的な評価にエスカレーションされた理由を説明します。

2. リスク

個別のリスクごとに記載します（15件ではなく、2〜5件を目安にしてください）。

### Risk [N]: [Short name]

**Scenario:** [What would have to happen for this to go wrong. Be specific —
not "data breach" but "the recommendation algo surfaces a user's sensitive
category interest to someone who shouldn't see it because X."]

**Who gets hurt:** [Users? The company? A third party? Specific.]

**How likely:** [Low / Medium / High — with a reason. "Low — would require
both X and Y to fail simultaneously." Not just a vibes rating.]

**How bad if it happens:** [Low / Medium / High — with a reason. "High —
regulatory fine + class action exposure + press" vs. "Low — one angry
tweet, no actual harm."]

**Existing mitigations:** [What already reduces the likelihood or impact]

**Gap:** [What's missing, if anything]

**Residual risk:** [After existing mitigations — is this acceptable or does
it need more?]

3. 規制環境（該当する場合）

規制当局がこの領域に積極的な関心を寄せている場合のみ記載します。その場合は、以下を含めます。

• 該当する規制当局と、最近の発言や対応
• この機能が規制当局にどう受け止められるか
• 見出しで知るよりも、当社から伝えるほうが望ましいか

4. 先例（該当する場合）

他社が類似のことを行ったことはありますか？その結果はどうでしたか？

• 悪い結果がなかった場合 → 参考にはなりますが、決定的な根拠ではありません
• 悪い結果があった場合 → その会社の状況との違いは何か、ここにも当てはまるか

先例を過度に重視しないでください。規制当局の優先事項は変わります。ある会社が問題を免れたからといって、次の会社も同じとは限りません。

5. 選択肢

現実的な道筋を2〜3つ提示します。

| Option | Description | Risk reduction | Cost |
|---|---|---|---|
| A: Ship as designed | [current plan] | None | None |
| B: Ship with [mitigation] | [change] | [how much] | [eng effort, timeline, UX] |
| C: Don't ship [component] | [scope cut] | [how much] | [product impact] |

6. 推奨事項

1つ選びます。その理由を説明し、何を引き換えにするのかも認めます。

**Recommended: Option [X]**

[Why. What risk remains. Why that's acceptable. Who accepts it.]

**If the answer is "not my call":** [Who decides, what they need to know]

評価基準の確認

最終化する前に、~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md → Risk calibration と照合します。

• このリスク評価は、一般論ではなく、この会社に合わせて調整されていますか？
• 同意命令下にある会社では「高」リスクとなるものが、そうでない会社では「中」リスクになる場合があります
• 評価には、実務プロファイルに記録された実際の規制上の姿勢、訴訟履歴、リスク許容度を反映する必要があります

引き継ぎ

• AI ガバナンスへ： 詳細評価のきっかけが AI 機能だった場合——多くの場合そうなります——並行して、または直後に /ai-governance-legal:aia-generation [feature] を実行します。機能リスク評価は意思決定の枠組みを示し、AIA は AI ガバナンスに必要な形式で AI システムを個別に記録します。重複する文書ではありません。FRA はプロダクト法務の意思決定文書であり、AIA はガバナンス記録です。
• プライバシーへ： 機能に新たなデータ収集または処理が含まれる場合は、/privacy-legal:pia-generation [feature] を実行します。FRA のリスク項目は PIA の内容と重なる可能性が高いため、作業が重複しないよう、その重なりを明記します。ただし、両方の文書が必要です。
• AI ガバナンスのベンダーレビューへ： 機能が新しい AI ベンダーを使用する場合、ローンチレビューでまだ実施していなければ、/ai-governance-legal:vendor-ai-review [vendor agreement] を実行します。

出力形式

単独で読める文書、2～4ページ。~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md の「## Outputs」にある成果物ヘッダーを先頭に付けてください（ユーザーの役割によって異なります。「## Who's using this」を参照してください）。

スライド資料でも、ファイルに綴じるためのメモでもありません。読んだ人が判断を下すための意思決定文書です。

~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md の「Launch review process」に記載されている、レビュー文書の保存先に保存してください。文書を秘匿特権のある関係者以外にも共有する場合（広く共有されるチケットへの投稿など）は、外部向けコピーからのみ成果物ヘッダーを削除し、秘匿特権のある原本は案件ファイルに保管してください。

引用の確認

評価で判例、制定法、規制、または執行措置を引用している場合、特に「規制環境」または「先例」のセクションにある引用は、AI モデルが生成したものであり、一次資料との照合が済んでいません。意思決定者に意思決定文書を提出する前に、各引用を法律調査ツール（Westlaw、CourtListener、または所属事務所の調査プラットフォーム）で確認し、正確性、現在も有効かどうか、および執行状況を検証してください。架空の執行措置に基づくリスク評価は、評価がないよりも悪いものです。

補足を黙って加えないでください。 設定済みの法律調査ツールで検索した結果、評価に必要な法規制や先例について該当結果がほとんどない、またはまったくない場合は、見つかった内容を報告してそこで止めてください。許可を得ずに、ウェブ検索やモデルの知識で不足を補ってはいけません。次のように伝えてください。「検索結果は[ツール]から[N]件でした。[法規制／先例]について、網羅性が不足しているようです。選択肢：（1）検索クエリを広げる、（2）別の調査ツールを試す、（3）ウェブ検索を行う——結果には [web search — verify] のタグを付け、依拠する前に発出機関の情報と照合する、または（4）未検証として明記し、ここで止める。どれにしますか？」信頼度の低い情報源を受け入れるかどうかは、弁護士が判断します。

出典の明記。 「規制環境」と「先例」のセクションにある各引用には、その出典を示すタグを付けてください。法律調査コネクターから取得した引用には、出典に応じて [Westlaw]、[CourtListener]、[regulator site]、または MCP ツール名を付けます。ウェブ検索による引用には [web search — verify]、学習データから想起した引用には [model knowledge — verify]、機能チームから提供された引用には [user provided] を付けてください。verify タグ付きの引用は捏造のリスクが高いため、優先して確認してください。タグを削除したり、まとめたりしてはいけません。意思決定者が、どの引用を先に確認すべきか分かるようにする必要があります。

次のステップの意思決定ツリーで締めくくる

CLAUDE.md の「## Outputs」に従い、次のステップの意思決定ツリーで締めくくってください。このスキルで作成した内容に合わせて選択肢を調整してください。標準の5つの分岐（X のドラフトを作成する、エスカレーションする、追加情報を得る、状況を見守る、その他）は出発点であり、固定ではありません。成果物はこのツリーです。どの選択肢を選ぶかは弁護士が判断します。

このスキルで行わないこと

• すべての機能を評価するわけではありません。ほとんどの機能では、ローンチレビューを1回行うだけです。
• 意思決定は行いません。判断材料を整理します。権限を持つ人が選択肢を決定します。
• 定量的なリスクモデリングは行いません。会社に数値を用いる正式なリスクフレームワークがある場合は、それを使用してください。この評価は定性的なものです。