Claude Coworkのプラグインを、誰に・どれを・どこまでの権限で配れば、「便利だが事故らない」状態で組織と個人に入れられるのか。これは接続先の多さの問題ではなく、権限をどこで絞るかという設計の問題です。
私は、Coworkプラグインは「接続先の多さ」で選ぶものではなく、まず権限を絞る側から設計すべきだと考えています。境界は3本だけ引きます。組織配布は既定をNot availableにする「デフォルト拒否」から始める。Local MCPを含むプラグインは、配布元がAnthropic公式か自社内製でない限り組織には配らない。そして送信・投稿・支払い・契約操作の前には必ず人間承認を残す。個人の試用はこの逆で、小さなフォルダ・読み取り限定から広げます。これは公式仕様から導ける既定線であって、業種や体制によって覆るならそれでいい、という境界付きの立場です。
私自身、新しい接続やプラグインを見るとき、最初に気にするのは「何ができるか」ではなく「何が読める・書ける状態になるか」です。便利さは後からいくらでも足せますが、広すぎる権限を最初に許可してしまうと、後から絞り込むのは心理的にも運用的にもコストが高くなります。だからこそ、最初の一歩は常に一番狭い設定から、という順序を崩さないようにしています。
2026年5月は、金融・法務・小規模事業者向けのプラグインが立て続けに発表され、組織配布の仕組みも整った月でした。選択肢が増えるほど、選定と権限設計が現場の判断力に追いつかなくなる、という感覚があります。この記事は、2026年5月18日時点のAnthropic公式ヘルプ、Claude公式ページ、Claude Code docs、GitHub上の公式プラグイン、X/Redditの利用者反応を確認して整理した、そのための素振りです。
なお、Coworkのプラグイン機能自体は、有料プランでCoworkを利用しているユーザー向けの機能です。個人アカウントでも、Pro/Maxなどの有料プランでCoworkが使える契約であれば、以下の内容は同様に当てはまります。
Redditでの利用者の反応を見ると、関心は機能の有無より運用の細部に向いています。プラグインがどこに保存され何が実体として増えるのか分かりにくいという声、秘密情報やAPIキーの扱いへの不安、GitHub同期やMarketplaceの挙動が想定通りに動かないという報告、候補が多いなかでの選定と権限設計そのものへの戸惑い、そして公式デモで見せられる体験と実際に自分の環境で動かしたときの体験との乖離を指摘する声が目立ちます。いずれも「機能があるかどうか」ではなく「安全に運用できるかどうか」に関心が寄っている点は、この記事が権限境界から書き起こしている理由と重なります。
Coworkの拡張を読むときに、まず区別しておきたい概念が2つあります。
接続面 vs 実行パッケージ。コネクタは、外部サービスに「届くための面」でしかありません。プラグインは、スキル・コネクタ・サブエージェントを業務単位で束ねた「実行パッケージ」です。プラグインを見るときは名前でなく、増えるスキル・前提コネクタ・含む操作(読み取りか、作成・更新・送信まで含むか)・Local MCPの有無を、束として読みます。
権限境界(trust boundary)。「どこで実行されるか」(Anthropicのクラウド経由か、PC上のLocalか)と「どこまでの操作か」(読み取りか、送信・支払いまでか)の2軸で引く線です。この記事の判断はほぼすべて、この線をどこに引くかに還元できます。
この2つの区別を道具として、Coworkの部品を並べると次のようになります。
| 要素 | 役割 | どこで見るか | 注意点 |
|---|---|---|---|
| プラグイン | 業務ごとの実行パッケージ | Customize > Browse plugins | スキル、コネクタ、サブエージェントを含みうる |
| コネクタ | 外部サービスへの接続面 | Customize > Connectors | 権限範囲は接続先サービス側の権限に依存する |
| スキル | 繰り返し使う手順や指示 | / または + メニュー | プラグインを入れるとスキルが増える |
| Remote MCP | インターネット越しのMCP接続 | コネクタ設定、組織設定 | Anthropicのクラウドから到達できる必要がある |
| Local MCP | PC上で動くMCPサーバー | プラグイン内、Desktop設定 | 信頼できる配布元だけに絞る |
一番重要なのは、Coworkがデスクトップアプリでも、コネクタ接続はPC内だけで完結しないことです。公式ヘルプでは、CoworkのコネクタはAnthropicのクラウド経由で外部サービスへ届くと説明されています。つまりRemote MCPは、社内LAN内に置いたサーバーをそのままつなぐ仕組みではありません。
プラグインまわりは動きが速いので、固定の「対応サービス一覧」より、用途別の広がりを俯瞰しておく方が安全です。
| 領域 | 2026年5月時点の見方 | 権限境界の勘所 |
|---|---|---|
| 金融 | 金融分析、投資銀行、株式調査、PE、ウェルスマネジメント向けの公式プラグイン群がある | データプロバイダー契約、APIキー、専門家レビュー |
| 法務 | 契約、調査、訴訟、IP、コンプライアンス向けの接続とプラグインが広がっている | 守秘、監査、引用元、弁護士レビュー |
| 小規模事業者 | Claude for Small BusinessでQuickBooks、PayPal、HubSpot、Canva、Docusign、Google Workspace、Microsoft 365などを束ねる | 支払い・送信・投稿前の承認境界 |
| 組織配布 | Team/EnterpriseでMarketplace、GitHub同期、必須インストール、非表示、グループ別制御が使える | CoworkとSkillsの有効化、配布責任者、同期失敗時の戻し方 |
以下、個別のケースを見ていきます。
個人で試す場合、基本の流れは次の通りです。
Customizeを開くBrowse pluginsでプラグインを探すInstallする/または+から追加されたスキルを呼び出すCustomizeで、自分の業務に合わせて調整するこの導線で見るべきなのは、名前ではなく中身です。どのスキルが増えるか、どのコネクタを前提にしているか、Local MCPを含むか、個人で追加したものか組織管理のものか、読み取りだけか作成・更新・送信まで含むか。5つとも、さきほどの「実行パッケージを束として読む」の実践です。
Google Driveは代表的な接続先ですが、Drive単体で見るより、Coworkタスクの文脈に資料を持ち込む接続面として考える方が実務的です。議事録や提案書を要約する、GmailやCalendarの文脈と合わせて会議前の論点を整理する、共有フォルダの資料からレポート下書きを作る、といった使い方です。
ここでの注意点は、Driveとつないだから全社の資料が見えるわけではないことです。Claudeから見える範囲は、接続したアカウントとGoogle Workspace側の権限に依存します。最初は、個人フォルダや小さな共有フォルダだけで試してください。
前述のRedditでの利用者の声にもあったように、コネクタがどこまでの範囲を見ているのか、検索精度がどこまで信頼できるのかが分かりにくいという指摘は珍しくありません。依頼の対象範囲を曖昧にしたまま「全社のDriveから」のような指示を出すと、権限の壁で見えていないだけなのか、検索が拾いきれていないだけなのか、結果からは区別がつかない場面が起こり得ます。だからこそ、対象フォルダやファイル名を具体的に絞った指示から始める方が安全です。
Google Driveの「Q2 Review」関連資料だけを対象にしてください。
資料名、更新日、要点、確認すべき数字、来週の会議で聞くべき論点をMarkdown表でまとめてください。
ファイルの移動、削除、外部送信はしないでください。
Microsoft 365は名前が広いため、特に誤解が起きやすい領域です。少なくとも、Outlook・OneDrive・SharePoint・Teamsに届く「Microsoft 365コネクタ」、Officeアプリ内での編集・生成体験である「Claude for Excel / PowerPoint」、営業・金融・法務などの流れに合わせてM365情報を使う「プラグイン側の業務パッケージ」の3つは別物です。
「Microsoft 365対応」と書かれていても、メール送信、Excel編集、SharePoint更新、Teams投稿がすべて同じ条件で使えるとは限りません。接続カードと管理者設定で、実際に使える操作を確認する必要があります。
2026年5月時点では、Claude Coworkのプラグインは一般的な仕事術だけでなく、かなり縦割りの業務に広がっています。
金融向けでは、公式ヘルプでFinancial analysis、Investment banking、Equity research、Private equity、Wealth managementが案内されています。中核のFinancial analysisプラグインは比較会社分析、DCF、LBO、3表モデルなどを扱い、Daloopa、Morningstar、S&P Global、FactSet、Moody's、LSEG、PitchBookなどのデータ接続を前提にできますが、これらは別途契約やAPIキーが必要な場合があります。出力をそのまま意思決定に使わず、モデル・前提・数値・出典を人間が確認する運用は必須です。
法務向けでは、Claude公式の法務ページでiManage、NetDocuments、Docusign、Ironclad、Thomson Reutersなどへの接続や、商事法務・企業法務・知財・訴訟などの領域別プラグインが案内されています。ここでの価値は文書をつなぐこと自体ではなく、契約書・判例・社内プレイブック・相手先情報を同じタスクの文脈に置き、レビューとドラフトの速度を上げることです。ただし最も慎重に扱うべき領域でもあり、引用元・守秘義務・アクセス権・監査証跡・弁護士レビューが前提になります。
小規模事業者向けでは、2026年5月13日に発表されたClaude for Small Businessが、QuickBooks、PayPal、HubSpot、Canva、Docusign、Google Workspace、Microsoft 365などを束ね、給与計画、月次締め、請求リマインド、キャンペーン作成などを扱います。ここで大事なのは、送信・投稿・支払いの前に人間が承認する境界です。公式発表でも、タスクやワークフローは利用者が開始し、送信・投稿・支払いの前に承認すると説明されています。
Team/Enterpriseでは、個人がバラバラにプラグインを追加するだけでなく、所有者がMarketplaceで配布を管理できます。配布状態は4つ(Installed by default・Available for install・Not available・Required)、追加方法は2つ(ZIP手動アップロード・GitHub同期)です。GitHub同期はprivate/internal repo前提でgithub.comのみ、同期には最大30分かかる場合があり、同期失敗時にプラグインが一時的に消えたり設定の再確認が必要になったりします。
同期に最大30分かかる、失敗時にプラグインが一時的に消えうるという仕様は、組織配布を任される側にとって軽視できない制約です。同期中や失敗直後に利用者から「プラグインが消えた」という問い合わせが来ても、実際には同期の遅延や一時的な失敗であることが多く、配布責任者はこの仕様を前提に、問い合わせへの初動対応を決めておく必要があります。
Enterpriseのグループ別制御には、見落としやすい仕様があります。複数グループに所属する人には、最も許可が広い設定が適用されるのです。優先順位はRequired > Installed by default > Available for install > Not available。あるグループでNot availableにしても、別グループでInstalled by defaultなら、より許可が広い方が勝ちます。
ここまでの事実を、業務領域ではなく「権限をどう絞るか」という軸で並べ直すと、3本のレバーが見えてきます。
レバー1: グループ優先順位から導かれる、デフォルト拒否設計。複数グループ所属時は最も広い権限が勝つという仕様がある以上、部分的な禁止は信頼できません。完全に止めたいプラグインは、グループ上書きではなく組織全体でNot availableにしたうえで、必要なグループだけに許可する設計にする必要があります。これは「グループ制御が安全境界にならない」という事実の裏返しです。
レバー2: Remote MCPとLocal MCPの信頼境界。Remote MCPは公開エンドポイント・OAuthスコープ・外部サービス操作がリスクで、先に見るべきはAnthropicのIPから到達できるかどうかです。Local MCPは自分のPC上で通常アプリと同等の権限で動きうるため、リスクの中心はPC上のファイル・プロセス・認証情報への接近であり、先に見るべきは配布元・権限・中身です。組織利用では、この2つを同じ「MCP対応」として扱うことが、一番の事故の元になります。
レバー3: 送信・投稿・支払い・契約操作の前の承認境界。金融・法務・小規模事業者向けの各プラグインに共通するのは、この承認境界がどこに引かれているかです。Claude for Small Businessの公式発表でも、タスクは利用者が開始し、送信・投稿・支払いの前に承認するという境界が明示されています。縦割り業務が増えるほど、このレバーの有無が便利さと事故りやすさの分かれ目になります。
3本のレバーを踏まえて、私が実際に引く境界線は次の3つです。
Not availableにしてから、必要なグループにだけ許可する。この3本の境界線は、私自身の実運用での失敗事例から導いたものではなく、公式仕様に書かれている挙動(グループ優先順位、Local MCPの権限範囲、承認フローの明示)を素直にたどれば導ける既定線として述べています。事故が起きてから絞るより、起きる前提で狭く始める方が合理的だという立場です。
これは公式仕様から導ける既定線であって、絶対的な正解ではありません。業種や体制によって覆るなら、それでいいと思っています。
最後に、命令ではなく判断材料としてチェックリストを置きます。プラグインやコネクタを入れる前に、対象業務・接続先・承認者・ログ・禁止操作を先に決めてください。特に金融、法務、人事、顧客情報、契約、支払いに関わる用途では、「便利そうだから入れる」では足りません。
| 確認項目 | 見ること |
|---|---|
| 配布元 | Anthropic公式、社内管理、信頼できる相手か |
| 操作範囲 | 読み取りだけか、作成・更新・送信・削除まで含むか |
| 接続先 | Google Drive、Slack、Docusign、会計、CRMなど何に届くか |
| 権限 | OAuthスコープ、管理者承認、接続先サービス側の権限 |
| Local MCP | PC上で何が動くか、不要なら無効化できるか |
| Remote MCP | 公開サーバー、認証、ログ、ツール変更時の監視 |
| 監査 | Coworkの作業内容をどこまで追えるか。必要ならOpenTelemetryを検討する |
| 承認 | 送信、投稿、支払い、契約操作の前に人間確認を残すか |
このチェックリストは、私が引いた3本の境界線を、あなたの組織や業種に合わせて調整するための材料です。どこで線を引くかは、最終的にはあなた自身の判断に委ねられます。
本記事は2026年5月18日に、公式Help Center、Claude公式ページ、Claude Code docs、GitHub上の公式プラグイン、X/Reddit上の利用者反応を確認して更新しています。