お久しぶりです。たつたつです。 先日、AWS Summit Japan
お久しぶりです。たつたつです。
先日、AWS Summit Japan 2026 へ行ってきました！
AWS Summitへは、AI関連の活用方法や最新動向キャッチアップすること、
そして現在担当しているプロジェクトで利用しているAWSサービスについて理解を深めることを目的に参加しました。
上記の目的に基づいてセッション（講演）も聞いてきました。
そのなかでも特に印象に残った講演とEXPOなどについて書こうと思います！
ただその前に、AWS Summit Japan 2026 について簡単に紹介します！
AWS Summit Japan 2026 は、Amazon Web Services（AWS）が主催する、その年のITトレンドについて学べる大規模イベントです。
2026年6月25日〜26日に幕張メッセで行われました。毎年開催されるイベントです。
今年は特にAI関連のセッションや展示が多く、AIがイベント全体の大きなテーマになっていました。
セッションは200以上あり、AWS公式ブースやパートナー企業ブース、デモ・体験コーナーなどのEXPOも多数あります。
なんと参加費は無料（事前登録制）です！
先着でお弁当引換券、入場特典（今年はクッション）を貰えます。
今回初めて参加して、次参加する際にこうしたらよかったああしたらよかったなど思ったことがあったのでブログに残そうと思います。
もし次回以降行く方はぜひ参考にしてみてください。
[参加ガイド編]
- まず事前登録は早めに！参加可否が未確定の場合でも早めに登録しておくことをおすすめします。
早くしたほうがいい理由は、セッション予約です！事前登録したあとにセッションの予約ができます！
私は2日前に事前登録して興味のあるセッションを予約しようとしたのですがほぼ埋まっていました。。。
セッションの予約はすぐにキャンセルできるので気軽に早くしたほうがいいと思います！
また、予約以外にも興味のあるものにお気に入り登録もできて、予約とお気に入りをスケジュール表として表示させてくれるのでとても便利です！
おそらく来年も公式サイトから登録できるかと思いますが、AWS Eventsというアプリもあるのでこれもぜひ事前に登録しておいた方がいいかと思います。 - 当日の会場入りの時間ですが、Day1は9時6分に海浜幕張駅に到着しましたが、行列ができていて最終的に会場入りしたのは10時30分でした。
Day2も同様に9時6分に海浜幕張駅に到着したのですがDay2は会場までのルートが規制されていてスムーズに会場入りできました！9時30分前には入場できたかと思います！
なんでDay1あんなに並んでいたのかわからないですが、来年行く方は時間参考までに！ちなみにDay2は早期入場特典のクッションはもらえました！
でもお弁当引換券と10時からの講演の指定席は取れませんでした。。。 - 1日中いるのであればモバイルバッテリーはあった方がいいと思います！充電できる場所はありましたが常に満員でした。。。
また、かなり疲れるので歩きやすい靴を履き、前日はしっかり睡眠を取ることをおすすめします。
セッションやブースを結構見るのであれば軽く食べれるご飯も会場入りする前に買っておくと良いかと思います！
海浜幕張駅にはNewDaysがあるのでそこで買うのも良いと思います。（多少は並ぶ覚悟で） - 資格取得者はCredlyというアプリをインストールしておいてください！このアプリに表示されるAWSのバッジを見せることでシールと交換できました！
シールはなくなることもあるっぽいので早めに並んでおいた方がいいと思います！私は待ち時間15分くらいでした！
長くなりましたがぜひ来年行く方は参考にしてみてください！
[本題]
私が聞いたセッションは以下になります。
Day1
・PRT201-S
自律型AIエージェントが再定義する企業活動 (sponsored by NTT DATA)
・MAM202
創業100年の酒屋カクヤスが挑む、生成AIで実現するシステム革命
・AIM222
AI駆動は上流工程にこそ活きる－非エンジニアにこそ知ってほしい、AI駆動開発ライフサイクルによる上流工程の変革
・CNS309
Amazon ECS 最新デプロイパターン DeepDive
・DVT225
AWS Infrastructure as Code:2025 年主要アップデートの振り返り
Day2
・STP201
【リアルタイム実装実況！】AWS Summitを案内する:AIエージェントの実装を15分で実装からデプロイまでRTA（解説つき）
・DVE352
AWS Infrastructure as Code:2025 年主要アップデートの振り返り
・DVT350
AIを活用した新しいデプロイメント手法とCI/CDにおける迅速な障害検知と復旧の実現方法
・PRT136-S
「使う」から「共に働く」へ－Claude 最新動向－（sponsored by Anthropic）
一部セッションを除いてセッションは2026年7月11日までにこちらを登録すれば皆さん見れるので興味のある方はぜひこちらから見てみてください。
https://summitjapan.awslivestream.com/
資料はこちらです。
https://pages.awscloud.com/AWS-Summit-Japan-2026-Session-Materials-Download.html
上記のなかで特に印象に残ったセッションをいくつかピックアップしたいと思います。
1. 創業100年の酒屋カクヤスが挑む、生成AIで実現するシステム革命（MAM202）
本セッションでは、1995年に誕生したレガシーシステムの刷新事例が紹介されました。
※レガシーシステム:導入から長期間が経過し、老朽化や複雑化が進んでしまった旧型の情報システム
そのシステムは、誰も内部仕様を把握しておらず、設計書も存在しない状態でした。さらにソースコードの一部が欠損し、本番環境と検証環境も一致していないうえ、
テスト環境やテスト資産も十分に整備されていませんでした。
そのような状況から、生成AIを活用して約3年かけてシステム刷新を実現した取り組みが紹介されました。
ただ、この成果は単に生成AIを利用しただけで実現できるものではなく、生成AIを効果的に活用したからこそ実現できたものだと感じました。
では、生成AIをどのように活用すべきなのでしょうか。本セッションでは、その考え方について学ぶことができました。
a. 生成AIに人格や役割を与える
例えば、
あなたはAWSの専門家です
あなたはシステムアーキテクトです
といった前提を与えることで、回答の精度が向上し、欲しい情報を得やすくなります。
b. 生成AIには作らせるだけでなく説明・検証もさせる
成果物を作成させるだけではなく、
なぜその回答になったのか
検証結果はどうか
他の選択肢はないか
まで説明させることで、成果物の品質向上と利用者自身の理解につながります。
c. 生成AIに思い出させる仕組みを作る
生成AIは長い対話の中で、過去の情報を見失ってしまう場合があります。
そのため、
・前提条件を定期的に再提示する
・要件をまとめたドキュメントを参照させる
など、生成AIが過去の情報を思い出せるような仕組みを用意することが重要です。
d. 生成AIへの指示作成にも生成AIを活用する
生成AIの成果物は、与える指示（プロンプト）の質に大きく左右されます。
そのため、
「この課題を解決するための最適なプロンプトを作ってください」
というように、プロンプト作成自体を生成AIに支援してもらうことも有効です。
生成AIを活用するにあたって、「生成させること」だけに注目するのではなく、「説明させる」「検証させる」「思い出させる」といった考え方が特に参考になりました。
今後、生成AIを活用する機会はさらに増えていくと思うので、本セッションで学んだ考え方を意識しながら生成AIを活用していきたいと思います。
2.Amazon ECS 最新デプロイパターン DeepDive（CNS309）
本セッションでは、2025年7月にAmazon ECSがネイティブ（独自）のBlue/Greenデプロイ（Canary、Linearを含む）に対応したことを受け、
ECSネイティブのデプロイの特徴やAmazon CodeDeployからの移行方法について紹介されていました。
私は2025年4月から始まったプロジェクトで、初めて業務でAWSを利用しました。
4月から6月にかけて設計を行っていたのですが、その当時はECSネイティブのBlue/Greenデプロイは利用できず、ECSのネイティブデプロイ方式はローリングアップデートのみでした。
一方、担当していたシステムではBlue/Greenデプロイを採用する方針だったため、CodePipelineとCodeDeployを組み合わせた構成で設計を行いました。
しかし、CodeDeployを利用したBlue/Greenデプロイの設計は想像以上に難しく、
デプロイの種類（Canary、Linear）それぞれの利点に基づいたデプロイの思想の決定、
デプロイグループやAppSpec.ymlの作成、CodePipelineやALB、ECSとの連携するための他サービスの理解など、とても苦労したことを覚えています。
その後、設計が一段落したタイミングでECSネイティブのBlue/Greenデプロイがリリースされたことを知り、
そっちの方がいいのかはわからなかったのですが「もう少し早く出てほしかった…！」と思いました(;_;)
自分自身がCodeDeployの設計に苦労した経験もあり、ECSネイティブのBlue/Greenデプロイでは何が変わるのか、
どのように移行できるのかを詳しく知りたいと思い、本セッションを受講しました。
では、CodeDeployとECSネイティブのBlue/Greenデプロイの違いはなんなのでしょうか。移行はどのようにできるのでしょうか。
本セッションでは、以下について学ぶことができました。
a.構成がシンプルになる
ECSネイティブのBlue/Greenデプロイでは、ECSのリソースだけでデプロイが完結します。
また、CodePipelineとECSネイティブのBlue/Greenデプロイを組み合わせたデプロイ構成も利用できるようになっています。
これまで必要だったCodeDeploy関連のリソース（デプロイグループやAppSpec.yml）が不要となるため、構成がシンプルになります。
b. デプロイ戦略の変更が容易になる
デプロイ戦略は UpdateService API を利用して簡単に変更できます。
そのため、CodeDeploy利用時に必要だったAppSpecファイルやデプロイグループ定義などが不要になり、設定管理もシンプルになります。
c. 利用できるデプロイオプションが豊富
CodeDeployと比較して利用できるオプションが増えているとの説明がありました。
セッションでは詳細までは追いきれませんでしたが、今後改めて調べてみたいと思います。
d. ECSのライフサイクルフック
CodeDeployのライフサイクルフックよりも、ECSネイティブのフックの方が柔軟な処理を実装できるという紹介がありました。
私は今回初めてライフサイクルフックという機能自体を知りました。デプロイプロセスの特定の段階（「新タスクセット作成前」「本番トラフィック移行前」など）で、
新しいタスクセット作成前の準備や本番環境へ移行する前の最終確認などの処理を実行できるため、
状況によっては安全なデプロイを実現する上で活躍しそうな機能だと思いました。
また、ECSネイティブのBlue/Greenデプロイへ移行するためのパターンが以下の3つ紹介されていました。
・インプレース更新：既存ECSサービスをECSネイティブのBlue/Greenへ変更。ALBもそのまま利用。
・新サービス作成：ECSサービスのみ新規作成しECSネイティブのBlue/Greenへ変更。既存のALBはそのまま利用。
・新サービス・ALB作成：ECSサービスをECSネイティブのBlue/Greenへ変更。ALBも新規作成する。
私は、現在利用している環境ではどの移行方法が適しているのかという視点で聞いていました。
しかし、途中で「これ、CodeDeploy単体での移行パターンで、CodePipeline+CodeDeploy構成の場合の移行の紹介ではないのでは？」と気づきました。
そのため、現在利用しているCodePipeline+CodeDeploy構成から移行する方法については、
自分でも調査してみる必要があると感じました。
本セッションでは、CodeDeployとECSネイティブのBlue/Greenデプロイの違いや、ライフサイクルフックなど新しく知った機能についても学ぶことができました。
現在利用しているCodePipeline＋CodeDeploy構成からの移行方法については確認できませんでしたが、
移行した場合はCodeDeploy関連のリソース（デプロイグループやAppSpec.yml）が不要になるため、管理負荷を削減できる可能性があると感じました。
今後の学習も兼ねてCodePipeline＋CodeDeploy構成からの移行方法について調査し、
ECSネイティブのBlue/Greenデプロイによってどの程度構成や運用をシンプルにできるのか検証してみたいと思いました。
3.AI を活用した新しいデプロイメント手法と CI/CD における迅速な障害検知と復旧の実現方法（DVT350）
本セッションは前半・後半の2部構成でした
「前半：MCPによるCI/CD構築」
まず前半では、MCP（Model Context Protocol）を活用したCI/CDパイプライン（CodePipeline）の構築手法について紹介されました。
先ほども書いた通り、私は2025年4月からAWSを用いたシステム更改プロジェクトに参画しています。
そのプロジェクトではCodeDeployを利用したCodePipelineも構築しており、興味のある内容だったため本セッションを受講しました。
CodePipelineの設計自体は担当ではありませんでしたが、当時の担当者はかなり苦労していた印象があります。
私自身も現在構成を見ていますが、CodePipelineは他サービスとの依存関係や設定項目も多く、構築難易度の高いサービスだと感じています。
そのような中で、MCPを活用すると「実現したいこと」を伝えるだけでCI/CDパイプラインの構築やデプロイを自動化できるという話が紹介されていました。
さらに、AWSのベストプラクティスを踏まえた構成を提案してくれるとのことで非常に驚きました。
デモではKiroがMCPを通じてAWSサービスと連携をとりCodePipelineの構築やデプロイを行っていました。
MCP自体はAIとAWSサービスを接続するためのプロトコルであり、Kiroは実際に操作を行うAWSのAIエージェント（IDE）にあたります。
一方で、便利な反面、MCPに任せきりにすると利用者自身の知識が身につきにくくなるのではないかとも感じました。
そのため、前述のカクヤスのセッションで学んだように、生成AIに構築だけでなく理由や設計意図も説明させながら活用することが重要だと思いました。
最終的には、人間が内容を理解しレビューすることが必要だと感じました。
「後半：AppConfigによる運用改善」
後半では、CI/CDパイプライン構築後の運用方法として、AWS AppConfigを活用した設定管理について紹介されていました。
私は今回のセッションで初めてAppConfigについて知ったのですが、AppConfigはAWS Systems Managerの機能の一つで、
アプリケーション設定を安全に管理・配布するためのサービスです。簡単に言うと、機能フラグ（if文制御のような仕組み）を提供しており、
アプリケーションの機能をオン・オフできるようになります。
例えば、
・未完成機能をオフにした状態で本番リリースする
・将来公開予定の機能を事前にデプロイしておく
・公開タイミングでフラグをオンにする
といった運用が可能になります。
機能の有効化・無効化のためにコードを再リリースする必要がなくなるため、
アーキテクチャによってはリリース時間の短縮や障害発生時の迅速な切り戻しにもつながると感じました。
本セッションでは、MCPを活用したCI/CD構築の可能性と、AppConfigを活用した運用改善について学ぶことができました。
kiroとMCPを組み合わせたCI/CD構築やAppConfigによるフラグ機能は、実際の業務で利用できる機会があれば、ぜひ試してみたいと思いました。
[おまけ]
EXPOもたくさん見たり体験したりしてきました。その中からいくつかピックアップして紹介します！
まず、深層学習を用いた聴覚採点（歌声評価モデル）というシステムです。
現状の機械採点は音程を重視していますが、人間が感じる「歌のうまさ」を十分に反映できないという課題があります。
本システムは、機械採点と人間の聴感採点の差異を分析し、人間の感覚に近い採点を実現することを目的として開発されたそうです。
カラオケに行くと、音程は少し外れていても「この人歌うまいな」と感じることってありますよね。
そういった感性を採点に取り入れるため、人が実際に歌声を聞き、一対比較法を用いて「力強い」「明るい」「優しい」といったラベル付けを
SageMaker Ground Truthで実施したとのことです。そのラベル付け回数は約15万回にも及ぶそうです。
このAI採点は実際に体験することができ、90点以上を獲得すると専用ボトルがもらえるとのことでした。
私はDay1の午前中に訪れたのですが、ちょうどシステム説明が終わり体験が開始されたタイミングだったため、先陣を切って挑戦してきました！
選曲は普段からの十八番の「ウィーアー！」です！
結果はギリギリ90点超えで、ボトルもゲットでき、とても良い思い出になりました。
次に、あなたとトップアスリートの差を体感せよというシステムです。
計測用カメラで取得したデータをAWS上で分析し、Bedrockを活用してトップアスリートのデータと比較した結果をリアルタイムでモニターに表示するシステムです。
計測は以下4つの視点から行われているそうです。
・データ（体格/測定値）
・フィジカル（運動能力）
・栄養（体づくり）
・メンタル（競技適性）
測定結果では、適性スポーツをトップ3まで紹介してくれるほか、1位に選ばれたスポーツのトップアスリートを100点とした場合の自分のスコアを表示してくれます。
また、腕のリーチや肩幅などの細かい数値も結果として出ていました。
こちらも実際に体験してみました！
栄養や競技適性を分析するための簡単なアンケートに回答し、その後、データとフィジカルを測定するために片足立ち（バランス力）や前屈（柔軟性）などを行いました。
結果は、
・3位：体操
・2位：競泳
・1位：ラグビー
で適性スコアは54点。
身体を鍛えてラグビー選手を目指そうかなと思います（笑）。
自分では想像していなかった競技が上位に表示されたので面白かったです。みんなにもぜひ体験してもらいたいEXPOの一つでした。
[まとめ]
今回初めてAWS Summitへ参加しましたが、とても充実した2日間となりました。
参加目的としていた「AI関連の活用方法や最新動向のキャッチアップ」という点では、生成AIを活用したシステム刷新事例やMCP、Kiroなどの新しい技術について知ることができ、
AIの活用がさらに広がっていることを実感しました。
また、「担当プロジェクトで利用しているAWSサービスへの理解を深める」という点では、ECSネイティブのBlue/GreenデプロイやCI/CD関連のセッションを通じて、
現在利用しているサービスについてより理解を深めることができました。
セッションだけでなく、EXPOでは最新の技術やサービスを実際に体験することもでき、AIやAWSの活用事例を楽しく学ぶことができました。
ノベルティもたくさんもらえて、正直これが無料なのかと驚くレベルのイベントでした！
来年参加する方は、本記事の[参加ガイド編]を確認の上、ぜひ参加してみてください！
（早めの事前登録とセッション予約をおすすめします）
来年も可能であればぜひ参加したいと思います！
最後まで読んでいただきありがとうございました。