Claude Coworkを安全に使うには？権限管理と導入チェックリスト

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

まず見るべき3つの判断軸

安全に使えるかどうかは、Claude Coworkが強いか弱いかではなく、どの範囲を渡し、どの仕事を渡さず、誰が設定を握るかでほぼ決まります。まずは「便利そうだから全部つなぐ」ではなく、境界線から考えるのが近道です。

最初に見るべき判断軸は次の3つです。

この3つが固まると、「Coworkは危ないのか」という曖昧な不安が、「この範囲なら使える」「ここは人が持つべきだ」という判断に変わります。以降は、権限境界の地図を見たうえで、承認の入り方、管理者設定、学習利用と保存期間まで順に確認していきましょう。

① 権限を絞るほど使いやすい

Coworkを安全に使うコツは、最初から全部開けることではありません。必要な範囲だけ有効にして、足りなくなったら少しずつ広げるほうが、運用も判断もずっと楽になります。

たとえば最初は、作業用フォルダを1つだけ connected folders に入れ、必要なコネクタだけを接続し、trusted sites も仕事で本当に使うサイトだけに絞ります。Coworkは、より正確な手段があるなら connector や browser を先に使う設計なので、範囲を狭くしても「使えなくなる」より「暴れにくくなる」効果のほうが大きい場面が多いです。

逆に、フォルダもサイトもコネクタも広く開けた状態で使い始めると、便利さは増えても「今どこまで見えているのか」が読めなくなります。最初は不便なくらいでちょうどよく、慣れてから必要な権限だけ足す運用のほうが安全です。

② 機密業務は任せない

安全運用で一番効くのは、「何を有効にするか」より先に「何を任せないか」を決めることです。特に、金融口座、法務文書、医療情報、人事データ、顧客の個人情報のように、ミスや漏えいの代償が大きい領域は Cowork の担当外に置くほうが無難です。

また、削除、送金、契約更新、公開反映、管理者権限での設定変更のような取り返しのつきにくい操作も、人が最後まで持つ前提で考えたほうが安全です。Coworkに任せるなら、下調べ、下書き、要約、比較、候補出しまでにとどめ、最終実行だけは人が行う切り分けが現実的です。

「便利だからやらせる」ではなく、「失敗しても被害が限定される仕事だけ渡す」と決めると、Coworkは急に扱いやすい道具になります。

③ 社内導入は管理設定まで見る

個人でProやMaxを試すのと、Team/Enterpriseで社内導入するのは、同じCoworkでも見方がかなり変わります。個人なら「自分がどこまで開けるか」が中心ですが、組織では誰が有効化し、誰が監視し、どこまで中央で制御できるかまで確認が必要です。

とくに、Coworkの有効化範囲、コネクタの approval、Chrome や desktop extensions の制御、Tenant Restrictions、保存期間、監視方法は、導入後に慌てて考えるより先に決めておくほうが安全です。ここを曖昧にしたまま始めると、現場は便利でも、セキュリティや情シスが後から止めざるを得ない状態になりがちです。

社内導入では「機能があるか」より、「その機能をどこまで閉じられるか」を先に確認しましょう。

Coworkの権限境界を5層で見る

ここでは、Coworkを「ひとつの黒箱」として見るのをやめて、権限境界ごとに分けて考えます。境界を分けてしまえば、「この層は開ける」「この層は閉じる」という判断がしやすくなります。

この5層を混ぜてしまうと、「VMだから安全」「PCを触るから危険」といった雑な結論になりやすくなります。次の節からは、それぞれの層で何を任せやすく、どこに注意すべきかを具体化していきます。

① つないだフォルダとローカルファイル

Coworkのいちばん基本的な権限は、connected folders に指定したフォルダの読み書きです。ここは便利さの源でもありますが、最初に広く開けすぎやすい場所でもあります。

