ちょうどよい機会なので、大学サークルのアドベントカレンダーに合わせて技術ブログをデプロイした。

https://adventar.org/calendars/12135

(↑ OGP展開…まあいっか)

今みなさんが見ているこの文章が見れるようになるまでに経た、技術選定で紆余曲折したログをここに記事として残す。
概ね実際の時系列に沿って書くので、結論だけ見たければ末尾までスクロールしてほしい。

コストを抑えよう

個人開発においてはコストが最も重要とされる。
コストがゼロならサービスは潰れないからだ。

参考: 個人開発のコストはDB次第 <https://laiso.hatenablog.com/entry/nope-sql>

もちろんブログも例外ではない。
(本当に無料でブログを出したいだけなら各種ブログサービスを使えばいいのだが、エンジニアというのは自前のブログを持ちたがる生き物なのである)

収益化してサーバー代を回収できるのが理想だが、やるなら広告しかないだろう。

この分野は SEO徹底して戦わないとアクセス稼げないレッドオーシャンなので、使いまわしのドメインで適当書き散らすだけのブログでは無理だ。ということで無料構成を検討していくことになる。

手法の検討

コスト低めで出来そうな方法は、主に以下の選択肢があるだろう。ブログに使うかは考えず、まずは選択肢を並べてみる。

フロントエンド

静的ホスティングならどこでも大差ない。
あえて候補を出すなら、github pages, cloudflare, aws s3 あたりだろうか。

SSR を動かすなら cloudflare か cloudrun あたり、または lambda などが安価な選択肢で上がる。探せばこれ以外にも有象無象のサービスがあるだろう。

あとは収益化しない趣味プラン限定なら、 vercel も有効に使えそうだ。

バックエンド

フロントの SSR と基本同じで、cloudflare, cloudrun, lambda だ。

この中では cloudflare が頭ひとつ抜けて手軽で扱いやすいのだが、基本的に JavaScript 縛りという欠点がある。
( 一応 WebAssenbly 経由で Go 言語や Rust を配置することもできるらしい )

データベース

このあたりは前述の記事が詳しい。
状況の変化としては、SQL (SQLite) でありながら非常に寛容な無料枠を提供してくれる、 Cloudflare D1 の登場があるぐらいだ。

  • Cloudflare D1 (SQLite)
  • DynamoDB (NoSQL)
  • Firebase (NoSQL)
  • TiDB (NewSQL)
  • cockroachDB (NewSQL)
  • Supabase (BaaS)
  • VPSを借りて全部積む
  • レンタルサーバーでDBだけ使う

VPS はすべてを賄えるしそこまで高くはないのだが、手間がかかりすぎるのとセキュリティが面倒なので出来れば避けたい。
一度も使ったことがなければ経験のためにやっておくべきだが、何度か作って消した経験のある私が今更選ぶスタックとしては手間のわりに魅力が少ない。

Supabase は悪くないが、無料プランからはみ出た場合あまりにも高すぎるし、無料だけで運用することはあまり想定されてない印象が強いので、個人的にはあまり積極的に選定したくなさがある。

TiDB あたりの NewSQL は SQL でありながら純サーバーレスの従量課金になっているものが多く、かなり有力だ。勉強にもなる。

これらを組み合わせてシステムを構築するわけだが、必ずしも全てが必須になるわけではない。

特にブログなどのwebサイトの場合、JAMStack 構成 (後述) にして、記事はgithub管理、フロントだけにする手もある。

要件定義

ここで、やりたいブログの要件を考えてみる。

  • 記事の表示 → static でもOK。つまり構成は何でもいける
  • 画像の表示 → R2, S3 など。あるいはビルド物にまとめて含める
  • コメント投稿機能など → つけられるなら付けてみたいが、必須ではない
  • ブログにポートフォリオっぽい情報を添えたい → static で足りる

複雑な機能はないので、取れる選択肢は多そうだ。この段階でふるい落とされる構成は基本的にない。

開発保守コスト

「手法の検討」では金銭のコストしか計算に入れてなかったが、実際には開発保守にかかる時間的コストもあり、両者のバランスを見て総合的に検討する必要がある。箇条書き的に書き連ねてみる。

まずNoSQLが不利になる。いくら趣味開発だし私はDynamo慣れているとはいえ、しんどい。

AWSなどのクラウドは一定額でアラートを発する機能はあるが、サービス自体を落とす機能はない。VPSなら負荷を超えた場合はサーバーが落ちるで済むが、クラウドの場合はすぐに止めないと青天井に課金が膨れ上がってしまう危険性がある。個人開発程度なら可用性なんていらないので、金で延命せずさっさと死んでもらった方が助かる。
あくまで可能性の話で実際は恐らく起きないのだが、まあリスクはなければない方が好ましい。

VPSは固定コストのうまみはあるものの、構築作業と保守が大変なのと、最低料金が発生するのでやっぱり不利。

ところで、いくら安いからといって S3 & cloudflare & TiDBみたいな一見良いとこどりに見えるﾓﾀﾞﾝｳｪﾌﾞｻｲﾄ構成を取ってしまうと、これらを繋ぎ合わせて運用していくのが地味に面倒な作業となる場合がよくある。
こうなるとサービスをまるごと1つでデプロイしたいという気持ちが出てきて、それなら Cloudflare スタックが非常に有力な選択肢となる。

まずは作ってみて手触りを確認すると、事前検討では見えなかったことがたくさん見えてくるものだ。
(ブログではあまり関係ないが) 一旦 PoC にして後で丸ごと作り直すことも視野に入れるとして、全部まるごと爆速で作れて移植性もある程度担保しておける方が都合が良いだろう。

