ソースと参考文献：引用ルール

ソースブロックは、ページの事実に基づく主張をトレース可能にし、読者や回答エンジンが検証・引用できるようにする、末尾に配置された順序付きレコードです。

この実例は、最小限の完全なエントリ（リンク付きタイトル、発行元、公開日、アクセス日）を示しています。URLは長い生の文字列としてではなく、タイトルの背後に配置されています。ブロックを別のパブリッシングシステムに適応させる場合は、共通の要素作成ルール を適用してください。

この要素が重要な理由

読者はすべての主張を同様に扱いません。医学的推奨、金融比較、パフォーマンス数値は、単純な機能説明よりも大きなリスクを伴います。完全な参考文献は、誰がエビデンスを公開したか、それがいつ最新であったか、そしてそれが主張を裏付けているかを示します。また、事実が変更されたときに編集者にメンテナンスの痕跡を与えます。

末尾に10個の評判の良いリンクを並べても、各リンクがどの文を裏付けているかは証明できません。インライン引用がローカルな接続を作り出し、末尾のリストが完全なレコードを保持します。これらが連携することで、懐疑的な読者が推測することなく主張からエビデンスへと移動できます。

機械による抽出可能性とは、ソフトウェアがページのデザインの外側で境界のあるレコードを識別できることを意味します。一貫したフィールドは、タイトル、発行元、URL、公開日、アクセス日を公開します。検索に対してドキュメントやパッセージを選択するソフトウェアである検索システムは、日付、発行元、主張を比較できるようになります。

回答エンジンの結果では、複数の候補ページが同様の記述を行う場合があります。一次資料を引用し、エビデンスの日付を記録したページは、検索システムがそれ以外では推測しなければならない検証作業の一部を完了します。これは選択を保証するものではありませんが、監査可能なエビデンスチェーンを生成します。

この原則は、サイトのE-E-A-Tとエンティティの基礎 と一致しています。可視の出所は信頼をサポートし、一貫した発行元とタイトルフィールドはエビデンスの背後にあるエンティティの識別に役立ちます。

使用すべき場合

情報提供型またはエビデンス主導型のページが、読者が合理的に検証できる外部の事実に依存する場合は常にソースブロックを使用してください。これには、標準規格に由来する定義、統計、研究結果、法律、ポリシー、市場の主張、製品比較、歴史的記述、引用、公開されたエビデンスに基づく推奨が含まれます。健康、金融、法律、保険、安全性、その他規制対象または重大な影響を及ぼす分野では明示的に必須です。

インラインリンクがすでにある場合でも、記事に複数のソースが含まれている場合はソースブロックを使用してください。ブロックはレビュー可能なインベントリを作成します。ケーススタディでは、内部測定値と外部ベンチマークを区別してラベル付けし、自社データが独立した調査と誤認されないようにしてください。

外部で検証可能な主張のない意見記事を装飾するためにソースブロックを追加しないでください。ナビゲーション、おすすめの読み物、関連コンテンツ、未使用の参考文献エントリは属しません。ソースはページをサポートするものであり、「さらに読む」は単にトピックを拡張するものです。

微妙なケースには明確なルールが必要です：

• 単一の事実に基づく主張： インラインで引用してください。1エントリだけの閉じるブロックは、規制対象分野でない限り任意です。
• ツールのリスト： ベンダーのホームページはリンク先であってエビデンスではありません。特定の主張をサポートする場合にのみドキュメントを含めてください。
• 引用文： インラインで引用し、完全な末尾のレコードを含めてください。
• 一般的な知識： 「1週間は7日ある」など、対象読者が異議を唱えないであろう事実は引用しないでください。正確な解釈、測定値、ポリシー、または争点のある境界については引用してください。
• 自社製品のコピー： テスト可能な機能については公式ドキュメントにリンクしてください。自社のマーケティングページを優位性の証明として引用することで、独立性の外観を作り出さないでください。

配置場所

ソースブロックはFAQの後にある最後の編集ブロックです。サイト全体のクローム、法的通知、またはテンプレートレベルの変換コントロールのみが後に続くことができます。この位置により、リストが完成した記事をサポートし、レビュー担当者に1つの予測可能な監査場所を提供します。

