NIST AI RMFで考えるClaude導入ガバナンス

1. はじめに：Claude導入の課題を、NIST AI RMFで整理する

DXソリューション営業本部の三浦です。

AIガバナンス・セキュリティ・アーキテクトの視点から、NIST AI RMF（AIリスクマネジメントフレームワーク）1.0の「コア」構造に沿って、Claude（Team / Enterpriseプラン）を組織へ導入・運用する際に「考えるべきこと」と「Claudeで実現する手段」を整理します。本稿はチェックリストでも、そのまま従うべき手順書でもありません。NIST AI RMF Playbookと同じく、自組織のユースケースに応じて取捨選択するための"手引き"として活用してください。

本稿について：本稿は NIST AI RMF（NIST AI 100-1）を参考に QUICK E-Solutions（QES）が独自に作成した解説記事であり、NIST や Anthropic をはじめとする第三者による公式文書・公式見解ではありません。また、特定の認証の取得・法令遵守・コンプライアンス適合を保証するものではありません。実際の適合性の判断は、各組織の責任のもと、公式ドキュメントや専門家の確認を経て行ってください。

本稿の情報時点：2026年7月。Claudeのモデル世代・プラン機能・提供リージョンは頻繁に更新されます。本文中の仕様・数値には公式ドキュメントへのリンクを併記していますが、導入設計時には各リンク先で最新の状態をご確認ください。

Claudeのような生成AIを組織へ導入するとき、多くの企業がぶつかるのは「使わせたい。でも、どこまで・どんな統制で使わせればよいのか」という課題です。判断の拠り所がないまま個別対応で進めると、統制の抜け漏れが生じたり、逆に過剰な制限で活用が進まなかったりします。この課題を体系立てて整理するのに有効なのがNIST AI RMFです。

NIST AI RMF とは

NIST AI RMF（AI Risk Management Framework）は、米国国立標準技術研究所（NIST）が2023年に公開した、AI特有のリスクを管理するためのフレームワークで、国際的に広く参照されています。主な性格は次のとおりです。

• 任意適用・分野非依存：規制（守らないと罰則）ではなく、あらゆる業種・規模の組織が自主的に使えるガイダンス。
• 開発者だけでなく、導入・運用・利用する組織も対象：他社が開発したAI（＝Claude）を導入する自社は、このフレームワーク上「デプロイヤ／運用者」というAIアクターの立場でこれを使います。「AIを作る側」だけの話ではありません。
• 「禁止事項リスト」ではなく「問いの構造」：組織が自らに問いを立て、リスク許容度に応じて統制の強度を自分で決めるための枠組みです。その中核（コア）が、次に示す GOVERN / MAP / MEASURE / MANAGE の4機能です。

Claude（特にEnterpriseプラン）は、このフレームワークが問う「技術的堅牢性」と「組織的統制」の一部を、具体的な機能として実装できます。本稿は、NIST AI RMF の4機能を"共通言語"に、Claude導入で決めるべきことを「問い（考えるべきこと）」と「Claudeで実現する手段」の形で整理します。

NIST AI RMFコアの構造

NIST AI RMFのコアは、次の4つの機能で構成されます。

ここで押さえておきたいのは、NISTが明言している2つの原則です。

• 4機能は逐次的な手順ではなく、反復的（iterative）に実施する。GOVERNで土台を作ったうえで、多くの組織はMAP→MEASURE/MANAGEへと進みますが、順序は固定ではなく、機能間を相互参照しながら回し続けるものです。
• GOVERNは他の3機能と並列の「4番目のステップ」ではなく、全体を貫く横断的機能である。したがって本稿でも、GOVERNを土台として最初に置き、MAP・MEASURE・MANAGEを個別の実践として展開します。

サブカテゴリの扱いについて

各機能はさらにカテゴリ・サブカテゴリに分かれますが、その多くは「人材の訓練」「方針文書」「多様性」「ステークホルダ参画」といった組織的なアウトカムで、製品機能で直接カバーできる性質のものではありません。