安全に始めるなら、デスクトップ全体やダウンロードフォルダ全体ではなく、案件ごとの作業フォルダだけをつなぐ運用が向いています。たとえば「この案件の資料」「このリポジトリ」「この下書き置き場」のように単位を切り、終わったら外す前提にすると、見せる範囲が読みやすくなります。

ローカルファイルは一度見せると便利ですが、誤って混ぜた個人資料や機密情報まで拾うと事故のもとです。フォルダの粒度を小さくすること自体が安全策だと考えてください。

② コネクタと元システム権限

コネクタは便利ですが、考え方はシンプルです。まず元システムの権限が土台で、その上に Claude 側の権限絞り込みが乗るだけです。Claude 側の設定が、元システムより強い権限を生むことはありません。

たとえば Drive 側で見えないファイルは、Claude からも見えません。そのうえで Team/Enterprise では、Connectors の Tool permissions を使って「常に許可」「都度承認」「ブロック」を分けられます。つまり、元システム権限を絞り、さらに Claude 側でも絞る二重の考え方が基本です。

ここを理解しておくと、「コネクタをつないだら全部取られるのでは」という不安がかなり解けます。怖いのは接続そのものより、元システム権限が広すぎる状態のまま運用することです。

③ ブラウザとClaude in Chrome

Coworkがウェブを触るときは、何でも自由に開けばよいわけではありません。安全に使うなら、仕事で本当に必要なサイトだけを trusted site として考えるのが基本です。

理由は単純で、ウェブは便利さと同時に prompt injection の入口にもなりやすいからです。見てよい社内ドキュメント、調べてよい公式サイト、作業してよいSaaSを先に決めておくと、ブラウザ経由の事故をかなり減らせます。

Team/Enterprise なら、Claude in Chrome を allowlist / blocklist で絞る考え方が取りやすくなります。最初は広く開けるより、必要なサイトだけを許可して pilot 運用し、業務で困る場所だけ後から足すほうが安全です。

④ 画面操作とcomputer use

computer use は、Cowork が最後の手段として使う強い能力です。画面に表示された情報を手がかりに、アプリを直接クリックし、入力し、操作します。便利ですが、ここは他の層より一段慎重に扱うべき場所です。

重要なのは、computer use にはアプリとの間に sandbox がないことです。つまり、許可を出したアプリで見えている情報は、画面上にある範囲で Cowork も扱えると考えたほうが安全です。銀行、労務、契約、個人情報管理のような敏感なアプリでは、そもそも許可を出さない判断が有力です。

逆に、社内でルールを決めたうえで、単純なフォーム入力や既知のGUI操作だけに使うなら価値があります。computer use は「便利そうだからON」にするより、「このアプリでは使わない」を先に決めるほうが失敗しません。

⑤ VMとネイティブ実行

Coworkの安全性で誤解されやすいのが、「VMで動くなら全部そこに閉じているのでは」という見方です。実際には、shell commands と code execution は VM 側でも、会話処理や connected-folder の読み書き、web fetch、local plugin MCP servers はネイティブ側で動きます。

この違いを知らないと、隔離されている部分と、端末に近い部分を同じ感覚で扱ってしまいます。たとえば VM 側は隔離の恩恵がありますが、Cowork の活動は Compliance API や audit logs に載らず、ホスト側の EDR で VM 内をそのまま検査できるわけでもありません。

つまり、Coworkは「全部ネイティブ」でも「全部VM」でもありません。どの処理がどちら側かを知って、任せる仕事を分けるのが現実的な安全策です。

承認が入る場所・入らない場所

ここで一度、「どこで人の確認が入るのか」をまとめておきます。Coworkは何でも自動で実行する道具ではなく、層ごとに承認の入り方が違います。

一方で、承認があるから完全に安全というわけでもありません。computer use のように、許可した後の画面情報が見える層もありますし、web fetch/search や native 側の挙動は「どこまで開けたか」の設計次第です。承認は最後の保険であって、最初の設計の代わりではないと捉えておくと判断しやすくなります。

