CodexでWordPressテーマを作り、AFFINGERの30記事を移行した実践記録

Codexで、WordPressのオリジナルテーマを作りました。

でも、実務で大変なのは、テーマを作ることだけではありませんでした。

対象のブログには、すでに30記事が入っていました。以前使っていたテーマはAFFINGERです。記事の中には、AFFINGERのショートコードや専用ブロックが残っています。

新しいテーマへ切り替えるだけでは、過去の記事が新しいデザインにうまく合いません。

そこで最終的に、30記事すべてをCodexのブラウザ操作で書き換えました。

最初のテーマは、明らかにAIが作った見た目だった

最初に出てきたテーマを見たときの感想は、正直よくありませんでした。

「ダサすぎる。気持ち悪い」

不気味の谷に近いというか、明らかにAIが作ったと分かる見た目でした。動いてはいる。でも、自分が使いたいブログには見えませんでした。

技術的に大きく苦戦したわけではありません。ただ、デザインが思うようにならない。

そんなときは、ChatGPTに参考になりそうなデザインやサイトを調べさせ、そのURLをCodexへ渡しました。最終的にどのサイトの何が効いたのかまでは追えていません。それでも、「もっといい感じにして」と言葉だけで伝えるより、目指す見た目をURLで渡すほうが改修を進めやすくなりました。

今回の経験では、参考デザインは完成形をコピーするためではなく、AIとの認識を合わせるための材料として役立ちました。

トップページより、実際の記事で使えることが大事だった

テーマを作るときは、トップページの見た目に目が向きます。

ただ、ブログで読者が長く見るのは各記事です。

実際の記事を入れると、長いタイトル、見出し、画像、関連記事、スマートフォン表示など、最初のデモ画面だけでは分からなかった問題が出てきます。

一方で、明示的に依頼していなかったのに、記事には目次まで実装されていました。記事を読むために必要な機能まで形になっていたのは、うれしい驚きでした。

ただし、実際にスマートフォンで使ってみると、目次が開きっぱなしになり、開閉できない問題が見つかりました。機能があることと、実際の利用環境で問題なく使えることは別でした。

テーマは、見た目のテンプレートを一度生成して終わりではありません。本物の記事を入れ、読んで、気づいたことを直していく必要があります。

旧テーマのコードが、30記事に残っていた

今回のブログでは、以前AFFINGERを使っていました。

WordPressの記事には、テーマ固有のショートコードや専用ブロックが入ることがあります。その状態でテーマだけを新しくすると、表示が崩れたり、新しいテーマの見た目に合わなくなったりします。

考えられる対応は、主に次の3つでした。

1. 過去記事を新しい形式へ書き換える
2. 旧テーマのコードを、新しいテーマ側で引き継いで表示する
3. 互換性を残しつつ、新しい記事から少しずつ形式を変える

今回は、30記事を新しい形式へ書き換える方法を選びました。

30記事の書き換えも、ブラウザ操作で任せた

30記事を一つずつWordPressの管理画面で開き、古いショートコードや専用ブロックを確認し、新しい形式へ直す。

内容を考える仕事ではありませんが、人が手作業で繰り返すには負担が大きい工程です。

そこでCodexにブラウザを操作させ、30記事すべてを書き換えました。専用の投稿APIを作ったのではなく、ログイン済みのWordPress管理画面を、人間と同じように操作する方法です。

何を残し、何を書き換え、公開してよいかは人が決めます。そのうえで、画面を開く、入力する、保存する、表示を確かめるといった反復作業をAIへ渡しました。

AIの役割は、判断をなくすことではありません。人が判断すべきことへ時間を戻すことです。

記事を更新するたびに、テーマも育っていった

テーマの更新回数は増え続けています。

途中の細かなバージョンで何を直したか、すべてを覚えているわけではありません。毎回、記事を更新する中で見つかった問題と学びを、次の改修へ反映するフライホイールを回していたからです。

Codexが改善点に気づき、テーマ側の改修を提案することもありました。僕への確認を挟み、内容を見て許可したうえで反映しています。

今は、電車の中でスマートフォンからブログを確認し、目次が開きっぱなしになっていることに気づきました。そこでスマートフォンからCodexへ伝え、リモートで開閉できるように修正させています。

さらに欲が出て、見た目や使いやすさだけでなく、コード上の脆弱性を減らすための見直しも依頼しました。僕からは細かな修正項目を一つずつ指定せず、かなり大まかに伝えています。それでもCodexが必要な確認と改修を具体化し、僕への確認を挟みながら進めています。

ただし、これは安全性を保証するものではありません。具体的な変更内容の確認と、公開後の継続的な更新は今後も必要です。

AIで作るより、使いながら改善できることが大きい

今回分かったのは、AIならWordPressテーマを一発で完成させられる、ということではありません。

最初の見た目は思いどおりではありませんでした。旧テーマのコードも残っていました。実際の記事を入れなければ分からない問題もありました。

それでも、次の流れを繰り返せます。

1. ChatGPTで参考情報を探す
2. Codexへ参考URLと目的を渡す
3. 本物の記事で使う
4. PCやスマートフォンで問題を見つける
5. 問題と学びを次の作業へ引き継ぐ
6. Codexが改修案を具体化する
7. 人が確認して許可し、また使う

作って終わるのではなく、使う、気づく、直す、また使う。

この改善ループを自分たちで回せることが、AIを実務へ入れる一番大きな変化だと感じています。

いきなりWordPressテーマを作る必要はありません。まずは、毎回同じ画面で繰り返している作業を一つ選び、どこまでAIへ渡せるか試すところから始められます。

テーマ制作そのものの経緯は、代表の公開実験「Money Journey」でも紹介しています。

CodexでWordPressテーマを作った。21回直して、投稿まで任せた

---

AIやWebは、利益改善のための手段です

セキオラは、手段から入らず事業の構造を見て、売上を増やす、ムダを減らす、仕事をラクにするために必要な施策を選びます。提案だけでなく、実装と改善まで支援します。