AWS Summit Japan 2026 参加レポート

AWS Summit Japan 2026 参加レポート

はじめに

こんにちは、ZOZOMO部FBZブロックの杉田です。普段はFulfillment by ZOZOが提供するAPIシステムを開発・運用しています。昨年からは、社内における開発者向けAI支援ツールの推進を担う専門チームでも兼務で活動しています。

ZOZOMO部SREブロックの𠮷富です。普段はFulfillment by ZOZOのSREをしています。

2026年6月25日・26日の2日間、幕張メッセにて「AWS Summit Japan 2026」が開催されました。本記事では、会場や各ブースの様子に加え、特に印象に残ったセッションについてご紹介します。

目次

AWS Summit Japanとは

AWS Summit Japanは、AWSの最新技術や活用事例を学べる日本最大級のイベントです。2026年も幕張メッセで2日間にわたり開催され、260以上のセッションや展示、ハンズオン、コミュニティ企画など、幅広いコンテンツが用意されていました。AIエージェントやサーバーレス、クラウド活用の最新動向など、今後のシステム設計や運用に関わるテーマが多く取り上げられていました。現地参加だけでなくオンデマンド視聴もできるため、気になるセッションを後から見返すこともできます。

会場の様子

紹介:𠮷富

早い時間から多くの参加者で賑わっていました。基調講演の開始時刻の前後は列が伸び、入場に1時間以上かかることもあったようです。

同僚提供写真

大きいAWSロゴ

先着5,000名に毎年恒例のクッションとお弁当引換券が配布されました。さらに基調講演の開始前に入場したところ朝食も配布されていました。

配布物

いくつかのセッションは入場時に配布されるイヤホンを利用して視聴するサイレントセッションでした。座席に設置されたレシーバーを利用してセッションの音声を視聴できます。

Partner Solution Expoの様子

AWS Builders’ FairではAWSサービスを利用したプロジェクトが多数紹介されていました。ゲーム形式のものが多く、楽しく学べました。

AWS Builders’ Fairブース 大人気新食感スイーツもちぷるを転売ボットからAWS WAFで守ろう

AWS Builders’ Fairブース AIパワポカラオケ

「Physical Hands'on Blocks 組んで守れ! AWSアーキテクチャ」を実際に体験しました。ブロックを動かしアーキテクチャを完成させ、攻撃から守るゲームです。

AWS Builders’ Fairブース Physical Hands'on Blocks 組んで守れ!AWSアーキテクチャ

ELBからEC2を切り離す痛恨のミス

Physical AI特設エリアではロボットの実機を体験することができました。

Physical AI – 見て、考えて、動かす

セッション紹介

AI 駆動開発ライフサイクル (AI-DLC) のご紹介(AIM221)

紹介:杉田

AI生産性のパラドックス

AIを開発に導入しても速度向上は10〜15%にとどまり、場合によっては「AIを使うと19%遅くなる」というデータが紹介されました。たとえコーディングで時間を節約しても、開発ライフサイクルの他の部分で時間が失われているためです。

AIは決して銀の弾丸ではないので、適材適所で効果的な使い方をしないとかえって状況の悪化を招く場合があると、実感としても強く感じています。この研究結果から、AIに丸投げしたり、逆にAIを単なる補助ツールとして狭く使ったりするだけではダメなのだとあらためて感じました。

AIソフトウェア生産性のパラドックス

開発手法「AI-DLC」の紹介

AIのポテンシャルを最大限に発揮したうえで、ビジネスの意図をソフトウェアシステムとして価値提供できるようにするには、従来の方法の延長線上では限界があります。具体的には、以下のような課題が挙げられます。

  • 人間の関与を最小限またはゼロにした開発は信用が難しく、説明責任も果たすことができない
  • AIによるアジリティは開発ライフサイクル全体では限定的
  • コーディングで節約した時間は他の部分で失われている

これらの課題を解決するためにAWSが再構想したのは「AI-DLC」です。AI-DLCは以下の3つのステップに分かれ、人間の意図伝達、AIによる計画・実行、人間によるレビューや承認という形で進むオペレーティングモデルです。

  • Inception
  • Construction
  • Operation

AIのためのオペレーティングモデル

AI利用を前提とした開発が行われる昨今では、開発プロセス自体をAIネイティブに作り直すというアプローチはとても重要だと思いました。 コンテキストの扱いがポイントとなるAI利用を前提とした開発において、各ステップが次のステップのコンテキストを構築していく流れは、とても理にかなっていると感じました。

全体の流れ

実践事例と驚異的な成果

実際の実践事例として、AI-DLCの導入により属人性の高い領域でも開発生産性が200%以上も向上したほか、従来の方法では2か月想定の開発をわずか48時間で達成させた事例が紹介されました。

