Pro/Con ブロック：フォーマットとルール

Pro/Con ブロックは、名前の付けられた1つの選択肢に対して、コンパクトでバランスの取れた評価を提供します。読者は、その選択肢が何を得意とし、何を受け入れる必要があるのか、そしてそれらのトレードオフが目の前の判断に適しているのかを理解できます。以下のブロックは実際のプロダクションモデルです：1つの所有者、並行した項目構成、そして偽装された賞賛ではなく意味のある制限事項を示しています。

製品名と詳細は説明用です。各項目が短い主張で始まり、1文の裏付けを追加している点に注目してください。長所と短所は、機能、運用上の制約、および結果について同じ詳細レベルで論じています。

この要素が重要な理由

購入者は、有用な機能をプロモーションから切り離し、さらに販売者が他の場所で説明したり省略したりする可能性のあるコストや制約を特定する必要があります。Pro/Con ブロックは、両方の側面を1つの境界のあるユニットに配置することで、その負担を軽減します。決定を下すのではなく、その背後にあるトレードオフを明らかにするのです。

信頼は、目に見える緊張から生まれます。「初心者は選択肢に困るほど多くの機能」というような、1つの表面的な欠点と並ぶ5つの熱狂的な利点は、形の上ではバランスが取れていても、実質的にはそうではありません。読者はその説得戦術をすぐに見抜きます。真の短所は、購入を変えたり、オーディエンスを除外したり、コストを追加したり、リスクをもたらしたり、回避策を必要としたりする可能性があります。通常は最低2つの意味のある短所が必要です。調査で本当に1つしか見つからなかった場合は、何をテストしたのか、なぜ2つ目の制限が確認できなかったのかを述べ、埋め合わせの項目をでっち上げないでください。

機械抽出可能性とは、ソフトウェアが文の主題や意味を失うことなく文を切り出す能力です。アンサーエンジンは、ラベルが評価を分類し、短い項目が明確な境界を作るため、Pro/Con を多用します。そのため、曖昧な短所やでっち上げの短所は、修飾句なしに繰り返される可能性があります。各項目は、ブロックのタイトルだけが一緒に引用されると想定して記述してください。

使用するタイミング

この要素は、読者が明確に名前の付けられた製品、サービス、方法、プラン、または選択肢を評価しており、利点と制限の両方を裏付けることができる場合に使用します。レビューセクションの後、繰り返される候補リストのエントリ内、またはプロダクトページのエビデンスの後に特に有効です。読者は、その選択肢が何であり、どのようなシナリオで評価されているかをすでに理解している必要があります。

ページが単に2つの対立する議論を必要としているだけの場合は使用しないでください。「移行する理由」と「待つ理由」は、製品の長所・短所というよりも、意思決定の枠組みである可能性があります。緊急の対応を必要とするリスクには使用しないでください。警告は結果と対応を直接述べる必要があります。複数の選択肢を同じ正確な基準で評価する必要がある場合に、完全な比較表の代わりとして使用しないでください。

よくある不完全なケースは以下の通りです：

• 機能リスト＋反対意見： 機能は存在するものを説明しますが、長所はなぜその機能が名指しされた購入者にとって役立つのかを説明します。よくある営業上の反論は自動的に短所にはなりません。
• 長所と注意事項： 医療、法律、財務、安全上の注意事項は、その結果に見合った重要性が必要です。
• 偽装された評決： 長所がある選択肢を支持し、短所が別の選択肢を攻撃している場合、ブロックには単一の所有者がいません。
• 根拠のない対称性： 3つの長所に合わせて短所を3つ目でっち上げないでください。調査の深さが数の一致よりも重要です。

配置場所

Pro/Con ブロックは常に近くの1つの所有者に属します：その見出しまたはアクセシブルラベルに記載された選択肢です。その選択肢の説明とエビデンスの後に配置し、そこで確立されたトレードオフを要約できるようにします。最初のブロックとして使用しないでください。その時点では、読者は主張を解釈するために必要な範囲、オーディエンス、プラン、バージョン、エビデンスを欠いています。

複数選択肢のページでは、各選択肢に同じ場所と形式で1つのブロックを配置します。Aに5つの詳細な項目、Bに2つの曖昧な箇条書きでは偏りが生じます。同じ制限、主張パターン、見出し順序、情報源の基準を適用してください。

選択肢セクションの間に浮かせたり、近くの比較表を繰り返したり、説明とブロックの間に行動喚起を挿入したりしないでください。推薦の言葉はリストの内側や間に配置できません。推薦と編集上の評価には別々の境界が必要だからです。

構造

レンダリング凡例

1. 所有者見出し： 評価に影響を与える場合、正確な選択肢、プラン、バージョン、オーディエンスを指定します。
2. 長所ラベル： 続くリストを利点として分類する可視テキスト。色やアイコンは補助的なものです。
3. 短所ラベル： 同じ評価範囲での制限事項として続くリストを分類する可視テキスト。
4. 短い主張： 実用的な範囲で90文字以内の、自己完結型かつ具体的な文。
5. オプションの裏付け： エビデンス、結果、または購入者にとっての関連性を説明する1文。160文字以内。
6. 情報源メモ： 主張が一般的に観察可能な事実でない場合、実際のテスト、ベンダー資料、または帰属表示されたレビューを特定します。

