Amazon BedrockでClaude Coworkを動かす方法：社内リサーチ向け導入ガイド（2026）

まず結論

可能だ。2026-04-21 時点で、チームは Anthropic ホストの推論ではなく Amazon Bedrock 経由で Claude Cowork を動かせる。実務上の価値ははっきりしている。ナレッジワーカーは Cowork のデスクトップアプリで文書分析、多段リサーチ、ファイル作業、MCP 接続、定期タスクを使いながら、モデル推論、課金、Bedrock API ログは既存の AWS 環境に残せる。AWS は 2026-04-21 にこの構成を発表し、2026-04-22 に確認した Anthropic の Cowork on 3P overview でも、Bedrock deployment では会話内容が Anthropic 基盤に入らないと説明されている。

2026-04-22 時点で、Anthropic は調達とコンプライアンス審査で重要になる 2 つの制約も明記している。1 つ目は、managed configuration で明示的に無効化しない限り、アプリは運用テレメトリをデフォルトで送ること。2 つ目は、Cowork activity が Audit Logs、Compliance API、Data Exports に記録されないことだ。つまり OpenTelemetry は監視には使えるが、規制対象ワークロードで必要な formal audit logging の代替にはならない。Anthropic はその境界を telemetry and egress docs と Cowork monitoring guidance で明確に書いている。

この構成が向いているのは、すでに AWS を中核に使っていて、より厳密な data residency や procurement control を求めつつ、seat 契約の別製品を増やさずに社内リサーチ向けのデスクトップ workflow を欲しい企業だ。逆に、Claude Enterprise のフル機能面を期待しているなら向かない。Anthropic の 3P feature matrix を 2026-04-22 に確認した限り、Chat tab、Computer Use、Voice mode、Claude in Chrome、Anthropic 1P connectors、project/plugin sharing はまだ欠けている。Anthropic の public plugin marketplace も使えない。ただし、組織配布の plugins は引き続き利用できる。

2026-04-21 に何が変わったのか

AWS は 2026-04-21 に Claude Cowork in Amazon Bedrock の公式発表記事 を公開した。重要なのは、Bedrock に Claude models がなかったわけでも、Anthropic に Cowork がなかったわけでもないことだ。欠けていたのは、Cowork の体験は欲しいが、推論と課金は Anthropic の一方スタックに戻したくない企業向けの中間レイヤーだった。

今回のローンチでその空白が埋まった。AWS はこれを、Claude を開発者向け workflow からより広い knowledge work へ拡張しつつ、同じ AWS control plane 内に留める選択肢として位置づけている。Anthropic の third-party Cowork docs では、同じ deployment mode を Cowork on 3P と呼んでおり、model inference は設定した provider に流れ、conversation history はユーザー端末に残る。

IT バイヤーや internal tools lead にとって、これは単なる AI ニュースではない。deployment choice そのものが変わるからだ。これまで一般的な選択肢は次の 2 つだった。

• Claude Enterprise を使い、Anthropic ホスト推論を受け入れる
• Bedrock 上に独自の社内アプリを構築して社員に提供する

今は 3 つ目の道がある。パッケージ済みのデスクトップ workflow を保ったまま、推論だけを Bedrock に流せる。

どんなときにこの構成が向くか

次の条件の多くに当てはまるなら、Claude Cowork in Amazon Bedrock は有力な選択肢になる。

• すでに AWS IAM、CloudTrail、network controls が整っている
• procurement が別の seat 契約より usage-based cloud billing を好む
• AWS 内で region selection や geographic cross-Region controls が必要
• ユーザーの主なニーズが document analysis、research、synthesis、file-based workflows である
• Jamf、Intune、Group Policy、または他の MDM による device management が普通に回っている

逆に、実際のニーズが標準的な SaaS chatbot rollout に近いなら見送った方がよい。

• Web ベースの user management console が欲しい
• Chat tab、Claude in Chrome、Voice mode、Computer Use が必要
• デスクトップ設定を MDM や OS policy で管理したくない
• identity、logging、network policy の中心が AWS ではない

