MCP 2026-07-28 リモートMacは必要？導入判断

MCP 2026-07-28のサーバーは、通常のAPI、データベース、文書検索だけならMacに置く必要はありません。Xcode、Simulator、Keychain、AppleScriptなどmacOS固有の機能を実行するToolだけを実Macへ分離し、本番は汎用サービス層とMac実行ノードの混合構成にするのが、今週の推奨判断です。

Appleプラットフォーム向けAI Agentを開発し、MCP Toolからビルドやテストを呼び出したいエンジニア向けです。
MCPサーバーの配置、権限分離、可用性を評価する開発基盤担当者や、Linuxのサービス層はあるもののmacOSの常時稼働ノードが不足しているチームにも適しています。

最初の判断：AIクライアントがMac上で動いていることだけを理由に、MCPサーバー全体をMacへ移す必要はありません。実際に子プロセス、ファイル、システムサービス、グラフィカルセッションのどれがmacOSに依存するかをTool単位で確認します。

Model Context Protocolは、ホスト、クライアント、サーバーを分けてToolやリソースを扱う構成です。公式アーキテクチャでは、ローカルプロセスとの接続とリモートサービスへの接続を区別して説明しているため、クライアントの実行場所とToolの実行場所は同一である必要がありません。MCP公式アーキテクチャを基準に、設計図を分けて考えます。

各Toolについて、次のような依存関係を表にします。

• 入力と出力はHTTP API、データベース、文書ストレージだけか
• 子プロセスとしてxcodebuildなどを起動するか
• Apple SDK、Simulator、署名環境、Keychainへ触れるか
• GUIログインセッションやユーザー同意を要求するか
• プロジェクトファイルを置くディレクトリと生成物の保存先はどこか
• 秘密鍵、証明書、アクセストークンをどのプロセスが読むか

API呼び出し、データ検索、文書変換のような処理は、既存のLinux系サーバーに残す候補です。一方、Xcodeのコマンドラインツールを呼ぶ処理は、AppleのXcodeコマンドラインツールリファレンスで利用条件を確認し、実際のmacOSノードを候補にします。

MCPサーバーはMacに必須か

MCPサーバーがMacに必須になるのは、プロトコルではなく、サーバーが実行する処理のOS依存性によります。データ取得Toolだけなら汎用ノードで十分であり、Apple専用の実行器を含む場合だけMacノードを追加します。

最初はローカルプロセスでToolを呼び出す構成が扱いやすいです。コード、設定、環境変数、子プロセスがどこで実行されるかを追跡でき、権限を狭めながらプロトコルのデバッグもできます。共有利用や継続実行が必要になった時点で、リモートMCPサービスへ移します。

試作の合格条件は、単に接続できることではありません。

• Tool一覧がクライアントから発見できる
• 必須パラメーターと不正な型を検証できる
• 標準出力に診断ログを混ぜず、プロトコル応答を壊さない
• 実行結果、終了状態、エラー原因を構造化して返す
• 同じ入力を再実行した時の副作用を把握できる

MCP 2026-07-28は公式のリリース情報として公開されていますが、個別のクライアント、SDK、第三者製MCP Serverがすべて同じ仕様を完全に実装しているとは限りません。利用するSDKの対応状況は、TypeScript SDKの2026-07-28移行説明で個別に確認します。

最初から大きなAgentワークフローを接続せず、実際のプロジェクトを対象に最小のToolを一つ作ります。入力をプロジェクトパス、スキーム、構成などに限定し、MCPからXcodeのコマンドライン処理を起動して、終了状態とログの要約を構造化して返す設計にします。

Appleも継続的インテグレーションでのビルドについて、Xcodeのコマンドライン処理を使う手順を案内しています。XcodeのCIビルド公式資料に沿って、必要なSDK、依存関係、署名条件を洗い出します。

ここで、純粋なコマンドラインビルドが成功したことを、Apple開発環境全体が使える証拠と解釈してはいけません。Simulatorを起動するテスト、グラフィカルなログインセッションを要求する処理、Keychain内の資格情報を読む処理では、別の制約が生じます。Keychainの保護やアクセス条件は、AppleのKeychain Services資料で確認します。

通用ノード、Macノード、混合構成の比較

私たちが本番で第一候補にするのは混合構成です。プロトコル入口と認証を汎用サービス層に置き、Apple専用の操作だけを制限付きMacノードへルーティングします。ただし、Toolが少なく、全処理がApple環境に密接な場合は、リモートMac単独構成の方が運用を単純にできます。

MCPを共有サービスにする前に、専用の非管理者アカウントを作成し、プロジェクト用ディレクトリ、キャッシュ、生成物の保存先を分けます。デフォルトで管理者権限を継承させたり、任意のシェルコマンドをToolとして公開したりする設計は避けます。

MCPの認可仕様では、リモート接続における認証と認可の扱いが定義されています。MCP公式認可仕様を確認し、認証済みであることと、個別Toolを実行できることを同じ条件にしない設計にします。

