Practical log guide

Codexへの指示を具体化した実践ログ

Codexへの指示は、長ければよいわけではありません。大事なのは、目的、対象、完了条件、触らない範囲、確認方法が明確であることです。この実践ログ型ガイドでは、曖昧な見た目修正の指示を、順位・指標・ORDER BY・リンク先確認まで含む具体指示へ変えた流れを整理します。

当サイトはOpenAI公式サイトではありません。Codexの使い方を実体験ベースで整理する非公式ガイドです。最新の仕様・料金・対応プランはOpenAI公式情報をご確認ください。

この記事は2026年8月時点の情報をもとに整理しています。Codex、ChatGPT、GitHub、Google関連サービスの仕様は変更される可能性があります。

今回やった作業

今回の作業では、Codexへの指示を「見た目を直して」から「順位・指標・ORDER BY・リンク先を確認して」へ具体化した流れを一般化してまとめます。これは、単にプロンプトを長くした話ではありません。作業の完了条件を明確にし、Codexが何を確認すればよいか、人間がどこを判断するかを分けた話です。

最初の指示は「ランキングカード化」のような見た目寄りのものでした。カードの余白や装飾を変えれば、画面上は変わります。しかし、ランキングとして成立しているかどうかは、見た目だけでは判断できません。順位、順位指標、並び順、内部詳細ページへの導線、外部リンクの扱い、公開HTMLでの確認が必要です。

そこで、指示の粒度を変えました。「ランキングらしくして」ではなく、「現在のORDER BYを確認し、順位と順位指標を画面に出し、内部リンク先を確認し、公開HTMLと実画面で確認して」と書くようにしました。これにより、Codexの作業が装飾だけに寄らず、データ根拠と導線まで含む改善になります。

作業前の状態

作業前は、最初の指示が見た目寄りでした。カードの見た目は変わっても、ランキングとしての意味が弱く、順位や指標が見えにくく、内部詳細ページへの導線も十分ではありませんでした。

完了条件も曖昧でした。「ランキングカード化」が完了したとは、何を意味するのか。順位が出ていることなのか、指標が出ていることなのか、ORDER BYが確認されていることなのか、内部リンクが成立していることなのか。この定義が曖昧だと、Codexは何かしらの変更を行っても、本質的な問題が残ります。

また、触ってよいファイルと触らないファイルの指定も重要でした。ランキング改善という言葉だけでは、CSS、テンプレート、データ取得、共通部品など、どこまで触るのかが曖昧になります。公開中サイトでは、この曖昧さが事故につながります。

作業前に問題だったこと

Codexは曖昧な指示でも作業できます。むしろ、曖昧な指示からでもそれらしい修正案を出せるのが便利なところです。しかし、便利だからこそ、完了条件が曖昧なままだと、見た目だけ整って本質的な問題が残ることがあります。

たとえば「ランキングらしくする」と頼むだけでは、順位、指標、並び順、内部リンク先、公開HTML確認まで含まれない可能性があります。CSSだけが変わり、画面の印象は変わっても、何の順番で並んでいるのか、ユーザーがどこで詳しく確認できるのかが残ったままになることがあります。

また、Codexの報告が「作業しました」で終わると、人間側も完了扱いしやすくなります。しかし、公開画面で見えるのか、クリック先が合っているのか、canonicalやrobotsを意図せず変えていないかまで確認しなければ、本番作業としては不十分です。

Codexに任せたこと

Codexには、作業させる前に調査項目と確認項目を指定しました。まずORDER BYを確認すること、使える指標を確認すること、画面に表示する項目を整理すること、内部リンク先を確認すること、公開HTMLで反映を確認することを依頼します。

次に、完了条件に沿った再実装を求めました。完了条件は、ユーザーが見て何のページか分かること、表示内容とデータ根拠が一致していること、内部導線が成立していることです。これを最初に書くと、Codexの作業が見た目だけで終わりにくくなります。

最後に、報告書形式に沿った結果報告も指定しました。変更したファイル、触っていないファイル、確認したURL、未確認事項を報告させることで、人間が確認しやすくなります。

  • ORDER BY確認
  • 指標確認
  • 表示項目追加
  • リンク先確認
  • 公開HTML確認
  • 完了条件に沿った再実装
  • 報告書形式に沿った結果報告

人間が判断したこと

人間側で判断したのは、なんとなくランキング風では不十分だということです。ランキング改善なら、見た目だけではなく、データ根拠と導線を見る必要があります。

また、Codexには何でも任せるのではなく、触ってよいファイル、触らないファイルを明確にする必要があります。DB、cron、.htaccess、sitemap、robots、広告タグなどは、今回の作業では変更しない対象として明記します。

さらに、「作業しました」ではなく、公開画面でどう確認できるかまで必要です。人間は、Codexの作業報告を読むだけでなく、公開HTMLや実画面で確認する前提を持ちます。

  • なんとなくランキング風では不十分
  • 完成条件を定義し直す必要がある
  • Codexには見た目ではなく、データ根拠と導線を確認させる
  • 作業しましたではなく、公開画面でどう確認できるかまで必要
  • 触ってよいファイル、触らないファイルを明確にする必要がある

実際に使った指示文の考え方

