Claude Media
ClaudeとDrataを連携する方法 — コンプライアンス管理を会話で進める

ClaudeとDrataを連携する方法 — コンプライアンス管理を会話で進める

Drata公式のMCPサーバーをClaudeに接続し、コントロール・証跡・リスク・ベンダーを会話で扱う手順です。OAuthスコープの決め方と、書き込み・削除系ツールの扱いをまとめます。

Claude Drata連携とは何か

Drata連携は、コンプライアンス管理(GRC)プラットフォームのDrataが公式に提供するMCPサーバーを、ClaudeのConnectorとして接続する仕組みです。コントロール、ポリシー、リスク、証跡(Evidence)、フレームワーク、ベンダー、従業員、デバイスといったDrata上のデータを、自然文で検索したり更新したりできます。

開発元はDrata Inc.で、Connectorsディレクトリには「Anthropic verified」の表示付きで掲載されています。カテゴリーは「Productivity」、追加時期は2026年8月、サインインは必須です。接続先のURLは https://mcp.drata.com/mcp です。Connector全般の仕組みはClaude Connectorsの解説にまとめてあります。

この連携の特徴は、読み取りだけでなく書き込みと削除まで届く点です。証跡やリスクの作成・削除は、そのまま監査の記録に影響します。接続手順よりも、どの権限を渡すかの設計が記事の中心になります。

接続前に決めておくこと:管理者のOAuth設定が先

Drata MCPの初回セットアップは2段階です。先にDrataの管理者がテナント側でOAuthを設定し、そのあとで各ユーザーがClaudeから接続します。管理者側の設定が済んでいないと、ユーザーは接続できません。

手順

管理者のOAuth設定(Drataの管理者権限が必要)

  1. 1

    設定画面を開く

    Drataの「Settings」から「MCP OAuth Configuration」を開きます。

  2. 2

    名前と説明を入れる

    あとで見返したときに用途が分かる名前にします。

  3. 3

    有効期限を決める

    手順に有効期限の入力が含まれています。期限が切れたあとの再承認は、権限の棚卸しを兼ねた運用にできます。

  4. 4

    付与するスコープを選ぶ

    読み取りだけか、書き込みまで含めるかをここで決めます。

地域ごとにサーバーURLが分かれる

DrataのリモートMCPサーバーは、データの所在地ごとに3系統あります。

地域URL
米国URLhttps://mcp.drata.com/mcp/
欧州URLhttps://mcp-euc1.drata.com/mcp/
アジア太平洋URLhttps://mcp-apse2.drata.com/mcp/

Connectorsディレクトリに載っているコネクタURLは、米国のURLだけです。欧州やアジア太平洋のテナントは、Drataのヘルプにある自社の地域のURLに合わせてください。

Claudeから接続する手順

管理者の設定が終わったら、ユーザーがClaudeで接続します。Drataのヘルプは、Claude側のセットアップをAnthropicのガイドに委ね、会話ごとの有効化を案内しています。手順は次の2段階です。

手順

ユーザー側の接続

  1. 1

    Connectorsディレクトリから追加する

    Anthropicのガイドに従ってClaudeのConnectorsからDrataを追加し、Drataのサインイン画面でOAuth認証を完了します。

  2. 2

    会話ごとに有効にする

    会話の「+」メニュー→「Connectors」からDrataを有効にします。

Drataのヘルプによると、OAuth認証ではClaudeにDrataの資格情報が渡りません。ClaudeがDrata上でできるのは、ユーザー本人がDrataで持つ権限の範囲までです。Team・Enterpriseプランの組織側の有効化については、Ironcladの連携記事に手順があります。

OAuthスコープと役割:渡す権限をどう決めるか

Drata MCPの権限は、OAuthスコープとユーザーのDrata上の役割(ロール)の掛け合わせで決まります。ユーザーが使えるのは、設定されたスコープが許す操作と、そのユーザーのロールが元々許す操作の重なりだけです。Drataで許されていない操作は、MCP経由でもできません。

