mcpField
R
Rhizome MCP

Rhizome MCP

ローカル
odrin.github.ioAI・エージェント12 週間前に更新

Rhizome MCP について

Rhizome MCPは、同じリポジトリで作業するコーディングエージェント向けのローカル優先型タスク調整サーバーです。SQLiteベースのリース、チェックポイント、バージョン固定レビューにより、デーモンやクラウドサービスなしで復旧と引き継ぎを支援します。

主な機能

  1. 01期限付きリースによる障害耐性のあるタスク取得
  2. 02セッション間引き継ぎ用チェックポイント
  3. 03課題と依存関係の計画
  4. 04バージョン固定のレビュー依頼
  5. 05ローカルプロジェクトボードとCLI

活用シーン

  1. 01複数のコーディングエージェントセッションの調整
  2. 02エージェント中断後の作業再開
  3. 03ブロッカーとタスク依存関係の追跡
  4. 04固定された課題バージョンに基づく変更レビュー

MCP 対応

デフォルトのstdioで、タスク、計画、引き継ぎ、レビュー機能をMCPクライアントに公開し、ループバック限定のStreamable HTTPも選択できます。プロジェクトごとにSQLiteデータベースを使用します。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"odrin-rhizome": {
"command": "npx",
"args": [
"-y",
"rhizome-mcp"
]
}
}
}
起動コマンドnpx -y rhizome-mcp

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
npmrhizome-mcp1.6.1

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

rhizome-mcp ロゴ

CI 単体テストのカバレッジ 統合テストのカバレッジ 最新リリース Go バージョン ライセンス npm npm のダウンロード数 MCP レジストリ

コーディングエージェントがタスクの途中で停止すると、タスクは自ら解放されます。

rhizome-mcp は、自律型コーディングエージェントに MCP 経由のクラッシュセーフなタスク調整機能を提供します。タスクの割り当ては更新可能で期限切れになるリースであり、in_progress は保存されることなく導出され、中断された試行のチェックポイントは、次に作業を引き継ぐセッションに渡されます。静的な Go バイナリ 1 つ、プロジェクトごとに SQLite データベース 1 つ。デーモンもアカウントもクラウドも不要です。

異なる製品のエージェントを同時に利用できます。Claude Code、Codex、GitHub Copilot、VS Code、その他の MCP 対応クライアントに、プロジェクトの作業状況を共有する永続的なビューを提供します。

1 つの課題に対する 2 つのエージェントセッション。2 回目の割り当ては ACTIVE_ATTEMPT_EXISTS によって拒否され、最初のエージェントが停止するとリースが期限切れになり、2 つ目のセッションが課題を割り当てられてチェックポイントから再開します

demo/record.sh が実際のサーバー出力を記録したものです。演出はありません。

理由 · 比較 · クイックスタート · プロジェクトを監視する · MCP の機能 · ドキュメント

理由

