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

Coworkは、自社が契約するAmazon Bedrock・Google Cloud・Microsoft Foundryを推論先にして動かせます。Anthropic直営のサービス(claude.aiやClaude API)は通しません。正式名称は「Claude Desktop on 3P(third-party)」で、推論の送信先だけをこれらのプロバイダーへ切り替えるデプロイモードです。会話データを米国のAnthropicへ渡せない企業向けの構成ですが、3社は同じ扱いではありません。データの行き先、レジデンシーの決まり方、HIPAA対応の可否がプロバイダーごとに分かれます。

自社クラウドで動かすのはどんな組織か

Claude Desktop on 3Pは、Chat・Cowork・Codeの機能セットを保ったまま、モデル推論の送信先を差し替えます。ファイル作成・複数ステップのリサーチ・サブエージェントの連携といったCoworkの機能は、標準のClaude Desktopと同じです。会話はユーザーの手元のディスクに保存され、Webアプリケーション本体もデスクトップアプリに同梱されます。

公式が想定する導入先は2種類です。

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

Anthropic直営のサービス(claude.aiやClaude API)を使える組織なら、標準のClaude DesktopにTeamまたはEnterpriseプランを組み合わせるほうが導入は簡単です。新機能も3P版より早く届きます。Anthropicの推論を通すこと自体が選べないときに、この構成が候補になります。

標準版から入れ替わるのは何か

サンドボックスは標準版と同じ仕組みで、シェルコマンドはCowork用のVMの中で動きます。ファイルアクセスは許可したフォルダーに、Webフェッチは設定した送信許可リストに限られます。「3Pにすると標準版の管理機能をすべて失う」と読むのは正確ではなく、設定の届け方に管理コンソールという選択肢が残っています。この管理コンソールはベータで、Anthropicの担当者に組織を用意してもらう必要があります。ただしその場合、アプリは起動時と設定の再確認のたびにapi.anthropic.comへ、サインイン時にclaude.aiへ接続します。Anthropicとの接点を最小にしたい構成とは両立しません。

標準のクラウド実行とローカル実行でデータの扱いがどう違うかはCoworkセキュリティ — データはどこに置かれ誰が触れるかで扱っています。

3社でデータの行き先はどう違うか

推論エンドポイントにリクエストが届いた後の扱いは、プロバイダーによって決める主体が変わります。

Amazon BedrockとGoogle Cloudは、データの扱いがそれぞれのクラウドの規定(AWSのデータ保護、Google Cloudのデータガバナンス)に従います。Claude Desktop on 3PはユーザーデータやプロンプトをAnthropicへ送りません。送信先はクラウドプロバイダーと、利用者が自分で設定したリモートMCPサーバーだけです。

Microsoft Foundryは構造が違います。デプロイ時に「Hosted on Azure」か「Hosted on Anthropic」を選びますが、どちらでもAnthropicがClaudeモデルを運用します。AnthropicはMicrosoftの独立した処理者として会話データを扱い、利用にはAnthropicのデータ利用条件が適用されます。

くらべる

Foundryの2つのホスティング形態

プロンプトはAzure内

Hosted on Azure

推論はAzureのインフラ上にある、Anthropic運用のサービスで動きます。自社のAzureテナントの中ではありません。プロンプトと生成結果はAzureの外に出ず、Anthropicへ出るのは利用状況のメタデータと、安全システムがフラグを立てたコンテンツだけです。

プロンプトはAnthropic側へ

Hosted on Anthropic

プロンプトと生成結果が、推論のためにAnthropic自身のインフラへ送られます。

同じ「Foundry経由」でも、プロンプトがAzureの外に出るかどうかが正反対になります。契約書やセキュリティ審査で「Azureだから域内」と書く前に、どちらのホスティング形態でデプロイしたかを確かめる必要があります。

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

Google CloudとAmazon Bedrockでは、推論リクエストが端末から、設定したリージョンのエンドポイントへ直接届きます。レジデンシーを決めるのは、推論に選んだクラウドリージョンと、会話が保存されるデバイスの物理的な所在地の2点です。拠点が複数あるなら、拠点ごとにMDMの設定プロファイルを分け、各拠点のユーザーが域内のエンドポイントを向くようにします。両社ともEU・英国・アジア太平洋のリージョンでClaudeを提供していて、最新の対応リージョンは各社のモデル提供状況のページで確認する形です。

Foundryは、ホスティング形態とデプロイタイプの組み合わせで決まります。

