はじめに

みなさん、はじめまして！！2026年3月よりaskenに入社し、プロダクト開発本部でインフラを担当している柳澤と申します。

今回、初めてのブログ執筆ということで先日開催されたAWS Summitに参加してきた所感などをお伝えできればと思います。

私自身はインフラエンジニアとしてのキャリアは10年ほどになりますが、「現地まで行く必要あるの？」の問いに毎回答えることができず、気がつけば、AWS Summit への現地参加は実に5年ぶりとなっていました。

今回はセッション聴講3本と会場全体をぶらり散歩した程度で終えてしまったのですが、その限られた3本のセッションや全体を見渡して改めて感じた「インフラエンジニアとしてできることはなにか？」についてまとめたいと思います。

※ブログを執筆することになるとは思っていなかったので、巷に出回っている記事と比べて写真少なめの慎ましげな雰囲気でお送りします😇

参加してきた3つのセッション

レジリエンスの実践 ― 大規模障害から考える（ARC339）

導入で触れられていたのは、記憶に新しい 2025年10月20日の US-East-1 大規模障害 でした。DynamoDB の DNS が有効な IP を返さなくなり、DynamoDB に依存する数多くの AWS サービスへ影響が連鎖したあの障害です。

「Amazon ストアだけでも Prime Day には毎秒1億5,100万リクエストを処理する」という規模の基盤が止まると何が起きるか、という話から入り、AWS 自身が20年かけて障害と向き合う中で築いてきたプロセスと原則が語られました。

私にとって特に印象的だったのは、次の3点です。（いずれも登壇資料に記載があります（ほかのセッションについても同様））

障害対応は3フェーズで回す：検出と軽減 → 振り返りと計画（COE：Correction of Error を含む）→ 学習とスケーリング。なかでも根本原因分析の Five Whys について、「5回で止めない」「直線的に掘らず、問いを分岐させる」という指摘は、原因を単一に決めつけがちな自分への戒めとして響きました。
障害から生まれた4つの可用性原則（Availability Axioms）：以下の4原則が、AWS 内部の実装例とセットで紹介されました。

原則	ひとことで言うと	代表的な機能・仕組み
リージョンの分離	影響範囲をリージョン内に閉じ込める	STS のリージョナル化
AZ 障害への自動対応	異常な AZ から自動で退避する	Zonal Shift / Zonal AutoShift
厳密なテスト	本番同等の環境で壊して試す	専用テストリージョン / Game Day
過負荷からの保護	リトライの積み上げによる回復不能を防ぐ	準安定障害（Metastable Failure）の分析

9分で2,000アプリを切り替えた実例：金融サービス企業 Fidelity が、前述の US-East-1 障害の際に、障害検知から9分でおよそ2,000のアプリケーションをマルチリージョンでフェイルオーバーさせた事例が紹介されました。これを支えるのが AWS Fault Injection Service（障害注入によるレジリエンステスト）と、Amazon Application Recovery Controller の Region switch（マルチリージョン復旧のオーケストレーション）です。「日常的にテストしているからこそ、本番の9分がある」という点が強調されていました。

3本の中で唯一、AI の気配がほとんどないセッションでしたが、内容は最も"実務"に近いものでした。どれだけ上位のアプリケーションが賢くなろうと、土台が止まればすべて倒れます。

特に、登壇者の「過去一週間テストしていないものは、おそらく壊れている」という言葉は、なかなか胸に刺さるものがありました。

堅牢な SaaS データエージェントの設計 ― Amazon Bedrock AgentCore（AIM344）

3本の中で唯一、真正面から「AI エージェント」を扱うセッションでした。テーマは、自然言語での指示を受けて自律的にデータ分析を行う データエージェント を、SaaS のマルチテナント環境でいかに"堅牢に"作るか、です。

まず、素朴に作ったデータエージェントがいかに危ういかがデモで示されます。個人情報（PII）の漏洩、他テナントのデータへの越境、プロンプトインジェクション、LIMIT のない非効率なクエリの実行——。LLM に「WHERE 句でテナントを絞ってほしい」と指示するだけでは、テナント分離は守られないのです。

これに対し、脅威を 4つのレイヤー で捉え、それぞれに防御を仕込むという設計フレームが提示されました（OWASP Top 10 for Agentic Applications を下敷きにしています）。

レイヤー	何を守るか	代表的な対策
LLM 層	入出力のコンテキスト	Bedrock Guardrails / システムプロンプト
呼び出し層	ツール呼び出しの可否・引数	AgentCore Gateway（Cedar Policy ＋ Interceptor）
ツール層	ツール実装の安全性	読み取り専用ロール / 出力からの PII 除外
リソース層	データそのものへのアクセス	RLS（行レベルセキュリティ）/ IAM によるテナント分離

肝は、テナントの識別子（tenant_id）を LLM の推論に委ねず、JWT のクレームから機械的に取り出してリソースまで伝播させる という設計です。そして締めくくりのメッセージが、私にとって今回の Summit で最も響いた一言でした。

LLM は自然な対話と推論を担い、最終的な制御は決定的な仕組みに委ねる。

