Claude Cowork が登場したとき、「エージェントと人間が同じ作業空間で並走する」というコンセプトに反応したエンジニアは少なくなかったと思います。
ただ、Anthropic のサブスクリプションに縛られず、自前の環境で同じことができないか——そう考えて different-ai/openwork にたどり着いた人も多いはずです。
この記事では、openwork を実際に検証した経験をもとに、opencode 基盤の設計思想、セットアップのつまずきどころ、コスト構造の違い、そして採用判断の軸まで、実務目線で整理します。
AIエージェントとの「共有ワークスペース」という発想
Claude Cowork が提示したのは、チャット UI でも単なるコーディングエージェントでもない、もう少し広い概念です。
エージェントが使えるスキル・MCP・外部サービス接続を「一度定義したら複数のエージェントと複数人で再利用できる」共有レイヤー——それが Cowork の核心でした。
たとえば、GitHub の操作や Slack への通知といったスキルを一人が登録しておけば、チームメンバー全員のエージェントがそのスキルを呼び出せる。
セッションをまたいでも設定が消えない。
そういう「ワークスペースとしての永続性」が、単発のチャットとは根本的に違う部分です。
openwork はそのコンセプトを OSS で再現しようとしたプロジェクトです。
作者が Hacker News に投稿したコメントが、ツールの動機をよく表しています。
「ホームサーバーを持っていて、妻と一緒に特権的なワークフローを実行したかった。Home Assistant の操作や自作 Web アプリのデプロイ、合法的なトレントのダウンロードといったことを、ターミナルに住まずにできるようにしたかった」という話です。
エンタープライズ向けの壮大な構想ではなく、「自分のホームサーバーで家族と使いたい」という具体的な不満が出発点でした。
その原体験が、ローカルファーストでシェアしやすい設計につながっています。
opencode基盤の意味——「Ejectable」設計がopenworkに何をもたらすか
openwork を理解するには、その土台である opencode を知っておく必要があります。
opencode はターミナルネイティブの AI コーディングエージェントで、2025年6月に v0.0.55 をリリースしたあと、同年9月にアーカイブ化されています（現在はリードオンリー）。
openwork はこの opencode の SDK（@opencode-ai/sdk/v2/client）を Tauri アプリのバックエンドとして組み込む形で動いています。
Tauri は Rust ベースのデスクトップアプリフレームワークで、Electron より軽量なネイティブ体験を提供します。
ここで重要なのが、AGENTS.md に明記されている 「Ejectable」 という設計哲学です。
「openwork は opencode によって動いているので、opencode ができることは専用の UI が存在しなくても openwork 越しに使える」という考え方です。
つまり opencode の機能が先に進んでいれば、UI の実装が追いついていなくても機能を呼び出せる設計になっています。
ひとつ、混乱しやすいことを整理しておきます。
GitHub には「openwork」という名前のリポジトリが2つ存在します。
- different-ai/openwork：Tauri（Rust + Web）ベース。opencode の SDK をバックエンドとして統合。開発者向けの拡張性・スキル・プラグインに注力。
- accomplish-ai/openwork：Electron（Node.js）ベース。opencode CLI をサブプロセスとして起動する構造。エンドユーザー向けの使いやすさに注力。
両者はどちらも opencode と連携し、ローカルモデルや BYOK（Bring Your Own Key）に対応していますが、アーキテクチャが根本的に違います。
この記事で扱うのは different-ai 版 です。
opencode がアーカイブ化されたことは、openwork にとって上流リスクです。
ただし、openwork の AGENTS.md には「Server-consumption first」という原則があり、openwork 自身がサーバーサーフェスを消費する設計になっています。
opencode の開発が止まっても、SDK が動いている限り openwork は動き続けます。
現時点では実用上の影響は限定的ですが、このリスクを完全に無視するのも正直ではありません。
採用判断の軸として後述します。
セルフホストして動かすまで——起動ルートの選択と詰まりやすい場所
openwork を動かす入り口は大きく2つあります。
ひとつはデスクトップアプリをダウンロードして起動するルート、もうひとつは既存のエージェント（Claude Code や Cursor など）に MCP サーバーとして組み込むルートです。
デスクトップアプリは GitHub の Releases から macOS・Windows・Linux 向けのバイナリを取得できます。
ソースからビルドする場合は Tauri の環境（Rust ツールチェーン + Node.js）が必要になります。
最初の一歩としては、素直にバイナリを使うのが現実的で、ここでの環境構築に時間をかける必要はありません。
起動後の流れはこうなります。
まず org（組織）を作成し、そこにスキルを登録していきます。
スキルはエージェントが呼び出せる能力の単位で、MCP サーバーや外部サービスへの接続もここで設定します。
スキルのスコープ設定（個人用か org 共有か）を間違えると、チームメンバーに見えないという問題が起きやすいので、最初に確認しておくべきポイントです。
MCP サーバーとして既存エージェントに組み込む場合、認証フローで一度詰まります。
MCP エンドポイントを追加すると、エージェントがブラウザを開いてサインインを求めてきます。
これ自体は想定された動作ですが、CI 環境やヘッドレス環境では動かないので、そういった用途には向きません。
Claude Code・Cursor 向けの MCP 設定は、公式 README に記載されているプロンプトをエージェントに貼り付けると自動で設定してくれる導線があります。
手動で設定ファイルに書く場合の構造は、おおむね以下のようなイメージです（実際のコマンドや引数は 公式 README で最新版を確認してください）。
{
"mcpServers": {
"openwork": {
"command": "<openwork が指定するコマンド>",
"args": ["<公式ドキュメント参照>"]
}
}
}
openwork MCP が公開するツールは search_capabilities（使えるスキルを探す）と execute_capability（スキルを実行する）の2つです。
エージェントはこの2つを通じて openwork に登録されたスキルを呼び出します。
実際に動かしてみると、スキルの登録と実行の往復はかなりスムーズです。
一方で、org の権限管理や per-user 接続の設定まわりは UI がまだ荒削りで、ドキュメントを読みながら手探りする場面が出てきます。
Claude Coworkと並べたとき——機能差・コスト構造・使い分けの現実
機能面から見ると、openwork の強みはスキル共有・MCP 再利用・マルチエージェント対応です。
一度登録したスキルを Claude Code でも Cursor でも Codex でも呼び出せる、というのは実際に便利で、「ツールを乗り換えても設定を引き継げる」という安心感があります。
一方で、Claude Cowork のような洗練されたオンボーディングや安定したホスト済みインフラは openwork にはありません。
Cowork はサブスクリプションを契約すればすぐ使い始められますが、openwork はセットアップコストが先払いです。
非エンジニアのチームメンバーと共有したい場合、openwork のセットアップを誰かが代わりにやってあげる必要があります。
「妻と共有したかった」という作者の動機は理解できますが、実際にそれをやるには多少の技術的な準備が要ります。
コスト構造の違いも重要です。
Claude Code Teams のプレミアムシートは 2026年3月時点で月額 $150/seat です（Stoneforge のブログ記事 による）。
10人チームなら月 $1,500 のベースコストになり、超過分はトークン課金が加わります。
openwork はその代わりに Anthropic の API 料金を直接払う構造です。
シート費用はゼロですが、インフラの維持コストと運用の手間が乗ってきます。
使用量が多いチームほど API 直結が有利になる傾向がありますが、使用量が少ない・予測しにくい段階では、管理コストを含めると必ずしも安くならないこともあります。
コスト比較は「シート費用 vs API 費用 + 運用コスト」という構造で考えるのが正確です。
データの所在という観点では、openwork のセルフホストは自前インフラ上でデータが完結します。
Cowork は Anthropic のクラウド上で処理されます。
社内の機密コードや顧客データを扱う場合、この違いは判断軸のひとつになります。
採用するか見送るか——opencodeアーカイブ化というリスクを含めた判断軸
openwork が向いているのは、すでに Claude Code や Cursor を使っているエンジニアが複数人いて、スキルや MCP 設定を共有したいと思っているチームです。
ツールをまたいで設定を再利用できる価値は、チームの規模が大きくなるほど効いてきます。
API 直結でコストをコントロールしたい、あるいはデータを自前インフラに置きたいという要件がある場合も、openwork は有力な選択肢になります。
逆に向かないのは、非エンジニアが多いチームへの展開や、すぐに安定した環境が必要な場面です。
セットアップに慣れた人間が一人いれば乗り越えられますが、全員がエンジニアではないチームに「自分でセットアップして」とは言いにくい。
そういう用途では Cowork のほうが現実的です。
opencode のアーカイブ化は、正直、無視できないリスクです。
openwork の動作基盤が読み取り専用になっているということは、上流でバグが修正されることも新機能が追加されることもないということです。
ただ、openwork 自体のコミュニティは動いていますし、Ejectable 設計のおかげで openwork 側で吸収できる部分もあります。
「今すぐ本番投入して長期運用」というより、「個人環境や小規模チームで試しながら様子を見る」くらいの距離感が今の openwork には合っています。
判断に迷うなら、まず個人の開発環境に MCP として追加してみるのが一番手っ取り早いです。
デスクトップアプリのインストールは不要で、既存エージェントに設定を数行足すだけで動き始めます。
そこで「スキル共有の価値を感じるか」を実際に確かめてから、チームへの展開を考えるのが現実的な入り口だと思います。
株式会社ホコサキは山口県宇部を拠点に、Web 制作・業務システム開発・AI 活用支援・DX 推進に取り組んでいます。
openwork のようなツールの評価・導入検討から、実際の環境構築まで、実務目線でご相談に乗ることができます。
気になることがあれば お問い合わせページ からどうぞ。