サイト運用コストの悩みは「波」にある

繁忙期には予約が殺到し、閑散期にはアクセスがほとんどない──イベント予約サイトや季節商材を扱う農園直売所、そして少人数で運営するデザイン事務所の共通点は「負荷変動」です。
この波に合わせて常時サーバーを超過スペックで構えておくと、稼働していない時間まで基本料金を払い続けることになり、運用コストが膨らみます。
サーバーレスは、この「波」を自動で吸収し、使った分だけ課金される仕組みです。

サーバーレスとは？従来構成との違い

従来は VPS や共用サーバー、クラウド VM を立て、OS やミドルウェアを自社で管理するのが一般的でした。
サーバーレスでは OS 層を意識せず、関数単位や リクエスト単位でリソースが瞬時に立ち上がり、アイドル状態の課金をゼロに近づけます。
具体例として、AWS Lambda や Cloudflare Workers、Azure Functions などがあります。

コスト構造の比較

項目	従来構成	サーバーレス
基本料金	固定（サイズに比例）	0 円
課金単位	常時稼働時間	実行時間 + リクエスト数
スケール方法	手動またはオートスケール設定	完全自動
障害対応	OS/ミドルウェアも自社責任	基盤はクラウド側が管理

この比較からわかるように、アイドル時間が多いサイトほどサーバーレスの恩恵が大きくなります。

中小企業が得られる三つの経済メリット

1. 固定費の圧縮

従来構成では、最小構成でもメモリやディスクに応じて月数千円〜数万円の基本料金が発生します。
サーバーレスでは実行されていない時間は課金対象外のため、閑散期はほぼゼロコスト。ピーク月だけ支払いが増える、いわば「従量電灯プラン」です。

2. キャパシティプランニング不要

「今年はアクセスが 1.5 倍になるかもしれない」と予測してサーバーを増強する必要がありません。
伸びた分だけ自動でスケールし、使った分だけ請求されるため、過剰投資や機会損失が同時に防げます。

3. 保守人件費の削減

OS パッチ適用、SSL 証明書更新、監視ツールのメンテナンスといった作業は、意外と工数を奪います。
サーバーレスではこれらの責任範囲がクラウド側に移るため、エンジニア不在の組織でも「インフラ担当」を新たに雇う必要がありません。

サーバーレス導入前に把握すべき数字

導入効果を測るには、まず 「1 リクエストあたりの平均実行時間」 と 「月間リクエスト数」 の二つを押さえましょう。

• 平均実行時間：コードとライブラリのサイズ、DB 呼び出し回数で決まる
• 月間リクエスト数：PV × API 分離数で概算可能

ここで 200 ms／100 万リクエストを例に、AWS Lambda と t3.small 相当の VM を比較してみます。

指標	t3.small (東京リージョン)	AWS Lambda	コメント
月額固定費	約 2,300 円	0 円	ストレージや DB は別途
実行・稼働費	常時稼働で 0 円	約 210 円	200 ms × 100 万 × 0.0000000167 USD
合計	約 2,300 円	約 210 円	約 91％削減

表は単純化した試算ですが、固定費がゼロにできるインパクトは大きいことがわかります。
なお、処理が 1 秒を超えるような重量 API はコンテナベースの Fargate やスケジューラ併用でコスト最適化を図るのが定石です。

導入ハードルは「設計」と「テスト」

「クリックひとつでサーバーレス」とはいきません。従来型のモノリシック PHP アプリをそのまま移すと、コールドスタートが長くなり割高になるケースがあります。

• ルーティングを API Gateway に寄せ、機能を小さく分割
• 画像や PDF はオブジェクトストレージへオフロード
• 可能ならステートレス設計にリファクタリング

このような前処理が、コストとパフォーマンスを左右します。

失敗しやすいポイント

症状	原因	回避策
コールドスタートが 2 秒超	関数が巨大／ライブラリ多用	依存を削減し 10 MB 以内に
意外と料金が高い	DB 接続を切り忘れ	コネクションプールを使う
監視が難しい	ログ集約設計不足	CloudWatch/Loki で集中管理

適切な設計をすることで、「安いけれど遅い」から「安くて速い」へと変えられます。

サーバーレスが向かないケースもある

• 常時 90％ 以上の CPU 使用率：24 時間負荷が一定なら従量課金のうまみが薄れる
• メモリ 10GB 超クラスの機械学習推論：メモリ課金が跳ね上がり、コンテナ常時起動の方が有利
• レガシーな状態管理を多用：共有セッションやファイル書き込みが前提のアプリは大規模改修が必要

とはいえ、中小企業サイトの多くは「ピークを除けば暇」という特性を持ちます。向かないケースを把握した上で、自社がどちら側に属するかを判断することが第一歩です。

ここまでのまとめ

1. 負荷の波 が大きいほどサーバーレスの費用対効果は高い
2. 固定費ゼロ化により 資金繰りが平準化
3. 設計段階での小規模リファクタリングが 性能と料金を最適化 する鍵

