小川 雄喜 ちょうど2年前のJAWS DAYS 2024、同じ会社から参加したAWS好きのメンバーと参加した懇親会で盛り上がり、翌週には社内コミュニティ "MAWS-UG"での対面イベントを正式に企画しました。
* * * * *
三菱電機の社内コミュニティ"MAWS-UG"は、JAWS-UGに感化され、サイロ化された縦割りの会社を変えたいと思った熱いメンバーで作られたコミュニティです。
職場の数人が参加する勉強会が、全社で1000人規模のコミュニティに発展し、企業広告やTV出演するまでの物語を伝えます。
このセッションでは技術的な話はなく、今日JAWS DAYSが楽しいなと思った皆様が、職場にどうやってこの熱量を持ち帰り、その炎を大きくするかについてお話しします。
もしこのセッションを通じて、コミュニティの素晴らしさ、そして職場で頑張る皆様に勇気を与えられれば、ありがたいと思います。
荒木泰詞 フロントエンド開発において、デザイナーやプロダクトオーナーなど多様なステークホルダーが画面レイアウトや動作を確認する機会は重要です。
本セッションでは、App RunnerとGitHub Actionsを組み合わせて、プルリクエスト単位でプライベートなレビュー環境を自動構築する実践的な手法をご紹介します。
社内ネットワークからのみアクセス可能な環境を手軽に立ち上げることで、開発者だけでなく非エンジニアのメンバーも安全に動作確認でき、フィードバックサイクルが大幅に短縮されます。
また、ECS Express Modeと比較しながら、App Runnerならではの利点(主にコスト効率など)を掘り下げます。
re:Inventで新機能が発表されなかったApp Runnerですが、まだまだ現役で活躍できることを実例とともにお伝えします。
岩本隆史 A2Aの登場により、専門性の高いAIエージェントを個別に開発・デプロイし、協働させられる時代になりました。いわば「AIエージェント・マイクロサービス」時代の到来です。
本セッションでは、AWSでAIエージェント・マイクロサービスを手軽に実現する方法として、以下を用いた実装例をお伝えします。
解説に使うPythonのサンプルコードは、署名処理やエージェント呼び出し処理をモジュール化しており、すぐに再利用できます。新時代のAIエージェント実装例、ぜひお持ち帰りください。
オンプレの機器からインターネット接続するためのAWSプロキシサーバにて、
NW帯域を拡張する目的で、DirectConncetと接続していたVitual private gatewayをAWS Transit Gatewayへ切り替える作業を実施しました。
その際に発生したAWS内の非対称ルーティングによる通信断とその時の移行設計のノウハウを解説しようと思います。
移行作業時のAWS構成図の状態遷移を作成し、各フェーズで発生する業務影響を整理した移行設計の作成方法を解説します。
詳細は下記のブログで解説したものをブラッシュアップした内容を説明する予定です。
https://qiita.com/tkazuaki0820/items/281ad9b097754cf3d557
大谷 優多 組織で AI 活用が進む中、「どの MCP ツールが実際に使われているか」といった利用実態に関する情報は、AI 活用の方針を決定するための材料となります。Amazon Bedrock のモデル呼び出しログにそれらの情報が記録されており、本格的な分析基盤を構築せずとも、DuckDB なら環境構築不要で手元ですぐ分析できます。
【話す内容】
【持ち帰れるもの】
検知は自動化できても、判断と是正は人手頼み。この限界を突破するため、Amazon BedrockとMCPを活用し、AWSツールをAIに操作させる自律型運用基盤のアーキテクチャを共有します。
単なるボットではなく、以下の能動的エージェントを目指した実装アプローチです。
藤原吉規 CloudFront flat-rate Free プランは個人サイト運営者にとって新たな選択肢です。このセッションでは、月額無料で利用できる Free プランの実力を徹底解説します。
エッジロケーションを活用した高速配信や AWS WAF によるセキュリティ対策、 CloudFront Functions によるエッジでの動的処理、 Amazon Route 53 による DNS 管理、 AWS Certificate Manager による無料の TLS 証明書、 毎月 5GB の Amazon S3 ストレージおよびセキュリティダッシュボードが月100万リクエスト・100 GB まで無料で利用可能です。
トラフィックスパイクやセキュリティ攻撃が発生しても追加料金は発生しません。 Free プランで実現できる可能性を、実例を交えてご紹介します。
武田一成 東北IT物産展は、2014年に仙台で開催されたJAWSFestaをきっかけに誕生した、東北各地のITコミュニティが連携するクロスコミュニティ型イベントです。「技術×地域×コミュニティ」を軸に、エンジニア・企業・学生・自治体(行政)など、多様な参加者が交わる場として発展してきました。
どのような経緯で生まれ、どのように成長し、築き上げてきたのか、その軌跡と魅力を紹介します。
取り扱う主な内容:
・JAWSFesta2014から東北IT物産展が生まれた背景
・東北地域に点在するITコミュニティと自治体をつなぐ仕組み
・自治体との関係の近さをいかしたテーマとセッション
AWSコミュニティから生まれた東北IT物産展という取り組みを通して、地方における技術コミュニティづくりの可能性や、自治体を巻き込んだ地域協働のモデルケースを共有します。
古屋 啓介 みなさんはCapture The Flag(CTF)という競技をご存知でしょうか。情報セキュリティの分野において、技術や知識をもとに隠された「フラグ」と呼ばれる文字列を見つけるゲーム感覚のコンテストです。
私が所属する企業では毎年、ソフトウェアエンジニアの頂点を決める「ごーとんカップ」というCTFを開催しており、セキュリティだけではなくWeb一般の知識を使うものやAWSの知識を問うものが出題されています。毎回非常に高評価なこのコンテストをみなさんにも体験していただきたく、AWSに絞った出張版「ごーとんカップ」を開催します!
セキュリティの深い知識は不要です。普段の業務知識が武器になります。初心者の方から腕に覚えのある方まで楽しんでいただけるようインフラ、ストレージ、AI、もちろんセキュリティなど様々なレベルの問題をご用意する予定ですので、奮ってのご参加お待ちしています!
織田 繁 KIROを使った仕様駆動型開発(Spec-driven development)でレトロゲームを作成します。プログラミング言語開発が未経験の方でも、自分のアイディアでコンテンツを作成できる点が魅力です。サンプルの仕様を準備しますので、コピー&ペーストだけでもレトロゲームの作成が可能です。
座席配置は4-6名を1グループとする形式でお願いします。KIROがコード生成中は待ち時間が発生するため、その間にどんなゲームを作成するか参加者同士で語り合ったり、実際にお互いのゲームをプレイしていただけます。KIROを通して楽しく仕様駆動型開発を体験できるワークショップです。
本ワークショップは、AWS re:Invent 2025のセッション「Game On: Build a Retro Adventure Game in 120 Minutes」を90分枠に編集し、日本語対応したものです。
黒澤圭一 最近のAIエージェントは自律的に動作するようになってきたLLM、さまざまなデータソースやツール、MCP、RAG。これらを組み合わせた構成になり、複雑なタスクを自律的に任せれば任せるほど実行時間は長くなっていきます。
長くなった実行時間を待つことなく、他の作業をしつつ、終わった時にはリアルタイムに完了通知が来る。そんなアプリアーキテクチャを考えたいという希望は多くあるのではと思います。
そうした非同期通知アーキテクチャをフルサーバレス(API Gateway, Lambda, DynamoDB)を組み合わせて実現する構成についてデモを交えて解説したいと思います。なぜアプリをこうするのか、こんな時にはどうなるのかといったことについても併せてお話しすることで具体的なイメージを持って帰っていただきたいと思います。(セッション後にはデモ用のサンプルリポジトリも公開予定)
加我 貴志 みなさんre:Invent 2025で発表されたアップデートのキャッチアップは終わりましたか?私が気になっているのはAWS DevOps Agentです。
このサービスは自律的にテレメトリーデータやリポジトリを横断的に調査し、発生した問題の原因や解決方法について "自然言語で" やり取りすることが可能です。
さて、DevOpsに関するロールといえばSREです。
Googleのサイトリライアビリティワークブックでは「class SRE implements DevOps」と記述されており、DevOpsの具体的な実装を行うロール = SREと見なすことができると理解できます。
というわけでSREを担当していた私がAWS DevOps AgentをDevOpsの観点から評価していきます。
AWS DevOps Agentはあなたの助けになるものか、あなたの立場を脅かすものなのか。乞うご期待。
松尾 優成 「権限付与のリードタイムが、開発のアジリティを殺している」
エンタープライズのAWS活用において、最大の敵は技術ではなく「社内プロセス」でした。
そこで私たちは、AWS IAM Identity Centerのマルチアカウント環境において、Platform Engineeringのアプローチでこの課題に挑みました。
私たちの答えは、「IdPであるEntra IDをテナントに直接操作させる」という大胆な選択でした。
着目したのは「役割の定義」と「人のアサイン」の分離です。
AWS上の権限設計は中央で統制しつつ、頻繁なメンバー変更はEntra IDの機能を活用してセルフサービス化しました。
本セッションでは、「IdPを直接触らせる」判断に至った背景、セキュリティと開発者体験を両立させたアーキテクチャ、そして運用の変革についてお話します。
Tomoya Kitaura このハンズオンでは、リアルなデモ用ECサイトを題材に、
Service Levelを設計・管理・運用する体験を提供します。
AWSのサービスだけでなく、Service Levelを学びたい方を意識した構成にしています。
◆カリキュラム
Kiro CLIやKiro(IDE)など、コーディングエージェントはAWSにはあります。しかしながらAWSのパラダイムだけで観るとアップデートの凄さや、機能の位置付けが良くわからないことも。本セクションではAWS Ambasaddorに留まらず、Zenn.devやスライド「エンジニアに許された特別な時間の終わり」など、当該コミュニティでも活動する私が、「AWSでの」コーディングエージェントの現在地を総括し、どこでも使える最新の知識をお届けします。
「あれ、リソース作れない…」調べてみたらクォータ上限。このパターン、何回繰り返しましたか?私は何度も経験してきました。
かといってLambda + CloudWatch Alarmsで自前監視を組むのは構築も運用もしんどい。
結局サービスクォーターエラーが発生したタイミングでクォーターの引き上げ申請をした方、多いんじゃないでしょうか。
そんな状況を変えるかもしれない機能がService Quotasに追加されました。
コンソールから数クリックで設定完了、閾値超えで通知、さらに自動で上限緩和リクエストまで飛ばしてくれます。
このセッションでは実際に使ってわかった「これはいい」と「あとちょっと惜しいなぁ」を正直にお伝えします。
木村直紀 JAWS FESTA 2025 向けに、ブラウザからの音声をほぼリアルタイムで文字起こしするための機能を実装しました。本セッションでは、その技術選定と構成上の工夫を紹介します。
技術選定としては下記を選定しています。
・音声入力:MediaStream API+AudioWorklet など
・音声認識と翻訳:Amazon Transcribe SDKとTranslate SDK
音声入力に関しては安定性を考慮しました。その詳細な構成について説明させていただきます。
音声認識と翻訳はリアルタイム性と使いやすさを意識しました。UIにおける工夫も述べさせていただきます。
音声入力でWeb Speech API 、音声認識と翻訳でChime SDK や、API Gateway+Lambdaも候補に上がりましたが、それらを不採用とし、今回のリソースを採用した理由についても説明させていただきます。
山下 祐樹 Strands AgentsのBidiAgentsに
Amazon Nova 2 Sonic
Amazon Nova Sonic
OpenAI Realtime
Gemeni Live
といったモデルを組み合わせて、S2S(Speach to Speach)を実装してみたということについてお話しします。
これをAmazon Connectと組み合わせて、究極は「人がいらないコールセンター」を目指しております。
そこも含めてお話しできればと思っております。
奥田 雅基 12月に開催されたAWS re:InventでAWS DevOps Agent(以下、Agent)が発表されました。Agentを活用することで障害検知/予防保全を実現したすることができます。Agentを用いることで、既存システムをW-Aで定めている基準に近づけることができます.本セッションでは、Agentの紹介、W-Aを満たすための実装例、今後の展望について紹介します。
⚪︎対象者
1.AWSを用いたシステム運用につらさを感じている方
2.AgentがW-Aにどのように貢献するか知りたい方は
⚪︎ラーニングアウトカム
1.Agentを通じてシステム復旧速度を格段に向上できる
2.W-A視点では「オブザーバビリティ」に最も役立てることができる
3.AgentだけでなくCloudWatchなどの監視サービスとの組み合わせが重要
大瀧広宣 昨今話題のランサムウエア被害。本番環境を外部に公開している以上は他人ごとではありません。
AWSは責任共有モデルであり、ランサムウエア被害にあえば、その責任は企業側にあります。
入口対策、出口対策をしただけで満足していませんか?
AWS独特のリスクとはなにか?リスクに関する備えはなにをすべきか?いざやられたときの対応はどうすべきか?
実際はAWSのサービスだけでは防御もできなければ、実際に被害にあったときの対策もできません。
被害にどう向き合い、解決できるかは日頃のAWSインフラエンジニアの準備にかかっているといっても過言ではないです。
今回は、実際にランサムウエア被害にあった際、どう対応するかを時間軸で整理し、必要な対応策をお伝えできればと思います。