おすすめ記事と公開日時順を両立させるには

「最新」と「おすすめ」は、どちらも読者に先に読む記事を示すものに見えます。しかし、答えている問いは異なります。

最新順は、どの記事が直近に正式な公開条件を満たしたかを示します。おすすめのフラグは、編集者が一覧の入口でどの記事を特に紹介したいかを示します。この二つを一つの並べ替えフィールドにまとめると、新しい記事が公開されるたびに、編集者が残しておきたい入口の記事が下へ押されます。一方、時間を完全に無視すると、読者は内容の新しさを判断できません。

ここで記録する実装では、二つの役割を分けています。まず、公開対象の記事集合を公開日時と安定したIDで並べ替えます。その後、有効な各一覧ページに featured の記事を独立したおすすめブロックとして表示し、通常の記事だけをページ分割します。

まず公開日で記事集合への参加条件を決めます

ノートの公開クエリは、レイアウトより先に公開条件を確認します。

• draft は false である必要があります。
• 記事には publishedAt が必要です。
• 公開日は、台北の今日の日付より後であってはいけません。
• 言語を指定する場合は、locale が一致する必要があります。

条件を満たした記事は、publishedAt の新しい順に並べます。秒単位の公開日時が同じ場合は、stableId で順序を安定させます。この層が決めるのは、公開可能な記事と最新順の計算方法だけです。featured に指定しても、記事の日時は変わりません。

つまり、featured は公開条件でも、別の種類の日付でもありません。草稿に featured: true を設定しても、先に正式サイトへ出すことはできません。公開日がまだ来ていない記事も、おすすめに指定したからといって公開条件を省略できるわけではありません。

一覧ページでおすすめブロックを分けます

ノート一覧は、並べ替え済みの公開記事集合を受け取ってから、記事を二つのグループに分けます。

公開条件を満たした記事
  ├── featured の記事 → 有効な各ページのおすすめブロック
  └── featured ではない記事 → 通常の記事一覧とページ分割

おすすめブロックは有効な各ページに表示されます。通常の一覧からはおすすめ記事を除外するため、同じ記事が通常一覧に重複して出ることはありません。通常記事のページ分割も、おすすめではない記事集合だけを対象に計算します。

この順序なら、どのページでもおすすめ記事を見つけられ、通常一覧の件数やページ分割も乱しません。2ページ目以降にも同じおすすめ記事集合を表示しますが、通常一覧の枠やページ数には影響しません。

おすすめ記事しかなく、通常の記事がない場合も、一覧には正式な公開内容があります。通常のブロックは、画面を埋めるためにカードを複製しません。記事がないことを示す空の状態は、その言語に公開条件を満たす記事が一つもない場合にだけ表示します。

おすすめの指定はホームページの固定表示ではありません

ホームページは、その言語で正式に公開された記事を最新順に最大3件取得します。公開日時による並べ替えの結果を使い、featured の記事を別途先頭へ移動することはありません。

同じメタデータでも、ページごとに役割が異なる場合があります。

• Notes一覧では、おすすめブロックを作るために使います。
• ホームページでは、最新順で最近の記事を表示します。
• 記事ページとサイトマップでは、正式な出力条件を満たしているかだけを確認します。

これはデータの不整合ではなく、ページの役割の違いです。おすすめのフラグは、一覧の表示に使う編集上の意思を示すもので、サイト全体で記事を先頭に固定する命令ではありません。

おすすめブロックに手動の並び順はありません

おすすめの記事集合も、公開クエリの公開日時と stableId による順序を引き継ぎます。メタデータはブール値だけで、別の featuredOrder や重み、固定のピン留め時間はありません。

2件をおすすめに指定すると、システムは両方をおすすめブロックに表示する必要があると判断できます。ただし、frontmatterでは「こちらの記事を必ずもう一方より先にする」とは指定できません。今後、編集上の並び順が必要になった場合は、明確なデータ契約と検証を追加する必要があります。ファイルの順番やビルド時の読み込み順を、並べ替えの基準にはできません。

この制約があることで、動作は分かりやすくなっています。

• 公開日は、時間の前後関係を決めます。
• featured は、おすすめブロックに入るかどうかを決めます。
• stableId は、公開日時が同じ場合にだけ、安定した順序を決める最後の比較基準になります。

この三つは、互いの役割を代わりに担いません。

