「ChatGPT Enterprise は契約しているが、現場部門が”自分の業務に AI をどう繋ぐか”で止まっている」——4 月以降、こうした相談が一気に増えています。背景には Anthropic が 2026 年 4 月 9 日に Claude Cowork を全有料プランへ拡大 したという大きな動きがあります。
Claude Cowork は単体の AI チャットではなく、SaaS のなかで動く AI エージェント実行基盤に位置付けられました。今回の GA で RBAC・SCIM・利用分析といった企業向け管理機能が一気に揃い、情シス側も「とりあえず触ってみる」段階を超えて、全社展開の設計責任を負うフェーズに入っています。本記事はその設計指針と、受託支援者として入るときのチェックポイントを整理します。
なぜ「Cowork で何ができるか」より「ロールアウト設計」が論点になるのか
Claude Cowork 自体の機能は、Anthropic 公式や AI ニュースサイトに大量の記事が出ているので、ここでは深追いしません。代わりに、現場で本当に詰まっているのは次の 4 点です。
- どの部門の、どの業務から開放するか（権限の段階導入）
- 既存 SaaS（Salesforce / Notion / Slack / Google Workspace 等）との接続方針
- プラグインを”配る”のか”作る”のか、そのガバナンス
- 利用分析データを誰が見て、誰が止めるのか
ChatGPT Enterprise や Microsoft Copilot の社内導入を経験した企業ほど、上記の論点に敏感です。「ライセンスは買ったが利用が伸びない」「逆に伸びすぎてコストが読めない」を経験しているからです。Cowork の導入もこの轍を踏まないことが第一目標になります。
弊社がサイバーエージェントの ChatGPT Enterprise 全社展開プレイブック を取り上げたのも同じ問題意識からでした。Cowork は「実行する AI」になった分、ガバナンス論点が一段増えています。
ロールアウトを 3 フェーズで設計する
受託で Cowork 導入を支援するときの標準スコープを 3 フェーズに分けると、合意形成がスムーズに進みます。
フェーズ 1: パイロット（4〜6 週間）
- 対象部門は 1〜2 部門・延べ 30〜50 名に絞る
- ロールは「Cowork User（一般）」「Cowork Admin（管理）」の 2 種類のみ
- プラグインは Anthropic 公式 + 既存 SaaS 公式の合計 5 つ以内
- 利用分析は週次レビュー、KPI は「業務カット時間」「タスク完了数」の 2 指標
このフェーズで一番効くのは、「使わない人を観測する」ことです。Cowork Admin で利用ログを見ると、立ち上がっている人と止まっている人の差がはっきり出ます。止まっている人へのフォローアップ設計が、後のフェーズ成功率を左右します。
フェーズ 2: 横展開（8〜12 週間）
- 部門数を 5〜8 に拡大
- SCIM 連携で Okta / Azure AD からプロビジョニング
- ロールを「VIEW / RUN / APPROVE / ADMIN」の 4 段に拡張
- 部門独自プラグインを 2〜3 本開発（後述）
このフェーズで、受託側の本領が問われます。部門独自プラグインの設計が、社内開発リソースだけでは捌けないからです。
フェーズ 3: 全社展開と内製化（12 週間〜）
- 全社員ロールアウト
- 内製チームへナレッジ移管（プラグイン開発・運用ガイドライン）
- 利用分析を BI に接続し、CFO レビュー対象に格上げ
ここで「受託 → 内製化の橋渡し」をどう設計するかが、長期パートナーとして選ばれるかどうかの分かれ道になります。
プラグイン開発を受託で取りに行く 3 つの型
Cowork の本当の価値はプラグインで決まります。受託で取りに行ける案件の型は、いまのところ次の 3 つに分類できます。
| 型 | 例 | 工数感 | 単価帯 |
|---|---|---|---|
| 既存 SaaS 連携型 | 自社の基幹系 ERP・人事 SaaS との連携 | 2〜4 週間 | 100〜300 万円 |
| 業務手順カプセル化型 | 「契約書レビュー → 法務 Slack 通知」など複数ツール横断 | 3〜6 週間 | 200〜600 万円 |
| ドメイン特化型 | 業界規制対応・特殊計算ロジックを内包 | 6〜12 週間 | 500〜1,500 万円 |
ドメイン特化型は、私たちが取り上げた MCP サーバー実装ガイド のノウハウと地続きです。Cowork プラグインの実体は MCP サーバー + ロール定義 + UI スキーマの組み合わせなので、MCP サーバーの設計経験がそのまま転用できます。
受託提案テンプレート（社内提案でも流用可）
クライアントの稟議や、社内の予算化に持っていくときは、次の構成で資料を組むとほぼ通ります。
1. 現状の AI 利用課題（ChatGPT Enterprise 等が"使われていない"事実の可視化）
2. Claude Cowork で解ける課題と、解けない課題の線引き
3. パイロット計画（対象部門・KPI・期間・概算費用）
4. ガバナンス設計（ロール・SCIM・監査ログ・コスト上限）
5. プラグイン開発ロードマップ（最初の 6 ヶ月で何を作るか）
6. 内製化マイルストーン（受託からの卒業計画）特に 6 番が重要です。「ずっと外に頼まないと回らない」提案は、Cowork のような変化が激しい領域では確実に嫌われます。「3 期目には情シス内製で運用できるようにする」を最初から書いておくと、稟議の通り方が変わります。
失敗パターンとリカバリ
過去半年で複数社の支援を見てきたなかで、繰り返し起きる失敗が 3 つあります。
- PoC を 100 名で始める：管理工数が爆発し、誰も責任を取れない状態に陥ります。30 名以内に絞り、Admin 1 名・伴走者 1 名の 2 人体制から始めるのが鉄則です。
- プラグインを社内 IT に押し付ける：MCP サーバー実装とユースケース設計は、まったく違うスキルです。少なくとも初回は外部の伴走を入れ、内製化はフェーズ 3 から計画的に始めるのが現実的です。
- コスト上限を設定しない：Cowork は実行型 AI なので、トークン消費が読みづらい局面があります。部門ごとの月次コスト上限を Admin で設定し、超過時は自動アラートにしておくのが必須です。
まとめ — Cowork は「導入支援案件」が量産される
Claude Cowork の GA は、AI 受託の景色を確実に変えました。これまで「ChatGPT API でツールを作る」という単発案件が中心だった領域が、「全社ロールアウト × プラグイン開発 × ガバナンス設計」という、より中長期の伴走案件に置き換わっていきます。
弊社では、Cowork のロールアウト支援・プラグイン開発・MCP サーバー実装をワンストップで提供しています。「PoC は終わったが横展開で詰まっている」「プラグイン開発を内製化したい」といった相談は、お問い合わせフォーム からお気軽にどうぞ。