各リストは対等です。どちらかが強い書体、コントラスト、またはスペースを持つことはありません。執筆者が意味とエビデンスを提供し、レンダラーが表示を提供します。

デザイン例

バリエーションは密度とビューポートの動作を変更しますが、コンテンツ契約は変えません。

標準2カラム： 片側あたり2〜5項目。ソース順は長所、次に短所とします。

スタック型モバイル表示： 完全なテキストと順序を保持します。短所を折りたたんで長所だけを展開したままにすることはありません。

裏付け付き： 1つの短い結果またはエビデンスの手がかりを追加。より長いサポートはブロックの後に続きます。

コンパクトな繰り返しエントリ： すべての候補リスト選択肢が同等の調査と視覚的配分を受けます。

パラメータ

Pro/Con パラメータ

項目数範囲は、表面的な評決や機能の羅列を防ぎます。記載された購入者の決定を最も変える可能性が高い5つのトレードオフを選択し、範囲を埋めるために1つのアイデアを分割しないでください。

構文とコード例

すべてのマッピングは同じ所有者、リスト、主張、オプションの裏付け、情報源メモを持ちます。2つの見出しは構造フィールドです。

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

:::pros-and-cons{owner="Relay project software — Agency plan" source="Hands-on test, 27 August 2026; vendor plan documentation"}
## Pros
- **Client approvals stay in the project record.** Decisions remain attached to each deliverable.
- **Templates reduce repeated setup.** Recurring task groups retain owners and deadlines.

## Cons
- **Annual billing is required.** Teams cannot test this plan month to month.
- **CSV export omits approval history.** External archiving needs a second process.
:::

Hugo ショートコード

このコントラクトを実装したプロダクションショートコードはまだありません。以下の意図したアダプターはポータブルフィールドを保持します。ショートコードが存在するまでは、ライブブロックにはセマンティック HTML を使用してください。

{{< pros-and-cons owner="Relay project software — Agency plan" source="Hands-on test, 27 August 2026; vendor plan documentation" >}}
## Pros
- **Client approvals stay in the project record.** Decisions remain attached to each deliverable.
- **Templates reduce repeated setup.** Recurring task groups retain owners and deadlines.

## Cons
- **Annual billing is required.** Teams cannot test this plan month to month.
- **CSV export omits approval history.** External archiving needs a second process.
{{< /pros-and-cons >}}

レンダラーは、ラベル付きの1つの領域と2つの見出し付きリストを出力し、所有者をそのアクセシブル名として使用します。

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

[pros_and_cons owner="Relay project software — Agency plan" source="Hands-on test, 27 August 2026; vendor plan documentation"]
[pros]
- Client approvals stay in the project record. | Decisions remain attached to each deliverable.
- Templates reduce repeated setup. | Recurring task groups retain owners and deadlines.
[/pros]
[cons]
- Annual billing is required. | Teams cannot test this plan month to month.
- CSV export omits approval history. | External archiving needs a second process.
[/cons]
[/pros_and_cons]

WordPress ブロックは同じフィールドを公開できますが、画像を保存したり、評価から短所を推測したり、否定的な項目を非表示にしたりすることはできません。

例

良い例：バランスが取れ、並行しており、判断に関連

3名のコンサルティング会社向け LedgerPro 会計ソフトウェア

これは、両側が同じ購入者に対する具体的なワークフロー動作と結果を説明しているため有効です。各短所は、プランの選択、労力、またはレポートの信頼性に影響を与える可能性があります。ブロックは、利点と妥協点の両方を示しています。

悪い例：装飾を追加した広告

LedgerPro 会計ソフトウェア

欠点を装った1つの賛辞と並ぶ5つの一般的なポジティブ要素は、バランスのルールに違反しています。「高速」には対象や結果がなく、短所はレポートの量を説明しています。項目の抽象度と具体性が異なり、空のセルは調査された制限事項を提供していません。

プランと購入者を定義し、再現可能なワークフローをテストし、形容詞を観察可能な行動に置き換えてください。「月次の照合は1つのレビュー画面で完了する」と「分割された領収書には手動でのカテゴリレビューが必要」は同じ抽象度です。2つの実際の制限事項を確認するか、ブロックを公開しないでください。

情報源と帰属表示

実際の使用または信頼できるレビューで見つかった制限は、でっち上げられた短所よりも価値があります。記載されたユースケースをテストし、バージョン、プラン、日付、設定、タスクを記録してください。プランの制限についてはベンダー資料を、長期的な経験については独立したレビューを使用してください。

外部の観察結果はブロックの近くに帰属表示します。「情報源：Agency プランでの実機テスト、2026年8月27日、エクスポートはベンダー資料で確認済み。」元のレビューにリンクし、範囲を保持してください。4日間の対応が、サポートが常に遅いことを証明するわけではありません。

