こんにちは、せーのです。今日は先日 Anthropic から発表された The full Claude Desktop experience on AWS, Google Cloud, and Microsoft Foundry の話題を取り上げ、Amazon Bedrock と Google Cloud Vertex AI 経由で Claude Desktop を動かしてみましたので、共有します。

今回のニュースで大きいのは、Chat タブが Bedrock / Vertex AI / Foundry 経由でも使えるようになったことです。これまで 3rd-party（以下 3P）モードでは Cowork と Code のみ対応で、Chat は Anthropic アカウント直結のときだけでした。

ですが、私が今回もっと気になっていたのは別のところです。

「Claude Enterprise 契約なしで Bedrock や Vertex AI 経由にすると、ガバナンスはどこまで自前で組めるのか」

という点です。具体的には、SSO・外部 IdP 連携・権限制御・監査ログ・機能単位の ON/OFF です。

記事の流れとしては、まず Bedrock / Vertex AI で Chat まで動かす手順 を実機で確認し、そのあと AWS / GCP エコシステムでどこまでガバナンスできるか を整理します。

なお、公式ブログ では Chat 追加とあわせて Deployment controls（デプロイ制御） も強調されています。IT チーム向けに per-user SSO・MDM ポリシーテンプレート・オフラインインストーラなどが揃った、という位置づけです。後半でこの部分を実機の観点から整理します。

Claude Desktop on 3P とは（おさらい）

出典は Claude Desktop on 3P: Overview です。

Claude Desktop on 3P は、推論を Anthropic API ではなく 自社のクラウドアカウント（Bedrock / Vertex AI / Foundry 等） に向けるモードです。ポイントは次のとおりです。

• local device identity のみ。Anthropic アカウントは不要
• 設定は MDM（Jamf / Intune / Group Policy 等）から push する managed config が主な統制手段
• in-app 管理コンソール・ユーザー管理 UI・分析ダッシュボード・RBAC はない（Team / Enterprise プラン専用）

つまり、Enterprise の「Anthropic 管理コンソールで一元管理」は手に入りません。代わりに 各クラウドベンダーの IAM・IdP・監査ログ・MDM で自前構成するモデルです。

違いを整理すると、Enterprise は Anthropic 側の管理 UI と SCIM / Compliance API が中心、3P はクラウド側の IAM と MDM が中心、というイメージです。

Bedrock / Vertex AI で Chat まで使えるようになった

3P 設定 UI の開き方

Claude Desktop の 3P 設定は、Developer Mode を有効にすると GUI から触れます。

1. Help → Troubleshooting → Enable Developer Mode
2. メニューバーに Developer が出る
3. Developer → 「サードパーティ推論を設定…」

ここが今回の最大の発見のひとつで、既存の Anthropic セッションがあっても、再起動やサインアウトなしで 3P setup window を開けます。custom3p-setup.log に Opening 3P setup window at app://localhost/setup-desktop-3p と記録されることも確認しました。

3P setup window の「接続」ドロップダウンには、Gateway / Claude API / Bedrock / Bedrock Mantle / Vertex AI / Foundry が並びます。

最重要: Chat タブ（ベータ）の有効化

Chat タブを出すのに、最初は chatTabEnabled を plist に書いても表示されず、少し困りました。

defaults write com.anthropic.claudefordesktop chatTabEnabled -bool true

そこで色々調べたところ、3P setup window の「ワークスペースの制限」にある「チャット（ベータ）」トグルがデフォルト OFF で、こちらが GUI 側の設定を上書きしている、ということがわかりました。

有効化手順は次のとおりです。

1. Developer → 「サードパーティ推論を設定…」
2. 左サイドバー → 「ワークスペースの制限」
3. 「許可されたサーフェス」→ 「チャット（ベータ）」を ON
4. 右上の 「変更を適用」 をクリック

chatTabEnabled plist キーだけでは不十分で、GUI で明示的に ON にする必要がある点は、MDM 配布時にも chatTabEnabled: true を managed config に含めるべき、というブログのポイントになります。

