AIで記事下書きを作ると、短時間で整った文章になります。しかし、整っているだけでは有用な記事とは限りません。このサイトがAdSenseで有用性の低いコンテンツと判断された理由の一部は、記事が一般論に寄り、実際のリポジトリや実装と結び付いていなかった点にあると考えています。この記事では、AI下書きを公開前にどう直すかを、このサイトの改善作業に沿って整理します。
最初に消すべき表現
確認できない実体験は、本文から外します。たとえば、実際に試した、問題なく動いた、最短で完了した、収益が出た、審査に通った、という表現は、確認できる記録がある場合だけ使います。確認できない場合は、この構成ではこう実装している、デプロイ後の確認が必要、のように書き換えます。
下書きをリポジトリに接続する
記事の中で、どのファイルを根拠にしているかを確認します。Cloudflareの記事なら wrangler.toml と src/index.ts、D1の記事なら migrations/、GASの記事なら gas/fetch_threads.gs、管理画面の記事ならadmin関連のHTMLとAPIを見ます。根拠ファイルが見つからない文章は、一般論として残すのではなく、削るか要確認にします。
公式資料の扱い
公式資料は、仕様や機能名を確認するために使います。ただし、公式ドキュメントの言い換えだけで記事を作ると独自性が出ません。この記事群では、Cloudflare Workers、D1、GASの公式リンクを参考資料として置きつつ、本文ではこのCMSでどう使っているかを中心に書きます。
公開前のレビュー項目
- タイトルが広すぎないか
- slugを変えずに具体的なタイトルへできるか
- 本文に実ファイル、実設定、実装上の判断があるか
- 下書きやnoindexにすべき記事が公開されていないか
- RSSとsitemapが公開対象だけを返しているか
- 関連記事が文脈上つながっているか
このサイトで追加した安全弁
今回の改善では、記事に review_status を追加しました。公開条件は reviewed の記事だけです。AIで作った下書きに事実確認が残る場合は fact_check_required にして、公開面、RSS、sitemapから外せます。これは、記事を削除せずに編集途中として残すための仕組みです。
AIを使うこと自体が問題なのではなく、確認できない内容を自然な文章にして公開してしまうことが問題です。AIは文章整理の補助として使い、根拠はリポジトリ、公式資料、管理画面の確認に置く。この運用を 編集方針 として固定ページにも反映しました。