[🛠] GitHub Pagesブログを、もう一度作業できるシステムとして立て直す

✨ GPT-5.5の要約 　

止まっていたGitHub Pagesブログを再び開き、Daily ReviewとAI会話アーカイブを分けて、公開記録システムとして再稼働させた記録。

今日、ブログをもう一度開いた。

ただ記事を一つ書こう、という程度の話ではなかった。止まっていたGitHub Pagesブログを、もう一度ちゃんと作業できる状態に戻す作業だった。

出発点は2026年5月25日のDaily Reviewだった。その記事は、また毎日記録していくという宣言であると同時に、あまりにも多くのものを一度に抱え込んでいた。予備軍死亡事件への怒り、政治への嫌悪、信仰と実行に対する自己点検、AIを自己管理ツールとして使うアイデア、ブログ再開の決意。その全部が一つの記事の中に入っていた。

最初は、それでいいと思っていた。

再開初日なのだから、その日に自分を押し出した会話まで全部残せばいいと思っていた。けれど実際にファイルを見てみると、これはDaily Reviewではなかった。一日の記録というより、会話アーカイブに近かった。Daily Reviewに数千行規模の会話全文を貼り付けてしまったら、その記事はもう毎日続けられる記録ではなくなる。

だから今日の最初の判断は単純だった。

Daily ReviewとAI会話アーカイブを分ける。

まず条件を決めた

ブログを再開するには、かっこいい宣言より先に、運用できる構造が必要だった。

条件はこうだった。

• Daily Reviewは毎日書けるくらい軽くしておく。
• 長いAI会話は別のアーカイブ記事として分ける。
• 会話アーカイブをexporterのダンプのように見せない。
• 罵倒や過激な表現は公開用にマスキングする。
• ユーザーの発話とAIの応答を視覚的に区別する。
• アーカイブ一覧で記事のカテゴリがすぐ見えるようにする。
• モバイルでコードブロックや長い会話カードが画面を横に押し出さないようにする。

言葉にすると、ただの整理作業のように見える。

でも実際には、ブログ再開を妨げていた一番大きな問題を片付ける作業だった。再開初日の記事が重すぎると、次の日からまた書けなくなる。今日の核心は、記事を大きくすることではなく、もう一度続けて書ける状態を作ることだった。

会話全文をDaily Reviewから取り出した

最初は、2026年5月25日のDaily Reviewの中に会話全文を折りたたみ形式で入れていた。

けれど、このやり方はすぐに限界が見えた。

Daily Reviewは、その日の勝敗、成果物、身体の記録、逃避の記録を残す記事であるべきだ。そこに2,900行近い会話全文が入ってしまうと、記事の性格がぼやける。読者も混乱するし、自分も次の日に同じ形式を続けたくなくなる。

だから会話は別の記事に分けた。

_posts/daily-review/2026-05/2026-05-25-2026-05-25.md
_posts/diary/ai/2026-05-25-reservist-anger-to-blog-restart.md

Daily Review側では巨大な会話ダンプを減らし、別の会話アーカイブを作った。

ここが核心だった。

一日の記録は一日の記録として残す。会話アーカイブは会話アーカイブとして残す。二つを混ぜない。

exporterダンプを記事らしく変えた

AI会話のexportは、そのまま貼ると読みにくい。

検索ログ、期限切れになるかもしれない画像リンク、繰り返されるメタ情報、会話途中の雑多な構造が混ざる。そのまま公開すれば「記録」にはなるが、「記事」ではない。ブログに残すことはできても、読まれるものにはならない。

だから会話アーカイブをカード構造に変えた。

<section class="conversation-entry conversation-entry--user">
  <div class="conversation-meta">私 · 2026.05.25 09:12:38</div>
  <div class="conversation-body">
    ...
  </div>
</section>

ユーザー発話は黄色系で強調し、AI応答はもう少し静かな背景にした。conversation-meta、conversation-body、conversation-mask、conversation-codeのようなクラスを作った。罵倒は***として見える形で残しつつ、公開記事の中でそのまま飛び出さないようにした。

これは単なるCSS装飾ではなかった。

会話を公開資料に変える過程だった。原文を完全に消してしまうのではなく、ブログの読者が「どこで話題が変わり、誰が話し、なぜこの会話が再開宣言につながったのか」を追えるようにする作業だった。

