Codex指示書テンプレート集｜コピペして使える依頼文

指示書に必ず入れる5点（目的・対象・やらないこと・停止条件・報告）

Codexへの指示書は、目的・対象・やらないこと・停止条件・報告の5点が入っていれば、短くて構いません。逆にこの5点が抜けた指示書は、丁寧に長く書いても作業範囲が広がります。ここから下のテンプレートは、そのまま貼って（　）内だけ書き換えれば使える形にしてあり、どれもこの5点を必ず含めています。5点が揃っていれば、言い回し自体は自分の言葉に変えて構いません。

共通する考え方はひとつです。「やってほしいこと」より「やらないでほしいこと」と「止まる条件」を先に固定する。ここが書いてあれば、多少指示が雑でも被害は範囲内に収まります。逆にここが無いと、丁寧に書いた指示でも想定外の場所に手が届きます。

貼る前に見直す6点

• 対象URLと対象ファイルを入れる
• 変更してよい範囲を入れる
• 触らないものを入れる
• 停止条件を入れる
• 報告書形式を入れる
• 判断が必要なら止めるように書く

停止条件をどこに引くかは 停止条件の決め方、1回の依頼をどこまで小さく切るかは 作業を小さく分ける考え方 に分けています。やりたい作業からどの型を使うかを選びたい時は 作業シーン別テンプレート早見表、指示書そのものをChatGPTに書かせる時のプロンプトは Codexに渡す指示文をChatGPTで作る にあります。

① 修正せず、確認だけ頼む

まず現状を把握したい時。変更を伴わないので、初めての相手（新しいサイト・新しいフォルダ）にはこれから始めます。差し替えるのは（対象ページ）（フォルダ名またはURL）（確認したいこと）の3か所です。

目的: （対象ページ）の現状確認。今回は調査のみで、ファイルの変更は一切しない。
対象: （フォルダ名またはURL）
やること:
- （確認したいこと。例: リンク切れがないか / titleとh1の内容 / スマホ表示で崩れる箇所）
やらないこと: ファイルの作成・変更・削除。設定ファイルを開くこと。
停止条件: 変更が必要だと判断した場合は、変更せずに内容を報告して止まる。
報告: 確認結果を「問題なし / 要修正 / 判断が必要」の3つに分けて一覧にする。

短い版（公開済みの1ページを見てもらう時）

以下の対象ページについて、まず修正せず確認だけ行ってください。
対象URL、実ファイル、title、meta description、canonical、robots、H1、内部リンク、CSS読み込みを確認してください。
変更が必要な場合も、勝手に実装せず、確認結果と最小修正案だけ報告してください。

確認だけの依頼でも、Codexが作業フォルダの外を読めるか、コマンドを実行できるかは設定で決まります。初めてのフォルダで使う前に 作業フォルダと権限の決め方 を一度見ておくと、確認のつもりで設定ファイルまで開かれる事故を防げます。

② 1ページだけ修正を頼む

対象を1ページに絞ることで、想定外の変更を構造的に防ぎます。複数ページを直したい時も、まず1ページで結果を確認してから残りに広げるほうが安全です。

目的: （直したいこと。例: スマホで見出しがはみ出すのを直す）
対象: （ファイルパス）の1ファイルのみ
やること:
- （具体的な修正内容）
やらないこと: 対象ファイル以外の変更。本文の意味を変える書き換え。CSSの共通部分の変更。
停止条件: 対象ファイル以外を変更する必要が出たら、変更せず報告して止まる。
報告: 変更した箇所を、変更前と変更後の対比で示す。

本文を足すだけの短い版

対象ページの本文だけを実践ガイドとして補強してください。一般論の水増しではなく、手順、注意点、指示文例、確認チェックリストを追加してください。title、meta description、canonical、robots、H1、共通ヘッダー、共通フッターは変更しないでください。

1ページで結果を見てから残りへ広げる時は、対象URLの一覧を先に作ります。一覧の渡し方は⑦のスプレッドシートの型に書きました。新しいページを1枚足す作業は 新規ページ追加テンプレート、小さなブロックだけ足す作業は 既存ページ軽補強テンプレート のほうが差し替え箇所が少なくて済みます。

③ 公開前チェックを頼む

公開直前に、見落としを機械的に拾わせます。チェック項目を自分のサイトに合わせて増減させて、毎回同じリストを使うのがコツです。

