こんにちは、柴垣です！
先日参加した AWS Summit Japan 2026 では、2日間で数多くのセッションが開催されていました。
その中から、特に面白かった・学びが多かったセッションを3つ選んで紹介します。
「運用 → セキュリティ → 開発」という流れで、AWS を使ったシステムに関わる方なら誰かしらに刺さる構成になっているはずです。
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 化してみる、そんなスモールスタートが現実的な第一歩だと思います。
AI エージェントを本番導入する際に必ずぶつかる「ID とアクセス管理」を扱ったセッションです。
エージェントはユーザーの代理で CRM や財務システムにアクセスする存在であるため、
①権限を安全に委任できるか（セキュリティ）、
②アクセスのたびに同意を求められる「同意疲れ」（UX）、
③各サービスとの認証連携を独自実装するコスト（開発速度）という3つの課題が生じます。
これらをマネージドで解決するのが Amazon Bedrock AgentCore Identity という位置づけでした。
認証認可を2方向に整理しているのが特徴です。
両者をつなぐワークロードアクセストークン（WAT）により「誰が・どのエージェント経由か」を追跡でき、ユーザーの OAuth トークンはトークンボールトに安全に保管して同意疲れを解消します。
CloudTrail 統合による監査や、AgentCore Policy による「500ドル未満の返金処理だけ許可」のようなきめ細かいツール認可も可能です。
エージェント活用の話題はどうしても「何ができるか」に寄りがちですが、本番導入で最初に止まるのは実はこの認証認可の設計だと感じました。
「エージェントに社内システムのパスワードをそのまま持たせるわけにはいかない」この当たり前の壁に、AWS がマネージドサービスとして正面から答えを出してきたという印象です。
既存の ID 基盤（Entra ID や Cognito）をそのまま活かせる点は、これからエージェント導入を検討されるお客様にとって大きなポイントだと思います。
認証基盤を作り直すことなく、最小限のコードでエージェントを安全に組み込める。
エージェント導入の相談をいただく際には、まず「Inbound / Outbound をどう設計するか」から一緒に整理していくのが良さそうです。
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 をシニアエンジニアではなく「アイディア豊富なインターン」として監督すること、まず実験して失敗から学ぶことなどが挙げられ、
最後は「コードの所有者はあなた。コミットログに著者として載るのはあなたの名前」という言葉で締められていました。
「AI を導入したのに思ったほど全体は速くならない」という話は現場でもよく聞きますが、このセッションではそれが体感論ではなく、10〜15%程度の向上にとどまるという調査や、むしろ19%遅くなったという研究データで示されていました。
その原因をツールの性能ではなくプロセス側に求め、SDLC 全体を再設計するというのが AI-DLC のアプローチです。コーディングだけを速くしても、要件定義・レビュー・各種の待ち時間がボトルネックのままなら全体は変わらない、という整理は納得感があります。
また、AI-DLC は全フェーズに人間のレビューと承認のゲートを組み込んでおり、「AI に任せきりにする方法論」ではない点も押さえておきたいところです。
9つの教訓は資料を読むだけでも持ち帰れる実践知で、特にコンテキストウィンドウの管理や、AI を「アイディア豊富なインターン」として監督するという位置づけは、AI 駆動開発に取り組むチームの指針として使いやすいと思います。
Skill Builder コースやワークショップも公開されているので、まずは小規模なプロジェクトで型を試してみるのが現実的な第一歩ではないでしょうか。
3本を通して見えてくるのは、AWS の関心が「AI で何が作れるか」から「AI をどう組織の仕組みに組み込むか」へ完全に移った、ということです。
運用は DevOps Agent が調査を担い（CNS319）、エージェントの権限は AgentCore Identity が管理し（SEC353）、開発プロセス自体は AI-DLC で再設計する（AIM221）。
どれも共通しているのは「AI が実行し、人間が監督する」という役割分担でした。
弊社でも AWS の構築・運用支援の中で、こうした変化をお客様と一緒にキャッチアップしていきたいと思います。
最後まで読んでいただきありがとうございました。