Codex MCP server removal入門——移行漏れをCIで見つける
Codexのcodex mcp-server廃止を題材に、Next.js + Firestore + GitHub ActionsでAI開発基盤の移行漏れを検出し、監査ログに残す方法を解説します。

はじめに
AIコーディング環境を少しずつ拡張していると、古い入口がGitHub Actions、package scripts、社内ドキュメント、管理画面の連携設定に残ることがあります。普段は目立たなくても、Codex更新後に夜間ジョブだけ失敗したり、新しいメンバーが廃止済み手順をコピーしたりします。
OpenAI DocsのCodex changelogでは、2026年9月5日の更新として、codex mcp-server コマンドと単体の codex-mcp-server バイナリが削除されたことが案内されています。8月24日に非推奨化されたあと、Codexをアップグレードする前に該当連携を更新する必要がある、という位置づけです。
一方で、Codexから外部MCPサーバーへ接続する機能自体がなくなったわけではありません。公式ドキュメントでは、外部MCPサーバーの追加や確認には codex mcp add、codex mcp list、codex mcp --help、OAuthが必要な場合の codex mcp login <server-name> が案内されています。
本記事では、架空の問い合わせ管理SaaS「SupportNest」を題材に、Next.js + Firestore + GitHub Actionsで「廃止されたCodex MCP server入口が残っていないか」を継続チェックする仕組みを作ります。
参考にした一次情報は次の通りです。
何が変わったのか
今回のポイントは、「MCPが消えた」ではなく「Codex自身をMCP serverとして起動する古い入口が消えた」と分けて理解することです。
| 用途 | これまで残りがちな書き方 | これから確認すること |
|---|---|---|
| CodexをMCP serverとして起動する連携 | codex mcp-server / codex-mcp-server | 削除済みなので移行対象にする |
| Codexから外部MCP serverへ接続する | codex mcp ... | 継続利用できる。設定と認証を棚卸しする |
| 独自クライアントからCodexを深く操作する | 独自に旧入口へ接続 | app-serverやSDKなど、公式の現行案内を確認する |
| CIでCodexを自動実行する | server起動を前提にした自作ラッパー | CI用途ならCodex SDKや非対話実行の方針を確認する |
Codex App Serverの公式ページでは、codex app-server は認証、会話履歴、承認、ストリーミングされたagent eventsなどを含む深い連携向けのインターフェイスとして説明されています。ただし、WebSocket transportやapp-serverコマンドは実験的で、本番ワークロード向けのサポート対象ではない旨も明記されています。
つまり、SupportNestで最初にやるべきことは、いきなり全連携を codex app-server に置き換えることではありません。まず、廃止された入口を参照している場所を洗い出し、「外部MCP接続」「CI自動化」「独自UI連携」のどれなのかを分類します。
ハンズオン1: 廃止済み入口を検出する
まず、SupportNestのリポジトリ内で廃止済み文字列を探します。最初は単純な検索で十分です。
rg "codex mcp-server|codex-mcp-server" .github scripts docs package.json src
この検索で見つかったものは、すべて同じ危険度ではありません。CIやpackage scriptsは error、docsやメモは warning として扱えるよう、アプリ側の型を先に決めます。
// src/lib/codexMcpAudit.ts
export type AuditFile = {
path: string;
content: string;
};
export type CodexMcpFinding = {
path: string;
line: number;
severity: "warning" | "error";
};
const removedEntryPoint = /codex mcp-server|codex-mcp-server/;
export function findDeprecatedCodexMcpReferences(
files: AuditFile[],
): CodexMcpFinding[] {
const findings: CodexMcpFinding[] = [];
for (const file of files) {
file.content.split("\n").forEach((text, index) => {
if (!removedEntryPoint.test(text)) return;
findings.push({
path: file.path,
line: index + 1,
severity: file.path.startsWith(".github/") ? "error" : "warning",
});
});
}
return findings;
}
ハンズオン2: Firestoreに監査ログを残す
次に、検出結果をFirestoreへ保存します。目的は、どのリポジトリに古いCodex連携が残っているかを時系列で追うことです。
// src/app/actions/saveCodexMcpAudit.ts
"use server";
import { FieldValue, getFirestore } from "firebase-admin/firestore";
import type { CodexMcpFinding } from "@/lib/codexMcpAudit";
export type SaveCodexMcpAuditInput = {
repository: string;
commitSha: string;
findings: CodexMcpFinding[];
};
export async function saveCodexMcpAudit(input: SaveCodexMcpAuditInput) {
const db = getFirestore();
const hasError = input.findings.some((finding) => finding.severity === "error");
return db.collection("codexMigrationAudits").add({
repository: input.repository,
commitSha: input.commitSha,
status: hasError ? "needs_action" : "ok",
findingCount: input.findings.length,
findings: input.findings,
checkedAt: FieldValue.serverTimestamp(),
});
}
findings には該当ファイル、行番号、重要度だけを入れ、ファイル全文は保存しません。CIログやソースコードをFirestoreへ丸ごと残すと、不要な機密情報まで蓄積されやすいためです。
ハンズオン3: GitHub Actionsで移行漏れを止める
最後に、GitHub Actionsで簡易チェックを走らせます。ここでは実在確認済みの汎用コマンドだけを使います。
name: Codex MCP migration audit
on:
pull_request:
paths:
- ".github/**"
- "scripts/**"
- "docs/**"
- "package.json"
- "src/**"
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check removed Codex MCP server entry points
run: |
if rg "codex mcp-server|codex-mcp-server" .github scripts docs package.json src; then
echo "Removed Codex MCP server entry point found."
echo "Classify it as external MCP, CI automation, or app-server integration."
exit 1
fi
外部MCPサーバーを使っているプロジェクトでは、このチェックに加えて、開発者の手元で codex mcp list を実行して登録済みサーバーを確認します。OAuthが必要なMCPサーバーは codex mcp login <server-name> でログインする、と公式ドキュメントにあります。
ここで大事なのは、codex mcp 系の現行コマンドまで禁止しないことです。廃止対象は codex mcp-server と codex-mcp-server です。正しい接続設定を誤って消すと、エージェントが必要な社内ツールへアクセスできなくなります。
見つかった参照は、用途ごとに処理します。GitHub Actionsで旧serverを起動しているならPRを止めます。社内CLIが旧binaryをspawnしているなら、利用者と認証方式を棚卸しします。外部MCP接続の説明文だけなら、codex mcp と旧入口を混同しないよう表現を直します。独自UI連携でapp-serverを検討する場合も、実験的・非本番向けの制約を明記してPoCから始めます。
まとめ
codex mcp-server の削除は、小さなコマンド変更に見えて、AI開発基盤の依存関係を見直すよいタイミングです。
- 廃止されたのは
codex mcp-serverとcodex-mcp-server - Codexから外部MCPサーバーへ接続する
codex mcp系の入口は別物として扱う codex app-serverは深い連携向けだが、実験的・非本番向けの制約を確認する- Next.js + Firestoreでは、検出結果を監査ログ化するとチーム横断で移行漏れを追いやすい
- GitHub Actionsでは、まず文字列検出で古い入口を止めるだけでも効果がある
AIエージェントまわりの連携は、小さな破壊的変更が広く効きます。ニュースを読んで終わりにせず、CIと監査ログに落として「残っている古い入口」を見える状態にしておくのがおすすめです。