SoftwareApplicationの構造化データ：価格と評価が表示を決める

SoftwareApplicationの構造化データは、name、offers.price、そしてaggregateRatingかreviewのいずれか、この3つが揃って初めてGoogleのソフトウェアアプリのリッチリザルト対象になります。名前とカテゴリだけを書いて残り2つを省いても、構文チェックは通ります。有効は対象外という意味ではありません。2026-10-25に読んだGoogleのソフトウェアアプリのドキュメントは、価格や評価の欠落を警告ではなく「必須条件が満たされていない」状態として扱っています。

SoftwareApplicationの構造化データが求めるもの

実際に効くのは3つのプロパティです。うち2つはschema.orgでは任意で、Googleでは必須です。この差が、あと1項目で止まるページを量産しています。

止まりやすいのは評価の項目です。aggregateRatingにはratingValueとratingCountが必要で、単体のreviewには投稿者と評価点が必要です。Googleのレビュー スニペットに関するガイドラインは明確で、他のサイトのレビューや評価をまとめてはいけません。偽のレビューや、報酬を明示していないインセンティブ付きレビューも入れられません。評価は自社製品に対する、実際に使った人のものである必要があります。

applicationCategoryはGoogleが対応を示している一覧から値を選びます。BusinessApplication、DeveloperApplication、DesignApplicationは一覧にあります。WebApplicationは型であってカテゴリではありません。読み心地のよいラベルを考えるより、ドキュメントの値をそのまま使います。

ソフトウェアアプリの結果は、名前・価格・評価の3点セットです。1つ欠ければ、Googleに見せるものがありません。

どの型を使うか：WebApplication、SoftwareApplication、Product

ブラウザで動く製品は通常WebApplication、インストールして使うデスクトップやモバイルのアプリはSoftwareApplication、カタログから売る商品はProductです。Googleは3つとも対応していますが、同じページに2つの型を置き、違う価格を書くのが誤りです。

選ぶ前に知っておきたい文書化された例外があります。VideoGameだけを持つソフトウェアアプリには、Googleはリッチリザルトを表示しないと明記しています。MobileApplicationなど2つ目の型を重ねる必要があります。狭いケースですが、正しく見えるマークアップが何も起こさない典型です。

すでに価格と在庫のあるプランを売っているページなら、先にプロダクトのランディングページの書き方を読み、そのページで価格を持つ型を1つに決めてください。2つの型に違う数字を書いてはいけません。

成果物1：そのまま貼れるJSON-LD

無料プランがあるブラウザ製品で、対象になり得る最小のブロックです。4つの値を置き換え、構造は変えません。

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Example",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "ratingCount": "128"
  }
}

無料プランが典型的な落とし穴です。offers.priceは答えが0でも必須なので、offerごと消さずに"price": "0"と書きます。有料プランがあるなら実際の開始価格を入れ、priceCurrencyは残します。ダウンロードするアプリなら@typeをSoftwareApplicationに変え、動くプラットフォームを書きます。

値はチャネル別の製品紹介と同じ原本から取ります。ページごとに価格や名前がずれるのを防ぐためです。

aggregateRatingは、その評価がページ上に表示されている場合だけ入れます。Googleの構造化データ一般ガイドラインは、マークアップが表示内容を説明していることを求めています。scriptタグの中にしか存在しない評価は誤表示です。レビューのガイドラインはさらに、集計した評価は実際のレビューから作るべきで、他サイトから持ってきてはいけないとしています。

成果物2：公開前の8行チェック

上から順に確認します。最初の4行は機能しようがないブロックを止め、後の4行は動くけれど別のページを説明しているブロックを止めます。

ブロックはタイトルや説明と同じくページテンプレートに置きます。本文を編集しても位置がずれないようにするためです。値はページが表示に使う場所から取り、手書きの評価は最初に古くなります。

1. ページのURLをリッチリザルトテストに貼り、「Software app」が検出されるか確認します。
2. 警告より先にエラーを読みます。必須プロパティの欠落はエラー、推奨の欠落はエラーではありません。
3. 同じURLをURL検査で開き、レンダリング後のHTMLにブロックがあるか見ます。
4. 数日間、Search Consoleの構造化データレポートを確認します。出るのはGoogleが見つけた事実で、意図ではありません。

有効なマークアップでも表示されない理由

失敗はたいてい4つの形で、どれも構文エラーではありません。ブロックは解析され、ページはインデックスされ、結果は出ません。

4行目が最も静かです。チームが普段編集しているリリース告知にマークアップを置き、アプリを実際に説明している製品ページには何も置かない、という形がよくあります。Googleはブロックがあるページを評価します。製品ページに結果を出したいなら、ブロックもそこに必要です。

もう一段手前の失敗もあります。JSON自体が壊れていて、カンマが多い、引用符が足りない。この場合はテストが解析エラーを出し、Search Consoleは「解析できない構造化データ」として別に扱います。勘で直す必要はありません。

分かっていないこと、やめるべき時

ページが対象になったとき、Googleがどれくらいの頻度でソフトウェアアプリの結果を出すのかは分かっていません。Googleは表示率を公開しておらず、構造化データを使う機能の表示も保証していません。自社ページでの測定期間も短く、数字を出すには足りません。対象かどうかは制御できますが、表示は制御できません。

正直に待つのが正解の場面もあります。実際の評価がまだないなら、数字を作ったり、レビューサイトから持ってきたりしないでください。名前、カテゴリ、価格を公開し、実際の利用者が評価を残してから追加します。評価がないことで失うのはリッチリザルトです。作り話の評価で失うのは、マークアップと、そのページを作った理由そのものです。

テストがエラーなしでアプリを認識し、表示内容とブロックが一致したら終わりです。その先は結果が出たかどうかの測定で、検索とAIの分析の仕事であり、ソースコードの仕事ではありません。

よくある質問

SoftwareApplicationの構造化データとは何ですか

ページ上のソフトウェア製品を説明するschema.orgのマークアップです。名前、カテゴリ、対応環境、価格、評価を記述します。Googleはこれを見て、名前・価格・星付きのアプリ結果を表示できるか判断します。

Googleは今もこのマークアップに対応していますか

対応しています。2026-10-25に読んだ時点でGoogleのソフトウェアアプリのドキュメントは公開されており、最終更新は2026-09-08でした。アプリ結果も対応機能の一覧に残っています。FAQやHowToのように廃止されたものではありません。

アプリのマークアップで星は表示されますか

評価かレビューがある場合だけです。名前と価格だけで評価がなければ、必須プロパティを満たしません。評価を捏造すれば、話は表示ではなくポリシー違反になります。

SoftwareApplicationとProductは両方書くべきですか

いいえ。ページが売っているものに合う型を1つ選び、価格はその型に持たせます。同じページに2つの型と違う価格を書くと、Googleには矛盾する事実が2つ渡り、どちらを読んだのか分からなくなります。

リッチリザルトテストで何も見つからないのはなぜですか

多くは、テストが最初に見るHTMLの後にJavaScriptでJSON-LDを追加しているか、テストしたURLがブロックのあるページではないかのどちらかです。サーバー側で出力し、順位を狙う実際のURLでテストしてください。トップページでは意味がありません。