Claude Media
Cowork Approval Gatesを部門ごとに設計する考え方

Cowork Approval Gatesを部門ごとに設計する考え方

Coworkの承認は個人のモードとツール権限に、管理者の組織設定が重なって決まります。部門の業務特性に合わせて承認ゲートを設計する判断軸をまとめます。

Coworkが「対外メール送信」や「顧客データベースへの書き込み」のような取り消しにくい操作をどこまで自律的に進めるかは、個人が選ぶ承認モードだけでは決まりません。ConnectorやScheduled Tasksで自動化する業務が広がるほど、承認ゲートの設計が運用の安全性を左右します。

最初に押さえたいのは、コネクタのツール権限を「要承認」に設定しても、Skipモードでは承認なしで通ることです。モード・ツール権限・組織設定の掛け合わせから、業務の性質で承認ゲートを決める判断軸と部門別のパターンに進みます。モードそのものの挙動はCowork自動承認モードとはに詳しいので、中身から知りたい場合はそちらが先です。

Approval Gatesは個人設定と組織設定の2層で決まる

個人側には、承認モードとコネクタごとのツール権限という2つの設定があります。Team・Enterpriseでは、その上に組織設定がもう1層重なります。

仕組み

承認の結果を決める3つの設定

  • 承認モード(個人)

    Manual・Auto・Skipの3つです。Claudeが操作の前に止まるかどうかの大枠を決めます。

  • ツール権限(個人)

    コネクタのツールごとに「常に許可」「要承認」「ブロック」を選びます。+メニューやCustomize > Connectorsから管理します。

  • 組織設定(管理者)

    書き込み可能なツールで「常に許可」を使えるか、Autoを選べるかを管理者が決めます。Enterpriseではカスタムロールとも重なります。

モードとツール権限の組み合わせ

3つのモードと3つのツール権限は、次の表のとおり9通りの組み合わせで結果が決まります。

モード常に許可要承認ブロック
Manual常に許可承認済みとして通る要承認毎回確認を求めるブロック拒否
Auto常に許可読み取りツールは承認済み。書き込み・削除ツールはClaudeが判断要承認Claudeが判断ブロック拒否
Skip常に許可承認済みとして通る要承認承認済みとして通るブロック拒否

「ブロック」の列は、どのモードでも拒否です。逆にSkipでは「要承認」の設定が働かず、操作を自動で点検する仕組みもありません。いちばん緩いモードなので、止めたい操作は「ブロック」に置くのが前提になります。

Autoの「Claudeが判断」は、各操作の実行前に安全性を点検し、危険と判断した操作を止める動作を指します。ブロックが続けば、Claudeは1手ずつ許可を求める動作に戻ります。この点検はAutoの追加の処理なので、他のモードより使用量を多く消費します。

なお、新しいClaudeの体験に切り替わったアカウントでは、メッセージ欄の権限設定がAutoとManual(既定)の2択です。この表示ではSkipを選ぶ場面がありません。

組織設定が個人の「常に許可」を止める

Team・Enterpriseの組織設定「Organization settings > Cowork」のPermissions配下には、「Always allow」をコネクタツールに使えるかを決める項目があります。書き込み可能なコネクタツールについて、メンバーがタスクごとの承認を省略できるかを管理者が決める設定で、既定はオフです。

オフのあいだは、組織全体のツールポリシーで許可されているツールでも、承認ダイアログの「すべてのタスクで許可」がグレーアウトします。以前に保存した「常に許可」の設定も反映されません。メンバーは書き込み系ツールをタスクごとに承認し続けます。

読み取り専用のツールはこの制限の対象外です。ただし、コネクタが読み取り専用だと注釈している場合に限ります。注釈を持たないカスタムコネクタが多く、その場合はコネクタ上の全ツールが承認の対象になります。

Enterpriseでは、この設定はカスタムロールによる権限付与と並んで働き、最も制限の厳しい層が優先されます。ロール側で許可を広げても、この設定を上書きできません。ロール設計の手順はClaude CoworkのRBAC運用にまとめています。

Autoを選べるかどうかは、別の設定「Allow "Automatically approve" mode」が決めます。こちらは既定でオンで、オフにするとメンバーのモード選択からAutoが消えます。

承認ゲートを業務の性質で設計する4つの判断軸

すべての業務に同じ承認レベルを当てると、軽い作業まで毎回止まるか、重い作業まで自動で進むかのどちらかに寄ります。業務を次の4軸で分類してからゲートの強さを決めると、設計がぶれません。

軸問いゲートを強める方向
取り消しやすさ問い誤りに気づいたとき、元に戻せるかゲートを強める方向戻せない・戻しにくいほど強める
金銭・契約への影響問い支出や契約が確定する操作を含むかゲートを強める方向含むほど強める
社外への影響問いメール送信や公開投稿など社外に届く操作かゲートを強める方向届くほど強める
頻度と定型度問い毎回同じパターンで繰り返す定型作業かゲートを強める方向定型度が高いほど弱めやすい

