aia-generation について
aia-generationは、AI影響評価を記録する法律業務向けスキルです。聞き取り、リスク経路の選択、規制調査を進め、チームの書式に沿った評価書、条件、引き継ぎ事項を作成します。
主な機能
- 01システムと影響に関する対話形式の聞き取り
- 02迅速または完全なリスク経路の選択
- 03出典を示した規制分類
- 04チームの書式に沿った評価書
- 05ポリシー差分の確認と引き継ぎ事項
活用シーン
- 01導入予定のAI履歴書選考システムの評価
- 02個人に影響する、または個人データを扱うAIの確認
- 03企業の適用範囲における規制上の義務の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ anthropics/ claude-for-legal --skill aia-generationインストール後、Claude Code で/aia-generationを入力して読み込まれたか確認します。
詳細
/aia-generation
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.mdを読みます。影響評価のハウススタイルが設定されていることを確認します。- ガバナンスのティアとユースケースの特性に基づいて、以下のフレームワークを使用し、リスクトラック(fast または full)を判定します。
- インテークを行います。フォーム形式ではなく、対話形式で進めます。
- 対象範囲に含まれる各規制体制について、規制上の分類を行います。調査ティア、禁止行為への該当可能性、適用される義務を確認し、一次資料を引用します。
- ハウススタイル(シード文書から取得。記録がない場合はデフォルト)に従って評価書を作成します。
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.mdの AI ポリシー上のコミットメントとポリシーの差分を確認します。- 出力:評価書 + 条件の一覧 + 引き継ぎフラグ(必要に応じてプライバシー PIA、ベンダーレビュー)。
/ai-governance-legal:aia-generation "AI résumé screening for HR"
案件のコンテキスト
案件のコンテキスト。 プラクティスレベルの CLAUDE.md で ## Matter workspaces を確認します。Enabled が ✗(社内ユーザー向けのデフォルト)の場合、この段落の残りはスキップします。スキルではプラクティスレベルのコンテキストが使われ、案件関連の仕組みは表示されません。有効で、アクティブな案件がない場合は、「これはどの案件のものですか?/ai-governance-legal:matter-workspace switch <slug> を実行するか、practice-level と入力してください。」と尋ねます。アクティブな案件の matter.md を読み込み、案件固有のコンテキストと上書き設定を確認します。出力は案件フォルダー ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/ に書き込みます。Cross-matter context が on でない限り、他の案件のファイルは読み込みません。
目的
AI 影響評価はフォームではなく、文書化された意思決定です。AI システムが何をするのか、どのように出力に至るのか、誤りがあった場合に誰が影響を受けるのか、どのような監督体制があるのか、導入しても問題ないのかに答えます。このスキルは、その対話を構成し、このチームの形式で出力を作成します。この形式は、コールドスタート時にシードとなる影響評価から学習したものです。
AI 影響評価は PIA と同じではありません。PIA は、個人データが適法に取り扱われているかを確認します。AIA は、AI システムが責任ある方法で設計・導入されているかを確認します。両者は並行して実施する必要があることが多く、互いの代わりにはなりません。
ハウススタイルの読み込み
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md の ## Impact assessment house style を読みます。次の内容が記載されています。
- この会社で影響評価を実施するきっかけとなる条件
- シード評価から抽出した構成テンプレート
- 標準的な詳細度
- 承認者
シードの構成が ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md にある場合は、それを使用します。この評価書を、このチームが作成する他の評価書と同じ形式にすることが目的です。
管轄区域の範囲。 この評価では、~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md の ## Regulatory footprint に記載された規制体制を適用します。AI に関する法的規則、リスク分類、導入義務は、管轄区域によって大きく異なり、急速に変化しています。このシステムが対象範囲外の地域で導入されている(または導入される予定である)場合、あるいは準拠法の選択が問題となる場合、この分析をそのまま適用できないことがあります。対象範囲を再確認するか、拡張してください。
ステップ 0:影響評価は必要ですか?
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md の実施基準を確認します。
また、以下についても必ず確認します。
- この AI は、人に影響する意思決定(雇用、信用、アクセス、価格設定、コンテンツモデレーション)を行う、または実質的に左右しますか?
- この AI は、個人に関する個人データを処理しますか?
- これは純粋な社内利用ではなく、顧客向けの AI システムですか?
- 会社がデプロイヤーとなる形で、サードパーティのモデルを使用しますか?
- このユースケースは、
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.mdに定めるガバナンスの中程度または高リスクのティアに該当しますか?
上記のいずれにも該当せず、ハウススタイルの実施基準も満たさない場合:
「包括的な影響評価は必要なさそうです。後で問い合わせがあった場合に備え、その理由を説明するファイル用の記録を、1 段落で作成します。」
ステップ 1:リスクトラック
受付前に、実行するトラックを決定してください。階層の定義とファストトラックの基準は、特定の規制体制に固有のフレームワークにハードコードされたものではなく、~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md(## Use case registry と ## Governance tiers)に記載されています。
ユーザーが対象とする各規制体制について、該当するリスク分類フレームワークを調査してください。多くの規制体制では、リスク階層、影響を受ける対象者、意思決定の重大性によって区分されています。具体的な基準を調査してください。ほとんどの規制体制では、従業員データも個人データとして扱われ、従業員の監視も重大な影響を伴うものとみなされます。社内利用のみのシステムは対象外だと決めつけないでください。
黙って補足しないでください。 設定された法務調査ツール(Westlaw、EUR-Lex、規制当局のサイト、または法律事務所のプラットフォーム)への調査クエリで、ある制度のリスク階層やトリガーに関する検索結果がほとんど、あるいはまったく得られなかった場合は、見つかった内容を報告して終了してください。尋ねずに、ウェブ検索やモデルの知識で不足を補ってはいけません。次のように伝えてください。「[tool] から [N] 件の検索結果が得られました。[regime / topic] に関する情報は少ないようです。次の選択肢があります。(1)検索クエリの範囲を広げる、(2)別の調査ツールを試す、(3)ウェブを検索する — 結果には
[web search — verify]のタグが付けられ、依拠する前に発出機関の情報と照合する必要があります、または(4)未検証としてフラグを付け、終了する。どれにしますか?」確度の低い情報源を受け入れるかどうかは、弁護士が判断します。出典の帰属レベル分け。 AIA 内の引用(規制文書、委任法令、ガイダンス、規格)すべてに、出典のタグを付けてください。モデルの知識に基づく引用には、一律に「verify」と付けるのではなく、次の3段階のいずれかを使用してください。
[settled]— 変更される可能性が低い、安定した、よく知られた法令・規制上の参照(例:概念としての GDPR Art. 22、EU AI Act としての Regulation (EU) 2024/1689 の存在)。認証前には検証が必要ですが、優先度は低めです。[verify]— 実在するものの、検証が必要なモデル知識に基づく引用:個別の委任法令/実施法令、規制当局のガイダンス、NYC DCWP の規則、Colorado AI Act の規定、整合規格、発効日、EEOC のガイダンス、および2023年以降の情報。[verify-pinpoint]— ピンポイント引用(EU AI Act の具体的な条番号、付属書への参照、Colorado AI Act の項番号、NYC LL 144 の規則の条項、小項目を示す文字)は捏造されるリスクが最も高く、必ず一次資料と照合してください。特に EU AI Act の条番号は統合時に変更されているため、同法へのピンポイント引用はすべて官報掲載の本文と照合する必要があります。ツールで取得した引用には出典タグ(
[Westlaw]、[EUR-Lex]、[regulator site]、または MCP ツール名)を付けたままにします。ウェブ検索による引用には[web search — verify]、ユーザー提供の引用には[user provided]を付けたままにします。この段階分けにより、実際に必要な検証作業が明確になります。すべてを検証対象にすると、何も検証しないのと同じです。タグを削除したり、まとめたりしてはいけません。弁護士以外のユーザーには、不確かな日付を本文に入れず、確認リストに記載してください。 「2026年2月1日発効」に
[verify]タグが付いていても、[verify]の意味を知らない CISO には「2026年2月1日発効」と読めてしまいます。~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.mdの## Who's using thisを読んでください。役割が Non-lawyer で、日付、期限、段階的導入、基準値、または発効日の主張が不確かな場合(本文に記載するなら[verify]または[verify-pinpoint]が付く場合)は、その主張を「発効日:弁護士に確認してください」(または「基準値:弁護士に確認してください」など)に置き換え、不確かな主張をすべて、AIA の最後に次の見出しを付けてまとめてください。確信が持てない点 — 依拠する前に弁護士に確認してください:
各不確かな項目について、(1)記載した内容、(2)不確かな点、(3)評価にとって重要な理由を列挙してください。これにより、弁護士ではない読者が、注意書きの付いた推測を確認済みの事実と誤解するのを防げます。弁護士の役割のユーザーには本文中に
[verify]を付けます — そのタグの意味を理解しているためです。
簡易評価と完全評価: ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md に、どのような場合に簡略化した対応が可能かが定められています。~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md に簡易評価の基準が定められていない場合は、完全評価を標準とし、次回に向けてどの基準を記録したいか、ユーザーに尋ねてください。
迷った場合は、完全評価を実施してください。低リスクな案件であっても、誤った簡易評価は、十分に検討した評価よりも望ましくありません。
ステップ 2:情報の確認
何かを書く前に、以下について回答を得てください。会話形式で構いません — 相手に送るフォームではありません。
システム
- AI は何を行いますか?マーケティングコピーではなく、平易な言葉で説明してください。
- どのモデルまたはベンダーがそれを支えていますか?ファインチューニング済みですか、それとも既製品ですか?
- ワークフローの中でどこに位置しますか — 支援型(人間が出力をレビューする)、拡張型(人間が上書きできるが通常はしない)、それとも自動型(ループに人間が関与しない)ですか?
- 出力は何ですか — 生成テキスト、スコア、分類、推薦、アクションですか?
誰が影響を受けるか
- AI の出力は誰に対して作用しますか — 従業員、顧客、第三者ですか?
- AI がエラー(偽陽性、偽陰性、ハルシネーション)を生み出した場合、誰が損害を負い、現実的に起こりうる最悪のケースは何ですか?
- 脆弱なグループが不当に多く対象に含まれていませんか — 未成年者、求職者、経済的困難にある人々、患者など?
入力とデータ
- AI はどのようなデータを取り込みますか?
- 個人データを取り込みますか?それは誰のものですか?
- モデルはこの企業のデータでトレーニングされましたか、それとも企業固有のトレーニングを行っていない基盤モデルですか?
- 入力データはどこへ行きますか — 境界の外にある第三者モデルの API に渡されますか?
意思決定と監督
- AI の出力は自動的にアクションを引き起こしますか、それとも出力をどう扱うかは人間が決定しますか?
- 人間によるレビューがある場合、人間が実際に AI の出力を変更する頻度はどれくらいですか?(答えが「まれにしか」であれば、その人間は実際にはレビューしておらず、ただゴム印を押しているだけです。)
- AI の出力によって影響を受ける人々のための異議申し立てや訂正のプロセスはありますか?
- AI システムの出力に対して責任を負うのは誰ですか — 指名されたオーナーはいますか?
精度と失敗
- 既知または推定のエラー率はどれくらいですか?どのようなテストが行われましたか?
- AI が間違ったとき、何が起こりますか — エラーは表面化され、ログに記録され、訂正されますか?
- バイアステストは行われましたか?どの人口統計グループに対してですか?
展開段階と規模
尋ねてください:
- 段階: 「このシステムは (a) 提案段階でまだ構築されていない、(b) パイロット中、(c) 本番稼働中、または (d) 稼働中かつ規模拡大済みのどれですか?」
- 規模: 「[月/年]あたりおよそ何人の個人が影響を受けますか?どのくらいの期間稼働していますか?」
- 履歴: 「以前に評価されたことはありますか?異議申し立て、上訴、または覆された決定を生み出したことはありますか?」
段階によって評価は変わります。提案されたシステムには設計レビューが行われます(安全に構築できるか?)。パイロットには設計レビューに加えて「規模拡大前に」のゲートが設けられます。稼働中のシステムには、遡及的な影響チェック(害を引き起こしたか?)と今後のレビューの両方が行われます。稼働中かつ規模拡大済みのシステムには、上記すべてに加えて、問題が見つかった場合の修復計画が行われます。なぜなら、単に電源を切るわけにはいかないからです。
ステップ 3: 規制上の分類
ステップ 3 の事前チェック — フットプリントの鮮度。 キャプチャされた ## Regulatory footprint を反復処理する前に、ユースケースの影響を受ける集団と決定タイプ(ステップ 2 より)を、記述されたフットプリントと比較してください。フットプリントはコールドスタート時に、その時点での企業の運営体制に基づいて設定されました。ユースケースが、フットプリントで想定されていない影響を受ける集団(例: 児童、新しい州の従業員、EU のデータ主体)または決定タイプ(例: 採用、信用力、健康診断、法執行、重要インフラ)を導入する場合、古いリストを反復処理するのではなく、適用される制度を再導出してください。
ユーザーに次のように伝えてください:
「プラクティスプロファイルの規制上のフットプリントは、[コールドスタート時にキャプチャされた影響を受ける集団/決定タイプ]に対して設定されました。このユースケースは [新しい集団または決定タイプ — 例: コロラド州の従業員、13 歳未満の未成年者、信用決定、生体認証による識別] に影響を与えますが、これはキャプチャされたフットプリントには含まれていません。古いフットプリントを使用するのではなく、企業の運営管轄区域(
## Company profileのリスト)とこのユースケースの決定タイプ([Y])から、適用される制度を再導出します。このユースケースが、今後さらに多く見込まれる作業を代表するものである場合は、この実行の最後に## Regulatory footprintを更新して、次回の AIA で再導出する必要がないようにしてください。」 よくある失敗例:規制対象として EU AI Act、GDPR、NYC Local Law 144 が記載されている一方で、ユースケースはイリノイ州とコロラド州で導入される採用システムです。規制対象にイリノイ州もコロラド州も含まれていないため、これを順に確認しても IL AIVIA、コロラド州の新しい AI Act による導入者の義務、さらに生体認証コンポーネントがある場合の BIPA への影響が、気づかれないまま見落とされます。再導出してください。
2 つ目の失敗例:現在関係する規制が成立する前、または施行される前に規制対象が設定されていました。再導出によって規制対象に含まれていない規制が見つかった場合は、出力の推奨事項セクションでその規制を明示し、根拠となる法令を引用して、規制対象の更新を推奨してください。
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## Regulatory footprint に記載され、このシステムに適用される各規制について、さらに上記の再導出で明らかになった規制も含めて、現在有効なリスク分類フレームワークを調査し、このシステムがどの分類に該当するかを判断してください。
調査事項:
- 規制固有の分類体系(例:禁止/高リスク/限定的/最小リスク、または同等の分類)は何ですか?
- 各分類の基準は何ですか?特定箇所を示した一次資料を引用してください。
- システムの機能、影響を受ける当事者、意思決定の重大性を踏まえると、このシステムはどの分類に該当しますか?
- システムが該当する可能性のある禁止行為はありますか?該当する可能性が少しでもあれば、重大事項として直ちに明示してください。
- 分類にかかわらず適用される透明性義務はありますか?(利用者に AI とやり取りしていることを開示する義務、AI 生成コンテンツにラベルを付ける義務、自動化された意思決定の対象者に通知する義務など)
- 会社が汎用モデルまたは基盤モデルを提供する構築者である場合、提供者レベルではどのような義務がありますか?(技術文書、学習データの透明性、著作権の遵守、システミックリスクのテストなど)
- 規制対象のいずれかが、個別の基本的人権影響評価(FRIA)を義務付けていますか? EU AI Act Art. 27 は、一定の高リスク AI システムの導入者(公的機関および公共サービスを提供する民間事業体、ならびに特定の信用力評価および保険リスク評価の用途)に FRIA を義務付けています。各規制に、今回の AIA とは別個の成果物となる、同等の基本的人権または人権影響評価があるか確認してください。FRIA(または規制上同等の評価)が必要な場合は、推奨事項と条件に独立した成果物として明記してください。この AIA が代替になるものとして扱ってはいけません。
社内のみで使用するシステムは適用対象外だと決めつけないでください。多くの規制では従業員データを個人データとして扱い、従業員の監視を重大な影響を伴うものとみなします。該当する具体的な規則を確認してください。
提供者と導入者の役割分担(AI role: Both の場合)。 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## Company profile → AI role が Both(会社が提供者/構築者と導入者の両方に該当する場合)であれば、セクション 6 に、規制ごとの提供者と導入者の役割分担を示す表を必ず含めてください。多くの規制では、提供者(または構築者)と導入者(または利用者)に実質的に異なる義務を課しています。これらを区別のない単一の一覧にまとめると、義務の見落としやリスクの混同につながります。提供者と導入者の義務を単一のセクションにまとめないでください。規制ごとに、次の表を作成してください。
| 義務 | 提供者として | 導入者として |
|---|---|---|
| [具体的な義務、特定箇所を示した引用] | [適用されるか/適用されないか/例外の有無] | [適用されるか/適用されないか/例外の有無] |
高リスクまたは同等の分類が適用される場合: 該当する具体的な条項と規制を引用して、評価書に明記してください。この AIA は内部レビューを記録するものであり、規制で義務付けられる正式な適合性評価の代わりにはならないことを記載してください。該当する法域での導入前に、外部の法律専門家による審査を推奨してください。
分類と引用した根拠法令を、評価書の出力に記載してください。
Step 4: 評価書を作成する
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md のシード構造を使用してください。 取得されていない場合は、次のデフォルトを使用してください。
[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]
# AI Impact Assessment: [System/Feature Name]
**Prepared by:** [name] | **Date:** [date] | **Status:** DRAFT / APPROVED
**System owner:** [name] | **AI governance reviewer:** [name]
**Governance tier:** [Standard / Elevated / High]
**Track:** [Fast track / Full assessment]
---
## Executive summary
[Two sentences: what this AI does and whether it's okay to deploy. E.g., "This
system uses a third-party LLM to draft initial responses to customer support tickets
before human agent review. Processing is consistent with the company's AI policy;
three conditions required before production deployment."]
**Overall risk:** 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high
---
## 1. System description
**What it does:** [plain English — not marketing]
**Model / vendor:** [who's providing the AI]
**Deployment mode:** [Assistive / Augmentative / Automated]
**Output type:** [text / score / classification / recommendation / action]
**Status:** [Not started / Pilot / Production]
---
## 2. Affected parties
**Who it acts on:** [employees / customers / third parties]
**Scale:** [how many people, how often]
**Harm if wrong:** [most realistic worst case — specific, not generic]
**Vulnerable groups in scope:** [yes — [who] / no]
---
## 3. Data inputs
**Data categories used:** [specific fields, not "user data"]
**Personal data:** [yes — [whose] / no]
**Data leaves perimeter?** [yes — to [vendor] / no]
**Model training:** [company data used / foundation model / fine-tuned on [dataset]]
---
## 4. Decision-making and oversight
**Human in the loop:** [Always / Nominally (rubber-stamp risk) / No]
**Override mechanism:** [how a human can intervene or correct]
**Appeals / correction for affected parties:** [yes — [how] / no]
**Named owner:** [name or role]
---
## 5. Accuracy and bias
**Error rate:** [known / estimated / untested]
**Failure mode:** [what happens when it's wrong — surfaced? logged? corrected?]
**Bias testing:** [done — [results] / not done / not applicable]
---
## 6. Regulatory classification
*[One subsection per regime in the regulatory footprint that applies to this system.]*
**Regime:** [name]
**Classification under this regime:** [tier, with pinpoint citation to the controlling provision]
**Prohibited practices triggered:** [none identified / [specific provision and why]]
**Applicable obligations:** [researched list with citations — transparency, documentation, human oversight, testing, registration, etc.]
**Fundamental-rights impact assessment required?** [Yes — e.g., EU AI Act Art. 27 FRIA applies / regime equivalent / No / Not applicable. If yes, this is a separate deliverable, not subsumed by this AIA.]
**Effective / enforcement date:** [date(s)]
**Ambiguity or open interpretation:** [flag anything not yet settled]
**Provider-vs-deployer obligation split (required if `AI role: Both`):**
| Obligation | As provider | As deployer |
|---|---|---|
| [specific obligation + pinpoint cite] | [what applies / does not apply] | [what applies / does not apply] |
---
## 7. AI policy consistency
| Policy commitment | Consistent? | Notes |
|---|---|---|
| [commitment from `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` AI policy section] | 🟢 / 🟡 / 🟠 / 🔴 | |
[If any item is 🟡 or worse: policy update needed before deployment, or design needs to change.
One of them has to change — not both flagged and left open.]
---
## 8. Risks and mitigations
| # | Risk | Likelihood | Impact | Mitigation | Status | Owner |
|---|---|---|---|---|---|---|
| 1 | [specific risk tied to this design — not "AI hallucination" generically] | L/M/H | L/M/H | [specific control] | Done / Planned / Gap | [name] |
**Residual risk after mitigations:** [assessment]
---
## 9. Recommendation
**[APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED]**
**Conditions (if any):**
- [ ] [specific action before deployment — owner, deadline]
**Privacy review required?** [Yes — run `/privacy-legal:pia-generation`, if the plugin is installed /
No]
**Sign-off:** [name, date]
---
## Cite check
Regulatory citations in Section 6 (and anywhere else) were generated by an AI model and have not been verified against primary sources. Before the assessment is certified or relied on, run a verification pass against a legal research tool (Westlaw, EUR-Lex, or your firm's platform) for each cited provision — confirm the pinpoint, currency, and any delegated or implementing acts. The AI regulatory landscape shifts quickly; verify before advising. Source tags on each citation (e.g., `[EUR-Lex]`, `[web search — verify]`) show where it came from; `verify` tags carry higher fabrication risk and should be checked first.
AIA を認証する前に(承認ステップで、Status: APPROVED に設定する前に): ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md の ## Who's using this を確認してください。Role が Non-lawyer の場合:
この AIA の認証には法的な影響があります。規制当局または影響を受けた当事者からこのユースケースの評価方法を尋ねられた場合に、会社が根拠として示す記録となるためです。弁護士と一緒に内容を確認しましたか?確認した場合は、続行してください。まだの場合は、弁護士に相談するための概要を以下に作成します。
[1 ページの概要を作成します。システム、規制上の分類、特定されたリスク、実施済みの緩和策、残余リスク、未解決の質問、認証前に弁護士に尋ねるべきことを記載します。]
弁護士、事務弁護士、法廷弁護士、またはその他の認可を受けた法律専門家を探す必要がある場合は、所属する専門職規制機関の紹介サービスを利用するのが最も早い方法です(米国では州弁護士会、イングランドおよびウェールズでは SRA/Bar Standards Board、スコットランド/北アイルランド/アイルランド/カナダ/オーストラリアでは Law Society、または管轄地域の同等機関)。
明示的な「はい」がない限り、このゲートを通過しないでください。弁護士による確認用の DRAFT 評価にはゲートは不要ですが、認証には必要です。
リスクの品質基準
PIA スキルと同じ基準です。リスクは具体的で、設計に結び付いている必要があります。
| 悪いリスク | 問題点 | 改善例 |
|---|---|---|
| 「AI のハルシネーション」 | あらゆる LLM に当てはまり、何も説明していません | 「モデルがもっともらしいものの誤った法的引用を生成する可能性があります。サポート担当者には、顧客に送信する前に確認する現在の手順がありません」 |
| 「バイアス」 | あいまいすぎます | 「履歴書のスコアリングモデルは過去の採用者データでトレーニングされています。過去の採用者集団の人口統計的な構成が均質だった場合、過小評価されている候補者のスコアが体系的に低くなる可能性があります」 |
| 「ベンダーリスク」 | 循環論法です | 「OpenAI の利用規約では、デフォルトで API 入力をトレーニングに使用することが認められています。契約でオプトアウトが確認されていない場合、カスタマーサポートのメッセージがモデルのトレーニングに使用される可能性があります」 |
数を水増しした 12 件ではなく、実際のリスクを 2~5 件挙げてください。
AI ポリシーとの差分
すべての評価で、~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md にある AI ポリシーのコミットメントと照合してください。
よくある逸脱:
- ポリシーで [category] における AI の使用が禁止されています。このユースケースはそのカテゴリに該当します。中止してください。
- ポリシーでは人間によるレビューが必要とされています。この導入には人間が介在する手順がありません。設計を変更する必要があります。
- ポリシーでは影響を受ける当事者への開示が必要とされています。開示の仕組みが実装されていません。
- 承認済みベンダーリストがあります。このベンダーはリストにありません。調達手続きが必要です。
不一致はすべて指摘してください。導入前に、そのうちのいずれかを変更する必要があります。
引き継ぎ
- プロダクト/エンジニアリングへ: 担当者と期限を含む条件の一覧を渡します。「監督を追加する」ではなく、「自動送信メールの前に人間によるレビュー手順を追加する。担当者:[product lead]、期限:ローンチ前」のように記述します。
- プライバシー担当へ: 個人データが関係する場合は、次のように伝えます。「プラグインがインストールされている場合は、並行して
/privacy-legal:pia-generation [system name]を実行してください。AIA は PIA の代わりにはなりません。」 - vendor-ai-review へ: 新しいベンダーが関係する場合は、次のように伝えます。「[vendor] の AI 追加条項がレビューされていない場合は、本番環境に移行する前に
/ai-governance-legal:vendor-ai-reviewを実行してください。」 - reg-gap-analysis へ: 新たな規制上の義務(EU AI Act の高リスク分類、新たな業界規則など)が生じた場合、このスキルでギャップを追跡します。
次のステップの意思決定ツリーで締めくくる
CLAUDE.md の ## Outputs に従って、次のステップの意思決定ツリーで締めくくってください。このスキルで作成した内容に合わせて選択肢を調整します。デフォルトの 5 つの分岐(X をドラフトする、エスカレーションする、追加情報を得る、様子を見る、その他)は出発点であり、固定されたものではありません。ツリーが成果物であり、どの選択肢を選ぶかは弁護士が決めます。
このスキルでできないこと
- デプロイを承認するものではありません。評価には人間が署名します。
- 規制上の適合性評価を構成するものではありません。制度(例:EU AI Act)が正式な適合性評価を求める場合は、ここに記載した内容を超える、外部の法務レビューと技術文書を必要とする別の作業です。
- 緩和策を設計するものではありません。緩和が必要な事項を説明し、エンジニアリングチームが修正方法を設計します。
- 個人データを扱う場合にPIAの代わりとなるものではありません。両方を実施してください。