Claude CodeからCodexへ移行するときは、CLAUDE.mdをAGENTS.mdへ移し、skills、MCP、hooks、subagents、承認設定をCodexで動く形に整えます。設定ファイルをコピーするだけで始めると、古い指示やClaude Code専用の設定までCodexに渡してしまいます。

移行作業は、次の順番で進めると整理しやすくなります。

  1. Claude Code側の設定を棚卸しする
  2. Codex側にAGENTS.mdと設定ファイルを用意する
  3. skills、MCP、hooks、subagentsを移す
  4. サンドボックスと承認ルールを確認する
  5. 小さなリポジトリで動作確認する
  6. 問題がなければ利用範囲を広げる

OpenAIのCodex公式の移行ページとCodex CLI公式ページ、Claude Codeの公式概要を確認しながら、個人利用でも複数人利用でも使える移行手順として整理します。

Claude CodeからCodexへ移行する前に結論を整理

最初に、移行作業の範囲をはっきりさせます。Claude CodeとCodexのどちらが優れているかを決めるのではなく、すでにClaude Codeで作った設定をCodexでも安全に使える形へ組み替えます。

扱う移行範囲

対象にするのは、次の7つです。

移行対象 主な確認ポイント
CLAUDE.md AGENTS.mdへ移す内容と分ける内容
プロジェクトルール 共通化し、シンボリックリンクで参照する範囲
skills 同一フォーマットのため、コピーではなくシンボリックリンクで共有する範囲
hooks / slash commands 1対1コピーせず、発火条件から見直す
MCP 認証方式、権限、環境変数の扱い
subagents MarkdownからTOMLへの変換と、成果物の受け渡し
承認・サンドボックス 破壊的操作をどこで止めるか

Codex公式の移行ページでは、instructions、configuration、skills、MCP servers、hooks、subagents、recent sessionsなどが検出・移行対象として示されています。ただし、公式のimport flowは「見つかった設定を移す」機能です。複数人で使う場合の責任範囲やオンボーディングまでは自動で決めてくれません。

そのため、移行の本番作業に入る前に、何を自動移行し、何を人間が確認して直すかを分けることが重要です。

比較検討と移行手順の違い

Claude CodeとCodexの違いをまだ選定中なら、まず機能差、料金、MCP対応、サンドボックス、ユースケース別の向き不向きを比較します。移行手順に入るのは、Codexへ移す方針が決まってからです。

Codexへ移行すると決めた後は、比較表を最小限にし、次のような作業へ寄せます。

  • CLAUDE.mdとAGENTS.mdの正本を決める
  • ルールファイルやskillsをシンボリックリンクで共有する
  • Claude Code固有のhooksを見直す
  • MCPの認証情報を安全に扱う
  • subagentsをMarkdown形式からTOML形式へ変換する
  • subagentsの成果物をファイルで受け渡す
  • 必要に応じて承認ルールを作る

比較と移行を1つの作業に混ぜると、判断がぼやけます。選定中は比較、移行中は設定手順、という分担にします。

すぐ移行すべきケース・併用から始めるケース

すぐ移行しやすいのは、Claude Codeの使い方がまだ軽いケースです。CLAUDE.mdが短く、MCPも少なく、個人のローカル設定に依存していないなら、Codex側で受け皿を作って小さく試せます。

反対に、併用から始めるべきケースもあります。

  • CLAUDE.mdが長く、暗黙ルールが多い
  • hooksがCIやデプロイに近い処理を持つ
  • MCPに社内システムや顧客情報がつながっている
  • subagentsが複数あり、責任範囲が曖昧
  • レビューなしでファイル変更やコマンド実行を任せている

この状態で一気に移すと、問題が起きたときに原因を切り分けられません。まずは1つの小さなリポジトリで、同じタスクをClaude CodeとCodexの両方に試すのが安全です。

移行前に棚卸しするClaude Codeの設定

移行方針が見えたら、次は棚卸しです。ここで雑に進めると、不要な指示、古い認証情報、個人の好みまでCodexへ持ち込んでしまいます。