Amazon Bedrock 接続（実機）

Bedrock を選ぶと、認証情報の種類として複数の経路が選べます。

出典: Claude Desktop on 3P: Amazon Bedrock

今回の検証では、手元の環境に合わせて Named Profile（検証用 AWS プロファイル）で接続しました。AWS リージョンは us-east-1、モデルは us.anthropic.claude-sonnet-4-6 です。

設定を適用すると再起動ダイアログが出ます。

再起動後、左下に 「Bedrock」 と表示され、Cowork タブでも Bedrock 経由の推論が動きました。

なお、GUI の代わりに plist でプロバイダーを切り替える場合は inferenceProvider キーが使えます。

defaults write com.anthropic.claudefordesktop inferenceProvider -string bedrock

このキーが Bedrock / Vertex AI など 3P プロバイダーの切り替えスイッチになっているようです。

そして「チャット（ベータ）」を ON にしたあと、Chat タブが Cowork / Code と並んで表示され、Bedrock 経由で会話できることを確認しました。

きちんと Bedrock 経由の Chat が動いています。

CLI でも同じプロファイルで InvokeModel が成功することを先に確認しており、cross-region inference で実処理が us-east-2 側に振られる挙動も見えました。これは Bedrock の inference profile の仕様どおりだと推測できます。

Google Cloud Vertex AI 接続（実機）

Vertex AI 側は、まず Model Garden で Claude モデルをサブスクライブする必要があります。

GCP コンソール → Vertex AI → Model Garden → Anthropic → Claude モデルを選択
→ 「利用規約に同意してサブスクライブ」

3P setup window では Vertex AI を選び、次の値で接続しました。

注意: Vertex AI では「接続テスト」ボタンが機能しません。

クリックすると次のエラーが出ます。

Vertex auth cannot be probed from the main process.

Electron アプリのメインプロセスから ADC（Application Default Credentials）に直接アクセスできないためです。UI 上は接続テストがあるのに、Vertex では 「変更を適用」→ 再起動 → 実際に Chat で試す しかありません。少しモヤッとする UI ですね。

適用後は左下に 「Vertex AI」、Chat タブで応答が返り、「思考プロセス」（Extended Thinking） も表示されました。

違いを整理すると、Bedrock は Named Profile や IAM IC SSO で接続テスト相当の確認がしやすく、Vertex AI は接続テストが使えず適用後の実動確認が必須、というイメージです。

ここまでで、Bedrock / Vertex AI いずれも Chat を含む Desktop が 3P 経由で動く ことは確認できました。次は本記事の本題である、AWS / GCP エコシステムでどこまでガバナンスできるか に移ります。

AWS・GCP エコシステムで細かくガバナンスできる

公式ブログが言う「Deployment controls」とは

The full Claude Desktop experience on AWS, Google Cloud, and Microsoft Foundry（2026-06-22 公開）では、Chat 追加に加えて 組織展開のための制御機能 が前面に出ています。要点を整理すると次の 5 つです。

公式が強調しているのは、「Anthropic Enterprise の管理コンソール」ではなく 既存の IdP・MDM・クラウド IAM をそのまま使って組織展開できる 点です。推論は自社クラウド、会話履歴はローカル、データコネクタの到達先と Anthropic へのテレメトリも管理者が制御する、というモデルです。

Enterprise vs Bedrock / Vertex の比較

一言で言うと、Anthropic の管理コンソールで全部まとめて統制する方式（Enterprise）ではないが、MDM でポリシーを端末に強制配布し、SSO で本人確認し、AWS / GCP の監査ログで利用を追う、という形なら組織展開できる、ということです。

2026-06 アップデートで、その部品（ポリシーテンプレートの export、Chat / Cowork / Code ごとの policy key、per-user SSO）が公式に揃いました。なお「誰が API を叩いたか」の per-user 記録は、CloudTrail / Cloud Audit Logs 側のほうがむしろ強い、という印象でした。

