Claude Cowork を統制・管理する方法 — 組織設定・MDM・OpenTelemetry の 4 層で考える

Cowork は 2026 年 4 月 9 日に全有料プランで一般提供になり、同時にエンタープライズ向けの管理機能（グループ・カスタムロール・支出上限・利用分析・OpenTelemetry）が拡充されました。統制の各論に入る前に、押さえるべき前提が 1 つあります。Cowork のセッションには実行場所の異なる 2 種類があり、この区別が履歴の保存先・監査手段・監視の可視性のすべてを決める、ということです。

つまり「デスクトップ中心で使わせるなら、テレメトリを設定しない限り組織には何も残らない」が出発点です。これを踏まえて、統制を 4 つの層で見ていきます。

組織側の設定は管理コンソールの Organization settings > Cowork に集約されています。最上位のスイッチは「Enable for your organization」で、組織全体の有効/無効を切り替えます。ここからの粒度がプランで異なります。

• Team — 有効/無効は組織一括のみ（部署別の出し分けは不可）。
• Enterprise — グループ（手動または ID 基盤からの SCIM 同期）とカスタムロールを組み合わせて、特定のチームだけに Cowork を有効化できる。

クラウドセッション（「Run Cowork in the cloud」トグル）は既定値がプランで逆です。Team は既定で有効（オーナーがいつでも無効化可能）、Enterprise は既定で無効で、オーナーが有効化したうえでカスタムロールにより付与します。Enterprise で「Web から Cowork が使えない」という問い合わせが来たら、まずこの既定値を疑ってください。

次に承認ポリシーです。Organization settings > Cowork > Permissions の「Allow 'Always allow' for connector tools」トグルは、書き込みを伴うコネクタツールについて、メンバーが「全タスクで許可（毎回の承認をスキップ）」を選べるかどうかを組織として決めます。オフにすると常に都度承認になります。読み取り専用ツールは、コネクタ側が明示的に読み取り専用と注釈している場合のみ承認なしで実行されます。さらに Enterprise 向けの管理機能として、コネクタ内の特定アクションだけを組織全体で制限する per-tool 制御（例: 読み取りは許可し書き込みは無効化）も提供されています。

• プラグイン — オーナーがプラグインマーケットプレースを作成し、「Installed by default / Available / Required / Not available」の 4 段階で配布を制御。Enterprise ではグループ別に出し分け可能。
• ネットワークアクセス — Organization settings > Capabilities の Code execution 設定でセッションの外部接続先を制御。変更は新規セッションから適用され、進行中のセッションには及ばない。なお web fetch / web search ツールはこのネットワーク設定の対象外。

組織設定はサインイン後の世界の話です。その手前、デバイス側の統制は Claude Desktop の管理ポリシー（Team / Enterprise の管理者向け）で行います。macOS はドメイン com.anthropic.claudefordesktop の構成プロファイル（Jamf Pro・Kandji・Intune など）、Windows はグループポリシーまたは Intune でマシン単位（HKLM）／ユーザー単位（HKCU）のレジストリに配布します（マシン単位が優先）。

実務でまず入れるべきは forceLoginOrgUUID と allowedWorkspaceFolders の 2 つです。前者は「組織の統制が及ばない個人アカウントで Cowork が動く」経路を塞ぎ、後者は万一の誤操作やプロンプトインジェクション時の影響範囲をマウント可能なフォルダに限定します。MCP・拡張系のキーは、コネクタの統制を組織設定側（承認ポリシー）でやるかデバイス側で全面的に止めるかの選択です。

Cowork はエージェントとして自律的にツールを回すぶん、Chat よりトークン消費が読みにくい機能です。コスト統制の手段はプランのコストモデルに従います。Enterprise（usage-based）では利用が最初の 1 トークンから従量課金されるため、管理コンソールからグループ単位の支出上限を設定して歯止めをかけます（チームごとに予算を割り当て、導入の進み方に応じて調整する運用）。Team では定額シートの利用枠に内包され、枠超過は usage credits 側の組織・メンバー別上限で制御します。プラン自体の選び方は姉妹記事「Claude Team と Enterprise、どちらを選ぶべきか」を参照してください。