CLAUDE.mdとプロジェクトルール

CLAUDE.mdは、Claude Codeに作業ルールを伝える中心的なファイルとして使われることが多いです。ここには、プロジェクトの前提、よく使うコマンド、禁止操作、テスト手順、レビュー観点などが入ります。

移行時は、CLAUDE.mdを丸ごとAGENTS.mdへ貼り替えないでください。まず、内容を4種類に分けます。

分類 Codex側での扱い
プロジェクト事実 AGENTS.mdへ移す
開発ルール AGENTS.mdへ移す
長い手順 docsやskillsへ分ける
Claude Code固有設定 そのまま移さず再設計する

たとえば「このリポジトリはAstroで作られている」「記事ファイルはblog/draftに置く」はプロジェクト事実です。Codexにも必要なのでAGENTS.mdへ移します。

一方で、「Claude Codeの特定コマンドを使う」「Claude Codeのhooksで自動実行する」といった記述は、そのまま移してもCodexでは意味が変わる可能性があります。ここはCodexの仕組みに合わせて書き直します。

skills・slash commands・hooks

Claude Codeでskills、slash commands、hooksを使っている場合は、移行の難易度が上がります。公式移行ページでも、slash commandsはCodex skillsへ、hooksはCodex hooksへ、subagentsはCodex agentsへ対応づけられています。ただし、すべてがきれいに1対1で移るわけではありません。

棚卸し表は、次の形にすると整理しやすいです。

名前 種類 発火条件 入力 出力 Codex側の扱い
記事レビュー skill レビュー前 draft md 指摘一覧 シンボリックリンクで共有
URL確認 hook 保存時 md内URL 結果ログ 手動チェックへ変更
調査コマンド slash command 任意実行 KW research.md skill化を検討
調査担当 subagent 任意実行 調査テーマ research.md TOML形式へ変換

ポイントは、名前ではなく「入力と出力」で見ることです。AIエージェントの運用では、どのツールを使うかよりも、何を受け取り、何を成果物として残すかが重要になります。

MCPサーバーと認証情報

MCPは、AIエージェントに外部ツールやデータを渡す仕組みです。便利ですが、移行時に最も注意が必要な領域でもあります。

Codex公式ページでは、MCP server configurationも移行対象として扱われます。ただし、custom authentication、headers、environment variables、transportsを使う設定は、移行後に見直すべき対象として明記されています。

ここでやってはいけないのは、トークンやAPIキーの実値をドキュメントへ貼ることです。レビュー用の説明やチャットにも書いてはいけません。書くのは、環境変数名、管理者、権限範囲、ローテーション方針までにします。

例としては、次の粒度に留めます。

MCP名: issue-tracker
用途: GitHub Issueの参照
認証: 環境変数 GITHUB_TOKEN を参照
権限: read-only
管理者: 開発基盤チーム
移行後確認: CodexからIssue一覧を読めるか

実値を書かなくても、運用に必要な情報は十分残せます。

subagentsとワークフロー

subagentsは、複数のAIに作業を分ける仕組みです。調査担当、執筆担当、レビュー担当のように役割を分けると便利ですが、移行時には責任範囲が曖昧になりがちです。

関連する考え方は、Claude Code・Codex・OpenClawのサブエージェント機構比較でも整理されています。ここでは移行に必要な観点だけに絞ります。

subagentsを移すときは、会話履歴に頼らない設計へ寄せます。加えて、Claude CodeとCodexではsubagentsの定義形式が異なる点に注意します。Claude Code側はMarkdown形式で管理される一方、Codex側はTOML形式で定義するため、単なるシンボリックリンクやコピーでは移行できません。ここは形式変換が必要な領域です。

調査結果はresearch.md、レビュー結果はreview.md、構造化データはJSONやYAMLに保存する。こうしておくと、Claude CodeからCodexへ移しても、成果物を追跡しやすくなります。

Codex側の受け皿を設計する