判断表

展開前に確認すべきもの

始める前に、次の prerequisites を確認する。

見落としやすい細部として、Anthropic の現行 configuration reference では managed values が OS preference store 上で string として保存される。つまり booleans は "true" / "false" になり、inferenceModels や coworkEgressAllowedHosts のような array-typed keys は、native plist array や registry array ではなく、文字列化された JSON array で渡す必要がある。

Step 1: Bedrock の認証方式を選ぶ

Anthropic の現行 configuration reference は、Bedrock 向けに 2 つの一般的な auth path と、より厳格な環境向けの credential-helper path を案内している。

AWS は開発者向け導入を簡単にする新しい認証手段として Bedrock API keys も公開している。公式記事によれば、short-term keys は最大 12 時間、long-term keys は 1 日から無期限まで設定できる。とはいえ、enterprise rollout で bearer token が自動的に最善とは限らない。会社がすでに SSO と named profiles で AWS access を統制しているなら、profile-based auth の方が audit と rotation はしやすいことが多い。

静的 token を完全に禁止している環境なら、Anthropic は inferenceCredentialHelper もサポートしており、アプリは bearer token をローカル保存する代わりに session 開始時に short-lived credential を取得できる。

Step 2: まず 1 台のテスト機で設定を固める

Anthropic の現行 installation guide は、evaluate -> egress allow -> validated config export -> broad rollout という staged rollout を推奨している。

最も速くて安全な手順は次の通り。

1. テスト機に claude.com/download から Claude Desktop をインストールする。
2. Help -> Troubleshooting -> Enable Developer Mode を開く。
3. Developer -> Configure third-party inference を開く。
4. inference provider を bedrock に設定する。
5. AWS Region、Bedrock profile または bearer token、さらに picker に出す Bedrock model / inference-profile ID を少なくとも 1 つ入力する。
6. 検証済みの .mobileconfig を macOS 用に、.reg を Windows 用に export する。

Anthropic の docs によれば、この設定画面は選択した構成に必要な egress hosts をそのまま表示できる。firewall allowlist は記憶で推測せず、その出力を使うべきだ。

Step 3: 本当に重要なキーを押さえる

最初の pilot ではすべてのキーは要らない。ただし、本当に必要な小セットは外してはいけない。以下の例は Anthropic の configuration reference にある managed-preference format に沿っており、booleans と array-typed values を strings で書く前提になっている。

{
  "enterpriseConfig": {
    "inferenceProvider": "bedrock",
    "inferenceBedrockRegion": "us-west-2",
    "inferenceBedrockProfile": "company-bedrock",
    "inferenceModels": "[\"<your-bedrock-inference-profile-id>\"]",
    "deploymentOrganizationUuid": "11111111-2222-3333-4444-555555555555",
    "disableDeploymentModeChooser": "true"
  }
}

各キーの意味はこうだ。

• inferenceProvider: third-party inference mode を有効にし、Claude Desktop を Bedrock に向ける
• inferenceBedrockRegion: 推論に使う AWS Region を指定する
• inferenceBedrockProfile: 端末上に存在する AWS named profile を使う
• inferenceModels: Bedrock で必須の model list。ユーザーに見せたい exact inference-profile ID を入れる
• deploymentOrganizationUuid: support と telemetry attribution のために deployment を識別する
• disableDeploymentModeChooser: 初回起動時のモード選択を出さず、managed deployment mode に直接入れる

1 台の unmanaged machine で試すだけなら、Anthropic の docs は macOS での local config の場所を ~/Library/Application Support/Claude-3p/claude_desktop_config.json とし、その enterpriseConfig キー配下に設定を書くとしている。本番 rollout では managed profile が優先され、local values は無視される。

Step 4: AWS 側もプロダクトの約束に合わせる

プロダクトの説明が成立するのは、AWS 側のセットアップも実際に噛み合っている場合だけだ。

AWS と Anthropic は、次の enterprise controls を共通して指している。