メタデータも整理し直した

記事を分けると、別の問題が見えてきた。

アーカイブ一覧でタイトルと日付だけが見えても、その記事がDaily Reviewなのか、AIアーカイブなのか、開発日誌なのか、Tips記事なのか、すぐには分からない。ブログをまた大きくしていくなら、一覧の段階から文脈が見える必要があった。

そこで_includes/archive-single.htmlにカテゴリ表示を付けた。

daily-reviewはDaily Review、diaryは日記、aiはAI、github-pages-blogはGitHub Pages Blogのように見せるようマッピングした。raw categoryをそのまま出すのではなく、実際の読者が読む名前に変えた。

最初はカテゴリチップを本文メタ情報の下に置いたが、すぐに散らかって見えた。もう一度直して、日付メタ情報とカテゴリチップを同じ行に置いた。

日付 / カテゴリチップ / 要約

この小さな修正で、アーカイブ一覧の情報密度がよくなった。ポートフォリオの観点でも意味がある。ただ記事を書くブログではなく、コンテンツタイプを分け、探索しやすさを改善したシステムに見えるからだ。

モバイルで崩れる部分も直した

会話カードとコードブロックを入れると、モバイルの問題も出てきた。

長い文章、引用、コードブロック、コピーボタンが画面を横に押し出すと、ブログはすぐ雑に見える。特にMinimal Mistakesのコードコピーボタンは便利だが、狭い画面ではボタン自体がoverflowを作ることがあった。

だから、いくつかすぐに直した。

.conversation-entry {
  overflow-wrap: break-word;
}

.conversation-body {
  min-width: 0;
}

.clipboard-copy-button {
  overflow: hidden;
}

会話カード内の見出し、blockquote、最初と最後の段落のmarginも調整した。モバイルではカードのpaddingと内部見出しのサイズを小さくした。

こういう修正は目立ちにくい。でもポートフォリオとして見ると、むしろ重要だ。機能を付けて終わりにしたのではなく、実際の画面で崩れる部分まで追いかけて整えたという意味だからだ。

今日変わったこと

今日の変更は、おおよそ次のように整理できる。

AGENTS.mdと_project/blog-system/README.mdでブログ運用ルールを整理
Daily Reviewから会話全文を削除
AI会話アーカイブの別記事を作成
conversation-entryベースの会話カードスタイルを追加
罵倒マスキングと添付画像省略ルールを整理
アーカイブ一覧にカテゴリチップを追加
日付メタ情報とカテゴリチップのレイアウトを整理
会話timestampを韓国式表記に統一
会話カードを適用
モバイルの会話カードとコードコピーボタンのoverflowを修正

コミットの流れで見ると、短い時間でかなり多くのことをした。

d3fb3d5  clean blog project files
1d36a01  clean #87 transcript
1d9ab13  restore #87 toc
ccb9139  archive #87 transcript
310b3af  show archive categories
4579858  refine archive post metadata
fb3516b  localize conversation timestamps
0564866  apply conversation cards
244a4a5  prevent mobile copy-code overflow

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

ブログ再開宣言を、実際に運用できる記録システムへ変えた。

結果

今日、ブログはもう一度開いた。

でももっと大事なのは、記事が一つ上がったことではなく、構造がもう一度整ったことだ。

Daily Reviewは毎日続けられる記録として残し、長いAI会話は別のアーカイブに分けた。会話アーカイブはexporterダンプではなく、読める公開資料に変えた。アーカイブ一覧にはカテゴリの文脈を付け、モバイルで崩れる部分も直した。

これは派手な機能追加ではない。けれどブログをもう一度生かす最初の段階としては、正確だった。

自分がまた書くためには、ブログは感情の保管庫ではなく、運用できるシステムでなければならない。今日やったことは、そのシステムの最小限の骨組みを復旧することだった。

ポートフォリオとして見ても、この点が気に入っている。

問題は明確だった。再開初日の記事が大きくなりすぎて、毎日の記録システムを壊す危険があった。解決は単純な削除ではなかった。コンテンツタイプを分け、UIを作り、メタデータを整理し、モバイルレンダリングまで整えた。

ブログをもう一度始める、と言うのは簡単だ。

今日はその言葉を、ファイル構造、テンプレート、スタイル、メタデータ、モバイル画面に変えた。