CodexでMCP連携を設定する方法｜社内ツールをAI開発に接続する手順

本記事を読めば、CodexにMCPサーバーを接続できるようになり、Figma・ドキュメント・社内ツールを開発作業の文脈に取り込めます。

MCP連携は便利ですが、接続先の権限や認証情報を整理しないまま広げると、確認範囲が曖昧になります。AIzen株式会社は、AIエージェント開発と業務システム連携の支援を通じて、参照系から安全に始める導入設計を重視しています。

本記事では、CodexでMCPを使う仕組み、設定方法、社内ツール別の活用、権限管理までを解説します。

CodexでMCP連携を使う仕組み

MCPはModel Context Protocolの略で、AIが外部ツールや外部情報へアクセスするための共通プロトコルです。Codexでは、MCPサーバーを設定することで、ドキュメント検索、デザイン参照、GitHub操作、社内ナレッジ検索などを作業文脈に加えられます。

ただし、MCPは「接続すれば何でも安全に任せられる仕組み」ではありません。公式情報では、CodexのMCP対応はCLIとIDE extensionを中心に説明されています。2026年6月時点では、利用するCodexの画面や組織設定によって導入手順が異なる場合があります。

MCPサーバーで追加できるツール

MCPサーバーは、Codexに追加のツールや情報源を提供します。たとえばOpenAI Docs MCPなら公式ドキュメントを検索・参照でき、Figma MCPならデザイン情報を確認でき、GitHub MCPならissueやPRの情報を扱いやすくなります。

実務では、まず「参照するだけ」のツールから始めるのが安全です。公式ドキュメント検索、社内FAQ検索、デザイン読み取りのような用途であれば、更新操作を伴わずに効果を確認できます。更新系ツールは、承認ルールを設計してから広げることがMCP連携の基本です。

CLI・IDEで共有するconfig.toml

CodexのMCP設定は、公式情報では config.toml に保存されます。標準では ~/.codex/config.toml を使い、信頼済みプロジェクトではプロジェクト単位の .codex/config.toml も使えます。CLIとIDE extensionはこの設定を共有できるため、同じMCPサーバーを複数の作業画面で使いやすくなります。

ただし、すべてのCodex環境で同じように使えるとは限りません。チーム導入では、誰の端末に置く設定か、プロジェクトに含める設定か、認証情報を環境変数で渡すかを分けて考えます。config.tomlには接続設定、秘密情報は環境変数や認証基盤へ分けるのが基本です。

社内ツール連携で広がる作業範囲

MCP連携により、Codexはコードだけでなく、仕様書、UIデザイン、運用手順、問い合わせ履歴などを参照しながら作業できます。これにより「仕様を別画面で探してからプロンプトに貼る」手間が減り、開発者は判断とレビューに集中できます。

一方で、社内ツールを接続するほど、AIが見られる情報の範囲も広がります。全社ナレッジを一気に接続するのではなく、最初は開発プロジェクトに必要なフォルダ、チャンネル、データベースに限定します。社内規程、個人情報、顧客情報を含む領域は、閲覧権限とログ管理を先に整えます。

CodexにMCPサーバーを接続する方法

CodexにMCPサーバーを接続する方法は、大きくSTDIOサーバーとStreamable HTTPサーバーに分かれます。ローカルで起動する開発者向けツールならSTDIO、社内やクラウドで提供する共通サービスならHTTPが候補になります。

設定前に、接続目的、認証方法、利用者、許可するツール、更新操作の有無を決めます。技術的に接続できることと、社内運用として許可できることは別です。

STDIOサーバーの設定

STDIOサーバーは、Codexがローカルコマンドとして起動するMCPサーバーです。公式ドキュメントの例では、codex mcp add コマンドでサーバー名、起動コマンド、引数、環境変数を設定できます。Node.js製のMCPサーバーであれば、npx を使って起動する構成もあります。

STDIOはローカル開発環境との相性がよく、Figmaのローカル連携、ブラウザ検証、社内CLIラッパーなどに向いています。ただし、実行者の端末権限で動くため、環境変数、作業ディレクトリ、ログ出力の扱いを確認します。個人端末ごとに設定差が出る点にも注意が必要です。

HTTPサーバーと認証方式

