OpenClaw Gateway が動くところまで来たら、次の一手は多くの場合 Model Context Protocol（MCP） でツールをエージェントのワークフローに載せることです。リポジトリの参照、社内 API の呼び出し、制御されたコマンド実行などが典型です。現場では次の 3 つに摩擦が集中します——ツールの発見とバージョンの漂流、ゲートウェイ側のホワイトリストと最小権限、そして本番でよくある 握手失敗・タイムアウト・子プロセスの固まり です。本稿では、サイト内の インストール、セキュリティ強化、modelRouting、観測 各記事との役割分担を示し、stdio とリモート MCP の対照、再現可能な本番投入の 6 ステップ、および症状対照表をまとめ、MCP を一時的なプラグインではなく監査可能な「ツールのサプライチェーン」として運用する手がかりにします。
MCP は「ツール呼び出し」を一度きりのスクリプトから、セッションをまたいで再利用する能力面へ引き上げます。ツールが 1 つ増えるたびに、データ経路が 1 本、子プロセスのライフサイクルが 1 段増えます。いまだに「手元で動けばよい」で進めると、ゲートウェイ側では ツール列挙の爆発、暗黙のアップグレード、タイムアウトなし、ホワイトリストなし の 4 類にすぐぶつかります。以下の 7 条はレビュー会での自己点検用で、デモ用設定をそのまま本番に写さないための目安です。
「はい」が 3 つ以上あたるなら、MCP は ガバナンスの効いたサプライチェーン として扱うべきです。明示的な登録、バージョンの固定、観測とロールバックが要り、openclaw.json をメモ帳代わりにしてはいけません。
ツール一覧が再起動のたびに変わるか：毎回、ツール数や名前が変わるなら、発見パスがバージョン管理されていないか、作業ディレクトリが固定されていないことを示します。切り分けは「今日は何が列挙されたか当てる」ゲームになります。
明示的なホワイトリストがないか：デフォルトの「全部オン」はデモでは早いですが、本番では任意のプロンプトが任意のシステム能力に写るのと同じです。dmPolicy や実行承認ポリシーとあわせてレビューしてください。
stdio 子プロセスにハードなタイムアウトがあるか：上限なしの待ちは、1 つの固まった MCP が Gateway のスレッドやキューを占有する原因になり、「モデルは返しているのにツールが一生返ってこない」ように見えます。
リモート MCP が外向きポリシーをすり抜けていないか：HTTP／SSE ツールを networkPolicy の議論に入れていないと、ゲートウェイの背後に新しい出口が開き、セキュリティ強化稿の前提と矛盾します。
秘密情報は環境変数でどう注入しているか：トークンをツール単位で分けずグローバル環境に書くと、1 回の漏えいがすべての MCP に波及します。設定セクションを分け、ローテーションしやすくしてください。
modelRouting と衝突していないか：大きなコンテキストは高価なモデル、小さなタスクは軽量モデル、というとき、ツール失敗のリトライが別モデルで繰り返されることがあります。ルーティング層とツール層で共通のレート制限が必要です。
観測は Gateway だけを見ているか：ログに MCP 子プロセスの起動引数や終了コードが出ていないと、本番では「とりあえず再起動」しかできません。観測稿のログ項目と揃えてください。
これらを並べると、核心は次の一文に集約されます。MCP 接続は、設定・プロセス・ネットワーク・権限の 4 本を同時に締めること です。続いて stdio とリモート MCP の差を表で固定し、そのあと 6 ステップのチェックリストに入ります。
サイト内の記事分担は次のように覚えるとよいでしょう。3 OS のインストールと systemd／Docker 稿は「Gateway プロセスをどう常駐させるか」、セキュリティ強化稿は「誰が接続でき、どこへ出ていいか」、modelRouting 稿は「モデルの階層とコスト」、本稿は「ツールの出自、許可のされ方、切り分け」 です。4 つが重なって初めて、監査可能な本番トポロジーになります。
この表はアーキテクチャレビュー用です。同じ業務要件でもどちらでも実装できることが多いですが、脅威モデルと故障モード は異なります。「設定が 2 行少ない方」だけでは選べません。
| 観点 | stdio（同一ホストの子プロセス） | リモート MCP（HTTP／SSE など） |
|---|---|---|
| プロセス境界 | Gateway と同一ユーザー／同一ホスト。環境変数とファイル権限を継承します。 | ホストをまたぎ、TLS・認証・ヘルスチェックが別途必要です。 |
| ネットワーク露出 | 追加のリスンは原則なし。リスクはローカルコマンドとパス注入側に寄ります。 | 新しいエンドポイントと外向き依存が増え、networkPolicy に含める必要があります。 |
| アップグレードと再現 | ローカルバイナリ／パッケージマネージャの版に依存。版固定とハッシュが要ります。 | 集中配布はしやすいですが、ローリングアップグレードと互換マトリクスが要ります。 |
| 典型故障 | PATH・権限・インタプリタ不一致で起動直後に終了。 | DNS、TLS、リバプロのタイムアウト、401／403 の連鎖。 |
| 観測の手がかり | 子プロセス PID、終了コード、stderr の抜粋。 | HTTP ステータス、リトライ曲線、エンドツーエンド遅延の分位。 |
MCP は「プラグインが 1 つ増えた」ではなく、実行可能なサプライチェーンが 1 本増えたことです。stdio かリモートかは、リスクをローカル境界に置くかネットワーク境界に置くかの選択です。
重量級のビルドや macOS 専用ツールチェーン を遠隔実行層に載せる典型形は、Gateway を Linux／VPS で動かし、専用リモート Mac に xcodebuild と署名まわりを載せ、制御された経路でログと成果物を返す構成です。このとき MCP は「軽いオーケストレーション面」に向き、ゲートウェイ内に長時間タスクを積み上げるのは避けた方がよいでしょう。算力とディスクは契約可能なノードに置くのが現実的です。
順に実行し、「ツールが動く」から「変更が監査でき、失敗の位置が分かり、戻し道がある」レベルへ引き上げます。
ツールのアイデンティティを登録する：各 MCP に安定した名前、版の出所（パッケージ名／コミット／digest）、オーナーを書きます。匿名スクリプトをリポジトリに任せて漂流させないでください。
最小権限の起動引数：stdio は絶対パスと専用の作業ディレクトリを使います。リモート MCP は TLS・タイムアウト・リトライ上限を明示し、暗黙のシステムプロキシに頼りません。
設定の検証：変更後はまず openclaw config:validate、続けて openclaw doctor を実行し、エラーをマージのゲートにします。
ホワイトリストの整合：許可ツール一覧を dmPolicy／実行承認ポリシーと突き合わせ、「設定ではオフなのにモデルがパスを推測できる」ようなずれをなくします。
カナリア経路：まず低トラフィックのセッションだけ新ツールを有効にし、旧ツールを 1 週間並行させます。失敗率、P95 遅延、子プロセス再起動回数を比較記録します。
ロールバックパック：直前の openclaw.json とイメージ digest をバックアップします。障害時はまず設定とイメージを戻し、そのあとツール本体を調べます。
{
"mcpServers": {
"internal-git": {
"command": "/opt/mcp/git-mcp",
"args": ["--config", "/etc/mcp/git.prod.json"],
"env": { "MCP_LOG_LEVEL": "info" }
}
}
}
ヒント：この断片は構造のイメージ用です。実際のキー名とネストは、利用中の OpenClaw 版の文書に従ってください。メジャーアップグレードの前には、ステージング相当のクラスタで同じ validate／doctor を流してください。
セキュリティ強化稿はリスン面、トークン、dmPolicy、networkPolicy を扱います。MCP を接するとツール呼び出しが新しい「実行出口」になるため、呼び出してよいツールの集合 と 到達してよい下流 を同じレビュー表に載せます。実務ではツール種別ごとに、最大同時実行数、1 呼び出しあたりのタイムアウト、1 日あたりの呼び出し予算、失敗後のサーキットブレーカーを定義するとよいでしょう。
「モデルはツールを呼んでいるのにフロントがずっとくるくる」のときは、まず次の 3 系統を疑います。子プロセスが起動していない（パス・権限）、握手が終わっていない（プロトコル版・認証）、下流がブロックしている（ネットワークまたは業務 API）。終了コードと stderr を取らないまま Gateway を何度も再起動すると、間欠障害が慢性事故に化けます。
観測稿と組み合わせるときは、MCP の起動と破棄を同じログ相関 ID に載せ、「モデル要求 → ツール呼び出し → 子プロセス終了」を 1 本の鎖で追えるようにします。
注意：本番で「デバッグ級のツール列挙ログ」を長期間オンにし、マスキングもしないのは避けてください。ツール引数にはリポジトリパス、社内ホスト名、トークンの断片が混ざりがちです。
以下は当番と事後レビュー用です。具体的なしきい値は自社の SLO と監視で補ってください。
ノート PC だけに MCP を積み、ゲートウェイのガバナンスと安定した実行面がないと、スリープ、ディスク、複数人でのセッション争いで足を取られがちです。重い負荷を Gateway と同一プロセスに詰め込むと、故障の半径も大きくなります。監査可能なツールチェーン、安定したディスク、7×24 で予測しやすい算力 が要るチームには、OpenClaw Gateway がセッションとポリシーを担当し、専用リモート Mac が macOS／iOS ビルドと長時間ジョブを担当し、MCP は狭いインターフェースだけを出す、という組み合わせが現実的です。ツール統治と算力コストをあわせると、NodeMini の Mac Mini クラウドレンタル は実行層の土台として向きます。ゲートウェイ上の MCP オーケストレーションとクラウド Mac 上のビルド／署名を切り離し、本稿のチェックリストで版・ホワイトリスト・タイムアウトを締めてください。
まず openclaw config:validate を実行し、続けて openclaw doctor を実行することをおすすめします。既知の無効キーを自動修正するときは doctor --fix を慎重に使い、変更内容は記録に残してください。接続や契約の一般的な質問は ヘルプセンター も参照してください。
stdio は同一マシン向けで境界がはっきりします。HTTP／SSE はホストをまたぐのに向きますが、TLS・認証・networkPolicy が追加で要ります。選択肢は OpenClaw カテゴリ のセキュリティ稿とあわせてレビューし、単独で決めないでください。
Gateway は会話とツール方針を担い、重い負荷は専用リモート Mac に載せます。まず OpenClaw カテゴリ と レンタル料金の説明 を読み、ツールのオーケストレーションと算力ノードを分けて計画してください。