内部ドキュメントの読み取りや検索・要約は、4軸すべてで「弱めてよい」側に寄ります。対外メールの送信、支出承認、顧客データベースへの書き込みは、取り消しにくさと金銭・社外影響の両方で「強める」側に入ります。

4軸は足し算ではなく組み合わせで効きます。定型度が高くても、金銭・契約に響く操作は強いゲートを外せません。取り消しにくい操作でも、社内に閉じた作業なら緩めたときの実害は小さくなります。どの軸が該当業務にとって致命的かを先に見極めるところが、設計の起点です。

強いゲートが必要と判断した操作には、モードの表を踏まえた置き方があります。「要承認」はManualでは毎回の確認になりますが、Skipでは素通りします。誰がどのモードで実行しても止めたい操作は、「ブロック」に置く選択肢があります。

経理部の月次レポートで4軸を当てはめる

QuickBooksの月次残高を要約してSlackに投稿するScheduled Taskと、同じコネクタで請求書を発行するタスクを比べます。

くらべる

同じ経理部・同じQuickBooksでも承認ゲートは変わる

弱めやすい

月次レポート

QuickBooks側は残高の閲覧だけで、誤りがあってもレポートを再生成すれば済みます。支出も送金も発生せず、投稿先が社内チャンネルなら社外への影響もありません。毎月同じ形式で繰り返す定型業務です。

強める

請求書の発行

支出や請求が確定する書き込みが入り、取り消しにくくなります。コネクタ側は「要承認」か「ブロック」に置き、組織設定で「常に許可」を開けていても対象外にします。

ここで見落としやすいのは、月次レポートにも書き込みが1つ含まれることです。Slackへの投稿は、Slackコネクタから見れば書き込みツールの呼び出しです。QuickBooksのツールが読み取り専用の注釈を持つなら、組織設定の制限を受けず個人の「常に許可」がそのまま効きます。Slack側の書き込みは、組織設定の「常に許可」がオフのままだとタスクごとの承認に回ります。

読み取りの権限を緩める話と、書き込みの承認を省く話は、別の設定の話です。定型レポート業務の多い部署では、読み取りは注釈の有無を、書き込みは投稿先の範囲を、それぞれ確認すると設計が安定します。

Scheduled Tasksはクラウドで動き、実行中に人が見ていない前提です。ヘルプは、定期タスクでは機微なファイルへのアクセス、ユーザーに代わるメッセージ送信、購入のような取り消しにくい操作を避けるよう書いています。社内チャンネル向けの投稿でも書き込みなので、まず簡単な要約から始め、各回の結果を左サイドバーの「Scheduled」ページで見直す運用が合います。

部門別の設計パターン

4軸を業務に当てはめると、部門ごとに承認ゲートの重心が変わります。

経理・購買は、支出確定や請求処理が絡む部門です。QuickBooksやPayPalのような会計・決済系コネクタは、書き込みツールを「要承認」より強い側に置く設計があります。読み取りだけのレポート集計は、注釈つきのツールなら組織設定の制限を受けず、個人の「常に許可」がそのまま効く部分で、緩めたときの実害も小さめです。

営業・CRMは、リード情報の閲覧やパイプラインの要約といった読み取り中心の作業と、顧客データベースへの書き込みが混ざります。閲覧・要約は「常に許可」で回し、CRMへの書き込みだけ「要承認」に切り分けると、日常業務の速度を保ったまま書き込みにだけ人の目を挟めます。

マーケティングは、コンテンツ生成と分析レポートが中心で、ドラフト作成までは社外に届かない作業が中心です。ドラフト作成まではコネクタの権限を緩め、公開・配信の操作だけ「要承認」にする切り分けが、速度と安全性を両立しやすい形です。

人事は、個人情報を扱う頻度が高く、機微度の高いデータを扱う業務が中心です。コネクタの権限を絞り、組織設定の「常に許可」もオフのままにして、書き込み系の操作をすべてタスクごとの承認に置く設計があります。データの保存場所やアクセス範囲は、Coworkセキュリティでプラン別・実行方式別に整理しています。

モードを緩めても残るゲート

どの設定でも外れないゲートが、いくつかあります。ファイルの完全削除は、どのモードでも、実行前に「Allow」の選択を求められます。

一方で、承認ゲートの外にある操作もあります。コンピューター操作(computer use)は、Claudeが画面を直接クリック・入力するため、他のCoworkツールのような権限チェックを挟みません。あるアプリ内のリンクをクリックすると、許可を与えていない別のアプリでリンクが開くことがあります。

くらべる

承認の仕組みが及ぶ範囲

モードで制御できる

Autoの点検が及ぶ操作

