mcpField
A
arize-compliance-audit

arize-compliance-audit

github.com/arize-aiセキュリティ672.7k 回インストール6 日前に更新
リポジトリ

arize-compliance-audit について

arize-compliance-auditは、AIエージェントやLLMアプリの規制上の不足を調べる開発チーム向けスキルです。選択したフレームワークと用途に沿ってコードを確認し、Arizeのトレース範囲を点検して、個別のチェックリストを作成します。

主な機能

  1. 01フレームワークと用途に応じた監査範囲
  2. 027領域を対象とする読み取り専用のコード検査
  3. 03Arizeのトレースと監査記録の確認
  4. 04個別のコンプライアンスチェックリスト
  5. 05修正前にユーザーの確認を要求

活用シーン

  1. 01AIアプリのプライバシーやセキュリティの不足確認
  2. 02選択した規制に関する技術的統制の点検
  3. 03Arizeトレースの監査範囲の評価
  4. 04開発チーム向け修正項目の整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/arize-ai/arize-skills --skill arize-compliance-audit

インストール後、Claude Code で/arize-compliance-auditを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
compliance-checklist-template.md
eu-ai-act-gpai.md
iso-42001.md
us-ai-compliance.md

詳細

Arize コンプライアンス監査スキル

ユーザーがAI エージェントまたは LLM アプリケーションの規制コンプライアンス監査を希望する場合に、このスキルを使用します。このスキルはコードベースをスキャンしてコンプライアンス上のギャップを確認し、監査証跡の網羅性について Arize のインストルメンテーションと照合して、必要に応じて修正案を含む、用途に合わせたチェックリストを作成します。

トリガー:「アプリのコンプライアンスを監査して」、「EU AI Act の要件」、「NIST AI RMF チェックリスト」、「AI に関する GDPR」、「AI アプリは準拠していますか」、「コンプライアンスチェックリスト」、「規制監査」、「ISO 42001」、「AI マネジメントシステム」、「AIMS 認証」。

免責事項

何よりも先に、この免責事項をそのままユーザーに提示してください:


⚠️ 法的免責事項

この監査はガイダンスのみを目的としており、法的助言または完全なコンプライアンス評価を構成するものではありません。公開されている規制の枠組みに基づいて、一般的な技術パターンやギャップを特定しますが、お客様固有の法的義務、契約上の約束、データ処理契約、または業務プロセスを評価することはできません。

この出力を、資格を有する法律専門家への相談の代わりとして利用しないでください。 規制コンプライアンスの判断は複雑であり、管轄区域や事実関係によって異なります。拘束力のある評価を行う際は、必ず資格を有する弁護士またはコンプライアンス専門家に相談してください。


基本原則

  • 変更を加えるよりも調査を優先する — 変更を提案する前に、コードベースを把握してください。
  • 法律論ではなく、実務に即した内容にする — 法的見解ではなく、開発者が実行できる項目を提示してください。
  • 管轄区域とユースケースに合わせる — チャットボットと採用ツールでは、異なる義務が適用されます。規制の枠組み全体をそのまま提示しないでください。
  • インストルメンテーションと照合する — コンプライアンスには監査証跡が必要です。Arize のトレーシングで、規制当局が求める情報が記録されているか確認してください。
  • 修正案を提示し、必ず確認を得る — チェックリストの提示後、具体的な修正の実施を提案してください。ただし、ユーザーから明示的な確認を得ずにコードを変更してはいけません。
  • 出力は簡潔にし、本番環境を重視する — 要求がない限り、追加のドキュメントや要約ファイルを生成しないでください。
  • 認証情報の値をそのまま埋め込まない — 必ず環境変数を参照してください。コーディングエージェントのチャットに秘密情報を貼り付けるようユーザーに求めないでください。

フェーズ 0:フレームワークの選択とユースケース

コードをスキャンする前に、どのコンプライアンスフレームワークが適用されるかを確認してください。

ステップ 1 — フレームワークの選択

AskUserQuestion ツールを使って、該当するフレームワークをユーザーに尋ねてください。推測したり、自動選択したりしてはいけません — 必ず明示的に尋ねてください。

次のように尋ねます:

