Markdown の引用ブロック：引用、複数の段落、リスト

Markdown の引用ブロックは > とその後のスペースで始めます。引用する各行の先頭にマーカーを置くと、ソースが読みやすく、編集しやすくなります。

> 改訂したインストールガイドのレビュー準備ができました。

結果はコードブロックではなく、引用された段落になります。枠線、インデント、色はページや文書のテーマによって決まります。引用文は通常の Markdown のままなので、強調、リンク、リストなどの文書構造を含められます。

Markdown ビューアーで例を試し、編集可能なレビュー用コピーが必要になったら、Markdown から Word への変換ツールで文書を書き出してください。

複数のソース行にわたる段落を引用する

長い引用では、マーカーを繰り返します。

> 改訂したインストールガイドのレビュー準備ができました。
> リリースを承認する前に、前提条件を確認してください。

このサイトのプレビューでは、これらの 2 行は 1 つの段落になります。ソースの改行が、表示上の改行を必ず強制するわけではありません。文章を 2 行に分ける必要がある場合は、明示的な改行を追加します。

> ドキュメントレビュー\
> リリース責任者に割り当て

バックスラッシュは改行の直前に置きます。次の行にも引き続き引用マーカーを付けます。強制改行と段落の区切りの違いは、Markdown の改行をご覧ください。

1 つの引用に複数の段落を含める

段落間の、本来なら空行になる行にも引用マーカーを置きます。

> 最初の下書きはインストール手順を説明しています。
>
> 2 番目の下書きではトラブルシューティングの手順と例を追加しています。

これにより、2 つの段落を含む 1 つの引用ブロックができます。区切りの行に > を残すと、特に後から誰かが編集する際に、どこまでを同じ引用にする意図なのかが明確になります。

自分の文章に戻るには、空行を置き、マーカーなしで続きを書きます。

> レビューではインストールの節を短くするよう求められました。

詳しい設定の説明は付録に移しました。

空行を追加せずに、続きの行から > だけを外すのは避けてください。Markdown パーサーによっては、それを引用段落の省略記法による継続として扱います。この動作は CommonMark の引用ブロック仕様で説明されています。明示的なマーカーと明確な空行を使うほうが、共同編集者にとって管理しやすくなります。

強調、リンク、出典を加える

引用ブロックの内容には、通常のインライン書式を使えます。

> **レビューの指摘：** 移行手順には動作する例が必要です。
> [リリースチェックリスト](https://example.com/checklist)をご覧ください。
>
> 2026 年 9 月のドキュメントレビューからのフィードバック。

Markdown は最後の行に特別な出典としての役割を与えません。引用内の通常の段落内容です。必要に応じて出典、著者、リンクを含め、他人の文章を転載する前には許諾を確認してください。

引用ブロックは引用符そのものも追加しません。最終文書に引用符が必要な場合は、自分で入力してください。自分の文の中に短い引用を挿入する場合は、独立したブロックを作らず、通常の引用符だけで十分なこともあります。

引用を入れ子にする、またはリストを含める

外側の引用の中でさらに引用するには、> の階層を 1 つ増やします。

> レビュー担当者は以前の依頼を次のようにまとめました。
>
> > 設定ファイルの完全な例を追加してください。
>
> 更新後の下書きには、その例が含まれています。

レポートでは入れ子を浅く保ってください。引用を深く入れ子にすると、文章に使える幅が狭くなり、PDF や Word のレイアウトが読みにくくなる場合があります。

引用の中にリストを置く場合も、すべての行にマーカーを残します。

> レビューでは 2 つの変更が指摘されました。
>
> - 必要な権限を説明する。
> - トラブルシューティングの節を追加する。

反対に、リストの中に引用を置く場合は、リスト項目の本文の下にそろえてインデントします。

- ドキュメントへのフィードバック

  > 公開前にトラブルシューティングの節を追加してください。
- リリースチェックリスト

引用が項目の外に表示される場合は、Markdown インデントガイドの例とインデントを比べてください。

GitHub アラートには出力先の対応が必要

GitHub は引用構文を使った特別なアラートに対応しており、次の形式もその 1 つです。

> [!NOTE]
> 設定を変更する前にバックアップしてください。

GitHub は対応する種類をアラートのリファレンスに記載しています。アラートの色やアイコンはプラットフォームの機能であり、すべての Markdown の引用に備わるものではありません。

このサイトのレンダラーは GitHub のアラートスタイルを追加しません。この例は [!NOTE] というラベルが見える引用ブロックのままになります。出力先が変わっても読みやすい文書にするには、明示的な太字ラベルを使ってください。

> **注意：** 設定を変更する前にバックアップしてください。

これなら特別なアラート拡張がなくても意味が伝わります。同じ方法は警告、レビューの決定事項、編集上の注記にも使えます。

書き出す前に引用の問題を確認する

> がそのまま表示される場合は、その例がバッククォート、フェンス付きコードブロック、またはインデントによるコードブロックの中にないか確認します。これらの場所ではソースをそのまま表示するのが意図した動作です。マーカーの前にバックスラッシュを置いた場合も、マーカーはエスケープされます。

引用される文章が多すぎる場合は、引用の外に戻したい段落の前に空行を加えます。入れ子の内容が追いにくい場合は階層を減らし、出典は通常の段落として追加してください。

最後に、書き出した DOCX を開いて、長い引用と引用内のリストを確認します。ブラウザーの左枠線と Word 文書の段落スタイルは異なる場合があります。ソースの書式の問題と書き出し時のスタイルの問題を区別したいときは、Markdown から HTML への変換ツールで中間構造を確認してください。