6-4 MCP で外部サービスにつなぐ

このレッスンでわかること

ここまでの Codex は、手元のファイルを読み書きする道具でした。MCP は、そこに外部サービスを触る手を足す仕組みです。

• MCP が何をするものかがわかる
• プラグイン（6-2）との違いがわかる
• 接続方式の2種類と、設定の書き方がわかる
• 資格情報を安全に渡す方法がわかる

MCP とは

MCP（Model Context Protocol）は、Codex と外部サービスをつなぐための共通の決まりごとです。

Codex は、そのままでは手元のファイルとコマンドしか触れません。社内の文書管理システムにある資料や、チケット管理システムの起票内容は、コピーして貼り付けるしかありませんでした。

MCP サーバーを1つつなぐと、そのサービスに対する操作が Codex の使える手として増えます。

• 文書管理システムから、指定したページを読み取る
• チケット管理システムに、起票する
• 設計ツールから、画面の仕様を取り出す

**「Codex に外部サービスの手を持たせる仕組み」**と考えてください。共通の決まりごとなので、同じ MCP サーバーを Codex でも他の AI ツールでも使えます。

「サーバー」という言葉について

MCP では、つなぎ先のことを MCP サーバーと呼びます。遠くのデータセンターにある機械を指すとは限りません。自分のパソコンの中で動く小さなプログラムも MCP サーバーです。次の「接続方式」で扱います。

プラグイン（6-2）との違い

ここが最も混乱しやすいところです。役割が違います。

	プラグイン（6-2）	MCP（6-4）
何を足すか	Codex 側の道具一式（Skill・設定・チェック）	外部サービスに対する操作
主な向き先	自分の作業手順	自分の外にあるサービス
配布の単位	まとめて1パッケージ	サーバー1つ＝サービス1つ

プラグインは「Codex の使い方」を配るもの、MCP は「つなぎ先」を増やすものです。

ややこしいのは、プラグインの中に MCP サーバーの接続設定が入っていることがある点です。6-2 で「プラグインには外部サービスとの接続設定も含められる」と書いたのは、これを指しています。

つまり両者は対立せず、プラグインが MCP の設定を運んでくる関係になり得ます。それでも「何が増えたのか」を把握するために、MCP そのものの仕組みは知っておいてください。

接続方式は2種類

MCP サーバーへのつなぎ方は、大きく2つです。

型	どこで動くか	イメージ
ローカル型（stdio）	自分のパソコンでサーバーのプログラムが起動する	手元に道具を1つインストールする
リモート型（URL 指定）	提供元のサーバーに接続する	提供元の窓口に問い合わせる

判断の目安です。

• ローカル型：手元のファイルや社内ネットワークを見るもの。自分のパソコンでプログラムが動くので、入れるものの出どころ確認がより重要
• リモート型：提供元が用意した窓口につなぐもの。インストールは不要だが、認証が必要なことが多い

どちらを使うかは、提供元がどちらを用意しているかで決まります。自分で選ぶ場面は多くありません。

codex mcp add で追加する

ターミナルから追加します。

ローカル型（stdio）

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

-- より前が Codex 側の指定（サーバーにつける名前など）、-- より後がサーバーを起動するコマンドです。この区切りを覚えておくと読み解けます。

環境変数を渡す場合

codex mcp add SERVER --env VAR=VALUE -- COMMAND

リモート型（URL 指定）

codex mcp add example --url https://mcp.example.com --oauth-client-id my-client

--url を付けるとリモート型になります。--url の有無で型が決まるのが Codex の書き方です。

config.toml で設定する

コマンドを使わず、設定ファイルに直接書くこともできます。配置先は次のどちらかです。

場所	効く範囲
~/.codex/config.toml	自分の全プロジェクト
プロジェクト直下の .codex/config.toml	そのプロジェクトだけ

ローカル型（stdio）

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

[mcp_servers.context7.env]
MY_ENV_VAR = "MY_ENV_VALUE"

command が起動するプログラム、args がそれに渡す引数です。先ほどの codex mcp add context7 -- npx -y @upstash/context7-mcp と同じ内容を、ファイルに書いた形になります。

リモート型（Streamable HTTP）

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }

command の代わりに url を書くとリモート型になります。

このほか、起動の待ち時間や使う機能の絞り込みを指定するキーもあります。詳細は Codex CLI × MCP のリファレンス を参照してください。

資格情報の渡し方

設定ファイルにトークンを直接書かないでください。config.toml はプロジェクトに置けるファイルであり、そのままだと共有や履歴管理の対象に入り得ます。

Codex は、値そのものではなく「環境変数の名前」を書く方式を用意しています。

書き方	何を指定するか
env_vars = ["LOCAL_TOKEN"]	サーバーに渡したい環境変数の名前の一覧
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"	認証トークンが入っている環境変数の名前
http_headers = { ... }	追加で送るヘッダー（秘密の値は入れない）

# ❌ 悪い例：値を直書きしている
bearer_token = "sk-abc123..."

# ✅ 良い例：値が入っている環境変数の名前を書く
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

**実際の値はパソコン側の環境変数に持たせ、設定ファイルには名前だけを残す。**この分け方を守れば、設定ファイルを共有しても資格情報は漏れません。

リモート型では --oauth-client-id を使った認証もありますが、具体的な認証画面の流れは提供元によって異なるため、つなぎ先の案内に従ってください。

Claude Code との書式の違い

両方を使う場合、書式が違うことを先に知っておくと混乱しません。

	Claude Code	Codex
設定ファイル	.mcp.json（JSON 形式）	config.toml（TOML 形式）
追加コマンド	claude mcp add --transport stdio|http で型を明示する	codex mcp add。--url の有無で型が決まる
資格情報	${VAR} 記法で値を埋め込む	env_vars や bearer_token_env_var で変数名を指定する

