Blog

なぜ今、ブログにサイドバーが消えつつあるのか｜小説消費との意外な共通点 かつて、ブログといえばサイドバーが定番だった。カテゴリ、人気記事、タグクラウド、月別アーカイブ……読み手は気になったブログを見つけたら、作者の他の記事を「読み漁る」文化があった。小説の世界でも同様で、気に入った作家を見つけたら、その人の他の作品も読んでみようと思うのが普通だった。 だが、今は違う。ふと気がついた。静的サイトジェネレーター（SSG）で人気のテーマをいくつか見ていたところ、どれもサイドバーがない、もしくは最小限しかない。おや？と思った。 その直後、10年ほど前に小説家が語っていた話を思い出した。「昔は作家買いをしてくれる読者が多かったのに、今は“バズった1作品だけ読まれて、他のシリーズには手が伸びない”。」 この2つは、別の現象ではない。読者行動が“全体を見る”から“単体消費”に変わったのだ。 読者は「読み漁り」から「単体消費」へ 昔（〜2010年代前半） 好きになったブログや作家の他の作品も読む サイトを「回遊」して楽しむ サイドバーはそのための道標だった 今（2020年代） SNSや検索でたまたま見つけた“1記事だけ”を消費 他の記事や作品を追いかけない サイドバーが減ったのは、それがあまり使われなくなったからだ Webと小説の共通点：バズった1本主義 この傾向はブログに限らない。Web小説、ラノベ、Z世代の情報消費すべてに共通している。 SNSで話題になった「1冊だけ」が読まれる 作家名は覚えられない。シリーズものは続かない 読者は“その瞬間の満足”だけを求めている 北海道大学の「ゼロ年代の情報行動の変容」や、沖縄国際大学の学報『羅針盤』でも、こうした読者行動の変化は観察されている。今の消費行動は「広く・浅く・瞬間的」であり、過去のように「作者を追いかける」スタイルは主流ではなくなっている。 では、設計はどう変えるべきか？ サイドバーはあえて最小限にする 目次（TOC）だけで十分。記事に集中してもらう 回遊してほしいなら、記事の文中や末尾に自然な導線を仕込む 読み漁り型の読者にも対応する 記事が増えたら、「リンク集」や「このブログの読み方」ページを用意 タグやカテゴリは読者よりも自分のための構造整理と割り切る 読者行動の変化を、設計にどう活かすか ネットを長く使ってきた人ほど、サイドバーがないと違和感を覚えるかもしれない。それでも、時代は変わり、読み方も変わった。 今の読者は、1記事を読んだらすぐ離れていく。でもその1記事の中で「次の導線」が自然にあれば、ふとクリックしてくれることもある。読者が変わったなら、こちらの設計も変えていくしかない。 かつての読み漁り文化を懐かしむ気持ちを持ちつつ、今の単体消費型の行動様式にどう向き合うか。この変化を受け入れた上で、どんな情報設計をすれば伝わるのか。それを考えること自体が、ネットの読み手・書き手にとって価値ある営みだと思う。 昔の「読み漁り」も、今の「単体消費」も、それぞれの時代に合った読み方。 重要なのは、それに気づき、記録し、活かすことだ。 設計は、観察と気づきから始まる。

