Reviewed-byブロック：専門家レビューとクレデンシャルルール

Reviewed-byブロックは、ページを独立して確認した資格のある人物を特定し、確認した主張を明記し、そのレビューが行われた日付を記録します。これは、装飾的な信頼バッジではなく、完了した編集アクションの証拠です。

この見本は4つの質問に答えます：誰がページをレビューしたか、その人物がなぜ資格があるか、レビューがいつ行われたか、レビューが何をカバーしたか。最後の文は、一人のレビュアーがページ全体を保証すると主張するのではなく、役割と関係性を明確にします。

この要素が重要な理由

読者は、技術的、医療的、法的、財務的、または統計的な主張を自分で検証できない場合、可視的な専門性をショートカットとして使用することがよくあります。名前のあるレビュアーは不確実性を減らすことができますが、それは属性が異議を唱えられるほど具体的である場合に限ります。「専門家レビュー済み」は証拠なしに信頼を求めます。名前、関連する資格、日付、限定されたスコープにより、読者はレビューが自分が頼ろうとしている主張に合致するかどうかを判断できます。

心理効果は両刃の剣です。イニシャルの羅列は権威のハロー効果を生み出す可能性があります。読者は、レビュアーが製品をテストし、すべての推奨を承認し、将来の更新に対する責任を受け入れていると想定するかもしれません。ブロックは、実際のレビューイベントとその限界を説明することで、そのような過大解釈を防がなければなりません。

機械による抽出可能性により、ソフトウェアは周辺の散文から推測することなく、レビュー関係を分離できます。型付きブロックは、コンテンツシステムにレビュアーID、資格、レビュー日付、スコープの安定したフィールドを提供します。検索エンジン、AIエージェント、シンジケーションフィード、アクセシビリティツール、移行スクリプトは、レビュアーと著者、レビュー日付と修正日付、検証済みスコープとページの残りの部分を区別できます。

目的に応じて要素の書き方ルール に従ってください。独立した専門家レビューを主張する役割を持つ任意の文章は、見出しや視覚スタイルに関わらず、この要素を使用します。たまたま2つの名前を含む著者行は、異なる責任を保持していないため、同等ではありません。

使用すべき場合

識別可能な専門家が意味のあるセカンドパーソンチェックを完了し、もっともらしいエラーが重大な結果をもたらす場合に、ブロックを使用します。

• 健康および安全コンテンツ： 資格のある臨床医または安全スペシャリストが、自身の能力範囲内で特定の主張、禁忌、エスカレーションアドバイス、または手順を確認します。
• 法律、規制、財務コンテンツ： 関連する専門家が、管轄権、発効日、前提条件、計算、および一般的な情報と個別化されたアドバイスの境界線を確認します。
• 技術ドキュメンテーション： エンジニアまたは製品スペシャリストが、クリーンまたは代表的な環境で、コマンド、バージョンサポート、前提条件、期待される結果、および復旧手順を検証します。
• リサーチおよび統計： 方法論者、アナリスト、またはドメイン専門家が、定義、サンプリング、変換、計算、制限、および結論がデータから導き出されているかどうかを確認します。
• 意思決定コンテンツ： テーマ専門家が、レビュー、バイイングガイド、またはコストガイドにおいて、それらの主張が執筆者の能力範囲外にある場合に、評価基準と事実に基づく主張を確認します。

トリガーはトピックの深刻さだけではなく、完了したレビューです。専門家がメールにCCされた、引用を提供した、一般的なトピックを承認した、または以前のバージョンをレビューしたという理由だけで、ページがブロックを得ることはありません。コンサルテーションは記事に情報を提供することもありますが、コンサルテーションは、その人物が関連する最終資料を受け取り、記載されたスコープを確認し、所見を返し、属性を承認しない限り、独立したレビューではありません。

該当しないケースには、文法編集、自己レビュー、カスタマーテストモニアル、ソース引用、免責事項、および管理上の承認が含まれます。いずれも専門家による検証を証明するものではありません。役職の権限は資格ではありません。CEOは、税務、投与量、または統計の主張を自動的に検証する資格があるわけではありません。

