Claude Coworkセキュリティガイド

Claude Coworkを企業に入れてよいかは、「Claudeが賢いか」では決まりません。決まるのは、6つの操作面——コード/シェル実行、ローカルファイル、Computer use、Claude in Chrome、MCP/プラグイン、監査ログ——のうち、どこまでがVMの中に隔離され、どこから実画面・実ブラウザ・外部サービスに直接到達して、しかも監査にも残らなくなるか、という境界線です。

私は、Coworkは「読む・整理する・下書きする」の範囲でなら企業導入に値すると考えます。VM内のコード/シェル実行と、専用フォルダに限定したローカルファイル読み取りは、境界が明確だからです。一方でComputer useとClaude in Chromeは、2026年5月時点では業務端末に入れるべきではないと、はっきり反対の立場を取ります。この2つはVMの外に出て実画面・実ブラウザを直接触るうえ、Cowork activityはCompliance APIに残らず、事故が起きても後から戻せません。境界の外側——Team/Enterpriseで承認フローとOpenTelemetryを先に設計した組織——については判断を保留しますが、「設計が先、有効化が後」という順序だけは譲りません。この立場を覆す実例が出れば、そのときは朝令暮改します。

権限設計の考え方として私が重視しているのは、「渡す範囲を先に決めてから機能を有効化する」という順序そのものです。フォルダやコネクタを個別に絞り込む具体策は組織ごとに異なりますが、共通して言えるのは、承認モードや接続範囲を機能の使い勝手に合わせて後から緩めるのではなく、先に固定してから使い始めるべきだという点だと考えます。

なぜ今この整理をするかというと、2026年5月にLayerXが公開した「ClaudeBleed」レポートで、Claude in Chromeの信頼境界が実際に破られた事例が出たからです。2026年5月18日時点の公式Help CenterをCrawl4AIで確認し、X/Redditで見られる実利用上の不安、LayerXの第三者レポートを突き合わせました。断片的な情報を一度整理する素振りとして、この記事を書いています。

前提

この先の話は、2つの軸の上に乗っています。定義を先に置きます。

隔離面 vs 到達面——Claudeの操作は、VMの中で完結して実行が隔離される面(コード実行、シェル実行)と、実画面・実ブラウザ・外部サービスに直接到達し、端末そのものの権限で動く面(Computer use、Claude in Chrome、ローカルMCP)に分かれます。「VMがあるから安全」という判断は、この2つを混同しているために起きます。

監査に残る範囲 vs 残らない範囲——通常のChatはCompliance APIの前提の上にありますが、Cowork activityはその外にあります。OpenTelemetryで別途設計しない限り、事故が起きても後から調査できない領域が残ります。これは導入判断における第一級の変数であり、機能の便利さとは独立に評価する必要があります。

まず分けるべき6つの境界

Claude Coworkのセキュリティ境界

隔離面

/シェル実行とローカルファイル

公式Helpで確認できる主な安全策は次のとおりです。

公式Helpも「攻撃リスクはゼロではない」と明記しています。安全策はありますが、機密データを広く渡してよいという意味ではありません。

ここで誤解しやすいのが、ローカルファイルの扱いです。Coworkはファイルを直接扱えるため「アップロードしないから外に出ない」と思われがちですが、Claudeがファイルを読み、要約し、判断するなら、その内容はすでにClaudeの文脈に入っています。許可したフォルダは読み取りだけでなく、書き込み・削除の対象でもあります。VMは「実行が隔離される」ことは保証しますが、「渡したファイルの中身が漏れない」ことは保証しません。

実務では、次のルールに寄せる方が安全です。

• 共有するフォルダは業務単位の専用フォルダにする
• 秘密鍵、顧客台帳、給与、金融、医療、本人確認書類を含むフォルダは渡さない
• 出力先と更新先を明示する
• 削除、送信、公開、支払い、契約変更は自動化しない
• 重要ファイルはバックアップを前提にする

Team / EnterpriseのHelpでは、Coworkの会話履歴はユーザーPC上に保存され、管理者が中央管理・エクスポートできないと説明されています。一方でタスク削除時のバックエンド保管期間に関する記述もあるため、保持要件がある業務では「通常のChatと同じ監査・エクスポートができる」とは見ない方が安全です。

到達面その1

use

