はじめに

派手な機能をひとつ作るより、土台を整える日のほうが、日々の摩擦に効くと思う。2026-05-04 はそういう日だった。サンプル一覧の表示崩れ、CMS の見え方、LINE 公式アカウントの導線、最後にブログ運用のルールまで、半日かけて散らかっていた細部を順に直した。

新機能ではない。けれど、次に同じ作業をするときに半分の手数で済む仕組みが手元に残った。それが今日の収穫だと思っている。

基礎となる知識

今日触ったものを、記事を読み進めるための前提として軽くだけ揃えておく。

• サンプル一覧: Onbit のサイトで「こういうものが作れます」を並べているページ。土曜の作業で 30 件まで増えた
• CMS(コンテンツ管理システム): ブログ記事を自分で書いて公開できる管理画面。Onbit は自前で作っている
• アスペクト比: 画像の縦横比のこと。16:9(横長)や 4:5(縦長)など。画像の比率と表示枠の比率が合っていないと、表示時に切れる
• IntersectionObserver: 「要素が画面に入ったか」をブラウザに監視させる仕組み。スクロールに合わせてフワッと出すアニメによく使われる
• 環境変数: サイトの設定値を、デプロイ先で切り替えられる仕組み。「公開予定の URL は決まっていないけど、枠だけ用意しておく」みたいな運用ができる

解説と使い方

今日の作業を、起きた順に並べておく。

1. 画像と枠の比率がズレていた箇所を直した

サンプルの中身画像で、CSS の枠の比率と画像本体の比率が合っていない箇所が 6 箇所あった。object-fit: cover で枠を埋めているので、ズレていると上下や左右がガッツリ切れる。

直し方は 2 通りあって、

• 画像を作り直して比率を合わせる(コストが高い)
• CSS の比率を画像の本来比率に合わせる(その場で済む)

今回は後者でいった。16:8 だった hero 枠を 16:9 に、3:4 だった人物枠を 4:5 に、それぞれ画像側に揃え直した。あわせて再発検知用に scripts/check-image-aspect.py という小さなスクリプトを置いた。各サンプルの HTML をパースして、<img> の実画像比率と CSS の aspect-ratio 指定を突き合わせ、ズレを警告するだけのものだけど、次に同じ罠を踏んだら早く気付ける、と思う。

2. サンプル一覧のカードがスクロールしても出てこなかった

スマホで /samples/ を開くと、ヘッダーの下に何も見えない、という状態になっていた。

調べると、IntersectionObserver の threshold: 0.12(要素の 12% が画面に入ったら発火)で安心していたところ、サンプル 30 件で section が縦長になりすぎて、画面に section の 12% も入らない位置でずっと止まる、という状況になっていた。すると in-view クラスが永久に付かず、カードは opacity: 0 のまま。

一覧では reveal アニメ自体を外して、常時表示にした。30 件もあるとアニメは邪魔のほうが大きい、という判断。中身を増やしたことで動かなくなる API は、最小サンプルでは見えない罠だなと感じた。

3. サムネが壊れていた 4 件を修正した

カードのサムネが、4 件分縦長や正方形になっていた。一覧コンテナは aspect-video(16:9)を指定していたので、縦長サムネを流し込むと中央が大きく切れて変になる。

hp-cosme-pink lp-foodtruck-vibrant lp-photo-studio には 16:9 専用の thumb.jpg を新規生成して frontmatter で指定し直した。lp-coaching-premium だけは既存の hero 画像が 16:9 だったのでそちらに切り替えた。これで 30 件すべてのサムネ表示が安定した。

4. 連絡導線に LINE 公式アカウントを追加した

問い合わせ手段がメールしかなかったので、LINE 公式アカウントへの導線を仕込んだ。実装としては、

• src/config/contact.ts に MAIL_TO / LINE_URL / LINE_ID / hasLine を集約
• 環境変数 PUBLIC_LINE_URL がセットされている時だけ Footer / FinalCTA / Contact ページに「LINEで送る」ボタンが自動で出る作り
• 未設定なら従来通り(LINE 関連 UI は何も出ない)