Which compliance frameworks should this audit cover?
Select all that apply (reply with numbers, e.g. "1, 3"):

1. EU frameworks — EU AI Act, GPAI Code of Practice, GDPR
   (choose if end-users or data subjects are located in the EU)

2. US frameworks — NIST AI RMF, state laws (Colorado AI Act, NYC LL144),
   HIPAA (if processing health data)
   (choose if operating in the United States)

3. ISO 42001 — International AI Management System standard
   (choose if pursuing ISO 42001 certification, operating globally,
   or wanting an internationally recognised baseline)

You can select any combination. If unsure, select all that seem relevant
and we can narrow down during the audit.

選択内容に基づいて、次のように対応します。

  • 1 を選択 — EU AI Act、GPAI Code of Practice、GDPR が適用されます。references/eu-ai-act-gpai.md を参照してください。
  • 2 を選択 — NIST AI RMF、Colorado AI Act、NYC LL144、HIPAA が適用される場合があります。references/us-ai-compliance.md を参照してください。
  • 3 を選択 — ISO 42001 の AIMS 管理策が適用されます。references/iso-42001.md を参照してください。注:ISO 42001 は組織的なマネジメントシステムです。監査では技術的に監査可能な管理策のみを対象とし、純粋に組織的な条項(リーダーシップレビュー、内部監査)は別途フラグを付けます。
  • 複数を選択 — 選択したすべてのフレームワークが適用されます。監査では要件の和集合を対象とし、フレームワーク間で重複する部分は相互参照を付けます。
ステップ 2 — ユースケースのカテゴリを確認

AskUserQuestion ツールを使って、次のように尋ねてください:AI アプリケーションは何をしますか?

  • 一般的なチャットボット/アシスタント — リスクは限定的(EU)、一般的な義務(US)
  • 採用/人事 — 高リスク(EU Art. 6, Annex III);Colorado AI Act が適用されます。NYC の場合は NYC LL144 が適用されます。
  • 医療 — 高リスク(EU);PHI を処理する場合は HIPAA が適用されます。
  • クレジット/金融 — 高リスク(EU);Colorado AI Act が適用されます。
  • 教育 — 高リスク(EU)
  • コンテンツ生成 — リスクは限定的(EU Art. 50 の透明性);一般的な義務(US)
  • GPAI モデルプロバイダー — GPAI Code of Practice が適用されます(EU)
ステップ 3 — リスク階層を判断する

ユースケースと選択したフレームワークに基づいて判断します。

  • EU を選択: references/eu-ai-act-gpai.md に従って、許容できないリスク/高リスク/限定的リスク/最小リスクに分類します
  • US を選択:高リスク(Colorado AI Act における重大な決定に関わるもの)または一般に分類します
  • ISO 42001 を選択:ISO 42001 ではリスク階層は正式な分類ではありませんが、システムがハイステークスかどうかを記載します(該当する場合、影響評価とバイアス管理の優先度が高まります)
フェーズ 0 の出力

簡単な概要を提示します。

Frameworks selected: {EU / US / ISO 42001 / combination}
Use case:            {category}
Risk tier:           {EU tier if applicable} / {US tier if applicable}
Applicable:          {list of specific regulations and standards}
ISO 42001 note:      {if selected} Audit covers technically-auditable controls only;
                     organisational clauses will be flagged but not code-audited.

その後、フェーズ 1 に進みます。

フェーズ 1:コードベースの監査(読み取り専用)

このフェーズでは、コードの記述やファイルの作成を行わないでください。

コードベースを体系的にスキャンし、7 つの領域にわたるコンプライアンスの証拠と不足を確認します。各領域について、記載された検索を実行し、結果を記録します。

A. 透明性と開示

確認する項目:

  • AI の関与を開示するユーザー向け文字列:UI テンプレート、API レスポンス、ユーザー向けコードで、AI、artificial intelligence、automated、bot、machine learning、generated by、powered by などの語句を検索します
  • コンテンツのラベル付け:AI 生成出力(テキスト、画像、音声)に付けられたマーカー
  • コードベース内の利用規約およびプライバシーポリシーへの参照