目的: （対象ページ）の公開前チェック。修正はせず、結果の一覧だけ出す。
対象: （ファイルパスまたはURL）
確認項目:
- リンクを全て列挙し、リンク切れ・仮リンク（#や未設定）がないか
- titleとdescriptionが入っているか、他ページと重複していないか
- 画像のalt抜け、表示されない画像がないか
- スマホ幅で崩れる要素がないか
- 電話番号・メールアドレス・住所などの実データが仮のままになっていないか
やらないこと: 修正。チェック項目以外の指摘の追加。
報告: 項目ごとに「OK / NG（該当箇所）」の表にする。

公開URLで見る版（HTTP・sitemap・robots・canonical）

手元のファイルではなく公開されたURLを見てもらう時は、確認項目をこちらに差し替えます。sitemap.xmlやcanonicalは確認だけにして、勝手に直させません。

目的: （公開URL）の公開後チェック。修正はせず、結果の一覧だけ出す。
対象: （公開URL。複数ならここに列挙）
確認項目:
- HTTP 200で返るか。noindexが入っていないか
- title、meta description、canonical、robots、H1の内容
- 対象URLがsitemap.xmlに載っているか
- 内部リンク、CSS読み込み、スマホ表示
- 電話番号・メールアドレスなどの実データや秘密情報が露出していないか
やらないこと: 修正。sitemap.xml・robots.txt・canonicalの変更。
停止条件: HTTP 500や大量の404が出たら、原因調査に進まず結果だけ報告して止まる。
報告: URL×項目の表にして「OK / NG（該当箇所）」で埋める。

報告を受け取ったら、自分の目で見る6点

• 変更ファイルは想定内
• title / description / canonical / robots / H1 を維持
• noindexなし
• 内部リンクとCSS読み込みを確認
• 秘密情報や認証情報を本文に出していない
• 最終判断は人間が行う

404や500、CSS崩れが見つかった時の切り分けは トラブル対応の入口 にまとめています。公開前チェックの型だけを1枚で持ちたい人は 公開前チェックテンプレート も同じ作りです。

④ 元に戻す（ロールバック）を頼む

問題が起きた時用。このテンプレは、問題が起きる前に読んでおいてください。バックアップがない状態では戻せないので、②や③の作業とセットで「作業前にバックアップを取る」運用が前提です。

目的: （対象ファイル）を（いつ時点）の状態に戻す。
対象: （ファイルパス）
戻し先: （バックアップの場所。例: backup_before_〇〇フォルダ内の同名ファイル）
やること:
1. いまのファイルとバックアップの差分を先に見せる
2. 私が確認して「戻してよい」と言ってから置き換える
やらないこと: 確認前の置き換え。バックアップ側のファイルの変更・削除。
停止条件: バックアップが見つからない、または差分が想定より大きい場合は止まって報告。
報告: 置き換えたファイルと、置き換え後に表示確認すべきURL。

「直前の変更だけを戻す」「差分を先に見せる」「私が確認してから置き換える」の3つが入っていれば、戻すつもりで別の場所まで巻き戻す事故は起きません。バックアップの取り方と戻す単位の決め方は ロールバックを前提にした進め方 に、戻したのに表示が直らない時の見方は 戻し方のトラブル にまとめています。GitHubで管理しているなら、戻す対象はcommitやPRの差分で指定できます。

⑤ GitHub PRレビューを頼む

Pull Requestの差分を、mergeする前に読ませます。軽微な好みではなく、実害がありそうな点を優先させるのが肝で、見る順番を指示書に書いておくと報告が読みやすくなります。

目的: このPull Requestの差分レビュー。修正もmergeもしない。
対象: PR #（番号）の差分のみ。差分に無いファイルは開かない。
見ること（優先順）:
1. 重大な不具合、セキュリティ上の問題
2. SEOタグ（title・description・canonical・robots・H1）の意図しない変更
3. 秘密情報（APIキー・.env・パスワード）の混入候補
4. 不要ファイルの混入、戻しにくい変更（大量削除・一括置換）
やらないこと: コードの修正・commit・merge。軽微な好みの指摘。
停止条件: 秘密情報の混入候補を見つけたら、値は貼らずに場所だけ報告して止まる。
報告: 「重大 / 要確認 / 参考」の3段階に分け、該当ファイルと行を添えて一覧にする。