per-user SSO と「端末に認証情報を置かない」設計

公式ブログの 「Sign in like any work app」 は、Bearer Token のような共有キーを端末に配らず、ユーザーごとの SSO サインイン で短期認証情報を取得する設計を推しています。

Bedrock の in-app SSO フローは次のとおりです（出典: Claude Desktop on 3P: Amazon Bedrock）。

ユーザー起動
  → OIDC device-authorization（inferenceBedrockSsoStartUrl）
  → ブラウザで AWS access portal → Entra ID / Okta 等で認証
  → 短期 IAM 認証情報を Keychain / DPAPI に暗号化保存
  → 各ターン前に token 交換 → Bedrock:InvokeModel
  → CloudTrail に per-user identity が記録

Bearer Token 経路は PoC 専用で、CloudTrail 上は共有キーの identity になり個人特定ができません。本番展開では公式の意図どおり SSO 系を選ぶべきです。

本番向けアーキテクチャ（Bedrock + IAM Identity Center）

Enterprise 契約を避けつつ組織展開するなら、おおむね次の流れになります。

外部 IdP（Entra ID / Okta）
  ↓ SAML + SCIM
AWS アカウント内
  ├─ IAM Identity Center（ユーザー/グループ）
  ├─ 権限セット → AWSReservedSSO_* ロール（bedrock:InvokeModel*）
  ├─ Amazon Bedrock
  │    ├─ ① パブリックエンドポイント（今回の検証）
  │    └─ ② PrivateLink（オプション・端末から VPC 到達 or プロキシが別途必要）
  └─ CloudTrail / Bedrock invocation logging（S3）
       ↑
Claude Desktop（ユーザー端末）— in-app OAuth で SSO サインイン
       ↑ MDM managed config push

構成図をまとめました。IAM Identity Center と権限セットは AWS アカウント内 のリソースとして描いています。

① パブリックエンドポイント経路（今回の検証）

② VPC Endpoint 経路（閉域網向け・オプション）

Bedrock への通信経路（パブリック vs PrivateLink）

Claude Desktop は ユーザー端末（VPC の外）で動くため、デフォルトでは パブリックの Bedrock Runtime エンドポイント（bedrock-runtime.{region}.amazonaws.com）へインターネット経由で InvokeModel します。今回の検証もこの経路です。この構成だけを見ると、VPC 内に推論リクエストを送るアプリケーションは存在しません（Bedrock も IAM Identity Center も AWS のマネージドサービスであり、お客様 VPC 内の EC2 等ではありません）。

Interface VPC Endpoint（PrivateLink）は、AWS 公式に「VPC 内に配置したリソースが AWS サービスへプライベート接続する」ための仕組みです（出典: Create a VPC endpoint — Prerequisites — Deploy the resources that will access the AWS service in your VPC）。VPCE の ENI には VPC サブネットのプライベート IP が割り当てられるため、インターネット上の端末から VPCE へ直接到達することはできません。

そのため、② を使う場合は VPCE の作成に加え、次のいずれかが別途必要です。

• 端末 → VPC へのネットワーク経路（Client VPN / Site-to-Site VPN / Direct Connect 等）を用意し、端末の inferenceBedrockBaseUrl を VPCE の DNS 名に向ける
• VPC 内に LLM プロキシ等を配置し、プロキシが VPCE 経由で Bedrock を呼び出す。端末の inferenceBedrockBaseUrl はプロキシの URL を向ける（Anthropic も inferenceBedrockBaseUrl を「VPC endpoints or gateway proxies」向けと記載 — 出典: Configuration keys）

いずれにせよ 必須ではなく、プライベート接続が必要な環境向けのオプション です。

どちらを選ぶか

