Claude CodeからCodexへの移行ガイド 2026

2026年5月3日、私はローカルのエージェント設定項目744件を棚卸しし、そのうち691件を運用上の重みによって順位付けした。¹ 数だけ見ると大きい。しかし重要だったのは形だった。およそ20個のファイルが、実質的にシステムを支えていた。

Claude Code から Codex への移行では、ファイルツリーをコピーするのではなく、運用契約を移植するべきだ。CLAUDE.md のルールは階層化した AGENTS.md へ、再利用可能な手順は Codex スキルへ、決定的な品質基準は焦点を絞ったフックへ、リスク姿勢はプロファイルへ、ブラウザやソース取得の道具立ては明示的な MCP へ移す。Claude のフック網を Codex にそのまま写してはいけない。移すべきなのは、何を証明しなければならないかという義務だ。

TL;DR

私の Codex 環境には、非公開の執筆と検証の仕組みはすでに存在していた。欠けていたのはスキルの中身ではない。欠けていたのは公開できる運用マニュアルだった。再利用可能なスキルをどこに置くべきか、Codex がそれをどう選ぶべきか、公開文章にはどのプロファイルを使うべきか、Claude 時代のどの基準を非公開の作業詳細を露出させずに Codex ネイティブなルールへ変えるべきか、という話だ。

最初の実運用の Codex パスで、移行ルールは変わった。非公開の作業手順を移植した瞬間に常時有効化してはいけない。段階化する。私のサイト固有の執筆経路は現在、明示的に呼び出した場合だけ開始する。一方で移行手順は、ローカルで能動的に使うユーザースキルとして、またローカルテスト用の非公開 Codex パッケージ候補として存在している。そのパッケージはオープンソースでも一般公開でもない。移行手順を試したい場合は、私に連絡してほしい。ローカルのインストール項目があるという理由だけで、そのパッケージを既定の実行経路にしてはいけない。本当のインストール試行には、パッケージ検証、プラグインのインストール確認、名前空間付きスキル検出、重複の整理、新しい Codex セッションがまだ必要だ。それによって、ある手順が既定動作になる前に、実作業から学べる。¹⁸¹⁰¹⁴

Claude のフックをすべて Codex に複製するところから始めてはいけない。まず Codex の契約を書く。

• 永続的なリポジトリ横断ポリシーは ~/.codex/AGENTS.md に置く。
• リポジトリのポリシーは AGENTS.md に置き、より狭い上書きは作業対象の近くに置く。
• 再利用可能な手順は .agents/skills または $HOME/.agents/skills に置く。
• 公開文章は careful-review、または専用の public-writing プロファイルに昇格させる。
• 決定的な基準はフックとして残す。ただしフックは安全策の一つであり、安全モデル全体ではない。

最初に成功すべき移行成果物は、自己説明できる記事であるべきだ。その成果物は、システムが自分自身を説明し、現在のドキュメントを引用し、サニタイズしたローカル棚卸しを使い、非公開の内部機構を公開せずに Codex 管理下で公開物を作れることを証明する。

Claude 側の仕組みは Claude Code as Infrastructure で、指示ファイル側は AGENTS.md Patterns で、スキルの劣化問題は Static Skills Are Dead Skills で扱った。以下の移行は、それらの話を私が実際に使っている Codex 実行環境につなげる。

関連する背景として、Codex CLI guide、Claude Code vs Codex、Codex vs Claude Code 2026、Claude Code Hooks Tutorial、Building Custom Skills、Jiro Quality Philosophy も読むとよい。これらの記事は、ここで移行が組み立てる部品を説明している。

移行の棚卸しから何が分かったか？

ローカルシステムには、重心が三つあった。

利用データも同じ結論を示していた。私のプロファイル振り分けログでは、レビュー比重の高い作業が日常実行の大部分を占めていた。¹ 本当の中核は、最も長いファイルでも最も賢いスクリプトでもなかった。中核は、リスク水準を選び、思想を読み込み、完了前に証拠を要求する判断層だった。

