Cowork

🤝 Cowork — Claude Code、Codex、Gemini CLI、Hermes エージェント向けの共通タスク受信箱

異なる AI コーディングエージェントが 1 つのタスクキューを共有できる、セルフホスト可能な MCP サーバーと Web ダッシュボードです。 いずれかのエージェント（または UI）からタスクを割り当てると、ディスパッチャーが名前付きのブレイン（モデル × CLI × マシン）にタスクをルーティングして実行し、結果を検証します。レート制限が発生した場合は、次のブレインに切り替えます。ワークフロー、成果物、リモートマシン、コスト／使用量メーターが組み込まれています。

• ベンダー混在のエージェントを、1 つの受信箱に集約： Claude Code、Codex、Gemini CLI / Antigravity、Hermes、Ollama。
• フォールバックチェーンを備えたブレインルーティング： 役割ごとにルーティングし、タスクごとに固定して、クォータエラー時にフェイルオーバーします。
• ディスク上のプレーンファイル： タスクストアはファイルです。実行にデータベースは必要ありません。
• リモートブレイン： 別のマシンが 1 つのコマンドで参加し、モデルを提供します (JOIN-AS-A-BRAIN.md)： COWORK_URL=http://<host>:6868 HOST=<you> node cowork/deploy/remote-brain-client.mjs

移動先：クイックスタート · エージェントの接続 · ディスパッチャー · ブレイン · ワークフロー · MCP ツール

スクリーンショット

操作全体を把握できる、ダークテーマのシングルペインダッシュボードです。ホストのライブメトリクス （CPU / GPU / メモリ / 温度）、未完了タスクと Agencies のカウンター、ディスパッチャーの現在の 役割 → モデルチェーン、リアルタイムのアクティビティフィードを表示します。

ワークフロー、 タスク受信箱、ブレイン、 接続、チャットの画面は、 この README の各所で実際の使用例とともに紹介しています。

対応プラットフォーム

プラットフォーム	エージェント	形式
Claude Code	約 285	YAML frontmatter 付き .md
Antigravity (AGY)	組み込み + スキル	SKILL.md
Hermes Agent	39 スキル	SKILL.md + トリガー
Gemini CLI	ソースから変換	.md サブエージェント
GitHub Copilot	Claude と同じ	.md エージェント
Codex	変換済み	.toml エージェント
Cursor	変換済み	.mdc ルール
+ 7 つ	agency-agents リポジトリを参照	各種形式

---

クイックスタート

前提条件

• Node.js ≥ 20（v22 でテスト済み）

• npm ≥ 10

• agency-agents リポジトリ — cowork/agency-agents に git サブモジュールとしてバンドルされています（Agencies — 285 エージェント）。サブモジュールを含めてクローンします：

  git clone --recurse-submodules https://github.com/slashman413/cowork
  # already cloned without it? initialise the submodule:
  git submodule update --init
  

最短手順 — 2 つのスクリプト（推奨）

サブモジュールを含めてクローンした後（上記）、リポジトリのルートから実行します：

# 1. Build + launch the server (installs deps, builds, starts a systemd user service)
deploy/install-server.sh

# 2. Drop the coordination skill + MCP connection into your agent clients on this box
deploy/install-skill.sh            # auto-detects Claude Code / Hermes / Antigravity

install-server.sh は、このマシンの実際の node パスと作業ディレクトリを使って systemd ユニットを生成するため、手作業での編集は不要です。ターミナルで起動するには --foreground を、ビルド後に終了するには --build-only を渡します。install-skill.sh は、クライアントごとに適切なスキルを所定の場所にコピーし、Claude Code の場合は mcpServers.cowork を ~/.claude.json に非破壊的にマージします（リモートサーバーの場合は --url http://<host>:6868 を追加し、対象を 1 つに絞るには --client claude|hermes|agy|all を指定します）。以下の番号付き手順は同じ作業を分割したもので、手動で行う場合に使用します。

コンテナー（ハブのみ）

docker run -d -p 6868:6868 -v cowork-data:/data ghcr.io/slashman413/cowork:1.0.0

イメージ（amd64 + arm64）は MCP サーバー、ダッシュボード、タスク受信箱を実行し、ローカルのディスパッチャーは無効にします。エージェントは http://<host>:6868/mcp に接続し、マシンは deploy/remote-brain-client.mjs を使ってブレインを提供します（JOIN-AS-A-BRAIN.md を参照）。設定とすべての状態は /data ボリュームに保存されます。キーを必須にするには COWORK_API_KEY を設定します。イメージは、ダイジェストを固定したベースを使用して、.github/workflows/release.yml により v* タグからビルドされます。

1. 依存関係をインストールする

cd cowork/server
npm install

2. 設定を構成する

設定はリポジトリの外にあります。 管理対象の cowork/config.json は、サニタイズされた テンプレートのみです。初回起動時に、サーバーはこれを ~/.cowork/config.json にコピーします。 こちらがサーバーごとの実際の設定（ホストのバインド、登録済みの brain、チェーン）です。テンプレートではなく、 こちらのコピーを編集してください。サーバーはダッシュボードや API で行ったすべての変更もここに保存するため、 ホストや brain に関する個人設定がリポジトリに反映されることはありません。場所を変更するには、 COWORK_CONFIG 環境変数を指定してください。

環境に合わせて ~/.cowork/config.json を編集します。

{
  "server": {
    "port": 6868,          // ← Change the port here
    "host": "0.0.0.0",     // ← Bind address (0.0.0.0 = all interfaces)
    "name": "cowork-mcp",
    "version": "1.0.0",
    "apiKey": null          // ← Set a string to require API key auth, or null for open
  },
  "paths": {
    "agencyAgents": "./agency-agents",  // ← Path to agency-agents repo
    "inbox": "./inbox",
    "status": "./.status",
    "decisions": "./decisions",
    "workflows": "./workflows",
    "artifacts": "./artifacts",
    "inputs": "./inputs"
  }
}

