mcpField
A
agent-mesh

agent-mesh

ローカル
github.com/johnmwhitmanAI・エージェント11 週間前に更新

agent-mesh について

agent-meshは、OpenCode向けの監査可能なマルチエージェント調整サーバーです。専門エージェントを並列稼働させる用途を想定し、独立プロセス、ピア間メッセージ、受領記録、定足数による決定をローカルに記録します。

主な機能

  1. 01並列エージェントフリートの起動
  2. 02ピア間メッセージと引き継ぎ
  3. 03受信者ごとの配信・既読記録
  4. 04定足数に基づく評議会の決定
  5. 05ローカル台帳の検査と検証

活用シーン

  1. 01探索と実装を並行して実行
  2. 02専門エージェント間でタスクを振り分け
  3. 03エージェント承認の証跡を確認

MCP 対応

標準のstdio MCPサーバーとして、MCPクライアントにフリート調整と台帳のツールを提供します。ワーカーは既定でOpenCodeのopencode-cliランタイムを使用します。

設定

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

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

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

パッケージ
npmmeshfleet0.22.0

ツール

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

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

詳細

Agent Mesh — meshfleet.app

OpenCode 向けの監査可能なマルチエージェント連携です。 独立した OS プロセスとしてエージェントを並行して起動できます。専門エージェントに作業を割り当て、エージェント同士がピアツーピアで連携できます。証跡付きの記録と定足数による承認により、「誰がこれを確認し、誰が承認したのか」を証明できます。コアは MIT ライセンスで無料です。

ウェブサイト:meshfleet.app · ソースのバージョン:0.22.0 · npm · CI

メンテナンス状況:最新のソースと Git タグはリポジトリで確認できます。タグはリリースの意図を示すものであり、実際にリリースされた内容を記録するのはレジストリだけです · 問い合わせには48時間以内に回答 · ダウンロード数を誇張して見せることはありません。

プロジェクトの状況 — 意図的に1.0未満で、積極的にメンテナンスしています。 リリースの頻度は意図的に抑えています (カレンダーに従うのではなく、リリースする価値のあるものができたときにバージョンを公開します)。リポジトリでは 毎月メンテナンスを実施し、問い合わせには48時間以内に最初の回答を返します。

誓約としての境界: 仕組みは無料であり続けます。連携、証跡、評議会、プロバイダーに依存しないアドバイザリーインターフェース、および検証を実行する 機能は、永久に MIT ライセンスで提供します。暗号署名と監査人向けの アテステーションは、別の有料レイヤーです (meshfleet-pro)。アカウント固有のプロバイダー操作 とマネージドポリシーも、このコアの対象外です。既存のコアの仕組みが有料化されることはありません。コアはプロバイダーアカウントの 認証情報、残高、リセットポリシー、支出権限、外部公開を所有せず、独立して制御することもありません。

ホストのポータビリティ: これはエージェントの監査証跡であり、まず OpenCode に対応しています。OpenCode 専用の構想ではありません。 コアは標準的な MCP サーバーです。より幅広いホストへの対応は、実際の需要に応じて進めます。


Meshfleet を選ぶ理由

OpenCode は単一エージェントのランタイムです。話しかけると、処理を実行します。複数の専門家を並行して動かす必要が生じた瞬間、たとえば探索してからレビューし、その後に実装するといった場合に、バックグラウンドタスクの30分タイムアウトに直面します。

Meshfleet は不足していたレイヤーを追加します。並行して動作し、互いにメッセージを送り、作業を引き継ぎ、自律的に編成するエージェントのフリートです。バックグラウンドタスクではなく、独立した OS プロセスとして動作します。人為的な上限はありません。

以下はソース/オペレーターが設定する例であり、表示されているすべてのランタイムが現行の npm パッケージに含まれているという主張ではありません。

const { fleet_id } = await callTool("spawn_fleet", {
  agents: [
    { role: "Explorer",   prompt: "Map the auth layer",    agent: "codebase-onboarding-engineer" },
    { role: "Analyst",    prompt: "Review the architecture", agent: "oracle" },
    { role: "Engineer",   prompt: "Implement JWT refresh",  agent: "backend-architect", model: "opencode-go/minimax-m3" },
    { role: "Reviewer",   prompt: "Review the resulting diff", runtime: "claude-cli", workspace_binding: "review-worktree" },
  ],
});

4人の専門家。4つの独立したプロセス。作業を引き継ぎ、質問し、問題を通知します。あなたは結果を確認します。

各 OpenCode エージェントでは、任意で model(provider/model)セレクターを指定できます。指定すると、Meshfleet はこれを不変のリクエスト(Agent.requested_model)として保持し、そのエージェントに対して opencode run --model <value> を起動します。観測されたランタイムバナーは Agent.runtime_model に記録されます。バナーがない、またはリクエストと一致しない場合、complete 状態のエージェントはフェイルクローズします。model を省略した場合、従来どおりの argv が維持されます。このセレクターはデータであり、シェルテキストではありません。また、バナーは観測された証拠であり、認証、課金、プロバイダーの利用可否、アテステーションを示すものではありません。