Claude Code側の棚卸しが終わったら、Codex側に受け皿を作ります。ここを先に設計しておくと、移行後に「どこへ何を書けばいいか」で迷いません。

AGENTS.mdの役割と配置

Codexでは、プロジェクトに対する作業指示をAGENTS.mdに置く運用が使われます。Claude CodeのCLAUDE.mdに近い役割ですが、移行時は単なる名前変更にしないほうが安全です。

AGENTS.mdには、次のような情報を短く置きます。

  • プロジェクトの目的
  • 変更してよい範囲
  • 変更してはいけない範囲
  • テストや確認コマンド
  • レビュー前のチェック項目
  • 参照すべきdocsやskills

長くなりすぎる指示は、AGENTS.mdから分けます。AIに渡す文脈が長すぎると、重要なルールが埋もれます。AGENTS.mdは目次と安全ルール、詳細はdocsやskills、という分担が扱いやすいです。

config.tomlとプロファイル設計

Codex CLIはローカルのターミナルで動くコーディングエージェントです。公式ページでは、Codex CLIが選択したディレクトリ内のコードを読み、変更し、コマンドを実行できると説明されています。

複数人で使う場合は、1つの設定で全作業をさせるより、用途別にプロファイルを分けるほうが安全です。個人利用でも、通常作業用と高リスク作業用を分けると確認漏れを減らせます。

プロファイル 用途 承認の考え方
通常開発用 小さな修正、テスト追加 ファイル編集は許可、破壊的操作は承認
レビュー用 差分確認、指摘作成 読み取り中心、編集は限定
高リスク用 DB、認証、課金まわり 原則すべて人間承認

この設計は、AIエージェントのハーネスの考え方に近いです。AIを賢くするだけでなく、AIが動く範囲を外側から囲う発想です。

Codexのサンドボックス・承認モード

AIエージェントにコードを触らせるときは、サンドボックスと承認モードが重要です。サンドボックスは、AIが触れる範囲を制限する箱のようなものです。承認モードは、AIがコマンド実行やファイル変更をする前に、人間へ確認する仕組みです。

Codex CLI公式ページでも、approval modesが機能として案内されています。移行時は、Claude Codeで許可していた操作をそのままCodexへ渡さず、操作の危険度で分けます。

  • 読み取り: 原則許可
  • 通常のファイル編集: リポジトリ内だけ許可
  • パッケージ追加: 承認制
  • 削除、初期化、マイグレーション: 承認制
  • デプロイ、本番接続、秘密情報操作: 原則禁止または別フロー

特に本番環境へ影響する操作は、AIの便利さよりも監査性を優先します。誰が承認し、どのログを残すかまで決めてから移行します。

Windows・macOS・Linuxでの導入差分

Codex CLIは、公式ページでmacOS、Windows、Linuxに対応すると説明されています。WindowsではPowerShellでネイティブに使う方法と、Linux環境が必要な場合にWSL2を使う方法があります。

チームでOSが混在している場合は、導入手順を1つに固定しすぎないほうが安全です。たとえば、macOSとLinuxは同じ手順、WindowsはPowerShell版とWSL2版を分ける、といった書き方にします。

ここで重要なのは、開発者ごとの環境差を「個人の工夫」にしないことです。セットアップ手順、認証方法、よくあるエラー、問い合わせ先をチーム用ドキュメントに残します。

CLAUDE.mdをAGENTS.mdへ移す手順

Codex側の受け皿ができたら、いよいよCLAUDE.mdからAGENTS.mdへ移します。ここでは、ファイル変換ではなく、指示の整理として進めます。

移すべき内容・残すべき内容

まず、CLAUDE.mdを上から読み、各段落にラベルを付けます。

[project] プロジェクトの前提
[rule] 作業ルール
[command] よく使う確認コマンド
[security] 禁止操作・承認条件
[claude-only] Claude Code固有の説明
[old] 今は使っていない古い説明

AGENTS.mdへ移すのは、project、rule、command、securityです。claude-onlyはCodex向けに再設計します。oldは移しません。

