Codex MCP入門｜外部ツール連携の仕組みと安全な使い方

Codexを使っていると、「コードだけでなく、ドキュメント、ブラウザ、Figma、エラーログ、GitHubのIssueなども一緒に見てほしい」と思う場面が出てきます。毎回必要な情報を手で貼り付けることもできますが、作業が増えるほど限界があります。

そこで登場するのがMCPです。MCPを使うと、Codexが外部ツールや外部データソースにアクセスしやすくなります。本記事では、MCPとは何か、Codexで何が便利になるのか、どのように設定するのか、認証や権限で何に注意すべきかを初心者向けに整理します。

1. MCPとは何か

ひとことで：MCPは、AIエージェントと外部ツールをつなぐための共通の仕組みです。

MCPは Model Context Protocol の略です。Codexから見ると、MCPは「外部ツールや外部の文脈にアクセスするための接続口」と考えると分かりやすいです。

OpenAI公式のCodex MCPページでは、MCPはモデルをツールやコンテキストにつなぎ、Codexにサードパーティのドキュメントを読ませたり、ブラウザやFigmaのような開発ツールと連携させたりできる仕組みとして説明されています。

たとえば、次のようなイメージです。

Codex
  ↓
MCP server
  ↓
外部ツール・外部データ

Codexが直接すべてのサービスを知っているわけではありません。MCPサーバーが間に入り、「このツールでは何ができるか」「どの情報を取得できるか」「どの操作を実行できるか」をCodexに渡します。

用語	ざっくりした意味
MCP	AIと外部ツールをつなぐ共通プロトコル
MCP server	ツールやデータへの窓口になるサーバー
tool	Codexから呼び出せる操作
context	Codexが参照できる追加情報
auth	外部サービスへ接続するための認証

2. MCPで何が便利になるのか

ひとことで：Codexに、貼り付けなくても参照できる情報源を増やせます。

MCPのメリットは、Codexが作業に必要な情報へアクセスしやすくなることです。特に、情報がコードベースの外にある場合に役立ちます。

代表的な使いどころです。

連携先	できることの例
ドキュメントMCP	最新のライブラリDocsを調べながら実装する
ブラウザ操作MCP	ローカル画面を開き、表示やエラーを確認する
Figma MCP	デザインを参照してUI実装の手がかりにする
Sentry MCP	エラーログを見て原因調査の入口にする
GitHub MCP	IssueやPull Requestの文脈を参照する

たとえば、フロントエンド実装で「Figmaのデザインを見ながら既存コンポーネントに合わせて実装してください」と頼む場合、MCPがあるとCodexが必要なデザイン情報にアクセスしやすくなります。

一方で、MCPは必須ではありません。最初のうちは、必要な情報をプロンプトに貼る、関連ファイルを指定する、公式Docsへのリンクを渡すだけでも十分です。MCPは、手作業の情報共有が繰り返し発生し、接続する価値が出てきた段階で検討します。

3. Codexで使えるMCPの基本形

ひとことで：CodexではCLIとIDE拡張でMCP設定を共有できます。

公式Docsでは、CodexはCLIとIDE拡張の両方でMCPサーバーをサポートすると説明されています。設定はCodexの config.toml に保存され、CLIとIDE拡張で共有できます。

MCPサーバーの接続方式は、大きく2種類です。

種類	何をするか	向いている例
STDIO server	ローカルプロセスとして起動する	ローカルの開発補助、npm経由のMCP
Streamable HTTP server	URLへ接続する	Figmaなど外部サービスのリモートMCP

STDIOは、Codexがローカルでコマンドを起動してMCPサーバーとやり取りする形です。Streamable HTTPは、外部のURLに接続する形です。

初心者は、まず「どちらが正しいか」よりも、「そのMCPサーバーが何にアクセスできるのか」を確認することが大切です。ローカルファイルを読めるのか、外部サービスに書き込みできるのか、認証情報が必要なのかで、注意点が変わります。

4. 設定はどこに書くのか

ひとことで：MCP設定はCodexの config.toml に書きます。

CodexのMCP設定は、基本的に ~/.codex/config.toml に保存されます。信頼済みプロジェクトでは、プロジェクト内の .codex/config.toml にスコープすることもできます。

設定方法は2つあります。

1. codex mcp コマンドで追加・管理する
2. config.toml を直接編集する

公式Docsでは、MCPサーバーごとに [mcp_servers.] の形で設定する例が紹介されています。STDIOサーバーなら、起動コマンドや引数、環境変数を指定します。

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

HTTPサーバーなら、接続先URLやBearer token用の環境変数、HTTPヘッダーなどを設定できます。

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

ここで重要なのは、認証情報そのものを設定ファイルに直接書かないことです。トークンは環境変数に入れ、bearer_token_env_var のように「どの環境変数を使うか」だけを書きます。

