Serverless Compute for the Agentic Era

TBD

Profile

Working on core compute capabilities that make it simple for customers to build massively scalable applications with AWS Lambda.

AIエージェントが再発見したサーバーレス

2026年6月、AWSはAIエージェントのための実行環境「Lambda MicroVMs」を発表しました。マイクロVM、スナップショット起動、ゼロスケール、新製品のはずなのに、部品はどれもサーバーレスが十年かけて磨いてきた道具です。同じ現象はMicrosoft、Google Cloud、Cloudflareでも起きています。断続的で予測のつかない負荷、人間のレビューを経ないコードの隔離、長い待ちとセッションの継続、エージェントが実行環境に求める特性は、サーバーレスが解いてきた課題とよく似ています。本セッションではこの現象を「サーバーレスの再発見」と捉え、各社のエージェント実行基盤を収斂進化として読み解きます。そのうえで、原理も実装もそのままに文脈だけが変わった〔再発見〕と、原理は似ていても実行モデルを作り替えた〔再発明〕として整理します。コールドスタート対策のスナップショットがセッションのsuspend/resumeへ姿を変えた例から、MCP最新仕様のステートレス化まで、新発表をどちらのラベルで読むかによって、既存の運用知識がどこまで通用し、どこから仕様を読み直すべきか決まります。全てのエージェント向け技術を追いかけなくても使い回せる「エージェント時代のサーバーレス知識地図」を持ち帰ってください。

Profile

秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア。

0と1が紡ぐ「ゆるやかなつながり」に魅せられ早20年、SNSとCGMの力で世界を幸福にするのがライフワーク。

市民、幸福は義務です。

あなたは幸福ですか？

バイブコーディングで作ったアプリをどう安全に動かすか

AIエージェントに指示するだけでアプリが作れる時代になったが、「正しく動くこと」と「安全であること」は別物で、未認証の第三者にデータが見えるような欠陥は画面からは分かりません。作った本人も中身を完全には説明できず、人のレビューだけで守り切るのは現実的ではありません。

そこで、認証・認可、シークレット管理、egress制御、監査証跡といった守りをアプリ外部のマネージドサービスに寄せて強制します。あわせて手元からの直接デプロイを塞ぎ、信頼したCI経由のみに限定して記録と脆弱性チェックを担保します。サーバーレスではこれらをIaCテンプレート化し、誰がデプロイしても崩れない形で配れるかが鍵になります。本セッションではAWSでの構成例と、この方式の限界もあわせて話します。

Profile

2008年にGMOペパボ株式会社に入社し、EC事業およびホスティング事業においてシニアエンジニアとして開発業務に従事。2014年よりKaizen Platform株式会社に参画し、Tech Lead、SRE Group Manager、Engineering Group Managerを歴任しながら、SREとして長年サービス全般開発と運用体制の構築を推進。2023年に株式会社クラウドネイティブに加わり、エンジニアとして認証基盤、アプリケーション開発、生成AI領域のプロジェクトに携わる。プライベートではVimエディタ向けプラグイン「memolist.vim」の作者としても活動。

AIアプリのDBはTiDBだけでいい！3種のDBをTiDB1本に

セッション概要は近日公開予定です。

Everything will be SERVERLESS — 信じて運用した10年の経験値

長年運用されてきた基幹システムを、AWSのサーバーレスサービスで再構築しています。レガシー基幹からデータを受け取り、ドメインごとにAWSアカウントを分け、共通のテンプレートから同型のサービスを複数展開する構成です。人が入れ替わっても10年作り続けられることを前提に設計しています。

今回は、実際のコードをもとに、取り込み処理・SQSの再試行・冪等性・DLQ・内部アーキテクチャの判断を説明します。いずれも「サーバーレスの制約にどう向き合うか」という判断の積み重ねです。

S3取り込みLambdaの同時実行数はあえて1です。並行実行による、古いデータの後勝ちCOMMITを防ぐためです。

SQSのvisibilityTimeoutはLambdaタイムアウトの3倍、maxReceiveCountは3です。再試行を増やすと、失敗メッセージの滞留が正常処理を遅らせます。キューは1本に保ち、復旧手順とアラームを増やしません。