おすすめ記事を通常の並び順へ戻さない理由

おすすめ記事を通常の一覧の先頭へ直接並べると、いくつかの問題が生じます。

• 最新記事と編集上のおすすめのルールが混ざり、読者は一覧の順序を理解しにくくなります。
• おすすめ記事が通常のページ分割の枠を使い、一部の通常記事が次のページへ押される可能性があります。
• おすすめを解除すると記事の相対的な位置が急に変わり、日時と編集上のフラグのどちらが原因なのか分かりません。
• 言語版ごとにおすすめの状態が異なると、一覧の順序にも説明しにくい差が生じる可能性があります。

独立したブロックを設けるのは、ホームページを複雑にするためではありません。おすすめの意図と時間の順序を、それぞれ読み取れるようにするためです。まず編集者が紹介したい記事を数件示し、その後で通常の一覧に時系列全体を載せられます。

おすすめの使い方にも制限が必要です

featured は、一覧の入口で特に紹介する価値のある記事に向いています。たとえば、サイトの方向性を表す記事、新しい読者が内容の範囲を理解するのに役立つ記事、最新ではなくても先に読んでほしい記事です。

次のような用途には向きません。

• 記事の品質の自動採点。
• 検索順位やアクセス数の保証。
• 公開日のない草稿を先に露出させる方法。
• レイアウトに大きなカードを置くためだけの、根拠のない指定。
• すべての記事にフラグを付けて作る、もう一つの通常一覧。

おすすめの件数が増えすぎると、選んだ記事という意味が薄れます。その段階では、ブール値の指定を増やし続けるより、まずおすすめブロックがまだ必要かを見直すべきです。

多言語版では編集の責任を先に決めます

featured は、各言語の記事ファイルが持つメタデータです。同じ stableId を持つ繁体字中国語・英語・日本語の記事でおすすめの状態が異なれば、各言語の一覧で異なる記事が推薦される可能性があります。

それ自体が必ず誤りとは限りませんが、意識的に決めたルールである必要があります。たとえば、次のような方針を選べます。

• 言語ごとにおすすめを独立して編集し、それぞれの読者に合う入口を用意します。
• 同じ stableId でおすすめの判断を共有し、翻訳版にも同時に更新を反映します。
• 正式な公開内容がある言語だけでおすすめを選び、存在しない翻訳のためのフラグは用意しません。

コードが扱うのは、各記事自身の featured 値です。同じ stableId の言語版をまたいで、おすすめの状態が一致しているかを検証する仕組みはありません。3言語共通のおすすめルールを設けるなら、先にデータ契約を追加し、その後で一覧とテストを変更する必要があります。

執筆と検証では二つの並べ方を分けて確認します

記事を追加したり、おすすめの状態を変えたりするときは、次の順に確認できます。

1. 記事が、まず正式な公開条件を満たしているかを確認します。
2. おすすめに指定しない状態で、公開日時と stableId による順序が期待どおりかを確認します。
3. おすすめに指定した記事が、有効な各ページのおすすめブロックに表示されるかを確認します。
4. 通常の一覧がおすすめ記事を除外し、ページ分割の件数も正しいかを確認します。
5. ホームページが、誤っておすすめ順に変わらず、引き続き最新の最大3件を表示しているかを確認します。
6. サイトマップが正式な一覧と記事のルートだけを反映し、メタデータを新しいURLとして扱っていないかを確認します。

これらのチェックで、データフィールドが正しく使われているかは確認できます。ただし、おすすめ記事が実際に読者の役に立つかまでは分かりません。何を推薦するかは、引き続き編集者とサイトオーナーによる内容の判断です。

おすすめは編集上の意味を持ち、時間は公開上の意味を持ちます。それぞれの役割を分ければ、一覧で曖昧な「重要度」フィールドを使い、最新順・推薦・公開条件を一度に代用する必要はありません。

この記録の範囲

この記事は、ノートのスキーマ、公開記事の並べ替え関数、一覧コンポーネント、ページ分割のルート、ホームページのクエリ、サイトマップの実装をもとに整理しました。2026年10月2日の原稿に記録された、featured と公開日時順の技術的な動作を説明しています。おすすめに指定すれば必ず閲覧数が増えると主張するものではなく、言語版をまたぐおすすめの一致を、すでに実装済みの機能として扱ってもいません。