レビューが証明できない場合はブロックを使用しないでください。「専門家がレビューしました」という属性のない行は、責任者、日付、またはスコープのない検証可能な信頼主張を作り出すため、沈黙よりも悪質です。

配置場所

プライマリのreviewed-byブロックは、出典クラスター内の著者属性とフレッシュネススタンプ の直下、冒頭の回答またはイントロダクションの前に配置します。その理由は解釈上のものです。読者は、素材に依拠し始める前に、誰が作成し確認したかを知るべきです。モバイル、印刷、リーダーモード、シンジケートコピーでもこの順序を維持してください。

ブロックが冒頭に詳細すぎる場合は、コンパクトな行をそこに配置し、ソースブロック の直前にある1つの拡張ブロックにリンクします。両方とも同じレコードを使用し、日付とスコープが乖離しないようにします。

ブロックは著者バイオ と統合してはなりません。執筆とレビューは別々の役割として維持されなければならないからです。 testimonial、レビュースコア、製品オファー、価格、アフィリエイトボタン、信頼バッジストリップ、またはコールトゥアクションの内部または直接隣に配置してはなりません。これらの隣接要素は、事実に基づくレビューを推奨のように見せかける可能性があります。レビュー属性と商業的説得の間には、通常のコンテンツ境界を維持してください。

唯一の属性をフッター、ホバー状態、画像、アコーディオン、ポリシーページ、またはレビュアープロファイルに隠してはいけません。ページレベルのブロックは、イベントとスコープを明示しなければなりません。

構成要素

ブロックには7つの識別可能な領域があります：

1. 役割ラベル： 「Reviewed by」「Medically reviewed by」などの宣言されたバリアントを表示し、レビューと執筆を混同させません。
2. レビュアー名： その人物の公開されたプロフェッショナル名を使用し、利用可能な場合は安定したプロファイルにリンクします。
3. 関連資格： このレビュースコープをサポートする資格のみを含めます。
4. 所属または関係性： 読者が独立性を判断するのに役立つ場合、現在の組織または素材のパブリッシャーとの関係を特定します。
5. レビュー日付： 記載されたスコープの最新の完了したレビューを記録します。
6. スコープステートメント： 実際に確認された主張、計算、手順、またはセクションを明記します。
7. 役割の境界： 意味のある制限、利益相反、またはレビュアーが主題を作成、テスト、推奨していないことを明確にします。

これらのラベルはライブテキストで保持してください。注釈付きスクリーンショットはデザインを説明しますが、レビュー詳細の唯一の情報源になってはいけません。

デザイン例

バリエーションはラベルと証拠を変更しますが、コアとなるデータ契約は変わりません。

標準的な専門家レビュー

ドメインスペシャリストが規制された専門職ラベルなしで正確性と完全性を確認する場合に、「Reviewed by」を使用します。資格行に専門分野を表示し、レビューしたセクションを明記します。

医療レビュー

「Medically reviewed by」は、レビュアーが関連する現在の医療資格を持ち、レビューがその専門的範囲内にある場合にのみ使用します。資格は平易に表示し、異なる専門職を「Dr.」に圧縮してはいけません。

法務またはコンプライアンスレビュー

確認した管轄権、基準、または規制領域を明記します。法的正確性はスコープに依存するためです。ラベルは代理または個別化されたアドバイスを暗示してはいけません。

財務レビュー

レビュアーが税務、会計、貸付、保険、投資、または価格設定の主張を確認したかどうかを特定します。漠然とした「財務専門家」ラベルは関連性を確立しません。

技術レビュー

レビュアーが検証した製品、バージョン、環境、または実装領域を明記します。コマンドが実行された場合はその旨を記載し、机上レビューの場合はテストを暗示してはいけません。

方法論およびデータレビュー

確認した統計的またはドメインの方法（計算、分母、除外条件、推論の限界を含む）を明記します。実際に文書化されたピアレビュープロセスが行われない限り、ピアレビューと呼んではいけません。

コンパクト表示では、ラベル、名前、資格、日付に1行を使用し、その後に表示可能なスコープ文またはリンクを続けます。拡張表示では2つの短い段落を使用します。いずれもスコープを省略してはいけません。