既存のコネクタとプラグイン、組み込みブラウザー、Claude in Chrome、Webページの取得などCoworkの一部の操作です。

別の対策が要る

別の仕組みで管理される操作

アプリごとの許可で管理され、ブロックしたいアプリは個別に指定します。ネットワークの外向き通信制限は、Web取得・Web検索・MCP(Claude in Chromeを含む)には効きません。

プラグインを入れると承認ゲートはどう変わるか

プラグインはスキル・コネクタ・サブエージェントを1つのパッケージにまとめたものです。コネクタが同梱されることがあり、入れるとClaudeが操作できる範囲が広がります。

Cowork内のプラグインは、Coworkを有効にする管理者設定と同じトグルで管理され、プラグイン専用の別設定はありません。ただし、組織向けのプラグインマーケットプレイスで、プラグインごとの扱いを選べます。

4段階

マーケットプレイスでのプラグインの扱い

  • Installed by default

    組織全員に自動で追加されます。メンバーはオフにできます。

  • Available to install

    Discoverタブに並び、メンバーが自分で追加します。

  • Required

    全員に自動でインストールされます。メンバーはオフにも削除もできません。

  • Not available

    メンバーから見えなくなります。ステージングや廃止予定のプラグインに向きます。

Enterpriseでは、グループ単位でこの扱いを上書きでき、特定のチームだけに自動インストールして他からは隠す運用ができます。プラグインの棚卸しは、承認の強さの調整とは別に、「そもそも入れるか」の判断として行えます。

デスクトップ拡張やプラグインに同梱されるローカルのMCPサーバーは、ユーザーのコンピューター上で、他のプログラムと同じ権限で動きます。Claude Desktopのディレクトリにある検証済みのものに絞り、要求される権限を入れる前に見ることが推奨されています。Enterpriseでは、インストール時にスキルとプラグインの中身を悪意の観点で検査するスキャン機能もあります。

Autoは既定でオン、「常に許可」は既定でオフ

2つの組織設定の既定値は、向きが逆です。Autoを選べる設定はオン、書き込みツールの「常に許可」を使える設定はオフです。

Autoは各操作を実行前に点検しますが、「常に許可」は点検なしに承認を省くだけです。Autoには実行前の点検があり、「常に許可」にはありません。

導入初期の組織では、Autoだけを使えるまま運用を始め、定型の書き込みが増えてから「常に許可」を開けるかを部門ごとに決める順序が選べます。どこまで開けるかは組織のリスク許容度で決まり、一律にオンへ寄せることが正解とは限りません。

承認ゲートを見直す手順と、判断の記録の取り方

接続先やScheduled Tasksで自動化する業務が増えるたびに、操作の性質は変わります。新しいタスクを足すときは、既存のゲートに合わせて何となく決めず、そのタスクだけを評価し直す手順を入れると、強すぎる・弱すぎるゲートが放置されません。

手順

新しいタスクを足すときの見直し手順

  1. 1

    読み取りと書き込みに分ける

    タスクが呼ぶコネクタのツールを、読み取りと書き込みに仕分けます。書き込みが1つでもあれば、組織設定の影響を受けます。

  2. 2

    書き込みを4軸で評価する

    取り消しやすさ、金銭・契約、社外への影響、定型度の順に当てはめます。致命的な軸が1つでもあれば強い側に置きます。

  3. 3

    モードとの組み合わせを確かめる

    「要承認」で止めたい操作が、Skipで実行される経路に乗っていないかを見ます。誰が使っても止めたい操作はブロックに寄せます。

  4. 4

    実行後に承認の記録を見る

    想定外の範囲まで承認なしで進んでいたら、ゲートを強める側に直します。

実行後の記録は、OpenTelemetryで取れます。Team・Enterpriseの管理者は、Coworkのイベントを監視基盤やSIEMへ流せます。ツール呼び出し、ファイルアクセス、人による承認の判断などが対象で、承認ゲートが実際にどう働いたかを後から数えられます。ただし、コンプライアンス用の監査ログの代わりにはなりません。

Claude・Claude Desktop・Claude Mobile経由のCoworkセッションは、Compliance APIにも記録されます。ローカルセッションの会話履歴は利用者のコンピューターに保存され、管理者が一括で管理・削除することはできません。Enterpriseの管理者はCompliance APIで内容を取得できますが、ローカルセッション用の削除エンドポイントはまだありません。この違いは、承認の記録をどこまで追えるかに関わります。

調査は常に許可、作成だけ承認制にする実例はDatadog×Coworkのアラート閾値調整で扱っています。

まとめ

承認の強さは、モード・ツール権限・組織設定の掛け合わせで決まり、Skipでは「要承認」が効かない一方、ブロックはどのモードでも残ります。設計の起点は、タスクの中の書き込みを1つずつ取り出して4軸で評価することです。

この記事を共有:XはてブLinkedIn