この作業では、削る勇気が必要です。過去の事故対策や一時的なメモがCLAUDE.mdに残っている場合、それを全部Codexへ渡すと、AIの判断が鈍ります。AGENTS.mdには、今も守るべきルールだけを残します。

ルールファイルはシンボリックリンクで共有する

Claude CodeのルールファイルとCodexのルールファイルは、どちらもMarkdownで運用できます。そのため、移行期間中に両方を使い続けるなら、同じ内容をコピーして二重管理するより、片方を正本にしてもう片方からシンボリックリンクで参照する方法がおすすめです。

たとえば、AGENTS.mdを正本にするなら、CLAUDE.mdをAGENTS.mdへのシンボリックリンクにします。逆に、既存のCLAUDE.mdを当面の正本にするなら、AGENTS.mdからCLAUDE.mdへリンクします。

# AGENTS.mdを正本にする例
ln -s AGENTS.md CLAUDE.md

この方法なら、Claude CodeとCodexを併用している間も、ルール更新が1か所で済みます。コピー運用にすると、片方だけ古くなり、AIごとに違う判断をする原因になります。

長すぎる指示を分割する

AGENTS.mdが長くなるときは、次の基準で分けます。

内容 置き場所
常に守る安全ルール AGENTS.md
たまに使う詳細手順 docs/
繰り返し使う作業手順 skills/
チェックリスト docsまたはscripts
古い判断履歴 changelogやADR

たとえば、ブログ記事の書き方を毎回AIに読ませるならskillが向いています。リリース手順のように人間の確認が多いものはdocsが向いています。

この分割は、Agent Skillsの考え方とも相性がよいです。長いプロンプトを1つにまとめるのではなく、作業ごとの小さな手順に分けると、AIが必要なときだけ参照できます。

Claude CodeとCodexを併用する場合のSSOT

移行期間中は、Claude CodeとCodexを併用することがあります。このとき最も避けたいのは、CLAUDE.mdとAGENTS.mdが別々に育つことです。

SSOTとは、Single Source of Truthの略です。日本語では「正本」や「唯一の基準」と考えると分かりやすいです。併用期間中も、どちらのファイルを正本にするかを決めます。

おすすめは、プロジェクトの事実と安全ルールをAGENTS.mdまたは共通docsに寄せ、CLAUDE.mdはシンボリックリンクで同じ内容を参照する方法です。ただし、チームによって逆でも構いません。既存のClaude Code運用をすぐには止めないなら、CLAUDE.mdを正本にしてAGENTS.mdからリンクしても問題ありません。大事なのは、二重管理を放置しないことです。

skills・hooks・MCP・subagentsを移行する

AGENTS.mdが整ったら、周辺の自動化を移します。ここは便利さと危険さが隣り合う場所です。動けばよい、ではなく、失敗したときに止められる形へ変えます。

skillsはシンボリックリンクで共有する

Claude CodeとCodexのskillsは、どちらもMarkdown形式の手順ファイルとして扱えます。そのため、ルールファイルと同じく、単純コピーではなくシンボリックリンクで共有するのがおすすめです。

コピーしてしまうと、Claude Code側のskillだけ更新され、Codex側のskillが古いまま残る、といったズレが起きます。シンボリックリンクにしておけば、Claude CodeとCodexを両方使い続けながら、手順の正本を1つに保てます。

ただし、共有前にはskillの中身を軽く確認します。Claude Code固有のコマンド名、画面名、hooks前提の説明が入っている場合は、Markdownファイル自体は共有できても、記述を両ツールで通じる表現へ直したほうが安全です。

確認する観点は次の通りです。

  • いつ読むべきskillか
  • 入力は何か
  • 出力は何か
  • 外部ツールを使うか
  • Claude Code固有の操作名に依存していないか
  • 失敗時に止まる条件は何か

たとえば「記事レビューskill」なら、入力はdraft.md、出力は指摘一覧、合格条件はverdict: passのように定義します。この形にすると、ツールが変わっても運用が残ります。

