CodexのMCP設定は、接続したい仕事を一つ決め、サーバーを登録し、実際に情報を一件取得するところまで確かめると理解しやすくなります。この記事では、OpenAIの公開ドキュメント用MCPを例に、CLIとTOMLの設定、接続・認証・権限の違い、つながらないときの調べ方を説明します。
仕様確認日は2026年10月10日です。ローカルのCodexクライアントを対象にしています。Webのプラグイン経由で使うツールは、ローカル設定と同じ操作ではありません。業務上の確認表・依頼文は編集部が設計した例です。
MCPで何が変わる？最初に一つの仕事を決める
MCPは、AIから情報源やツールを利用するための接続規格です。Codexが利用できる操作は、接続先が提供する機能と、そのアカウントに許可された範囲で決まります。ドキュメント検索ができる接続先を追加しても、それだけで顧客管理システムを更新できるようにはなりません。
最初に作るとよいのは、サーバーのおすすめ一覧ではなく、次のような小さな導入メモです。名前のよく知られたサーバーでも、必要な仕事と一致しなければ追加する理由はありません。
やりたいこと：OpenAIの公式仕様を調べ、出典付きで回答する
必要な情報：CodexのAGENTS.mdの探索順
接続先：OpenAI Docs MCP
初回の操作：検索し、該当ページ本文を読む
成功の条件：回答内容と参照URLを公式ページで照合できる
今回の範囲：読み取りのみ。ローカルファイルは変更しない手元の資料だけで終わる仕事なら、外部接続を増やす前にローカルファイルで試せます。一方、更新される製品仕様や、権限のある業務サービス内の情報を使いたい場合はMCPが候補になります。接続できることと、仕事に必要であることを分けて考えましょう。
STDIOとStreamable HTTPの違い
ローカルのCodexが扱う代表的な接続方式は、コマンドでサーバーを起動するSTDIOと、URLへ接続するStreamable HTTPです。提供元の公式手順に合わせて選びます。公式：CodexのMCP対応
| 比較項目 | STDIO | Streamable HTTP |
|---|---|---|
| 主な設定 | 起動するコマンドと引数 | サーバーのURL |
| 最初に確かめるもの | コマンドの存在、必要な実行環境、作業場所 | 公式エンドポイント、ネットワーク、認証方式 |
| 失敗の例 | 実行ファイルが見つからない、起動直後に終了する | URL違い、認証待ち、アクセス範囲不足 |
| 今回の教材 | 比較のみ。追加のプログラムを導入しない | 公開ドキュメント用MCPで設定例を示す |
「ローカル」と書いてあっても、Codexを実行しているコンピューターが自分の操作端末と同じとは限りません。リモート開発環境を使っている場合は、どのホストでコマンドが実行され、どの設定ファイルを読むかを先に確認します。
設定する前に確認する5項目
- 提供元：検索結果のコマンドをそのまま実行せず、提供元の公式ページで配布元と接続先を確認する。
- 対象の仕事：検索・作成・更新・送信のどこまで必要かを決める。
- アカウント：個人用と会社用、利用する組織・ワークスペースを区別する。
- 設定範囲：個人共通か、そのプロジェクトだけかを選ぶ。
- 成功条件：何を取得し、どの内容を照合すれば使えると判断できるかを決める。
たとえば文書検索に失敗したとき、共有されていない文書なのか、別組織へ接続しているのか、検索条件が違うのかを分けて確認できるよう、最初は既知のテスト文書を一つ選ぶと切り分けやすくなります。
設定場所と、コピーできる最小TOML
通常の個人用設定は~/.codex/config.toml、信頼済みプロジェクト用は.codex/config.tomlです。同じCodexホストのローカルクライアント間で設定を共有する構成と、Web上のプラグインは区別します。設定範囲の公式説明
OpenAI Docs MCPの最小設定は次の2行です。既存のconfig.toml全体をこの内容で置き換えず、同名のサーバーが既にあるかを確認してから追加します。ファイル内に同じテーブルを二重に定義しないようにしてください。
[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"この接続先は公開ドキュメントの検索・本文取得用です。OpenAI APIを利用者の代わりに呼び出すサーバーではありません。公式：Docs MCPの提供範囲と設定例
手動で編集する場合は、変更前の設定を保存しておきます。設定場所を変更している環境では、標準パスと実際の保存先が異なることがあります。自分が開いているクライアントの設定を確認し、別環境のファイルを編集していないか確かめてください。
実例：OpenAI Docs MCPを追加して一件読む
1. CLIの存在を確認し、サーバーを追加する
ターミナルでcodex --versionが実行できることを確認します。コマンドが見つからない場合は、先にCodexのインストール手順を確認してください。次の追加コマンドは、既に手動で同名の設定を作成した場合には重ねて実行する必要はありません。
codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp
codex mcp list追加前にもcodex mcp listを確認し、同名の接続が既にあれば登録内容を確認して使います。一覧に表示された段階で確認できたのは、登録が存在することです。目的の情報を取得できるかは、次の段階で確かめます。この記事の作成時には、使用環境のcodex mcp add --helpでも--urlの構文を確認しています。
2. Codex内の接続状態を確認する
新しいCodexセッションを開き、入力欄で/mcpを使って対象サーバーの状態を見ます。エラーがある場合は、その文言を記録してください。「一覧にあるが起動できない」と「一覧にもない」では、調べる順番が変わります。
3. 情報源を指定して、検索と本文取得を依頼する
OpenAI Docs MCPを使って、CodexのAGENTS.mdの探索順を調べてください。
検索結果の見出しだけで判断せず、該当ページの本文を確認してください。
回答には根拠となる公式ページのURLを付けてください。
ローカルファイルは変更しないでください。期待するのは、公式ページに対応する説明と参照URLです。ツールが使われたか確認できる画面では、検索・本文取得の記録も見ます。通常の回答が返っただけでは、MCPを利用したことまでは証明できません。
4. 参照URLを開き、回答した箇所を照合する
返されたページで、説明された探索順や例外を探します。質問と無関係な一般トップページだけが示された場合や、ページに書かれていない仕様を断定した場合は、再確認が必要です。ここまでできれば、この題材に対する「情報取得と照合」の確認になります。
編集部は公開MCPへの初期接続、ツール一覧取得、AGENTS.mdに関する検索と本文取得を読み取り専用の検証プログラムで確認しました。Codexの対話セッションから同じ依頼を実行した検証とは別です。読者のアカウントや端末での接続成功を保証するものではありません。
認証が必要なMCPで、設定とログインを分ける
業務サービスでは、サーバーの登録後にログインが必要になることがあります。OAuth対応サーバーなら、提供元の案内に従ってcodex mcp login サーバー名を使います。トークン方式なら、指定された環境変数や認証設定を利用します。方式を推測して混ぜないでください。
次の表は、接続先が業務文書サービスだった場合の確認例です。架空の組織名を使っています。
| 確認すること | 確認例 | 不足している場合 |
|---|---|---|
| ログイン先 | 仕事用アカウントで接続している | 別アカウントでの結果を正しい対象と扱わない |
| 組織 | 「練習会社」ワークスペースを開いている | 同名の文書があっても組織を照合する |
| 共有範囲 | テスト文書1件をそのアカウントが読める | 文書の存在と共有権限を別に調べる |
| 操作権限 | 読むだけか、更新も可能かを把握している | 読み取り成功を更新許可と解釈しない |
Bearerトークンを参照する設定では、bearer_token_env_varに入れるのは環境変数の名前です。例としてEXAMPLE_MCP_TOKENのような名前を指定しますが、実際の値を記事や共有用設定へ貼り付ける必要はありません。環境変数を利用する場合でも、その値が対象のCodex実行環境へ渡っているかは別途確認が必要です。
接続後の確認は、操作の影響に合わせて変える
同じ「成功」でも、検索と送信では確認すべきものが違います。以下は実務に合わせた確認手順の例です。MCPの規格が業務上の承認や結果照合を代行するわけではありません。
情報を読む：対象と内容を照合する
まず既知の文書を一件読みます。タイトルだけでなく、文書のURL・組織・本文の一部が想定と一致するかを確かめます。検索で出なかった場合は、「存在しない」と即断せず、検索語・権限・対象範囲を調べてください。
文書を更新する：差分と保存後の内容を確認する
更新対象の文書と変更箇所を固定し、更新前の内容を残します。実行後に同じ文書を読み直し、変更した箇所と残すべき箇所を照合します。別名の文書を新規作成しただけなら、「元文書を更新した」とは扱いません。
メッセージを送る：宛先と送信後の状態を確認する
送信前に宛先・スレッド・本文を確認し、必要な承認を得ます。送信後はサービス側の送信済み状態を確認します。通信が切れて結果が不明なときは、先に履歴を照合し、送れていないと決めつけて再送しないでください。
業務の完了：ツールの成功だけで判断しない
たとえば「報告書を担当者へ届ける」仕事なら、ファイル作成だけでは終わりません。保存場所へのアクセス、共有先、必要な受領確認まで、依頼の範囲に応じて結果を確かめます。完了条件をSkillや依頼文に記載すると、毎回の確認を揃えやすくなります。
つながらないときの症状別チェック
| 症状 | 最初の確認 | 次の一手 |
|---|---|---|
| 一覧に出ない | 編集した設定ファイル、対象ホスト、同名設定、プロジェクトの信頼状態 | 使う環境で登録先を確認し、新しいセッションで読む |
| 設定の構文エラー | エラーが示す行、引用符、重複したテーブル | 変更前との差分を見て、追加部分から直す |
| STDIOが起動しない | コマンドがその実行環境にあるか、起動ログ、作業ディレクトリ | 提供元の前提条件を確認する |
| HTTPの404 | 公式エンドポイントと入力URL | 古いURLや一般WebページのURLを指定していないか確認する |
| 認証エラー | 提供元の認証方式、アカウント、認証の有効性 | 公式手順で認証する。秘密値をログへ出さない |
| 接続済みだが目的の文書が見えない | 組織、共有権限、検索範囲 | 既知のテスト文書を一件指定して確かめる |
| タイムアウト | 起動時かツール実行中か、毎回同じ箇所か | 先に処理とログを確認する。待ち時間を延ばすだけで原因を消さない |
| 別の端末では使えない | 設定があるホストと、今使っているホスト | 設定・認証・必要な実行環境を個別に確認する |
タイムアウトは、サーバーの起動待ちと一回のツール実行待ちで設定項目が異なります。調整する場合は、どちらが失敗したかを確認してから公式の設定項目を参照してください。権限不足や存在しないコマンドは、待ち時間を伸ばしても直りません。
エラーの相談時には、OS、Codexのバージョン、接続方式、サーバー名、発生した段階、秘密値を除いたエラー文をまとめると伝わります。設定ファイル全体を無加工で公開せず、認証値や社内URLを除いた必要部分だけを使いましょう。
設定を引き継ぐときのチェックシート
接続先の公式ページ：
接続方式：STDIO / Streamable HTTP
設定の範囲：個人 / プロジェクト
実行するホスト：
利用するアカウント・組織：
必要なツールと操作範囲：
秘密値の管理方法（値は記載しない）：
初回に読むテスト文書：
取得内容を照合する方法：
更新・送信の確認方法：
接続を止める場合の担当と手順：
確認日・利用環境：設定だけを渡すと、認証や対象組織が抜け落ちやすくなります。接続情報と、業務上の手順を分けて管理し、繰り返す仕事はSkillsへまとめます。共通の完了条件や保存ルールはAGENTS.mdへ整理できます。
よくある質問
MCPを追加すれば、外部サービスも無料で使えますか？
MCPという接続方式と、各サービスの利用条件は別です。サービス側の契約・API利用料・制限がある場合は、その提供元で確認します。公開ドキュメントを読む教材例から、ほかのサービスの料金を推測しないでください。
Webとローカルで同じ設定を使えますか？
利用する画面と実行環境によります。Webのプラグインと、ローカルのconfig.tomlを同じものとして扱わず、それぞれの利用画面の公式手順を確認してください。
最初から複数のサーバーを入れるべきですか？
まず一つの仕事に必要な接続で、取得から照合まで試すと問題を切り分けやすくなります。複数必要になったら、同じ情報をどこから読むか、どのツールが更新するかを決めて追加します。
使わなくなった接続はどう扱いますか？
設定を無効化する場合と、サービス側の認証を取り消す場合は別の操作です。停止する目的を決め、Codex側の設定と提供元の接続管理をそれぞれ確認します。共有環境では、利用中の仕事がないかも確認してください。
