WeatherForecastスキーマ完全ガイド：構造化データ初心者から専門家まで
本レポートは、ウェブサイトに天気予報コンテンツを掲載する開発者、SEO専門家、ウェブサイト運営者を対象に、schema.orgのWeatherForecastスキーマに関する包括的な解説を提供します。構造化データの基本概念から始まり、WeatherForecastスキーマの全プロパティ、その提案段階にあるというステータス、そしてGoogle検索における現実的な影響まで、専門的な知見を交えて詳細に解説します。
I. データの意味を伝える：構造化データ入門
ウェブコンテンツが抱える根本的な課題
ウェブページ上の情報は、人間にとっては直感的に理解できるものであっても、検索エンジンをはじめとするコンピュータープログラムにとっては単なるテキストの羅列に過ぎません。例えば、ページに「東京 25°C」と書かれていた場合、人間はこれを「東京の現在の気温は摂氏25度である」と即座に解釈します。しかし、検索エンジンは、これが現在の気温なのか、昨日の最高気温なのか、あるいは小説の一節なのかを文脈から推測するしかありません 。この曖昧さが、検索エンジンがコンテンツの真の意味を理解する上での大きな障壁となります。
構造化データ：機械のための「翻訳者」
この問題を解決するのが「構造化データ」です。構造化データとは、ウェブページの内容を検索エンジンやAIに分かりやすく伝えるための、標準化された特別な記述方法です 。これは、ウェブページのHTMLコードに「ラベル」を付けるようなもので、「このテキストは都市名です」「この数字は気温です」「この単位は摂氏です」といったように、各情報が何であるかを明示的に伝えます 。
この仕組みは、AIにとっての「翻訳者」に例えることができます 。人間が読むためのウェブコンテンツを、機械が理解できる言語に「通訳」してくれるのです。整理されたタンスから目的のシャツをすぐに見つけ出せるように、構造化データによって整理された情報は、検索エンジンによって迅速かつ正確に解釈されます 。
Schema.org：世界共通の「辞書」
この「機械が理解できる言語」が世界中でバラバラでは意味がありません。そこで、Google、Microsoft、Yahoo!といった主要な検索エンジンが共同で立ち上げたのがschema.orgです 。schema.orgは、構造化データで用いる語彙（ボキャブラリ）の国際的な標準規格であり、いわば世界共通の「辞書」の役割を果たします 。この共通の辞書に従ってウェブページの情報を記述することで、どの検索エンジンも同じように内容を理解できるようになります。
構造化データの核心的利点：曖昧さから明確性へ
構造化データを導入する最大の利点は、検索エンジンがウェブページの内容を推測するのではなく、正確に理解できるようになる点にあります 。これにより、検索エンジンはページの主題や情報の種類をより深く把握し、結果としてユーザーの検索意図に対してより関連性の高いページを提供できるようになります 。これは、ウェブサイトがそのコンテンツの価値を最大限に検索エンジンに伝えるための、極めて効果的な手段です。
このプロセスは、ウェブサイト運営者が検索エンジンとのコミュニケーションにおいて、受動的な立場から能動的な立場へと移行することを意味します。構造化データがなければ、運営者は検索エンジンが自サイトのコンテンツを正しく解釈してくれることを祈るしかありません。しかし、構造化データを実装することで、運営者は自ら「このデータはこういう意味です」と積極的に伝えることができ、誤解のリスクを大幅に低減させることが可能になります。これは、単なるSEOテクニックを超えた、より本質的な情報伝達の最適化と言えます。
期待される効果：リッチリザルト
構造化データを正しく実装することによる具体的なメリットの一つに、「リッチリザルト」（リッチスニペットとも呼ばれる）があります 。これは、検索結果ページにおいて、通常の青いリンクと短い説明文に加えて、価格、レビュー評価（星の数）、FAQのドロップダウンリストといった付加情報が表示される機能です 。
これらの付加情報は検索結果上で視覚的に目立つため、ユーザーの注意を引きやすく、クリック率（CTR）の向上が期待できます 。ただし、構造化データを記述すれば必ずリッチリザルトが表示されるわけではない、という点は重要です 。リッチリザルトの表示は、あくまでGoogleのアルゴリズムによって決定されるものであり、構造化データはそのための「資格」を得る手段と考えるべきです。
II. Schema.orgの構造：タイプとプロパティの理解
schema.orgの語彙体系は、現実世界のあらゆる「モノ」や「コト」を記述できるように、階層的な構造を持っています。この構造を理解することが、WeatherForecastスキーマを正しく扱うための鍵となります。
すべての基本：「Thing」
schema.orgの世界における最も基本的で包括的な概念がThing（モノ、コト）です 。ウェブ上で表現されうる、ありとあらゆるものがThingから派生します。Thingは、すべてのタイプが共通して受け継ぐ基本的なプロパティ（属性）を持っています。
name：そのモノの名前description：そのモノの説明url：そのモノに関する詳細情報が記載されたページのURLimage：そのモノを表す画像
これらのプロパティは、後述するWeatherForecastを含む、ほぼすべてのschema.orgのタイプで使用可能です。
階層構造：汎用的なものから具体的なものへ
schema.orgは、生物の分類学のように、情報を階層的に整理します 。頂点にThingがあり、その下に具体的な概念が連なります。
例えば、Thingの下にはCreativeWork（創造物）やEvent（イベント）、Intangible（無形物）といった、より具体的なタイプが存在します。さらにCreativeWorkの下にはArticle（記事）、Book（本）、Movie（映画）といった、さらに専門化されたタイプが定義されています。この「継承」という仕組みにより、下位のタイプは上位のタイプのプロパティをすべて受け継ぎ、それに加えて独自のプロパティを持つことができます。
タイプとプロパティ：スキーマを構成する二大要素
schema.orgの語彙は、基本的に「タイプ」と「プロパティ」という2つの要素で構成されます 。
- タイプ (Type)：記述する対象の「種類」や「カテゴリ」を定義します。いわば「名詞」に相当し、
Product（商品）、Recipe（レシピ）、LocalBusiness（地域ビジネス）などがあります 。 - プロパティ (Property)：特定のタイプが持つ「属性」や「特徴」を定義します。いわば「形容詞」や詳細情報に相当し、例えば
Productタイプはname（商品名）、brand（ブランド）、aggregateRating（総合評価）といったプロパティを持ちます 。
WeatherForecastスキーマの系譜
本レポートの主題であるWeatherForecastは、公式文書ではありませんが、その提案文書においてCreativeWorkのサブクラス（下位のタイプ）として定義されています 。これは非常に重要な分類です。この分類は、天気予報を単なるデータセット（Intangible）や自然現象（Event）としてではなく、特定の機関や個人によって作成・発表された「創造物」として位置づけていることを意味します。
この設計思想には深い意図が隠されています。CreativeWorkのサブクラスであることにより、WeatherForecastはauthor（著者）、publisher（発行者）、copyrightHolder（著作権者）、datePublished（発行日）といった、創造物特有のプロパティを継承することができます 。これにより、気象庁や民間の気象情報会社、ニュースメディアなどが、自ら作成した天気予報データの出所や著作権を構造化データ内で明確に主張できるのです。これは、もしWeatherForecastが単なるIntangible（無形物）として定義されていた場合には、自然な形で表現することが難しい情報です。この分類は、天気予報という情報が持つ「作成されたコンテンツ」としての側面を的確にモデル化していると言えます。
また、WeatherForecastが公式なスキーマではなく「提案」段階にあるという事実は、schema.orgが固定的なものではなく、コミュニティの要求に応じて進化し続ける「生きた語彙体系」であることを示しています 。schema.orgにはpending（保留中）セクションが存在し、新しい用語が議論・レビューされる場が設けられています 。WeatherForecastの提案は、ウェブ上で天気予報情報をより良く表現したいというコミュニティのニーズから生まれたものであり、このような提案の存在自体が、schema.orgのエコシステムのダイナミズムを物語っています。
III. WeatherForecastスキーマ：提案されている標準の詳細
このセクションでは、WeatherForecastスキーマの全プロパティを詳細に解説します。ただし、その前に極めて重要な注意点があります。
最重要事項：WeatherForecastスキーマの「提案」ステータス
本レポートで解説するWeatherForecastスキーマは、schema.orgの公式な語彙の一部ではありません 。これは、過去に提出された「提案文書」に基づくものであり、pendingセクションにも含まれていない、コミュニティによる初期の試みの一つと見なされます 。
この事実は、実装にあたって以下の点を理解しておく必要があることを意味します。
- Googleを含む主要な検索エンジンが、このスキーマを公式に認識し、特別な処理（リッチリザルトの生成など）を行う保証はありません。
- 将来的に、公式な天気予報スキーマが全く異なる構造で導入される可能性があります。
- しかし、後述するように、公式サポートがなくとも、検索エンジンがページの文脈を理解するのを助けるという点で、このスキーマを実装することには依然として価値があります。
2層構造モデル：WeatherForecastとWeatherForecastElement
提案されているWeatherForecastスキーマは、情報を効率的に整理するため、2つの主要なタイプから構成されています 。
WeatherForecast: 予報全体を格納するコンテナの役割を果たします。例えば、「東京の5日間天気予報」といった、予報の全体像を定義します。WeatherForecastElement:WeatherForecastの中にネストされる形で使用され、予報内の特定の時間単位（例：「金曜日の予報」「午後3時の予報」）の詳細なデータを保持します。
この構造により、一つの予報の中に日ごと、あるいは時間ごとの詳細な予報を複数含めることが可能になります。
プロパティ詳細リファレンス
以下に、WeatherForecastとWeatherForecastElementが持つプロパティを、それぞれ表形式で網羅的に解説します。
WeatherForecastのプロパティ
このタイプは、天気予報全体のメタデータを定義します。
| プロパティ名 | 想定される型 | 説明 | 具体例 |
|---|---|---|---|
weatherForecastPlace |
Place |
この天気予報が対象とする場所。Placeタイプを使用して、地名だけでなく、地理座標なども指定可能。 |
"weatherForecastPlace": {"@type": "Place", "name": "Boston"} |
weatherForecastDaysType |
Number |
予報がカバーする日数（例：5日間予報、10日間予報）。 | "weatherForecastDaysType": 5 |
weatherForecastStartDateTime |
DateTime |
予報期間の開始日時。ISO 8601形式で記述。 | "weatherForecastStartDateTime": "2025-10-26T00:00:00-05:00" |
weatherForecastEndDateTime |
DateTime |
予報期間の終了日時。ISO 8601形式で記述。 | "weatherForecastEndDateTime": "2025-10-30T23:59:59-05:00" |
hourWeatherForecast |
WeatherForecastElement |
特定の1時間の天気予報。このプロパティを複数回繰り返すことで、時間ごとの予報を表現する。 | "hourWeatherForecast": |
dayWeatherForecast |
WeatherForecastElement |
特定の1日の天気予報。このプロパティを複数回繰り返すことで、日ごとの予報を表現する。 | "dayWeatherForecast": |
継承されるプロパティ:
前述の通り、WeatherForecastはCreativeWorkのサブクラスであるため、name、description、author、publisher、datePublishedといったCreativeWorkおよびThingのプロパティもすべて利用可能です。
WeatherForecastElementのプロパティ
このタイプは、特定の時間断面における具体的な気象データを定義します。
| プロパティ名 | 想定される型 | 説明 | 具体例 |
|---|---|---|---|
weatherForecastElementPlace | Place | この予報要素が対象とする場所（通常は親のWeatherForecastと同じ）。 | "weatherForecastElementPlace": {"@type": "Place", "name": "Boston"} |
weatherForecastElementStartDateTime | DateTime | この予報要素の開始日時。 | "weatherForecastElementStartDateTime": "2025-10-26T00:00:00-05:00" |
weatherForecastElementEndDateTime | DateTime | この予報要素の終了日時。 | "weatherForecastElementEndDateTime": "2025-10-26T23:59:59-05:00" |
weatherForecastElementCondition | WeatherCondition | 予報される天気の状態。SunnyWeather、CloudyWeatherなどの列挙型メンバーを使用する。 | "weatherForecastElementCondition": "(http://schema.org/SunnyWeather)" |
weatherForecastElementConditionAlert | WeatherAlert | 予報される気象警報。TornadoWarningAlertなどの列挙型メンバーを使用する。 | "weatherForecastElementConditionAlert": "(http://schema.org/SevereThunderstormWarningAlert)" |
weatherForecastElementPrecipitationChance | QuantitativeValue | 降水確率。パーセンテージで示す。 | "weatherForecastElementPrecipitationChance": {"@type": "QuantitativeValue", "value": 80, "unitCode": "P1"} |
weatherForecastElementTemperature | QuantitativeValue | 気温。摂氏または華氏で示す。 | "weatherForecastElementTemperature": {"@type": "QuantitativeValue", "value": 25, "unitCode": "CEL"} |
weatherForecastElementVisibility | QuantitativeValue | 視程。距離の単位で示す。 | "weatherForecastElementVisibility": {"@type": "QuantitativeValue", "value": 10, "unitCode": "KMT"} |
weatherForecastElementWindSpeed | QuantitativeValue | 風速。MPHやKPHなどの単位で示す。 | "weatherForecastElementWindSpeed": {"@type": "QuantitativeValue", "value": 15, "unitCode": "KMH"} |
weatherForecastElementAirPressure | QuantitativeValue | 気圧。インチやヘクトパスカルで示す。 | "weatherForecastElementAirPressure": {"@type": "QuantitativeValue", "value": 1012, "unitCode": "A98"} |
weatherForecastElementFeelsLikeTemperature | QuantitativeValue | 体感温度。 | "weatherForecastElementFeelsLikeTemperature": {"@type": "QuantitativeValue", "value": 28, "unitCode": "CEL"} |
weatherForecastElementHumidity | QuantitativeValue | 湿度。パーセンテージで示す。 | "weatherForecastElementHumidity": {"@type": "QuantitativeValue", "value": 65, "unitCode": "P1"} |
weatherForecastElementPolution | QuantitativeValue | 大気汚染指数。 | "weatherForecastElementPolution": {"@type": "QuantitativeValue", "value": 55} |
weatherForecastElementPollenCount | QuantitativeValue | 花粉数。 | "weatherForecastElementPollenCount": {"@type": "QuantitativeValue", "value": 300} |
weatherForecastElementUV | QuantitativeValue | UV指数。 | "weatherForecastElementUV": {"@type": "QuantitativeValue", "value": 7} |
weatherForecastElementWindDirection | Text | 風向。WNW（西北西）、SSW（南南西）などテキストで示す。 | "weatherForecastElementWindDirection": "WNW" |
データモデルの設計思想
このプロパティリストを分析すると、いくつかの重要な設計思想が見えてきます。
第一に、QuantitativeValueの多用による拡張性と明確性の確保です。気温、風速、湿度といった多くの数値データで、単なるNumberではなくQuantitativeValueタイプが指定されています 。これは、単に数値を記述するだけでなく、その数値の「単位」を明確に指定できる非常に強力な仕組みです。例えば、temperatureに25という値を入れるだけでは、それが摂氏なのか華氏なのか不明確です。しかしQuantitativeValueを使えば、valueプロパティに25を、unitCodeプロパティにCEL（摂氏）を指定することで、データの曖昧さを完全に排除できます。これにより、データは国際的に通用し、機械による自動的な単位変換なども可能になります。これは、初心者が見落としがちな、高品質な構造化データを作成するための重要なベストプラクティスです。
第二に、列挙型（Enumeration）の採用による語彙の統制です。天気の状態を示すweatherForecastElementConditionプロパティでは、自由なテキストではなくWeatherConditionという列挙型が指定されています 。この列挙型には、SunnyWeather（晴れ）、CloudyWeather（曇り）、RainyWeather（雨）といった、あらかじめ定義されたメンバーが含まれます。これにより、「晴れ」「快晴」「晴天」といった表記の揺れを防ぎ、すべてのウェブサイトが共通の語彙で天気の状態を表現できます。これは、機械がデータを集計・分析する際の信頼性を劇的に向上させます。同様に、WeatherAlertは気象警報のための統制された語彙を提供します。
IV. 実践的な実装と現実世界への影響
理論を学んだ後は、それをどのようにコードに落とし込み、どのような結果を期待できるのかを理解することが重要です。
推奨される実装方法：JSON-LD
構造化データをHTMLに埋め込む方法には、主にJSON-LD、マイクロデータ、RDFaの3種類がありますが、現在最も推奨されているのはJSON-LD (JavaScript Object Notation for Linked Data)です 。
JSON-LDを推奨する理由は以下の通りです。
- Googleが推奨: Googleは公式にJSON-LDを推奨しており、サポートが最も手厚い形式です 。
- コンテンツとデータの分離: JSON-LDは、通常、HTMLの
<head>タグ内に<script>タグとして配置されます。これにより、人間が見るためのHTMLコンテンツの構造と、機械が読むための構造化データを明確に分離できます。この分離は、ウェブサイトのデザイン変更が構造化データに影響を与えるリスクを低減し、メンテナンス性を大幅に向上させます 。 - 管理の容易さ: ページの情報を一箇所にまとめて記述できるため、データの追加や修正が容易です。
JSON-LDによる実装コード例
以下に、東京の3日間の天気予報をWeatherForecastスキーマを用いてJSON-LDで記述した具体的なコード例を示します。各行には、その意味を理解するためのコメントを付記しています。
{
"@context": "https://schema.org/",
"@type": "WeatherForecast",
// 予報全体の名前
"name": "東京の3日間天気予報",
// この予報を発行した組織
"publisher": {
"@type": "Organization",
"name": "サンプル気象情報"
},
// 予報の発行日
"datePublished": "2025-10-25",
// 予報の対象地域
"weatherForecastPlace": {
"@type": "Place",
"name": "東京"
},
// 予報の日数
"weatherForecastDaysType": 3,
// 予報期間の開始日時
"weatherForecastStartDateTime": "2025-10-26T00:00:00+09:00",
// 予報期間の終了日時
"weatherForecastEndDateTime": "2025-10-28T23:59:59+09:00",
// 日ごとの予報データを配列で格納
"dayWeatherForecast":
}
Google検索とリッチリザルトに関する現実
ここで、期待値を適切に設定するために、非常に重要な点を明確にする必要があります。本レポート執筆時点で、Googleは公式の検索ギャラリーにおいて「天気予報」に関するリッチリザルトをサポートしていません 。
これは、上記のWeatherForecastスキーマを実装しても、Googleの検索結果に天気予報が特別なデザインで表示されることはない、ということを意味します。構造化データ初心者が陥りがちな誤解は、「構造化データを実装すれば、必ずリッチリザルトが表示される」というものですが、現実は異なります。リッチリザルトは、Googleがサポートを明言している特定のスキーマタイプ（FAQPage、Recipe、Productなど）に対してのみ、表示される可能性があります 。
では、サポートされていないスキーマを実装することは無意味なのでしょうか。答えは明確に「いいえ」です。Googleのウェブマスター・トレンド・アナリストであるジョン・ミューラー氏は、「たとえ構造化データがリッチリザルトに繋がらなくても、我々のシステムは構造化データが使われているページをより良く理解することで利益を得る」と述べています 。
この発言の背後には、検索エンジンの進化があります。現代の検索エンジンは、単にキーワードが一致するかどうかを見るだけでなく、ページに書かれている「エンティティ（実在するモノやコト）」とその関係性を理解しようとしています。WeatherForecastスキーマを実装することは、Googleに対して「このページには、東京という場所に関する、特定の期間の天気予報という情報が含まれています」と、機械が解釈可能な形で明確に伝える行為です。これにより、Googleはページの主題をより深く、正確に理解することができます。
この「セマンティック（意味論的）な理解の向上」こそが、リッチリザルトのサポートがないスキーマを実装する真の価値です。この深い理解は、より複雑な、あるいは会話的な検索クエリ（例：「今週末、東京は傘が必要？」）に対して、あなたのページが関連性の高い回答を持っていると判断される可能性を高めます。これは、将来の検索技術、特に音声検索やAIによる要約生成などを見据えた、先進的なSEO施策（セマンティックSEO）と言えるでしょう。
実装の検証：必須のプロセス
構造化データの実装後は、必ずその記述が正しいかどうかを検証する必要があります。Googleは、そのための公式ツールとして「リッチリザルト テスト」を提供しています 。
このツールにページのURLまたはコードスニペットを入力すると、構造化データが構文的に正しいか、また、Googleが認識できるタイプやプロパティが使用されているかをチェックできます。WeatherForecastはリッチリザルトの対象ではないため、「このページはリッチリザルトの対象です」というメッセージは表示されませんが、構文エラー（カンマの抜け、括弧の閉じ忘れなど）があれば検出してくれます。エラーのないクリーンなコードを実装することは、検索エンジンに正しく情報を伝えるための最低条件です。
また、Google Search Consoleでは、サイト全体で検出された構造化データアイテムの有効・無効の状況を追跡するレポートが提供されます 。定期的にこのレポートを確認し、意図しないエラーが発生していないかを監視することも、プロフェッショナルなウェブサイト運営には不可欠です。
V. 広範な文脈と将来展望
WeatherForecastスキーマを理解する上で、schema.orgという枠組みだけでなく、より広いデータモデリングの世界に目を向けることは、その戦略的価値を深く認識する助けとなります。
提案スキーマの先にあるもの：代替データモデルの存在
ウェブ検索の文脈を超えると、天気予報データはIoT、スマートシティ、農業、物流など、多岐にわたる分野で活用されています。これらの分野では、より専門的で詳細なデータモデルが求められることがあります。
その一例が、スマートシティ向けのデータモデル標準化を推進するFIWARE Foundationが提供するWeatherForecastデータモデルです 。このモデルは、schema.orgの提案よりもはるかに詳細なプロパティを持っています。例えば、dataProvider（データ提供者情報）、dateIssued（予報発表日時）、dateRetrieved（データ取得日時）といったメタデータや、dayMinimum、dayMaximumといった構造化された値を用いて、期間中の最低・最高の気温や湿度を詳細に記述することができます 。
点と点をつなぐ：Schema.orgの基盤的役割
興味深いのは、FIWAREのような専門的なデータモデルでさえ、その仕様の中でschema.orgを参照している点です 。例えば、場所を記述する際にはschema.orgのaddressプロパティを参照するよう規定されています 。
これは、schema.orgが単にGoogle検索のためだけのものではなく、ウェブ上のエンティティを記述するための「共通言語（リンガ・フランカ）」としての地位を確立しつつあることを示しています。異なる目的で構築された様々なシステムが、場所、組織、人物といった基本的な概念についてschema.orgを共通の基盤として参照することで、データの相互運用性が飛躍的に向上します。ウェブサイト運営者がschema.orgに準拠した構造化データを実装するということは、自社のデータをGoogleだけでなく、将来登場するかもしれない様々なデータ活用アプリケーションと連携可能にする、オープンなエコシステムに参加することを意味するのです。
結論：なぜ提案段階のスキーマを実装する価値があるのか
本レポートを通じて、schema.orgのWeatherForecastスキーマが公式なものではなく提案段階にあること、そして直接的なリッチリザルトには繋がらないことを明らかにしてきました。それでもなお、このスキーマを実装することには大きな戦略的価値があります。
その価値を要約すると以下のようになります。
- セマンティックな優位性の確立: 検索エンジンに対してコンテンツの意味を明確に伝えることで、ページの主題に関する権威性を高め、より関連性の高いトラフィックを呼び込む土台を築きます。
- 将来への投資: 現在の検索エンジンだけでなく、AIアシスタント、スマートデバイス、サードパーティのアプリケーションなど、機械が情報を消費する未来に適応するための準備となります。ウェブコンテンツを、単なる「ページ」から再利用可能な「データ」へと昇華させる第一歩です。
- データ相互運用性の確保: ウェブの共通言語であるschema.orgに準拠することで、自社のデータをよりオープンでポータブルなものにし、未知のビジネスチャンスに備えることができます。
WeatherForecastスキーマの実装は、短期的な視覚的効果を求めるものではありません。それは、自社のウェブサイトが持つ情報の価値を最大化し、機械が情報を理解することが当たり前になる未来のウェブにおいて、持続的な競争力を確保するための、長期的かつ戦略的な投資なのです。
