スコアカード：固定基準に基づく透明な評価

スコアカードとは、1つの対象を固定された一連の基準に従って評価し、明示された方法でそれらのサブスコアを組み合わせるコンパクトな評価ブロックです。評価を、読者に数字を盲目的に信頼させるのではなく、検証可能な計算へと変換します。

あくまで説明用の例です。記載された製品名と観察結果は架空のものです。スケール：0〜10。0は基準を満たしていない、10は完全に満たしていることを意味します。

この要素が重要な理由

読者は評価に対して当然ながら懐疑的です。なぜなら、ひとつの数字に数十もの編集上の判断が隠されている可能性があるからです。どのような品質が判断されたのか？すべての対象に対して同じ方法で判断されたのか？商業的に都合のよい機能が、深刻な制限事項を上回ってしまっていないか？スコアカードは、評価結果、基準、重み、エビデンスを一体に保つことで、その不確実性を軽減します。読者が事実には同意しつつも優先順位には同意しない——サポートを統合よりも重視する人は、公開された合計点が自分の判断に合わない理由を理解できます。

この心理効果は、数字の権威よりも先に方法が示されるときにのみ機能します。大きな数字は測定を暗示し、小数点以下の桁は再現性を暗示します。ルーブリックと計算方法が開示されていなければ、「8.3/10」は研究室の服装を着た意見に過ぎません。スケールのアンカー、エビデンスルール、重み、四捨五入ポリシーを公開することで、精度に正当な根拠が与えられ、編集上の判断を隠すのではなく可視化できます。

機械による抽出可能性とは、自動化システムが、何が評価されたか、各基準の意味、スコアスケール、サブスコアと合計の関係を保持できることを意味します。裸の「7.7」は曖昧で、ユーザー評価、テスト結果、バージョン番号の可能性があります。明示的な対象とスケールを持つテキストベースの表は、安定したフィールドと値のペアを公開します。クローラーやAI回答システムは、「5つのタスクテストにおけるユーザビリティの10点中7.5点」のような範囲が定められた主張を、数字をその根拠から切り離すことなく引用できます。

要素作成ルール に基づき、スコア評価を目的とするブロックは、型付きスコアカード契約を使用しなければなりません。スタイル付きバッジの並びはこれと同等ではありません。型付き要素は方法論を保持し、重みと合計の検証を可能にし、公開システム全体で一貫した出力をサポートします。

使用すべき場面

1つ以上の対象が同じ固定ルーブリックに対して評価され、その結果のサブスコアが読者の評価理解に役立つ場合にスコアカードを使用します。適切な入力には、文書化されたテスト、要件にマッピングされた検証済み仕様、公開されたアンカーに基づく専門家による検査、またはそれらの定義された組み合わせが含まれます。スコアカードは、読者が基準の内訳を見た後に合理的に異なる選択をする可能性がある場合に、その価値を発揮します。

方法はスコアリングを開始する前に存在していなければなりません。対象、適合条件、基準、重み、スケールアンカー、エビデンスソース、テスト条件、欠損データポリシー、四捨五入ルールを定義します。これらを評価セット全体で固定します。方法を途中で変更した場合は、影響を受けるすべての対象を再スコアリングするか、結果を異なるエディションとして識別し、直接比較できないようにします。

よくある不完全なケースは次のとおりです：

• スコアリングされていない機能マトリックス。 機能の有無を示すことが目的の場合は、比較表 を使用します。ポイントを追加すると、評価的ではなく事実的な差異が歪められる可能性があります。
• 単一の測定指標。 ページ速度、価格、応答時間、バッテリー寿命はすでに単位を持っています。測定値と関連するベンチマークを報告し、それを恣意的な星評価に変換しないでください。
• ユーザーレビューの集計。 顧客平均は、作成者、サンプリング条件、バイアス管理が異なります。それを出典付きの集計として表示し、パブリケーションのスコアカードとしては表示しないでください。
• チェックリスト。 8つの要件のうち6つを満たしたからといって、自動的に7.5/10の評価にはなりません。一部の要件は必須であり、非補償的（他の分野での強みが不合格を相殺できない）な場合があります。
• 受賞バッジ。 「編集部推薦」は結論を伝えますが、その理由は伝えません。スコアカードの後には配置できますが、スコアカードの代わりにはなりません。
• 製品を見た後に作成されたランキング。 好ましい勝者を正当化するために選択された基準は、事後的な理屈であり、再現可能な評価ではありません。