そこで本稿はフレームワーク全体を網羅することを目的とせず、Claude（Team / Enterprise）で技術的に対応できる部分に絞って解説します。あくまで"AIツール側で実現できる統制"の視点です。対応する箇所には、NISTの原典を参照しやすいよう要所にサブカテゴリ番号（例：GOVERN 1.6＝AIシステムの棚卸し）を併記します。

以下、各機能について「NISTが問うこと（考えるべきこと）」と「Claude（Team / Enterprise）で実現する手段」の2段構成で解説します。

2. GOVERN（統治）：リスク管理の土台と責任の所在を築く

NISTの意図：AIリスクをMAP・MEASURE・MANAGEするための組織全体の方針・プロセス・体制を整備し、透明性をもって効果的に実施する。GOVERNは法規制対応、方針の文書化、役割と責任、AIシステムの棚卸し、廃止、サードパーティ・リスクまでを含む、最も広い機能である。

考えるべきこと

• 自社にAI利用の方針（ポリシー）は文書化されているか。誰が何のために、どこまでの範囲で使ってよいかが定義されているか。（GOVERN 1.1＝法的・規制的要件／1.2＝トラストワージ特性の方針への統合）
• AIに関する役割・責任・指揮系統は明確か。最終的な意思決定者と、その権限の委譲関係は定義されているか。（GOVERN 2.1＝役割と責任・コミュニケーションライン／2.3＝経営幹部の責任）
• 組織で使われているAIシステム・アカウントを棚卸しできるか。誰がアクセスできるかを把握・是正できるか。（GOVERN 1.6＝AIシステムの棚卸し）
• 利用終了時のアカウント停止・データ削除の手順は定まっているか。（GOVERN 1.7＝安全な廃止・段階的廃止）
• コネクタや外部ツールといったサードパーティ資源の利用可否は統制されているか。（GOVERN 6.1 / 6.2＝サードパーティのソフトウェア・データ・AIシステムのリスク）

Claude（Team / Enterprise）で実現する手段

① アイデンティティ基盤の一元管理

② 運用ポリシーとして定めるべき事項

• Primary Ownerのサービスアカウント化：個人の異動・退職によるロックアウトを防ぐため、Primary Ownerは個人に紐付けないサービスアカウントで運用することを推奨します。
• 招待プロセスの定義：メール招待の有効期限は21日間です（招待リンク自体の有効期限は明記されておらず、管理者はいつでも無効化・再生成できます）。SSOを必須化した組織では招待リンク機能は使えず、プロビジョニングはIdP経由（JIT / SCIM）に一本化されます。期限切れ後の再送フローを運用に織り込んでください。（出典：Team / Enterpriseプランのメンバー管理）
• 認証経路の把握（意図しないアクセスの防止）：Claude Codeでは、環境変数・OAuthログイン・クラウド設定など複数の資格情報が同時に存在すると、決まった優先順位で機械的に1つが選ばれます。これを把握していないと、意図しない組織・課金・データ境界で動作したり、無効化された組織のキーで認証が失敗したりします。運用では /status で使用中の認証方式を可視化し、managed settings で認証設定を中央管理、テナント制限（anthropic-allowed-org-ids）と組み合わせて二層で防御します。（出典：Claude Code 認証）

③ サードパーティ資源のガバナンス

• コネクタ（Connectors）の統制：Google Drive・Slack等の外部連携は、Team / Enterpriseプランで「常に許可（Always allow）」「要承認（Needs approval）」「ブロック（Blocked）」の3段階を、全体・コネクタ単位・ツール単位で制御できます。（出典：コネクタでClaudeの機能を拡張する）
• MCP・許可ツール（allowed tools）：利用を認めるツール・コマンドをホワイトリスト化し、サーバー管理設定（server-managed settings）で端末へ配布します。サーバー管理設定は Claude for Teams / Enterprise で利用でき、利用には対応バージョンの Claude Code が必要です（必要バージョンは変動するため、公式ドキュメントで最新の要件を確認してください）。（出典：サーバー管理設定の構成）