AI コーディングエージェントは並行して動作し、コンテキストに制限があり、中断されることもあります。TODO.md や単一のチャットコンテキストでは、こうした状況に対応できません。rhizome-mcp は、これらの障害パターンを前提に設計されています。

  • クラッシュに強いタスク取得。 イシューは、更新可能なリースを使ってアトミックに取得されます。in_progress は保存されるステータスではなく、アクティブなリースから導出されます。そのため、消失したエージェントがイシューを永久にロックすることはありません。リースの有効期限が切れると、イシューは再び取得可能になります。部分ユニークインデックスにより、データベースレベルで各イシューのアクティブな試行は最大 1 件に保証されます。

  • 契約によるトークン効率化。 コンパクトな一覧表示(100 件のイシューページが 64 KB 未満に収まることを統合テストで検証)、SQL レイヤーで自由記述の本文を除外するグラフノード、スニペットのみの検索、イベント ID による差分同期、上限付きの単一呼び出し作業コンテキストパッケージを備えています。

  • 永続的なプロジェクトメモリ。 次の手順を含むチェックポイント、置き換え可能な意思決定記録、追記専用のイベント履歴、イシュー、コメント、意思決定、メモを対象とする FTS5 全文検索を備えています。新しいセッションでは、状態を再導出するのではなく、最後のチェックポイントから再開できます。

  • 計画と依存関係グラフ。 循環をチェックする blocks 関係、エピック、取得可能な開始点の強調表示、およびアトミックな一括計画(最大 50 件のイシュー、100 件の関係、20 件の意思決定を 1 回の全成功または全失敗のトランザクションで処理)を備えています。

  • レビューのワークフロー。 レビュー依頼は、特定のイシューバージョンとイベント位置を固定します。変更後のコードを承認することは構造上不可能で、古くなった依頼は後継の依頼に置き換えて、新しいバージョンに固定することしかできません。

    古くなった承認が拒否される様子を見る

    バージョン 2 に固定されたレビュー依頼は、イシューがバージョン 3 に進むと承認を拒否します。replace_review_request はこれを置き換え、新しいバージョンに固定された後継の依頼を作成します

  • リソース予約。 取得時に、ファイル、ディレクトリ、グロブ、または論理リソース(ポート、マイグレーション用の時間枠、デプロイ枠)をアトミックに予約できます。予約が重複する取得は、後から 2 つのエージェントが競合するのではなく、保持者とリースの有効期限を示して即座に失敗します。

    予約の競合によって取得がアトミックに失敗する様子を見る

    重複するリソース予約により、保持している試行とそのリースの有効期限を示して、RESOURCE_RESERVATION_CONFLICT で取得全体が失敗します

  • 一貫した並行処理の規律。 ミューテーションには楽観的バージョン管理を適用し、再実行に安全な冪等性キーと、機械処理可能で安定したエラーコードを備えています。

  • サーバー不要の人間向け可視化。 rhizome-mcp board は、有効なリース、ブロッカー、レビューキューを表示するか、自己完結型の HTML スナップショットを書き出します。CLI ではすべてをテーブル、JSON、または Mermaid 形式で読み取れます。

このリポジトリは、自身が提供するサーバーを通じてバックログを管理しています。作業の選択、取得、チェックポイントの作成、レビューはすべて rhizome-mcp 自体を介して行われます(AGENTS.md)。

次のような場合に使用してください: 複数のエージェントセッション(または複数のエージェント製品)が、同じリポジトリで長期にわたって作業し、引き継ぎ、並行作業、クラッシュやコンテキスト制限からの復旧が必要な場合。

次のような場合は使用しないでください: 認証、権限、ウェブ UI を備えたホスト型のマルチユーザートラッカーが必要な場合。このツールは、設計上、ローカルで使う単一開発者向けです。

比較

エージェントのタスクトラッカーは、機能一覧ではなく、障害発生時の保証内容で比較してください。このカテゴリでは、ローカルファーストの SQLite ストレージと MCP サポートは基本要件です。

問題発生時の動作rhizome-mcpbeadsKataGuild
クラッシュ後にタスクが自動で解放されるはい — 有効期限付きリースいいえいいえいいえ
ストレージ層で二重取得を防止するはいアトミックな取得アトミックな取得アトミックな取得
古いレビュー承認が不可能はい — バージョンを固定いいえいいえいいえ
テスト済みの契約に基づいて応答サイズを制限はい — ≤ 64 KiB / 100 issuesいいえいいえいいえ
中断された試行を別のセッションで再開可能はい — チェックポイントいいえいいえ注記のみ

ソース、固定バージョン、率直な「どのような場合に X を選ぶか」のガイダンスを含む詳細な比較については、**rhizome-mcp の比較**をご覧ください。

クイックスタート

インストールして実行

ワークフローに合った方法を選んでください。

npm でインストール不要ですぐに試す

別途バイナリをインストールしたり、Go ツールチェーンを用意したりせずに、すぐに rhizome-mcp を試せます。

npx rhizome-mcp serve

あらゆる MCP クライアントで動作します。対応プラットフォームについては、packages/npm/README.mdをご覧ください。手早く評価するのに最適です。

Claude Code プラグイン
/plugin marketplace add Odrin/rhizome-mcp
/plugin install rhizome-mcp@rhizome