最低限、次を拒否テストします。

• プロジェクト外のディレクトリを指定した要求
• sudo、任意のシェル、削除系処理など許可していない命令
• 期限切れ、形式不正、対象外環境の資格情報
• 他チームのプロジェクト名や秘密情報を指定した要求

ローカルプロセスでは環境変数、設定ファイル、子プロセスの継承権限を確認します。リモートHTTP接続では、TLS、認証、Toolごとの認可、要求ログの秘匿性を確認します。認証トークンや署名鍵をプロンプト、標準出力、ビルドログへ出さないことも合格条件です。

権限分離の経験則：MCP Toolに「何でも実行できるシェル」を渡すと、Apple専用処理の検証ではなく、Mac全体の管理権限をAgentへ渡す試験になります。操作をビルド、テスト、成果物取得などに分解し、引数の許可範囲を固定します。

共有利用へ進める前に、障害をネットワーク、MCPプロセス、macOSセッションの三つに分類できる状態を作ります。SSH接続については、AppleのMacリモートログイン公式説明を参照し、SSHが復旧してもGUIやSimulatorまで利用可能とは限らない点を記録します。

試験は次の順で実施します。

1. MCPクライアントからTool一覧を取得し、通常のToolを実行します。
2. SSHを切断し、バックグラウンド処理の状態とログを確認します。
3. クライアントを再接続し、同じ要求を安全に再実行できるか確認します。
4. Macを再起動し、ログイン状態、MCPプロセス、必要なサービスの復旧を確認します。
5. MCPプロセスだけを異常終了させ、監視または起動機構で戻るか確認します。
6. ビルド中断後に成果物と一時ファイルが不整合にならないか検査します。

各試験では、失敗地点、復旧操作、再実行結果、残ったファイルを記録します。SimulatorやGUIを使うToolは、無人状態、セッション切断、再起動直後の動作を別々に検証し、SSHが通ることだけで可用性を判定しません。

継続的なAppleビルドでは、署名、証明書、依存パッケージ、SDKの更新が復旧性に影響します。ビルドノードの責任者が、MacのOS更新だけでなく、資格情報の更新と失効時の手順まで持てないなら、単一ノードを本番の唯一の経路にしない方が安全です。

試運転の結果は、次の三つに分類します。

• Apple固有の依存がなく、復旧試験も汎用基盤で完了した場合は、汎用サーバー単独
• ほぼすべてのToolがXcodeやmacOSサービスを必要とし、権限と復旧をMac上で管理できる場合は、リモートMac単独
• 通用ToolとApple専用Toolが混在する場合は、汎用サービス層とMac実行ノードの混合構成

判断基準はCPUやメモリの仕様比較だけではありません。Toolが何を呼ぶか、誰の資格情報を読むか、再起動後にどこまで自動復旧するか、失敗時に誰が対応するかを優先します。

MCP 2026-07-28については、2026年8月28日時点で公式リリース情報を再確認しています。なお、仕様の公開日と各実装の対応完了日は同じではないため、導入時には利用中のSDKとクライアントの対応資料を再確認します。

• [ ] 全Toolについて、子プロセス、ファイル、SDK、システムサービスの依存先を記録した
• [ ] macOS固有の処理と汎用API処理を別ノードへ分類した
• [ ] ローカルプロセスでTool発見、引数検証、構造化エラーを確認した
• [ ] Xcodeの最小ビルドを実Macで実行し、コマンドライン処理とGUI依存処理を分けた
• [ ] 専用アカウント、許可ディレクトリ、許可コマンドを固定した
• [ ] Keychain、証明書、トークンがログやプロンプトへ漏れないことを確認した
• [ ] 不正なディレクトリ、危険な命令、無効な資格情報を拒否できた
• [ ] SSH切断、クライアント再接続、Mac再起動、MCP異常終了を試験した
• [ ] 失敗をネットワーク、プロセス、macOSセッションの層別に記録した
• [ ] 単独構成を選ぶ理由、または混合構成で分離する境界を文書化した

既存のLinuxサービス層をそのまま使えるなら、最初から全体をMacへ移すより、Apple専用Toolだけを隔離した方が変更範囲を抑えられます。長期タスクの切断復旧まで詰める場合は、SSHで長期稼働するmacOS開発サーバーの確認項目も併せて確認すると、接続確認と実行環境確認を混同しにくくなります。

現在の構成がLinuxサーバーだけなら、XcodeやSimulatorを呼べないこと、Apple固有の資格情報を扱えないこと、別のMacを都度手動で用意すると再現性と復旧手順が崩れやすいことが弱点になります。反対に、すべてをMacへ集約すると、汎用サービスまでMacの保守対象になり、権限境界も広がります。まず隔離したMacで最小MCP Toolを試し、Xcode呼び出し、権限拒否、再起動復旧を確認したい場合は、JEXCLOUDのMacレンタル構成を検討するのが現実的です。検証結果が出てから正式なAgent基盤へ組み込めば、不要なMac導入や本番ノードの早期改造を避けられます。