Team/Enterpriseの管理者設定

個人利用では自分の判断が中心ですが、Team/Enterprise では管理者設定が安全運用の土台になります。ここを整えずに現場へ開くと、「便利だけど止めるしかない」状態になりやすくなります。

管理者が先に見るべきなのは、大きく3つです。誰に有効化するか、どの接続手段をどこまで絞るか、どこまで監視・制御できるかです。この3点がそろうと、Cowork を一気に全社へ広げるのではなく、小さく始めて安全に拡張しやすくなります。

次の3節では、それぞれを分けて確認します。設定項目が多く見えても、実際は「人」「接続」「統制」の3カテゴリに分けると整理しやすいです。

① Coworkの有効化範囲

最初に見るべきは、Cowork を誰に開くかです。Team/Enterprise では Cowork 自体の有効化が出発点になりますが、細かさはプランで違います。

Team では基本的に組織全体での on/off に近く、まず小さな組織や pilot チームで試す設計が向きます。Enterprise では groups や custom roles を使って、対象チームを絞りながら rollout しやすくなります。

もう1つ大事なのは、Projects に個別の管理者設定があるわけではないことです。Projects のデータは local storage 前提なので、「プロジェクト単位であとから厳しくする」より、「誰に開くか」を最初に丁寧に決めるほうが効きます。

② コネクタ・拡張・サイト制御

次に見るのは、Cowork が外とつながる面をどう絞るかです。ここは「Coworkを許可する / しない」の二択ではなく、接続手段ごとに細かく閉じる発想が重要です。

導入時は、まずコネクタを最小限にし、Chrome は allowlist から始め、desktop extensions も必要なものだけ残す順番が分かりやすいです。便利さは後から足せますが、開けすぎた権限を現場から剥がすのは難しくなりがちです。

③ 監視・ネットワーク制御

最後に見るのは、運用を続けるための統制面です。ここは「使えるか」より、「使ったあとに追えるか」「会社アカウントだけに閉じられるか」を判断する章だと思ってください。

Cowork では、OTel でイベントを流して SIEM に寄せる道があります。一方で、Cowork の活動がそのまま Compliance API や audit logs に載るわけではありません。つまり、既存の監査の見え方と完全に同じではない前提で考える必要があります。

また、Enterprise では Tenant Restrictions を使って corporate networks 上の personal account 利用を絞れます。network egress も制御点になりますが、web fetch/search など例外もあるため、「閉じたつもり」の盲点がないかを事前に確認しておくと安心です。

学習利用と保存期間の見方

ここは混同しやすいので、個人利用と社内利用を分けて見ます。執筆時点では、commercial の Team/Enterprise は inputs / outputs が default で model training に使われない 一方、consumer の Pro/Max は設定や安全審査の条件によって chats and coding sessions が改善に使われる場合があります。

ここで大事なのは、「Coworkは学習されるのか」という問いに1行で答えないことです。自分のプランが consumer なのか commercial なのかで答えが変わるので、導入判断ではまずアカウント種別を確定させましょう。

導入前チェックリスト

最後に、導入前に最低限そろえたい項目を順番に並べます。ここが曖昧なまま始めると、現場の試用は進んでも、本番運用で止まりやすくなります。

この順番で詰めると、「便利そうだからまず全開で使う」流れを避けられます。Coworkは、最初に制御点を決めてから小さく始めるほど、現場にも管理側にも受け入れられやすくなります。

よくある質問

まとめ

Coworkを安全に使うコツは、「怖いから使わない」でも「便利だから全部開ける」でもなく、権限境界ごとに分けて判断することです。

次の一歩は、小さく始めることです。まずは作業フォルダと trusted sites を最小限に絞り、任せない業務を決め、必要なら pilot チームだけで試してください。その設計ができていれば、Coworkは「危ない道具」ではなく、境界を守りながら使える実務ツールになります。