基準が互いに合理的に補償できない場合は、合計スコアを使用しないでください。例えば、重大な安全上の欠陥は、魅力的なデザインによって平均化されるのではなく、通常は除外または明示的な不合格状態をトリガーする必要があります。その場合は、合格/不合格のゲートと残りの記述的評価を別々に公開してください。

配置場所

最初のスコアカードは、ページが対象、評価目的、読者層、テスト日、簡潔な方法論の説明を特定した後に配置します。レビューの場合、通常は概要評価の後、詳細な基準セクションの前になります。比較の場合、共通のルーブリックを一度紹介し、その後ページ全体で使用されているのと同じ対象順序でスコアカードを提示します。ベンチマークレポートの場合は、評価対象を示す前にコホートとデータ期間を説明します。

この要素は、方法がその直前または隣接する記述的な方法リンクから入手可能な場合にのみ、ページ上部近くに表示されることがあります。読者が何を評価されたかを知る前に、スコアがページをリードすることはできません。詳細なエビデンスは後続しても構いませんが、各行には依然として短いエビデンス概要または関連セクションへの直接リンクが必要です。

スコアカードを星評価の集計、お客様の声、価格販促、アフィリエイトボタン、「受賞」バナーの隣に直接配置しないでください。これらの要素は、編集上の判断が商業的に誘導されたように見えたり、読者が別々の評価システムを混同したりする原因になります。異なるスケールのスコアカードを2つ並べて配置しないでください。スコアカードと密集したチャートまたは2番目の採点システムの間には、少なくとも1つの説明段落を挟み、広告で方法論とスコアカードを分離しないでください。

構成要素

ラベル付きキャプチャは以下の領域を識別する必要があります：

1. 対象： 評価された正確な製品、企業、ページ、サービス、またはエディション。
2. 全体スコア： 計算結果。常に分母またはスケールとともに表示。
3. 方法概要： 誰が、いつ、どのエビデンスとテスト条件を用いて評価したか。
4. スケールアンカー： 最小値、中間値、最大値の意味。「10点満点」だけでなく具体的に説明。
5. 基準ラベルと定義： 1つの安定した評価軸と、その範囲の境界。
6. 重み： 合計に対する基準の貢献度。明示的な均等重み付けを含む。
7. サブスコア： 宣言されたスケールにおけるその基準の結果。
8. エビデンス概要： サブスコアを正当化する観察結果または出典。
9. 計算と四捨五入の注記： 表示された合計を生成するために使用された計算式。
10. 日付とバージョン： 評価が実施された日付と、テストされた対象のバージョンまたはプラン。
11. 開示： 商業上の関係、提供されたアクセス、または重要なテスト上の制限事項。

デザイン例

すべてのバリエーションは同じコア契約を維持します。視覚的な圧縮により各行の説明が減る場合がありますが、方法論、重み、スケール、エビデンスへのアクセスを削除することはできません。

加重標準： レビューや購入判断のデフォルト。基準の重要度が異なる場合に使用します。すべての重みを表示し、合計が100%になることを確認します。

均等重みコンパクト： 編集方法が各基準に同一の影響を与える場合に適しています。「均等重み付け」が表示されている必要があります。重みが省略されていることは、均等重みを意味しません。

比較スコアカード： 1つの固定ルーブリックで評価された2〜3の対象に使用します。基準は行として残り、対象は一貫した順序で表示されます。より多くの対象の場合は、個別のカードまたはエビデンスへのリンク付き比較表を使用して、モバイルでの読みやすさを維持します。

ゲート付きスコアカード： 必須条件が加重合計をオーバーライドできる場合に使用します。オプション基準の前にゲートを明示し、「推奨なし—必須セキュリティ要件を満たしていません」と表示し、高い平均が承認を暗示することを防ぎます。

不完全または未スコア状態： エビデンスがないことが正直であり、ポリシーが事前に定義されている場合にのみ使用します。基準を「未テスト」とマークし、その理由を説明し、合計を保留するか、分母と再重み付けが明確な暫定合計を表示します。黙ってゼロを割り当てたり、重みを再配分したりしないでください。

パラメータ

