Claude Media
SaaSとClaudeの連携が禁止・制限されるケースの見分け方
MCPClaude CodeClaude連携Tips

SaaSとClaudeの連携が禁止・制限されるケースの見分け方

業務SaaSをMCPでClaudeに繋ぐ前に、その経路を提供元が許可しているかどうかを確認する具体的な見分け方をSansanの実例で解説します。

読了目安 約11分

MCP経由で業務SaaSとClaudeを連携させようとしたとき、「機能として繋げるか」は調べても「その繋ぎ方が規約上許されているか」まで確認する人は多くありません。Sansanは2025年12月、顧客向けのAPIについて、記事の公開時点では社外のMCPサーバーから使う前提ではないと明言し、無断でのMCP実装を控えるよう技術ブログで呼びかけました。連携前に確認したいのは、接続経路を誰が用意しているかという一点です。

確認すべきは「MCPで使えるか」ではなく「誰が許可した経路か」

業務SaaSとClaudeの連携を検討するとき、最初に見るべきは機能の有無ではなく、その接続経路をSaaS提供企業自身が用意しているかどうかです。MCP(Model Context Protocol)とは、生成AIが外部のツールやAPIを呼び出すための共通規格で、SaaS側が自社で配布するMCPサーバーもあれば、個人開発者が公開APIをラップしたものもあります。同じ「MCP対応」という言葉でも、提供元が保証している経路かどうかで安全性はまったく違います。提供元が経路を用意していても、Intercomのように意図的にRead専用へ絞る例もあります(ClaudeとIntercomを連携する方法)。

連携方法は、経路の出どころで3パターンに分かれます。

出どころ

接続経路の3パターン

  • 1. 提供元が配布している

    freee、kintone、Backlog、Garoon、kickflow、Chatwork、マネーフォワードなど。契約書まわりのSaaSはClaude法務連携ガイドにまとめています。

  • 2. 第三者がAPIをMCP化している

    提供元の自社製サーバーとは別に、個人やサードパーティが公開REST APIをラップして配布しているものです。

  • 3. APIが契約顧客向けの限定提供

    外部ツールからの機械的なアクセスを想定していないAPIです。規約上の制限に最も触れやすい領域です。

パターン1にあたるかどうかの入り口は、Claude Code公式ドキュメントが案内する「Anthropic Directory」です。ここに載るリモートMCPサーバーは「reviewed connectors」と呼ばれ、Claude Codeのclaude mcp addと同じ基盤で追加できます。ディレクトリに載っていないサーバーは、運営企業が関わっているのか個人開発なのかを自分で見分けます。

Sansanの事例が示す「公開されているAPI」と「誰でも自由に使えるAPI」の違い

Sansanは自社のMCPサーバーを開発した技術ブログの中で、次のように注意を添えています。

当社からの許可があるまでSansan APIを利用したMCPサーバーの実装や利用はご遠慮ください

禁じられているのは「実装」だけではなく「利用」も含みます。理由として、Sansan APIは顧客向けに公開されているサービスでありながら、記事の公開時点では社外のMCPサーバーからの利用を前提として設計されていないためとされています。事情が変われば、許可の範囲も変わりえます。

これはClaudeに限った制限ではありません。SansanのブログはMicrosoft CopilotやChatGPTと並べてClaudeをMCPホストの例に挙げており、AIエージェントの種類を問わず「公開APIを外部のMCPサーバー化してよいか」という論点そのものが対象です。「顧客向けに公開されている」と「外部の自動化ツールから自由に呼んでよい」は別の話だと分かる実例です。

APIが技術的に動くことと、その使い方が契約上カバーされていることは一致しません。たとえば取得したデータを外部のMCPサーバー経由で別のAIベンダーに渡す場合、データの渡し先は契約で定めた範囲に収まっているか、という確認が別に要ります。

同じ記事の中でSansanは、Sansan MCPサーバー自体はPoC(概念実証)として開発をスタートし、その後トライアルという形で実際の顧客に提供したと説明しています。Sansanは第三者製を黙認せず、自社で作って提供する道を選びました。第三者製のラップを組む前に、開発者向けページやリリースノートで提供の動きを見ておく価値があります。

提供元が配布した経路かを、パッケージの出どころで見分ける

MCPサーバーが企業自身によるものか個人開発かは、READMEだけでは判断しにくいことがあります。npmで配布されているサーバーなら、npm viewでレジストリの登録情報を直接引けます。

npm view freee-mcp author repository.url maintainers.length

freee-mcp(v0.36.3)で実行すると、次の情報が返りました。

author = 'freee_jp'
repository.url = 'git+https://github.com/freee/freee-mcp.git'
maintainers.length = 7

repository.urlはfreee自身のOrganization配下を指しています。それでも、maintainersの7アカウントのうちfreeeの企業ドメイン(freee.co.jp)のメールを持つのは1つ(freee_developers)だけです。残りは企業ドメイン以外のメールで、企業が配布するパッケージでもメンテナーが企業ドメインだけとは限りません。

比較として、マネーフォワードのAPIをラップした第三者製パッケージ@jp-mcp/server-moneyforward(v0.1.0)も同じコマンドで引いてみます。

npm view @jp-mcp/server-moneyforward author repository.url
author = 'jp-mcp'
repository.url = 'git+https://github.com/jp-mcp/mcp-server-moneyforward.git'

リポジトリはマネーフォワードのOrganizationではなくjp-mcp配下です。説明文に「MCP Server for Money Forward Cloud APIs」とあっても、提供元が作ったことは読み取れません。READMEには公式ではないOSS版と書かれています。

リモート型のMCPサーバーにはnpmパッケージが無いため、この方法は使えません。