hooksとslash commandsは1対1で移さない

hooksは、特定のタイミングで自動実行される処理です。便利ですが、移行では最も事故が起きやすい領域です。保存時、コミット前、レビュー前などに動く処理は、Codex側でも同じタイミングで動かすべきとは限りません。

slash commandsも同じです。Claude Codeで使っていたコマンド名をCodexで再現するより、「そのコマンドが何を達成していたか」を見ます。

たとえば、/reviewが実際には「差分確認」「URL確認」「表記ゆれ確認」の3つをしていたなら、Codexでは3つのskillへ分けたほうが扱いやすい場合があります。

MCPは認証方式と権限を再確認する

MCPの移行では、接続できるかよりも、接続してよい範囲を確認します。読み取りだけでよいMCPに書き込み権限が付いているなら、移行を機に落とします。

確認する項目は次の通りです。

  • 認証は環境変数か、設定ファイルか
  • トークンの実値がリポジトリに入っていないか
  • 読み取りと書き込みの権限が分かれているか
  • 本番データに触れるか
  • ログに秘密情報が出ないか
  • 権限の棚卸し担当者がいるか

Codex公式の移行ページも、MCP server settingsのうちcustom authenticationやheaders、environment variablesを使うものは移行後に見直す対象としています。ここは手動レビューを前提にします。

subagentsはMarkdownからTOMLへ変換する

subagentsだけは、ルールファイルやskillsと同じ扱いにできません。Claude Codeではsubagent定義がMarkdown形式であるのに対し、CodexではTOML形式で管理します。つまり、シンボリックリンクを貼るだけでも、ファイルをコピーするだけでも移行は完了しません。

ここでは、定義内容をCodexが読めるTOML形式へ変換する必要があります。subagent名、役割、利用条件、出力形式、禁止事項など、Markdown内に書かれている情報をTOMLの項目へ対応づけます。

変換は手作業でもできますが、subagentsが複数ある場合は変換スクリプトを使うほうが安全です。変換スクリプトの入手方法と使い方は、次の章で整理します。

変換スクリプトを使う場合の確認点

subagentsが複数ある場合は、定義変換をスクリプト化すると作業漏れを減らせます。ただし、変換スクリプトを使う場合も、出力結果の確認は必要です。

確認する項目は次の通りです。

  • agent名が変わっていないか
  • 説明文がCodex側の利用条件として読めるか
  • 禁止事項が落ちていないか
  • 入力と出力の形式が残っているか
  • 使ってよいツールが広がっていないか
  • 成果物の保存先が明確か

自動変換は、形式をそろえるための補助です。権限、責任範囲、禁止事項は、変換後に人間が読み直します。

subagentsは成果物受け渡しをファイル化する

subagentsを使う場合は、会話の中だけで完結させない設計にします。調査担当が調べたことはresearch.mdへ、レビュー担当の指摘はreview.mdへ、修正指示はtasks.yamlへ残します。

ファイル化すると、次の利点があります。

  • 人間が途中で確認できる
  • 別のエージェントへ引き継げる
  • 失敗時にどこでズレたか追える
  • レビュー時に根拠を示せる

AIエージェントの能力が上がるほど、作業は速くなります。ただし、速い作業ほどログが必要です。移行後のCodex運用では、成果物を残す場所まで設計しておきます。

個人利用と複数人利用で決めるルール

ここまでで、技術的な移行対象は整理できました。次に必要なのは、利用範囲に応じた決めごとです。Claude CodeからCodexへの移行は、日々の開発フローにも影響します。

誰が移行判断を持つか

最初に決めるべきは、移行判断の責任者です。個人が便利だから使う段階と、チーム標準として採用する段階では、必要な判断が違います。

最低限、次の役割を分けます。

役割 責任
移行責任者 いつ、どの範囲をCodexへ移すか決める
技術管理者 AGENTS.md、MCP、権限を管理する
レビュー責任者 AI生成差分の品質基準を決める
導入担当 メンバー向けの使い方を整える

