AIでコンテンツを作る際に大事なのは「AIで作れるか？」ではなく「本当に必要か？」

グーグル検索SEO情報②

AIでコンテンツを作る際に大事なのは「AIで作れるか？」ではなく「本当に必要か？」
大規模コンテンツ制作における評価フレームワーク （Aleyda Solis on LinkedIn） 海外情報

「AIを活用したコンテンツ作成が適している場合」と「適していない場合」の違い、そしてその判断基準を、スペインを拠点とするSEOコンサルタントのアレイダ・ソリス氏が共有した。要点をまとめる。

適したケースと不向きなケース

• 適した例 ―― 構造化された独自データがすでにコンテンツとは別に存在する領域。
  たとえば、次のようなものだ：
  • 大規模ECの商品カタログ
  • マーケットプレイスの出品情報
  • ソフトウェア連携ページ
  • など
• 不向きなケース ―― 専門家の知見や体験（E-E-A-T）を要する解説記事やガイドの大量生産。

AI導入前に検討すべき評価基準

• ユーザーニーズと検索目的 ―― 検索流入だけを目的にしない。必ず、「AIで作るこのページは、ユーザーにとって価値があるか」を判断する。

• 情報の独自性 ―― ページごとに固有・差別化されたデータ入力があるか。他で得られない価値を提供できるか。

• 正確性と品質担保 ―― 長期的に品質と正確性を検証し、ブランド体験を損なわない体制を保てるか。

• 低リスクな代替案 ―― AI生成以外の方法で、より低リスクかつ優れた体験を提供できないか。

成功のための運用要件

• 「自社データの活用」「品質保証システム」「人による編集・事前検証のステップ」を組み込む。
• 技術展開に合わせて判断基準を継続的に見直す。
• グーグル公式の「AI生成コンテンツのガイドライン」も併せて参照・準拠する。

軸とすべきは、「AIで作れるかどうか」ではなく、「そのページが本当に必要で、AIを使っても品質・独自性・ユーザー価値を確保できるか」である。

AIコンテンツ活用で組織を蝕む「育成の負債」「コンテンツ負債」
育成の負債、格差の拡大など （Content Marketing World） 海外情報

AIを使えば、経験の浅いマーケターでも一見プロらしい成果物を作れる。しかし、弊害も発生することを指摘する記事を紹介する。

AIの利用により、試行錯誤を通じて判断力や審美眼を養う「実務体験」を省くと、成果物の価値を見極められない「育成の負債」が蓄積するというのだ。この判断力の欠如が積み重なると、別の問題が生じる。管理不全となった古い情報を適切に評価・削除できなくし、「コンテンツ負債」の解消を阻む要因となるのだ。

経験の浅いマーケターによるAI利用が引き起こす可能性がある弊害として、次のような具体例を記事は挙げている：

• 育成の負債の発生 ―― 「会議の傾聴」「10回以上に及ぶ議事録の書き直し」「泥臭い試行錯誤」などのプロセスをAIに依存して飛ばすことで、成果物の「良し悪し」を察知する感覚や判断力が育たなくなる。

• AIによる格差の拡大 ―― AIは「制作効率」を上げるが、「判断力そのもの」は生み出せない。金融の「ブルームバーグ端末」のように、過去の実務で判断力を培ってきた熟練者ほどAIの効果を増幅させられるため、未経験者との差はむしろ広がる。

• パイプラインの空洞化 ―― 企業が若手向けのポストを削減し、判断力ではなく「ツールの操作法（プロンプト）」の教育に偏重すると、将来の熟練人材が育たない業界構造が生じる。

• 2つの負債の連動 ―― 「コンテンツの整理や削減」は高度な判断力を要する作業である。育成の負債を抱えたチームは、「どのコンテンツを残し何を捨てるべきか」を判断できず、結果としてコンテンツ負債をさらに悪化させる。

解決策として「現場での実践」を積ませることを記事は推奨している。単にツールを禁止するのではなく、コンテンツ監査の場に若手を同席させ、「何が正しく、何が不要か、なぜそうなのか」を経験者と対話・議論させることで、判断力という体験の蓄積を担保するのだ。

