Cowork権限モデルの考え方 — Read/Writeで見る安全設計

なぜRead/Writeという2分類で権限を分けるか

Coworkの安全設計は、Claudeが持つツールを「読み取り(Read)」と「書き込み(Write)」の2つに大別することを土台にしています。何かが起きたときの影響は、この2つのどちらに属するかでほぼ決まる、というのが公式の説明です。

読み取りツールとは、Claudeが情報にアクセスし内容を把握するためのツールです。メールの受信箱を読む、画面のスクリーンショットを撮る、といった操作が当てはまります。書き込みツールとは、Claudeが環境に対して実際の行動を起こすためのツールです。カレンダーの予定を作る、ファイルを削除する、コマンドを実行する、画面をクリックする、といった操作が該当します。

書き込みツールは本質的にリスクが高いと公式は位置づけています。意図しない結果につながりやすいからです。この非対称性ゆえに、Coworkは書き込みツールを読み取りツールとは異なる扱いにし、影響が大きい場面での人間の目を推奨しています。

何がRead側、何がWrite側に分類されるか

分類の軸は「情報を見るだけか、環境を変えるか」の一点です。この軸に沿って主要な操作を並べると、次のようになります。

見落としやすいのは、接続アプリ側の権限設定(Always allow・Needs approval・Blocked)とこの分類が別軸だという点です。Read/Write分類は「そのツールがそもそもどちらの性質を持つか」を決め、接続アプリ側の設定は「そのツールを承認なしで動かしてよいか」を決めます。両方が掛け合わさって、実際にどこで確認が挟まるかが決まります。承認モードとの組み合わせはCowork自動承認モードとはで扱っています。

Writeが重く扱われる理由 — プロンプトインジェクションとの関係

Write側が重く扱われる理由は、単体のリスクだけではありません。プロンプトインジェクション攻撃が成立する条件と直結しているからです。

プロンプトインジェクションとは、外部コンテンツに紛れ込ませた悪意ある指示で、Claudeの挙動を乗っ取ろうとする攻撃です。公式ドキュメントは、この攻撃が成立するには2つの条件が同時に満たされる必要があると説明しています。信頼境界の外側にある情報をClaudeが読めること、そしてユーザーに不利益をもたらしうる行動をClaudeが実行できること、の2つです。どちらか一方が欠ければ、攻撃は成立しにくくなります。

言い換えると、Read側だけをどれだけ広げても、Write側が閉じていれば実害は起きにくい設計です。逆にWrite側を広げるほど、Readで拾った悪意ある指示がそのまま実行に化ける経路が太くなります。Coworkが承認プロンプト・autoモードの行動スクリーニング・削除保護をWrite側に置き、読み取り側は内容分類器で受けているのは、2つの条件をそれぞれ別に断ちにいく設計です。

隔離実行環境も、この構造を変えるものではありません。Coworkのタスクはセッションごとの一時環境で動きますが、これはコードの実行場所を制限するだけで、権限として与えた範囲でClaudeが何を読み何をするかは制限しません。外部から読み込んだ内容の危険性を判定するのは、別立ての内容分類器の役割です。

この分類だけでは防げない領域 — Computer Useという例外

Read/Write分類がきれいに機能する一方で、例外的にこの枠組みが薄くなる領域があります。Computer Use(画面操作)です。

ファイル操作には権限チェックが、コード実行には隔離環境という壁がありますが、Computer Useには画面とClaudeの間を隔てるサンドボックスがありません。Claudeはアプリごとにアクセス許可を求める仕組みを持ってはいるものの、許可済みのアプリ内でクリックしたリンクは、そのリンク先のアプリへの許可が無くても開いてしまいます。1つのアプリへの許可が、別のアプリへの実質的な入り口になり得るということです。

もう1つの例外は、ライブアーティファクトの更新です。Coworkライブアーティファクトの使い方で扱ったとおり、ライブアーティファクトは作成・更新時に承認した接続アプリを、以後は確認を挟まずに使い続けます。通常のタスクなら承認モードに応じて書き込み操作の前に確認が入る場面でも、ライブアーティファクトの更新経路はその確認を経由しません。便利さの代償として、Write側の扱いがここでは通常より軽くなっています。

