"架空のおにぎり店"の成長物語に学ぶ、サーバレスで起きる「成長痛」への対処法：AWS Summit Japan 2026

サーバレスアーキテクチャは小規模ビジネスの立ち上げから世界展開まで対応できる。だが規模の拡大とともに、システムは「成長痛」に突き当たる。架空のおにぎり店の成長物語になぞらえてAWS Japanが説いた、5つの乗り越え方とは。

[斎藤公二，ITmedia]

　サーバレスアーキテクチャは、個人店レベルのビジネスの立ち上げから、世界進出を見据えた規模の拡大まで対応できる。2026年6月25〜26日に開催された「AWS Summit Japan」で、AWS Japanの北村友氏（ソリューションアーキテクト）は「おにぎり月40個から32万個へ―ビジネスの成長痛を和らげるサーバーレスアーキテクチャの育て方」と題して講演した。

　題材は、おにぎりのモバイルオーダーサービスを提供する架空の企業「クラウドにぎり」だ。「個人店から始まり、国内外60店舗へ、おにぎり生産を月40個から月32万個へと成長させた企業のサーバレスアーキテクチャの変遷を、現実に近いストーリーとして紹介する」（北村氏）

　ただ、サーバレスで創業した企業は、ビジネスの成長に伴って痛みに直面することも多い。クラウドにぎりも物語の中で、成長の節目ごとに異なる「成長痛」を経験した。北村氏はその乗り越え方を5つの原則に整理した。

おにぎり店を成長させた5つの原則とは

　5つの原則とは「適切なサイジング」「同期処理から非同期処理へ」「仕事を楽にする」「パフォーマンス最適化」「コスト最適化」だ。

全面ダウンを招いた「Fat Lambda」問題

　1つ目の「適切なサイジング」は、サーバレスアプリケーションのサイジングと構成方法についてだ。物語の設定では、クラウドにぎりは2020年に1店舗（自宅）、月40個の注文数で創業し、1年後には近所に4店舗を加えた計5店舗、月4000個の規模の企業に成長した。だが、アーキテクチャは「Amazon API Gateway」と「AWS Lambda」で構成したシンプルなものだったため、1つの関数に多くの責務を詰め込むアンチパターン「Fat Lambda」の問題が発生した。

　「1つのLambda関数が注文、在庫確認、通知、決済などの全ての処理を実行していた。デプロイに5分、テストに45分かかっていたが、とりあえず動いていればOKというスタンスだったため、Fat Lambdaというアンチパターンに陥った。その結果、ゴールデンウィークに小さなバグがシステム全体をダウンさせ、復旧に長時間を要した。この成長痛をきっかけに適切なサイジングを学ぶことになった」（北村氏）

　北村氏によると、Lambdaのサイジングには普遍的な原則があるという。

• 単一責任：1つの関数は1つの明確な責務を担う
• 責務に応じたサイジング：Lambdaではメモリ量に応じてCPUパワーが比例配分されるため、メモリを増やすとパフォーマンスが向上する
• パッケージの最適化：パッケージを小さくして、コールドスタート（関数の初回起動時に生じる遅延）を低減する

　「最初から細かく作るのではなく、まとまりのある関数から始め、成長痛を感じたときに分割することが重要だ。スタックやリポジトリも同じだ。理論的な完璧さを優先しないことだ」（北村氏）

　分割後は、注文や在庫管理、顧客体験などのチームごとに適切な技術を利用し、自律性を持たせる。こうした構成はドメイン駆動型組織に発展する。その際のポイントは2つある。

1. ドメインごとに自分のデータを所有し、チームで効果的にデータを管理する
2. リポジトリを関数ごとに作るのではなく、1つのリポジトリで複数サービスを管理できるようにする

多店舗展開で「Fat Lambdaアンチパターン」に直面（出典：AWS Japanの講演資料）

注文待ちの離脱を防ぐ、非同期処理への移行

　2つ目の「同期処理から非同期処理へ」は、複数地域に店舗を広げたフェーズで求められる対応だ。適切なドメイン分割でエンジニアチームの生産性を高めたクラウドにぎりは、2022年には18店舗、月5万個の規模で地域展開する企業になった。アーキテクチャは、API Gatewayと複数のLambda関数（在庫、決済、通知処理など）を直列につないだ構成だ。直面した問題は「同期処理の連鎖」だ。

　「分断されたLambda関数が同期的に処理することに問題があると分かった。ユーザーは全ての処理が終わるまで待機していなければならない。実際にランチタイムのピーク時にはパフォーマンスが低下し、注文待ちによるユーザーの離脱が増加するといった成長痛に直面した。1つの遅いサービスがワークフロー全体に影響し、多くの顧客が確認を待っている間に注文を放棄していた」（北村氏）

　そこで採用したのがイベント駆動設計だ。サービス間通信にイベントバスを使い、直接的なサービス依存を排除した。疎結合による障害の分離と、独立したスケーリングが可能になった。非同期コールバックによって、処理の進捗をクライアント側の画面に反映できるようになった。このイベント駆動設計で利用するサービスは4つある。非同期処理を実行するための「Amazon SQS」と「Amazon EventBridge」「AWS Step Functions」「AWS AppSync Events」だ。