ここまでの成果を出すには、AI単体の力ではなく、ビジネス、開発、QAなどのチームが垣根を越えて協働する「モブエラボレーション」の体制づくりが不可欠になります。

モブエラボレーション

本セッションを通じて、AIを単なる開発支援のツールとして使う段階は終わったとあらためて痛感しました。適用できそうな領域からAI-DLCの思想を取り入れ、人間とAIが強みを最大化し合う新しい開発プロセスへの移行を検討していきたいと思います。

まとめ

サイバーエージェントにおける AI 推進戦略と変革への取り組み(AIM229)

紹介:杉田

エンジニアの評価制度

サイバーエージェントでは、2028年の開発プロセス完全自動化を見据え、AIを武器に開発領域からビジネス領域へ越境する「ビジネスリードエンジニア」などを新設していました。技術のみならず課題発見から実装・運用までを一気通貫で担える人材を正当に評価する枠組みです。

エンジニアの評価制度

詳細については、以下のブログに記載があったので、気になる方はご覧ください。

developers.cyberagent.co.jp

AIの台頭により、コーディングそのものの価値が相対的に変化している中で、エンジニアのキャリアパスを組織主導で再定義している点が印象的でした。AI時代においてエンジニアが目指すべき姿を考えるうえで、参考になる評価軸だと感じました。

全社AI活用を可視化・底上げする「AI番付」の取り組み

各事業部におけるAI活用の「成果インパクト」や「カルチャー醸成」などを、相撲の番付表(横綱〜幕下)に見立てて評価・可視化している取り組みが紹介されました。

AI番付の評価指標

単にツールを導入して終わるのではなく、組織ごとの成熟度を定量・定性的に測る仕組みを作ったうえで、全社的なナレッジ共有と底上げを図る非常に効果的なアプローチだと感じました。特に、結果を分析レポートとしてまとめ、事業ごとの改善案を提案する仕組みは参考になりました。

AI番付の分析レポート

AIを「楽しむ」文化の醸成

AIをフル活用して実装速度を競う「AI開発RTA」や、2日間でゼロからプロダクトを作る「AI Agent Arena」を開催した様子が紹介されました。これらのイベントを通じて、エンジニアがAIに楽しく触れる場を提供し、ベストプラクティスの創出・共有を促していました。

AI Agent Arena

利用を強制するのではなく、イベントを通じて「AIフレンドリー化」を推進する姿勢は、組織の熱量を高める取り組みとして参考になりました。

人間がボトルネックにならないための「Human in the Loop」設計

自動化が進むと人間の監視が形骸化する「プロセスの萎縮」というリスクがあります。このリスクに対して、タスクのリスクに応じて「全件レビュー」「スコアベース」「エスカレーション」の3パターンで人間の関与を設計している取り組みが紹介されました。

Human in the Loop

タスクに関係なく一律でHuman in the Loopを採用するのではなく、リスクや複雑さを加味したうえで段階的にHuman in the Loopを設計している点が参考になりました。

サイバーエージェントの取り組みは、ツールの導入にとどまらず、評価制度、企業文化、そして開発プロセスそのものをAI時代に適合させていくといったものでした。AIと協働する新しい開発組織のあり方については、私の所属組織でも重要なテーマなので、今後の活動の参考になるセッションでした。

まとめ

生成 AI ブームのその先へ -AI を使いこなす人材戦略とプラットフォームエンジニアリング-(PRT237-S)

紹介:杉田

生成AIプロジェクトの成果創出までの「4つの壁」

同社のアンケートから、2024年から2025年にかけて生成AIの活用率は増加している一方で、DXの成果について「期待通り以上」と回答した割合は減少していることが確認できました。

アンケート

また、PoCの成功はゴールではなく、その先には「本番化までの時間」「LLMの精度不足」「利用が広がらない」「想定外のコスト増」という4つの壁が存在すると指摘されていました。

4つの壁

本番化までの時間と「Governance as code」

セキュリティやコンプライアンスの都度審査により、本番の開発開始までに数か月を要するケースがあると紹介され、これは組織の規模感が大きくなることでより顕著になる傾向があります。対策として、ガバナンス要件を組み込んだ開発テンプレート(Governance as code)を用意し、事前承認済みの型を開発者に利用させるアプローチが紹介されました。

Governance as code

守りのプロセスを自動化・テンプレート化して、開発者の認知負荷を下げる取り組みはまさにプラットフォームエンジニアリングの真骨頂だと思いました。Governance as codeは、社内での車輪の再発明を回避する手段として、OSSで有名なBackstageをはじめとした開発者向けポータルとの相性が良いと感じました。

生成AI時代の「FinOps」

