AIの回答は、完成原稿ではなく下書きとして扱います。このサイトでは、文章としては読めるのに、運営の実態と合わない記事を公開してしまったからです。

私はWordPressを使っていません。それでも、提携した広告案件へつなげようとしてWordPressの記事を増やし、実践サイトなのか調査サイトなのか分かりにくくなりました。AIが書いた文章の誤字だけを探しても、この矛盾は直りません。

現在は、本文を書く前に「自分がしたこと」「公式ページで確認したこと」「まだ分からないこと」を分けています。公開までに使う確認手順を、実際の失敗と一緒に残します。

この記事で実体験として書くのは、CodexでAstroサイトを直し、GitHubとCloudflare Pagesを使って公開した範囲です。WordPress、エックスサーバー、mixhostは使っていません。料金や機能に触れるときは、公式ページで確認した内容と自分の判断を分けて書きます。

1．一文ずつ、根拠の種類を決める

私は取材メモを作るとき、事実を3種類に分けます。

種類 このサイトでの例 書いてよい範囲
実体験 Astroで公開し、Codexで記事を修正した 実際に行った操作と確認できた結果
公式情報 Cloudflare Pagesの上限を公式資料で読んだ 資料に書かれた条件と確認日
自分の判断 今はAstroを使い続ける 判断した理由と、変わる条件

「一般的に人気」「初心者でも簡単」といった言葉は、どこにも置けません。誰が、何を根拠に判断したのか分からないからです。

分類できない文は、本文へ入れる前に止めます。うまく分類できないときは、事実ではなく雰囲気を書こうとしていることが多いです。

2．空欄をAIに埋めさせない

記事の形を整えようとすると、分からない数字や感想まで埋めたくなります。ここで「自然に補って」と頼むと、読みやすい架空の体験ができてしまいます。

このサイトでは、分からないものを次のように残します。

ドメイン取得額：記事用の記録なし
WordPressの操作感：未使用のため評価しない
検索結果での表示回数とクリック数：Search Consoleの確認値だけを書く
広告収益：発生と確定を分け、確認できた数字だけを書く

空欄があると記事は少し不格好です。それでも、存在しない体験で埋めるより、読者は判断しやすくなります。

3．検索結果ではなく、元の公式ページを開く

料金、機能、契約期間は変わります。検索結果に出る短い説明や、別サイトのまとめだけでは、現在の条件を確認できません。

私はサービス運営会社の料金ページ、利用条件、公式マニュアルまで開きます。AIに探してもらった場合も、リンク先を自分で読みます。確認した日を残し、後で条件が変わったときに直せるようにします。

OpenAIの公式ガイドにも、現在の情報が必要ならWeb検索と出典を求め、分からない情報は推測せず示すという案内があります。2026年8月27日にChatGPTのプロンプト案内を確認しました。

4．数字は、同じ条件へそろえて計算する

月額料金だけを比べても、契約期間や初回支払額が違えば判断を誤ります。割引後の料金と通常料金、税込と税抜、初年度と更新後も混ざりやすいです。

サーバー比較の記事では、公式ページの数字を同じ契約期間へそろえ、計算式を本文に残しました。AIが出した合計額も、そのまま使わず電卓と元ページで確認します。

料金記事の確認方法は、エックスサーバーとmixhostの2年間の料金比較で実際の表として見られます。両サービスは未契約なので、数字は比較しても速度や管理画面の使いやすさは評価していません。

5．リンク先が、書いた内容を本当に支えているか読む

公式リンクが付いていても安心できません。トップページへリンクしただけで、本文に書いた料金や条件が載っていないことがあります。

リンクを開いたら、次を確認します。

  • 記事で使った数字や条件が同じページにあるか
  • 対象のプランや地域が合っているか
  • 古いキャンペーン情報ではないか
  • ログインしない読者でも確認できるか

出典の数を増やすことより、一つの主張と一つの根拠がつながっていることを優先します。リンク切れも公開前の検査だけでは分からないため、実際にブラウザで開きます。

6．文章の確認と、事実の確認を別に行う

AIへレビューを頼むと、読みやすさ、見出し、重複には気づきやすくなります。ただ、点数が上がっても事実が正しくなるとは限りません。

このサイトでは、Claudeにエックスサーバーとmixhostの2年間の料金比較を採点させ、初回35点から修正後46点まで直したことがあります。この点数は、次に紹介する編集ルールの記事で取り上げているものと同じです。点数は修正候補を探す目安にはなりましたが、未契約のサービスを使ったように見せないか、運営者の動機が本当に書かれているかは、別に読み直しました。

文章を整える過程で起きた失敗は、AIっぽい文章を直すために作った編集ルールにまとめています。評価の高さより、書いた内容と実態が一致することを優先しています。

7．公開画面で読み、使っていない範囲を明記する

編集画面で自然に見えても、スマートフォンでは一文が長く感じることがあります。公開前のプレビューで、改行、句読点、表の横幅、内部リンクの流れを読みます。

未使用サービスの記事では、使っていないことを冒頭に書きます。片方だけを使った比較なら、体験した側と公式情報で確認した側を同じ文章に混ぜません。

修正日も残します。最初から正しかったように見せるより、何を直したか分かるほうが、このサイトの実践記録として役に立つと考えています。

公開前に使っている取材メモ

私は、AIへ本文を頼む前に次の欄を埋めます。書けない欄があれば、調べるか、記事の範囲を狭くします。

この記事を書く理由：
自分が確かめたいこと：
実際に行ったこと：
確認できた結果：
公式情報のURLと確認日：
自分が判断したこと：
まだ分からないこと：
実際には使っていないもの：

このメモを先に作ると、AIへ渡す材料が増えるだけではありません。体験が足りない記事を、無理に一人称で書こうとしていることにも気づけます。

私は、一度の生成で公開しない

今後もAIには構成整理と下書きを頼みます。ただし、出力された本文をそのまま公開することはしません。自分の体験、公式情報、自分の判断へ分けられない一文は削ります。

この手順は記事を速く量産する方法ではありません。むしろ1本にかかる時間は増えます。それでも、公開後にサイト全体の矛盾を直すより、取材メモの段階で止めるほうが手戻りは小さくなりました。

AIへ何を頼み、人がどこを確認するか迷う人は、ChatGPTとCodexをこのサイト制作で使い分けた記録も続けて読めます。実際の公開作業まで含めた流れは、Codexでアフィリエイトサイトを作った記録に残しています。