CoworkをBedrock・Vertex・Foundryで動かす方法

CoworkはAnthropicのクラウドを使わず、自社が契約するAmazon Bedrock・Google Cloud・Microsoft Foundryのインフラ上で動かせます。正式名称は「Claude Desktop on 3P(third-party)」で、推論だけをこれらのプロバイダーへ切り替えるデプロイモードです。データが米国のAnthropicへ渡ることを規制・契約上避けたい企業向けの構成で、プロバイダーによってデータの扱いとレジデンシーの決まり方が異なります。

Coworkを自社クラウドで動かすとは何か

Claude Desktop on 3Pは、Claude Desktopの機能セット(Chat・Cowork・Code)をそのまま維持しつつ、モデル推論の送信先だけを差し替えるデプロイモードです。会話の内容はユーザーの手元のデバイスに保存され、認証もAnthropicアカウントではなくローカルのデバイスIDに切り替わります。ファイル作成・複数ステップのリサーチ・サブエージェントの連携といったCoworkの機能そのものは、標準のClaude Desktopと同じです。

想定される導入先は次の2つです。

• サードパーティ推論のみが許される高規制企業: 規制や自社のセキュリティ基準により、第三者の推論基盤しか使えない組織
• データレジデンシー要件を持つ国際企業: 会話データを米国へ送れない、リージョン内保存が契約条件になっている組織

Anthropicが直接提供するサービス(claude.aiやClaude API)を使える組織であれば、標準のClaude Desktop + Team/Enterpriseプランのほうが導入は簡単です。管理コンソールでのユーザー管理・分析・RBACが揃っていて、新機能のリリースも速いためです。Claude Desktop on 3Pを選ぶのは、Anthropicの推論を経由すること自体が選択肢にない場合に限られます。

標準Coworkと何が違うか

推論の送信先以外にも、いくつかのコンポーネントが標準のClaude Desktopと入れ替わります。

コード実行サンドボックスは標準版と同じ仕組みがそのまま使われます。変わるのは推論の送信先・会話の保存場所・認証・設定方法の4点で、Cowork自体の機能や隔離の仕組みには手が入りません。標準のクラウド実行とローカル実行でデータの扱いがどう違うかはCoworkセキュリティ — データはどこに置かれ誰が触れるかで詳しく扱っています。

3つのプロバイダーでデータの扱いはどう違うか

推論エンドポイントに届いた後のデータの扱いは、プロバイダーごとに規定する主体が変わります。

Amazon BedrockとGoogle Cloudの場合、データの扱いはそれぞれのクラウドプロバイダーが定める条件に従います。Anthropicはこの経路のデータ処理には関与しません。

Microsoft Foundryは事情が異なります。モデルをデプロイする際、「Hosted on Azure」と「Hosted on Anthropic」の2つのホスティング形態から選びます。どちらの形態でもAnthropicがClaudeモデルを運用し、Microsoftの独立処理者として会話データを扱います。Foundry経由の利用も、Anthropicのデータ利用条件が適用される対象です。

• Hosted on Azure: 推論はAzureインフラ上で動くAnthropic運用のサービス内で完結し、プロンプトと生成結果はAzureの外に出ません。ここでいうAzureインフラは自社のAzureテナントではなく、Anthropicが運用する環境です。Azureの外へ送信されるのは、利用状況のメタデータと、Anthropicの安全システムがフラグを立てたコンテンツだけです
• Hosted on Anthropic: プロンプトと生成結果が推論のためにAnthropic自身のインフラへ送信されます

同じ「Microsoft Foundry経由」でも、ホスティング形態によってプロンプトがAzureの外に出るかどうかがまったく違います。デプロイ時にどちらを選んだかを必ず確認する必要があります。

データレジデンシーはどこで決まるか

3つのプロバイダーでレジデンシーが決まる要素も異なります。

Google CloudとAmazon Bedrockは、推論リクエストがユーザーの端末から設定したリージョンのエンドポイントへ直接届きます。レジデンシーを決めるのは次の2点です。

1. 推論に選んだクラウドリージョン
2. 会話が保存されるユーザーのデバイスの物理的な所在地

複数拠点にまたがる組織では、拠点ごとに別のMDM設定プロファイルを配布し、各拠点のユーザーがリージョン内のエンドポイントを向くようにします。Google CloudとAmazon Bedrockは、いずれもEU・英国・アジア太平洋リージョンでClaudeモデルを提供しています。最新の対応リージョンは、各プロバイダーのモデル提供状況のドキュメントで確認が必要です。

Microsoft Foundryは、デプロイ時に選ぶホスティング形態とデプロイタイプでレジデンシーが決まります。Hosted on Azureにはさらに2種類のデプロイタイプがあります。

他の2プロバイダーと同様、会話履歴自体はユーザーのデバイスに保存されます。リージョン内保存が契約条件になっている組織は、Hosted on AzureのUS Data Zone Standardのように、地理的な範囲が明示されたデプロイタイプを選ぶ必要があります。

高規制環境で外向き通信をどこまで絞れるか

