統計バンド：ソースと期間を備えた主要な数字

統計バンドとは、2〜4つの見出し数値をコンパクトに並べたもので、各数値にはラベル、ソース、報告期間が付随します。その役割は、ページ全体を象徴する少数の数字を提示することであり、データセット全体を装飾的なタイルに圧縮することではありません。

上記の値はサポートチームの例示であり、AmICitedや実際の企業に関する主張ではありません。ソースと期間は表示されたままです。なぜなら、例は、読者に後から証拠を追加することを教えるのではなく、本番の契約を示すべきだからです。

この要素が重要な理由

読者は、周囲の段落を読む前に大きな数字に気づきます。優れた統計バンドは、その注意を利用して、規模、変化、または結果を数秒で伝えます。3つの強力な数値は、シンプルなメンタルモデル（応答速度、サービス信頼性、顧客反応）を作り出します。8つの弱い数値はスキャンの問題を引き起こします。それらは同じ視覚的重みで競合し、読者にどれが重要かを判断させ、強調をノイズに変えてしまいます。

バンドが機能するのは、選択の労力を減らすからであり、大きなタイポグラフィが主張をより説得力のあるものにするからではありません。各数字は、異なる重要な質問に答える必要があります。2つのタイルが本質的に同じことを言っている場合（例：「94%がSLA内で解決」と「6%がSLAを超過」）、そのうちの1つは限られたスペースを無駄にしています。数値が印象的であってもページの結論に無関係であれば、その prominence は助けにはならず、誤解を招きます。

機械抽出可能性とは、クローラー、検索システム、またはAI回答エンジンが、値とそれが測定するものとの関係を保持する能力です。「94%」だけでは使用できません。「サポートチケットの94%がSLA内で解決、サポートエクスポート、2026年1月～6月」は、値、指標、ソース、期間が結びついた、範囲が定まった主張です。統計バンドは、これらの関係を文書の順序でテキストとして公開し、画像に埋め込んだり、JavaScriptの実行後にのみ組み立てたりしてはいけません。

これが、型付き要素が視覚的に類似したフリーテキストよりも優先される理由でもあります。要素作成ルール に従い、少数の見出し数値を提示することを目的とした箇所は、統計バンド構造を使用しなければなりません。3つの太字の段落は視覚的に似ているかもしれませんが、安定した項目境界、フィールド、ソースと期間の検証フックを提供しません。

使用すべきタイミング

2〜4つの数値がページの中心的証拠を要約し、方法論セクションを読まずに理解できる場合に統計バンドを使用します。適切な数値には、測定結果、ベースラインから現在までの変化、市場規模、コホート数、中央値、比率、期間、または特定時点の運営実績が含まれます。バンドは、数値が1つの結論を繰り返すのではなく、補完的な質問に答える場合に特に有用です。

証拠は、バンドが設計される前に存在していなければなりません。優れた選択テストは次のとおりです。読者がこれらの数値だけをコピーした場合、それぞれが正確で、適切に限定され、ページを代表するものであり続けるでしょうか？そうでない場合は、その数値を散文または詳細なデータ表示に留め、注釈が一緒に付随できるようにします。

類似事例はよくあります：

• 製品メリットの羅列：「より速い」「よりシンプル」「よりスマート」 — これらは統計ではなく主張です。証拠に裏付けられたメリットコピーを使用してください。
• KPIダッシュボード： ライブ運用監視には、タイムスタンプ、トレンド、フィルター、ステータスロジックが必要です。静的な編集バンドで代用することはできません。
• 統計サマリー： 平均、中央値、範囲、サンプルサイズ、信頼区間は、それらの関係が重要であるため、通常はテーブルやチャートに含めるべきです。
• 8つの数値のリスト： 読者は主要な発見と補助データを区別できません。結論を導く3つを選択し、残りは分析セクションに移動してください。
• 未検証のマーケティングクレーム： 視覚的な prominence は曖昧さのコストを増大させます。ソース、分母、期間が判明するまで、その主張を削除してください。
• 単一の数値： 1つの数値は通常、文、コールアウト、またはチャート注釈に属します。少なくとも2つの値が意味のあるセットを形成する場合のみバンドを使用してください。