冪等キーと条件付き書き込み(attribute_not_exists)で、最初の書き込みだけを成功させます。TTLの削除は遅れるため、期限切れは読み取り側でも確認します。

1,500万件超の初回移行は、15分制限では終わらないため、Lambdaの外に出しました。

それでも、失敗は起きます。復旧は自動化せず、人が順序を確認しながら戻します。どこまで仕組みに任せ、どこから人が動くか。この線引きは、10年間の本番運用で身につけた知見です。

こうした制約への正しい対応をADRに残し、次の設計判断に使います。過去の10年のサーバーレス経験が、未来の10年のサーバーレス経験を作ります。基幹システムにサーバーレスを選んだ理由も説明します。

Profile

Serverlessconf Tokyo 2018に参加して衝撃を受けて、Serverlessの世界にハマる

翌年ServerlessDays Tokyo 2019のスタッフをしながら、 ServerlessDays Fukuoka 2019 のco-chairを務めるなどどっぷりServerlessにはまり込んでいく

その後もAWS Dev Day JapanやJAWS DAYSでもServerlessにフォーカスした登壇をおこなう

"AIエージェントが働きやすい会社"をCloudRunでつくったすべて

セッション概要は近日公開予定です。

Profile

ChatGPTの利活用を中心に大規模言語モデルを活用したアプリケーション開発ならびにアドバイザリーを提供する中で、吉田、大嶋と出会い、株式会社ジェネラティブエージェンツを共同創業。AIエージェントを経営に導入することにより、あらゆる業種業態の生産性を高めるための活動に尽力している。

「その仕事、AIエージェントがやっておきました。――ChatGPTの次に来る自律型AI革命」（技術評論社）単著、Software Design「実践LLMアプリケーション開発」（技術評論社）連載。

コーディングエージェントに全部書かせない！ ― AIに任せる実装と、決定論的に作るサーバーレス基盤の境界設計

Agentic Codingを取り入れた開発では、AIに判断・実装を委ねたい領域と、同じ入力から同じ構成を再現したい領域が、一つのプロジェクト内に共存します。

画面や業務ロジックにはAIの柔軟性を活かしたい一方、API契約、認証、データアクセス、IaC、CI/CDなど、サーバーレスアプリケーションの土台には一定の構成と再現性を持たせたい。この境界をどのように設計すべきでしょうか。

本セッションでは、個別要件の判断や実装はCoding Agentに委ね、既知の構成はスキーマ、Scaffolding、IaCで決定論的に構築し、型検査やテスト、構造検証で機械的に確認する設計を考えます。さらに、Agentがプロジェクトの状態を観測し、定義済みの操作で変更を加え、検証結果をもとに修正を繰り返す開発ループを、どのように組み立てるかも扱います。これはAIに無制限な自律性を与えるのではなく、基盤が示す境界と検証可能な手順の中で、反復的に開発を進めるための仕組みです。

Profile

クラウドネイティブ／サーバーレス技術を活用したシステムの設計・開発や技術支援に加え、エンジニア向け研修やハンズオン、育成施策の企画・実施を担当しています。

近年は生成 AI や Coding Agent を活用した開発体験・開発基盤の改善にも注力しており、Next.js アプリのための Azure サーバーレス基盤の生成と開発効率向上を目指す OSS「SwallowKit」を開発・公開しています。

趣味はイタリア料理とイタリア語の勉強です。

「とりあえず動く」の先へ。AI時代のチーム開発と内部設計

AI コーディングエージェントの普及により浸透した変化を捉え、チーム開発にフォーカスした現場の課題と解決方法について紹介します。また、システム全般の品質や合理性を保ちつつ、時代にあった形での開発業務とは何かについて解説します。

Profile

思いをすぐに形にできるサーバーレスが大好きです。フロントエンド／バックエンド問わず、面白いサービスを作るのが生きがいです。AWS Community Builders (Serverless) として活動しています。

サーバーレスをどこまで使う？ WebRTC対戦ゲームで選んだVPSとの共存設計

WebRTCではTURNサーバーなど長時間接続を必要とするコンポーネントがあり、すべてをサーバーレス化することは現実的ではありません。本セッションでは、どこまでサーバーレスを採用し、どこをVPSへ切り出したのか、その設計判断を実例とともに紹介します。特に、サーバーレス側を認証基盤とし、coturn標準のHMAC認証を利用してVPS側と疎結合に連携した設計について詳しく解説します。