補足：Team / Enterpriseプランでは、入力・出力データが既定でモデル学習に利用されません（規約上、コマーシャル製品として学習対象から除外。フィードバック提供等は明示的なオプトイン）。この「学習に使われない」という前提は、GOVERNの方針文書に明記しておくべき基礎的事実です。（出典：私のデータはモデル学習に使われますか？）

3. MAP（マッピング）：文脈を理解し、リスクの境界を定義する

NISTの意図：AIシステムの文脈・目的・想定ユーザー・潜在的インパクトを特定し、リスクの境界を枠組みする。ここで得た知識がMEASURE・MANAGEの基礎となり、「そもそも導入すべきか」の初期判断（Go/No-Go）を支える。

考えるべきこと

• どの部門が、どのユースケースで、どんなデータを扱うのか。データの境界はどこか。（MAP 1.1＝意図された目的・コンテキスト・展開設定の理解／MAP 1.6＝システム要件（例：プライバシー尊重）の抽出）
• 部門・職責ごとに、許容できるリスクと必要な機能は異なるのではないか。一律の設定で本当によいか。（MAP 3.3＝対象とする適用範囲の特定・文書化）
• 外部データソースとの連携によって、どんなデータフローが新たに生まれるか。（MAP 4.1＝サードパーティのデータ／ソフトウェア利用を含むリスクのマッピング）
• 部門ごとの利用規模・コスト（＝リソース消費リスク）の許容度をどう設定するか。（MAP 1.5＝組織のリスク許容度の決定・文書化）

Claude（Team / Enterprise）で実現する手段

• プロジェクト（Projects）：Chat・Coworkで、ナレッジベースと会話（タスク）を論理的なスコープにまとめ、データの取り扱い単位を明確にします。データ保持については、プロジェクトレベルの設定がチャットレベルの設定に優先し、組織レベルの設定がベースラインとなる階層関係に留意してください。なお Claude Code はプロジェクトではなく、リポジトリ単位と CLAUDE.md でコンテキスト・データ境界を管理するため、サーフェスごとに"データの単位"が異なる点に留意が必要です。（出典：プロジェクトとは ／ Enterpriseのカスタムデータ保持設定）
• コネクタ（Connectors）：外部連携によるデータフローを可視化・特定します（統制自体はGOVERNで、フローの"特定"がMAPの役割）。
• カスタムロール（Custom Roles）：Enterpriseプランでグループ単位にAI機能を制限します。カスタムロールを付与されたメンバーは既定権限を持たず、割り当てられたロールで許可された機能のみ利用できます。（出典：Enterpriseのカスタムロール管理）

具体的活用例：部門に応じた機能制限

• 開発部門：コード生成・実行が不可欠なため、コード実行機能やターミナルツール「Claude Code」へのアクセスを許可。
• 営業部門：誤操作や過剰なリソース消費のリスクを抑えるため、コード実行や高度な推論を制限しつつ、CRM連携コネクタのみを承認制で許可。

支出上限（Spend Limit）による"リスク許容度"の設計

部門ごとの支出上限をグループ単位で設計します。ユーザーが複数の制限グループに所属する場合の調停ルール（「Multi-group spend limit」設定）を定義してください。

• Lower group limit：特定サブグループに厳しい予算を課したい場合に適用。
• Higher group limit：全社ベースラインに対し、特定の開発部門等へ高い自由度を与えたい場合に適用。

（出典：Enterpriseのグループ・グループ支出上限管理）

4. MEASURE（測定）：リスクを定量的に可視化する

NISTの意図：MAPで特定したリスクを、定量・定性・混合の手法で分析・評価・ベンチマーク・モニタリングする。測定できないものは管理できない――MEASUREの出力がMANAGEの前提となる。

考えるべきこと

• 「誰が・いつ・どのような操作をしたか」を追跡・監査できるか。操作証跡は、実運用でのAIリスクを継続的に把握する仕組み（MEASURE 3.1）を支える基礎データの一つとなります。
• 監査に必要な情報を、既存のSIEM / SOC基盤へ機械的に取り込めるか。
• 誰が・どこで・どれだけ使っているかを可視化し、想定外の利用やシャドーAI（管理外の利用）を検知・是正できるか。

