2026年、サーバーレスの現在地 ~「制約と戦う技術」から「当たり前の実行基盤」へ~

本記事は2026年1月31日のJAWS-UG名古屋で発表した内容を記事にしたものです。スライドは以下に貼り付けておきます。

現在、AWSを中心としたクラウドを使うにあたってサーバーレスで構成を組むことは当たり前になってきたでしょう。もちろん、制約条件等からIaaSを使うことを否定することはありません。しかし、特にAIを実装するにあたってEC2でオートスケーリングを組むと言ったことは発想にすら出てこないでしょう。AWSからリリースされるサービスもその多くがサーバーレスを基軸として構成されており、もはやサーバーレスとすら呼ぶ必要すらないかもしれません。この記事ではサーバーレスというムーブメントが2014年のAWS Lambdaリリースに始まり、現在のサーバーレスの現在地を様々な観点から整理して今後、自分たちがクラウドをどう向き合うべきかのヒントになれば幸いです。

制約条件の塊だった過去のサーバーレス

過去のサーバーレスの定義で言うと2014年 - 2018年くらいまでを想定しています。最初のLambdaがリリースされた際の上限実行時間を皆さんは御存知でしょうか。なんと6秒しかありませんでした。その後、15分まで伸びましたがこのタイムアウトの上限が、想定できない将来の実行時間を想定した時にLambdaの使用にブレーキをかけていたのではないでしょうか。以下の図に代表的な制約や困りごとをまとめてみました

まさに過去のサーバーレスはこれらの制約をどのように回避して運用レスなアプリケーションを開発することが肝となっていました。当時でもしっかりとこれらの制約を理解した上でサーバーレスのコストやスケーラビリティを最大限活かしたアプリケーションを開発することの出来るAWSエンジニアは存在していましたが、結果的に多くの方はその学習コストの高さから、普段から慣れているIaaSやコンテナを使うほうが早いという結論に達することが多かったのではないでしょうか。

緩和された制約条件

現在のサーバーレスではローンチ当時にあった多くの制約条件が緩和されています。代表的なものを以下の図にまとめています。

これらの制約条件が緩和されただけでもだいぶサーバーレスは使いやすいものになったのではないでしょうか。今や、サーバーレスは特殊な技術から普通の実行基盤へ進化し、「制約条件使えるか？」を戦う技術ではなく「どう設計するか？」の時代に突入したと言っても過言ではないでしょう。

LambdaはFaaSを超えWebアプリ実行基盤へ

過去、API Gateway + LambdaでWebアプリをつくろうとした時に、API Gatewayの背後にRest APIのメソッドごとにLambdaを作成。結果として30 - 50個のLambdaが出来上がってしまい管理できなくなったという経験をした方も多いのではないでしょうか。運用を減らすために導入したサーバーレスですが、その分管理コストがあがってしまいトータルで考えた時に「楽になった」とは思えなかったでしょう。そしてこの数十個ものLambdaのランタイムアップデートもまた地獄だったのではないでしょうか。

しかしながら現在では、Lambda Web Adapterというライブラリの登場によって1つのLambdaでおなじみのWebフレームワークを使ってAPIを構築できるようになりました。Lambda Web Adapterの解説についてはフロントエンド SSR 環境構築の悩みを解決！最新 React Router v7 と Next.js 15 のサーバーレス環境構築方法の記事に書いてますのでご参考頂ければと思います。

この技術のお陰で以下のようなモダンなWebフレームワークがLambda上で動くようになりました。

• Next.js, React Router v7 (Remix) など SSR (Server-side Rendering) フロントエンドフレームワーク
• Express, FastAPI, Flask など Node/Python ウェブ/WebAPIフレームワーク
• Spring Boot など Java ウェブ/WebAPIフレームワーク

さらにコンテナをベースとしているため、そのまま状況に応じてFargateやEC2に移行することも可能です。そしてかつては不可能と思われていた、オンプレからのサーバーレスへの以降も現実的な手段となりました。