Google CloudかAmazon Bedrockを使う場合、推論は自社のクラウドテナント内で完結します。Claude Desktop on 3Pの通信は、そのテナントとリージョンが持つコンプライアンス境界の内側に収まります。それでも、デスクトップアプリ自体がAnthropic運用のホストへ接続する経路が残っています。

アプリがAnthropicへ接続するのは次の用途です。VMワークスペースのバンドルとClaude CLIバイナリのダウンロード(これは常に必須)、クラッシュレポート、プロダクト分析、非必須サービス(コネクタのファビコン・アーティファクトのプレビュー・MCP Appsのウィジェット)、自動更新です。後半4つは、管理設定でそれぞれ個別に無効化できます。

テレメトリ・非必須サービス・自動更新をすべて無効にすると、残るAnthropic向けの通信は1つだけになります。セッション開始時にdownloads.claude.aiからVMバンドルを取得する経路です。CodeセッションでWeb Fetchを使わせる場合は、skipWebFetchPreflightをtrueに設定するか、disabledBuiltinToolsにWebFetchを追加してください。設定しないと、Claude CodeのCodeセッションはフェッチしたドメインごとにapi.anthropic.comへの照会を行います。ここまで絞り込んだ後のコンプライアンス姿勢は、選んだ推論プロバイダー側の条件で決まります。

HIPAA対応はプロバイダーで結論が変わる

医療情報(PHI)を扱う可能性がある組織にとって、HIPAA対応の可否はプロバイダー選びの分岐点になります。

Google CloudかAmazon Bedrockであれば、Claude Desktop on 3Pはユーザーデータ・プロンプト・生成結果をAnthropicへ送信しません。そのためAnthropicが、ユーザーのアップロードしたPHIに触れることはありません。データが渡る先はクラウドサービスプロバイダーと、自分で設定したリモートMCPサーバーだけです。HIPAA対応の構成にするには、クラウドサービスプロバイダーとの間でBAA(Business Associate Agreement)を締結してください。接続するMCPサーバーがHIPAA対応かどうかも事前に確認する必要があります。テレメトリを無効にする必要はありません。Anthropicのテレメトリに含まれるのは編集済みのクラッシュレポートと集計された利用状況メトリクスのみで、ユーザーデータ・プロンプト・生成結果は一切含まれないためです。

Microsoft Foundryでは、HIPAA対応の構成が用意されていません。ホスティング形態にかかわらずAnthropicがClaudeモデルを運用し、会話データを処理するためです。AnthropicがAPI経由で提供しているHIPAA対応の枠組み(BAAの締結とPHI処理のための保護策)は、Microsoft Foundry経由の利用を対象に含んでいません。PHIを扱う可能性がある組織は、推論プロバイダーとしてGoogle CloudかAmazon Bedrockを選び、そのプロバイダーとBAAを締結する必要があります。

「Vertex AI」ではなく「Google Cloud's Agent Platform」という名称の変化

このプロバイダーはかつて「Vertex AI」と呼ばれていましたが、公式ドキュメントでは「Google Cloud's Agent Platform」という名称に置き換わっています。社内資料や検索では旧称の「Vertex」がまだ広く使われていますが、契約や設定作業に入る際は、この呼称で公式ドキュメントを開き直し、機能範囲が変わっていないかを確認するのが安全です。

どんな組織がこの構成を選ぶことになるか

3つのプロバイダーの違いを踏まえると、選択の軸は「PHIを扱うか」と「レジデンシーの単位をどこに置きたいか」の2つに整理できます。PHIを扱う可能性がある組織は、HIPAA対応が用意されているGoogle CloudかAmazon Bedrock一択です。PHIを扱わず、契約上のレジデンシー要件だけが問題であれば、Microsoft Foundryも選択肢に入ります。ただしHosted on AzureとHosted on Anthropicのどちらを選ぶかで「プロンプトがAzureの外に出るかどうか」が変わる点は、導入前に必ず詰めておく必要があります。

いずれのプロバイダーを選んでも、標準のClaude Desktop + Cowork(Team/Enterpriseプラン)が持つ管理コンソール、分析、RBACの使い勝手は失われます。設定はMDM経由のOSネイティブな構成に置き換わり、新機能の展開も標準版より遅くなります。データレジデンシーという1つの要件のために、運用面のコストを引き受ける構成だと捉えておくのが実態に近いです。

まとめ

CoworkをBedrock・Google Cloud・Microsoft Foundry経由で動かす「Claude Desktop on 3P」は、推論の送信先を自社のクラウド契約に差し替えるモードです。Cowork自体の機能やサンドボックスの仕組みは標準版と変わりません。違いが出るのはデータの扱いです。Google CloudとAmazon BedrockはAnthropicを経由せず各クラウドの条件に従うのに対し、Microsoft Foundryはホスティング形態にかかわらずAnthropicがモデルを運用し続けます。HIPAA対応が必要な組織はGoogle CloudかAmazon Bedrockを選ぶ必要があり、Foundryにはその構成がありません。

導入の実務やRBAC・監査ログの設計はClaude CoworkのRBAC運用にまとめています。VS Codeなどエディタ側でサードパーティ推論プロバイダーを使う設定はClaude Code拡張機能でのサードパーティプロバイダー設定も参考になります。