Claude CodeからCodexへブログ運営を移行した実例｜WordPress・Git・復旧まで引き継いだ方法

※本記事にはアフィリエイト広告（PR）が含まれています。

このブログは、記事作成やWordPress更新をClaude Code中心で進めてきました。2026年9月、その主担当をCodexへ変更しました。

結論から言うと、私の環境では日本語記事の品質に大きな不満がなく、ChatGPT/OpenAI側の画像生成を含めて一つの流れで進めやすかったため、Codex中心へ移す価値がありました。

ただし、Claude Codeを削除したわけではありません。Codexが使えないときのバックアップと、今後も結果を比較するための選択肢として残しています。

Claude Code自体の基本的な使い方や一般的なレビューは、この記事では繰り返しません。導入から知りたい方は「Claude Codeの始め方」、実際に使って感じた長所と短所は「Claude Codeを3ヶ月使った正直レビュー」をご覧ください。

なぜClaude CodeからCodex中心へ移したのか

主担当を変えた理由は、Claude Codeに大きな不満が出たからではありません。

私がCodexを含むChatGPT/OpenAI側の環境を試したところ、ブログ記事の日本語品質はClaude Codeと比べて大きく見劣りしませんでした。そのうえで、記事作成と画像生成を同じ環境の流れに置きやすい点が、ブログ運営では大きな差になりました。

日本語記事の品質は、私の用途では遜色なかった

ここでいう品質は、一般的な性能テストの結果ではありません。このブログで、既存記事、運営ルール、本人の体験、公式情報を読ませたうえで記事を作ったときの実感です。

Codexでも、事実と体験を分ける、スマホで読みやすい段落にする、未承認の広告リンクを出さない、といった既存ルールに沿って日本語記事を整えられました。

一方で、どちらを使っても事実確認は必要です。AIが自然な日本語で書けたことと、その内容が正しいことは別だからです。実際、このブログでは料金・仕様・検索データを一次情報で確認する工程を残しています。

決め手は、画像生成まで一体で進めやすかったこと

ブログは本文だけでは完成しません。アイキャッチや図解を作り、本文との意味が合っているか確認し、必要なら直す作業があります。

私にとってCodex側へ移した一番の利点は、ChatGPT/OpenAIの作業環境で、記事の調査・執筆・ファイル編集から画像生成までを一つの流れで進めやすいことでした。生成画像の仕上がりも、このブログで使いたい水準だと感じました。

OpenAIの公式ドキュメントでは、Codexから組み込みの画像生成・編集を利用でき、gpt-image-2が使われると案内されています。私の場合は、この機能を含むChatGPT/OpenAI環境で、記事作成から画像生成までを一つの流れで進めやすかったことが主担当変更の大きな理由でした。

なお、画像生成も利用枠を消費します。2026年9月13日時点の公式説明では、品質やサイズによって、画像を生成しない同程度のターンより利用枠を平均3〜5倍速く使うとされています。便利さだけでなく、利用制限も含めて考える必要があります。

移行前に「記事が書ける」以外を確認した

運営中のブログでは、文章を作れるだけで主担当を交代できません。WordPressへ反映できるか、GitHubへ正しい差分を残せるか、事故が起きたときに戻せるかまで確認する必要があります。

今回、実際に確認した範囲は次のとおりです。

横にスクロールできます

この表は「Codexなら何でも自動化できる」という意味ではありません。対象、権限、停止条件を決めたうえで、一つずつ実測した結果です。

WordPressはREST APIの読み書きと取得後照合まで試した

最初に、認証付きGETで公開記事と固定ページを読み取り、編集用の本文データを取得できるか確認しました。

次に、私が用意したテスト用下書き1件だけを対象に、短い文字列を追加して更新し、再取得で反映を確認しました。その直後に元の本文へ戻し、タイトル、slug、下書き状態、本文が元どおりかをもう一度確認しています。

下書きで書き込み経路を確認した後は、公開済みのマネーフォワードME記事1件を更新しました。更新後にWordPressから取り直し、タイトルを維持できていること、本文とMETA DESCRIPTIONがローカル正本と合うこと、未承認の広告CTAが非表示のままであることを照合しました。

WordPress公式のREST APIにも、投稿更新はPOST /wp/v2/posts/<id>として定義されています。ただし、APIに機能があることと、本番記事を無条件に更新してよいことは別です。このブログでは、対象記事と変更内容を決め、私が確認・承認した範囲だけ書き込む運用にしています。

Git/GitHubは「操作できるか」と「操作してよいか」を分けた

Gitでは、現在のブランチ、正規リモート、origin/mainとの差、認証状態を確認しました。その後も、commitやpushは自動では行わず、私が対象ファイルを指定して承認したときだけ進めています。