　「LambdaがEventBridgeにメッセージを送り、在庫確認、決済処理、通知処理などのサービスを非同期で処理し、完了したら自身のイベントを発行する。その後、AppSync Eventsと連携して、処理が完了するたびにリアルタイムにクライアントの情報を更新する。ユーザーは決済完了、キッチン準備中、お渡し準備完了といったメッセージを確認できる。レスポンスタイムは20秒から0.2秒に短縮された」（北村氏）

　北村氏は、「Lambda Event source mapping」やAmazon SQSを使えば、高トラフィック時のシステム負荷の調整や、正しく処理されるまでのメッセージの保持、エラーハンドリングが可能になるとも説明した。

非同期処理へ移行しサービス品質を向上させる（出典：AWS Japanの講演資料）

人手不足を越える「仕事を楽にする」工夫

　3つ目の「仕事を楽にする」は、リソース不足の解消や運用負荷の削減に向けた取り組みだ。非同期処理によって大量の注文をさばけるようになったクラウドにぎりは、2023年には35店舗で月18万個を実現した。ただ、離職者が発生して追加採用が進まず、人手不足と運用負荷の増加という課題に直面した。

　「離職者が残した複数のLambda関数でエラーが発生し、システム障害が頻発した。単純なデータ変換やサービス間の直接呼び出し、データのルーティング、データの情報追加などを全てLambdaでやるべきかが検討課題になった」（北村氏）

　そこで有効なのが、Lambda関数のコードを書かずにAWSサービス同士を直接つなぐ方法だ。まずはStep FunctionsのAWS SDK統合だ。これを使うことで、AWSサービスを呼び出すための多くのLambda関数を排除できる。220以上のAWSサービスについて1万4000以上のAPIアクションが利用できる。

　Lambda関数内で非同期処理とオーケストレーションを実行する方法もある。それが「Lambda durable functions」（Lambda関数内で状態管理や失敗からの復旧を自動処理し、長時間のワークフローを実行できる機能）だ。北村氏は「ビジネスロジックをシンプルな逐次コードで記述し、使い慣れたプログラミング言語とツールを利用できる」と説明した。

　このように、仕事を減らせるところは減らし、直接サービス統合を使えるところは使う。コードが必要な場合はLambda durable functionsを使う。こうしてクラウドにぎりは全体のワークフローを整理できた。

Lambda関数自体のパフォーマンス最適化

　ワークフローの整理でリソース不足を乗り越えたクラウドにぎりのアーキテクチャは、Step FunctionsやLambda durable functionsの裏側にLambda関数を置く構成になった。次に取り組んだのが4つ目の「パフォーマンス最適化」だ。

　「いよいよ全国展開を見据え、注文数も月28万個の見込みになった。全体のワークフローは最適化できたものの、Lambda関数自身の最適化は未着手だった。実際に負荷テストを行ってみると、関数の実行時間やコールドスタートなど、関数自身のパフォーマンスがボトルネックになったことが分かった。この成長痛に対応するため、Lambda関数の最適化を含め、パフォーマンスの最適化に取り組んだ」（北村氏）

　Lambdaはマネージドサービスのため、ユーザーが最適化できる部分は限られている。取り組めるのは、メモリ割り当てや関数の初期化コード、ハンドラーコード、全体のパッケージサイズなどだ。北村氏は具体策として、「AWS Lambda Power Tuning」を使ったコストパフォーマンスの最適化や、「Provisioned Concurrency」と「SnapStart」を使ったコールドスタート対策、ランタイムのアップグレードなどを挙げた。

アーキテクチャを見直し、パフォーマンスを最適化（出典：AWS Japanの講演資料）

世界進出を見据えたコスト最適化

　5つ目の「コスト最適化」は、海外展開を含め60店舗、月32万個を想定したサービス運営の取り組みだ。海外出店には多額の投資が必要になるが、これまではスケールを優先し、コスト削減は後回しだった。

　「Lambda関数の最適化により、全国展開できるアーキテクチャとなったものの、AWS利用料が一気に増加する懸念があった。世界展開で別リージョンにデプロイすると、ただでさえ出店費用が高いのに、AWS利用料がさらに高い金額になってしまう。そこで取り組んだのがAWSサービスのコスト最適化だ」（北村氏）

　北村氏は、サーバレスの料金モデルの理解がコスト効率のいいアーキテクチャ判断の前提になると述べ、Lambdaの課金体系を説明した。Lambdaのオンデマンドコストは、使った分だけ支払う体系で、リクエスト数とコンピュート時間に対して課金される。課金はミリ秒単位で、呼び出しごとに発生する。そのため、処理の間に隙間があるワークロードではコスト効率が良くなる。

　最後に北村氏は「ビジネスの拡大に沿って、適切なサイジングからコスト最適化までのテーマに取り組んでいく。どのような順番からでも適用できる。ぜひ皆さんのビジネスにおいて成長痛を感じた際は、これらの原則を思い出してほしい」とアドバイスした。

サーバレスの仕組みをフェーズごとに最適化することが重要（出典：AWS Japanの講演資料）