AI の最前線を扱うセッションの結論が、「肝心なところは AI に任せるな。認可・テナント分離・行レベルセキュリティといった、決定的（deterministic）な仕組みで守れ」だったのです。それはまさに、私たちインフラ／プラットフォームエンジニアが普段から扱っている領域そのものでした。

効果的な脆弱性管理のためのスマート戦略（SEC337）

主役は Amazon Inspector でした。「クラウドの速度に対応した脆弱性管理」をキーワードに、次の3本柱で語られました。

定期スキャンから「継続的」なスキャンへ：パッケージのインストールや新たな CVE の公開などをトリガーに、ニアリアルタイムで脆弱性を検出する。EC2 についてはエージェント（SSM）ベースとエージェントレス（EBS スナップショット利用）を組み合わせた ハイブリッドスキャン で、SSM が入っていないインスタンスの管理漏れも防ぐ。
リスクベースでの優先順位付け：単純な CVSS スコアではなく、ネットワークの露出状況や既知の攻撃コードの有無といった環境要因まで加味した Inspector リスクスコアで、対応すべき脆弱性を絞り込む。
シフトレフト（Code Security）：SCA（依存関係の解析）・SAST（コードの静的解析）・IaC（構成の解析）のスキャンを開発の早い段階に組み込む。Pull Request をトリガーにスキャンし、結果を GitHub 上で確認できる。しかも 生成 AI が修正案まで自動で提示する。

印象的だったのは、「Log4j の脆弱性が広く知られた後も、Log4j を利用するアプリの約30%が脆弱なバージョンのライブラリを使い続けていた」というデータです。

このセッションにも、修正案の生成という形でしっかり生成 AI が顔を出していました。ただ本質は、「開発の速度を落とさずに、いかにガードレールを敷くか」という運用設計の話です。セキュリティ側がガードレールを用意し、開発者はその内側で自由に動く——という統制モデルは、インフラ／プラットフォームを預かる立場として大いに共感できるものでした。

会場全体で感じた"AI一色"

3本のセッションの合間に会場を歩いて感じたのは、とにかく どこを向いても生成AI・エージェントの単語が目に入ってきたことでした。

中でも AWS 自身の推しとして強く感じたのが、Kiro（仕様駆動開発の IDE・CLI）でした。私自身、以前は Amazon Q Developer を使っていたのですが、Kiro はあまり触れていませんでした。Q Developer の後継的な位置づけの Kiro CLI はともかく、IDE の方はほとんど未経験だったので、機会があれば触っていきたいと思います。

なお、会場ではKiroのキャラクター（かわいい）のLINEスタンプを無料配布していたので、これはすかさずGETしました。

おまけ

ここからは参加が久々すぎてしくじったことや、次回参加するときに気をつけたいことを徒然なるままに書き連ねていきます。

セッションはレシーバーで聞きましょう

席に着き、なにやら前の方で登壇者が話していそうな雰囲気はあるものの、一向に音が聞こえず完全に困惑していましたが、自分の座っている前の席にあるレシーバーと入場口で配られるイヤホンで登壇者の声を聴くサイレントセッション形式になっていることに5分ほど経ってようやく気づきました。

もし、今後初めて参加される方がいたら気をつけてください。

セッションの資料は後ほど共有されるので、がんばって写真を撮らなくても大丈夫

おそらく今回だけではないかと思いますが、基本的にセッションの資料は別途公開されます。（https://pages.awscloud.com/AWS-Summit-Japan-2026-Session-Materials-Download.html）

自分を含め会場でもスライドが変わるごとに写真を撮影している方がいましたが、あまりがんばって撮影する必要はなさそうです。

午前のセッション予約がなければ、開場直後を避けるのもあり

参加者数の増加もあってか、開場直後の入場待ち行列はかなり長くなっていたようです。

午前中に参加したいセッションやイベントの予約がない場合は、少し時間をずらして入場すると待ち時間を減らせそうです。

おわりに ― "AIに任せない（られない）部分"をどうハンドリングしていくかが、我々の仕事

私が（半ば無意識に）選んだセッション3本は、どれも「止めない（レジリエンス）」「守る（脆弱性管理）」「堅牢に動かす（データエージェントの設計）」という、守りと運用の話でした。

そして極めつけは、AI の最前線だったはずの AgentCore のセッションが、「最終的な制御は決定的な仕組みに委ねよ」と結論づけていたことです。

AI が自律的に動く領域が広がるほど、その足場——可用性、セキュリティ、認可、テナント分離——が決定的に効いてきます。派手さはないけれど、その"AI に任せてはいけない部分"を設計し、堅牢に保つことこそが私たちインフラエンジニアの仕事なのだと、5年ぶりの Summit はむしろ再確認させてくれました。

もともと「現状の業務に照らし合わせてなにか役立つ情報を持ち帰れそう」ということで選んだセッションでしたが、まずは内容を改めて咀嚼し、Inspectorの運用設計や既存のBedrockリソースと照らし合わせて適切に設計できているか？の確認から実践していけるとよさそうかなという所感を持ちました。（レジリエンスの話はなかなかに壮大&ゴール設定から必要なトピックなので、長期的な目線でロードマップを描くところからになりそうです）