実際の移行作業では、記事の変更とテーマ修正を別コミットに分けました。関係のない未追跡ファイルをstageせず、push後にmainとorigin/mainが一致するところまで確認しています。

この経験から、私の運用では「CodexがGitを扱える」ことを「常に完全自動でpushできる」とは考えていません。差分を作る担当と、外部へ確定する権限を分けておく方が安全でした。

CLAUDE.mdを捨てず、共通ルールへつなぎ直した

移行で最も時間を使ったのは、ツールのインストールより運営ルールの整理でした。

Claude Codeでは、CLAUDE.md、専用のcommands・hooks・skills、会話から蓄積されたauto-memoryを使っていました。その中には、記事の品質基準だけでなく、公開前の確認、SEO実験中の記事を同時変更しない、未承認の広告リンクを出さない、といった事故防止ルールも含まれていました。

そこで、CLAUDE.mdの長文をそのままAGENTS.mdへコピーする方法は取りませんでした。Codexの入口をAGENTS.md、Claude Codeの入口をCLAUDE.mdとして残し、両方が共通の運営文書を参照する形にしました。

• AGENTS.md／CLAUDE.md：それぞれの入口
• OPERATIONS：権限、禁止事項、開始・完了手順
• memory：記事、SEO、ASP、WordPressなどの恒久ルール
• SESSION_BRIDGE：進行中、待ち、次の行動
• decision-log：重要な判断と理由

OpenAIの公式ドキュメントでも、Codexは作業前にAGENTS.mdを読み込むと説明されています。Claude CodeはCLAUDE.mdとauto memoryを使います。

入口は違っても、詳細な運営ルールを共通化すれば二重管理を減らせます。将来Claude Code中心へ戻す場合も、過去の設定を作り直す必要がありません。

Xserverのバックアップを隔離環境へ実際に復元した

主担当を変えるなら、記事を更新できることだけでなく、壊れたときに戻せることも確認したいと考えました。

このブログでは、Xserverに存在する同じ日付のWeb・DBバックアップを取得し、本番とは別のURLと専用DBを使う隔離環境へ手動で復元しました。

復元後は、次の項目を確認しました。

• トップページと記事ページが表示できる
• WordPress管理画面へログインできる
• 画像とPochippの商品ボックスが表示できる
• 本番URLへリダイレクトされない
• テスト環境がnoindex・nofollowになっている
• canonicalがテスト環境自身を指している
• 本番用GA4コードが出力されていない
• BASIC認証が維持されている

本番Webと本番DBへの復元や上書きはしていません。これで「バックアップが管理画面に表示されている」だけでなく、隔離環境でWordPressを起動・閲覧・管理できるところまで確認できました。

Xserver公式の主要機能ガイドは、自動バックアップを1日1回取得し、14日間保存すると案内しています。ただし、公式資料にも完全な保全を保証する機能ではない旨があります。バックアップの表示だけで安心せず、隔離した復元先で確かめたことが今回の移行では重要でした。サーバーを選んだ経緯は「エックスサーバーとConoHa WINGで迷って選んだ理由」にまとめています。

Codexへ移しても、人の操作が必要な場面は残った

一番困ったのは、ログイン状態が必要な外部サービスの確認です。

ValueCommerceの提携状況を確認しようとしたときは、管理画面がログアウト状態になっており、Codexだけでは最後まで確認できませんでした。最終的には私自身が画面を確認しました。

ほかにも、ブラウザのログイン、BASIC認証、WordPress管理画面、Xserver、Gitの権限など、現在のセッションや端末状態に左右される場面がありました。

これは「Codexは外部サービスを扱えない」という一般論ではありません。私の環境で、実際にログイン切れや権限制限によって止まった、という記録です。

そのため、現在も次の操作は人の承認や操作を残しています。

• 公開済み記事の変更
• 記事の新規公開
• 本番テーマのアップロード
• commit・push
• ASPへの問い合わせ送信や設定変更
• 本番DBの操作や復元

主担当をCodexへ変えることと、すべての権限を自動で渡すことは別です。

Claude Codeはバックアップ兼比較対象として残した

Claude Codeの設定、commands、hooks、skillsは削除していません。Codexが使えないときにブログ運営を止めないためです。

もう一つの理由は、今後も両方を比較したいからです。記事によってはClaude Codeの方が修正が少ないかもしれません。別の作業ではCodexの方が進めやすいかもしれません。

同じ判断を両方に任せて一致したとしても、それだけで正しいとは限りません。重要な判断では公式情報や実測値を優先し、必要なときだけ片方を提案担当、もう片方をレビュー担当にします。

ChatGPT・Claude・Perplexityの日常的な役割の違いは「ChatGPT・Claude・Perplexityの違いと使い分け」で扱っています。本記事の範囲は、実サイトの運営移行と共存です。

