スペック表：書式、ルール、および例

スペック表は、1つの対象に関する事実を明確なラベルと値のペアに変換します。読者は製品説明を再読することなく動作温度を見つけられ、機械は「動作温度」と「−10〜45 °C」の関係を、どの数字がどの主張に属するかを推測することなく保持できます。

上記の製品名と値は説明用です。この構造が制作モデルです：1つの対象、行ごとに1つの正確なラベル、単位付きの1つの値、および事実値を提供できない場合の明示的なステータスです。

この要素が重要な理由

仕様を散文で書くと、読者は避けられる再構築作業を強いられます。次の例を考えてみてください：「このユニットの重量は6.4キログラムで、連続500ワットを出力し、寸法は280×190×210ミリメートルで、マイナス10度から45度の範囲で動作します。」この文は文法的に正しいですが、寸法だけを探している購入者はすべての節を解析しなければなりません。後で出力を確認するために戻ると、もう一度解析する必要があります。テーブルはラベルを予測可能な端に、値を2列目に移動させ、記憶作業を減らし、スキャンを確実にします。

この構造は機械にとっても同様に重要です。機械抽出可能性とは、クローラー、検索システム、アシスタント、または下流の公開ツールが、コンテンツの意味と関係性を保持できる能力です。ネイティブの<table>、<th scope="row">、<td>マークアップは、行ヘッダーが隣接する値を修飾することを示します。「使用可能容量 — 512 Wh」という信頼性の高いペアを生成します。プロモーション文の中に埋め込まれた同じ2つの文字列は、言語レベルの推論が必要であり、スタイル付けされた無関係な<div>要素の集合は、データの関係性を公開せずに視覚的な整列だけを公開する可能性があります。

クエリ可能とは、すべてのWebサイトがデータベースになるという意味ではありません。それぞれの事実に安定したラベル、個別の値、予測可能なマークアップがあることを意味し、読者やシステムが段落全体を抽出することなく1つのプロパティを要求できるようにします。比較可能とは、個別に公開された製品が同じ標準的なラベルと単位を使用できることを意味し、「約0.5キロワット」「500ワット」「0.5 kW」を最初に正規化することなく、後で値を整列させることができます。スペック表はその後の比較を可能にしますが、複数の対象を並べて提示しない限り、それ自体が比較表ではありません。

使用するタイミング

ページが1つのエンティティを説明し、読者が少なくとも3つの個別の検証済み事実を必要とする場合にスペック表を使用します。一般的な対象には、製品、ソフトウェアプラン、API、ファイル形式、施設、車両、組織、サービスパッケージ、技術標準などが含まれます。適切な事実は、境界のある回答を持ちます：寸法、対応オペレーティングシステム、コネクタタイプ、応答形式、保証期間、法人名、カバレッジエリア、バージョン、または規定された制限などです。

テーブルの周囲には散文を使用して結果を説明します。「最大ペイロード：18 kg」はテーブルに属しますが、その制限が特定の設置を排除する理由は散文に属します。テーブルは「値は何か？」に答え、周囲の説明は「なぜそれが重要なのか？」に答えるべきです。

類似しているが異なるケースは一般的です：

• 2つ以上の製品を共通の基準で判断する必要がある場合は、代わりに比較表 を使用します。スペック表には1つの対象があり、複数の値列を追加するとその目的が変わります。
• コンテンツが一連のイベントである場合は、タイムラインを使用します。2列のテーブルに日付を入れても、自動的に関係が時系列になるわけではありません。
• 各行に数文の解釈が必要な場合は、見出しと散文を使用します。セル内の密集した段落はスキャンを妨げ、狭い画面で読みづらくなります。
• リストに2つだけの簡単な事実が含まれている場合は、投稿タイプが登録済みのスペック表を必要としない限り、文または定義リストを使用します。テーブルは検索価値を生み出すべきであり、小さな事実を装飾するものではありません。
• 値が継続的に更新される場合は、要素を所有するデータソースに接続し、取得時刻を表示します。手動でコピーした「ライブ」値は、ずれるとすぐに誤解を招きます。
• ドキュメントがフィールド名、タイプ、およびバリデーション制約を記述する場合は、以下のグループ化バリアントを使用してください。データモデル全体を1つの散文主体の「詳細」セルに詰め込まないでください。

要素の書き方ルール が優先されます：見出しや外観ではなく、パッセージの目的によって要素を選択してください。ブロックの役割が仕様を公開することである場合、テーマが同じ言葉をカードとして表示できたとしても、それはスペック表のままです。

配置する場所

