AIへ読者、検索意図、実体験、禁止事項を渡しても、そのまま公開できる記事になるとは限りません。事実として正しい数値でも確認日が違えば、画像と本文が食い違います。
2026年8月28日、ナマズノートで実際に経験したサイトマップ404を題材に、Codexで初稿を作りました。保存初稿は画像指定情報を含めて4,426文字です。保存初稿と8月28日朝の修正版を比較すると、追加10行・削除5行、合計15行の差分がありました。
保存初稿と8月28日朝の修正版で変わったのは、Search Consoleの確認日・キャプションと、関連記事カードへ変換するための内部リンクの置き方です。撮影できなかったXML画面の扱いは作業記録に残る判断として、原稿の差分と分けて紹介します。
今回の検証条件
| 項目 | 内容 |
|---|---|
| 実施日 | 2026年8月28日 |
| 使用AI | Codex、GPT-5.6 Luna、reasoning max |
| 記事テーマ | SWELLでwp-sitemap.xmlが404になった原因 |
| 対象読者 | SWELL利用中にWordPress標準サイトマップが404になった人 |
| 保存初稿（画像指定情報を含む） | 4,426文字、105行 |
| 8月28日朝の修正版（画像指定情報を含む） | 4,561文字、110行 |
| 修正記録上の時刻差 | 10分24秒 |
| 当時の修正記録 | 3段階 |
10分24秒は、当時の修正記録にある08:45:09から08:55:33までの時刻差です。記録上の対象は、初稿ファイルの作成から、公式情報とWordPress・Search Consoleの実画面を照合して8月28日朝の修正版を保存するまでです。アイキャッチ生成、WordPress入稿、公開後確認は含めていません。今回、実行時間を再測定したものではありません。
4,426文字・4,561文字は、保存ファイルから先頭の管理情報を外し、前後の空白を除いて数えた値です。画像の指定情報を含むため、読者に見える本文だけの文字数ではありません。保存初稿と8月28日朝の修正版を比べると、追加10行・削除5行でした。 8月28日午後にはカテゴリサイトマップの記述も訂正されているため、この15行は公開最終稿までの全差分ではありません。
AIへ渡した記事テーマと検索意図
記事テーマは「SWELLでwp-sitemap.xmlが404になった原因｜実際に直した設定」です。
想定した読者は、SWELLを使っていて/wp-sitemap.xmlを開いたら404になり、サーバー、プラグイン、テーマのどこを確認すればよいか分からない人です。
検索後にできるようになってほしいことは、次の4つに絞りました。
- SWELLの設定場所へたどり着く
- WordPress標準サイトマップを使う構成か確認する
- 停止設定を戻す
- 親・子サイトマップとSearch Consoleを確認する
検索意図を「サイトマップとは何か」まで広げず、404を直して確認するところへ限定しました。
保存している入力記録
8月28日の入力記録には、記事要件と、事実として使ってよい情報を分けて残しています。記事要件は次のとおりです。
- どのタイミングで気づいたか
- wp-sitemap.xmlがどうなっていたか
- Search Consoleとの関係
- 原因として確認した設定
- SWELL側で確認した場所
- 修正方法
- 修正後の確認
- 失敗した点
- AdSenseとの関係を断定しない
- SWELLレビューへの内部リンク
- 実際の体験が確認できない部分は捏造しない
- 初心者が画面を追える日本語にする
- SWELL・Gutenberg標準ブロックを優先する
さらに、事実として使ってよい情報も分けて渡しました。
- SWELL設定の「コアのサイトマップ機能を停止する」が有効だった
/wp-sitemap.xmlが404になった経験がある- 停止解除後、親と子のサイトマップがHTTP 200になった
- 2026年7月13日のSearch Console記録は成功、18ページ検出、動画0
- 当時の404画面は保存していない
- AdSense不合格との因果関係は確認できない
料金、順位、収益、発生日など、確認できない内容は補わないよう指定しました。
保存している入力記録には、次の条件も残っています。
実際の体験が確認できない部分は捏造しない
当時の404画面は保存していない。安全のため、設定を戻して404を再現しない。
この記録は制作時に渡した要件の保存資料です。会話全文や、配布中の拡張版プロンプトを無修正で実行した記録としては扱っていません。
保存初稿はどんな内容だったか
初稿は、症状、原因、修正手順、Search Console、再発防止の順にまとまりました。
見出しの流れは次のとおりです。
- 404に気づいたときの状態
- 原因はSWELLの機能停止にあった
- 実際に戻した設定
- 親と子のサイトマップを確認
- Search Consoleで成功を確認
- 管理画面だけ見て終わらせた失敗
- AdSenseとの関係は断定できない
- まとめ
文章の流れは使えました。ただし、初稿に書かれた一つひとつの事実が「過去の記録」なのか「現在の画面」なのかは、別に確認する必要がありました。
初稿で良かった部分
症状から解決までの順番が崩れていなかった
404に困っている読者が先に知りたいのは、一般的なXMLの仕組みではなく、どこを直すかです。初稿は原因と設定場所を早い段階へ置いていました。
404画面を再現しない判断を残せた
当時の404画面は保存していません。画像を作るために停止設定へ戻すと、正常なサイトマップを再び止めます。初稿では、再現画像を作らない理由まで本文へ入れられました。
AdSenseとの因果関係を分けられた
ナマズノートはAdSense審査に不合格となった経験があります。しかし、通知にはサイトマップ404が理由とは書かれていません。プロンプトで断定禁止を指定したため、「直せば合格する」という文章は入りませんでした。
削除・書き直した部分
過去の18ページを現在の画面へ使いかけた
保存している初稿では、Search Consoleの画像に次のキャプションを付けていました。
キャプション：2026年7月13日に再送信し、ステータス「成功しました」と18ページの検出を確認しました。
一方、載せる画像の最終読み込み日は8月25日で、検出ページ数は34でした。7月13日の記録にある18という数値を、そのまま8月28日に確認した画像の説明へ使うと、本文と画像が食い違います。
修正版では、キャプションを次のように変えました。
キャプション：2026年8月28日の再確認では、最終読み込み8月25日、ステータス成功、34ページ検出でした。
本文にも7月13日の初回記録と8月28日の再確認を分けて残しました。数字が正しいかに加え、どの時点の数字なのかを画像と照合する必要がありました。
| 確認時点 | 表示 |
|---|---|
| 2026年7月13日の初回記録 | 成功、18ページ検出、動画0 |
| 2026年8月28日の再確認 | 最終読み込み8月25日、成功、34ページ検出 |
保存初稿の画像指定情報には34ページとある一方、表示用キャプションは18ページでした。ファイル内でも記述が一致していないため、保存初稿を会話から取り出した無修正のAI生出力とは扱っていません。
完成した設定手順とSearch Consoleの画面は、サイトマップ404の修復記事で確認できます。
撮れなかったXML画面を画像計画から外した
修正記録には、復旧後のXML画面を撮ろうとしたものの、作業中のブラウザで表示できず、SWELL設定とSearch Consoleの画像だけに絞ったことが残っています。
ただし、保存されている初稿ファイルの画像一覧は、すでにこの2枚になっています。XML画面を含む変更前の画像一覧は確認できないため、この判断を原稿の差分として示すことはできません。当時の404画面も保存しておらず、説明用の再現画像は作っていません。
通常の内部リンクをSWELL関連記事カードへ変えた
初稿では、本文中の文章へ内部リンクを置いていました。リンク自体は正しくても、ナマズノートの入稿ルールでは次に読む記事をSWELL関連記事カードへ統一しています。
リンクを独立行へ分け、Gutenberg入稿時にwp:loos/post-linkへ変換しました。
保存資料と作業記録の区別
原文比較で確認できるのは、Search Consoleの本文・キャプション、日付別の表、内部リンク2か所の独立行化です。XML画像を使わない判断、修正の3段階、所要時間は当時の作業記録に基づきます。初回の会話全文と、XML画像を含む変更前の画像一覧は確認できていません。
当時の修正記録に残る3段階
1回目｜事実と画像計画
当時の作業記録では、数値を確認日で分け、保存できた2枚の画像だけを使う判断を残しています。
2回目｜内部リンク
SWELL初期設定記事と約1年レビューへのリンクを独立させ、関連記事カードへ変換できる形にしました。
3回目｜SWELL入稿データ
当時の作業記録では、MarkdownをGutenbergブロックへ変換し、SWELLバリデーターで通常の内部リンクが残っていないことを確認したとあります。
完成稿で変わらなかったこと
修正後も、記事の中心は変えていません。
- 原因はSWELL設定の停止項目
- 別のサイトマッププラグイン利用時は重複を確認する
- 設定保存後に公開URLを開く
- 親だけでなく子サイトマップも見る
- Search Consoleの成功はインデックスや順位を保証しない
- AdSenseとの因果関係を断定しない
構成を全部捨てるのではなく、使える部分を残して事実の境界を直しました。
次回のプロンプトへ追加する4つ
次回は、記事要件へ次の4つを追加します。
- 過去の数値と現在値を同じ文で扱わず、確認日を必ず付ける
- 撮影できない画面は代替画像で埋めず、画像計画から外す
- 内部リンクはSWELL関連記事カードへ変換できる独立行にする
- 実画面を確認してから画像キャプションを書く
プロンプトを長くすることより、事実の確認日と公開条件を明確にする方が、修正量を減らせます。
まとめ｜初稿は確認箇所を見つけるために使う
保存初稿は画像指定情報を含めて4,426文字、8月28日朝の修正版は同じ数え方で4,561文字でした。原文の差分を比べると、記事の流れを残しながら、確認日とキャプション、内部リンクの置き方を修正しています。撮影できた画像の範囲は作業記録と照合して判断しました。
- 良かった部分は残す
- 数字へ確認日を付ける
- 実画面とキャプションを照合する
- 撮れない画像は作ったことにしない
- サイト固有の公開ルールで検査する
AIへ渡す情報を調査・体験・公開条件に分けた理由は、プロンプト設計の記事で詳しく整理しています。
記事テーマの決定からSWELL装飾、スマートフォン確認、公開までの全体は、実演記事から順番に確認できます。
コメント