Profile

インディーゲーム制作サークルPegass85代表。IT企業でバックエンドエンジニアとして働く傍ら、ブラウザゲームを開発している。「AWS Alien Attack: A Serverless Adventure」をきっかけにサーバーレスの魅力に惹かれ、自作ゲームにサーバーレスを活用したネット対戦機能を実装した。現在はユーザー登録なしで対戦できるモードを、サーバーレスとVPSを組み合わせたWebRTC構成で開発中である。

Azure Serverless 2026：Production-ready な AI エージェント基盤 — Functions／Container Apps、Foundry、Microsoft IQ の使いどころ

Azure Serverless の実行単位は、Function や Container から Agent Session と Workflow Activity へ広がり、隔離されたコード実行、組織コンテキストの取得、長時間ワークフローの完遂までを担う実行基盤へ進化しています。本セッションでは、この基盤を Compute／Context／Agent Hosting／Workflow の4レイヤーで整理し、Functions／Container Apps、Microsoft Foundry、Microsoft IQ の「使いわけ」「役割分担」を解説します。イベントで起動したエージェントが Microsoft IQ から根拠付き情報を取得し、Sandbox で安全にコードを実行し、長時間処理を Durable ベースの Workflow へ委譲して完遂するといった Production-ready なリファレンスアーキテクチャも紹介します。本番運用を見据えた Azure Serverless の全体像を持ち帰れるセッションです。

Profile

ZEN Architects 代表。Microsoft Azure を中心としたエンタープライズ向けクラウド・AI システムのアーキテクチャ設計と導入を手がける。主な専門領域は Azure Serverless Architecture、Microsoft Foundry。Microsoft Regional Director / Microsoft MVP（Microsoft Azure / Microsoft Foundry）。AI Dev Day発起人。

作って終わりじゃないサーバーレス 〜9年運用する大規模EC物流API基盤の設計・運用のリアル〜

私たちは、大規模ECの物流を支えるBtoB向けのAPI基盤を、AWS上のサーバーレス構成で開発・運用しています。開発開始から9年が経過し、本番環境のLambda関数は500本を超え、多数のスタックが注文・決済・在庫・配送を日々処理する規模に成長しました。

本セッションでは、この実運用中の大規模サーバーレスシステムを題材に、「作って終わりではなく、運用が続くサーバーレス」を支える設計と運用の経験を、良かった点だけでなく、つまずいた点や後悔も含めて以下2つのテーマでお話しします。

1. Serverless Frameworkで実現する設計・運用

9年にわたり使い続けるなかで向き合ってきた、リアルな知見を「うまくいったこと・いかなかったこと」の両面から共有します。

2. 大規模サーバーレスにおける可観測性

多数のLambda関数やマネージドサービスに処理が分散する環境において、Datadogを用いた可観測性の運用事例を紹介します。

Profile

2019年に株式会社アラタナへ新卒入社。2020年4月の株式会社ZOZOテクノロジーズへの吸収合併を経て、2021年10月より現職。現在はFulfillment by ZOZOが提供するAPIシステムの開発・運用を担当。昨年からは、社内の開発者向けAI支援ツール（Claude Code、Codex、Devinなど）の活用推進を担う専門チームにも兼務で参加。辛麺を愛してやまない。

AIエージェントの一手は誰も見ていない: Falco拡張OSS「Prempti」とeBPFでサーバーレス実行基盤を二層防御する

AIコーディングエージェントは、シェル実行やファイル操作、MCP呼び出しなど「破壊的なことも含めて何でもできる」状態のまま業務に入ってきています。現状のガードレールはシステムプロンプトやIDE設定など「お願いベース」で、実行時に何が起きるかを構造的に保証できていません。これがこのセッションの出発点にある課題です。

この課題を解く鍵として、クラウドネイティブの世界で実行時の脅威検知を担ってきたOSS「Falco」を紹介します。syscallをリアルタイムに監視し、YAMLルールに従って異常を検知するランタイムセキュリティエンジンで、CNCFプロジェクトとしてKubernetes環境の標準的な脅威検知手段になってきました。