個人利用なら、移行責任者、技術管理者、レビュー責任者はすべて自分です。それでも役割を分けて書くと、危険な操作をするときに立ち止まりやすくなります。複数人で使うなら、事故が起きたときに誰が止めるのかまで決めます。

レビュー・承認・破壊的操作の扱い

AIエージェントの移行で最も大事なのは、破壊的操作の扱いです。ファイル削除、依存パッケージの大幅更新、DBマイグレーション、本番デプロイなどは、通常のコード編集と同じ扱いにしないほうが安全です。

承認ルールは、次のように分けると運用しやすくなります。

操作 承認
ドキュメント修正 原則不要
小さなコード修正 レビューで確認
依存関係更新 技術管理者の確認
DB・認証・課金 事前承認必須
本番公開 人間の明示承認必須

この考え方は、ハーネスエンジニアリングにもつながります。AIに任せる範囲を広げるほど、外側の安全装置を強くする必要があります。

オンボーディングを用意する

Codexへ移行した後、使い方を自然に覚えるだけでは定着しにくいです。複数人で使うなら、最初に読む短い手順を用意します。個人利用でも、あとから自分が見直せるメモを残しておくと再設定が楽になります。

最初に確認する順番は、次の形がわかりやすいです。

  1. Claude CodeとCodexの役割分担
  2. AGENTS.mdの読み方
  3. やってよい作業・だめな作業
  4. MCPや秘密情報の扱い
  5. レビュー前の自己チェック
  6. 失敗したときの戻し方

特に、AIに「全部やって」と頼む前に、作業単位を小さく切ることが大切です。AI駆動開発では、プロンプトの上手さだけでなく、仕事を分解する力が品質を左右します。

移行後の検証チェックリスト

利用ルールまで決めたら、すぐ全リポジトリへ広げずに検証します。小さく試すことで、Codex側の設定ミスやルールの抜けを早く見つけられます。

小さなリポジトリでパイロットする

最初の検証は、影響範囲が小さいリポジトリで行います。ドキュメント修正、軽微なバグ修正、テスト追加のようなタスクが向いています。

代表タスクは3〜5件で十分です。多すぎると評価に時間がかかり、少なすぎると偏ります。

評価項目は、次のようにします。

評価項目 見るポイント
品質 人間の修正量は増えたか減ったか
速度 初稿からレビューまでの時間
安全性 禁止操作を避けられたか
再現性 別メンバーでも同じ手順で使えるか
レビュー負荷 指摘の種類と件数

ここでClaude CodeとCodexを必要以上に競わせる必要はありません。目的は勝敗ではなく、Codexへ移したときに業務が回るかを見ることです。

安全性・再現性・コストを確認する

検証では、見た目の速度だけで判断しないようにします。AIが速くコードを書いても、レビューが重くなれば全体としては遅くなります。

確認する項目は次の通りです。

  • AGENTS.mdの指示を守ったか
  • 変更範囲が想定内か
  • テストやlintを実行したか
  • MCPが必要以上の権限を持っていないか
  • 秘密情報がログや差分に出ていないか
  • レビュー用の説明に判断根拠が残っているか
  • 利用プランやAPI利用のコストが想定内か

料金やモデル名は変更が速い領域です。公開前や導入前には、必ず各公式ページで最新情報を確認してください。

Claude Codeとの併用期間を決める

移行でよくある失敗は、併用期間が終わらないことです。Claude CodeとCodexの両方にルールが残り、どちらが正しいか分からなくなります。

併用する場合は、最初に期限を決めます。

併用開始日: 2026-05-15
対象リポジトリ: blog-site
評価期間: 2週間
判定日: 2026-05-29
判定基準: 代表タスク5件のうち4件でレビュー指摘が許容範囲
移行後: AGENTS.mdを正本にし、CLAUDE.mdは参照用へ縮小

このように、判定日と基準を置くと、移行がプロジェクトになります。なんとなく両方使う状態を避けられます。

よくある失敗と回避策