spawn_fleet では、エージェントごとに任意の runtime も指定できます。デフォルトは引き続き opencode-cli です。デフォルト以外のランタイムは、オペレーターが設定した場合にのみ利用できます。claude-cli には、絶対パスのコマンド、設定済みのバージョンラベル、オペレーターが許可した不透明なワークスペースバインディングが必要です。呼び出し元はそのバインディングを workspace_binding として繰り返し指定し、OpenCode 固有の agent と model のセレクターは省略する必要があります。minimax-cli と grok-cli は、それぞれ明示的な指定でのみ利用できる、別個のテキストレーンです。それぞれに専用の絶対パス MESHFLEET_<VENDOR>_COMMAND と設定済みの MESHFLEET_<VENDOR>_VERSION が必要です。モデル/エージェントのセレクター、ワークスペース権限、成果物の期待値は受け付けません。構造化された最終テキストエンベロープで結果を宣言し、生の診断情報は提供せず、自動フェイルオーバー先になることもありません。Grok アダプターはさらに、設定済みラッパーにソースを参照しないテキスト専用の境界を強制します。各ラッパーは独自の認証を管理します。Meshfleet はサニタイズ済みの環境を渡し、認証情報の読み取りやシリアル化は行いません。また、アカウント、認証情報、実効モデル、クォータ、利用可否について、いかなる主張も行いません。このアウトバウンドワーカーアダプターは、ランタイムを起動しないオフラインの静的な Grok 設定変換とは別のものです。権限と証拠の正確な制限については、アダプターの仕様を参照してください。いずれかのアカウントに対するローカルのスモークテストは、環境内でのみ行われます。別個の純粋な recommend_route アドバイザリーでは、呼び出し元が証拠を提示した場合に限り、リセット間近であることをタイブレーカーとして利用できます。ただし、アカウントのポーリング、プロバイダー権限の付与、有料サービスの実行は行いません。

エージェントのアクションが重要な場合、Meshfleet は何が起きたかを証明できます。メッセージごとに受信者単位のレシート(配信済み、確認済み、応答済み)が記録されます。意思決定は評議会を通じて行うこともできます。定足数に基づく批准と必須の承認が、同じ台帳に記録されます。この設計は、本番環境で40日間、18,404件のメッセージにわたり10体以上のエージェントフリートを稼働させたバスを移植したものです。これには、定足数によって批准された意思決定も含まれます。


30秒でインストール

npm から(パッケージ名は meshfleet です。agent-mesh という npm 名はプレースホルダーによって占有されています):

npm install -g meshfleet

またはソースから:

git clone https://github.com/johnmwhitman/agent-mesh.git \
  ~/.config/opencode/mcp-servers/agent-mesh
cd ~/.config/opencode/mcp-servers/agent-mesh
npm install && npm run build

~/.config/opencode/opencode.jsonc に追加します(npm インストールの場合):

{
  "mcp": {
    "meshfleet": {
      "type": "local",
      "enabled": true,
      "command": ["npx", "-y", "meshfleet"]
    }
  }
}

正規の設定ではない、開発専用のソースチェックアウトの使用方法について(推奨リリース設定ではありません):

{
  "mcp": {
    "meshfleet": {
      "type": "local",
      "enabled": true,
      "command": ["node", "~/.config/opencode/mcp-servers/agent-mesh/dist/index.js"]
    }
  }
}

OpenCode を再起動し、フリートを起動します。クライアントへの接続方法 →

公開パッケージから始める

公開されている meshfleet パッケージのキー不要のウォークスルーは、スクリプトによる台帳のデモです。パッケージとインスペクターが実行されることを示すものであり、モデルを利用するワーカーが実際のタスクを完了したことを示すものではありません。

npx -y --package=meshfleet -- agent-mesh demo

この公開ウォークスルーは、一時的な使い捨ての台帳に対してのみ実行され(~/.config/opencode 配下には何も触れません)、デモの監査記録と次の手順としてインスペクターを実行するコマンドを表示します。後で独自に設定した MCP 台帳を調べるには、パッケージを明示的に指定してください。--package=meshfleet を付けずに npx 経由で agent-mesh バイナリを実行すると、このパッケージではなく、npm にある無関係な予約済みパッケージ [email protected] が解決されます。

npx -y --package=meshfleet -- agent-mesh inspect --verify

これを実行したとき(または MCP サーバー自体が)、CRASH ... unsupported newer storage schema version で終了する場合、実行中のものより新しい meshfleet ビルドによって書き込まれた既存の台帳が、デフォルトのパス(~/.config/opencode/agent-mesh.db)に見つかったことを意味します。これは、新規インストールではなく、すでに OpenCode/meshfleet を実行したことのある開発マシンでよくあります。MESHFLEET_DB_FILE=/path/to/other.db を指定して別の台帳ファイルを使ってください(MCP クライアントの設定でも指定できる同じ環境変数です)。既存のファイルには触れません。

ソース限定の決定論的ランタイム

このページで説明している新しいソースチェックアウトには、決定論的なワーカーを現在の Node 実行ファイルで動かす local-demo ランタイムが含まれています。これは公開パッケージには含まれていません。このソースチェックアウトをビルドした後、MCP ホストから次のように起動してください。

spawn_fleet with agents [{ role: "scout", prompt: "Count the receipts.", runtime: "local-demo" }]

起動、ライフサイクルイベント、レシート、および collect_results はすべて実際のものです。合成されたものはワーカーだけであり、出力("model": null、創作されたテキストなし)にもそのことが示されています。local-demo が自動フェイルオーバーに使われることはありません。失敗した実際のエージェントが、エコーに黙って置き換えられることはありません。

実際の読み取り専用タスクを試す

前提条件:OpenCode がすでにインストールされており、使用許可のあるアカウント用に設定されていること。Meshfleet は、ワーカーの起動を依頼するまで、認証情報の作成、課金範囲の選択、プロバイダーへの呼び出しを行いません。MCP ホストから次の手順を実行してください。

  1. spawn_fleet を呼び出し、次を指定します。 agents: [{ role: "explorer", prompt: "Read this repository's README and list its three main sections. Do not edit files." }]。 runtime は省略して、公開時のデフォルトである opencode-cli アダプターを使います。
  2. 返された fleet_id を collect_results に渡し、npx -y --package=meshfleet -- agent-mesh inspect --verify を実行してローカルの証跡を調べます。
  3. complete とローカル整合性レポートは、記録された主張として扱い、回答やコードが正しいことの証明とはみなさないでください。ワーカーの結果はご自身で確認してください。