利用の把握には 2 つの公式手段があります。管理ダッシュボードには Cowork のセッション数とアクティブユーザーが期間別に表示され、Analytics API ではユーザー別の Cowork アクティビティ、スキル・コネクタの起動回数、DAU/WAU/MAU を、Chat・Claude Code のデータと並べて取得できます。定期レポートを組むなら Analytics API、リアルタイムの実行内容まで追うなら次節のテレメトリ、という使い分けです。

監査・監視の公式チャネルは 2 つです。まず Compliance API（Enterprise）。かつて Cowork は対象外でしたが、現在は Web・モバイルのクラウドセッションが Chat と同じ監査トレイルに載り、各セッションを個々のユーザーに帰属させて取得できます。SIEM・DLP 連携もこの経路に乗ります。

ただし冒頭の前提のとおり、ローカルのデスクトップセッションは Compliance API の対象外です。会話履歴は端末ローカルに保存され、標準のデータ保持ポリシーが適用されず、管理者が中央から管理・エクスポートすることもできません。ローカルセッションを組織として観測できる公式チャネルは、次節の OpenTelemetry だけです。

Cowork の OpenTelemetry エクスポートは Team・Enterprise プランで利用できます。バージョン要件は、ローカルセッションが Claude Desktop v1.1.4173 以降、クラウドセッション（Web・モバイル）の取り込みが v1.22209.3 以降です。設定は管理者が Organization settings > Cowork で行い、入力するのは次の 3 項目だけです。

OTLP endpoint:   https://collector.example.com     # コレクタの URL
OTLP protocol:   HTTP/protobuf                      # または HTTP/JSON（gRPC は不可）
OTLP headers:    Authorization=Bearer <token>       # 認証ヘッダー（保存時に暗号化）

重要な性質が 2 つあります。第一に、エンドポイントを設定しない限りデータは一切送信されません（既定は無送信）。第二に、送信されるのはメトリクスの数字だけではなく、セッションの実行内容そのものです。

• ユーザープロンプトの全文
• ツール・MCP 呼び出し — サーバー名・ツール名・パラメータ・成否・実行時間
• ファイルアクセス — 読み取り・変更したパス
• スキル・プラグインの起動
• 承認判断 — ユーザーが承認したか・拒否したか・既存の許可により自動実行されたか
• リクエスト単位のモデル・トークン数・概算コスト・所要時間・エラー

各イベントは共通の prompt.id 属性で紐付くため、「この指示から何が実行されたか」を 1 本のトレイルとして再構成できます。属性にはユーザーのメールアドレスが含まれ、誰の操作かを特定できます。Splunk や Cribl などの SIEM・ログ基盤にそのまま流せて、Compliance API とはユーザー識別子で突合しながら並行運用できます。

ここまでの 4 層を、実際の展開順序に落とすと次のようになります。ポイントは、観測（OpenTelemetry）を展開より先に入れることです。テレメトリは設定した時点以降しか記録されないため、後から入れると導入初期の利用実態——本来いちばん見たいデータ——が永久に欠けます。

1. ポリシーを決める — 誰に許すか（Enterprise ならグループ設計から）、クラウドセッションを許すか、コネクタの「Always allow」を認めるか。
2. MDM を先に配る — forceLoginOrgUUID で組織アカウントを強制し、allowedWorkspaceFolders でマウント可能なフォルダを限定。Cowork を許可しない端末群には secureVmFeaturesEnabled を false に。
3. OpenTelemetry を設定する — Organization settings > Cowork にエンドポイント・プロトコル・認証ヘッダーを入力し、テスト用ユーザーでイベントが届くことを確認。
4. 組織設定で有効化する — Team は一括、Enterprise はパイロットのグループから。クラウドセッションの既定値（Team: 有効 / Enterprise: 無効）を意図どおりか確認。
5. 承認ポリシーは厳しめに始める — 「Always allow」を許可せず都度承認で開始し、運用が回り始めてから緩める。逆方向（緩→厳）は反発が大きい。
6. 支出と利用を見る — ダッシュボードと Analytics API で利用の分布を、テレメトリで実行内容とコストを確認し、グループ支出上限や許可範囲を調整。

Claude Code をすでにテレメトリで統制している組織なら、3 の手順は送信先を流用するだけです。まだの場合は、Claude Code 側の統制も含めて姉妹記事「Claude Code のコストガバナンス」で実装手順を解説しています。