SaaS Claude連携が禁止・制限されるケースの見分け方
業務SaaSをMCPでClaudeに繋ぐ前に、その経路を提供元が許可しているかどうかを確認する具体的な見分け方をSansanの実例で解説します。
MCP経由で業務SaaSとClaudeを連携させようとしたとき、「機能として繋げるか」は調べても「その繋ぎ方が規約上許されているか」まで確認する人は多くありません。Sansanは2025年12月、顧客向けに公開しているAPIについて「社外のMCPサーバーからの利用を前提として設計していない」と明言し、無断でのMCP実装を控えるよう技術ブログで呼びかけました。連携前に確認したいのは、接続経路を誰が用意しているかという一点です。
確認すべきは「MCPで使えるか」ではなく「誰が許可した経路か」
業務SaaSとClaudeの連携を検討するとき、最初に見るべきは機能の有無ではなく、その接続経路をSaaS提供企業自身が用意しているかどうかです。MCP(Model Context Protocol)とは、生成AIが外部のツールやAPIを呼び出すための共通規格で、SaaS側が自社で配布するMCPサーバーもあれば、個人開発者が公開APIを勝手にラップしたものもあります。同じ「MCP対応」という言葉でも、提供元が保証している経路かどうかで安全性はまったく違います。
連携方法はおおむね3パターンに分かれます。
- SaaS企業自身がMCPサーバーを配布している(freee、kintone、Backlog、Garoon、kickflow、Chatworkなど。クラウドサインやkickflowなど契約書まわりのSaaSとの接続方法はClaude法務連携ガイドにまとめています)
- 自社製のMCPサーバーは無いが、SaaS企業が公開しているREST APIを個人やサードパーティがMCP化している
- 公開されているAPIそのものが契約顧客向けの限定提供で、外部ツールからの機械的なアクセスを想定していない
3番目のパターンが、規約上の制限に触れやすい領域です。
パターン1にあたるかどうかを最初に確認する場所は、Claude Code公式ドキュメントが案内する「Anthropicのディレクトリ」です。ディレクトリに掲載されているリモートMCPサーバーは、Claude Codeのclaude mcp addと同じ基盤を使うレビュー済みの接続先として案内されています。逆に言えば、ディレクトリに載っていないサーバーは、運営企業自身が関わっているか個人開発かを自分で見分ける必要があるということです。
Sansanの事例が示す「公開されているAPI」と「誰でも自由に使えるAPI」の違い
Sansanは自社のMCPサーバーを開発した技術ブログの中で、次のように注意を添えています。
当社からの許可があるまでSansan APIを利用したMCPサーバーの実装や利用はご遠慮ください
理由として挙げられているのは、Sansan APIが契約顧客向けに公開されているサービスであるものの、社外のMCPサーバーからの利用を前提として設計されていないという点です。APIそのものは稼働していても、外部ツール経由の機械的なアクセスパターンを運用側で制御できていない、というのが実態に近い説明でしょう。
これはClaudeに限った制限ではありません。SansanのブログはMicrosoft CopilotやChatGPTと並べてClaudeをMCPホストの例に挙げており、AIエージェントの種類を問わず「公開APIを外部のMCPサーバー化してよいか」という論点そのものが対象です。「顧客向けに公開されている」と「外部の自動化ツールから自由に呼んでよい」は別の話だと分かる実例です。
なぜこの手の制限が出てくるかは、SaaS側の立場で考えると分かりやすくなります。公開APIは人間がブラウザで操作する頻度を前提にレート制限や監視を設計していることが多く、AIエージェントが自動生成する大量のリクエストは想定外の負荷になりえます。加えて、取得したデータを外部のMCPサーバー経由で別のAIベンダーに渡す経路は、契約書に定めた第三者提供の範囲を超えてしまう可能性もあります。技術的にAPIが動くことと、その使い方が契約上カバーされていることは、常に一致するとは限りません。
同じ記事の中でSansanは、Sansan MCPサーバー自体はPoC(概念実証)として社内で開発を進め、その後トライアルという形で実際の顧客に提供を始めたと説明しています。つまりSansanが選んだ答えは「外部の第三者製MCPサーバーを黙認する」ではなく「自社でMCPサーバーを作って提供する」でした。読者にとっての実務的な含意は、対象SaaSがまだ自社製のMCPサーバーを持っていなくても、しばらく待てば本家のルートが用意される可能性があるという点です。急いで第三者製のラップを組む前に、開発者向けページやリリースノートで自社製MCPサーバーの提供予定を確認する価値はあります。
第三者製パッケージかどうかをnpmのメンテナー情報で見分ける
MCPサーバーが企業自身によるものか個人開発かは、パッケージのREADMEだけでは判断しにくいことがあります。確実なのは、npmレジストリのメンテナー情報を直接見ることです。
curl -s https://registry.npmjs.org/<パッケージ名> | grep -A3 maintainers企業自身が配布するパッケージは、メンテナーのメールアドレスが企業ドメイン(@freee.co.jpや@chatwork.comなど)になっており、GitHubのリポジトリも企業のOrganizationアカウント配下にあります。個人開発のパッケージは、メールアドレスが個人ドメイン(Gmailなど)で、リポジトリも個人アカウント配下です。この2点が一致していれば、企業が関与を認めていると判断してよい材料になります。逆に一致していない場合は、技術的な完成度が高くても「企業自身が作った」と誤読しないよう注意します。
MCPサーバーが無いSaaSに接続する前に確認する3点
自社製のMCPサーバーが見当たらないSaaSを連携させたい場合、次の3点を確認すると判断しやすくなります。
| 確認項目 | 見るべき場所 | 見つからないときの対応 |
|---|---|---|
| 外部ツール・自動化からのAPI利用可否 | 見るべき場所利用規約とは別文書のAPI利用規約 | 見つからないときの対応用途を明記してサポート窓口に問い合わせる |
| 取得したデータをMCPサーバーとして配布・転載してよいか | 見るべき場所開発者ポータルの禁止事項の節 | 見つからないときの対応社内利用に留め、社外への配布はしない |
| データを外部のAIベンダーへ送信してよいか | 見るべき場所プライバシーポリシー・データ処理条項 | 見つからないときの対応送信先(Anthropicなど)を明示したうえで確認する |
いずれも「規約に明記されていない」場合が実務では多く発生します。そのときは黙って進めるのではなく、サポート窓口に用途を伝えて確認を取るのが最も確実です。
個人が作ったMCPサーバーをどう扱うか
会計クラウドのマネーフォワードには、企業自身が配布するMCPサーバーが存在しません。GitHubの企業アカウントにもMCP関連のリポジトリは無く、npmレジストリにも自社製パッケージの登録は見当たりませんでした。代わりに検索で見つかるのは、個人開発者が公開しているパッケージです。前節の方法でメンテナー情報を確認すると、公開元は個人のメールアドレスで、マネーフォワード社の関与を示す記載はありませんでした。
このこと自体が「規約違反」を意味するわけではありません。ただし、対象SaaSの開発者向け規約に「第三者による自動化ツールの作成」を制限する条項が無いかどうかは、パッケージの完成度とは別に確認する事項です。freeeとマネーフォワードのMCP対応状況を実際に比較すると、対応の違いがどう業務フローに影響するかが具体的に見えてきます。マネーフォワードを含む会計SaaS全般でConnector・MCP・API直叩きの接続方式がどう違うかは、経理部門がClaudeで使えるSaaS連携まとめで横断的に比較しています。
連携する「面」によって確認の入り口が変わる
同じSaaSでも、Claude.ai・Claude Desktop・Claude Codeでは連携の入り口が異なります。Claude.aiやDesktopではカスタムコネクタからURLを登録するだけで済むSaaSがある一方、Claude Codeではコマンドでサーバーを追加します。
claude mcp add --transport http <サーバー名> <MCPサーバーのURL>面が違えば、規約上の想定利用者(個人利用か組織利用か)も変わることがあります。組織で導入する場合は、個人アカウントでの動作確認だけで判断せず、管理者向けの案内も併せて確認しておくと手戻りが少なくなります。
よくある質問
企業が配布するMCPサーバーなら規約を確認しなくていい?
企業自身による配布は提供元が許可した経路なので、個人が作ったAPIラップよりリスクは下がります。ただし、誰のアカウントで動かすか、書き込み権限まで与えるかといった運用面の判断は、配布元を問わず利用側で行う必要があります。
個人開発のMCPサーバーは一律に使ってはいけない?
一律の禁止ルールがあるわけではありません。対象SaaSの規約が外部ツールからのアクセスを制限していないか、開発元が注意喚起を出していないかを確認したうえで判断する事項です。
MCPではなくREST APIを直接呼び出す場合も同じ確認が必要?
同じです。Sansanのケースも技術形式はREST APIで、論点はMCPという規格そのものではなく「外部からの機械的なアクセス」をどこまで許可するかでした。
自社製のMCPサーバーがまだ無いSaaSは諦めるしかない?
そうとは限りません。Sansanのように、自社製のMCPサーバーをPoCやトライアルという形で段階的に整備しているSaaSもあります。開発者向けページやリリースノートを定期的に確認し、本家のルートが用意されたタイミングでそちらに乗り換える方が、第三者製のラップを自作して運用し続けるより長期的な手間は小さくなります。
まとめ
業務SaaSとClaudeをMCPで連携する前に確認すべきは、機能として使えるかではなく、その経路を提供元が許可しているかです。自社製のMCPサーバーが用意されていれば最も確実で、無い場合は利用規約とAPI提供範囲を個別に確認します。Sansanの事例は、契約顧客向けに公開されたAPIが、必ずしも外部の自動化ツールに開放されているとは限らないことを具体的に示しました。どのSaaSが自社製のMCPサーバーを持っているかは国産SaaS MCP対応一覧でまとめて確認できます。