その後、初回利用についての任意のフィードバックを共有し、その経路が役に立った、役に立たなかった、または進められなかったのいずれだったかと、最初につまずいた手順を教えてください。ソースコード、プロンプト、認証情報、シークレット、または未加工の台帳ファイルはアップロードしないでください。役に立った場合は、別の日に別の有意義なタスクで同じ証跡チェックを試してください。スクリプトによるデモを再実行するだけでは、再利用とはいえません。


クライアントへの組み込み

Meshfleet は標準的な stdio MCP サーバーです。実行方法は常に同じで、npx -y meshfleet を使います(package.json の meshfleet バイナリはサーバーの dist/index.js を指しています)。クライアントごとに変わるのは、その周囲の設定ファイルだけです。

正確性に関するラベル。「テスト済み」とは、このリポジトリ自体で検証可能という意味です。以下のクライアント固有の設定形式は、各クライアントのドキュメントに記載されている形式に従っています。すべてのエディターに対して CI を設定しているわけではないため、「<client> のドキュメントに準拠 — 検証歓迎」と記したものがあります。

任意の MCP クライアント(汎用 stdio) — テスト済み:この正確な形式は、このリポジトリに mcp.json として含まれています
{
  "mcpServers": {
    "meshfleet": {
      "command": "npx",
      "args": ["-y", "meshfleet"]
    }
  }
}
OpenCode — 主なホスト、正規の meshfleet サーバー ID

~/.config/opencode/opencode.jsonc:

{
  "mcp": {
    "meshfleet": {
      "type": "local",
      "enabled": true,
      "command": ["npx", "-y", "meshfleet"]
    }
  }
}
Claude Code — Claude Code のドキュメントに準拠 — 検証歓迎

CLI 形式:

claude mcp add meshfleet -- npx -y meshfleet

または、リポジトリのルートにあるプロジェクトスコープの .mcp.json:

{
  "mcpServers": {
    "meshfleet": {
      "command": "npx",
      "args": ["-y", "meshfleet"]
    }
  }
}
Codex — ホストに依存しない同一の stdio サーバー

Codex の MCP サーバーエントリを、同じコマンドと引数で設定します。

{
  "mcpServers": {
    "meshfleet": {
      "command": "npx",
      "args": ["-y", "meshfleet"]
    }
  }
}

これらの Claude Code、Codex、OpenCode、および汎用 MCP の設定は、すべて同じ受信 stdio サーバーを呼び出します。これは、MCP の境界におけるクライアント間の相互運用性のみを示すものです。ワーカーのデフォルトは OpenCode の opencode run です。オペレーターは、claude-cli のようなデフォルト以外のランタイムを別途登録できます。subscribe_inbox SSE エンドポイントは、任意で利用できる高速化手段です。互換性に必須ではなく、クライアントは get_inbox によるポーリングを利用できます。

上記のいずれかのブロックがクライアントで機能しない場合は、イシューを登録してください。設定の陳腐化はバグです。

ローカル A2A 互換インターフェース

ローカルの親プロセスは、ダッシュボードと統合のドッグフーディング用に、ループバック接続のみを受け付ける A2A 互換アダプターも公開します。

GET  /.well-known/agent-card.json
POST /a2a/tasks
GET  /a2a/tasks/:task_id

Agent Card が通知するのは、ローカルでのタスク送信とステータスのみです。タスク ID はローカルの SQLite 台帳(local_a2a_tasks テーブル)に永続的に保存されるため、同じ台帳を使うプロセスの終了後や再起動後も保持されます。このアダプターは MESHFLEET_SSE_TOKEN(既存の SSE 認証エイリアスを含む)で保護され、ループバックにバインドされたままです。また、パブリック A2A イングレス、リモートリレー、署名付き ID、プッシュ通知を提供するものではありません。ローカルアダプターでは、ローカルタスクの状態が永続的に保存されるようになりました。MCP stdio が引き続き主要な制御インターフェースです。


CLI

Meshfleet をインストールすると、agent-mesh CLI(meshfleet npm パッケージから利用できます。npm 上で単独の agent-mesh を指定すると、別の予約済みプレースホルダーが解決されます)で実行中のフリートをターミナルから確認でき、agent-mesh-dashboard でライブ TUI を利用できます。名前が占有されているパッケージを誤って選択しないよう、以下のすべてのコマンドで --package=meshfleet を明示的に指定しています。

$ npx -y --package=meshfleet -- agent-mesh inspect
3 fleets:

bc34d339-935c-4…  complete  3 agents, 3 done (34.8m)
37ae1cf2-5ce8-4…  complete  1 agents, 1 done (28.2m)
d648beb0-cfb2-4…  failed    2 agents, 2 done (27.3s)

$ npx -y --package=meshfleet -- agent-mesh inspect --metrics
Total fleets:       7
  completed:        3
  failed:           4
Total agents:       16
Success rate:       42.9%
Avg duration:       1.34s

$ npx -y --package=meshfleet -- agent-mesh inspect --events 5
TIMESTAMP            EVENT              DETAIL
──────────────────────────────────────────────────────────────────────
2026-07-02 12:40:12  agent_spawned       fleet=f-1 agent=a-1
2026-07-02 12:40:12  agent_spawned       fleet=f-1 agent=a-2
2026-07-02 12:40:12  fleet_created       fleet=f-1

$ npx -y --package=meshfleet -- agent-mesh inspect timeline f-1 --from 2026-07-02T12:40:00Z --to 2026-07-02T12:45:00Z
Local ledger timestamps in [1782996000000,1782996300000) · not authenticity, completeness, tamper evidence, authenticated provenance, or external time
TIMESTAMP            KIND                SUMMARY
──────────────────────────────────────────────────────────────────────
2026-07-02 12:40:13  message             handoff agent-a→agent-b
2026-07-02 12:40:18  receipt             ack by agent-b on 3f9c1a2b