配置する場所

配置は主張の一部です。リサーチページやベンチマークページでは、導入部が主題、母集団、期間を定義した後、詳細な調査結果の前にバンドを配置します。ケーススタディでは、状況と介入が明確になった後に配置します。そうしないと、読者が結果を誤った出発点や行動に帰属させる可能性があります。会社プロフィールでは、アイデンティティと事業範囲が確立された後に配置します。

すべての項目が独立して理解可能であり、ページがすぐ下に方法論またはコンテキストを提供する場合にのみ、バンドは上部近くに表示されることがあります。直接的な回答、リサーチサマリー、または変更内容の説明を置き換えてはなりません。それは証拠のプレビューであり、議論全体ではありません。

統計バンドを、別の統計バンド、同じ数値を示すチャート、価格表、推薦文カルーセル、または強調度の高いコールトゥアクションのすぐ隣に配置しないでください。同じくらい目立つモジュールが2つあると注意が競合し、数値が重複すると読者はどちらのバージョンが最新なのか疑問に思います。バンドと別の高密度データ表示の間には、少なくとも1つの説明段落を挟んでください。バンドを共有の方法論やソースノートから、広告、サインアップフォーム、無関係な画像で切り離さないでください。

構造

ラベル付きキャプチャは、7つの機能領域を識別しなければなりません：

1. 値： 観測された数値。変化の方向が重要な場合は符号を含みます。
2. 単位： パーセント、通貨、期間、カウント、スコア、比率、またはその他の明示的な尺度。
3. 指標ラベル： 測定されたもの。曖昧さの可能性がある場合は分母を含みます。
4. ソース： その項目の背後にあるデータセット、システム、調査、ファイリング、または名前付き出版物。
5. 報告期間： 基礎となる活動が発生した時期、またはスナップショットの正確な「現在」の日付。
6. グループコンテキスト： バンド全体に対して、コホート、地理、計画、またはシナリオを一度定義するオプションの見出しまたは文。
7. 項目境界： 各値を独自のラベルと証拠に結び付けるセマンティックコンテナ。

値は視覚的に先頭に立つべきですが、ソースと期間をホバー、ツールチップ、またはアイコンの背後に隠すことはできません。控えめなタイポグラフィを使用してもかまいませんが、不在にしてはいけません。

デザイン例

デザインシステムは4つのコンテンツバリエーションをサポートしています。それぞれが同じセマンティックフィールドと証拠ルールを維持し、アイテム数と値の形状のみが変更されます。

標準3項目バンド： デフォルト。ページの主要な結果をまとめて確立する、3つの異なる数値を使用します。単一の数値が明示的な主要結果でない場合、均等な視覚的重みが適切です。

2項目ペア： ベースラインと現在、または組織とベンチマークなど、意味のある比較に使用します。ラベルは関係性を明示しなければなりません。物理的な近接だけでは、各タイルがどの期間またはコホートを表すかを暗示してはなりません。

4項目最大： 4つの数値すべてが異なる意思決定関連の質問に答える場合のみ使用します。レイアウトが密集するため、ラベルを短くする必要があります。5つ目の項目は、テーブル、チャート、または調査結果セクションに移動します。

混合単位レスポンシブバンド： ラベルが明示的であれば、パーセンテージ、期間、カウント、スコアが共存してもかまいません。狭い画面では、タイルは文書順に積み重なり、単位はその値とともに、証拠はその項目とともに保持されます。

「ソースなし最小」バリアントは存在しません。ソースや期間を削除することはデザイン上の選択ではなく、範囲が定められた測定を曖昧な主張に変えてしまうからです。

