第1回 CodexとMCPを理解する
はじめに
本シリーズ「VS Code + Pythonで学ぶCodexとMCP入門」は、本編・全3回を通じて、Codexを「仕組みを理解する → 公開サーバーを使う → 実務で連携する」という流れで学ぶ構成となっています。
Codexは、単にコードを提案するだけのツールではなく、プロジェクトのファイルを読み、コードを書き換え、ターミナルコマンドを実行するところまで一貫して行う「コーディングエージェント」です。本シリーズでは、MCP（Model Context Protocol）を通じてCodexを外部ツールと連携させる仕組みを理解し、公開されているMCP Serverを使い、最終的にGitHubなどと連携した実践的な開発まで、段階的に発展させていきます。さらに発展編では、Pythonで独自のMCP Serverを自作する方法も扱います。
前提となる記事: 本シリーズは、Codex単体の基本的な使い方（インストール・サインイン・Pythonコードの作成/実行/修正）を理解していることを前提にしています。まだの方は、先に以下の記事をご覧ください。
シリーズ全体の構成
| 回 | テーマ |
|---|---|
| 第1回 | CodexとMCPを理解する（本記事） |
| 第2回 | 公開されているMCP ServerをCodexから使ってみる |
| 第3回 | Codex + MCPで外部サービスと連携してみる |
| 発展編 | PythonでMCP Serverを作ってCodexから使ってみる |
本シリーズは、すべて自分のPC（ローカル）だけで進められます。サーバー契約などの追加インフラ費用はかかりません。
シリーズ全体の学習範囲は以下の通りです。
VS Code + PythonでCodex×MCP
│
├─【本編】
│ ├─ 第1回 MCPを理解する
│ │ ├─ CodexとMCPの関係
│ │ ├─ MCPとは
│ │ ├─ MCP Server
│ │ └─ MCPあり・なしの違い
│ │
│ ├─ 第2回 公開MCP Serverを使う
│ │ ├─ 公式Reference Servers
│ │ ├─ GitHub公式MCP Server
│ │ └─ Codexへの登録
│ │
│ └─ 第3回 外部サービスと連携する
│ ├─ GitHubなど外部連携
│ ├─ 情報取得
│ ├─ Pythonコード修正
│ └─ テスト
│
└─【発展編】MCP Serverを作る
├─ PythonでMCP Server作成
├─ Tool作成
├─ Codexへ登録
└─ Tool実行
第1回となる本記事では、Codexが自分のPCの外にある外部ツールやサービスとどうやってつながるのか、その仕組みであるMCP（Model Context Protocol）を理解します。
改めて確認すると、Codexは、単にコードを提案するだけのツールではなく、プロジェクト内のファイルを読み取り、コードの作成・修正、さらにターミナルコマンドの実行まで一連の開発作業を行える「コーディングエージェント」です。
例えば、VS CodeでPythonプロジェクトを開いている状態で、
このPythonコードのバグを調べて修正してください
とCodexに依頼すると、Codexはプロジェクト内のPythonファイルを確認し、問題のあるコードを特定して修正できます。さらに、修正後にPythonプログラムやテストを実行し、正しく動作するか確認するところまで進めることができます。
ユーザー
│
│「このPythonコードのバグを修正して」
↓
Codex
│
├─ プロジェクトのファイルを確認
├─ バグの原因を調査
├─ Pythonコードを修正
└─ プログラムやテストを実行
このように、手元のPythonプロジェクトを扱うだけであれば、Codex単体でも多くの開発作業を行えます。
一方、実際の開発では、プロジェクト内のファイルだけではなく、外部にある情報やサービスを利用したい場面もあります。例えば、
- GitHubに登録されているIssueの内容を取得する
- データベースから必要な情報を検索する
- 社内システムや外部APIから情報を取得する
といったケースです。
そこで登場するのが MCP（Model Context Protocol） です。MCPを利用すると、CodexからMCP Serverが提供するツールやデータへアクセスできるようになり、外部の情報を開発作業に組み込めます。
例えば、
GitHubのIssue #12の内容を確認し、その内容に沿ってPythonコードを修正してください
といった作業を考えると、次のような流れになります。
本シリーズでは、まずMCPを使ってCodexと外部ツールを連携させる仕組みを理解し（本記事）、次に公開されているMCP Serverを使ってみて、最終的にはGitHubなどと連携した実践的な開発まで進みます。
「Codexを使う」だけで終わるのではなく、
MCPを理解する → 公開サーバーを使う → 外部サービスと連携する
という流れで、段階的にCodexとMCPの活用方法を学んでいきます。さらに深めたい方は、発展編で自分専用のMCP Serverを作る方法も扱います。
第1回となる本記事は、この中の「MCPを理解する」にあたる部分を扱います。本記事は概念の理解が中心です。実際に手を動かして公開MCP Serverを使うのは第2回で行いますので、まずは「MCPとは何か」「なぜ必要か」をつかんでいきましょう。
補足: 本記事の内容は執筆時点の情報にもとづいています。Codexは更新が速いため、最新のMCP対応状況や設定方法はOpenAI公式のCodex MCPドキュメントで確認してください。
この記事のゴール
本記事では、CodexとMCPの関係を理解し、外部ツールとつながる仕組みを説明できるようになることを学習します。
最終的には、
「Codexが外部ツールを使えるのはMCPのおかげ」「MCP Serverがツールの提供元」という関係を、人に説明できるようになる
ところをゴールにします。
1-1. Codex単体でできること
前提記事で学んだとおり、Codexは次のようなことができました。
Codex
├─ プロジェクトのファイルを読む
├─ コードを書き換える
└─ ターミナルコマンドを実行する
これらはすべて、自分のPC（ローカル）の中での作業です。Codexは「手元のフォルダを触るのは得意」なのです。
しかし実際の開発では、次のような「PCの外」の情報や操作も必要になります。
- GitHubのIssueやPull Requestの情報を取得したい
- データベースの内容を検索したい
- 社内ドキュメントやAPIの仕様を参照したい
- 外部サービスへ操作を反映したい
こうした「PCの外とのやり取り」を、Codexはどうやって実現しているのでしょうか。その答えがMCPです。
1-2. MCPとは
MCP（Model Context Protocol）とは、AI（Codexなどのモデル）と、外部のツールやデータをつなぐための共通ルール（プロトコル）です。
イメージしやすいたとえとして、MCPはよく「AIのためのUSB-C」と説明されます。USB-Cという共通規格があるおかげで、メーカーの違うPC・スマホ・周辺機器が1本のケーブルでつながります。MCPも同じで、共通の規格を決めておくことで、どのAIからでも、どの外部ツールへでも同じ方法でつなげるようにするものです。
MCPがない世界では、「Codex専用のGitHub連携」「Codex専用のデータベース連携」…と、AIとツールの組み合わせごとに専用のつなぎこみが必要でした。MCPという共通規格ができたことで、その手間が大きく減りました。
| MCPがない場合 | MCPがある場合 | |
|---|---|---|
| つなぎ方 | ツールごとに専用実装が必要 | 共通の規格で統一 |
| 再利用 | 他のAIでは使い回せない | MCP対応なら使い回せる |
| 追加のしやすさ | 増やすほど複雑になる | サーバーを追加するだけ |
MCPはCodex専用ではありません
MCPは、OpenAIやCodexだけのための規格ではなく、オープンな標準（公開仕様）です。CodexのようなMCP対応のクライアント／ホストであれば、同じMCP Serverに接続できます。公式SDKも「任意のMCPホスト（any MCP host）」とつなげられるものとして説明されています。つまり、一度作ったMCP Serverは、Codex以外のMCP対応ツールからも使い回せる、ということです。
1-3. CodexとMCPの関係（ClientとServer）
MCPには、大きく2つの役割があります。
| 役割 | 担当 | 説明 |
|---|---|---|
| MCP Client（クライアント） | Codex | ツールを「使う」側 |
| MCP Server（サーバー） | 外部ツール提供側 | ツールを「提供する」側 |
Codexは、MCP Clientとして振る舞います。つまりCodexは「ツールを使う側」です。一方、GitHubやデータベース、あるいは自分で作ったプログラムは、MCP Serverとしてツールを提供する側になります。
両者の関係を図にすると、次のようになります。
ここで大切なのは、MCPは Codex と MCP Server の「間に存在するサーバーやソフトウェア」ではないという点です。MCPは、両者がやり取りするための**通信の共通ルール（プロトコル）です。
CodexはMCP Serverに対して「どんなツールが使える？」と尋ね、返ってきたツールを必要に応じて呼び出します。CodexはMCP Serverの中身（どう実装されているか）を知る必要はなく、MCPという共通ルールに従ってやり取りするだけです。
1-4. MCP Serverとは
MCP Serverは、Codexに対して「使えるツール（機能）」を提供するプログラムです。ここでいう「ツール」とは、Codexが呼び出せる関数のようなものだと考えてください。
例えば、GitHub用のMCP Serverなら、次のようなツールを提供します。
GitHub MCP Server
├─ Issueを検索するツール
├─ Pull Requestを取得するツール
└─ リポジトリ情報を取得するツール
Codexは会話の中で「このIssueの内容を教えて」と頼まれると、GitHub MCP Serverの「Issueを検索するツール」を呼び出し、その結果を使って回答します。ツールの実体（GitHubへのアクセス処理）はMCP Server側にあるため、Codex自身はGitHubの細かい仕様を知らなくてよいのです。
MCP Serverは必ず自作するものではない
MCP Serverを使うには、次の2つの方法があります。
| 方法 | 説明 | 例 |
|---|---|---|
| 既存のMCP Serverを利用する | 公開されているサーバーをそのまま接続する | GitHub / ファイルシステム用など（第2回で使用） |
| 自分でMCP Serverを作る | Pythonなどで独自のツールを実装する | 発展編で自作 |
つまり、MCP Serverは必ずしも自分で作る必要はありません。すでに公開されている便利なMCP Serverをつなぐだけでも、Codexの能力を広げられます。本シリーズの本編では、公開されているMCP Serverを使うことを中心に扱います（第2回・第3回）。そのうえで、公開サーバーにない自分専用の機能がほしくなったら、発展編でPythonを使って自分でMCP Serverを作る方法に進めます。
代表的な公開MCP Server
「既存のサーバーを使う」といっても、どんなものがあるのかイメージしにくいかもしれません。ここでは、開発でよく使われる代表的な公開MCP Serverを紹介します。
| MCP Server | できること | 主な用途 |
|---|---|---|
| Filesystem（ファイルシステム） | 指定フォルダのファイル読み書き | ローカルファイルの参照・編集 |
| GitHub | Issue・Pull Request・リポジトリの操作 | コードレビュー、Issue確認（第2回・第3回で使用） |
| Git | コミット履歴や差分の参照 | 変更内容の調査 |
| Fetch | Webコンテンツを取得してAIが扱いやすい形にする | ドキュメント参照 |
| Memory | Knowledge Graph形式で情報を保持 | 情報の記憶 |
これらの多くは、MCPを策定しているグループが公開しているリファレンス実装や、各サービスの公式が提供しているものです。まずは自分の開発でよく使うサービス（多くの場合はGitHubやFilesystem）から試すのがおすすめです。具体的な使い方は第2回で詳しく扱います。
補足: 公開されているMCP Serverは、公式のMCP Registryや、リファレンス実装をまとめたmodelcontextprotocol/servers リポジトリから探せます。新しいサーバーが次々に増えているため、最新の一覧はこれらで確認してください。なお、接続するサーバーは提供元が信頼できるものを選ぶことが大切です（詳しくは1-7で触れます）。
MCP Serverは必ずインターネット上に置くものではない
もう一つ大切なのが、MCP Serverは必ずしもインターネット上に置く必要はないという点です。自分のPC（ローカル）上でも動かせます。MCP Serverには、動く場所と通信方式によって、大きく2つの形があります。
| 種類 | 動く場所 | 主な通信方式 | 例 |
|---|---|---|---|
| ローカルMCP Server | 自分のPC上 | stdio（標準入出力） | 自作のPythonサーバー（発展編） |
| リモートMCP Server | インターネット上 | Streamable HTTP | クラウドに公開されたサーバー（GitHub公式など） |
ローカルで動かす場合は、Codexとサーバーが同じPC内にいるため、stdio（標準入出力）を通じてやり取りします。一方、インターネット越しに使う場合は、Streamable HTTPという通信方式でやり取りします。現在の公式SDKも、この2つを標準の通信方式（Transport）として扱っています。ここでは「近くならstdio、遠くならHTTP」というイメージだけ持っておけば十分です。
本シリーズの本編では、公開されているMCP Server（GitHub公式など）を使うことを中心に扱います。いずれもサーバー契約は不要で、追加インフラ費用もかかりません。発展編では、ローカルPC上に自分でMCP Serverを作る方法にも進みます。
1-5. MCPなし・ありの違い
MCPの価値を、具体的なシーンで比べてみましょう。「GitHubのあるIssueの内容を踏まえてPythonコードを直したい」というケースを考えます。
MCPを使わない場合
MCP以外にも、外部と連携する方法はあります（API、CLI、Codexの組み込みツールなど）。ただ、手軽なMCPなしのやり方としては、次のように人間が手で情報を運ぶケースがあります。
① 自分でGitHubを開く
② Issueの内容をコピーする
③ Codexのチャットに貼り付ける
④ 「この内容を踏まえて直して」と頼む
参照先が変わったりIssueが増えたりするたびに、このコピー＆ペーストの手作業が発生します。
MCPがある場合
① 「Issue #12 を踏まえて直して」と頼むだけ
↓
② Codexが GitHub MCP Server の「Issue取得ツール」を呼び出す
↓
③ MCP Server が GitHub API へアクセスして内容を取得
↓
④ MCP Server が結果をCodexへ返す
↓
⑤ Codexがその内容を踏まえてコードを直す
ここで正確に押さえておきたいのは、Codex自身が直接GitHubへアクセスするわけではないという点です。Codexが行うのは「MCP ServerのToolを呼び出す」ことで、実際にGitHub APIへアクセスするのはMCP Serverです。取得結果がCodexに返され、それを踏まえて回答・修正が行われます（この流れは第3回で実際に体験します）。
いずれにせよ、情報取得のきっかけをCodexへの一言の依頼にまとめられるため、人間はコピー＆ペーストの手間から解放されます。これがMCPの大きな恩恵です。
両者を並べると、違いがはっきりします（ここでの「MCPなし」は、手でコピー＆ペーストする単純なケースを指します）。
| 観点 | MCPなし（手作業の場合） | MCPあり |
|---|---|---|
| 情報の取得 | 人間が手動でコピー | Codexの依頼でMCP Serverが取得 |
| 手間 | 参照のたびに発生 | 一度つなげば繰り返し使える |
| ミス | コピー漏れ・貼り忘れ | 起きにくい |
| 対象の広さ | チャットに貼れる範囲 | サーバーが提供する範囲すべて |
1-6. CodexにMCP Serverをつなぐイメージ
実際の接続手順は第2回で扱いますが、ここでは全体のイメージだけ押さえておきましょう。
CodexにMCP Serverをつなぐと、Codexは起動時にそのサーバーへ接続し、「使えるツールの一覧」を受け取ります。
Codex 起動
↓
設定されたMCP Serverへ接続
↓
「どんなツールがある？」と問い合わせ
↓
ツール一覧を受け取る
↓
会話中に必要なツールを呼び出す
Codex CLIでは、MCP Serverの登録状況を確認するためのサブコマンドが用意されています（詳細な設定は第2回で解説します）。
codex mcp list
このように、MCP Serverを1つ追加すれば、そのサーバーが持つツールがまとめてCodexから使えるようになる、というのがMCPの仕組みです。
1-7. MCPを使うときの注意点
MCPは強力な仕組みですが、外部とつながる以上、セキュリティ面の配慮が欠かせません。学習段階から意識しておきましょう。
- 信頼できるサーバーだけにつなぐ: MCP Serverは、あなたの環境や認証情報にアクセスできる場合があります。提供元が信頼できるサーバーだけを接続しましょう。
- 最小限の権限にする: サーバーに渡す認証情報（トークンなど）は、必要最小限の権限にとどめます。
-
認証情報の扱いに注意する: トークンやAPIキーはURLに直接埋め込まず、ヘッダーや設定の適切な場所に保存します。
.envなどで管理し、公開リポジトリに含めないようにします。 - 重要な操作は承認を挟む: ファイルの変更や外部への書き込みなど、影響の大きい操作は、実行前に承認を求める設定にしておくと安全です。
これらは第2回・第3回で公開サーバー（GitHubなど）を扱う際に、あらためて具体的に触れます。
まとめ
本記事では、CodexとMCPの関係を、次のように整理しました。
| 項目 | ポイント |
|---|---|
| MCPとは | AIと外部ツールをつなぐ共通ルール（プロトコル）。AIのUSB-C |
| MCPの正体 | MCP自体はプログラムではなく「通信のルール」。CodexとMCP Serverの間に立つ別のサーバーがあるわけではない |
| オープン標準 | Codex専用ではなく、MCP対応クライアントなら使える |
| Codexの役割 | MCP Client（ツールを使う側） |
| MCP Serverの役割 | ツールを提供する側（GitHub・DB・自作サーバーなど） |
| 自作は必須ではない | 既存サーバー利用と自作の両方がある（本シリーズは学習のため自作） |
| 置き場所 | ローカル（stdio）でもリモート（Streamable HTTP）でも動く |
| MCPなし | 単純なケースでは人間が手でコピー＆ペーストすることもある |
| MCPあり | Codexの依頼でMCP Serverが情報を取得して返す |
| 注意点 | 信頼できるサーバー・最小権限・認証情報の管理 |
CodexとMCPの関係を図で振り返ります。MCPは両者をつなぐ「共通ルール」であって、間に立つ別のサーバーではない点に注意してください。
Codex（MCP Client：使う側） ──── MCP ──── MCP Server（提供する側）
（共通ルール） │
↓
外部サービス・データ
第1回では、Codexが外部ツールとつながる仕組みである「MCP」を理解しました。「Codexはツールを使う側（Client）、MCP Serverはツールを提供する側」という関係がつかめれば十分です。
次回はいよいよ、実際に手を動かします。第2回では、すでに公開されているMCP Server（GitHub公式など）をCodexに登録し、使ってみます。自分でサーバーを作らなくても、登録するだけでCodexの能力が広がることを体験しましょう。
本シリーズの記事一覧は以下の通りです。
- 【第1回】VS Code + Pythonで学ぶCodexとMCP入門 〜CodexはどうやってMCPで外部ツールとつながるのか〜
- 【第2回】GitHub公式MCP ServerをCodexから使ってみる 〜公開MCP Serverの基本〜
- 【第3回】Codex + MCPで外部サービスと連携してみる
- 【発展編】PythonでMCP Serverを作ってCodexから使ってみる
ぜひシリーズを通して、MCPを「理解する」段階から「使い・実務で連携する」段階まで身につけていきましょう。