$ npx -y --package=meshfleet -- agent-mesh inspect --follow            # or -f; add --fleet <id> to scope to one fleet
ledger: ~/.config/opencode/agent-mesh.db  · poll 400ms  · ctrl-c to stop
watching… no messages yet  (spawn a fleet or send_message from MCP)
2026-07-22 09:14:03  handoff  agent-a → agent-b  msg=3f9c1a2b  {"task":"review PR #42"}

タイムラインの境界は省略可能で、数字のみのエポックミリ秒、ISO 日付(YYYY-MM-DD)、またはタイムゾーン付き ISO 日時(YYYY-MM-DDTHH:mm:ss[.fraction](Z|±HH:mm))を指定できます。小数部の精度はエポックミリ秒に正規化されます。境界を指定すると、ローカル台帳に保存されたタイムスタンプに対して、半開区間 [from,to) が選択されます。--json を追加すると、追加の timeline_window 検査エンベロープを取得できます。境界を指定しない inspect timeline [fleet] は、従来のテキスト形式と JSON 形式を維持します。これはローカル記録の読み取り専用選択であり、真正性、完全性、改ざんの証拠、認証済みの来歴、または外部時刻を証明するものではありません。


MCP ツール

デフォルトの stdio tools/list は、引き続き互換性のある40 ツールのカタログを提供します。MESHFLEET_COMPACT_CATALOG=1 を設定すると、助言的なルーティングツール 3 つ(compile_route_candidates、recommend_route、plan_speculative_backlog)と非推奨の verify_ledger_v2 を省いた、36 ツールのコンパクトカタログが通知されます。コンパクトモードで MESHFLEET_ROUTE_ADVISOR=1 を設定すると、助言的なツール 3 つが復元され、39 ツールのカタログになります。新しい統合では、verify_ledger と verify_ledger_v3 を優先してください。

フリート

ツール機能
spawn_fleet独立した OS プロセスとして、N 個のエージェントを並列に起動します。各エージェントは、登録済みの runtime と必須の不透明な workspace_binding を選択するか、デフォルトの OpenCode ランタイムと任意の model(provider/model)セレクターを使用できます
spawn_from_template保存済みテンプレートからフリートを起動します
save_fleet_template / list_fleet_templates再利用可能なバージョン管理されたフリート設定
list_fleets / fleet_statusすべてのフリート、または 1 つのフリートの完全な状態
collect_resultsすべてのエージェントの最終出力を 1 回の呼び出しで収集します
set_fleet_timeoutフリートごとのタイムアウト上書き(ミリ秒単位)
attach_agent事前に作成されたエージェントを実行中のフリートに動的に追加します。エージェントは同じ任意の model(provider/model)セレクターを設定できます

メッセージングと受信確認

ツール機能
send_messageP2P メッセージ(5 種類)。または to_agent_id: "*" を指定して、フリート全体にブロードキャストします
send_messagesバッチ送信。バッチごとに 1 つのアトミックなトランザクションとして処理します(最大 1000 件。これを超えるバッチは拒否されます)
get_inbox / ack_messageポーリングして確認応答します。確認応答のたびに、受信者ごとの配信確認レシートを書き込みます
subscribe_inboxポーリングの代わりに SSE でプッシュ配信します(認証トークンは任意)
subscribe_eventsフリート全体の統合 SSE イベントストリームです。fleet_id で絞り込めます。追記時にすべての台帳イベント種別を出力します(認証トークンは任意)
receipt / get_receipts配信確認台帳に記録し、照会します。誰が、何を、いつ見たかを確認できます
verify_ledger台帳全体の内部整合性を監査します。エラーは、台帳自身の記録で裏付けられない内容を台帳が主張していることを意味します
verify_ledger_v2専用の読み取り専用ファイルスナップショットから取得した、変更されていない検証レポートを囲む、バージョン付きの署名なしスナップショット整合性エンベロープです。ハンドラーは台帳への書き込みを行いません
verify_ledger_v3オプトインの、分離された検証エンベロープです。重大度から導出したローカル整合性ラベルのみを含み、来歴や信頼度は示しません。ハンドラーは専用の読み取り専用ファイルスナップショットを使用し、台帳への書き込みを行いません
get_build_identity実行中のインストールに関する完全な BuildIdentityReport です。パッケージ名/バージョン、source_commit、entrypoint_count、エントリーポイントごとの SHA-256 マップ、entrypoints_match_runtime ビットを含みます。公開済みマニフェストと照合して特定のパスのハッシュを検証するための専用診断名です。get_health() と同じ情報を返し、verbosity 引数はありません。

協議会(定足数による批准)

ツール機能
open_ratificationフリートに決定を提示します。定足数、期限、必須の承認に加え、投票者ごとの任意の重みを指定できます
cast_voteエージェントが記録に残る形で投票します。再投票すると履歴を書き換えずに有効票が変更されます
tally_ratification / sweep_ratifications結果を確定し、期限を過ぎた投票を失効させます

ルーティングと運用