この思考を基に、cloudflare にデプロイ、必要なら D1 と R2 にデータを入れるようにすると

  • SSG から SSR まで構成変更に対応できる
  • 実用的な無料枠で実行環境からストレージまで整う
  • 1サービスで完結する
  • 別構成に移し替えたいとなったときに移植性が高い
  • 私が慣れており、AI並行で開発したときに超速で組みあがる
  • すでに cloudflare で取ったドメインがある

で実現出来るので、これをベースに考えることにした

JAM Stack か否か

インフラ面は cloudflareで固めることに決めた。
2025年冬現在、これは金銭的、時間的コストを加味すると総合的に最良の選択肢であるケースが非常に多い。

実はフロント構成がまだ決まっていないのだが、これがちょっと難しい。
ブログの場合、JAMStack が有力な選択肢として出てくる。

JAMStackについて説明しておくと、アクセス時にフロントエンドを動的に生成したりバックエンドからデータを取るのではなく、記事などのコンテンツ投稿に合わせてwebページ全体をビルドし静的に生成。サーバーランタイム不要の状態にして完成品をそのままホスティングする方法。
要するに html 手打ちしていた古のホームページと同じ技術構成を、モダンな技術で作り上げる手法のことである。

メリットとして

  • 表示速度で理論値が出る
  • サーバーにランタイムが無くファイルが置いてあるだけなので脆弱性がほとんど or 全くない
  • バックエンド、データべースが無くても動くので構成が非常にシンプルで管理しやすくなる
  • 静的ホスティングになるので、デプロイの選択肢が非常に多くなり、安価な手段も取りやすい
  • デプロイ後に変化する部分がないため、放置していても安定稼働する

デメリットは

  • ビルド時に全て作る必要があるため、動的に変化する部分は作りにくい（構成次第だが不可能ではない）
  • コンテンツの編集機能は別途用意する必要が出てくる

デメリットの最たる例は、例えばコメント機能が作りにくくなる。別途サーバーを用意しないといけない。考えないといけないことと構成が少し複雑になる。

そもそもコメントなんて作っても荒らされるだけでは？という話もあるが、例えばコメントではなく閲覧数カウンター作って「キリ番踏み逃げ禁止」とか書いてBBSへのリンクを張ってみようと思いついたときに、それが面倒でやり辛い構成となってしまう。（繰り返しだが、別でサーバー置いて画面側にJS埋め込めばいいので出来なくはない）

こういった「後からこれやりたいなー」が難しくなる、技術的制約が発生する可能性があるのが JAMStack 最大のデメリット。 だが今回のようなブログであれば画面に複雑な動きが発生する可能性は低く、JAMStack ベースにして別サーバーにより少しだけ動きを足す運用で十分足りそうだ。

汎用的な判断基準としては、ログイン機能がなければユーザーごとの出し分けが不要なので、ビルド時に決定して問題ない場合が多いはずだ。

技術選定

ここまで決めたら、ようやく言語側の技術選定に入れる。 Cloudflare にデプロイするので TypeScript が言語で確定する。 Rust, Go のWASMビルドで置くことも出来るが、以前試した感じさすがにトリッキーな構成になるので、TypeScript分からないかつ Rust, Goが得意というわけでなければ無理に使う必要はないと感じた。

フロントエンドは SSG ができるフレームワークであることが望ましい。これを満たすには

  • NextJS
  • Sveltekit
  • Astro
  • HonoX

が2025年冬の技術選定で主な候補に挙がるだろう。

NextJS は AppRouter 以降、SSG したいだけならあまりに機能過剰で取り回しが悪いため、除外。

Sveltekit は悪くないが、画面の動きを作らないので旨味がやや薄い。とはいえ明確なデメリットもメリットもない、無難な選択ではある。

今回はJSを極限まで減らせるアイランドアーキテクチャの適正が高い要件なので、せっかくなら使ってみたく、そうすると Astro と HonoX が有力候補として残る。

正直この択はどちらでも良く、2,3度ゼロから作って比較を行った。

記事の編集機能を付けると認証の取り回しがとても厄介なので、当分は付けないことにした。

記事は markdown で git に突っ込んで管理すればDB周りを考える必要もなくなる。
HonoXだと SSR へ切り替えて API 追加も簡単に実現出来るが、試しに markdown のままアップロードファイルに含めて env.ASSETS.fetch で取得を試したところあまりに遅すぎてブログ用途だと使い物にならなかった。
mdファイル管理の場合はビルド時に html をレンダリングしておくことも前提条件になりそうだった。(動的取得でもd1なら早かったのだが……)

そういうシンプル SSG 構成なら HonoX をわざわざ選定することは技術的興味以外の観点でメリットがなく、まだ使ったことがない Astro でも興味は満たせるので、そちらを選定することにした。

まとめ

  • Astro
  • Cloudflare Workers

で JAMStack 構成の SSG でブログを構築したのが、このブログ兼ポートフォリオである。

コーディングはヘッダーや css などのベース部分だけ最初に claude code で作らせて、細かな調整は Astro を理解するためAIに頼らず手動で進めた。合計2時間程度。

ページ本体は JS が一切存在せず、公開時点でのこのページは 10kb 前後と、超軽量webサイトを構築できたので満足だ。これは画像データを除けば、かの有名な「阿部寛のホームページ」に匹敵する小ささとなる。

workers の無料枠で、日に20万アクセスまでは捌くことが可能だ。
Cloudflare は個人開発者の味方すぎて、本当にいつも助かっている。

参照元

このブログの機能やデザインを考えるにあたって、以下のブログを参考にしながら整理して進めた。
私が普段見ている情報源でもあり、私より参考になると思うので ここで紹介させていただく。