AWS Summit Japan 2026 面白かったセッション3選

#AWS #イベント参加 #GAWS

■ はじめに

こんにちは、柴垣です！

先日参加した AWS Summit Japan 2026 では、2日間で数多くのセッションが開催されていました。

その中から、特に面白かった・学びが多かったセッションを3つ選んで紹介します。

「運用 → セキュリティ → 開発」という流れで、AWS を使ったシステムに関わる方なら誰かしらに刺さる構成になっているはずです。

■ CNS319「AWS DevOps Agent による自律的インシデント対応 −その能力を引き出す設計のベストプラクティス−」

● 概要

AWS DevOps Agent は、障害対応と運用改善に特化した AI エージェントです。

セッションのメッセージは一貫して「調査は AI、判断は人」。

障害対応で最も時間のかかる初動と調査・切り分けを AI に任せ、最終的な判断と実行は人間が担う役割分担です。

デモでは、CloudWatch Alarm をトリガーに Agent が自律的にメトリクス・CloudTrail・ログを並行調査し、複数のテレメトリを相関づけて数分で根本原因（外部IPからのバーストトラフィック）に到達する流れが紹介されました。

調査中もチャットで Agent に質問できます。

● 技術的なポイント

本題は、DevOps Agent の能力を引き出す3つの設計ベストプラクティスです。

1. Agent Space 設計：調査スコープに合わせて論理コンテナを切る。マルチアカウント構成なら依存先アカウントまで1つにまとめ、本番とステージングは分けてノイズを防ぐ。

2. テレメトリの充実：不足すると Agent 自身が「調査ギャップ」として報告してくる。Container / Database / Lambda の各 Insights と OpenTelemetry（ADOT）で観測を積み上げる。

3. ナレッジ共有：既存の Runbook を Skills や Agent Instructions（AGENTS.md）として Agent に教えられる。デモでは根本原因への到達時間が6分32秒→3分38秒とほぼ半減。

このほか、MCP サーバー経由で Zabbix や社内 Wiki など既存の運用資産と連携できる点、KDDI の事例で調査リードタイムが数週間→数日に短縮された点も紹介されました。

● 感じたこと

障害対応のノウハウが特定の人に偏る「属人化」はどの組織でも課題ですが、既存の Runbook をほぼそのまま Agent の Skill として流用できるなら、導入のハードルはかなり低い。

「AI 導入のために新しく何かを整備する」のではなく「今ある手順書がそのまま AI の教材になる」という発想の転換が重要だと感じました。

また、Agent はあくまで調査と提案までで、危険な操作を勝手に実行しない設計になっている点は、お客様に提案する際にも安心材料になります。

まずはステージング環境で Agent Space を1つ作り、既存の手順書を Skill 化してみる、そんなスモールスタートが現実的な第一歩だと思います。

■ SEC353「エージェンティック AI アプリのセキュリティ・UX・開発速度を同時に実現 ─ Amazon Bedrock AgentCore Identity が解決する3つの課題」

SEC353

● 概要

AI エージェントを本番導入する際に必ずぶつかる「ID とアクセス管理」を扱ったセッションです。

エージェントはユーザーの代理で CRM や財務システムにアクセスする存在であるため、

①権限を安全に委任できるか（セキュリティ）、

②アクセスのたびに同意を求められる「同意疲れ」（UX）、

③各サービスとの認証連携を独自実装するコスト（開発速度）という3つの課題が生じます。

これらをマネージドで解決するのが Amazon Bedrock AgentCore Identity という位置づけでした。

● 技術的なポイント

認証認可を2方向に整理しているのが特徴です。

Inbound Auth：「このユーザーは誰か？エージェントを呼び出す権限があるか？」を検証する入口側。IAM SigV4 と JWT の2方式で、Okta / Entra ID / Cognito など既存 IdP をそのまま使えます。
Outbound Auth：「エージェントがユーザーに代わってリソースへアクセスする権限があるか？」を検証する出口側。IAM に加え、3LO / On-Behalf-Of / 2LO / API Key といった OAuth のアクセスパターンに対応します。

両者をつなぐワークロードアクセストークン（WAT）により「誰が・どのエージェント経由か」を追跡でき、ユーザーの OAuth トークンはトークンボールトに安全に保管して同意疲れを解消します。

CloudTrail 統合による監査や、AgentCore Policy による「500ドル未満の返金処理だけ許可」のようなきめ細かいツール認可も可能です。

● 感じたこと

エージェント活用の話題はどうしても「何ができるか」に寄りがちですが、本番導入で最初に止まるのは実はこの認証認可の設計だと感じました。

「エージェントに社内システムのパスワードをそのまま持たせるわけにはいかない」この当たり前の壁に、AWS がマネージドサービスとして正面から答えを出してきたという印象です。

既存の ID 基盤（Entra ID や Cognito）をそのまま活かせる点は、これからエージェント導入を検討されるお客様にとって大きなポイントだと思います。

認証基盤を作り直すことなく、最小限のコードでエージェントを安全に組み込める。

エージェント導入の相談をいただく際には、まず「Inbound / Outbound をどう設計するか」から一緒に整理していくのが良さそうです。

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

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

● 概要

AWS が打ち出す新しい AI ネイティブな開発方法論「AI-DLC（AI-Driven Development Lifecycle）」の紹介セッションです。

出発点は「AI ソフトウェア生産性のパラドックス」。

AI を導入しても速度向上は10〜15%程度にとどまるという調査（Thoughtworks）に加え、METR の2025年初頭の研究では、経験豊富な開発者が AI を使うとむしろ19%遅くなったという結果も示されています。

原因は現在主流の2アプローチの限界にあります。

AI に任せきる AI-Managed はめったに機能せず信頼も説明もできない。

AI を狭いタスクに使う AI-Assisted は、コーディングで節約した時間が SDLC の他の部分で失われる。

この限界を超える「パラダイム・リープ」を狙い、ツール・ロール・セレモニーを整合させたチームのための方法論が AI-DLC です。

● 技術的なポイント

核となるのは「AI が手を動かし、人が節目でレビューする」オペレーティングモデルです。

人が意図を渡す → AI が計画を作成 → 人がレビュー・承認 → AI が実行 → 人が結果を確認、というサイクルを高速に回します。

ライフサイクルは Inception（ユーザーストーリーで意図を明確化し作業単位で計画）→ Construction（ドメインモデル作成、コードとテストの生成、IaC でデプロイ）→ Operation（本番デプロイ、AI ファーストなインシデント管理）の3フェーズ構成で、各ステップが次のためにより豊かなコンテキストを構築していきます。

人間側の働き方としては、PM・BA・開発・運用・QA が同じ場で AI と要件やコードを具体化する「モブエラボレーション」などが提示されました。

実績も豊富で、Wipro は20時間で本番リリース可能な状態に到達、Dhan は2ヶ月想定の開発を48時間で達成、サイバーエージェントでは開発速度（US Point）が平均+102.9%向上。

AWS 自身の測定でも、12週間と見積もったプロジェクトを品質+30%改善しつつ6週間で完了しています。

後半の「9つの教訓」では、コンテキストウィンドウの慎重な管理、大規模コードベースは要約したリッチなコンテキストを事前構築すること、既存コードを模倣させること、AI をシニアエンジニアではなく「アイディア豊富なインターン」として監督すること、まず実験して失敗から学ぶことなどが挙げられ、

最後は「コードの所有者はあなた。コミットログに著者として載るのはあなたの名前」という言葉で締められていました。