すべてのパスは cowork/（server/ の親ディレクトリ）を基準とします。 ホームディレクトリのパスには ~ を使用してください（例：~/.claude/agents）。

主な設定

設定	デフォルト	説明
server.port	6868	MCP エンドポイントと Web UI の HTTP ポート
server.host	0.0.0.0	バインドアドレス（ローカルのみの場合は 127.0.0.1）
server.apiKey	null	認証用 API キー（null = 認証なし）
paths.agencyAgents	./agency-agents	agency-agents リポジトリへのパス
platforms.*.enabled	true	個々のプラットフォームの有効／無効を設定
platforms.*.agentsDir	varies	プラットフォーム固有のエージェントがディスク上にある場所
services.*.enabled	false	サービスのヘルス監視の有効／無効を設定

3. サーバーを起動する

# Development mode (with hot-reload)
cd cowork/server
npm run dev

# Production mode
npm run build
npm start

次のように表示されます。

🤝 Cowork MCP Server running at http://0.0.0.0:6868
   MCP endpoint: http://0.0.0.0:6868/mcp
   Web Dashboard: http://0.0.0.0:6868/
   REST API: http://0.0.0.0:6868/api/
   Agencies loaded: 285 agents across 19 divisions

4. ダッシュボードを開く

ブラウザーで http://localhost:6868 を開きます。

---

AI エージェントを接続する

接続済みのモデルとやり取りする最も簡単な方法は、ダッシュボードの Chat ビューです。brain を選び、 必要に応じて部門と特定のエージェントに対象を絞ると、メッセージがタスクとして送信され、 返信としてタスクの結果が返されます。

部門を選択	…次にエージェントのペルソナを選択

プログラムからアクセスするには、MCP 接続をエージェントクライアントに設定します。

スクリプトを使用する場合（推奨）： deploy/install-skill.sh は cowork の連携スキルをインストールし、 マシン上で検出されたすべてのエージェントクライアントに MCP 接続を設定します。各設定を手動で編集する代わりに、 1 つのコマンドで実行できます。

deploy/install-skill.sh                          # auto-detect all clients, localhost server
deploy/install-skill.sh --client claude          # just Claude Code
deploy/install-skill.sh --client all --url http://cowork-host:6868   # remote server, every client

クライアントの稼働中のスキルディレクトリに、クライアントごとのスキル（正規のコピーは deploy/skills/ にあります）を配置します。 また、Claude Code では、他のサーバーに影響を与えずに mcpServers.cowork エントリーを ~/.claude.json にマージします。 参考として、クライアントごとの手動設定を以下に示します。

Claude Code

MCP 設定（~/.claude.json またはプロジェクトレベル）に追加します。

{
  "mcpServers": {
    "cowork": {
      "url": "http://localhost:6868/mcp",
      "transport": "streamable-http"
    }
  }
}

その後、Claude Code でエージェントが次のように呼び出せます。

Use the cowork MCP tools: register_agent, create_task, get_roster, etc.

Antigravity (AGY)

AGY の MCP 設定に追加します。

{
  "mcpServers": {
    "cowork": {
      "url": "http://localhost:6868/mcp"
    }
  }
}

agy クォータメーター／トークンの更新。 Antigravity のアクセストークンを発行するには、使用状況プローブと deploy/remote-brain-client.mjs に Google OAuth クライアントの値が必要です。これらは agy と Gemini の CLI に付属する公開値です。 これらの値はコミットされていません。.env.example を ~/.cowork/oauth-clients.env にコピーして値を入力し、 chmod 600 を実行してください。代わりに、サービス環境で同じ変数をエクスポートすることもできます。 プロセス環境変数が優先されます。値が設定されていない場合、agy メーターが機能するのは、キャッシュされた CLI アクセストークンが 有効な間のみです。

Hermes Agent

Hermes で MCP エンドポイントを設定します。

{
  "mcp_endpoints": {
    "cowork": "http://localhost:6868/mcp"
  }
}

MCP 互換クライアント全般

サーバーは Streamable HTTP 経由の標準 MCP に対応しています。MCP をサポートするクライアントであれば、 http://localhost:6868/mcp に接続できます。

---

タスク実行 — ディスパッチャー

サーバーには、キューに登録されたタスクを実際のエージェント実行に変換するディスパッチャーが含まれています。 出力はタスクのresultになり、トランスクリプト全体はタスクのアーティファクトディレクトリ内の result.mdに保存されます。

すべてのタスクはタスク受信箱に登録され、実行した部門／エージェントと 実行に使用したブレインのタグが付けられ、出力アーティファクトが添付されます。また、ステータス （完了・実行中・保留中・入力待ち・失敗）で絞り込めます。

2 段階のルーティング

未割り当てのタスクは、オーケストレーター／分類器ブレイン（デフォルトはHermes経由の qwen3.8-27b、orchestration.classifier）によって2 段階でルーティングされます。

1. 部門 — 19 の部門（テスト、エンジニアリング、セキュリティなど）から 1 つを選択します。
2. エージェント — その部門の約 285 のエージェントから 1 つを選択します。選択されたエージェントの 完全な.mdペルソナがシステムプロンプトになります。

その後、エージェントはブレインのフォールバックチェーン（以下を参照）で実行されます。分類器をスキップするには、 context.agent: "<agent-slug>"または特別なエグゼキューター名を直接指定します。 タスクにmanualタグを付けると、自動実行されなくなります。

エグゼキューター：特別なエージェントとAgencies

