Coworkカスタムコネクタ自作ガイド — リモートMCPで社内システムに接続する
Coworkに社内システムを自作コネクタとして繋ぐ手順です。リモートMCPサーバーの立て方、認証方式の選び方、接続できないときの切り分け方をまとめます。
Coworkディレクトリに無い社内システムやニッチなSaaSは、リモートMCPサーバーを自分で立てて「カスタムコネクタ」として登録すれば接続できます。Team/Enterpriseプランではオーナーが組織に登録し、メンバーが個別に認証する2段構成です。この記事ではサーバー側の技術要件、登録手順、接続できないときの切り分け方を順に扱います。
Coworkのカスタムコネクタとは何か
カスタムコネクタとは、URLを登録するだけで接続できるリモートMCPサーバーの登録機能です。Model Context Protocol(MCP)はAnthropicが策定したオープンな標準規格で、AIアプリケーションがツールやデータに接続するための共通仕様です。以前はMCPサーバーがローカル(利用者のノートPC上)でしか動きませんでしたが、現在はインターネット越しに通信するリモートMCPサーバーを開発者が自分でホストできます。
Coworkに限らず、claude.ai・Claude Desktop・モバイルアプリを含むすべてのClaudeクライアントで、カスタムコネクタは同じ仕組みで動きます。Free・Pro・Max・Team・Enterpriseの全プランで利用でき、Freeプランだけ登録数が1件に制限されます。プリビルドconnectorやディレクトリ掲載サービスとの使い分けはClaude CoworkのConnectors一覧で扱っています。
自作する前に確認すること — 接続はAnthropicのクラウドから発信される
自作コネクタで最初につまずくのがネットワークの向きです。Coworkはローカルで動くアプリですが、カスタムコネクタを追加すると、ClaudeはAnthropicのクラウドインフラからあなたのリモートMCPサーバーに接続します。手元の端末からではありません。これはCoworkとClaude Desktopでも同様で、両者がローカルアプリであることとは関係ありません。
つまり、サーバーはAnthropicのIPレンジからパブリックインターネット経由で到達可能である必要があります。社内ネットワークの内側、VPNの背後、ファイアウォールで塞がれた場所に置いたサーバーは、自分のマシンからは届いても接続できません。社内ネットワークに置く場合は、ファイアウォールでAnthropicのIPアドレスを許可リストに追加する必要があります。
手順1: リモートMCPサーバーを用意する
サーバー実装から始める場合、TypeScript SDKとPython SDKにサーバー実装のサンプルが用意されています。ゼロから作るのが手間な場合は、Claude Codeに公式のmcp-server-devプラグインを入れると、対話形式でサーバーの実装・テスト・パッケージ化まで進められます。ホスティングにはCloudflareのように、オートスケーリングとOAuth管理を備えたリモートMCPサーバー向けのプラットフォームも使えます。ゼロからサーバーを組み立てる手順はMCPサーバー自作ガイドにまとめています。
対応しているプロトコル機能とサーバー側の技術仕様は次の通りです。
| 項目 | 内容 |
|---|---|
| 対応トランスポート | 内容Streamable HTTP(推奨)。旧HTTP+SSEも動くが非推奨化が進行中 |
| 対応プロトコル機能 | 内容Tools・Prompts・Resources、テキスト/画像のツール結果、テキスト/バイナリのリソース |
| 未対応の機能 | 内容リソースの購読(subscription)・Sampling・draft段階の高度な機能 |
| Claude.ai/Desktopのツール結果上限 | 内容約15万文字 |
| Claude Codeのツール結果上限 | 内容25,000トークン(MAX_MCP_OUTPUT_TOKENSで変更可) |
| Claude.ai/Desktopのタイムアウト | 内容300秒(5分) |
公式の技術仕様表はclaude.aiとClaude Desktopを対象に上限を示しています。Coworkに適用される値は公開されていないため、巨大なレスポンスや長時間の処理を前提にしないツール設計が安全です。
手順2: 認証方式を選ぶ
サーバー側で選べる認証方式は6種類あります。どれを選ぶかで、追加の申請が要るかどうかが変わります。
| 方式 | 内容 | 提供状況 |
|---|---|---|
oauth_dcr | 内容Dynamic Client Registration(RFC 7591)によるOAuth 2.0 | 提供状況標準で対応 |
oauth_cimd | 内容Client ID Metadata Documentを使うOAuth 2.0 | 提供状況標準で対応 |
oauth_anthropic_creds | 内容Anthropicが管理するクライアント認証情報を使うOAuth 2.0 | 提供状況mcp-review@anthropic.comへの申請が必要 |
custom_connection | 内容接続時に入力するカスタムURL・認証情報(Snowflakeのような形式) | 提供状況同上、要申請 |
static_headers | 内容組織管理者が接続時に入力する固定の認証情報(APIキーやbearerトークン) | 提供状況ベータ |
none | 内容認証なし | 提供状況標準で対応 |
社内システム向けに自作する場合、認可サーバーを自前で持っているならoauth_dcrが最も手間が少なく、標準で動きます。認可サーバーがregistration_endpointを公開できない場合は、Client ID Metadata Documentへの対応を検討します。それも難しければ、oauth_anthropic_credsへの切り替えが候補です。アクセス頻度が高いコネクタでは、oauth_dcrは接続のたびに新しいクライアントを登録してしまいます。CIMDやoauth_anthropic_credsのほうが、認可サーバー側の登録済みクライアント数を抑えられます。
固定のAPIキーやbearerトークンで動くシンプルな社内ツールなら、static_headers(リクエストヘッダー認証)が候補になります。組織全体で1つの認証情報を共有する用途に向いていて、個人ごとのサインインが要らない代わりに、組織の管理者が1回だけ値を入力する運用です。OAuth認証の仕組みをさらに深く知りたい場合はリモートMCPのOAuth認証を参照してください。
サーバーを実装したら、登録前にMCP Inspectorで認可フローを検証しておくと、組織登録後のトラブルを減らせます。認可サーバーとのやり取り(discovery・クライアント登録・トークン取得)をInspector上で一通り通してから、claude mcp addでClaude Codeに一時的に追加し、/mcpコマンドで疎通と認証が通ることを確認します。この2段階を踏んでから組織への登録に進むと、原因の切り分けが楽になります。
手順3: Team/Enterpriseプランで組織に登録する
Team/Enterpriseプランでは、コネクタを組織に追加できるのはOwnerだけです。追加された後、メンバーは個別に認証して使い始めます。これにより、Claudeがアクセスできるのは各利用者が実際に権限を持つ範囲のツールとデータに限られます。
オーナーが行う初期設定は次の流れです。
- Organization settings > Connectorsに移動する
- 「Add」ボタンをクリックする
- 「Custom」にカーソルを合わせ「Web」を選ぶ
- リモートMCPサーバーのURLを入力する
- 必要に応じて「Advanced settings」でOAuthクライアントID・シークレットを指定する
- 「Add」で確定する
その後、メンバー側の手順は次の通りです。
- Customize > Connectorsに移動する
- オーナーが追加したカスタムコネクタを探す(通常「Custom」ラベルが付く)
- 「Connect」をクリックして認証する
登録したカスタムコネクタのURLが、Connectorsディレクトリに載っているサービス(Workatoのワークスペースなど)のドメインと一致することがあります。この場合、「Custom」ではなくそのサービス名とブランディングで表示されます。中身は自分で登録した接続先のままなので、削除して登録し直す必要はありません。
手順4: Pro/Maxプランで個人アカウントに追加する
個人のPro/Maxプランであれば、組織の承認なしに自分で追加できます。
- Customize > Connectorsに移動する
- 「+」から「Add custom connector」を選ぶ
- リモートMCPサーバーのURLを入力する
- 必要に応じて「Advanced settings」でOAuthクライアントID・シークレットを指定する
- 「Add」で確定する
追加後は、チャット入力欄下部の「+」ボタンから「Connectors」を開くと、会話ごとに有効/無効を切り替えるトグルが表示されます。
よくあるつまずき — 接続できない・認証が通らないとき
接続エラーには2種類あります。「Couldn't reach the MCP server」と「Authorization with the MCP server failed」です。どちらも複数の原因をひとまとめにした表示なので、症状だけで原因を決めつけず、順番に切り分けます。
まず確認すること: 接続に失敗すると、エラーのトーストとページURLにofid_から始まる参照IDが表示されます。原因が特定できずサポートに問い合わせる場合、このIDを控えておくと調査が早くなります。参照IDには有効期限があるため、失敗した直後に控えてください。
「Couldn't reach the MCP server」の主な原因
- ホスト名がプライベートIPを指している — claude.aiはAnthropicのインフラから、パブリックインターネット経由でサーバーに到達します。名前解決の結果がプライベートアドレス(
10.0.0.0/8など)やキャリアグレードNAT、ループバック、リンクローカルのいずれかであれば、Claudeはリクエストを送る前に接続を拒否します。手元の端末やClaude Codeでは繋がるのにclaude.aiだけ繋がらない場合、社内DNSと外部DNSで解決結果が違う「スプリットホライズンDNS」を疑ってください - ファイアウォールやWAFがAnthropicの通信を止めている — CDNやWAF、bot対策のルールがリクエストをブロックしていないか、エッジのログで
403や429を確認します - サーバーのURLが別ホストへリダイレクトしている — 登録したURLが
301/302などで別ホストへ転送される設定だと、標準的なHTTPクライアントのセキュリティ挙動としてAuthorizationヘッダーがリダイレクト時に落とされます。転送先は認証なしのリクエストを受け取り401を返します。結果として「認証に失敗した」というエラーになります - OAuthのdiscoveryが失敗している —
401レスポンスにresource_metadataを指すWWW-Authenticateヘッダーが無い場合、Claudeは/.well-known/配下の標準パスを探しにいきます。そこも404なら、認可サーバーの場所自体を特定できません
curl -i https://your-server.example.com/.well-known/oauth-protected-resource
curl -i https://your-server.example.com/.well-known/oauth-authorization-server
curl -i https://your-server.example.com/.well-known/openid-configuration上記をパブリックなネットワークから実行します。protected resource metadataが200とJSONを返すか、authorization server metadataの2つのエンドポイントのうち少なくとも一方が200を返すかを確認してください。Auth0・Okta・Microsoft Entra・Keycloak・Supabase Authなど多くのホスト型IDプロバイダーは/.well-known/openid-configurationだけを提供します。もう一方が404でも問題ありません。
「Authorization with the MCP server failed」の主な原因
- issuerの不一致: 認可サーバーのメタデータに書かれた
issuerと、実際にトークンへ署名している発行者が食い違っている - audienceの不一致: ClaudeはRFC 8707の
resourceパラメータに、MCPサーバーURLの正規形(スキームとホストは小文字、末尾スラッシュなし)を載せて送ります。認可サーバー側がこの正規形をそのままaudとして検証できないと失敗します - PKCE未対応: Claudeはすべての認可リクエストに
code_challenge_method=S256のPKCEを付けます。認可サーバーがS256のPKCEに対応していないと、トークンエンドポイントで失敗します - トークンエンドポイントの応答が遅い: Claudeはdiscovery・登録・トークン取得のエンドポイントに最大10秒、リフレッシュトークンには最大30秒待ちます。この時間内にレスポンスが返らないと、サーバー側で最終的に成功していても失敗扱いになります
Microsoft Entra IDを認可サーバーに使っている場合に固有の落とし穴もあります。トークン要求がAADSTS9010010で失敗するときは、原因はアプリ登録側にあります。Claudeが送るresourceの値(MCPサーバーURLそのもの)が、「Application ID URI」に登録されていないのです。既定のapi://{client-id}だけでは足りず、MCPサーバーのURLをパスまで含めてApplication ID URIに追加する必要があります。
診断チェックリスト
問い合わせる前に、次の順で確認すると原因の切り分けが早くなります。
- パブリックなネットワークから
dig +short your-server.example.comを実行し、グローバルにルーティング可能なアドレスが返るか確認する curl -i https://your-server.example.com/your-mcp-pathを実行し、レスポンスが返るか確認する(401や405は正常、タイムアウトや接続拒否は異常)curl -sIでリダイレクトの有無を確認する。別ホストへの3xxが返るなら、転送先のURLを登録し直す- エッジのログで
403/429が出ていないか確認し、必要ならAnthropicの公開IPレンジを許可リストに追加する - discoveryメタデータの2つのエンドポイントを
curlで確認する - 認可サーバーとMCPサーバーのホストが異なる場合、認可サーバー側もAnthropicの発信元から到達可能か確認する
- 再現させて
ofid_の参照IDを控える
Claude Code側での接続確認や切り分けの手順はMCPサーバーに接続できないときの切り分け手順で扱っています。
セキュリティ上、自作コネクタで気をつけること
カスタムコネクタはAnthropicが検証していない任意のサービスへの接続を許可する機能です。接続後、Claudeはそのサービスにアクセスし、権限の範囲内で操作を実行できるようになります。信頼できる組織が構築・運用しているサーバーにのみ接続し、OAuthの同意画面で要求される権限スコープは接続のたびに確認してください。想定外のスコープを要求された場合は許可しない判断も必要です。
悪意のあるMCPサーバーは、隠された指示でClaudeに意図しない操作をさせようとするプロンプトインジェクションを仕込むことがあります。Claudeには対策が組み込まれていますが、ツールの入出力には注意を払い、信頼できるサーバーにのみ接続する原則は変わりません。サーバー開発者が後からツールの挙動を変更する可能性もあるため、想定外の動きが無いか継続的に確認する運用が安全です。悪意のあるMCPサーバーを見つけた場合は、Anthropicの脆弱性報告プログラムへの報告が案内されています。接続後のデータ取り扱いはCoworkセキュリティ — データはどこに置かれ誰が触れるかで詳しく扱っています。
まとめ
Coworkのカスタムコネクタは、URLを登録するだけで社内システムやニッチなSaaSに接続できる仕組みです。ただし接続はAnthropicのクラウドから発信されるため、社内ネットワークに置く場合は許可リストの設定が前提になります。認証方式は自前の認可サーバーがあればoauth_dcrが最短で、固定キーで動く社内ツールにはstatic_headersが向きます。接続できないときは、まずDNSとリダイレクト、次にOAuth discoveryの順で切り分けると原因にたどり着きやすくなります。細かな切り分け手順はMCPサーバーに接続できないときの切り分け手順にまとめています。