Claude（Team / Enterprise）で実現する手段

手段はプランとサーフェス（Chat / Cowork / Code）で使えるものが変わります。「誰が何をしたか（操作証跡）」と「何を入力したか（会話内容）」は別の経路で取る点がポイントです。

3行で要約：①操作証跡（誰が何をしたか）＝監査ログ（Enterprise専用、内容は含まない）。②会話・内容そのもの＝Compliance API（Enterprise・claude.ai組織）またはOTel（Cowork/Code）。詳細は以下の各項目・表を参照してください。

• 監査ログ（Audit Logs）＝"組織で何が起きたか"の証跡：Enterprise 専用。claude.ai組織の操作イベント（認証、メンバー招待、プロジェクト・会話の操作、SSO設定、ドメイン検証など）を過去180日分取得できます。会話の内容は含まれず、タイトル・本文はエクスポートされず一意の識別子（UUID）のみが出力されます――"誰が何をしたか"の証跡であって、"何を入力したか"ではない点に注意。（出典：監査ログへのアクセス）
• Compliance API＝"プログラムで取得"：Claude Enterprise顧客が対象です。プログラムから取得でき、SIEM・DLP・eDiscovery基盤へ連携できます。内容取得には Compliance Access Key が必要で、レート制限は親組織あたり600 req/min。Claude Console（API/Platform）組織は申請制で利用可能で、内容取得はEnterprise（claude.ai組織）に限られます。（出典：Compliance API ／ Compliance APIの設定）
• OpenTelemetry (OTel)＝"会話・操作の内容ログ"を取る経路：監査ログが内容を持たないのに対し、プロンプトやツール実行などの内容ログは OTel で取得します。
  • Claude Cowork：Team / Enterprise 両対応。プロンプト内容やファイルアクセスが既定でイベント出力されます（リダクトはコレクタ側で設定）。（出典：CoworkのOTel監視）
  • Claude Code (CLI)：メトリクス・イベントを出力。プロンプト／応答／ツールの内容は既定でリダクトされ、OTEL_LOG_USER_PROMPTS=1 等の明示設定でのみ含められます。（出典：Claude Codeの利用監視）
• Analytics API＝"利用の可視化"：ユーザー別・組織別の利用量やコストを集計値で取得。NIST的には「リスクの測定」というより利用の可視化――誰がどれだけ使っているかを把握し、想定外の利用やシャドーAIを是正する統制――に位置づけられます（Compliance APIが個別イベント単位なのに対し、Analytics APIは集計値）。（出典：Compliance API（Analytics APIの項））

Bedrock構成での測定：Amazon Bedrock経由でClaudeを利用する場合、InvokeModel / Converse 等のAPI呼び出しはAWS CloudTrailに記録され、メトリクスはAmazon CloudWatchで監視できます。ただしCloudTrailの管理イベントに残るのは操作メタデータ（実行者・時刻・リクエストID等）のみで、プロンプトや応答の内容は含まれません。入出力のペイロードまで記録するにはモデル呼び出しログ（Model invocation logging）をCloudWatch Logs／S3へ有効化します。この組み合わせにより、AWSネイティブの監査・監視基盤を測定手段として活用でき、既にAWSを統制基盤としている組織――とりわけ日本国内レジデンシーが必要な組織――にとって大きな利点となります。（出典：CloudTrailによるBedrockのログ記録 ／ モデル呼び出しログ）

5. MANAGE（管理）：リスク対応と技術的制御を実施する

NISTの意図：MAP・MEASUREの結果に基づき、リスクへの対応（回避・低減・移転・受容）とリソース配分を実施する。ここには「異議申し立て」「無効化」「インシデント対応」といった継続的な制御活動も含まれる。

考えるべきこと