最後に、Claude CodeからCodexへの移行で起きやすい失敗を整理します。どれも技術力不足ではなく、移行設計の不足で起きます。

CLAUDE.mdを丸ごとコピーして指示が肥大化する

最も多い失敗は、CLAUDE.mdをそのままAGENTS.mdへ貼ることです。最初は楽ですが、古いルール、Claude Code固有の説明、一時的なメモまでCodexに渡ります。

原因は、指示ファイルを「資産」ではなく「メモ置き場」として扱っていることです。影響として、AIが重要ルールを見落としやすくなります。

回避策は、移行前にラベル付けすることです。project、rule、command、security、claude-only、oldに分け、AGENTS.mdには今も必要なものだけ残します。

MCP認証情報を移行時に露出する

MCPの設定を共有するとき、トークンやAPIキーを貼ってしまう事故があります。これは絶対に避けるべきです。

原因は、接続手順と秘密情報を同じ場所で管理していることです。影響は大きく、外部サービスへの不正アクセスや権限漏えいにつながります。

回避策は、実値を一切書かないことです。環境変数名、権限範囲、管理者、更新手順だけを残します。レビュー用の説明にもチャットにも、秘密情報の実値は書きません。

比較と移行手順の役割が混ざる

Claude CodeとCodexを扱うと、つい料金、性能、モデル、機能差まで説明したくなります。しかし移行手順のページで比較が長くなると、設定作業の流れが見えにくくなります。

原因は、作業目的を1つに絞れていないことです。影響として、必要な設定手順が見つけにくくなります。

回避策は、比較を導入部の最小限に留めることです。選定前の人には比較情報、移行する人には手順、棚卸し、権限、オンボーディングを詳しく示します。

個人の便利設定をチーム標準にしてしまう

最後の失敗は、強い個人の設定をそのままチーム標準にすることです。個人には便利でも、全員にとって安全とは限りません。

原因は、個人最適とチーム標準を分けていないことです。影響として、初心者が危険な操作を実行したり、レビュー基準が揃わなかったりします。

回避策は、標準設定、推奨設定、個人設定を分けることです。標準設定は最小限にし、便利な拡張は任意にします。AI駆動開発では、自由度よりも再現性がチームの生産性を支えます。

まとめ：Codex移行は設定変更ではなく運用設計

Claude CodeからCodexへの移行は、CLAUDE.mdをAGENTS.mdへ変換するだけの作業ではありません。skills、hooks、MCP、subagents、承認、サンドボックス、オンボーディングまで含めた設定移行です。

最後に、移行前のチェックポイントをまとめます。

  • 比較検討は別記事に分けたか
  • CLAUDE.mdを分類してからAGENTS.mdへ移したか
  • secretsやトークン実値を書いていないか
  • ルールファイルとskillsをコピーではなくシンボリックリンクで共有したか
  • skillsは入力・出力・失敗条件で整理したか
  • hooksやslash commandsを1対1コピーしていないか
  • MCPの権限を読み取り・書き込みで分けたか
  • subagentsをMarkdownからTOMLへ変換したか
  • subagentsの成果物をファイルで残す設計にしたか
  • 破壊的操作と本番操作に承認ルールを置いたか
  • 小さなリポジトリでパイロットしたか
  • 併用期間の期限と判定基準を決めたか

まだClaude CodeとCodexの選定で迷っている場合は、先に違いを確認します。すでに移行へ進むなら、棚卸し表とチェックリストを使い、まず1つの小さなリポジトリで試してください。

複数人でAI駆動開発を標準化するなら、ツールの使い方だけでなく、レビュー、権限、オンボーディング、作業ルールまで揃えることが大切です。Codex移行を一度きりの作業ではなく、継続して使える開発手順に変えられます。

この記事を書いた人
せお丸（田中淳介）
理事長

せお丸（田中淳介）

AI駆動開発協会 代表理事 サイバーフリークス株式会社 代表取締役

YouTubeYouTubeXX (Twitter)
講演実績多数
せお丸（田中淳介）の講演の様子
← ブログ一覧に戻る