業務SaaS連携は読み取り専用アクセスから始める理由

業務SaaSをClaudeに接続するときは、最初から書き込み・削除まで許可せず、読み取り専用アクセスから始めるのが安全な順序です。理由は単純で、接続した瞬間に付与した権限は、Connectorの開発元やラベルにかかわらずそのまま有効になるからです。承認は後から絞るより、最初から狭めて必要な分だけ広げるほうが事故が起きにくくなります。この順序は、個人利用でも組織導入でも共通して当てはまります。

読み取り専用から始めるとどう変わるか

読み取り専用で始めると、Claudeは検索・要約・閲覧はできても、メッセージ送信やファイルの作成・変更・削除はできません。業務でよくあるのは「メールを検索・要約させたいが、勝手に送信されては困る」「GoogleDriveのファイルは読んでほしいが、ドキュメントの作成・編集は防ぎたい」というケースです。読み取り専用はこの境界をそのまま実現します。

書き込みが必要になった時点で、対象のツールだけを個別に開放すれば済みます。最初から全権限を許可してしまうと、後から絞る作業のほうがはるかに手間がかかります。承認済みの操作を取り消すより、未承認の操作を後から足すほうが運用として軽いというのが基本の考え方です。

Connectorsのアクション制限は読み取り専用をどう実現するか

TeamプランとEnterpriseプランでは、Ownerが組織設定からConnectorごとに「読み取り専用ツール」と「書き込み/削除ツール」を分けて権限を設定できます。それぞれのカテゴリ、あるいは個別のツールに対して「常に許可」「承認が必要」「ブロック」のいずれかを選ぶ仕組みです。組織全体に一律で適用され、個々のメンバーが自分の判断で緩めることはできません。

重要なのは、この制限がソースシステム側の権限と連携して働く点です。Claude側で書き込みを許可していても、接続先のアカウントに書き込み権限がなければ実行できません。逆にClaude側で制限をかけても、ソースシステムが許可する以上のアクセスが新たに生まれることはなく、制限は常にアクセスを狭める方向にしか働きません。

個人利用のFree・Pro・Maxではどう絞るか

組織単位のアクション制限はTeam・Enterprise管理者向けの機能ですが、個人利用でも自衛策はあります。「カスタマイズ」からConnectorを選び、個別のツール権限を「ブロック」に変更すれば、自分が使う範囲では書き込み系のツールを止められます。ただしこれはアカウント個人の設定にとどまり、組織全体への強制力は持ちません。Connectorsの基本的な仕組みはClaude Connectorsとはにまとまっているので、まだ設定画面の場所が分からない場合はそちらを先に確認してください。

カスタムConnectorを追加するときに増える論点

ディレクトリに無いSaaSをMCPサーバー経由で自作・コミュニティ利用する場合は「カスタムConnector」として追加します。Team・Enterpriseプランでは組織設定からOwnerがサーバーURLを登録し、メンバー側は個別に認証する流れです。Free・Pro・Maxプランでは、利用者本人が「カスタマイズ」から直接URLを追加できます。無料プランはカスタムConnectorを1つまでに制限されています。

カスタムConnectorを追加する画面には「未検証のサービスへの接続を許可することになる」という警告が明示されます。ディレクトリ経由のConnectorと違い、Anthropicによるスクリーニングを経ていないため、読み取り専用から始める判断がより重要になります。信頼できる開発元のサーバーだけを追加し、承認済みのツールでも挙動が変わっていないかを定期的に見直す運用が推奨されています。MCP接続そのものの安全設計はMCPセキュリティガイドで詳しく扱っています。

Verified・Communityラベルは読み取り専用の判断にどう関わるか

ConnectorsディレクトリにはVerified(Anthropicが品質と互換性をテスト済み)とCommunity(スクリーニングのみで詳細レビューはしていない)の2種類のラベルがあります。ここで見落としやすいのが、このラベルは接続後の権限の広さとは無関係という点です。Verifiedは品質と互換性の検証であって、セキュリティ監査ではありません。Community Connectorも、接続を許可すれば付与した権限と同じだけの能力をそのまま持ちます。