ツール機能
register_capabilityルーティング用に、役割とスキルを自己申告します
route_workキーワードと役割の重複度に基づき、タスクに最適なエージェントを照合します
recommend_route呼び出し側が指定したエージェント/ランタイム/モデル候補を推奨順に並べます。厳格なプライバシー/機能フィルターを適用し、オプトインでリセット間近の候補を同点判定に利用できます
plan_speculative_backlog呼び出し側が承認した投機的作業を純粋に予測します。ルートのゲート条件を維持し、キャパシティは明示的にモデル化しません
compile_route_candidatesサニタイズ済みのマニフェスト/観測スナップショットを純粋にオフラインで予測します。順位付け、永続化、実行、認可、起動、プロバイダーへの連絡は行いません
record_routing_outcome結果をフィードバックし、ルーティングを改善します
list_agents100 種類以上の事前作成済みエージェントのペルソナを検出します
get_health / pingフリートの健全性と稼働状況を確認します。get_health は任意の verbosity 引数を受け付けます。"full"(デフォルト。エントリーポイントごとの SHA-256 マップを含む完全な BuildIdentityReport)または "summary"(定期プローブのペイロードを小さくするため、エントリーポイントのマップを省略)を指定できます。公開済みマニフェストと照合して特定のパスのハッシュを検証する場合は、診断名として専用の get_build_identity ツールを使用してください。

ディスカッション(2 エージェント間の制限付き交渉)

ツール機能
ask_peer制限付きのディスカッションを開始します。最初の質問を送信し、任意でピアへの試行を 1 回確保して、回答が確定するまで待ちます
wake_agentディスカッションを実行する唯一の汎用トリガーです。制限付きの試行を 1 回アトミックに確保して開始します
reply_discussionアクティブな起動試行で許可された 1 件の返信を送信します。エージェントは起動しません
get_discussion読み取り専用です。永続化されたメッセージとレシートから、トランスクリプト、試行、予算、フェイルクローズ状態を導出します

クイックスタート、ツールのリファレンス、終端状態の優先順位について詳しくは、docs/discussions.md を参照してください。 デフォルトの tools/list は互換性のため、引き続き40です。36ツールのコンパクトプロファイルを使用するには、MESHFLEET_COMPACT_CATALOG=1 を設定してください。コンパクトモードで3つのアドバイザリールーティングツールを再び有効にするには、MESHFLEET_ROUTE_ADVISOR=1 を設定してください。verify_ledger_v2 は正確な名前を指定すれば引き続き呼び出せますが、コンパクトな検出結果からは除外されます。

RoutePlane カタログの検出機能は、MCP ツールではなく、独立したパッケージライブラリおよび CLI です。RoutePlane の固定ループバックモデルカタログを取得し、呼び出し元が所有するポリシーをアドバイザリー候補に反映します。パッケージライブラリ API の recommendRoutePlaneCatalog() は、すでに取得済みのスナップショットを構成します。オプトインの fetchAndRecommendRoutePlaneCatalog() は、同じ構成を行う前に、この固定ループバックカタログを1回取得します。evaluated と no_compiled_candidates のステータスは、タスクの除外とは別にカタログの診断情報を保持し、すべての効果を false にしたまま、あくまで助言にとどまります。どちらの API も、デプロイ、公開、プロバイダーの選択、モデルの実行、明示的なループバックカタログ取得を超えたプロバイダーへの接続、予算テレメトリのポーリングを行わず、プロバイダーのラベルから権限を推測することもありません。 RoutePlane カタログの境界 → docs/ROUTEPLANE-CATALOG.md

Fleetbudget の取り込みと観測値の投影は、MCP ツールではなく、独立したパッケージインターフェースです。新しい meshfleet/fleetbudget-sanitizer ライブラリと、標準入力を使う meshfleet-fleetbudget-sanitize CLI は、呼び出し元が所有する収集間隔に照らして、現在のバージョンなしの fleetbudget --json バイト形式を厳密に検証します。lane は不透明な証拠識別子としてのみ保持し、measured、used、total、unit も保持します。routes、state、utilization、note、detail は検証後に破棄します。CLI は標準入力を読み取り、Fleetbudget、他のプロバイダープロセス、またはルートコマンドを実行することはありません。

サニタイズ済みの生レーンには、意図的に型付きのクォータウィンドウが含まれません。そのため、生の上限が完全な状態でも使い果たされた状態でも、診断専用となります。WINDOW_MISSING が生成され、観測値も、可用性、枯渇、割り当て、ランキング、ルーティングに関する権限も付与されません。compileFleetBudgetObservations() は引き続き、実際の型付きクォータウィンドウが存在する場合に、候補との明示的なバインディングを含む、呼び出し元が提供したバージョン付きスナップショットを受け付けます。複数の候補が、分割されていない証拠をコピーしたものとして同じレーン ID を共有できます。コンパイラーは、観測値または診断情報、正規化された来歴ハッシュ、およびすべて false の効果を返します。どちらのインターフェースも、合計、割り当て、予約、同期、実行、承認を行いません。検証済みのウィンドウ境界は、レーン ID やウィンドウ ID を伴わずに、ルート候補コンパイラーに渡されます。明示的な prefer_near_reset 推奨では、既存の最終スコアを決定した後のタイブレークに限り、これらの境界を使用できます。デフォルトのアカウント最適化ポリシーはありません。 生の測定予算を実用化するには、構造化されたコレクターのバージョン管理、プロデューサーが所有する観測タイミング、型付きクォータウィンドウが必要です。安全なホスト収集と厳密な境界 → docs/FLEETBUDGET-OBSERVATIONS.md plan_speculative_backlog は、呼び出し元が指定した閉じた入力に対する、独立した純粋なキュー投影です。呼び出し元が不透明な state: "approved" の証拠を含めた場合にのみ、タスクが提案されます。これは MeshFleet の認可ではありません。既存の recommend_route のハードゲートを組み合わせ、タスクごとにすでに導入済みのニアリセット・タイブレークを選択できますが、リセットの緊急度をグローバルなキュー優先度として扱うことはありません。候補の品質タグが示すのは適格性の宣言のみであり、品質の測定ではありません。アセットおよび動画の候補には、テキストのみの権利資料、または呼び出し元が証明する権利資料、非公開レビュー、および人間によるリリース要件が必要です。結果には、リプレイの証拠として、指定された入力の正規化ハッシュのみが含まれ、すべての副作用は false で、共有候補のキャパシティは明示的にモデル化されていないと報告されます。実行、スケジュール設定、ポーリング、認証情報の読み取り、プロバイダーの推論、プールのバインド、キャパシティの予約、予算の消費、送信、公開を行わず、鮮度、来歴、承認、プロバイダーの状態、レシート、実行コミットメントも確立しません。proposed と blocked の配列は、優先度の降順、タスク ID の昇順で並び、各エントリーにはその全体順序におけるゼロ始まりの queue_index が含まれます。 アドバイザリールーティング → docs/ADVISORY-ROUTING.md

