Codex CLI MCPをリモートMacと本機のどちらに配置する？2026年の選び方

先に結論：参照する資源に合わせて配置します

Codex公式の文書MCP例では、Codex CLIからHTTPのMCP serverへ接続する設定が示されています。公式の設定例が示すとおり、すべてのMCPをリモートMacへ移す必要はありません。遠隔データを提供するHTTP MCPは到達可能な管理環境へ、ローカルコマンドやプロジェクトファイルに依存するstdio MCPはその資源がある実行環境へ配置します。XcodeなどApple専用ツールを呼び出す処理だけ、Mac上で実行してください。

この記事は、Codex CLIでMCPを設定する独立開発者、MCPと作業環境の境界を設計するDevOps担当者、AgentからXcodeを呼び出したいiOS・macOS開発者向けです。接続できることと、遠隔のファイルやツールを実際に扱えることを分けて判断します。

まず整理：クライアント、MCP server、作業環境は別の役割です

Codex CLIはツール呼び出しを行うクライアントで、MCP serverはツールやデータを提供します。Codex CLI自体はローカルコンピューターで動作するCLIとして説明されていますが、どのMCP serverを設定するか、またツールがどのホストの資源を参照できるかは別々に確認する必要があります。Codex CLI公式リポジトリとCodexの基本設定を参照し、クライアントの場所とツールの実行場所を混同しないようにします。

HTTPとstdioは、MCP serverへの接続方法の違いです。MCPのトランスポート仕様では、stdioはクライアントがローカルプロセスを起動して通信する方式、HTTPはネットワーク越しに接続する方式として扱われます。したがって「リモートMCPに接続できる」という事実だけでは、リモートMac上のプロジェクトへアクセスできるとは判断できません。

文書や共有データだけなら、HTTP MCPを独立させます

検索対象がリモート文書や共有データであり、ツールが開発中の作業ツリーやMac上のコマンドを必要としない場合、MCP serverをCodex CLIと同じMacに置く理由はありません。HTTPで接続できるサービス環境を選び、ネットワーク経路、認証、利用者ごとのデータ権限を確認します。

Codexの公式文書MCP例は、HTTPを使う文書参照の構成です。ただし、これはその例のサーバーが提供する機能と権限を示すものであり、任意のHTTP MCPが読み取り専用であることや、同じ認証方式を採用することを保証しません。Codexの設定リファレンスも確認し、接続先や認証情報の扱いを実際の構成に合わせます。

注意：MCP serverの認証が成功しても、ツールが返すデータの閲覧範囲まで適切とは限りません。接続確認とは別に、意図した利用者の権限で許可範囲を確認してください。

作業中のファイルやコマンドを扱うなら、stdioを実行環境に寄せます

stdio MCPは、Codex CLIがプロセスとして起動するため、ツールが参照するファイルパスやコマンドの実体は、そのプロセスが動くホストに属します。手元の作業ツリーを読むなら、本機でCodex CLIとstdio MCPを動かします。リモートMac上の作業ツリーを扱うなら、リモートMac側で動くクライアントとMCPプロセスが、そのツリーにアクセスできる構成にします。

Codexの設定資料では、MCP serverの起動コマンドや環境変数を設定できます。基本設定の説明を参照し、起動コマンドがどのホストで実行されるかを確かめてください。手元のCodex CLIからHTTP経由で遠隔のMCPに接続する構成では、遠隔のstdioプロセスや作業ツリーが自動的に手元へ移るわけではありません。必要なら、遠隔側の実行環境でCodex CLIとツールを動かす方法を別途設計します。

XcodeやmacOS専用ツールを呼ぶときは、該当処理をMacで動かします

MCPはツール呼び出しのための仕組みであり、MCP serverすべてにMacが必要なわけではありません。一方、ツールがXcode、xcodebuild、macOS SDK、またはMac上のリソースに依存する場合、処理を実行する環境にはそれらが必要です。

Appleの資料では、xcodebuildなどのコマンドラインツールはXcodeに含まれ、コマンドラインで利用するにはXcodeをインストールしてアクティブな開発ディレクトリを設定する手順が案内されています。コマンドラインツールの導入説明と開発ディレクトリの設定方法を確認してください。これはAppleツールを実行するOS上の条件を示すもので、特定のMacノードの性能を保証するものではありません。

確認ポイント：MCP serverがMacにあることと、ビルドがそのMacで実行されることは同義ではありません。ツールの起動ホスト、リポジトリの場所、ビルドコマンドの実行結果を一続きで検証します。

チーム共有では、サービス提供とタスク実行を分けます

HTTP MCPをチーム共通の入口として用意する場合、認証、ツールごとの許可範囲、利用者がアクセスできるデータをサービス側で管理します。しかし、共有HTTPサービスを用意しただけでは、各利用者の作業ツリー、ビルド用の資格情報、実行ホストまで共有・分離されるわけではありません。