• 推論は設定した AWS Region または inference profile で Bedrock 上に流れる
• CloudTrail は Bedrock API calls を記録し、cross-Region requests も source Region 側で見える
• otlpEndpoint を設定すれば、OpenTelemetry は prompts、tool calls、file access、token counts、errors を自前 collector へ送れる
• 必要なら VPC endpoints により public internet path を避けられる
• Bedrock には in-Region、geographic cross-Region、global cross-Region inference profiles がある

ただし、ここにも重要な compliance limit がある。Anthropic の telemetry docs と、2026-04-22 に確認した Cowork monitoring guidance は、Cowork activity が Audit Logs、Compliance API、Data Exports に記録されず、OpenTelemetry stream も compliance 目的の formal audit logging を置き換えないと明記している。regulated workloads で formal audit trails が必要なら、Bedrock logging は full compliance answer ではなく partial coverage と考えるべきだ。

ルーティングのトレードオフは、2026-04-22 に確認した AWS cross-Region inference docs と global cross-Region docs に明確に書かれている。

コンプライアンスが主要要件なら、まずは geography-constrained option を選び、global routing は policy review の後の最適化として扱う方が安全だ。

Step 5: ユーザーが使えない機能を先に知っておく

ここで内部 rollout が失敗することは多い。ユーザーは「Claude Desktop in AWS」と聞くと、claude.ai 上のすべてが使えると思いがちだ。しかし Anthropic の feature matrix を 2026-04-22 に確認した限り、それは違う。

だから rollout message は正直であるべきだ。これは research、document work、controlled tool use に強いデスクトップ workflow だが、Claude の first-party surfaces をそのまま置き換えるものではない。

最初の社内ユースケースとして良いもの

AWS の launch post は、product manager 向けの例を出している。顧客ミーティングメモと requirements をアップロードし、Claude を documentation と web search に MCP 経由で接続し、その上で grounded な product brief を作らせる、というものだ。

これは良い pilot だ。入力が明確で、出力をレビューでき、acceptance criteria も作りやすいからだ。

次のような prompt から始められる。

You are helping prepare an internal product brief.

Inputs in this workspace:
- customer interview notes
- current project requirements
- latest architecture constraints

Task:
1. Extract the repeated customer requests.
2. Flag conflicts between requests and current requirements.
3. Draft a one-page product brief with risks, open questions, and a recommended scope.
4. Cite which uploaded file supports each major recommendation.

Return format:
- Problem statement
- Recommended scope
- Risks and constraints
- Open questions
- Source mapping

これは「Cowork で何ができるか見せて」という曖昧な trial より良い。出力を評価しやすく、failure cases も見つけやすいからだ。

ありがちな rollout ミス

3P Cowork を pure SaaS の切り替えだと思う

そうではない。Anthropic 自身の docs が、MDM、policy keys、network egress を deployment の一部として扱っている。もしチームが desktop policy management を嫌うなら、その摩擦自体がコストになる。

feature gap を launch 後まで隠す

ユーザーが Chat、browser features、Computer Use を期待しているなら、current 3P deployment にはそれらがないと upfront に伝えるべきだ。

会社に合わない auth method を選ぶ

Bearer tokens は便利だが、自動的に最も governable とは限らない。AWS-heavy な環境なら、named profiles と既存 IAM patterns の方が長期的には扱いやすいことが多い。

workflow を絞らずに pilot する

曖昧な trial は曖昧な feedback しか生まない。まずは 1 つの document-heavy workflow、1 チーム、1 つの acceptance rubric から始めるべきだ。

FAQ

Claude Cowork in Amazon Bedrock は seat 単位で売られるのか？

少なくとも推論利用についてはそうではない。Anthropic の feature matrix と AWS の launch post は、Cowork on 3P を Anthropic の seat licensing ではなく、cloud provider 側の token-based consumption と説明している。一方で Anthropic の legal page は、Claude Desktop application 自体が Anthropic の commercial terms の対象であることも示している。

この構成で Anthropic は prompts や files を見るのか？