LINE のアカウント自体は別途作って、Cloudflare Pages の管理画面に URL を変数として登録すればすぐ反映される。準備は枠側にあって、開示はあとから、を運用に組み込めるのがいいなと思っている。

5. CMS の記事一覧に公開日と更新日を併記した

自前 CMS の管理画面で、記事カードに表示されている日付がひとつだけ(更新日 or 公開日のどちらか)になっていた。「これって公開日?更新日?」が一目で分からなかったので、両方並べた。

あわせて並び順を select で切り替えられるようにした(更新日の新しい順 / 古い順、公開日の新しい順 / 古い順、の 4 通り)。並び順は URL の ?sort= と双方向に同期するので、リロードしても状態が残る。書きかけの下書きを公開日順で見ると、まだ公開していない記事が並ぶので、その場合は更新日にフォールバックする処理だけ入れた。

途中、こちらが「作成日」と読み替えてしまっていて、不要な createdAt フィールドを足してしまった。本来は「公開日」だったので、その分は revert している。会話ログでの言葉のすり合わせは、もう一段念を入れて確認したほうがよさそう、と感じた。

6. ブログ記事の構造テンプレと文体プロファイルを整理した

書き手側のルールも整えた。

構造のテンプレとして、技術ブログ用の 6 セクション(はじめに / 基礎となる知識 / 解説と使い方 / やってみた結果 / まとめ / 参考文献)を docs/blog-writing/technical-article.md に置いた。同時に /onbit:blog:new-technical <テーマ> というスラッシュコマンドも仕込んで、テーマを 1 行渡せばこの構造で骨組みが返ってくる、という運用にした。

夜になって、メモから抽出した文体プロファイル(ghostwriter-style.md)を別途渡してもらったので、構造テンプレと並べて配置した。「構造は本ファイルが優先、文体はプロファイルが優先、対外発信ルール(本業の言及禁止など)は memory が最優先」という優先順位を統合ルールに明記してある。

ちなみに、この記事自体がそのプロファイルを使って書いた最初の 1 本になっている。

やってみた結果

数字でまとめると:

領域	修正前	修正後
アスペクト比のズレ箇所	6 件	0 件(検査スクリプトつき)
一覧で表示されないサムネ	4 件(うち 2 件は 404)	0 件
サンプル 30 件のカード表示	スマホで非表示	全件表示
連絡導線	メールのみ	メール + LINE(env で切替)
CMS 一覧の日付	1 つだけ	公開日 + 更新日を併記、ソート切替
ブログテンプレ	なし	6 セクション + 文体プロファイル + slash command

うまくいった点:

• 細部の修正が、それぞれ小さい改善でも、合わせると体感がだいぶ変わる
• 「次に同じ作業を半分の手数でやれる仕組み」(検査スクリプト・テンプレ・統合ルール)が残った
• LINE 導線のように「準備だけ仕込んで開示はあと」のパターンを実装できた

うまくいかなかった点:

• サンプル説明文の話し言葉化のついでに、トップページや About ページまで口語化したら違和感が出て、結局 revert した。トーンは場所で使い分ける必要があると気づいた
• 「作成日 / 公開日」の言葉のすり合わせで一往復したので、用語の確認は最初にもっと強くしたほうがいい

今後やりたいこと:

• 文体プロファイルを使って書いた記事をいくつか溜めて、ズレが見えたらプロファイルを進化させる

まとめ

派手な機能を作る日があってもいいし、こういう「整える日」も同じくらい大事だと思っている。土台が緩んだままで新しいものを乗せても、結局あとで剥がれる。

今日のメモは、未来の自分に「ここまでは整っている」を伝えるために残しておきたい・・・というのと、もう一つ。整え直した日が記事として残ることで、「ちゃんと見直しに時間を使った」という事実そのものが、自分の運用の足場になる気がしている。

参考文献

• 関連記事: samples-30-sprint-2026-05-04(土日に 30 件まで増やしたスプリントの記録)