この発見は移植の仕方を変える。

重要なのが「Claude には多くのフックがある」なら、移行はフックをコピーすればよい。重要なのが「システムに思想がある」なら、移行は文章をコピーすればよい。棚卸しが示した答えは違った。重要なのは、適切なタイミングで発火する小さな契約である。

公開前に何をしたか？

この記事自体が、最初の移行演習になった。

まず、成熟した Claude Code 構成の形を整理した。どの部品が振る舞いを支配し、どの部品が単に好みを文書化しており、どの部品を非公開のままにすべきかを見た。次に、現在の Codex の挙動を公式ドキュメントとローカル CLI で確認した。移行ガイドは古いフラグや非対応の設定形状を引き継ぐとすぐ劣化するからだ。それから、実際の移行を念頭にこの記事を下書きした。ただし公開する詳細は、非公開の実装ではなく、サニタイズしたアーキテクチャに絞った。

次の手順は公開前に起こる。このガイドを使って Codex 構成を作り込み、実際に変わった内容で記事を修正する。公開記事は、移行パターンと受け入れ基準を示すべきだ。非公開プロンプト、非公開の執筆手順、正確なフック内部、機密性の高いパス、読者が非公開システムを再構築できる情報を公開してはいけない。

実運用パスでは、公開しても安全な証明表ができた。公開するのは契約、有効化状態、受け入れシグナルだけであり、非公開プロンプト、正確なフック本文、執筆手順の内部ではない。

Codex 移行はフックから始めるべきか？

Claude は私に、ライフサイクルイベントで考えることを教えた。UserPromptSubmit フックはプロジェクト文脈を注入できる。PreToolUse フックは機密パスをブロックできる。Stop フックは弱い完了を拒否できる。このパターンは Claude では機能する。私のローカル構成が、多数の小さなスクリプトを一つの順序付きイベントパイプラインへ変えるディスパッチャを中心に成長したからだ。¹¹

Codex にもフックはある。ただし現在の Codex では、常時有効のフックディレクトリではなく、機能フラグ付きのライフサイクルシステムとして扱われる。OpenAI のフック文書は config.toml の [features] codex_hooks = true を示しており、私のローカル codex features list は Codex CLI 0.130.0 で hooks が stable かつ enabled と報告する。²⁸ OpenAI はフック入力を stdin の JSON として文書化しており、セッション ID、作業ディレクトリ、イベント名、有効モデルなどの共通フィールドがある。² Codex は SessionStart、PreToolUse、PermissionRequest、PostToolUse、UserPromptSubmit、Stop などのイベントをサポートする。PreToolUse は Bash、apply_patch、MCP ツール呼び出しを遮れる。²

同じ文書には、移行にとって重要な警告もある。PreToolUse は安全策であって、完全な強制境界ではない。文書では、遮断がすべてのシェル経路を覆うわけではなく、Web 検索やその他の非シェル、非 MCP ツール呼び出しを遮らないと説明されている。²

この制限は、Codex フックが弱いという意味ではない。フックに移植全体を背負わせるべきではない、という意味だ。OpenAI はまた、同じイベントに一致する複数のコマンドフックは並行して起動されると述べている。そのため、順序を必要とする Codex 移植には、なおディスパッチャか一つにまとめたフックコマンドが必要だ。²

Codex では、狭く決定的なチェックにフックを使いたい。

• 明らかに破壊的なシェルコマンドをブロックする。
• 認証情報らしいパスに警告する。
• 小さなセッション開始文脈を加える。
• 公開執筆実行から証拠を記録する。
• 必須成果物や検証コマンドがない場合、停止イベントを失敗させる。

執筆の声、引用ポリシー、思想、振り分け、プロジェクト思想をフックに背負わせたくはない。Codex には、それらに向いたよりよい置き場所がすでにある。

Claude の成果物は Codex にどう対応するか？

Claude の各成果物を、その役割に最も合う Codex の基本要素へ対応付けると、移行はすっきりする。