• 特別なエグゼキューター（config.json → orchestration.agents）— orchestrator、generalist、videoのみです。それぞれが{description, brains: [...]}で定義され、 独自のチェーンを持ちます。videoはComfyUIのLTXパイプラインを実行します （deploy/video-pipeline.sh。LTXのみ — Wan／Hunyuan／SVDは使用しません）。
• Agenciesエージェント — agency-agentsサブモジュールに含まれる約 285 のペルソナで、19 の部門に分類されています。独自のチェーンはなく、部門のチェーンが設定されていればそれを使用し、設定されていなければグローバルのデフォルトを使用します。

ブレインのフォールバックチェーン（GET /api/chains）

• グローバルデフォルト — orchestration.defaultChain。ブレインビューでドラッグして順序を変更します（PUT /api/chains/default）。
• 部門ごとのオーバーライド — orchestration.divisionChains[<division>]。エージェントビューで設定／解除します（PUT /api/chains/division/:division。空の場合はデフォルトを使用）。

チェーンは上から下へ実行されます。タスクはchain[0]で実行され、失敗するとディスパッチャーが chain[1]、続いて[2]…へ引き継ぎます。成功するかチェーンを使い切るまで、試行ごとに失敗したブレインがタスクに記録されます。タスクを 1 つのブレインに固定するには、 context.brain: "<id>"を指定します。

エージェントビューには、すべての部門の部門ごとのチェーンが表示されます。ドラッグして順序を変更するか、 ＋ ブレインを追加…を選択するか、グローバルデフォルトにリセットします。テンプレートの編集や再起動は不要です。

ブレイン — 名前付きの実行 ID（モデル × プラットフォーム × 場所）

config.json → orchestration.brains（GET /api/brains）では、チェーンから参照できる各ブレインに名前を付けます。ブレインビューには、登録済みのすべてのブレインが一覧表示されます。プラットフォーム （claude／agy／hermes）、基盤モデル、場所、および接続したクライアントによって auto登録されたかどうかが表示され、ワンクリックで登録を解除できます。

エイリアス	場所	実行内容
local-hermes-qwen3.8-27b	ローカル	そのモデルでHermesを実行
local-dsh-qwen3-8-27b	ローカル	そのモデルでDeepSeek Harness（dsh）を実行
local-cc-opus-5-5 / -sonnet-5-5 / -fable-5-1	ローカル	そのモデルでClaude Codeを実行
local-agy-* / local-comfy-ltx	ローカル	Antigravity/Gemini ／ ComfyUI-LTX動画
remote-codex-gpt-5-6-terra / -luna / -default	リモート	codexクライアントが要求するCodex（このホスト上）
remote-ai-code-gen-cc-opus-4-8 / -sonnet-5 / -fable-5	リモート	ai-code-genマシン上のClaude Code
remote-<host>-cc-sonnet-5-5	リモート	別のマシン上のClaude Code
ブレイン ID にはモデルのバージョンが含まれます（local-cc-opus-5-5 であり、local-cc-opus ではありません）。そのため、ブレインが実行するモデルを ID から確認できます。アカウントのデフォルト設定に従う -default ブレインのみ、バージョンがありません。local-／remote- のプレフィックスはブレインの location と一致している必要があります。これは「どのマシン上にあるか」ではなく、誰が実行するかを示します（local = ディスパッチャーが起動する、remote = クライアントが受信トレイから取得する）。DeepSeek ブレインは廃止されました。/deepseek/i に一致する ID は、読み込み時にレジストリから削除されます（DENYLISTED_BRAIN_RE を参照）。そのため、新しい ID に deepseek を含めないでください。

名前を変更した ID も引き続き使用できます。 server/src/config.ts の BRAIN_ID_ALIASES（および設定内の任意の orchestration.brainAliases）は、廃止された ID を正式な ID にマッピングします。ディスク上の設定、タスクの context.brain ピン留め、またはクライアントの登録にある古い ID は、すべて正式なブレインに解決されます。古い ID を引き続き宣言しているクライアントには、正式な ID を再宣言するまで、その ID のままタスクが割り当てられます（ブレインの clientId）。2026-10-07 に名前を変更しました。

廃止された ID	正式な ID
local-ha-qwen3-8-27b、local-ha-qwen38-27b、local-ha-qwen3.8-27b	local-hermes-qwen3.8-27b
local-codex-default / -gpt-5-6-terra / -gpt-5-6-luna	remote-codex-default / -gpt-5-6-terra / -gpt-5-6-luna
remote-ai-code-gen-cc-opus / -sonnet / -fable	remote-ai-code-gen-cc-opus-4-8 / -sonnet-5 / -fable-5

ローカルブレインは、ディスパッチャーがここで起動します。リモートブレインは pending のままにし、ブレイン ID をタスクの context.brain に公開することで、そのマシンのクライアントが検出して取得できるようにします（クライアントは context.brain が自身の ID のいずれかであるタスクを list_inbox でフィルターします）。orchestration.remoteGraceMs（デフォルトは 60 秒）以内にリモートの段階をクライアントが取得しなかった場合、ディスパッチャーはチェーン内の次のブレインに進むため、クライアントのいないリモート段階によってタスクが停止することはありません。

成果物はローカル、リモートのどちらのブレインでも利用できます。ローカルブレインは $COWORK_ARTIFACTS_DIR にファイルを保存し（ディスパッチャーがディスクから収集します）、リモートブレインは同じ環境変数のディレクトリに保存し、クライアントが各ファイルを POST /api/artifacts/:taskId/:file でアップロードします。どちらの場合も artifacts/<task-id>/ に保存され、受信トレイからダウンロードできるようになります。