AI時代の真の競争力は「生成能力」ではなく「評価・判断能力（審美眼）」にある。効率化を追求しつつも、若手が実務での議論や評価の反復を通じて判断力を磨く「育成の場」を意図的に残すことが不可欠である。

ビジネス寄りの内容ではあるが、SEOもビジネスを発展・拡大するための手段といえるので取り上げた。

多言語サイトで、インデックス未登録のURLが検索結果に表示されるのはなぜ？
クラスター内の代替URLだから （Gary Illyes on LinkedIn） 海外情報

多言語グローバルサイトのグーグル検索の挙動に関して、次のような質問をリンクトインに投稿したユーザーがいた。

クラスター内^※でグーグル自身が選択した正規URLを採用した結果、主要言語以外のURLは「インデックス未登録」となっている（Search Consoleで確認できる）。にもかかわらず、ページのローカライズ版／言語別バージョンのURLを検索結果に表示できるのはなぜか？

要は、「言語ごとのページは、正規URLではないとしてインデックス非登録状態なのに、どうして検索結果に表示されるのか」を質問者は疑問に思っている。

グーグルのゲイリー・イリェーシュ氏は次のように回答した。

2つの要因が絡んでいる：

1. 代替名（alternate names） ―― あるURLを正規化する際、その正規URLが選ばれた重複クラスター内の他のURLは、いわゆる「代替名」になることがある。これらは、ユーザーのクエリがそれらの代替名のいずれかに該当する場合、検索結果で使用されることがある。最も顕著な使用例は「site:」検索だ。[site:bit.ly]のような検索を行うと、実際にはリダイレクトするだけのURLが多数表示されることがある。これらは本来の意味でインデックスされているわけではなく、単に正規URLの代替名にすぎない。

2. hreflangの代替URLもこの種の代替URLになる ―― これらも、本来の意味でインデックスされているわけではない。

代表のURLとしてインデックスされるのは「正規URL」である。しかし、クラスター内には、正規URL以外の同内容（とグーグルが判断した）URLが「代替URL」として含まれている。クエリによっては、正規URLではなく代替URLが検索結果に表示されることがあるのだ。

最たる例がhreflangを構成したURLだ。スペイン語で検索したら代替URLのスペイン語ページが選ばれるし、日本語で検索したら日本語ページが選ばれる。いずれも正規URLではない。

言語・国を指定するhreflangはrel="alternate"要素とともに用いるが、「alternate」はまさしく「代替」という意味だ。hreflangは、どの言語・国のクエリに対してどの代替ページを検索結果で表示すべきかをサイト側からグーグルに能動的に指示している。グーグルはその情報を記録して管理しているため、「正規URL」ではなく「代替」として処理できるのだ。

GooglebotがサポートするHTTPメソッドは？ GETやPOST以外も送信する？ 新しいQUERYは？
QUERYは将来的にはサポート予定 （Gary Illyes on LinkedIn） 海外情報

グーグルのクローラーはGETやPOST以外のHTTPリクエストを送信するのか？

この問いへの回答を、検索チームのゲイリー・イリェーシュ氏がリンクトインに投稿した。そうした質問を立て続けに聞かれたのだという。

結論から言うと、グーグルはGETやPOST以外のHTTPメソッドを利用している。

ただし、大部分はGETだ。それ以外のHEAD、OPTIONS、PUT、PATCH、DELETEを合わせても、グーグルのすべてのクローラーが送信するリクエストの総数の1.5%未満にすぎない。

ではなぜこうした種類のHTTPリクエストを送信しているのか。JavaScriptが原因だ。基本的には、何らかのJavaScriptの処理がこれらのリクエストを発生させ、レンダリングがそのレンダリング処理を行っているようだ。

そのうえでイリェーシュ氏は、RFC 10008として提案された「QUERY」メソッドに関して、さらに解説した。

「QUERY」は新しいHTTPリクエストメソッドで、既存の「GET」「POST」などに並ぶもの。ただし、現在はまだ「Proposed Standard」（提案）の段階で、「Internet Standard」（標準）にはなっていない。

