30秒で要点
Googleは2026年10月8日にUGC Fresh Data Programの解説ページを公開しました。参加条件を読むと、重いのは技術要件ではなく運用要件の側です。
- 対象は主にユーザー投稿・ソーシャル投稿・フォーラム議論をホストするプラットフォーム。事業会社のオウンドメディアは第一項で対象外になる
- 技術要件は2つだけ（OAuth 2.0によるAPI認証と、指定されたschema.orgのマークアップ）
- 鮮度の要求は「数分以内の送信」と「作成後72時間以内のカウンタ更新」で、どちらも一度やれば終わる作業ではない
- 申込は掲載を保証せず、回答までに6〜8週間かかると明記されている
鮮度を「更新日の申告」だと考えていなかったか
鮮度という言葉は、SEO（検索エンジン最適化）の文脈では長く「いつ更新したか」を指してきました。更新日を書く、最終更新を出す、サイトマップに日付を載せる。どれも申告です。申告は一度やれば完了し、やったかやっていないかで判定できます。
ところがGoogleが2026年10月8日に公開したUGC Fresh Data Programの解説ページを読むと、参加条件の側で鮮度が別の意味で使われています。ここで要求されているのは、更新した事実の申告ではなく、更新を続けられる状態そのものです。
この記事は申込ガイドではありません。むしろ大半の読者は対象外です。それでも読む価値があるのは、Googleが「鮮度」という言葉に何を要求したのかが、この条件表のかたちで明文化されているからです。
まず、ほとんどの読者は第一項で対象外になる
参加資格の第一項は、プラットフォームが主にユーザー生成コンテンツ（利用者が投稿した文章や口コミ）・ソーシャル投稿・フォーラム議論をホストしていることです。あわせて、そのコンテンツはプロフィールページやフィードページではなく、安定したURLを持つ専用ページ上にある必要があるとされています。
自社で記事を作って載せているオウンドメディアは、この一行で対象から外れます。規模の要件として「大量のユーザー投稿と相当な利用者基盤」も挙げられていますが、具体的な閾値は書かれていないため、数値で自己診断することもできません。
表が収まらない場合は、横にスクロールできます
| 条件の層 | ページが書いていること | 自己診断できるか |
|---|---|---|
| 対象 | 主にユーザー投稿・ソーシャル投稿・フォーラム議論をホストする | できる（該当するかしないかは明確） |
| 規模 | 大量のユーザー投稿と相当な利用者基盤 | できない（閾値が書かれていない） |
| 技術 | OAuth 2.0によるAPI（システム連携の窓口）認証と、指定されたマークアップ | できる |
| 運用 | 送信の速さ、カウンタの更新、帰属、公開性、モデレーション | 一度では判定できない |
対象外だと分かった段階で読むのをやめてよい記事もありますが、ここで面白いのは下の2行です。技術の列と運用の列で、満たし方の性質がまったく違います。
技術要件は2つしかない
ページが技術的な準備として挙げているのは2点です。安全なOAuth 2.0（外部サービスに認証を預ける仕組み）によるAPI認証を実装できる能力と、schema.orgの SocialMediaPosting または DiscussionForumPosting（いずれも interactionStatistic のサブフィールド付き）による有効なオンページ・マークアップです。
これだけです。詳細な技術文書は受理後に提供されるとされているため、このページから実装の具体を書き起こすことはできません。逆に言えば、技術要件は「やれば終わる」種類の条件として書かれています。実装してテストして通れば、その項目は満たされた状態になります。
鮮度として要求されているのは、時刻ではなく更新の継続
鮮度の項に書かれている要求は2つです。送信するコンテンツは可能なかぎり新鮮に、理想的には数分以内であること。そして、エンゲージメントのカウンタについて、作成後72時間以内の定期更新を送信できること。
ここで指標を定義しておきます。前者は「投稿がサイト上に生まれた時刻から、Googleへ送信した時刻までの経過時間（単位：分）」です。後者は「投稿の作成時刻から、その投稿の反応数の更新を送信した時刻までの経過時間（単位：時間）」で、上限が72です。なお「数分以内」は ideally（理想的には）として書かれた目安で、未達で失格になるとは書かれていません。
この2つは、技術要件とは違って終わりがありません。昨日の投稿を5分で送れたことは、今日の投稿を5分で送れる保証になりません。満たしているかどうかは、常に「直近の運用実績」としてしか言えない形になっています。
終わりのない条件は、鮮度の項だけではない
運用側の条件は他にもあります。すべてのユーザー投稿が公開プロフィールを持つ作者に帰属できる状態であること。コンテンツがGooglebot（Googleの巡回プログラム）と利用者の双方から到達できる公開ページ上にあり、ログインやペイウォール（閲覧に課金や会員登録を要する仕切り）の背後にないこと。違法なコンテンツを公開しないこと。利用者による通報機構を含む能動的なモデレーションを維持すること。
モデレーションについては、水準や頻度の定義がページに書かれていません。「どこまでやれば active（能動的）と言えるのか」はこちらから書けません。ただ、定義が無いこと自体が条件の性質を示しています。チェックボックスとして一度埋めれば済むものではなく、維持している状態を問われているということです。
なぜ鮮度を申告の問題だと誤解しやすいのか
誤解の構造はおそらく単純です。申告は自分の側で完結し、検証もしやすいからです。更新日を書き換えるのは数分で終わり、やったかどうかを自分で確認できます。一方で「更新を続けられる体制がある」は、自分では完了を宣言できません。宣言できないものは、やることリストに載りません。
結果として、鮮度への対応は手を動かした感触の得られる側、つまり日付の申告に寄ります。これは担当者の怠慢ではなく、完了を定義できる作業のほうが選ばれるという、ごく普通の力学です。
確かなことと、ここからは書けないこと
確かなことは、解説ページの公開日が2026年10月8日であること（ページ末尾の最終更新表記と、Search Centralのドキュメント変更履歴の同日の項目が一致します。こちらの確認日は2026年10月20日です）、対象の第一項、技術要件の2点、鮮度要求の2点、運用条件の内容、そして申込が掲載を保証せず回答までに6〜8週間かかると明記されていることです。
書けないことのほうが重要です。このページは検索順位について何も書いていません。 上がるとも、影響しないとも書かれていません。制度の運用開始日、参加しているプラットフォームの実例、承認件数も、ページには存在しません。
したがって「この条件を満たせば評価される」という読み方は、ページの記述からは出てきません。ここから先は仮説の領域です。
対象外の読者が持ち帰れる判断軸
ここからはFirst byte側の仮説で、Googleの方針ではありません。鮮度を主張したいなら、申告ではなく痕跡の設計で考えるほうが筋が通るのではないか、という見方です。
この制度の対象外である事業者にとって参考になるのは、要求の形です。技術要件のように一度で終わる条件と、運用要件のように終わらない条件が、同じ条件表の中で別の性質のまま並んでいます。自社で「鮮度を上げる」と言うとき、どちらの話をしているのかを先に分けておくと、計画の立て方が変わります。
最小の検証はこれです。直近で更新した記事を5本選び、更新の内容が確定した時刻と、その更新が公開URL上で読める状態になった時刻を記録してみる。差が日単位なら、鮮度は申告の問題ではなく運用の問題として現れています。差が測れないなら、そもそも鮮度を主張する根拠を持っていないことになります。
鮮度の申告をどう扱うかについては、サイトマップやメタデータ側の設計と関わります。検索結果の前提が地域ごとに違う話は検索結果は世界で一つではなくなったで扱っています。
条件表は、要求の性質を読むために使える
UGC Fresh Data Programは、ほとんどの事業者にとって申し込む対象ではありません。それでもこの条件表が読む価値を持つのは、鮮度という曖昧な言葉が、送信までの分数、カウンタ更新の72時間、そしてモデレーションの維持という形に翻訳されているからです。
翻訳の結果を見ると、鮮度の大半は申告ではなく体制の話でした。自社の鮮度をどう語るかを決める前に、語ろうとしているのが一度で終わる条件なのか、終わらない条件なのかを分けておく。それだけで、更新日を書き換える作業に鮮度対策という名前を付けてしまう事故は避けられます。