パラメータ

ソースレコードは、事実を重複させることなく、コンパクト表示と拡張表示の両方をサポートしなければなりません。

credentials は、取得したすべての称号ではなく、関連する公開資格を記録します。scope は表示可能かつ必須であり、名前だけでは読者に何が確認されたかが伝わらないためです。プライベートなレビュー対応はコンポーネントの外部に保持してください。

シンタックスとコード例

ポータブルディレクティブが正規のものです。専用のHugoレンダラーが存在するまでは、すべての正規の事実を保持しながらcalloutアダプターを使用します。

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

:::reviewed-by{reviewType="technical" reviewerName="Alex Rivera" credentials="Senior platform engineer" affiliation="Northstar Cloud" reviewedOn="2026-08-27" display="expanded"}
## Technically reviewed by

Scope: installation commands, supported versions 4.2–4.4, Linux prerequisites, expected output, and rollback steps were checked in clean Ubuntu 24.04 and Debian 13 environments.

The reviewer verified the procedure but did not assess third-party plugins or custom infrastructure.
:::

最初の見出しが title に、最初の段落が scope に、残りの段落が roleBoundary にマッピングされます。

Hugoショートコード

{{< callout type="note" title="Technically reviewed by" >}}**Alex Rivera — Senior platform engineer, Northstar Cloud**  
Reviewed 27 August 2026. Scope: installation commands, supported versions 4.2–4.4, Linux prerequisites, expected output, and rollback steps were checked in clean Ubuntu 24.04 and Debian 13 environments.

The reviewer verified the procedure but did not assess third-party plugins or custom infrastructure.{{< /callout >}}

すべてのHugoパラメータは名前付きです。位置指定のcalloutタイプと名前付きの title パラメータを組み合わせないでください。

WordPressブロックとショートコード

<!-- wp:amicited/reviewed-by {"reviewType":"technical","reviewerName":"Alex Rivera","credentials":"Senior platform engineer","affiliation":"Northstar Cloud","reviewedOn":"2026-08-27","display":"expanded"} -->
<p>Scope: installation commands, supported versions 4.2–4.4, Linux prerequisites, expected output, and rollback steps were checked in clean Ubuntu 24.04 and Debian 13 environments.</p>
<p>The reviewer verified the procedure but did not assess third-party plugins or custom infrastructure.</p>
<!-- /wp:amicited/reviewed-by -->

[reviewed_by review_type="technical" reviewer_name="Alex Rivera" credentials="Senior platform engineer" affiliation="Northstar Cloud" reviewed_on="2026-08-27"]Scope: installation commands, supported versions 4.2–4.4, Linux prerequisites, expected output, and rollback steps were checked in clean Ubuntu 24.04 and Debian 13 environments.[/reviewed_by]

インポートとエクスポートは、テーマがそれらを異なる方法で表示する場合でも、レビュアーの役割、日付、スコープ、および境界を保持しなければなりません。

例

良好例：範囲を限定した方法論レビュー

これが機能する理由は、資格が関連しており、チェック内容が具体的で、最後の文が読者が統計レビューをデータ収集や購入アドバイスに拡張するのを防ぐからです。

悪い例：借用された権威

エキスパート検証済み ✓ Dr. Samによるレビュー済み。すべての事実は正確で承認済みです。

これは、レビュアーが特定できず、「Dr.」が関連する専門分野を示さず、日付がなく、「すべての事実」が無制限のスコープを設定しているため、失敗しています。チェックマークは、根拠のないガバナンスの主張を認証のように見せかけます。「承認済み」もまた、その人物が証拠、計算、安全性、スタイルを確認したのか、単にドラフトを見ただけなのかを説明せずに、推奨を示唆しています。修正するには、レビュアー名、資格、日付、レビュー済みの主張、除外された領域、および重要な関係性を明記してください。

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

WebPage の場合、実際のレビュアーをSchema.orgの reviewedBy に Person または Organization としてマッピングし、完了したレビュー日付を lastReviewed にマッピングします。表示される名前と日付は構造化された値と一致しなければなりません。dateModified は別に保持してください。ページの編集とレビューは別のイベントであるため、一方の日付をもう一方に自動的にコピーしてはいけません。

