Claude Coworkのように、ローカルのファイルやSaaSを横断して複数ステップの仕事を任せられるエージェントを、他社サービスやオープンソース、オンプレミスで再現できるのか。データを外に出せない組織にとっては、導入の可否を左右する問いです。
結論を先に書くと、機能の「部品」は多くがOSSで揃います。ただし「何割再現できるか」「体験品質がどれだけ違うか」は、対象業務と検証構成を決めた比較をしないかぎり数字では言えません。そのうえで最も近い現実解は、Anthropic公式の「Claude Desktop on 3P」です。オフラインインストーラーを使えば、Anthropic運営ホストへの実行時通信をなくせます。一方で、推論はClaudeモデルが前提で、Claudeの推論を完全オンプレミスに置けることは公式資料から確認できません。
1. 先に結論
- Anthropicへの実行時通信は排除できます。3P版にはVMワークスペースとClaude CLIを同梱したオフラインインストーラーがあり、Anthropicへの接続なしでセッションを開始できます。自動更新とモデルカタログ取得を止めれば、必要な外向き通信は推論プロバイダだけになる、と公式の導入手順は説明しています。
- ただし「完全オンプレミスのClaude」は確認できません。自社ゲートウェイの公式説明はClaudeモデルの利用を前提としています。完全エアギャップが要件なら、3Pは「推論先に到達できる閉域」までが射程です。
- OSSでも主要機能は組めます。gooseのようにMCP拡張とサブエージェントを備えたものがあります。しかし権限UX、サンドボックス、監査、Office成果物の品質は自前で詰める部分が大きく、Coworkとの差は実測しないと分かりません。
- 国内ベンダーの閉域基盤は、推論とガバナンスの層として有力です。ただしCowork型の汎用デスクトップ体験そのものを提供するものとは、公式資料から読めません。
2. Coworkを5層に分けて考える
再現を検討するときは、「Coworkという製品」を丸ごと探すより、構成要素に分けたほうが見通しが立ちます。Coworkは、Anthropicが2026年4月9日に全有料プランで一般提供(macOS・Windows)を始めた機能です。
| 層 | 内容 | 再現するときの論点 |
|---|---|---|
| モデル | Claude系モデル | 長時間・多ツールのタスクを破綻なく進める能力。オープンウェイトで同等かは、業務ごとに測るしかない |
| エージェント・ハーネス | タスク分解、サブエージェント、承認フロー、Auto modeの安全審査 | OSSにも部品はあるが、承認と自動審査を一体で提供しているものは今回確認できなかった |
| 実行環境 | ローカルの隔離VM(標準版にはクラウド実行もある) | ローカル実行型OSSは隔離を別途用意する必要がある |
| 接続層 | MCPコネクタ、スキル、プラグイン、フック | MCP自体は標準規格で再現しやすい。配布と権限の統制が論点 |
| 管理層 | RBAC、グループ別の利用上限、OpenTelemetry、コネクタのツール単位制御 | ここが製品として揃っていないと、組織展開で最初に詰まる |
出典:Anthropic「Making Claude Cowork ready for enterprise」(2026年4月9日)。管理層の項目は同記事の記述による
3. 最も近い選択肢:Claude Desktop on 3P
3-1. 3Pとは何か
3Pは、Claude Desktopの推論をBedrock、Google Cloud、Microsoft Foundry、Anthropic Messages API互換の自社ゲートウェイなどに振り向けるデプロイモードです。課金はトークン従量で、席ごとのライセンスはありません。会話履歴は端末に保存されます。一方で、モバイル/Web、Anthropicクラウド上のセッション、ユーザー間の共有、音声モード、Claude Tag、Claude Securityは使えません。
| 機能 | 標準版Cowork | 3P版 |
|---|---|---|
| 実行場所 | Anthropicのクラウド、またはローカル | セッションはローカル(SSH経由のCodeを除く) |
| スケジュールタスク | クラウドで実行され、PCが停止していても動く | 対応。ただしローカル実行で、端末が起動・稼働している必要がある |
| ブラウザ操作 | 内蔵ブラウザとClaude in Chrome | 内蔵ブラウザは対応。Claude in ChromeはEnterprise Admin Consoleで管理する組織のみ |
| メモリ/プロジェクト | チャットとメモリを共有 | 両方に対応。メモリは端末保存で、チャット履歴検索と夜間要約は使えない |
| 自動承認(Auto mode) | 利用可能 | 管理者がautoModeEnabledをtrueにした場合に提供 |
| 管理 | 管理コンソール | Admin Console、MDM、ブートストラップサーバー、OTelエクスポート、MCP許可リスト |
出典:Anthropic公式「Features」(3P機能表)、標準版の記述はAnthropicのヘルプセンター。AWS公式ブログによれば、Computer Use、Skills Marketplace、Claude Designは3Pの対象外
機能表は、Webサーチについても条件を付けています。Bedrock経由、またはAnthropicのサーバーツールを転送しないゲートウェイでは、先にWebサーチプロバイダの設定が必要です。また、3PはクラッシュレポートとプロダクトアナリティクスをAnthropicへ既定で送ります。プロンプトや応答の内容は含まれず、管理設定で完全に無効化できると説明されています。
3-2. 閉域性は3段階に分けて評価する
「3Pは完全エアギャップ不可」と一括りにすると、実態を外します。要件を3つに分けると評価が変わります。
| 要件 | 評価 | 根拠・留保 |
|---|---|---|
| Anthropic運営ホストへの通信を禁止したい | 対応可能 | 標準インストールはVMワークスペース(1GB超)とClaude CLIをdownloads.claude.aiから取得する。オフラインインストーラーは両方を同梱し、チェックサム検証もアプリ内蔵。自動更新(disableAutoUpdates)とモデルカタログ取得(modelCatalogEnabledをfalse、またはミラー)を止めれば、必要な外向き通信は推論プロバイダだけになると説明されている |
| 許可した推論基盤だけに接続したい | 設計確認が必要 | オフラインでも推論エンドポイントへの到達性は必要。MCP、検索、監視、認証の通信先も含めて確認する |
| 外部の推論サービスにも接続しない完全オンプレミス | 公式対応を確認できない | ゲートウェイの公式説明はClaudeモデルの利用を前提としている |
出典:Anthropic公式「Installation and setup」(Offline installation)
構成の選び方でも差が出ます。Enterprise Admin Console経由の配布では、ユーザーはClaudeアカウントでサインインし、Anthropicがユーザー一覧と設定を保持します(プロンプトは推論プロバイダにのみ送られ、会話は端末に残るとされています)。どの端末もAnthropicへのサインインに依存させたくないなら、MDMプロファイルの配布が公式に示された選択肢です。
3-3. 「国内リージョン」は十分条件ではない
「国内リージョンのBedrockかGoogle Cloudを選べばよい」という整理には、追加の確認条件が要ります。
- 使うモデル、バージョン、推論方式で、国内処理が保証されているか
- クロスリージョン処理やフォールバック先を制限できるか
- 推論以外の通信先(MCP、Webサーチ、ブラウザ、監視、認証)はどこか
- 端末、ログ、バックアップ、運用者アクセスまで要件を満たすか
Microsoft Foundryは扱いが異なります。公式資料によれば、AnthropicがClaudeモデルを運用し、Microsoftの独立した処理者として会話データを扱います。BedrockとGoogle Cloudでは、データの扱いはそれぞれのクラウド事業者の規定に従います。データ在留が要件なら、経路ごとに評価してください。
3-4. ゲートウェイ経由で他モデルを使えるか
自社ゲートウェイ(LiteLLM、Portkey、自作プロキシなど)を推論先にするには、Anthropic Messages APIのPOST /v1/messages(ストリーミングとツール利用を含む)を実装する必要があります。モデルの自動検出は、Claudeと判別できるモデルIDだけを表示します。公式説明はClaudeモデルを前提としており、背後に非Claudeモデルを置いた場合の動作や品質は示されていません。この使い方は公式サポートの外と考えておくのが安全です。
出典:Anthropic公式「Deploy Claude Desktop on 3P with an LLM gateway」
4. 商用の競合:機能は重なるが、同等性は別の話
Coworkと機能が重なる商用製品は、2026年に相次いで登場しました。ただし、機能の重複があることと、同じ条件で同等に業務を完遂できることは別です。同一タスクでの比較検証は今回確認できていません。
| 製品 | 確認できた事実 | 留保 |
|---|---|---|
| Microsoft Copilot Cowork | 2026年3月9日に発表、6月16日に世界でGA(Microsoft公式)。GA時の変更一覧でOpus 4.8への対応が記載されている(Microsoft Learn) | Microsoft 365テナント前提。オンプレミス版は確認できない |
| ChatGPT Work(Codex統合) | 2026年7月9日に登場(OpenAI公式リリースノート)。文書・表計算・プレゼン生成と、スケジュール・トリガー・変更監視に対応 | Enterpriseでのトリガー条件など細部は別途確認が必要。SaaS前提で、オンプレミス版は確認できない |
| Gemini agent(Gemini Enterprise) | 2026年10月8日に発表(Google Cloud公式)。報道によれば発表時はプライベートプレビュー | 11月時点の提供段階は未確認 |
出典:Microsoft、Microsoft Learn、OpenAI、Google Cloud
5. オープンソース:部品は揃うが、ライセンスの読み分けが要る
5-1. 候補
gooseは、Apache 2.0のOSSで、Linux Foundation傘下のAgentic AI Foundation(AAIF)のプロジェクトです。デスクトップアプリ(macOS・Linux・Windows)、CLI、APIを備え、Ollamaを含む15以上のプロバイダと、MCP経由で70以上の拡張に対応します。サブエージェントの並列・逐次実行も公式文書に記載があります(GitHub)。ローカルで動く設計なので、隔離は別に用意する必要があります。
OpenWorkは、OpenCodeをベースにしたデスクトップアプリで、「Claude CoworkのOSS代替」を掲げています。開発元はDifferent AI, Inc.です。MIT部分とEE(Enterprise Edition)部分が混在する点に注意が必要です。
5-2. ライセンスの要点
「オープンソース」と書かれていても、OSI承認のOSSと、追加条件付きのsource-available/fair-codeが混在しています。
| 対象 | 区分 | 条件の要点 | 採用時の確認 |
|---|---|---|---|
| OpenWork | MIT部分とEE部分が混在 | EE部分の本番利用には有効なサブスクリプションが必要。例外は、Enterprise Featuresを除き組織全体で5ユーザー以下、初回デプロイから30日以内の評価、開発・テスト。各版は公開の2年後にMITで利用可能になる | 条文はdevブランチのもの。リリースタグと使う部位を固定して再確認する |
| Open WebUI | source-available(開発元の説明) | 任意の連続30日間に直接アクセスする自然人が50人を超える場合、ブランド変更に条件がある。権利者の個別の書面許可という経路もある | 利用規模とブランド変更の有無で判断 |
| n8n | fair-code | 非商用・個人利用は可能。コンサルティングや構築・保守サービスも許容される | 再販・埋め込みなど具体的な形態で判定する |
| Dify | Apache 2.0に追加条件 | マルチテナント運用とロゴ除去に条件があると説明されている | 対象タグのLICENSE条文で確認する |
出典:OpenWork EEライセンス、Open WebUI LICENSE、n8n
6. 国内の閉域基盤とセルフホストモデル
| 提供元・製品 | 確認できた内容 | 提供形態 | 留保 |
|---|---|---|---|
| NTTドコモビジネス+エクサウィザーズ「クローズドAIエージェント」 | 2026年8月17日提供開始。エクサウィザーズのexaBase Studioと、閉域ネットワーク・GPU基盤を組み合わせる。tsuzumi 2やOSSのLLMを専用環境で動かし、プロンプトは外部のAIサービスに送られないと説明。オンプレミス版はハードウェアからLLM、エージェントまでを国内の自社環境内で完結できるとされる | プライベートクラウド版、オンプレミス版。運用保守はNTTドコモビジネス | 申し込みは営業窓口経由。プロンプトインジェクション対策やガバナンス機能は「今後強化を推進」とされ、整備途上 |
| 富士通 Kozuchi Enterprise AI Factory | 製品ページによれば、LLMのTakane、PRIMERGY/Private GPT上の専用環境、追加学習、量子化、低コード/ノーコードのエージェント開発(MCP・エージェント連携)を備え、オンプレミスにも対応 | 専用環境(オンプレミス対応) | 提供開始日や導入実績は製品ページからは確認できない |
出典:NTTドコモビジネス ニュースリリース(2026年8月17日)、富士通 製品ページ
セルフホストできるモデルについては、「動く」という言葉の中身を確認する必要があります。
- tsuzumi 2は、NTT自身の資料で30B規模とされています。重みを16bitで持つと、30B × 2バイトで約60GBというのが筆者の単純計算です。「A100 40GB 1枚で動く」は、量子化方式、コンテキスト長、同時実行数の前提を付けないと仕様として扱えません。
- Qwen3.8-27Bは、公式モデルカードで27Bであることと長いコンテキストへの対応が確認できます。「4bitで17〜19GB」という数字は、ファイル容量なのか実行時メモリなのかが不明なので、構成設計の根拠にはできません。
- Kimi K3は、公式モデルカードで2.8Tパラメータとされています。単一GPU級ではなく、複数ノードの運用が前提になります。
- gpt-oss-120b/20bは、2025年8月公開でApache 2.0のモデルです。小〜中規模のGPUで運用しやすい一方、最前線のモデルとの差は用途次第です。
ベンチマーク値の多くはベンダーの公表値で、同一のハーネスで比べたものではありません。エージェントとしての採否は、自組織のタスクで測って決めてください。
7. 構成ごとの整理
下の表は、公式資料で確認できる機能の有無と、追加で作り込む部分を並べたものです。同一タスクでの成功率や成果物の品質を比べた結果ではありません。
| 構成 | 標準で揃う機能 | 追加構築が必要な点 | 閉域適合性 | 主な留保 |
|---|---|---|---|---|
| Claude Desktop on 3P | Cowork、Code、Chat。サブエージェント、スキル・プラグイン・フック、ローカル/リモートMCP、スケジュール(ローカル)、内蔵ブラウザ、MDM配布、OTel | 推論基盤(Bedrock、Google Cloud、ゲートウェイ)、Webサーチプロバイダ、IdPとMDM | オフライン版で運用時の外向き通信を推論先のみにできる。完全オンプレミスのClaude推論は確認できない | Computer Useなど一部機能は対象外。スケジュールは端末の稼働が条件 |
| 商用SaaS(Copilot Cowork、ChatGPT Workなど) | 各社のエージェント機能。文書・表計算・プレゼン生成、スケジュール | テナント設定、予算管理、権限設計 | SaaS前提。オンプレミス版は確認できない | 同一タスクでの比較検証は確認できない |
| goose+セルフホストLLM | デスクトップ/CLI/API、MCP拡張、サブエージェント、15以上のプロバイダ | サンドボックスによる隔離、承認ポリシー、スキル配布、監査ログ | 構成次第で完全閉域が可能。外部通信を遮断した実機試験が条件 | 長時間タスクとOffice成果物の品質はモデル依存で、検証が必要 |
| OpenWorkなど+セルフホストLLM | OpenCodeベースのデスクトップ、ローカルモデル対応 | EE条件の確認、隔離、統制機能 | 同上 | ライセンス条文の部位ごとの確認が必要。継続性は調達側で見極める |
| 国内閉域基盤+OSSフロント | 閉域/オンプレミスの推論と運用、日本語LLM、ベンダーによってはMCP・エージェント連携 | OSSフロントとの接続検証(OpenAI互換エンドポイントなど)、エージェントUX | NTTのオンプレミス版は国内の自社環境で完結と説明されている | Cowork型の汎用デスクトップ体験そのものではない |
8. 構成案
案A:公式Coworkの閉域クラウド版
Claude Desktopをオフラインインストーラーで配布し、MDMで設定します。推論は国内リージョンのBedrockまたはGoogle Cloud(3-3の確認条件を満たすこと)、必要ならLiteLLMなどのゲートウェイを挟みます。社内MCPサーバー、OTelコレクタ(SIEM連携)、egress許可リストを組み合わせます。再現度は最も高く、構築と運用の負荷は低〜中です。課金はトークン従量で、GPU投資は要りません。ただし、完全オンプレミスの要件は満たせません。
案B:完全閉域のOSSスタック
フロントにgooseかOpenWork、ゲートウェイにLiteLLM、推論にvLLMとセルフホストモデル、実行隔離にコンテナ/microVM型のサンドボックス、そして社内MCPサーバー、IdP、OTelとSIEMを置きます。完全エアギャップが可能な一方、モデル更新、評価、サンドボックス保守、MCPのセキュリティレビューを自前で回す体制が要ります。コストは、GPU、構築SI、運用人員が中心です。利用規模、稼働率、トークン量次第でクラウド従量課金と逆転する可能性はありますが、TCOを置いて試算しないかぎり、どちらが安いかは言えません(筆者の推定)。
案C:国内閉域基盤とOSSフロントのハイブリッド
推論とガバナンスに国内ベンダーの閉域基盤を使い、ユーザー接点にgooseなどをOpenAI互換エンドポイント経由で接続します。日本語、データ主権、保守体制は強みですが、汎用デスクトップ・エージェントのUXはOSS側に依存します。接続の検証が前提で、費用は個別見積になります。
9. 非機能面で見落としやすい点
- データの所在:3Pでは、会話履歴は端末に保存され、推論データの扱いは選んだプロバイダ(Bedrock、Google Cloud、Foundry、自社ゲートウェイ)で変わります。
- 監査・権限:Coworkには、OpenTelemetryのイベント(承認が手動か自動かも含む)、RBAC、コネクタのツール単位制御があります。OSSでは、こうした統制機能の多くを自前で実装するか、商用版を買う構図になりやすいと考えられます(OpenWorkのEE条件は一例です)。
- プロンプトインジェクション対策:CoworkのAuto modeの安全審査に相当するOSS機能は、今回の調査範囲では確認できませんでした。緩和策としては、承認を既定でオンにする、MCPツールを読み取り専用に絞る、egressを許可リストで制限する、サンドボックスで実行する、が現実的です。
- 日本語性能:tsuzumi 2やTakaneは日本語の強さを打ち出していますが、エージェントとしての横並びの公開評価は確認できていません。
- 調達上の判断:海外製、特に中国製のオープンウェイトモデルを使えるかは、所管の調達・セキュリティ方針に照らして判断する必要があります。
10. まとめ:進め方
閉域・オンプレミス環境でも、OSSのエージェント基盤、MCP、セルフホストLLM、実行サンドボックスを組み合わせて、Coworkと重なる主要機能を構成することは可能です。ただし、機能の再現割合やCoworkとの品質差は、対象業務と検証構成を定義した比較評価なしには定量化できません。
Claude Desktop on 3Pは、公式のデスクトップ体験を第三者の推論基盤で使う候補です。オフラインインストーラーで、Anthropicへの実行時通信を排除する構成もあります。ただし、完全オンプレミスのClaude推論を公式に使えることを意味しません。
結論を出す前に、次の順で進めるのが妥当です。
- 要件を分類する。クラウド閉域でよいのか、完全エアギャップが必須なのか。
- 代表的な業務を10〜20件選ぶ(日本語の文書作成、Excel集計、社内システムのWeb操作など)。
- 案A、B、Cで同じタスクを並べ、成功率、手戻り、所要時間、成果物の品質を測る。
- 外部通信を遮断した環境で、実際の通信先を測る。
- MCPサーバーのレビュー、承認ポリシー、egress許可リストを整える。
- スキルやプラグインの社内配布とバージョン管理の体制を作る。
- 段階的に展開し、モデルを定期的に再評価する。
この検証が終わるまでは、「OSSで7〜8割再現できる」「同等品質は不可能」「この構成が最良」のいずれも、確定した結論として扱わないのが安全です。
主な一次情報:Claude Desktop on 3P 導入手順、同 機能表、同 ゲートウェイ、Cowork GA発表、goose、OpenWork EEライセンス、NTTドコモビジネス、富士通