くらべる

配布形態ごとの見分け方

ローカル起動型

npmなどで配布されるサーバー

npm viewでrepository.urlとauthorを引き、提供元のOrganizationを指しているかを見ます。メンテナーのメールドメインは決め手にしません。

リモート型

URLを登録して使うサーバー

接続先URLのホスト名が提供元のドメイン配下か、そのURLが提供元の開発者サイトの接続案内に載っているかを見ます。

規約に当たる3つの確認先と、見つからないときの動き方

自社製のMCPサーバーが見当たらないSaaSを連携させたい場合、次の3点を順に確認します。

確認

規約まわりの確認手順

  1. 1

    外部ツール・自動化からのAPI利用を許しているか

    見る場所は、利用規約とは別に置かれていることがあるAPI利用規約です。

  2. 2

    取得したデータをMCPサーバーとして配布・転載してよいか

    見る場所は、開発者ポータルの禁止事項の節です。判断がつかなければ社内利用に留め、社外には配布しません。

  3. 3

    データを外部のAIベンダーへ送信してよいか

    見る場所は、プライバシーポリシーとデータ処理条項です。送信先(Anthropicなど)を明示したうえで確認します。

どの項目も、規約に明記されていない場合は黙って進めずに、サポート窓口へ用途を伝えて回答をもらうのが最も確実です。

公式の経路があるSaaSで第三者製をどう扱うか

会計クラウドのマネーフォワードは、自社製のリモートMCPサーバーを提供しています。開発者サイトの接続案内には、クラウド会計向けのURLとしてhttps://beta.mcp.developers.biz.moneyforward.com/mcp/ca/v3が載っています。ホスト名がmoneyforward.com配下にあり、開発者サイトの接続案内に載っているので、前節の見分け方でも提供元の経路と判断できます。認証にはOAuthのほかに、アプリポータルで発行するAPIキーも使えます。

注意点も案内ページに書かれています。Claude Desktopについて「認可は完了しても接続できない事象が報告されている」とあり、詳細は提供元のトラブルシューティングへの案内です。提供元が経路を用意していても、使い方によっては接続に手間がかかる例です。

先ほど確認した@jp-mcp/server-moneyforwardは、同じ会社のAPIを使いつつ出どころが別の経路です。公式の経路が既にあるSaaSでは、第三者製を選ぶ前に、両者の出どころの違いを踏まえておきます。

個人開発のパッケージが規約違反になると決まっているわけではありません。対象SaaSの開発者向け規約に「第三者による自動化ツールの作成」を制限する条項が無いかは、パッケージの完成度とは別に確認する事項です。freeeとマネーフォワードのMCP対応状況を実際に比較すると、2社の経路の違いが業務フローにどう効くかが見えます。マネーフォワードの接続手順はClaudeマネーフォワード連携にあります。会計SaaS全般でConnector・MCP・API直叩きの接続方式がどう違うかは、経理部門がClaudeで使えるSaaS連携まとめで比較しています。

Claude.ai・Desktop・Codeと組織の設定で確認の入り口が変わる

同じSaaSでも、Claude.ai・Claude Desktop・Claude Codeでは連携の入り口が異なります。Claude.aiやDesktopではカスタムコネクタからURLを登録するだけで済むSaaSがある一方、Claude Codeではコマンドでサーバーを追加します。claude mcp add --help(v2.1.287)の例には、リモートサーバーとローカル起動のサーバーが並んでいます。

# リモート(HTTP)サーバー
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
 
# ローカル起動(stdio)のサーバー
claude mcp add my-server -e API_KEY=xxx -- npx my-mcp-server

--transportを省くとstdioとして扱われます。前者はURLのホスト名、後者はnpmパッケージのrepository.urlが、それぞれ前節の確認先です。追加先は--scopeでlocal・user・projectから選べ、既定はlocalです。

組織で使う場合は、管理者側で接続先を絞る仕組みもあります。Claude Codeの管理設定では、allowedMcpServersとdeniedMcpServersで、ユーザーが追加できるサーバーを許可・拒否できます。allowedMcpServersにallowManagedMcpServersOnly: trueを組み合わせると、管理者が公開した一覧にあるサーバーだけが追加できます。規約の確認が済んだ接続先だけを一覧に載せる運用に使えます。allowManagedMcpServersOnlyが無いと、各スコープの許可リストが合算されます。ユーザー自身の~/.claude/settings.jsonも含まれるので、ユーザーが許可の範囲を広げられます。拒否リストだけを置いて、既知の問題があるサーバーだけを止める使い方もあります。

個人アカウントで動いたからといって、組織で同じ経路が通るとは限りません。導入前に、管理者側の許可リストの有無を確認します。

よくある質問

企業が配布するMCPサーバーなら規約を確認しなくていい?

企業自身による配布は提供元が許可した経路なので、個人が作ったAPIラップよりリスクは下がります。ただし、誰のアカウントで動かすか、書き込み権限まで与えるかといった運用面の判断は、配布元を問わず利用側で行います。

MCPではなくREST APIを直接呼び出す場合も同じ確認が必要?

同じです。Sansanのケースも技術形式はREST APIで、論点はMCPという規格そのものではなく「外部からの機械的なアクセス」をどこまで許可するかでした。

まとめ

個人のアカウントで動いた経路でも、組織の許可リストに載っていなければ業務では通りません。出どころの確認と許可リストへの登録は、導入を決める前に済ませておく作業です。どのSaaSが自社製のMCPサーバーを持っているかは国産SaaS MCP対応一覧で見られます。

この記事を共有:XはてブLinkedIn

関連する記事

MCP をもっと見る →