A3ro.cc のソースコードを見ると、tailwind.config.mjs は存在しません（厳密にはセットアップ時に除外しました）。 代わりに目立つのは、各 .astro ファイルの末尾にある <style> ブロックと、昔ながらのCSS変数定義です。

なぜ Tailwind CSS を使わないのか？

誤解のないように言うと、私はTailwind CSSが大好きですし、業務では必須レベルで使っています。 しかし、今回のプロジェクトにおいては以下の理由で採用を見送りました。

  1. 「AIエージェントにとっての」可読性 CursorやWindsurfを使って開発する際、長いクラス名の羅列はコンテキストウィンドウを消費します。 また、AIに修正を指示する際、「divのクラスにmt-4を追加して」と言うより、「.container の margin-top を調整して」と伝える方が、構造とスタイルが分離されていて意図が伝わりやすいケースがありました。

  2. Bloggerからの移植性 前身のBloggerブログでは、大量のCSS変数を定義してテーマを管理していました。 この資産（変数の設計思想）をそのまま引き継ぐには、TailwindのUtility Classに書き直すよりも、CSS変数をそのまま使い回せるVanilla CSSの方が手っ取り早かったのです。

  3. AstroのScoped CSSが優秀すぎる Astroはデフォルトでコンポーネント単位のCSSスコープを提供します。 Vue.jsの <style scoped> と同様に、クラス名被りを気にする必要がありません。 BEMのような厳格な命名規則も、Tailwindのようなユーティリティファーストも不要で、「そのコンポーネントに必要なスタイルをただ書く」だけで安全にスタイリングできます。

実装例：グラデーションアンダーライン

例えば、記事中の H2 タグに施しているグラデーションの下線。

  .prose h2 {
    position: relative;
    display: inline-block;
    padding-bottom: 5px;
    border-bottom: none;
  }

  .prose h2::after {
    content: '';
    position: absolute;
    left: 0;
    bottom: 0;
    width: 100%;
    height: 2px;
    background: var(--gradient-primary); /* ここに変数が活きる */
    transform: scaleX(0);
    transform-origin: bottom right;
    transition: transform 0.3s ease;
  }

  .prose h2:hover::after {
    transform: scaleX(1);
    transform-origin: bottom left;
  }

このように var(--gradient-primary) を再利用できるのが変数の強みです。 Tailwindでも bg-gradient-to-r などで実現できますが、独自のグラデーション定義を tailwind.config.js に書く手間と、CSS変数でグローバルに定義する手間の差は、今回の規模感では後者に軍配が上がりました。

なぜVanilla CSSか

「流行っているから使う」のではなく、「資産（BloggerのCSS）を活かすために使う」。 この判断基準を持てたことが、移行プロジェクトを短期間で完了できた要因の一つです。 AstroのScoped CSSは、古き良きCSSを書く楽しみを思い出させてくれます。