次章では、具体的な「イベント予約サイト」のケーススタディを通じて、ピーク対策の考え方を掘り下げます。

よくある誤解 Q＆A

• Q: サーバーレスは遅いのでは？
  A: 遅延の原因はコールドスタートとネットワーク I/O。メモリを 512 MB 以上に増やせば CPU が比例して速くなり、体感速度は大幅改善します。
• Q: ベンダーロックインが心配
  A: インフラ定義を Terraform／Pulumi などでコード化し、マルチクラウド対応ランタイム（OpenFaaS など）を選べば移行コストを下げられます。
• Q: デバッグが大変？
  A: ローカルエミュレータと CI パイプラインを組むことで、従来構成よりテストが高速化する事例も増えています。

ケーススタディ①：イベント予約サイトのピーク対策

課題の整理

イベントのチケット販売開始直後にアクセスが数十倍に跳ね上がり、従来の VM 構成では CPU が飽和して決済フローがタイムアウト。
運営側は「年に 3 回のピークのためだけにサーバーを増強するのは非効率」という悩みを抱えていました。

サーバーレス設計例

• 静的ページ：オブジェクトストレージ＋CDN でキャッシュ TTL 24 h
• 予約 API：Lambda（Go で 200 ms 以下に最適化）をプロビジョンドコンカレンシ 5 で待機
• 決済連携：Step Functions で非同期処理し、失敗時は自動リトライ
• キュー：SQS をバッファにして突発的な同時実行を平滑化

シナリオ	従来構成費用（月）	サーバーレス費用（月）	削減率
平常月	9,800 円	1,250 円	87 %
発売月	26,400 円	4,900 円	81 %

運用ポイント

• ブルーグリーンデプロイを導入し、切替時間を 30 秒以下に短縮
• Step Functions のステート履歴を 30 日で自動削除しログ料金を抑制
• GraphQL サブスクリプションを AppSync に統合し、接続数課金を最適化

ケーススタディ②：季節変動が大きい農園直売所

背景

いちご狩りや桃狩りなど収穫シーズンに PV が集中し、オフシーズンは EC 注文がまばら。
広告費をかけて集客するため、余剰サーバー費用は極力削りたいという要望でした。

導入アプローチ

• 商品カタログを Jamstack 化し、生成 HTML を CDN にキャッシュ
• オーダー API は Lambda＋DynamoDB でセッションレスに
• SNS キャンペーン用 URL を CloudFront Functions でリダイレクト
• 在庫連携は EventBridge 経由で基幹システムへ非同期通知

指標	移行前	移行後
ページ表示速度（モバイル）	3.8 秒	1.2 秒
月平均インフラ費	12,600 円	2,100 円
シーズン最⾼ PV/日	2.1 万	2.1 万
障害件数/年	4 回	0 回

追加の成長施策

• レシピ動画を S3 ストリーミングへ切替え、再生開始時間を 58 % 短縮
• Harvest カレンダーを自動生成し、平均滞在時間を 2.4 倍に向上

ケーススタディ③：エンジニア不在のデザイン事務所

直面した課題

• PHP＋MySQL の自社サイトを代表者が自己管理
• セキュリティアップデート忘れで改ざん被害を受けた経験あり
• 保守外注費が売上の 15 % を占めていた

サーバーレス化の手順

1. WordPress を静的出力し S3＋CloudFront へ配置
2. 問い合わせフォームは API Gateway＋Lambda(Python)＋SES
3. 画像最適化は Lambda@Edge で自動リサイズ
4. GitHub Actions で自動公開、通知は Slack Webhook

項目	移行前	移行後
年間インフラ＋保守費	約 240,000 円	約 36,000 円
脆弱性パッチ工数	月 3 時間	0 時間
売上比率	15 %	2 %

セキュリティとガバナンスの強化

• IAM を最小権限で定義し、キー管理を KMS へ統一
• CloudFront の WAF で OWASP Top10 ルールを適用
• アクセスログを S3 へ 365 日保存し、不正アクセスを可視化

サーバーレス導入で起こりがちな落とし穴と対策

コールドスタート測定不足

初回アクセスが遅延し離脱を招く。
対策：Gatling などで p95 レイテンシを測定し、メモリ設定を段階調整。

無料枠のつもりが課金

大量ログで S3 と CloudWatch 料金が膨張。
対策：ライフサイクルポリシーで 7 日後にインテリジェントティアへ移行、90 日後に削除。

パフォーマンスチューニングの罠

並列実行し過ぎて DynamoDB がスロットル。
対策：リトライ戦略とパーティション分割を実装。

運用自動化チェックリスト

チェック項目	実装例	期待効果
IaC がリポジトリで管理されている	Terraform Cloud で PR ごとに plan 実行	ヒューマンエラー削減
障害通知が 5 分以内に届く	CloudWatch アラーム→SNS→ChatOps	平均復旧時間短縮
バックアップが暗号化されている	DynamoDB PITR と S3-SSE	コンプラ遵守
コストアラートが設定されている	予算超過 80 % でメール	請求サプライズ防止
ステージ環境が自動削除される	PR マージ後に Lambda で掃除	リソース最適化

