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

Coworkが「対外メール送信」や「顧客データベースへの書き込み」のような取り消しにくい操作をどこまで自律的に進めるかは、個人が選ぶ承認モードだけで決まりません。Connectorを増やし、Scheduled Tasksで自動化する業務が広がるほど、承認ゲートをどう設計するかが運用の安全性を左右します。Team・Enterpriseでは、組織側の設定がもう1層重なり、個人設定より組織設定が優先される場面があります。ここでは承認ゲートを業務の性質に合わせて設計するための判断軸と、組織設定が個人設定をどう上書きするかを見比べます。承認モード自体の挙動はCowork自動承認モードとはに詳しいので、モードの中身から知りたい場合はそちらを先に読むと理解が早くなります。

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

Coworkの承認は、個人が選ぶモード(Manual・Auto・Skip)と、コネクタごとのツール権限(常に許可・要承認・ブロック)の掛け合わせで結果が決まります。ここまでは個人アカウントでも設定できる範囲です。Team・Enterpriseでは、これに組織設定がもう1層重なります。

組織設定「Organization settings > Cowork(Permissions配下)」には、書き込み可能なコネクタツールについて、メンバーが個人の判断だけでタスクごとの承認を省略できるかを管理者側で決める項目があります。この設定は既定でオフです。オフの状態では、コネクタ側の権限を「常に許可」にしていても、Coworkの承認ダイアログで「すべてのタスクで許可」という選択肢がグレーアウトして選べません。すでに保存していた「常に許可」の設定も反映されず、この組織設定がオンになるまで、メンバーは書き込み系のツールをタスクごとに承認し続けることになります。

読み取り専用のツールはこの制限の対象外ですが、それはコネクタ側が「読み取り専用」だと明示的に注釈している場合に限られます。多くのカスタムコネクタはこの注釈を持たないため、実際にはほとんどのツールが組織設定の対象に入ります。なお、ファイルの完全削除だけはこの階層と関係なく、モードや組織設定にかかわらず常に明示的な許可(Allow)を求められます。

Enterpriseプランでは、この組織設定はカスタムロールによる権限付与とも重なります。両者が競合する場面では、より制限の厳しい側が優先されます。ロール側で許可を広げても、組織設定側の制限を上書きすることはできません。承認ゲートを設計するときは、個人のモード設定だけでなく、この組織設定とロール設計の3つを同時に見る必要があります。ロール設計の具体的な手順はClaude CoworkのRBAC運用にまとめています。

なお、Coworkに同梱されるプラグインには、コネクタのような個別の承認トグルは用意されていません。Cowork自体を組織で有効にするかどうかの管理者設定に含まれる形で扱われるため、プラグインだけを個別に許可・制限したい場合でも、コネクタ側のような粒度の細かい設定はできない前提で棚卸しする必要があります。

なお、個人が選ぶモードのうちAutoはPro・Maxプラン向けの設定で、Team・Enterpriseでは選択肢に含まれません(Cowork自動承認モードとは参照)。Team・Enterpriseで承認ゲートの強弱を作る手段は、コネクタごとのツール権限(常に許可・要承認・ブロック)と、組織設定・ロール設計の組み合わせになります。

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

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

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

4軸は独立して効くのではなく、組み合わせで強弱が決まります。頻度と定型度が高くても、金銭・契約への影響が大きい操作は強めのゲートを外せません。逆に、取り消しにくい操作でも社外への影響が一切ない社内限定の作業であれば、コネクタ側の権限を緩めても実害が小さい場合があります。4軸を機械的に足し合わせるのではなく、どの軸が該当業務にとって致命的かを先に見極めることが設計の起点になります。

具体例で見る設計プロセス — 経理部の月次レポート自動化

取り消しやすさ・金銭や契約への影響・社外への影響・頻度と定型度の4軸を実際にどう当てはめるかは、具体的な業務で追うと分かりやすくなります。経理部がQuickBooksの月次残高を要約してSlackに投稿するScheduled Taskを作る場面を例にします。

まず取り消しやすさを見ます。この業務は残高の閲覧と要約だけで、書き込み・削除を含みません。誤りがあってもレポートを再生成すれば済むため、この軸では「弱めてよい」側に入ります。次に金銭・契約への影響です。数字を扱う業務ですが、支出や送金そのものは発生しないため、直接の金銭リスクはありません。社外への影響も、投稿先が社内Slackチャンネルに限られるなら小さいままです。頻度と定型度は、毎月同じ形式で繰り返す定型業務にあたります。

