「Claude の Cowork と Code、会社として使うならどちらが安全ですか」。最近、こうしたご相談が増えています。同じアプリの中に並んでいて、見た目も操作感もよく似ています。だからこそ「どっちを選べばいいのか」で迷ってしまう、というわけです。
ですが、先に結論をお伝えします。会社としての統制（＝ガバナンス）を左右するのは、「Cowork か Code か」という製品の違いではありません。効いてくるのは、次の2つです。
- どの契約プランで使っているか（無料・Pro・MAX・ビジネス・エンタープライズ）
- どうやってログインしているか（Claude公式のアカウントか、AWSの「Bedrock」経由か）
この記事では、耳慣れない言葉をひとつずつかみ砕きながら、この2軸で「何が変わるのか」を1枚の表に整理していきます。そして最後に、「自社ならどう選ぶべきか」というガバナンスの結論まで持っていきます。
先にひとつだけ、大事な注意です。この分野は、とにかく変化が速い。Claude関連の機能は数週間単位で更新され、名称も「できる・できない」もすぐに変わります。実際、本稿を準備しているあいだにも、デスクトップアプリを外部クラウドで動かす「Claude Desktop on 3P」が2026年7月9日に正式提供へと切り替わりました（執筆の途中で状況が動いた、ということです）。本稿の表や可否は、あくまで執筆時点（2026年7月13日）のものとお考えください。実際の導入判断では、記事末尾に挙げた公式ドキュメントで必ず最新の状態をご確認ください。
まずは登場人物を整理します
本題に入る前に、言葉の意味をそろえておきます。ここがあいまいなまま進むと、話がすれ違いやすいためです。
本稿では、弊社がAWSを利用している関係で、②の例としてAWSの「Bedrock」を取り上げて説明します。ただし、これはAWSに限った話ではありません。MicrosoftのAzure（Microsoft Foundry）やGoogle CloudのVertex AIでも、考え方はまったく同じです。いずれも「Claude公式アカウントではなく、クラウドが発行する鍵（APIキー）でログインする」点が共通していて、これから述べる統制の変化も共通します。読み替えていただいて差し支えありません。
契約プランで、「会社にできること」がここまで変わります
まずは①のClaude公式アカウントでログインする、ふつうの使い方から見ていきます。この場合、会社が使える統制の手段は契約プランで決まります。その手段は、次の6つです。表を見る前に、一つずつ意味を確認しておきましょう。
- 利用の制限：会社が「この機能は使わせない」「この部署だけ止める」と指定できるか。
- SSO（シングルサインオン）：社員が"会社のID"でログインする仕組み。私物アカウントの混在を防げます。
- SCIM（スキム）：「System for Cross-domain Identity Management」の略で、利用者アカウントを社内システムと外部サービスの間で自動的にやり取りするための規格です。入社・退社にあわせて利用者を自動で追加・削除できるため、退職者のアクセスが残る事故を防げます。
- 組織の操作の監査：「誰がいつログインし、誰が設定を変えたか」という組織の操作記録を取り出せる仕組み。Claudeでは「コンプライアンスAPI」という機能名で提供されています（APIは他社システムと連携するための"受け渡し口"のこと。ここでは深く気にせず、監査記録が取れる仕組みだと捉えてください）。
- 設定の強制：会社が決めたルール（使える接続先など）を、社員の端末に上書きできない形で配る仕組み。
- 画面操作（Computer Use）：AIが人の代わりに画面をクリック・入力・読み取りする機能。便利な反面、ログイン済みの社内システムを本人になりすまして操作できてしまうため、最も慎重に扱うべき機能です。
これらが契約プランごとにどうなるかを、1枚にまとめました。この表は Cowork でも Code でも同じです（土台が共通だからです）。
| 会社にできること | 無料 | Pro | MAX | ビジネス | エンタープライズ |
|---|---|---|---|---|---|
| そもそも使えるか | × | ○ | ○ | ○ | ○ |
| 利用を制限・停止できる | × | × | × | △ 全社一律のみ | ○ 部署別も可 |
| 会社IDでログイン（SSO） | × | × | × | ○ | ○ |
| 入退社で自動連携（SCIM） | × | × | × | × | ○ |
| 組織の操作を監査 | × | × | × | × | ○ |
| 設定を強制する | × | × | × | ○ | ○ |
| 画面操作（Computer Use） | × | ○ | ○ | × | × |
○＝できる／△＝限定的／×＝できない（またはその機能がない）。以降の表も同じ表記です。
この表から、見落としがちな点が2つ読み取れます。
意外な点①：画面操作は「個人プランだけ」にあります
いちばん危険度の高い画面操作（Computer Use）が使えるのは、Pro と MAX、つまり個人プランだけです。会社向けのビジネス・エンタープライズでは、そもそも提供されていません。
これは直感に反します。ふつうは「上位の企業向けプランほど、できることが多い」と考えますよね。ところが最も慎重に扱うべき機能は、会社の管理がいっさい効かない個人プランの側にだけある。社員が業務PCに私物アカウントでこっそり入れて、ログイン済みの社内システムをAIに操作させても、会社はそれに気づく手段がありません。
意外な点②：ビジネス契約は「エンタープライズの安い版」ではありません
ビジネス契約（Team）は、少人数で小さく始めるための入り口です。SCIMも組織の監査（コンプライアンスAPI）もありません。利用の制限も「全社まとめて」しかできず、「経理部だけ止める」といったような細かい調整ができません。
そのため「まずビジネスで試して、必要になったらエンタープライズへ」という移行には、見えないコストがかかります。統制の設計をやり直すことになるからです。会社として本当に管理・監査したいなら、実質的な出発点はエンタープライズです。
Bedrockを挟むと、話が根本から変わります
ここまでは①のClaude公式アカウントでログインする前提でした。では、提案書でおなじみの「Bedrock経由にする」を選ぶと、どうなるのでしょうか。
ここがこの記事のいちばん大事なところです。Claudeの公式ドキュメントには、こう書かれています。「どうやってログインするかが、使える機能を決める」。そして、Bedrock（やGoogle Cloud等）のAPIキーでログインする場合、これまでの契約プラン別の機能表は"適用されなくなる"、と。
つまり Bedrock で認証するというのは、Claude公式のアカウントでサインインしない、ということです。その瞬間、「エンタープライズだから使える」といった契約プランの概念そのものが外れます。「データは社外に出ない」という話（データの置き場所の話）だと思われがちですが、実際にはログインの仕方が変わる＝使える統制機能が変わるという話なのです。
そのため、エンタープライズ契約が用意している監査や設定の強制は、Bedrockで動かす使い方には効きません。「エンタープライズ契約を結んだまま、推論だけBedrockに流して、管理機能も両取りする」ことはできない、ということです。エンタープライズ契約が生きるのは、あくまでClaude公式アカウントでログインして使う場面です。Bedrockを選ぶなら、統制は自社とクラウド側の道具で組み直す——これが前提になります。
では、何が使えて、何が使えなくなるのか。ここでも新しい言葉が出てくるので、先に説明します。
- 端末管理（MDM）：会社が社員のPCに、決めた設定を配って強制する仕組み。Claude公式の管理画面を使わなくても、こちらは使えます。
- 動作ログの送出（OpenTelemetry）：アプリが「どんな操作をしたか」の記録を、外部のログ基盤へ送るための共通のしくみ。
- ログ基盤（SIEM）：各種のログを一箇所に集めて監視・分析する、セキュリティの土台となる仕組み。
| 統制のしくみ | Claude公式でログイン | Bedrock経由でログイン |
|---|---|---|
| 契約プラン別の機能表 | ○ そのまま適用される | × 適用されない（プランの区別が消える） |
| 組織の監査・設定の強制・SSO / SCIM | ○ 契約に応じて使える | × 使えない |
| 画面操作・Web検索など | ○ プランに応じて使える | × 使えない |
| 端末で完結する機能 （隔離実行・動作ログ・MDM設定） | ○ 使える | ○ 使える |
| 監査・統制の担い手 | Anthropic（クラウド側） | 自社（MDM＋ログ基盤） |
要するに、Bedrockを挟むと「データの境界」は堅くなる一方で、Anthropicがクラウド側で用意してくれていた管理・監査のしくみは、まとめて手が届かなくなります。その代わり、端末で完結する部分（会社のPC管理や動作ログの送出）は残るので、統制の担い手が「Anthropicのクラウド」から「自社」へ移る、と理解するのが正確です。
もうひとつ、デスクトップアプリ（Chat・Cowork・Code の3つのタブ）を丸ごとBedrock等に向ける場合の補足です。コマンドで動かすClaude Codeは環境変数の設定だけでBedrockに向けられます。一方、デスクトップアプリ全体をBedrock・Google Cloud・Microsoft Foundry・自前ゲートウェイに向ける仕組みは「Claude Desktop on 3P（第三者プロバイダ版）」と呼ばれ、2026年7月9日に正式提供が始まりました。この構成では利用者の識別が端末ごとのローカルIDだけに限られ（Anthropicのアカウントを使いません）、会話の履歴も各自の端末に保存されます。なお、セッション開始時に隔離環境（VM）を取得するため downloads.claude.ai への通信だけは常に必要で、ここを塞ぐと動かなくなる点には注意が要ります。
同じ条件でも、CoworkとCodeで違うところ
ここまで「Cowork も Code も同じ」と繰り返してきました。実際、統制の面ではほとんど同じです。ただ、数は少ないものの、知っておくべき違いはあります。
| Cowork | Claude Code | |
|---|---|---|
| 実行環境の隔離 （サンドボックス） | 作業を常に仮想の隔離環境の中で実行。パソコン本体と切り離されている | 隔離は初期状態ではオフ。利用者が自分で有効にするまで、パソコンと同じ権限で動く |
| 入力した文章の外部送信 | 初期状態で、入力文の全文がログとして外部へ送られる | 初期状態では文字数だけ。本文は送られない |
| 想定されている使い手 | 非エンジニアの業務担当者向けとされる | エンジニア・開発者向けとされる |
ひとつ補足します。いちばん下の「使い手」は、上の2つとは種類が違います。ここまで見てきたとおり中身（土台）は同じアプリなので、これは能力の差ではなく、「どちら向けに用意されているか」という位置づけ・呼び方の違いにすぎません。実際には、Coworkでエンジニア寄りの作業をしても、Codeでオフィス寄りの作業をしても構いません。「そう言われている入口の違い」くらいに受け取ってください。
意外かもしれませんが、実行環境の隔離はむしろCoworkのほうが堅いのです（常に隔離された仮想環境で動くため）。一方で、監査ログを整えようとして Cowork の記録をそのままログ基盤へ流すと、入力文の全文が個人情報ごと流れてしまうことがあります。良かれと思った監査が、新しい漏えい経路になりかねません。もしログを集めるなら、送る前に中身をふせる（マスクする）設定が要ります。この「入力文がまるごと送られるか」が、CoworkとCodeの、いちばん実務に効く違いです。
結論：ガバナンスでどう選ぶか
ここまでを、意思決定の順番に並べ直します。会社が決めるべきは「CoworkかCodeか」ではなく、次の2つです。
- どの契約で使わせるか（無料・Pro・MAX・ビジネス・エンタープライズ）
- Bedrockを挟むかどうか（Claude公式ログイン／Bedrock経由）
それぞれの選択が、ガバナンスにどう効くかをまとめます。
- 無料・Pro・MAX（個人プラン）：会社による制御・監査の手段がありません。しかも最も危険な画面操作が使えるのはこの層だけ。業務での本格利用には向きません。
- ビジネス（Team）：小さく試すには十分ですが、監査（コンプライアンスAPI）も自動連携（SCIM）もなく、制限も全社一律のみ。本格運用の器としては不足します。
- エンタープライズ：会社が本当の意味で管理・監査できる、実質的な出発点。統制を効かせたいなら、まずここです。
- Bedrockを挟む場合：データの境界は堅くなりますが、上のエンタープライズの管理機能ごと会社側からは使えなくなります。その分を自社（端末管理・動作ログ・ログ基盤）で肩代わりする覚悟と予算が前提です。デスクトップアプリ全体をこの構成にするなら「Claude Desktop on 3P」（2026年7月9日に正式提供開始）を用います。
Cowork と Code のどちらが安全か——この問いは、そもそも立て方が違います。統制を決めるのは製品ではなく、「どの契約か」と「Bedrockを挟むか」。まずはこの2つを設計してください。
提案書に「Bedrock経由にするので安心です」と一行だけ書いて終わり、というのが最もよくない止め方です。Bedrockを選ぶなら、失う管理機能を自社の何で埋めるのか——端末管理、動作ログ、ログ基盤まで含めて、導入前に予算化しておくべき項目です。ここを言語化できてはじめて、決裁は前に進みます。逆に言えば、そこにこそ、誰かが責任を持って設計すべき"空白"があります。
出典（一次情報）
本稿の主張は、以下のAnthropic・AWSの公開ドキュメントで裏付けを確認しています（いずれも2026年7月13日時点）。
- プラン別の機能可用性／「どう認証するかが機能を決める」こと／Bedrock・Google Cloud・Microsoft Foundry・Console APIキーで認証するとプラン別機能表が適用されないこと／各プロバイダで失う機能・全プロバイダで動く機能（CLI・サブエージェント・フック・スキル・MCP・サンドボックス・OpenTelemetry・管理設定ファイル）：
Feature availability ― Claude Code Docs - Claude Code のサンドボックスは既定で無効・Bashのみを制約し「無人実行には十分でない」と明記されていること：
Configure the sandboxed Bash tool ― Claude Code Docs - Claude Code の OpenTelemetry は既定でプロンプト本文を収集せず（長さのみ）、
OTEL_LOG_USER_PROMPTS=1で有効化すること：
Monitoring ― Claude Code Docs - コンプライアンスAPIは推論活動（利用者とモデルのやりとり）を記録せず、組織・リソースのイベントのみを対象とすること：
Compliance API ― Claude Platform Docs - Cowork の活動は監査ログ・コンプライアンスAPI・データエクスポートに記録されないこと／コード実行が仮想マシン（ハイパーバイザ）で隔離されること：
Claude Cowork architecture overview ― Claude Help Center - Cowork の OpenTelemetry は利用者のプロンプト全文を送出し、SIEMへ連携できること：
Monitor Claude Cowork activity with OpenTelemetry ― Claude Help Center - 「Claude Desktop on 3P（第三者プロバイダ版）」が2026年7月9日に正式提供となり、Chat・Cowork・Codeの全タブを選択したプロバイダで動かすこと／利用者識別はローカルIDのみ／
downloads.claude.aiがセッション開始時に常に必要なこと：
Claude Desktop on third-party (3P) ― Overview
本稿の内容はすべて、上記のAnthropic および AWS の公開ドキュメントに基づいています（2026年7月13日時点）。プラン名・機能の対応・提供状況は変更されることがあります。導入判断の際は、必ず最新の公式情報をご確認ください。