**懸念すべき兆候:**ユーザー向けコードに AI の開示がないこと。特に、アプリケーションがコンテンツを生成したり、推奨を行ったりする場合です。

B. データ保護とプライバシー

確認する項目:

  • コード内の PII フィールド名:プロンプト、コンテキスト、取得したドキュメント内の email、phone、ssn、social_security、date_of_birth、address、name
  • トレーススパンの属性に含まれる PII:input.value や output.value に個人データが含まれ、未編集のまま Arize に送信される可能性があるか確認します
  • 同意の仕組み:consent、opt-in、opt-out、gdpr、ccpa への参照
  • DPIA またはプライバシー評価への参照
  • データの保持および削除を処理するハンドラー
  • データ主体の権利:right_to_access、right_to_erasure、data_subject_request、data_protection_officer
C. セキュリティ

確認する項目:

  • プロンプトインジェクション対策:入力検証、ガードレールライブラリ(guardrails-ai、nemo-guardrails、rebuff、lakera)、コンテンツフィルタリング、システムプロンプトの保護
  • データ損失防止:ユーザーに返す前の出力スキャン、機密データの検出
  • ツール/関数呼び出しの制御:権限の境界、許可リスト、ツール実行のサンドボックス化
  • AI エンドポイントのレート制限と認証
  • ハードコードされたシークレット:ソースファイル内の api_key、secret、password、token のリテラル(環境変数への参照を除く)
D. テストと評価

確認する項目:

  • バイアスと公平性のテスト:人口統計学的均等性、影響比率、公平性指標への参照
  • レッドチーム演習または敵対的テストスイート:プロンプトインジェクションテスト、ジェイルブレイクテスト
  • 評価フレームワーク:Arize 評価器、カスタム評価スクリプト、pytest ベースの評価、実験インフラストラクチャ
  • A/B テストまたはモデル比較のインフラストラクチャ
E. ドキュメント

確認する項目:

  • モデルカード:MODEL_CARD.md、model_card.json、model_card.yaml、または同様のファイル
  • システムアーキテクチャのドキュメント
  • プロンプトやモデルの更新に関する変更履歴またはバージョン管理
  • インシデント対応に関するドキュメント
F. モニタリングとオブザーバビリティ

確認する項目:

  • Arize のトレーシング設定:arize-otel、register()、TracerProvider、opentelemetry、openinference のインポート
  • トレーシングが存在する場合は、対象範囲を確認します。
    • すべての LLM 呼び出しがトレースされているか(その一部だけではないか)
    • 会話の継続性を保つセッション ID
    • データ主体からの要求に対応するユーザー ID
    • エラー追跡と例外スパン
  • アラートとドリフト検出の設定
  • トレースの保持設定
G. ベンダー管理

確認する項目:

  • サードパーティ製 AI API の利用状況:OpenAI、Anthropic、Google、Azure、Bedrock、Cohere のインポートまたはクライアントのインスタンス化
  • モデルのバージョン管理:特定のモデルバージョン(例:gpt-4-0613)が固定されているか、latest またはバージョン指定のない識別子が使われているか
  • プロバイダー間のフォールバックおよびフェイルオーバーのロジック
フェーズ 1 の出力

2 部構成のレポートを提示します。

パート 1 — サマリーテーブル

ドメイン確認できた証拠特定されたギャップ評価
A. 透明性{findings}{gaps}準拠 / 一部準拠 / 非準拠 / 該当なし
B. データ保護{findings}{gaps}...
C. セキュリティ{findings}{gaps}...
D. テスト{findings}{gaps}...
E. ドキュメント{findings}{gaps}...
F. モニタリング{findings}{gaps}...
G. ベンダー管理{findings}{gaps}...

パート 2 — ギャップの詳細(非準拠または一部準拠と評価されたすべての項目について必須)

非準拠または一部準拠と評価されたドメインごとに、以下を含む専用のサブセクションを作成します。

  1. 正確なコードパス — ファイルパス、行番号、ギャップが存在する箇所を示す関連コードスニペットを記載します。言い換えず、実際のコードを引用してください。
  2. このアプリで重要な理由 — このコードベースにおける具体的なリスクを説明します(例:悪用される可能性のあるツール、露出するデータフロー、攻撃者や規制当局が確認できる内容)。
  3. 不足しているもの — 存在すべきだが欠けている制御またはコードを具体的に説明します(例:「PII のマスキングを追加」ではなく、「OTLP エクスポーターが実行される前に user_email をハッシュ化するスパン属性プロセッサ」)。

