Codexにブログ運営をもっと任せたい｜はてなブログからAstro＋Cloudflareへ移行した理由

AIで記事を書けるようになっても、過去記事の修正やデザイン変更、公開前の確認まで毎回手作業で行うのは負担になります。

一方で、ブログの設定やコードをすべて理解しているわけではないので、AIにサイトを触らせて壊れるのは怖い。最後に自分で確認することならできても、細かな作業を毎回手で行うのは負担になります。

私も、ChatGPTで企画や相談を行い、Codexで記事を作る運営はできていました。ただ、AIにサイトを触らせて壊れるのは怖く、最後の公開・反映やサイト側の変更には、はてなブログの管理画面で人間が作業する工程が残っていました。

そこで、記事作成以外のブログ作業もCodexに依頼しやすくし、人間は確認と公開判断へ寄せやすい環境に移しました。この記事では、そのためにはてなブログからAstro＋Cloudflareへ移行した理由と、移行後に変わった運営方法を紹介します。

17記事の移行と本番公開は完了しています。この記事は移行後最初の新規記事として、新しい通常運営フローで作成しています。ただし、移行が完了したことと、長期的に運営しやすいことは別です。継続運営の負担や検索・計測への影響は、今後確認していきます。

Codexで記事は書けても、最後は自分で作業していた

はてなブログ時代も、記事の企画や下書きにChatGPTを使い、Codexで記事ファイルや管理情報、CSSを確認・修正していました。AIを使った記事作成そのものに困っていたわけではありません。

ただ、最後の公開・反映だけは、はてなブログの管理画面で行っていました。

当時の流れは、次のようなものでした。

段階	はてなブログ時代
企画・相談	ChatGPT
記事作成・ファイル確認	Codex
管理情報・CSS	ファイルで管理
最後の公開・反映	人間が管理画面で作業
読者が見るサイト	はてなブログ

はてなブログが悪かったという話ではありません。私の運営方法が、記事本文だけでなく、過去記事の修正やサイト全体の変更まで広がったため、公開側も同じ流れで確認できるようにしたくなりました。

移行して、Codexに任せやすくしたかったこと

移行の主な理由は、Astroを使いたかったからではありません。Codexに、記事を書く作業以外も依頼しやすくしたかったからです。

過去記事を見ながら修正する

たとえば、次のような依頼です。

• 「この記事の説明を更新して」
• 「関連記事へのリンクを追加して」
• 「公開済み記事の表現を今の情報に合わせて直して」

記事がファイルとしてまとまっていれば、Codexに対象記事と関連する管理情報を確認させながら修正を依頼できます。変更後はpreviewを見て、意図どおりかを人間が確認します。

デザインやサイト側の変更も作業として渡す

記事本文だけでなく、記事一覧、レイアウト、CSS、metadata、内部リンクなども、ブログ運営の一部です。

これらを別々の管理画面で手作業するのではなく、同じサイトのファイルを見ながら変更できるようにしました。細かなコードをすべて自分で書くことが目的ではなく、変更したい内容を言葉で依頼し、Codexに対象箇所を調べて作業してもらうためです。

ChatGPTとCodexの役割分担や、企画・レビューとファイル作業の分け方は、ChatGPTとCodexをブログ運営でどう使い分けているかで整理しています。

公開前の確認と変更履歴を残す

AIにサイトを触らせるなら、変更した結果を見られることが重要です。

今回は、Codexが修正する、buildやpreviewで確認する、Gitに変更履歴を残す、問題があれば戻す候補を持つ、という流れを作りました。AIだから安全なのではなく、AIに触らせるからこそ確認できる状態を残す考え方です。

自分の役割は「作業」より「確認」へ寄せる

移行後も、人間の仕事がなくなったわけではありません。自分が残す役割を、細かなファイル操作から、依頼・確認・公開判断へ寄せたイメージです。

基本的な流れは次のとおりです。

1. 何を変更したいかを決めて、ChatGPTやCodexへ依頼する
2. Codexが記事やサイト側のファイルを確認・修正する
3. buildやpreviewで変更結果を見る
4. 事実関係や表示を人間が確認する
5. 公開してよいかを人間が判断する

実際、この記事を作っている途中でも、previewを見て「専門的な内容が続き、読む前から長く感じる」と判断した場面がありました。そこで長文記事のレイアウト改善をCodexへ依頼し、文字サイズや行間、H2・H3の余白、目次の表示方法を調整してもらいました。

その後もpreviewを確認し、まだ情報を拾いにくいと感じたため、4つのメリットを先に見せる要約と、Before / Afterを読みやすいHTMLへ追加で変更しました。以前ならCSSや表示箇所を自分で調べながら進めていた作業ですが、今回は希望を伝えて実装を任せ、自分は画面を見て「良くなったか」「まだ直すか」を判断する側に寄せられました。細かな実装を任せやすくなった一方で、改善の方向と公開判断は人間に残っています。

記事の内容が事実に合っているか、リンク先が意図どおりか、表示が崩れていないかは、AIに任せきりにしません。

Codexに任せる範囲と、人間が確認する範囲を分けた理由は、ブログ運営でCodexに任せない作業｜自動化にしない理由と人間が確認するポイントにもまとめています。

Before / Afterで見る変化

変わったのは、ツールが増えたことより、記事と公開サイトを同じ運営フローで確認しやすくしたことです。

