このサイトは package.json に Tailwind CSS v4 が入っていて、global.css の先頭でも読み込んでいます。
@import "tailwindcss";ですが、実際にコンポーネントのマークアップを見ると flex や px-4 のようなユーティリティクラスはほぼ出てきません。skills-grid や service-card のような、独自に命名したクラス名に対して、1300行の global.css でスタイルを当てています。
なぜユーティリティ主体にしなかったか
理由は、このサイトの見た目が「昼・夕暮・夜」という3つのムードで大きく変わるからです。Tailwindのユーティリティクラスは基本的に固定値（text-amber-400 など）を前提としており、data-mode 属性によって同じ要素の色が丸ごと変わるこのサイトの構造とは相性が良くありませんでした。CSSカスタムプロパティ（var(--accent) など）を軸にした設計にする以上、値をクラス名として静的に書き下すユーティリティファーストとは、そもそも設計思想が噛み合わなかった形です。
それでも Tailwind を残している理由
ユーティリティクラスをほぼ使わないなら Tailwind自体を外せばいいのでは、とも思いましたが、そのままにしています。理由は2つあります。1つは Preflight（リセットCSS）の恩恵で、ブラウザごとのデフォルトスタイルの差異を毎回自分で潰す手間が省けること。もう1つは、今後の記事や小さなコンポーネントを追加する際、細かい調整だけユーティリティクラスで済ませたい場面が出てくる可能性を残しておくためです。@tailwindcss/vite の導入コスト自体は設定ファイルもほぼ不要で軽いので、「使わない機能を持て余す」というほどのデメリットにはなっていません。
「導入した技術を使い切る」ことにこだわりすぎない
技術選定において、導入したツールの機能をフル活用できていないと、なんとなく「無駄に入れてしまった」という感覚を持ちがちです。しかし実際には、デザインシステムの前提（このサイトなら「CSS変数でムードを丸ごと切り替える」という設計）と、ツールの前提（Tailwindなら「クラス名で値を静的に書き下す」という設計）が噛み合わない場面は普通にあります。そういうときは無理にツールの流儀に合わせにいくより、リセットCSSなど噛み合う部分だけを享受して、あとは素のCSSで押し通す判断も十分にありだと考えています。