Anthropic の managed config では、inferenceBedrockBaseUrl に VPC Endpoint のホスト名（または gateway proxy の URL）を指定すると、Claude Desktop が Bedrock Runtime への接続先を上書きできます（出典: Configuration keys — inferenceBedrockBaseUrl — For VPC endpoints or gateway proxies）。つまりアプリ設定としては「パブリック URL か VPCE URL か」を選べます。ただし VPCE を選んでも、端末からその URL に届くネットワークが別途必要 です（前節のとおり）。

① を選ぶ典型例

• 在宅・出先から Claude Desktop を使うユーザーが多い
• Bedrock Runtime への HTTPS をインターネット経由で許容できる（TLS + IAM 認証で保護される）
• VPCE や VPN の運用コストをかけたくない

② を選ぶ典型例

• 社内ポリシーで AWS API 通信を閉域網に閉じたい（推論リクエスト/レスポンスがパブリック IP を経由しない）
• すでに Client VPN / Direct Connect で端末と VPC が接続されている
• VPC 内に LLM プロキシを置き、端末はプロキシ URL だけ向ける構成を取れる

② のイメージは次のとおりです。

端末 ── VPN / Direct Connect 等（閉域網） ──► VPC ── VPCE（PrivateLink） ──► Bedrock

切り分けの注意: inferenceBedrockSso* による IAM Identity Center サインインは、推論経路とは別です。oidc.{region}.amazonaws.com や *.awsapps.com へのアクセスは、② を選んでも 別途 egress が必要 になります。② が効くのは主に Bedrock Runtime への InvokeModel 通信 です。推論だけ PrivateLink に載せ、認証はパブリック経由、という構成もあり得ます。

重要な制約: inferenceBedrockSso*（アプリ内 IAM IC SSO）が要求する inferenceBedrockSsoRoleName は IAM Identity Center の権限セット名 です。権限セットは organization インスタンス でしか作れません（出典: Create a permission set、Account instances）。

ここで紛らわしいのが、「AWS Organizations を使っているか」と「IAM IC のインスタンス種別」は別の話だという点です。

つまり「Organizations を使っていれば OK」というより、Organizations の管理アカウント上の organization インスタンス が前提です。Organizations 未利用でも単一アカウントに IAM IC は立てられますが、それは account インスタンスになり、ユーザー/グループ管理やアプリ SSO はできても権限セットは使えません。今回の検証環境でも、account インスタンスで ListPermissionSets を叩くと次のエラーになりました。

ValidationException: This operation is not supported for account instances of IAM Identity Center.

Organizations を使っていない単一アカウント で Bedrock 3P を動かす場合は、inferenceBedrockSso* ではなく named profile や credential helper など別経路を選ぶ必要があります。Organizations をこれから導入して管理アカウントで organization インスタンスを立てる、というのが本番 SSO 連携の王道です。

なお、3P setup window の SSO「接続テスト」は「検証できない」と表示されますが、公式ドキュメントでも実際のサインインでは問題ない旨が説明されています。今回の実機検証は named profile で代替し、Bedrock 推論と per-user 監査の取得までは確認しました。

MDM ポリシーテンプレートとサーフェス別の段階展開

公式ブログの 「Deploy like any app」 と 「Start small, expand」 は、3P setup window で設定した内容を ポリシーテンプレートとしてエクスポートし、Intune / Jamf / GPO 経由で push する 流れを指します。macOS では .mobileconfig、Windows では .reg として取得できます（出典: Configuration reference）。

GUI で触れる設定と、本番ガバナンスは別物

ここが重要で、Developer Mode の「ワークスペースの制限」トグルだけでは、組織ガバナンスとしては不十分 です。今回の実機検証でも、GUI 上で ON/OFF できる一方、ユーザー自身が「変更を適用」で plist を書き換えられることがわかりました。

つまり今回実機で触った「ワークスペースの制限」は、chatTabEnabled 等の policy key が GUI 上でどう効くかを確認するための UI であり、Enterprise の RBAC 管理コンソールに相当するものではありません。本番では setup UI で設定を試したあと エクスポート → MDM 配布 するのが公式の想定ルートです。

