1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

プログラマティックSEOの1.9万ページがAdSenseの「有用性の低いコンテンツ」判定から復帰するまで

1
Posted at

3行まとめ

  • 公的ハザードデータを町丁目単位で配信する個人開発サービス(約19,000ページ)がAdSense審査で「有用性の低いコンテンツ」判定を受けた
  • 原因は市区レベルのデータを町丁目ページに表示する際、散文の段落が同一市内の全ページで文字どおり一致していたこと。「AIで書いたかどうか」ではなく「重複しているかどうか」が判定基準だった
  • 自動生成文に独自の体験談を書き込む対策は人手の制約上不可能だったため、(1)粒度が上げられないデータは正直にラベル化する (2)上げられるデータは粒度自体を上げる (3)自動生成文はテンプレ置換でなくデータの組み合わせで内容そのものを変える、の3方向で設計し直し、再申請で承認された

公的データ(地震・洪水・土砂災害などのハザード情報、人口統計、不動産相場)を町丁目単位で可視化する個人開発サービスを運営している。地点ごとにページを自動生成する「データベース型SEO」で、現在約19,000ページを公開している。このサイトがAdSense審査で「有用性の低いコンテンツ」判定を受け、再承認まで取った対策を書く。サービス名は非公開だが、使った公的API・技術的な対策は具体的に書く。

判定内容:複製コンテンツ、AIかどうかは関係ない

AdSenseの「有用性の低いコンテンツ」は、Googleの用語で言うと scaled content abuse(スケールした複製コンテンツの濫用)に該当する。審査で問題視されたのは、第三者データに付加価値を付けずに複製しているように見えるページだった。

重要なのは、この判定基準にAIで書いたかどうかは関係ないということ。このサイトはCLAUDE.mdの方針で定型文の自動生成のみが許可されていて、レポート部分のAI生成は最初から使っていない。それでも「有用性が低い」と判定された。Googleのポリシーはコンテンツの生成手段ではなく、ユーザーにとっての価値の有無で判定する。

原因診断:市区データが町丁目ページ全部で一致していた

診断してみると、致命度が最も高かったのは次の問題だった。

  • 不動産取引価格・賃料相場のデータが、API仕様上そもそも市区単位でしか取得できない
  • それをそのまま各町丁目ページに表示していたため、同じ市内の全ページで数値も説明の散文も完全に一致していた

ある区では277ページすべてで、不動産価格セクションの説明段落が一字一句同じになっていた。数値の表や短い定型キャプションはGoogleもボイラープレートとして問題視しないが、同一の文章段落がページ数分そのまま繰り返されるのは複製コンテンツの核になる。

次点の問題は、自動生成文がいわゆる穴埋めテンプレ(数値だけ差し替わるMad-lib形式)だったこと。これも「情報内容は変わらず表現だけ違う」と見られるリスクがあった。

制約:19,000ページに人力で独自文は書けない

一般的な「有用性の低いコンテンツ」対策としては、各ページに独自の体験談や解説を書き加えるのが定石とされる。ただこのサイトにはCLAUDE.mdレベルの制約として「レポート文章はテンプレート埋め込みのみ、コラムは人間手書き」というルールがあり、19,000ページぶんの独自文を人力で書くのは現実的に不可能だった。

そこで「全ページを個別に書き込んで通す」という発想は最初から捨て、(a) データ自体の固有性を上げる、(b) 重複の核になっている部分を取り除く、(c) 自動生成でも付加価値が審査側に読み取れる形にする、という3方向で設計し直した。

対策1:粒度を上げられないデータは「正直にラベル化」する

不動産取引価格・賃料のように、データ提供元の仕様上どうしても市区単位でしか取れない指標がある。これを町丁目固有のデータのように見せかけるのをやめ、「市区単位の参考値である」ことを明示する方向に変えた。

  • セクション見出しに「市区単位の参考値」であることを示すラベルを追加
  • 重複の核になっていた多文の説明段落そのものを削除し、「このデータは市区単位の集計である」ことだけを伝える短い定型キャプション1文に置き換え
  • 数値の表・都道府県との比較(1行)・推移グラフはユーザー価値として残す

重複していたのは「データ」そのものではなく「データを説明する散文」だった。表や短い注記はそのまま残し、重複の原因になっていた段落だけを外す、という切り分けが効いた。ただし数値の表自体は市区粒度のまま変わらないため、この対策単体でAdSenseの判定を覆すには力不足で、次の対策と組み合わせる前提だった。

対策2:粒度を上げられるデータは、API仕様の裏を取って昇格させる