セッション内では、AIエージェントに危険な操作を指示し、tool-call層でブロックされる様子と、tool-call層をすり抜けた操作がsyscall層で捕捉される様子の両方をライブデモでお見せします。

Profile

Sysdig Japan にて Senior Customer Solutions Engineer として、金融・エンタープライズ領域のクラウドネイティブセキュリティを技術支援。Falco / eBPF を用いたランタイム検知の設計・運用を専門とし、近年は MCP ベースのシステムに対する Prompt Injection とその実行時検知をテーマに研究・登壇を行っている。Falco 解説書の執筆や OSS 開発を通じた発信も継続中。

音声コミュニティを守るAI監視基盤: 90%以上の入力削減を支えたServerless設計と運用判断

「ピグパーティ」のボイスチャット健全化プロジェクトを題材に、利用者が増え続ける音声コミュニティを、AIと人の運用でどう守るか、そのためのサーバーレス/イベント駆動アーキテクチャの設計判断を共有します。公開事例では、音声データに含まれる無音区間の検出・削除、再生速度調整、AIへの入力対象の絞り込みにより、入力データを90%以上削減し、APIコストを抑えながら90%以上の監視カバレッジと月170件の検知実績につなげたことが紹介されています。

本セッションでは、その裏側にある「全部処理する」から「必要なデータだけを段階的に処理する」への設計転換を、サーバーレスらしいワークフロー分割、マイクロバッチ、キュー/イベント駆動、コスト制御、失敗時のリトライ、可観測性、人間による最終判断を前提にしたHuman-in-the-loop運用として整理します。AIモデルやプロンプトの一般論ではなく、音声ファイル、ユーザー単位の発話、違反候補、監視チームへのエスカレーションという実際の業務フローを、どこで非同期化し、どこで同期的に判断し、どの粒度でログとメトリクスを残すべきかを具体的に話します。サーバーレスを採用する/しない境界、AI処理のコストがプロダクトの安全性投資に与える影響、そして最終判断を人間に残しながら監視カバレッジを拡大するための運用設計を持ち帰れる内容にします。

参考: CyberAgent Way「成長し続けるコミュニティを、AIと共に守る。『ピグパーティ』のボイスチャット健全化プロジェクト」

https://www.cyberagent.co.jp/way/list/detail/id=33443

Profile

2024年にAIエンジニアとして中途入社。現在はAIオペレーション室でCTOを務め、様々な事業部へのAI導入を専門とするチームをリードしている。X: oka000111

AgentCore Runtime上にAgentic Coding基盤を構築・展開する際の設計ポイントと限界点

セッション概要は近日公開予定です。

Profile

AWSを中心としたクラウド基盤や、AIエージェントの設計・構築を行っています。最近は社内FDEをやる機会があったり、アプリ側も作ったりしています。最近の趣味はクラフトビール。

AWS Community Builder - AI Engineering (2025-2026)

Japan AWS Jr.Champion (2025)

EventBridge に「合流」はない ― サーバーレスのワークフローを育てるということ

日次ETLを、1本の Step Functions から2本に分割することになりました。

本セッションでは「合流をどこに作るか」を、実行内でのポーリング / 起動条件の入れ替え / タスクトークン / 外部状態ストア / Parallel という選択肢で、それぞれがどう壊れるかとあわせて比較します。あわせて、後続の起動を先行ワークフローの末尾に書いた場合に、処理が全て成功していてもワークフロー全体が失敗扱いになるという、状態表現の壊れ方を扱います。合流をどこに置くかは、待ち時間がステートマシンのタイムアウトを食うか、状態管理の置き場所が増えるか、といった副作用まで含めて決まります。その連動も整理します。

Profile

クラウドアーキテクトとして、AWSを用いたWebサービスの設計・開発・運用に加え、新技術適用に向けたPoCにも取り組む。社内ではCCoEとして人材育成・技術広報・AI活用推進を担う。AWS Ambassador / AWS Community Builder。昨年のServerlessDays Tokyo 2025に続き2回目の登壇。前回「アーキテクチャは育てるもの」と話した本人が、育てた先で詰まった話をしに来ました。好物はつけ麺。

