Fahren Labのサイトデザインを、一般的なブログに近い見た目から、明るくクリーンな事業サイト寄りのデザインへ変更しました。
改修のきっかけは、記事ページを見たときに感じた、単純な違和感です。
「全体的に文字が小さい気がする」
最初は、本文の文字サイズを大きくすれば解決すると考えていました。しかし、実際に数値を変更しても、思ったほど読みやすくなりません。
画面を見比べていくと、問題は文字サイズだけではありませんでした。
画面の左右に余白が多く、本文とサイドバーが中央に細く収まっていたため、コンテンツ全体が縮小されているように見えていたのです。
そこで今回は、文字サイズだけでなく、サイトの横幅、カラム比率、ヘッダー、トップページの印象、外部サービスへの導線まで含めて見直すことにしました。
有料の親テーマは直接変更せず、専用の子テーマを作成。Local上に検証用のWordPress環境を用意し、実際の画面を確認しながらCodexと修正を繰り返しました。
この記事では、Fahren Labをどのような流れで改修したのか、途中で起きた失敗も含めてまとめます。
「文字が小さい」という違和感から始まった
改修前の記事ページでは、本文とサイドバーが画面中央に細く収まり、左右に広い余白が残っていました。
本文の文字サイズだけを見れば、極端に小さいわけではありません。
それでも記事全体が小さく感じられたのは、画面幅に対してコンテンツが使っている範囲が狭かったためです。
文字を大きくするだけでは、今度は本文だけが不自然に大きくなります。読みやすさを改善するには、文字サイズと一緒に、本文幅やサイドバーとの比率も見直す必要がありました。
また、サイト上部の濃紺を基調としたデザインは、制作ラボらしい雰囲気がある一方で、少し暗く、技術寄りに見えすぎるところも気になっていました。
そのほかにも、いくつか改善したい点がありました。
サイト名が初期設定に近く、ブランドとしての印象が弱いこと。「New Articles」「Recent Posts」といった英語表記が、日本語サイトの中で浮いていること。サイドバーの文字や項目が左側に詰まり、少し窮屈に見えること。
さらに、note、X、Amazon著者ページへの導線や、生成AIの利用方針、Amazonアソシエイトの表示も整理したいと考えていました。
今後、Fahren Labを電子書籍、生成AI、自作アプリ、Web運営の実践をまとめる場所として育てていくのであれば、単に見た目を整えるだけでは足りません。
記事を読みやすくしながら、このサイトが何を扱っているのかも伝わる構成にする必要がありました。
以前は、少し変えるだけでも簡単ではなかった
僕がブログに触れ始めたのは、今回が初めてではありません。
10年以上前からBloggerでブログを運営し、過去にはWordPressでブログを作ったこともあります。
管理画面から記事を書いたり、テーマを変更したりする程度であれば、まったく経験がないわけではありませんでした。
一方で、用意された設定の範囲を超えて、少し踏み込んだ変更をしようとすると、途端に難しくなります。
文字サイズや余白、本文の横幅を変えるだけでも、テーマのどの部分が表示を制御しているのかを調べ、CSSを書き換える必要がありました。
コードを追加しても思ったように反映されなかったり、一つの場所を直したことで別の表示まで崩れたりすることもあります。
特にBloggerでは、僕が知りたい内容を日本語で詳しく解説しているサイトが少なく、海外の情報や断片的なコードを頼りに試行錯誤することもありました。
WordPressはBloggerより情報量が多いものの、使用しているテーマによって構造が異なります。解説どおりにコードを貼り付けても、自分の環境ではそのまま動かないことがあります。
そのため以前は、
「ここをもう少し広くしたい」
「文字を少しだけ大きくしたい」
「色や余白を変えて比較したい」
と思っても、修正に必要な手間を考えて、そのままにすることが少なくありませんでした。
今回の改修で大きく変わったのは、この部分です。
以前は「自分でコードを書けるかどうか」が、変更を試すための入口にありました。
今回は、実際の画面を見て感じた違和感を言葉にし、Codexに実装してもらう形で進められました。
親テーマを直接変更せず、子テーマを作った
Fahren Labでは、有料のWordPressテーマであるXwriteを使用しています。
親テーマのファイルを直接書き換える方法もありますが、テーマがアップデートされたときに、変更した内容が上書きされる可能性があります。
そのため、今回の改修では親テーマを直接変更せず、専用の子テーマを作成しました。
作業を始める前に、UpdraftPlusで既存サイトのバックアップを取り、現在使用している子テーマと親テーマの構造を確認しました。
親テーマの本体やライセンス情報、データベースを作業用の成果物に含めないことも、最初に方針として決めています。
さらに、本番サイトを直接編集するのではなく、Localをパソコンにインストールし、検証用のWordPress環境を用意しました。
Codexには、Local上の子テーマフォルダを開かせ、CSSやPHPを直接編集してもらいます。
修正後はブラウザを更新し、表示がどう変わったかを確認。その結果を見ながら、次の修正を依頼する形で進めました。
LocalとCodexの組み合わせが非常に快適だった
今回の作業で特に便利だと感じたのが、LocalとCodexの組み合わせです。
従来のように、変更するたびに子テーマをZIP化し、本番サイトへアップロードする必要がありません。
Codexがファイルを修正した後、Local上のサイトをブラウザで更新すれば、変更結果をすぐに確認できます。
完全なリアルタイム更新ではありませんが、感覚としてはそれに近いものでした。
「まだ文字が小さく感じる」
「左右の余白が広く、記事全体が細く見える」
「この色だと少し暗い」
「サイドバーの項目が左に詰まって見える」
このような、実際の画面を見なければ分からない違和感を伝えると、Codexが関連する箇所を探して修正します。
その結果をブラウザで確認し、必要であれば、さらに調整を依頼する。
この短い試行錯誤を何度も繰り返せることが、非常に快適でした。
以前は、変更したい場所があれば、まず関連するCSSやテーマの構造を調べる必要がありました。
今回は、実際のテーマファイルをCodexに確認してもらいながら進められます。
技術的な作業の負担が下がったことで、以前なら諦めていた細かな調整まで気軽に試せるようになりました。
もちろん、Codexに完成形を一度で作らせたわけではありません。
Codexが修正を担当し、僕が実画面を見て方向を判断する。
今回の改修では、この役割分担がうまく機能しました。
文字サイズより先に、レイアウトの比率を見直した
当初は、本文の文字サイズを大きくすることから始めました。
しかし、20px前後まで大きくしても、サイト全体が小さく見える問題は解消しませんでした。
原因は、文字そのものよりもレイアウトの比率にありました。
そこで、サイト全体の最大幅と、本文、サイドバーの比率を見直しました。
最終的な主な設定は、次のとおりです。
- サイト全体の最大幅：1360px
- 記事本文の最大幅：820px
- サイドバー幅：320px
- 記事とサイドバーの間隔：32px
- PCの記事本文：19px
- スマートフォンの記事本文：18px
本文は途中で20px前後まで大きくしましたが、実際の画面では少し大きく感じたため、最終的には19pxへ戻しました。
単純に文字を大きくするのではなく、本文が使える横幅を広げたことで、記事が画面の主役として見えるようになりました。
サイドバーについても、「Recent Posts」だけを個別に直すのではなく、プロフィール、カテゴリー、各ウィジェットの左余白と見出し位置を統一しました。
カテゴリーラベルは背景色と文字色のコントラストを強め、記事カード、見出し、本文、補助情報の文字サイズも整理しています。
デスクトップだけでなく、スマートフォンの表示も確認しながら調整しました。
トップページの印象を明るくした
記事ページの調整と並行して、トップページのヒーロー部分も作り直しました。
改修前は、濃紺の背景に「BUILD」と表示したカードを配置した、制作ラボらしいデザインでした。
格好よさはありましたが、Fahren Labが目指す方向と比べると、少し暗く、技術寄りに見えすぎていました。
最初は、マスコットキャラクターのトバリくんを配置する案も試しました。
しかし、背景の上にキャラクターを置くだけでは、サイト全体の印象を変えるには不十分でした。
そこで、キャラクターを追加するのではなく、ヒーローの背景全体を見直すことにしました。
最終的には、ノート、ペン、ノートPC、観葉植物が見える明るい個人用ワークスペースを右側に配置しています。
文字を置く左側には、深いオリーブグレーのオーバーレイを重ねました。
テーマカラーも、濃紺からオリーブグレー、セージグリーン、生成りを中心とした配色へ変更しています。
企業のオフィスではなく、個人が自分の場所で制作や検証を続けている雰囲気を意識しました。
ヒーロー部分の文言は、次の内容に整理しました。
AI × PUBLISHING × WEB
個人の可能性を、実験と検証で形にする。
生成AI・自作アプリ・電子書籍・Web運営。個人が収益を生み出す仕組みを、実践と検証の記録から組み立てます。
当初は「個人の可能性を、実験からかたちに。」という表現も検討しました。
しかし、ひらがなが続いて見えることや、サイトの姿勢をもう少し具体的に伝えたかったことから、現在の表現に変更しました。
note、X、Amazonへの導線を整理した
改修前のヒーローには、「最新の記事を見る」というボタンを置いていました。
しかし、ボタンのすぐ下には新着記事が表示されています。
ページ内を移動させるボタンとしては役割が弱く、操作後の挙動にも少し違和感があったため、削除することにしました。
代わりに、その場所へ外部サービスへの導線をまとめました。
現在は、ヒーロー部分からnote、X、Amazon著者ページへ移動できます。
noteとXには、それぞれのサービスを識別できるアイコンを使用しました。
Amazon著者ページへのボタンも同じ高さにそろえ、アフィリエイトリンクであることが分かるように「広告」と表示しています。
サイト内の主なUIも日本語化しました。
「New Articles」は「新着記事」に変更し、サイドバーの見出しも日本語を基準に整えています。
英語表記を完全に排除したわけではありませんが、利用者が操作する部分は、日本語で意味が分かることを優先しました。
AI利用案内とAmazon表示をサイト全体に追加した
Fahren Labでは、記事、画像、サイト制作に生成AIを補助的に使用しています。
一方で、AIが自動的に生成した内容を、そのまま掲載しているわけではありません。
そこで、個別の記事だけではなく、サイト全体の方針として、次の案内を掲載しました。
※当サイトでは、コンテンツ制作に生成AIを補助的に活用し、運営者が内容を確認・編集しています。
この表記を設けた背景には、Amazonアソシエイトの規約改定もあります。
2025年11月の改定では、Creators APIの導入に伴い、自動化されたソフトウェアによる操作を対象とするエージェント規約や、プログラム・コンテンツでのAI生成コンテンツと機械学習モデルの利用に関する追加のガイドラインが設けられました。
この改定によって、生成AIを補助的に使ったすべての記事に、読者向けのAI利用表示が一律に義務付けられたわけではありません。
ただ、AIや自動化を利用する際の責任や透明性が、これまで以上に重視される方向性は明確です。
そこでFahren Labでは、規約上の最低限だけを満たすのではなく、生成AIを文章、画像、サイト制作の補助として利用し、公開前には運営者が内容を確認・編集していることを、サイト全体で明示することにしました。
フッターには、Amazonアソシエイトの参加者表示も追加しました。
Amazonのアソシエイトとして、Fahren Labは適格販売により収入を得ています。
AIの利用案内とAmazonアソシエイトの参加者表示は、目的の異なるものです。そのため、一つの文章にまとめず、それぞれの役割が分かる形で掲載しています。
デザインを整えるだけでなく、AIの利用方法や広告収益との関係を分かりやすく示すことも、サイトを継続的に運営するうえでは必要だと考えています。
ロゴとフッターを仕上げた
ヘッダーのサイト名は、画像ロゴではなく「Fahren Lab.」というテキストロゴにしました。
最後のピリオドだけをアクセントカラーにすることで、シンプルなまま、初期設定とは異なる印象を持たせています。
通常のヘッダーだけでなく、画面をスクロールした後に表示される追従ヘッダーにも、同じロゴデザインを適用しました。
フッターのコピーライトは、サイトを開始した2026年を基準にしています。
2026年中は「2026」、2027年以降は「2026-2027」のように、自動で現在の年まで表示される仕組みにしました。
一度作って終わりではなく、今後の更新や運営を続けやすい構造にすることも、今回の改修で重視した部分です。
本番導入で起きた2つのトラブル
Local上では問題なく動いていても、本番サイトへ導入すると、別の問題が発生することがあります。
今回も、子テーマを本番サイトへアップロードする段階で、2つのトラブルが起きました。
「style.cssがありません」と表示された
最初に作成した子テーマのZIPをWordPressへアップロードすると、「style.cssがありません」と表示され、テーマとして認識されませんでした。
原因は、ZIP内部のファイルパスです。
Windows形式の区切り文字が使われていたため、WordPressがテーマ直下にあるはずのstyle.cssを正しく認識できませんでした。
ZIP内部のパスをWordPressが認識できる形式で作り直すことで解決しました。
以後は、同じ問題が起きないよう、確認済みのZIPにはwordpress-compatibleと分かる名前を付けて管理しています。
カスタマイザーで重大なエラーが出た
子テーマを有効化した後、WordPressのカスタマイザーを開くと、重大なエラーが発生しました。
親テーマ側から渡される設定値の中に、文字列ではなく、配列やオブジェクトが含まれる場合があったことが原因です。
子テーマ側の処理は、すべての値を文字列として扱う前提で作られていました。
そのため、配列やオブジェクトを文字列として置換しようとして、エラーが発生しました。
文字列の場合だけ置換処理を行い、それ以外の値はそのまま返すように修正することで解決しました。
Localで画面が表示されることを確認するだけでなく、テーマのインストール、カスタマイザー、スマートフォン表示など、本番環境でしか分からない部分も確認する必要があります。
PlusプランのCodex週次利用枠を約50％消費した
今回の一連の作業では、当時表示されていたChatGPT PlusプランのCodex週次利用枠を、約50％消費しました。
決して軽い作業量ではありません。
記事レイアウトの修正だけでなく、トップページの再設計、ロゴ、サイドバー、外部導線、フッター、開示表示、本番導入後の不具合修正まで依頼したため、相応に利用枠を消費しました。
ただ、これらを自分一人で調べながら修正する場合、かなりの時間が必要だったと思います。
特に、テーマ固有の構造やPHPのエラーまで含めて考えると、途中で作業を止めていた可能性もあります。
利用枠は大きく減りましたが、サイト全体を一通り改修できたことを考えれば、個人的には十分に価値のある使い方でした。
Codexを使用すれば、何でも無制限に作れるわけではありません。
それでも、以前は知識や調査時間が壁になっていた作業を、現実的な時間で進められるようになったことは、大きな変化だと感じています。
改修して分かったこと
今回の改修で最も強く感じたのは、文字を大きくするだけでは、読みやすいサイトにはならないということでした。
本文の横幅、左右の余白、サイドバーとの比率、行間、見出しとの強弱が組み合わさって、記事全体の見え方が決まります。
トップページも同じです。
色と写真を変えるだけで、同じサイトでも「暗い制作ラボ」から「個人の実践を記録する明るい事業サイト」へ、印象が大きく変わりました。
そして、特に便利だったのが、LocalとCodexを組み合わせた作業方法です。
修正結果をすぐに画面へ反映し、人間が違和感を見つけ、その場で次の修正を依頼できます。
以前はCSSの知識や情報収集の負担が壁になっていました。
今回は、僕が実画面を見て方向を判断し、Codexが技術的な実装を担当することで、細かな違和感をすぐに修正へつなげられました。
AIは、複数の修正案を短時間で出したり、コードを実装したりすることには向いています。
ただし、19pxと20pxのどちらが読みやすいのか、サイトの色が暗すぎないか、写真と文字のバランスが自然かといった「ちょうどよさ」は、実際の画面を見なければ判断できません。
今回のサイト改修は、AIにサイト制作を丸投げした事例ではありません。
人間の目と感覚を、AIによって素早く実装へ反映した事例です。
10年以上前にBloggerやWordPressを触っていた頃と比べると、サイトを自分の感覚に合わせて変更するためのハードルは、かなり下がったと感じました。
まとめ
今回完成した子テーマは、「Fahren Lab Business 1.4.26」として運用しています。
記事の横幅と文字サイズを見直し、トップページの配色と写真を変更し、ロゴ、サイドバー、フッター、外部サービスへの導線も整理しました。
さらに、AIの利用案内、Amazonアソシエイトの表示、親テーマの更新を妨げない子テーマ構造など、運営を続けるための部分も整えています。
途中では、ZIPのファイルパスやカスタマイザーの値の型が原因となる不具合も起きました。
それでも、Local上で画面を確認しながらCodexと修正を繰り返すことで、原因を切り分け、完成まで進めることができました。
以前は、CSSやPHPの知識が不足していると、少しの変更でも簡単ではありませんでした。
現在は、何を変えたいのかを人間が考え、技術的な実装をAIに補助してもらう方法が使えます。
サイトは、一度完成させて終わるものではありません。
実際に使いながら違和感を見つけ、必要な部分を少しずつ直していく。
今回作ったのは、完成されたデザインというよりも、今後の活動に合わせてFahren Labを育てていくための土台なのだと思います。