OpenAI の AGENTS.md 文書は、最初の行を移行の背骨にする。Codex は作業前に AGENTS.md ファイルを読み、Codex ホームディレクトリからグローバルな指針を重ね、その後プロジェクトルートから現在のディレクトリまでたどり、近いファイルが先の指針を上書きできる。³ この挙動は、私が CLAUDE.md に実際に求めているもの、つまり永続的な作業合意とプロジェクト固有の詳細に合っている。

重要な動きは、ルールを操作として書き直すことだ。「丁寧に書く」は AGENTS.md に属さない。「公開記事では、まず引用を集め、URL を検証し、禁止表現チェックを走らせ、未検証の主張を報告する」はそこに属する。

非公開の執筆スキルは Codex へどう移すべきか？

ブログライターの仕組みは、もともと適切な形をしていたため、きれいに移植できる。Codex スキルは、frontmatter と指示を含む SKILL.md ファイルを持つフォルダだ。ユーザーが明示的に呼び出した場合、またはタスクがスキル説明と一致する場合に、Codex はスキルを有効化できる。⁴ Codex はリポジトリ、ユーザー、管理者、システムの各場所からスキルを読む。これにはリポジトリの .agents/skills、$HOME/.agents/skills、/etc/codex/skills が含まれる。⁴

ここで Claude Code の移行は微妙に間違いやすい。Codex スキルは Claude のスラッシュコマンドではない。明示呼び出しのための公式な Codex スキル経路は、スキルセレクタまたは $skill-name メンションである。一方、Codex CLI のスラッシュコマンドは、status、permissions、model 変更、plugins、セッション制御などの組み込み操作のための別の対話面だ。⁴¹⁵ /cave のようなプロンプトは、スキル説明が認識する場合やラッパーが Use $cave ... に変える場合には便利な短縮形になり得る。しかしスラッシュ文字列そのものは永続的な契約ではない。移行の証明では $skill-name をテストし、その互換性を約束する場合だけ /name を別にテストする。

つまり、新しい Codex ネイティブの執筆スキルは、非公開のスキル名や内容を公開せず、公式のスキルパスへ標準化するべきだ。

$HOME/.agents/skills/source-verifier/SKILL.md
$HOME/.agents/skills/public-post-writer/SKILL.md
$HOME/.agents/skills/site-specific-writer/SKILL.md

私のローカル実行環境には、古い場所で動いているユーザースキルもある。¹ 公開ドキュメントが .agents/skills を名指ししているからといって、それらを削除すべきではない。安全な移行は次のようになる。

1. 一つのスキルを $HOME/.agents/skills にコピーまたはシンボリックリンクする。
2. Codex を再起動する。
3. Codex がそのスキルを一覧表示し、有効化できることを確認する。
4. 試行中は、そのスキルを明示呼び出し専用にする。
5. 検出と試行利用が機能してから、残りを移す。
6. 既存セッションとスクリプトが依存しなくなるまで、古いパスを残す。

最初の非公開執筆手順では、この経路を取った。私はサイト固有のライターを、あらゆるコンテンツタスクの既定ライターにするのではなく、明示呼び出し専用の非公開スキルとして段階化した。これにより移行にはよりよいテストができた。そのスキルが、非公開の手順を漏らさずにこの記事と次の公開執筆実行を改善するなら、明示専用から試行へ進める。混乱を増やすなら、範囲を絞ったままにする。

ブランド固有のライターを、既定のサイトライターにしてはいけない。非公開のプロダクトライターが同じ引用基準やレビュー基準を共有することはある。しかし対象読者、製品事実、行動喚起、声のルールは、そのプロダクトに閉じているべきだ。正しい移植では、ブランドアダプタを分離したままにし、blakecrosley.com 用の薄いサイト固有ライターを作る。

そのサイトスキルは薄く保つべきだ。

---
name: site-specific-writer
description: Write public technical posts for a specific site. Use for articles that need verified sources, internal links, site voice, and publication checks.
---

# Site-Specific Writer

Use the private writing, source-verification, and AI-discoverability skills for every public technical article.

