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