スコープは「読む」「作る」「更新する」「削除する」の動詞と対象(リスク、コントロール、証跡、ベンダーなど)の組み合わせで並んでいます。

対象読み取り書き込み系
リスク読み取りread:risk / read:risk-registers書き込み系create:risk / update:risk / delete:risk
コントロール読み取りread:frameworkなど書き込み系create:control / update:control
証跡読み取りread:evidence書き込み系create:evidence / update:evidence / delete:evidence
ベンダー読み取りread:vendor / read:vendor-security-review / read:vendor-document書き込み系create:vendor / update:vendor / delete:vendor
従業員読み取りread:personnel / read:device書き込み系update:personnel / create:user-document / create-restricted:personnel
ポリシー・テスト読み取りread:policy / read:assigned-policies / read:monitor-test書き込み系なし

Drataのヘルプが書き込みを許すと明記しているのは、証跡の作成・更新・削除、コントロールの作成・更新、従業員情報の更新です。表のほかに、ワークスペース(read:workspace)やユーザー情報(read:users / read:user)を読むスコープもあります。

同じスコープでもロールで通る範囲が違う

スコープ表には、スコープごとの許可ロールが並んでいます。ここを読むと、同じ設定でも誰が使うかで効く範囲がかなり変わります。代表的なロールを並べると次のとおりです。

ロール通る書き込み系通らない読み取りの例
Control Manager通る書き込み系コントロールの作成・更新、証跡の作成・更新・削除通らない読み取りの例リスク・ベンダー・従業員
DevOps Engineer通る書き込み系コントロールの作成・更新通らない読み取りの例証跡の作成・更新・削除(読み取りは可)
Risk Manager通る書き込み系リスクとベンダーの作成・更新・削除通らない読み取りの例証跡・フレームワーク・モニタリングテスト
People Ops通る書き込み系従業員情報の更新、従業員文書のアップロード通らない読み取りの例証跡
Employee通る書き込み系なし通らない読み取りの例自分に割り当てられたポリシーとユーザー一覧のみ

DevOps Engineerが証跡を読めても作れない点は、証跡の自動登録を任せたい場合に効きます。Risk Managerは read:evidence の許可ロールに入っていないため、スコープを足しても証跡は読めません。

Employeeでも通る read:assigned-policies は、例文集の「General & knowledge」にある質問に対応します。「スマホでJiraを使ってよいか」「セキュリティ研修の頻度は」といった、ポリシーに答えがある問いです。従業員向けに読み取り専用で開く使い方に向くスコープです。

ほかに、次の3点がスコープ表の注記にあります。

  • read: のスコープは、各ロールの閲覧専用版(Read-only Admin、Read-only Control Managerなど)でも同じ範囲を読める。閲覧専用ロールは作成・更新・削除のスコープを使えない
  • Service User(連携用)ロールは、表のすべてのスコープと同等のアクセスを持つ
  • read:workspace を許すのはAdminだけで、Workspace Administratorは入っていない

従業員に関わるスコープは別扱い

create:user-document は、セキュリティ研修やHIPAA研修の修了証、MFAの証跡、退職時の証跡といった従業員のコンプライアンス文書をアップロードするスコープです。単独では動かず、create:evidence か update:evidence と組で使う仕様です。

ロール表では、People Opsは create:user-document の許可ロールですが、create:evidence と update:evidence の許可ロールには入っていません。この組み合わせでPeople Opsが文書を登録できるかは、スコープ表だけでは決まりません。人事部門に任せる前に、試験用の接続で実際に通るかを見ておく手があります。例文集には、ファイルを添付する代わりに「修了証のアップロード用リンクをください」と頼む形もあります。

create-restricted:personnel は、個々の従業員の記録に退職時の証跡を書き込むスコープです。Drataのヘルプは、個人の記録へ書き込むアプリケーションを信頼できる場合にだけ付与するよう注意しています。許可されるロールも、AdminとWorkspace Administratorに絞られています。

読み取りだけで始める

