「Claude を Slack や Notion、社内のデータベースにつなぎたいと現場から言われた。許可してよいのか、何を決めておくべきか」。この記事は、その問いに Anthropic の公式ドキュメントと MCP（Model Context Protocol）の仕様だけで答えるための整理です。
対象は、Claude を Team または Enterprise プランで使う組織の情報システム・セキュリティ・DX の担当者です。コネクタを自分で実装する開発者向けの手順はClaude API・MCP 実装ハンドブックに、Claude Code 全体の配布・権限・費用の設計はClaude Code の法人導入ガイドにまとめてあります。
読み終えると、「誰が追加できるか」「認証をどう配るか」「ツール単位で何を許すか」「Claude Code 側をどう縛るか」「データはどこへ流れるか」「記録と事前ブロックをどう組むか」の6点について、自社の方針を決められる状態になります。
結論 — 先に要点だけ
- コネクタの追加権限は Owner に集約されています。Team・Enterprise では、組織全体でコネクタを有効にできるのは Owner と Primary Owner だけで、メンバーはその後に個別に接続します。Enterprise はカスタムロールでロールごとに絞れます
- 認証の配り方は2択です。メンバーが各自 OAuth でサインインする「個別」と、管理者が ID プロバイダー経由で配る「Enterprise-managed authorization」です。後者は 2026年9月時点で Okta に対応し、Team・Enterprise で一般提供されています
- ツール単位の承認は3段階で決められます。Enterprise のカスタムロールでは「常に許可」「承認が必要」「ブロック」をコネクタごと、さらにツールごとに設定できます。Cowork の書き込み系ツールは既定で毎回承認です
- Claude Code 側は管理設定で許可リスト・拒否リストを強制できます。
allowedMcpServers・deniedMcpServersと、claude.ai コネクタを丸ごと止めるallowAllClaudeAiMcps・disableClaudeAiConnectorsがあり、ロール権限とは「より厳しい側」で合成されます - 記録は Compliance API、事前ブロックは Inference hooks です。アクティビティフィードは発生から1分以内に照会でき6年間保持されますが、有効化前には遡れません。Inference hooks はプロンプトだけでなくツールの呼び出しと結果も判定対象にできます
※ 出典: Claude Help Center — Set up role-based permissions on Enterprise plans（取得 2026-09）／ Claude Help Center — Authorize MCP connectors for your entire organization（取得 2026-09）／ Claude Docs — Query the Activity Feed（取得 2026-09）
前提 — コネクタと MCP の関係、Claude のどの入口から使われるか
Anthropic のヘルプセンターは、コネクタを「Claude がアプリやサービスにアクセスし、データを取得し、接続先で操作を行うための仕組み」と説明しています。技術的な土台は MCP というオープンな接続規格で、Anthropic が提供するコネクタも、自社で立てるカスタムコネクタも同じ規格で動きます。重要なのは、Claude は接続したユーザー本人の権限を引き継ぐという原則です。元のサービスで見えないファイルや記録は、コネクタ経由でも見えません。
※ 出典: Claude Help Center — Use connectors to extend Claude's capabilities（取得 2026-09）
管理者が最初に押さえるべきなのは、コネクタが使われる「入口」が1つではないことです。同じ MCP サーバーでも、入口ごとに管理の仕組みが違います。
| 入口 | 誰が設定するか | 管理者が使える制御（2026年9月時点） |
|---|---|---|
| claude.ai（Web・デスクトップ・モバイル） | Owner が組織に追加し、メンバーが会話ごとに有効化 | 組織設定でコネクタの有効・無効、Enterprise のカスタムロールでツール単位の許可・承認・ブロック |
| Cowork（デスクトップのエージェント） | claude.ai と同じコネクタを使う | 「書き込み系ツールの常に許可」を認めるかの組織設定。既定はオフ |
| Claude Code（CLI） | 開発者が .mcp.json などで追加。claude.ai のコネクタも取り込める | 管理設定の allowedMcpServers・deniedMcpServers・managedMcpServers、ツール単位の ask／blocked、コネクタの一括無効化 |
| Claude API の MCP connector | 開発者が Messages API のリクエストに mcp_servers を書く | ツールの許可リスト・拒否リストをリクエスト側で指定。ベータ機能で、対応はツール呼び出しのみ |
※ 出典: Claude Help Center — Use Claude Cowork on Team and Enterprise plans（取得 2026-09）／ Claude Code Docs — Connect Claude Code to tools via MCP（取得 2026-09）／ Claude Docs — MCP connector（取得 2026-09）
MCP の規格自体も 2026年7月28日に大きく改訂されました。Anthropic の公式ブログは、この版で MCP が「双方向のステートフルな規格からリクエスト／レスポンス型に移行」し、「認可が本番の OAuth 2.0 と OIDC の運用に揃ったので、MCP サーバーが Entra や Okta のような企業の ID 基盤に回避策なしでつながる」と説明しています。管理者にとっては、社内の ID 基盤でコネクタの認可を握れるようになった、という意味です。
※ 出典: Claude Blog — MCP 2026-07-28 spec: stateless core, coming to Claude（取得 2026-09）／ MCP Specification（2026-07-28）（取得 2026-09）
判断1 — 誰がコネクタを追加できるか
最初に決めるのは「追加できる人」です。Anthropic のヘルプセンターは、Team・Enterprise でメンバーがカスタムコネクタを設定する前に、Owner または Primary Owner が Organization settings の Connectors からコネクタを組織に追加する必要があると説明しています。手順は「Add」→「Custom」→「Web」でリモート MCP サーバーの URL を入れ、必要なら Advanced settings で OAuth の Client ID と Client Secret を指定して「Add」です。メンバーはその後、Customize の Connectors から個別に有効化します。
同じページは、カスタムコネクタが「Anthropic が検証していない任意のサービスに Claude をつなぐ」ものだと警告しています。悪意ある MCP サーバーは「Claude に意図しない操作をさせようとする隠れた指示を含む可能性がある」ため、要求される権限を注意して確認し、有効にしたツール経由で Claude が破壊的な操作をしないか把握するよう求めています。
※ 出典: Claude Help Center — Custom connectors using remote MCP（取得 2026-09）
Enterprise では、さらにロール単位で絞れます。ヘルプセンターによれば、カスタムロールのメンバーは組織で有効なコネクタを自動では引き継がず、「必要な機能はすべて明示的に付与する」必要があります。逆に注意点として、Anthropic が組織に対してコネクタ権限を有効化した時点で、既存のカスタムロールはすべて「All connectors」を「Always allow」で付与された状態から始まると書かれています。ロール設計を後回しにすると、既存ロールが全コネクタを常時許可のまま動きます。
※ 出典: Claude Help Center — Set up role-based permissions on Enterprise plans（取得 2026-09）
プラグインも同じ考え方で管理します。Team・Enterprise の Owner と Primary Owner は、組織のプラグインを「既定でインストール」「インストール可能」「利用不可」「必須」の4区分で配れます。Claude Code に同期されたプラグインは「フック・サブエージェント・MCP サーバーがユーザーの端末上で動く」と明記されているので、プラグインの許可はそのまま MCP サーバーの許可を意味します。
※ 出典: Claude Help Center — Manage plugins for your organization（取得 2026-09）
判断2 — 認証をどう配るか（個別サインインか、ID プロバイダー経由か）
コネクタの認証には2つの方式があります。Enterprise のロール設定画面では「Individually（メンバーが各コネクタに自分のアカウントでサインインする）」と「Managed authorization（メンバーが ID プロバイダー経由で自動的に接続され、自分ではサインインしない）」を選びます。
後者の Enterprise-managed authorization について、ヘルプセンターは「すべての人が各コネクタを個別に認証する代わりに、管理者が組織の ID プロバイダーを通じてコネクタのアクセスを中央で配る」仕組みだと説明しています。Team・Enterprise で一般提供されており、管理者が Organization settings の Connectors から設定します。
| 設定ステップ | 内容 |
|---|---|
| 1. Connect | Organization settings の Connectors で対象コネクタを選び、Configuration タブの Managed authorization で「Set up」。ID プロバイダーとの接続を確認 |
| 2. Roles | どのロールにコネクタを自動配布するかを選ぶ |
| 3. Scopes | ID プロバイダー接続時に Claude が要求する権限（スコープ）を選ぶ |
| 4. Save & turn on | 保存して有効化。メンバーは初回ログイン時に自動で接続される |
2026年9月時点で対応する ID プロバイダーは Okta で、対象コネクタは Asana・Atlassian・Canva・Datadog・Figma・Granola・Linear・Notion・Slack・Supabase の10です。ブラウザでの個別サインインと Managed authorization は同時にオンにでき、その場合 Claude は Managed authorization を先に試し、失敗したら個別サインインを促します。
※ 出典: Claude Help Center — Authorize MCP connectors for your entire organization（取得 2026-09）
この方式の管理上の利点は、退職・異動時の失効です。Anthropic の公式ブログ（2026年6月18日公開・8月24日更新）は「誰かをデプロビジョニングすると、古いトークンに残り続けるのではなく、コネクタのアクセスが速やかに失効する」と説明しています。一方で責任分界も明確です。ヘルプセンターは「ID プロバイダーと各コネクタは第三者が自身の条件で運営しており、Claude は ID プロバイダーが発行した認可を中継するだけで、アクセスの判断・スコープ・各コネクタが到達できるデータは、ID プロバイダーの方針と接続先サービスの権限で決まり、Anthropic は決めない」と書いています。つまり、IdP 側のグループ設計が甘ければ、そのまま Claude の到達範囲になります。
※ 出典: Claude Blog — Centrally manage authorization for MCP connectors（取得 2026-09）
個別サインイン方式でも、トークンの扱いは公開されています。Microsoft 365 コネクタのセキュリティガイドは、OAuth 2.0 の On-Behalf-Of（代理）方式を使い、アクセストークンとリフレッシュトークンは「Claude のバックエンドにキャッシュされる間は暗号化される」と説明しています。リフレッシュトークンは既定で90日間使われないと失効します。
※ 出典: Claude Help Center — Microsoft 365 connector security guide（取得 2026-09）
判断3 — ツール単位で何を許すか（読む・書く・承認）
コネクタは「つなぐか、つながないか」の二択ではありません。1つのコネクタの中に、検索のような読み取り系と、メール送信や課題作成のような書き込み系のツールが混在します。管理者が決めるのは、ツールの種類ごとの扱いです。
| 入口 | 制御の単位 | 選べる状態（公式の表記） | 既定 |
|---|---|---|---|
| Enterprise カスタムロール | コネクタごと、または「Custom」でツールごと | Always allow（全ツール利用可・自動承認可）／ Needs approval（使えるが毎回確認）／ Blocked（ロールのメンバーから隠す） | 既存ロールは All connectors が Always allow |
| Cowork | 書き込み系ツールの「常に許可」を認めるか | 組織設定「Allow 'Always allow' for connector tools」 | オフ（書き込み系は毎タスク承認） |
| Microsoft 365 コネクタ | ツールごと | 読み取り系（SharePoint・Outlook・Teams の検索）は既定で使える。書き込み系（メール送信・予定作成・ファイル送信・Teams 投稿）は管理者が個別に有効化 | 書き込み系はブロック |
| Claude Code（組織管理下） | ツールごと | ask（自動モードでも毎回確認）／ blocked（Claude に見せる前に除外） | — |
| Claude API の MCP connector | ツールごと | MCPToolset で全ツール有効、許可リスト、拒否リストのいずれか | 全ツール有効 |
※ 出典: Claude Help Center — Set up role-based permissions on Enterprise plans（取得 2026-09）／ Claude Help Center — Use Claude Cowork on Team and Enterprise plans（取得 2026-09）／ Claude Help Center — Microsoft 365 connector security guide（取得 2026-09）／ Claude Docs — MCP connector（取得 2026-09）
ここで見落としやすい注意が2つあります。
1つ目は、Cowork の読み取り系の免除は、コネクタ側がツールを「読み取り専用」と注釈している場合だけという点です。ヘルプセンターは「ほとんどのカスタムコネクタはツールに注釈を付けていないので、そのコネクタのすべてのツールが承認対象になる」と明記しています。自社で MCP サーバーを立てるなら、読み取り系ツールに注釈を付けるかどうかが、現場の承認回数を左右します。
2つ目は、ロール権限は加算されるという点です。複数のロールを持つメンバーには最も緩い付与が適用され、ロール間で矛盾があると警告が表示されます。ただしロールの権限は組織のツールポリシーの基準を超えられず、Claude Code の管理設定とは「より厳しい側」で合成されます。
※ 出典: Claude Help Center — Set up role-based permissions on Enterprise plans（取得 2026-09）
判断4 — Claude Code 側の MCP をどう縛るか
開発者が使う Claude Code では、MCP サーバーの追加口が複数あります。公式ドキュメントは、同じサーバーが複数の場所に定義されたとき「ローカル → プロジェクト（.mcp.json）→ ユーザー → プラグイン提供 → claude.ai コネクタ」の優先順位で1つだけ接続すると説明しています。管理者が使うのは、管理設定（managed settings）に置く次のキーです。
| 管理設定のキー | 役割 |
|---|---|
managedMcpServers | 全ユーザーに配る事前設定済みサーバー |
allowedMcpServers | サーバー名の許可リスト |
deniedMcpServers | サーバー名（serverName）または URL パターン（serverUrl）の拒否リスト |
allowAllClaudeAiMcps | claude.ai コネクタの取り込みを許すか（false で止める） |
disableClaudeAiConnectors | claude.ai コネクタを丸ごと無効化 |
配布ホスト側に managed-mcp.json を置くと、そのファイルに書いたサーバーだけを読み込む排他制御になります（公式ドキュメントの「Exclusive control with managed-mcp.json」節）。組織のツール制御で blocked にしたツールは Claude に見せる前に除外され、ask にしたツールは自動モードでも毎回確認が出ます。
※ 出典: Claude Code Docs — Connect Claude Code to tools via MCP（取得 2026-09）
同じページには、管理者が現場に伝えるべき挙動が3つ書かれています。
- プロジェクトの
.mcp.jsonは信頼ダイアログを通らないと読み込まれない。リポジトリをクローンしただけで外部サービスに勝手につながらないための仕組みで、claude mcp listで「Pending approval」と表示されます。ただし非対話モード（claude -p）や Agent SDK、クラウドセッションではこの確認が省かれます - OAuth のスコープは
.mcp.jsonのoauth.scopesで最小に絞れる。公式は「OAuth スコープを必要最小限の権限に制限する」ことを、信頼できないサーバーへの対策として挙げています - 外部コンテンツを取得するサーバーはプロンプトインジェクションの経路になる。公式は「各サーバーを信頼できるか確認してから接続する」「外部コンテンツを取得するサーバーはプロンプトインジェクションのリスクにさらす」と警告しています。管理側の対策は、
allowedMcpServersの許可リスト方式、deniedMcpServersのserverUrlパターン、コミット前の.mcp.jsonレビューの3つに集約されます
※ 出典: Claude Code Docs — Connect Claude Code to tools via MCP（取得 2026-09）
権限・サンドボックス・利用上限も含めた管理設定の配り方は、Claude Code の法人導入ガイドの「判断2」に書いてあります。定期実行で無人運転するときに許す操作の決め方は、Claude Code を決まった時刻に動かすを参照してください。
判断5 — データはどこへ流れ、学習に使われるか
コネクタを許可する前に、データの経路を1本ずつ確認します。公式に書かれている事実は次の4点です。
| 確認項目 | 公式の説明（2026年9月時点） |
|---|---|
| 接続先での処理 | 「接続されたサービスは、自身のインフラで、自身の条件のもとにデータを処理し、その所在地は米国外の場合がある」 |
| カスタムコネクタの到達性 | リモート MCP サーバーは「Anthropic の IP レンジから公開インターネット経由で到達できる」必要がある。VPN 内やファイアウォール内のサーバーは、Anthropic の IP を許可しない限り動かない |
| モデル学習 | 商用製品（Claude for Work・API など）では「既定で入力・出力をモデル学習に使わない」。フィードバックとして送る場合も「コネクタやリモート・ローカル MCP サーバーの生データは含まない」。会話に直接コピーした内容は含まれ得る |
| Enterprise の限定 | 認証済みドメインのコネクタを組織アカウントだけに制限できる |
※ 出典: Claude Help Center — Use connectors to extend Claude's capabilities（取得 2026-09）／ Claude Help Center — Custom connectors using remote MCP（取得 2026-09）／ Anthropic Privacy Center — Is my data used for model training?（取得 2026-09）
社内で「生成 AI にどのデータを入れてよいか」の規程がまだ無い場合は、先に生成 AI の社内利用ガイドラインの作り方で分類を決めてください。コネクタは、その分類を機械的に守らせるための道具です。分類が無いまま接続すると、Claude はユーザー本人の権限で到達できるデータをすべて読みに行けます。
判断6 — 記録と事前ブロックをどう組むか
Enterprise には「後から監査する」仕組みと「事前に止める」仕組みの両方があります。
後から監査する — Compliance API。アクティビティフィードは「認証・チャット・ファイル・プロジェクト・管理・プラットフォームの操作」を組織横断で記録し、発生から1分以内に照会でき、6年間保持されます。記録は遡及しません。Compliance API を組織で有効化した時点から始まり、それ以前の操作は埋め戻されません。Cowork と Claude Code のセッション書き起こしを返すエンドポイントは 2026年8月26日にベータを外れています。
※ 出典: Claude Docs — Query the Activity Feed（取得 2026-09）／ Claude Docs — Release notes（取得 2026-09）
事前に止める — Inference hooks。2026年8月5日にベータ提供が始まった Enterprise 向けの機能で、組織が運用する AI セキュリティサーバーに各プロンプトを送り、allow か deny の判定を待ってから推論に進みます。公式ドキュメントは、セキュリティサーバーが「ユーザーが見るもの、つまり書き起こしのテキスト、ツールの呼び出しとその結果、添付から抽出したテキスト」を受け取ると説明しており、コネクタ経由で取得したデータもここで検査できます。
| 項目 | 公式の説明 |
|---|---|
| 対象 | claude.ai・Cowork・Claude Code・Claude Tag の会話。Bedrock・Vertex AI 経由は対象外 |
| 判定の待ち時間 | 既定 5 秒。超過・エラー時の扱い（ブロックか、検査なしで通すか）は組織が設定 |
| 段階導入 | shadow mode（判定を観察するだけで止めない）、割合指定、ロール単位の除外 |
| 記録 | 拒否はすべてアクティビティフィードに残る |
| できないこと | プロンプトの書き換え・マスキング。画像のみの内容の検査 |
※ 出典: Claude Docs — Inference hooks（取得 2026-09）
公式は、両者の使い分けを「Inference hooks はモデルに届く前に止めるため、Compliance API は後で何が起きたかを監査するため」と整理しています。コネクタの運用では、最初は shadow mode で「どのツールがどのデータを引いているか」を観察し、規程に照らして deny 条件を決める順番が現実的です。
自作 MCP サーバーを社内で立てるときの安全要件（MCP 仕様の要点）
社内システムを MCP サーバーとして公開する場合、Claude 側の設定だけでは足りません。MCP 仕様の「Security and Trust & Safety」は、ホスト（Claude などのアプリ）が「サーバーにユーザーデータを渡す前に明示的な同意を得る」こと、「ツールを呼ぶ前に明示的な同意を得る」ことを求め、ツールの説明や注釈は信頼できるサーバーから得たものでない限り信頼しないと書いています。
※ 出典: MCP Specification（2026-07-28）（取得 2026-09）
仕様に付属する Security Best Practices は、サーバー実装者向けに攻撃と対策を列挙しています。管理者が発注仕様やレビュー項目に落とすべき要点は次のとおりです。
| 攻撃・リスク | 仕様が求める対策（MUST は必須） |
|---|---|
| Token passthrough（他サービス向けのトークンをそのまま受け入れ、下流に転送） | 「MCP サーバーは、自身に対して明示的に発行されたのではないトークンを受け入れてはならない（MUST NOT）」 |
| Confused deputy（プロキシ型サーバーが静的 Client ID を使い、同意画面が飛ばされる） | クライアントごとの同意をサードパーティ認可の前に実施（MUST）。redirect_uri は完全一致で検証、state は単回使用 |
| ローカルサーバーの危険な起動コマンド | クライアントは実行するコマンドを省略せず表示し、明示的な承認を得る（MUST）。サンドボックス実行を推奨 |
| スコープの過大要求 | 最小のスコープから始め、必要時に段階的に昇格。ワイルドカードや「全権」スコープを避ける |
| 状態ハンドルの乗っ取り | ハンドルの所持を認証とみなさない（MUST NOT）。推測不能な値を使い、サーバー側でユーザーに紐づける |
※ 出典: MCP Specification — Security Best Practices（2026-07-28）（取得 2026-09）
Claude API から MCP サーバーを直接呼ぶ場合の制約も押さえておきます。MCP connector はベータ機能で、MCP 仕様のうち対応するのはツール呼び出しだけです。サーバーは HTTP で公開されている必要があり（Streamable HTTP と SSE に対応）、ローカルの stdio サーバーは直接つなげません。
※ 出典: Claude Docs — MCP connector（取得 2026-09）
導入の手順 — 最初の1本から全社まで
- 規程で「入れてよいデータ」を先に決める。分類が無いと、ツール単位の許可・ブロックの判断基準が作れません
- Owner がコネクタを1つだけ組織に追加する。最初は読み取り系だけのコネクタ（検索・参照）を選び、書き込み系は Blocked または Needs approval にします
- 認証方式を決める。Okta を使っている組織で対象コネクタなら Managed authorization、それ以外は個別サインイン。個別の場合は OAuth の同意画面で要求スコープを記録します
- Enterprise ならカスタムロールを先に作る。既存ロールは全コネクタが常時許可の状態から始まるため、パイロットのロールだけに絞ります
- Claude Code の管理設定を配る。
allowedMcpServersを許可リスト方式で書き、外部 URL を止めるならdeniedMcpServersのserverUrlパターンを足し、.mcp.jsonのレビューをコードレビューの項目に入れます - 記録を有効にする。Compliance API は有効化した時点からしか記録されないので、パイロット開始前に有効化します。Inference hooks を使うなら shadow mode から始めます
- 28日ほど運用して見直す。アクティビティフィードから「どのツールが、どのくらい、誰に使われたか」を集計し、承認回数が多すぎるツールと、使われていないコネクタを整理します
※ 出典: Claude Help Center — Set up role-based permissions on Enterprise plans（取得 2026-09）／ Claude Docs — Query the Activity Feed（取得 2026-09）
管理者向けセルフチェックリスト（15項目）
導入の可否を判断する会議の前に、印刷して埋めてください。
- コネクタを組織に追加できる Owner・Primary Owner は誰か、名簿にしてある
- 接続したいコネクタが Anthropic 提供か、カスタム（自社・第三者の MCP サーバー）か区別してある
- カスタムコネクタの運営者・所在地・利用規約を確認した
- 各コネクタのツールを「読み取り系」「書き込み系」に分けて一覧にした
- 書き込み系ツールの扱い（Blocked／Needs approval／Always allow）をロールごとに決めた
- Cowork の「Allow 'Always allow' for connector tools」をオフのままにするか決めた
- 認証方式（個別サインイン／Managed authorization）を決め、要求スコープを記録した
- Managed authorization を使う場合、IdP 側のグループ設計がそのまま到達範囲になることを IdP 管理者と共有した
- Enterprise のカスタムロールで、既存ロールの「All connectors・Always allow」を見直した
- Claude Code の管理設定に
allowedMcpServersを許可リスト方式で書いた（必要ならdeniedMcpServersのserverUrlパターンも） -
.mcp.jsonのレビューをコードレビュー項目に入れ、信頼ダイアログの意味を開発者に説明した - 社内 MCP サーバーの発注・レビュー項目に、トークンの audience 検証とクライアントごとの同意を入れた
- Compliance API をパイロット前に有効化した（遡及記録は無い）
- Inference hooks を使うなら、失敗時の扱い（ブロック／通す）と除外ロールを決めた
- 28日後に、承認回数・未使用コネクタ・拒否件数を見直す会議を予定に入れた
よくある失敗パターン 5つ
| 失敗 | 何が起きるか | 公式ドキュメント上の根拠と対策 |
|---|---|---|
| ロールを作らずに Enterprise のコネクタ権限を有効にする | 既存カスタムロール全員が全コネクタを常時許可で使える | 有効化時点で「All connectors・Always allow」が既定。先にロールを絞る |
| 「読み取り専用のはず」のカスタムコネクタが毎回承認になる | 現場が承認疲れで Always allow を要求する | Cowork の免除はコネクタ側の読み取り専用注釈がある場合だけ。サーバー側で注釈を付ける |
| VPN 内のサーバーをカスタムコネクタに登録する | 接続に失敗する | リモート MCP サーバーは Anthropic の IP レンジから公開インターネット経由で到達できる必要がある |
| 監査が必要になってから Compliance API を有効化する | 過去の操作が取れない | 記録は有効化時点から。遡及なし |
| 社内 MCP サーバーがユーザーのトークンをそのまま下流 API に転送する | 監査が効かず、トークン窃取時の影響が広がる | 仕様は「自身宛てでないトークンの受け入れ」を禁止（MUST NOT） |
※ 出典: Claude Help Center — Set up role-based permissions on Enterprise plans（取得 2026-09）／ Claude Help Center — Custom connectors using remote MCP（取得 2026-09）／ MCP Specification — Security Best Practices（2026-07-28）（取得 2026-09）
公式ドキュメント・リソース集
判断のたびに原文を確認する用の一覧です。いずれも 2026年9月に取得を確認しています。
| 用途 | ページ |
|---|---|
| コネクタの概要・データの扱い | Use connectors to extend Claude's capabilities |
| カスタムコネクタ（リモート MCP）の追加手順と警告 | Custom connectors using remote MCP |
| 一括認可（Enterprise-managed authorization） | Authorize MCP connectors for your entire organization |
| Enterprise のカスタムロールとツール単位の権限 | Set up role-based permissions on Enterprise plans |
| Cowork の書き込み系ツール承認 | Use Claude Cowork on Team and Enterprise plans |
| プラグインの組織管理 | Manage plugins for your organization |
| Claude Code の MCP 管理設定 | Connect Claude Code to tools via MCP |
| API から MCP サーバーを呼ぶ | MCP connector |
| 監査ログ | Query the Activity Feed |
| 事前ブロック | Inference hooks |
| 学習利用の方針 | Is my data used for model training? |
| MCP 仕様と安全要件 | MCP Specification ／ Security Best Practices |
よくある質問
Q. コネクタを追加できるのは誰ですか？
Team・Enterprise では、組織全体でコネクタを有効にできるのは Owner と Primary Owner だけです。カスタムコネクタ（リモート MCP サーバー）も Organization settings の Connectors から Owner が追加し、その後にメンバーが個別に有効化します。Enterprise のカスタムロールでは、ロールごとに使えるコネクタとツールを絞れます。
Q. 社員ごとに OAuth でログインさせる以外の方法はありますか？
あります。Enterprise-managed authorization（管理者による一括認可）を使うと、管理者が ID プロバイダー経由でコネクタを組織に配り、メンバーは初回ログイン時に自動で接続されます。2026年9月時点では ID プロバイダーは Okta から対応し、Asana・Atlassian・Notion・Slack など10のコネクタが対象です。
※ 出典: Claude Help Center — Authorize MCP connectors for your entire organization（取得 2026-09）
Q. コネクタ経由で読んだ社内データは Anthropic の学習に使われますか？
Anthropic のプライバシーセンターは、Claude for Work や API などの商用製品では既定で入力・出力をモデル学習に使わないと明記しています。フィードバックとして送る場合も、コネクタやローカル・リモート MCP サーバーの生データは含まれません。ただし会話に直接コピーした内容は含まれ得ます。
※ 出典: Anthropic Privacy Center — Is my data used for model training?（取得 2026-09）
Q. 書き込み系のツール（メール送信・課題作成など）を勝手に実行されない仕組みはありますか？
あります。Enterprise のカスタムロールでは、コネクタごと・ツールごとに「常に許可」「承認が必要」「ブロック」を選べます。Cowork では書き込み系ツールの「常に許可」を認める組織設定が既定でオフです。Microsoft 365 コネクタも書き込み系ツールは既定でブロックされています。
Q. 誰がどのツールを呼んだかを後から監査できますか？
Enterprise では Compliance API のアクティビティフィードで組織の操作記録を取得でき、記録は発生から1分以内に照会可能で6年間保持されます。有効化した時点から記録が始まり、それ以前は遡れません。事前に止めたい場合は Inference hooks（ベータ）で、プロンプトとツール結果を自社のセキュリティサーバーに判定させる方法があります。
※ 出典: Claude Docs — Query the Activity Feed（取得 2026-09）／ Claude Docs — Inference hooks（取得 2026-09）
次の一歩
この記事のチェックリストを埋めると、「どのコネクタを、誰に、どの認証方式で、どのツールまで許すか」が1枚にまとまります。次にやることは3つです。
- 社内のデータ分類と生成 AI 利用規程を、コネクタのツール単位の許可・ブロックに対応づける
- 最初の1本を読み取り系コネクタに絞り、Compliance API を有効化してからパイロットを始める
- 社内システムを MCP サーバー化するなら、MCP 仕様の安全要件を発注・レビュー項目に落とす
「自社の規程をコネクタの設定に落とし込む順番を相談したい」「社内システムを MCP でつなぐ設計と実装を頼みたい」「Claude Code の管理設定と合わせて全体を見てほしい」という場合は、お問い合わせからご連絡ください。現在の契約プラン・つなぎたいツール・データ分類の有無を書いていただければ、書面で進め方をお返しします。Claude 導入支援の全体像はClaude 導入支援に、契約経路の比較はClaude 法人導入 完全ガイドにまとめています。
更新履歴
- 2026-09-29: 初版公開