これは引き続き、5つの意思決定のうち2番目である「アクセス」です。どの製品サーフェスと機能にグループがアクセスできるかはすでに決定しました。次は、Claudeがどのツールとデータソースにアクセスできるかを決定します。
コネクタとは
コネクタは、Claudeが別のアプリケーション（ドライブ、Wiki、チケットトラッカーなど）にアクセスできるようにするもので、メンバーは貼り付けやアップロードをすることなく、リアルタイムの業務コンテキストを会話に持ち込めるようになります。このリーチこそが価値であると同時にリスクでもあるため、コネクタへのアクセスは3つの独立したゲートで制御されます。これはまた、早期導入を後押しする要因にもなります。ツールを早期に接続したチームは初日からリアルタイムのコンテキストを活用できるため、グループに最初のコネクタを有効化することは、展開において最もレバレッジの高い施策の一つです。
3つのゲート
コネクタとそれを実際に使用するメンバーとの間には3つのゲートがあり、Claudeがコネクタのデータにアクセスできるようにするには、その3つすべてが開いている必要があります。
| ゲート | 制御する内容 | 設定者 | 閉じている場合 |
|---|---|---|---|
| 組織ゲート | コネクタが組織内でそもそも利用可能かどうか | OwnerまたはPrimary Owner | ロールに関係なく、誰もコネクタを見ることができません |
| ロールゲート | グループのロールにコネクタが含まれているかどうか | OwnerまたはPrimary Owner | 一部のグループにはコネクタがありますが、このメンバーのグループにはありません |
| メンバーゲート | このメンバーが自分のアカウントを接続し、Claudeが本人として動作することを許可しているかどうか | メンバー本人 | コネクタは付与されていますが、このメンバーがアカウントを接続するまで使用できません |
各グループのコネクタアクセスは、そのカスタムロールのConnectorsタブで設定されます。すでに存在していたカスタムロールは、すべてのコネクタで「Always allow」に設定されていたため、ロールを絞り込むまでメンバーは従来のアクセス権を保持します。各ロールのConnectorsタブを確認してください。今作成するロールは、すべてのコネクタで「Needs approval」（メンバーが呼び出しごとに確認する）から始まります。
あなたが制御できること
あなたが管理する2つのゲートの中で、3つの制御を行います。
- 組織に追加するコネクタ。
- グループ単位のスコープ設定：どのグループがそれぞれのコネクタを利用できるか。
- コネクタが提供している場合のアクセス深度：読み取り専用か読み書き可能か。製品内では、コネクタの書き込みツールと削除ツールはそれぞれ「Always allow」「Needs approval」「Blocked」のいずれかに設定されており、これらをブロックすることで読み取り専用に保てます。
コネクタにアクセスする際、Claudeは接続先サービスにおけるメンバー本人の権限を引き継ぎます。メンバーが元のシステム内の特定のファイル、チャンネル、レコードにアクセスできない場合、その権限の境界はコネクタを通しても引き継がれます。
Claude Codeのネットワークへのリーチ、つまりプラットフォームリードが管理設定（レッスン6）で設定する許可ドメインは、ネットワークに適用された同じ問いであるため、コネクタの一覧と同じ会話の中で取り上げてください。
Enterprise-managed authorization
デフォルトでは、3つ目のゲートはメンバーに属します。メンバー自身が自分のアカウントを接続するのであり、あなたが代わりに行うことはできません。ほとんどの組織ではこれで問題ありませんが、これはつまり、スコープを設定したグループに対してコネクタが実際に有効になっていることを保証できないということでもあります。
Enterprise-managed authorization（EMA）はこのギャップを埋めます。各メンバーが自分のアカウントを接続する代わりに、組織のIDプロバイダーを通じてアクセスを一元的にプロビジョニングします。コネクタが有効化されると、対象範囲内の全員が初回ログイン時に自動的にそれを取得し、権限は既存のIdPのグループとロールから引き継がれます。オフボーディングはいずれの場合もIdPを通じて行われます。EMAは、プロバイダーがそのサポートを構築しているコネクタでのみ利用可能であるため、リスト内の一部のコネクタは引き続きメンバーゲートを経由します。組織全体でMCPコネクタを承認する（新しいタブで開きます）では、EMAが何を行うか、どのコネクタとIDプロバイダーがそれをサポートしているか、そしてその設定方法について説明しています（MCPはコネクタが構築されているオープンスタンダードです）。
読み取りアクセスと書き込みアクセス
コネクタアクセスには2つのレベルがあり、それぞれリスクの大きさが異なります。読み取りアクセスは2つのうちリスクが低い方で、Claudeがシステムを閲覧できるようにします：ドキュメントの取得、トラッカーの検索、ダッシュボードの閲覧などです。書き込みアクセスは、Claudeがそれを変更できるようにします：チケットの起票、ページの編集、新規エントリの作成などです。Claudeに書き込みアクセスを与えるということは、Claudeがメンバー本人として、接続先アプリケーション内の情報を変更または上書きできるようになることを意味します（Coworkおよび統合Claude体験（新しいタブで開きます）では、コネクタツールの「Always allow」が有効になっていない限り、メンバーは書き込みのたびに確認を求められます）。そのため、書き込みアクセスには異なるレベルの承認を設けるべきです。レッスン2で指名したデータリスクオーナーに書き込み権限の付与を承認してもらい、リスクをその所有者が管理するようにすることを検討してください。
コネクタは、あなたが有効化する変更の中で最も目に見えるものです。Claudeが突然データに直接アクセスできるようになった瞬間、メンバーはそれに気づきます。各コネクタが利用可能になったら必ず告知し、メンバーにとって何が変わり何が変わらないのかを明確にしてください。コネクタは今や利用可能になりましたが、それを有効にするかどうかは各メンバーが選択します。新しいコネクタのリクエストは、レッスン2で指名したアクセスオーナーを通して処理してください。
Plutoのコネクタ
Plutoは、すべてのグループに対してドライブとWikiを読み取り専用で追加し、1日中チケットを起票するワークフローを持つEngineeringには、リスクオーナーの承認を得た上でチケットトラッカーを読み書き可能で追加しました。Payments-eng（レッスン5でEngineeringから除外済み）は読み取り専用のままであり、自分たちの業務範囲外にデータがあるコネクタは、そのグループには一切付与されません — これはPayments & Trustが一貫して取っている、より厳格な姿勢です。
以下のインタラクティブウィジェットでは、単一のコネクタに対するPlutoの3つのゲートを実行できます。任意のゲートを開閉して、誰がそれを制御し、各メンバーがどのような体験をするかを確認してください。
1 · あなたの意思決定
各グループはどのコネクタを取得し、ツールごとにどの深度（読み取り専用か読み書き可能か）で利用できるでしょうか？
2 · 選べる選択肢
コネクタアクセスは、最終的にはリスクに関する判断です。各コネクタについて、どのグループの業務が毎週書き込みアクセスを必要としているかを問いましょう。
| 選択肢 | 選ぶべき場面 | 意味と影響 |
|---|---|---|
| 読み取り専用、その業務がそのシステムに存在するグループに限定 | 以下の状況が当てはまらない限り、ほとんどの組織はここに落ち着きます。 | 読み取りアクセスはすぐに役立ちます：取得と検索だけでも実際の価値を生み出します。これにより、組織がメンバーが実際にそのリーチで何をするかを学ぶ間、Claudeがシステム内で何を変更できるかという問いを避けられます。よくあるパターンは、ワークフローが必要性を示し、リスクオーナーが承認した後に、書き込みが後から追加されるというものです。 |
| 段階的な承認付きの書き込み | グループのワークフローが明らかにClaudeによるシステムへの書き込み（チケットの起票、ページの更新）を必要としており、そのリスクオーナーがそれに納得している場合。 | グループは他の全員と同様に読み取り専用から始まり、必要性が示されリスクオーナーが承認した時点で書き込みを取得します。その後、Claudeはメンバーに代わってそのシステムを変更できるようになり、リスクはそれを受け入れたオーナーが負います。 |
3 · 後で変更する場合
コネクタの設定は自由に元に戻せます。追加したコネクタ、各グループのスコープ設定、読み取り専用か読み書き可能かは、すべて組織設定の中で変更できます。範囲を広げることはメンバーに何のコストもかけません。しかし、範囲を狭めることは慎重に扱うべきです。書き込みアクセスの取り消しやコネクタの削除は、メンバーがそれを基に構築したワークフローを壊してしまいます。アクセスの変更を行う際は、メンバーがそれを認識できるよう必ず告知することがベストプラクティスです。
リソースを設定する
判断が決まったら、組織のコネクタを設定しましょう。追加するコネクタと各グループのコネクタスコープは、組織設定内のグループとそのロール割り当てとともに管理されます。EMAを使用する場合は、そこがメンバーゲートを一元的に構築する場所にもなります。
- コネクタを使ってClaudeの機能を拡張する（新しいタブで開きます）：メンバー側から見たコネクタとは何か、何をするものか——あなたがゲートしている対象です。
- リモートMCPを使ったカスタムコネクタの利用を開始する（新しいタブで開きます）：カスタムコネクタがどのように構築・追加されるか——何を承認しているのかを理解するために。
- Enterprise Planでロールベースの権限を設定する（新しいタブで開きます）：カスタムロールが各グループの利用できるコネクタをどのように制御するか。
- 組織全体でMCPコネクタを承認する（新しいタブで開きます）：enterprise-managed authorization——それが何を行うか、どのコネクタとIDプロバイダーがそれをサポートしているか、そしてその設定方法。
- Enterprise-managed authorization（MCPドキュメント）（新しいタブで開きます）：EMAの背後にある標準規格。
- サンドボックス化されたBashツールを設定する（新しいタブで開きます）：Claude Codeのネットワークへのリーチ——サンドボックスの管理設定内の許可ドメインで、プラットフォームリードが管理します。
レッスンアクティビティ
コンパニオン内のコネクタ表に記入してください：コネクタ、誰が取得するか、深度（読み取り専用か読み書き可能か）。
リスクオーナーに持参すべきもの： 書き込みアクセスを持つすべての行——それを必要とするワークフロー、それを担うグループ、そして上記セクションの読み取りと書き込みのリスクの枠組み。
→ これをワークアロングコンパニオンのレッスン7セクションに記録してください。
ダウンロード
次のステップ
次のモジュール「ガバナンス」では視点を内側に向け、メンバーがClaude自体をどれだけ自由にカスタマイズできるかを扱います：メンバーが構築するSkills、それらのSkillsがどのように共有されるか、そして全員のためにClaudeを形作る組織の指示、さらにこの3つすべてをカバーするガバナンスの姿勢です。