プロポーザル

AIエージェントを設計する中で、「記憶をどう持たせるか」は必ず直面する悩みです。
実際に Amazon Bedrock AgentCore を使って検証を進めると、短期的な会話履歴と長期的に保持すべき情報の切り分けや、保存先の選択によって挙動や運用性が大きく変わることが分かりました。
本セッションでは AgentCore の Memory 機能を題材に、短期・長期メモリをどのように分離し、どこに配置すべきかを設計視点で整理します。S3、マネージドメモリ、外部データストアといった選択肢を比較し、それぞれのメリット・デメリットや、実際に試して分かった失敗しやすいポイントを紹介します。
機能紹介に留まらず、「何を覚えさせ、何を忘れさせるか」を判断するための考え方を持ち帰ってもらうことを目的としたセッションです。

私はJAWS-UGの勉強会に初めて参加・登壇したのが2年前であり、そこから2年間様々な勉強会・カンファレンスに参加してきました。

その過程で様々な人と出会い、AWS Community Builders等の素晴らしい表彰をいただきました。

AWS DevDay, AWS CDK Conferenceなどの比較的大きなカンファレンスで登壇することもありました。

2年間マイペースにJAWS-UGと関わり続けた中で感じたコミュニティの良さと、コミュニティとの距離感について自分なりの考えをお話しします。

AWS Digital Innovation Program（DIP）に参加した、地方にこだわる某金融機関の情報システム部員が登壇。
「Working backwards（顧客中心に考える）」（WB）との出会いで、仕事の向き合い方や考え方（人生）がどう変わったのか。
お客さま視点をとことん突き詰めた結果、どうして、個人として地方の農業系中小企業向けにAWSでシステムを作ることになったのか。
なぜ、AWSの力が必要だったのか。
個人としての限界を感じ、その後にとった行動はなにか。
地方の農業系中小企業、金融情シス、AWSといった全く異なる背景を持った企業、サービス、人がどのよう混ざり合い、どのような結果を起こしたのか。
その先の目指す姿は何か。
今回のテーマである「Mashup for the Future」でなければ話す意味がないリアルな話をお届けします。

AWSには様々な目的別のデータベースサービスが存在しますが、企業の基幹業務やWebアプリケーションの中核を担うのは、依然としてRDBMSが中心になります。
本講演では、利用頻度の高いRDSとAmazon Auroraに焦点を当て、PostgreSQL/MySQL等のOSSエンジンから、Oracle/SQL Server等の商用エンジンまで、その特性と使い分けを網羅的に解説します。

「Aurora独自のアーキテクチャが活きる場面とは？」「クラウド移行におけるDBaaSの役割は？」など、コスト・性能・可用性の観点から各選択肢を徹底比較。
NoSQLとの適切な役割分担にも触れつつ、現代のシステム要件に即した「失敗しないRDBMSアーキテクチャ」を設計するための決定版ガイドを提供します。

生成AIを用いての開発は世の中で一般的になりました。
kiroとAWS Documentation MCP Serverを組み合わせての開発スピードは、それがなかったときと比較し、何倍にも早くなりました。
それでも「唐突のpythonスクリプトがきた」「公式ドキュメントをみないとほぼ間違ってる答えを言ってくる」などと、kiroと会話をするときも行間を読まなくてはいけない、真偽を見極めるための知識はやはり必要など、わかった事がありました。
たった一言を添えるだけで、kiroの回答精度は格段に上がります。
間違った回答を出してきも、我々はcreditsを払わなくてはいけません。
うまく使えばIaaS,SaaS,windows,Linuxなんでもこいの強力な味方になってくれます。
kiroを用いて、20GBzipファイルの解凍基本設計、NW制約のあるEC2とパッチ運用実装をしたお話をします。

生成AIの進化とともに、音声AIを活用した音声インターフェースが再び注目を集めています。しかし、実際にプロダクトへ組み込む立場から見ると、「どれを使うべきなのか」という問いに明確な答えはありませんでした。本セッションでは、失語症支援アプリ『Speech Link』を開発する過程で、音声AIの利用者として主要サービスを検証した結果を共有します。Speech Linkは、AIと専門家による失語症当事者の言語回復支援を目的に開発されているサービスで、今回の検証の背景となっています。 OpenAI、Gemini、ElevenLabs、Deepgram、Livetoon、そしてAmazon PollyとAmazon Transcribe。 これらを同一条件で評価し、精度や自然さ、レイテンシの観点から「使える/使えない」を選定しました。盛り上がる音声AIの現在地と、今選ぶべきAIを20分で提示します。

AWSでのバックエンド処理において、AWS Step Functionsのステートマシンを使う機会も多くなりました。
しかしステートマシンを構成していると、下記のような保守性や変更容易性に影響する疑問が出てきます。

・ 複雑な共通処理は別のExpress同期ステートマシンとして切り出すべきか、その際「mostly once」の実行保障にどう対応するか
・ 同一処理は1アクションに集約すべきか、あるいはアクションを複数作成すべきか。また後者の場合、同じ変更を複数アクションに反映する煩雑さを解消できないか
・ JSONataが登場したことで、Lambdaは極力使わないようにすべきなのか。また使うとしたらどのようなケースで使うべきなのか

