長い段落を三つに切って、先頭に「・」を付ける。画面はすっきりしても、特徴、作業、注意点が混ざっていれば、読む人は項目同士の関係を考え直すことになります。短くする途中で「写真提供がある場合」という条件が消えると、依頼の範囲まで変わってしまいます。
記事の箇条書きは、同じ問いに答える項目を並べるのが基本です。作業の順番を伝えるなら番号を付け、理由や経緯を読ませる部分は文章でつなぎます。文末をそろえる前に、何をひとまとまりとして見せるかを決めます。
対象は企業メディアの解説記事や取材記事に入れる箇条書きです。並列のそろえ方、番号・句点の使い分け、条件を残す直し方を扱います。以下の記事制作に関する文例は、説明用の架空の設定です。
箇条書きにするのは、読者が見比べる項目
箇条書きは関連する複数の項目を一つずつ見つけたり見比べたりできる形にしたものです。必要な資料、選択肢、確認項目などを示すときに向きます。一方、判断に至った理由や出来事のつながりは、段落で読んだほうが関係を追いやすい場合があります。
たとえば、取材当日の持ち物を探す読者には、録音機、予備の電池、質問案を一覧で渡せます。しかし、なぜ質問の順番を変更したのかという説明を単語だけにすると、相手の発言を受けて聞き方を変えた経緯が消えてしまいます。何を探してほしいかと、何を理解してほしいかでは、合う形式が違います。
オーストラリア政府のStyle Manual「Lists」は、関連情報のまとまりや手順を示す用途とともに、リストを多用すると内容を追いにくくなる点を挙げています。これは同政府の英語の文章指針です。日本語記事でも、短さだけでなく情報同士の関係を見て使うかを判断できます。
一節の中に、理由を説明する段落と、確認する対象のリストがあってもかまいません。すべてを箇条書きへ直すより、それぞれに仕事を持たせます。記事全体の章分けから考える場合は、記事構成案の作り方も参考になります。
何の一覧かを決めて、同じ問いへの答えを並べる
項目をそろえるときは、箇条書きの直前の一文へ、各項目を続けて読んでみます。「撮影前に確認することは」と書いたなら、どの項目も確認する対象になっているかを見る方法です。
次は、並べる内容が混ざった例です。
- 撮影場所の確認
- 写真が豊富
- 提供素材は担当者に相談してください。
一つ目は作業、二つ目は素材の状態、三つ目は依頼です。三つとも写真に関する内容ですが、同じ一覧にしただけでは何を判断するのかが定まりません。撮影前の確認項目として残すなら、次のように問いをそろえられます。
撮影前に確認する項目の例は、次の三つです。
- 撮影場所と使用できる時間
- 記事に必要な写真の種類
- 提供素材の有無と相談先
「写真が豊富」が実際の素材の説明として必要なら、別の段落へ戻します。並列を整えるために、確認できていない写真の種類や数量を作ることはできません。
同じStyle Manualの並列構造の説明は、項目の文法的な形、時制、文の種類をそろえる考え方を示しています。ただし、原稿の「依頼」を「確定した事実」に直してまで形を合わせる必要はありません。項目を別のまとまりへ移す方法もあります。
何の一覧かが見出しだけで伝われば、同じ説明の一文を重ねなくても読めます。見出しと項目の関係を決める際は、記事の小見出しの付け方で扱う、見出しが約束する答えとの対応も使えます。
「すべて」か「いずれか」かと、適用する条件を残す
条件の一覧では、全部に当てはまる必要があるのか、一つ選べばよいのかを先に書きます。「必要なもの」とだけ示すと、必須条件と選択肢の区別が付かない場合があるためです。
たとえば資料の提出方法なら、「PDFか、共有リンクのいずれかで提出できます」と書けば、両方を用意する必要がないことが伝わります。両方が必要な設定なら、「PDFと共有リンクの両方を送ってください」と変わります。記号や改行だけに、その違いを担わせないようにします。
もう一つ気を付けたいのが、条件を箇条書きの外へ移すときです。元の文が次の内容だったとします。
写真提供がある場合は、提供元名と、予定している掲載先で使えるかを確認する。公開日は、写真提供の有無にかかわらず確認する。
これを「確認すること」として提供元名、掲載先、公開日だけに縮めると、最初の二つに付いていた条件が見えなくなります。次の形なら、それぞれに適用する範囲が残ります。
- 写真提供がある場合は、提供元名と、予定している掲載先で使えるかを確認する。
- 写真提供の有無にかかわらず、公開日を確認する。
長い項目を必ず二つへ分けると、条件と作業が離れる場合があります。文字数をそろえる前に、どこまでが同じ条件で行うことなのかを確かめます。赤入れをするなら、「文が長い」だけでなく、どの条件がどの項目に掛かるかまでコメントすると、直す意図を共有できます。原稿の赤入れのコメント例もこの判断を伝える際に使えます。
順番が必要な手順は、番号付きリストにする
番号は先にすることと後にすることの関係を示すために使います。記事に必要な資料の一覧なら、必ずしも順番はありません。一方、原稿確認を進める手順では、修正する版を確定してから確認を頼む、といった前後関係があります。
架空の原稿確認の手順なら、次のように示せます。
- 確認してもらう原稿の版を確定する。
- その原稿のリンクと確認期限を、担当者へ送る。
- 指摘を反映した箇所を、元の原稿と照合する。
Microsoft Style Guide「Lists」は、特定の順番を必要としない共通項目には箇条書きを、手順など順番のある項目には番号付きリストを使い分けています。この例の三つは、同時に選べる選択肢としては扱えません。
番号が付いていても、順位なのか作業順なのかは説明が要る場合があります。「重要度の高い順」と「この順に操作する」では、読む人の行動が違うからです。確認していない優先順位を、番号を付けるだけで作らないようにします。
文末・句点は、項目の役割に合わせてそろえる
文で説明するリストは文として終え、短い名称の一覧は名称の形でそろえると、項目の対応を読み取りやすくなります。「録音機」「予備の電池」のような名詞の一覧と、「録音機が動くか確かめる。」という作業の一覧は、どちらも使えます。
本稿では名称・短い語句だけの項目には句点を付けず、独立した文には句点を付けています。これはこの記事の表記方針で、すべての日本語リストに共通する唯一の規則ではありません。媒体に既存ルールがあれば、それを確認します。英語の指針にある大文字や句読点の規定を、そのまま日本語へ移す必要もありません。
直す際は、同じリストの中で読み方が不意に変わらないかを見ます。文末だけを「確認」に置き換えると、依頼なのか、確認済みなのかが曖昧になることもあります。状態を伝える一覧なら「確認済み」「確認待ち」を残し、作業の一覧へ作り替えないほうが正確です。
項目の字数や総数には、ここでは固定の正解を設けません。多いときは数を削る前に、別の問いに答える項目が混ざっていないか、まとまりを分けられないかを確かめます。表記と意味の確認を分けて運用する方法は、記事の表記ルールの作り方にまとめています。
入稿後は、記号の見た目とリストの構造を確かめる
CMSへ入れたら、項目の順番、字下げ、途中の改行を実際のページで確認します。折り返した二行目が別の項目に見えたり、見出しとリストが離れたりすると、原稿では明らかだった関係を読み取りにくくなります。
W3CのWCAG 2.2達成方法集H48は、順序のあるリストにHTMLのol、順序のないリストにulを用いる方法を説明しています。記号と改行だけで一覧に見せた場合、プログラムから項目の関係を読み取れないことがあるという指摘です。H48は達成方法の一例で、これだけでページ全体のアクセシビリティ適合を判断するものではありません（2026年11月10日確認）。
編集者はまずCMSの箇条書き・番号付きリストの機能を使い、公開候補の画面で項目の区切りを見ます。音声で読む場合の構造も必要なら、実装担当者とリストとして出力されているかを確かめます。スマートフォン、noteなどの別の掲載先にも移す場合は、変換後の番号や入れ子を再確認します。
次の原稿では、既にある箇条書きの直前へ「何を並べた一覧か」を一文で書いてみてください。その問いに各項目が答えているか、順番と条件を保てているかを読めば、短くする場所と、文章へ戻す場所を判断できます。
参考資料
- Australian Government Style Manual：Lists
- Microsoft Style Guide：Lists
- W3C WAI：H48: Using ol, ul and dl for lists or groups of links
資料は2026年11月10日に確認。文章の構成と、Webページのリスト構造という、それぞれの指針が扱う範囲を参照しています。