やっていることは同じで、書き方だけが違います。「Codex は TOML、値ではなく変数名を書く」と覚えておけば足ります。

Claude Code の設定をそのまま貼り付けても動きません。移すときは書き直してください。

設定は3つの入り口で共有される

Codex の便利な点です。MCP の設定は、CLI・ChatGPT デスクトップアプリ・IDE 拡張で共有されます。

第2章で選んだ入り口が何であれ、**一度つないだサーバーは他の入り口でも使えます。**入り口ごとに設定し直す必要はありません。

裏を返すと、1か所で入れたものは全部に効くということです。次の注意につながります。

安全に使うための注意

**MCP サーバーは外部のプログラムです。**6-2 のプラグインと同じ注意が必要で、外部サービスとつながるぶん、考えることが1つ増えます。

入れる前に提供元を確認する

判定	提供元
✅ つないでよい	サービスの公式が提供しているもの
✅ つないでよい	自分の会社が用意したもの
⚠️ 慎重に	提供元がはっきりしている第三者のもの
❌ 避ける	出どころが分からないもの

とくにローカル型は、**自分のパソコンでそのプログラムが動きます。**6-2 の「道に落ちていた USB メモリ」の話がそのまま当てはまります。

第3章の設定は引き続き効かせる

承認モードとサンドボックス（3-1・3-2）は、MCP を入れたあとも歯止めとして働きます。MCP を入れたから設定を緩める、という順番にしないでください。

MCP でできることが増えるほど、**承認を求められる場面も増えます。**そこで面倒がって承認をすべて省く設定にすると、外部サービスへの操作まで無確認で通ります。

権限は最小から始める

つなぎ先で権限を選べる場合は、読み取りだけから始めてください。

• まず読み取りだけでつなぐ
• 実際に使ってみて、書き込みが要ると分かってから広げる
• 使わなくなったサーバーは外す

3つ目が忘れられがちです。つないだままのサーバーは、権限を持ったまま残ります。

会社のパソコンでは

MCP は社内の情報を外部サービスとやりとりすることがあります。プラグインと同じく、**導入前に会社の情報取り扱い規程を確認してください。**とくにどの範囲のデータがつなぎ先に渡るかは、事前に把握しておく必要があります。

やってみよう

1. 違いを言葉にする：プラグインと MCP の違いを、自分の言葉で1文ずつ書き出してみましょう
2. 候補を挙げる：普段使っているサービスのうち、Codex からつなげたら助かるものを3つ挙げてください
3. 公式提供か調べる：その3つについて、公式が MCP サーバーを出しているかを確認しましょう。出していないものは候補から外します
4. 1つつないでみる：公式提供のものを1つ、練習用のプロジェクトでつないでみてください。権限は読み取りだけにします
5. 設定を読む：~/.codex/config.toml を開き、追加された [mcp_servers.…] の中身を読んでみましょう。トークンの値が直接書かれていないことを確認します
6. 外す：確認できたら外してください。入れる・外すの往復ができれば、以降は気軽に試せます

演習5で「値ではなく変数名が書かれている」ことを目で見ると、資格情報の扱い方が定着します。

まとめ

• MCP は Codex に外部サービスの手を持たせる仕組み。共通の決まりごとなので他の AI ツールでも同じサーバーを使える
• **プラグインは「Codex の使い方」を配るもの、MCP は「つなぎ先」を増やすもの。**プラグインが MCP の設定を運んでくることもある
• 接続方式は2つ。ローカル型（stdio）は自分のパソコンでプログラムが動く、リモート型（URL 指定）は提供元のサーバーにつなぐ
• 追加は codex mcp add。--url の有無で型が決まる
• 設定ファイルは ~/.codex/config.toml かプロジェクト直下の .codex/config.toml。TOML 形式
• 資格情報は直書きしない。env_vars や bearer_token_env_var で変数名だけを書く
• Claude Code は JSON で値を埋め込む方式。書式が違うので移すときは書き直す
• 設定は CLI・デスクトップアプリ・IDE 拡張で共有される
• 提供元を確認してから入れる。権限は読み取りから。使わなくなったら外す
• 第3章の承認モードとサンドボックスは、MCP を入れたあとも緩めない

理解度チェック

Q1. プラグイン（6-2）と MCP の関係として、正しいものはどれでしょう？

1. MCP はプラグインの新しい呼び名で、同じものを指す
2. プラグインは Codex 側の道具一式を配るもの、MCP は外部サービスへのつなぎ先を増やすもの
3. プラグインを入れると MCP は使えなくなる
4. MCP はプラグインより高機能な上位版である

答えを見る

正解：2

役割が違います。プラグインは Skill や設定などの「Codex の使い方」をまとめて配るもの、MCP は文書管理システムや設計ツールといった「外部サービスに対する操作」を増やすものです。両者は対立せず、プラグインの中に MCP サーバーの接続設定が含まれていることもあります。

Q2. config.toml で認証トークンを扱うとき、適切な書き方はどれでしょう？

1. bearer_token = "sk-abc123..." のように値を直接書く
2. bearer_token_env_var = "FIGMA_OAUTH_TOKEN" のように、値が入っている環境変数の名前を書く
3. http_headers にトークンの値をそのまま入れる
4. トークンは設定ファイルに書かないと動かないので、書くしかない

答えを見る

正解：2

config.toml はプロジェクトに置けるファイルなので、共有や履歴管理の対象に入り得ます。実際の値はパソコン側の環境変数に持たせ、設定ファイルには env_vars や bearer_token_env_var で名前だけを書いてください。この分け方なら設定ファイルを共有しても資格情報は漏れません。