定義ボックス：フォーマット、ルールと例

定義ボックスは、記事で詳しく説明する前に、ページの主要用語に対して正確で境界のある説明を1つ提供します。これは開始要素です：再利用可能なコンテンツコンポーネントであり、読者が例や利点、背景から中心的な用語を推測する必要がないように、記事の前半に表示されます。

この実際の例が完全な要素であり、ページ下部の定義の teaser ではありません。タイトルはオプションですが、本文は必須です。以下の制作契約は、要素がいつ属するか、各フィールドの意味、同じコンテンツが公開システム間でどのようにマッピングされるかを決定します。

この要素が重要な理由

読者が情報ページを最初から最後まですべての単語を順番に読むことはほとんどありません。読者はタイトル、冒頭の行、見出し、視覚的に区別されたブロックをスキャンして、ページが自分の質問に答えているかどうかを判断します。導入段落に埋もれた定義は、読者がコンテキスト、主張、場面設定から回答を分離する作業を強います。ボックスはその作業を取り除きます：その境界が「これが定義です」と示します。

その境界により、定義は安定したアドレス可能な位置も得ます。編集者はどこでレビューすべきかがわかり、テンプレートはどこでレンダリングすべきかがわかり、将来の改訂でも読者や品質チェックが複数の冒頭段落を検索する必要がありません。一貫した配置はライブラリ全体で重要です。なぜなら、同じ情報提供の役割がページごとに予測不可能に移動すべきではないからです。

機械抽出可能性とは、ソフトウェアが意味を失うことなくコンテンツユニットを分離できる能力です。タイトルと本文を持つ型付き定義は、独立して索引付け、比較、引用、変換できます。自由文の中でたまたま用語を定義している文は、周囲の散文に溶けてしまいます。ソフトウェアは定義の開始位置と終了位置、そして先行する主張がその一部かどうかを推測しなければなりません。要素作成ルール に従うことで、視覚的デザインが変更されても意味的アイデンティティを維持できます。

表現はボックスなしでも機能する必要があります。スタイリングは人のためにコントラストを生み出しますが、自己完結した主語、動詞、区別する意味が機械のための抽出可能性を生み出します。「It is a method for improving them（それはそれらを改善する方法です）」は段落から切り離すと機能しません。「Content pruning is the process of removing, consolidating, or updating pages that no longer serve a useful search or business purpose（コンテンツプルーニングとは、有用な検索またはビジネス目的を果たさなくなったページを削除、統合、または更新するプロセスです）」は機能します。

使用するタイミング

ページが1つの用語を中心に構成されており、その用語が短い文で正確に定義できる場合に定義ボックスを使用します。用語集用語（glossary-term）およびWhat-is-X形式では必須です。また、診断や症状に関するコンテンツでも必須です。読者は原因、検査、治療法を検討する前に、名前のついた状態が何かを知っている必要があります。

症状主導のページやハウツーページでは、この要素をほとんど使用しません。1つの短い定義がタスクに必要な真の曖昧さを解決する場合にのみ追加します。例えば、「キーワードカニバリゼーションを修正する方法」というタイトルのガイドでは、診断によって適用する修正が決まるため、ステップの前にキーワードカニバリゼーションを定義する場合があります。「タイトルタグを変更する方法」というタイトルのガイドでは、対象読者と冒頭の指示ですでにオブジェクトが明確であるため、タイトルタグを定義するボックスは必要ありません。

以下の場合には定義ボックスを使用しないでください：

• 幅広い紹介、歴史、利点の主張、または主題の重要性の説明。これらの文章は記事を展開するものであり、用語を定義するものではありません。
• ページの要約。要約は複数の結論をまとめるものですが、定義は1つの用語の意味を示します。
• 「AmICitedは可視性を向上させる最も簡単な方法です」のような製品の約束。これはポジショニングであり、検証可能な定義ではありません。
• 警告、注意事項、前提条件、またはヒント。テーマ的に同じ色のパネルのように見えても、コミュニケーションの役割が異なります。
• 記事の途中で導入される二次的な用語。その用語は最初に登場する文で定義するか、十分な扱いに値する場合は独自のページを与えます。
• 権威が明確さの代わりとなる引用。帰属表示が必要な場合は、周囲の散文で正式な定義を帰属表示し、ボックスは直接的な声明として読みやすく保ちます。