最初のスペック表は、対象が特定された後、ページが読者に解釈、設定、比較、購入を促す前に配置します。製品ページでは、通常は簡潔な製品説明と主要な利点の後、詳細な機能説明の前になります。ドキュメントでは、前提条件やプロトコルテーブルを、それに依存する手順の直前に配置します。読者は値を見る前にそれらが何を説明しているかを知る必要がありますが、長いナラティブを辿って値を取得する必要はありません。

ページに複数のカテゴリがある場合は、各テーブルを「物理仕様」や「互換性」などの説明的なH2またはH3の下に配置します。カテゴリタイトルはテーブルの外側に保ち、キャプションは正確な対象と範囲を指定します。兄弟ページ間で同じラベル順序を維持し、読者がパターンを再学習する必要がないようにします。

スペック表を別の密集したテーブル、全幅スクリーンショット、またはアニメーションカルーセルの直接隣に配置しないでください。2つの競合するグリッドは不明瞭な読み取り経路を作り、タブレット幅で特に見づらくなります。キャプションとその行の間にコールトゥアクションを挿入したり、無関係なコンポーネント内に脚注を配置したり、値列にプロモーション主張を入れたりしないでください。キャプション、テーブル、ステータス凡例、検証日、ソースノートを1つの境界のあるユニットとして保持します。その後に説明を続け、別のデータ主体の要素を導入する前に配置します。

構成要素

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

1. セクション見出し： ページに複数のテーブルがある場合（例：物理仕様または電気仕様）、カテゴリに名前を付けます。
2. キャプション： テーブルの対象と正確な範囲を識別します。周囲の段落とは独立して意味を成す必要があります。
3. 行ヘッダー： 1つのプロパティの標準的で曖昧さのない名前を使用します。
4. 値： 解説や販売主張ではなく、1つの事実を含みます。
5. 単位： 値が本当に無単位でない限り、すべての数値に付記します。
6. ステータス値： 空のセルを残すのではなく、「Unknown」または「Not applicable」と明記します。
7. 検証日： 変動する事実が最後に確認された日付を記載します。
8. ソースノート： 値の出典となった主要なシステム、ドキュメント、テスト、または所有者を特定します。

Unknownは、プロパティは適用されるが、検証時に信頼できる値が利用できなかったことを意味します。Not applicableは、プロパティの前提がこの対象に適用されないことを意味します。Not availableはさらに異なり、機能やオプションが存在しないことを意味します。ゼロは測定値または宣言値です。空のセルはこれらの意味のいずれも伝えず、したがって許可されません。

デザイン例

すべてのデザインバリアントは、ネイティブのテーブルマークアップ、行ヘッダー、可視ラベル、テキスト値、およびキャプションを保持します。スタイリングは密度とグループ化を変更できますが、事実を画像に変えたり、色だけに意味を持たせたりすることはできません。

標準2列： 1つの対象と3〜12個の事実のデフォルト。ラベルが1列目、値が2列目を占めます。製品、会社、プラン、サービス情報に使用します。

グループ化： 2つ以上の短いテーブルが、より大きな仕様セットを読者のタスクごとに分割します。各グループは見出しを受け取り、各テーブルは独自のキャプションを保持します。マージされた区切り行を見出しとして使用しないでください。ナビゲーションと抽出が複雑になるためです。

フィールドリファレンス： タイプ、要件、制約など、意味を理解するために一貫した二次フィールドが必要なプロパティのためのドキュメンテーションバリアント。1列目は行ヘッダーセマンティクスを使用し、各二次ディメンションには列ヘッダーがあります。

コンパクトモバイル： ラベルと値はフォントサイズを小さくせずに自然に折り返します。シンプルな2列テーブルはそのコンテナ内でリフローする必要があります。より広いフィールドリファレンスバリアントは、ラベル付けされたキーボードフォーカス可能なリージョン内でスクロールする場合がありますが、ページ全体を水平スクロールさせてはいけません。

パラメータ

以下の契約はポータブル要素を定義します。最後の列の「ソース」は、レンダラーがパラメータを取得する場所を示し、事実の主張が調査された場所ではありません。

価格、互換性、可用性、バージョンサポート、容量、またはその他の値が変更される可能性がある場合は、必ずverifiedを使用します。公開日は代用になりません。公開日はページが公開された日を示すものであり、仕様が確認された日ではありません。

構文とコード例

すべての実装は、同じキャプション、順序付き行、ステータスの意味、検証値、およびソースにマッピングされます。ポータブルディレクティブが標準的な作成形式です。

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

:::spec-table{caption="Northstar Field 500 — コア仕様" verified="2026-08-27"}
| 仕様 | 値 |
|---|---|
| 使用可能容量 | 512 Wh |
| 連続AC出力 | 500 W |
| 寸法（幅 × 高さ × 奥行） | 280 × 190 × 210 mm |
| 防水等級 | Unknown |
| 燃料タイプ | Not applicable |