プロジェクトを読んだりビルドしたりする処理では、リポジトリ、実行ユーザー、必要な資格情報、ツールプロセスがどの実行端末に揃うかを明確にします。Appleの継続的インテグレーション向けビルド手順も参照し、Xcodeを呼ぶ処理を適切なMac上で確認してください。リモートMacは実行先の選択肢であり、それだけで安全な隔離環境になるわけではありません。

条件分岐で配置先を決め、実際の呼び出しで受け入れます

以下の条件に沿って決めると、サービスの設置場所とタスクの実行場所を分離できます。

• 参照するのが遠隔の文書や共有データで、作業ツリーやローカルコマンドに依存しない場合は、HTTP MCPを選びます。認証、通信経路、データ権限を確認できなければ、共有範囲を広げず構成を見直します。
• ツールが現在のプロジェクトファイル、ローカルコマンド、作業中の状態を使う場合は、stdio MCPをその作業環境に置きます。資源がリモートMac上にあるなら、ツールプロセスもその環境で動くようにします。
• ツールがXcode、xcodebuild、macOS SDK、Mac上の資源を必要とする場合は、該当タスクをMacで実行します。Appleのツールチェーンが揃わない環境へ、ビルド実行まで任せないでください。
• 文書参照とAppleプラットフォームのビルドを両方行う場合は、HTTPの共有データサービスとMac上の実行処理を分ける混合構成を選びます。資格情報やリポジトリへのアクセスは、それぞれの境界で個別に許可します。
• チームで共有する場合は、共通サービスと個別タスクの実行端末を分けて記録します。誰の権限でどのホストのファイルやコマンドを使うか説明できなければ、運用開始を保留します。

導入時は、まず利用するツールごとに「読み取るデータ」「実行するコマンド」「必要なOS」を書き出します。次にCodex CLIの稼働ホストとMCPの起動方式を確定し、設定した認証情報が想定した権限に限られるかを確認します。その後、実際の呼び出しで文書の取得、対象プロジェクトファイルへのアクセス、Appleツールを使うタスクの完了をそれぞれ確かめます。最後に、ログから実行ホストと利用者の識別ができること、失敗時にどの段階で止まったかを追えることを確認してから運用へ移します。

よくある質問

リモートMac上のプロジェクトを手元のCodex CLIから扱うには、何を確認しますか？
接続先のMCP serverだけでなく、プロセスが動くホスト、リポジトリの実際のパス、ツールを実行するユーザーを確認します。遠隔の作業ツリーを使うなら、同じ環境でツールを動かす構成にするか、必要な資源を安全に公開する仕組みを別途設計してください。単にHTTP接続できる状態を、ファイル共有済みとみなさないことが重要です。

stdio MCPをリモートMacで動かした場合、手元のクライアントから利用できますか？
stdioはクライアントがローカルプロセスを起動する方式なので、手元のCodex CLIがリモートMac上のプロセスをそのまま起動するわけではありません。CLIも遠隔の実行環境で動かすか、ネットワーク越しに利用できる別の接続方式を用意する必要があります。採用する方式は、認証とツール権限を含めて検証します。

Mac上でMCP serverを動かせば、Xcodeのビルドも自動的にMacで行われますか？
自動的には行われません。MCP serverの配置先ではなく、呼び出されたツールのプロセスがどのホストで起動し、そのホストにXcodeと対象プロジェクトがあるかを確認します。Xcodeを使うタスクでは、実際のxcodebuild実行結果まで確認し、接続成功だけで受け入れ判定を終えないようにします。

共有HTTP MCPにプロジェクトファイルや資格情報もまとめるべきですか？
共有サービスにすることと、すべての利用者へ同じファイルや資格情報を渡すことは別の判断です。共有が必要なデータ、個人の作業ツリー、ビルド用資格情報を分け、利用者とタスクに必要な範囲だけ許可します。実行ホストやアクセス権を説明できない場合は、サービスの共有範囲を絞ってから運用してください。

本機にXcodeがあり、作業も同じ端末で完結するなら、ローカル構成のほうが余計な遠隔アクセス設計を避けやすい場合があります。反対に、Appleツールを使うタスクだけが不足している環境では、Macを購入する前に、必要な実行環境や利用条件をRUVCLOUDの案内と料金情報で確認する方法があります。リモートMacを選ぶ場合も、長期の常時負荷や物理ポートを必要とする用途に合うとは限らないため、必要なツールと実行時間を基準にしてください。短期の検証やXcodeタスク用の環境が必要なら、利用プランを確認し、手元のCodex CLIとMac側の実行プロセスをどこで分けるか決めてから導入すると、不要な移行を避けられます。