MCP サーバーを登録し(npx 経由、バイナリのインストール不要)、rhizome-task-workflow と rhizome-execution-plan のスキルを追加します。追跡する各リポジトリのルートで、一度だけ npx rhizome-mcp init を実行する必要があります。

VS Code

マーケットプレイスまたは Open VSXから Rhizome MCP(odrin.rhizome-mcp)をインストールします。この拡張機能にはプラットフォーム用バイナリが含まれており、MCP サーバーを自動的に登録し、コマンドパレットに Rhizome: Initialize Project を追加します。ターミナルも mcp.json の編集も不要です。詳細については、docs/10-vscode-extension.mdをご覧ください。

代わりに、単体のバイナリを使い、シンプルな mcp.json エントリを設定しますか?下記からバイナリをインストールし、このワンクリックリンクをご利用ください:VS Code に追加。

ネイティブバイナリインストーラー

お使いのプラットフォーム用のリリースバイナリをダウンロードしてインストールします。チェックサムを検証し、デフォルトで ~/.local/bin にインストールします。

curl -fsSL https://raw.githubusercontent.com/Odrin/rhizome-mcp/main/scripts/install.sh | sh
irm https://raw.githubusercontent.com/Odrin/rhizome-mcp/main/scripts/install.ps1 | iex
公式 MCP レジストリ

レジストリを利用するクライアント向けに、Model Context Protocol registryで io.github.Odrin/rhizome-mcp として公開されている公式 MCP レジストリ経由で rhizome-mcp を利用できます。

初期化して接続する

リポジトリ内で追跡を初期化します。

rhizome-mcp init

次に、MCP クライアントにサーバーを登録します。一般的なクライアント向けの自動セットアップ:

rhizome-mcp connect claude    # Claude Code
rhizome-mcp connect codex     # Codex
rhizome-mcp connect vscode    # VS Code (if using standalone binary instead of extension)
rhizome-mcp connect json      # Template for any other client

ドライランには --print を使用します。connect は、serve と同じ方法で現在のディレクトリから上位をたどり、プロジェクトの実際のルートを見つけ、それを --project-root で固定します。これにより、後で MCP クライアントがどのサブディレクトリからサーバーを起動しても、書き込まれた設定が機能します。4 つのターゲット(claude、codex、vscode、json)はすべてこの動作に対応しています。任意の MCP クライアント向けに、connect 自身のサーバーキーに一致する手動設定を行う場合:

{
  "mcpServers": {
    "rhizome-mcp": {
      "command": "/absolute/path/to/rhizome-mcp",
      "args": ["serve", "--project-root", "/absolute/path/to/your/repository"]
    }
  }
}

または、バイナリをインストールせずに npx 経由で設定する場合:

{
  "mcpServers": {
    "rhizome-mcp": {
      "command": "npx",
      "args": ["-y", "rhizome-mcp", "serve", "--project-root", "/absolute/path/to/your/repository"]
    }
  }
}

connect は、npx rhizome-mcp ラッパー経由で自身が実行されていることを検出し、解決済みのバイナリパスの代わりに、この npx 形式を自動的に出力します。解決済みのバイナリパスは npx キャッシュ内にあり、キャッシュの削除やバージョンの更新によって古くなります。解決済みの絶対パスを使って書き込まれた設定(それ以外の場合のデフォルト)はマシン固有であり、チェックインして複数のマシン間で共有することを想定していません。共有するポータブルな設定を出力するには、connect TARGET --command を渡して、代わりに PATH に依存する rhizome-mcp というコマンド名を出力します。この設定を使うすべてのマシンで、rhizome-mcp が PATH 上にある必要があります。

デフォルトのトランスポートは Stdio です。プロトコル出力は stdout に、ログは stderr に出力されます。

これで完了です。接続されたエージェントは、絶対リポジトリルートを指定して open_project を呼び出し、返された project_ref を保持して、以降のプロジェクトスコープの呼び出しに渡します。ワークフローの全容については、エージェントのワークフローガイドを参照してください。返されるメタデータには、rhizome://guides/agent-workflow、rhizome://guides/issue-lifecycle、rhizome://guides/multi-agent-handoff の各リソースへのリンクが含まれます。また、リポジトリ内のエージェントは .github/skills/ から rhizome-task-workflow スキルを読み込めます。