そこでこのセッションでは、ステートマシンの保守性や変更容易性を保つための構成やその手法について、私の実務経験を元にお話ししたいと思います。

生成AIの飛躍が激しい今、ベクトルDBは多くのAIプロダクト(RAG, AI Agent)に利用されています。 そして、ベクトルDBの性能を向上させるにはベクトルインデックスを使用するのが有効です。

ベクトルインデックスには多くのインデックス構築手法とハイパーパラメータが存在します。 それゆえ、実務において「どのベクトルインデックスを採用し、どのパラメータをチューニングすれば良いか」が明らかになっていません。

このセッションでは、Amazon Auroraで構築されたベクトルDBに対して、インデックス構築上の課題を、パブリックデータでの実験からインサイトを得ることを目標とします。

以下のテックブログの内容を凝縮してお届けする予定です。
https://zenn.dev/exwzd/articles/20251015_a_guide_to_vector_indexing

Amazon ConnectとLLMを組み合わせた音声自動応答システムを構築する中でお客様から必ず挙がる課題が「レスポンス速度」でした。
沈黙が長いと会話が不自然になり、満足度も下がります。従来の「Transcribe→LLM→Polly」の直列処理を最適化してきましたが、平均応答時間は約4.65秒が限界でした。
re:Invent 2025にて日本語STS対応のAmazon Nova 2 Sonicが登場し、ストリーミング経由で組み込むことで平均2.65秒まで短縮し、会話体験が大きく向上しました。
本セッションでは、なぜ従来アーキテクチャでは限界があったのか、Sonicがどこでボトルネックを解消したのかを現時点の構成と今後想定されるConnectとのネイティブ連携を含めた3構成の比較を通じて解説します。
なお、本セッションでは、登壇時点で利用可能な最新の機能・構成を前提にお話しします。

エンタープライズ企業で働く私はJAWS Festa Sapporo 2019での5分登壇をきっかけにJAWS-UGに参加し、自社では得られない知識や価値観に触れた。しかし、異動でマネジメント中心となりAWSから離れ、JAWS参加にも後ろめたさを感じて足が遠く。慣れないマネジメントで仕事も上手くいかず、自信はどん底へ。転機は2023年、札幌開催のAWS Carnivalが自社内での開催となったことだ。社内に熱量ある人たちの交流が目の前で繰り広げられる。AWSに触れる時間が年に数秒の人がJAWSを楽しむ姿を見て、不要な思い込みに縛られていたと気づく。コミュニティは、話したい内容をフラットに受け止めてくれる場所であり、登壇内容の評価や交流が失った自信を取り戻すきっかけとなった。コミュニティでの外のモノサシが自分を見つめ直す力をくれた。私が体験した「これがコミュニティだ」を“温泉“を例に伝えたい。

生成AI時代「調べれば答えが出る」環境で、初心者に何を教えるべきか。
たどり着いたのは、考える工程を省略させない育成でした。

本セッションでは、AWS経験の浅いメンバーがCloudFormationを用いてアプリ基盤を自走設計・構築できるようになるまでの育成手法を紹介します。
「なぜこのリソースが必要なのか」「他に選択肢はないのか」といった問いに、自分の言葉で答えられることを目標にしてきました。

例えば「なぜEC2+MySQLではなくRDSなのか」「ALBとNLBをどう選ぶか」といった問いを繰り返し、経験者が無意識に行っている判断を言語化していきました。試行錯誤を前提に、設計に迷ったときに立ち返る軸を育てる過程をお話しします。
育成を担う立場の方には思考の型を、初心者には考える手がかりを持ち帰っていただけます。

このセッションでは、実案件で対応したノウハウや注意事項等をシェアしたいと考えています！

Serverless framework V4からの有償化に伴い、AWS SAM(Serverless Application Model)の「SAMインポート機能」を使用して、CloudFormation管理下のLambda関数()をAWS SAM管理下となるように移行対応を実施しました。
その後、AWS SAM + GitHub ActionsによるCI/CD化を実装することで、脱Serverless framework対応に成功しました。
()Serverless frameworkでAWSリソースをデプロイする際、内部でCloudFormation APIを実行しています。

Cognitoは手軽に認証基盤を構築できる一方で、各設定の意味や仕様を正しく理解していないと脆弱性つながりかねない「罠」が潜んでいます。
しかし、ぱっと見ただけでは想定通りに動いてるように見えるため、罠に気付けないことも。

本セッションでは、Cognitoユーザ―プールを使ったアプリを開発時に陥りがちな罠と、それによってどのような攻撃や被害を受ける可能性があるのかを解説します。
Cognitoを使うことになった際に「そういえば、この設定にはこんな罠があったな」と思い出してもらえれば幸いです。

罠の例：「従来のウェブアプリケーション」ならクライアントシークレットが必要なので、ユーザが勝手にAPIを操作することはない

なお、本セッションでは上記目的のため罠に関する説明を中心とし攻撃手法については概念的な手順紹介に留め、具体的な攻撃手法等は取り扱わない予定です。