入力ファイルは逆方向に渡されます。つまり、ブレインが読み取るファイルを人が添付します。チャットの入力欄（📎）または受信トレイの任意のカード（「＋ ファイルを添付」）で添付してください。ファイルは inputs/<task-id>/ に保存され、context.inputFiles にも反映されます。ディスパッチャーはローカルブレインのプロンプトに絶対パスを指定します。リモートブレインのクライアントは実行前にファイルをダウンロードし（GET /api/inputs/:taskId）、プロンプトにローカルパスを列挙します。入力ファイルは再実行後も保持されます。

失敗したタスクと再実行。 タスクがフォールバックチェーン全体を使い切ると（すべてのブレインで検証に失敗した場合）、failed: true のフラグが付いて終了します。受信トレイでは、これらのタスクは赤い 「失敗」 フィルターにまとめられ（緑色の「完了」件数には含まれません）、確認操作が必要な ↻ 再実行 が表示されます。この操作はタスクの brief と添付された入力を保持したまま、チェーンの先頭からタスクを pending にリセットします（POST /api/inbox/:id/rerun）。

自動登録されるブレイン（クライアント機能プロトコル）

接続する MCP クライアントは、register_agent ツールの brains フィールドを通じて、実行可能なブレインを宣言します。サーバーはそれらを dynamic として、そのクライアントの所有下でレジストリに自動追加します。1 台のマシンで複数のモデルを同時に提供できます。自動登録されたブレインは保持され、削除されるのは deregister_agent またはブレイン画面からの場合のみです（ハートビートのタイムアウトでは削除されません）。削除すると、デフォルトチェーン、すべての部門チェーン、すべての特別なエージェントからも削除されます。これらはすべて、ダッシュボードの エージェント 画面と ブレイン 画面から管理できます。

リモートのブレインマシンを接続する

deploy/remote-brain-client.mjs は、依存関係ゼロ（Node 18 以降）の Cowork MCP クライアントで、まさにこの一連の処理を実行します。ヘッダーコメントにすべての環境変数が記載されています。

最速の方法 — 直接実行する（フォアグラウンドで実行。最初のテストに適しています）。ブレインが 1 つの場合：

git clone https://github.com/slashman413/cowork
COWORK_URL=http://<cowork-host>:6868 EXEC=claude MODEL=claude-sonnet-5-5 \
  BRAIN_ID=remote-<host>-cc-sonnet-5-5 \
  node cowork/deploy/remote-brain-client.mjs

1 台のマシンで複数のブレインを実行する場合（すべてを宣言し、それぞれが指定可能なブレインになります）：

COWORK_URL=http://<cowork-host>:6868 EXEC=claude HOST=<host> \
  BRAINS='[{"id":"remote-<host>-cc-opus-5-5","model":"claude-opus-5-5"},
           {"id":"remote-<host>-cc-sonnet-5-5","model":"claude-sonnet-5-5"}]' \
  node cowork/deploy/remote-brain-client.mjs

起動サービスとして実行する場合（常時稼働マシンに推奨）：

mkdir -p ~/.config/cowork-remote-brain
cp cowork/deploy/remote-brain-client.env.example ~/.config/cowork-remote-brain/aicodegen.env
# edit: COWORK_URL, BRAINS (or BRAIN_ID), EXEC, HOST, COWORK_CLIENT_JS
cp cowork/deploy/[email protected] ~/.config/systemd/user/
systemctl --user daemon-reload && systemctl --user enable --now cowork-remote-brain@aicodegen

COWORK_URL/mcp に接続し、register_agent を実行して（BRAINS を宣言し、自動的にレジストリに登録）、ポーリングして、context.brain がいずれかのブレイン ID と一致するタスクのみを取得します。一致する EXEC/MODEL を実行し、結果とアップロード済みアーティファクトを指定して complete_task を実行します。他のクライアントと同様に、接続に表示されます。柔軟性：環境変数を変更するだけで、同じスクリプトをあらゆるブレインに使用できます。スケーラビリティ：<name>.env ファイルを追加するだけで、マシンやブレインを追加できます。取得処理はアトミック（単一プロセスの compare-and-set）なので、同じブレイン ID を使う複数のクライアントがいても、タスクが二重に実行されることはありません。最初に取得したクライアントが実行します。

接続中のクライアントはすべて接続ビューにリアルタイムで表示されます。プラットフォームごとにグループ化され、提供するブレイン、アイドル／ビジー状態、および各ブレインが実行したタスク数と送信したタスク数のセッションごとの集計が一覧表示されます。

接続に cowork/orchestrator として表示される常時稼働のコーディネーターエージェントは、受信トレイをポーリングし、未割り当てのタスクを 2 段階でルーティングし、孤立したタスクを再取得してディスパッチします。タスクごとに一時的に起動するワーカーは、実行中に testing / Workflow Optimizer · local-hermes-qwen3.8-27b や video · local-comfy-ltx のように表示されます。

CEO のワークフロー：Hermes に（たとえば Discord 経由で）アイデアを伝える → Hermes が context.agent: "orchestrator" を指定したタスクを 1 つ作成する → オーケストレーターが POST /api/inbox 経由でサブタスクに分解する → 各サブタスクが 2 段階でブレインチェーン上のエージェントにルーティングされる → 結果とアーティファクトがダッシュボードにリアルタイムで表示されます。

LLM 分類器 — タスクを取りこぼさない

未割り当てのタスク（たとえば、Discord から直接登録された自由記述のアイデア）も、処理が停止することはありません。ディスパッチャーが2 段階の LLM ルーター（デフォルトでは Hermes 経由の qwen3.8-27b、config.json の orchestration.classifier）を実行してタスクを読み取り、部門を選択した後、エージェントを選択します。その後、選択されたエージェントのブレインチェーン上で通常どおりディスパッチされます。ルーティングとディスパッチの両方をスキップするには、タスクに manual タグを付けます。

古い取得状態の回収

