AWS Summit Japan 2026 参加レポート 〜AI革命の最前線から〜
2026.11.05
はじめに
こんにちは。開発本部 基盤開発部 グループ基盤課の亀井です。
中途入社2年目で、グループ会社のインフラ構築・運用案件を担当しています。
2026年6月25日（木）・26日（金）に幕張メッセで開催された AWS Summit Japan 2026 に、開発メンバーの三原・仲宗根・亀井の3名で参加してきました。
昨年の参加レポート（歩き方編・内容編）に続き、今年は少し趣向を変えて、参加した3人がそれぞれのイチオシセッションを1つずつ紹介するオムニバス形式でお届けします。
AWS Summit Japan 2026 とは
AWS Summit Japan は、AWS が主催する日本最大級のクラウドイベントです。
入場無料（事前登録制）で、基調講演や事例セッション、パートナー企業の展示ブースなど、2日間では回りきれないほどのコンテンツが用意されています。
今年の会場は例年にも増してAI一色。
エージェンティックAIをテーマにしたセッションが目立ち、来場者数も体感で昨年以上でした。
今年の会場の様子と歩き方メモ
会場の全体像は昨年の歩き方編に譲るとして、今年現地で得た学びを簡単に共有します。
- 初日の朝は入場までが大行列。9:45に会場に着いて、入場できたのは11時前でした。2日目の朝は打って変わってほぼ待ち時間ゼロだったので、大行列を覚悟すべきは初日だけと考えてよさそうです
- 基調講演は席に座ってじっくり聴くのが一番学びになります。ただ席は争奪戦で、初日は入場の行列で開始に間に合わないことも
- 席を取れなかったときは切り替えて、オンライン配信をスマホで視聴しながら「並ばないと手に入らないもの」に時間をあてるのが良いです。私は2日目はこのスタイルにして、配信を聴きつつAWS認定資格者向けステッカーを受け取りました
- 大きな荷物は並ぶ前にコインロッカーへ。キャリーケースを持ったまま行列に並ぶのはなかなか大変です
- お弁当の引換券は基調講演の入場券に付属。昼のピークを外すとスムーズに受け取れます
- 会場内は時間帯によって通信がかなり厳しくなります。サブ回線があると安心です
3人のイチオシセッション
三原のイチオシ: AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス
業務最適化室 室長の三原です。
AWSの杉本さんのセッションを紹介します。
みなさんもAIを活用して業務を進める中で、「AIによって業務は本当に効率化されているのか」と疑問に感じるときがあるのではないでしょうか。
個人としては効率化されていると感じていても、組織全体としてはさほど効果が出ていない状態を「AI活用のパラドックス」と呼びます。杉本さんは、このパラドックスには以下の2つの要因があると分析しています。
- スキル侵食の悪循環
- 個人のスキルが低下していても、短期的にはAIによって業務が回るため問題が顕在化しません。その結果、中長期的にはAIの成果物をレビューできる能力を持った人がいなくなってしまいます。
- オーナーシップの欠如
- AIが担当者から心理的なオーナーシップを奪ってしまいます。その結果、業務に対する最終判断を引き受けてくれる人がいなくなってしまいます。
これらは長期的に組織を蝕むため、各組織においてあらかじめ「意図的な非効率」という仕組みを設計・実施して対応する必要があると提案されています。
「意図的な非効率」の例として、セッション内で提示された2つのアイデアが非常に参考になりました。
- 環境レイヤーでAIの依存度を変える設計
- 本番環境ではAIを活用してできる限り自動化を進める一方で、開発環境ではAIの利用を禁止し、人の学びの場とするアイデアです。開発速度の面では非効率が発生するものの、開発者のスキルとオーナーシップを育むことができる設計だと感じました。
- 時間軸でAIの依存度を変える設計
- 各部署が「責任を持つ必要があるものの、理解が不足している」と感じる業務領域を1つ選び、一定期間その領域でのAI利用を禁止します。AIを使わずに業務を行い、十分な理解と責任を持てるようになった段階でAIの利用を解禁し、次にAIを禁止する領域を相談して決定します。
この時間軸での設計は、弊社でいう「山ごもり休暇制度（年1回、まとまった休暇を取得し、その間は完全に業務を引き継いで連絡を断つ制度）」にかなり近い施策だと感じました。業務の引き継ぎを組織ルールとして義務付けることで、結果として長期的な業務の属人化を防ぐ仕組みとなっています。
これらのルールは短期的には非効率を伴うため、組織ごとの意思決定が必要です。しかし、組織を長期的に継続させていくために、我々もこのような施策を策定していく必要があると大きな学びを得ました。
発表資料も公開されています: 発表資料（PDF）
仲宗根のイチオシ: ランサム危機を転機に ― アスクルが加速させた AI-DLC
AD EBiS 開発担当の仲宗根です。
少し前にランサムウェア対策を担当していたこともあり、真っ先に選んだのがこの講演でした。
アスクル株式会社 代表取締役社長CEO 吉岡 晃氏によるセッションです。
2025年10月のランサムウェア被害からの復旧と、その経験を機に加速させたAI活用が語られました。
印象に残ったのは、復旧時の判断軸として紹介された3つです。
「被害の拡大防止」「安全かつ安心な再開」「一刻も早いサービス再開」。
速さは3番目。この順番が決まっていたからこそ、売上ゼロを覚悟したサービス停止を発生当日に判断できたのだと感じました。
AD EBiS の計測の仕組みはお客様のWebサイト上で動作するため、私たちにとって「拡大防止」の重みはさらに増します。
もし AD EBiS が攻撃を受ければ、影響はお客様のサイトだけでなくそのサイト訪問者にまで及ぶからです。
一方で、計測を止めること自体がお客様のマーケティング活動に影響します。
有事の際に「どう止めるか」まで平時で決めておくことが大切です。
そして私たちにとっての「安全な再開」には、計測した数字が正しいと示せることも含まれます。
20年もの間、データでお客様の意思決定を支えてきた我々だからこそ、生半可な覚悟で復旧という言葉は使えません。
もう一つ印象に残った話があります。
自力での再構築を決めてから28日で新しいネットワークを構築できた一方、全国の物流拠点の全面復旧には108日を要したという話です。
背景には、構成の異なる7,000台以上の現場機器がありました。
日頃から詳細な仕様管理を緻密に行い、継続的にシステムを更新していくことが BCP に重要だと語られていました。
では、物流拠点を持たない私たちのようなWebサービスには関係のない話でしょうか。
決してそうではないと思います。長く運用してきたシステムには、いざという時に同じように作り直すことが難しい部分が残っていくものです。
AIで速く作り直せる時代だからこそ、作り直したものが正しいかを確かめる「なぜそう作ったのか」という記録が重要になると感じました。
有事の速さは、その場の頑張りではなく、平時にどれだけ決めておき、残しておいたかで決まる。
まずは自分が関わるシステムから「なぜ」を残すことを始めようと思います。
発表資料も公開されています: 発表資料（PDF）
亀井のイチオシ: IaC コードを資産へ：AWS CDK 社内ライブラリと横断展開
株式会社メイツの後藤健太さん（AWS DevTools Hero）によるセッションです。
複数プロジェクトに散在しがちなインフラコードを、AWS CDK の Construct として社内ライブラリ化し、GitLab のパッケージレジストリから各プロジェクトへ npm パッケージとして横断展開する取り組みが紹介されました。
- 部品化と一元管理
- インフラコードを CDK Construct として部品化し、社内ライブラリとして一元管理します。
- 標準品質の自動担保
- ライブラリの改善が各プロジェクトに行き渡るため、セキュリティ・ログ・アラートといった標準品質を自動的に担保できます。
複数案件のインフラ構成を横断して見る立場にあり、「同じような構成をプロジェクトごとに少しずつ違う形で持ってしまう」という課題をまさに感じていたため、このアプローチは非常に刺さりました。
持ち帰って課内で話したところ、運用面の論点もいくつか出てきました。
- 共通部分の修正が意図せず全プロジェクトへ波及しないよう、プロジェクトごとのバージョン管理が必要になり、その運用コストをどう見るか
- メンバーのスキルが十分に高いチームでは、共通化の恩恵より制約が勝つ場面もあるのではないか
- 導入直後は快適でも、数年後にバージョンの分散が問題として顕在化しないか
あらためて発表資料を読み返すと、このうち2つについては、セッションで対策が紹介されていました。
修正の波及については、後から追加するプロパティは省略可能にし、不要になったプロパティも削除せず @deprecated で示すというルールで互換性を保ち、ライブラリ側の integ テストと各プロジェクト側のスナップショットテストで変更を確認しているそうです。
共通化が制約になる懸念については、全部入りの Construct は作らず、公開する Construct を最小限に絞るという設計の原則が示されていました。
一方で、数年後のバージョンの分散については触れられておらず、ここは我々で考える必要がありそうです。
セッションを持ち帰ってこうした議論ができたこと自体が、大きな収穫でした。
もし当社に当てはめるなら、まずはセキュリティやログ・アラートといったガードレール的な領域に絞るのがよいと考えています。課内であらためて検討し、有用だと判断できれば、小さく試すところから始めたいと思います。
発表資料も公開されています: 発表資料（PDF）
おわりに
3人がそれぞれ選んだセッションはテーマこそバラバラでしたが、振り返ってみると「速く作れる時代に、人が理解し判断できる状態をどう残すか」という共通の問いが見えてきました。
AIで成果物は速く作れても、それをレビューし最終判断を引き受ける人のスキルとオーナーシップは、意図して育てなければ失われていく。
有事に速く動けるかどうかは、平時にどれだけ判断軸を決め、「なぜそう作ったのか」を残してきたかで決まる。
そしてインフラコードも、プロジェクトごとに書き捨てるのではなく、組織の資産として育てていくことで標準品質を保てる。
どれも、目先の効率だけでなく、数年先の組織やシステムの状態を見据えた話です。
今回の学びを持ち帰り、それぞれの現場で小さく試していきたいと思います。
最後までお読みいただき、ありがとうございました。