AI時代はサーバーレスであることが「前提条件」となった

LLMを始めとするAIサービスは、最初からサーバーレスネイティブで設計されています。これは以下のようなAIの特性がサーバーレスにドンピシャでマッチするからです。

• 予測できないトラフィックのためLLMにはスケーラビリティが必要
• ある程度の失敗を前提を前提としているためリトライロジックが重要
• 推論には時間がかかるためコールドスタートは気にならない
• トークン単位の課金でありサーバーレスの課金モデルにあう

まさにサーバーレスというテクノロジーをクラウドベンダーが成熟させてきたからこそ、現在のような使いやすいAIサービスがローンチされて普及したと言っても過言ではないでしょう。

「AWS障害がおきたら指を咥えて待つしかない」は昔話化した

過去、サーバーレスで障害が起きた場合には何もせずに復旧を待つしか無いと言うのが一般的では無かったでしょうか。しかし今は違います。まず、2018年ころからLambdaを始めとするサーバーレスなサービスにもSLAが公開されるようになりました。以下は一部の例になります。

これにより、SLAの数値を軸に信頼性を設計判断の材料として使えるようになりました。さらにこれ以上の可用性を求めたいサービスでは、EventBridge, CloudFront, Route53などの機能をうまく使うことでマルチリージョン構成の今はマルチリージョン構成によるDR戦略も技術的には十分現実的な選択肢となりました。例えば以下のアーキテクチャにてRoute 53 Health Checkの機能を使うことでAWS IoTに障害が発生すればセカンダリーのリージョンへ自動でフェイルオーバーしてくれます。

そしてさらなるメリットとしてサーバーレスなサービスは使った分だけの課金です。つまり無課金にてホットスタンバイ構成のDR戦略が可能となるのです。

クライアント側でのリトライ処理を適切に仕込むことでAWSに障害が発生したときもある程度克服が可能になってきました。ここ10年以上にわたりAWS障害に関する特性も見えてきましたが、いきなりLambdaなどのサービスなどがすべてシャットダウンされるといった障害は発生していません。AWS障害は「エラー率の上昇」の形で現れクライアントでのリトライを徹底すれば克服可能な場面が多いです。つまり、Lambdaのエラー率が上昇したとしてもリトライを繰り返すことでエラーが発生していないLambdaのインスタンスを実行できるガチャ的なイメージを想像してもらうとわかりやすいと思います。

ベンダーロックインからの脱却

サーバーレス黎明期ではたまにサーバーレスを使うことによるベンダーロックインの危険性が議論されていました。しかしながら今はHono など、各種クラウドベンダーのエッジで動かせるようにしたライブラリが出現してグローバルで広く使われるようになり、Lambda はじめコンテナ技術が進み、マイクロサービスアーキテクチャでサービス間の界面のインタフェースをしっかり設計して作っていれば、AWS でなくても十分動かすことが可能になります。ベンダーロックインによるリスクやポータビリティの向上は前ほどではなく十分現実的になってきています。

まとめ

というわけで、2026年のサーバーレスの現在地についてまとめてみました。サーバーレスはもう『尖った技術』ではありません。かつての「制約パズル」を解く時代は終わり、現在はインフラの当たり前の選択肢になったことが見えてきたかと思います。サーバーレスはもはや「Lambda か否か」を議論する対象ではなく、アプリケーション全体の設計思想の一部として自然に組み込まれる存在になりました。制約が緩和された今、設計の良し悪しはより鮮明に結果に表れます。これはある意味「選択の責任」を開発者に返してきたのだと思います。スケールしない理由も、運用が破綻する理由も、もはやプラットフォームのせいにはできません。2026年、サーバーレスは当たりまえの実行基盤になりました。その中で私たちにとって重要なのは、それをいかなる状況でもうまく判断し、使いこなす設計力となってくるでしょう。