[🛠] GitHub Pagesブログのsidebarにカレンダーと活動統計を付ける

✨ GPT-5.5の要約 　

ブログ再開直後にsidebarへ投稿カレンダーとカテゴリ活動統計を付け、現在の記事基準の月表示と月別archive探索まで作った記録。

ブログ再開の記事を整理し終えると、すぐ次の問題が見えた。

記事はまた書き始めた。けれどブログがもう一度生き返った感じは、まだ足りなかった。カテゴリ一覧だけでは、このブログがいつ動いたのか、どの日に記録が積まれたのか、最近どんな流れがあるのかがよく見えなかった。

Daily Reviewをもう一度書くには、日付感覚が重要だ。

このブログは結局、「どの日に何を残したのか」が中心だ。けれどGitHub Pagesブログには、Naver Blogのように自然に見える日付探索がない。静的ブログなので、なおさら自分で作る必要があった。

だから今夜付けた機能は、単なる飾りではなかった。

sidebarを記事リストの補助装飾ではなく、日付と活動の流れを見せる探索ツールへ変える作業だった。

最初に付けたのは小さく直接的なカレンダーだった

最初のコミットはf6971fcだった。

f6971fc  feat: add sidebar activity widgets

このとき新しく作ったファイルは二つだ。

_includes/sidebar-calendar.html
_includes/sidebar-nav-stats.html

sidebar.htmlにはカレンダーincludeを付けた。

{% include sidebar-calendar.html %}

最初のカレンダーはJavaScriptなしで、Liquidだけで作った。

site.postsから非表示記事を除外し、現在月の最初の曜日と最終日を計算した。2月のうるう年計算までLiquidの中で処理した。

{% assign calendar_posts = site.posts | where_exp: "post", "post.hidden != true" %}
{% assign calendar_year = site.time | date: "%Y" %}
{% assign calendar_month = site.time | date: "%m" %}

月の中で記事がある日はリンクになり、記事がない日は数字のまま残る。最初の基準はsite.timeだった。つまりこの時点のカレンダーは、「現在月の投稿状況」を見せるsidebar widgetだった。

この程度でも、効果はすぐにあった。

ブログがまた動いている感じが出た。記事タイトルの一覧だけを見るのとは違って、カレンダーは記録の密度を見せてくれる。どの日に記事が集中したのか、どの日が空いたのか、今日がどこなのかが一目で入ってくる。

カテゴリにも活動情報を付けた

カレンダーだけを付けると日付の流れは見えるが、カテゴリ別の流れはまだ鈍かった。

そこでsidebar-nav-stats.htmlも一緒に作った。

このincludeはsidebar項目のURLをカテゴリパスと見なし、そのカテゴリに属する記事をもう一度フィルタリングする。

{% assign stat_posts = site.posts | where_exp: "post", "post.hidden != true" %}
{% assign stat_categories = include.url | remove_first: "/" | split: "/" %}

たとえば/daily-reviewならdaily-reviewカテゴリの記事数を見せ、/diary/aiならdiaryとaiの両方を含む記事だけを残す。

出力は単純だ。

記事数 · 最新記事日付

これがよかった理由は、sidebarが単なる目次から抜け出したからだ。

今日一日はが何本あるのか、人工知能の記事が最近いつ上がったのか、GitHub Pages Blogが実際に運用中なのかが見える。ブログが死んでいるのか生きているのかは、記事数より最新日付のほうによく出る。

モバイル密度からすぐ調整した

カレンダーを付けるとすぐ、モバイル密度が問題になった。

sidebarはデスクトップでは余裕があるが、モバイルでは本文の下へ降りたり、メニューと混ざったりする。カレンダーのセルが大きい、あるいは記事数ラベルが長いと、widget一つが画面を大きく食ってしまう。

そこで17d074dとb401d8bで、sidebar活動ラベルとカレンダー密度をすぐ縮めた。

17d074d  fix: tighten sidebar activity labels
b401d8b  [Fix] | Sidebar calendar: Improve mobile density

SCSSでは日付セルをaspect-ratio: 1で固定し、小さなフォントと4px radiusを使った。カテゴリ活動情報は一行の中で小さく見えるようにした。

ここで重要なのは、カレンダーを「主役」にしないことだった。

カレンダーはブログ探索を助ける装置だ。本文より大きくなってはいけない。特に記録ブログでは、sidebarは情報を与えつつ、記事を読むことを邪魔してはいけない。

現在の記事基準の月へ変えた

すぐに、もっと重要な問題が見えた。

カレンダーがsite.time基準なら、2025年の記事を読んでいるときも2026年5月のカレンダーが出る。これではカレンダーが現在の記事の文脈を説明できない。