チェックリストを月次レビューに組み込み、継続的に改善することで「導入して終わり」にならない体制を築けます。

ケーススタディから得られる 5 つの共通教訓

1. 関数は小さく、状態は外だしでコールドスタートとテスト難易度を最小化
2. オブザーバビリティを最初に設計し、ログ基準とアラート閾値を明文化
3. リソースをタグで一元管理して部門別コストを即把握
4. キャッシュレイヤーを積極活用し、呼び出しゼロでもレスポンスできる構成へ
5. 不要リソースを自動削除して置き忘れによる課金を防止

サーバーレス導入ステップと推奨ツール

フェーズ 1 ― 準備

• 現状ヒアリング：リクエスト数・実行時間・ピーク時刻をログから抽出
• 費用見積もり：クラウド計算ツールで 3 パターン（平常／繁忙／最悪）を算出
• 影響範囲の洗い出し：ミドルウェア依存・ライブラリサイズ・状態管理箇所をチェック
• ステークホルダー合意：部門別コストコードと責任分界点を明文化

フェーズ 2 ― 実装

• IaC：Terraform/Pulumi で最小構成をコード化
• CI/CD：GitHub Actions と OIDC 連携でキー管理負荷をゼロに
• サイドテスト：負荷試験（Gatling、k6）と回帰テストを自動実行
• ブルーグリーン／カナリア：Route 53 ウェイト付きレコードで切替コストなし

フェーズ 3 ― 運用と最適化

• オブザーバビリティ：OpenTelemetry でトレース→Grafana に可視化
• コスト削減ループ：月次で ‟実行時間 × メモリ” を散布図にし、長い関数を分割
• セキュリティ：定期的に IAM Access Analyzer と Prowler を実行し逸脱を検知
• 教育：運用手順を Notion に動画付きで記録し、属人化を防止

フェーズ	主要タスク	推奨ツール	成功指標
準備	ログ分析	CloudWatch Logs Insights	リクエスト分布を把握
実装	IaC & CI/CD	Terraform Cloud, GitHub Actions	デプロイ時間 < 10 分
運用	コスト最適化	AWS Cost Explorer, Lambda Power Tuning	月次コスト -15 %/Q

月次コストシミュレーションのつくり方

ステップ

1. 3 層のトラフィックモデルを設定
   • 閑散（25 %）・平均（100 %）・繁忙（250 %）
2. 可変費目（Lambda, API Gateway, DynamoDB）と 固定費目（S3, Route 53）を分離
3. スプレッドシート関数で「=IF(トラフィック<閾値,0,従量単価×件数)」を定義

トラフィック層	Lambda 実行回数	月額（円）	API Gateway リクエスト	月額（円）	合計
閑散 25 %	25 万	55	30 万	96	630
平均 100 %	100 万	210	120 万	384	1,920
繁忙 250 %	250 万	525	300 万	960	4,050

ポイント：固定費はほぼ横ばいだが、可変費が**“右肩上がりの階段”**になる。ピーク対策目的なら「繁忙 250 %」の行を最も厳しく監視し、超過しそうな月は広告出稿量を先に調整する手もある。

移行時によくある質問・注意点

Q1. 既存モノリスをすべて分割する必要がある？

A. 段階移行が現実的。まず画像変換やメール送信など“自己完結するバッチ”だけを Lambda 化し、効果を可視化してからコア機能に進む。

Q2. データベースはどうする？

A. 負荷変動が激しいなら DynamoDB のオンデマンド課金が相性良好。
常時接続が多い管理画面用には RDS Serverless v2 でオーロラスケールを併用する手法が実績豊富。

Q3. コンプライアンス監査のログ要件は満たせる？

A. CloudTrail と EventBridge Archive を併用すれば最大 10 年の監査証跡を確保できる。コストは GB 単価×保存期間で直線的に伸びるため、古いデータは S3 Glacier へ自動移行するライフサイクルを設定。

Q4. CDN のキャッシュを即時削除したい場合は？

A. オブジェクト ID をバリデーションキーに埋め込み、最長 30 秒キャッシュに限定する「短命 TTL + バージョニング」戦略が有効。パージ API の乱用はコストを押し上げるため注意。

まとめ：費用対効果を最大化するポイント

• 負荷の波を定量化し、従来構成との費用差を初期段階で比較する
• 小さく試して勝ち筋を見極める――バッチや画像変換など切り出しやすい機能から始める
• オブザーバビリティとガバナンスを最初に組み込むことで、後追いの修正コストを削減
• Cost Explorer のアラートを自動化し、請求サプライズをゼロに
• 教育とドキュメントで属人化を防ぐことで、エンジニア不在でも持続的に回せる体制を築く

これらを守れば、中小企業サイトでもピークを難なく乗り越え、閑散期のコストを10 分の 1 以下に抑えることが現実的になります。