Computer useは、Claudeが画面を見て、クリックし、入力し、アプリを操作する機能です。2026年5月18日時点の公式Helpでは、Pro / Max向けとされ、Team / Enterpriseでは利用できません。

Computer useを試す場合は、個人PCやテスト用プロファイルで、小さな作業から始めるべきです。メール、Slack、Drive、CRMなどをそのまま開いた状態で触らせるのは、VMの外で実画面を渡す行為そのものだからです。仕組みの詳細はComputer useガイドにまとめています。

到達面その2

in ChromeとClaudeBleed

Claude in Chromeは、Chrome上でClaudeがWebページを読み、クリックし、フォーム操作できる拡張機能です。公式Helpでは全有料プラン向けのβ機能として案内されています。

2026年5月、LayerXがClaude in Chromeの信頼境界に関する「ClaudeBleed」レポートを公開しました。LayerXは、別のChrome拡張がClaude in Chromeへ命令を注入し、Gmail、Google Drive、GitHubなどで機密情報の抽出や操作を誘発できると報告しています。Anthropicが拡張機能v1.0.70で緩和策を出した後も、LayerXは一部経路で回避可能だと主張しています。これは第三者研究であり公式の見解ではありませんが、公式Help自体もClaude in Chromeを高リスクなβ機能として扱い、機密情報を扱う作業に使わないよう警告しています。

企業導入では、少なくとも次の運用にすべきです。

• Enterpriseでは、必要になるまでClaude in Chromeを有効化しない
• Teamでは、既定で有効でも組織設定で無効化を検討する
• 使う場合は、許可サイトを厳しく絞る
• Act without askingは原則禁止する
• 会社管理のChrome拡張機能だけを許可する
• ほかの拡張機能がclaude.aiへ干渉できないか確認する
• 機密SaaS、金融、医療、管理者画面では使わない

Redditでは、接続不良、会社のセキュリティ製品によるブロック、許可ダイアログの多さ、無効化したはずのChromeツールが残るという不満も見られました。セキュリティ以前に運用が不安定な面もあり、全社展開ではなく限定パイロットから始めるべきです。

ClaudeBleedのようなレポートが出た以上、Claude in Chromeは「β機能だから様子見」ではなく「実際に信頼境界が破られた実績がある機能」として扱うべきだと考えます。緩和策が出たことをもって解決済みと見なすのではなく、次に同種の報告が出るまでは既定無効を基本線にし、有効化する場合も許可サイトと権限モードを個別に絞るという運用の方が、業務端末では妥当だと考えます。

Claude in ChromeとComputer useのリスク整理

到達面その3

Coworkのプラグインは、スキル、コネクタ、サブエージェントを束ねます。便利ですが、導入するとClaudeの到達範囲が広がります。特に注意すべき点は2つです。

1. Remote MCP / カスタムコネクタは、Anthropicクラウドから到達できる公開エンドポイントが必要
2. ローカルMCPを含むプラグインは、PC上で通常アプリと同じ権限で動くことがある

「社内ネットワークにあるから安全」「MCPだから安全」という判断はできません。配布元、要求権限、接続先、ログ、トークン保管方法を確認する必要があります。

Team / Enterpriseでは、組織プラグインのMarketplaceを使って配布制御できます。ただし、Enterpriseのグループ上書きは「最も許可が広い設定」が優先されるため、セキュリティ境界としては過信しない方が安全です。禁止したいプラグインは組織全体でNot availableにして、必要なグループだけ許可する設計にします。信頼境界の詳細はCoworkプラグインガイドで扱っています。

監査に残らない範囲

Cowork activityは、2026年5月時点でCompliance APIには含まれません。通常の監査ログやエクスポートを前提にしたまま導入すると、あとで調査できない領域が残ります。

Team / Enterpriseでは、OpenTelemetryでCoworkイベントをSIEMや監視基盤に流せます。公式Helpでは、Claude Desktop 1.1.4173以降が必要です。

注意点もあります。プロンプト本文、ツール引数、ファイルパス、メールアドレスがイベントに含まれるため、SIEMに流す前にフィルタリングや保持期間を決めておく必要があります。

通常のChat監査を前提にしたまま導入すると、この領域は調査できないまま残ります。SIEM側でのフィルタと保持期間の設計は、機能を有効化した後ではなく、有効化する前に決めておくべきだと考えます。

Claude Coworkの監視設計

