AI

Codex MCP server removal入門——移行漏れをCIで見つける

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

2026年9月20日
CodexMCPGitHub ActionsFirestoreNext.js
Codex MCP server removal入門——移行漏れをCIで見つける

はじめに

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 addcodex mcp listcodex 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-servercodex-mcp-server です。正しい接続設定を誤って消すと、エージェントが必要な社内ツールへアクセスできなくなります。

見つかった参照は、用途ごとに処理します。GitHub Actionsで旧serverを起動しているならPRを止めます。社内CLIが旧binaryをspawnしているなら、利用者と認証方式を棚卸しします。外部MCP接続の説明文だけなら、codex mcp と旧入口を混同しないよう表現を直します。独自UI連携でapp-serverを検討する場合も、実験的・非本番向けの制約を明記してPoCから始めます。

まとめ

codex mcp-server の削除は、小さなコマンド変更に見えて、AI開発基盤の依存関係を見直すよいタイミングです。

  • 廃止されたのは codex mcp-servercodex-mcp-server
  • Codexから外部MCPサーバーへ接続する codex mcp 系の入口は別物として扱う
  • codex app-server は深い連携向けだが、実験的・非本番向けの制約を確認する
  • Next.js + Firestoreでは、検出結果を監査ログ化するとチーム横断で移行漏れを追いやすい
  • GitHub Actionsでは、まず文字列検出で古い入口を止めるだけでも効果がある

AIエージェントまわりの連携は、小さな破壊的変更が広く効きます。ニュースを読んで終わりにせず、CIと監査ログに落として「残っている古い入口」を見える状態にしておくのがおすすめです。