CodexのMCP設定ガイド — 外部ツール連携のやり方・おすすめサーバー・安全に使う設定

MCPとは — AIと外部ツールをつなぐ共通規格

MCP（Model Context Protocol）は、AIをツールや情報源に接続するための共通規格です。「MCPサーバー」と呼ばれる接続部品を追加すると、Codexはそのツールを自分の道具として使えるようになります。たとえばブラウザ操作・Figmaのデザイン参照・GitHubのプルリクエスト管理・最新の開発者ドキュメント検索などが、依頼文の中で自然に使えるようになります。

人間の組織にたとえるなら、MCPサーバーの追加は「新しい社内システムのアカウントをスタッフに発行する」ことに近い操作です。道具が増えるほど任せられる仕事は広がりますが、後述のとおり何でも繋げばよいわけではない点が実務のポイントになります。

前提 — アプリ・CLI・IDE拡張で設定は共有される

CodexのMCP設定は config.toml という設定ファイル（標準では ~/.codex/config.toml）に保存され、デスクトップアプリ・CLI・IDE拡張が同じ設定を共有します。一度設定すれば、どの入り口からCodexを使っても同じ外部ツールに接続できます。プロジェクト単位で接続先を分けたい場合は、信頼済みプロジェクトに限り .codex/config.toml をプロジェクト側に置くこともできます。

ただしこの「設定の共有」は、手元のパソコンで動く3つのクライアントの間での話です。スケジュール実行（定期実行）やクラウド実行になると事情が変わるため、その違いは後半の実行場所別の整理で扱います。

接続のやり方 — コマンド1行から始める

基本: codex mcp add で追加する

最も簡単な追加方法は、ターミナルでの1行です。公式ドキュメントの例では、開発者向けドキュメント検索のContext7を次のように追加しています。

codex mcp add context7 -- npx -y @upstash/context7-mcp

追加済みのサーバーは codex mcp list で一覧でき、Codexの対話画面では /mcp で現在有効なサーバーを確認できます。OAuth認証が必要なサーバーは codex mcp login <サーバー名> でログインします。

細かく制御したい場合: config.toml を編集する

接続先ごとの詳細設定は、config.toml に [mcp_servers.<サーバー名>] のブロックを書いて行います。ローカルでコマンドとして起動するタイプ（STDIO）と、URLで接続するタイプ（Streamable HTTP）の両方に対応し、環境変数・認証（Bearer トークン／OAuth）・タイムアウトなどを指定できます。

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

何を繋ぐか — 公式が挙げる代表例と選び方

公式ドキュメントが「よく使われる例」として挙げているのは次のようなサーバーです。

• OpenAI Docs MCP — OpenAIの開発者ドキュメントを検索・参照
• Context7 — 最新の開発者ドキュメントに接続
• GitHub — プルリクエストやIssueなど、gitコマンドを超えたGitHub操作
• Playwright / Chrome Developer Tools — ブラウザの操作・検証
• Figma — デザインデータへのアクセス
• Sentry — エラーログの参照

選び方の原則はシンプルで、「いま任せたい業務に必要な道具だけを繋ぐ」ことです。SNSで話題の「おすすめMCP」を手当たり次第に入れるのではなく、議事録業務ならカレンダーやドキュメント系、開発業務ならGitHubやブラウザ系——と、業務起点で1つずつ足していくのが、当社が研修でお伝えしている順番です。

安全に使う — 承認モードとツール許可リスト

外部ツールに触れるということは、Codexの行動範囲が自分のPCの外へ広がるということです。Codexには接続先ごとの統制機能が用意されており、業務利用では最初に押さえておくべきポイントです。

• 承認モード — サーバー単位・ツール単位で「自動実行してよいか、都度確認するか」を設定できます（auto／prompt／writes／approveの4段階。writesは書き込み系ツールだけ確認）
• ツール許可リスト — enabled_tools（使ってよいツールだけ列挙）と disabled_tools（禁止ツールを列挙）で、サーバーの機能の一部だけを開放できます
• 一時停止 — 使わない時期は enabled = false で、設定を消さずに無効化できます

スケジュール実行・クラウド実行でMCPは使えるのか — 実行場所で答えが変わる

MCP連携を業務の仕組みに載せようとすると、必ず次の疑問にぶつかります。「手元で設定したMCPは、定期実行やクラウド実行でも同じように動くのか」。ここは実行場所によって答えが変わる部分で、知らずに自動化すると、手元では動いていた連携が無人実行の場面だけ静かに失敗します。2026年8月時点の公式ドキュメントの記述を整理すると、次のとおりです。