• 認可された組織以外へのデータ流出（個人アカウント経由の持ち出し等）をネットワーク層で防げるか。（MANAGE 1.x＝優先順位に基づくリスク対応の実施）
• 暗号化キーを自社管理下に置き、キー失効によるアクセス遮断を担保できるか。
• 推論の実行場所・データの所在（データレジデンシー）を、自社のコンプライアンス要件に合わせて制御できるか。
• 端末に配布する設定・権限を中央管理し、逸脱を防げるか。（MANAGE 4.x＝リスク対応の文書化・モニタリング・コミュニケーション）

Claude（Team / Enterprise）で実現する手段

MANAGEは、MAPで組織が特定・優先順位付けしたリスクに対して、軽減・移転・回避・受容のどの対応を取るかを決めて実施する機能です（MANAGE 1.3）。リスクの特定・優先順位付けそのものは組織側（MAP）の作業のため本稿では踏み込まず、ここではフレームワークに則って、Claude／構成側で対応できる 「① リスク対応（軽減）の実施」 と 「② 監視・調査・停止の仕組み」 を整理します。

① リスク対応（軽減）の実施

MAPで特定されたリスクに対する「軽減（mitigation）」の技術的選択肢です。

• CMEK（顧客管理暗号化キー）：AWS KMS / Google Cloud KMS / Azure Key Vault で自社鍵を管理します。CMEKを有効化すると、UI上の監査ログ・エクスポートが無効化され、会話履歴の検索も無効化される（タイトルが暗号化されるため）ため、監査はCompliance API（意図的に暗号化対象外とされているActivity Feed）経由に一本化されます。（出典：CMEK）
  • 注意：CMEK（ファーストパーティ機能）は米国リージョン限定のため、後述の日本国内レジデンシー（Bedrock東京）とは現時点で両立しません。日本レジデンシーが要件でかつ自社鍵管理も必要な場合は、Bedrock構成でAWS KMSを用いて鍵管理を担う設計になります。「CMEK（ファーストパーティ）」と「日本国内推論」はどちらを優先するかを要件定義で切り分けてください。
• 推論ロケーション制御／データレジデンシー（日本国内推論）：推論の実行場所とデータの所在を要件に合わせて制御できます。ただし提供形態によって選択肢が根本的に異なる点に注意が必要です。

  提供形態	推論ロケーションの選択肢	日本国内レジデンシー
  Anthropic ファーストパーティAPI（Anthropic直接提供） / Claude Enterprise	inference_geo は us（米国固定）または global（グローバル）のみ。ワークスペースのデータ所在は us のみ。	不可（ファーストパーティでは日本レジデンシーは提供されない）。
  Amazon Bedrock（QESの提供形態）	東京リージョン（ap-northeast-1）で利用可能。日本地理限定のクロスリージョン推論プロファイル（jp.）は東京↔大阪（いずれも日本国内）間のみでルーティング。	可能（jp. プロファイルで推論を日本国内に閉じられる）。

  • ファーストパーティAPIで米国固定（inference_geo: "us"）にした場合、標準料金の 1.1倍 になります（この 1.1倍と inference_geo は「Opus 4.6 / Sonnet 4.6 以降」のモデルに適用される、という公式に定義されたしきい値です。値の指定は us / global のみ、ワークスペースのデータ所在は us のみ）。（出典：データレジデンシー）
  • 対応モデルは頻繁に更新されます。東京リージョン／jp. プロファイルで利用できる具体的なモデルは随時追加されるため、本稿では個別のモデル名を挙げません。導入時は必ず AWSのモデル対応リージョン一覧 で最新の状態を確認してください。

  ➡ 日本国内でのデータレジデンシーが要件となる場合、Amazon Bedrock（東京リージョン＋jp. 推論プロファイル）が現実的な解となります。 この構成では、ファーストパーティ機能（Compliance API・CMEK・ネイティブ監査ログ）ではなく、後述のAWSネイティブ基盤（CloudTrail／モデル呼び出しログ／Bedrock Guardrails／AWS KMS）で統制を担います。QESはこの構成での環境構築・調達を支援します。

• サーバー管理設定 / 許可ツール：端末の設定・権限ポリシーをサーバー側で中央管理し、逸脱を防ぎます（Claude for Teams / Enterprise で利用可。必要な Claude Code バージョンは公式ドキュメントで確認）。（出典：サーバー管理設定の構成）

