ねぇねぇ、佐藤さん！前のチャットが長くなったので新しくしたいんですが、「続きからお願いします」だけで大丈夫ですか？公開したページと、まだ直していない部分を取り違えられそうで不安です。
会話の記憶だけに頼らず、サイトのフォルダへ「いまの正しい状態」を残そう。公開済み、未実施、禁止事項、次の一作業を別々に書けば、新しいチャットでも確認してから進められるよ。
過去の会話を全部コピーするのではなく、今の状態をファイルにまとめるんですね。でも、どこまで詳しく書けば安全ですか？
対象フォルダ、必読ファイル、公開URL、完了事項、未実施事項、禁止事項、復旧方法の七つから始めよう。秘密情報は書かず、実画面で確かめられる事実だけを残すのがコツだよ。
既存WordPressサイトを新しいCodexチャットへ引き継ぐ時は、過去の会話を丸ごと渡すのではなく、プロジェクト内のMarkdownへ「現在の状態」を整理します。 最重要なのは、公開済みの結果と、まだ行っていない作業を同じ箇条書きへ混ぜないことです。
この記事では、前の担当者が自分でも、別の人でも、別のCodexチャットでも使える引き継ぎ方法を説明します。準備がまだなら、先に CodexでWordPressを始める前の準備 で作業フォルダ、権限、秘密情報の扱いを確認してください。
結論：引き継ぐのは会話ではなくいまの正しい状態
新しいチャットが必要とするのは、過去に何を話したかより、いま何が公開され、どこにファイルがあり、何を変更してよく、次に何を確認すべきかです。これを人が読めるMarkdownへ残します。
| 残す情報 | 書く内容 | 混ぜないもの |
|---|---|---|
| 現在の公開状態 | 公開URL、記事ID、ステータス、確認日 | 公開予定や下書き案 |
| 完了事項 | 実施内容と確認証拠 | 今後やりたいこと |
| 未実施事項 | 次に必要な作業と理由 | 完了済みの作業 |
| 禁止事項 | 触らない記事、使わない機能、承認が必要な操作 | 単なる好みや候補 |
| 復旧情報 | バックアップ日時、戻し方、担当者 | パスワードや秘密鍵 |
最初に固定する七つの引き継ぎ情報
- 対象： サイト名、作業フォルダの絶対パス、本番URL。
- 必読ファイル： 作業開始前に全文を読むMarkdown。
- 公開済み： 記事ID、URL、公開日時、確認できた表示。
- 未実施： まだ保存・公開・検査していない作業。
- 禁止事項： 変更禁止の記事、API、Worker、Cron、削除など。
- 復旧： バックアップの有無、変更前へ戻す入口。
- 次の一作業： 最初に調べる対象と完了条件。
「だいたい終わっています」「必要なら直してください」では判定できません。「公開URLでH1とcanonicalを確認済み」「サイトマップ確認は未実施」のように、確認済みと未確認を分けます。
引き継ぎファイルは三層に分ける
| ファイル | 役割 | 更新する時 |
|---|---|---|
| PROJECT_RULE.md | 変えてはいけない恒久ルール | 方針や禁止事項が正式に変わった時 |
| CURRENT_STATUS.md | 現在の公開状態、直近作業、次の作業 | 保存、公開、検査、判断が変わるたび |
| POST_COMPLETION_CHECKLIST.md | 完了と呼ぶための確認項目 | 見落としから再発防止を追加する時 |
ファイル名はサイトに合わせて変更できます。重要なのは、恒久ルールと日々変わる状態を一つの長い文書へ混ぜないことです。新しいチャットには、どの順番で読むかも指定します。
記事を公開した後に、スマホ確認だけ残っている場合は「作業中の記事」と書けばいいですか？
「記事は公開済み」「スマホ表示確認は未実施」と二つに分けよう。公開を取り消す必要があるのか、検査だけ続けるのかが明確になるよ。
タイトル案を作っただけなのに「記事を作成」と書くのも危ないですね。
そうだね。「案を作成」「CMSへdraft保存」「公開」「公開URLを確認」は別の状態だよ。動詞を具体的にすると取り違えにくい。
完了と未実施を混同しない状態表
| 状態 | 意味 | 必要な証拠 |
|---|---|---|
| 案 | 候補を考えただけ | 設計メモやタイトル候補 |
| 下書き保存 | CMSにあるが一般公開されていない | 記事IDとdraft表示 |
| 公開済み | 一般公開URLが生成された | 公開URLとHTTP状態 |
| 表示確認済み | PC・スマホで内容を読んだ | 画面幅、確認箇所、異常の有無 |
| 完了 | 公開後チェックをすべて通過した | チェック結果と最終評価 |
公開済みでも未完成の場合があります。逆に、次の改善候補が残っていても、今回決めた範囲をすべて確認できれば、その作業単位は完了です。範囲と証拠をセットで書きます。
CURRENT_STATUS.mdの実例
## 2026-08-30 / 記事#123の公開
Status: published; mobile review pending.
- 公開URL: https://example.com/guide/
- 完了: title、H1、canonical、PC表示を確認
- 未実施: 390px表示、フォーム送信、sitemap確認
- 変更禁止: 記事#122、既存URL、商品リンク
- 次の作業: 390pxで横幅とコード枠を確認
- 使用禁止: OpenAI API、Worker、Cron
- 復旧: Revision #45から戻せる
この例なら、新しいチャットは記事を作り直さず、残っているモバイル検査から始められます。URLや記事IDが分からない時は推測せず、管理画面や公開ページで調べてから更新します。
新しいチャットへ渡す最初の依頼文
このフォルダのWordPress作業を引き継いでください。
開始前にPROJECT_RULE.md、CURRENT_STATUS.md、POST_COMPLETION_CHECKLIST.mdを全文読んでください。
特にCURRENT_STATUS.mdの最新日付を確認してください。
公開済み状態と未実施事項を混同しないでください。
まず変更せず、対象URL、現在の状態、次に行う一作業を報告してください。
パスワード、APIキー、秘密鍵、個人情報などの秘密値は、会話・ログ・報告へ表示、転載、保存、外部送信しないでください。設定確認が必要な場合も、秘密値そのものは出力しないでください。
公開、削除、契約、外部送信は実行前に確認してください。
最初の依頼でいきなり「全部直して」と頼まないことが大切です。必読ファイルを読んだ結果と、公開側の事実が一致するかを確認してから、作業を一件に絞ります。
危険な引き継ぎ依頼と直し方
| 危険な依頼 | 問題 | 安全な直し方 |
|---|---|---|
| 前の続き全部やって | 対象と完了状態が不明 | 最新状態を読み、次の一件を報告させる |
| 古いファイルは消して | 対象と復旧方法が不明 | 削除候補、件数、参照箇所を先に一覧化 |
| 本番を最新にして | 最新の基準が不明 | 反映するコミットやRevisionを指定する |
| ログイン情報は設定ファイルにある | 秘密情報を表示する危険 | 本人がログインし、秘密値を表示・転載・保存・外部送信しないよう指定 |
| 問題なければ公開して | 合格条件が曖昧 | PC、390px、リンク、canonicalなどを列挙 |
公開URLとローカルファイルを対応させる
既存サイトでは、ローカルのファイル名と公開URLが一対一とは限りません。テンプレート一つが多くの記事へ影響する場合や、CMS本文から静的HTMLを書き出す場合があります。
- 公開URLはブラウザで確認する。
- 変更元がテーマ、プラグイン、CMS本文、生成済みHTMLのどれか記録する。
- 自動生成ファイルを直接直す前に、次回生成で上書きされないか確認する。
- URL変更がある場合は旧URL、転送先、canonical、サイトマップを一組にする。
「index.htmlを直したから完了」とせず、次回の公開処理でも維持される変更元へ反映します。
禁止事項は「気をつけてください」とだけ書けば伝わりますか？
対象と行為を具体的にしよう。「記事#676の公開済み本文・URL・ステータスを変更しない」のように書けば確認できるよ。
「APIは禁止」も、どのAPIなのか書いた方がよさそうですね。
その通り。OpenAI APIは禁止、ログイン済みブラウザの確認は可、というように境界を明確にすると、必要な作業まで止めずに済む。
禁止事項は対象・行為・例外を書く
禁止事項は短くても、判定できなければ役に立ちません。次の三要素を含めます。
- 対象： 記事ID、URL、ディレクトリ、機能名。
- 禁止する行為： 編集、公開、削除、起動、外部送信。
- 許可される確認： 読み取り、表示確認、差分確認など。
記事#676は公開済み状態を維持し、本文・URL・ステータスを変更しない。
OpenAI API、Legacy AI、Worker、Cronは使用しない。
ローカルファイルと公開URLの読み取り確認は実施してよい。
削除、契約、支払い、公開範囲変更は実行前に確認する。
バックアップは「ある」ではなく戻せるかを書く
引き継ぎ文書へパスワードや秘密鍵を書いてはいけません。代わりに、バックアップの対象、日時、保管先の種類、復元担当、確認状況を書きます。
- データベース、uploads、テーマ、プラグイン、設定のどれを含むか。
- 本番サーバーと別の場所にも保管されているか。
- 誰がどの管理画面から復元するか。
- 復元テストまたはRevisionからの戻し方を確認したか。
- 復旧に必要な時間と、復旧中に停止する機能は何か。
引き継ぎ文書に「バックアップあり」とだけ残っている場合は、作業開始前に WordPress作業前のバックアップ完全チェックリスト で、DB・ファイル・外部保管・復元入口を一組として確認してください。
引き継ぎ直後は変更せず五つを照合する
- 指定された作業フォルダが実在し、別サイトではない。
- 必読Markdownの最新日付と次の作業が一致する。
- 公開URL、title、H1、canonical、ステータスが記録と一致する。
- Git差分や未保存Revisionに、別作業の変更が混ざっていない。
- 禁止事項と復旧方法を説明できる。
一致しない時は、文書か公開状態のどちらが正しいかを推測しません。「記録では公開済みだがURLは404」のように差を報告し、変更前に、どちらを正しい状態として扱うか決めます。
引き継ぎが成功したと判断する基準
- 新しいチャットが対象サイトと作業フォルダを言える。
- 公開済み、下書き、未実施を別々に説明できる。
- 変更禁止の対象と、許可された確認を言える。
- 最初に変更する一件と、合格条件が決まっている。
- 秘密情報を表示せず、復旧入口を確認できている。
長い要約を返せることより、「いまは何を変えず、何を一件だけ進めるか」が一致することを重視します。
よくある質問
前のチャット全文をコピーする必要はありますか？
通常は必要ありません。恒久ルール、現在の公開状態、未実施事項、禁止事項、復旧情報をMarkdownへ整理した方が、古い相談や撤回済み案を混ぜにくくなります。
README.md一つだけでは不足ですか？
小さなサイトなら一つでも始められます。ただし恒久ルールと頻繁に変わる進捗が長くなったら分け、読む順序をREADMEに残すと安全です。
パスワードの保管場所を書いてよいですか？
秘密値そのものや取得方法を会話・公開文書へ書かないでください。「本人がログイン済み」「認証情報は共有しない」のように作業条件だけを記録します。
公開済み記事に未修正箇所がある場合はどう書きますか？
「記事は公開済み」と「見つかった修正候補」を分けます。緊急に非公開へ戻す必要があるのか、公開を維持して次のRevisionで直すのかも明記します。
Gitを使っていないサイトでも引き継げますか？
引き継げます。CMSのRevision、サーバーバックアップ、変更前コピーなど、実際に使える復旧方法を記録してください。
新しいチャットで最初に変更を頼んでもよいですか？
まず記録と公開状態を照合するのがおすすめです。対象、差分、禁止事項、戻し方が一致した後に、一件だけ変更します。
引き継ぎ文書は公開してよいですか？
通常はプロジェクト内部で管理します。サーバーパス、管理URL、個人名、内部構成などが含まれる場合があるため、一般公開の記事本文や公開リポジトリへそのまま置かないでください。
引き継ぎ文書はいつ更新しますか？
公開、URL変更、ステータス変更、復旧方法変更、禁止事項変更、次作業の決定時に更新します。作業終了時だけでなく、重要な状態が変わった直後に残します。
公開済みと未実施を分け、禁止事項は対象と行為まで書きました。最初は変更せず、記録と公開URLを照合してもらいます。
それなら、新しいチャットが過去の案を現在の事実と取り違えにくいね。差があれば、直す前に報告してもらおう。
最後に次の一作業と合格条件を書けば、「続き」だけでも迷わず進められそうです。
うん。作業が終わるたびにいまの正しい状態を更新すれば、チャットが変わってもサイトの状態は失われないよ。
まとめ：次の担当が事実から始められる状態を作る
安全な引き継ぎは、長い会話履歴を残すことではありません。恒久ルール、現在の公開状態、未実施事項、禁止事項、復旧情報、次の一作業を、人が確認できるファイルへ分けて残すことです。
「公開済み」と「検査未実施」、「案を作成」と「CMSへ保存」、「公開」と「完了」を分けてください。 新しいチャットでは最初に変更せず、記録と公開URLを照合します。これができれば、既存WordPressサイトを壊さず、前回の続きから進められます。
カテゴリ全体の工程へ戻る場合は、 CodexでWordPressサイトを作る完全ガイド から次の段階を選んでください。