AWS re:Invent 2025 IoT 向け?アップデート&次世代モビリティ最前線

「2025/12/17 AWS re:Invent 2025 ふりかえり勉強会 re:Growth 2025 製造業向け in Tokyo」に登壇した際の発表資料です。
https://events.classmethod.jp/seminar/251217-regrowth-tokyo-mbt/

Transcript

1. 2025/12/17 re:Growth 2025 製造業向け in Tokyo 若槻⿓太 AWS re:Invent 2025 IoT 向け?アップデート&次世代モビリティ最前線
2. ⾃⼰紹介 2 • 若槻⿓太 • 所属 ◦ クラスメソッド株式会社 ◦ 製造ビジネステクノロジー部 • ソフトウェアエンジニア • JAWS-UG IoT 専⾨⽀部 運営メンバー • 2025 Japan AWS Top Engineers • 2025 Japan All AWS Certifications Engineers • 2025 AWS Community Builders (User Group Leaders) https://dev.classmethod.jp/author/wakatsuki-ryuta/ re:Invent 参加歴：今年で4回⽬ （2022,2023,2024,2025）
3. アジェンダ（どれかが誰かに刺されば良いな） 3 1. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 2. Lambda Managed Instances（LMI） 3. ロボタクシー「Zoox」に乗ってきた 4. 終わりに ラスベガス到着後のハリーリード空港にて撮影
4. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 4
5. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 5 Dr. Werner の今年で14回⽬(!)とな るキーノートで彼は Renaissance を引き合いに出して、AI 時代の開 発者像について語った。 https://www.youtube.com/watch?v=3Y1G9najGiI
6. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 6 Dr. Werner の今年で14回⽬(!)とな るキーノートで彼は Renaissance を引き合いに出して、AI 時代の開 発者像について語った。 絶賛の声が多かったが、聞いてい て思ったのは、「Renaissance を ある程度知っていた⽅が、話の意 図がより⽴体的に⾒えてもっと楽 しめるぞ！」という点だ。 https://www.youtube.com/watch?v=3Y1G9najGiI
7. というわけで、 Werner キーノートが”もっと”楽しくなる Renaissance の話 を少しだけします。(2分ほど) はじめに: 何度でも⾒返したくなる Werner キーノート、の話 7
8. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 8 中世ヨーロッパでは、宗教権威を 司る教皇と、世俗権威を司る皇帝 の2⼤体制の⽀配下にあった。（諸 説あり） Gemini ⽣成
9. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 9 11〜13世紀の⼗字軍遠征により、 ⻄欧諸国は地中海を通じて東⽅世 界(⻄アジア⽅⾯)と接続され、⻄側 の交易拠点となったイタリアの都 市国家は⼤きく発展し、さらにそ の過程で⾃治権を獲得した。 Gemini ⽣成
10. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 10 この過程で、東⽅世界に保存‧発 展していた古代ギリシア‧ローマ の学問や思想が⻄欧にもたらさ れ、特にヴェネチアやジェノヴァ などのイタリア都市で古典古代の 政治‧⽂化が再評価された。 re:Invent 会場 (The Venetian) にて撮影
11. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 11 その経済的繁栄と知的刺激を背景に、 ⼈間中⼼の思想と芸術を特徴とする Renaissance が成⽴した。 https://www.youtube.com/watch?v=3Y1G9najGiI
12. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 12 そんな Renaissance に Werner は 現在進⾏中の AI の変⾰を重ね合わ せて、 “The Renaissance Developer; IS AN OWNER” “ルネッサンス開発者よ、 オーナーたれ” と訴えた。 キーノート会場にて撮影
13. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 13 つまり、Renaissance 期に起きた⾃治権獲 得や⼈間中⼼の思想への回帰と同様に、現 代の開発者も AI 時代において「オーナー シップを持て」という原点回帰を Werner は我々に働きかけた。（若槻の解釈） キーノート会場にて撮影
14. はじめに: 何度でも⾒返したくなる Werner キーノート、の話 14 つまり、Renaissance 期に起きた⾃治権獲 得や⼈間中⼼の思想への回帰と同様に、現 代の開発者も AI 時代において「オーナー シップを持て」という原点回帰を Werner は我々に働きかけた。（若槻の解釈） この歴史的パラレルが単なる技術発表を超 えた物語性を持たせていて、構造的な遊び ⼼を効かせながら熱いメッセージで開発者 の⼼に⽕を着ける、そんな実に Werner ら しい何度でも⾒返したいキーノートになっ ていた。 キーノート会場にて撮影
15. はじめに: Werner キーノートについて 15 さらに、そんなキーノートの会場 が Renaissance の舞台になった ”Venetia”の名を冠しているのは⾯ ⽩い偶然を感じた。 re:Invent 会場 (The Venetian) にて撮影
16. Lambda Managed Instances (LMI) 16
17. Lambda Managed Instances (LMI) 17 Lambda Managed Instances 発表されましたね！ https://www.youtube.com/watch?v=JeUpUK0nhC0
18. Lambda Managed Instances (LMI) 18 その名の通り、Lambda がマネー ジドな EC2 インスタンス上で動く サービス 開発‧運⽤性は従来 Lambda のま まで、実⾏基盤がリクエスト単位 （MicroVM 単位）ではなくインス タンス単位で起動するようになっ た https://www.youtube.com/watch?v=7mWa2HpCZfg
19. Lambda Managed Instances (LMI) 19 実は他のクラメソ振り返りイベントで、既に何度か取り上げられている https://dev.classmethod.jp/articles/re-growth-osaka-2025-l ambda-before-after/ https://dev.classmethod.jp/articles/ regrowth2025-tokyo-lambda-manag ed-instances-durable-functions/ https://dev.classmethod.jp/articles/ regrowth2025-sapporo-lambda/
20. Lambda Managed Instances (LMI) 20 実は re:Growth では既に何度も取り上げられている https://dev.classmethod.jp/articles/re-growth-osaka-2025-l ambda-before-after/ https://dev.classmethod.jp/articles/ regrowth2025-tokyo-lambda-manag ed-instances-durable-functions/ https://dev.classmethod.jp/articles/ regrowth2025-sapporo-lambda/ まだまだ擦っていきます！
21. Lambda Managed Instances (LMI) 21 Lambda がマネージドなインスタンス上で動くということは...
22. Lambda Managed Instances (LMI) 22 Lambda がマネージドなインスタンス上で動くということは... → （段階的な）料⾦固定のインスタンス上で稼働するので、定常的なリクエ ストをコスト効率よく処理できそう！
23. Lambda Managed Instances (LMI) 23 Lambda がマネージドなインスタンス上で動くということは... → （段階的な）料⾦固定のインスタンス上で稼働するので、定常的なリクエ ストをコスト効率よく処理できそう！ → 定常的なデータ送信が発⽣しがちな IoT 通信の処理に向いていそう！！
24. Lambda Managed Instances (LMI) 24 Lambda がマネージドなインスタンス上で動くということは... → （段階的な）料⾦固定のインスタンス上で稼働するので、定常的なリクエ ストをコスト効率よく処理できそう！ → 定常的なデータ送信が発⽣しがちな IoT 通信の処理に向いていそう！！ → スマートファクトリー、スマートプロダクト、コネクティッドカーなど、製 造業‧⾃動⾞産業でのコスト削減のユースケースに適してそう！！！ Gemini ⽣成
25. というわけで、 ここでは “LMI vs 既存サービス” の コスト⽐較をしてみました！ Lambda Managed Instances (LMI) 25
26. Lambda Managed Instances (LMI) 26 LMI の料⾦には 3 つの要素がある。（料⾦ページより引⽤） 1. リクエスト料⾦: 0.20 USD/100 万リクエスト 2. コンピューティング管理料⾦: Lambda がプロビジョニングおよび管理す るインスタンスの EC2 オンデマンドインスタンス価格の 15% 割増額 (以下 に説明する各インスタンスタイプのプレミアム) 3. EC2 インスタンス料⾦: キャパシティプロバイダーでプロビジョニングされ たインスタンスには、標準の EC2 インスタンス料⾦が適⽤されます。 Compute Savings Plans、リザーブドインスタンス、またはその他の EC2 料⾦オプションを使⽤することでコストを削減できます https://aws.amazon.com/jp/lambda/pricing/
27. Lambda Managed Instances (LMI) 27 ⽐較のための前提条件は以下とする。 • 東京リージョンでの Pricing を採⽤ https://aws.amazon.com/jp/lambda/pricing/ https://aws.amazon.com/jp/ec2/pricing/on-demand/
28. Lambda Managed Instances (LMI) 28 ⽐較のための前提条件は以下とする。 • 東京リージョンでの Pricing を採⽤ • 従来 Lambda (x86) GB-秒単価: 0.0000166667 USD/GB-秒 https://aws.amazon.com/jp/lambda/pricing/ https://aws.amazon.com/jp/ec2/pricing/on-demand/
29. Lambda Managed Instances (LMI) 29 ⽐較のための前提条件は以下とする。 • 東京リージョンでの Pricing を採⽤ • 従来 Lambda (x86) GB-秒単価: 0.0000166667 USD/GB-秒 • LMI 基盤 EC2: t3.medium (4 GiB メモリ) オンデマンド時間単価 : 0.0544 USD/時間 https://aws.amazon.com/jp/lambda/pricing/ https://aws.amazon.com/jp/ec2/pricing/on-demand/
30. Lambda Managed Instances (LMI) 30 ⽐較のための前提条件は以下とする。 • 東京リージョンでの Pricing を採⽤ • 従来 Lambda (x86) GB-秒単価: 0.0000166667 USD/GB-秒 • LMI 基盤 EC2: t3.medium (4 GiB メモリ) オンデマンド時間単価 : 0.0544 USD/時間 • LMI コンピューティング管理料⾦ : 15% 割増し https://aws.amazon.com/jp/lambda/pricing/ https://aws.amazon.com/jp/ec2/pricing/on-demand/
31. Lambda Managed Instances (LMI) 31 ⽐較のための前提条件は以下とする。 • 東京リージョンでの Pricing を採⽤ • 従来 Lambda (x86) GB-秒単価: 0.0000166667 USD/GB-秒 • LMI 基盤 EC2: t3.medium (4 GiB メモリ) オンデマンド時間単価 : 0.0544 USD/時間 • LMI コンピューティング管理料⾦ : 15% 割増し • あくまで単価⽐較なので、LMI でインスタンスがデフォルトで 3AZ に起動 される点は考慮不要 https://aws.amazon.com/jp/lambda/pricing/ https://aws.amazon.com/jp/ec2/pricing/on-demand/
32. Lambda Managed Instances (LMI) 32 【計算】LMI のGB-秒単位あたりのコスト • LMI 時間単価 に 管理料⾦ 15% を乗じたGB-秒単位を求める ◦ 単純化のため GB = GiB とする
33. Lambda Managed Instances (LMI) 33 【計算】LMI のGB-秒単位あたりのコスト • LMI 時間単価 に 管理料⾦ 15% を乗じたGB-秒単位を求める ◦ 単純化のため GB = GiB とする 1. 0.0544 USD/時間 × 1.15 = 0.06256 USD/時間 2. (0.06256 USD/時間) / ((3600秒/時間) × (4GB)) = 0.0000043444 USD/GB-秒
34. Lambda Managed Instances (LMI) 34 LMI と従来 Lambda の同じ単位の単価が出揃った • 従来 Lambda : 0.0000166667 USD/GB-秒 • LMI : 0.0000043444 USD/GB-秒
35. Lambda Managed Instances (LMI) 35 LMI と従来 Lambda の同じ単位の単価が出揃った • 従来 Lambda : 0.0000166667 USD/GB-秒 • LMI : 0.0000043444 USD/GB-秒 両者を⽐較すると、LMI は約4倍優位！という計算結果となった
36. Lambda Managed Instances (LMI) 36 LMI と従来 Lambda の同じ単位の単価が出揃った • 従来 Lambda : 0.0000166667 USD/GB-秒 • LMI : 0.0000043444 USD/GB-秒 両者を⽐較すると、LMI は約4倍優位！という計算結果となった • もちろん、これは起動されているインスタンスのリソースをフルで利⽤し た場合の理想値である • それでも例えば利⽤率50%なら2倍優位
37. Lambda Managed Instances (LMI) 37 その他の LMI の優位性 • 複数リクエストで実⾏環境が共有される（マルチコンカレンシー機能）た め、リソースの利⽤効率は従来 Lambda に⽐べて⾼い ◦ 弊社‧岩⽥さんの振り返りに詳しい https://dev.classmethod.jp/articles/re-growth-osaka-2025-lambda-before-after/
38. Lambda Managed Instances (LMI) 38 その他の LMI の優位性 • 複数リクエストで実⾏環境が共有される（マルチコンカレンシー機能）た め、リソースの利⽤効率は従来 Lambda に⽐べて⾼い ◦ 弊社‧岩⽥さんの振り返りに詳しい • Savings Plan/Reserved Instance 適⽤可能（最⼤72%オフ） ◦ さらにコストを改善できる
39. Lambda Managed Instances (LMI) 39 その他の LMI の優位性 • 複数リクエストで実⾏環境が共有される（マルチコンカレンシー機能）た め、リソースの利⽤効率は従来 Lambda に⽐べて⾼い ◦ 弊社‧岩⽥さんの振り返りに詳しい • Savings Plan/Reserved Instance 適⽤可能（最⼤72%オフ） ◦ さらにコストを改善できる • コールドスタート発⽣なし ◦ 追加コスト無しでこれが実現できるのは⾮常に嬉しい！！
40. 定常的な IoT リクエストの処理に 従来 Lambda を利⽤している場合は、 LMI への移⾏を検討する価値は⼤いにあり！ Lambda Managed Instances (LMI) 40
41. Lambda Managed Instances (LMI) 41 （おまけ）Fargate とのサービス料⾦⽐較 • メモリ ◦ 0.004445 GB-時間 = 0.00000123472 GB-秒 • vCPU ◦ 0.01557604 vCPU-時間 = 0.00000432667 vCPU-秒 • 2GB-0.25vCPU の場合 ◦ ⽐率は8:1 ◦ 0.00000123472 + 0.00000432667/8 = 0.00000177555 GB-秒 ◦ メモリ最適(vCPU に対するメモリの⼤きさ)な処理ほど優位 • Savings plans 適⽤可能（最⼤51%オフ） • 最低課⾦時間は1分 ◦ 数秒程度の処理では Fargate 不利
42. Lambda Managed Instances (LMI) 42 （おまけ）Fargate とのサービス料⾦⽐較 • メモリ ◦ 0.004445 GB-時間 = 0.00000123472 GB-秒 • vCPU ◦ 0.01557604 vCPU-時間 = 0.00000432667 vCPU-秒 • 2GB-0.25vCPU の場合 ◦ ⽐率は8:1 ◦ 0.00000123472 + 0.00000432667/8 = 0.00000177555 GB-秒 ◦ メモリ最適(vCPU に対するメモリの⼤きさ)な処理ほど優位 • Savings plans 適⽤可能（最⼤51%オフ） • 最低課⾦時間は1分 ◦ 数秒程度の処理では Fargate 不利 • 20秒未満程度の処理の実⾏基盤なら、LMI にコスト優位がありそう！
43. Lambda Managed Instances (LMI) 43 （おまけ）Fargate とのサービス料⾦⽐較 • メモリ ◦ 0.004445 GB-時間 = 0.00000123472 GB-秒 • vCPU ◦ 0.01557604 vCPU-時間 = 0.00000432667 vCPU-秒 • 2GB-0.25vCPU の場合 ◦ ⽐率は8:1 ◦ 0.00000123472 + 0.00000432667/8 = 0.00000177555 GB-秒 ◦ メモリ最適(vCPU に対するメモリの⼤きさ)な処理ほど優位 • Savings plans 適⽤可能（最⼤51%オフ） • 最低課⾦時間は1分 ◦ 数秒程度の処理では Fargate 不利 • 20秒未満程度の処理の実⾏基盤なら、LMI にコスト優位がありそう！ 従来 Lambda や Fargate だと 帯に短し襷に⻑し... そのギャップを埋めることができるサービス、 それが LMI だ！！
44. ロボタクシー「Zoox」に乗ってきた 44
45. ロボタクシー「Zoox」に乗ってきた 45 Zoox とは、Amazon が2020年に 買収し⼦会社化した Zoox, Inc が 開発‧提供する MaaS および⾃動 運転⾞ 「It’s not a car」というキャッチ コピーが挑戦的 https://zoox.com/
46. ロボタクシー「Zoox」に乗ってきた 46 ちょうど re:Invent 期間中にラス ベガスで Zoox の試験運⾏をしてお り体験してきたので、レポートし ます https://zoox.com/las-vegas/
47. ロボタクシー「Zoox」に乗ってきた 47 写真などは予め書いておいたレ ポートブログから掻い摘んでます https://dev.classmethod.jp/articles/zoox-aws-reinvent-2025/
48. ロボタクシー「Zoox」に乗ってきた 48 試験運⾏中の乗降場所は決まった 場所のみ The Venetian からだと CONRAD が近かったので歩いて向かった
49. ロボタクシー「Zoox」に乗ってきた 49 CONRAD に到着したらスマホアプ リで配⾞依頼を⾏う アプリ上の地図から⽬的地を指定 します。今回は ニューヨーク‧ ニューヨークを⽬的地に指定した
50. ロボタクシー「Zoox」に乗ってきた 50 ⽬的地を指定したら、決済が求め られるが、試験運⾏中なので無 料！
51. ロボタクシー「Zoox」に乗ってきた 51 配⾞確定まで待つ。この辺は Uber っぽい UX となっている
52. ロボタクシー「Zoox」に乗ってきた 52 配⾞が確定。7分後に到着予定との こと
53. ロボタクシー「Zoox」に乗ってきた 53 乗降場所には Zoox のカウンターが あり、スタッフが常駐している が、特にやり取りなどすることな く乗⾞まで進めた
54. ロボタクシー「Zoox」に乗ってきた 54 乗り場に Zoox のロボタクシーが到 着。アプリで予約した番号の⾞両 に乗る
55. ロボタクシー「Zoox」に乗ってきた 55 驚いたのは、横から⾒て左右対称 になっており、前後⽅向が無いこ と。 なぜならそもそも⼈間による運転 を前提とする必要がないから。
56. ロボタクシー「Zoox」に乗ってきた 56 乗⾞から降⾞まで（動画）
57. ロボタクシー「Zoox」に乗ってきた 57 （所感） モビリティの徹底したサービス 化、を感じた。⾃動⾞に乗った、 というよりは、⾞体がくっついた スマホをアプリから利⽤しまし た、という感覚
58. ロボタクシー「Zoox」に乗ってきた 58 （所感） ⾃動⾞を徹底的にモビリティサー ビスに仕⽴て上げたらこうなる、 という未来の形を体現していた。 従来の⾃動⾞が持っていた「所 有」や「運転」という概念を完全 に排除し、純粋に「移動体験」だ けを提供するプロダクトデザイン になっていた
59. ロボタクシー「Zoox」に乗ってきた 59 （所感） これは単なる技術的な進化ではな く、モビリティに対する根本的な 価値観の転換を迫られた感覚に なった。Zoox は⾃動⾞産業の延⻑ 線上にあるのではなく、まったく 新しいサービス産業として⽣まれ 変わたモビリティの姿と⾔える。
60. ロボタクシー「Zoox」に乗ってきた 60 （所感） これは単なる技術的な進化ではな く、モビリティに対する根本的な 価値観の転換を迫られた感覚に なった。Zoox は⾃動⾞産業の延⻑ 線上にあるのではなく、まったく 新しいサービス産業として⽣まれ 変わったモビリティの姿と⾔え る。 こんなモビリティを⽇常的に 利⽤可能となる未来が待ち遠しい！
61. 終わりに 61
62. 終わりに 62 Treasure Island Hotel 外観を撮影 Renaissance で発展したイタリア 諸都市は、その後に⼒を失っていく
63. 終わりに 63 Treasure Island Hotel 外観を撮影 Renaissance で発展したイタリア 諸都市は、その後に⼒を失っていく • ⼤航海時代が始まり、交易の中 ⼼が地中海から⼤⻄洋やインド 洋へ移ったから
64. 終わりに 64 Treasure Island Hotel 外観を撮影 Renaissance で発展したイタリア 諸都市は、その後に⼒を失っていく • ⼤航海時代が始まり、交易の中 ⼼が地中海から⼤⻄洋やインド 洋へ移ったから • 宗教改⾰でカトリックの後ろ盾 が弱まり、ヨーロッパ美術の中 ⼼がフランスに移ったから
65. 終わりに 65 Werner はキーノートでこう⾔っていた。 Will AI make me obsolete? NO (if you evolve.) https://www.youtube.com/watch?v=3Y1G9najGiI
66. 終わりに 66 Werner もキーノートでこう⾔っていた。 Will AI make me obsolete? NO (if you evolve.) https://www.youtube.com/watch?v=3Y1G9najGiI 我々 Developer も 時代に取り残されないように 進化し続けていきましょう！