サニタイズ済みのフリートラッパー使用状況は、独立した純粋な meshfleet/wrapper-usage-observations パッケージのインターフェイスから利用できます。受け付けるのは、閉じた、すでにデコード済みの fleet.wrapper-usage-summary/v1 オブジェクトのみで、副作用と権限がすべて false の、別個の accepted/groups ステータスエンベロープを返します。routeplane-unattributed をそのまま保持し、プロンプト、未加工のイベント ID、プロバイダーやクォータの推論、導出されたレート、永続化、実行、スケジュール設定、ルーティング、ロギングの有効化、MeshFleet のヘルス変更を行うことなく、ソース側の却下と集計カウントをコピーします。これは MCP ツールではなく、ルート候補の観測データとは構造的に互換性がありません。 ラッパー使用状況のステータス境界 → docs/WRAPPER-USAGE-OBSERVATIONS.md

アドバイザリールーティング → docs/ADVISORY-ROUTING.md · フリート予算の観測データ → docs/FLEETBUDGET-OBSERVATIONS.md · アーキテクチャの概要 → AGENT-MESH-SPEC.md · P2P/レシート → SPEC-P2P.md · 評議会 → SPEC-COUNCILS.md


5 種類のメッセージ

種類用途
handoffパイプライン内の次のエージェントにコンテキストを渡す
question確認の質問をする(任意の correlation_id を指定可能)
result最終結果を報告する
alertフリート内のすべてのピアに問題を通知する
request_help行き詰まった際にエスカレーションする(関連スキルを持つ特定のピアを指定)

ペイロードの上限は 64 KB です。デフォルトのエンコーディングは JSON ですが、ペイロードは文字列なので、任意の内容を送信できます。ブロードキャスト(to_agent_id: "*")はフリート内のすべてのピアに配信され、各受信者が個別に ACK を返します。レシート台帳には、誰がメッセージを確認したかが正確に記録されます。


4 つの連携パターン

  • パイプラインのハンドオフ:A → B → C。各専門エージェントが次のエージェントにコンテキストを渡します。オーケストレーターは介在しません。
  • 合意形成のための議論:A と B が同じ成果物をレビューし、質問を通じて議論し、報告前に合意に至ります。
  • 障害からの復旧:C がブロッカーに直面したら alert をブロードキャストし、関連スキルを持つピアが修正を提示します。
  • 批准済みの決定:評議会がリスクの高いアクションについて投票します。定足数、期限、必要な承認といった条件があり、沈黙を保った参加者を含む結果が台帳に記録されます。

レシートの仕組みについて詳しく見る →


検証器が検出できること、できないこと

「証明する」は検出に関する主張であるため、その証拠も公開しています。 test/fixtures/corpus/ は、意図的に改ざんされた85個の台帳からなるコーパスです。それぞれがクリーンなベースラインに宣言された変更を1つ加えたものです。結果は3つの独立した分類で報告され、単一のカバレッジ数にまとめられることはありません。

分類N意味
caught60過剰な主張です。台帳が、記録によって裏付けられていない内容を断定しています。エラーを発生させ、台帳を不合格にします。
anomaly15不自然ではありますが、記録が裏付ける範囲を超えて主張してはいません。警告のみで、意図的に検出数には含めません。
undetectable10署名のないローカルコアでは、構造上検出できません。検出結果はゼロです。

この3つ目の分類は、意図的に公開しています。 コアが検証するのは内部整合性であり、来歴、コンテンツのひも付け、完全性、絶対時刻は検証できません。そのため、評議会の承認後に差し替えられたペイロード、正当に議席を持つエージェント用に発行された投票、整合性のある履歴を持つゴーストエージェント、時計の全面的なずらしは、すべて問題なく検証されます。それぞれが、まさにその結果を示すフィクスチャとして登録されています。これは、私たちが主張するだけでなく、実際に実行できる形で示された無料コアの境界です。また、Meshfleet Proがまさにその境界の向こう側に存在する理由でもあります。これらのベクトルを検出可能にするのは署名であり、このコアには署名が含まれていません。

caughtとanomalyを合わせたベクトルは、discussion.*ファミリー以外で検証器が出力できるすべてのチェックを網羅しています。この一覧は実行のたびにソースから再生成されるため、フィクスチャのない新しいチェックがあるとビルドは失敗します。

実装済みのバージョン管理された証拠範囲

verify_ledger_v2は、実装済みのMCP検証器インターフェースです。互換性のあるデフォルトカタログには引き続き含まれますが、MESHFLEET_COMPACT_CATALOG=1の場合は非推奨となり、コンパクトなtools/listから非表示になります。このリリースでは、ハンドラーは引き続き呼び出し可能です。verify_ledgerとverify_ledger_v3の使用を推奨します。既存のverify_ledger、VerifyReport、VerifyFinding、agent-mesh inspect --verify、meshfleet.inspect/v1に変更はありません。

ツールのディスパッチ時に、ハンドラーは専用の読み取り専用ファイルスナップショットを通じて設定済みの台帳を読み込み、台帳への書き込みは行いません。通常の親モードでは、サーバーの起動時の復旧または移行によって、ツールのディスパッチ前に設定済みの台帳が初期化または変更されることがあります。こうしたディスパッチ前の動作はv2による変更の影響を受けず、このハンドラーの境界外です。