パラメータ

契約は、表示される値とその意味および出所を分離し、レンダラーが各関係をプラットフォーム間で保持できるようにします。

項目がコホート、地理、通貨ベース、計画、または方法論を共有しており、それらが各ラベルに正確に収まらない場合、コンテキストが必須になります。共有ソースまたは期間は、すべての項目に同一に適用され、マークアップがそれをグループに関連付ける場合にのみ、1回だけレンダリングできます。それでも、正規のコンテンツモデルは各項目にソースと期間を保持し、再利用によって値が証拠から切り離されないようにする必要があります。

構文とコード例

3つの実装すべてで、項目の順序と4つの必須項目フィールド（値、ラベル、ソース、期間）を保持しなければなりません。これらの例は、組織に関する主張ではなく、説明用のコンテンツです。

ポータブルMarkdownディレクティブ

:::stat-band{heading="サポートパフォーマンス" context="すべての優先度レベル"}
- value: "12 min"
  label: "初回応答の中央値"
  source: "サポートエクスポート"
  period: "2026-01-01/2026-06-30"
- value: "94%"
  label: "SLA内で解決されたチケット"
  source: "サポートエクスポート"
  period: "2026-01-01/2026-06-30"
- value: "4.7/5"
  label: "顧客満足度"
  source: "解決後アンケート"
  period: "2026-01-01/2026-06-30"
:::

Hugoショートコード

既存の statgrid ヘルパーは、1行につき1つのパイプ区切り項目（値、ラベル、オプションのソースURL）を受け入れます。専用のレンダラーが期間とソースを別々のフィールドとして公開するまでは、両方をラベルに表示し、どちらも省略しないでください：

{{< statgrid >}}
12 min | 初回応答の中央値 · サポートエクスポート · 2026年1月～6月
94% | SLA内で解決されたチケット · サポートエクスポート · 2026年1月～6月
4.7/5 | 顧客満足度 · 解決後アンケート · 2026年1月～6月
{{< /statgrid >}}

このマッピングは表示には許容されますが、3つの意味が1つのラベル文字列を共有するため、機械検証には理想的ではありません。将来の型付きレンダラーは、作成された意味を変更せずに上記の正規フィールドを実装する必要があります。

WordPressブロックまたはショートコード

[stat_band heading="サポートパフォーマンス" context="すべての優先度レベル"]
[stat value="12 min" label="初回応答の中央値" source="サポートエクスポート" period="2026-01-01/2026-06-30"]
[stat value="94%" label="SLA内で解決されたチケット" source="サポートエクスポート" period="2026-01-01/2026-06-30"]
[stat value="4.7/5" label="顧客満足度" source="解決後アンケート" period="2026-01-01/2026-06-30"]
[/stat_band]

カスタムWordPressブロックは、同じフィールドをフォームコントロールとして表示できます。それらを実際のテキストとしてレンダリングし、ソースリンクを保持し、スタイルが無効になっても読み上げ順序が適切であることを保証する必要があります。

例

良い例：3つの補完的で範囲が定まった数値

12分 — 初回応答の中央値；サポートエクスポート；2026年1月～6月
94% — SLA内で解決されたチケット；サポートエクスポート；2026年1月～6月
4.7/5 — 顧客満足度；解決後アンケート；2026年1月～6月

これは、各値が異なる運用上の質問に答え、その単位を含み、証拠を特定し、活動が発生した時期を明記しているため機能します。同じ期間により比較が容易になり、別のアンケートソースが感情データとチケットシステムデータを正直に区別しています。

悪い例：範囲のない印象的な数字

12 — 応答時間
94% — 成功率
4.7 — 顧客スコア
2× — より高速
#1 — 最高のサービス