エージェントのワークフロースキルをインストールする

オープンな Agent Skills 形式に対応するエージェントには、npm で配布されている skills CLI を使って rhizome-task-workflow をインストールします。

npx skills add Odrin/rhizome-mcp --skill rhizome-task-workflow

プロジェクトスコープでインストールするには、プロジェクト内でこのコマンドを実行します。プロジェクトをまたいでスキルを利用できるようにするには、--global を追加します。このスキルは、互換性のあるエージェントが Rhizome の作業を選択、取得、チェックポイント化、引き継ぎ、完了する方法を学べるようにします。MCP サーバーを補完するものであり、rhizome-mcp バイナリをインストールしたり、MCP 接続を設定したりするものではありません。

プロジェクトを監視する
rhizome-mcp board                        # status counts, active leases, blockers, review queue
rhizome-mcp board --serve                # interactive local board UI at a loopback URL
rhizome-mcp board --output board.html    # self-contained HTML snapshot with the planning graph
rhizome-mcp issue list --status ready
rhizome-mcp graph ISSUE-42 --format mermaid
rhizome-mcp doctor --full

シード済みプロジェクトの rhizome-mcp ボード:ステータス数、実行中のリース済み試行 2 件、アクティブなディレクトリ予約、理由付きのブロック中イシュー

ステータスボードには、現在のリース数、ブロック中のイシューとその理由、未解決のレビューリクエスト、プロジェクト全体の計画グラフが表示されます。計画グラフでは、ノード予算の計算から完了済みの作業(完了、キャンセル)を除外するため、エントリーポイント数は常に取得可能な作業を反映します。100 ノードの予算によりグラフが切り詰められた場合、ボードにその旨が表示され、保持されたノード数がテーブル形式と JSON 形式の両方で報告されます。

オプション:ローカル HTTP トランスポート
rhizome-mcp serve --http-address 127.0.0.1:0

バインドされたエンドポイントは stderr に記録されます。Streamable HTTP エンドポイントは http://127.0.0.1:<port>/mcp です。このトランスポートはループバックのみで、認証はなく、厳格な Host/Origin 検証と 1 MiB の外側リクエスト本文サイズ制限を適用します。最新の MCP 2026-07-28 クライアントは server/discover を呼び出した後、プロトコルメタデータ付きの直接リクエストを送信します。従来の 2025-11-25 クライアントも、永続的なトランスポートセッションに依存せずに initialize と notifications/initialized を使用できます。永続的な監査属性を記録するには、create_agent_session で明示的な agent_session_handle を作成し、該当する変更用ツールに渡して、後で end_agent_session を使って終了します。トランスポートが閉じても、セッションは終了しません。

仕組み

init は、リポジトリに次のファイルを1つだけ書き込みます。

{
  "version": 1,
  "project_id": "01J..."
}

このファイルは .agent-tracker.json として保存されます。SQLite データベースはリポジトリの外にあるプラットフォームのアプリケーションデータディレクトリに置かれ、project_id を使って解決されます。

<application-data>/rhizome-mcp/projects/<project-id>/tasks.db

任意のコマンドで --data-root PATH を使うと、明示的なデータルートを選択できます。リポジトリに対してこれ以外の変更は行われず、データベースが Git にコミットされることもありません。

設計原則: issue が in_progress のまま永久に滞留してはなりません。有効なステータスは、保存されたステータスと有効なリース付き試行の有無から算出されます。エージェントが消えてリースが期限切れになると、試行は expired になり、保存された状態が許す場合、issue は再び利用可能になります。

コア制約(設計上): Go、SQLite(modernc.org/sqlite、純粋な Go、CGO 不使用)、主要なトランスポートとしての stdio、プロジェクトごとに1つのデータベース、ホスト型または認証付きのウェブ UI はなし(ループバック接続のみのローカルステータスボードを含みます)、認証なし、最小限の CLI。延期された機能については docs/06 を参照してください。