エージェントはローカル、検証はMicroVM — Lambda MicroVMsでつくるServerless CI

セッション概要は近日公開予定です。

Profile

AWSインフラ設計とアプリケーション開発に精通しているマルチスタックエンジニア。現在はフォージビジョン株式会社にてDevOpsエンジニアとして、アプリケーション開発を効率化するためのAWSサービス設計やプログラムの実装、さらにシステム運用まで対応している。2025～2026年のJapan All AWS Certifications Engineer、2026年のJapan AWS Top Engineer（Services）に選出。

「これ、外に売れない？」から始まる、1人運用・フルサーバーレスでのSaaS化戦記

ある日「これ、外に売れない？」と言われました。さも簡単そうに。放送局でエンジニア1人が運用する社内向けAI原稿支援ツールを、増員なしで外販SaaS化している話です。その間にあった「6つの壁」を、フルサーバーレス＋1顧客1AWSアカウントでどう越えているか話します。

社内アプリとSaaSの距離は「機能」でなく「テナントと運用の設計」だと感じています。サーバーレスなら、その距離は1人でもなんとかなる。同じ無茶振りを受けた人の地図になれば嬉しいです。

Profile

北海道文化放送のDX推進やってます。

社内システムをひとりで作って運用しています。

元々は放送技術で、深夜番組のロケ隊（1人）とかやっていました。

色々ありまして、QuickSightからAWSを触り始めて今に至ります。QuickSightが好きです。

今は社内のAI原稿支援ツールを、ひとりのまま外販SaaSにしようとしています。

その Lambda、8分で管理者権限まで奪われます — 実際の攻撃を再現して見えたサーバーレスの分かれ道

「インシデント対応の訓練、ドキュメントレビューで済ませていませんか」

サーバーレスは平常時、マネージドサービスに支えられて安定して動きます。だからこそ私たちは、自分のワークロードの「壊れ方」を練習する機会をほとんど持てません。CI/CDにスキャンは入れたが検出結果は放置されている、最小権限は掛け声で終わっている、攻撃を受けたとき何分で気づいて何を切れるのか分からない。

題材は、2026年2月にSysdigが公開した実在の脅威レポートです。公開S3バケットからの認証情報窃取、Lambdaへのコード注入による権限昇格（わずか8分）、19プリンシパルへの横展開、Bedrockの無許可利用。この観測済みキルチェーンを5段階に再構成し、自社GameDayとして再現しました。

そして本題です。同じ攻撃を受けても、キルチェーンがStep 3で止まるチームと、管理者権限まで抜かれるチームがありました。分けたのはIAMポリシーではありません。構成上のある一つの判断でした。それが何か、なぜ効くのかを当日お話しします。ご自身の環境で明日確認できるチェックポイントとして持ち帰ってください。

Profile

株式会社キャラウェブにて、クラウドインテグレーション事業「Cloud Partner」の事業責任者を務めています。AWS Community Builder (Serverless)、Japan AWS Top Engineers 2026。AWSサーバーレスの推進と、GitLabを活用したAI DevSecOpsに取り組んでいます。

JSONataとAWS Step Functionsで目指すRuntime Lessな世界

AWS上の処理を実装する際、AWSサービス間を接続するglue codeや、入力値の検証、データ変換、条件判定といった小さなロジックを、AWS Lambdaで実装しているケースは少なくありません。

本セッションでは、AWS SDKの呼び出し、入力値の検証、データ加工、条件分岐、エラー処理を行っていたLambdaを題材に、Step FunctionsとJSONataへ置き換えていく過程を紹介します。どのような処理であればLambdaを削除できるのか、移行によってどの保守作業が不要になるのかを、移行前後の構成と実装を比較しながら整理します。

Lambdaを無条件に排除するのではなく、処理の複雑さ、外部依存などを踏まえ、不要なランタイムを減らすための現実的な設計判断を提示します。

Profile

AWSを中心にクラウド基盤の設計・構築に取り組むエンジニア。開発者体験やIaC、サーバーレスなどに関心があり、業務のほかOSSへのコントリビューションや技術発信にも取り組んでいます。

最近は、より運用責任の少ないクラウドアーキテクチャを模索しています。