唯一のリストをサイドバーに配置しないでください。サイドバーはモバイルレイアウト、印刷、フィード、リーダーモード、抽出テキストから消える可能性があります。ブロックを関連コンテンツカード、フォーム、無関係なコールトゥアクションから離して、エビデンスの境界が明確になるようにしてください。

インライン引用は主張の箇所に残ります。閉じるブロックはエビデンスをそれがサポートする文から遠ざけるのではなく、レコードを完成させます。FAQの回答が新しい事実に基づく主張を導入する場合は、その回答内で引用し、閉じるブロックでソースを繰り返してください。FAQが既にサポートされているコンテンツを再掲するだけの場合は、重複エントリを追加するのではなく既存のソースを再利用してください。

アナトミー

レンダリングされた凡例は、アセットが置き換えられた場合もページに残ります：

1. ブロック見出し： 公開基準が「参考文献」を要求しない限り、「ソース」を使用します。
2. エントリ番号： 各レコードに音声、印刷、抽出を通じて安定した識別子を提供します。
3. タイトルとURL： 説明リンクテキストとしての正確なタイトルで、引用されたバージョンに解決されます。
4. 発行元： 素材を担当する組織。
5. 公開日： ソースが発行されたか実質的に更新された日付。
6. アクセス日： 著者がソースと主張を検証した日付。
7. ブロック境界： 1つの順序付きリスト。見出しとリストがセマンティクスを保持します。

この凡例をスクリーンショットに焼き付けないでください。画像は外観を文書化し、番号付き凡例はコンテンツ契約を定義します。

デザイン例

バリエーションは、5フィールドのエントリ契約を変更せずに、密度と利用可能なメタデータを変更します。

標準ウェブソース： 標準、ドキュメント、レポート、ウェブページを引用する記事のデフォルト。各タイトルはリンクされており、発行元と両方の日付は表示テキストとして残ります。

混合ソースタイプ： DOIは研究用の永続的な識別子です。論文にはこれを使用し、レポートやドキュメントには正規URLを使用してください。巻号、号、バージョン詳細を追加する際は共通のフィールド順序を維持してください。

長いタイトル： 自然に複数行に折り返します。2つの異なるドキュメントが区別できなくなるまでタイトルを切り詰めないでください。

モバイル： エントリは、水平スクロールなしの単一の順序付きリストのままです。長いURLはタイトルの背後に留まり、メタデータはテキストを縮小せずにその下で折り返します。

パラメータ

パラメータ契約は、著者が提供するエビデンスとレンダラーの動作を分離します。以下の「ソース」は、コンポーネントが値を取得する場所を意味します。

5つのエントリフィールドすべてが必須です。発行元のないタイトルは責任を隠し、URLのない発行元は検査できません。2つの日付は、素材がいつ最新であると主張したか、そしていつ検証されたかを示します。公開日も更新日も存在しない場合は、n.d. と記入してください。時間に敏感な主張については、日付のないエビデンスを置き換えるか、主張を削除してください。

構文とコード例

各表記は同じフィールドと順序を持ちます。コンポーネントはソースデータを変換してもかまいませんが、脆弱なページマークアップから発行元や日付を推測してはなりません。

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

