連載「モダン Web バックエンド設計」第 0 回（序文）
この連載の対象読者
- 長期間ミドルエンジニアに留まっていて、次のスキル計画に悩んでいる方
- インハウス開発など、成果がそのまま評価につながる領域 への転向を考えている方
- AI 時代にも利益を生み出せる上級開発エンジニアを目指したい方
- これからエンジニアを志し、学習の方向性を決めかねている方
技術記事ですが、扱っているのは同時に 「何を身につければ市場で価値が落ちにくいか」 という問いでもあります。単体のコードを書く力ではなく、システム全体を破綻させない設計力 ―― そこに焦点を当てています。第 8 章では、そのスキルがなぜ契約構造によって評価されたりされなかったりするのかにも触れます。
この記事の結論
- IaaS で削減できるのは物理運用だけで、運用工数はほとんど減らない。そして日本の中小規模プロダクトでは、運用工数のほうがインフラ費用より高くつく
- K8s が正当化される規模は思うより高い。会員数 1,000 万人でも難しく、専任のプラットフォーム人員を置けるかが実質的な判定軸
- サーバレスの単価は数倍だが、損益分岐点は「平均稼働率 ＜ 1 ÷ 単価倍率」。国内向け Web の実効稼働率は 20〜30% なので、多くの場合は総額で安くなる
- 課金モデルを 成長段階に合わせて乗り換えられる。立ち上げ期はリクエストベースで使った分だけ、安定期はインスタンスベース＋CUD（1 年 28% / 3 年 46%）。移行は再デプロイのみ
- 「長時間バッチだからサーバレスに向かない」のではなく、分割設計とべき等性を持ち込めば長時間バッチである必要がなくなる
- ただし、従来型の設計をそのまま持ち込むとコストも品質も悪化する。その差分こそが本連載の主題
- そしてこの領域は、割り当てを待たずに一人で実証を積める。ゼロスケールゆえに検証コストがほぼかからず、成果が金額と時間で示せる
本連載は、サーバレスの各層が何を保証すべきか（責務）を整理し、それを実現する理論と動くコードを示す という構成で進めます。責務の大半は インフラ特性に由来する非機能要件 であり、シンプルな仕様書をそのまま AI に渡すと構造的に欠落します。AI への指示とレビューの両端に理論的理解が要る 領域です。
1. クラウドを使っているのに、クラウドの利点を得ていない
クラウドがインターネットの基盤となって、すでに十数年が経ちました。にもかかわらず、いまだに IaaS 上に仮想マシンを並べ、そこに OS とミドルウェアを載せ、パッチを当て、監視を組み、ログをローテートし、キャパシティを見積もって台数を決める ―― という運用に多大なコストを払い続けている現場は少なくありません。
もちろん、それが最適解である案件も存在します。しかし 日本国内で実際に開発されているプロダクトの大半において、クラウドの真価を引き出す構成は PaaS / FaaS / コンテナ実行プラットフォームといったサーバレス寄りの選択である ―― これが本連載の出発点となる立場です。
この記事では、なぜそう言えるのかを、責任範囲・コスト構造・トラフィック特性・処理モデル の 4 つの角度から整理します。そして最後に、それでもサーバレスが破綻する理由と、本連載が何を扱うのかを述べます。
2. IaaS は「下半分だけ仮想化されたオンプレ」である
クラウドの各サービスモデルで、事業者と利用者の責任がどう分かれるかを整理すると、IaaS の位置づけがはっきりします。
| 領域 | オンプレ | IaaS | コンテナ実行基盤 / PaaS | FaaS |
|---|---|---|---|---|
| 物理設備・電源・空調 | 自社 | 事業者 | 事業者 | 事業者 |
| ハードウェア・ネットワーク機器 | 自社 | 事業者 | 事業者 | 事業者 |
| 仮想化基盤 | 自社 | 事業者 | 事業者 | 事業者 |
| ★ OS・カーネル・パッチ適用 | 自社 | 自社 | 事業者 | 事業者 |
| ★ ミドルウェア・ランタイム | 自社 | 自社 | 事業者（一部自社） | 事業者 |
| ★ キャパシティ設計・スケーリング | 自社 | 自社 | 事業者 | 事業者 |
| アプリケーション | 自社 | 自社 | 自社 | 自社 |
★ を付けた 3 行 ―― OS・カーネル、ミドルウェア、キャパシティ設計 ―― に注目してください。IaaS の列だけが「自社」のまま残っています。つまり IaaS で削減できるのは、データセンターの物理運用だけ です。OS の脆弱性対応、ミドルウェアのバージョン管理、ディスクの空き容量監視、ログローテーション、そして「ピークに何台必要か」の見積もりは、そっくりそのまま手元に残ります。
これは価値がないという意味ではありません。物理調達のリードタイムが数週間から数分になったことの意義は決定的です。しかし、日々の運用工数という観点では、IaaS は思ったほど楽になっていない。「クラウドに移行したのに人手が減らない」という現場の実感は、この表が示すとおり正確な認識です。
そして運用工数は、多くの日本のプロダクトにおいて インフラ費用そのものより高価です。月額数万円のサーバ費用を節約するために、月に何十時間もエンジニアが運用に費やしているなら、経済計算は完全に逆転しています。
なお「IaaS でもオートスケールすればよい」という反論には第 4 章で答えます。結論だけ先に書けば、マネージドインスタンスグループを運用するより、Cloud Run のほうが制御は細かく、管理コストは小さい というのが本記事の立場です。
3. Kubernetes には「規模の経済」が要る
「ならば Kubernetes（K8s）でコンテナ運用を」という選択肢はあります。実際、大規模かつ多数のサービスを抱える組織では、K8s は極めて合理的です。
ただし K8s には、無視できない固定費があります。
- クラスタ自体の運用：コントロールプレーンの料金、ノードプールの管理、バージョンアップグレードの計画と実施
- 周辺エコシステムの整備：Ingress、cert-manager、外部シークレット管理、監視スタック、CNI の選定
- YAML / Helm / Kustomize の設計と保守：抽象化の設計自体が専門技能
- 専任者の確保：K8s を理解する人材の採用・維持コスト
これらは サービス数がいくつあっても、ほぼ同額かかります。したがって K8s のコスト効率は、その固定費を分散できるだけのサービス数・トラフィック規模があって初めて成立します。
逆に言えば ―― 日本で最も本数が出ている中小規模プロダクトの現場では、この固定費を回収できないケースが多い。サービスが 3 つ、エンジニアが 5 人、月間のピークトラフィックが数百 rps、という典型的な構成で K8s クラスタを維持するのは、多くの場合オーバーエンジニアリングです。
では、K8s が正当化されるのはどの規模からか
「オーバーエンジニアリング」と書きましたが、では境界はどこか。筆者はこの業界に四半世紀いますが、その中で見てきた範囲での目安を書いておきます。厳密な閾値ではなく、あくまで経験則です。
K8s が適正になるのは、おおむね次のいずれかに当てはまる規模です。
- エンタープライズの基幹系・社内システム群
- 大規模 EC
- 複数サービスを並行展開する SaaS ベンダー
- 国内トップ水準のトラフィックを持つサイト
会員数で言えば、1,000 万人規模でも正当化は難しく、2,000 万人あたりでようやく候補に上がる ―― というのが実感です。
ただし会員数は指標として粗いので、より直接的な軸も挙げておきます。
| 判定軸 | K8s が視野に入る水準 |
|---|---|
| 常時デプロイされているサービス数 | 十数〜数十以上 |
| 常時稼働しているノード台数 | 数十台以上（クラスタ固定費が相対的に小さくなる） |
| プラットフォーム専任の人員 | 恒常的に 1 人以上を置ける |
| 常態としてのピークトラフィック | 数千 rps 以上 |
このうち最も本質的なのは 3 行目です。 アプリケーション開発の片手間で K8s を見る体制なら、規模の大小にかかわらず割に合いません。逆に専任のプラットフォームチームを置けるなら、その人件費を回収できるだけの複雑さがすでに存在しているということでもあります。
そして、日本の主力案件の多くは、この水準より 1 桁以上低いところにあります。 グロースを見込んでも当面は十分な余裕があるはずです。
規模以外の理由で K8s が正解になる場合
規模の話だけで判断すべきではないので、こちらも挙げておきます。
- すでに K8s の運用資産と人材が社内にある
- マルチクラウドやオンプレ併用が、契約上・規制上の要件になっている
- サーバレスの制約（実行時間、GPU、特殊なミドルウェア、細かいスケジューリング制御）に恒常的にぶつかる
- ベンダーロックインの回避が、経営判断として明示されている
これらに該当するなら、規模が小さくても K8s を選ぶ合理性はあります。
迷ったら「後から移れる」ことを思い出す
そうした規模帯における現実的な最適解が、マネージドなコンテナ実行プラットフォーム（Cloud Run、AWS App Runner、Azure Container Apps など）と FaaS です。コンテナという可搬性の高い成果物はそのままに、クラスタ運用という固定費だけを外部化できます。
そして、この選択には 後戻りできる という重要な性質があります。成果物がコンテナイメージである以上、事業が伸びて K8s が正当化される規模に届いたとき、そこへ移行する道は残っています。
つまり判断はこうなります。
「今 K8s が必要か」ではなく、「K8s が必要になるまで待てるか」。
後から移行するコストは、必要になる前から K8s を運用し続けるコストより、たいていずっと小さく済みます。
4. Cloud Run が実際に提供しているもの
筆者が多用する Google Cloud を例に、具体的に何ができるのかを整理します。他クラウドにも類似のサービスがあり、本質的な議論は共通です。
課金モデルを 2 つから選べる
Cloud Run には性格の異なる 2 つの課金モデルがあり、サービス単位で選択できます。
| リクエストベース課金（既定） | インスタンスベース課金 | |
|---|---|---|
| 課金対象 | リクエスト処理中の CPU / メモリ使用時間 + リクエスト回数 | インスタンスのライフサイクル全体 |
| アイドル時 | 課金されない（ゼロスケール時はコストもゼロ） | 課金される。ただし負荷が下がればインスタンスは縮退し、最小インスタンス数 0 なら最終的にゼロになる ―― IaaS ほど固定的ではない |
| リクエスト課金 | あり | なし |
| CPU / メモリ単価 | 標準 | 割安（CPU 約 25%、メモリ約 20% 引き） |
| 向いているトラフィック | 散発的・バースト的 | 安定して継続的 |
| バックグラウンド処理 | レスポンス後は CPU が絞られる | レスポンス後も CPU が使える |
課金は 100 ミリ秒単位で切り上げられます。トラフィックが散発的・バースト的ならリクエストベース、安定して継続的ならインスタンスベースが推奨されており、インスタンスベースを選ぶとリクエスト処理以外でも CPU が割り当てられるため、レスポンス返却後の短時間のバックグラウンド処理を実行できます。
選び方の目安はシンプルです。リクエストが不規則に跳ねるなら、リクエストベース。 待機時間に課金されないため、突発的なスパイクを最も安く吸収できます。時間帯に沿って緩やかに増減する一般的な Web サイトなら、インスタンスベース。 単価が割安でリクエスト課金もないぶん、常時ある程度の負荷が乗る形態では効率的です。
ここで重要なのは、インスタンスベースを選んでも 固定インスタンスになるわけではない ことです。負荷が下がればインスタンス数は減り、最小インスタンス数を 0 にしていればいずれゼロになります。「常時課金」と聞いて IaaS のような固定費を想像すると、判断を誤ります。
縮退までの待機時間は公式に保証された値ではなく、実測ではおおむね十数分程度です。設計の前提にする場合は、自分のワークロードで確認してください。
成長段階に合わせて、課金モデルを乗り換えられる
そして最も実務的な価値は、この選択が後から変えられる ことにあります。
プロダクトのライフサイクルに沿って整理すると、こうなります。
| フェーズ | トラフィックの性質 | 最適な課金モデル | 効いてくる理由 |
|---|---|---|---|
| 立ち上げ期 | 読めない。アイドル時間が大半 | リクエストベース | 使った分だけ。誰も来ない時間帯は コストがゼロ |
| 成長期 | 時間帯変動はあるが常時負荷が乗る | インスタンスベース | 単価が割安（CPU 約 25% / メモリ約 20% 引き）＋ リクエスト課金なし |
| 安定期 | ベースラインが読める | インスタンスベース ＋ CUD | さらに 1 年 28% / 3 年 46% 引き（第 5 章） |
重要なのは、この移行がデプロイ設定の変更だけで完結する ことです。アプリケーションのコードも、コンテナイメージも、アーキテクチャも変わりません。
しかも判断を勘に頼る必要すらありません。Cloud Run の Recommender は過去 1 か月のトラフィックを自動的に分析し、そのほうが安くなる場合にリクエストベースからインスタンスベースへの切り替えを提案します。
IaaS のオートスケールと比べて何が違うのか
「IaaS でもマネージドインスタンスグループ（MIG）でオートスケールできる」という反論があります。できます。しかし、得られる制御の細かさと、支払う管理コストが違います。
| IaaS（MIG + オートスケーラ） | Cloud Run | |
|---|---|---|
| スケールの粒度 | VM 単位のみ | インスタンス数 × 同時実行数の 2 軸 |
| スケール速度 | VM 起動に分オーダー | 秒オーダー |
| ゼロスケール | 設定上は可能だが、起動が遅く実用的でない | 実用的に可能 |
| 課金の粒度 | 起動から停止まで（リクエストの有無を問わない） | 処理中のみ（リクエストベースの場合） |
| 構成変更の手順 | インスタンステンプレートを作り直し、ローリングアップデート | デプロイ設定を変更して再デプロイ |
| 維持すべき成果物 | マシンイメージ、起動スクリプト、テンプレートのバージョン | コンテナイメージのみ |
| 付随して必要なもの | ロードバランサ、ヘルスチェック、スケーリングポリシーの設計 | 不要（プラットフォームが内包） |
とくに 同時実行数という第 2 の軸 は、IaaS 側には対応物がありません。MIG では「1 台がどれだけのリクエストを同時に捌けるか」はアプリケーション任せで、スケーリング判断は CPU 使用率などの間接指標を通じてしか行えません。Cloud Run では、そこを明示的な設定値として制御できます。
そして第 2 章で見たとおり、IaaS 側にはインスタンステンプレートの管理という固定的な運用コストが残ります。マシンイメージの更新、起動スクリプトの保守、ローリングアップデートの計画 ―― これらはサービスが 1 つでも 10 個でも発生します。
つまり課金モデルの選択可能性とは、単に「2 択がある」という話ではなく、プロダクトの成長に合わせてコスト構造を段階的に最適化していける仕組み であり、しかもその操作コストが IaaS のオートスケール運用より一段低い、ということです。
0 から大規模までスケールする
最小インスタンス数は 0 に設定でき、その場合 リクエストが来ない時間帯のコンピューティング費用は発生しません。
上限側は、リージョンの CPU / メモリ割り当てをサービスの構成で割った値によって決まります。ベースライン割り当てが 1,000 vCPU または 2,000 GiB の場合、1 CPU / 2 GiB の構成なら単一サービスで最大 1,000 インスタンスまで指定できます。それ以上が必要なら割り当ての増加をリクエストできます。
つまり 特別なアーキテクチャ上の工夫なしに、0 から 1,000 インスタンスまでのレンジをカバーできる。しかもスケーリングの設定は、コンソールか gcloud のフラグか YAML の数行です。ロードバランサの設定も、オートスケーリンググループの設計も、ウォームプールの管理も要りません。
コスト事故が怖ければ最大インスタンス数に上限を設ければよく、これは 予算の上限を構成として表現できる ことを意味します。
インスタンスあたりの同時実行数を制御できる
もう一つの重要な調整軸が、1 インスタンスが同時に受け付けるリクエスト数です。既定値は 80 で、gcloud run services update SERVICE --concurrency 1 のように変更できます。上限は 1,000 です。
アプリケーションが並行リクエストを処理できない場合は 1 に設定します。また、指定した同時実行数はあくまで上限であり、インスタンスの CPU 使用率がすでに高い場合、Cloud Run はそのインスタンスに設定値いっぱいまでリクエストを送らないことがあります。
この設定は、後述する アプリケーション側の並行処理設計と直結します。Python のように「1 プロセスで何スレッド動かすか」が性能を左右する言語では、concurrency と max_workers の関係を理解していないと、インスタンスを増やしても性能が出ない、あるいは 1 インスタンスが過負荷で落ちる、といった事態になります。
5. 日本の Web トラフィック特性と、コスト構造の噛み合わせ
ここが本題です。
日本国内向けのサービスは、そのほとんどが 単一リージョン・単一タイムゾーン に閉じたトラフィックを持ちます。グローバルサービスのように「地球のどこかは常に昼」ではなく、トラフィックがはっきりと時間帯で上下する。
典型的な B2C サービスの 1 日は、おおむねこうなります。
|
1 2 3 4 5 6 7 8 9 10 |
リクエスト量 ^ | ████ | ███████ | ██ ██ ██████████ | ██████ ███████ ██████████████ | ████████████ ███████████████████████████████ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--→ 時刻 0 6 8 12 14 18 21 24 深夜 通勤 昼休み 帰宅 夜ピーク |
- 早朝から通勤時間帯にかけて緩やかに上昇
- 昼休みに中程度の山
- 夕方の帰宅時間から上昇し、夜 21〜23 時頃にピーク
- 深夜 1 時前後から急落し、明け方まで最低水準
固定インスタンス構成では、このピークに合わせて台数を決める しかありません。仮にピーク時に 5 インスタンス必要なら、5 台分を 24 時間確保します。しかし深夜帯には、1 インスタンスすら大半の時間がアイドルです。
サーバレスなら、深夜は実際に処理した数分間だけを支払い、ピーク時には必要なだけ立ち上げてレスポンス低下を防ぐ。この挙動が、設定ファイルの数行で実現します。
損益分岐点を計算する
「でもサーバレスは単価が高いのでは」―― そのとおりです。同じ vCPU 時間あたりで比べると、Cloud Run のリクエストベース課金は Compute Engine の常時稼働インスタンスより割高です（構成やリージョン、割引の適用状況によりますが、おおむね数倍のオーダーになります）。
しかしこれは、単価と稼働率のかけ算で判断すべき問題 です。損益分岐点は単純な式で表せます。
|
1 2 3 |
サーバレスが有利になる条件： 平均稼働率 ＜ 1 ÷ 単価倍率 |
具体的に見てみましょう。
| サーバレスの単価倍率 | 損益分岐点となる平均稼働率 |
|---|---|
| 2.0 倍 | 50% |
| 2.5 倍 | 40% |
| 3.0 倍 | 33% |
| 4.0 倍 | 25% |
ここで言う平均稼働率とは、確保したキャパシティに対する実際の使用量の比 です。固定インスタンス構成では、これは「平均トラフィック ÷ ピークに合わせて確保したキャパシティ」になります。
典型的な国内向け Web サービスでは、
- 平均 ÷ ピークが、およそ 0.3〜0.4
- さらに、スパイクへの備えとして 1.5 倍程度の安全マージン を積む
- 加えて、冗長構成のため最低 2 台は常時起動する
これらを掛け合わせると、実効的な平均稼働率は 20〜30% 程度 に落ち着きます。上の表と照らすと、単価が 3 倍でも損益分岐点（33%）を下回っており、総額ではサーバレスのほうが安くなる 領域です。
これが、元の主張である「単価は数倍だが総額は半分以下になり得る」の内実です。単に「サーバレスは安い」のではなく、「稼働率が低いワークロードでは、従量課金のほうが構造的に安い」 ということです。
この計算が成り立たない条件
公平を期すために、逆側も書いておきます。
- 24 時間ほぼ一定の負荷がかかっている（稼働率が 50% を超える）なら、固定インスタンスが有利です。
- 確約利用割引（CUD）やリザーブドインスタンス、Spot / プリエンプティブル を使えば固定側の単価が下がり、分岐点は動きます。予測可能な負荷にはこれらが強力です。
- CUD は 1〜3 年の確約であり、その期間トラフィックが読めるという前提 が必要です。読めないならリスクプレミアムを払っていることになります。
CUD は「固定インスタンス側だけの武器」ではない
ここで、意外と知られていない事実を補足しておきます。サーバレスにも CUD は適用できます。 しかも Cloud Run の場合、インスタンスベース課金なら IaaS と遜色ない割引率が設定されています。
現在は Compute フレキシブル CUD に統合されており、1 つのコミットメントで Compute Engine、Google Kubernetes Engine、Cloud Run の対象費用をまとめてカバーできます。課金アカウント内であれば、任意のリージョン・プロジェクトの利用に適用されます。
割引率は課金モデルによって大きく変わります。
| 対象 | 1 年確約 | 3 年確約 |
|---|---|---|
| Cloud Run（インスタンスベース課金） / ジョブ / ワーカープール | 28% | 46% |
| Cloud Run（リクエストベース課金） | 17% | 17% |
| Cloud Run functions | 17% | 17% |
| （参考）Compute Engine リソースベース CUD | 37% | 55% |
インスタンスベース課金の Cloud Run サービス、ジョブ、ワーカープールには 1 年で 28%、3 年で 46% の割引が適用されます。一方、リクエストベース課金のサービスと Cloud Run functions は、1 年・3 年ともに 17% です。
ここに実務上の判断材料があります。 28% と 17% の差は小さくありません。ベースラインとして常時乗っている負荷があるなら、その分をインスタンスベース課金のサービスに寄せて CUD を適用するほうが有利です。前節で「選べることが重要」と書いたのは、こういう場面でも効いてきます。
そして損益分岐点の計算に戻ると、両側に割引が乗るため、単価倍率はそれほど大きくは動きません。
|
1 2 3 4 5 6 7 |
固定側（CE リソースベース 1 年 37% 引き） → 単価 0.63 倍 サーバレス側（Run インスタンスベース 28% 引き）→ 単価 0.72 倍 相対倍率の変化 ＝ 0.72 ÷ 0.63 ≒ 1.14 倍 元の単価倍率が 3.0 倍だった場合 → 約 3.4 倍 損益分岐点となる平均稼働率： 33% → 約 29% |
分岐点は動きますが、構図がひっくり返るほどではありません。「固定側だけが CUD で安くなる」という前提で判断すると、見積もりを誤ります。
CUD は「支出の平坦さ」に効く ―― ここでサーバレスが有利になる
もう一段踏み込むと、より重要な性質があります。フレキシブル CUD は 時間あたりの最低支出額 を確約する仕組みです。確約した時間あたり支出に達しない時間帯でも、その金額は支払う必要があり、確約分を超えた使用量には割引が適用されません。
つまり 支出が時間帯で凸凹しているほど、CUD の消化効率は落ちます。夜のピークに合わせて確約すれば深夜に使い切れず、深夜に合わせて確約すればピーク時の大半が定価になる。
ここでサーバレスの機動性が効いてきます。負荷を時間帯で意図的に配置できる からです。
- 昼〜夜のオンライン処理が谷になる深夜帯に、バッチやデータ処理を寄せる
- CUD は課金アカウント内で横断適用されるため、サービスをまたいで枠を融通できる
- 結果として時間あたりの支出が平坦化し、確約分をほぼ使い切れる
これは、かつてオンプレで行われていた「夜間に空いた計算資源をバッチに回す」という発想と同じです。違うのは、リソースの割り当てが物理的な制約ではなく、実行タイミングの設計だけで済む こと。第 6 章で扱う「バッチを分割・並列化する」設計と組み合わせれば、深夜の処理を短時間で終わらせつつ、CUD の消化にも寄与させられます。
CUD を使うときの注意点
- 使わなくても支払う。 時間あたりの最低支出が確定するため、事業が縮小しても義務は残ります。
- キャンセルできない。 3 年 46% は魅力的ですが、3 年先の事業規模を見通せるかは別問題です。まずは 1 年で始めるのが無難です。
- ネットワーク費用と GPU は対象外です。
- 確約を超えた分は定価。 「多めに確約しておく」も「少なめにして超過させる」も、どちらも損をします。実測に基づいてベースラインを見積もる必要があります。
要は「常に正しい」と主張したいのではなく、自分のワークロードの稼働率を測れば、どちらが有利かは計算で出せる ということです。そして日本の中小規模プロダクトの多くは、計算するとサーバレス側に落ちます。
6. 「バッチ処理」という発想自体を手放せる
コスト以外に、もう一つ見落とされがちな利点があります。サーバレスのスケーリングは、これまでバッチでしかできなかった処理を、ほぼリアルタイムに置き換えてしまう という点です。
なぜ従来は「バッチ」だったのか
夜間バッチという設計は、技術的な必然ではなく キャパシティの制約から生まれた妥協 でした。
固定インスタンス構成では、計算資源は常に有限です。10 万件のデータを処理したいとき、日中のオンライン処理を妨げないよう、トラフィックが落ちる深夜帯に、限られた台数で少しずつ処理する ―― これが夜間バッチの正体です。処理時間が 4 時間かかるなら、それは「4 時間分の資源しか用意できないから 4 時間かかる」のであって、本質的に 4 時間必要なわけではありません。
その結果、次のような副作用を業務側が引き受けてきました。
- データが最大 1 日古い。 「昨日の締め分までしか反映されていません」という仕様は、多くの場合ユーザー価値の毀損です。
- バッチ枠の奪い合い。 深夜の限られた時間に処理が集中し、1 本遅延すると後続が総崩れになります。
- 失敗時のリカバリが翌日。 再実行の余裕がなく、障害対応が深夜作業になります。
分割できるなら、時間は買える
サーバレスでは、この前提が崩れます。10 万件を 1 台で順番に処理する代わりに、1,000 並列で一斉に処理する ことができ、しかもその 1,000 インスタンスは数十秒で立ち上がって、終わったら消えます。
決定的なのは、この時間短縮に追加コストがほとんどかからない ことです。従量課金は「リソース量 × 時間」の積分で決まるため、インスタンス数を増やして時間を縮めても、積分値は変わりません。
|
1 2 |
1 インスタンス × 3,600 秒 = 3,600 インスタンス秒 1,000 インスタンス × 3.6 秒 = 3,600 インスタンス秒 ← 総量は同じ |
つまり 実行時間の短縮が実質的に無料で手に入る。これは固定インスタンス構成には存在しない性質です。固定構成で 1,000 並列を得ようとすれば、1,000 台分を常時抱えるか、都度調達する運用コストを払うことになります。
並列化には 2 つの軸があり、効き方が違う
ここで一つ整理が必要です。サーバレスにおける並列化には インスタンス数を増やす 軸と、1 インスタンスあたりの同時実行数を増やす 軸の 2 つがあり、コストへの効き方が異なります。
| 増やすもの | 実行時間 | 支払総額 | 適する処理 | |
|---|---|---|---|---|
| 軸 A | インスタンス数 | 短縮する | ほぼ変わらない | CPU バウンド |
| 軸 B | 同時実行数（concurrency） | 短縮する | 下がる | I/O バウンド |
軸 A が先ほどの積分の話です。CPU を使い切る処理では、総仕事量は不変なので支払いも変わりません。得られるのは時間だけ ―― ただしそれが無料で手に入る。
軸 B は性質が違います。外部 API の応答待ちのような I/O バウンドな処理では、待っているだけの時間まで課金対象になっています。1 インスタンスで 100 件を同時に待てるなら、その待ち時間が 100 件で共有され、支払総額そのものが下がります。
第 1 回との関係 軸 B こそが本連載第 1 回の主題です。Lambda で外部呼び出しを直列 20 秒から並列 1.5 秒にすることで、GB-秒が約 92% 削減される ―― という試算を扱います。ただし軸 B を効かせるには、アプリケーションがその並行度に耐える必要があります。Python では、スレッド設計とコネクションプールの理解がそのまま請求額に跳ね返ります。
実務では、この 2 軸を組み合わせます。次の具体例がまさにそれです。
具体例：1 万件の処理
抽象論では実感が湧かないので、具体的な数字で見てみます。1 万件のレコードに対して、それぞれ外部 API 照会と DB 更新を行う処理を考えます。1 件あたり 2 秒、そのほとんどが応答待ち だとしましょう。
従来の構成（固定インスタンス）
|
1 2 |
1 台で直列処理： 10,000 件 × 2 秒 = 20,000 秒 ≒ 5.6 時間 延べインスタンス秒： 20,000 |
日中のオンライン処理を圧迫できないので、深夜 1 時に起動して朝までに終わらせる。まさに典型的な夜間バッチです。台数を増やせば短縮できますが、そのために常時 10 台を抱えるのはコスト的に選べません ―― これが「長時間バッチ」という設計を選ばせていた本当の理由 です。
サーバレスの構成
Cloud Run のインスタンスあたり同時実行数を 100（軸 B）、最大インスタンス数を 100（軸 A）に設定すると、同時処理数は次のようになります。
|
1 |
同時実行数 100 × インスタンス 100 = 10,000 並列 |
1 万件が一斉に処理され、処理そのものは 2 秒で完了します。インスタンスの起動を含めても、5.6 時間が数十秒のオーダーになります。
そして支払いはこうなります。
|
1 |
100 インスタンス × 2 秒 = 200 インスタンス秒（理論値） |
待ち時間が 1 インスタンスあたり 100 件で共有されるため、延べインスタンス秒そのものが二桁減ります。実際には起動・終了の時間も課金対象なので理論値どおりにはならず、インスタンスの生存時間を控えめに 30 秒と見ても 3,000 インスタンス秒程度。それでも従来の 20,000 を大きく下回ります。
| 従来（1 台で直列） | サーバレス（1 万並列） | |
|---|---|---|
| 実行時間 | 約 5.6 時間 | 数十秒 |
| 延べインスタンス秒 | 20,000 | 数百〜数千（オーバーヘッド込み） |
| データ鮮度 | 翌朝 | 即時 |
| 失敗時の影響範囲 | ジョブ全体 | 該当件のみ |
| 深夜の運用当番 | 必要 | 不要 |
5.6 時間が数十秒になり、しかも安くなる。 これがサーバレスにおける「時間を買う」ということの意味です。
なお、コストまで下がるのは処理が I/O 待ち主体（軸 B が効く）だからです。CPU を使い切る処理なら支払総額は横ばいで、得られるのは時間だけ になります。それでも、時間が無料で手に入るという結論は変わりません。
注意：同時実行数 100 は無条件には成立しません 1 インスタンスで 100 リクエストを同時に捌くには、アプリケーション側がその並行度に耐える必要があります。Python の場合、これはまさに本連載第 1 回の主題です。スレッド設計とコネクションプールの設定が噛み合っていなければ、concurrency を上げてもリクエストが詰まるか、メモリを食い潰します。CPU を使う処理なら、同時実行数はもっと小さく（1〜数十）設定するのが適切です。
既存バッチからの移行パスは、思うより短い
「そうは言っても、既存のバッチを全部書き直すのは無理だ」という反応が当然あります。しかし実際には、移行の変更点はループ構造の部分だけ であることが多いです。
既存のバッチは、たいてい次の形をしています。
|
1 2 3 4 |
# 従来のバッチ（1 プロセスで全件を回す） def main(): for record in fetch_all_records(): process(record) # ← このロジックは変えなくてよい |
これを Pub/Sub でファンアウトする構成に変えると、こうなります。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# ① Publisher：全件をメッセージとして投入するだけ（数秒で終わる） def enqueue(): for record in fetch_all_records(): publisher.publish(TOPIC, json.dumps({"id": record.id}).encode()) # ② Subscriber：Cloud Run の push エンドポイント。1 件だけ処理する @app.post("/handle") def handle(message: PubSubMessage): record = load(message.id) process(record) # ← 既存ロジックをそのまま移植 return {"ok": True} # 2xx を返すと ack される |
process() の中身は変更不要です。 変わるのは「全件をループする」部分が「全件をキューに積む」に置き換わり、ループの中身が HTTP ハンドラになるだけ。あとは Cloud Run が Pub/Sub の配信量に応じて勝手にインスタンスを増やします。
失敗の扱いをプラットフォームに任せられる
この構成の見逃されがちな利点が、エラーハンドリングの大半をマネージドサービスが吸収してくれる ことです。
| 従来のバッチで自前実装が必要だったもの | Pub/Sub 構成での扱い |
|---|---|
| リトライ処理 | ack されなければ 自動で再配信 |
| 指数バックオフ | サブスクリプションの設定で指定 |
| 失敗レコードの退避 | 規定回数超過で デッドレターキューへ自動移動 |
| 進捗管理・再開位置の記録 | 不要（未 ack のメッセージが残っているだけ） |
| 部分失敗時の切り分け | 失敗した件だけが DLQ に残る |
従来のバッチでは、「どこまで処理したか」を記録するチェックポイント機構、失敗レコードを別テーブルに退避する仕組み、リトライ回数のカウンタ ―― これらを自前で書き、テストし、保守してきました。Pub/Sub 構成では、そのほとんどが設定項目になります。
障害対応も変わります。DLQ に 12 件溜まっていれば、原因を調べて修正し、その 12 件だけをトピックに再投入すればよい。全件を流し直す必要も、深夜に叩き起こされる必要もありません。
ただし、これには一つだけ条件があります。Pub/Sub の配信保証は at-least-once であり、同じメッセージが 2 回届くことが正常な動作として起こり得る ということです。上の process() が二重実行に耐えなければ、この構成は静かにデータを壊します。
これが本連載第 2 回でべき等設計を扱う理由です。「失敗をプラットフォームに吸収させる」という利点は、べき等性という対価を払って初めて手に入ります。
さらに進めると、バッチが消える
処理を分割できるなら、次の問いが出てきます ―― そもそも溜めてから処理する必要があるのか？
イベントが発生した時点で 1 件ずつ処理してしまえば、バッチという概念自体が不要になります。
| 従来のバッチ | イベント駆動 | |
|---|---|---|
| 起動契機 | 時刻（cron） | データの発生（Pub/Sub、Eventarc、DB トリガー） |
| 処理単位 | 全件 | 1 件（または小さなまとまり） |
| データ鮮度 | 最大 1 日 | 数秒 |
| 失敗の影響範囲 | ジョブ全体 | その 1 件のみ |
| リカバリ | 翌日、全件再実行 | DLQ から該当分のみ再投入 |
失敗の影響範囲が「ジョブ全体」から「1 件」に縮む ことの価値は、運用してみると特に大きく感じられます。10 万件のうち 3 件が不正データで落ちたとき、従来はジョブ全体が失敗し、原因を特定して全件を流し直していました。イベント駆動なら、その 3 件だけがデッドレターキューに落ち、残りは正常に処理されています。
ただし、成立には前提がある
この転換は無条件には成立しません。
- 分割可能であること。 各要素が独立に処理できる（embarrassingly parallel）必要があります。前の結果が次の入力になる逐次依存の処理は、並列化できません。全件を一度に見る必要がある集計は、BigQuery のようなクエリエンジンに委ねるのが筋です。
- 下流がスケールに耐えること。 ここが実務で最も詰まる箇所です。1 万並列で走らせても、書き込み先の RDB のコネクション上限が 100 なら、そこで詰まって意味がありません。それどころか、大量のコネクション試行が DB を巻き込んで倒します。並列度の上限は、自分ではなく下流が決めます。前述の「同時実行数 100 × 100 インスタンス」も、下流が耐えるからこそ選べる値です。実務では最大インスタンス数を意図的に絞る、あるいは接続プロキシを挟むといった設計が必要になります。
- べき等であること。 並列化とリトライを前提にした瞬間、同じ処理が 2 回走る可能性が生まれます。これは本連載第 2 回の主題そのものです。
- 実行時間の上限。 個々のタスクが極端に長い場合は、Cloud Run ジョブなど別の実行形態を選ぶか、処理をさらに分割する必要があります。
つまり、「長時間バッチだからサーバレスに向かない」のではなく、「分割設計とべき等性を持ち込めば、そもそも長時間バッチである必要がなくなる」 ということです。制約に見えたものが、設計を見直す契機になっている。ここがサーバレスの面白いところだと思います。
そして、この 4 つの前提がそのまま 本連載で扱う技術 に対応します。分割と並列度の設計が第 1 回、べき等性が第 2 回です。
7. それでも、サーバレスが最適でない場面
技術選定の記事として、向かないケースも明示しておきます。ここを誤ると、本記事は単なるポジショントークになります。
| 状況 | 理由と代替案 |
|---|---|
| 極端にレイテンシに厳しい | コールドスタートが許容できない場合、最小インスタンス数を 1 以上に設定して緩和できますが、その分の常時課金が発生し、コスト優位が縮みます |
| 分割できない長時間処理 | 前節のとおり、分割可能な処理はむしろ並列化してリアルタイム化できます。問題になるのは、逐次依存で分割不能な処理や、単一タスクが実行時間上限を超えるケースです。Cloud Run ジョブや専用のバッチ基盤、あるいは BigQuery のようなクエリエンジンへの委譲を検討します |
| ステートフルなワークロード | インスタンスがいつ落ちても良い前提の基盤です。永続状態は外部（DB、オブジェクトストレージ）に置くのが必須です |
| 常時稼働かつ高稼働率 | 前節のとおり、固定インスタンス + CUD が有利です |
| 特殊なカーネル要件・レガシー依存 | OS レベルの制御が必要なら IaaS 以外に選択肢がありません |
| 大量の常時 GPU 推論 | GPU 利用時はインスタンスベース課金が前提となり、完全な従量課金にはなりません |
「サーバレスが常に正解」ではありません。主張はあくまで 「日本の中小規模 Web プロダクトという最も本数の多い領域において、既定の選択肢とすべきである」 という点です。
8. そして、それでも破綻する ―― 本連載の主題
ここからが重要です。
サーバレスは「使えば自動的に安くなる」魔法ではありません。むしろ、プラットフォームの性質を理解せずに従来型の設計を持ち込むと、コストも品質も悪化します。
現場でよく見る破綻のパターンを挙げます。
- I/O 待ちの時間をそのまま課金されている。 外部 API を 100 回直列に叩く処理を、そのまま Cloud Run / Lambda に載せる。待っているだけの時間が丸ごと課金対象になり、「サーバレスにしたら高くなった」という結論に至ります。
- 同時実行数とスレッド設計が噛み合っていない。 concurrency 80 のインスタンスに、スレッドセーフでないコードや、コネクションプール上限が 10 のクライアントを載せる。インスタンスを増やしても性能が出ない、あるいはデータが壊れます。
- リトライを前提としていない。 サーバレスとメッセージングは at-least-once の世界です。同じ処理が 2 回走る前提を持たない実装は、二重課金や在庫の二重引き当てを引き起こします。
- インスタンスの揮発性を無視している。 ローカルディスクやプロセス内キャッシュに状態を持ち、スケールイン時に静かにデータを失います。
- コールドスタートに無自覚。 重い初期化をリクエストごとに走らせ、レイテンシと課金時間の両方を悪化させます。
これらはいずれも 「動くことは動くが、本番の負荷で壊れるか、想定より高くつく」 種類の問題です。開発環境やステージングでは再現しません。
5 つを並べると、共通点が見えてきます。いずれも 「以前は環境が勝手にやってくれていたことを、誰も引き受けていない」 という形をしています。常駐プロセスが保持していた状態、直列実行が保証していた一意性、OS が割り振っていた CPU ―― これらが失われたことに気づかないまま設計している。第 9 章では、この 責務の再配分 を出発点として連載の構成を示します。
そしてこの種の設計上の勘所は、個々のコードの正しさではなく、システム全体の整合性 に関わります。関数単位で見れば正しいコードが、並行実行とリトライの文脈では壊れる ―― という性質を持つため、局所的な修正の積み重ねでは到達しにくい領域です。生成 AI にコードを書かせる場合も同様で、この点は第 9 章で改めて掘り下げます。
だからこそ、サーバレスを正しく設計できるエンジニアの価値は高い。
ミドルで停滞するのは、能力ではなく「見ている単位」の問題であることが多い
冒頭に挙げた対象読者に向けて、もう少し踏み込んで書いておきます。
長くミドルに留まってしまう方は、コードが書けないわけではありません。むしろ個々の実装は堅実であることが多い。停滞の原因は、評価される仕事の単位が「関数やクラス」に留まっている ことにあります。
上で挙げた 5 つの破綻パターンを思い出してください。どれも、個々のコードをいくら丁寧にレビューしても見つかりません。並行実行の文脈、リトライの文脈、課金の文脈に置いて初めて問題になるからです。この「文脈を跨いだ整合性」を設計できるかどうかが、ミドルと上級を分ける実質的な境界 です。
そしてここは、生成 AI が最も苦手とする領域でもあります。関数単位のコードは AI が高速かつ正確に書きます。しかし「このハンドラが 2 回呼ばれる可能性があるか」「この並列度で下流が耐えるか」「この待ち時間は課金対象か」といった問いは、システム全体の前提を保持していなければ立てられません。問いを立てる側に回れるかどうか、という話です。
なぜ SES・受託では報酬に結びつきにくいのか ―― 構造の話
もう一つ、報酬の話をしておきます。これは能力の問題ではなく、契約構造の問題 です。
SES や受託の売上は、原則として 「工数 × 単価」 で決まります。成果物が稼働した結果として発注側にどれだけの利益が生まれたかは、この式に入っていません。ここから逆説的な帰結が導かれます。
サーバレス化してインフラ費を月 30 万円削減し、運用工数を月 40 時間減らしたとします。 発注側には確実な利益が生まれます。しかし受注側の売上は増えないどころか、減った工数のぶん、翌月から売上が下がります。
つまり、この種のスキルを発揮することが、自社の売上を減らす行為になってしまう。企業として合理的に行動するかぎり、そこへ人材投資を行う動機は生まれません。結果として、
- 利益を生むスキルへの評価・教育の仕組みが社内に作られない
- エンジニア側もそのスキルを獲得する機会と動機を持ちにくい
- スキルを持つ人材が構造的に不足する
- だからこそ、持っている人材の希少価値が上がる
という循環が生じます。長くミドルに留まっている方の多くは、能力ではなくこの構造の側にいます。
一方インハウスでは、式が変わります。削減したコストも、伸ばした売上も、そのまま自社の利益です。「インフラ費用を月 30 万円削減した」「深夜バッチの運用当番をなくした」という成果が、評価の対象そのものになります。同じスキルでも、置かれる構造によって値段が桁違いになる ということです。
そしてサーバレス構成は、この効果を増幅します。運用工数が小さく、スケールしてもコストが線形に増えにくいため、プロダクトの利益がインフラと運用に吸われにくい。分配できる原資が残りやすい構造だからです。近年インハウス採用が増えている状況を踏まえると、このスキルセットは 市場価値と実際の貢献が素直に一致しやすい領域 だと言えます。
念のために書いておくと、これは受託や SES を貶める話ではありません。成果報酬型やラボ型の契約を採り、スキル投資を評価に組み込んでいる会社も存在します。問題は個々の企業の姿勢ではなく、「工数 × 単価」という式そのもの にあります。式が違えば、同じ努力の行き先が変わる ―― それだけの話です。
インハウスに移れば解決、でもない ―― 「割り当ての壁」
ただし、インハウスに移れば自動的に道が開ける、という話ではありません。インハウスでもスキル獲得の教育が成立していない現場は多い というのが実情です。
よくある形はこうです。
- 中核となる設計判断や、コスト影響の大きい部分は、少数の有能なメンバーが握っている
- ミドル層には、コスト影響の小さい周辺機能 が繰り返し割り当てられる
- 周辺機能をいくら丁寧に作っても、前節で述べた「文脈を跨いだ整合性」を扱う機会が来ない
- 結果として経験が積まれず、次も同じ層のタスクが割り当てられる
これは誰かの悪意ではなく、短期的には合理的な判断です。中核部分は失敗コストが高いので、実績のある人に寄せるのが安全だからです。しかしこの合理性を続けるかぎり、組織としては人が育たず、個人としては停滞する。 「タスクが割り当てられないから経験が積めず、経験がないから割り当てられない」という循環に入ります。
突破口は「割り当てを待たずに実証できる」こと
ここで、この技術領域の性質が効いてきます。サーバレスは、個人が単独で実証を積みやすい数少ない領域です。
- 検証コストがほぼゼロ。 ゼロスケールする以上、動かしていない時間の費用は発生しません。無料枠の範囲で、スレッド設計の効果もべき等性の挙動も、自分の手元で実測できます。大規模な検証環境も、上長の承認も要りません。
- 周辺機能にも適用できる。 並列化とべき等化は、中核でなくても効きます。担当している地味なバッチ 1 本を並列化して実行時間を 10 分の 1 にすれば、それは立派な実測値です。
- 数字は割り当ての外側でも提示できる。 「この処理はこう変えれば月いくら下がる」という試算は、担当外の領域についても作れます。そして数字を伴う提案は、経験の有無ではなく内容で評価されやすい。
つまり 成果を数字で示せる領域を選ぶことが、割り当ての壁を迂回する現実的な手段になる ということです。「経験がないから任されない」の循環は、任される前に小さく実証してしまうことで断ち切れます。
本連載で扱う技術は、その種の成果を出しやすい領域を意図的に選んでいます。 並列化でインフラ費を下げ、べき等設計で深夜の障害対応をなくす。どちらも 削減額と削減時間という形で数字にできる 成果であり、手元で小さく検証してから提案できる 種類のものです。
だからこそ本連載は、概念の説明ではなく 動くコードと具体的な試算 で書いています。読んで納得するだけでなく、明日そのまま試せることを重視しています。
9. 本連載について
出発点：サーバレスでは「責務」が再配分される
第 8 章で挙げた 5 つの破綻パターンには、共通する正体があります。どの層も引き受けていない責務が生じている ということです。
従来の構成では、多くの責務が暗黙のうちに引き受けられていました。1 つのプロセスが起動しっぱなしなら、状態はメモリに置けます。1 台で直列に処理するなら、二重実行は起こりません。OS のスケジューラが CPU を割り振ってくれるなら、並行度を意識する必要もありません。これらは設計されたのではなく、環境の副産物として与えられていた のです。
サーバレスでは、その前提が消えます。インスタンスは揮発し、同じ処理が並行して走り、同じメッセージが 2 回届く。かつて環境が肩代わりしていた責務が、明示的にどこかの層へ再配分される ―― この再配分を把握しないまま従来の設計を持ち込むと、責務の空白が生まれ、本番の負荷で表面化します。
そこで本連載は、まず 各層が何を保証しなければならないか を明確にし、次に それを実現する理論と実装 を示す、という順序で進めます。
| 層 | 負うべき責務 | 実現する理論・技法 | 扱う回 |
|---|---|---|---|
| プラットフォーム | スケーリング、可用性、配信の再試行 | 課金モデルと同時実行数の設計 | 本記事（第 4・5 章） |
| ハンドラ（実行効率） | 与えられた並行度を使い切り、待ち時間を課金に変えない | GIL の理解、スレッドセーフ設計、コネクションプール | 第 1 回 |
| ハンドラ（正しさ） | 二重に実行されても結果を壊さない | べき等性、べき等キー、レスポンスの記録と再生 | 第 2 回 |
| データストア | 一意性と原子性の保証（プロセス内ロックは無力） | 条件付き書き込み、楽観的ロック | 第 2 回 |
| メッセージング層 | 配信保証と、失敗の隔離 | at-least-once、DLQ、指数バックオフ | 第 3 回以降 |
| インスタンス | 状態を持たない（いつ消えてもよい） | 状態の外部化、Transactional Outbox | 第 3 回以降 |
| 観測基盤 | 分散した実行を 1 本の処理として追跡する | 構造化ログ、分散トレーシング | 第 3 回以降 |
言語は Python を中心に、実際に動くコードで示します。
| 回 | テーマ | 扱う内容 |
|---|---|---|
| 第 1 回 | スレッドセーフ設計によるコスト最適化 | GIL の正しい理解、I/O バウンド処理の並列化、ThreadPoolExecutor の実装、コネクションプールの落とし穴、コスト試算 |
| 第 2 回 | べき等（冪等）設計 | at-least-once 前提の設計、条件付き書き込み、べき等キー、FastAPI / SQS の実装、並列テスト |
| 第 3 回以降 | 非同期メッセージングのエラー設計ほか | DLQ と指数バックオフ、Transactional Outbox、サーバレスの可観測性 |
上の責務表で言えば、第 1 回は「実行効率の責務」、第 2 回は「正しさの責務」 を扱います。並列化して速く安くする（第 1 回）と、並列化とリトライの下でも壊れない（第 2 回）。この 2 つは表裏一体であり、片方だけでは実務で使えません。速いが壊れるシステムも、正しいが高くつくシステムも、どちらも実務では失格だからです。
責務の設計は、AI に任せきれない ―― 指示とレビューの両端に理論が要る
上の責務表を眺めると、この作業の性質が見えてきます。責務とは、コードのどこにも書かれていないもの です。
「このハンドラは 2 回呼ばれる可能性がある」という事実は、ハンドラのソースコードを何度読んでも出てきません。上流のメッセージング設定、配信保証のモデル、クライアントの再送方針といった システムの運用前提 から導かれるものだからです。同様に「この処理は I/O 待ちが支配的だから並列化が課金に効く」も、コードの字面ではなく実行環境の課金モデルから来ます。
ここが、生成 AI を使った開発で最も破綻しやすい箇所です。
| AI が強い領域 | 人が担う必要がある領域 | |
|---|---|---|
| 対象 | どう書くか（実装） | 何を保証すべきか（前提・責務） |
| 例 | ThreadPoolExecutor を使った並列化のコード | そもそも並列化が課金に効くワークロードかの判断 |
| 例 | 条件付き書き込みの実装 | この処理にべき等性が必要だという認識 |
| 検証 | 単体テストが通ることの確認 | 並行・再送の下でも壊れないことの確認 |
厄介なのは、責務の欠落したコードほど「もっともらしく動く」 ことです。べき等でない決済処理も、単体テストは通ります。コネクションプールの設定を欠いた並列処理も、開発環境の低負荷では正常に動きます。壊れるのは並行実行とリトライが同時に起きたときだけ ―― つまり 本番でしか再現しません。
なぜ仕様書から漏れるのか ―― 責務の大半は非機能要件である
漏れる理由は、責務の性質にあります。ここまで挙げた責務は、そのほとんどが非機能要件に属します。
| 仕様書に書かれること | 書かれないこと | |
|---|---|---|
| 種別 | 機能要件（何をするか） | 非機能要件（どう振る舞うべきか） |
| 例 | 「注文を登録し、決済を実行する」 | 同じ要求が 2 回届いても課金は 1 回であること |
| 例 | 「対象データを集計して通知する」 | 待ち時間を並列化して課金時間を圧縮すること |
| 例 | 「処理結果を保存する」 | インスタンスが消えても結果が失われないこと |
さらに厄介なのは、これらが「インフラ特性に由来する非機能要件」 だという点です。可用性やレスポンスタイムのように、一般的な非機能要件のチェックリストに載っている項目ですらありません。「同じメッセージが 2 回届く」は業務仕様から出てくる話ではなく、実行基盤の配信保証モデルから出てくる 話だからです。
そして従来、これらは 書く必要がありませんでした。常駐プロセスが状態を保持し、直列実行が一意性を保証していた時代には、環境が黙って満たしてくれていたからです。日本の仕様書の様式は、その時代の慣習をおおむね引き継いでいます。
結果として、こうなります。
シンプルな仕様書をそのまま AI に渡すと、インフラ特性に由来する責務が構造的に欠落する。
AI は仕様に忠実です。書かれていないものは実装されませんし、「これは書かれていないが必要だろう」と補完してくれるとは限りません。 熟練したエンジニアが「この処理はリトライが来るな」と暗黙に補っていた部分が、そのまま穴として残ります。
裏を返せば、先ほどの責務表は、そのまま AI への指示チェックリストとして使えます。 「この処理は 2 回実行されうるか」「待ち時間は課金対象か」「状態はどこに置くか」を仕様に明示してから渡せば、AI は十分に信頼できる実装者になります。理論は、AI を使いこなすための前提条件でもあるということです。
つまり 「べき等にしてください」と指示できるのは、べき等性が必要だと分かっている人だけ です。理論を持たなければ、正しい指示は出せず、出力の妥当性も判断できない。AI への指示とレビューの両端に、理論的理解が要る ―― 問題は AI の能力ではなく、前提を供給し検証できる人がいるかどうか です。
この領域の需要は、AI 時代に縮まない ―― むしろ高まる
最後に、なぜ今このスキルに投資する価値があるのかを書いて締めとします。根拠は 3 つあります。
1. AI が書く量が増えるほど、責務を担保する仕事が増える
前節のとおり、AI が担うのは実装であり、前提の供給と検証は人に残ります。そして生成 AI によって、世に出るシステムの量そのものが増えます。破綻は関数の中ではなく 関数と関数のあいだ、並行実行とリトライの文脈 で起きるため、生産されるコードが増えれば 責務の空白が生まれうる接合部も比例して増えます。
書く仕事が自動化されるほど、繋いで壊れないことを保証する仕事の比重が上がる。 しかもその役割を担えるのは、理論を持つ人に限られます。
2. AI アプリケーション自体が、この連載の技術を最も必要とするワークロードである
ここが最も直接的な理由です。LLM の API を呼び出す処理は、本連載が扱う課題の典型例そのものです。
| AI アプリの特性 | 対応する回 |
|---|---|
| 推論 API の応答に数秒〜数十秒かかる。極端に I/O バウンド | 第 1 回（並列化しなければ待ち時間がそのまま課金される） |
| レート制限とタイムアウトが日常的に発生し、リトライが前提 | 第 2 回（at-least-once 前提の設計） |
| トークン課金は従来の API より桁違いに高い | 第 2 回（二重実行が、そのまま二重の請求になる） |
| 処理時間が読めず、負荷が突発的 | 第 4・5 章（ゼロスケールと従量課金の相性が良い） |
従来の Web API なら、二重呼び出しの損失は「無駄なクエリ 1 回」で済みました。LLM API では、それが実費として跳ね返ります。 べき等設計の経済的な重要度は、AI の普及によってむしろ上がっています。
つまり、AI を業務に組み込むプロダクトが増えるほど、本連載の内容を必要とするシステムが増える という関係にあります。
3. 供給が構造的に不足している
第 8 章で述べたとおり、このスキルは業界の契約構造上、育ちにくい位置にあります。需要が増える一方で供給が増えにくい ―― これは、投資対象としては悪くない条件です。
本連載は、この領域で必要になる 理論と、そのまま動く実例 を示していきます。GIL の挙動やべき等性の定義といった原理を押さえたうえで、実際にデプロイできるコードと、金額に換算した試算まで含めます。
読んで理解するためだけでなく、明日の業務で使い、成果を数字で示すため の連載です。
まずは第 1 回から読み進めてください。
→ 第 1 回：サーバレス時代の Python コスト最適化 ―― スレッドセーフなマルチスレッド設計
本記事に記載した Cloud Run の仕様・料金体系は執筆時点のものです。最新の情報は公式ドキュメントをご確認ください。
※ 本記事は、筆者が記述した内容および構成方針をもとに、Claude を用いて清書・整形と事実確認を行っています。主張・技術的判断・実務経験に基づく評価はすべて筆者によるものです。
(2)