orchestration.staleClaimMs（デフォルトでは 30 分）は、取得したエージェントが見つからなくなった進行中のタスク（クラッシュまたは終了したライブエージェントや、実行中に強制終了されたディスパッチャーなど）を pending に戻し、作業を再試行できるようにします。ハートビートを送信しているエージェントがまだ所有しているタスクには手を加えません。

ディスパッチャーの状態：GET /api/dispatcher。config の orchestration.maxConcurrent／taskTimeoutMs／pollIntervalMs／classifier／staleClaimMs で調整します。

デプロイ（systemd）とリモートアクセス

最も簡単な方法 — deploy/install-server.sh は、このマシンの解決済み Node パスと作業ディレクトリを指定したユーザーサービスを生成し、有効化します。

deploy/install-server.sh          # build + install & start the cowork-mcp user service

同等の手動手順（追跡対象の deploy/cowork-mcp.service には /home/USER というプレースホルダーがあるため、事前に編集してください。スクリプトが代わりに設定します）：

cp deploy/cowork-mcp.service ~/.config/systemd/user/   # then edit the USER/paths inside
systemctl --user daemon-reload
systemctl --user enable --now cowork-mcp

server.host: "0.0.0.0" にすると、他のマシンから http://<host-ip>:6868/（LAN または Tailscale の IP）でダッシュボードにアクセスできます。0.0.0.0 自体はバインドアドレスであり、URL ではありません。信頼できるネットワークの外部からホストにアクセスできる場合は、server.apiKey（または COWORK_API_KEY）を設定してください。

HTTP から HTTPS への切り替え

デフォルトでは、サーバーはプレーンな http:// でリッスンします。localhost では問題ありませんが、ブラウザーがマイク（新規タスクの 音声入力 音声テキスト変換ボタン）を公開するのは、セキュアコンテキスト（https:// または http://localhost）に限られます。http://<lan-or-tailscale-ip>:6868 でダッシュボードにアクセスすると、navigator.mediaDevices は未定義となり、音声入力を開始できません。HTTPS で配信すれば解決します。

server.tls にディスク上に存在する証明書と鍵のペアを指定すると、サーバーは自動的に HTTPS で配信します。ファイルが見つからない場合は警告をログに記録し、http:// にフォールバックします。次の順序で切り替えてください。切り替えは計画的に行ってください。スキームが切り替わった時点で、http://…:6868/mcp を参照したままのすべての MCP クライアントとスキルが動作しなくなります。

1. 証明書と鍵を生成します（LAN／テイルネットでは自己署名で問題ありません）。アクセスするすべてのホスト名／IP を SAN に含めてください。

   server/gen-tls-cert.sh ~/.cowork/tls cowork-host 100.80.243.33 cowork.tailXXXX.ts.net
   

   Tailscale テイルネットで警告の出ない証明書を使用するには、自己署名証明書ではなく tailscale serve（実際の Let's Encrypt 証明書）を使用してください。

2. 設定でファイルを指定します。 ~/.cowork/config.json（実際に使用する設定ファイル。リポジトリの config.json はデフォルトのテンプレートにすぎず、"tls": null が設定されています）の server の下に tls ブロックを追加します。

   "server": {
     "host": "0.0.0.0",
     "port": 6868,
     "tls": { "certFile": "~/.cowork/tls/cert.pem", "keyFile": "~/.cowork/tls/key.pem" }
   }
   

   ~ とリポジトリ相対パスは自動的に解決されます。**ここが最も見落とされやすい手順です。**証明書を生成するだけでは何も起こりません。このブロックがないと、サーバーは http:// のままです。

3. サーバーを再起動して、新しいスキームを適用します。 タスクの実行中に systemctl --user restart cowork-mcp を実行すると、再起動対象のユニットの子プロセスであるそのタスクに SIGKILL が送られます。そのため、実行中のタスクがなくなるまで待機する、アイドル時に安全な再デプロイを使用してください。

   systemd-run --user --collect --unit=cowork-server-redeploy \
     deploy/redeploy-server-when-idle.sh
   

   HTTPS で起動したことを確認します。

   journalctl --user -u cowork-mcp -n 5 | grep 'API:'
   curl --cacert ~/.cowork/tls/cert.pem https://localhost:6868/api/status | jq .uptime   # HTTPS handshake + a live number
   

4. すべてのクライアントを https:// に切り替えます。 https URL を指定してインストーラーを再実行し、各クライアントの mcpServers.cowork エントリーとスキルを更新してから、クライアントを再起動します。

   deploy/install-skill.sh --client all --url https://cowork-host:6868
   

   COWORK_URL=http://… で起動しているリモートブレインクライアントは、COWORK_URL=https://… に変更して再起動する必要があります。自己署名証明書の場合、ブラウザーに一度だけ警告（「サイトに進む」）が表示されます。進んだ後はオリジンがセキュアコンテキストとなり、音声入力が使えるようになります。

   **Node クライアントでは自己署名証明書を信頼する必要があります。**信頼しない場合、MCP ハンドシェイクは SELF_SIGNED_CERT_IN_CHAIN で失敗します。クライアントを起動する環境（たとえば claude を実行するシェルや、リモートブレインクライアントの環境変数）で、証明書を追加の CA として指定してください。

   export NODE_EXTRA_CA_CERTS=~/.cowork/tls/cert.pem
   

   検証を完全に無効にする NODE_TLS_REJECT_UNAUTHORIZED=0 より、この方法を推奨します。CA の信頼設定が現実的でない場合に限り、プライベートテイルネット上でのみ後者を使用してください。

サーバー側のセルフディスパッチはすでにスキームに対応しています。設定は不要です。 ディスパッチャーは server.tls に基づいてオーケストレーターの curl コマンドと子ブレインの COWORK_API 環境変数を構築するため、TLS が有効な場合は https://localhost:6868 を参照します（curl には --cacert が指定され、Node の子プロセスには NODE_EXTRA_CA_CERTS が自動的に設定されます）。切り替え時に、リポジトリ内に http://localhost:6868 のハードコードは残りません。