HTTPサーバーは、URLでアクセスするMCPサーバーです。Codexの設定では、サーバーURLに加えて、Bearer token用の環境変数やHTTPヘッダーを指定できます。OAuthに対応するサーバーでは、ログインフローを使う構成もあります。

HTTP型は、社内共通のナレッジ検索や承認済みAPIへの接続に向いています。チーム全体で同じサーバーを使える一方、公開範囲、認証、通信経路、監査ログの設計が重要です。社内MCPを作る場合は、ユーザーごとの権限をMCPサーバー側でも判定し、Codex側の設定だけに依存しない構成にします。

接続後の動作確認

接続後は、/mcp などの確認機能や、簡単な参照タスクでサーバーが認識されているかを確認します。最初から更新操作を試すのではなく、「公式ドキュメントを検索して要約する」「Figmaファイル名を確認する」「社内FAQから該当ページを探す」のような参照系で試します。

確認時は、期待するツールだけが見えているか、不要なツールが公開されていないか、タイムアウトや認証エラーが起きないかを見ます。MCPサーバーの起動ログやCodex側のエラーを残しておくと、チーム展開時のトラブル対応が楽になります。

社内ツール別のMCP連携パターン

MCP連携は、接続先ツールごとに設計が変わります。公式ドキュメントの参照、FigmaやGitHubの開発補助、社内ナレッジ検索では、必要な権限も確認手順も異なります。

最初にすべてを接続するのではなく、開発作業で使う頻度、情報の機密度、更新操作の有無で優先順位を決めます。参照系で効果を確認してから、承認付きの更新系へ広げる流れが現実的です。

OpenAI Docs MCPの公式情報参照

OpenAI Docs MCPは、OpenAIの公式開発ドキュメントを検索・参照する用途に向いています。Codex関連やAPI仕様のように更新が多い情報は、記憶や過去のメモではなく、公式情報を確認してから実装判断するべきです。

ただし、OpenAI Docs MCPはドキュメント参照用であり、OpenAI APIの代理実行やアカウント操作をするものではありません。記事作成や実装支援では、機能名、設定項目、提供条件の断定を避け、公式情報を確認したうえで表現します。

Figma・GitHub連携の開発補助

Figma連携では、デザインの構造、コンポーネント、余白、文言をCodexが参照し、UI実装の材料にできます。GitHub連携では、issue、PR、レビューコメントを読み、修正範囲や確認観点を整理できます。

連携先	主な用途	初期導入で確認すること
Figma	デザイン参照、UI実装補助	閲覧権限、対象ファイル、デザイン更新の頻度
GitHub	issue・PR確認、レビュー支援	リポジトリ権限、コメント権限、ブランチ保護
Docs MCP	公式仕様確認	参照対象、回答に使う範囲、引用ルール
社内検索	FAQ・仕様書参照	インデックス範囲、閲覧権限、機密情報

FigmaやGitHubは開発効率に直結しますが、更新権限を持つ場合は承認フローが必要です。最初は読み取り中心にし、コメント投稿やファイル変更は人の確認を挟む運用にします。

社内ナレッジ検索用MCP

社内ナレッジ検索用MCPは、仕様書、議事録、問い合わせ履歴、運用手順をCodexから参照できるようにする構成です。開発者が仕様確認のたびに別システムを検索する時間を減らせます。

設計では、検索対象を細かく分けます。全社ドキュメントをまとめて接続するより、プロジェクト別、顧客別、部署別に範囲を限定したほうが安全です。検索結果に個人情報や契約情報が含まれる場合は、マスキングや権限判定をMCPサーバー側で行います。

CodexでMCP連携を使う際の権限管理

MCP連携の価値は、Codexが必要な情報やツールへアクセスできる点にあります。同時に、権限管理を誤ると、AIが参照してよい範囲や更新してよい範囲が曖昧になります。

チーム導入では「どのツールを公開するか」より先に、「誰が、どの目的で、どこまで操作してよいか」を決めます。MCPは技術設定と社内ルールをセットで運用する必要があります。

ツール権限と利用範囲

MCPサーバーが公開するツールは、必要最小限にします。検索、読み取り、要約のような参照系と、コメント投稿、チケット更新、ファイル変更のような更新系を分けて、利用者やプロジェクトごとに許可範囲を決めます。