非準拠または一部準拠のドメインごとに、少なくとも 1 つのサブセクションを作成します。このセクションは省略しないでください。エンジニアリングチームにとって、監査の主要な価値となる部分です。

続けて、フェーズ 2 に進みます。

フェーズ 2:コンプライアンスチェックリスト

フェーズ 1 の調査結果と、references/compliance-checklist-template.md のテンプレートを使用して、状況に合わせたコンプライアンスチェックリストを作成します。

チェックリスト作成のルール
  1. 関連するセクションのみを含めます。 ユーザーの対象が米国のみの場合、GDPR 固有の項目は省略します。医療分野でない場合は HIPAA を省略します。ニューヨーク市で採用活動を行っていない場合は LL144 を省略します。
  2. フェーズ 1 の項目をマークします。 証拠が確認できた項目は Compliant とマークします。ギャップがある項目は、具体的な修正案を添えて Non-compliant とマークします。
  3. 適切に優先順位を付けます。 Critical = 執行リスクまたはシステムの禁止。High = 規制で必須。Medium = フレームワークで推奨。Low = ベストプラクティス。
  4. 修正内容を具体的にします。 「入力検証を実装する」ではなく、「guardrails-ai のようなガードレールライブラリを追加し、コンテンツポリシーに照らして LLM の入力と出力を検証する」と記載します。
  5. テンプレートのインストルメンテーション相互参照テーブルを含めます。 Arize のトレーシングが設定されていない場合、監査証跡は EU Art. 12 および NIST MAN-2.1 で必須であるため、Critical のギャップとして指摘します。
最終レポート

以下の 4 セクションで構成する、単一の統合レポートを提示します。

セクション 1 — 監査範囲(フェーズ 0 の概要)

  • 選択したフレームワーク、ユースケース、リスクティア、適用される規制

セクション 2 — コードベースの調査結果(フェーズ 1 のサマリーテーブル)

  • 証拠、ギャップ、評価を記載したドメインテーブル(A~G)

セクション 3 — ギャップの詳細(フェーズ 1 の詳細)

  • 非準拠または一部準拠のドメインごとのサブセクション。各サブセクションに、正確なファイルパスと行番号、引用したコードスニペット、アプリ固有のリスクの説明、不足しているものの具体的な説明を含めます。このセクションは必須です。省略しないでください。

セクション 4 — コンプライアンスチェックリスト(フェーズ 2)

  • 状況に合わせたチェックリスト(ステータスと修正案を含む)、インストルメンテーション相互参照テーブル、優先順位の概要、推奨する次のステップ

ユーザーがレポートファイルを求めた場合は、4 つすべてのセクションを含む単一の Markdown ファイルを /tmp/<app-name>-compliance-audit-<YYYY-MM-DD>.md に書き込みます。

レポートを提示した後、フェーズ 3 の修正対応を提案します。

フェーズ 3:是正(任意)

チェックリストを提示した後、特定の修正を実施するかどうかを提案してください。変更を加える前には、必ず AskUserQuestion ツールを使用して確認してください。

是正のカテゴリ

依存関係の追加 — 次のインストールを提案します:

  • 入力/出力の検証用ガードレールライブラリ(例:guardrails-ai、nemo-guardrails)
  • PII の検出/マスキング用パッケージ(例:presidio-analyzer、scrubadub)
  • コンテンツ安全性分類器

コードの挿入 — 次の追加を提案します:

  • ユーザー向け出力(テンプレート、API レスポンス)に AI 開示文を追加
  • Arize へのエクスポート前にスパン属性に PII マスキングフィルターを適用
  • AI エンドポイントに入力検証/サニタイズを追加
  • データ主体からのリクエストに対応するため、トレーススパンにユーザー ID 属性を追加