Required proof before final:
- External technical claims have citations.
- Current Codex claims cite OpenAI docs.
- Internal claims link to existing posts or author analysis.
- The post includes a TL;DR, role-specific takeaways, and reader questions when useful.

Codex スキル文書は、name と description を手動スキルの frontmatter フィールドとして示し、description が暗黙起動のトリガーになると説明している。⁴ 本文では、Codex に非公開の伴走スキルを使うよう指示できる。ローカルの道具立てが追加メタデータを持たない限り、合成は指示の中に属する。一般的な仕組みが執筆ルールを持つ。サイトのラッパーは、声、リンクパターン、証明を持つ。

同じ分割は移行手順そのものにも当てはまる。OpenAI のプラグイン文書は、個人的な一つの手順をまだ反復中ならローカルスキルから始め、チーム間で安定したパッケージを共有したい場合や追加連携を束ねたい場合にプラグインを作ることを勧めている。¹⁰ そのため有効な経路は明らかだった。先にユーザースキル、次に非公開パッケージ試行である。私は移行スキルをオープンソース化しておらず、公開リリースも約束していない。試したい場合は私に連絡してほしい。プラグインキャッシュの調査では、インストール済みプラグインのスキルが裸のスキル名ではなくプラグイン名前空間の下に現れることが分かった。そのためパッケージ文書では、直接のスキル利用とプラグイン経由でインストールされたスキル利用を区別するべきだ。⁸

非公開パッケージにまず必要なのは、公開話ではなく検証器だ。最新のパスでは、マーケットプレイス JSON、プラグイン manifest、スキル frontmatter、必須参照、引用チェッカー構文、インストールポリシー、有効なフックまたは MCP manifest がないこと、生成ファイル、明らかな非公開パスや秘密情報フィクスチャ漏れを確認する検証器を追加した。このチェックは、より広い有効化の前に必要だ。OpenAI のプラグイン文書は、マーケットプレイスをインストール面として扱っており、不安定な非公開手順の作業場所として扱っていないからだ。⁸¹⁰

AGENTS.md は公開執筆ルールをどう持つべきか？

最も強い Codex 移行変更は、フックではなく AGENTS.md に属する。公開執筆には既定のリスク分類が必要だ。

グローバルまたはプロジェクトファイルの上部近くに置きたいルールはこれだ。

## Public Writing Is Product Work

Public articles, guides, landing pages, docs that shape user understanding, and product copy use `default` profile at minimum. Promote to `careful-review` when claims, citations, brand, money, safety, security, or user trust are at stake.

Before finishing public writing:
- Gather citations before drafting.
- Cite official product docs for current tool behavior.
- Label author analysis clearly.
- Run a banned-phrase scan.
- Verify internal links.
- Report any claim that could not be verified.

このルールは、ルーター棚卸しで見つけた欠陥を直す。一部のコンテンツ作業は、ルーターが「コンテンツ」を安い作業として扱ったため、高速実行側へ流れていた。公開執筆は、人々が何を信じ、買い、インストールし、実行するかを変えるなら、安い作業ではない。ブログ下書き、ガイド、プロダクトページには、通常のコード編集より多くのレビューが必要だ。失敗モードがローカルテストの失敗ではなく、公開の信頼だからだ。

今読んでいるこの記事が例だ。現在の Codex 挙動には現在の Codex 文書を引用している。ローカル棚卸しの主張は著者分析として明示している。空のマシンから移行が始まるふりをせず実際の仕組みを使っているが、非公開の実装詳細は公開記事の外に置いている。

Codex プロファイルはリスクをどう表すべきか？

OpenAI の設定リファレンスは、profile を起動時の既定プロファイルとして定義し、対応する設定キーについてプロファイル単位の上書きをサポートしている。⁵ 同じリファレンスは、model_reasoning_effort、approval_policy、sandbox_mode を明示的な設定制御として定義している。⁵

これにより、Codex にはリスクを表す自然な場所ができる。

[profiles.public-writing]
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
web_search = "live"