これらが有効な内部レポートからコピーされた値であっても、この例は失敗しています。「12」には単位がありません。「成功率」には分子も分母もありません。スコアには尺度がありません。「2倍高速」にはベースラインがなく、「#1」にはカテゴリと比較セットがありません。ソースや期間を挙げているものはありません。5つの等しい重みの項目は、どの結果が最も重要かを隠してしまいます。修正方法は、5つすべてに小さな脚注を追加することではなく、意思決定に関連する3つの指標を選択し、定義を復元し、それぞれに証拠を添付することです。

スキーママークアップとアクセシビリティ

統計バンドには専用のSchema.orgタイプはありません。通常は、Article、Report、Dataset、Organization、またはその他の有効なページレベルのエンティティ内で可視コンテンツとして残ります。リサーチページでは、データセットの時間的カバレッジや測定変数などの検証済みフィールドをDatasetマークアップにマッピングできますが、数値が視覚的に存在するからといって資格が生まれるわけではありません。StatBand、Statistic、評価、賞、またはパフォーマンスプロパティをでっち上げないでください。

構造化データは、可視の主張よりも具体的であってはなりません。タイルに「4.7/5 顧客満足度」と表示されている場合、ページが必須の評価人口、方法、および適格な主題も提供しない限り、マークアップがそれを製品のaggregateRatingとして静かに再解釈することはできません。最も安全なデフォルトは、要素レベルのスキーマなしです。

アクセシビリティのために、各項目をDOM順の一貫したテキストグループとしてレンダリングします。値は、ソースと期間の前にラベルとともに読み上げられる必要があります。単位にCSS生成テキストを使用しないでください。支援技術が見逃す可能性があるためです。ポジティブまたはネガティブなパフォーマンスを緑と赤だけでエンコードしないでください。矢印が方向を示す場合は、「8パーセンテージポイント上昇」などのテキストを含めてください。ソースリンクには説明的なアクセシブルな名前が必要であり、繰り返される「ソース」リンクは実際の出版物またはデータセット名を公開する必要があります。

バンドは縮小するのではなく、リフローする必要があります。狭い幅では、項目は同じ編集順序で積み重なります。大きな数字には十分なコントラストが依然として必要ですが、補助的な証拠が判読不能なほど小さくなってはいけません。コンテナは、実際のインタラクティブコントロール（編集フォームには含めるべきではありません）を含まない限り、アラート、ライブ領域、ボタンリスト、またはキーボードターゲットではありません。

作成ルール

読者は、通常の本文コピーの文よりも大きな数字に多くの権威を認めます。そのため、抑制がコンテンツ要件となります。デフォルトでは3つの数値を使用し、意図的なペアには2つ、それぞれが異なる次元を追加する場合にのみ4つを使用します。5つ以上を統計バンドとして公開してはなりません。

値は、正確さが許す限りコンパクトに記述します。通常は単位を含めて1〜12文字です。数字を使用し、意味のある小数点精度を維持し、単位を付けたままにします。「12分」「94%」「€2.4m」「4.7/5」など。値の解釈が変わる場合は、タイルをきれいに見せるためだけに丸めないでください。パーセント変化とパーセンテージポイント変化を混在させず、正しい方をラベルまたは修飾子に記述してください。

ラベルは2〜10語で、測定対象を称賛ではなく名称で示します。「SLA内で解決されたチケット」は検証可能です。「卓越したサービスパフォーマンス」はプロモーション的な曖昧表現です。妥当な読者が誤解する可能性がある場合は分母を明記してください：「監査済みURLの32%」、「32%準拠」ではありません。バンドの前になじみのない略語を定義するか、ラベルに完全な表記を記述してください。

すべての項目にソースと期間が必要です。数値は異なる速度で陳腐化し、異なるシステムから取得される可能性があるためです。公開日ではなく、観測期間（「2026年1月～6月」）を使用してください。在庫、従業員数、価格、またはその他のスナップショットの場合は、「2026年6月30日現在」を使用します。予測の場合は、「予測」をラベルに記述し、ソースとしてモデルまたは計画を特定してください。

