2026年7月、CodexでWordPressのオリジナルテーマを作りました。僕が別に運営しているブログ「Money Journey」で使うためのものです。ところが、テーマの見た目を作るだけでは、そのブログを作り直したことにはなりませんでした。
すでに公開していた30記事の中に、以前使っていたAFFINGERのショートコードや専用ブロックが残っていたのです。新しいテーマへ切り替えても、本文の中身までは自動で新しい形式になりません。器を作る仕事と、そこへ過去の記事を載せ直す仕事がありました。
最終的に、この30記事すべてをCodexのブラウザ操作で書き換えました。WordPressの管理画面を開き、古い形式を確認して、直して保存する。テーマ制作の後に続いた、この地道な作業まで含めて、AIとブログを作り直した記録です。
最初の見た目には「ダサすぎる」と思った
最初に出てきたテーマを見たときの感想は、かなりはっきりしています。
「ダサすぎる。気持ち悪い」
動いてはいる。でも、自分が使いたいブログには見えない。明らかにAIが作ったと分かる見た目で、不気味の谷に近いものを感じていました。技術的に大きく苦戦するというより、デザインが思う方向へ進まないところで引っかかったのです。
そこで、ChatGPTに参考になりそうなデザインやサイトを調べさせ、そのURLをCodexへ渡しました。言葉だけで「もっといい感じに」と頼み続けるより、実際の画面を材料にして、目指す方向を合わせる方が進めやすくなりました。
参考サイトのどの部分が最終的なデザインに効いたかまでは、追えていません。ただ、何をよいと感じるかを、AIと共有する材料になったことは確かです。色や装飾を増やせば好みに近づくわけでもなく、完成したコードが、そのまま使いたい画面になるわけでもありませんでした。
トップページより、毎回読む記事の画面を見た
テーマを作っていると、トップページが整ったところで、ずいぶん進んだ気がします。けれど、ブログを読む人が時間を使うのは、記事の中です。既存の記事を入れると、デモ用の画面では見えなかったところが気になり始めました。
長いタイトルでも読みづらくならないか。見出しと本文の区切りは分かるか。画像や関連記事は、記事を読む流れの中で邪魔にならないか。PCで整って見えたものが、スマートフォンではどう折り返されるか。作りたい見た目を、実際に使う画面へ合わせていく必要がありました。
一方で、明示的には頼んでいなかった目次が実装されていたのは、うれしい驚きでした。僕が細かな部品を一つずつ指定しなくても、記事を読むために必要な機能が、形として出てきていたのです。
そうやって実物を見ながら直していくと、テーマ自体の問題と、過去の記事が持っている問題が、少しずつ分かれてきました。表示する側を直せば済むものもあれば、記事の保存内容を見直さなければいけないものもあります。新しい見た目だけを作っても、後者は残ります。
AFFINGERの装飾は、本文の中にも残っていた
今回の30記事には、旧テーマの機能を使って作った部分がありました。WordPressのショートコードは、短い記述をもとに内容や表示を呼び出す仕組みです。仕組み自体はWordPressの公式説明にもありますが、今回問題になったのは、その中にAFFINGER側の機能を前提にしたものがあったことでした。
テーマを新しくしても、過去に保存したその記述が、標準の見出しや段落へ勝手に変わるわけではありません。本文の文章を残すことと、旧テーマで表示できていた装飾を、新しい画面でも読める形にすることは、別に考える必要がありました。
対応には、いくつかの道があります。過去の記事を書き換える方法。旧テーマの記述を、新しい側でも表示できるようにする方法。互換性を残し、今後の記事から少しずつ形式を変えていく方法です。それぞれ、記事側へ仕事を置くか、表示する側へ仕事を置くかが違います。
今回は、30記事を新しい形式へ書き換える方法を選びました。この方法なら、記事の保存内容そのものを、新しい側で扱う形へ直せます。その分、テーマの完成とは別に、30記事を一つずつ確認し、変更する作業が発生します。テーマのコードを作れたことだけで、この工程まで終わるわけではありませんでした。
30記事分の画面操作を、Codexへ渡した
一記事ずつ管理画面を開き、古いショートコードや専用ブロックがあるところを確認し、新しい形式へ直す。これを30本繰り返すのは、人が手作業で行うには負担の大きい仕事です。しかも、一度入力したら終わりではなく、保存した内容が公開画面でどう表示されるかも確かめる必要があります。
そこで、この操作をCodexへ任せました。専用の投稿APIを作ったのではなく、ログイン済みのWordPress管理画面をブラウザで操作する方法です。僕がふだん使っている画面で、記事を開く、内容を書き換える、保存するといった作業を進めさせ、30記事すべてを書き換えました。
何を残し、何を書き換え、どこまで公開してよいかは、僕が決めました。その範囲を決めたうえで、画面上の反復作業をCodexへ任せました。
オリジナルテーマを作れることも面白いのですが、この作業は、AIを仕事へ入れる場面として、もっと身近です。すでに管理画面があり、操作の順番もあり、終わった状態を見て確かめられる。そういう仕事で、毎回人が同じ入力を繰り返さなくてもよくなる。その具体例になりました。
ただ、30本を対象にしたからこそ、どれを処理したかが分からなくなると困ります。「何本か直せた」では移行は終わりません。対象をそろえ、変更した記事と、まだ残っている記事を区別することまで含めて、一つの作業として扱う必要があります。
電車の中で、目次が閉じないことに気づいた
テーマを実際に使うようになると、作っているときには気づかなかった問題も出てきました。電車の中でスマートフォンからブログを見ていたとき、目次が開きっぱなしになり、閉じられないことに気づいたのです。
目次が実装されていたときは、便利な機能が加わったと感じていました。でも、あることと、使えることは違いました。自分が普段読む画面で操作して、初めて引っかかったところです。
その場でスマートフォンからCodexへ問題を伝え、リモートで開閉できるように修正させました。実際に使う場所で気づき、起きていることを伝え、直したものをまた使う。PCの前に戻ってから改めて作業を始めるのを待たずに、改善を進められました。
目次なら、開くか、閉じるか。スマートフォンで読み進めたときに、本文を邪魔しないか。機能名が並んでいるところから、自分の操作へ戻して確かめるところまでが、作る仕事の続きです。
記事を使うたびに、テーマの直しどころが分かった
テーマの更新回数は増え続けました。細かな版ごとに何を直したか、すべてを覚えているわけではありません。記事を更新し、実際の画面を見て、その中で見つかった問題と学びを、次の改修へ渡すことを繰り返していたからです。
Codexの側から改善点に気づき、改修案を提案してくることもありました。その提案を僕が確認し、許可したものを反映しています。最初に僕が全部の仕様を書き切ってから作る形だけでなく、使った結果を材料にして、次に直すところを具体化していく形になりました。
最初の見た目への違和感、30記事に残っていた旧テーマの記述、スマートフォンで閉じなかった目次。問題の種類は違います。参考になる画面を渡した方が進むものもあれば、記事の保存内容を直すものもあり、実際の端末で操作しなければ分からないものもありました。「もっとよくして」という一言だけでは、同じようには直せません。
AIが作ったものに不満があったとき、何が気に入らないか、どの画面で起きているか、どんな状態なら使えるかを渡す。すると、次の仕事が見えてきます。今回のテーマづくりは、その材料を実際の記事から拾い続ける作業でもありました。
自社で試すなら、すでに繰り返している画面から
自社で試すなら、毎回同じ画面を開き、似た入力をして、保存後の結果を確かめている作業から、一つ選んでみます。すでに使っている画面なら、どこまで任せるか、何が変わったら困るかも、具体的に考えられます。
例えば、今回なら「30記事を新しい形式へそろえる」という対象がありました。何を残すかを決め、同じ操作を繰り返し、処理した記事を確認する。そのように、対象と、変えてよいものと、終わりの状態を決めると、AIへ任せる仕事が具体的になります。
僕にとって大きかったのは、最初に出てきた見た目に不満があっても、そこで終わらなかったことです。参考を探し、実物を使い、記事を直し、また使う。30記事の移行も、電車の中で見つけた目次の問題も、その続きとして直していけました。
テーマ制作そのものの経緯は、Money Journeyの制作記録にも残しています。AIへ任せる仕事の範囲をどう決めるかについては、10万円の事業実験で、最初の商品案を作り直した話もあわせて読んでみてください。