:::sources{heading="ソース"}
1. [citation — Schema.org Property](https://schema.org/citation) — Schema.org. 公開日 2026-03-19. アクセス日 2026-08-27.
2. [Understanding SC 2.4.4: Link Purpose (In Context)](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html) — W3C Web Accessibility Initiative. 更新日 2026-05-18. アクセス日 2026-08-27.
:::

Hugoショートコード

{{< sources heading="ソース" >}}
1. [citation — Schema.org Property](https://schema.org/citation) — Schema.org. 公開日 2026-03-19. アクセス日 2026-08-27.
2. [Understanding SC 2.4.4: Link Purpose (In Context)](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html) — W3C Web Accessibility Initiative. 更新日 2026-05-18. アクセス日 2026-08-27.
{{< /sources >}}

これはポータブル契約であり、このショートコードが存在するという主張ではありません。レンダラーが実装するまでは、ネイティブの見出しと順序付きMarkdownリストを使用してください。

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

[sources heading="ソース"]
[source title="citation — Schema.org Property" publisher="Schema.org" url="https://schema.org/citation" publication_date="2026-03-19" accessed_date="2026-08-27"]
[source title="Understanding SC 2.4.4: Link Purpose (In Context)" publisher="W3C Web Accessibility Initiative" url="https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html" publication_date="2026-05-18" accessed_date="2026-08-27"]
[/sources]

WordPressブロックはフォームコントロールを公開してもかまいませんが、見出しとネイティブの順序付きリストをレンダリングし、エクスポートされたコンテンツに日付を保持する必要があります。

例

良い例：完全、属性付き、日付付き

ソース

1. 「Understanding Success Criterion 2.4.4: Link Purpose (In Context).」 W3C Web Accessibility Initiative. 更新日 2026年5月18日. アクセス日 2026年8月27日.
2. 「citation — Schema.org Property.」 Schema.org. 公開日 2026年3月19日. アクセス日 2026年8月27日.

これが機能する理由は、レビュー担当者が各ドキュメント、発行元、ソース日付、検証日付、リンク先を識別できるためです。エントリは一次資料であり、最初の出現順に並べられているため、インライン番号と末尾のレコードを調整しやすくなっています。

悪い例：ドメインの山

参考文献

• Google
• あるアクセシビリティブログ
• schema.org
• https://example.com/article?id=18492

これは、どのエントリもドキュメントや日付を識別していないため機能しません。「Google」は組織であり、エビデンスではありません。「あるアクセシビリティブログ」は発行元と品質ティアを隠しています。生のURLには使用可能なタイトルがなく、どのエントリも主張にマッピングされていません。各主張のエビデンスを選択し、インライン引用を追加し、すべての必須フィールドを記録することで修正してください。

インライン引用と末尾のソースリスト

読者がどのソースがそれを裏付けているかを知る必要がある場合は主張の箇所で引用し、ページがそのソースに依存している場合は完全な末尾のレコードを含めてください。ほとんどのエビデンス主導型ページでは両方が必要です。

インライン引用は、数値、引用文、研究結果、法律、ポリシー、争点のある主張、安全指示、時間に敏感な製品事実、またはソースに依存する結論に必要です。該当する文の中または直後に配置してください。1つの引用で無関係な主張のパラグラフをサポートすることはできません。

末尾のリストは、複数のソース、必須のインベントリ、または規制対象の主題に対して必要です。繰り返しの引用は1エントリとし、実質的に異なるバージョンは別のエントリとして扱います。

ソース品質ティア

品質とは主張に対する適合性であり、名声ではありません。記述を直接サポートできる最も適切な上位ティアを使用してください：

ティアはミスマッチな主張を救いません。規制当局の提出ページは臨床的な主張をサポートできず、研究論文は研究後にリリースされた機能を証明できません。ベンダーの価格ページは現在の価格を証明できますが、それが最高の価値を提供することを証明することはできません。

ソースが競合する場合は、違いを説明するスコープまたは日付を明記し、支配的な一次レコードを優先し、主張を絞り込んでください。解決できない場合は、エビデンスが競合していると述べてください。

リンク処理とソース消失

外部リンクはデフォルトで現在のタブに開いたままにします。HTTPSと正規URLまたは永続的URLを使用し、トラッキングパラメータ、セッション識別子、リダイレクトラッパーを削除してください。「ここをクリック」ではなくタイトルにリンクしてください。通常の編集上の引用に nofollow を追加しないでください。リレーションシップ値は、それらのリレーションシップを持つリンクのために予約してください。

製品が意図的に外部ソースを新しいタブで開く場合は、target="_blank" rel="noopener" を出力し、表示テキストまたはプログラム的に関連付けられた説明でユーザーに警告してください。noopener は、開かれたページが元のウィンドウへの参照を受け取るのを防ぎます。noreferrer は、サイトのプライバシーポリシーがリファラー情報の抑制を要求する場合にのみ追加してください。これは普遍的な編集上の引用要件ではありません。

公開前および定期レビュー時にすべてのソースを確認してください。デッドリンクとは、引用された素材に解決しなくなったURLのことです。デッドリンクが発生した場合：

1. 発行元が管理する代替、正規リダイレクト、新しいバージョン、DOI、または公式アーカイブを探してください。
2. 代替が同じ主張をサポートしていることを確認してください。動作するホームページは、欠落したレポートの代わりにはなりません。
3. URL、バージョンが変更された場合は公開日、アクセス日、そして新しいソースによって影響を受ける主張を更新してください。
4. 信頼できるアーカイブのみが正確なドキュメントを保存している場合は、アーカイブにリンクし、アーカイブ済みとラベル付けしてください。
5. エビデンスを回復できない場合は、ソースを置き換え、主張を再評価してください。適切なエビデンスが残っていない場合は、主張を削除するか条件付きにしてください。

異なる主張をする代替に古い引用を向けないでください。

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

ソースブロックは独立したSchema.orgエンティティを作成しません。これは、包含する Article、TechArticle、Report、またはその他の有効な CreativeWork の一部として残ります。Schema.orgの citation プロパティは、テキストまたは別の CreativeWork として参考文献を保持できます。構造化データが生成される場合、各真正の編集上の参考文献を citation にマッピングしてください。ナビゲーション、アフィリエイトリンク先、または単に関連する読み物を引用としてマークしないでください。

表示コンテンツと構造化データは一致している必要があります。JSON-LD（Linked DataのためのJavaScript Object Notation）は、存在しないソースを導入したり、表示上の修飾語を省略したりしてはなりません。表示リストやインラインリンクを置き換えることはありません。

アクセシビリティのためには、見出しの後に <ol> と <li> を使用してください。順序付きエントリは安定したアイテム数と識別子を提供します。ソースタイトルをリンクテキストとして使用し、発行元と日付は同じアイテムに保持してください。識別手段として色、ファビコン、ロゴのみを使用しないでください。

ネイティブリストでの role="list"、デフォルトでエビデンスを隠すインタラクティブアコーディオン、単純な1次元の参考文献シーケンスのためのテーブルは避けてください。リンクが新しいタブを開く場合、警告は視覚的および支援技術の両方で利用可能でなければなりません。キーボードフォーカスは可視のままでなければならず、長いタイトルはクリップや水平ページスクロールなしで折り返す必要があります。

作成ルール

正確なタイトルと認識可能な発行元名を使用してください。タイトル、発行元、公開日または更新日、アクセス日の順序を維持してください。著者、版、ページ、DOI、またはバージョンは、作品を識別するためまたは出版基準を満たすために必要な場合にのみ追加してください。

エントリは最初の出現順に並べてください。ただし、必須のスタイルが別の方法を指定する場合は除きます。同一のレコードは重複排除しますが、違いが主張に影響する場合は版やバージョンを別々に保持してください。

すべてのエントリは主張をサポートしなければならず、すべての重要な外部主張はエビデンスにマッピングされなければなりません。タイトルはリンク先と一致する必要があります。アクセス日は、リンク先とそのサポートがチェックされた日付を記録するものであり、CMSがページを保存した日付ではありません。

コールトゥアクション、アフィリエイトラベル、関連記事、エビデンスとして使用されていない推奨図書、著者経歴、方法論の散文、プロモーション説明、星評価、またはソースが「素晴らしい」かどうかについてのコメントをブロック内に配置しないでください。ソースの制限は、関連する主張の横または方法セクションで説明してください。閉じるブロックはエビデンスのインベントリとして維持してください。

任意の最大数はありません。レポートでは数十のレコードが必要になる場合があります。20エントリを超える場合は、安定した参照番号を使用し、狭い画面での折り返しをテストしてください。1つの記事のエビデンスを無関係なサイドバーに分割しないでください。

使用する投稿タイプ

postTypes フロントマターは、以下の9つのエビデンス主導型ページタイプへの機械可読な結合を作成します。表示テーブルは配置と要件の強度を追加します。

製品、カテゴリ、ユースケースページでも、事実に基づく主張を行う場合はそれを引用しますが、ページが主に取引用であり自社の機能情報のみに依存する場合、末尾のリストは条件付きです。すべての投稿タイプにおいて、健康、金融、法律、その他の規制対象コンテンツは、長さに関わらず完全なソースブロックを必要とします。

QAチェックリスト

• すべての外部検証可能な重要な主張に適切なソースがある。
• 正確な帰属が必要な主張には、主張の箇所にインライン引用がある。
• すべてのインライン引用が1つの完全な末尾エントリに明確にマッピングされている。
• すべての末尾エントリがページで実際に行われた少なくとも1つの主張をサポートしている。
• 各エントリにタイトル、発行元、正規URL、公開日または n.d.、正確なアクセス日が含まれている。
• 公開日が著作権フッター、検索スニペット、URLパターンから推測されていない。
• アクセス日は、一括CMS移行日ではなく実際の検証を記録している。
• ソース品質が主張に一致している。ベンダー素材が優位性の証明に使用されていない。
• 利用可能で使用可能な場合、二次的な報道よりも一次または支配的な公式素材が優先されている。
• 研究の主張は、解釈に影響を与える母集団、方法、日付、限界を保持している。
• 競合するエビデンスは、黙って省略されるのではなく、開示され、範囲が示され、または解決されている。
• タイトルは説明リンクテキストであり、リンク先と一致している。
• 外部URLはHTTPSを使用し、トラッキングパラメータを省き、引用されたバージョンに解決される。
• リンクは、文書化された製品ルールが別の方法を指定しない限り、現在のタブで開く。
• 新しいタブのリンクは noopener を使用し、新しいタブが開くことをユーザーに警告している。
• デッドまたはリダイレクトされたリンクは、サポートされる主張を気付かれずに変更することなく修正された。
• ブロックはメインドキュメントフロー内の見出しと順序付きリストである。
• ブロックはFAQ後の最終編集セクションであり、関連コンテンツやコールトゥアクションと混在していない。
• 表示上の参考文献とSchema.orgの citation 値が一致している。
• ブロックは読み取り可能で、キーボードアクセシブルで、狭い画面で水平ページスクロールがない。

FAQ

すべての記事にソースブロックが必要ですか？

情報提供型またはエビデンス主導型のコンテンツで、外部の事実に依存するものには使用してください。自社の機能説明のみを含む短い製品ページは閉じるブロックを必要としない場合がありますが、各事実に基づく主張には適切なソースが必要です。健康、金融、法律、その他の規制対象コンテンツには常に必要です。

ソースブロックはインライン引用を置き換えますか？

いいえ。読者がどのソースがその正確な記述を裏付けているかを知る必要がある場合、主張の箇所にインライン引用を配置してください。閉じるブロックは完全な参考文献レコードとページレベルのエビデンス一覧を提供しますが、離れた主張とソースの関係を明らかにするものではありません。

ソースに公開日がない場合はどうすればよいですか？

公開日を n.d. と記録し、正確なアクセス日を含めてください。日付を捏造したり、フィールドを省略したりしないでください。時間に敏感な主張については、日付のある代替ソースを見つけるか、主張を削除してください。日付のないページは情報がいつ最新であったかを確定できないためです。

ベンダー素材をソースブロックに含められますか？

はい、ベンダーが管理する主張（文書化された機能、価格、リリースノート、契約条件など）については可能です。ただし、ベンダー素材を自社製品が最良、最安全、最速、または最も効果的な選択肢であるという独立した証拠として使用してはなりません。

外部ソースリンクは新しいタブで開くべきですか？

通常のリンクはデフォルトで現在のタブに開いたままにし、読者がナビゲーションを制御できるようにしてください。製品が意図的に新しいタブを開く場合は、target="_blank" に rel="noopener" を使用し、新しいタブが開くことを視覚的またはプログラム的に関連付けられた警告として提供してください。

ソース

1. 「citation — Schema.org Property.」 Schema.org. 公開日 2026年3月19日. アクセス日 2026年8月27日.
2. 「Understanding Success Criterion 2.4.4: Link Purpose (In Context).」 W3C Web Accessibility Initiative. 更新日 2026年5月18日. アクセス日 2026年8月27日.
3. 「Technique G201: Giving Users Advanced Warning When Opening a New Window.」 W3C Web Accessibility Initiative. 更新日 2026年5月18日. アクセス日 2026年8月27日.