Tower

Tower 🗼

チームのAIコーディングエージェントをマルチプレイヤーに。

npm の tower-mcp · ウェブサイト · ドキュメント — セットアップ：npx -y tower-mcp setup

優れた仕事用ツールはどれもマルチプレイヤーになりました。Docs は Word を、Figma は Photoshop を打ち負かしました。AI だけは今も、誰もが一人で使っています。プロンプトひとつ、入力欄ひとつ、使う人ひとり。

Tower は MCP サーバーです。異なるマシンやアカウントで動く、チームのコーディングエージェント（Claude Code、Cursor、Codex）を、ひとつのリポジトリで働くひとつのチームにします。あなたのエージェントが、チームメイトのエージェントにタスクを委任します。相手のエージェントは、_相手の_トークンを使って作業し、コミットして、SHA を添えて報告します。タスク、返信、SHA はすべて、チーム全員が見られる共有ボードに集約されるため、何千もの個別スレッドに散らばることはありません。また、編集前に全員が作業の意図を宣言するので、同じコードに対して複数のエージェントがトークンを無駄にすることはありません。衝突はマージ時に発覚するのではなく、最初のキー入力より前に防止されます。

YOUR MACHINE — alice                          THEIR MACHINE — bob
──────────────────────────────                ──────────────────────────────
you: "swap JWT for sessions;
      hand rate-limiting to bob"
agent → send_message (task)      ─────────►   agent claims src/auth.ts
                                              → "unreadMessages: 1" → fetch_messages
                                              (or: tower work accepted it, running claude…)
                                              → does the task, their machine/tokens
                                              → commits (hook completes the claim)
[DONE] bob → alice:              ◄─────────   → send_message (task_update)
"rate limit 30/min, merged in ab12f3"

ステータス：v0.12.1 — 開発初期段階。開発を公開しながら進めています。 以下に記載する機能はすべて、CI で適用されるカバレッジ 80％の基準を満たしながら、現在エンドツーエンドで動作します。リリース済みの内容と今後の予定： CHANGELOG.md · 設計ドキュメント：MVP-SPEC.md。

理由

各ベンダーはエージェントにツールとメモリを提供していますが、あなたのエージェントをチームメイトのエージェントにつなぐものはありません。2人、10個のエージェント、ひとつのコードベース。それなのにエージェント同士は互いを認識できず、作業を引き継げず、同じファイルで衝突します。残るのはマージコンフリクトだけです。Tower は欠けていたコラボレーションレイヤーです。すべてのエージェントがやり取りする、共有のタワーです。git の上に位置し、MCP を_利用_しますが、どちらも置き換えません。構造上、モデルに依存しません。調整が意味を持つのは、_別の_ベンダーのエージェントが参加しているときだけだからです。

必要な6つの用語

claim は自動的に期限切れになります（TTL は15分で、ハートビートによって更新されます）。そのため、クラッシュしたエージェントがファイルを永久にロックすることはありません。また、稼働中のエージェントの claim は自動的に延長されるため、タスクの途中で期限切れになることもありません。

1つのリポジトリが1つの調整スペースです。 Tower はリポジトリの_ルートコミット SHA_ を基準に claim を管理し、これはすべてのクローン、フォーク、ミラーで共通です。そのため、フォークとその上流リポジトリは相互に連携します。また、[email protected]:acme/app.git と https://github.com/Acme/App は、別々のグループではなく同じ場所として扱われます。

使ってみる — 30秒

Node 22.13+ が必要です（組み込みの node:sqlite を使うため、コンパイルは不要です）。 インストールも、ディスクへの書き込みもありません。

npx -y tower-mcp demo

ブラウザーのタブが開きます。実際の hard 競合と、完了済みの委任タスクが設定されたライブボードが表示されます。

Tower demo is live → http://localhost:52410/board#token=demo

What you're seeing: alice and bob both claimed AuthService.verify — a HARD
collision caught before either wrote a line. Below it: a delegated task with
bob's reply + commit, a broadcast still waiting, and a pinned team rule.
Ctrl+C stops the demo (nothing was written to disk).

うまくいきませんでしたか？ npx -y tower-mcp doctor を実行すると、Node、git、ランナー、サーバーを確認し、不足しているものを正確に知らせます。