② 監視・調査・停止の仕組み

「対応が実際に守られているか」を継続的に監視し、逸脱・インシデントに対処する仕組みです（MANAGE 2.4 / 4.1 / 4.3）。いずれも本稿で既に触れた統制を、この目的で束ね直したものです。

• 遵守の監視・調査：4 MEASURE の経路（監査ログ／Compliance API／OTel）＋ SIEM で、ポリシー通りに使われているかを継続的に監視し、禁止ツールの使用・スコープ外アクセス・コスト急増などの逸脱を調査します。
• 停止・無効化（封じ込め）：インシデント時には、2 GOVERN の SSO / SCIM によるアカウント無効化、および ① のテナント制限の更新で、対象のアクセスを速やかに遮断します。
• ※ インシデント対応計画（MANAGE 4.1）・関係者への通知フロー（MANAGE 4.3）・継続的な改善サイクル（MANAGE 4.2）は組織側の作業です。手順化は導入チェックリスト（運用ルール）や QES の導入支援で具体化します。

6. まとめ：成熟度に応じた導入ロードマップ

NIST AI RMFは「一度導入して終わり」ではなく、脅威動向に合わせて更新し続けるリビングドキュメントです。継続的な測定結果を管理プロセスへフィードバックし、安全なAI活用サイクルを維持してください。組織の成熟度に応じて、次のステップでの導入を推奨します。

ステップ1：基本統制（Self-serve Enterpriseで対応可）

• ドメイン検証とSSOの必須化
• サービスアカウントによるPrimary Ownerの確立
• 基本的なテナント制限の導入

ステップ2：高度なガバナンスと可視化

• ログ取得による監査対策と、利用状況モニタリング
• 部門別カスタムロールと、Higher / Lowerルールに基づいた支出統制

ステップ3：最高度の規制・コンプライアンス対応（必要な場合）

• CMEKの適用（UIログ抽出・検索停止を前提とした運用）
• 推論ロケーション制御／データレジデンシー要件への対応（日本国内推論が要件の場合はAmazon Bedrock東京リージョン＋jp.プロファイル構成）
• IP許可リスト（CIDR）のセールス経由での適用

参考：主なセキュリティ適合性と業界標準

Claudeは、以下の主要な第三者認証および標準に適合しています（各認証の最新の取得状況は下記の公式ページで確認してください）。これらは、規制業界での対応根拠（MANAGE 1.3）や自社の法令遵守の確認（GOVERN 1.1）を支える"証跡"として活用できます（適用法令の特定・充足判断そのものは組織側の責務です）。

• SOC 2 Type I & Type II：セキュリティ・可用性・機密性の検証済み。
• CSA STAR：クラウドセキュリティの第三者評価。
• ISO 27001:2022 / ISO 42001:2023：情報セキュリティおよびAIマネジメントシステムの国際規格。
• HIPAA：医療情報の保護（Sales-assisted EnterpriseプランにてBAA締結が可能）。
• NIST 800-171：非分類の管理対象情報（CUI）保護基準への適合（第三者アテステーションレターをNDA下で提供）。
• FedRAMP High：米国政府最高レベルのセキュリティ認可（Claude for Government）。
• モデルトレーニングのオプトアウト：Team / Enterpriseプランでは、入力データが既定でモデル学習に利用されないことが規約で保証されています。

（出典：Anthropicが取得している認証 ／ 公共部門FAQ ／ データはモデル学習に使われるか）

QESでは、ガバナンス整備・セキュアな利用環境構築・利活用コンサルティング・セキュリティレビューまで、Claude / Claude Code の組織導入を一貫して支援しています。AWS（Amazon Bedrock）経由での提供にも対応しています。支援内容は下記のサービスページ、および無料の「Claude 導入チェックリスト」をご覧いただくか、お問い合わせフォームよりお気軽にご相談ください。

※このブログで参照されている、Anthropic、Claude、Claude Code、Claude Cowork は、Anthropic, PBCの米国およびその他の国における商標または登録商標です。