ロールバックするには、server.tls を null に設定する（またはブロックを削除する）だけで、サーバーは http:// に戻ります。

MCP ツールリファレンス

接続すると、エージェントは次のツールを利用できます。

ツール	説明
register_agent	このクライアントを登録します。実行可能な brains を宣言することもできます
deregister_agent	このクライアントを削除し、登録したすべてのブレインも連鎖的に削除します
heartbeat	ステータスと現在のタスクを更新します
get_roster	19 の部門にわたる約 285 のエージェントを検索します
create_task	別のエージェント／プラットフォーム向けのタスクを作成します
claim_task	保留中の受信トレイタスクを取得します
complete_task	結果を添えてタスクを完了としてマークします
list_inbox	ステータス／プラットフォームのフィルターを使って受信トレイのタスクを一覧表示します
get_dashboard	ダッシュボードの全データ（アクティブなエージェント、受信トレイの統計など）を取得します

例：プラットフォーム間のタスクディスパッチ

You: "Review the auth code in saas-starter"

AGY Agent calls:
  create_task(
    title: "Review auth middleware",
    from_platform: "antigravity",
    from_agent: "self",
    to_platform: "claude",
    to_agent: "engineering-code-reviewer",
    priority: "normal"
  )

→ Task appears in dashboard inbox
→ Claude Code picks it up, runs review
→ Claude calls complete_task(...) with its result + artifacts
→ Result + artifacts appear on the task card

---

ワークフロー — 宣言型パイプライン、2つの実行モード

ワークフローは、バージョン管理されたテンプレート（workflows/<id>.json）です。「mode」でテンプレートごとに選択した、次の2つのモードのいずれかで実行されます。

Workflowsビューでは、各テンプレートがライブグラフとして表示されます。順次処理のファン・スルーパイプラインも、並列処理のファンアウト／ファンインのダイヤモンドも表示され、各ステップはディビジョンまたはエージェントに固定されます。また、解決済みプランを確認する Dry run と Run の操作も利用できます。

build-and-ship — 5ステップのエンジニアリングパイプライン	expand-perspectives — 並列の多角的なファンアウト → 統合

• dag（デフォルト）— 静的かつ決定論的です。 ステップは dependsOn で接続されたDAGを構成します。実行開始前にグラフ全体が受信トレイのタスクに展開され、ディスパッチャーが依存関係の順に処理します。新しい実行エンジンを使うわけではありません。展開時に、ディスパッチャーがいずれにせよ実行するタスクをあらかじめ接続するだけです。複数ステップのジョブは、毎回LLMが最初から計画し直すのではなく、再利用可能で確認しやすいものになります。
• orchestrated — 適応型で、オーケストレーターが主導します。 ステップは候補となる操作のライブラリであり、事前の計画はありません。各ステップの完了後、オーケストレーターの頭脳が、goal とそれまでの結果をもとに次のステップを自動的に決定するか、DONE と回答します。実際の経路は、返された内容に応じて変化します。各決定（選択したステップとその理由）は workflow-runs/<runId>.json に記録され、ダッシュボードでは決定ログとして表示されます。

DAG モード

テンプレートはステップのリストです。各ステップは安定した key を持つタスクで、ほかのステップはそのキーを dependsOn で参照します（実行時に実際のタスクIDに解決されます）。

{
  "id": "content-pipeline",
  "params": ["topic"],
  "steps": [
    { "key": "research", "title": "Research: {{topic}}", "division": "marketing" },
    { "key": "draft",    "title": "Draft {{topic}}", "division": "marketing", "dependsOn": ["research"] },
    { "key": "review",   "title": "Review {{topic}}", "agent": "code-reviewer", "dependsOn": ["draft"] },
    { "key": "publish",  "title": "Publish {{topic}}", "division": "marketing", "dependsOn": ["review"] }
  ]
}

実行します（または、作成せずに解決済みプランを確認するにはドライランを実行します）。

curl -s -X POST localhost:6868/api/workflows/content-pipeline/run \
  -H 'content-type: application/json' -d '{"params":{"topic":"RISC-V laptops"}}'

実行によって作成されるすべてのタスクには context.workflowId、context.workflowRunId、context.stepKey が含まれます。これにより、ダッシュボードの Workflows タブで実行をグループ化し、ノードごとのライブステータス付きでDAGを表示できます。テンプレートは読み込み時に検証されます（キーが一意であること、依存先が存在すること、グラフに循環がないこと。循環があると dependsOn が永久にデッドロックします）。検証に失敗したテンプレートはリストをクラッシュさせずにスキップされ、理由はダッシュボードと GET /api/workflows-invalid に表示されるため、不正なテンプレートを簡単に修正できます。ステップでは agent、division、brain を指定して固定することも、指定せずにルーターに選択させることもできます。

オーケストレーション（アダプティブ）モード

"mode": "orchestrated" を設定し、テンプレートに goal を指定して、ステップを候補ライブラリとして列挙します（dependsOn は、上流のステップがすでに実行済みの場合にステップの入力を接続するための任意のヒントになります）。実行すると実行記録が書き込まれ、タスクは作成されません。ディスパッチャーのオーケストレーターループが次のティックで最初の判断を行い、その後は各ステップの完了後にもう一度判断します。

{
  "id": "adaptive-research",
  "mode": "orchestrated",
  "goal": "Produce a decision-ready brief answering: {{question}}",
  "params": ["question"],
  "steps": [
    { "key": "scope",     "title": "Scope the question", "division": "operations" },
    { "key": "survey",    "title": "Broad survey", "division": "operations" },
    { "key": "deep-dive", "title": "Deep dive on the crux" },
    { "key": "counter",   "title": "Steelman the opposing view" },
    { "key": "brief",     "title": "Write the decision brief" }
  ]
}

