それ、本当にLambdaでやりますか？ 2026.02.20 TECH BATON in 東京 〜今 Lambdaどうやって使ってる？ 〜 すずけん / @szk3 

1 2 自己紹介 はじめに 経歴 前職にてフロント・バックエンド・インフラ・ネイティ ブアプリ・EMなど一通り経験した後に、パブリックク ラウド活用のスペシャリストとして、AWS移行やCCoE の組成などを牽引。2022年10月にカミナシに入社。 カミナシでの仕事 クラウド・インフラロールのICとして、技術負債解消や サービスチームでの開発に従事した後、新規事業「カミ ナシ 設備保全」にて、プレイングマネージャー型のEM を実践中。 株式会社カミナシ エンジニアリングマネージャー 鈴木 健太郎 (すずけん) szk3 

今 Lambda に対して感じていること 

Lambdaといえば、サーバーレス / FaaS を牽引した立役者。 イベント駆動型のマネージドサービスを利用することは、アーキテクティングにおけるス タンダードになり、Lambdaは設計パターンの定石として、当たり前のように採用される ようになっている。 Lambdaを利用する設計パターンは定石になった 今 Lambda に対して感じていること 1 

では、非同期処理なら Lambda が第一選択肢になる？ いや、（個人的には）そんなことはない。 昔より今のほうが、Lambdaをアーキテクチャとして採用することに慎重になっている。 … なぜか？ 定石だからといって、何も考えずに選んでないか？ 今 Lambda に対して感じていること 1 

Lambdaのビジネスロジックに集中しRuntimeで実行すればよいというシンプルな思想は美しい一方、 それらを運用しようとすると、ソースコードの置き場所（リポジトリ管理との相性）や、ビルド・デ プロイツールの選定、複雑性が高い非同期処理の考慮など、検討すべき点が実はたくさんある。 運用を見据えたアーキテクティングの複雑性が上がっている 今 Lambda に対して感じていること 1 １．エコシステムの多様化 / 開発者体験への考慮 　　SAM？、Serverless Framework？、GitHub Actionsでbuild？ 　　ローカル開発どうする？テストツールは？ ２．コンテナに代表される競合的インフラの台頭 　　ECS/Fargate？ AWS Batch？ 例えば... 

それ、本当にLambdaでやりますか？ 

いいえ、使ってます。ですが、現チームでは一つのユースケースにのみ採用している。 とはいえ、そのユースケースでさえ、最初はLambdaを採用していたわけではなかった。 じゃあ、Lambda使ってないの？ それ、本当にLambdaでやりますか？ 1 

いわゆる、Lambdaの採用が第一候補になりうる王道のユースケース。 　 　・既存Webアプリケーションに、後付けで画像変換処理を入れる 　・変換対象はブラウザから署名付きURLを使ってS3に直接アップロード/ダウンロードされる画像 　・アップロードが成功したらAPI経由でDBに画像の情報を永続化している 　・すでにアップロードされている既存画像も生成の対象とする必要がある 　・現時点のアプリケーションにおいて、Lambdaを使ったアーキテクチャは存在しない 　・諸事情により、特定の期日までに対応したい（1日でも早く対応できるのが望ましい） ユースケース：サムネ画像生成機能の実装 それ、本当にLambdaでやりますか？ 1 コンテキストは、 

Design Doc を一部抜粋 それ、本当にLambdaでやりますか？ 1 

なるべく作らないで済む方針を選択 １．運用コストが増えない 　　既存のBackendに組み込むため、新規インフラ不要 ２．既存画像の移行が不要 　　取得時に自動で遅延生成されるため、既存画像の移行処理が不要 初手、Backendレイヤーでの画像変換を選択 それ、本当にLambdaでやりますか？ 1 

結果 ・実装からデプロイまでだいたい1-2日くらい。 ・通信量は、約 1/35 に！ やったぜ！！！ 初手リリース！ それ、本当にLambdaでやりますか？ 1 

数日後、想定外の画面のレスポンスに影響に気づく... 調査した結果、既存の共通処理に無駄な箇所が見つかったのと、想定外に呼び出し回数が増え るケースがあったことで、特定の画面のレスポンスを遅くしてしまう事象が発生。 また、複数サイズの最適化画像を生成したいという要件も浮上。 うーん、これは... と、思ったのもつかの間... それ、本当にLambdaでやりますか？ 1 

（どんまい、おれたち 😇） やっぱ、Lambda使うわ それ、本当にLambdaでやりますか？ 1 

すぐに方針転換し、あるべき姿から逆算して設計し直し。 ・既存バックエンドの画像変換処理を、Lambdaに切り出し ・ビルド・デプロイは、Docker ImageをECRにpushする方針に ・Alpineでlibvipsを使って、heifを最適化するのに、lib-heif周りの処理を追加 ・ローカル開発では、AWS Lambda Runtime Interface Emulator (RIE)を利用 ・既存画像は、一括変換処理をAWS Batch + ECS Task で実装 結果的に、既存の良くない実装も直せて、今後の拡張性も担保できた。 AIコーディングエージェントの恩恵もあり、実働としては数日くらいでリプレイスの準備完了。 次の一手、S3イベント + Lambdaでの処理にリプレイス それ、本当にLambdaでやりますか？ 1 

まとめ 

それ、本当にLambdaでやりますか？ まとめ 1 ＼ 今回のユースケースにおいての学び ／ 　最初から作ることもできたが、なるべく作らない方針で進めたからこそ、気づけたこともあり、 　良い Fail Fast だったと思う。 AIエージェント時代は、実装自体が負担にならないので、作り直しも負荷が低い。 

それ、本当にLambdaでやりますか？ まとめ 1 一方で、Lambdaに限らず「ビジネスロジックだけ考えればいい」という視点は、プラットフォーマー としては正しいが、運用しつづけるユーザー視点で見ると若干ホントかなぁ？という気もしている。 実際には... １．ビジネスロジックだけに集中すればいいわけではない 　 既存のコンテキストに合わせ、将来の運用や開発体験を見据えた、アーキテクティングが必要 ２．エコシステムや競合するアーキテクチャの拡大 　 選択肢が広がることはとても良いが、一方で運用設計の判断負荷も上がっている 　 ワークロードに応じた、使い分けや判断力が必要 

Lambdaは使いやすくて大好きだけど、Lambda を使ったアプリケーションをちゃんと運用しようとす ると、考えることは意外と多いことを忘れてはいけない。 初手Lambdaで行ける！と感じた時こそ、「それ、本当にLambdaでやりますか？」 と、最初の設計判断を確かめる勇気が必要だと感じます。 （最初の直感が正しいこともあるけどね） それ、本当にLambdaでやりますか？ まとめ 1 

株式会社カミナシ https://kaminashi.jp