AIのレビューは人間レビューの補助です。mergeと本番反映は、報告を読んだ人が決めます。PRで差分を見る手順そのものは Pull Requestで差分を見る方法、CodexとGitHubをつなぐ全体の流れは GitHubとCodex にあります。

⑥ Webデザイン修正を頼む

見た目の修正は、対象と確認項目を先に分けると安全です。SEOタグ、AdSenseコード、robots.txt、sitemap.xml、ads.txt を触らないことも明記してください。項目を埋める型なので、空欄のまま貼らずに全部埋めます。

対象ページ：
直したい場所：
今の問題：
参考にする既存ページ・既存ブロック：
変更してよいもの：
変更してはいけないもの：
PC表示で確認すること：
スマホ表示で確認すること：
SEOタグを変更しないこと：
AdSenseコードを変更しないこと：
報告書形式：

埋め方の例。「直したい場所：トップの3枚カードの余白」「変更してよいもの：そのカードに当たるCSSだけ」「変更してはいけないもの：共通CSSの他の部分、HTMLの構造」。共通CSSを触る必要が出たら止めて報告、と一行足すと、1か所の修正が全ページに波及する事故を防げます。見た目の依頼の考え方は Webデザイン修正を頼む方法、余白や文字サイズだけなら CSS修正の頼み方 に分けています。作業後はPCとスマホの両方で表示を見てから公開します。

⑦ 外部ツールを使う作業の指示書（ドライブ・スプレッドシート・Canva・Gemini）

外部ツールが絡む作業でも、指示書の5点は変わりません。変わるのは「対象」から外部ツール側を外すことです。Codexにドライブやスプレッドシートを直接操作させる前提にせず、素材や一覧の受け渡しは人がやり、Codexにはサイト側のファイルだけを触らせます。

Googleドライブの素材を使う

素材とバックアップはドライブに置き、Codexの作業対象から外します。使う画像だけを人がサイトのフォルダへ入れてから頼みます。

目的: （対象ページ）の画像を差し替える。元の素材はGoogleドライブの（フォルダ名）にあり、使う分は私が /assets/img/（フォルダ）に置いた。
対象: （ファイルパス）の1ファイルと、/assets/img/（フォルダ）に置いた画像のみ
やること:
- 対象ページののsrcを、置いた画像に差し替える。altは内容に合わせて書き直す
やらないこと: ドライブ側のファイルの操作。置いた画像以外の画像の変更・削除。CSSの変更。
停止条件: 画像のファイル名が一致しない、または同じ画像が他のページでも使われている場合は止まって報告。
報告: 差し替えたsrcとaltを、変更前・変更後で並べる。

フォルダの分け方と共有範囲の注意は 素材とバックアップをGoogleドライブに置いてCodexの作業対象から外す指示書 に書いています。

スプレッドシートのURL一覧を渡す

複数ページの確認や修正は、対象URLの一覧をスプレッドシートで作り、一覧に無いページは触らせません。結果は人がシートに貼り戻せる形で返してもらいます。

目的: 下に貼ったURL一覧の各ページについて、（確認項目。例: titleとdescriptionの有無）を確認する。修正はしない。
対象: 一覧に載っているURLに対応するファイルのみ。一覧に無いページは開かない。
やること:
- 各URLのファイルを開き、確認項目を確かめる
やらないこと: ファイルの変更。一覧に無いページの確認。
停止条件: 一覧のURLに対応するファイルが見つからない場合は、そのURLを飛ばして最後にまとめて報告。
報告: URL・確認結果・備考の3列で、私がスプレッドシートに貼れる形（タブ区切り）にする。
--- URL一覧（シートのA列をコピー） ---
（ここに貼る）

一覧の列の作り方と進捗の持ち方は 対象URLと進捗の一覧をスプレッドシートで渡す時の指示書 に。

Canvaで作ったロゴ・バナーを設置する

Canvaでの書き出しは人がやり、Codexには設置だけを頼みます。縦横比が変わるとCSSまで触る話になるので、その場合は止めさせます。

目的: Canvaで作ったロゴ画像（ファイル名.png。/assets/img/ に置いた）をヘッダーに設置する。
対象: （共通ヘッダーのファイルパス）の1ファイルのみ
やること:
- 既存のロゴのsrcを新しいファイルに差し替える。表示サイズは今のCSSに合わせ、CSSは変えない
やらないこと: CSSの変更。他ページの変更。既存ロゴファイルの削除。
停止条件: 新しい画像の縦横比が既存と違い、CSSを変えないと崩れる場合は、変更せずに報告して止まる。
報告: 差し替え前後のsrcと、PC・スマホ幅で表示確認すべきURL。