MCPツールは次のエンベロープを返します。対応するオプトインのagent-mesh inspect --verify-v2 [file] CLIモードも実装済みです。このモードでは、指定されたファイル、または設定済みの台帳を、同じ専用の読み取り専用ファイルスナップショットを通じて監査します。--jsonを指定すると同じオブジェクトを出力し、指定しない場合は証拠範囲のヘッダーを1つ出力した後、変更されていない従来の検証器テキストを出力します。

{
  "schema": "meshfleet.verify/v2",
  "evidence_scope": {
    "profile": "unsigned_snapshot_consistency/v1",
    "ok_means": "no_detected_internal_consistency_contradiction",
    "assurance_ceiling": "internal_consistency_of_the_unsigned_snapshot_read",
    "not_established": [
      "authorship_and_authenticated_provenance",
      "pre_read_snapshot_integrity_and_tamper_evidence",
      "content_binding",
      "completeness_and_deletion",
      "external_delivery_and_execution",
      "external_time"
    ]
  },
  "report": "the unchanged VerifyReport"
}

report.okの意味は現在と完全に同じです。読み取った署名なしスナップショットで、検出された内部整合性の矛盾がないことを示します(report.errors === 0)。作成者や認証済みの来歴、読み取り前のスナップショットの完全性や改ざん証拠、コンテンツのひも付け、完全性や削除がないこと、外部への配信や実行、外部時刻を証明するものではありません。この範囲は、呼び出し元や台帳の入力ではなく、生成された検証器の出力です。これはレポートが証明する内容の上限であり、信頼度スコア、完全性の判定、昇格を示すものではありません。

opt-in の verifier v3 ローカル整合性バンドを実装

verify_ledger_v3 と agent-mesh inspect --verify-v3 [file] は、個別に opt-in する verifier のインターフェースです。6 項目の unsigned_snapshot_consistency/v1 evidence_scope はそのまま維持しますが、変更のない VerifyReport の分離コピーを含む、新たに厳密な 4 キーのエンベロープを返します。

{
  "schema": "meshfleet.verify/v3",
  "evidence_scope": {
    "profile": "unsigned_snapshot_consistency/v1",
    "ok_means": "no_detected_internal_consistency_contradiction",
    "assurance_ceiling": "internal_consistency_of_the_unsigned_snapshot_read",
    "not_established": [
      "authorship_and_authenticated_provenance",
      "pre_read_snapshot_integrity_and_tamper_evidence",
      "content_binding",
      "completeness_and_deletion",
      "external_delivery_and_execution",
      "external_time"
    ]
  },
  "report": {
    "ok": true,
    "scope": {
      "covers": "internal consistency — every receipt, flag, inbox entry, and ratification tally is supported by the ledger's own records",
      "excludes": "authenticity — there is no hash chain or signature here, so an edit that rewrites the ledger consistently is indistinguishable from honest history"
    },
    "errors": 0,
    "warnings": 0,
    "counts": { "fleets": 0, "agents": 0, "messages": 0, "receipts": 0, "ratifications": 0 },
    "findings": []
  },
  "finding_local_bands": []
}

レポート内の各検出項目に対して、レポートの既存の順序どおりにローカルバンドが 1 つずつ対応します。error は local_consistency_error に、warning は local_consistency_warning になります。このマッピングでは、検出項目の並べ替えや重複排除、チェック名の確認、スコア付けは行いません。severity が不明または欠落している場合は、フェイルクローズします。検出項目が 0 件の場合、バンドも 0 件になり、undetectable の検出項目は生成されません。

レポートのコピーとバンド配列は、呼び出し元による別名参照の安全性を確保するためだけに凍結されます。改ざんの証拠にはなりません。ラベルは severity から導出されるローカル整合性ラベルに限られ、来歴や信頼度を示すものではありません。ラベルがないからといって、真正性も完全性も保証されません。v2 と同様に、ハンドラーは専用の読み取り専用ファイルスナップショットを通じて読み取り、台帳への書き込みは行いません。verify_ledger、verify_ledger_v2、VerifyReport、既存の inspect JSON、そのテキストと終了コード、台帳の動作、サイドカーは変更されません。


これがエージェントについて証明すること — そして証明しないこと

上のセクションは、台帳が嘘をつくことについてです。このセクションは、エージェントが嘘をつくことについてです。これは、どのような調整記録でも否定できません。Meshfleet は、誰が起動され、誰が誰にメッセージを送り、誰が投票し、各エージェントが自身の結果について何を宣言したかを、構造化され、クエリ可能な履歴として、ローカルの署名なし SQLite 台帳に記録します。これは暗号学的なロギングシステムではなく、第三者による証明を提供せず、LLM の主張を真実にすることもできません。

台帳で確認できること台帳では確認できないこと
記録された履歴の範囲内で、内部調整ルール(クォーラムのしきい値、投票セット、レシートキー)が満たされているかどうか。エージェントが報告した調査結果、終了コード、テストの成功が真実かどうか。
記録された調整イベントの順序とタイムライン。ローカルへの書き込みアクセス権を持つプロセスによって、行が帯域外で書き換えられたかどうか(上記の undetectable バケットを参照)。
どのエージェントが参加、投票、ack したか、および各エージェントが宣言した結果。第三者に対する実行や誠実さの証明 — このコアには署名がありません。

運用原則:証跡ではなく手掛かりです。 フリートの出力は手掛かりであり、証跡ではありません。自分で再実行するまでは、何もレポートに記載しないでください。自律実行とユーザーの意思決定の間にオーケストレーターが位置するため、自らの責任がどこまでかを明示する必要があります。Meshfleet はプロトコルルールを適用し、候補となる成果物を提示します。作業の検証は、ユーザーのツールとレビューに委ねられます。

