なぜブログを作ったか、なぜAstroを選んだか
導入
フロントエンドは昔から苦手でした。 実務でも趣味でも、気づけばバックエンドとCLIツールばかり作っていて、ブラウザ側の技術にはほとんど触れていません。 普段の作業はほぼターミナルで完結するため、フロントを学ぶ必要性すら感じない生活が続いていました。
正直に言うと、フロントエンドを避けていた理由の一つに偏見がありました。 「フロントエンドはコンピュータのエンドユーザーが使う機能なので、わざわざ作るのは効率が悪い。エンドユーザーが少しコンピュータを勉強したほうが、全体的に効率的だろう」 そんな風に思っていました。
しかし実務を重ねる中で、お客様は技術の詳細を理解しているわけではないという当たり前の事実に気づきました。 どれだけ裏側で優秀なアルゴリズムやアーキテクチャを組んでも、フロントエンドがちゃんとしていないと「なんか微妙なサービス」と思われてしまう。 逆に、バックエンドの実装は大したことなくても、UI/UXがしっかりしていれば「すごいサービス」と評価されることも珍しくありません。
お客様にとって、システムの価値は目に見える部分で判断される。 これはエンジニア的には悔しい現実ですが、ビジネスの世界では避けられない真実でもあります。
もし将来的に自分でプロダクトを作って売るなら、フロントエンドの知識は避けて通れない。 そう気づいた時、ようやく重い腰を上げることにしました。
何度か「勉強しよう」と思ったことはありますが、直接自分のワークフローに関係ない技術の勉強はどうしてもモチベーションが続かず、教材を買っても結局手を動かさない…そんな繰り返しでした。
そこで発想を変えて、**「日常の作業に無理やりフロントエンドを組み込む仕掛け」**を作ることにしました。 それがこのブログです。
ブログを作った目的
| 目的 | 詳細 |
|---|---|
| フロントエンドの勉強 | 触る場を作らないと、また勉強しないことが目に見えていた |
| Zettelkastenのアウトプット不足解消 | Obsidianで書いたノートを外に出して定着させる |
| 将来のReact/Vue練習の土台作り | まずはMarkdownで始めて、後からUIコンポーネントを追加 |
技術選定の候補と条件
候補は以下。
- Astro : 調べている中で出会った新しい静的サイトジェネレータ
- Docusaurus : 普段から使うNvimのプラグインドキュメントによく採用されていた(lazy.nvimなど)
- Hugo : Go製の高速静的サイトジェネレータ、どっかで使われているのを見た
- Next.js : React界隈では定番の有名フレームワーク
- Nuxt.js : Vue.js界隈では定番の有名フレームワーク
- Gatsby : React製の静的サイトジェネレータ、一時期よく聞いた
- Jekyll : GitHub Pages標準、Ruby製の老舗静的サイトジェネレータ
- VitePress : Vue.js作者が作った軽量ドキュメントサイト向けSSG
- WordPress : 自前のブログといえばこれ
- Laravel : 実務で使ったことあるのでノウハウがある
選定条件はこうです。
- Markdown対応 → Obsidianのノートをそのまま使える
- 静的サイト生成（SSG）対応 → 高速・安全・デプロイ容易
- バックエンド不要 → 本来の目的（フロント学習）に集中
- 学習コストが低め → 苦手分野なのでまず動かすこと優先
- 将来の拡張性 → React/Vue/Svelteを後から組み込める
- 広告掲載可能 → 将来的に小遣い稼ぎもできるように
候補比較表
| 技術 | メリット | デメリット |
|---|---|---|
| Astro | ・Markdown標準対応 ・高速SSG ・部分的にReact・Vue・Svelteを導入可能 ・ゼロJS by default | ・新しい技術なので情報量が少ない ・日本語情報が特に少ない |
| Docusaurus | ・ドキュメントサイト向けに最適化 ・Markdown対応 ・Meta製で安定 ・多言語対応が優秀 | ・ブログ用途には機能過多 ・柔軟性が低い ・デザインが似通いやすい |
| Hugo | ・非常に高速（Go製） ・多機能SSG ・テーマが豊富 ・単一バイナリで動作 | ・Goテンプレート学習が必要 ・HTMLなどが隠蔽されるので勉強にならない ・設定が複雑 |
| Next.js | ・豊富な情報量・事例 ・SSR・ISR・SSGすべて対応 ・Reactエコシステム ・Vercel最適化 | ・多機能で学習コストが高い ・バックエンド寄りの機能が多い ・オーバースペック |
| Nuxt.js | ・Vueエコシステムと相性抜群 ・ファイルベースルーティング ・SSR・SSG両対応 | ・多機能で学習コストが高い ・SSR中心の設計 ・Vue.js自体を覚える必要 |
| Gatsby | ・React製で拡張性高 ・GraphQL統合 ・プラグインエコシステム豊富 ・PWA対応 | ・ビルドが重い ・GraphQL必須で複雑 ・オーバーエンジニアリングになりがち |
| Jekyll | ・GitHub Pages標準 ・老舗で安定 ・シンプル ・無料ホスティング | ・Ruby環境が必要 ・拡張性が低い ・モダンな機能に乏しい |
| VitePress | ・非常に軽量・高速 ・Vue.js製 ・Markdown拡張が優秀 | ・ドキュメント特化でブログ向きではない ・カスタマイズ性が低い |
| WordPress | ・簡単にブログ開設 ・プラグイン豊富 ・ノーコードで管理 | ・勉強にならない ・セキュリティ管理が面倒 ・サーバー必要 |
| Laravel | ・実務経験があるので学習コストが低い ・フルスタック ・豊富な機能 | ・バックエンド作りたくない ・サーバー必要 ・フロント学習が目的からズレる |
なぜAstroにしたのか
- Markdown標準対応 → Obsidianのノート資産を活用可能
- 高速な静的サイト生成 → ビルド・デプロイが一瞬
- 必要な部分だけReact/Vue/Svelteを組み込める → 将来のUI練習に最適
- バックエンド不要で完結 → 本来の目的に集中できる
他の候補を見送った理由：
- Docusaurus → ドキュメント特化で自由度が低い
- Hugo → Goテンプレート学習が目的からズレる
- Next.js / Nuxt.js → 機能過多で今回の用途にオーバースペック
まとめ
このブログは、フロントエンド学習とZettelkastenのアウトプット強化という二つの目的を同時に叶えるために作りました。 AstroはMarkdown対応・高速SSG・拡張性という条件をすべて満たし、かつ将来的にReactやVueの練習もできる理想的な選択肢でした。 これからはブログを改善しながら、UI/UXやコンポーネント実装にも挑戦していく予定です。 学習の成果はまたここでアウトプットしていこうと思います。