2026年 OpenClaw：MCP で企業 SaaS／イントラネット API に接続——レジストリ設定、出域ホワイトリスト、OAuth／Client Secret ローテーションと独占リモート Mac の SSH ポート転送までの再現手順＋FAQ
エージェントが社内の CRM／チケット／独自 REST を安全に触るには、MCP サーバのレジストリ固定、境界装置での出域ホワイトリスト、OAuth／Client Secret のローテーション手順、そしてデータセンター側に置いた独占リモート Macへの SSH ローカルポート転送を同じ runbook に載せます。大規模アップグレード後の環境変数とプラグイン周りは OpenClaw 大規模アップグレードと OPENCLAW_* 環境変数対照（リモート Mac SSH） 、SSH 側の鍵境界とローテーション方針は 企業向け専有リモート Mac プールの SSH-CA と鍵ローテーション意思決定マトリクス と併せて参照してください。
1. 目的と範囲
本稿は次を扱います。① OpenClaw（またはゲートウェイ／ノード）から Model Context Protocol（MCP）経由で、許可された企業 SaaS とイントラネット上の HTTP API にだけ到達させること。② MCP サーバ一覧をレジストリとしてバージョン管理し、ビルドと実行時の解決結果を一致させること。③ クライアント資格情報（OAuth 2.0 の Client Secret 等）を定期ローテーションし、半開き状態を避けること。④ エージェント実行体を独占リモート Mac に置き、開発者ノートから SSH でトンネルを張って検証するパターン。
対象外：各 SaaS の細かいスコープ設計の網羅、ゼロトラスト製品の選定比較、公開インターネット向けのリバースプロキシ設計——別ドキュメント向けです。
2. 参照アーキテクチャ（論理）
典型的には「制御平面（誰がどの MCP サーバを許可するか）」と「データ平面（実際の HTTP 呼び出し）」を分けます。MCP サーバは社内レジストリの URL または固定パスから起動し、ツール定義に含まれるベース URL はすべて境界プロキシまたは許可リスト済みホストに限定します。OpenClaw 側のプロセス常駐・ログローテーション・再起動ポリシーは、既存の安定運用マニュアルと同様に単一ユーザ境界に固定すると切り分けが楽です。
3. MCP サーバのレジストリと再現性
- 単一の真実源： 社内 Git に
mcp-registry.yaml（仮称）を置き、サーバ ID・起動コマンド・想定バージョン・許可ツール一覧を宣言する。 - イメージ／バイナリのダイジェスト固定： CI でビルドしたコンテナ digest または npm／brew のロックファイルをコミットし、本番ノードはタグではなく digest で pull する。
- スキーマ検証： MCP のツール定義 JSON を PR で lint し、外部 URL がホワイトリスト外なら merge 不可にする。
4. 出域ホワイトリストとプロキシ
エージェントホスト（独占 Mac または専用 VM）からの外向き通信は、次のいずれかに限定します。
- 明示的なドメイン＋ポートの allowlist（ワイルドカード乱用を禁止）。
- 社内 HTTPS プロキシでの TLS インタセプト方針（ポリシーが許す場合のみ）と、プロキシ認証用の短命クレデンシャル。
- DNS の split-horizon でイントラ API の FQDN を内部 VIP に解決し、インターネット経路に出さない。
OpenClaw／MCP プロセスが直接 0.0.0.0 にバインドしないこと、ログにフルシークレットを出さないことを受入条件に含めます。
5. OAuth 2.0 と Client Secret のローテーション
機密クライアント流儀では、Authorization Server が発行する Client Secret を環境変数またはシークレットストアに注入します。ローテーションの推奨順序は次のとおりです。
- IdP 管理画面で新しい Secret を追加（旧 Secret は当面有効のまま）。
- 独占 Mac 上の LaunchAgent／systemd ユニットの環境を新 Secret に更新し、MCP サーバと OpenClaw を順に再起動。
- 監視で 401 が消えたら IdP 側で旧 Secret を失効。ロールバック手順を同じ runbook に書く。
Public client（ネイティブアプリ等）では Secret を置かず PKCE とリダイレクト URI 厳格化に寄せる——エージェント用バックエンドは通常機密クライアントとして扱います。
6. 独占リモート Mac と SSH ローカルポート転送
社内ネットワーク上の API は、インターネットから直接触れないことが多いです。検証者のノート PCから、ジャンプホスト経由で独占 Mac に入り、そこで待つ MCP／ゲートウェイのループバックにトンネルを張る例（ホスト名・ポートは置換）：
ssh -N -L 18790:127.0.0.1:18789 devuser@dedicated-mac.corp.exampleローカルで http://127.0.0.1:18790 に向けた MCP Inspector や SDK が、リモート Mac 上のリスナーと同じ挙動になるかを確認します。ServerAliveInterval と ControlMaster で長時間セッションを安定化し、鍵はユーザ単位で分離します。
7. 受入チェックリスト
| ID | 検証内容 | 合格条件 |
|---|---|---|
| R1 | レジストリのロックファイルと実ホストの起動コマンド | digest／バージョンが一致し、差分が監査ログに残る |
| E1 | 意図しない外向き curl |
プロキシまたは FW でブロックされ、エージェントログに要約のみ |
| O1 | Client Secret ローテーション演習 | 新旧切替中も SLO 内、失効後は旧 Secret で 401 |
| S1 | SSH トンネル経由で MCP ツール呼び出し | Mac 直叩きと同等のレスポンス（RTT を除く） |
8. FAQ
Q: MCP サーバが勝手に新しい外部ドメインに接続した。
A: ツール定義のレビューを自動化し、実行時は egress プロキシの拒否ログと突合する。レジストリ外のバイナリ起動を禁止する。
Q: Secret ローテーション直後にだけ 401 が続く。
A: 再起動順序を見直す。IdP が複数シークレット併存を許さない設定なら、メンテ窓口で一括切替する。
Q: SSH トンネルが夜間に切れる。
A: ServerAliveInterval、autossh、または恒久的な社内 VPN／ZTNA を検討する。業務要件に応じてどちらを正とするかを文書化する。
MCP と社内 API を載せるなら Mac mini が扱いやすい理由
MCP サーバ複数、ローカル検証用のコンテナ、ssh-agent、軽量なログ集約を同一ホストに載せると、CPU とメモリ帯域の詰まりと熱がボトルネックになります。Apple Silicon の Mac mini はユニファイドメモリで複数 Node プロセスとプロキシを同居させやすく、待機電力が数ワット程度に抑えやすいため、検証用の常時ノードとしてコストと騒音のバランスが良いです。macOS は OpenSSH・launchd・Gatekeeper／SIP により、無人で動かす際の攻撃面も狭めやすく、FileVault を有効にすれば物理持ち出し時のリスクも下げられます。
本記事のような「レジストリ固定・出域制御・OAuth ローテーション・SSH トンネル」を一つの箱で再現したいチームには、Mac mini M4 は静かで省電力な起点になります。プラン比較はトップページから行い、社内 API との接続検証を繰り返しやすい環境を整えてください。