コンポーネントの整理と、スマホ表示の構造

1. 一つのファイルが長くなりすぎた問題

前編で作った器に記事の一覧を並べてみると、一つのファイル（page.tsx）の中にデザインのコードがどんどん長くなっていきました。
記事カードの見た目、タイトルの装飾、日付の表示……全部が一つのファイルに詰め込まれている状態です。
動きはするけれど、どこに何が書いてあるのか見通しが悪い。

そこでClaudeに「もっと管理しやすくする方法はありませんか？」と聞いたところ、「記事カードのデザインを別のファイルに切り出しましょう」と提案されました。
具体的には、ArticleCard.tsx という専用のファイルを作り、記事1つ分のデザインをそこにまとめるという方法です。

これが「コンポーネント（部品）」という考え方でした。
記事カードを独立した部品にしておけば、トップページだけでなく、カテゴリページや検索結果ページでもまったく同じデザインをそのまま使い回せます。
そしてデザインを変更したくなったときも、ArticleCard.tsx を一箇所直すだけで、サイト中のカードが同時に更新される。

もし部品化せずに同じデザインを各ページにコピーしていたら、修正のたびに全ページを探して直して回ることになります。
この方法を知ったことで、ウェブサイトは一枚の大きな絵ではなく、小さな部品の組み合わせで成り立っているのだという感覚がつかめてきました。

2. 文字の大きさと色で「情報の優先順位」を伝える

ここからの見た目の設定には、「Tailwind CSS」というスタイリングの仕組みを使っています。あらかじめ用意されたクラス名を指定するだけで、色や大きさなどを手軽に調整できるものです。

記事カードの部品ができたので、次はその中身の見た目を整えていきます。
タイトル、日付、カテゴリ、抜粋文——カードの中にはいくつかの情報がありますが、全部を同じ大きさ・同じ色にすると、どこを見ればいいのかわからない画面になってしまいます。

Claudeから教わったのは、「情報の重要度に合わせて見た目を変える」という考え方でした。
読者が最初に目にすべき情報はタイトルなので、最も濃い色（text-gray-900）を使い、視線が自然とそこに向かうようにする。
一方で、日付やカテゴリは補助的な情報なので、少し薄い色（text-gray-600）にして存在感を抑える。
こうすることで、読者は意識しなくても「タイトル→カテゴリ→日付」という順序で情報を受け取ることができます。

もう一つ、Claudeが提案してくれたのが、抜粋文の表示を2行までに制限する設定（line-clamp-2）でした。
記事によって抜粋文の長さはバラバラです。
何も制限しなければ、長い抜粋文のカードだけ背が高くなり、一覧画面の並びがガタガタになってしまいます。
2行で切って末尾を「…」にすることで、どんな記事でもカードの高さが揃い、一覧全体が整った印象になりました。

一つひとつは小さな設定ですが、こうした細かい調整の積み重ねが、サイト全体の「なんとなく見やすい」という印象を作っていることを実感しました。

3. 画面の幅に合わせて列数を変える仕組み

記事カードの見た目が整ったので、次はそれを画面上にどう並べるかの設計です。
パソコンの広い画面では3列に並べたいけれど、スマホの狭い画面で3列にしたら文字が小さすぎて読めません。
画面の幅に応じてレイアウトを切り替える必要があります。これが「レスポンシブ対応」です。

ここで使ったのは、「グリッド」という仕組みでした。

設定自体はシンプルで、スマホでは1列、タブレットでは2列、デスクトップでは3列と指定するだけです。

ただ、ここでClaudeが教えてくれた「モバイルファースト」という考え方が印象に残っています。
最初に画面の広いパソコン向けを作って、それをスマホ用に縮めていくのではなく、まずスマホの1列表示を基本として作り、画面が広くなるにつれて列数を増やしていく。
これが今のウェブ開発の標準的な進め方なのだそうです。

発想が逆だったことに気づかされました。
「大きいものを小さくする」のではなく「小さいものを大きくしていく」。
この順序で作ることで、コードもシンプルになり、どの画面サイズでも無理のないレイアウトが自然にできあがりました。

4. スマホメニューの「重なり順」を整理する

スマホ対応で一番手こずったのが、画面右上の三本線（ハンバーガーメニュー）の実装でした。
三本線をタップするとメニューが開き、元の画面が少し暗くなる。よく見かける動きですが、これを実現するには「画面上の要素がどの順番で重なるか」を正しく管理する必要がありました。

Claudeに仕組みを聞いたところ、「3枚の紙が重なっているとイメージしてください」と教えてくれました。
一番下に元の記事ページがあり、その上に画面を暗くするための半透明の膜を敷き、一番上にメニューの箱を置く。
この3層構造を、z-index という数値で管理します。

下から順に0、40、50と数値を割り当てることで、どの要素が手前に来るかをブラウザに指示できる仕組みです。

ここで大事だったのは、「とりあえず大きな数字を入れておけば手前に来る」という雑なやり方をしないことでした。
役割ごとに数値を決めて、層の構造を明確にしておく。
そうしないと、後から要素を追加したときに重なりが崩れて、ボタンがメニューの裏に隠れてしまったり、タップできなくなったりする原因になります。

目に見える動きの裏側で、こうした「重なりの設計」が必要だということは、実際に作ってみるまでわかりませんでした。

後編のまとめ

後編で取り組んだのは、記事カードの部品化、文字の色や大きさによる情報の整理、画面幅に応じたレイアウトの切り替え、そしてスマホメニューの重なり管理でした。

前編で感じた「なぜ？を聞くことの大切さ」は、後編でも同じでした。
文字の色を一段階薄くする理由、画面の狭い方から先に作る理由、重なり順に数値を割り振る理由。
どれも「とりあえずこう書けば動く」で済ませることはできたかもしれません。
でも、理由を聞いて納得してから書いたコードは、後から見返したときに「なぜこうなっているのか」を自分で説明できます。
それが、自分の中に残る確かな基準になっていると感じています。

前編・後編を通して、ブログとしての形はひとまず整いました。次回はいよいよ、このブログをインターネット上に公開する作業に入ります。
Vercelでのデプロイと、環境変数の設定について記録していきます。