よくある惜しい例は「定義への導入」です：「顧客解約率はサブスクリプションビジネスにとって最も重要な概念の1つであり、それを理解することで成長を変革できます。」これは概念が重要であると言っていますが、それが何であるかを決して述べていません。ボックスは空の場面設定を正確にすることはできません。

配置する場所

配置は優先順位を表します。定義ボックスは、導入段落または短い紹介の直後、最初のコンテンツブロックとして配置します。導入部は読者がなぜページにいるのかを確立し、ボックスは原因、例、利点、ステップ、比較がそれに依存する前に意味を確定します。

導入部と定義の間にナビゲーション、目次、重要ポイント、画像ギャラリー、またはプロモーションの行動喚起を配置しないでください。これらのブロックは、読者が用語の意味を受け取る前に無関係な資料を通過させることになります。パンくずリストとページヒーローはテンプレートのクロームであり、作成されたコンテンツではないため、導入部の前にあっても構いません。

1ページに1つの定義ボックスを使用します。このルールは、コンポーネントがページの主要な定義対象を識別するために存在するためです。2つのボックスは競合する2つの主要用語を作り出し、抽出を曖昧にします。両方の用語が本当に主要な場合は、主題を2つのページに分割し、散文でそれらを結び付けます。2つ目の用語が従属的である場合は、2つ目の標準的な回答としてスタイリングするのではなく、インラインで定義します。

ダイレクトアンサーブロック は、異なる主要な質問に回答する場合にのみ定義と共存できます。診断ページでは、定義が症状が何であるかを述べ、ダイレクトアンサーが推奨される最初のアクションを述べることがあります。ページの主要な質問が「Xとは何か？」である場合、ダイレクトアンサーと定義は同じ回答です。1つの定義ボックスに統合します。隣接するバージョンは単に表現を繰り返し、抽出を競合させます。

構造

要素には2つの作成領域と1つの構造的関係があります。スクリーンショットは、説明テキストを画像に埋め込まずにレンダリングされた要素を示す必要があります。以下の凡例は、デザインが変更されても選択可能、アクセス可能、維持可能な状態を保ちます。

レンダリングされた凡例

1. オプションのタイトル： 通常は「Xとは何か？」です。正確な用語を特定し、2つ目の主張を追加してはいけません。
2. 必須の本文： 用語を命名し、有用なカテゴリに配置し、それを区別するものを述べる、1つの自己完結型の定義。
3. 開始位置： ボックスは導入部に続き、最初の説明セクションの前に位置します。この関係はフィールドではありませんが、契約の一部です。

境界線、背景、パディング、アイコンの処理、タイポグラフィはレンダラーに属します。作成者は意味を提供し、視覚的なトークンは提供しません。すべての装飾スタイルが削除されても、要素は理解可能でなければなりません。

デザイン例

ギャラリーは、異なる意味タイプを発明するのではなく、サポートされているコンテンツのバリエーションをカバーします。各キャプチャは可能な限り同じ定義を再利用し、レビュー担当者が無関係なコピーを比較するのではなく、タイトルの処理、本文の折り返し、ビューポートの動作を判断できるようにする必要があります。

タイトルあり： 用語が馴染みがない、曖昧である、略語である、または正確なページタイトルと異なる場合の推奨バリアント。

タイトルなし： ページ見出しと直前の導入部で主題が明白な場合に許可されます。本文は依然として用語を命名する必要があります。タイトルを省略しても、「それ」などの代名詞で主語を置き換えることは決して許可されません。

最大長： レンダラーは完全な本文を折り返します。編集上の最大値のコピーに対応するために、切り捨て、折りたたみ、スクロール、またはフォント縮小をしてはいけません。

狭いビューポート： タイトルと本文は順序、読みやすい行長、可視の境界を保持します。アイコンがテキストの横に移動することに意味が依存してはいけません。

パラメータ

パラメータはコンテンツとプレゼンテーションを分離します。その制限により、定義がページ間で比較可能になり、コンポーネントが汎用のコールアウトになるのを防ぎます。

定義ボックスパラメータ

レンダラーは索引付けのために用語を派生させる場合がありますが、作成者はその派生フィールドが表示されることに依存する本文を決して書いてはいけません。コピーされた定義はその主題を明示的に命名する必要があります。

構文とコード例

3つの形式すべてが同じタイトルと本文を持ちます。ポータブルMarkdownディレクティブが標準的な作成形式であり、HugoとWordPressはアダプターです。例は意図的に同一の表現を使用しており、移行テストが外観だけでなく値を比較できるようにしています。

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