標準的な0〜10モデルの計算式は total = Σ(サブスコア × 重み（小数として）) です。検証では、マイナスの重み、100%以外の合計、スケール外のサブスコア、計算結果と異なる手入力の全体スコアを拒否しなければなりません。レンダラーが合計を計算しても構いませんが、保存された基準と重みが信頼できる入力として残ります。

構文とコード例

以下のすべての実装は、同じ架空の評価を表しています。方法、日付、スケール、アイテム順序、重み、エビデンス、四捨五入ポリシーを保持しています。

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

:::scorecard{subject="Acme Support Desk" scaleMin=0 scaleMax=10 dateEvaluated="2026-08-20" rounding=one-decimal}
## 製品評価

評価日時点のドキュメントに基づき、5つの標準サポートタスクをテストし、必要な管理機能と統合を検証しました。

::item{weight=30 subscore=8}
### セキュリティ管理

必要な管理機能は文書化済み。高度な管理機能2つは未対応。
::
::item{weight=25 subscore=7.5}
### ユーザビリティ

定義された5つのタスクをテスト。1つは繰り返しの操作が必要。
::
::item{weight=25 subscore=9}
### 統合カバレッジ

必要な統合20件中18件に対応。
::
::item{weight=20 subscore=6}
### サポート

メール応答は公開SLAを満たす。電話チャネルなし。
::
:::

Hugoショートコード

Hugoアダプターは、親呼び出しとアイテム呼び出しの名前付きパラメータのみを受け付ける必要があります。以下の表記はポータブルな実装仕様であり、このリポジトリにレンダラーがすでに存在することを主張するものではありません。

{{< scorecard subject="Acme Support Desk" scale-min="0" scale-max="10" evaluated="2026-08-20" rounding="one-decimal" >}}
## 製品評価

評価日時点のドキュメントに基づき、5つの標準サポートタスクをテストし、管理機能と統合を検証しました。

{{< score criterion="Security controls" weight="30" value="8" >}}必要な管理機能は文書化済み。高度な管理機能2つは未対応。{{< /score >}}
{{< score criterion="Usability" weight="25" value="7.5" >}}定義された5つのタスクをテスト。1つは繰り返しの操作が必要。{{< /score >}}
{{< score criterion="Integration coverage" weight="25" value="9" >}}必要な統合20件中18件に対応。{{< /score >}}
{{< score criterion="Support" weight="20" value="6" >}}メール応答は公開SLAを満たす。電話チャネルなし。{{< /score >}}
{{< /scorecard >}}

WordPressブロック

<!-- wp:amicited/scorecard {"subject":"Acme Support Desk","scaleMin":0,"scaleMax":10,"dateEvaluated":"2026-08-20","rounding":"one-decimal"} -->
<!-- wp:amicited/score {"criterion":"Security controls","weight":30,"subscore":8} -->
<p>必要な管理機能は文書化済み。高度な管理機能2つは未対応。</p>
<!-- /wp:amicited/score -->
<!-- wp:amicited/score {"criterion":"Usability","weight":25,"subscore":7.5} -->
<p>定義された5つのタスクをテスト。1つは繰り返しの操作が必要。</p>
<!-- /wp:amicited/score -->
<!-- wp:amicited/score {"criterion":"Integration coverage","weight":25,"subscore":9} -->
<p>必要な統合20件中18件に対応。</p>
<!-- /wp:amicited/score -->
<!-- wp:amicited/score {"criterion":"Support","weight":20,"subscore":6} -->
<p>メール応答は公開SLAを満たす。電話チャネルなし。</p>
<!-- /wp:amicited/score -->
<!-- /wp:amicited/scorecard -->

WordPressエディターは、合計を計算し、手入力を許可しないようにする必要があります。重みの合計が100%にならない場合は公開をブロックし、アイテムにエビデンスやテスト済みバージョンがない場合は警告を表示します。

例

良い例：再現可能な加重評価

Acmeサポートデスク：10点中7.7点、2026年8月20日評価。 セキュリティ管理は30%で8.0点、ユーザビリティは25%で7.5点、統合カバレッジは25%で9.0点、サポートは20%で6.0点。各サブスコアは文書化された要件または5タスクテストに紐づいています。合計は加重サブスコアの合計であり、最後に1回だけ小数点以下1桁に四捨五入されています。

