【技術選定ガイド第3部】実録！個人開発ブログの技術選定～コストと既存リソース優先の決断～

6月 20, 2025

【技術選定ガイド第3部】実録！個人開発ブログの技術選定～コストと既存リソース優先の決断～

はじめに

これまで「技術選定ガイド」シリーズでは、技術選定における主要な考慮ポイント（第1部）や、エンジニアの立場による視点の違い（第2部）について解説してきました。しかし、理論だけではなかなかイメージが湧きにくい部分もあるかもしれません。

本記事は「技術選定ガイド」シリーズの最終回、第3部です。今回は、個人開発でサービスサイトを立ち上げるという具体的なシナリオを通して、実際にどのように技術選定が行われたのか、その思考プロセスと最終的な決断に至るまでの道のりをケーススタディとして詳しくご紹介します。

特に、コストや既存リソースといった現実的な制約の中で、どのように最適なバランスを見つけ出したのか、その過程が皆さんの技術選定の一助となれば幸いです。

(本ガイドは全3部構成です)

第1部：失敗しないための主要な5つの考慮ポイント
第2部：立場別！SIer・フリーランス・事業会社エンジニアの視点
第3部：実録！個人開発ブログの技術選定～コストと既存リソース優先の決断～ (本記事)

技術選定の具体例：個人開発ブログにおけるコストと既存リソースを優先したケース

1. 背景と目的－何を、なぜ作るのか？－

ある個人開発者が、自身のスキルアップの一環として学んだことや、開発したツールの情報を発信・公開するための場として、ポートフォリオを兼ねたサービスサイトを立ち上げようと考えました。

目的:
- スキル習得のアウトプットの場
- 開発したツールや知見の公開
- ポートフォリオとしての活用
既存リソース:
- すでに別の目的で契約している共用レンタルサーバーの存在。月額料金は支払い済み。

この「既存リソースの存在」が、後の技術選定に大きな影響を与えることになります。

2. 当初の技術選定（流行りの技術を検討）－理想の構成－

開発者は当初、モダンな開発体験と将来性を重視し、以下のような人気の高い技術スタックを検討しました。

フロントエンド: React + Next.js
- 選定理由:
  - 優れた開発体験（コンポーネントベース、豊富なエコシステム）
  - SSR（サーバーサイドレンダリング）やSSG（静的サイト生成）による高速なページ表示
  - 豊富な機能（ルーティング、画像最適化など）
  - 活発なコミュニティと充実したドキュメントによる情報収集の容易さ
  - 当初想定していたサービスでは、SEOによる集客や、一部動的なコンテンツ表示の可能性も考慮しており、Next.jsのこれらの機能が適していると考えました。
インフラ: Vercel や AWS Amplify などのクラウドプラットフォーム (PaaS/BaaS)
- 選定理由:
  - Next.jsとの親和性が非常に高く、デプロイもGit連携で非常に簡単。
  - アクセス数に応じて自動でスケールするため、パフォーマンス面での安心感がある。
  - CDN（コンテンツデリバリーネットワーク）が標準で利用できることが多い。

この時点では、開発体験や機能性を優先した、いわば「理想的な構成」を描いていました。

3. 直面した課題と再検討－理想と現実のギャップ－

しかし、この構成を具体的に検討していく中で、特に個人開発ならではの2つの大きな課題に直面しました。

課題①：予測不能な運用コストクラウドプラットフォームの多くは従量課金制です。無料枠が用意されているサービスも多いですが、アクセス数やデータ転送量、ビルド時間などが一定量を超えると費用が発生します。個人運営のサイトでは、いつ、どれくらいアクセスが増えるか予測が難しく、特に何らかのきっかけで急増した場合の運用コストが読めないという懸念が生じました。たとえ月数百円～数千円だとしても、継続的に発生するコストは精神的な負担となり得ます。「趣味や学習の一環なのに、思ったよりお金がかかるな…」と感じてしまう可能性がありました。
課題②：既存リソースの未活用すでに月額料金を支払っている共用レンタルサーバーがあるにもかかわらず、新たにクラウドサービスを契約するのは、経済的に見ると二重投資になってしまいます。この既存リソースを有効活用できないか、という思いが強くなりました。

これらの課題、特に個人開発におけるコスト管理の重要性と既存リソースの有効活用という観点から、開発者は技術選定の方針を大きく転換する必要に迫られました。

4. 技術選定の見直しと最終決定－現実的な落としどころ－

新たな方針: 「既存のレンタルサーバーで、追加コストをかけずに運用できること」 を技術選定の最優先事項とする。

この方針転換に伴い、技術的な制約が出てきました。

技術的な制約の確認

多くの安価な共用レンタルサーバーでは、Node.jsの実行環境が標準では提供されていません（提供されていても、バージョンが古かったり、自由度が低かったりすることがあります）。そのため、Next.jsの強力な機能であるSSR（サーバーサイドレンダリング）をレンタルサーバー上で直接動かすことが難しいという壁に突き当たりました。

最終的な技術決定： React (SPA) で開発し、静的サイトとして配信

Next.jsのSSR機能や一部の高度な機能は諦める代わりに、以下の構成を選択しました。

フロントエンド: React（Create React App や Vite などを利用したSPA構成）
- Next.jsほどの多機能性はないものの、React単体でもコンポーネントベースで効率的な開発が可能。
- npm run build コマンドで、静的なHTML/CSS/JavaScriptファイル群を生成できる。
インフラ: 既存の共用レンタルサーバー
- 生成された静的ファイルを、FTPソフトなどを使ってレンタルサーバーにアップロードするだけで公開可能。

この選択によるメリット:

ほぼゼロコスト運用:
- 既存のレンタルサーバーの費用以外に、追加のインフラ費用は発生しません。
リソース負荷が低い:
- サーバー側での複雑な処理（Node.jsの実行など）が不要なため、共用レンタルサーバーへの負荷が非常に小さいです。
優れた表示速度（静的コンテンツの場合）:
- ブログのようなテキスト中心のコンテンツの場合、事前に生成された静的ファイルを提供するため、サーバー側の処理が不要となり、非常に高速なページ表示が期待できます。これはユーザー体験の向上に大きく貢献します。
- （ただし、SPA特有の初回ロード時間の問題や、SEO対策については別途考慮が必要になる場合があります。）

5. この事例から学べること－技術選定の本質－

この個人開発者の意思決定プロセスは、技術の流行や理想形だけを追うのではなく、プロジェクトの目的と現実的な制約を深く考慮した結果と言えます。

「流行」よりも「目的と制約」を優先する
- 技術選定では、まず「何を作りたいのか（目的）」そして「使えるリソースは何か（制約条件：予算、期間、既存資産、スキルなど）」を明確にすることが最も重要です。今回のケースでは「低コストでの情報発信」が目的であり、「既存レンタルサーバーの活用」と「追加コストを抑える」が大きな制約でした。
身の丈にあった選択をする
- 特に個人開発やリソースの限られた小規模プロジェクトでは、管理しきれないほどの高機能な技術や複雑な構成よりも、自身がコントロール可能で持続できる技術を選ぶことが成功の鍵となります。「オーバースペック」は、時としてコスト増や運用負荷増に繋がります。
トレードオフを意識する
- Next.jsのSSRやクラウドプラットフォームの利便性といった「理想」を一部諦める代わりに、「運用コストほぼゼロ」と「既存リソースの有効活用」という大きな「現実的なメリット」を得ました。技術選定は、多くの場合、何らかのトレードオフを伴います。何を優先し、何を妥協するのか、そのバランスをプロジェクトの状況に応じて見極めることが大切です。