ここに落とし穴があります。Foundryで選べる地理的な限定は、公式の記述では米国内だけです。「日本国内」「EU域内」で推論を閉じたい組織にとって、Foundryの2つのデプロイタイプはどちらも該当しません。域内保存が契約条件なら、リージョンを自分で指定できるGoogle CloudかAmazon Bedrockが先に候補になります。会話履歴がデバイスに残る点は3社共通です。

認証はどの方式で配るか

プロバイダー選びと並んで、導入で時間がかかるのが認証です。3社とも「共有の長期シークレットを配る方式」と「ユーザーごとにサインインさせる方式」の両方を用意していて、監査ログでユーザーを個別に追えるかどうかが分かれ目になります。

認証

プロバイダー別の認証の選択肢

• Amazon Bedrock

  PoC向けのBearerトークン(共有キー)とAWS CLIの名前付きプロファイルに加え、アプリ内のAWSサインイン(IAM Identity Center経由、アプリv1.6259.0以降)があります。認証プロキシを置く構成向けには、IdPサインイン(v2.7032.0以降)も使えます。Bearerトークンは共有キーなので個別ユーザーをCloudTrailで追えず、IdPサインインでは識別がプロキシ側になります。

• Google Cloud

  サービスアカウントキー(共有)、Googleアカウントでのアプリ内サインイン、Entra IDやOktaなど外部IdPのWorkforce Identityサインイン、認証情報ヘルパーがあります。Cloud Audit Logsで個人を追えないのは、共有のサービスアカウントキーです。

• Microsoft Foundry

  APIキー(共有)、Entra IDでのアプリ内サインイン(デバイスコード・ブラウザー・OSのIDブローカーの3方式)、認証情報ヘルパーの3系統です。

どのプロバイダーにも、実行時に標準出力へ認証情報を出す実行ファイルを指定する認証情報ヘルパー(inferenceCredentialHelper)があります。長期キーを設定ファイルに置けないが、社内に取得手段はある、という組織向けの逃げ道です。

共有キー方式はどの社も「PoC向け」と位置づけています。Bedrockの公式ページは、Bearerトークンを「広い展開には推奨しない」としています。全社展開を見込むなら、最初からサインイン方式を前提にしたほうが、後で配布物を作り直さずに済みます。

つまずきやすい設定

公式ページには、設定ミスが起きやすい箇所が具体的に書かれています。

• Bedrockのモデル有効化: Model accessで有効にしたリージョンと、アプリに設定するリージョン(inferenceBedrockRegion)を一致させる必要があります。許可はリージョン単位で付くためです
• BedrockのBearerトークン: キーを作っただけでは足りません。キーの裏にあるIAMプリンシパルにbedrock:CallWithBearerTokenを許可しないと、キーがあっても認可エラーになります
• Bedrockのサインイン方式の制約: アプリ内サインインは、1つの設定プロファイルにつき1つのAWSアカウントと1つの権限セットに固定されます。部署ごとに権限を変えるなら、inferenceBedrockSsoRoleNameを変えた設定プロファイルを別々に配ります
• FoundryのEntra IDサインイン: アプリ登録に「Azure Cognitive Services」の委任権限user_impersonationを追加し、管理者の同意を付与します。ユーザー同意を無効にしているテナントでは、同意を付けるまでエラーコードAADSTS65001でサインインに失敗します
• Google Cloudのセッション制御: WorkspaceでGoogle Cloudのセッション長を数時間以下にしていると、アプリ内Googleサインインは期限切れのたびに再サインインを求めます。回避策として、OAuthクライアントを信頼済みアプリにして再認証の対象外にするか、サービスアカウントキー・Workforce Identityサインイン・ゲートウェイに切り替える方法が示されています

モデルの見つけ方にも違いがあります。Bedrockで自動検出が効くのはBearerトークンと認証情報ヘルパーのときだけです。それ以外の方式では、推論プロファイルID(例はus.anthropic.claude-sonnet-5)をモデル一覧に書く必要があります。

導入の流れ

実際の配布は、どのプロバイダーでも次の順に進みます。

手順

設定を配るまでの4段階

1. 1

   プロバイダー側でClaudeを使える状態にする

   BedrockならModel access、Foundryならリソースの作成とモデルのデプロイ(デプロイ名を控える)が先です。

2. 2

   認証方式を決めて準備する

   IAM Identity Centerの権限セットやEntra IDのアプリ登録など、方式ごとの準備がここに入ります。