これが機能する理由は、別の編集者が同じルーブリック、エビデンス、計算式を使用して、基準レベルでの相違点を説明できるからです。小数点以下の桁は加重入力によって正当化されています。結果は日付とテスト条件によって範囲が定められているため、永続的な製品品質を暗示するものではありません。

悪い例：評価結果を無理やり数値化したもの

Acmeサポートデスク：10点中9.3点。 機能9.5、価値9.0、エクスペリエンス9.4。「当社の専門家が重要な要素すべてを考慮しました。」

これは、基準が重複しており、定義、重み、アンカー、エビデンス、テスト日、計算がないため失敗しています。「価値」は、価格、プラン、対象者、代替案なしには解釈できません。「エクスペリエンス」にはユーザビリティ、サポート、またはその両方が含まれる可能性があります。説明のない小数点は、方法では生成できない精度を示唆しています。修正するには、評価前にルーブリックを定義し、基準レベルのエビデンスを収集し、重み付けを開示し、記録された入力から合計を計算する必要があります。つまり、望ましい見出し数値に平均化されるサブスコアを選択するのではなく、適切なプロセスを踏む必要があります。

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

スコアカードには汎用のSchema.orgタイプはありません。デフォルトでは、ページの有効なエンティティおよび記事マークアップ内の可視コンテンツとして保持します。ReviewおよびRatingマークアップは、本物のレビューが特定の対象アイテムを評価する場合に適用されることがあります。使用する場合、ratingValue、bestRating、worstRatingは表示される全体スコアおよびスケールと一致しなければならず、レビュー作成者、レビュー対象アイテム、日付、および補足のレビューコンテンツも存在する必要があります。企業ベンチマーク、編集フレームワーク、または抽象的な概念のスコアカードは、数字が含まれているという理由だけで自動的に対象になるわけではありません。

各基準を個別のReviewとしてマークアップしないでください。また、一人の編集者の計算結果にAggregateRatingを使用しないでください。集約は複数の評価を表し、表示可能な数と適切な出典が必要です。外部のユーザー平均を、2つのシステムを別々に表示せずに編集上の合計にブレンドしないでください。ページが多くの資料を引用する場合は、ソースブロック を使用して、より広範なエビデンスセットを検査可能にします。

アクセシビリティのために、読者が列を横断して基準を比較する必要がある場合は、実際のテーブルを使用します。対象と合計を示すキャプション、列ヘッダー、行ヘッダー、tfoot計算行を提供します。色、アイコン、グラフィカルメーターが消えた場合でも、同じ情報が利用可能でなければなりません。「緑」や「塗りつぶされた星5つ」だけをステータスとして告知せず、「10点中8点」を公開します。

プログレスバーはテキストを補完することはできますが、置き換えることはできません。意味のあるメーターには、アクセシブルな名前、現在値、最小値、最大値を与えてください。モバイルでは、各列をラベルのないスタックに変換するのではなく、ソース順序を保持します。キーボード、タッチ、テキストのみのユーザーはツールチップを受け取れない可能性があるため、ツールチップに必須のエビデンスを保持することはできません。role="alert"、自動カルーセル、アニメーションスコアカウントは避けてください。スコアは静的な編集コンテンツであり、ライブシステムイベントではありません。

作成ルール

結果を公開する前に、評価の理由を説明してください。対象者とスコアがサポートする意思決定を明示します。なぜなら、小規模チームにとって「最良」の基準が、規制対象の企業にとっては間違っている可能性があるからです。詳細な分析の前または中に、各基準を一文で定義します。基準は、同じ観察結果が2度評価されないように十分に区別されている必要があります。

3〜7つの基準を使用します。3つ未満では通常、単純な比較に陥ります。7つを超えると合計の監査が困難になり、些細な区別を助長します。基準ラベルは2〜8語を使用します。エビデンス概要は8〜40語で、観察結果を述べ、宣伝的な形容詞は使用しません。「エンタープライズプランでSAML SSOをサポート」はエビデンスですが、「優れたセキュリティ」は判断を繰り返しているに過ぎません。

スケールアンカーを公開します。0〜10スケールの場合、各基準または真に共有されたルーブリックについて、少なくとも0、5、10を定義します。中間点は、比較母集団と統計が定義されていない限り、「平均」ではなく、テスト可能な状態を記述する必要があります。すべての対象を同じスケールとルーブリックバージョンに保ちます。