スケジュール実行 — 公式に示されている道は「プラグイン」

公式ドキュメントは、Web版で作ったスケジュールタスクも、デスクトップアプリで作ったスケジュールタスクもプラグインを使えると明記しています。プラグインは、Skills・コネクタ・MCPサーバー・Hooksなどをひとまとめにして導入できる単位で、MCPサーバーを内包できます（標準で入っているDocuments・Spreadsheetsなども同じプラグインの仕組みです。詳しくはCodexの標準プラグイン解説を参照）。つまり定期実行から外部サービスを触りたいとき、公式に示されている道はプラグインです。プラグインが持ち込むMCPサーバーも、有効・無効やツール単位の承認方針は利用側の設定で制御できます。

一方でWeb版のスケジュールタスクは、手元のパソコンのフォルダで直接作業することができず、ローカルのCodex設定ファイルも読み込みません。手元の config.toml に書いたMCPは、Web側の定期実行には引き継がれないと考えてください。デスクトップアプリのスケジュールタスクは手元のパソコン上で動くため同じ設定の圏内にありますが、公式が明示しているのはあくまでプラグインの方です。手元の設定を当てにするなら、本番の定期実行に載せる前に一度スケジュール実行で通して確かめるのが確実です。

Codex cloud — MCPの設定項目はなく、外部連携は環境変数から

クラウド実行（Codex cloud）の環境設定で用意されているのは、依存関係・セットアップスクリプト・メンテナンススクリプト・環境変数・シークレット・インターネットアクセス・パッケージのバージョン指定です。MCPサーバーを登録する項目は用意されていません。手元の config.toml がクラウドへ引き継がれるわけでもないため、「ローカルで繋いだMCPがそのままクラウドでも使える」という前提は置かないでください。

では外部サービスに一切触れないかというとそうではなく、APIキーを環境変数に入れて、そのサービスのAPIやCLIから叩く形なら成立します。ただしここには、公式ドキュメントに書かれている2つの落とし穴があります。

• シークレットはエージェントの作業が始まる前に削除される — シークレットはセットアップスクリプト専用で、安全のためエージェントの実行フェーズに入る前に取り除かれます。エージェント本体に使わせたい値は環境変数側に置くことになり、暗号化層がない前提での取り扱いを自分で判断する必要があります
• エージェントのインターネットアクセスは既定でオフ — セットアップ時はネットに出られますが、エージェントの作業中の通信は既定で遮断されています。外部APIを叩かせるなら、許可範囲を明示的に設定します

整理すると、実行場所が変わったときに同時に変わるのは設定の読み込み元・ネットワーク・認証情報の3つです。「手元で動いた」は「自動でも動く」ではない——これがMCPを仕組み化するときの、いちばん実務的な注意点です。定期実行そのものの考え方はCodexの定期実行（スケジュール）、クラウド実行の全体像はCodex Cloud（Web版）とスマホ活用で解説しています。

見落としがちな注意点 — MCPは利用枠も消費する

MCPサーバーを接続すると、その道具の説明が毎回の依頼に文脈として追加されるため、接続数が多いほど1回あたりの利用枠の消費が増えます。公式ドキュメントも「使わないMCPサーバーは無効化する」ことを利用枠の節約術として挙げています。「繋いだまま使っていないサーバー」は、料金効率の面でも見直す価値があります（利用枠と節約術の全体はCodexの料金を参照）。

MCPは「仕組み化」の一部 — 全体像の中で考える

MCPで道具を増やすことは、AGENTS.mdでルールを教える・Skillsで手順を登録するといった仕組み化と組み合わさって初めて業務基盤になります。「どの業務に・どの道具と・どんなルールで」をセットで設計する考え方は、Codexの応用機能まとめとCodexの使い方 — 頼み方3つの型で解説しています。

組織導入では「接続先の統制」がセキュリティ設計そのもの

個人利用なら必要な道具を自分で足していけば十分ですが、組織では「誰が・どの外部ツールを・どの権限で繋いでよいか」の統制がセキュリティ設計の中心になります。認証情報の管理、書き込み権限の扱い、部署ごとの接続先の標準化——当社のCodex研修・導入伴走支援では、MCP連携を含む利用ガイドラインの整備までを一体でご支援しています。