バンドには、ソースのない最上級表現、推薦文の断片、ボタン、長い方法論ノート、チャート、2つ目のネストされたバンド、またはその限定条件が明白な意味を反転させる数値を含めてはなりません。アニメーションによるカウントアップ効果を使用しないでください。理解を遅らせ、読者の気を散らし、主張ではない中間値を露出させる可能性があります。詳細な方法と引用は、バンドのすぐ下、またはページのソースブロック に配置し、すべてのタイルに表示可能なソース名と期間を保持してください。

使用する投稿タイプ

postTypesフロントマターは、機械可読な関係です。以下の表は、各登録投稿タイプがいつ、どこでこの要素を使用するかを定義しています。

QAチェックリスト

• バンドには2〜4つの数値が含まれ、コンテンツが別の数を正当化しない限り3つを使用する。
• すべての数値がページの結論の中心であり、異なる次元を追加している。
• すべての値に、該当する場合は単位、尺度、符号、または比率分母が含まれている。
• すべてのラベルが、メリット、最上級表現、または曖昧な「成功」指標ではなく、測定可能な事実を名称で示している。
• すべての項目がそのソースを特定している。バンドの下に共有ソースノートがある場合でも同様。
• すべての項目が観測期間または正確な特定時点の日付を明記している。
• コホート、地理、通貨ベース、計画、比較セットが、解釈に必要な場所で表示されている。
• 予測と目標は明示的にラベル付けされ、観測結果と誤認される可能性がない。
• バンドの前に、数値を理解可能にする十分なコンテキストがあり、詳細な分析の前に配置されている。
• 別の強調度の高いデータ、推薦文、価格、またはコンバージョンモジュールの隣に配置されていない。
• 近くのチャートやテーブルを、明確な要約目的を追加せずに重複していない。
• 値、ラベル、ソース、期間は実際のテキストであり、文書順に接続されたままである。
• 単位がCSS、アイコン、色、ホバー、またはアニメーションによってのみ提供されていない。
• 狭い画面レイアウトが編集順序、読みやすいタイプ、項目境界を保持している。
• 構造化データは有効なページレベルのタイプのみを使用し、証拠がサポートしない評価、賞、またはプロパティを主張していない。
• ポータブルMarkdown、Hugo、WordPressバージョンが同じ値と出所を保持している。
• すべてのスクリーンショットコメントは、名前付きアセットが存在するまでレンダリングされないキャプチャ指示のままである。

FAQ

統計バンドにはいくつの数値を含めるべきですか？

デフォルトでは3つを使用します。意味のあるペアを形成する場合は2つが機能し、4つが最大です。5つ目の数値は、コンテンツに優先順位付けまたは別のフォーマットが必要であることの証拠です。

すべての数値に個別のソースが必要ですか？

はい。1つのデータセットを使用する場合、共有の表示ノートですべての項目をカバーできますが、コンテンツモデルは各値にそのソースを関連付けたままにし、抽出や再利用で分離できないようにする必要があります。

報告期間としてカウントされるものは何ですか？

測定された活動が発生した期間を使用します（例：「2026年1月～6月」または「2026年第2四半期」）。スナップショットの場合は、正確な「現在」の日付を記述します。ページの公開日は、記事がいつ表示されたかを読者に伝えるだけです。

バンドに予測や目標を含めることはできますか？

はい。ただし、ラベルに「予測」「見通し」「目標」と明示的に記載し、ソースがモデル、計画、または責任者を特定している場合に限ります。観測結果と将来の推定値は別々のバンドに分けるか、すべての項目で区別をラベル付けしてください。

統計バンドにSchema.orgマークアップは必要ですか？

通常は不要です。それを囲むページスキーマ内に保持してください。主題、プロパティ、方法論、証拠が独立して資格を持つ場合にのみ、値を構造化プロパティにマッピングしてください。視覚的な強調だけではスキーマの資格は生まれません。