生成AIの利用拡大に伴い請求額が想定の数倍に膨らむリスクに対し、コストの可視化とプロンプトキャッシング等の対策が紹介されました。

コスト可視化

プロンプトキャッシングの仕組みとして、キャッシュは先頭から一致した場合のみヒットするため、プロンプトの上部に変数(可変部)が存在すると効果が薄くなる点について解説されました。

プロンプトキャッシュの仕組み

そこで、この性質を活かすために可変部をプロンプトの下部に移動させる構造変更をしたことで、1ワークフローあたり400円かかっていたコストが80円(80%削減)へと劇的に改善した事例が紹介されました。

プロンプトキャッシュによるコスト削減

機能としてキャッシングを有効にするだけでなく、内部の仕組みを理解してキャッシュヒット率を最大化している点は学びでした。生成AIを活用するうえで、それらのコストは切っても切り離せない課題だと思うので、機能を使いこなすことによるコストインパクトに驚きました。

Amazon S3セキュリティベストプラクティス(STG357)

紹介:𠮷富

Amazon S3はシステム構成において、データ保存先、ログ出力先、バックアップ、データ連携基盤など、さまざまな場面で利用されています。利用用途が増えるにつれて、アクセス制御や利用者・アプリケーションごとの権限管理、意図しない公開の防止など、セキュリティ面で考慮すべきポイントも増えていきます。

このセッションでは、Amazon S3のセキュリティを高めるためのベストプラクティスを改めて学べました。

セッションのテーマと背景

S3が標準的に備えているセキュリティ

パブリックアクセスのブロック(BPA)や全新規オブジェクトの暗号化などがデフォルトで有効になっており、データを安全に活用しやすいデフォルト設定が用意されています。

S3セキュリティ8つのベストプラクティス

データ保護を実現するためのプラクティスとして以下が提示されました。

  1. パブリックアクセスをブロックする
  2. バケットキーを有効にする:SSE-KMS利用時のAWS KMSコストを最大99%削減。
  3. 統制を分離してスケールする
  4. セキュリティ変更をモデル上でテストする
  5. AWS Organizationsを活用する:RCP/SCPによる組織レベルの強力なガードレールを適用。
  6. データ保護をアプリケーションにも広げる:チェックサムの活用など、アプリケーション側でもデータ保護を考慮する。
  7. ログを有効にする:異常検知や自動修復などの対応を実装する。
  8. 耐久性とリカバリを事前に計画する

統制の分離とスケール

ビジネスや組織の成長に合わせて、権限管理における統制を分離する必要があります。単一のバケットポリシーだけですべてを管理しようとすると保守が難しくなりやすいため、以下の機能を活用して権限を適切に委譲・分割する考え方が紹介されていました。

  • S3 Access Points:ユースケースごとに独自のポリシーを持たせる。
  • S3 Access Grants:特定のプリンシパルに対して、バケットやプレフィックスへのアクセス権をプログラムで付与する。
  • ABAC(属性ベースアクセス制御):リソースやプリンシパル名ではなく、タグに基づいてセキュリティポリシーを定義する。

S3のセキュリティはバケットの設定だけで完結するものではなく、組織全体のガバナンスやアプリケーション側も含めて設計する必要があることを再認識しました。紹介されていた内容の中には、パブリックアクセスブロックや暗号化、ログ設定など、既存のバケットでもすぐに確認できる項目が多くあります。S3を利用している環境がある場合は、ぜひこの機会に設定状況を見直してみてください。

Advanced VPC Networking-知っておきたいAWSネットワークの最新動向:VPC関連サービスのアップデートを総整理-(CDN320)

紹介:𠮷富

このセッションでは、VPCやネットワーク関連サービスにおける2025年のアップデートを網羅的にキャッチアップできました。普段VPCを触っている人ほど、こんなにアップデートがあったのかと驚く内容だったと思います。紹介量が多く見応えのある内容だったので、ネットワーク構成に関わる方はぜひチェックしてみてください。特に気になったアップデートを2つ紹介します。

Amazon VPC Latticeのさらなる進化とカスタムDNS対応

VPC Lattice

VPC Latticeは、複数のVPCやアカウントをまたぐサービス間通信を論理的にグループ化(サービスネットワーク)してつなぐ機能です。これまではサービスやリソースに自動生成された一意のFQDNが割り当てられていましたが、2025年のアップデートとして、カスタムDNS名や設定可能なIPに関する機能強化が紹介されていました。自分で設定したDNS名によるアクセスが可能になり、既存のアプリケーションからのアクセスルーティングがやりやすくなります。

AWS Direct Connectとハイブリッド/マルチクラウド接続の強化

AWS Direct Connect

