Claude CodeからCodexへ移る前に：指示書を写すだけで終わらせない

AIコーディングエージェントを使い始めると、しばらくして「今のツールから別のツールへ移りたい」という場面が出てきます。

そのときに危ないのは、モデル性能の比較だけで判断してしまうことです。

実務で本当に移さなければならないのは、チャット履歴ではありません。会社の作業ルール、禁止事項、確認コマンド、公開前チェック、ファイルを触ってよい範囲です。

Claude Codeで CLAUDE.md を育ててきた会社がCodexへ移るなら、単にファイル名を変えるだけでは足りません。 Codexは AGENTS.md を読み込みますが、どの階層の指示が優先されるか、どの権限で動かすか、どこまで自動実行させるかを一緒に見直す必要があります。

移行するのは「AI」ではなく「作業の前提」

AIツールを乗り換えるとき、多くの人は次のような点を見ます。

どちらの回答が速いか
どちらがコードを書けるか
どちらが画像や資料も作れるか
月額費用に見合うか

もちろん大事です。しかし、業務利用で失敗を分けるのはそこではありません。

AIエージェントは、ローカルファイルを読み、編集し、コマンドを実行します。つまり、業務ルールが曖昧なまま乗り換えると、新しいツールの方が高性能でも、より速く間違えるだけになります。

移行前に見るべきものは、次の4つです。

1. 事業上の前提
2. 編集してよい場所
3. 実行してよいコマンド
4. 公開・納品前の検証手順

この4つが分かれていれば、Claude CodeでもCodexでも、別のAIエージェントでも引き継ぎやすくなります。

CLAUDE.mdとAGENTS.mdの役割を混ぜない

Claude Codeの公式ドキュメントでは、CLAUDE.md はプロジェクトや組織の永続的な指示を置くファイルとして説明されています。一方、OpenAIのCodex公式ドキュメントでは、Codexは作業前に AGENTS.md を読み、グローバル、プロジェクト、現在の作業ディレクトリに近い指示を組み合わせます。

ここで大事なのは、どちらも「AIに読ませる説明書」ではありますが、運用上は同じものとして扱わないことです。

たとえば、既存の CLAUDE.md に次のような内容が入っているとします。

このリポジトリでは、公開前に npm run build を実行する。
ブログ記事では、文字起こしの固有名詞をそのまま使わない。
顧客情報を含むファイルはコミットしない。

これはCodexにも引き継ぐ価値があります。

一方で、次のような内容はそのまま移すと混乱します。

ClaudeのPlan Modeで作業する。
/init でCLAUDE.mdを更新する。
Claude固有の設定ファイルを確認する。

ツール固有の操作は、共通指示ではなく、ツール別の補足に分けるべきです。

まず共通ルールをAGENTS.mdにする

移行時のおすすめは、最初に AGENTS.md を「ツール非依存の作業契約」にすることです。

書くべき内容は、AIツール名ではなく、会社として守りたい判断です。

## 事業前提
- 公開記事では未確認の価格、日付、提供条件を断定しない。
- 文字起こしは事実源として扱わず、外部事実は一次情報で確認する。

## 編集範囲
- ブログ本文は src/content/blog/ に作成する。
- アイキャッチ画像は public/images/blog/ に置く。
- 機密情報を含むファイルは読まない、編集しない、コミットしない。

## 検証
- 新規ブログ作成後は npm run check:blog-service-claims を実行する。
- 公開前に npm run check:sensitive-files を実行する。
- ビルドが通らない場合は公開しない。

## 承認
- 破壊的操作、外部公開、本番反映は明示された範囲でだけ行う。

ここまでを AGENTS.md に置くと、Codexで作業するときの基礎になります。

Claude Codeも併用するなら、Claude公式ドキュメントが示すように、CLAUDE.md から AGENTS.md を読み込ませる方法もあります。つまり、共通ルールは AGENTS.md に寄せ、Claude固有の補足だけを CLAUDE.md に残す形です。

ツール固有の補足は短く分ける

ツールをまたいで使う会社ほど、1つの指示書に何でも詰め込みがちです。

しかし、ファイルが長くなるほどAIは重要なルールを見落としやすくなります。 Claude Codeの公式ドキュメントでも、指示は具体的で簡潔な方が一貫して守られやすいと説明されています。

移行時は、次のように分けると扱いやすくなります。

AGENTS.md
  全ツール共通の事業前提、禁止事項、検証手順

CLAUDE.md
  Claude Code固有の操作、Claude側の補足

.codex/config.toml
  Codexの権限、承認、プロファイルなどの設定

docs/operations/
  長い手順書、公開フロー、事故対応、チェックリスト

AIに毎回読ませるものと、必要なときだけ参照するものを分ける。これだけで乗り換え時の事故はかなり減ります。

権限は「便利そう」ではなく「作業範囲」で決める

文字起こしの中でも、作業フォルダー、フルアクセス、サンドボックスの話が出ていました。ここはそのまま真似るのではなく、自社の作業に合わせて決めるべきです。

OpenAIのCodex公式ドキュメントでは、読み取り専用、ワークスペース内の編集、広いローカルアクセスといった権限プロファイルが説明されています。業務利用では、最初から広い権限を渡すのではなく、次の順序で始めるのが安全です。

1. 読み取りだけで調査する
2. テスト用フォルダーだけ編集させる
3. 本番リポジトリでは承認付きで編集させる
4. 外部公開やpushは、明示指示があるときだけ行う

特に、顧客情報、契約書、請求情報、個人情報、APIキーが近くにあるPCでは、「フォルダーを選べるから大丈夫」と考えない方がよいです。 AIに触らせるフォルダーと、絶対に触らせないフォルダーを先に分けておく必要があります。

移行前チェックリスト

Claude CodeからCodexへ移る前に、最低限このチェックを行います。

1. CLAUDE.mdの中身を分類したか
- 共通ルール
- Claude固有ルール
- 古いルール
- 秘密情報に近い記述

2. AGENTS.mdに移す内容を絞ったか
- 事業前提
- 禁止事項
- 編集範囲
- 検証コマンド
- 公開前の停止条件

3. Codexで読まれる階層を確認したか
- グローバル指示
- リポジトリ直下
- サブディレクトリの上書き

4. 権限を作業別に分けたか
- 調査
- 編集
- ビルド
- 外部公開

5. 移行後の初回タスクを小さくしたか
- README修正
- テスト用ページ作成
- 既存記事の軽微修正
- 差分確認だけ

最初から大きな実装や公開作業を任せる必要はありません。まずは小さな作業で、指示書が正しく読まれているかを確認します。

Optiensの見方

Optiensでは、AIエージェント導入を「どのツールが強いか」ではなく「会社の作業前提をどれだけ明文化できているか」で見ます。

AIエージェントは、指示が曖昧でも動いてしまいます。だからこそ、業務導入前に決めるべきなのは、プロンプトの上手さではなく、作業場所、権限、検証、停止条件です。

Claude CodeからCodexへ移る場合も同じです。 CLAUDE.md を AGENTS.md に置き換える作業ではなく、会社のAI作業ルールを棚卸しする機会として扱うべきです。

AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断簡易版（無料）で、現在の業務のどこがAI化しやすいかを確認してください。より具体的に導入可否や優先順位を整理したい場合は、詳細版AI活用診断（¥5,500税込・MTGなし）で、構成案と費用前提まで整理できます。

ツールを変える前に、指示書を整える。この順番を守るだけで、AIエージェントの乗り換えはかなり安定します。