この記事で扱う作業
この記事で扱うのは、Codexの作業報告では表示やリンクが整っているように見えたものの、実際の公開画面では想定通りに見えなかったため、公開HTML、ブラウザ表示、クリック先を確認した作業です。
Codexの報告は作業の整理に役立ちますが、報告書はユーザーが見る画面そのものではありません。ファイルに追加されていても読み込まれていない、HTMLには存在してもCSSで目立たない、リンク先が想定と違う、ということがあります。
このログでは、報告を否定するのではなく、報告と実画面を接続するための確認手順をまとめます。実装済み、公開HTMLに存在、ブラウザで視認可能、クリック先が正しい、という段階を分けて確認します。
作業前の状態
作業前は、Codexの報告だけを見ると「表示あり」「内部リンクあり」「確認済み」に見える状態でした。しかし、実際にブラウザで確認すると、期待した表示が見えにくかったり、サムネイルやタイトルのクリック先が想定と異なったりしていました。
この時点で問題になるのは、報告内容をそのまま完了判断に使ってしまうことです。Codexがファイルを編集したとしても、そのファイルが公開ページに読み込まれていなければ、ユーザーには何も変わりません。
また、公開HTMLに文言が出ていても、ブラウザ上で見えにくい位置にある、ボタンのリンク先が外部になっている、スマホ幅で隠れている、といった違いがあります。実画面確認を分けて行う必要がありました。
作業前に問題だったこと
作業前の問題は、「実装済み」と「ユーザーに伝わっている」が混同されていたことです。Codexの報告では作業が終わっているように見えても、ユーザーの画面で確認できなければ、ページ改善としては完了していません。
公開HTML、本番ファイル、ブラウザ表示、クリック先はそれぞれ別の確認です。HTMLにあるだけでは不十分で、実際に見えること、操作できること、リンク先が意図通りであることまで確認する必要があります。
特に内部リンク改善やランキングカード改善では、hrefの向きが重要です。サムネイルやタイトルが外部へ直接飛ぶ場合、内部詳細ページへの導線としては成立しません。報告書で「リンクあり」とされていても、どこへリンクしているかを確認しなければ意味がありません。
なぜこの作業が必要だったか
この作業が必要だった理由は、Codexの報告を実務で使える確認結果に変えるためです。報告書は便利ですが、公開サイトの品質確認では、実画面と公開HTMLが最終的な判断材料になります。
公開前チェックでは、title、description、canonical、robots、noindexなし、HTTP 200といったメタ情報だけでなく、ユーザーが実際に読む本文やクリックするリンクも確認します。作業報告だけで完了にすると、見落としが残る可能性があります。
また、報告と実画面のズレを記録しておくと、次回のCodex指示が具体的になります。「実装してください」ではなく、「公開HTMLと実画面で確認してください」と指示できるようになります。
Codexに任せたこと
Codexには、報告済みの内容を再確認する役割を任せました。対象文言が公開HTMLに出ているか、hrefがどこを向いているか、HTTP 200で到達できるかを整理させます。
さらに、ブラウザ上で視認できるか、サムネイル、タイトル、詳しく見るボタン、外部リンクのクリック先が想定通りかも確認対象にしました。単にHTMLを読むだけでなく、ユーザーの操作導線として成立しているかを見るためです。
- 公開HTMLに対象文言があるか確認する
- 対象リンクのhrefを確認する
- サムネイル、タイトル、ボタンのリンク先を分けて確認する
- リンク先がHTTP 200で到達できるか確認する
- ブラウザ上で視認できるか確認する
- 報告内容と実画面の差分を整理する
- 修正が必要な場合も範囲が大きければ停止して報告する
人間が判断したこと
人間側で判断したのは、Codexの報告より実画面を優先することです。報告が正しそうに見えても、ユーザーが見ている画面で確認できないなら完了とは言えません。
また、実装済み、調査済み、提案済みを分けることも重要でした。Codexの報告には、調査結果や次の提案が混ざる場合があります。何が実際に反映済みで、何が未実装なのかを人間が切り分ける必要があります。
修正判断も慎重に行いました。ズレの原因が明確で、最小修正で直せる場合は対応できますが、読み込み条件や部品構成に広く関わる場合は、無理に進めず停止して報告する方が安全です。
実際に使った指示文の考え方
指示文では、「確認してください」をさらに分解しました。公開HTMLにあるか、ブラウザ上で見えるか、クリック先が想定通りか、リンク先が200 OKかを別々に確認させます。
また、「今回は修正より原因確認を優先してください」と入れることで、Codexがいきなり広範囲の修正に進むのを防ぎます。原因が特定できた場合だけ、最小修正を提案させます。
報告形式も指定します。確認したURL、見つかった差分、想定と違ったリンク、修正が必要な箇所、未確認事項を分けて報告させると、人間が次の判断をしやすくなります。
うまくいった点
うまくいった点は、報告と画面のズレを早い段階で発見できたことです。ファイル上の実装だけを見ていたら、ユーザーに伝わっていない状態を見落としていた可能性があります。
公開HTMLとブラウザ表示を分けて見たことで、どの段階でズレているのかを整理できました。HTMLにはあるが見えにくいのか、HTMLにも出ていないのか、リンク先だけが違うのかで、対応方法は変わります。
クリック先を確認したことも大きなポイントでした。カード一覧では、サムネイル、タイトル、ボタンがそれぞれ別のリンクになる場合があります。リンク先を分けて確認することで、内部導線として成立しているか判断できました。
詰まった点・危なかった点
危なかった点は、Codexの報告だけで完了扱いにしてしまうことです。報告書に「確認済み」と書かれていると安心しがちですが、公開ページの確認とは別です。
もう一つの危険は、HTMLに存在するだけで表示済みと判断することです。CSS、条件分岐、表示位置、スマホ幅によって、ユーザーが見つけにくい状態になることがあります。
さらに、リンク先の確認を省くと、内部リンクを追加したつもりが外部リンクのままだったり、未作成URLへ向いていたりする可能性があります。リンク改善では、hrefと実クリックの両方を見る必要があります。
作業後に確認したこと
作業後は、まず対象ページがHTTP 200で表示されるか確認しました。次に、公開HTMLに対象文言が出ているかを確認し、そのうえでブラウザ上でも視認できるかを見ました。
さらに、サムネイル、タイトル、ボタン、外部リンクのhrefを確認しました。内部リンクとして期待しているものが外部へ飛んでいないか、未作成URLや404リンクを追加していないかを確認します。
最後に、title、description、H1、canonical、robotsが意図せず変わっていないか、noindexメタが入っていないか、スマホ表示で大きく崩れていないかを確認しました。
- 公開URLがHTTP 200で表示される
- 公開HTMLに対象文言がある
- ブラウザ上で対象文言が視認できる
- サムネイルのクリック先を確認した
- タイトルのクリック先を確認した
- ボタンのクリック先を確認した
- 内部リンクと外部リンクを分けて確認した
- 404リンクを追加していない
- canonicalとrobotsが維持されている
- noindexメタが入っていない
次回使えるCodex指示文テンプレート
次回は、Codex報告をそのまま完了扱いせず、公開HTML、ブラウザ表示、クリック先を分けて確認する指示にします。
Codex報告では実装済みとされていますが、公開URLに実際に反映されているか確認してください。
確認することは、公開HTML上に対象文言があるか、ブラウザ上で視認できるか、サムネイル・タイトル・詳しく見るボタン・外部リンクのhrefが想定通りか、リンク先がHTTP 200か、です。
今回は修正より原因確認を優先してください。報告内容と実画面がズレている場合は、どの段階でズレているのかを、公開HTML、ブラウザ表示、クリック先に分けて報告してください。
必要な最小修正が明確な場合のみ対応し、範囲が大きくなる場合は停止して報告してください。確認チェックリスト
このチェックリストでは、報告、HTML、画面、クリック先を別々に確認します。どれか一つだけでは完了判断にしません。
- Codex報告の内容を確認した
- 公開HTMLに対象文言がある
- ブラウザ上でも対象文言が見える
- サムネイルクリック先を確認した
- タイトルクリック先を確認した
- ボタンリンク先を確認した
- 内部リンクと外部リンクを分けて確認した
- リンク先がHTTP 200
- 未作成URLを追加していない
- 報告と実画面に差がある場合は実画面を優先した
- 修正範囲が大きい場合は停止して報告した
まとめ
Codexの作業報告は便利ですが、公開ページの最終確認ではありません。実装済み、公開HTMLに存在、ブラウザで視認可能、クリック先が正しい、という段階を分けて見る必要があります。
特に内部リンクやカード導線の改善では、リンクがあるかどうかだけでなく、どこへ飛ぶかが重要です。ユーザーが内部詳細ページへ進めるのか、外部へ直接出るのか、未作成URLへ向いていないかを確認します。
Codexに任せる部分は調査と整理、人間が判断する部分は完了判定と修正範囲です。報告と実画面が違う時は、実画面を優先し、必要な最小修正だけを進めることが安全です。
注意書き
この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。
同じ作業でも、サイト構成、利用しているCMSやHTML構成、公開環境、GitHub運用の有無によって確認すべき点は変わります。実作業の前には、対象ファイル、触らないファイル、停止条件、確認項目を決めたうえで進めてください。