npm run demo    # after: git clone … && npm install

⛔ COLLISION — AuthService.verify
   Agent "cursor-bob" is mid-change (started 2s ago, ETA ~6m, purpose: replace JWT).
   Options:
     [w] wait      — no need to retry: Tower messages you when their claim ends
     [d] dependent — run: tower next-task  (a module that's safe to start now)
     [b] branch    — build on their WIP instead of racing them
     [f] force     — re-run guard with --force; you own the merge risk

setup が書き込む内容 — すべてリポジトリ内に書き込まれます。グローバルな設定は一切変更せず、設定していないネットワーク呼び出しも行いません。

npx -y tower-mcp setup

エディターを再読み込みすれば完了です。--keep-going を追加すると、書き込まれるルールによって、エージェントは停止してユーザーに尋ねるのではなく、競合を回避するようになります（誰も待たないを参照）。チームサーバーに参加しますか？

npx -y tower-mcp setup --url https://tower-xxxx.onrender.com/mcp --token <team-secret> --hooks

// Claude Code — .mcp.json
{
  "mcpServers": {
    "tower": { "command": "npx", "args": ["-y", "tower-mcp", "serve"] },
  },
}

npx -y tower-mcp init      # writes .tower/policy.yaml + prints MCP setup
npx -y tower-mcp serve     # MCP over stdio (or: serve --http --port 4319 --token <secret>)

git clone https://github.com/Rohanxmalik/Tower && cd Tower
npm install && npm run build
node packages/cli/dist/index.js serve

次に、エージェントのルールファイルに追加します：

「ファイルを編集する前に、変更するファイルとシンボルを指定して claim_intent を呼び出してください。 hard 競合が返された場合は、停止してユーザーに確認してください。応答の alternatives に、作業を続けても安全な対象が示されています。」

セットアップの詳細 → docs/quickstart.md。

マシン間で作業を委任する（基本的なループ）

2人、2台のマシン、2つのアカウントで、1つのリポジトリを使います。Tower の目的はこれです。

1. 委任 — エージェントに「レート制限の作業を bob に任せて」と伝える（または、ルールに従ってエージェントが自分で判断する）と、kind: "task" を指定して send_message を呼び出します。任意のターミナルから手動で実行する場合は tower send を使います（相手と内容を尋ねます。ユーザーの識別情報とリポジトリは git から取得されます）。
2. タスクを受け取る — 次に bob のエージェントが Tower にアクセスすると（任意の claim_intent）、レスポンスに unreadMessages: 1 と表示されます。ルールファイルに従って fetch_messages を呼び出し、対応します。MCP にはプッシュ通知の仕組みがないため、メッセージは受信トレイ形式で配信されます。電話ではなく Slack のように、非同期でやり取りします。常時稼働にすることもできます。 bob のマシンで tower work を実行すると、タスクの受け取りが自動化され、ワーカーがタスクを受け入れてローカルエージェントをヘッドレスで実行するため、エディターは不要です。
3. 作業する — 相手のマシンで、相手のアカウントを使って。 bob のエージェントがファイルを確保するため、他の人がそのエージェントと競合することはありません。bob のトークンと git の識別情報を使ってコードを書きます。API キーがマシン間を行き来することはありません。
4. コミットしてループを完了する — コミット時に git の post-commit フックが sha を使って確保を完了し、エージェントは send_message { kind: "task_update", replyTo: <task> } を返信します。「/login のレート制限を 1 分あたり 30 回に設定し、ab12f3 でマージしました。」あなたのエージェントは次に接続したときに返信を確認できます。また、やり取りはすべて、その間ずっとボードの COMMS パネルに表示されます。tower work を使う場合、結果は ブランチと PR として届きます。ワーカーは tower/task-<id> 上でコミットし、プッシュして PR を作成します。task_update には sha と PR のリンクが含まれます。

常時稼働での委任： npx -y tower-mcp work を実行すると、どのマシンもタスクワーカーになります。委任されたタスクをポーリングし、あなたの確認を得て（または --auto を指定して無人で実行し）、claude -p / codex exec をヘッドレスで動かして、結果の PR を作成します。詳しいガイドとセキュリティモデルはこちら → docs/worker.md。

ワーカーに必要なものは3つあります（npx -y tower-mcp doctor を実行すると、すべて確認されます）。クリーンな git 作業ツリー — 未コミットの変更があると実行を拒否するため、あなたの作業がタスクのコミットに混ざることはありません。PATH 上にある claude または codex。プルリクエストを作成する場合は、認証済みの gh も必要です（これがなくてもブランチはプッシュされます）。

信頼モデルを率直に説明すると、受信したタスクは、チームメイトのエージェントが実行するコードです。共有する TOWER_TOKEN はプッシュ権限と同じように扱い、エージェントは担当範囲外のタスクについて人間に確認する必要があります（SECURITY.md）。

スマートフォンから操作する

ボードは単なるダッシュボードではなく、リモートコントロールです。スマートフォンで https://<your-tower>/board を開きます。

• 送信ボックス — 1行でタスクを委任します。稼働中のワーカーのドロップダウンから相手を選びます（緑色 = オンラインで、すぐに実行されます。オフライン = キューに登録されます）。そのマシンで tower work デーモンがタスクを受け取り、エージェントを実行して PR を作成します。
• 承認／拒否 — --approve remote を付けてワーカーを実行すると、ターミナルで確認を求める代わりに、タスクを1件ずつ保留します。スマートフォンには「cursor-dana が実行しようとしています：/health エンドポイントの追加」と2つのボタンが表示されます。承認をタップすると、ノートパソコンが作業を行います。
• マップ表示 — 指示の流れを示すツリーです。誰が誰に指示しているか、各タスクとその返信、リアルタイムのプレゼンスを示す点が表示されます。任意のエージェントをタップして指示を出せます。（docs/map.png）
• ワンタップ認証 — /board#token=<token> を開くと、文字入力なしで接続できます。

他のすべてと同じ TOWER_TOKEN を使います。ボードを開ける人は誰でもワーカーを操作できるため、プッシュ権限と同じように共有してください。詳細はこちら → docs/worker.md。

重複作業が発生する前に検知する

コストの高い失敗は、通常、マージコンフリクトではありません。2 人のエージェントが同じ作業をしてしまうことです。別々のファイル名を選び、Git ではどちらも問題なくマージされ、1 つの成果物に二重のコストを払うことになります。ファイル単位のチェックではそれを検知できず、どちらかのエージェントがファイルに手を付ける頃には、すでにトークンを消費しています。

そのため、調査を始める前に、エージェントはこれから行う作業を宣言します。

propose_intent  "write a blog post about prompt injection"

⚠️  claude-bob is already on this (2m ago):
    "AI agent security / prompt injection"
    → stand down, or pick something else

パスではなく意味で照合するため、一方のエージェントが prompt-injection-agent-security.mdx を書き、もう一方が ai-agent-security-prompt-injection.mdx を書く場合でも検知します。完全にローカルで動作し、モデルも埋め込みもネットワーク呼び出しも必要ありません。

変更された契約を検知する

主張の鮮度は、それを生み出した読み取りの鮮度に左右されます。

2 人のエージェントが書き込む内容を比較すれば、同じ関数を編集していることを検知できます。しかし、よりよくある失敗は検知できません。alice が auth.ts の AuthService.verify を変更している間に、10 分前に古いシグネチャを読んだ bob が payments.ts に呼び出し元を書きます。ファイルもシンボルも異なるため、何も重複せず、2 人とも作業を続けるよう指示され、bob が気付くのは CI です。

そこで、主張には、それが基づいている内容も含まれます。

claim_intent  files: ["src/payments.ts"]  symbols: ["charge"]

[HARD] AuthService.verify moved under you — alice changed the declaration you read
    was: verify(token: string)
    now: verify(token: string, opts: Opts)

これを有効にしておく価値がある理由は、次の 2 点です。

警告ではなく、差分を表示します。 エージェントに「コンテキストが古い可能性があるため、ファイルを読み直してください」と伝えると、1 つのパラメーターが移動したことを確認するために、モジュール全体をコンテキストに読み戻す必要があります。代わりに 2 行で差分を示すため、エージェントは何も読み直さずに呼び出し箇所を修正できます。

呼び出し元が実際に壊れる場合にのみ検知します。 フィンガープリントが対象とするのは_宣言_のみで、本体は対象外です。そのため、実装の書き換え、ローカル変数名の変更、コメントの変更、prettier の実行では何も変わりません。一方、パラメーターの追加や戻り値の型の変更は必ず検知します。

読み取った内容を宣言する必要はありません。PostToolUse フックが Read を監視し、各宣言のシグネチャを読み取り時点の状態で記録します。先に作業を宣言した後で何かが変更された場合は、エージェントがすでに 60 秒ごとに行っている呼び出しで heartbeat が知らせます。

正直なところ、同じシグネチャのまま動作だけが変わった場合は検知できません。誤検知をほぼゼロに抑えるためのトレードオフです。docs/protocol.md を参照してください。

誰も待ちません

以前は拒否されるとそこで終了でした。stand_down と、エージェントにあなたへ確認するよう指示するルールだけでした。 1つの競合で、誰かが気づくまでエージェントは停止していました。0.12.0 以降、競合は 迂回路になります。

拒否の際に、引き続き安全にできることを伝えます。 alternatives を含みます。避けるべきことと、 一行のアドバイスです。

(claim REFUSED — another agent holds this. Re-run with --force to override.)
What to do instead:
  Held by bob (~10 min). Don't wait: work on anything outside the 2 symbols in
  `avoid`. Tower will message you when it frees up — no need to retry.
  Avoid for now: AuthService.verify() (src/auth.ts), charge() (src/payments.ts)

Tower が charge を推論したため、ここに含まれています。以前の claim で verify を読み取ったうえで charge が記述されていたため、charge は verify に依存します。依存関係マップを記述する必要はありません。 エージェントが実際に読み取った内容から導き出されます。

誰もポーリングしません。 bob の claim が完了、解放、または期限切れになった瞬間、拒否されていたエージェントは tower から、何が解放されたかを知らせるメッセージを受け取ります。

同じことが、PreToolUse フックまたは git pre-commit ガードによってブロックされた場合にも当てはまります （0.12.1 以降）。ブロックされたエージェントは、代替案を確認でき、claim が解放されたときにメッセージを受け取ります。

編集時ではなく、読み取り時に知らせます。 誰かが変更中のファイルを開くと、 PostToolUse フックがその時点でエージェントに通知します。これから変更されるコードを前提に何かを計画する前に知らせます。

依存する作業は並列で進みます。まず契約を提示します。 alice がシグネチャを変更する場合、 変更後の内容を伝えます。

claim_intent  symbols: [{ symbol: "AuthService.verify",
                          declares: "verify(token: string, opts: Opts): boolean" }]

呼び出し側を書く bob には、verify が変更されるという警告だけでなく、その契約が渡されます。 そのため alice が変更を反映するのを待たず、すぐにそれに基づいてコードを書けます。alice が完了すると、Tower は実際に反映された内容を確認し、bob に宣言どおりかどうかを伝えます。つまり、計画が変わっていた場合、CI ではなく Tower から知らせを受け取ります。

エージェントが自力で作業を続けられるようにします。 tower setup --keep-going は、競合時に avoid の範囲外で作業し、安全にできることが何もない場合にのみ人間へ確認するルールを書き込みます。 既定のルールは引き続き、停止して確認するよう指示します。人の返答を待つのは慎重な選択であり、これまでどおり既定の動作です。

実際に衝突するもの

$ tower stats

2 collision(s) recorded

  by kind
    write_write  1  (50%)  two agents on the same symbol
    write_read   1  (50%)  a contract moved under a reader

件数のみです。ファイル名、シンボル名、コードは含まれず、マシンの外に情報が送られることもありません。 Tower は4つのバージョンにわたって衝突を検出しながら、その都度すべて忘れてしまっていたため、実際にどの種類の衝突が起きるのか誰も把握できませんでした。この機能はそのためにあります。

20 個のツール

ワイヤーコントラクト → docs/protocol.md。

仕組み

MCP clients (Claude Code / Cursor / Codex)
        │  stdio  ·  HTTP/SSE
        ▼
Tower server ── collision engine (tree-sitter) · agent inbox · sequencer · SQLite · /board UI
        ▲
tower CLI: demo · doctor · init · setup · serve · status · stats · watch · complete · claim · guard · next-task · send · inbox · nudge · work · version

• **テキストではなく意味に基づきます：**シンボルは tree-sitter の AST（TS/JS/Python）から取得するため、異なる diff のハンク間でも AuthService.verify は競合します。
• **モデルに依存しません：**これは MCP サーバーであり、現在、主要なエージェントすべてが利用できます。

強制適用（エージェントの記憶に頼らない）

エージェントが自ら選んで行うツール呼び出しは、安全策にはなりません。Tower には3 つの強制適用レイヤーがあります。組み合わせて使いましょう。

1. MCP ツール＋ルールファイル — すべてのエージェント（Claude、Cursor、Codex）は編集前に申告します。 tower setup がこれを設定します。
2. Claude Code フック — 競合する Edit／Write／MultiEdit は物理的に ブロックされます。⚠️ 現時点では Tower のクローンが必要です — フックスクリプトは npm パッケージには含まれていません。クローンから実行され、ビルド済みの CLI をインポートします：

   npm install && npm run build
   npx tower-mcp init --hooks   # writes .claude/settings.json, then reload Claude Code
   

   これにより 5 つのフックが設定されます：SessionStart はセッションを登録し、UserPromptSubmit はタスクやメッセージが待機中であることを通知し、PreToolUse は強く競合する編集をブロックし（終了コード 2）、PostToolUse は編集時にアクティブ状態を維持し、Read 時には読んだ内容を記録して、誰かが変更中の場合に警告し、SessionEnd は申告を解除します。既存のインストールをアップグレードする場合も同じコマンドを使います — git pull && npm install && npm run build && npx tower-mcp init --hooks — Tower 自身のエントリーを現在のバージョンに書き換え、ユーザー独自のフックは変更しません。 再実行しても変更はありません。
3. 汎用 git pre-commit ガード — あらゆるエディターやエージェントで機能します。チームメイトのエージェントが競合する申告を保持している間は、コミット自体が拒否されます：

   cp examples/git-hooks/pre-commit .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit
   

フックの精度について： 各編集箇所を特定し、その編集が行われる関数を申告するため、同じファイル内でも異なる関数を編集する 2 つのエージェントが互いをブロックすることはありません。Write、新規ファイル、または宣言間（インポートやトップレベルのコードなど）の編集は、ファイル全体にフォールバックします。過剰な申告は安全ですが、過少な申告は安全ではありません。対象範囲と制限の詳細 → docs/enforcement.md。

ライブボード

serve --http を実行すると、Tower は常に /board にライブボードを提供します（2 秒ごとに更新されます）。 すべてのエージェントのアクティブな申告、赤色で示される競合、各申告が開始されてからの経過時間を確認できます — さらにCOMMS パネルには、届いたすべてのメッセージと委任されたタスクが表示されます。エディターの横で開けば、誰が何を担当しているか、進行中のタスクは何か、エージェント間のすべてのメッセージを確認できます（この README の冒頭にスクリーンショットがあります）。

これは何を表示するものなのか、明確にしておきます。ボードに表示されるのは申告、タスク、メッセージであり、エージェントのセッションをリアルタイムで記録したものではありません。各エージェントが何に取り組むと宣言し、どのような報告を返したかを確認できますが、キー入力は表示されません。

ターミナルからエージェント用チャンネルを使うには、send を実行するだけです。自分が誰で、どのリポジトリかは git から取得され、他の情報はプロンプトで尋ねられます：

$ npx -y tower-mcp send
To (agent id, or * for everyone): bob
Message: add rate limiting to /login
Is this a task for them? [y/N]: y
📨 Sent task c78094d1 → bob

$ npx -y tower-mcp inbox         # your messages (identity inferred from git)

（スクリプトやエージェントからは、代わりにフラグを渡します：send --to bob --body "..." --task — プロンプトが表示されるのは実際のターミナルだけです。）

GitHub Action：PR の競合レポート

サーバーは不要です — ワークフローファイルを 1 つ追加するだけで、別のオープン PR と同じファイル（重複する行は明示）を変更する PR にコメントし、ホスト型 Tower を実行している場合はライブのエージェント申告も表示します：

- uses: Rohanxmalik/Tower/[email protected]

このようにリリースタグを固定します。@main も使えますが、最新の開発版が追跡されます。セットアップとスクリーンショット → docs/action.md。

チームモード（チーム全員、異なるマシン）

全員のエージェント（Claude、Cursor、Codex）を1つのTowerに接続します。2人のエージェントが 同じファイルを編集しようとすると、マージ時ではなく、トークンを消費する前に2人目に警告が表示されます。 チームに合わせて、次の2つのセットアップから選んでください。

• 同じオフィス／同じWi-Fi（または同居している場合）： デプロイもトンネルも不要です。ノートPC 1台でホストし （serve --http --host 0.0.0.0）、全員がその192.168.x.xアドレスに接続します。2分で設定できます。
• リモート／異なるネットワークの場合： Towerをオンラインで1台ホストし、永続的なHTTPS URLを使用します。

約5分で自分の環境をオンラインにデプロイできます（無料プランあり）。トンネルは不要です。

または、Dockerで自分で管理します。

TOWER_TOKEN=your-secret docker compose up -d   # http://<host>:4319/mcp

各開発者の.mcp.jsonでは"type": "http", "url": ".../mcp"を使用します。これでClaudeが 共同創業者のCodexに「コミットabc123まではauthに手を付けないで」と伝えられます。初心者にもわかりやすい完全なセットアップ手順 （同じWi-Fiモード＋Renderのクリックごとの手順＋エディター別の設定）はこちらです → docs/team.md。

🚀 自分でホストしたくないですか？ チーム向けのマネージド型常時稼働コーディネーションサーバー Tower Cloud が近日登場します。ウェイトリストにご登録ください。

信頼性、データ、削除方法

• テレメトリーはありません。 Towerは、設定したものを除き、ネットワーク通信を行いません。ボードページは外部リソースを一切読み込みません（CDN、フォント、アナリティクスもありません）。
• データはリポジトリ内に保存されます。 クレーム、メッセージ、タスク、決定事項は .tower/tower.db（通常のSQLiteファイル）に保存されます。このフォルダーを削除すれば、データも削除されます。
• APIキーがマシン間を移動することはありません。 ワーカーは、そのマシンにすでにインストールされているclaude／codexをシェルから呼び出します。Towerがベンダーの認証情報を参照することはありません。
• TOWER_TOKENは共有シークレットです。プッシュアクセス権と同様に扱ってください。 このトークンを持つ人は、チームのワーカーにタスクを委任できます。SECURITY.mdを参照してください。
• Towerが失敗しても、作業を妨げることはありません。 すべてのフックは_オープンに失敗_します。Towerに接続できない場合やフックでエラーが発生した場合でも、編集とコミットは続行できます。
• 削除するには： .tower/を削除し、.mcp.jsonからtowerエントリーを削除します。--hooksを使ってインストールした場合は、.git/hooks/pre-commitとpost-commitも削除します。init --hooksを実行した場合は、.claude/settings.jsonからTowerのnode hooks/…エントリーも削除してください。

モノレポの構成

packages/shared   protocol types + zod schemas (source of truth)
packages/server   collision engine, sequencer, SQLite store, MCP server, transports
packages/cli      the `tower` command
hooks/            the five Claude Code hooks (SessionStart … SessionEnd; PreToolUse blocks)
action/           GitHub Action — PR collision reports
extensions/       tower-anywhere — claim-before-you-edit for non-code work (docs, briefs)
examples/         two-agents-demo, git-hooks (pre-commit guard, post-commit release)
docs/             quickstart, protocol, worker, enforcement, team, action
Dockerfile        hosted team server

開発

npm install
npm test          # vitest, 80% coverage gate
npm run build     # tsc -b

ロードマップ

• エージェントごとのIDと認証（現状はチームで共有するトークン1つ）— Tower Cloudの基盤
• シンボル抽出に対応する言語文法の追加（Go、Rust、Java — コントリビューション歓迎）
• 競合の予測検出（マージ履歴を使ったML）— 将来的な競争優位性
• 自動解決／調整エージェント
• リポジトリ横断／組織全体のインテントグラフ＋APIコントラクトの破壊的変更検出
• エンタープライズ向け：ポリシーエンジン、SSO、監査台帳

コントリビューションとコミュニティ

PRを歓迎します。CONTRIBUTING.mdをご覧ください（TDD、小規模なPR、初めての方におすすめのアイデアを掲載しています）。 セキュリティに関する報告 → SECURITY.md。変更履歴 → CHANGELOG.md。

ライセンス

MIT