重み付けは透明でなければなりません。すべてのパーセンテージを表示し、合計が100%になるようにし、高加重の基準が指定された対象者にとってなぜより重要なのかを説明します。均等重み付けも重み付けであり、明示する必要があります。対象ごとに重みを変更せず、スポンサーシップステータス、アフィリエイトコミッション、製品アクセス、または好ましい結果が重みに影響を与えることを許してはいけません。

四捨五入されていないサブスコアで計算し、最終結果を1回だけ四捨五入します。デフォルトでは小数点以下1桁を表示します。小数点以下2桁は、入力ルーブリックがその精度を確実に区別できる場合にのみ許可されます。そうでなければ信頼度を偽造することになります。すべてのスコアの横に分母を表示し、パーセンテージとポイントを区別します。

根拠のない称賛、販売CTA、価格の緊急性、お客様の声、ユーザーレビューの星、または未開示の商業関係をスコアカード内に決して配置しないでください。失格となる不合格を脚注に隠さないでください。欠落したエビデンスを中立的な中間点として扱わないでください。「未テスト」と明示し、事前に定義された欠損データルールに従い、公正な計算が不可能な場合は合計を保留します。

使用する投稿タイプ

postTypesフロントマターがこのマッピングのソースです。対象となるということは、安定したルーブリックと基準レベルのエビデンスが存在する場合に、そのフォーマットがスコアカードをサポートできることを意味します。すべてのページで評価を必須とするものではありません。

QAチェックリスト

• 対象、バージョンまたはプラン、評価日、対象者、意思決定が明示されている。
• 方法論はスコアリング前に定義され、再度適用可能である。
• テスト可能な定義を持つ、3〜7つの明確に区別された基準がある。
• すべての基準に可視の重みがあり、すべての重みの合計が正確に100%である。
• スケールアンカーが最小値、中間値、最大値の意味を説明している。
• すべてのサブスコアにエビデンス概要とトレース可能な出典またはテスト観察結果がある。
• 必須ゲートがオプション基準での強みによって平均化されることがない。
• 合計はサブスコアと重みから計算され、1回だけ四捨五入される。
• 表示される精度は入力の粒度によってサポートされている。
• 欠落したエビデンスは開示されたポリシーに従い、黙ってゼロまたは平均とスコアリングされることはない。
• 商業上の関係、提供されたアクセス、重要な制限事項が開示されている。
• スコアカードはユーザーの星、お客様の声、販促、または競合するスケールの隣に配置されていない。
• テーブルヘッダー、キャプション、読み取り順序、テキスト代替、モバイルでのリフローがアクセシブルである。
• 構造化データが存在する場合、表示される対象、作成者、評価、スケールと一致し、ページタイプに対象資格がある。
• 選択された投稿タイプがpostTypesに表示され、周囲の記事が詳細なエビデンスを提供している。

FAQ

すべてのスコアカードに重み付け基準が必要ですか？

すべてのスコアカードは、各基準が合計にどのように貢献するかを明示しなければなりません。均等な重み付けも有効ですが、それでも開示が必要です。一部の基準がより重要な場合は、すべての重みを公開し、重みの合計が100%になるようにしてください。

スコアカードにはいくつの基準を含めるべきですか？

3〜7つを使用します。通常は4つか5つで、誤った精度を生み出すことなく十分なカバレッジが得られます。評価に7つ以上が必要な場合は、詳細なチェック項目を少数のスコアリング基準の下にグループ化し、完全なルーブリックは別途公開してください。

スコアカードで小数を使用できますか？

はい、入力値と計算がそれを正当化する場合に使用できます。デフォルトでは表示される合計に小数点以下1桁までとし、四捨五入ルールを明示し、主観的な判断を測定済みに見せかけるためだけに小数点以下の桁数を追加してはいけません。

ユーザーレビューを編集部のスコアカードに反映できますか？

出典、サンプルサイズ、収集期間、計算式への貢献度を明確に開示した、名前付きの入力としてのみ可能です。第三者によるユーザー評価を編集部のスコアとしてラベルを変更したり、テスト結果に暗黙的に融合したりしてはいけません。

スコアカードはレビューや評価のスキーマに適合しますか？

自動的には適合しません。評価マークアップが適切なのは、ページが対象となる明確に識別された主題をレビューし、表示される評価、スケール、作成者、および補足コンテンツが関連する構造化データ要件を満たしている場合のみです。