業務SaaS連携は読み取り専用アクセスから始める理由
業務SaaSをClaudeに繋ぐときは、まず読み取り専用に絞るのが安全です。アクション制限の仕組みと、ラベルが権限の保証にならない理由を一つずつ見ていきます。
業務SaaSをClaudeに接続するときは、最初から書き込み・削除まで許可せず、読み取り専用アクセスから始めるのが安全な順序です。接続した時点で付与した権限は、コネクタの開発元やラベルにかかわらず、そのまま有効になるからです。後から絞るより、狭く始めて必要な分だけ広げるほうが事故は起きにくくなります。個人利用でも組織導入でも同じです。
読み取り専用から始めるとどう変わるか
読み取り専用で始めると、Claudeは検索・要約・閲覧はできても、メッセージの送信やファイルの作成・変更・削除はできません。業務でよくある例は2つあります。
- メールは検索して要約させたいが、勝手に送信されては困る
- GoogleDriveのファイルは読ませたいが、新しいファイルを作られたくない
書き込みが必要になった時点で、必要なツールだけを個別に開放すれば済みます。
そもそも書き込めるコネクタかどうかを先に見る
絞る前に、そのコネクタが何をできるのかを見ます。連携先によっては、書き込みの能力がそもそも小さいことがあります。
Google系コネクタの書き込み能力
Gmail
Claude Docsのページでは、読み取り専用のコネクタと説明されています。一方、ヘルプセンターでは送信・返信・転送ができ、既定では実行前に承認を求めるとされています。
Googleカレンダー
Claude Docsのページでは、予定の作成・変更・削除はできないと説明されています。一方、ヘルプセンターでは、予定の作成・更新・削除ができるとされています。
GoogleDrive
検索と読み取りに加えて、新しいファイルの作成までできます。
先ほどの「送信されては困る」は、Claude Docsの説明どおりならGmailコネクタで満たされます。ただしヘルプとは食い違うため、Gmailでも書き込み系ツールの「ツール権限」を確認します。詳細はこちらの記事にあります。Driveでは、作成まで絞る効果が大きくなります。ディレクトリの各コネクタのページには、読み取りと書き込みの能力が載っています。Slack(メッセージ送信)やLinear(課題の作成)のように、書き込みが主用途のコネクタも少なくありません。
ツールの権限は3段階で決める
コネクタの詳細ページには「ツール権限」があり、ツールが種類別にまとまっています。たとえば読み取り専用ツールと、書き込み・削除ツールです。グループ単位でも、個別のツール単位でも、次の3つから選べます。
| 設定 | 動作 |
|---|---|
| 常に許可 | 動作確認なしで実行 |
| 承認が必要 | 動作実行前にユーザーへ確認 |
| ブロック | 動作実行不可 |
読み取り専用に絞る流れ
- 1
コネクタを開く
「カスタマイズ」から「Connectors」を開き、絞りたいコネクタを選びます。
- 2
ツール権限を見る
詳細ページの「ツール権限」に、読み取り専用ツールと書き込み/削除ツールのグループが並びます。
- 3
書き込み系を変える
書き込み/削除のグループを「承認が必要」か「ブロック」にします。必要なツールだけ個別に戻せます。
組織で絞るか、自分のアカウントで絞るか
同じ「ツール権限」でも、誰が設定するかで効く範囲が変わります。
アクション制限の効く範囲
Team・EnterpriseのOwner
組織全体に一律で効き、メンバーは上書きできません。「読み取りは許可し、書き戻しは止める」という線引きを全員に揃えられます。
自分のアカウントの本人
自分のアカウントのツールを「ブロック」にできます。効くのは自分の利用だけで、他のメンバーの設定には触れません。
個人の「ブロック」を組織のアクション制限と取り違えると、自分の画面では止まっているのに他のメンバーには別の設定が適用されている、というずれが起きます。コネクタの基本的な仕組みはClaude Connectorsとはにあるので、設定画面の場所が分からないときは先にそちらを見てください。
権限の天井はClaude側ではなく接続先にある
アクション制限はソースシステムの権限と並んで働きます。Claude側で書き込みを許可していても、接続先のアカウントに書き込み権限がなければ実行できません。逆に、Claude側で制限をかけても接続先が許す以上のアクセスは生まれません。制限は常に狭める方向にだけ効きます。
ここで条件が1つあります。ディレクトリのコネクタは、本人のサインインを通して本人の権限を引き継ぎます。ファイル・チャンネル・レコードを本人が開けないなら、コネクタからも届きません。ところがカスタムコネクタで共有の資格情報(APIキーなど)を使うと、その資格情報が届く範囲すべてに触れてしまいます。リクエストヘッダー認証の説明にも、全員が1つの資格情報を共有する内部ツールやサービスアカウント向けだと書かれています。この認証方式はベータで、一部の組織だけが使えます。
共有資格情報のカスタムコネクタでは、本人の権限で自然に絞られることを当てにできません。Claude側のツール権限に加えて、接続先で権限を絞った資格情報を用意する構成が選択肢になります。認証に「サインインなし」を選ぶと、サーバーURLを知っている人なら誰でも使えます。
ツールアクセスの3モードは権限の設定ではない
ヘルプには「ツールアクセス」という設定もあります。チャットの「+」メニューの「コネクタ」から、会話ごとに次の3つを選びます。
- Auto(既定): 作業内容に応じてClaudeが読み込むコネクタを決める
- 常に利用可能: すべてのコネクタを会話の最初に読み込む
- オンデマンド: Claudeが必要なコネクタを探して、見つけたものだけ読み込む
これは会話の容量をどう使うかの設定で、コネクタごとの読み取り・書き込みの許可とは別の話です。ヘルプでは、コネクタが10個以上あるときや会話が長さの上限にかかるときに、オンデマンドを選ぶ目安が示されています。書き込みを止める設定ではありません。止めたいときは、前の節のツール権限を使います。
会話ごとの切り替えには、もう1つ手段があります。「+」メニューの「コネクタ」でトグルをオフにすると、その会話ではコネクタが使われません。接続自体は残るので、次の会話で入れ直す必要はありません。サインアウトまで含めて外したいときは、切断します。
Team・Enterpriseでは有効化と認証が別々に進む
Team・Enterpriseでは、使い始めるまでに2段階あります。まずOwnerかPrimary Ownerがコネクタを組織で有効にします。有効にしただけでは誰にもアクセスは付きません。Teamプランでは、有効化の権限がないメンバーに未有効のコネクタの「Request」ボタンが表示され、Ownerに依頼が届きます。次に、メンバーが接続先に自分で認証します。共有資格情報のコネクタだけは、この個別認証が要りません。
Enterpriseには、組織全体で1回だけ認可するEnterprise-managed authもあります(ベータ)。メンバーは初回ログインで、そのままアクセスを引き継ぎます。Ownerは、自社の認証済みドメインのサービスを、組織外のClaudeアカウントに接続させない設定もできます。
組織で使うコネクタには、取り扱いの制約もあります。コネクタが使えるのは非公開のプロジェクトだけで、同期した内容を含むチャットは共有できません。
カスタムコネクタを追加するときに増える論点
ディレクトリに無いSaaSをMCPサーバー経由で使う場合は、カスタムコネクタとして追加します。Team・Enterpriseでは、Ownerが組織設定からサーバーURLを登録し、メンバーは自分のアカウントで認証します。Enterpriseでは、組織のライブラリを管理できるカスタムロールを持つメンバーも追加できます。
Free・Pro・Maxでは、本人が「カスタマイズ」から直接URLを追加できます。無料プランのカスタムコネクタは1つまでです。
カスタムコネクタのページには、未検証のサービスへの接続を許すことになるという警告があります。ディレクトリ経由と違い、Anthropicは中身を見ていません。ここで押さえたい挙動が2つあります。
- 追加後は、OAuthの資格情報もリクエストヘッダーも変更できません。変えるには、削除してから追加し直し、メンバーも再接続します
- 開発元はツールをいつでも変えられます。承認済みのツールでも挙動が変わっていないか、定期的に見直します
MCP接続そのものの安全設計はMCPセキュリティガイドで詳しく扱っています。
Verified・Communityラベルは権限の広さを示さない
ConnectorsディレクトリのラベルはVerified、Community、Customの3種類です。Verifiedは、Anthropicがツールを品質と互換性の面でテストし、Software Directory Policyの要件を満たしていた状態を指します。Communityは、第三者の開発者が作ったコネクタで、Anthropicはスクリーニングだけを行い、詳細なレビューはしていません。Customは、自分で追加したもので、Anthropicのレビューはありません。
見落としやすいのが、ラベルは接続後の権限の広さとは無関係という点です。公式には、ラベルはディレクトリでの表示と見つけやすさに影響するだけだと書かれています。接続した後は、Communityコネクタも、付与した権限と同じだけの能力を持ちます。Verifiedは、セキュリティ監査でも性能の保証でもありません。開発元がコネクタを運用し、ツールの中身も握っているので、審査の後で変わりえます。
つまりラベルは「開発元を信頼する目安」であって、「書き込みを許可してよい根拠」にはなりません。権限は、ラベルとは別の軸で自分たちが決めることになります。Communityコネクタを接続しようとすると、詳細にはレビューされていない旨の注意がClaudeから出ます。
「承認が必要」を選んだときの運用
「承認が必要」のツールは、Claudeが使おうとするたびに確認が挟まります。承認の画面には「1回だけ許可」と「常に許可」があります。「常に許可」を選ぶと、そのツールの確認は以後省かれます。あとから「ツール権限」で戻せます。
確認は反射的に通さず、どのツールを何のために使おうとしているかを見るのが本来の使い方です。「常に許可」は、頻繁に使う定型作業を毎回止めたくないときの選択肢になります。公式の注意書きでも、対象は信頼できるサーバーだけとされています。
| 場面 | 向く設定 |
|---|---|
| 読み取りだけで済む日常の調べもの | 向く設定読み取り専用ツールを「常に許可」 |
| 書き込みはたまにしか使わない | 向く設定書き込みツールは「承認が必要」 |
| 使う予定のないツール | 向く設定「ブロック」 |
| 実績の浅いCommunityコネクタ・カスタムコネクタ | 向く設定書き込み系は「承認が必要」か「ブロック」 |
よくある落とし穴
- Verifiedだから安心と考え、初回設定で書き込み系まで「常に許可」にしてしまう。ラベルは品質と互換性の結果で、権限の広さを保証しない
- 「承認が必要」を手間に感じて「常に許可」へ変え、確認なしで書き込みが通る。頻度の高いツールだけを個別に動かすほうが安全
- 接続先のアカウントが管理者権限を持つ状態で、Claude側の制限を緩める。緩める前に、アカウントが接続先で持つ権限を見る
- 開発元がツールを変えたのに気づかず、読み取り専用のつもりの接続が書き込み系を含んでいる。「ツール権限」を開き直して差分を見る
- 共有資格情報のカスタムコネクタを、本人の権限で絞られるディレクトリのコネクタと同じ感覚で扱う
- ツールアクセスの「オンデマンド」を、書き込みを止める設定だと思い込む
データベースに繋ぐ場合
データベースは書き込みの影響が大きいので、接続用のロールを読み取り専用にする設計がまず候補になります。具体的な接続設計はMCPからデータベースに接続する方法にあります。サーバー側で強制する製品と、DB側の権限に頼る製品があり、5製品の設定比較で違いを見られます。
まとめ
書き込み・削除は「承認が必要」かブロックにして、読み取りから始めます。まずは今つながっているコネクタの「ツール権限」を開き、書き込み系が「常に許可」になっていないかを見てください。