マルチクラウド接続を容易にする「AWS Interconnect Multicloud/Last Mile」が一般提供(GA)を開始しました。Direct Connectを経由してオンプレミス環境や他クラウド、AWS上のアプリケーションを接続しやすくなり、ハイブリッド/マルチクラウド環境におけるネットワーク設計の選択肢が広がりました。

VPC関連サービスでは、2025年だけでも150以上の新機能が追加されたそうです。このセッションはVPC周辺の最新情報をまとめてキャッチアップする良い機会になりました。

2024年のVPC関連サービス

2025年のVPC関連サービス

ワークフローオーケストレーターにおける複雑性と非決定性のコントロール(CNS454)

紹介:𠮷富

ワークフローは事業の成長、システムの改修に伴って複雑になってしまうことがあります。さらに障害の監視・管理やリトライ処理といった例外的な処理の整備によりシステムが複雑化したり、それらの解決のためにあらゆるシステムでAI・MLとの結合が求められたりするようになっています。

このセッションでは、複雑化しがちなワークフローの管理手法と、AIエージェント特有の「非決定的」な挙動をどう扱い、どのようにアーキテクチャに組み込むべきかを学べました。

ワークフローの役割とAWSサービスの紹介

ワークフローオーケストレーションサービスの使い分け

ワークフローは、複雑なシステム連携における例外処理・リトライ・並列処理・Map実行などの課題に対応し、可観測性(オブザーバビリティ)を高めるために用います。セッションでは、要件に応じたAWSの主要なワークフローオーケストレーションサービスの使い分けが紹介されました。

  • AWS Step Functions:GUI上でワークフローを視覚的に設計できるサービス。JSONataに対応しており、ステートマシン内でデータの変換・抽出・加工を行える。
  • AWS Lambda durable functions:JavaScript/TypeScriptやPythonなどで、長時間実行されるワークフローをコードとして記述できる仕組み。最大1年の実行に対応し、リトライや状態管理を扱いやすい。
  • Amazon MWAA:Apache AirflowをAWS上で利用できるマネージドサービス。DAG(有向非巡回グラフ)によってタスクの依存関係や実行順序を管理でき、AWS外のシステム連携にも向いている。

指揮者は歌わない

複雑性保存の法則が示す通り、システムが持つ複雑さを完全に消し去ることはできません。重要なのは「複雑性をどこに置き、どうコントロールするか」であり、その基本方針がワークフローの分割です。そこであげられていたのは「指揮者は歌わない(関心の分離)」という設計原則です。

例えばStep FunctionsのChoice stateに複雑なメール検証のような検証ロジックを書くと、保守が困難になります。オーケストレーターは進行管理に徹し、ビジネスロジックはAWS Lambdaなどのコード側に切り出すべきです。

AIエージェントの非決定性を制御するアプローチ

AIエージェントの非決定性を制御するアプローチ

ワークフローにとってAIは、予期せぬ判断や無限ループを引き起こす可能性のある「非決定的」なシステムです。この揺らぎをシステムに組み込む方法として、決定論的ワークフローで包み込むアプローチが紹介されました。

  1. Outer/Inner Loopパターン:AIの非決定論的な推論を、タイムアウトやリトライを備えたワークフローで制御。
  2. Human in the Loop(HITL)パターン:重要な判断はAIに任せきらず人間の承認フローを挟む。
  3. Workflow as Toolsパターン:既存の決定的なワークフローを、AIから安全なツールとして呼び出す。

また、Amazon BedrockなどのAIサービス利用時は、スロットリング対策としてExponential BackoffやJitterの活用が重要です。

  • Exponential Backoff
    • リトライ間隔を指数関数的に増加させることで、サーバーの負荷を軽減する。
  • Jitter
    • リトライ間隔にランダムな揺らぎを加えることで、同時リトライを防ぐ。

AIエージェントを利用する場合でも「処理を適切な単位で分割・委譲する」という設計の基本が大切なことを再認識しました。

まとめ

今回のAWS Summit Japan 2026を通じて、AI活用を前提にした開発・運用のあり方を改めて考える機会になりました。

生成AIは単なる開発支援ツールではなく、開発プロセス、組織文化、評価制度、ガバナンス、コスト管理まで含めて向き合うべきテーマになっていると感じました。一方で、AIエージェントのような非決定的な仕組みを安全に扱うためには、Human in the Loopや決定論的なワークフローによる制御など、従来から大切にされてきた設計原則も引き続き重要です。また、S3やVPCといった基盤領域についても、サービスの進化に合わせて継続的に設計や設定を見直す必要性を再認識しました。

今回得た学びを、日々の開発・運用だけでなく、社内でのAI活用推進にも活かしていきたいと思います。

ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com

カテゴリー