そこでccb58d5で基準日を変えた。

ccb58d5  [Fix] | Sidebar: Refine calendar behavior

核心はこの部分だ。

{% assign calendar_source_date = site.time %}
{% if page.date %}
  {% assign calendar_source_date = page.date %}
{% endif %}

ページにdateがあれば、その日付の月を見せる。日付がないページでは、従来どおりsite.timeを使う。

この修正で、カレンダーの性格が変わった。

最初のカレンダーは「今月のブログ状況」だった。今は「いま読んでいる記事が置かれた時間」を見せる。古いDaily Reviewを読めば、その月の記録の流れを見られ、同じ月にどんな記事があったのかも続けて探せる。

これは日付中心の記録ブログにはずっと合っている。

同じ日の複数記事はリストに展開した

同じコミットで、日付別記事リストも付けた。

一日に記事が一つだけなら、日付リンクをその記事へ送ればいい。けれど一日に記事が複数あると問題が起きる。再開初日だけ見ても、Daily ReviewとAI会話アーカイブが同じ日付にある。

だから記事が複数ある日付では、日付リンクがすぐ記事へ行かず、その日付の記事リストへ移動するようにした。

<section id="sidebar-calendar-2026-05-25-posts" class="sidebar-calendar__post-list">
  <h4 class="sidebar-calendar__post-list-title">5月25日の記事</h4>
  <ul>
    ...
  </ul>
</section>

この時点のルールは単純だった。

記事1本: その記事へ移動
記事2本以上: その日付の記事リストへ移動

完璧なルールというより、今すぐ同日複数記事の問題を解く方法だった。それでも重要なのは、問題を隠さなかった点だ。

一つの日付に複数の記事があるかもしれないという事実を、システムが認める必要がある。Daily Review、AI会話、開発記録が同じ日に出るブログなら、この処理が必要だ。

JavaScript enhancementも付けた

Liquidカレンダーだけでも現在月中心の探索はできるが、月をまたいで移動する探索は不便だ。

そこでb06b6d6でJavaScriptを付けた。

b06b6d6  [Feat] | Sidebar calendar: Add archive navigation

新しいファイルはこれだ。

assets/js/custom/sidebar-calendar.js

そして_config.ymlのafter_footer_scriptsに登録した。

after_footer_scripts:
  - /assets/js/custom/dark-theme.js
  - /assets/js/custom/sidebar-calendar.js

Liquid側では投稿データをJSONで渡した。

<script type="application/json" data-calendar-posts>
[
  {
    "title": "...",
    "url": "...",
    "date": "2026-05-25"
  }
]
</script>

JavaScriptはこのデータを読み、postsByDate、postCountByMonth、postCountByYear、latestPostMonthByYearを作る。その次に前月・翌月ボタン、month input、年/月別の記事数ボタン、日付別の動的記事リストをレンダリングする。

この構造がよかった理由は、fallbackを捨てなかったことだ。

JavaScriptがあれば、月移動とarchive探索が便利になる。JavaScriptがなくても、Liquidが現在の記事基準の月と複数記事fallbackリストをすでにレンダリングしている。

静的ブログでは、このバランスが重要だ。

今日変わったこと

今日の夜から明け方まで続いた流れはこうだ。

f6971fc  sidebarカレンダーとカテゴリ活動統計を追加
17d074d  sidebar活動ラベル密度を調整
b401d8b  モバイルカレンダー密度を調整
ccb58d5  現在の記事基準の月と複数記事日付リストを処理
b06b6d6  月別archive探索用JavaScript enhancementを追加

核心ファイルはこうだ。

_includes/sidebar.html
_includes/sidebar-calendar.html
_includes/sidebar-nav-stats.html
assets/js/custom/sidebar-calendar.js
_sass/custom/customOverride.scss
_config.yml

一行で要約するとこうだ。

ブログのsidebarに、日付とカテゴリ活動の流れを見せる探索レイヤーを付けた。

結果

これでブログsidebarは単なるカテゴリ一覧ではない。

現在の記事が属する月を見せ、記事がある日付を表示し、同じ日に複数記事があればリストとして展開する。カテゴリ項目には記事数と最新記事の日付が付く。JavaScriptが有効なら、年と月を行き来しながらブログarchiveを眺められる。

ポートフォリオとして見ると、この作業のポイントはサーバーなしで探索性を上げたことにある。

別DBもなく、APIもない。Jekyllのsite.posts、Liquid、SCSS、小さなJavaScriptで、静的ブログの弱い部分を埋めた。記録には日付がある。その日付をUIに出すと、ブログは単なる記事の山ではなく、時間順に動くシステムのように見える。

今日付けたカレンダーは、その始まりだ。