Hono に代表されるような Web フレームワークの登場により、スキーマ駆動開発や Lambdalith が注目されています。
一方で、 既存システムでは同じような開発体験を得ることが難しい、と感じている人も多いのではないでしょうか？
本セッションではそのような課題に対して、 Lambda Powertools と Pydantic を組み合わせることでどこまで解消できるのかを、実プロダクトでの事例を交えて紹介します。
Lambda Powertools は従来の Logger や Metrics にとどまらない多様な機能を提供し、モダンな開発体験を実現します。
リクエスト・レスポンスの検証、エラーハンドリング、 Lambdalith の実現など、handler 層における品質や開発効率を向上させるために活用している具体的なアプローチを解説します。

プログラミング言語Rustは、FirecrackerやCedar、BottlerocketなどAWSの裏側を支える技術として活躍してきました。そして2025年11月、ついにAWS LambdaがRustを正式サポート（GA）し、Rustは「表側」のステージへと進みました。

本セッションでは、re:Invent 2025で発表されたRust標準ライブラリの安全性検証（INV518）とRust×MCPサーバー構築（DEV405）の内容にも触れつつ、AWSがRustを採用し続ける理由を解説します。さらに実践編として、Lambda×Rustのコールドスタートやメモリ効率を他の主要ランタイムと比較した結果をお見せし、Rustの実力を体感していただきます。

裏側を知れば、表側の景色が変わる。AWSへの解像度が一段上がるセッションです。

生成AIやAIエージェントの活用が進むにつれ、AWS上では人やCI/CDだけでなく、自律的に動作する主体が増えていくと考えられます。この変化により、「どの権限が、どのスコープで動けるのか」というシステム境界の設計が、これまで以上に重要になっています。

現在の我々のAWS環境では、複数のシステムや機能単位が同一基盤上で連携して動作しており、AWS Organizationsを利用しつつも本格的なマルチアカウント化は途上にあります。AIエージェント時代を見据え、現状の境界設計のままで良いのかという課題意識を持つようになりました。

本セッションでは、AWS OrganizationsやAWSアカウントを、権限とスコープの観点からどのようなシステム境界として捉え直しているかを共有します。これからOrganizations運用やアカウント設計を本格化させる方の補助線となることを目指します。

弊社のシステムはほぼ全てAmazon ECS上で稼働し、一部ではECS Service間通信が行われています。現在利用中のAWS App Meshが2026年9月にEOLを迎えるため、その移行対応が急務です。
本セッションでは、App MeshからECS Service Connectへの移行を検討・採用した経緯と、Service Connectを利用した通信の仕組みを技術的に解説します。特に、AWS Cloud Mapのみを利用したサービス間通信で500エラーが頻発していたプロダクトにService Connectを適用し解消した事例、そしてApp MeshからService Connectへの移行方法について詳しく紹介します。
本セッションを通して、参加者がService Connectを理解し、自社環境で活用できるようになることを目指します。

AgentCore Gateway は、既存の API や Lambda など外部リソースをエージェント互換のツールとして公開し、AI エージェントのツール連携を安全に実現するための統一アクセスポイントを提供するマネージドサービスです。
その性質上、「誰が」「どのツールを」「どんな条件で」実行できるかを、用途に応じて適切な粒度で制御することが重要になります。
AgentCore Gateway のアクセス制御には、入口の認証/認可を担う Inbound Auth に加えて、Gateway Interceptors、そして Cedar ベースの Policy といった複数の選択肢があります。
本セッションでは、Inbound Auth / Policy / Interceptors それぞれで実現できる制御粒度を整理し、どう使い分け・組み合わせると安全で運用しやすいかを解説します。

弊社が運営するサービスではキャッシュ基盤としてRedisを利用してきましたが、帯域ボトルネックやクライアント更新の制約、さらにBloom Filterなど未サポート機能が課題となっていました。
これを受け、将来の拡張性と安定運用を見据えValkeyへの移行PoCを進めています。
本セッションでは、移行を検討するに至った背景、RedisとValkeyの違い、採用メリット、そして移行を通じて得られた知見を紹介します。
3/7時点で移行は完了している予定です。

クラウドネイティブなアプリケーションの実現で、もっとも重要なのは設計と開発。インフラエンジニアだけが頑張っても、設計・開発者が意識を変えなければ、真のクラウドネイティブとは言えません。

真のクラウドネイティブを目指すには、関わる全員が「ECSやEKSなどのコンテナ」「Lambdaなどのサーバーレス」などの技術要素を理解することも重要ですが、「イミュータブルなインフラストラクチャ」というクラウドネイティブの根本的な考え方も抑えておく必要があります。

こうした技術要素の真の意味を理解することで、「レガシーコードの、どこがダメなのか」「設計・開発者は、何に注意しなければならないのか」。そしてもし、設計・開発者の理解が得られない場合、どこまでならインフラだけの力でクラウドネイティブらしさを実現できるのかについてもお話します。

あるべきクラウドネイティブに近づくための三ヵ条を理解できる20分！