認証情報から policy key が自動で切り替わるわけではない

もう一点、「SSO でサインインしたユーザー属性に応じて、Desktop 側の policy key が自動選択される」モデルではない 点に注意が必要です。公式ドキュメント（Claude Desktop on 3P: Overview、Amazon Bedrock）の整理は次のとおりです。

1 managed config（= 1 つの MDM プロファイル）= 1 AWS アカウント + 1 権限セット

同じ managed config が入った端末では、全ユーザーが同じ chatTabEnabled / coworkTabEnabled 設定と、同じ inferenceBedrockSsoRoleName（権限セット）にサインインする 、という前提です。

グループごとに「営業は Chat のみ」「エンジニアは Code も」という 異なる Desktop ポリシー を与えたい場合は、Claude Desktop がログイン時に IdP クレームを読んで切り替えるのではなく、MDM 側でグループ別に別ポリシーテンプレートを配る 必要があります。

Entra ID グループ「営業」  → Intune が Profile A（chatTabEnabled=true, code=false）を配布
Entra ID グループ「開発」  → Intune が Profile B（全サーフェス ON + 別権限セット）を配布
         ↓ SCIM                              ↓
    IAM IC グループ                    IAM IC 権限セット A / B
         ↓                                    ↓
    各ユーザーが SSO サインイン → CloudTrail に per-user で記録

クラウド IAM 側の per-user 差分（例: 開発者だけ Opus モデル可）は、IAM IC で グループごとに別権限セットを割り当て、それに対応する 別 managed config を MDM で配る、という二段構えになります。SSO は「誰か」を特定して監査する役割が主で、Desktop の機能 ON/OFF をログイン時に動的に変えるスイッチではない、というイメージです。

サーフェス別 policy key 一覧

「ワークスペースの制限」のトグルは、以下の managed config キーの GUI 版です（export 後は MDM から強制）。

ツール単位の制御（hard-deny は全タブに横断適用、と公式ブログが明記）

IAM 権限セット側（AWS）では、bedrock:InvokeModel と bedrock:InvokeModelWithResponseStream が最小権限です。Resource ARN でモデルを絞ることも可能です。

"Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-*"

1 managed config = 1 AWS アカウント + 1 権限セット の制約は変わりません。グループごとに異なる Bedrock 権限を与えたい場合は、MDM で 別ポリシーテンプレート（別プロファイル） を配布します。公式ブログの「Start small, expand」と組み合わせると、例えば「営業向けプロファイル = Chat + Cowork のみ」「エンジニア向け = 全サーフェス + Code」という配布が現実的です。

Enterprise は Anthropic 管理コンソールの RBAC で ログイン後にユーザー属性に応じた機能制御 ができます。3P では MDM プロファイル配布 + クラウド IAM の組み合わせになり、グループ差分は IdP → MDM の targeting で間接的に作る、というイメージです。

ロールアウト前検証（Know it works before anyone sees it）

公式ブログは、展開前に コネクタ・モデル・接続を検証 できることを強調しています。Bedrock では 3P setup window の接続テストが使えますが、Vertex AI では前述のとおり 実動確認が必須 です。

また model guard により、設定ミスがあっても Claude モデル以外へのルーティングを防ぐ、と公式は説明しています（GovCloud 環境も含む）。今回の検証環境では未確認ですが、本番ロールアウト前のチェック項目として押さえておく価値があります。

監査ログの実機確認

AWS: CloudTrail と Bedrock invocation logging

Named Profile 経由でも、CloudTrail の InvokeModel イベントに per-user の assumed-role identity が記録されることを確認しました。

$ aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=InvokeModel \
  --region us-east-1 \
  --query 'Events[0].Username'
"cm-seino.example"

ARN には assumed-role/cm-seino.example/cm-seino.example の形式でユーザーが残ります。Bearer Token 経路だと共有キーの identity になり個人特定が難しいため、本番は SSO か named profile 系を選ぶべきです。