オーケストレーターの頭脳（ルーターモデル。orchestration.classifier、それがなければオーケストレーター／デフォルトチェーン内で最初に実行可能なローカル頭脳）には、目標、完了済みのステップとその結果、残りの候補がプロンプトとして渡されます。オーケストレーターはステップキーまたは DONE を返します。orchestration.maxWorkflowSteps（デフォルトは12）は、オーケストレーターが DONE と返さない実行を強制的に終了させます。

どちらのモードでも、各タスクには context.workflowId、context.workflowRunId、context.stepKey が付与されるため、Workflows タブでは実行がグループ化され、ライブ表示されます。静的な実行ではDAG、アダプティブな実行では判断タイムラインが表示されます。テンプレートは読み込み時に検証されます（キーの一意性、依存先の存在、DAGモードではグラフが非循環であること）。検証に失敗したテンプレートはリストをクラッシュさせずにスキップされ、その理由はダッシュボードと GET /api/workflows-invalid に表示されます。

エンジン（検証、サイクル検出、トポロジカル展開、DAG配線、実行の再構築、オーケストレーション判断ループ）はテストスイートでカバーされています。cd server && npm test

同梱の企業ワークフロー

workflows/ ディレクトリには、現実的な部門横断型企業パイプラインが複数同梱されています。各ステップでは division または agent（brain は使用しません）を指定するため、各役割の頭脳のフォールバックチェーンはダッシュボードの Agents ビューから編集できます（特別なエージェントでは orchestration.agents[*].brains、エージェントでは divisionChains[*] / defaultChain）。テンプレートに触れることなく、ステップの担当者を変更できます。

ワークフロー	モード	内容
idea-to-launch	dag	目玉ワークフローです。CEO向け概要 → 市場調査＋多角的な視点 → PM仕様書 → アーキテクチャ → エンジニアが実際の製品を構築し、GH ActionsでGitHubにプッシュ → マーケティング販促＋メール自動返信 → 営業支援 → 財務モデル → Chief-of-Staffによる実行可否レビュー。params: idea
product-spec	dag	PMが、ユーザー調査とエンジニアリングの実現可能性評価を基に、実装可能なPRDを作成し、リリース可能な最初のスプリントに落とし込みます。params: idea
build-and-ship	dag	仕様書を受け取り → アーキテクトが設計 → エンジニアを派遣して実際のコードを構築 → GitHub ActionsのCIパイプラインを接続 → コードレビュー → プッシュしてパイプラインが成功していることを確認します。params: spec
feedback-to-roadmap	dag	社員／顧客からの生のフィードバック → トリアージ → テーマに統合 → PMのイニシアチブ → 優先順位付けされたロードマップ → 「Now」の項目を実作業として派遣します。params: feedback
gtm-campaign	dag	マーケティング＋営業でローンチを準備します。オファーと販促の切り口 → メールシーケンス ＋受信メールの自動返信ルール → コンテンツ → 営業支援 → 成功指標。params: product
finance-close	dag	経理サイクルです。簿記担当者による照合 → FP&Aによる差異分析 → 将来予測モデル → CFOの承認＋取締役会向け概要。params: period
expand-perspectives	dag	研究者が4つの独立した視点（第一原理、先例、逆張り、二次的影響）からアイデアを並行して深掘りし、意思決定に使える視点マップに統合します。params: idea
adaptive-research	orchestrated	アダプティブな詳細調査です。オーケストレーターは、目標に必要な箇所だけを掘り下げます。params: question
plan-execution	orchestrated	計画を派遣済みのジョブに変換し、完了を検証するまで実行を進めます。params: plan
content-pipeline	dag	調査 → 草稿 → レビュー → 公開。params: topic
product-brief	dag	市場・技術・リスクの並行分析 → 1ページの実行可否概要。params: idea

# Run the flagship end-to-end company workflow:
curl -s -X POST localhost:6868/api/workflows/idea-to-launch/run \
  -H 'content-type: application/json' -d '{"params":{"idea":"a self-hosted receipts scanner"}}'

REST API

Web UI では以下のエンドポイントを使用します（スクリプトやインテグレーションからも利用できます）。

メソッド	パス	説明
GET	/api/status	ダッシュボードの概要データ
GET	/api/agents	すべてのアクティブなエージェント（id → name）
GET	/api/connections	稼働中の MCP クライアント（ハートビート）＋脳ごとの実行済み／送信済みカウンター
GET	/api/inbox?status=pending	受信トレイのタスク（フィルタリング可能）
POST	/api/inbox	新しいタスクを作成します。省略可能な inputs: [{token,name}] でアップロード済みファイルを添付できます
PATCH	/api/inbox/:id	タスクを取得または完了します
POST	/api/inbox/:id/rerun	FAILED（チェーンを使い果たした）タスクを再キューに登録します。チェーンの先頭から保留中にリセットし、入力は保持します
GET/POST	/api/inbox/:id/inputs	既存のタスクに添付された入力ファイルを一覧表示／添付します（{inputs:[{token,name}]}）
POST	/api/uploads?name=<file>	アップロードしたファイルをステージングします（raw body）。タスク入力として渡す {token} を返します
GET	/api/inputs/:taskId, /:taskId/:file	タスクに添付された入力ファイルを一覧表示／ダウンロードします
GET	/api/workflows / /api/workflows/:id	宣言型ワークフローテンプレート（検証済み）
GET	/api/workflows-invalid	読み込みに失敗したテンプレートとその理由（JSON／検証エラー）
POST	/api/workflows/:id/run	実行を開始します。DAG テンプレートをタスクに展開するか、オーケストレーションされた実行を開始します。{ params, dryRun }
GET	/api/workflow-runs / /api/workflow-runs/:runId	実行ビュー用の実行データ（タスクからグループ化された DAG、または実行記録＋判断ログから構成されたオーケストレーション実行）
GET	/api/roster?division=engineering	エージェンシー（フィルタリング可能）
GET	/api/roster-divisions	部門別にグループ化されたエージェンシー（エージェントビュー用）
GET	/api/dispatcher	特殊エージェント＋脳＋defaultChain＋divisionChains＋running
GET/PUT	/api/chains, /chains/default, /chains/division/:div	脳のフォールバックチェーンを読み取り／編集します
GET/PUT/DELETE	/api/brains, /api/brains/:id	脳のレジストリ（削除時に関連データも連鎖的に削除）
GET/PUT/DELETE	/api/agents-config, /api/agents-config/:name	特殊エグゼキューターのチェーン
GET/POST	/api/artifacts/:taskId, /:taskId/:file	一覧表示／ダウンロード。POST（raw body）ではリモートの脳からファイルをアップロードします
GET	/api/config	現在の設定
GET	/api/events	SSE イベントストリーム