具体的なモデルは変わり得る。ポリシーは変えるべきではない。公開執筆には、より高い推論、事実が変わり得る場合のライブソース確認、ワークスペース内に限定された実行、安全な作業経路を外れる操作への人間の承認が必要だ。

ルーターは、次のようなタスクを public-writing または careful-review に対応付けるべきだ。

• ブログ記事、ガイド、ホームページ変更。
• 引用を含む記事。
• ツールやベンダーを比較するコンテンツ。
• 現在の Codex、Claude Code、OpenAI、Anthropic、Apple、Google、その他変化の速い製品を名指しする記事。
• schema、llms.txt、SEO、アナリティクス、公開メタデータに触れる作業。

プロファイルは雰囲気ではない。プロファイルはリスク予算だ。

どの Codex フックがまだ重要か？

Codex フックは、実行時に必ず起こるべき小さなことを強制するために使うべきだ。

公開執筆の停止フックは、変更ファイルを確認し、公開 Markdown 記事に定義のない脚注参照が含まれていれば完了を拒否できる。事前ツールフックは、記事を書いている最中にエージェントが .env、アナリティクス認証情報、生成翻訳キャッシュを編集しようとした場合に警告できる。セッション開始フックは、現在日付を追加し、「latest」主張には検証が必要だと Codex に思い出させられる。

フックのペイロードは小さく保つ。OpenAI は、systemMessage、continue、イベント固有フィールドを含むフック用 JSON 出力形状を文書化している。² それらのフィールドを使って、正確な失敗をブロックまたは警告する。Codex の失敗データが必要性を証明するまでは、Claude のディスパッチャ網全体を再構築してはいけない。

セットアップテストだけでは昇格に値しない。フックを試行から外すのは、実利用の監視パスで三つが分かった後だけだ。意図した状況で発火すること、通常作業を通すこと、非公開内容ではなく安全な集計テレメトリを記録すること。ブロックが発火したら、その理由はユーザーが次に何をすべきかを伝えなければならない。²⁸

最初の実運用パス後、実用的なフック残件は次のようになっている。

1. SessionStart: 現在日付、最新性、プロジェクト、公開/非公開境界のコンパクトな文脈を試行として保つ。
2. PreToolUse:Bash: 狭い破壊的コマンドと認証情報読み取りガードを試行として保つ。
3. PostToolUse:apply_patch: 変更されたコード/設定パッチ行に対する非ブロッキング品質影実行を保つ。
4. Stop: 変更された公開 Markdown の引用基準を試行として保つ。
5. Stop: 最終検証契約は既存の品質 Stop 試行に畳み込み、実際の失敗が必要性を証明するまで別の要約フックを作らない。

この組み合わせは、Claude 固有の長い儀式を輸入せずに、安全性の振る舞いを移植する。

MCP とブラウザツールはどう組み込むべきか？

私の現在の Codex 構成は、すでに非公開の MCP ベースのブラウザ自動化経路を使っている。¹ Codex は CLI と config.toml の両方を通じて MCP サーバーもサポートする。codex mcp add は stdio サーバーを登録でき、[mcp_servers.<server-name>] テーブルは command、args、environment、URL、enabled_tools、disabled_tools、timeout を定義できる。⁶

公開執筆において、MCP が属する場所は二つある。

• 本番描画ページ、スクリーンショット、ローカルプレビューを確認するブラウザ自動化。
• 特定プロバイダが信頼できる MCP サーバーを提供している場合のソース発見やドキュメント取得。

MCP はソースの足跡を隠すべきではない。ブログライターに必要なのは、読者がクリックできる引用であり、セッション内にだけ存在した非公開ツール結果ではない。MCP は事実を見つける助けになる。最終記事には、それでも公開ソースが必要だ。

Claude Code から Codex への移行をどう立ち上げるか？

最初の Codex ネイティブ成果物は、その移植を使いながら移植を説明するべきだ。

対話的な立ち上げの循環はこうなる。