Anthropic の 3P docs を 2026-04-22 に確認した限り、Bedrock と Vertex deployments では prompts、responses、files、tool outputs は設定した inference endpoint に送られ、local machine に保存される。一方で crash reporting、analytics、auto-update については別経路があり、それらは設定または無効化できると文書化されている。

regulated workloads に向くか？

デフォルトでは向かない。Anthropic の Cowork docs を 2026-04-22 に確認した限り、activity は Audit Logs、Compliance API、Data Exports に入らず、OpenTelemetry export もそれらの control を置き換えない。

MDM なしでも rollout できるか？

単一マシンで local configuration を使った評価はできる。ただし Anthropic は、組織向け rollout の標準経路を MDM または OS policy として説明している。

自社で Bedrock アプリを作るより良いか？

ready-made の desktop workflow が今すぐ欲しいならこちらが良い。逆に、深い product customization、自前 UX、あるいは MCP と managed desktop policy より強い internal system integration が必要なら、自作の方が向く。

最終判断

Claude Cowork in Amazon Bedrock は、ただの AI パートナーシップ発表ではなく、実際に意味のある新しい deployment option だ。AWS 中心のチームにとって魅力は明快で、Cowork の desktop workflow を維持しながら、推論、課金、region control、Bedrock 側の API logging を AWS に移せる。

ただし、それが万人向けの default answer になるわけではない。device policy、network policy、user expectation management は自分たちで持つ必要があり、Anthropic telemetry、desktop update policy、そして formal な Cowork audit trail がない点も判断しなければならない。すでにそうした運用能力があるなら、これは non-developers により強い internal AI desktop を渡す実務的な方法になる。そうでなければ、Claude Enterprise の方がたいていシンプルだ。

検証メモ

検証日：2026-04-22。

• AWS の launch post で、2026-04-21 の発表日、Bedrock での位置づけ、サポートされる workflow 例、data-control claims、そして AWS consumption billing の記述を確認：https://aws.amazon.com/blogs/machine-learning/from-developer-desks-to-the-whole-organization-running-claude-cowork-in-amazon-bedrock/
• Anthropic の Cowork on 3P overview で、local conversation storage、Bedrock / Vertex data routing、security posture、適した deployment scenarios を確認：https://claude.com/docs/cowork/3p/overview
• Anthropic の installation guide で、staged rollout、Developer menu path、export formats、managed-vs-local configuration behavior を確認：https://claude.com/docs/cowork/3p/installation
• Anthropic の configuration reference で、必要な Bedrock keys、config precedence、array-string handling、model-list requirements、optional credential helper support、inferenceBedrockProfile と inferenceBedrockBearerToken の IAM permissions を確認：https://claude.com/docs/cowork/3p/configuration
• Anthropic の 3P feature matrix で、current missing features、token-based pricing、org-plugin marketplace behavior、on-device memory behavior を確認：https://claude.com/docs/cowork/3p/feature-matrix
• Anthropic の telemetry and egress page で、default telemetry categories、disablement controls、otlpEndpoint behavior を確認：https://claude.com/docs/cowork/3p/telemetry
• Anthropic の legal and compliance page で、commercial terms の適用範囲と current 3P compliance posture を確認：https://claude.com/docs/cowork/3p/legal
• Anthropic の OpenTelemetry と Team/Enterprise Cowork guidance で、current audit-log、Compliance API、Data Export limitations を確認：https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry と https://support.claude.com/en/articles/13455879-use-claude-cowork-on-team-and-enterprise-plans
• AWS Bedrock docs で、current cross-Region inference tradeoffs、source Region 側の CloudTrail behavior、global routing の約 10% pricing advantage を確認：https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html と https://docs.aws.amazon.com/bedrock/latest/userguide/global-cross-region-inference.html
• AWS の Bedrock API key announcement で、current short-term / long-term API key behavior を確認：https://aws.amazon.com/blogs/machine-learning/accelerate-ai-development-with-amazon-bedrock-api-keys/