自分がWebサイト制作で使っているツール・技術の選定理由をまとめました。「なぜそれを選んだか」を中心に書いています。
🏗️ インフラ：Cloudflare Pages
→ Cloudflare Pages
コストに上限があって、青天井の請求が来ない安心感が一番の理由です。無料枠が寛大で、課金が必要になっても月額5ドルベースで運用できます。WorkersではなくPagesを選ぶのは、クライアントがNS移行できないケースで外部DNSからサブドメインCNAMEを向けられるのがPagesのみだからです。
不採用にした理由
- AWS/GCP：コスト構造の把握に自信がなく、心理的負担が大きい
- Vercel：メンバー1人あたり月額20ドルの人頭税がクライアントワークで痛い
- VPS（Coolify等）：保守管理のコストが「ただのWebサイト」には過剰
⚡ フレームワーク：Astro
→ Astro
CloudflareはV8 Isolate環境で動いていて、通常のNode.jsサーバーを前提にしたフレームワークだと「Vercelでは動いたのにCloudflareで動かない」が起きやすいです。AstroはCloudflareとの相性が最初からよく、乗り換えてからこの問題がほぼなくなりました。Webサイト制作という文脈での構造のシンプルさも気に入っています。2026年1月にCloudflareがAstroを正式に買収し、開発チームがCloudflareに合流しています。
Webアプリを作る場合はReact Routerを使っています。用途で明確に棲み分けています。
不採用にした理由
- Next.js：OpenNextパッチが必要でCloudflareでのビルドが重い。構造的な複雑さもWebサイト制作にはオーバースペック
🛠️ 言語・ランタイム
→ .astro + tsx（TypeScript）/ ni
基本はAstro標準の.astroファイル。MotionによるアニメーションやuseState・useEffectが必要な箇所はtsxを使います。後々Webアプリ開発にステップアップするための訓練も兼ねて、型安全なtsxに慣れておきたいという理由もあります。
パッケージマネージャーはpnpmをデフォルト。ただcreate時だけ使って、普段はniを使うようにしています。たまにnpmで作ってる外部コーダーの修正対応とかも発生するので、普段からniを使うように習慣化しています。
💻 IDE：Zed
→ Zed
エディタ選びの基準は「Claude CodeがIDEのターミナル内で日本語入力込みで普通に使えるか」のほぼ一点です。日本語IMEとの相性でターミナル内の入力がおかしくなるケースが意外と多く、ここで躓くと開発体験が大きく落ちます。
以前はAntigravityを使っていましたが、Zedのアップデートでこの問題が解消されたのを確認して乗り換えました。現在の潮流もZedが来ていて、MacユーザーはGhosttyやtmuxと組み合わせて使うケースが多い印象です。
不採用にした理由
- Antigravity（GoogleのVS Codeフォーク）：知名度はあるが実務で選ぶエンジニアはほぼいない印象。Claude Code補助として置いていた程度
- Zed（以前）：Windows環境での日本語入力時のGPUレンダリング問題（アップデートで解消済み）
🖥️ 開発環境：Windows / Ubuntu
→ 用途で使い分け
クライアントのWebサイト制作はWindowsメイン。IllustratorやPhotoshopを使いたい場面がちょくちょくあるので、そこを捨てきれないのが正直なところです。個人開発（競技プログラミング等）はUbuntuを使っています。
WSL2を使っていた時期もありますが、Webサイト制作という文脈ではそこまで恩恵を実感できなくてやめました。
IMEとターミナルの相性問題はOSではなくエディタ・ターミナルごとの話になります。
🤖 AIエージェント・モデル
→ Claude Code（メイン）/ Sonnet 4.6中心の使い分け
ターミナルからClaude Codeで指示を出すのが開発の基本スタイルです。コンポーネントの設計や保守性の確認など「単に動く以外のこと」が気になる場面ではコードに目を通したいので、IDEはあった方がいいという立場です。
プロトタイプ生成時はfrontend-design Skillをほぼ毎回使っています。効果の厳密な検証はしていないですが、おまじない的に使い続けています。
モデルの使い分けはこうしています。
| モデル | 使いどころ |
|---|---|
| Claude Sonnet 4.6 | メイン。ほぼこれで十分 |
| Gemini 3.5 Flash | Claude APIエラー時のフォールバック兼、単純タスクのトークン使用量分散先。ゴールが明確な単純タスクには速い、ただし相談には向かない（イエスマン体質） |
| Claude Opus 4.8 | Sonnetで手に負えない問題（Cloudflareのデプロイエラー等） |
🧩 コンポーネント設計
→ 2層構造（common/ + pages/）
common/に全ページ共通のパーツ、pages/の中にページごとのディレクトリを作ってそのページ固有のコンポーネントを置いています。「このページのコンポーネントを直したい」というときに迷わず辿り着けるのが気に入っています。コンポーネントの行数は100行を目標に、最大でも200行以内を目安にしています。
不採用にした理由
- Atomic Design：Webサイトのパーツは一期一会が多く「MoleculeかOrganismか」を悩む時間が不毛だった
🖼️ 画像最適化：AVIF + WebPフォールバック
→ Astro <Image />コンポーネント
AVIFをデフォルト・WebPをフォールバックとして出力しています。caniuse調べでAVIFの普及率はすでに約93%で、非対応なのはIEや一部の旧ブラウザのみです。実質AVIFだけでも問題ないですが、念のためWebPも出しています。
🧹 Linter / Formatter
→ Biome（個人開発のみ）
個人開発ではBiomeを使っています。ただWeb制作においてはAIが最初から整ったコードを出すことと、案件ごとに一人で開発しているのでチーム間のスタイル統一という恩恵が発生しないこともあって、ありがたみをあまり感じていないのが正直なところです。
🧪 テスト
→ ほぼ書かない（フォームのみ手動確認）
Webサイト制作においては現状テストをほぼ書いていません。お問い合わせフォームだけ毎回手動で確認しています。
PlaywrightでスクリーンショットをとってAIで自律的にUI修正させるアプローチは試したことがありますが、今は逆に使いにくくなった感覚があります。AIの精度が上がったことで残っている修正箇所がスクリーンショットでは判別しにくい細かい差異（アニメーションのイージング、数ピクセルのパディング等）になってきていて、結局自分の目で確認するしかない場面が多いです。以前の精度が低いAI時代のほうがこのフローは有効でした。Webアプリ開発であればVitestもPlaywrightでの確認も恩恵が大きいですが…
🎨 スタイリング・アニメーション
→ Tailwind CSS / 用途でMotion・GSAPを使い分け
CSSはTailwindでHTMLと同じファイルに書きます。認知負荷を下げるためです。
アニメーションは以下の基準で使い分けています。
| 用途 | ツール |
|---|---|
| 画面遷移 | pageTransition API（ブラウザ標準） |
| マイクロインタラクション | Motion |
| スクロール連動・WebGL等のリッチな演出 | GSAP |
📝 CMS
→ microCMS（新規）/ Headless WordPress + SSG（既存資産）
新規クライアントにはmicroCMSを採用。日本語ローカライズが優れていて学習コストが低いです。
既存のWordPressを活かしたHeadless化は、更新をWebhookで受け取ってCloudflareの該当プロジェクトを再デプロイするSSG構成で運用しています。SSRが理想ですがCloudflare環境での構築でつまずいた過去があり、一旦これで安定運用中です。
📬 フォーム・メール送信
→ Resend（本命）/ Worker-mailer（フォールバック）
本命はResend、またはCloudflareエコシステム内のEmailSend（パブリックBeta）です。既存のSMTPを使わなければいけないケースでは、自作のOSS「Worker-mailer」を使ってCloudflare上からメール送信するフォールバックを用意しています。
📦 バージョン管理
→ GitHub
デファクトスタンダードなのでGitHubを使っていますが、特定のプラットフォームへの依存を避けることは意識しています。いざとなればwrangler deploy一発でリモートリポジトリを経由せずCloudflareに直接デプロイできる状態を保っています。
⌨️ 入力デバイス：自作キーボード roba + 大西配列カスタム
→ 左右分割型自作キーボード「roba」
大西配列をベースにした独自カスタムを乗せています。慣れるまで2ヶ月かかりましたが、今はこちらの方が速くなった実感があります。AI開発時代にタイピング速度の理論値を少しでも上げておきたい、という動機で移行しました。