codex -p careful-review --search \
  "Inventory the local Codex and Claude migration surface, then create a citation bank for a sanitized post about moving the setup to Codex."

codex -p careful-review \
  "Draft content/blog/claude-code-to-codex-migration.md using the local inventory, official Codex docs, and existing internal posts. Label author analysis clearly."

codex -p careful-review \
  "Review the draft for unsupported claims, stale Codex flags, broken internal links, and AGENTS.md operational value."

非対話作業では codex exec を使い、対話用の --search フラグをコピーするのではなく、ライブ検索を設定またはプロファイルの関心事にする。OpenAI はスクリプト実行や CI 形式の実行向けに codex exec を文書化しており、--profile、--sandbox、--config の上書きも示している。私のローカル Codex CLI 0.130.0 の help はそれらのフラグを確認し、codex exec --search を拒否する。⁷⁸

codex exec -p careful-review -c 'web_search="live"' \
  "Create a citation bank for content/blog/claude-code-to-codex-migration.md from official Codex docs and sanitized local inventory."

codex exec -p careful-review \
  "Review content/blog/claude-code-to-codex-migration.md for unsupported Codex claims, stale flags, broken internal links, and AGENTS.md operational value."

コマンドラインの細部は重要だ。OpenAI は --full-auto を非推奨の互換フラグとして示し、代わりに --sandbox workspace-write を推奨している。⁷ --full-auto を中心にした古いガイドに、新しい自動化を支配させてはいけない。

この記事が受け入れテストになる。Codex が次を満たせるなら、

• 執筆スキルを読み込む。
• careful-review を使う。
• 現在の OpenAI 文書を引用する。
• 非公開実装詳細を露出せずにローカル棚卸しを使う。
• AGENTS.md、スキル、フック、プロファイル、MCP で何が変わるかを説明する。
• サイトリポジトリ内にきれいな Markdown 記事を生成する。

そのとき、執筆移植は機能している。

Claude Code から Codex への移行チェックリスト

Codex 設定について:

• グローバル作業合意を含む ~/.codex/AGENTS.md を追加または更新する。
• 公開執筆用のリポジトリ AGENTS.md ルールを追加する。
• public-writing を作るか、公開執筆を careful-review に振り分ける。
• careful-review が公開主張に対して実際に high または xhigh 推論を使うようにする。
• ガイド、ブログ記事、ドキュメント、プロダクトコピーを公開面の作業として扱うルータールールを追加する。

スキルについて:

• 非公開執筆スキルを $HOME/.agents/skills へ一つずつ移すかミラーする。
• 能動的にテスト中の移行手順は、プラグインパッケージを実行経路として扱う前にユーザースキルとして保つ。
• $skill-name を標準の明示呼び出しテストとして使う。/name は便宜的ラッパーまたは選択習慣であり、Codex スキルが読み込まれた証明ではない。
• マーケットプレイス有効化前にパッケージ準備検証器を追加する。
• 昇格前に AGENTS 参照、プロファイル、スキル、フック、パッケージ状態、レジストリ形状、有効化状態を証明するハーネス健全性基準を追加する。
• インストール試行では、マーケットプレイス追加、プラグインの読み取り/インストール、プラグイン一覧、スキル一覧、新規セッションでのスキル可視性、重複マーケットプレイス整理を検証する。
• 暗黙起動を許可する前に、試行スキルを明示呼び出し専用に保つ。
• 一般的な執筆基準とサイト固有の声を分離する。
• ソース検証を厳格な事実基準として保つ。
• AI 発見性チェックを著者の声から分離する。
• ブランド固有ライターを再利用せず、薄いサイト固有ライタースキルを作る。
• 各移動後に Codex がスキルを検出することを確認する。

エージェント間協調について:

• 循環の所有者を Codex に保つ。
• レビューを実ファイルまたは文脈成果物へ固定する。
• アンカーがない、出力が空、第二エージェントがタイムアウトした場合は fail closed する。
• 根拠のない第二エージェント所見はローカル証拠で却下する。
• 根拠ある所見だけを受け入れ、最小の修正を適用し、静的レビューを再実行してから Codex 所有のチェックを走らせる。