ステータス: Unknown = 関連するが未検証; Not applicable = 該当なし。

ソース: 承認済み製品データシート、リビジョン4。
:::

Hugoショートコード

Hugoアダプターは名前付きパラメータのみを受け入れ、パイプテーブル本文をセマンティックなテーブル行としてレンダリングする必要があります。以下の表記は意図されたマッピングを定義するものであり、記事タスク内で新しいローカルショートコードを作成する必要があることを意味するものではありません。

{{< spec-table caption="Northstar Field 500 — コア仕様" verified="2026-08-27" >}}
| 仕様 | 値 |
|---|---|
| 使用可能容量 | 512 Wh |
| 連続AC出力 | 500 W |
| 寸法（幅 × 高さ × 奥行） | 280 × 190 × 210 mm |
| 防水等級 | Unknown |
| 燃料タイプ | Not applicable |

ステータス: Unknown = 関連するが未検証; Not applicable = 該当なし。

ソース: 承認済み製品データシート、リビジョン4。
{{< /spec-table >}}

レンダラーは<table>、<caption>、<tbody>、<th scope="row">、および<td>を出力する必要があります。フィールドリファレンスバリアントには、scope="col"ヘッダーを持つ<thead>も必要です。マイナス記号、乗算記号、単位のスペース、ステータステキストを正確に保持する必要があります。

WordPressブロック

<!-- wp:amicited/spec-table {"caption":"Northstar Field 500 — コア仕様","verified":"2026-08-27","variant":"standard"} -->
<table>
  <tbody>
    <tr><th scope="row">使用可能容量</th><td>512 Wh</td></tr>
    <tr><th scope="row">連続AC出力</th><td>500 W</td></tr>
    <tr><th scope="row">寸法（幅 × 高さ × 奥行）</th><td>280 × 190 × 210 mm</td></tr>
    <tr><th scope="row">防水等級</th><td>Unknown</td></tr>
    <tr><th scope="row">燃料タイプ</th><td>Not applicable</td></tr>
  </tbody>
</table>
<p class="spec-table__status">Unknown = 関連するが未検証; Not applicable = 該当なし。</p>
<p class="spec-table__source">ソース: 承認済み製品データシート、リビジョン4。</p>
<!-- /wp:amicited/spec-table -->

WordPressの実装では、リテラルHTMLではなく編集可能なブロックコントロールを使用できますが、保存された属性とサーバーレンダリング出力は同じ契約を保持する必要があります。作成者はスクリーンショットや汎用のカラムブロックを代用してはいけません。

例

良い例：完全で正規化された製品情報

検証日： 2026年8月27日。 ソース： 参考用承認済みインストールシート、リビジョン2。

これが機能する理由は、キャプションが1つの対象と1つのコンテキストを識別しているからです。すべてのラベルはテスト可能なプロパティに名前を付け、範囲は単位を保持し、寸法は異なるシステムを混在させず、最大電力は標準電力と区別されています。「Not applicable」は正当化されます。有線センサーには交換すべきバッテリーがないからです。不明なバッテリー仕様を隠しているわけではありません。このテーブルは人がスキャンでき、行ヘッダーでナビゲートでき、個別のプロパティと値のペアに変換できます。

悪い例：曖昧な疑似データ

悪いテーブルは整理されているように見えますが、信頼性のあるデータを提供していません。「電力」は供給電圧または消費電力を意味する可能性がありますが、「低」は測定可能ではありません。ケーブル長には単位がありません。温度行は摂氏か華氏かを示しておらず、範囲と度記号が混ざっているように見えます。「堅牢」は防護等級ではなくプロモーション言語です。空のバッテリーセルは、その事実が不明、無関係、ゼロ、または誤って省略されたのかを伝えていません。互換性の主張は、未定義の母集団と設置判断を1つのセルに詰め込んでいます。

修正するには、広範なラベルを標準的なプロパティに分割し、名前付きの主要ソースから値を取得し、すべての測定値に単位を追加し、空白を正しいステータスで置き換えます。ソースが防護等級を明記していない場合は「Unknown」と書き、マーケティング言語を創作された技術値に変換しないでください。

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

仕様テーブルに対する一般的なSchema.orgタイプは存在しません。JSON-LDを生成しない場合でも、テーブルは価値あるセマンティックHTMLのままです。包含ページが適格なエンティティを表す場合、正確で検証済みの事実のみをサポートされているプロパティにマッピングします。例えば、製品のsku、weight、width、height、depth、material、または該当する場合はadditionalPropertyエントリなどです。組織の事実は、法人名や住所などのプロパティにマッピングできます。可視テーブルと構造化データは一致し、同じ単位を使用し、同じソースから取得する必要があります。行が存在するという理由だけで、評価、オファー、識別子、またはスキーマプロパティを創作してはいけません。