書き込み系スコープは慎重に付与するよう、Drataのヘルプが2か所で念押ししています。この方針を運用に落とすなら、最初は read: で始まるスコープだけで設定を作る形が現実的です。読み取りだけでも、リスクの棚卸しや失敗しているモニタリングテストの一覧、ベンダー更新期限の確認まで回せます。

書き込みが要る業務が見えてから、対象を絞ってスコープを足します。たとえば証跡の登録だけを任せるなら、read:evidence・create:evidence から始めます。紐づけ先のコントロールを読むスコープはスコープ表から特定できないため、試験接続で通るかを確かめます。スコープを足した設定は、次に説明する再接続が必要になります。

ツールの一覧:ディレクトリに見えるもの

Connectorsディレクトリには、Drataのツールが「Show all 36 tools」という表記付きで載っています。初期表示の24個は、名前から用途がおおよそ分かります。

種別ツール
作成ツールDrata_createControl / Drata_createEvidence / Drata_createRisk / Drata_createVendor
削除ツールDrata_deleteEvidence / Drata_deleteEvidenceArtifact / Drata_deleteRisk / Drata_deleteVendor
取得ツールDrata_getCompany / Drata_getEvidence / Drata_getVendor
一覧ツールDrata_listDevices / listEvidence / listEvidenceArtifacts / listPersonnel / listPersonnelGroups / listPolicies / listRequirements / listRiskRegisters / listVendorDocuments / listVendorSecurityReviews / listVendors / listWorkspaces
照会ツールDrata_lookupUserIdentity

残りの12個は、初期表示に名前が出ていません。ツール名とスコープの対応も表に書かれていないので、接続後にClaudeが提示するツール一覧で突き合わせてください。

削除系は4つ(証跡・証跡ファイル・リスク・ベンダー)です。スコープ側も同じ形で、削除のスコープは delete:risk・delete:evidence・delete:vendor の3つだけです。コントロールには作成・更新のスコープがあるものの、削除のスコープは表にありません。例文集で削除を頼む例が出てくるのも、証跡・リスク・ベンダーの3領域です。

Claudeへの頼み方:公式が勧める書き方

Drataのヘルプは、プロンプトの書き方を3点案内しています。

  • Drataの名前を入れる: 「どのコントロールに証跡がないか」ではなく「Drataで、どのコントロールに証跡がないか」と書く。Claudeが内蔵知識でなくDrataのツールへ振り分けるためです
  • 具体的に頼む: フレームワーク名、期間、リスク分類、チーム名を含める
  • 自然文で頼む: コントロールはコード(CC6.1など)、担当者は名前かメールアドレス、従業員グループは名前で指定する。IDは要りません

例文集から、読み取りの型と書き込みの型を1つずつ引きます。

Drataで、SOC 2 CC6に紐づくコントロールのうち、
モニタリングされていて現在失敗しているものを一覧にして。

この種の依頼は読み取りだけで完結します。書き込みの型は次のようになります。

Drataで「四半期ごとのアクセスレビュー」というコントロールを
作成して、SOC 2 CC6.1に紐づけて。

両方ともDrataの例文集にある依頼の型です。Claudeが実際にどう応答するかは、テナントの設定とロールによって変わります。

担当者の指定は置き換えになる

コントロールの担当者など関係先の一覧を指定するとき、「担当者を設定する」と頼むと既存の担当者が置き換わります。既存の担当者を残したまま加えたいときは、「今の担当者を外さずに追加して」と明示する必要があります。Drataの例文集にも without removing the current ones の但し書きがあります。

書き込みと削除を任せる前に:運用の型

証跡やリスクの記録は、監査で「誰がいつ何を登録したか」を問われる性質の情報です。会話から作成・削除できるようになったぶん、次のような運用の型を先に決めておくと安全です。

運用