人口統計は逆に、町丁目単位に粒度を上げられる見込みがあった。通常使っていたe-Stat(政府統計の総合窓口)APIの市区町村別統計では小地域(町丁目)のテーブルが取得できなかったが、調査の結果、統計表を検索するAPIに特定のクエリパラメータを渡すと、都道府県別に小地域集計テーブルが見つかることが分かった。ドキュメントで目立つように案内されている機能ではなく、検索APIのパラメータ一覧を一通り試してようやく見つけたものだった。

ここから都道府県ごとに統計表IDを解決してマップ化し、小地域テーブルから町丁目単位の人口・年齢区分データを取得できるようにした。ただし取得したデータの地域キーは、サイトの既存の地域コードとは別仕様だったため、e-Statの地域名から市区名を取り除き丁目の数字表記を正規化して既存の地域名と突き合わせる、という名寄せ処理も追加で必要になった。東京23区の一部でこの名寄せを試したところ、ほぼ全件が一致した。一部の地域は人口が少なく秘匿処理の対象になるが、ゼロ件と表示すると「本当に人口がいない」と誤解されるため、秘匿対象であることが分かる表示に分けている。

「データソースの標準的なエンドポイントに小地域データがない」で諦めず、検索パラメータの仕様を掘って町丁目粒度を獲得できたことが、この対策の中では一番手応えのある部分だった。

対策3:自動生成文はテンプレ置換でなく、データの組み合わせで内容を変える

残る論点は、自動生成するリスク要約文そのものの固有性。ここで避けたのは「意味の変わらない同義語への置換」や「語順をランダムに入れ替える」といった、いわゆるスピン手法。これは別途ドアウェイ・スピンコンテンツとしてペナルティ対象になりうるため、最初から選択肢に入れなかった。

代わりに採ったのは、データの値や組み合わせによって文章の情報内容そのものが変わる分岐にすること。リスクが高い災害種別の組み合わせパターン(複数種別にまたがる・浸水系が重なる・土砂特有など)によって文章の骨格を変え、表に並んでいるだけの複数の生データを因果関係のある1文に統合する処理も加えた。「地震のスコアが低い」と単独で書くのではなく、想定震度の発生確率と地盤の揺れ増幅率のような複数の生データを1つの観察文に束ねる。こうすると地域ごとに参照する数値の組み合わせが変わるので、文章も自然に変わる。リスクの帯によって表現のトーンも変えていて、低リスク帯では過剰なアラームにならない穏やかな言い回しに、注意が必要な帯では防災行動の助言を添える、という分岐も入れた。防災行動の助言は「取れる行動」の案内に限定し、地点そのものの良し悪しを評価する価値判断の言葉は使わないようにしている(不動産取引に関わる表示のため)。このデータ駆動分岐の実装詳細は別記事で解説済みなので、ここでは繰り返さない。

検討したが見送った対策:薄いページのnoindex

当初は「データが乏しい町丁目ページをnoindexにしてサイトマップから除外する」という対策も候補に挙がっていた。ただ、対策2・3を実装した時点で「乏しいページ」自体がほぼ存在しなくなったこと、検索エンジンのインデックス登録がまだ蓄積中の段階でnoindexを入れると登録済みページを失うリスクがあることから、この対策は見送った。再度低評価を受けた場合のみ、まずサイトマップからの除外という弱い手段から試す、という条件を決めて保留にしている。

「対策案を全部実装する」のではなく、他の対策で前提が変わった時点で不要になった案を見送る判断をしたこと自体も、この対応の一部だと思っている。

結果:2〜4週間の再クロール待ちを経て承認

対策を実装してすぐ再申請はせず、サイトマップ再送信後に2〜4週間の再クロール待ちを置いてから申請した。古いキャッシュのまま再審査されると不利になるのと、無変更での再申請は審査が厳格化される傾向があるため。結果、再申請で承認を通過した。

まとめ

  • AdSenseの「有用性の低いコンテンツ」はAI生成かどうかではなく、第三者データに付加価値のない複製として見えるかどうかで判定される
  • 19,000ページ規模のプログラマティックサイトで人力の独自文追加が使えない制約下では、(1)粒度を上げられないデータの正直なラベル化 (2)API仕様の裏を取った粒度昇格 (3)データ駆動の分岐による自動生成文の固有化、という3方向の組み合わせが効いた
  • 重複の核は「データ」そのものではなく「データを説明する散文の段落」だったので、数値表や短い注記は残しつつ、重複していた段落だけを狙って削るという切り分けが有効だった
  • 対策を進めるほど前提が変わるので、当初検討していた対策(noindex)を途中で見送る判断も含めて対応した

公的データ×災害リスクサイトのアーキテクチャ全体(DB型SEO・出典自動生成・法務設計)は、以下の本でさらに詳しく解説している。
https://zenn.dev/sktt_panda/books/public-data-hazard-site


この記事は Zenn にも同じ内容を投稿しています。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?