アクセシビリティは実際のマークアップから始まります。テーブルに説明的な<caption>を付けます。各仕様ラベルに<th scope="row">を使用します。フィールドリファレンスバリアントでは、<thead>内に<th scope="col">も必要です。画面上だけでなく、ソースでも論理的な読み取り順序を保ちます。空白セル、マージされたセル、アイコンのみのステータス、色のみのグループ化、または値の唯一の場所としてのツールチップを使用しないでください。AC、DC、IPなどの略語は、対象読者が理解していない可能性がある場合は、近くの散文で展開する必要があります。

基本的な2列テーブルは、実用的な場合はスクロールではなく折り返す必要があります。より広いテーブルに水平スクロールが必要な場合は、アクセシブルなラベルとtabindex="0"を持つリージョンに格納し、可視のキーボードフォーカスインジケーターを保持し、高いズームで値を隠すように最初の列を固定しないでください。200%ズーム、キーボードナビゲーション、スタイル無効でテストします。ラベルと値の関係はこれらすべての状況で維持される必要があります。

作成ルール

ルールは検索と比較を保護するため、簡潔さよりも正確さが優先されます：

• テーブルあたり3〜12行を使用します。より長いセットは、物理、電気、互換性、商用など、読者のタスクごとに分割し、区別のない事実の壁を作らないようにします。
• ラベルは可能な限り1〜6語に抑えます。意味が変わる場合は、「最大」「標準」「設置時」「ユーザーあたり」などの修飾語を使用します。
• 通常の値は1行、最大12語に抑えます。解釈、例外、推奨事項は、隣接する散文または直接関連するノートに移動します。
• 対象読者が本当に両方を必要とする場合を除き、テーブルごとに1つの測定システムを使用します。両方が必要な場合は、該当するすべての行について、主要な値を最初に、括弧内に換算値を提示します。
• すべての数値測定値の横に単位を配置します：512 Wh、3 m、45 °C。見出しが一部の行にのみ単位を提供することを決して当てにしないでください。
• 兄弟ページ間で同等のプロパティを正規化します。1つのラベルと1つの単位（例：キログラムでの「重量」）を選択し、文書化された理由なしに「質量」、ポンド、または曖昧なフレーズと交互に使用しないでください。
• 正確なステータス語を使用します：Unknown、Not applicable、またはNot available。複数のステータスが表示される場合は、それらを一度定義します。ダッシュ、空のセル、TBC、疑問符、または色を使用してステータスを暗示しないでください。
• 事実に基づいた中立的なトーンを使用します。値が有利であっても、「すばらしい」「超高速」「業界最高」「寛大」などの言葉は結論であり、仕様ではありません。
• コールトゥアクション、お客様の声、販売コピーの段落、説明のないスコア、裏付けのない比較、または装飾的な画像を値セル内に決して配置しないでください。
• 変動する値や外部から主張された値については、ソースと正確な検証日を明記します。所有者が不明な場合、テーブルは公開準備ができていません。

使用する投稿タイプ

フロントマターのpostTypesフィールドが以下の承認された使用法を決定します。含まれていることは、その投稿タイプがこの要素を必要とするか、または恩恵を受ける可能性があることを意味します。すべてのページがレイアウトを満たすために3つの事実を製造しなければならないわけではありません。

QAチェックリスト

• テーブルは明確に識別された1つの対象を説明しており、複数の選択肢がスペック表として偽装されていない。
• キャプションは対象とテーブルの範囲の両方を示している。
• すべてのプロパティは正確で標準的なラベルを使用し、すべてのセルは1つの値を含んでいる。
• 数値には一貫した単位、修飾語、範囲、寸法が含まれている。
• 空白のセルはなく、Unknown、Not applicable、Not availableは定義された意味でのみ使用されている。
• 主張は名前付きの主要ソースと一致し、変動する事実は正確な検証日を示している。
• 公開出力は、画像やビジュアルグリッドではなく、ネイティブの<table>、<caption>、行ヘッダー、データセルを使用している。
• フィールドリファレンスバリアントは列ヘッダーを含み、すべてのヘッダー関係を保持している。
• テーブルは狭い幅、200%ズーム、キーボードナビゲーション、スタイル無効で機能する。
• 色、アイコン、略語、ツールチップが値を理解する唯一の方法ではない。
• 可視の事実と該当するSchema.orgプロパティが完全に一致している。
• プロモーション主張、解釈、コールトゥアクション、長い散文はテーブルの外側にある。
• 要素はプレイブックの優先順位ルールに従い、選択された投稿タイプはそのコンテンツ契約に要素を含んでいる。