ルーターはアドクロールMCPとしてMCPサーバーを提供しております。AIエージェントに応じて最適なMCPサーバーの提供方法も変わってきます。一通りのAIエージェントに対応（そして導入サポート）が完了したので、提供方針の内訳をご紹介します。

まずは、Claudeをベースに考える。

AIエージェントといえばClaudeですが、Claudeにも種類があります。ユーザーが「Claudeを使っています」といった場合には以下の分岐が発生します。

• Web or デスクトップ or CLI
• デスクトップの場合
  • Mac or Windows
  • Chat or Cowork or Code
• CLIの場合
  • Mac or　WindowsPowerShell or WSL
  • ターミナルから使う or VSCodeなどのエディタから使う

これらの分岐のうち、エンジニアがイメージするのは、Claude Code CLIでしょう。ところがClaudeの一番のメリットは非エンジニアがプログラミングできちゃうってところなので、エンジニアではない人が使うことを前提に考えた方がいいです。

Claude Code CLIはエンジニアが普段使ってるものなので、当然そこでもMCPはテストするとして、本命はClaudeデスクトップです。

さらにClaudeデスクトップの中でも、業務の自動化を考えるとClaudeデスクトップ＋Codeになりますが、その自動化があまりにもPCそのものを乗っ取らせてしまうような動きになるため、結局は禁止されるケースもでてきます。そうなるとChatかCoworkで行うことになります。

Chat（Cowork）とCodeの決定的な違いは、仮想環境内でプログラムが動作するかどうかの違いです。Chat（Cowork)の場合は、分離された仮想環境でプログラムが動作しており外部との通信に制限がかかっています。外部通信を許可するにはドメイン単位で許可設定を与える必要があります。HTMLの中の画像、MarkDownの中にリンクされた画像など、URLで示された別ファイルにアクセスできないのはかなり不便です。ドメイン単位で許可する場合でなおかつ導入しているClaudeがチームライセンスの場合には、個々のユーザが許可ドメイン設定をすることができません。

ただチームライセンスも不便なことばかりではなく、組織管理者が設定してしまえば「リモートMCPサーバー設定済み」「外部アクセス許可ドメイン設定済み」になるので個々のユーザーはむしろ設定不要で便利に使えます。

MCPサーバーの導入サポートをする際には、Claudのライセンスと権限に気を配る必要があります。

ローカルMCPサーバー？リモートMCPサーバー？

MCPサーバーにはローカルMCPとリモートMCPがあります。ClaudeアプリがクライアントでそこからMCPサーバ経由で外部システムにアクセスします。弊社ではどちらも用意しています。ローカルMCPはユーザのPCにMCPサーバーをインストールする必要があるので一見不便ですが、リモートMCPはユーザがClaudeのチームライセンスを使ってる場合には管理者しかインストールできません。

またリモートMCPはドメインを取得してサーバーを立てる必要があります。自分のPCしか使わないようなケースでも外部にWebサーバーを立てるとなるとセキュリティ面でのケアが必要となります。

ローカルMCPであれば、管理者権限不要でClaudeからの「自動化の口」を作ることが比較的簡単にできます。

ただし、ローカルMCPの設定には claude_desktop_config.json を編集する必要があります。設定ファイルがJSONで記述されたものなのですが、非エンジニアにとってはJSONを編集するということそのものが大きなハードルとなります。そもそもテキストエディタを使ったことがないユーザーかも知れません。全角半角が間違うだけでJSONとして機能しなくなります。それだけのことですがJSON編集サポートが必要となります。

ローカルMCPを作るとして、Node?Python?

AIが書いてくれるプログラミング言語では、Node.jsかPythonが多くを占めます。MCP関連ライブラリもこなれているため、この2つのプログラミング言語から選択しました。

結論として弊社でローカルMCPを提供しているのはuv経由のPython版にしております。以下その背景です。

• uvであれば初回起動時に依存ライブラリのダウンロード＆インストールもやってくれる
• uvであれば、ソースコードの中のコメント（PEP 723 の Inline Script Metadata）を参照して、依存モジュールを把握してくれるため、1ファイルを配布するだけでいい
• uvであれば、ローカルにファイルがなくても、uv run https://xxxx/xxxx.py と直接参照して実行してくれる

uvそのものをインストールする手間は発生しますが、それ以降は依存モジュールの解決の手間がほぼなくなるというのが特徴です。

uvが特に便利なのは、Mac,Windows,Linuxをまたがったビルド済みライブラリが整備されている点です。インストールが面倒なOpenCVを使ったプログラムもuv経由であれば意識することなく初回起動時に高速にインストールされます。uv経由のPythonは「マルチOS Better Shell＆マルチOSパッケージマネージャー」としてみても超優秀です。

ただ最初のuvのインストールは、MacとWindowsで別の作業が必要となります。Macではターミナル、WindowsではPowerShellの画面での操作が必要です。インストールスクリプトの1行をコピペするだけですが、ここでもサポートは必要です。

リモートMCPを作るとして認証の口はOAuth？Bearerトークン？

次にリモートMCPを提供する方法です。自社提供SaaSにリモートMCPを提供するなら、OAuthとBearerトークンの両方提供するのがいいでしょう。ローカルMCPであればBearerトークンが便利ですが、リモートMCPであればセットアップが楽なOAuthの認証の口を作っておくのがいいでしょう。

ClaudeはOAuthに対応してますが、他のツールはBearerトークンでの接続にしか対応してないものもありますので、両方に対応しておけば、ほとんどのAIエージェントに対応可能となります。

ローカルMCPの提供での副産物：API連携

MCPの実態は、自然言語でAPIにアクセスできるようにした被せ物です。弊社が提供するMCPサーバーは「コスメの広告をみたい」という自然言語をうけて、コスメカテゴリのカテゴリIDを探してカテゴリIDをクエリストリングとした検索APIを叩くという変換ロジックが書かれてるだけです。ローカルMCPサーバーのスクリプトを配布することの実態はAPIリファレンスの配布していることとほぼ同義となります。実際にMCPサーバーのスクリプトを配布すると「どうせ同じことを毎日やるのだからMCP経由しないでAPIでいいよね」という判断をされるケースもあります。MCPを経由しないと「トークン消費量がゼロ」になるという点がメリットです。MCPのいいところは自然言語を解析してくれるところですが、レスポンスが大きいとそれらのレスポンスを「読む」だけで結構なトークンを消費します。しかしAPI連携であればAIが登場しないでもシステムは構築できます。例えばGASを使ってスプシやLookerStudioに定期レポートを出す例もあります。そのGASのコードを最初に書くのにAIは使いますが、それ以降ではAIは不要です。当然LookerStudioのレポートを観るユーザにはAIのライセンスは不要です。

まとめ

• 意外とローカルMCPサーバーも便利だ（インストールのハードルを超えれば）
• uvはツールの配布という観点でとんでもなく便利だ
• MCPきっかけでAPI連携のハードルが下がってAPI連携が進むのはとてもいい話だ