フックについて:

• まず決定的なチェックだけを移植する。
• SessionStart、PreToolUse、PostToolUse、Stop を狭い基準に使う。
• 基準を増やす前に失敗を記録する。
• 影実行フックでは、生の非公開内容ではなくカテゴリを記録する。
• 昇格前に既知の悪いフィクスチャと既知のノイズが多いフィクスチャを一つずつテストする。
• 移行したチェックを強制する前に、きれいな失敗と整理負債を分離する。
• フックを実行時チェックとして扱い、思想の正本置き場にしない。

執筆手順について:

• 下書き前に引用を集める。
• 現在の Codex 挙動には公式文書を使う。
• ローカル棚卸しと経験には著者分析を使う。
• 既存記事が概念を説明している場合は内部リンクする。
• 最終前に検証を走らせる。
• ガイド保守では、ソースと実行時主張を検証し、派生する公開面を同期し、発見用ファイルを再生成し、スキップした翻訳、デプロイ、本番チェックを名指しする。
• 翻訳済みガイドでは、選択した翻訳プロバイダ、差分バッチまたはセクション数、値を含まない認証情報状態、書き込み/アップロードの有無、ロケール検証、実行がブロックされた場合の書き込まない理由を記録する。
• 秘密情報とログ衛生では、実行可能ソース、ドキュメント、生成キャッシュ、セッション記録、シェルスナップショット、ログ、意図的な秘密情報保管場所を分離する。移行した手順を安全と扱う前に、履歴を墨消しし、補助機能を環境必須設定へ変換する。
• デプロイ後は、正規 URL、構造化データ、サイトマップ、llms-full.txt、デプロイ状態、CDN 鮮度、本番の変更内容マーカーを検証する。
• CDN キャッシュが古い内容を返す場合は、既存のデプロイ経路を通じて影響を受けた公開 URL だけをパージし、変更マーカーを再確認する。

FAQ

非公開の執筆スキルは公開する必要があるか？

ない。移行記事は、非公開スキル名、プロンプト、採点詳細、ブランド固有アダプタを公開せずに、執筆システムの形を説明できる。公開すべき教訓は、それらのスキルをどこに置き、Codex がどう有効化すべきかである。

移行スキルにも同じルールが当てはまる。現在は非公開であり、オープンソースパッケージではない。手順を試したい場合は、私に連絡してほしい。

Claude Code から Codex への移行では、ブランド固有ライターを再利用すべきか？

すべきではない。ブランド固有ライターはブランド固有のままにするべきだ。個人サイトや会社サイトには、別プロダクトの読者、事実、行動喚起を継承せずに検証基準を共有する薄いサイトアダプタが必要だ。

Claude Code のフックをすべて Codex にコピーすべきか？

すべきではない。その裏にある契約を特定してから、振る舞いだけをコピーする。認証情報ブロックはフックに属する。執筆ルーブリックはスキルに属する。リスクルールはプロファイルまたはルーターに属する。思想は AGENTS.md と焦点を絞ったスキルに属する。

Codex スキルはどこに置くべきか？

新しい Codex ネイティブ作業では、公式のスキル場所を使う。プロジェクトスキルにはリポジトリ .agents/skills、ユーザースキルには $HOME/.agents/skills だ。⁴ 既存のローカル構成が ~/.codex/skills も使っている場合は、Codex の検出で新しい場所が機能することを確認するまで残しておく。

Codex で /skill プロンプトが失敗することがあるのはなぜか？

/skill は Codex スキル呼び出しの標準契約ではないからだ。Codex スキルは、$skill-name を含む明示的な選択またはメンション、あるいはタスクがスキル説明に一致した場合に有効化される。⁴ Codex CLI のスラッシュコマンドは、それ自体が組み込みコマンド面である。¹⁵ 決定的にスキルを有効化する必要がある場合は $skill-name を使う。/name は、便宜的ラッパー、選択習慣、または独自の証明が必要なプロンプト表現としてだけ残す。