指示文を具体化する時に大事なのは、長文にすることではなく、必要な要素を漏らさないことです。目的、対象、完了条件、触ってよいファイル、触らないファイル、停止条件、確認方法、報告書形式を入れます。

ランキング改善であれば、ORDER BY、順位表示、順位指標、内部詳細ページへのリンク、外部リンクの扱い、公開HTMLと実画面での確認が必要です。これらがないと、見た目だけ変わった状態で完了扱いになりやすくなります。

また、「やらないこと」を書くのも重要です。DBを触らない、cronを触らない、.htaccessを触らない、sitemapやrobotsを変更しない、広告タグを触らない。この制約があると、Codexが作業範囲を広げすぎるのを防ぎやすくなります。

うまくいった点

うまくいった点は、Codexに任せる範囲が明確になったことです。見た目の変更ではなく、ORDER BY、順位指標、内部リンク、公開HTML確認まで含めて依頼したことで、作業の焦点がずれにくくなりました。

また、報告書形式を指定したことで、変更したファイルと触っていないファイル、確認したURL、未確認事項が残りやすくなりました。これは、後から実践ログ化する時にも役立ちます。

さらに、完了条件を最初に書くことで、人間側の確認もしやすくなります。何を見れば完了なのかが決まっていれば、Codexの報告と実画面を照合しやすくなります。

詰まった点・危なかった点

詰まった点は、指示を具体化しようとすると、つい長くなりすぎることです。長いだけの指示は読みにくく、Codexにも人間にも扱いづらくなります。必要なのは長さではなく、目的と完了条件の明確さです。

危なかった点は、見た目修正だけで完了扱いにすることです。カードの見た目が整っても、順位指標がなければランキングとして弱いままです。内部リンクが外れていれば、サイト内で比較する導線も弱くなります。

また、指示に触らないファイルを書かないと、作業範囲が広がりすぎる可能性があります。公開中サイトでは、意図しない共通部品変更や設定変更が大きな影響につながるため、禁止事項と停止条件をセットで書く必要があります。

作業後に確認したこと

作業後は、まず公開HTMLで対象文言やリンク先が出ているか確認します。次に、実画面でユーザーに見えているかを確認します。HTMLに存在していても、CSSや表示位置の関係で分かりにくいことがあります。

さらに、ORDER BY、順位表示、順位指標、内部リンク先、外部リンクの扱いを確認します。指示が具体化されていても、実装後に確認しなければ、完了条件を満たしたか判断できません。

最後に、変更したファイル、触っていないファイル、確認したURL、未確認事項が報告されているかを見ます。この報告があると、次に同じ作業をする時の指示文テンプレートとして再利用できます。

次から使える指示文テンプレート

次回同じようにCodexへ依頼する時は、見た目の変更だけで完了にしないことを最初に書きます。以下のテンプレートは、ランキング改善やSEOページ補強で使いやすい形にしています。

この作業では、見た目の変更だけで完了にしないでください。

現在のデータ取得条件、並び順、表示指標、リンク先、公開HTMLでの確認結果を報告してください。

完了条件は、ユーザーが見て何のページか分かること、表示内容とデータ根拠が一致していること、内部導線が成立していることです。

対象ファイル以外は触らず、DB、cron、.htaccess、sitemap、robots、広告タグは変更しないでください。

作業前に、触るファイル、触らないファイル、停止条件、確認方法を整理してください。

作業後は、公開HTMLと実画面の両方で、順位・指標・リンク先が確認できるかを報告してください。

最後に、変更したファイル、触っていないファイル、確認したURL、未確認事項を報告してください。

確認チェックリスト

このチェックリストは、Codexへの指示が曖昧なまま進んでいないかを確認するためのものです。見た目だけでなく、データ根拠、リンク先、報告形式まで見ます。

  • 作業名が曖昧すぎない
  • 目的が明確
  • 完了条件がある
  • 表示だけでなくデータ根拠を確認する
  • 現在のORDER BYを確認する
  • 触ってよいファイルを指定した
  • 触らないファイルを指定した
  • DB変更禁止などの制約を入れた
  • 確認方法を指定した
  • 報告書形式を指定した
  • 実画面確認を含めた
  • 未確認事項を書かせた

まとめ

Codexへの指示は、長ければよいわけではありません。大事なのは、目的、対象、完了条件、触らない範囲、確認方法が明確であることです。特にランキング改善やSEOページ補強のような作業では、「見た目を直す」だけでは不十分です。

次に同じ作業をする人は、何を見れば完了なのか、ユーザーに何が伝われば成功なのか、公開HTMLや実画面でどう確認するのかまで決める必要があります。Codexには調査、修正案、最小実装、確認結果の整理を任せられますが、完了条件を決めるのは人間です。

この役割分担を持つと、Codexの作業が安定します。Codexに任せる部分は、ORDER BY確認、指標確認、リンク先確認、公開HTML確認、報告書作成です。人間が判断する部分は、何をもってランキングとして成立するか、どこまでを今回の作業範囲にするか、どの変更は止めるべきかです。

注意書き

この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。作業対象サイトの条件や利用しているサービスの仕様は変わる可能性があるため、実際に作業する前には現在の環境と公式情報を確認してください。