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