5. CLIで追加する流れ

ひとことで：まずは公式例や信頼できるMCPサーバーを、1つだけ追加して試します。

Codexでは、CLIからMCPサーバーを追加できます。公式Docsでは、codex mcp add を使ってMCPサーバーを追加する方法が紹介されています。

たとえば、開発者向けドキュメントを調べるためのContext7を追加する例です。

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

追加したあとは、CodexのTUIで /mcp を使うと、アクティブなMCPサーバーを確認できます。

ただし、初心者がいきなり複数のMCPを入れるのはおすすめしません。まずは1つだけ追加し、次の3点を確認します。

• 何の情報にアクセスできるか
• どの操作をCodexに許すことになるか
• 使わないときに無効化できるか

MCPは便利ですが、接続先が増えるほど管理する権限も増えます。最初は、読み取り中心のMCPから試すと安全です。

6. 認証と権限で見るべきポイント

ひとことで：MCPは便利なぶん、渡す権限を必ず確認します。

MCPは外部ツールへの入口になるため、認証と権限の確認が重要です。公式Docsでは、HTTPサーバーでBearer token認証やOAuth認証に対応し、OAuth対応サーバーでは codex mcp login を使う流れが示されています。

確認すべきポイントです。

• トークンが必要か
• トークンには読み取り権限だけか、書き込み権限もあるか
• そのMCPはどのツールをCodexに公開するか
• ツールの許可リスト・拒否リストを設定できるか
• 失敗時にどう停止するか
• チームで共有してよい設定か

CodexのMCP設定には、enabled_tools と disabled_tools のように、使えるツールを絞る設定もあります。すべての機能を渡すのではなく、最初は必要な機能だけに絞るのが安全です。

[mcp_servers.browser]
url = "http://localhost:3000/mcp"
enabled_tools = ["open", "screenshot"]
tool_timeout_sec = 45
enabled = true

この例では、使うツールを open と screenshot に絞っています。実際の設定名や使えるツールはMCPサーバーごとに違うため、必ずそのMCPサーバーの説明を確認します。

7. AGENTS.mdとMCPの役割分担

ひとことで：AGENTS.mdはルール、MCPは外部アクセスです。

CX-07で扱った AGENTS.md とMCPは、どちらもCodexの作業を支える仕組みですが、役割が違います。

仕組み	役割
AGENTS.md	プロジェクトの作業ルールや前提を伝える
MCP	外部ツールや外部データへの接続口を渡す
プロンプト	今回やってほしい具体的な作業を伝える

たとえば、Figma連携を使う場合でも、AGENTS.md には「UI変更時は既存コンポーネントを優先する」「アクセシビリティを確認する」といった作業ルールを書きます。MCPには、Figmaへアクセスするための接続を設定します。プロンプトには、「この画面のデザインを参考に、設定ページのフォームを調整してください」と今回の依頼を書きます。

3つを混ぜないことが大切です。MCP設定に作業ルールを書いてもCodexには伝わりません。AGENTS.md にトークンを書いても危険です。今回だけの依頼を AGENTS.md に入れると、次回以降の作業を邪魔します。

8. MCPが向いている作業

ひとことで：外部情報を何度も参照する作業に向いています。

MCPは、外部ツールを継続的に使う作業と相性が良いです。

向いている例です。

• 最新Docsを確認しながらライブラリ移行を進める
• Figmaを見ながらUIを実装する
• ブラウザでローカル画面を確認しながら修正する
• Sentryのログを見てエラー原因を調査する
• GitHubのIssueを参照して修正方針を整理する
• 社内ドキュメントを参照して仕様変更を進める

逆に、1回だけ見る資料や、短い仕様で足りる作業なら、MCPを使わなくても構いません。プロンプトに必要な情報を貼る方が早いこともあります。

判断基準はシンプルです。

同じ外部情報を何度も見に行く
  → MCPを検討する

今回だけの短い情報で済む
  → プロンプトに貼る

プロジェクト全体のルール
  → AGENTS.mdに書く

9. MCPを使うときの依頼文例

ひとことで：どのMCPを使うか、何を見てほしいか、何をしないかを明確にします。

MCPを設定しても、Codexに丸投げするのは避けます。外部ツールを使う場合ほど、目的と制約を明確にします。

ドキュメント調査の例です。

Goal:
React Routerの最新ドキュメントを確認し、このプロジェクトのルーティング実装に必要な変更点を整理してください。

Context:
Docs検索用のMCPが使える場合は利用してください。
対象ファイルは `src/router.tsx` です。

Constraints:
この段階ではファイルを変更しないでください。
公式Docsに書かれている内容と、推測を分けてください。