既知の制限と、それぞれの現状
  • 完了ステータスは申告されるものであり、証明されるものではありません。 エージェントが失敗の説明に complete を付けて記録した事例が確認されています。結果コントラクト(実装済み)では、各スポーンで結果エンベロープに done / refused / blocked のいずれかを申告する必要があり、エージェント行の result_contract として記録され、collect_results によって返されます。complete を記録できる値は ok だけです。refused、blocked、artifact_missing、invalid、または値がない場合は failed が記録されます。有効なエンベロープもあくまで申告であり、捏造、作業量、品質のチェックではありません。
  • エージェントのメトリクスの捏造。 エージェントは合成したテスト件数や、架空の「VERIFIED」という主張を報告でき、台帳にはそう述べたことが記録されます。未解決で、検出できるのも部分的に限られます。結果エンベロープの強制では解決しません。
  • クラッシュ時のエージェント消失。 collect_results は消失を明示的に報告します(lost_agents という名前で、何かが失われた場合にのみ表示される warning)。サーバーがクラッシュすると永続的なジャーナル行が残り、次回の正常な起動時に処理されます。中断された行には、整合処理で正直に原因を特定できる場合、stopped_reason(server_crash | process_lost)が記録されます。有効な結果コントラクトと出力、または申告済みのアーティファクトがある失敗行は、代わりに degraded_agents に一覧表示されます。結果は報告されていますが、ランタイムの状態は正常ではありません。これは配信の証拠であり、実行や真実の証明ではありません。すべて実装済みです。
  • 内部ルールの適用。 運用中、監査役は実行のたびにソースからルールを再導出します。自身の記録で裏付けられない内容を主張する台帳は、検証に失敗します。たとえば、投票なしの批准や、メッセージなしの受領記録などです(上記の caught バケット)。

比較

ツール最適な用途トレードオフ
OpenCode task()単一タスクの作業30 分のタイムアウト、P2P なし
LangGraphPython のグラフアプリPython 専用、ホスト型優先
CrewAI役割ベースの Python エージェントPython 専用、ホスト型
AutoGen研究プロジェクト重量級、Python 専用
手書きの cron特定の単発ワークフロー共通の抽象化なし
MeshfleetOpenCode + マルチエージェント、ローカル優先、監査可能TypeScript 専用(現時点)

いずれも「誰がこれを見たのか、誰が承認したのか、それを証明してください」には答えられません。そこがこのツールの領域です。

FAQ →


アーキテクチャ

src/
├── db.ts                # The withLedger transaction seam over SQLite (the write boundary)
├── core.ts              # Data layer: ledger, messages, receipts, capabilities, events
├── migrate.ts           # One-shot JSON→SQLite migration (runs once at startup)
├── ratify.ts            # Councils: quorum ratification over the receipts substrate
├── templates.ts         # Versioned fleet templates
├── routing-feedback.ts  # Outcome-informed work routing
├── health.ts            # Fleet health scoring
├── realtime.ts          # SSE push delivery (subscribe_inbox)
├── inspector.ts         # Pure formatters for CLI output
├── index.ts             # MCP server: transport + tool handlers
└── bin/
    ├── inspect.ts       # CLI: npx -y --package=meshfleet -- agent-mesh inspect
    └── dashboard.ts     # Live TUI: npx -y --package=meshfleet -- agent-mesh-dashboard

すべての書き込みは、db.ts の withLedger(mutator) という単一の関数を経由します。この関数は、単一の SQLite BEGIN IMMEDIATE トランザクション内で変更を実行します。エージェントは、それぞれが同じ台帳を使う独自の agent-mesh インスタンスを起動する実際の OS プロセスであるため、書き込みは本当に並行して行われます。SQLite(WAL + busy_timeout)がプロセス間の書き込み排他を提供するため、このコードベースはロックプロトコルを持たず、構造上、更新の取りこぼしは発生しません。(以前の JSON 読み取り・変更・書き込みストアでは、2 プロセスのテストで 120 件中 57 件の受領記録が気付かれないまま失われました。SQLite 版は同じテストに 200 回中 200 回成功しています。)読み取りにはロックフリーの readLedger() を使います。純粋なフォーマッターは inspector.ts にあり、テストしやすく、I/O もありません。

台帳は ~/.config/opencode/agent-mesh.db(SQLite)に、イベントログは ~/.config/opencode/agent-mesh.events.log(NDJSON)に保存されます。MESHFLEET_DB_FILE=/path/to/file.db で台帳のパスを上書きできます。これは、2 つ目のインストールやテスト用台帳、またはデフォルトの場所にある既存ファイルが新しいビルドや互換性のないビルドで書き込まれた場合に便利です。npx -y --package=meshfleet -- agent-mesh inspect --export を使えば、いつでも台帳を人が読める JSON として出力できます。JSON 台帳からのアップグレード後、初回起動時にサーバーが一度だけ移行します(検証済みで、.migrated.<ts> のバックアップを保持します)。

アーキテクチャの概要 → · P2P メッセージング仕様 →


要件

  • Node.js >= 20
  • $PATH に OpenCode CLI があること(OpenCode がサポートする任意のモデルプロバイダー)
  • 以上です

背景

背景:Human Out of the Loop は、このポートフォリオの基になった書籍です。


ライセンス

コア部分は MIT ライセンスです。自由に利用、フォークし、製品に組み込んでください。ライセンスファイルに記載されている以上の著作権表示は不要です。(商用利用向けの保証レイヤーである Meshfleet Pro は別のリポジトリにあり、この内容には影響しません。)


コントリビューション

CONTRIBUTING.md をご覧ください。バグの報告 → issues。セキュリティに関する報告 → SECURITY.md。ロードマップ → ROADMAP.md。

コメント

MCP は初めてですか?

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

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