もう1つ、性質の違う例外があります。ネットワークの送信先を制限する権限設定は、Web fetchツールやWeb検索、MCP経由のアクセス(Claude in Chromeを含む)には適用されません。Web fetchはサーバー側で完結し、検索結果と共有済みURLの範囲に限られる、という別ルールで動いています。これはRead/Write分類そのものの例外ではなく、その上に重ねてある別の権限軸(ネットワーク送信先の制限)が一部のツールを対象外にしている、という話です。権限を積み重ねて安全側に倒しているつもりでも、軸ごとに対象範囲が違う点は見落としやすいところです。

削除だけ全モード共通で確認が挟まる理由

Write側の中でも、ファイルの完全削除だけは特別扱いです。Manual・Auto・Skipのどの承認モードであっても、完全削除の直前には必ず明示的な許可画面が挟まります。

これは取り消しが利かない操作を1つに絞り込み、そこだけは必ず人間の判断を通す設計です。読み取りの誤りは読み直せば済み、多くの書き込みも修正や取り消しが利きますが、削除されたファイルは元に戻りません。Read/Write分類が「影響の重さ」で線を引く枠組みだとすれば、削除保護は同じWrite側の中で「取り消し可能性」というもう1段細かい軸を持ち込んでいる、と捉えると整合します。

Read/Write分類は業務のどこに効くか

この分類を意識する効果が大きいのは、接続アプリを追加する瞬間です。新しい接続アプリを承認する前に、それがRead寄りかWrite寄りかを自分に問うだけで、リスクの見積もりが具体的になります。

スケジュールタスクは特にこの視点が要ります。人が見ていない間に自動実行される以上、Write寄りの接続アプリを組み合わせたタスクほど、実行結果を都度確認する運用が必須になります。MCPサーバーやプラグインの導入も同様です。ローカルのMCPサーバーは、他の一般的なプログラムと同じ権限でコンピューター上に動くため、Read/Writeどちらの機能を持つかに関わらず、導入した時点でその権限の重みが乗ります。プラグインはスキル・接続アプリ・サブエージェントを1つにまとめて配布する仕組みで、1回のインストールがClaudeの行動範囲を一気に広げる点は、公式ドキュメントも明確に注意を促しています。

よくある質問

Read/Write分類はCowork画面のどこかに表示されているか

分類そのものを一覧するパネルはありません。実際に効いてくるのは、接続アプリごとのAlways allow・Needs approval・Blockedという設定と、承認モードの組み合わせです。分類は設計思想として存在し、その結果がこれらの設定値に反映される形です。

Enterpriseプランには追加の防御があるか

あります。Enterpriseプランでは、スキルとプラグインをインストール時に悪意あるコンテンツがないか確認するスキャン機能を有効化できます。ローカルMCPサーバーが通常のプログラムと同じ権限で動く以上、この事前チェックはWrite側のリスクを導入前の段階で下げる手段になります。

個人利用でこの分類をどう活かせばよいか

新しい接続アプリを承認する前に、それが情報を見るだけのものか、環境を変えられるものかを確認する習慣が実践的です。財務情報や資格情報のような機微なファイルは、専用の作業フォルダーに寄せてアクセス範囲を絞ることも、Write側の影響を小さく保つ具体策になります。

まとめ

Coworkの安全設計は、承認モードやコネクタ設定という個別の機能である以上に、Read/Writeという1本の軸に貫かれています。書き込みツールが重く扱われるのは、プロンプトインジェクションが成立する2条件のうち片方を直接担っているからです。

Computer Useとライブアーティファクトの更新は、この軸が実行時に薄くなる数少ない例外です。日々の運用では、新しい接続アプリやプラグインを承認する瞬間に「これはReadかWriteか」を自問するだけで、見えるリスクの解像度が上がります。組織としての具体的な設計はCowork Approval Gatesを部門ごとに設計する考え方、データがどこに置かれるかという別軸の話はCoworkセキュリティにまとめています。Coworkの機能全体像はClaude Cowork(クロードコワーク)とはを参照してください。