90年代SNMPの階層設計をMCPに移植する──『取り消せない操作』は確認待ちにするMCP-AXを読む

MCPサーバーが増えてくると、クライアントは無数のサーバーそれぞれに直接つながなければならなくなる。この問題に、ネットワーク管理の世界で1999年から使われてきた古い設計思想を持ち込んで解決しようとするのが、IETF個人ドラフト「MCP Aggregation Protocol（MCP-AX）」（著者I. Abbott氏、SoftOboros所属、2026年5月4日提出）だ。本文を確認すると、SNMPのAgentXプロトコル（RFC 2741）を直接の着想源とする「マスター・サブエージェント」構造を、MCPのツール／リソースモデルに置き換えて設計していることが分かる。

3行まとめ

• MCP-AXは、クラウドサービスから省リソースの組み込みデバイスまで、異種のMCPサーバーネットワークをまたいで階層的なツール名前空間の合成を可能にする集約プロトコル。RFC 2741（AgentX、SNMPのマスター・サブエージェント設計）から直接着想を得ている
• 「reversible: false かつ mutable: true」（元に戻せず、かつ状態を変える）と分類されたツール呼び出しを、集約サーバーがクライアントに「confirmation_required（確認が必要）」という応答で差し戻し、明示的な確認（mcpax/confirm）が来るまで下流への実行をしない「不可逆性ゲート」という安全機構を持つ
• 確認待ちのリクエストは、既定で300秒のタイムアウトが設定されている

SNMPの30年前の設計を借りる理由

ドラフトはこの着想源をこう説明している。

The protocol defines a master-subagent architecture directly inspired by the AgentX protocol (RFC 2741), adapted for the tool/resource model of MCP rather than the OID/MIB model of SNMP.

（このプロトコルは、AgentXプロトコル（RFC 2741）に直接着想を得たマスター・サブエージェント構造を定義するが、SNMPのOID/MIBモデルではなくMCPのツール／リソースモデルに合わせて適応させている）

AgentXは、SNMPの管理対象オブジェクト（MIBサブツリー）の委任を、マスターエージェントとサブエージェントの階層構造で扱う、1999年に標準化されたプロトコルだ。ドラフトはこの階層委任というアイデアを、MCPの「ツール名前空間」の委任に置き換えている。「MCP-AXアグリゲータ」がAgentXのマスターエージェントに、末端の個別MCPサーバーがサブエージェントに、それぞれ相当する設計だ。

「取り消せない操作」は確認待ちにする——不可逆性ゲート

このドラフトが持つ安全機構の中心が「Irreversibility Gate（不可逆性ゲート）」だ。

Tools with "reversible": false and "mutable": true are classified as irreversible-mutable and MUST be flagged with "x-mcpax-safety": "irreversible_mutable" in the namespace.

（reversible: falseかつmutable: trueのツールは「irreversible-mutable（不可逆かつ状態変更あり）」に分類され、名前空間内でx-mcpax-safety: irreversible_mutableとフラグを立てなければならない（MUST））

このフラグが立ったツールへの呼び出しは、「gated（ゲート）」モードで動作する集約サーバーによって差し止められる。

An aggregator operating in "gated" mode MUST intercept tools/call requests targeting irreversible-mutable tools, return a "confirmation_required" response to the client [...], and await "mcpax/confirm" before dispatching downstream. Unconfirmed requests expire after a configurable timeout (default: 300 seconds).

（「gated」モードで動作する集約サーバーは、不可逆かつ状態変更ありのツールを対象とするtools/callリクエストを差し止め、クライアントに「confirmation_required」応答を返し、下流への発行前にmcpax/confirmを待たなければならない（MUST）。未確認のリクエストは、設定可能なタイムアウト（既定300秒）の後に失効する）

ドラフトはこの設計の根拠を、集約階層が「下流の操作が及ぼす影響範囲（blast radius）を、末端の個別サーバーが持ちえない形で見渡せる、自然な安全ポリシーの執行点になる」からだと説明している。

確認（mcpax/confirm）自体にも歯止めが用意されている。ドラフト本文（Section 11.3）を読むと、確認リクエストには「proof」フィールドとして、要求元のモデルクライアント自身では作り出せない暗号学的な裏付けを含めなければならない（MUST）、とされている。

Without this requirement, an autonomous model client can trivially self-confirm by issuing "mcpax/confirm" immediately after receiving "confirmation_required", rendering the gate ineffective. The proof field ensures that confirmation requires a cryptographic assertion that the model client cannot manufacture from its own context.

（この要件がなければ、自律的なモデルクライアントは「confirmation_required」を受け取った直後に「mcpax/confirm」を発行するだけで自己承認でき、ゲートが無意味になる。proofフィールドは、モデルクライアントが自分の文脈だけでは作り出せない暗号学的な主張を確認の条件とする）