Claude CodeとCodexの料金・利用制限

料金は単純比較しにくい部分です。Claude CodeとCodexはいずれも個人向け定額プランで利用できますが、APIキーを使う場合は別の従量課金になります。また、使える量はモデル、作業の長さ、読み込むファイル、推論量、並列作業などで変わります。

以下は2026年9月13日時点の公式表示です。私の実際の支払額ではありません。

横にスクロールできます

OpenAIのCodex料金ページでは、CodexはFree、Go、Plus、Proなどに含まれると案内されています。公式の5時間あたりローカルメッセージ数の目安は、PlusでGPT-5.6 Solが10〜100、GPT-5.6 Terraが25〜200、GPT-5.6 Lunaが250〜2,000です。ただし固定上限ではなく、モデル、コンテキスト、推論、ツール利用などで消費は変わり、追加の週次上限が適用される場合もあります。

Anthropicの料金ページでは、無料プランにClaude Codeは含まれず、ProとMaxには含まれます。ClaudeのWeb・デスクトップ・モバイルとClaude Codeは同じ利用枠を使い、会話やリポジトリの規模、モデル、機能によって利用量が変わるため、固定のメッセージ数ではありません。

どちらも上限後に追加クレジットやAPI従量課金を使える場合があります。したがって、「月額だけを見てどちらが安い」とは決められません。普段の作業量、重いモデルを使う頻度、画像生成、長時間タスクを含めて判断する必要があります。

ChatGPT側のプラン選びを詳しく確認したい方は「ChatGPT Plusは月額料金に見合うか」も参考にしてください。

Codex中心へ移行する価値がある人

今回の経験から、移行を検討しやすいのは次のような人です。

• 記事本文だけでなく、画像、ファイル、Gitまで一つの流れで扱いたい
• 運営ルールがリポジトリ内に文書化されている
• WordPress APIやGitの更新後に照合する仕組みを作れる
• 公開や本番変更の承認を人に残せる
• Claude Codeを消さず、障害時の代替手段として維持できる

特に、すでにCLAUDE.mdへルールを蓄積している人は、その内容を捨てる必要はありません。ツール固有の入口と、両方が参照する共通ルールを分ける方が移行しやすいと思います。

無理に乗り換えなくてよい人

• Claude Codeで現在の運用が安定しており、画像生成を別工程にしても困らない
• ルールや復旧方法が会話の中にしかなく、まだ文書化できていない
• 新しい環境でWordPressやGitの読み書きを試す時間を取れない
• 外部サービスのログインや本番操作まで完全無人にしたい
• 料金だけを理由に、検証せずすぐ切り替えようとしている

Claude Codeで問題なく回っているなら、すぐに主担当を変える必要はありません。まず同じ記事や小さなローカル作業を両方で試し、修正時間と止まった箇所を比べる方が判断しやすいです。

私が実際に行った移行手順

1. CLAUDE.md、auto-memory、記事ルール、SEOルール、運営スクリプトを棚卸しする
2. Claude Code専用設定は残し、両方が読む共通運営文書へ恒久ルールを移す
3. Codexの入口として短いAGENTS.mdを用意し、詳細ルールの参照先を示す
4. WordPress、GSC、GA4、Git/GitHubなどを読み取りから確認する
5. テスト用下書きでWordPressの書き込みと原状復帰を試す
6. 対象を限定した公開記事更新と取得後照合を行う
7. XserverのWeb・DBバックアップを隔離環境へ復元し、復旧できることを確認する
8. Claude Codeから再開できる入口を残したまま、Codexを主担当にする

移行で重要だったのは、新しいツール用の設定を増やすことより、何が確認済みで、何が未確認かを分けることでした。

まとめ：主担当は変えたが、二者択一にはしなかった

私は、日本語記事の品質に大きな不満がなく、ChatGPT/OpenAI側の画像生成を含めて一つの環境で進めやすかったため、ブログ運営の主担当をCodexへ変えました。

WordPress REST APIの読み書き、公開記事の更新後照合、Git/GitHub、共通ルール、Xserverバックアップからの隔離復元まで確認できたことで、文章作成以外の運営も引き継げる見通しが立ちました。

一方、ValueCommerceのようにログイン状態で止まる外部サービスがあり、Gitの権限で人の操作が必要になった場面もあります。Codexへ移したからといって、公開や本番変更まで無条件に自動化したわけではありません。

現在の形は、Codexを主担当、Claude Codeをバックアップ兼比較対象として残す運用です。どちらが全面的に優れているかを決めるより、実サイトで必要な作業を一つずつ確認し、止まったときに戻れる構成を作る方が、私には合っていました。