書き込みと削除を任せる4つの型

  • 対象を文面で特定する

    書き込みの指示には、対象(コントロールコード・リスク名)と内容を必ず書きます。

  • 削除は読み取りを挟む

    「対象の一覧を出して」と読み取りで確認してから、別の指示として削除を頼みます。

  • 作成後に読み直す

    Drataの画面か get・list 系の読み取りで、意図どおり登録されたかをClaudeに確かめさせます。

  • ロールで範囲を狭める

    ロールの弱いアカウントで接続すると、権限の重なりで書き込み範囲が絞られます。

ChatGPTの場合、Drataのヘルプは、書き込み系ツールの利用にDeveloper Mode(ベータ)が必要で、書き込みのたびにリクエスト内容が表示され承認を求められると案内しています。Claude側の確認画面の挙動は、この案内には含まれていません。Claudeでは接続後に出るツール承認の設定を確認してください。

新しいスコープを追加したとき

すでに接続済みで、あとからスコープを足した場合の手順です。Drataは新しいMCPツールを順次公開しており、証跡ツールや従業員・デバイスのツールが後から追加された経緯があります。

手順

スコープを足したあとの流れ

  1. 1

    管理者が設定を編集する

    「MCP OAuth Configuration」で既存の設定を開き、新しいスコープを選んで保存します。

  2. 2

    ユーザーがいったん切断する

    ClaudeのConnector設定でDrataを切断します。

  3. 3

    再接続して承認する

    OAuth認証をやり直し、同意画面で新しいスコープを承認すると、新しいツールが使えるようになります。

新しいスコープは、有効なセッションには自動で反映されません。既存のトークンが古いスコープで発行されているためです。

よくあるつまずき:Callback URL mismatch

接続時に「Callback URL mismatch」のエラーが出る場合、原因はDrataの設定画面ではなく認証基盤のAuth0側にあります。「Settings」→「OAuth Applications」で別途作ったOAuthアプリのクライアントIDとシークレットを、Claudeのコネクタ設定に手入力したときに起きやすいエラーです。

Drata内には似た名前の2つの機能があります。

くらべる

名前が似た2つのOAuth機能

Claudeはこちら

MCP OAuth Configuration

Claude・ChatGPT・Cursor・CopilotなどのAIクライアントをDrataに接続します。

API直結用

OAuth Applications

トークン、クライアントID、クライアントシークレットによる直接のAPIアクセスに使います。

直し方は、コネクタ設定に手入力したクライアントIDとシークレットを消し、地域ごとのMCPサーバーURLだけで構成し直すことです。そのあとサインインをやり直し、求められた権限を承認します。

Drata連携が向く場面

Drataの例文集は、読み取りの依頼が大半を占めています。コンプライアンス担当者が日常で当たる次のような問いです。

  • どのコントロールがまだ準備できていないか、どのフレームワークに関係するか
  • 期限切れや更新期限の近い証跡はどれか
  • 対応計画のないリスクは何件あり、誰が担当か
  • 更新や審査の期限が迫っているベンダーはどこか
  • MFAやセキュリティ研修が未完了の従業員は誰か

監査前の点検に使うなら、Drata側の「Pre-Audit Checklist」のような資料と組み合わせ、Claudeには一覧の集計と抜け漏れの洗い出しを任せる使い方が合います。似た用途の連携としては、SOPの実行管理を扱うProcess Streetの連携も参考になります。同じコンプライアンス領域で開発者キーによる接続も選べるものに、Sprintoの連携があります。

まとめ

Drata連携は、Drata公式のMCPサーバーにOAuthで接続し、コンプライアンスのデータを会話で扱う仕組みです。管理者のOAuth設定が先で、その中身のスコープと各ユーザーのロールの重なりが、Claudeにできることの上限を決めます。

読み取りスコープだけで始め、必要になった業務に絞って書き込みスコープを足す進め方なら、証跡やリスクの記録を意図せず変えるリスクを抑えられます。スコープを足したあとは、ユーザー側の再接続が要ることも忘れやすい点です。

参照した一次ソース

この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。

  1. claude.com/marketplace/connectors/drata
  2. help.drata.com/en/articles/13379899-drata-mcp-setup-usage-guide
この記事を共有:XはてブLinkedIn