Team / Enterpriseの管理ポイントも要点だけ触れておきます。Cowork自体の有効化はEnterpriseでは組織全体トグルで一括制御でき、Teamではグループ単位・カスタムロールで範囲を絞れます。Coworkで作成したProjectsの保存範囲や、プラグインMarketplaceでの配布制御も管理者側の設定項目です。これらの席設計・有効化範囲・ローカル実行リスクの詳細は、Coworkチーム導入ガイドに委ねます。ここでは、Computer useが両プランで対象外であること、Claude in ChromeはTeamでは既定有効・Enterpriseでは既定無効というプラン間の差分だけ押さえておけば十分です。

再整理

vs 監査に残る操作

同じ6つの境界を、導入判断で実際に効く2軸で並べ替えると、レバーが3本だけ残ります。

• 専用フォルダの固定——コード/シェル・ローカルファイルは隔離面にあり、監査ログにも残る。ここは「渡すフォルダを業務単位に絞る」というレバー一本で管理できる。
• 承認モードの固定——Computer use・Claude in Chromeは到達面にあり、事故が起きると戻せない。ここはAsk before actingを固定するレバーで、被害の可能性を「実行前に人が見る」一段に落とし込む。
• OpenTelemetryの先行設計——Cowork activity全体がCompliance APIの外にあるため、監査は機能有効化後に足すのではなく、有効化前にSIEM側のフィルタと保持期間を決めておくレバーになる。

予約タスクも同じ枠組みで扱えます。定期的に仕事を頼める便利な機能ですが、リアルタイムで監視できないため、指示文自体に禁止操作を明示するのが実務上のレバーです。

このタスクでは、指定フォルダ内の資料を読み、要約ドラフトだけを作成してください。
ファイルの削除、移動、上書き、外部共有、Slack投稿、メール送信はしないでください。
不明点や権限エラーがある場合は、処理を止めて「要確認」と書いてください。

詳しくはClaude Cowork予約タスクガイドで整理しています。

私が企業導入担当なら

3本のレバーを自分の判断に引き直すと、番号は次のようになります。

1. 初日に禁止するのは、送信・削除・公開・支払い・契約変更の5操作。理由は単純で、Cowork activityがCompliance APIに残らない以上、戻せない操作は監査でも追えないからです。
2. 最初に許すのは、議事録整理、資料要約、週次レポート下書き、競合調査メモ。読み取り中心・下書き中心の仕事は、事故が起きても「渡したフォルダの外に出ない」という前提が成り立ちます。
3. Computer useとClaude in Chromeは、ClaudeBleedのような実例がもう一段積み上がるまで、業務端末では有効化しません。個人のPro/Max検証は止めませんが、業務データが開いた状態での検証は避けるべきだと考えます。

この3本のなかで最も譲れないと考えているのは1番目です。読み取り中心の仕事は事故が起きても被害の範囲が読めますが、送信・削除・公開・支払い・契約変更は一度実行されると、Cowork activityが監査ログの外にある以上、後から何が起きたかを追うこと自体が難しくなるからです。

FAQ

Q1. 個人のPro/MaxでComputer useを試すのはどこまで許容されますか?

テスト用プロファイルか個人PCで、業務データを開かない状態に限ってです。メール、Slack、Drive、CRMなどの業務アプリを開いたままComputer useを動かすのは、検証であっても避けるべきです。スクリーンショットで画面全体を理解する仕組み上、映っている情報はすべて対象になります。

Q2. LayerXのClaudeBleedは、拡張v1.0.70の緩和策で解決済みと考えてよいですか?

そうは見ない方が安全です。LayerXは緩和後も一部経路で回避可能だと主張しており、これは第三者研究であって公式の完了宣言ではありません。公式Help自体も、Claude in Chromeを高リスクなβ機能として扱い続けています。

Coworkの安全な導入は、「広く使わせる」ことではなく、Claudeに渡す権限を小さくし、監視できる範囲から始めることだと考えます。境界線をどこに引くかはこの記事で示した通りですが、その線をどこまで前に進めるかは、各組織が自分たちのSIEMと承認フローの設計速度で決めることです。私自身の立場も、ClaudeBleedを覆す実例やCompliance API側の対応が出れば変わります。判断材料として使ってもらえれば、それで十分です。全体像はClaude Cowork完全ガイドも参照してください。