有効なproofとして、人間オペレーターの鍵ペアによる署名、外部ポリシーエンジンが署名したnonce、帯域外の認可サービスが発行する承認トークンの3種類が挙げられている。さらに「Safety Gate Monotonicity（安全ゲートの単調性）」という規則もあり、集約階層のどこか1箇所で確認が必要と判定されたら、それより上流のすべての集約サーバーはこの要件を維持しなければならず（MUST）、ゲートを外す・格下げすることは許されない（MAY NOT）。ゲートを厳しくする方向（ungated→gated）への引き上げのみが認められている。

組み込み機器への橋渡し——5種類のトランスポートと2つのスタブプロファイル

MCP-AXが「省リソースの組み込みデバイスまで」を対象に含める設計であることは冒頭で触れたが、具体的な仕組みはSection 8（Transport Bridging）に書かれている。ゲートウェイが、MCPのネイティブトランスポート（HTTP+SSEやstdio）と、末端デバイス（スタブ）が使う制約付きトランスポートとの間を橋渡しする。ドラフトが定義する橋渡し対象のトランスポートクラスは次の5つ。

ゲートウェイはツール名を登録時に割り当てた整数IDへ置き換え、JSON-RPCのエンベロープフィールド（jsonrpc/method/id）をCBORマップキー0/1/2にマッピングする。ルーティング用のメタデータ（x-mcpax-*、ルート配列、カーソル、ホップ数、レイテンシ注釈）は、制約付きトランスポートに載せる前にゲートウェイ側で必ず除去しなければならない（MUST）とドラフトは規定している——「1バイトごとにコストがかかる環境にルーティング情報を漏らしてはならない」という理由からだ。

末端デバイス（スタブ）側の実装負担についても、2つのプロファイルに分けて明記されている。

能力メタデータと障害時のふるまい

ツールごとに付与する「能力アノテーション」のスキーマ（Section 9.1）は10個のフィールドからなる。

このうちavailability: degradedは、サブサーバーに接続できなくなった際、ツールを名前空間から即座に消すのではなく「一覧には残るが呼び出すとエラーになる」状態に留める仕組みだ（Section 13.2）。ドラフトはこのエラー応答の構造例を示している。

{
  "code": -32002,
  "message": "tool_degraded",
  "data": {
    "reason": "subserver_unreachable",
    "since": "2026-05-01T12:05:00Z",
    "retry_after_ms": 5000
  }
}

猶予期間（推奨5分）を過ぎても復旧しなければ、そのツールは名前空間から完全に削除される。ドラフトはこの設計の狙いを、産業制御や監視パイプラインで名前空間が急に変化すると、それを見ている上流の消費者側で連鎖的な障害が起きかねないためだと説明している。通知の扱いにも上限があり、サブサーバーごとの通知レート制限（既定100/秒）を超えると、既定1000件までバッファした上で古いものから破棄し、「notifications_dropped」カウンタを増やしながら「notification_overflow」という合成通知を上流に送る——これはSNMPの「トラップストーム」問題（RFC 3413）への直接的な対策だとドラフトは位置づけている。

集約サーバー自体が複数系統に分かれてしまう「スプリットブレイン」への対策も定義されている。各サブサーバーは固有のsubserver_idを、各集約サーバーは固有のaggregator_idを持ち、あるサブサーバーIDが別のaggregator_idの下に既に登録されていれば、後からの登録は拒否しなければならない（MUST）。クラウド環境ではDynamoDBやetcdのような共有ストアでの検出が推奨（SHOULD）され、共有状態を持てないエッジ環境では、サブサーバーに現在の親IDを問い合わせて食い違いがあれば拒否する方式が推奨されている。

運用モードの詳細とSoftOborosの実態は確認していない

このドラフトはExperimental（実験的）ステータスで提出されており、Standards Trackではない。IANA Considerations（Section 14）を見ると、このドラフト自身が要求している「mcpax/」メソッド名前空間や「x-mcpax-」メタデータキーの登録先レジストリは、この文書執筆時点ではまだ存在せず、「Agentic AI Foundationまたは将来のIETFワーキンググループによって設立される予定」という書き方に留まっている——つまり、登録を求める先の制度自体が未整備の状態にある。SoftOborosという企業がこの提案をどう実装・運用しているかについては、この記事ではドラフト本文以上の裏取りをしていない。「gated」モード以外の運用モード（例えば確認なしで即時実行するモード）が具体的にどう定義されているかについても、この記事では踏み込んでいない。この記事を書いている自分自身は、SNMP/AgentXの実装経験もMCPサーバーの集約基盤を構築した経験もなく、この設計が実際のマルチエージェント運用でどこまで有効かの評価はできない。日本語ではZenn・Qiitaともに、MCP-AX単体を扱った記事は検索時点で見当たらなかった。

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。