Bedrock model invocation logging を S3 に有効化すると、プロンプト内容・トークン数まで記録できます。実機ログの抜粋です（アカウント ID はマスク）。

{
  "operation": "InvokeModel",
  "identity": {
    "arn": "arn:aws:sts::123456789012:assumed-role/cm-seino.example/cm-seino.example"
  },
  "input": { "inputTokenCount": 19 },
  "output": { "outputTokenCount": 20 }
}

CloudTrail のデータイベント（Bedrock モデル呼び出し、$0.10/100K events）はオプションです。管理イベントだけでも per-user 監査は取れました。

GCP: Cloud Audit Logs

Vertex AI 利用前に、プロジェクトの Data Access ログ（aiplatform.googleapis.com）を有効化しました。

RawPredict に Google アカウントのメールアドレス が principal として記録されることを確認しました。Workforce Identity Federation なしの Google 直接認証でも per-user 属性は取れます。

global リージョン経由の場合、ログパスは ...bal:anthropic:claude-sonnet-4-5@20250929 のように global が略記されます。Claude Desktop 経由のログは curl 直接呼び出しより 4〜5 分遅延 することがありました。

補足: Platform on AWS との違い

Claude Platform on AWS は Bedrock とは別サービス です。platform.claude.com を SigV4 / Bearer + AssumeConsole フェデレーションで使う 2026-05 GA の機能で、認証基盤が異なります。Bedrock 3P は bedrock:InvokeModel 経由の Desktop ローカル推論、Platform on AWS は Anthropic 運用基盤の AWS 連携、と切り分けてください。

まとめ

Amazon Bedrock と Vertex AI 経由で Claude Desktop を使ってみて感じたのは、次の 4 点です。

1. Chat を含むフル Desktop が 3P でも使える — ただし「チャット（ベータ）」トグルを GUI で明示的に ON にする必要がある
2. 2026-06 アップデートで Deployment controls が前面化 — per-user SSO、MDM ポリシーテンプレート、サーフェス別 policy key による段階展開が公式に整理された
3. ガバナンスは各クラウドの IAM・IdP・MDM で自前構築 — Enterprise 管理コンソールの代わりに、権限セット・ポリシーテンプレート・監査ログで細かく制御できる
4. per-user 監査はクラウド監査ログで強く出せる — CloudTrail / Bedrock invocation logging / Cloud Audit Logs で個人属性を追える

そして、、、

Claude Desktop on 3P は Anthropic Enterprise の管理コンソールの代わりにはならない 一方で、既存の AWS / GCP の IdP・IAM・MDM・監査基盤をそのまま活かして組織展開できる モデルだと感じました。Bedrock 推論の通信経路はデフォルトでパブリックですが、閉域網要件がある場合は VPCE + VPN 等で PrivateLink に載せる選択肢もあります（認証用の IAM IC egress は別途必要）。

Enterprise を選ぶべきケース: Anthropic 管理コンソールでの SCIM / RBAC / Compliance API 一元管理が最優先で、in-app UI が欲しいとき。

3P（Bedrock / Vertex）を選ぶべきケース: 推論を自社クラウドアカウントに閉じたい、既存の AWS / GCP の IdP・IAM・監査基盤をそのまま使いたい、Anthropic への seat 課金を避けたいとき。

もっとスマートな IAM IC 構成や MDM 配布の方法を御存知の方がいれば、ぜひツイッターででも教えて下さい。

参考資料

• The full Claude Desktop experience on AWS, Google Cloud, and Microsoft Foundry
• Claude Desktop on 3P: Overview
• Claude Desktop on 3P: Amazon Bedrock
• Claude Desktop on 3P: Vertex AI
• Claude Desktop on 3P: Configuration reference
• Bedrock Interface VPC Endpoint（PrivateLink）
• Bedrock model invocation logging
• IAM Identity Center: 外部 IdP 連携（SAML + SCIM）