Done when:
必要な変更点、参照したDocs、実装前に確認すべきリスクをまとめてください。

Figma参照の例です。

Goal:
Figmaの設定画面デザインを参考に、既存のSettingsページとの差分を整理してください。

Context:
Figma MCPが使える場合は、対象フレームを確認してください。
実装対象は `src/pages/Settings.tsx` です。

Constraints:
まだ実装しないでください。
デザインシステムを新規作成せず、既存コンポーネントで対応できる範囲を優先してください。

Done when:
実装が必要な差分、既存コンポーネントで対応できる箇所、追加確認が必要な箇所を分けてください。

ポイントは、MCPを「使えるなら使って」ではなく、「どの情報を確認するために使うか」まで書くことです。外部情報を取得した場合は、何を根拠にしたかも報告してもらいます。

10. やりすぎ注意のポイント

ひとことで：MCPは、接続先を増やすほど管理コストも増えます。

MCPは便利ですが、増やしすぎると管理が難しくなります。外部サービスごとの認証、権限、トークン更新、ツールの挙動、失敗時の扱いを把握する必要があるためです。

避けたい状態です。

• 使っていないMCPサーバーが有効なまま残っている
• 何の権限を持つトークンか分からない
• 書き込み可能なMCPを確認なしで使っている
• チームで誰が設定を管理するか決まっていない
• Codexがどの外部情報を参照したか分からない
• MCPで取得した情報を人間が確認していない

MCPは「たくさん入れるほど強い」ものではありません。実務では、よく使うものだけに絞り、読み取り中心から始め、必要なときだけ権限を増やす方が安全です。

11. 導入前チェックリスト

ひとことで：接続する前に、目的・権限・停止方法を確認します。

MCPを導入する前に、次のチェックリストを確認してください。

• そのMCPで何をしたいか説明できる
• 接続先が信頼できる
• 必要な権限が最小限になっている
• トークンを設定ファイルに直書きしていない
• 使えるツールを絞れるなら絞っている
• 使わないときに無効化できる
• Codexに外部情報の根拠を報告させる
• 差分確認と人間レビューを省かない

最初のMCPは、読み取り中心で、失敗しても影響が小さいものがおすすめです。たとえば、ドキュメント検索やローカルブラウザ確認のように、作業の補助になるものから始めると扱いやすいです。

12. 次に読む記事

ひとことで：外部連携の次は、作業手順を再利用するSkillsへ進みます。

本記事では、CodexのMCPについて、外部ツール連携の仕組み、STDIOとHTTP、設定方法、認証、権限管理、AGENTS.mdとの役割分担、導入前チェックを解説しました。

次に読む記事は、CX-09「Codex Skills完全ガイド｜作業手順を再利用する方法」です。MCPが外部ツールとの接続を増やす仕組みだとすると、Skillsは繰り返し使う作業手順を再利用しやすくする仕組みです。外部連携と作業手順の両方を整えると、Codexをより実務向けに扱いやすくなります。

公式情報としては、Model Context Protocol、Agent approvals & security、Codex Security を確認しておくと、MCPを安全に扱うための前提を整理しやすくなります。

この記事とあわせて読みたいCodex記事

ひとことで：この記事の理解を深めるための関連回です。

• CX-05 Codexの権限と安全設定｜承認・サンドボックス・Git管理
• CX-07 Codex AGENTS.md完全ガイド｜プロジェクト指示を書く方法
• CX-09 Codex Skills完全ガイド｜作業手順を再利用する方法
• CX-11 Codex Cloud・Automations入門｜作業を任せる運用設計

Codexシリーズ記事一覧

ひとことで：Codex編は、導入から専門機能まで順番に読めるシリーズです。

• CX-01 Codex入門｜できること・始め方・Claude Codeとの違い
• CX-02 Codex導入ガイド｜App・IDE・CLIの選び方と初期設定
• CX-03 Codexの使い方｜最初に試すプロンプトと安全な進め方
• CX-04 Codexプロンプト設計｜Goal・Context・Done whenの書き方
• CX-05 Codexの権限と安全設定｜承認・サンドボックス・Git管理
• CX-06 Codex実践ワークフロー集｜調査・修正・レビューの依頼文例
• CX-07 Codex AGENTS.md完全ガイド｜プロジェクト指示を書く方法
• CX-08 Codex MCP入門｜外部ツール連携の仕組みと安全な使い方（本記事）
• CX-09 Codex Skills完全ガイド｜作業手順を再利用する方法
• CX-10 Codex Subagents入門｜複数エージェントで並列作業する方法
• CX-11 Codex Cloud・Automations入門｜作業を任せる運用設計
• CX-12 Codexベストプラクティス完全ガイド｜失敗しない使いこなし方