3. 3

   アプリの設定画面で入力する

   Developer → Configure Third-Party Inference… を開きます。Connectionの「Inference provider」でプロバイダーを選び、認証情報とモデル一覧を入れます。

4. 4

   Exportして配る

   macOSでは.mobileconfig、Windowsでは.regが書き出されます。これをMDMから端末へ配ります。

外向き通信をどこまで絞れるか

Google CloudかAmazon Bedrockなら、推論は自社のクラウドテナントの中で完結し、コンプライアンスの境界もそのテナントとリージョンが与えるものに収まります。ただしアプリ自体は、Anthropicが運用するホストに接続する場面を残しています。

• VMワークスペースのバンドルとClaude CLIバイナリのダウンロード(常に必須)
• クラッシュレポート
• プロダクト分析
• 非必須サービス(コネクタのファビコン、アーティファクトのプレビュー、MCP Appsのウィジェット)
• 自動更新
• モデル選択画面のラベルに使う公開モデルカタログの取得

必須のダウンロードを除く5つは、管理設定で個別に無効にできます。すべて無効にすると、残るAnthropic向けの通信は、セッション開始時にdownloads.claude.aiからVMバンドルとCLIバイナリを取る経路だけになります。オフライン版のインストーラーを使えば、この経路も不要になり、必要な外向き通信は推論プロバイダーだけになります。

CodeセッションでWeb Fetchを使わせる場合は、skipWebFetchPreflightをtrueにするか、disabledBuiltinToolsにWebFetchを加えます。設定しないと、Claude CodeのCodeセッションは、取得したドメインごとにapi.anthropic.comへ問い合わせます。ここまで絞った後のコンプライアンス姿勢は、選んだ推論プロバイダーの条件で決まります。

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

PHI(医療情報)を扱う可能性があるなら、HIPAA対応の可否がプロバイダー選びの分岐点です。

Google CloudとBedrockでは、Anthropicがユーザーの上げたPHIに触れません。データが渡るのはクラウドプロバイダーと、自分で設定したリモートMCPサーバーだけだからです。HIPAA対応の構成にするには、クラウドプロバイダーとBAA(Business Associate Agreement)を結び、接続するMCPサーバーがHIPAAに対応しているかも先に確かめます。テレメトリを止める必要はありません。Anthropicへ届くテレメトリは、編集済みのクラッシュレポートと集計済みの利用状況メトリクスだけで、ユーザーデータ・プロンプト・生成結果を含まないためです。

Foundryには、HIPAA対応の構成がありません。ホスティング形態を問わず、Anthropicがモデルを運用して会話データを処理するためです。AnthropicがAPIで提供するHIPAA対応の枠組み(署名済みBAAとPHI処理の保護策)も、Foundry経由を対象に含めていません。PHIを扱うなら、Google CloudかBedrockを選んで、そのクラウドとBAAを結ぶ流れになります。

「Vertex AI」は「Google Cloud's Agent Platform」に呼び名が変わった

Claude Desktop on 3PのGoogle Cloud向けページは、このプロバイダーを「Google Cloud's Agent Platform(formerly Vertex AI)」と呼んでいます。社内資料や検索では旧称のVertexがまだ広く通じますが、設定キー名にはinferenceVertex*の名前が残っています。ドキュメントを探すときは新旧どちらの名前でも当たるよう、両方で検索すると見落としが減ります。

選ぶ軸は3つに絞れる

ここまでの違いを踏まえると、選択の軸は「PHIを扱うか」「レジデンシーの単位をどこに置くか」「ユーザーを監査ログで個別に追えるか」です。

PHIを扱うなら、HIPAA対応の構成があるGoogle CloudかAmazon Bedrockに限られます。PHIを扱わず、契約上の問題が米国内に限った話であれば、Foundryも選べます。ただしHosted on Azureを選ぶのか、Hosted on Anthropicを選ぶのかで、プロンプトがAzureの外に出るかどうかが変わります。日本やEUなど米国以外のリージョンに閉じたい要件は、公式に挙がっているFoundryのデプロイタイプでは満たせません。

標準のClaude Desktop + Cowork(TeamまたはEnterprise)ほど新機能が早く届かない点は、公式も認めています。データレジデンシーという1つの要件のために、更新の速さを手放す選択になります。

VS Codeなどエディタ側でサードパーティの推論プロバイダーを使う設定は、Claude Code拡張機能でのサードパーティプロバイダー設定が別立てで扱っています。RBACや監査ログを含む運用設計はClaude CoworkのRBAC運用を参照してください。