Claude Code から Codex への移行の中核は何か？

中核はフック、スキル、プロファイルのいずれか単体ではない。中核は、作業開始前に四つの問いへ答える判断層だ。どんな種類の作業が来たのか。どのリスクプロファイルで実行すべきか。どの指示が支配するのか。完了前にどんな証明が必要か。

重要ポイント

Codex ユーザーへ: ディレクトリではなく契約を移植する。AGENTS.md、プロファイル、スキル、MCP、フックにはそれぞれ役割がある。各ルールを、Codex が最も直接的に守れる場所へ置く。

Claude Code から移るユーザーへ: Codex フックは安全策であり、成熟した Claude ディスパッチャシステムの完全な代替ではない。AGENTS.md とスキルから始め、実行時の強制が重要な場所にフックを追加する。

公開ライターへ: ブログ執筆は高レビューのプロファイルに属する。現在の主張には現在のソースが必要だ。磨かれた間違った記事は、壊れたローカルスクリプトより速く信頼を傷つける。

自分の仕組みについて: 非公開の執筆システムは、実質的に移植されただけではなくなった。最初のサイト固有ライターは明示呼び出し専用として段階化され、移行手順はユーザースキルとして有効であり、非公開プラグインパッケージは公開リリースにならないままローカルのインストール試行を通過した。Codex の思想は、品質と審美眼を運用ルールにした。最終検証要約は手動の影レビューに留め、狭い決定的チェックは別フックではなく既存の品質 Stop 試行に畳み込んだ。コンパクトな SessionStart 文脈フックは試行中であり、最初の有効な品質フックは apply_patch 変更を影実行で監視し、最初の事前 Bash 安全ガードは狭いブロッキング試行として動き、引用チェッカーは変更された公開 Markdown の Stop 試行として走るようになった。ガイド保守パスは実際の公開ドキュメントでソースから描画までの循環を証明し、あるパスは古いソースハーネスの数値を守るのではなく古い正確数の主張を修正し、別のパスは生成された AI 発見用ルートと提供中ルートの不一致を捕まえた。最近のパスでは、モデル/パラメータ互換性、ベンチマーク/モデルカードのずれ、変化の速いプラグインリリースのずれ、描画済み FAQ 構造化データのずれ、クレジット計算のずれ、第三者のみの API/法務/機能最小要件の主張、frontmatter slug によるルートずれを修正した。最新の Codex ガイドパスでは、ガイド翻訳をプロバイダ選択可能にし、Codex 所有の作業では Codex を既定プロバイダとして使い、切り詰められた翻訳出力をキャッシュ書き込み前に拒否し、ロケール書き込みを完了し、ロケールルートを検証し、Claude 専用経路に暗黙依存せず対象パージで古い CDN 応答を解消した。範囲を絞った秘密情報/ログ衛生パスは、ローテーション、墨消し、予防フック不足を記録する前に、ソース、ドキュメント、生成キャッシュ、セッション記録、シェルスナップショット、ログ、意図的な秘密情報保管場所を分離した。リリース循環は現在、ローカルチェック、デプロイ状態、CDN 鮮度、本番変更マーカー証明を別々の基準として扱う。ソース知能パスは、非公開メモリ書き込み前にドライラン/書き込み量規律を証明した。会社ブログのオンボーディング経路は、対象/パス/取材証拠が明示されるまでファイル生成前に停止するようになった。ブログ翻訳器は、D1 認証情報または明示的な対象がない場合に書き込み実行前に停止し、認証情報がある場合でも公開前に残留の多い Codex 出力を拒否する。エージェント間協調の循環は、第二エージェントに権限を渡さずにレビュー/修正/再検証を証明した。手動のハーネス健全性基準は、より広い有効化の前に決定的な昇格面を確認する。次の仕事は、残る明示専用の本番儀式を証明し続け、公開リリース境界を据え置き、どの基準も広げる前に実際の公開執筆とエンジニアリング作業を段階化された経路へ通し続けることだ。

参考文献