静的サイト・LP
こんなとき:コンテンツ表示が主役。ログインや複雑な動的処理がほぼ要らない。
ビルドして配るだけ。サーバー運用ゼロ・無料枠で十分。
更新を非エンジニアに任せつつ、配信は静的で速く安全に。
世界中の利用者に近い場所から配信し、表示を速く・落ちにくく。
engineer.notes
try / verify / log
2026.06.28
作るもの(種別)と規模・制約から、2026年版の推奨構成へ最短でたどり着くための意思決定フローです。各分岐は「なぜそれを選ぶか」の理由つきで、推奨パターンページへ案内します。
下の種別から、いちばん近いものを選びます。
個人・小規模 / 中規模 / 大規模のどれかで、行を選びます。
各行の「理由つきの推奨」から、詳しいパターンページへ。
STEP 1 — 何を作る?(種別で絞り込む)
気になる種別をクリックすると、その種別だけに絞れます。もう一度押すと全表示に戻ります。
STEP 2・3 — 規模で選び、理由つきの推奨へ
こんなとき:コンテンツ表示が主役。ログインや複雑な動的処理がほぼ要らない。
ビルドして配るだけ。サーバー運用ゼロ・無料枠で十分。
更新を非エンジニアに任せつつ、配信は静的で速く安全に。
世界中の利用者に近い場所から配信し、表示を速く・落ちにくく。
こんなとき:CMSとしての更新性・プラグイン資産・制作会社との相性を取りたい。
安価で手早い。小規模サイトやブログの定番。
速度・セキュリティ・バックアップを事業者が面倒を見てくれる。
大規模はマネージドWP + CDN/キャッシュで対応。専用ページは未作成。
こんなとき:ログイン・データ登録・業務処理など、サーバー側のロジックが要る。
インフラ管理を任せ、コードに集中。少人数でも回る。
コンテナ実行 + RDS/Cloud SQL。止まると困る段階の鉄板。
冗長化・読み取り分散・キャッシュで、止めない/さばく。
こんなとき:フロントやモバイル、外部に対してAPIを提供するのが主目的。
リクエストが来た分だけ課金。アイドルコストがほぼゼロ。
常時負荷や複雑な処理はコンテナ常駐の方が素直で安定。
大規模はコンテナ + LB + オートスケールへ。専用ページは未作成。
こんなとき:iOS/Androidアプリが主役。バックエンドをどう持つかが論点。
認証・DB・通知が一体。バックエンドを作らず速く出せる。
独自ロジックや他システム連携が増えたら自前APIへ。
大規模はWebアプリ大規模構成に準じる。専用ページは未作成。
こんなとき:分析・BI・ダッシュボードのために、データを集めてためたい。
小規模は専用基盤を作らず、既存DBやBIツール直結で十分なことが多い。
自前パイプラインを作らず、サービスをつないで分析基盤を立てる。
取り込み・変換・権限・コストを仕組み化し、全社分析に耐える。
こんなとき:LLM等のAIを機能として組み込む。特定AIが消えるリスクへの備えが論点。
AI呼び出しを1枚の層で包み、差し替え可能にしておく。
複数AIをフォールバックでつなぎ、OSSへの退避先も用意する。
コスト・規制・継続性次第で、OSSモデルの自前ホストまで視野に。
制約で迷ったら — 判断フレームワークへ
種別が決まらない/予算・可用性・依存などで迷うときは、考え方の軸から固めます。