レビュアー Person には、サポートされている場合、安定した url、affiliation、knowsAbout、検証可能な hasCredential を含めることができます。資格をでっち上げてはいけません。その人物が実際にコンテンツを作成し、両方の役割が表示可能でない限り、author を使用してはいけません。

これは消費者向けの Review、評価、 testimonial、推奨、またはClaimReviewではありません。星、reviewRating、itemReviewed、または製品レビューマークアップを生成してはいけません。

ブロックは意味論的な <aside> またはラベル付き領域として通常の順序でレンダリングします。表示ラベルをアクセシブル名として、人物名をリンクテキストとして使用します。資格はテキストで保持し、チェックマークだけではレビューを示すことができません。

コンポーネントは200%ズームでリフローし、名前–資格–日付–スコープの順序を維持しなければなりません。アバターは補助的なものです。隣接するテキストが人物名を明記している場合は空の代替テキストを使用し、アバターを唯一のリンクにしてはいけません。静的な出典情報にライブステータスロールを使用しないでください。

書き方ルール

スコープは信頼主張を監査可能なステートメントに変換します。レビュアーが行ったことを記述してください。oversaw（監督した）、validated quality（品質を検証した）、ensured excellence（優秀さを保証した）よりも、checked（確認した）、reproduced（再現した）、tested（テストした）、compared（比較した）、verified（検証した）、reviewed（レビューした）を優先します。

レビュアーの公開されたプロフェッショナル名を使用します。スコープを直接サポートする1～3つの資格を記載し、資格行は120文字以内に抑えます。馴染みのない資格は、プロファイルまたは初出時に説明します。学位、ライセンス、認定、役職、またはドメインでの実務年数が関連性を確立できます。主題と一致しない名声は確立できません。

スコープは12～60語、1～2文で記述します。具体的な主張グループ、セクション、計算、バージョン、管轄権、ソースクラス、または手順を明記します。読者が執筆、実践的テスト、法的代理、推奨、または実際よりも広範なレビューを合理的に推測できる場合は常に、35語以内の役割境界を追加します。

レビュアーが記載された確認を完了した日付を記録します。実質的な編集がレビュー済みの主張を変更した場合は、新しいレビューと日付を取得するか、レビューが完了するまで該当スコープから属性を削除します。スコープ外のコピー編集はリセットしません。ページの公開日と修正日は、レビューを公開として静かに扱うのではなく、フレッシュネス要素を通じて調整します。

トーンは事実に基づいて保ちます。ページの結論を論じないでください。属性への同意を得て、バージョン、スコープ、所見、解決策、日付、承認者を内部で記録します。

以下のものをreviewed-byブロック内に決して配置しないでください：

• プロモーション的な賞賛、 testimonial、星評価、推奨、または製品推奨；
• レビュアーが正確性、安全性、結果、コンプライアンス、または将来のフレッシュネスを保証するという主張；
• 無関係な資格、敬称の過剰使用、または検証不可能な「専門家」ラベル；
• レビュアーの完全な経歴、キャリア履歴、連絡先の売り込み、またはソーシャルフォロワー数；
• 本文に属する記事の結論、新しい事実主張、ソース、または方法論；
• 公開を意図していないプライベートメール、ライセンス番号、または内部レビューコメント；
• アフィリエイトボタン、オファー、価格、ニュースレターフォーム、またはその他のコンバージョンコントロール。

「独立」には注意が必要です。これは、レビュアーが別個の確認役割を持ち、著者に異議を唱える自由があったことを意味します。パブリッシャーとの金銭的関係が自動的に存在しないことを意味するわけではありません。雇用、コンサルティング、提供された製品、またはその他の重要な関係性が読者の判断に影響を与える可能性がある場合は、それらを明確に記載してください。

使用する投稿タイプ

postTypes 配列は機械可読な関係性を作成します。専門家レビューイベントが一般的に実質的な保証を追加するフォーマットを特定します。すべてのページに儀式的なレビュアーを要求するものではありません。