ドキュメントテンプレートの作成 — 次のひな形を作成します:

  • モデルカードのテンプレート(標準セクションを含む Markdown ファイル)
  • インシデント対応計画のテンプレート
  • データ処理記録のテンプレート

モニタリングの設定 — 関連スキルを使用して次を設定します:

  • バイアス検出とコンテンツ安全性のための Arize 評価器(arize-evaluator スキルを使用)
  • 監査証跡を網羅するためのトレーシング(arize-instrumentation スキルを使用)
是正のルール
  • 各是正策は、個別に確認できるアクションとして提示してください。変更をまとめて適用してはいけません。
  • 変更内容(ファイル、コード差分の概要)を正確に示したうえで、適用前に AskUserQuestion ツールを使用して確認してください。
  • 既存のコードスタイルとプロジェクトの規約に従ってください。
  • 認証情報を埋め込んではいけません。必ず環境変数を使用してください。
  • 変更後もアプリケーションがビルドできることをテストしてください。

スキルの連携

フェーズ 1 または 2 で特定したギャップへの対応に、他の Arize スキルの機能が必要な場合は、それらのスキルの実行を提案してください。他のスキルを実行する前には、必ず AskUserQuestion ツールを使用して確認し、コンプライアンス上のギャップに関連する理由を説明してください。

ギャップ実行するスキル理由
トレーシングがない/監査証跡が不完全arize-instrumentationEU 第 12 条と NIST MAN-2.1 はイベントのログ記録を求めています。Arize のトレーシングでこれに対応できます
バイアス評価または安全性評価がないarize-evaluator公平性、コンテンツ安全性、品質モニタリングのための LLM-as-judge 評価器を作成します
コンプライアンスの証拠としてトレースのエクスポートが必要arize-trace規制関連文書の作成やインシデント調査のためにスパンをエクスポートします
高リスクな判断に人間によるレビューが必要arize-annotationEU 第 14 条に基づく人間の監督のために、アノテーションキューを設定します
コンプライアンスの証拠を共有するためのディープリンクが必要arize-link関係者によるレビュー用に、特定のトレース、スパン、または評価への URL を生成します

インストルメンテーションの相互参照

Arize のトレーシングがすでに設定されている場合は、コンプライアンス要件を満たしているか確認してください。

コンプライアンス上のニーズ必要なトレースデータ確認する内容
AI の判断に関する監査証跡入力/出力を含むすべての LLM スパン一部だけでなく、すべての LLM クライアント呼び出しがインストルメント化されていることを確認します
データ主体からのアクセス要求スパン上のユーザー ID 属性user.id またはカスタムのユーザー識別子属性があるか確認します
トレース内の PIIinput.value/output.value 内の機密データPII がマスキングされずに通過していないか確認します。通過している場合は指摘します
インシデント調査全コンテキストを含むエラースパンスパンに例外追跡とエラーステータスがあるか確認します
保持要件必要な期間保持されたトレースデータEU:適切な期間(高リスクの場合は最低 6 か月)。HIPAA:6 年
バイアスモニタリング人口統計またはグループの属性公平性分析を可能にするメタデータ属性があるか確認します

Arize のトレーシングが設定されていない場合、これは重大なコンプライアンス上のギャップです。次のように提案してください:「監査証跡のトレーシングを設定するために、arize-instrumentation スキルを実行しますか?規制の枠組み(EU AI Act 第 12 条、NIST AI RMF MAN-2.1)では、AI システムのイベントログ記録が求められています。」

参考リンク

リソースURL
EU AI Act 全文https://eur-lex.europa.eu/eli/reg/2024/1689/oj
GPAI Code of Practicehttps://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
Code of Practice ポータルhttps://code-of-practice.ai/
NIST AI RMFhttps://www.nist.gov/artificial-intelligence/ai-risk-management-framework
Colorado AI Act(SB24-205)https://leg.colorado.gov/bills/sb24-205
NYC Local Law 144https://www.nyc.gov/site/dca/about/automated-employment-decision-tools.page
HIPAAhttps://www.hhs.gov/hipaa/index.html
ISO/IEC 42001:2023https://www.iso.org/standard/42001.html
Arize AX ドキュメントhttps://arize.com/docs/ax

参考ファイル

コメント