書き出しサイズや置き場所の決め方は Canvaで作ったロゴ・バナーをCodexで設置する依頼文 にまとめています。

Geminiで調べた結果を渡す

Geminiの出力はそのまま公開せず、構成案として指示書の末尾に貼ります。構成案に無い事実や数字は足させないのが要点です。

目的: 下に貼った構成案をもとに、（対象ページ）の本文を作る。
対象: （ファイルパス）の1ファイルのみ。新規なら（パス）に1ファイル作成。
やること:
- 構成案の見出し順に本文を書く。構成案に無い事実・数字は足さない
やらないこと: 構成案に無い情報の追加。title・description・canonical・共通部品の変更。
停止条件: 構成案に矛盾や出典不明の数字があれば、その箇所を空欄にして報告する。
報告: 構成案の見出しごとに「書いた / 空欄にした（理由）」の一覧。
--- 構成案（Geminiの出力。出典と確認日も一緒に） ---
（ここに貼る）

調査から実装までの分担は Geminiで調べた構成をCodexに渡してHTML/CSSを作らせる流れ に。ChatGPTのdeep researchの結果を渡す時も、調査結果をCodex向けにまとめる手順 は同じです。

⑧ 新しいチャットへ引き継ぐ時の一文

1つのチャットで別の作業を混ぜ始めたら、新しいチャットに移ります。移る時に貼る文は、指示書の5点に「いまどこまで」を足しただけです。前のチャットの履歴は引き継がれない前提で、この文だけで作業が再開できる形にします。

引き継ぎ（前のチャットからの続き。履歴は見ていない前提で読んでください）
目的: （何のための作業か）
対象: （フォルダまたはファイル）
触らない範囲: （設定ファイル・共通部品・他サイト など）
いまどこまで:
- 完了: （変更したファイルと、確認済みのURL）
- 未完了: （残っている作業）
- 保留: （私の判断待ちの点）
バックアップ: （場所と、いつ時点か）
次にやること: （1つだけ）。それ以外は着手しない。

どのタイミングで分けるか、同じチャットで続けてよい作業は何かは 作業が混ざったら新しいチャットへ。引き継ぎに何を書くか に。引き継ぎ文だけを1枚にしたものは 次のチャットへ引き継ぐテンプレート にあります。

悪い指示書 / 良い指示書

違いは長さではなく、対象と、維持するタグが書いてあるかどうかです。

指示書に書かないこと：モデルと推論レベルと権限は設定側で決める

テンプレートにモデル名や推論レベルを書き込まないでください。どのモデルで動かすか、どこまで深く考えさせるか、どこまでの操作を許すかは、指示書ではなくCodex側の設定で決めるものです。指示書に書くと、モデルが入れ替わった時にテンプレートごと古くなり、設定と食い違った時にどちらが効いているか分からなくなります。上の5点はモデルが変わっても変わりません。

• 作業フォルダ・権限・止める条件は Codexの設定で決める。指示書の「やらないこと」は、設定に対する二重の保険と考える
• 推論レベルは、Codexアプリなら入力欄付近の設定、CLIなら config.toml で決める。どの作業でどの段階を選ぶかは Codexの推論レベルの選び方 に
• フルアクセスの可否は指示書ではなく設定側で決める。許した日は、指示書の「やらないこと」と「停止条件」を必ず厚くする

推論レベルという考え方そのもの（APIのnone〜max）は gptguide.jpの推論レベル解説、ChatGPTの画面での選び方（Instant〜Pro）は chatgptguide.jpの選び方 に分けています。このサイトで扱うのは、Codexの作業にどう効かせるかだけです。

次に読むページ

テンプレートを貼ったら、次は「確認項目」「報告の読み方」「公開前の確認」「触らせない範囲」の4本です。

作業の進め方そのものは Codexの使い方 を親に、ChatGPTで整理してからCodexへ渡す流れ、Codexへ直接続けて頼む時の止め時、前提を毎回渡す理由、ChatGPTを相談役にする使い方、プロジェクトの分け方、タスク単位の切り方、画面の整理、SEO実装を頼む流れ に分けています。ChatGPT自体の使い方は姉妹サイトの chatgptguide.jp にあります。