CLI リファレンス

コマンド目的
init.agent-tracker.json とプロジェクトデータベースを作成します
serve [--http-address ADDR] [--profile full|agent|read-only|migration] [--toolsets GROUP[,GROUP...]] [--project-root PATH]MCP サーバーを実行します(stdio。ローカル HTTP には --http-address を指定します。公開するツールカタログを名前付きプロファイルに絞り込むには --profile を、機能グループからプロファイルを構成するには --toolsets を指定します。作業ディレクトリ以外のプロジェクトを提供するには --project-root を指定します)
connect TARGET [--print] [--command]MCP クライアント(claude、codex、vscode、json)にサーバーを登録します
board [--output PATH] [--serve [--http-address ADDR]]ステータスボード:件数、リース、ブロッカー、レビュー待ちキューを表示します。任意で HTML スナップショットを出力できます。--serve は一時的な HTTP サーバーを実行します
issue list / issue show ISSUE-IDフィルターを使って issue を確認します
search QUERYissue、コメント、決定事項、メモを全文検索します
graph ISSUE-ID依存関係グラフを表、JSON、または Mermaid 形式で表示します
project info / project export / project importプロジェクトのメタデータ、論理 JSON エクスポート、論理 JSON インポート(--dry-run または --apply とともに `--input PATH
backup --output PATHWAL セーフなオンラインバックアップ
doctor [--full]整合性、スキーマ、不変条件を確認します
maintenance release-attempt / rebuild-search-index / normalize-issue-timestamps --backup PATH管理者向けの復旧操作です。タイムスタンプの正規化には、新たに検証済みのバックアップが必要です

引数を指定せずに rhizome-mcp を実行すると使用方法全体が表示されます。ビルド情報は rhizome-mcp version で確認できます。

MCP の対象範囲

このサーバーは、プロジェクトの検出、ラベルと関連付けを含む課題の CRUD、アーカイブ/アーカイブ解除による可視性の切り替え、計画と依存関係グラフ、一括計画の検証/適用、コメントと決定、任意のアトミックなリソース予約を伴う作業試行のクレーム/更新/チェックポイント/完了、作業コンテキストの構築、レビュー依頼、全文検索、差分変更、論理プロジェクトのエクスポート/インポート、ゲートのエビデンスと診断を含むワークフローポリシーの管理まで、ライフサイクル全体をカバーする44個のツールを公開します。MCP ツールのアノテーションマトリクスと、full/agent/read-only/migration の公開プロファイルマトリクスを含む完全な仕様は、docs/03-mcp-tools.md にあります。

デフォルトでは、serve は完全な full カタログを公開します。--profile agent|read-only|migration を渡す(または RHIZOME_TOOL_PROFILE を設定する)と公開範囲を絞れます。たとえば、変更を行うツールを一切表示すべきでないクライアントには、serve --profile read-only を指定します。適切な名前付きプロファイルがない場合は、代わりに --toolsets を渡す(または RHIZOME_TOOLSETS を設定する)ことで、カンマ区切りの機能グループを指定できます。たとえば、serve --toolsets issues,planning とすると、常時有効な core の2つのツール(open_project、get_project)に加えて、指定したグループだけを公開します。この2つのフラグは同時に指定できません。プロファイルとツールセットは公開範囲とプロンプトサイズを制御するものであり、認可の境界ではありません。クライアントから tools/list で見えるかどうかにかかわらず、すべてのツールでサーバー側の検証が行われます。非推奨のプレフィックスなしフォールバック名を含む、環境変数と優先順位の全容については、docs/04-storage-runtime.md §17.1 を参照してください。

ドキュメント

docs/ 以下のモジュール別ファイルが正式な仕様です。SPEC.md は索引です。エージェントは、現在のタスクに関連するセクションだけを読み込んでください(その方法については AGENT_BRIEF.md で説明しています)。

  1. 製品の目標と範囲
  2. ドメインモデル
  3. MCP ツール
  4. ストレージとランタイム
  5. 実装要件
  6. 保留中の機能と対象外事項
  7. 論理交換フォーマット
  8. ローカル HTTP トランスポート仕様
  9. レビューワークフロー仕様
  10. VS Code 拡張機能
  11. プロジェクトルーティング仕様
  12. リソース予約
  13. ステータスボード

人間向けのガイド(クイックスタート、ワークフロー、CLI)は site/ にあり、GitHub Pages で公開されています。リリース履歴は CHANGELOG にあります。

開発

ビルドとテスト(CGO および外部サービスは不要です):

CGO_ENABLED=0 go build -o rhizome-mcp .
go test ./...
go test -tags=integration ./...

integration タグでは、実際のプロセスを使った MCP のスモークテストとワークフローテストを実行します。テストごとに一時的なサーバーバイナリをビルドし、新しいリポジトリと SQLite データルートを初期化して、stdio または HTTP 経由で serve と通信します。単一プロセスのスモークテストに加えて、同じ SQLite データルートを共有するプロセス間のシナリオもテストします。具体的には、claim と update-version の同時実行競合、正常終了しないプロセスの強制終了と再起動、サーバーの書き込み中に実行するバックアップを検証し、単一プロセスのテストでは構造上検出できない不具合を見つけます。大半のテストは専用の integration パッケージにあります。非公開の package-main 内部実装が必要なテストは、リポジトリのルートにあります。

CI では、go vet、レース検出器を使わないすべてのユニットテストと統合テスト、npm ランチャーのテストを、main を対象とするすべての push とプルリクエストで Ubuntu、macOS、Windows 上で実行します。Linux では既存のファジング実行時間もテストし、別のカバレッジジョブでユニットテストと統合テストのカバレッジしきい値を検証します。これと並行して、Linux の Race smoke ジョブでは、レース検出器を使い、claim、reservation、transaction-admission、project-router、HTTP-lifecycle の各テストから明示的に選んだものを実行します。このテスト対象の選定は .github/workflows/ci.yml で管理しています。

Full race checks は、毎日 02:17 UTC に最新の main を対象として、ユニットテストと統合テストの全レーステストを実行します。GitHub により、スケジュールされた実行が遅れることがあります。また、Actions タブから Run workflow を選び、マージ前の機能ブランチを含むブランチを指定して手動で開始することもできます。このワークフローは、テスト対象のコミットを記録し、JSON 形式のテストログを 14 日間保存します。また、通常の CI および Race smoke とは別のキャッシュを使用します。夜間テストとスモークテストでは -count=1 を指定し、キャッシュされた成功結果によってテストの実行が省略されないようにしています。

Full race checks はプルリクエストのマージ条件ではありません。プルリクエストが成功しても、確認できるのは選定されたレーステストであり、レーステスト全体ではありません。選定対象外のレースによるリグレッションは、マージ後、次回のスケジュール実行で検出される可能性があります。夜間テストの失敗を監視し、速やかに修正するか、変更を取り消してください。ローカルでレーステスト全体を検証する場合(CGO と C コンパイラーが必要です):

go test -race -count=1 ./...
go test -race -count=1 -tags=integration -run '^TestIntegration' ./...

テストハーネスにレース検出器が組み込まれている場合、統合テストハーネスは実際のサーバーサブプロセスも -race 付きでビルドします。

リリース(.github/workflows/release.yml)では、linux/amd64、linux/arm64、darwin/amd64、darwin/arm64、windows/amd64 向けに、CGO 不要のバイナリと SHA-256 チェックサムを公開します。リリースバイナリにはバージョン、コミット、ビルド日時が埋め込まれます(ローカルビルドでは git VCS 情報、または dev が報告され、VERSION 環境変数を設定すると両方が上書きされます)。

リリースの検証手順については、CONTRIBUTING.md に記載しています。

このリポジトリは、rhizome-mcp で独自のバックログを管理しています。作業は MCP サーバーを通じて選択、claim、完了し、永続的な決定事項は decision として記録します。Markdown には仕様のみを記載し、タスクのステータスは記載しません。AGENTS.md と CONTRIBUTING.md を参照してください。

ライセンス

Apache-2.0。セキュリティポリシー:SECURITY.md。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。