:::definition
## What is content pruning?

Content pruning is the process of removing, consolidating, or updating pages that no longer serve a useful search or business purpose.
:::

最初の見出しがtitleにマッピングされ、それ以降のすべてがbodyにマッピングされます。タイトルなしのバリアントでは見出しを省略しますが、用語は本文に残します。

Hugoショートコード

{{< callout type="note" title="What is content pruning?" >}}Content pruning is the process of removing, consolidating, or updating pages that no longer serve a useful search or business purpose.{{< /callout >}}

サイトは可視的なHugo処理のために既存のコールアウトレンダラーを再利用します。定義契約は依然として型付きポータブルソースから来ます。ここでのnoteはレンダリングアダプターであり、通常のメモを定義ボックスに入れる許可ではありません。

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

[definition title="What is content pruning?"]Content pruning is the process of removing, consolidating, or updating pages that no longer serve a useful search or business purpose.[/definition]

WordPress実装は同じフィールドをカスタムブロックとして公開する場合があります。保存される値はtitleとbodyのままです。エディターコントロール、色、スペーシングはプレゼンテーション設定であり、定義の意味を変更してはいけません。

例

これは良好な例です。用語を命名し、状態を特定し、区別する結果を述べているからです。すべての単語を共有するページのペアが競合するとは主張していません。「同じ検索意図」というフレーズが必要な境界を提供しています。本文はタイトルなしでも有用であり、そのまま引用するのに十分短いです。

これは不適切な例です。キーワードカニバリゼーションを決して定義していないからです。重要性、対象読者、緊急性、曖昧な影響を提供していますが、カテゴリや区別する条件はありません。「最も重要なものの1つ」を「複数のページが同じ検索意図を競合する状況」に置き換えることで、プロモーションが意味に変わります。

2つ目の不適切なパターンはボックスの過負荷です：定義の後に原因、5つの例、警告、推奨ツールが続きます。最初の文が正確であっても、余分な資料が安定した境界を破壊します。定義を維持し、原因と例は次のセクションに、警告は正しい要素に、推奨は読者が行動できる時点に移動します。

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

定義ボックスは自動的にスタンドアロンのSchema.orgエンティティを作成しません。通常の記事では、そのテキストは包含するArticleまたはTechArticleの一部のままです。用語集ページでは、サイトがそのスキーマポリシーを採用している場合にのみ、公開実装が用語と定義を適切な語彙にマッピングすることがあります。DefinitionBoxタイプを発明しないでください。Schema.orgには存在しません。

同様に、ボックスが重要に見えるという理由だけで、本文をJSON-LD に複製しないでください。スキーママークアップ はページを真実に説明する必要があり、可視の散文を無関係なプロパティに複製することは、より強い意味ではなくノイズを生み出します。スキーマプロパティが設定される場合、その値は可視の定義と実質的に一致し、それと共に更新される必要があります。

要素にインタラクティブなARIAロールは必要ありません。タイトルが本文の前に来るように、通常のドキュメント順序でラベル付き領域または意味的コンテナとしてレンダリングします。静的な定義は緊急または新しく到着した情報ではないため、role="alert"を使用しないでください。ブロックが定義であることを示す唯一の信号として色やアイコンを使用しないでください。タイトルが見出しとして実装される場合、そのレベルはページ階層に従う必要があります。ソースの##はフィールドマッピングの慣例であり、無効な見出しジャンプを作成する指示ではありません。

キーボード操作は通常の読み取り動作です。ボックス自体はフォーカス可能ではありません。内部のリンクは通常のリンクセマンティクスに従い、説明的なアンカーが必要です。スクリーンリーダーの出力は、画面に表示されるのと同じタイトル→本文の順序を保持する必要があります。

作成ルール

定義はその利点を書く前に書きます。用語自体から始め、次に「is」「means」「occurs when」などの連結動詞を使用します。最も近い有用なカテゴリと、その用語を隣接する概念から区別する特性を述べます。この順序は、区別のないカテゴリは広範であり、カテゴリのない区別は読者がその用語がどのような種類のものかわからなくなるために存在します。