Codexの設定では、サーバー単位やツール単位で有効化・無効化、承認モードを調整できる項目があります。チーム運用では、開発者個人の判断に任せず、標準設定を用意し、例外が必要な場合だけレビューする形にします。

認証情報とログ管理

認証情報は、config.tomlへ直接書かず、環境変数やシークレット管理へ分けるのが基本です。特にHTTP型MCPでBearer tokenを使う場合は、トークンの発行者、期限、権限範囲、失効手順を明確にします。

ログ管理では、Codexがいつ、どのMCPツールを使い、どの範囲の情報を参照したかを追える状態にします。社内ツール側の監査ログとMCPサーバー側のログを合わせて確認できると、問題発生時に原因を切り分けやすくなります。

更新系操作の承認ルール

更新系操作は、最初から自動実行にしないほうが安全です。issueのステータス変更、PRコメント投稿、チケット更新、ファイル書き込み、顧客データ更新などは、人が確認する承認ポイントを設けます。

弊社エンジニアからのコメント：

MCP連携は、接続できるツール数を増やすほど便利に見えますが、導入初期は読み取り専用のサーバーから始めるほうが定着しやすいです。社内ナレッジ検索、公式Docs参照、Figma閲覧のように「参照して判断材料を増やす」用途で効果を確認し、その後にコメント投稿や更新系へ広げるとレビュー負荷を抑えられます。

CodexのMCP連携をAIエージェント開発に活かす方法

MCP連携は、Codexでの開発支援だけでなく、社内AIエージェント開発の基盤にもなります。業務に必要な情報源や操作をMCPサーバーとして整理すれば、複数のAIエージェントから共通利用しやすくなります。

ただし、AIエージェント開発では、機能追加よりも運用設計が成果を左右します。権限、ログ、テスト、承認、停止手順を決めてから業務適用することが重要です。

参照系から始める導入順序

導入順序は、公式ドキュメント参照、社内ナレッジ検索、デザイン参照、GitHub情報参照の順に広げると進めやすいです。いずれも更新操作を伴わないため、効果検証とリスク確認を並行できます。

参照系で確認する指標は、検索時間の削減、仕様確認の手戻り削減、プロンプトへの貼り付け作業の削減です。定量化しやすい業務から始めると、次の投資判断がしやすくなります。

更新系へ広げる判断基準

更新系へ広げる判断基準は、操作内容が取り消し可能か、ログで追跡できるか、人の承認を挟めるか、誤操作時の影響範囲を限定できるかです。これらが満たせない場合は、Codexに更新案を作らせ、人が実行する運用に留めます。

たとえばPRコメント投稿は比較的始めやすい一方、顧客情報の更新や本番設定の変更は慎重に扱います。MCPサーバー側で読み取り専用モードやツール別権限を実装し、段階的に許可範囲を広げます。

AIエージェント開発支援の活用範囲

AIzen株式会社では、MCPサーバー設計、社内ツール連携、認証・権限設計、Codex導入、AIエージェント開発まで支援できます。既存の業務システムやナレッジ基盤を確認し、どの情報をAIへ接続すべきかを整理します。

単なるMCP設定代行ではなく、業務フロー、承認者、ログ、失敗時の対応まで含めて設計することで、現場で使い続けられるAI連携にできます。社内ツールをAI開発へつなげたい場合は、まず参照系の候補整理から始めるのが現実的です。

まとめ

CodexのMCP連携は、外部ドキュメント、Figma、GitHub、社内ナレッジを開発作業の文脈に取り込むための仕組みです。要点は次の3つです。

• config.toml でMCPサーバーを管理し、CLIとIDE extensionで共有できる前提を理解する
• 参照系から始め、更新系操作は承認ルールとログ管理を整えてから広げる
• 社内ツール連携では、認証情報、閲覧範囲、ツール権限をMCPサーバー側でも制御する

AIzen株式会社では、CodexのMCP設定、社内ナレッジ検索、Figma・GitHub連携、AIエージェント開発の設計を支援しています。社内ツールを安全にAI開発へ接続したい場合は、無料相談からご相談いただけます。