---

ディレクトリ構成

cowork/
├── config.json              # TEMPLATE only — real config at ~/.cowork/config.json
├── README.md                # This file
├── PROTOCOL.md              # Protocol specification
├── JOIN-AS-A-BRAIN.md       # Onboarding for a remote brain client
├── agency-agents/           # git SUBMODULE — the Agencies (~285 agents)
├── workflows/               # Workflow templates (*.json) — DAG + orchestrated
├── workflow-runs/           # Orchestrated run records + decision logs (gitignored)
├── server/                  # MCP Server + Web UI
│   ├── src/                 # TypeScript source
│   └── public/              # Web UI (HTML/CSS/JS)
├── deploy/                  # systemd units, remote-brain client, presets, skills
├── inbox/                   # Task queue (JSON files, auto-managed)
├── artifacts/               # Per-task OUTPUT files (audio/video/md), downloadable
├── inputs/                  # Per-task INPUT files a person attached for the brain (gitignored)
├── decisions/               # Decision log
└── .status/                 # Runtime state (auto-managed)

---

デバッグ

MCP Inspector

公式 Inspector で MCP エンドポイントをテストします。

npx @modelcontextprotocol/inspector http://localhost:6868/mcp

http://localhost:6274 に Web UI が開き、すべての MCP ツールを参照して対話的にテストできます。

curl の例

# Check server status
curl http://localhost:6868/api/status | jq

# List active agents
curl http://localhost:6868/api/agents | jq

# List pending inbox tasks
curl "http://localhost:6868/api/inbox?status=pending" | jq

# Browse engineering agents in Agencies
curl "http://localhost:6868/api/roster?division=engineering" | jq

# Watch real-time events
curl -N http://localhost:6868/api/events

MCP ツール呼び出しのテスト

# Register a test agent
curl -X POST http://localhost:6868/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "register_agent",
      "arguments": {
        "platform": "antigravity",
        "agent_name": "test-agent",
        "current_task": "Testing MCP connection"
      }
    },
    "id": 1
  }'

# Get dashboard data
curl -X POST http://localhost:6868/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "get_dashboard",
      "arguments": {}
    },
    "id": 2
  }'

---

設定リファレンス

config.json の完全な例

{
  "server": {
    "port": 6868,
    "host": "0.0.0.0",
    "name": "cowork-mcp",
    "version": "1.0.0",
    "apiKey": null
  },
  "paths": {
    "agencyAgents": "./agency-agents",
    "inbox": "./inbox",
    "status": "./.status",
    "decisions": "./decisions",
    "workflows": "./workflows",
    "artifacts": "./artifacts",
    "inputs": "./inputs"
  },
  "platforms": {
    "claude": {
      "enabled": true,
      "agentsDir": "~/.claude/agents",
      "color": "#D97757"
    },
    "hermes": {
      "enabled": true,
      "skillsDir": "../hermes-agent/skills",
      "color": "#7C3AED"
    },
    "antigravity": {
      "enabled": true,
      "skillsDir": "~/.gemini/config/skills",
      "color": "#0EA5E9"
    }
  },
  "inbox": {
    "autoArchiveDays": 30,
    "maxRetries": 3
  }
}

ポータルランチャーカードは専用ファイル portal.json（稼働中のコピーは ~/.cowork/portal.json。ホットリロード対応）に保存されます。詳しくは docs/dashboard.md#portal を参照してください。

環境固有のオーバーライド

デフォルトでは、実際の設定は ~/.cowork/config.json から読み込まれます。別の ファイルを指定するには COWORK_CONFIG 環境変数を使用します（ファイルを編集せずにポート／API キーを オーバーライドできます）。

COWORK_CONFIG=~/.cowork/config.staging.json COWORK_PORT=6900 npm start

エージェンシーカタログはメモリにキャッシュされ、COWORK_ROSTER_TTL_MS （デフォルトは 30000）ごとに最大 1 回再スキャンされます。新しいエージェントやサブモジュールの更新は、 再起動なしでこの期間内に反映されます。クエリのたびに再スキャンするには 0 を設定し、ディスク処理を減らすには より大きな値を設定してください。

---

Cowork Pro

Cowork Pro ($59) は本番環境向けの パッケージです。高度なワークフロー、優先サポート、生涯アップデートが含まれます。また、 AI Developer Stack Bundle ($79) にも含まれています。

ライセンス

MIT © 2026 slashman413。コアサーバー、ダッシュボード、リモート脳クライアントは 無料のオープンソースです。Cowork Pro（上記）は別途有料のアドオンです。