Workato MCPをClaudeに接続する手順 — トークンとWorkato Identityの選び方
WorkatoのMCPサーバーをClaudeのカスタムコネクタとして繋ぐ手順です。トークン方式とWorkato Identityの違い、つまずきやすい点、IP制限との相性をまとめます。
Workato MCPは、Workatoで組んだ業務自動化(API recipeやスキルなど)をMCPサーバーとして公開する仕組みです。Claudeからは、そのURLをリモートMCPサーバーとして登録するだけで、社内の自動化をツールとして呼べます。
最初に決めるのは、利用者の認証方式です。Workatoのトークン方式は設定が早い反面、トークンがURLに載ります。Workato Identity方式は、ユーザーごとのサインインと権限管理に向きます。この記事では、方式の選び方から、Claude側の登録手順、接続できないときの切り分けまでを扱います。
Workato MCPで何をClaudeに渡せるのか
MCPサーバーは、AIエージェントに「ツール」を見せる窓口です。Workatoでは、1台のサーバーに業務アプリ向けの絞り込んだツール群を載せ、認証とアクセス制御もサーバー側で行います。
Claudeに渡す元になるのは、次の3系統です。
- Workato-hostedのMCPサーバー: API collectionまたはプロジェクト内のアセット(スキルやAPI recipe)をツールにします。もっとも早く始められる構成です
- プロキシMCPサーバー: 外部のMCPサーバーのURLを登録し、Workatoを経由させます。Salesforceのような外部システムに、ユーザー本人の資格情報でつなげます
- ローカルMCPサーバー: 自社のインフラ上で動かします
別に、Workatoの開発者向けAPIをMCP化するサーバーもあります。Claude DesktopやCursorからWorkatoのワークスペース自体を操作する用途です。業務を自動化したいなら前の3系統、Workatoの資産を作る側に使うならこちらです。
利用できるのは、US・EU・AU・JP・SG・IL・KR・UKのデータセンターです。CNデータセンターのワークスペースでは使えません。
先に決める: トークン方式かWorkato Identityか
Claudeの登録画面に入れるURLの中身は、Workato側の認証方式で決まります。
Workato MCPの2つのアクセス方式
トークン方式
MCPサーバーを作ると、トークンが自動で発行されます。URLにwkt_tokenが付いた形で渡す設計です。管理者はトークンを複数作り、利用者ごとに分けられます。
Workato Identity
シングルサインオンで、Claude・Cursor・Windsurfなどに共通のサインイン体験を出せます。ただし、使う人は全員エンドユーザーグループに入れる必要があります。
選び方の分かれ目は3つあります。
1. 誰の権限でツールを動かすか。トークン方式は、トークンを持つ人が同じ入口を通ります。ユーザー本人の外部資格情報で動かす「verified user access」は、Workato Identityが前提です。トークン方式とは併用できず、トークン認証のまま切り替えるとそのツールは使えなくなります。
2. 誰が使えるか。Workato Identityでは、ワークスペースのオーナーや管理者でも自動では使えません。自分自身も含め、エンドユーザーグループへの追加が要ります。
3. 後から変えられるか。トークン方式からWorkato Identityへ切り替えると、トークンは失効します。トークンで登録済みのClaudeコネクタは、その時点で動かなくなります。
Claude側の作りも効いてきます。Claudeのカスタムコネクタでは、固定の認証情報を「Request headers」で渡す設計です。クエリに載せたトークンは、URLごとログや履歴に残りえます。ヘッダー認証とOAuthの使い分けはCoworkカスタムコネクタ自作ガイドで扱っています。wkt_tokenをURLに載せるWorkatoの設計は、チームで長く使うなら、Workato Identityへ寄せる理由になります。
手順: WorkatoでURLを取り、Claudeに登録する
Workato側でMCPサーバーを用意する
MCPサーバーの作成からURL取得まで
- 1
サーバーを作る
AI Hubの「Enterprise MCP」で「Create an MCP server」を選びます。ツールの取り込み元は、プロジェクトのアセット、API collection、外部MCPサーバーから選びます。
- 2
LLM向けの説明を書く
「Server instruction」に、サーバーの目的を書きます。この説明は、Claudeに接続した時点でそのまま共有されます。
- 3
アクセス方式を確認する
「End user access」タブで、トークン方式かWorkato Identityかを確かめます。Workato Identityなら、ここでエンドユーザーグループと、使わせるツールを指定します。
- 4
URLを控える
サーバーの概要ページに、Remote MCP URLが出ます。トークン方式では、「Developer MCP Token」欄の「Copy」でURLとトークンを一緒に取れます。
アセットはすべて同じプロジェクトに置く必要があります。種類の合わないアセットを選ぶと、エラーが出ます。
Claude側でカスタムコネクタとして登録する
Workatoのドキュメントは、Claude向けに「Settings > Connectors > Add new connector」から、名前とRemote MCP server URLを入れる手順を示しています。Claudeのヘルプセンターでは、個人のProとMaxなら「Customize > Connectors」から「Add custom connector」、TeamとEnterpriseならオーナーが「Organization settings > Connectors」から追加する案内です。画面の名称は両者でずれているので、手元の画面に合わせて読み替えます。
Team/Enterpriseでは、追加できるのはオーナーなどの限られた役割です。追加後、メンバーは「Customize > Connectors」で「Connect」を押し、各自で認証します。
登録の流れは次のとおりです。
- 名前を入れ、Workatoで取ったRemote MCP URLを貼り、「Continue」を押す
- Claudeが検出した認証設定を確認する。Workato Identityなら、サインインの方式として「Sign in now」か「Sign in when needed」を選ぶ
- 固定の認証情報をヘッダーで渡す構成なら、「Request headers」に入れる
- 「Add」で完了
Workatoの手順には、権限の項目もあります。追加後に「Configure」を開くと、「Always ask permission」か「Allow unsupervised」を選べます。既定は「Always ask permission」で、ツールを呼ぶたびに確認が入ります。社内の更新系ツールを含むサーバーでは、まず既定のまま使い、読み取り専用のツールだけを緩める運用が安全側です。
Claudeのヘルプによると、URLのドメインがコネクタディレクトリの掲載先と一致する場合(例としてWorkatoのワークスペースURL)、「Custom」ではなくそのサービス名とブランドで表示されます。自分で登録したコネクタであることは変わらないので、消して入れ直す必要はありません。
Claude Codeに登録する場合
Workatoのドキュメントが扱うClaude側の面は、Claude DesktopとClaude本体の「Connectors」です。Claude Codeでの手順は載っていません。Claude Code側のリモートHTTPサーバー追加の書式は、次のとおりです。
claude mcp add --transport http workato-tools \
https://<MCPサーバーのRemote MCP URL>トークンをヘッダーで渡す--headerオプションもあります。ただし、Workatoのトークン方式はwkt_tokenをURLのクエリで受ける設計で、ヘッダー渡しの手順は示されていません。ここで示した組み合わせは、両者のドキュメントの書式を合わせた例で、Workatoが検証済みの経路とは言えません。登録後は/mcpでツールが見えるかを確かめます。
組織全体でclaude.ai側のコネクタを止めている場合の挙動は、disableClaudeAiConnectorsの記事にまとめています。
接続できないときの切り分け
Workato MCPがClaudeで動かないとき
- QWorkato Identityを使っていて、自分自身がエンドユーザーグループに入っていますか？答えが入っていない答えがはい
エンドユーザーグループを作ってユーザーを追加し、MCPサーバーの「End user access」にそのグループを足します。管理者でも例外ではありません。
- QClaude Teamの複数プロジェクトで、同じトークンを使い回していませんか？答えが使い回している答えがはい
Unauthorizedが出る原因になります。Claude Teamのプロジェクトごとに、別々のwkt_tokenを作って使います。 - Qトークンを再発行・削除した直後ではありませんか？答えが再発行した答えがはい
再発行したトークンでは、古いトークンを持つクライアントが止まります。Claude側のURLを新しいトークンで入れ直します。
- Q社内のネットワーク機器がTLS検査をしていませんか？答えがしている答えがはい
検査機器が証明書を差し替えると、クライアントが接続を拒否します。ネットワーク担当に、
*.apim.mcp.workato.comをTLS検査の対象外にしてもらいます。
それでも解決しない
WorkatoのMCPサーバーログで、リクエスト元のIPやユーザーIDを確認します。ログは「Tools > Logs」で、ログの種類を「MCP server」にして絞ります。
IP制限とレート制限はClaudeとの組み合わせで効き方が変わる
Workato側では、MCPサーバー単位の制限を足せます。既定では、レート制限も利用量の上限もかかっていません。
| 設定 | 内容 | 効き方 |
|---|---|---|
| Rate limit | 内容時間あたりのツール呼び出し数 | 効き方サーバー全体の合計で数える |
| Usage limit | 内容月などの累計の呼び出し数 | 効き方上限に達すると、リセットまで全リクエストが止まる |
| Allowed IPs / Blocked IPs | 内容許可・拒否するIPアドレス | 効き方拒否が許可より優先される |
レート制限の対象は、サーバー内の全ツールと全ユーザーの合計です。1人の使いすぎで全員が止まる点に注意が要ります。
IPの許可リストは、Claudeとの組み合わせで落とし穴になりえます。Claudeのヘルプセンターは、カスタムコネクタの接続が利用者の端末ではなくAnthropicのクラウドから発信されると説明しています。Workatoの許可リストは「指定したIPから始まったツール要求だけ」を通します。両方を合わせると、社内のオフィスIPだけを許可した場合、Claude経由の呼び出しは通らない可能性があります。許可リストを使うときは、Anthropicが公開しているIPレンジを入れたうえで、実際に呼び出せるかをテストします。
運用で効く細かい仕様
- ツール名を変えると同意が消える: ツール名の変更は、新しいツールとして扱われます。以前の同意と設定は破棄され、クライアントが再発見します。Claude側で「Allow unsupervised」にしていたツールも、確認付きに戻りうる前提で見ます
- サーバー説明の書き方で呼ばれ方が変わる: LLM向けの説明は、どのツールをいつ使うかの判断材料になります。ツールを足したら、説明も更新します
- 独自ドメインは使えない: MCPサーバーのURLは、Workato既定のドメイン形式が必須です。開発者APIを直接叩くときの独自ドメインは例外です
- ネストしたレシピ関数は本人の権限にならない: verified user accessが効くのは、ツールとして公開した1階層目のレシピまでです。その中から呼ぶレシピ関数は、サービスアカウントの資格情報で動きます。「本人の権限で」と説明していたツールが、実際は共有アカウントで動く可能性があります
- 長時間アクションは対象外: verified user accessは、long actionを使うレシピ関数を扱えません
ツール一覧がサーバー側で変わっても困らないよう、Claude側のAPIでツールを固定する方法はmcp_tool_listingの記事にあります。Messages APIからこのサーバーを呼ぶ場合は、mcp_toolsetの手順が出発点です。
設計の前に押さえる判断軸
最後に、導入前の判断を3つに絞ります。
- 読み取り中心の自動化から始める。更新系は、確認付きの設定のまま段階的に開ける
- 複数人で使うなら、最初からWorkato Identityを選ぶ。後から切り替えるとトークンが失効し、全員の再設定になる
- IP制限とレート制限は、Claudeからの実トラフィックで試してから本番に入れる
トークン方式は、手元の検証用に割り切るとちょうどよい方式です。