つまりラベルは「信頼できる開発元かどうかの目安」であって、「安全に書き込みを許可してよいかどうかの判断材料」にはなりません。読み取り専用から始めるべき理由は、ラベルの信頼性とは別の軸で、権限そのものを自分たちで管理する必要があるからです。開発元がツールの中身を変える権限を持っている以上、ラベルだけを根拠に判断を止めるのは避けたいところです。

「承認が必要」を選んだときの運用

「承認が必要」に設定したツールは、Claudeがそのツールを使おうとするたびに確認が挟まります。ここで気をつけたいのは、確認プロンプトを反射的に承認しないことです。承認リクエストには、どのツールを何のために使おうとしているかが表示されるので、想定している業務の範囲に収まっているかをそのつど見るのが本来の使い方です。

「常に許可」は、頻繁に使う定型作業を毎回止めたくないときの選択肢ですが、対象は信頼できる開発元のConnectorに限定するのが安全です。とくにカスタムConnectorや接続実績の浅いCommunity Connectorに対して安易に「常に許可」を選ぶと、読み取り専用から始めた意味が薄れます。承認済みのツールでも、開発元が後から挙動を変える可能性はゼロではないため、定期的に権限一覧を見直す運用と組み合わせるのが望ましい形です。

よくある落とし穴

• Verifiedだから安心と考え、初回設定で書き込み系ツールまで「常に許可」にしてしまう。ラベルは品質と互換性のレビュー結果であって、権限の広さを保証するものではない。
• 「承認が必要」を運用の手間だと感じて「常に許可」に変えてしまい、確認なしで書き込みが通るようになる。導入直後は摩擦があっても、業務で本当に頻度が高いツールだけを個別に「常に許可」へ動かすほうが事故が起きにくい。
• ソースシステム側のアカウント自体が管理者権限を持っている場合、Claude側の制限を後で緩めた瞬間に想定より広い範囲が一気に使えるようになる可能性がある。権限を緩める前に、接続しているアカウントがソースシステム側でどこまでの権限を持つかを確認しておく。
• カスタムConnectorの開発元がツールの内容を変更しても気づかず、読み取り専用のつもりで許可した接続が書き込み系のツールを含むようになっている。定期的に権限一覧を開き直して差分を確認する習慣が要る。
• 個人アカウントでの「ブロック」設定を、組織全体に効くアクション制限と混同する。自分の画面で止まっているように見えても、他のメンバーには別の設定が適用されている場合がある。

よくある質問

読み取り専用にすると要約や検索もできなくなりますか

いいえ。検索・閲覧・要約は読み取り専用ツールの範囲に含まれます。制限がかかるのはメッセージ送信やファイルの作成・編集・削除といった書き込み/削除系の操作です。日常的な調べ物や情報収集の用途は、読み取り専用のままでもほぼ支障なくカバーできます。

アクション制限は個々のメンバーが上書きできますか

できません。Team・Enterpriseのアクション制限はOwnerが設定する組織全体のルールで、Connectorを使う全員に一律で適用されます。個人のカスタマイズ設定より、組織のアクション制限のほうが優先される構造です。

データベース接続の場合も同じ考え方ですか

はい。むしろデータベースは書き込みの影響が大きいため、読み取り専用ロールでの接続がより強く推奨されます。具体的な接続設計はMCPからデータベースに接続する方法にまとまっています。

「承認が必要」にすると、Claudeの応答が遅くなりますか

応答自体が遅くなるわけではなく、書き込み系のツールを使う場面でだけ確認のやり取りが1回挟まります。読み取りだけで完結する作業では影響がないため、体感の速度はほとんど変わりません。書き込みが頻発する業務であれば、そのツールだけを個別に「常に許可」へ切り替える判断も選択肢に入ります。

まとめ

業務SaaS連携で最初にやるべきことは、読み取り専用ツールだけを許可し、書き込み・削除は「承認が必要」かブロックにしておくことです。Verified・Communityのラベルは開発元への信頼の目安であって、権限の広さとは無関係だと理解しておくと、承認画面での判断がぶれません。組織全体を絞るならTeam・EnterpriseのOwnerによるアクション制限、個人の範囲で絞るならConnectors設定からのツールブロックを使い分けます。カスタムConnectorを追加するときは、この判断がとくに重要になります。まずは今つながっているConnectorの権限一覧を開き、書き込み系が「常に許可」になっていないかを確認するところから始めてください。