別に運営しているブログで、アフィリエイトリンクの見え方と、スマートフォンの表レイアウトを改善しました。
CSSを直接修正すること自体よりも、「何を変更したか分からなくなる」「元の状態を確認できなくなる」ことを避けたいと考えました。そこでCodexへ変更範囲を限定してCSS修正を依頼し、変更前のファイルと修正内容を残しました。
Codexを使えば安全になる、という機能紹介ではありません。今回の実例で確認できたことと、運用として人間が行う工程を分けて紹介します。
実際にブログのCSS改善をCodexへ依頼した
2026年8月8日、別に運営しているブログの追加CSSで、アフィリエイトリンクの見え方とスマートフォンでの操作性を調整しました。
記録に残っている変更は、記事内の商品検索リンクと、もしもかんたんリンクのCTAです。商品検索リンクは緑系の塗りボタンにして、関連記事リンクとは役割を分けました。もしもかんたんリンクには、スマートフォンでも押しやすいように最小高さ48px、文字サイズ、余白、角丸を設定しています。
Amazon・楽天市場・Yahoo!ショッピングの識別色は残しました。hover、active、focus-visibleの状態も追加しています。これは、マウスを乗せたとき、押したとき、キーボード操作で選択したときの表示です。
同じ日に、スマートフォンで表が横に広がる問題に対して、表を横スクロールできるようにするCSSも調整しました。最初の変更後に、表の幅をwidth: 100%とmax-width: 100%に整理し、見出し幅の指定が妨げにならないようにスマートフォン時の.simple-table thを調整しています。
ここで扱っているのは、CSSの変更記録に残っている範囲です。クリック数や表示速度が改善した、といった効果までは、今回の記録から判断していません。
CSS以外を変更しないように範囲を限定した
今回の記録では、変更対象をブログの追加CSSファイルに限定しました。
記事本文のHTMLやJavaScript、はてなブログ管理画面は変更していません。CTAの見た目を変えるために、記事本文へボタンを追加したわけでもありません。
この指定により、今回確認する対象はCSSの変更内容に絞れます。HTMLやJavaScriptまで同時に変わっていないかを、別の問題として追いかけずに済みます。
作業を分けて確認地点を作る考え方は、長いブログ運営タスクをCodexで分割して進める方法でも整理しています。今回は、その考え方をCSS改善へ適用した例です。
変更前のCSSを残してから修正した
変更前のCSSは、CTA、表の横スクロール、スクロールコンテナ調整の作業ごとに別のバックアップフォルダへ保存されています。
| 改善内容 | 保存したもの |
|---|---|
| CTAの視認性・操作性 | CTA調整前のCSS |
| 表の横スクロール | 横スクロール追加前のCSS |
| スクロールコンテナ調整 | コンテナ調整前のCSS |
これは、Codexが自動で作ったバックアップを使った、という話ではありません。ブログの運用ルールに沿って、変更前のファイルを別途保存したものです。
変更前CSSを残しただけで、どの環境でも自動的に元へ戻せるわけではありません。問題が起きたときに、変更前の状態を確認する材料として使います。
修正後に「何を変えたか」を確認した
CSSを修正した後は、完了報告と実ファイルを照合します。今回確認できる変更対象は、CSSのボタン色、サイズ、余白、状態表示、スマートフォンの表の横スクロール、表の幅と見出し幅の調整です。
記事HTMLとJavaScriptは変更対象外でした。Gitの差分管理やCodexの機能を使った、という意味には広げません。今回の記事で扱っているのは、ローカルに保存した変更前CSSと、修正後の対象ファイルを確認した運用です。
ChatGPTでも目的と変更結果を確認した
Codexの完了報告をそのまま公開判断に使うのではなく、ChatGPT側でも目的と変更範囲を確認します。
今回の確認では、CTAと表の改善目的に対して、指定した変更範囲が適切だったかを見直しました。記事HTMLやJavaScriptまで変更する必要がない内容だったかも確認しています。
これはCodexの出力をChatGPTが正解判定する工程ではありません。変更の目的、対象ファイル、対象外の範囲を別の確認工程として見直す作業です。
本番への反映と表示確認は人間側に残した
CSSファイルを修正できても、はてなブログへ反映することと、公開状態を確認することは別の作業です。今回の運用では、はてなブログへの反映、公開判断、実画面の確認を人間側に残します。
- PCでCTAの色、文字、サイズ、表の見え方を確認する
- スマートフォンでCTAが縦並びになったときの幅、タップしやすさ、表の横スクロールを確認する
ただし、今回確認した記録には、2026年8月8日のCSS変更について本番反映後のPC・スマートフォン実画面確認を完了した記録はありませんでした。今回の実例では、表示確認は未確認として扱います。
問題があったときに戻せる状態を先に作る
今回残したのは、変更前CSS、変更後の対象ファイル、そして変更範囲の記録です。
この3つがあれば、問題が起きたときに、どの状態から何が変わったのかを確認しやすくなります。一方で、これはGitのrevertとは別のものです。単純なバックアップファイルを残し、必要なら人間が内容を確認して戻す運用です。
CodexにCSS変更を任せれば安全という話ではない
Codexそのものではなく、変更前後を追える運用を組み合わせたことが、今回のメリットでした。
Codexを使わずに手動でCSSを直す方が早いケースもあります。小さな1行修正まで、必ずCodexを使うべきだとは考えていません。今回のように、複数のCTAやスマートフォンの表レイアウトを確認しながら、変更対象を限定して記録したい場合に、依頼と確認の流れを作りやすかった、という位置づけです。
CSS修正を依頼するときに指定していること
依頼前に、対象、目的、変更禁止範囲、完了報告を指定します。
対象: ブログの追加CSSファイルのみ
目的: スマートフォンでCTAを押しやすくし、表を横スクロールできるようにする
変更禁止: 記事HTML、JavaScript、はてなブログ管理画面
作業前: 変更前CSSを別ファイルへ保存する
完了時: 変更ファイル、変更箇所、対象外ファイルを変更していないことを報告する
禁止事項: 公開、はてなブログ操作、Git commit / push依頼文の項目を整理する考え方は、Codexへの指示文に何を書くかで詳しく扱っています。
まとめ
今回の実例では、ブログのCTAとスマートフォンの表レイアウトを改善するために、設定CSSだけを変更しました。変更前CSSは作業ごとに保存し、記事HTMLやJavaScriptは変更していません。
今回のメリットは、CSSを書いてもらえたことだけではありません。何を変えたかを追える状態で、ブログの見た目を改善できたことです。
CSSの小さな修正なら、手動作業の方が早い場合もあります。それでも、変更範囲を限定し、変更前後を残し、反映後の確認まで分けたいときには、この運用が判断しやすさにつながります。