4軸のうち3軸が「弱めてよい」側に寄るため、このタスクはQuickBooksコネクタの読み取り権限を「常に許可」にしてよい候補です。組織設定の「常に許可」トグルがオフのままだと、この読み取り専用のタスクでもタスクごとの承認を求められてしまうため、経理部のような定型レポート業務が多い部署ほど、読み取り専用ツールに限定してこのトグルをオンにする判断が効いてきます。

一方で、同じQuickBooks接続を使って請求書を発行する別のタスクを追加する場合は、支出確定に関わる書き込み操作が入るため、軸の評価がまるごと変わります。同じコネクタ・同じ部署でも、操作の中身が変われば承認ゲートの強さも変えるという判断が必要になります。この操作はコネクタ側の権限を「要承認」に固定し、組織設定の「常に許可」トグルをオンにしていても対象から外すべき業務です。読み取り専用のレポート業務と、書き込みを伴う請求書発行を同じコネクタ・同じ承認設定でひとまとめにしないことが、この例から得られる実務上の教訓です。

部門別の設計パターン

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

経理・購買では、支出確定や請求処理が絡む操作が中心になります。QuickBooksやPayPalのような会計・決済系コネクタは書き込み権限を「要承認」に固定するのが手堅い設計です。読み取り専用のレポート集計だけは、組織設定の「常に許可」トグルをオンにして委ねても実害が小さい部分です。

営業・CRMでは、リード情報の閲覧やパイプラインの要約のような読み取り中心の作業と、顧客データベースへの書き込みが混在します。閲覧・要約はコネクタ側の読み取り権限を「常に許可」にして回し、CRMへの書き込みだけ「要承認」に切り分けると、日常業務のスピードを落とさずに書き込みだけ人の目を挟めます。

マーケティングは、コンテンツ生成や分析レポートの作成が中心で、社外への影響は公開前のドラフト段階に限られることが多い部門です。ドラフト作成まではコネクタ側の権限を緩め、実際の公開・配信操作だけ「要承認」に切り替える二段構えが業務の速度と安全性を両立しやすい形です。

人事は、個人情報を扱う頻度が高く、対象データの機微度が他部門より高くなりがちです。データの機微度が高い部門では、コネクタ側の権限そのものを絞り、組織設定の「常に許可」もオフのままにして、書き込み系の操作をすべてタスクごとの承認に固定しておくのが無難です。Coworkが扱うデータの保存場所やアクセス範囲そのものを確認したい場合は、Coworkセキュリティでプラン別・実行方式別の扱いを整理しています。

なぜ組織設定の既定はオフなのか

組織設定が既定でオフになっているのは、導入初期の事故を避ける設計だと読めます。オンにする判断を組織側に委ねることで、Coworkを初めて触るメンバーが書き込み系の操作を無自覚に自動化してしまう事態を防いでいます。運用に慣れたチームから段階的にオンへ切り替えていく想定に見えますが、この判断は各組織のリスク許容度に依存するため、一律にオンへ寄せる選択肢だけが正解とは限りません。

承認ゲートは一度決めて終わりにしない

部門別の設計パターンは、最初に決めた形のまま固定するものではありません。QuickBooksやHubSpotのような接続先が増えたり、Scheduled Tasksで新しい定型業務を自動化したりするたびに、対象となる操作の性質が変わります。新しいタスクを追加するときは、既存のゲート設定に合わせて何となく決めるのではなく、そのタスクだけを4軸で評価し直す手順を挟むと、いつの間にか強すぎる・弱すぎるゲートが放置される事態を防げます。

見直しのきっかけとしてわかりやすいのは、承認プロンプトが出る頻度です。特定のタスクで承認プロンプトが毎回同じ内容で出続けているなら、そのタスクは定型度が高く、ゲートを弱めても実害が小さい候補です。逆に、承認なしで進めていた操作が想定外の範囲まで広がっていることに気づいたら、ゲートを強める側に見直すタイミングです。

まとめ

Coworkの承認は、個人のモード設定・コネクタ側のツール権限・組織設定の3つが重なって最終的な挙動を決めます。承認ゲートを設計するときは、取り消しやすさ・金銭や契約への影響・社外への影響・頻度と定型度の4軸で業務を分類し、部門ごとにモードと組織設定を使い分けるのが実務的です。組織設定を管理する立場のTeam・Enterprise管理者と、承認モードを自分で切り替える一般メンバーの両方が、この2層構造を理解しておく必要があります。

経理・購買は書き込み系を「要承認」に固定し、営業・CRMは閲覧と書き込みで権限を切り分け、人事は機微データを扱う操作を組織設定のオフのまま据え置く、というように部門ごとの重心は異なります。どの部門でも、承認プロンプトの頻度や想定外の操作範囲の広がりを手がかりに、該当タスクだけを4軸で評価し直すのが実務的な起点になります。