検索スニペット、帰属表示のない要約、方法のない比較は却下してください。文書にないことは、未検証であって利用不可ではありません。変動の多い商業的主張には日付を付けてください。

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

Schema.org には汎用の ProsAndCons タイプはありません。ブロックはそれを含む Article、Product、または真正な Review 内に保持し、プロパティをでっち上げたり、項目数から評価を導き出したりしないでください。可視のエビデンスと公開ポリシーが許可する場合にのみ、サポートされている肯定的または否定的なメモプロパティを使用してください。

ARIA（Accessible Rich Internet Applications）は、ネイティブ HTML が不十分な場合に、役割と関係を伝達します。所有者見出しで名前付けされた1つのセクション、次に2つの見出しと順序なしリストを使用してください。ソース順では長所を短所の前に配置してください。

「長所」と「短所」の可視ラベルは必須です。色、アイコン、位置だけでは意味を伝えられません。装飾アイコンは支援技術から非表示にしてください。静的ブロックはフォーカス可能、折りたたみ可能、またはアラートではありません。

執筆ルール

並行構造とは、同等の具体性を意味します。「高速」と「CSVエクスポートに承認履歴が含まれない」は、一方が無制限で他方が正確な動作を指定しているため、対比として機能しません。長所を「ダッシュボードフィルターがページをリロードせずに更新される」と書き直してください。項目には人工的な1対1の対比ではなく、同等の知的重量が必要です。

片側あたり2〜5項目を使用し、通常は少なくとも2つの意味のある短所を含めてください。購入者は、コスト、除外事項、学習負荷、コミットメント、摩擦、ミスマッチ、データ制限、依存関係、リスクを考慮できます。「よりコストがかかる」の背後にある価格と結果を明記してください。「やめたくなくなるかもしれません」は短所ではありません。

実用的な範囲で90文字以内の主張で始め、その後最大1つの160文字以内の裏付け文を続けてください。中立的な文の大文字小文字と一貫した文法を使用してください。抽出には完全な文が最も安全です。

以下のものを要素内に絶対に配置しないでください：

• 行動喚起、日付やプランコンテキストのない価格、クーポンコード、購入ボタン。
• 公開された方法のない星評価、スコア、勝者バッジ、「総合最高」ラベル。
• 推薦文、長い引用、スクリーンショット、動画、フォーム、ネストされた比較表。
• 安全警告、法的免責事項、または通常の短所よりも高い重要性を必要とする条件。
• 片側を長く見せるために複数の箇条書きに書き直された重複機能。
• 「完璧」や「すべての人に機能する」などの根拠のない絶対表現。

これを使用する投稿タイプ

Pro/Con を使用する投稿タイプ

リンクされた postTypes の値は、この要素を使用するタイプです。

QA チェックリスト

• ブロックには、評価を変更する場合にはプラン、バージョン、オーディエンス、日付を含む、曖昧でない1つの所有者がいる。
• 所有者の説明とエビデンスの後に続いており、最初のブロックではなく、選択肢の間に浮いていない。
• 複数選択肢のページでは、比較可能な選択肢に同じブロック形式、位置、項目制限、調査深度を提供している。
• 各側に2〜5項目が含まれ、明示的な調査メモが1つを正当化する場合を除き、少なくとも2つの意味のある短所がある。
• すべての短所は、適合性、コスト、ワークフロー、リスク、または購入の選択に現実的に影響する可能性があり、ネガティブラベルを付けた賞賛ではない。
• 長所と短所は、並行した文法、抽象度、具体性、裏付けの深さを使用している。
• 各項目には1つの短い主張と、最大1つの簡潔な補足文が含まれている。
• 主張は「高速」や「強力」などの形容詞に頼るのではなく、観察可能な動作または限定された結果を挙げている。
• 使用に関する所見は、テストしたプラン、バージョン、条件、日付を特定している。
• レビューに基づく主張は元のレビュアーに帰属表示され、普遍的な事実ではなく観察結果として範囲が限定されている。
• ブロックに、根拠のない評価、プロモーション行動、推薦文、長い引用、警告、メディア、ネストされた複雑な要素が含まれていない。
• 可視テキストラベルが両方のリストを特定しており、色、アイコン、位置だけが唯一の区別ではない。
• 所有者見出し、長所见出し、短所见出し、リスト項目が論理的なソース順と読み順を形成している。
• 要素はプレーンテキストとしてコピーされた場合や、スタイルやスクリプトが利用できない場合でも理解可能である。
• 構造化データはそれを含むページを正直に説明し、でっち上げられたスキーマタイプや推測された評価を使用していない。
• スクリーンショットコメントは、名前付きアセットが存在するまで非レンダリングのキャプチャ指示のままであり、存在しないアセットが画像として参照されていない。

FAQ

academy テンプレートは、このページの [[faq]] フロントマターに保存された5つのレビュー済み質問をレンダリングします。これらは項目数、バランス、レビューの帰属表示、構造化データ、アンサーエンジンによる引用をカバーしています。