本文はスペースを含めて最大約300文字に保ちます。1文を推奨します。必要な境界が最初の文で明確に表現できない場合にのみ、2番目の短い文が許容されます。この制限は編集上のものであり、句読点を圧縮したり、冠詞を削除したり、節を詰め込んだりするためのものではありません。正確さにより多くのスペースが必要な場合は、正確な核をボックスに入れ、その直後に条件を付け加えます。

中立的で宣言的なトーンを使用します。「important」「powerful」「game-changing」「you need to know」および類似の判断を避けます。「content optimization is the act of optimizing content（コンテンツ最適化とはコンテンツを最適化する行為です）」のような循環定義を避けます。略語がページの用語でない限り、最初の使用時に略語を展開します。ページタイトルに表示されるのと同じ標準名を使用します。

以下のものを本文内に決して配置しないでください：

• 複数の主要用語または関連用語のリスト。
• 利点、歴史、原因、症状、例、ステップ、製品の売り込み、または行動喚起。
• テーブル、画像、動画、フォーム、ボタン、脚注、またはネストされたコールアウト。
• 裏付けのない最上級表現、捏造された統計、または段落単位の証拠を必要とする主張。
• 2つ目の見出し、箇条書きリスト、またはブロック引用。
• 意味が直前の導入部に依存する代名詞。

1つの帰属リンクは例外であり、目標ではありません。法的、科学的、または標準ベースの定義が名前付きソースに依存する場合にのみ使用します。拡張された引用やソース間の不一致は通常の散文に記載し、読者が1つの争われている表現を普遍的な定義と誤認せずに条件を見極められるようにします。

使用する投稿タイプ

postTypesフロントマターは登録された結合を記録します。以下の表はそれらの結合を編集ルールに変換します。診断/症状スタイルおよび症状主導の形式はここでは使用パターンとして説明されていますが、現在の正規レジストリにないため、個別のプレイブック投稿タイプとしてはリンクされていません。

投稿タイプの要件

診断または症状スタイルのページでは、常にボックスを使用し、症状、原因、重症度、または治療法の前に配置します。症状主導のページでは、症状名が本当に短く安定した定義を持つ場合にのみ使用します。ボックスが単にタイトルを言い換えるだけの場合（「遅いウェブサイトとは遅いウェブサイトのことです」）、省略し、散文で診断の閾値または観察可能な問題から始めます。

QAチェックリスト

レビュー担当者は外観よりも意味をチェックします。磨かれたボックスに曖昧な導入が含まれている場合、依然として失敗した定義です。

• 1つの主要用語： ページとボックスが正確に1つの主要な概念を定義している。
• 正しい位置： ボックスが導入部後の最初の作成コンテンツブロックであり、その前に目次、重要ポイント、ギャラリー、プロモーションが挿入されていない。
• 1回の出現： 2つ目の定義ボックスが標準的な回答と競合していない。
• 実際の定義： 本文が用語が何であるか、または状態がいつ存在するかを述べており、単に用語がなぜ重要かを述べているだけではない。
• 自己完結型の表現： 本文がその主題を命名し、近くの散文やスタイリングなしでコピーしても意味を成す。
• 正確性： カテゴリ、区別する特性、および必要な境界が正確である。表現が過度に一般化していない。
• 長さ： 本文が約300文字以内であり、圧縮されることなく読みやすい。
• クリーンな内容： 利点、歴史、例、ステップ、製品の主張、メディア、テーブル、またはネストされた要素が内部にない。
• ダイレクトアンサーの判断： ページが「Xとは何か？」を尋ねる場合、定義ボックスが唯一のダイレクトアンサー要素である。両方の要素が出現する場合、明確に異なる質問に回答している。
• アクセシブルなセマンティクス： タイトルが本文の前に来る、見出し階層が有効である、色が唯一の識別子ではない、アラートロールや不要なフォーカスターゲットがない。
• ポータブルなパリティ： Markdown、Hugo、WordPressのマッピングが同じタイトルと定義を保持している。
• 構造化データの抑制： スキーマ値が可視のコピーと一致し、発明されたSchema.orgタイプが使用されていない。
• スクリーンショットステータス： 名前付きファイルが存在するまで、コメントはレンダリングしないキャプチャ指示のままである。存在しない画像パスが画像として参照されていない。

FAQ

アカデミーテンプレートは、このページの[[faq]]フロントマターに保存された5つのレビュー済み質問をレンダリングします。これらは、必要性、ダイレクトアンサーとの共存、リンクと引用、長さ制限、および1ページ1ルールをカバーしています。