その他の投稿タイプは、同じリスクと完了したレビューが存在する場合にこの要素を使用します。配列に含まれていることは、作業が完了する前にレビュアーの名前を追加する権限をパブリッシャーに与えるものではありません。

QAチェックリスト

• 著者以外の人物が、該当するページバージョンの実際の専門家レビューを完了した。
• レビュアーの専門知識が記載されたスコープに直接一致している。
• 公開名、1～3の関連資格、および重要な所属が正確で検証可能である。
• レビュアーが属性とその正確な表現に同意した。
• 表示される日付は、公開、編集、承認、または予定された将来の確認ではなく、完了したレビューを記録している。
• スコープは特定の主張、セクション、手順、バージョン、管轄権、または計算を明記している。
• 境界文が、執筆、テスト、推奨、アドバイス、または除外された素材についてのもっともらしい混乱を防いでいる。
• 「独立」「ピアレビュー済み」「テスト済み」「承認済み」「検証済み」は、証拠がそれらの正確な主張をサポートする場合にのみ表示される。
• ブロックは著者とフレッシュネス情報の下、冒頭の回答の前に配置されている。または、コンパクトな属性がソースの前の1つの同期された拡張ブロックにリンクしている。
• 著者バイオと統合されておらず、フッター、画像、ホバー状態、アコーディオン、または一般的なポリシーページのみに隠されていない。
• testimonial、評価、信頼バッジ、価格、オファー、アフィリエイトリンク、またはコールトゥアクションの直接隣に配置されていない。
• レビュースコープ内の実質的な変更が、再レビューまたは古い属性の削除をトリガーした。
• 内部レコードは、レビュー済みバージョン、スコープ、所見、解決策、日付、同意を保持している。
• reviewedBy と lastReviewed が出力される場合、表示されるレビュアーと日付と一致し、dateModified は独立して維持される。
• コンポーネントは消費者向けのReview、評価、testimonial、または製品推奨スキーマを出力しない。
• ラベル、名前、資格、日付、スコープは、色、アイコン、アバター、レイアウトなしでも理解可能である。
• レビュアーリンクは説明的な名前を使用し、フォーカスが可視であり、テキストがリフローし、静的なコンテンツにアラートロールがない。
• Markdown、Hugo、WordPressの表現は同じ正規の事実を保持している。
• スクリーンショットコメントは将来のキャプチャーのみを名指しし、存在しない画像はレンダリングされない。

FAQ

Reviewed-byブロックと著者バイオは同じですか？

いいえ。著者はページを作成し、レビュアーはその定義された部分を独立して確認します。両者が類似の資格を持つ場合でも、両方の役割を別々に明記してください。

すべての記事に専門家レビュアーが必要ですか？

いいえ。エラーが健康、金銭、法的権利、安全性、技術的実装、またはデータ主導の結論の妥当性に実質的に影響を与える可能性がある場合に、独立したレビューを使用します。日常的な低リスクの編集コンテンツは通常、儀式的な専門家名ではなく、編集者が必要です。

レビュースコープには何を記載すべきですか？

実際に確認された主張やセクション（例：投与量の安全性、税務の前提条件、方法論と計算、互換性手順）を明記してください。「完全に検証済み」のような無制限の表現は、レビュアーが明示的な基準に照らしてページ全体を確認した場合を除き、避けてください。

編集のたびにレビュー日付を変更すべきですか？

いいえ。レビュアーが該当するスコープを再度確認した場合にのみ変更します。そのスコープ外のコピー編集はレビュー日付をリセットしませんが、レビュー済みの主張への実質的な変更は、再レビューが行われるまで既存の属性を古いものにします。

従業員が独立したレビュアーになることはできますか？

はい。その人物が素材を作成しておらず、関連する専門知識を持ち、それに異議を唱えることができ、雇用関係や商業関係が明示されている場合に可能です。独立したレビューとは編集上の役割を指し、必ずしも経済的な独立性を意味するものではありません。

Reviewed-byブロックは、説明責任のある作業を明らかにする場合にのみ信頼を得ます。レビュアーを明記し、専門知識をスコープに結び付け、日付を保存し、意味のある制限を開示し、レビュー済みバージョンがページと一致しなくなった場合は常に属性を削除してください。