Hugoで記事が表示されない？ Hugoを使って記事を書いていたところ、記事が表示されないという現象に遭遇した。フロントマターに draft: false を設定しており、ファイル名やフォルダ構成にも問題はない。ビルドエラーも出ていない。それでも記事が出ない。 その原因は、日付フィールドが“未来”として扱われていたためだった。日本時間では「今日」でも、Hugoの内部処理では「まだ未来」だったのである。 Hugoの内部時間処理はUTC基準 Hugoでは、Markdown記事のフロントマターで指定する date: フィールドが、内部的に UTC（協定世界時）基準で解釈されている。そのため、たとえば日本時間で 2025-05-09 を指定した場合でも、 日本時間（JST）では5月9日 → 午前中 UTCではまだ5月8日 という時差がある。この状態でHugoを通常起動すると、「未来記事」として非表示扱いされる。 これは特に index.md を使った Leaf Bundle構成の記事や、content/ 以下に日付ベースで管理している場合に混乱を招きやすい。 初心者が気づきにくい理由 この挙動が厄介なのは、以下のような要因があるためだ： ビルドしてもエラーが出ない hugo server を使っても、記事が非表示である理由の明示はない draft: false にしていても関係なく非表示になる フォルダ構成やテーマ設定の問題と勘違いしやすい 結果として、「なぜか記事が出ない」という状態に陥り、構文ミス・設定ミスなどを疑って時間を浪費することになる。 対策①：date: を「過去日」にする もっとも単純で確実な解決法は、フロントマターの日付を現在の日本時間より確実に過去の日付にしておくことである。 例： date: "2025-05-08" 記事の執筆日と公開日を分ける設計にしておけば、JSTとUTCのズレによる非表示問題を防げる。 対策②：--buildFuture を付けて起動する 開発中で、あえて未来日付で記事を作成したい場合は、Hugoの起動オプションに --buildFuture を付けると、未来日付の記事もビルド対象になる。 hugo server --buildFuture ただし本番環境では、hugo 単体でビルドする限りこのオプションは無効なので注意。 対策③：ISO 8601形式でタイムゾーンを明示する（限定的） タイムゾーンを明示した形式： date: "2025-05-09T00:00:00+09:00" Papermodなど一部のテーマではこの表記に対応しているが、Hugo本体の表示制御には影響しない。表示可否に関しては、依然としてUTC基準で判断されるため、根本的な解決にはならない。 まとめ：日付の罠を避けるには Hugoでは、date: フィールドがUTC基準で処理されるという前提を押さえておくことが重要である。記事が表示されない場合、構文や構成ミスの前に「日付が未来になっていないか」を確認するのが鉄則だ。 実務上は、 date: は1日前など、明示的に過去日に設定する --buildFuture は開発時限定で使う といった運用を取り入れることで、この静かに発動する“非表示バグ”を回避できる。 この挙動を知っているだけで、Hugo運用はぐっと安定するだろう。

はじめに このサイトを作成することにしたきっかけです。 勤務場所や業務内容が変わる経験を経る中で、自分のスキルを棚卸しし、体系的に整理する必要性を強く感じるようになりました。また、関わる人々が変化することで、実績だけでは伝わらない場面も増え、資格などの客観的な証明を通じて、自分の能力に「外から見える形での説得力」を持たせることの重要性を再認識しました。 同時に、インプット中心の学習には限界があることも実感していました。若い頃から「何かに熱中→やめる→数年後に再開→記録が残っておらず一からやり直す」という非効率なサイクルを何度も繰り返してきました。その反省から、現在はアウトプットを重視し、学習内容や試行錯誤を記録するようにしています。 このWebサイトは、そうした記録をより体系的に蓄積し、共有可能な形に整理することを目的として構築したものです。 書式の選定 当初はWordやExcelで記録しようとしましたが、Microsoft製品はプラットフォーム依存が強く、将来的な移植性に不安がありました。PowerPointで手順書を作成しようとしたこともありましたが、1ページに収める制約や、見た目の調整（フォント選び、配置調整など）に多くの時間を取られてしまい、本質的な記述に集中できないことに気づきました。 そうした経緯から、視覚装飾に煩わされず、構造化された記録が可能なMarkdown形式に落ち着きました。 SSGの選定 Markdownでの記録が進む中、それをWeb上で公開・再利用可能にする方法として、**静的サイトジェネレータ（SSG）**の導入を検討しました。 まず試したのはDocsifyで、シンプルな見た目には好感を持ちましたが、数式表示の対応が難しく、数時間を費やしても解決に至らず断念しました。次に試したAstroも、数式問題が残ったうえ、見出しのデフォルトスタイル（特にフォントサイズ）が大きすぎることが気になり、カスタマイズに手間がかかると判断して除外しました。 最終的に選んだのがHugoです。Hugoは数式表示がスムーズで、Markdown資産との親和性が高く、デザインと運用のバランスも良好であったため、現時点では最適な選択と考えています。 なお、今後さらに適したSSGが現れた場合には、容易に移行できるよう、サイト構成はモジュール的に設計しています。 今後の展開 当サイトでは、主に以下の内容を発信・整理していく予定です。 資格試験の学習メモ 学習過程での要点整理、理解の深化、試験対策のための記録を行います。 Pythonスクリプトの提示 日々の業務や学習の中で使用しているミニツールやコード片を紹介し、再利用性と学習効率の向上を図ります。 このように、本サイトは「記録と再利用を重視した知的蓄積の場」として育てていきたいと考えています。