こうした質問が多かった理由は、HTTPにQUERYという新しいメソッドが追加されたことだろう。

インターネット向けの開発では、一般的に次の2つのどちらかを選ぶことになる：

• GETを使う場合 ―― すべてのパラメータをURL文字列に詰め込む。安全でキャッシュ可能だが、検索フィルタが複雑になるとURLが壊れてしまう。

• POSTを使う場合 ―― 任意のサイズのリクエストボディを受け取れるが、間に入るサーバーはデフォルトではキャッシュしてくれない。

QUERYは、この欠けているピースを組み合わせたものだ。GETと同様に「安全」「何回繰り返しても同じ結果」「キャッシュ可能」でありながら、POSTのように構造化されたデータを送信できる。

QUERYメソッドが価値をもつのは、たとえばファセットナビゲーションや複雑な検索フィルタだ。GETだとURLが異常に長くて複雑になってしまうし、POSTだとエッジ／CDNのキャッシュやクロール可能性を損なってしまう。でもQUERYメソッドを使えば、サーバーは複雑なフィルタ条件をすっきりと処理できるし、キャッシュも効く。

しかし、QUERYメソッドがインターネットで一般的に使われるようになるには時間がかかるだろう。まず、Webサーバー、CDN、リバースプロキシ、ブラウザが対応する必要がある。それには今後数年かかるだろう。HTML自体も更新が必要だし、CORSの仕組みも更新が必要だ。

インターネット全体のエコシステムがQUERYメソッドに対応していくにつれ、グーグルの仕組みもいずれQUERYメソッドをサポートすることになるだろう。それまでは、通常のGET用URLを使い続けることになるだろう（URLクエリ文字列は整理整頓してね）。

「QUERY」は、GETとPOSTの両方の長所を兼ね備えているとのことである。エコシステムが追いついた段階で、グーグル検索（Googlebot）も将来的にQUERYメソッドをサポートする予定だが、今すぐの話ではない。

GoogleマップとGeminiが連携、スポット検索や旅行計画をAIがサポート
ローカル情報を自然言語でマップに相談 （Google Japan Blog） 国内情報

Googleマップの新機能「マップに相談（Ask Maps）」が日本国内向けに順次提供開始された。Geminiとの連携により、自然な会話形式で複雑な条件のスポット検索や旅程作成が行える。また、Gmailとの連携による予約情報に基づいた提案や、リアルタイムの交通・遅延情報の確認にも対応している。

「マップに相談」を実際に試してみた。

検索バーの下の「マップに相談」から利用する。

次のように相談した。

今、皇居にいます。スマホの充電が切れそうです。長い列に並ばずにコーヒーが飲めて充電できる場所を教えて。

条件にあったカフェを2つ提案してくれた。

ユーザーの立場では、「マップに相談」を活用することで、従来の検索やクチコミの確認にかかっていた手間を大幅に削減し、日常の移動や旅行の計画をよりスムーズに行えるようになる。

ローカルビジネスの立場では、ビジネスプロフィールの項目を漏れなく正確に埋めることが今まで以上に重要になるだろう。さもないと、条件に合致しないとして推薦されないかもしれない。

また、「具体的で文脈のあるクチコミ」を集める導線づくりも欠かせなくなりそうだ。たとえば「席の雰囲気や利用シーン、メニューの感想などをぜひお寄せください」といった一言を添え、AIが読み取りやすい具体的なキーワードを含んだレビューが集まる仕組みをつくるといった施策が考えられる。

海外SEO情報ブログの
掲載記事からピックアップ

今までにない、AI検索の最適化（？）に関するトピックを2本ピックアップ。

• llms.txtはGEOに特別な効果があるのか？「cats.txt」実験で検証

  “パロディ”ファイルでもllms.txtと同じ効果あり

  ★★★★☆

  • AI SEOがんばってる人用（ふつうの人は気にしなくていい）
• TIME誌、ユーザーにはHTML、AIクローラーにはMarkdownを配信

  AIクローラーにも広告配信

  ★★★☆☆

  • AI SEOがんばってる人用（ふつうの人は気にしなくていい）