Astro・Git・Cloudflareは何のために使っている？

技術名だけを見ると難しく感じますが、今回の役割は分けて考えると単純です。

名前	今回の役割
Astro	ブログのページを作る
Git	変更履歴を残す
Cloudflare	作ったブログを公開する
Codex	記事やサイトのファイルを変更する

正確には、Astroでサイトを構築し、Cloudflare Workers Static AssetsでHTMLや画像などを公開しています。Astroが公開サーバーになるわけでも、Codexが無条件に公開するわけでもありません。

Astro公式のCloudflare向けデプロイガイドでは、AstroサイトをCloudflare Workersへデプロイする構成が案内されています。Cloudflare公式のWorkers Static Assets資料では、HTML・CSS・画像などをWorkerとともに扱う仕組みが説明されています。

ブログのフォルダや管理情報をどのように分けているかは、個人ブログをCodexで管理するために作ったフォルダ構成で詳しく紹介しています。

公開基盤は追加固定費なしで始められた

今回は独自ドメインを購入せず、Cloudflareのworkers.devでブログを始めました。そのため、ブログ公開基盤について新たな固定費をかけずに開始できました。

2026年8月時点のCloudflare公式資料では、Workers Static Assetsの静的アセットリクエストは無料・無制限、Assets保存にも追加料金がないと説明されています。また、workers.devは独自ドメインなしで始められるFree websiteとして案内されています。

ただし、Workerのコード実行リクエストやFreeプランの制限は別にあります。利用量や構成で条件が変わるため、「完全無料」「すべて0円」「将来も必ず無料」とは書きません。ドメイン、外部サービス、ChatGPTやCodexの利用費も別です。

今回言えるのは、独自ドメインを使わず、ブログ公開基盤の追加固定費なしで開始したという範囲です。詳細はCloudflare Workersの料金資料、Static Assetsの課金説明、workers.devの公式説明を確認してください。

17記事を実際に移して、簡単ではなかったところ

17記事を移す作業では、本文を表示できるようにするだけでなく、読者が迷わず読めるか、検索や計測が引き継がれるか、問題が起きたときに戻せるかを確認しました。

記事やリンクが正しく表示されるか

記事本文、URL、内部リンク、アイキャッチ、記事一覧、404ページなどを確認しました。公開後に読者が見る場所を一つずつ確認する必要があり、本文の移し替えだけでは終わりませんでした。

検索やアクセス計測を引き継げているか

canonical、sitemap、robots、GA4、Search Consoleを確認しました。Search Consoleではsitemap-0.xmlが一時的に取得できない表示になりましたが、生成されたXMLやURLを確認した範囲で異常は見つかりませんでした。

原因を断定できない状態で、不要な再buildや再deployを急ぐことはしませんでした。Search Console側の表示更新も含めて、監視対象として残しています。

問題が起きたとき戻せる状態か

Gitで変更履歴を残し、過去のcheckpointやrollback候補を確認できるようにしました。Windows環境ではdev起動が安定しない場面もあったため、同じ環境で作業を続けるのではなく、clean環境でinstall、build、previewを分けて確認しました。

移行時に確認した項目の詳しい管理方法は、ブログ公開後にCodexへ情報を同期する運用にもつながります。公開後も、記事台帳や次の作業へ情報を戻す必要があるためです。

全部AI任せにはしない

AIに任せる範囲を広げても、人間が何もしなくなるわけではありません。

Codexに記事やサイトの作業を依頼できても、previewの確認、エラーの確認、事実関係の確認、公開判断は残ります。技術をすべて暗記しなくても作業を進めやすくはなりますが、結果を見てOKかNGかを決める役割までなくなるわけではありません。

こんな人なら検討する価値がある

今回のような構成が向いていそうなのは、次のような人です。

• AIで記事作成を試していて、過去記事の修正も任せたい
• 記事だけでなく、デザインやサイト設定もAIに相談したい
• 過去記事が増えて、どこを直せばよいか管理しづらい
• CSSや設定を自分だけで触るのは怖いが、公開前の確認はできる
• 作業を依頼し、previewを見て公開判断する運営に変えたい

一方で、次のような場合は、はてなブログなどの管理画面だけで十分かもしれません。

• 書いてすぐ管理画面から公開できればよい
• AIには文章作成だけ頼めればよい
• 過去記事やデザインの管理に困っていない
• サイト構成や公開方法を変える必要を感じていない

Astroの方がはてなブログより優れている、という比較をしたいわけではありません。自分がAIへ任せたい作業の範囲と、公開前に確認できる時間に合わせて選ぶものだと思います。

まとめ：Codexに任せる範囲を広げ、確認と判断へ寄せた

Codexに記事作成以外のブログ作業も任せやすくし、自分は確認と公開判断へ寄せられる運営にしたかったからです。

今回の移行で、記事本文、過去記事の修正、デザイン、サイト設定、変更履歴、build、preview、公開確認を同じ運営の流れで考えやすくしました。

一方で、完全自動化や放置運営になったわけではありません。人間が依頼内容を決め、事実を確認し、previewを見て、公開してよいか判断する工程は残しています。

17記事の移行と本番公開は完了していますが、SEO、PV、収益、作業時間、長期的な運営負担がどう変わるかはまだ確認していません。移行後最初の新規記事として、この構成での通常運営を続けながら検証していきます。