爆速な技術ブログを作り直した理由
このブログ 「ともきちのエンジニア成長記」 は、エンジニアとしての学習・開発・失敗・改善を記録していく場所です。
実は今回、ゼロからの新規作成ではありません。もともとはNext.jsで構築していましたが、技術構成から完全に見直して作り直すことにしました。それは単なる気まぐれではなく、これまでの個人開発を通じた「反省」と「気づき」の結果です。
なぜ今、作り直す必要があったのか
大きな理由は、以前のブログが「技術ブログ」としての本質を見失い、過剰に肥大化していたことです。
- 機能と演出の盛りすぎ: 以前の構成では、見た目のインパクトを重視してリッチなアニメーションを多用していました。しかし、情報を探しに来た読者にとって、過剰な演出はかえってノイズになります。「技術ブログは、まず内容が速く届くべきだ」という当たり前のことに立ち返りました。
- 保守コストの増大: React Server Components（RSC）周りのアップデートや脆弱性対応が続き、次第に「記事を書く時間」よりも「ブログのシステムを維持する時間」が増えてしまいました。
- 「適材適所」への疑問: Next.jsはWebアプリ開発には最強のツールです。しかし、認証もDBもAPIも不要な、更新頻度がそこまで高くない個人ブログに、これほど巨大なフレームワークを使い続ける必要があるのか。その問いに対する答えが、今回のフルリニューアルです。
これまで旅行ブログの運営で学んだSEOの重要性や、AI旅程生成サービス Tabidea で経験したフルスタック開発の知見を活かし、今の自分に最も適した「思考を整理して速く届ける場所」を再定義しました。
技術選定の舞台裏：なぜAstroだったのか
多くのモダンな選択肢を検討しましたが、最終的に Astro を選びました。ここに至るまでには、いくつかの葛藤がありました。
検討した他のフレームワーク
- Vite + React: 開発体験は非常に軽快です。しかし、Markdownのパース、記事一覧の生成、RSS、サイトマップ作成などを一から自作・管理する手間を考えると、コンテンツ配信に特化したAstroに一日の長がありました。
- Remix / TanStack (Router/Start): Web標準に寄せた設計や型安全なルーティングはエンジニアとして非常にそそられる選択肢でした。ただ、フォーム処理や動的データ取得を必要としない今回の構成では、宝の持ち腐れになると判断しました。
- Vue (Nuxt) / SvelteKit: 優れたエコシステムを持っていますが、自分の主戦場であるReact/TypeScriptの知見を活かし、開発スピードを最大化するために今回は見送りました。
Astroを選んだ決定打：アイランドアーキテクチャの魅力
Astroは「コンテンツ中心のサイト」を作るために設計されています。ビルド時にMarkdownを純粋なHTMLへ変換し、クライアント側へ不要なJavaScriptを送らない設計は、今回の目的に完璧に合致しました。
特に Astro Content Collections による型安全な記事管理は、後述するAIエージェントと開発を進める上で、最強のガードレールとして機能してくれます。
このサイトの技術構成と設計思想
長く、静かに、そして速く運用し続けるために、構成は徹底してシンプルかつモダンにしています。
- Core: Astro (React/MDXはあえて非採用)
- Styling: Tailwind CSS v4
- Tooling: TypeScript, Biome, pnpm
- Infrastructure: Cloudflare Workers Static Assets + GitHub Actions
徹底した「静的」へのこだわり
「まず静的なHTMLとCSSだけで読めること」を最優先にしています。
- 記事本文はビルド時に完全にHTML化。JavaScriptが無効な環境でも閲覧可能です。
- クライアント側でのハイドレーションを最小限に抑え、Lighthouseのスコアは常に満点に近い状態を維持します。
- 多言語対応（i18n）についても、複雑なライブラリに頼らず、ディレクトリベースのシンプルな設計を採用しました。
AIエージェントと共創する開発プロセス
今回のブログ構築において、特筆すべきは開発スタイルです。私は現在、Claude Code、Codex、Gemini CLIなどのコーディングエージェントを片時も離さず開発しています。
AIに実装を任せる時代だからこそ、人間側が 「設計思想と制約」 を明文化しておくことが重要になります。
このサイトではあえて以下の制約を設けています。
- 「Reactを導入しない」
- 「記事をクライアント側で動的に描画しない」
- 「不要な外部スクリプトを増やさない」
これらの制約をプロンプトやドキュメントに焼き付けておくことで、AIが良かれと思って構成を複雑化させるのを防ぎ、長期間メンテナンス可能なコード品質を維持しています。AIは実装を速めてくれますが、サイトの「純度」を守るのは人間の役割です。
多言語対応：日本語と英語で発信する理由
このブログは、 /en/ 配下で英語版も展開します。これには、単なる露出増加以上の意図があります。
技術情報の一次ソースは常に英語です。将来的に自分の考えや実装方針を英語圏のエンジニアにも伝えられるようにしておくことは、キャリアの選択肢を広げるだけでなく、思考の解像度を上げることにも繋がります。日本語で考えたことを、英語でもう一度再定義する。そのプロセス自体を、自分の成長の一部にしたいと考えています。
これから書いていくこと
ここでは、完成された「正解」だけを載せるつもりはありません。むしろ、実際の開発現場で直面する泥臭い試行錯誤を言語化していきます。
- 個人開発の設計と思考: Tabidea開発で直面した技術的負債との戦いや、設計の意思決定。
- AIエージェントとの協調: どのようにAIに指示を出し、レビューし、プロダクトを形にしていくかという実践論。
- インフラと運用: Cloud RunやCloudflareなど、低コストかつ堅牢なシステムを構築するためのTips。
- フロントエンドのUX: 流行りに流されず、「使いやすさ」と「速さ」を両立させるための実装。
- セキュリティと保守: 個人開発で見落とされがちな認証や機密情報管理のベストプラクティス。
おわりに
このブログは、一度立ち止まって「自分にとって本当に必要なツールは何か」を問い直した結果です。
最初から大きなメディアを目指すのではなく、日々の開発で得た小さな手応えや、痛烈な失敗を、静かに、しかし情熱を持って積み上げていきたい。数年後に読み返したとき、エンジニアとしての成長が一本の線として見えるような、そんな場所に育てていきます。
速く、軽く、読みやすく。 新しくなった「ともきちのエンジニア成長記」を、どうぞよろしくお願いします。
