先日リリースされた Microsoft Agent Frameworkについて、弊社では早速これを用いた 2 件の PoC 案件を実施しました。この記事では、これらの案件で得た First Impression を共有いたします！ Microsoft Agent Framework とは？ Microsoft 社が提供する、.NET / Python で単体～マルチエージェントを構築できるフレームワークです。ワークフローの実装、素晴らしい開発者体験をもたらす Dev UI、MCP や A2A への対応、OpenTelemetry 準拠の可観測性を備えるなど、プロトタイプから運用設計ま

G-gen の杉村です。Google Cloud や Google Workspace の、2025年12月に発表されたイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud のアップデート Cloud Run コンソールで GitHub、GitLab、Bitbucket からの継続的デプロイ BigQuery に自動エンベディング生成が登場（Preview） Looker の Explore アクションメニューに Connected Sheets オプション Looker に Self-service Explore 機能が登場（Preview） A2A エージェントが Google Cloud Marketplace で購入可能に（Preview） カスタムエージェント（ADK、A2A、Dialogflow）の権限設定が可能に Dataplex Universal Catalog で自然言語検索が一般公開（GA） Compute Engine に VM Extension Manager が登場（Preview） 動画生成モデル Veo 3.1 で動画の拡張（続きを生成する）機能が Preview 公開 BigQuery remote MCP Server が Preview 公開 Google Cloud 公式 remote MCP Server が複数公開 新サービス「Cloud API Registry」が Preview 公開 Looker Studio Pro で Slack へのスケジュール配信機能が Preview → GA Cloud SQL for SQL Server で Entra ID との統合が可能に（Preview） Security Command Center - AI Protection が Premium tier で使用可能に Vertex AI Agent Engine で Sessions と Memory Bank が一般公開（GA） Cloud SQL で Enhanced backups（拡張バックアップ）が使用可能に BigQuery Data Transfer Service で Oracle からの転送が一般公開（GA） Gemini 3 Flash が Preview 公開 複数データベースサービスで「データエージェント」が Private Preview 開始 AlloyDB for PostgreSQL で Managed connection pooling が一般公開（GA） 古い Gemini モデルの廃止予告 BigQuery DTS で BigLake Iceberg tables へデータ転送が可能に（Preview） BigQuery Data Transfer Service の転送元として SQL Server が追加 GKE の Standard クラスタで Autopilot 機能が利用可能に Gemini Enterprise でノーコードエージェントのスケジュール実行が可能に Vertex AI の Agent Designer で AI エージェントの試験的構築が可能に Google Workspace のアップデート Gmail のメールを Google Chat に共有可能に Flows が Google Workspace Studio として一般公開 Google Meet で組織外ユーザーをライブストリーミングに招待できるように NotebookLM で docx ファイルをソースとして追加可能に Google Chat の URL が変更 Google Chat でメッセージのスケジュール送信が可能に Google Chat で RSS フィードと Atom フィードを購読できるように Google Meet で全画面共有のときもデバイス音声が共有されるように Gemini アプリで Gemini 3 Flash が使用可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud のアップデート Cloud Run コンソールで GitHub、GitLab、Bitbucket からの継続的デプロイ Continuously deploy from a repository (2025-12-01) Cloud Run コンソールに GitHub、GitLab、Bitbucket からの継続的デプロイ設定機能が登場（Preview）。 特定ブランチへの Push をトリガにして Cloud Build が起動して自動的にビルドとデプロイが行われる。 BigQuery に自動エンベディング生成が登場（Preview） Autonomous embedding generation (2025-12-02) BigQuery に自動エンベディング生成が登場（Preview）。 テーブルの特定列をベクトル化した列を生成して常時最新化。セマンティック検索や RAG に利用できる。パイプライン管理の工数やリードタイムが不要になり管理が簡素化できる。 Gemini 3 Pro Image（Nano Banana Pro）による解説画像 Looker の Explore アクションメニューに Connected Sheets オプション Connected Sheets quick link (2025-12-02) Looker の Explore アクションメニューに Connected Sheets オプションが登場（Preview）。 Google スプレッドシートと Looker Explore の接続をクイックにできる。 Looker に Self-service Explore 機能が登場（Preview） Creating self-service Explores (2025-12-03) Looker に Self-service Explore 機能が登場（Preview）。 CSV、XLS、XLSX ファイルをアップロードすると LookML を記述しなくてもクエリ・可視化できる。ユーザー主体の簡易的なデータ可視化・分析がクイックにできるようになる。 A2A エージェントが Google Cloud Marketplace で購入可能に（Preview） Add and manage A2A agents from Google Cloud Marketplace (2025-12-05) Gemini Enterprise で A2A プロトコルを使うエージェントが Google Cloud Marketplace で購入可能に（Preview）。 管理者がマーケットプレイスでエージェントを購入して Gemini Enterprise アプリに追加することで、ユーザーが使用可能になる。 カスタムエージェント（ADK、A2A、Dialogflow）の権限設定が可能に Share custom agents (2025-12-08) Gemini Enterprise でカスタムエージェント（Vertex AI Agent Engine - ADK エージェント、A2A エージェント、Dialogflow エージェント、Google Cloud Marketplace で購入したエージェント）の権限設定が可能になった。 これで、エージェントを使用可能なユーザーを制限できるようになる。ユーザー、グループ、Workforce identity pool、All users に対して権限付与が可能。 Dataplex Universal Catalog で自然言語検索が一般公開（GA） Search for resources in Dataplex Universal Catalog (2025-12-08) Dataplex Universal Catalog（旧 Dataplex Catalog）で自然言語検索が Preview → 一般公開（GA）。 BigQueryやCloud Storageなどのアセットを自然言語でセマンティック検索できる。通常のキーワード検索と切り替えて使用可能。 Compute Engine に VM Extension Manager が登場（Preview） About VM Extension Manager (2025-12-08) Compute Engine に VM Extension Manager が登場（Preview）。 Ops Agent 等の VM 用エージェントをログイン不要で一括インストール。ポリシー定義により条件に一致した VM 群にのみ適用できる。 動画生成モデル Veo 3.1 で動画の拡張（続きを生成する）機能が Preview 公開 Extend Veo on Vertex AI-generated videos (2025-12-08) 動画生成モデル Veo 3.1 で動画の拡張（続きを生成する）機能が Preview 公開。 動画の最後のフレームをもとに1〜30秒の続きを生成できる。 BigQuery remote MCP Server が Preview 公開 Use the BigQuery remote MCP server (2025-12-10) BigQuery remote MCP Server が Preview 公開。 AI を介してデータの読み書きが自然言語で実行できる。Google がホストして HTTPS エンドポイントとして公開するリモート MCP server なので、ローカルへのセットアップが不要。 BigQuery remote MCP Server Google Cloud 公式 remote MCP Server が複数公開 Announcing Model Context Protocol (MCP) support for Google services (2025-12-11) BigQuery 以外にも、以下の remote MCP server が公開された。 Google Maps : Google Maps に対するグラウンディング Google Compute Engine : 運用自動化 Google Kubernetes Engine : 運用自動化 さらに関連して、Apigee が remote MCP server サポートを開始。既存 API を MCP server としてホストできる。 参考 : Announcing MCP support in Apigee: Turn existing APIs into secure and governed agentic tools 新サービス「Cloud API Registry」が Preview 公開 Cloud API Registry overview (2025-12-10) Google Cloud が新サービス「Cloud API Registry」を Preview 公開。組織内で MCP server を管理・検索しやすくするための中央レジストリ。以下の MCP server を管理、監視、検索できる。 Google Cloud 公式の Remote MCP server（BigQuery等） Apigee API hub で公開される組織の独自 MCP server Cloud API Registry Looker Studio Pro で Slack へのスケジュール配信機能が Preview → GA Share and schedule reports with Slack (2025-12-11) Looker Studio Pro で Slack へのレポート共有のスケジュール送信機能が Preview → GA。 Looker Studio Pro ではこういった生成 AI 機能のほか、様々なレポート管理機能や自然言語でのデータソースへのクエリ機能などが $9/user/月で利用可能。 blog.g-gen.co.jp Cloud SQL for SQL Server で Entra ID との統合が可能に（Preview） Integration with Microsoft Entra ID (2025-12-11) Cloud SQL for SQL Server で Microsoft Entra ID との統合が可能に（Preview）。 アプリケーションから SQL Server に Entra ID の認証情報で認証できる。ユーザー管理・ID・パスワードが不要になる。Cloud SQLからEntra IDのパブリック認証エンドポイントに通信。 Security Command Center - AI Protection が Premium tier で使用可能に AI Protection overview (2025-12-12) Security Command Center - AI Protection が Premium tier で使用可能になった（Preview）。Google Cloud 組織内の生成 AI ワークロードの可視化と脅威検知。 Enterprise（最上位）ティア : Preview → 一般公開（GA） Premium ティア : 使用不可 → Preview Vertex AI Agent Engine で Sessions と Memory Bank が一般公開（GA） Vertex AI release notes - December 16, 2025 (2025-12-16) フルマネージドなAIエージェントプラットフォーム Vertex AI Agent Engine で、Sessions 機能と Memory Bank 機能が Preview → 一般公開（GA）。ユーザーとエージェントの間の履歴を保持してパーソナライズや履歴管理。 Sessions : セッション履歴管理 Memory Bank : 長期メモリ Cloud SQL で Enhanced backups（拡張バックアップ）が使用可能に Choose your backup option - Enhanced backups (2025-12-16) Cloud SQL で Enhanced backups（拡張バックアップ）が使用可能に。 Backup and DR サービスを使って中央プロジェクトにバックアップを保持。バックアップボールトに最大10年間、保持可能。 BigQuery Data Transfer Service で Oracle からの転送が一般公開（GA） Load Oracle data into BigQuery (2025-12-16) BigQuery Data Transfer Service で Oracle からのデータ転送が Preview → 一般公開（GA）。 Oracle データベースから BigQuery へのデータ転送がフルマネージドで可能。ネットワークアタッチメント経由でプライベート接続も実現できる。 Gemini 3 Flash が Preview 公開 Gemini 3 Flash: frontier intelligence built for speed (2025-12-17) Gemini 3 Flash が登場（Preview）。Gemini 3 Pro よりも軽量、低コスト、低遅延。 以下で利用可能。 API 経由 Vertex AI Google AI Studio Gemini CLI Google Antigravity アプリ経由 Gemini アプリ Gemini Enterprise 複数データベースサービスで「データエージェント」が Private Preview 開始 Data agents overview (2025-12-17) Google Cloud の 複数データベースサービスで「データエージェント」が Private Preview 開始。使用には申請が必要。 アプリから所定の JSON 形式で自然言語による質問を投入すると、DB 側で SQL が自動生成されて結果を返答。Cloud SQL（for PostgreSQL/MySQL）、AlloyDB、Spanner で使用可能。 データエージェント AlloyDB for PostgreSQL で Managed connection pooling が一般公開（GA） AlloyDB for PostgreSQL で Managed connection pooling が Preview から一般公開（GA）に。 データベースクライアントとのコネクションがプールの中から動的に割り当てられ、リソース効率とレイテンシが最適化。 Managed connection pooling（AlloyDB for PostgreSQL） 古い Gemini モデルの廃止予告 Model versions and lifecycle (2025-12-18) 以下のモデルは、廃止期限が近づいている。 gemini-2.0-flash-001 : 2026-03-03 に廃止 gemini-2.0-flash-lite-001 : 2026-03-03 に廃止 gemini-2.5-flash-preview-09-25 : 2026-01-15 に廃止 これらのモデルは、Gemini 2.5 Flash、Gemini 2.5 Flash Lite、Gemini 3 Flash などへの移行を検討する必要がある。 BigQuery DTS で BigLake Iceberg tables へデータ転送が可能に（Preview） Transfer data into BigLake Iceberg table in BigQuery (2025-12-18) BigQuery Data Transfer Service で Amazon S3、Azure Blob Storage、Cloud Storage からBigLake Iceberg tables へデータ転送が可能に（Preview）。 BigLake Iceberg tables は、標準テーブルと同じく読み書き可能だがデータは Apache Iceberg 形式で Cloud Storage に保存される。 BigQuery Data Transfer Service の転送元として SQL Server が追加 Load Microsoft SQL Server data into BigQuery (2025-12-19) BigQuery Data Transfer Service の転送元として Microsoft SQL Server が追加（Preview）。 オンプレミスやクラウド上の SQL Server から BigQuery へ定期的なデータ転送を自動化。BigQuery Data Transfer Service はフルマネージドでサーバーレス。 GKE の Standard クラスタで Autopilot 機能が利用可能に Run workloads in Autopilot mode in Standard clusters (2025-12-18) Google Kubernetes Engine（GKE）の Standard クラスタで Autopilot 機能が利用可能に。 ComputeClass を使い1つのクラスタ内で柔軟な Standard とマネージドな Autopilot のミックス運用が可能。柔軟な構成とコスト最適化を両立できる。 GKE の Standard クラスタで Autopilot 機能が利用可能 Gemini Enterprise でノーコードエージェントのスケジュール実行が可能に Schedule agent executions (2025-12-19) Gemini Enterprise でノーコードエージェントのスケジュール実行が可能に（Preview）。 月、週、日、時間単位などでノーコードエージェントを自動実行できる。 Vertex AI の Agent Designer で AI エージェントの試験的構築が可能に Agent Designer overview (2025-12-19) Vertex AIで、Agent Designer で AI エージェントを試験的に構築できるように（Preview）。 Get Code を押下すると Python + ADK（Agent Development Kit）のソースコードを取得。AI エージェントの PoC や開発を短縮できる。 Agent Designer 画面 取得されたコード Google Workspace のアップデート Gmail のメールを Google Chat に共有可能に New to Gmail: share emails in Google Chat (2025-12-02) Gmail のメールを Google Chat に共有できるようになった。 メールとチャットを横断したコミュニケーションを円滑にできる。2025年12月2日から15日程度かけて順次リリース。 Flows が Google Workspace Studio として一般公開 Now available: Create AI agents to automate work with Google Workspace Studio (2025-12-03) アルファ版だった Google Workspace Flows が Google Workspace Studio と改名して一般公開。 AI エージェントをノーコードで構築し様々なタスクを自動化できるサービス。Gmail や Google ドライブなどの Google Workspace アプリと統合されているほか、Webhookも利用できる。 Gemini 3 Pro Image（Nano Banana Pro）による解説画像 Google Workspace Studio の機能詳細は以下の記事で解説している。 blog.g-gen.co.jp Google Meet で組織外ユーザーをライブストリーミングに招待できるように Invite external guests to Google Meet live streams or limit access for targeted internal live streaming (2025-12-08) Google Meet で、組織外部のユーザーをライブストリーミングに招待できるようになった。 大規模な一方向配信が可能になる。また組織内部向けでも、参加可能な対象者を特定のユーザーやグループのみに制限できるようになった。 NotebookLM で docx ファイルをソースとして追加可能に Add or discover new sources for your notebook (2025-12-08) NotebookLM で docx ファイル（Microsoft Word ファイル）がソースとして追加可能になった。 Google Workspace バンドル版、Google AI Pro 版で確認。 Google Chat の URL が変更 A new web address for Google Chat (2025-12-11) Google Chat の URL が変更される。 旧 : mail.google.com/chat 新 : chat.google.com これにより、起動時間の短縮が見込まれる。既存 URL も引き続き使用可能だが拡張機能はアップデートが必要な可能性がある。 2025-12-11から順次ロールアウト。 Google Chat でメッセージのスケジュール送信が可能に Schedule messages to be sent at a later time in Google Chat (2025-12-11) Google Chat でメッセージのスケジュール送信が可能に。事前に送信予約日時を指定するとその時刻にメッセージが送信される。Slack 等にもある機能。 2025-12-11から順次ロールアウト。 Google Chat で RSS フィードと Atom フィードを購読できるように Keep your team informed: Introducing the Feeds app for Google Chat (2025-12-17) Google Chat で RSS フィードと Atom フィードを購読できるようになった。 RSS/Atom フィードの更新が Chat スペースに自動投稿される。 Google Meet で全画面共有のときもデバイス音声が共有されるように Share your device’s audio when presenting in Google Meet (2025-12-17) Google Meet で全画面共有のときもデバイス音声（動画の再生時の音声等）が共有されるように。これまでタブ共有にしないと共有されなかった。 Chromeブラウザのみ対応。即時リリース/計画的リリースの設定により機能のロールアウト時期は異なる。 Gemini アプリで Gemini 3 Flash が使用可能に Introducing Gemini 3 Flash for the Gemini app (2025-12-19) Gemini アプリで Gemini 3 Flash が使用可能になった。Gemini アプリでは、モードを3種類から選択可能。 高速モード -> Gemini 3 Flash 思考モード -> Gemini 3 Flash Pro -> Gemini 3 Pro 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

.table-of-contents > li > ul > li > ul { display: none; } .w70p .figure-image img { width:70%; } 12月1日〜12月5日にラスベガスで AWS re:Invent 2025 が開催され、ZOZOのエンジニアが5名参加しました。この記事の前半では熱気に溢れる会場の様子を、後半では面白かったセッションについてご紹介します！ AWS re:inventとは 現地の様子 メイン会場 朝食や昼食 Sports Forum 無料のStarbucks Coffee AWS主催のパーティ セッションレポート Build observable AI agents with Strands, AgentCore, and Datadog (AIM233) AIエージェント運用の課題 Strands AgentsとAgentCore デモ：AWS Newsletter Agent AWS Well-Architected Framework - Generative AI Lens DatadogによるLLM Observability まとめ SEC320-R: The AWS Security Incident Response Challenge: Defend the Cake! ストーリー設定：Unicorn Cake Companyを守れ！ インシデント対応のアプローチ（NIST SP 800-61 Rev.3） 環境のアーキテクチャ CISOからの指示 取り組んだセキュリティ課題 1. アクセス制御の強化 2. クラウンジュエル（秘密のレシピ）の保護 3. 検出と警告の設定 4. ウェブサイトの保護 攻撃者の手口：知っておくべき統計 IAM設定の問題点 Shift Left：開発段階からのセキュリティ AWS CIRT リソース Workshopの様子 まとめ Accelerate platform engineering on Amazon EKS (CNS301-R1) Workshopの概要 プラットフォーム基盤構築 生成AIを活用したプラットフォームエンジニアリング Progressive Deliveryの実践 感想 Using Amazon Q to Cost Optimize Your Containerized Workloads (CMP348) Workshopの概要 Amazon Qによる移行分析 負荷試験でGravitonへの移行の効果測定 段階的な移行アーキテクチャ Phase 1: 移行用のGraviton NodePoolを用意し、pilot環境での移行検証 Phase 2: capacity-spreadの導入 Phase 3: トラフィック分散 感想 Infrastructure Innovations (KEY004) 講演のはじめに 主なアップデート #1 Graviton5 主なアップデート #2 Lambda Managed Instances 主なアップデート #3 Vectors ゲストセッション 講演を通じて感じたこと おまけ Advanced AWS Network Security : Building Scalable Production Defenses [REPEAT] (SEC303-R1) 主な内容 AWS Network Firewallとは Route 53 Resolver DNS Firewallとは Labのアーキテクチャ図 AWS Network Firewallでの通信制御 DNS Firewallでの通信制御 Workshopまとめ The Kiro coding challenge (DVT317) Workshopの概要 実践 まとめ Ditch your old SRE playbook: AI SRE for root cause in minutes (sponsored by Resolve AI) (AIM260-S) 概要 内容 ソフトウェアエンジニアリングの進化 AI for prod Resolve AIの3つの重要な特徴 AIエージェント構築のアプローチ比較 感想 [NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agent [REPEAT] (DVT337-R1) AWS DevOps Agentができること - AWS上のリソースの可視化 AWS DevOps Agentができること - 障害調査 実際の使い所 おわりに AWS re:inventとは re:Invent はAmazon Web Services（AWS）が主催するAWS最大のカンファレンスです。このイベントでは、AWSが提供する様々なクラウドサービスに関する新サービスやアップデートが発表されます。 2025年は世界中から約60,000人以上が、日本から昨年と同程度がラスベガスに集まりました。今年のre:Inventでは、「 AIアシスタントからAIエージェントへ 」という転換点を象徴するイベントでした。 現地の様子 メイン会場 The Venetian Resort Las Vegasがメインの会場となっており、KeynoteやEXPO、Swag（ノベルティ）など様々なコンテンツがここに集合しています。そんな会場で出会った様々なコンテンツをご紹介いたします！ メイン会場では、AWS re:Invent会場への入口案内があり、この時点ですでに私たちはテンションがとても上がっていました。周りの参加者からも笑い声や笑顔で写真を撮る人も多くとてもよい空間となっていました。 エントランスの様子 メイン会場に入ると、大きな黒板がありチョークで好きなように描けました。たくさんの参加者がここで社名を書き記念撮影を行なっていました。イベントが行われる5日間このブースもとても盛り上がっていました。 メイン会場にある大きな黒板 ZOZOTOWNの名を記しました！ メイン会場で特に盛り上がっていたブースはKiroのお化け屋敷でした。筆者もお化け屋敷に入りました！　コーディングによるバグやエラーなどがホラー演出として現れ、それをKiroが救ってくれるといった内容だったと思います。このお化け屋敷を抜けた後に、記念写真をとってもらい、さらにKiroのSwagもいただきました！ Kiroのお化け屋敷 メイン会場にはAWSの公式グッズが売っているショップもありました！　シャツやパーカー、リュック、タンブラーなど様々な商品が売っておりどれも魅力的でした！　来年参加される方はぜひ立ち寄ってみてください！ AWS公式ショップ「AWS Merch Store」 メイン会場には2日目から世界的な企業がブースを構えているEXPOエリアがオープンします！ EXPOエリアの様子 各企業のブースに行って、議論を交わしたりサービスの説明を受けたりしました。 EXPOエリアにある企業ブースの様子 アンケートに答えたりゲームをクリアしたりするとSwagがもらえます。現地参加したメンバーもSwag集めを楽しんでいました！ 特に Resolve.ai さんのブースでは、オリジナルのパーカーに目の前で自分の名前を印字してくださる企画が開催されており、長蛇の列ができていました！ 長蛇の列ができていたResolve.aiさんのブースの様子 どの企業もブースやSwagに力を入れており、持って帰るのがかなり大変でしたが、様々な企業の話も聞けて楽しかったです！ 現地でいただいた数々のSwagたち！ 朝食や昼食 re:Inventの会期中は、朝食や昼食が各会場で提供されていて、参加者なら無料で食べられます！　ビュッフェ形式なので好きなものを食べられました！ 現地でいただいたビュッフェの様子 さらに、セッション会場の通路で定期的に軽食も提供されます。Workshopなど長めのセッションに参加する時は、軽食やコーヒーを持ち込んで栄養補給しながら臨みました！ セッション会場の通路で定期的に提供される軽食 Sports Forum AWSがスポーツ領域でどのようにクラウドやAIを活用しているか、展示・セッション・体験ブースを通じて体感できるSports ForumというイベントゾーンがCaesars Forum会場で開催されていました！ Caesars Forum 会場で開催されていたSports Forumというイベントゾーン F1からNBAまで様々なスポーツでの技術活用例が展示されており、セッションの合間のリフレッシュにもなり、とても楽しい空間でした。eSportsのRiot Games社も展示しており、ゲームを体験できるスペースも用意されていました。 eSportsのRiot Games社の展示 ゲームを体験できるスペース 無料のStarbucks Coffee re:Invent参加者には、会場であるVenetian内のスターバックスでドリンクとフード、合わせて4点までが無料で提供されます！　朝8:30くらいに行った際は30分ほど並んだので、時間に余裕のある方はぜひお立ち寄りください！ re:Invent参加者には、Venetian内のStarbucks Coffeeでドリンクとフードが無料で提供される AWS主催のパーティ APJ Kick Off Partyとre:Play会場内の様子 初日（12/1）は、「 APJ Kick Off Party 」に行ってきました。本イベントはアジア太平洋地域と日本からre:Inventに参加する方向けのAWS公式のネットワーキングイベントです。ラスベガスのナイトクラブで行われます。今年の出演はマーク・ロンソンさんでした。ブルーノ・マーズさんとの「Uptown Funk」など、大ヒット曲を生み出しています。 また、最終日前日、12/4には「 re:Play 」というパーティーが行われました。これはre:Inventのフィナーレのようなもので、大きな広場を使い行われました。日付が変わるまでパーティーでした。最後を締め括ったのはDJのKASKADEさんで、会場は大盛り上がりでした！ セッションレポート ここからはre:Inventの参加メンバーが気になったセッションを紹介します。 Build observable AI agents with Strands, AgentCore, and Datadog (AIM233) SRE部 カート決済SREブロックの小松です。ZOZOTOWNのカート決済機能のリプレイス・運用・保守に携わっています。また、全社のAWS管理者としての役割も担っています。 今回は興味を持っていたサービスの1つであるStrands AgentsとAmazon Bedrock AgentCoreについて、AIエージェントの本番運用に向けたObservability（可観測性）の観点から紹介されたセッションに参加しました。 DatadogのSr. Technical AdvocateであるKunal Batra氏と、AWSのSr. Developer AdvocateであるDu'An Lightfoot氏による共同セッションで、その内容について簡単ではありますがご紹介します。 AIM233 セッションの様子 AIエージェント運用の課題 セッション冒頭では、AIエージェントをスケールで運用する際の課題が紹介されました。 AIエージェント運用の課題 Hallucinations & Quality : LLMが不正確な情報を生成する可能性があり、継続的な評価と修正が必要 Complexity : エージェントは複合システムであり、内部の動作が見えないとトラブルシューティングが困難 LLM Costs : 本番ワークロードではコストが容易に膨らむ Security & Safety : プロンプトインジェクションやデータ漏洩のリスク 特に印象的だったのは、エージェントが「非決定的（non-deterministic）」であるという点です。同じ入力でも異なる出力を返す可能性があり、従来のソフトウェアとは異なるアプローチでの監視が必要になります。 印象的だったエージェントが「非決定的（non-deterministic）」であるという点 Strands AgentsとAgentCore 続いて、AWSが提供する、エージェント構築・運用ツールが紹介されました。 Strands Agents は、わずか数行のコードでエージェントを構築できるオープンソースのPython SDKです。モデルに依存せず、MCPやA2Aプロトコルもサポートしています。 Strands Agents Amazon Bedrock AgentCore は、エージェントを本番環境にデプロイするための包括的なプラットフォームです。 Amazon Bedrock AgentCore AgentCoreは以下のコンポーネントを提供します。 Runtime : エージェントのホスティング環境。DockerfileまたはCode-zipでデプロイ可能 Memory : 短期記憶（チャット履歴、セッション状態）と長期記憶（セマンティック、ユーザー設定、エピソディック） Observability : OpenTelemetry（OTEL）ベースのテレメトリ収集 Identity/Policy/Gateway : セキュリティとアクセス制御 デモ：AWS Newsletter Agent セッションではAWS Newsletter Agentを使ったデモが行われました。このエージェントはAWSの最新ニュースを取得し、AIに関連するアップデートをフィルタリングしてニュースレターとして配信します。 AWS Newsletter Agentのデモ デモでは、以下のような流れが紹介されました。 ユーザーが「What's new in AWS today?」と質問 エージェントが current_time と fetch_aws_news ツールを実行 AI/MLに関連するニュースを抽出してサマリーを生成 ニュースレターをメールで送信 デモの流れ さらに、エージェントが自然言語の指示だけでEventBridgeのスケジュールを作成し、毎日自動でニュースレターを配信する設定まで行っていました。 AWS Well-Architected Framework - Generative AI Lens セッションでは、AWS Well-Architected Frameworkに Generative AI Lens が2025年に追加されたことも紹介されました。 AWS Well-Architected FrameworkにGenerative AI Lens 6つの柱それぞれにAIエージェント向けのベストプラクティスが定義されています。 Operational Excellence : 包括的なObservabilityの実装 Security : 安全で責任あるアウトプットのためのGuardrails Cost Optimization : 長時間実行ワークフローにおける停止条件の設定 DatadogによるLLM Observability セッション後半では、Datadogを使ったAIエージェントの監視デモが行われました。 Datadogを使ったAIエージェントの監視デモ Datadogの LLM Observability では、以下のような情報を一元的に確認できます。 Summary : エラーレート、LLM呼び出し回数、トークン使用量の概要。 Evaluations : エージェントの応答品質を評価。「Failure to Answer」の割合や、カスタム評価（Financial Advisory Compliance Checkなど）の結果を確認できる。 Cost : トークン使用量とコストの推移。最もコストがかかっているモデル呼び出しを特定できる。 Traces : エージェントの処理フローを詳細に追跡。特に印象的だったのは、マルチエージェント構成（Budget Guru → Triage Agent → Prompt Injection Agent → PII Detection Agent）の各ステップが可視化されている点。 Security & Safety : プロンプトインジェクション、出力の有害性（Toxicity）、PII（個人情報）の検出状況を監視できる。 Experiments : 異なるモデルやプロンプトを比較して、品質・コスト・レイテンシのトレードオフを分析できる。Claude Haiku 4.5など複数モデルが比較されていた。 まとめ AIエージェントを本番運用する上で、従来のアプリケーション監視とは異なる観点が必要だと実感しました。特に以下の点が印象に残っています。 非決定性への対応 : 同じ入力でも出力が変わるため、品質評価の自動化が重要 コスト可視化 : トークン単位でのコスト追跡により、予期せぬコスト増加を早期に検知 セキュリティ監視 : プロンプトインジェクションやPII漏洩のリアルタイム検出 マルチエージェントのトレース : 複数エージェントが連携する場合、処理フローの可視化が不可欠 弊社でもAIエージェントの活用を進めていますが、本番運用に向けてはObservabilityの整備が重要な課題になりそうです。StrandsとAgentCore、そしてDatadogの組み合わせは、その解決策の1つとして検討していきたいと思います。 SEC320-R: The AWS Security Incident Response Challenge: Defend the Cake! このWorkshopは、架空の企業「Unicorn Cake Company」のセキュリティチームとして、攻撃者（Grumpy Cats）から秘密のレシピを守るという、ゲーム形式で楽しみながらセキュリティインシデント対応を学べる内容でした。 SEC320-R Workshopの様子 このWorkshopでは、Blue Teamとして、AWS Lambdaで実装されたRed Teamの攻撃を防御するシナリオをシミュレートします。30分の準備期間の後、攻撃が開始され、リアルタイムで対応していく形式です。 Workshopの概要 画像引用元: Workshop参加者向けに用意されたページの画面をスクリーンショット ストーリー設定：Unicorn Cake Companyを守れ！ 参加者は「Unicorn Cake Company」という架空のケーキ製造会社のクラウドセキュリティチームとして参加します。この会社はユニコーン向けの魔法のケーキを製造しており、その秘密のレシピ「UnicornCakesSecretRecipe.txt」が攻撃者に狙われています。 攻撃者は「Grumpy Cats（気難しい猫たち）」と呼ばれる集団で、レシピを盗むか、盗めなければ破壊しようとしています。 インシデント対応のアプローチ（NIST SP 800-61 Rev.3） Workshopでは、 NIST SP 800-61 Rev.3 に基づいたインシデント対応のフレームワークが紹介されました。 インシデント対応のフレームワーク Preparation（準備） : インシデント対応能力の確立、ツールの準備、スタッフの訓練 Detection & Analysis（検出と分析） : 脅威の検出と影響範囲の分析 Containment, Eradication & Recovery（封じ込め、根絶、復旧） : 被害の拡大防止と復旧 Post-Incident Activity（事後活動） : 振り返りと改善 Incident Response 特に印象的だったのは「 Incident Response is a TEAM SPORT! 」というメッセージです。セキュリティインシデント対応は一人で行うものではなく、チーム全体で取り組むべきものだという点が強調されていました。 特に印象的だった「Incident Response is a TEAM SPORT!」というメッセージ 環境のアーキテクチャ Workshopの環境は単一リージョン（us-east-1）で構成されており、以下のコンポーネントで構成されています。 環境のアーキテクチャ図 画像引用元: Workshop参加者向けに用意されたページの画面をスクリーンショット 主要コンポーネント CloudFront Distribution → Lambda (Competition Upload) → S3 (Competition Uploads) VPC内 Unicorn Cake Company Website → S3 (Unicorn Production Bucket) WorkshopHints （本番環境外、ヒント用） Unicorn Logging （ログ保存用） 組織構造 25人のユーザーが5つのチームに分かれている 営業、HR、開発、食品工学、レストラン経営者 全員がアクセスキーと管理者権限を持っている （これがセキュリティ的にヤバい設定） 全員がアクセスキーと管理者権限を持っている設定！ 画像引用元: Workshop参加者向けに用意されたページの画面をスクリーンショット CISOからの指示 Workshopでは、CISO（Rainbow Sparkles氏）からの緊急ブリーフィングという形で、取り組むべき課題が提示されます。 CISOからの指示 画像引用元: Workshop参加者向けに用意されたページの画面をスクリーンショット 最重要ルール：「生産を停止してはいけません」 ユニコーンたちのために魔法のケーキを作り続けなければならないという制約の中で、セキュリティを強化する必要があります。これは実際の本番環境でも同様で、セキュリティ対策のために事業を止めることはできないという現実的な制約を体験できます。 取り組んだセキュリティ課題 CISOから提示された課題は大きく4つのカテゴリに分かれていました。 1. アクセス制御の強化 MFAの有効化 : 全ユーザーにMFAを設定（まずは「Unicorn_Cakes_Sales_1」で実演） IAM認証情報レポートのダウンロード : 現状の把握 2. クラウンジュエル（秘密のレシピ）の保護 削除・ダウンロードの追跡 : 誰がレシピにアクセスしたかを特定できるようにする 改ざん検知 : レシピが変更されていないことを確認する方法 不変ストレージ : S3 Object Lockを使用して、管理者でも削除できないようにする 多層防御 : S3バケットポリシーでAWSアカウント内からのみアクセス可能にする 3. 検出と警告の設定 Amazon GuardDutyの有効化 : 24時間365日の脅威検知 即時アラートの設定 : EventBridgeを使用してレシピへのアクセスをリアルタイムで通知 CloudTrailの設定確認 : ログが正しく収集されているかの確認 4. ウェブサイトの保護 可用性の維持 : ウェブサイトが継続して動作することを確保 復旧手順の確立 : 万が一破損した場合の復旧方法 攻撃者の手口：知っておくべき統計 Workshopでは、実際の攻撃者がどのような方法で初期アクセスを獲得するかという統計も紹介されました。 実際の攻撃者がどのような方法で初期アクセスを獲得するかという統計 66% : 有効なIAM認証情報を使用（うち約1/3がroot認証情報） 13% : 公開されたEC2インスタンス経由 この統計からも、IAM認証情報の管理がいかに重要かがわかります。 IAM設定の問題点 Workshopの環境には、意図的にセキュリティ上の問題が含まれていました。 IAM設定の問題点 Long-term Security Credentials : 長期間有効なアクセスキーの使用 MFA未設定 : MFAトークンが設定されていない（×マーク） 過剰な権限 : 全ユーザーがInline Policyで管理者権限を持っている また、「Overprivileged website」として、EC2インスタンスがIMDSv1を使用して過剰な権限を持つIAMロールがアタッチされているという、典型的な攻撃対象となる構成も紹介されました。 典型的な攻撃対象となる構成 Shift Left：開発段階からのセキュリティ Workshopの最後には、「Shift security left in your development flow」というメッセージとともに、 Kiro が紹介されました。 Shift security left in your development flow 開発段階からApplication Security Testingを導入することで、本番環境に脆弱性を持ち込まないようにするアプローチです。 AWS CIRT リソース セッションの最後には、AWS CIRT（Customer Incident Response Team）が提供する、有用なリンク集がQRコードで共有されました。インシデント対応についてさらに学びたい方は、こちらのリソースも参考になります。 builder.aws.com Workshopの様子 会場では多くの参加者がチームごとに分かれて、リアルタイムで攻撃に対応していました。スコアボードには各チームのポイントが表示され、競争形式で楽しみながら学べる環境でした。 まとめ このWorkshopを通じて、以下の点が特に印象に残りました。 セキュリティと事業継続のバランス :「生産を停止してはいけない」という制約の中でセキュリティを強化する経験は、実際の本番環境でも直面する課題そのものでした。 多層防御の重要性 : IAMポリシー、S3バケットポリシー、MFA、GuardDuty、CloudTrailなど、複数のレイヤーで防御することの重要性を実感しました。 検知と対応の速度 : 攻撃はいつ来るかわかりません。GuardDutyやEventBridgeを使ったリアルタイム検知の仕組みが、早期対応には不可欠。 チームワーク : 「Incident Response is a TEAM SPORT!」というメッセージ通り、一人ではなくチームで対応することの重要性を学びました。 弊社でもAWS環境のセキュリティ強化を進めていますが、このWorkshopで学んだ実践的な知識を活かして、より堅牢なセキュリティ体制を構築していきたいと思います。 Accelerate platform engineering on Amazon EKS (CNS301-R1) SRE部 プラットフォームSREブロックのさかべっちです！　普段はZOZOTOWNのマイクロサービス基盤をEKSで構築・運用しています。 最先端のプラットフォームエンジニアリングを学ぶため参加してきました！　多くの人が帰国する最終日に開催されたセッションにもかかわらず、予約していない人はほとんど入れていなかったとても人気のセッションでした。 Workshopの概要 BackstageやArgo CDなどの最先端ツールやKiroを駆使して、ハンズオン形式で開発プラットフォームを構築するものでした。Workshopで使用したプラットフォームは、EKS Auto Mode上に構築されており、非常に豪華な構成でした。 ハンズオン形式で開発プラットフォームを構築するWorkshop 主なコンポーネントは以下の通りです。 Backstage：開発者ポータル Argo CD：GitOpsエンジン Argo Workflows：CI/CDワークフロー Argo Rollouts：Progressive Delivery KubeVela：OAM（Open Application Model）ベースのアプリケーション管理 kro：Kubernetes Resource Orchestrator Kargo：環境間のプロモーション管理 Amazon Q：生成AIアシスタント 今年発表されたEKS Capabilitiesについてもここで紹介されました。 発表されたばかりのEKS Capabilitiesについても紹介 Argo CD、ACK（AWS Controllers for Kubernetes）、kroがマネージドで提供されるようになり、運用負荷が大幅に下がりそうです。VPC CNIやFluent BitなどのEKS addonとは別物で、詳しくは下記のbreakout sessionで紹介されているのでご覧ください。 www.youtube.com プラットフォーム基盤構築 Workshopの前半は、Backstageを使ってプラットフォーム基盤を構築していく内容でした。Backstageを使うと、サービスカタログ、API一覧、ドキュメント、CI/CDパイプラインの状態などを一元管理できます。特に感動したのは、テンプレートからCI/CDパイプラインを数クリックで構築できる点です。Application Name、AWS Region、EKS Cluster Nameなどを入力して「CREATE」を押すだけで、GitLabリポジトリの作成からArgo CDの設定まで自動で行ってくれます。 たった数分でGitOpsワークフローの構築が完了する たった数分でGitOpsワークフローの構築が完了しました。GitOpsとは、インフラやアプリケーションの状態をGitで宣言的に管理する手法です。Gitにマニフェストをpushすると、Argo CDが差分を検知して自動でEKSクラスターに反映してくれます。 生成AIを活用したプラットフォームエンジニアリング Kiroをプラットフォームエンジニアリングに活用する方法も紹介されました。Kiroを活用して先ほどのプラットフォーム基盤にアプリケーションをデプロイします。 KiroにRustアプリケーションのDynamoDBテーブルとデプロイマニフェストを作成してもらいました。 Please use the Kubevela OAM component definition ...（中略） as a template and create a new Kubevela OAM component definition with the name of ddb-table using this dynamodb table CRD yaml Create an OAM manifest ...（中略） using Kubevela templates Include in strict order of dependency using dependsOn between components: - DynamoDB table with component-policy trait for permissions - Service account - Rust app (deploy last) - Path based ingress with /rust-app routing KubeVelaを用いたアプリケーションマニフェストが生成されます。KubeVelaを使うと、OAM（Open Application Model）に基づいてマイクロサービスを1つのファイルで定義できます。通常であればDeployment、Service、Ingressなどを個別に書く必要がありますが、KubeVelaのOAMを使えばこれだけでOKです。 apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: rust-application spec: components: - name: rust-webservice type: appmod-service properties: image: <image> image_name: java-app port: 8080 targetPort: 8080 replicas: 2 appPath: "/app" env: - name: APP_ENV value: "DEV" readinessProbe: httpGet: path: /app/ port: 8080 initialDelaySeconds: 10 periodSeconds: 5 timeoutSeconds: 5 resources: requests: cpu: "500m" memory: "256Mi" limits: memory: "512Mi" functionalGate: pause: "20s" image: "httpd:alpine" extraArgs: "red" performanceGate: pause: "10s" image: "httpd:alpine" extraArgs: "160" traits: - type: path-based-ingress properties: domain: "*.elb.us-west-2.amazonaws.com" rewritePath: true http: /app: 8080 また、kro（Kubernetes Resource Orchestrator）を使うと、cicdpipelinesやeksclusterといった新しいカスタムAPIを作成でき、KubernetesとAWSリソースのデプロイをさらにシンプルにできます。上記のコードをGitにpushすると自動でビルド・テスト・デプロイが実行されます。 git pushすると自動でビルド・テスト・デプロイが実行される Progressive Deliveryの実践 Workshopの後半では、Argo Rolloutsを使ったProgressive Deliveryを体験しました。Argo Rolloutsの詳細な設定はプラットフォームエンジニアが担当し、開発者はKubeVelaのコンポーネントを使ってgit pushするだけで段階的デプロイを実現できるようにします。 CI/CDパイプラインと組み合わせると、Progressive Deliveryは以下のようなフローになります。 開発者がGitリポジトリにコードをプッシュ Argo Workflowsがコードをコンパイル、イメージをビルド、ECRにプッシュし、マニフェストのイメージタグを更新 Argo CDがマニフェストの変更を検知し、DEV環境へのデプロイをトリガー Rolloutが新バージョンを20％に展開し、機能テストを実行 40％、60％、80％と段階的に展開し、パフォーマンステストを実行 テスト失敗時は自動で最後の安定バージョンにロールバック 実際にわざとエラーになる変更を入れてテストしてみました。 わざとエラーになる変更を入れてテストする revision:4のAnalysisRunが「Failed」となり、自動でロールバックされています。修正を加えて再度git pushすると、無事Successfulになりました。 修正を入れて再度git pushすると、無事Successfulになる DEV環境へのデプロイが成功した後はPROD環境へのデプロイです。DEVからPRODへの昇格管理にはKargoを使いました。Kargo UIで「Promote」をクリックすると、先ほどDEVでデプロイが成功したイメージを使用して、自動でK8sマニフェストを更新してくれます。 DEVでデプロイが成功したイメージを使用して、自動でK8sマニフェストを更新してくれる DEVで成功したイメージをそのままPRODに適用できるので、環境間の差異による問題を防げます。 さらに、DevOps Research and Assessment (DORA) メトリクスも自動で計測・可視化されます。これにより、チームや組織のソフトウェアデリバリのスピードと品質の改善点を特定できます。 チームや組織のソフトウェアデリバリのスピードと品質の改善点を特定できる 最終的に構築したDevOpsアーキテクチャの全体像は下記の通りです。 最終的に構築したDevOpsアーキテクチャの全体像 感想 Backstageの導入を検討していたのですが、実際に触ってみてCI/CDパイプラインをテンプレート化して開発者に提供できる点が便利であることを実感しました。また、EKS Capabilitiesで今後Argo CDなどがマネージドで提供されるようになると、プラットフォームの構築・運用コストが大幅に下がりそうです。 ただ、弊チームでは現在FluxCDを使ってGitOpsを運用していますが、今回のre:Inventの発表を見る限りArgo CDがかなり推されている印象だったので、中長期的にはArgo CD移行も視野に入れて検討していく必要がありそうです。今後様々なEKSエコシステムのEKS Capabilitiesも使えるようになると嬉しいです！ WorkshopのソースコードはGitHubで公開されているので、興味のある方はぜひ試してみてください！ github.com Using Amazon Q to Cost Optimize Your Containerized Workloads (CMP348) 引き続きさかべっちが参加したWorkshopをご紹介します！　こちらはAmazon Qを活用してEKSワークロードをGravitonに移行し、コスト最適化を行うWorkshopです！　私が入社前のアルバイトをしていた頃に、チーム内でGravitonの移行について話題が上がっていたので、今後移行の予定ができたときのためにキャッチアップしておこうと考えて参加しました！　AWS GravitonはAWSが独自開発したARMベースのプロセッサです。x86インスタンスと比較して最大40％優れたコストパフォーマンスを実現し、さらに最大60％少ないエネルギー消費という特徴があります。 Graviton移行の流れは以下の5ステップです。 Graviton移行の流れ Workshopの概要 サンプルのチャットボットアプリケーション（Java、Python、Go、.NET Coreから選択）をx86からGravitonへ移行する流れを体験しました（自分はGoを選択して進めました）。Amazon QにGraviton移行の専用agentがすでに組み込まれており、Amazon Qに質問しながら移行の分析や実装を進めていくスタイルでした。 Amazon Qによる移行分析 まず、Amazon Qに現状のEKSインフラがGraviton移行可能かを分析してもらいました。 Q. Analyze the EKS infrastructure for Graviton readiness すると、Karpenter NodePoolの設定やアプリケーションマニフェストの問題点、コンテナビルドの準備状況などを詳細に分析してくれます。さらに言語ごとの移行複雑度をスコアリングしてくれるので、どのアプリから移行すべきかの判断材料になりました。 コスト分析もAmazon Qにやってもらいます。 Q. Perform EKS Graviton migration cost analysis for my go app 現在のx86コストとGraviton移行後の予測コストを比較したレポートを作成してくれました。月額約14％の削減、年間では約$600の削減が見込まれるという結果でした。 負荷試験でGravitonへの移行の効果測定 Workshopでは事前に用意されていた負荷試験ツールを実行して、Graviton移行前後のパフォーマンスを比較しました。 Graviton移行前（x86） #[Mean = 2192.524, StdDeviation = 47.983] Requests/sec: 0.45 Amazon Qから言われた通りにGraviton移行で必要な下記の変更を加えてから負荷試験を実施します。 nodepool： kubernetes.io/arch に arm64 を追加 instance-familyを c7g に変更 Graviton移行後 #[Mean = 1593.935, StdDeviation = 57.964] Requests/sec: 0.63 レイテンシが約27％改善、スループットは約40％向上という結果になりました！　Gravitonはコスト最適化のイメージでしたが、パフォーマンスもかなり向上していることを知りました。 段階的な移行アーキテクチャ 本番環境での移行時は、いきなり全てをGravitonに切り替えるのではなく、段階的に進めることが推奨されていました。これにより、問題が発生した場合でも影響範囲を限定できます。 Amazon Qに段階的な移行方法を教えてもらいます。 Q. Can you help me create a migration runbook based on the progressive Graviton migration? 3フェーズ（Dev → Staging → Production）の段階的移行計画、バリデーション基準、ロールバック手順まで含んだ手順を生成してくれます。 また、マイクロサービスごとの移行は下記の手順で実行します。 Phase 1: 移行用のGraviton NodePoolを用意し、pilot環境での移行検証 Phase 1: 移行用のGraviton NodePoolを用意し、pilot環境での移行検証 Phase 2: capacity-spreadの導入 Phase 2: capacity-spreadの導入 Phase 3: トラフィック分散 Phase 3: トラフィック分散 具体的には topologySpreadConstraints を使って、x86とGravitonの両方にPodを分散させながら徐々に移行していく方法です。 topologySpreadConstraints: - labelSelector: matchLabels: app.kubernetes.io/name: goapp maxSkew: 1 topologyKey: capacity-spread whenUnsatisfiable: DoNotSchedule 感想 Graviton移行用のagentを使うと、インフラの分析からコスト試算、実装の提案、段階的な移行まで一貫してサポートしてくれます。Graviton移行の取り掛かりとしてはハードルがかなり下がった印象です。 特に印象的だったのは、負荷テストでパフォーマンスが大幅に向上した点です。Gravitonは「コスト削減」のイメージが強かったのですが、実際にはレイテンシ27％改善・スループット40％向上と、パフォーマンス面でも大きなメリットがあることを体感できました。 弊チームではZOZOTOWNのマイクロサービス基盤をEKSで運用していますが、マイクロサービスごとに使っている言語が異なるため、今回学んだ段階的な移行アプローチは非常に参考になりました。 具体的には、環境ごと（Dev → Stg → Prd）、NodePoolごと（x86とGravitonを併用）に段階リリースしていく方法は、弊チームでも必須になると思います。移行の予定が決まった際はAmazon Qに現状のインフラを分析してもらい、移行の優先度を決めるところから始めてみたいと思います。 Infrastructure Innovations (KEY004) SRE部 基幹プラットフォームSREブロックの若原です。普段はZOZOの倉庫システムやブランド様向けの管理ページなどのサービスのオンプレミスとクラウドの構築・運用に携わっています。 現地時間12/4の朝に行われた、AWS SVPのPeter DeSantis氏とVice President of Compute and Machine Learning ServicesであるDave Brown氏によるKeynoteを聴講してきましたので、この基調講演の概要と印象に残ったポイントをお伝えします。 www.youtube.com 講演のはじめに 講演では、AIがクラウドと開発者コミュニティに何をもたらすのかという問いから始まりました。Peter氏はAIトランスフォーメーションがもたらす未来を語る前に、まず変わらない大切な価値に目を向けるべきだと強調しました。 どれだけ世の中が変化しようとも、AWSが創業以来一貫して大切にしてきたSecurity（セキュリティ）、Availability（可用性）、Elasticity（弾力性）、Cost（コスト）、Agility（俊敏性）の5つのAttributes（特性）は、クラウド基盤の核心であり、AI時代においてさらに重要になると述べていたのが印象的でした。 主なアップデート #1 Graviton5 AWSが自社開発する次世代CPU「Graviton5」が発表されました。高いコア数やキャッシュ性能を備えながら省電力・高性能を両立している点が特徴で、複雑なデータ処理やAIワークロードにも適した設計になっています。 主なアップデート #1 Graviton5 主なアップデート #2 Lambda Managed Instances Lambda関数をEC2インスタンス上で実行可能にする新機能として紹介され、サーバーレスの簡易さを保ちながらEC2の柔軟なインスタンスタイプ選択と割引価格モデルを活用し、柔軟なトラフィックワークロードのコスト最適化と性能制御を可能にすると説明されました。 主なアップデート #2 Lambda Managed Instances 主なアップデート #3 Vectors Amazon S3 Vectorsがネイティブなベクトルデータの保存・検索をサポートするクラウドストレージとして紹介され、生成AIや意味検索（RAG）など大規模AIワークロードのコストを最大90％削減しつつ効率的に処理できる基盤として発表されました。 主なアップデート #3 S3 Vectors ゲストセッション 新機能のアップデート以外にも、AppleのPayam Mirrashidi氏が登壇し、AWS Gravitonを活用してSwiftベースのバックエンドでパフォーマンスとコスト効率を大幅に向上させた事例を紹介しました。また、TwelveLabs社のJae Lee CEOはS3 Vectorsを使って大規模な動画データを効率的にインデックス化・検索するAIシステムの事例を共有し、さらにDecart社のDean Leitersdorf CEOはTrainium3を用いたライブ・ビジュアル・インテリジェンスの実演を披露するなど、大変興味深い内容となりました。 ゲストセッションの様子 講演を通じて感じたこと AWSはAI時代の最前線で先進的なサービス・機能を展開しつつも、クラウドの原点となる価値を創業以来常に大切にしているというメッセージが強く伝わってきました。 今回発表されたGraviton5、Lambda Managed Instances、S3 Vectorsなどは、単に追加された新機能ではなく、基本となる要素であるAgilityやCostといった基本価値をさらに強化するものに感じられました。今後のAWSとクラウドの進化がますます楽しみです。 セッションの様子 おまけ 講演の冒頭で、Peter氏は学部時代に愛読していた「CSの教科書」の第7版が最近刊行され、その中にNitroシステムとGravitonプロセッサに関する新しい章が追加されたことを紹介していました。 これを記念して、会場に投影されたQRコードを読み取った先着1000名に、その最新版の教科書を講演後にExpoホールでプレゼントするというサプライズ企画があり、私も運よく受け取れました。ひとつ想定外だったのは、喜んで受け取ったのは良いものの、この本がほぼ2kgある大著で思いのほか重く、帰りの預け荷物の重量制限が頭をよぎり少しハラハラしてしまいました。無事に持ち帰れたので、これから大切に読ませていただこうと思います。 サプライズ企画で手に入った「CSの教科書」第7版 Advanced AWS Network Security : Building Scalable Production Defenses [REPEAT] (SEC303-R1) AWS環境におけるネットワークセキュリティ強化方法を実践的に学ぶ2時間のWorkshopに参加しました。 最初に講師の方から約30分ほどの座学があり、AWS Network FirewallやDNS Firewallの基礎、今回のLabのアーキテクチャについて解説がありました。その後は用意された環境を使い、参加者が自分の手で設定を進めながら学ぶハンズオン形式で進んでいきます。 SEC303-R1セッションの様子 #1 主な内容 冒頭の座学では、オンプレミス環境のように単一のファイアウォールで全通信を集約するモデルではなく、AWSではユースケースごとに適切な境界を組み合わせて防御する、という設計思想が強調されていました。 本WorkshopではEgress（外向き通信）とEast-West（VPC間通信）に焦点が当てられ、それぞれの通信に対して多層的に検査・制御するセキュリティを構築するという内容でした。 Ingress（内向き通信）ではWAFによるアプリケーションレイヤー保護が主役となる一方、本Workshopで取り扱ったEgressやVPC 間通信ではAWS Network FirewallとRoute 53 Resolver DNS Firewallの2つのサービスが中心的な役割を果たし、それぞれどのように組み合わせて環境を保護すべきかについて学びました。 SEC303-R1セッションの様子 #2 AWS Network Firewallとは AWS上のネットワークトラフィックを保護するためのマネージド型ファイアウォールサービスで、AWS環境のネットワークを総合的に守るためのセキュリティ基盤として利用できるサービスです。侵入防止(IPS)、ステートフル/ステートレスルール、ドメインフィルタリングといった機能を備えており、既存のセキュリティ運用に合わせた詳細なトラフィックの検査が可能です。Suricataというルール形式に対応している点も特徴で、既存のセキュリティ運用で利用している独自ルールやコミュニティルールをそのまま適用できます。 Route 53 Resolver DNS Firewallとは AWS環境内のDNSクエリを保護するためのマネージド型ファイアウォールサービスで、悪性ドメインへのアクセスやDNSを悪用した攻撃をDNSレイヤーで防止するための基盤として利用できます。AWSが提供する脅威ドメインリストや独自のカスタムリストを使ってドメイン単位で通信を制御でき、DNSトンネリングや不正なクエリを早期に検知・遮断できます。VPCのRoute 53 Resolverと統合されており、アプリケーションを変更することなくDNSトラフィックを一元的に監査・制御できるのが特徴です。 Workshop参加者には複数のVPCがTransit Gatewayで接続された環境を渡され、その上でネットワークセキュリティ構築を段階的に体験できる内容となっていました。 Labのアーキテクチャ図 Labのアーキテクチャ図 VPCの内部から外向きの通信状態を確認するテストスクリプトが用意されており、Labの開始時点では、画像のようにあらゆる通信が通ってしまう状態になっています。 Labの開始時点では、あらゆる通信が通ってしまう状態になっている ここからAWS Network FirewallとDNS Firewallを使って、攻撃に悪用されるポイントを1つずつ対策しながらセキュリティを強化していきます。 AWS Network Firewallでの通信制御 ここでは例としてAWS Network FirewallのGeoIP機能を使って、特定の国や米国・カナダ以外への通信をブロックするルールを追加し、地域ベースでの通信制御を実践します。 コンソール上のVPCサービスから、Lab用に用意されているFirewallを選択します。Firewall policy settings→StatefulRuleGroupへ移動し、RulesセクションからEditします。 Edit rulesからルールを追加する USとカナダ以外への通信をブロックするSuricataルール表記を追記してSaveします。 # Block Traffic To/From Any Country Besides the US or Canada drop ip any any -> any any (geoip:any,!US,!CA; msg:"Drop traffic to countries other than US and Canada"; sid:10000009;) 1分ほど待つとRuleが適用され、先ほどまで通っていたcurlコマンドが無事Blockされるようになりました。 curlコマンドがBlockされるようになった DNS Firewallでの通信制御 次に、DNS Firewallを用いて、独自のドメインブロックリストを作成し、攻撃者に悪用されやすいTLDをまとめてブロックする設定例を紹介します。 VPCの画面からDNS Firewallを選択、Rule groupsへ移動し、新規でRule groupを作成します。作成したRule groupに対してAdd ruleでブロックしたいドメインのリストを記載します。 Rule groupを作成する 設定例は以下の通りです。 Rule name: <Rule名は自由に設定> Domain list: Custom domain list and Create new domain list Domain list name: Domains: 以下を記載 *.ru *.cn *.xyz *.cyou *.pw *.ws *.gq *.surf *.cf *.ml Domain redirection setting: Select Inspect all (Default) Action: Block Block response: OVERRIDE Record type: CNAME Record value: dns-firewall-block TTL (seconds): Enter 0 適用後、該当ドメインへのリクエストがBlockされることを確認できました。 該当ドメインへのリクエストがBlockされることを確認できた Workshopまとめ 今回紹介した内容以外にも、プロトコルとポートのミスマッチを利用した攻撃を検出するPort/Protocol Enforcementや、AWS Managed Domain Listsを利用したDNS Firewallの設定などもありました。 また、上記で設定した検知のログをCloudWatch Logsで確認したり、VPC間通信のトラフィック制御を試したりするなど、他にもいくつかのシナリオを想定したLabもありました。内容が盛りだくさんで時間内に到底収まらないほどのボリュームでした。 普段意識しづらい外向き通信のネットワークセキュリティについて、実際に手を動かして学ぶ、とても良い機会となりました。 The Kiro coding challenge (DVT317) ZOZOMO部 SREブロックの中村です。ZOZOMOなどのマイクロサービスのSREを担当しています。ZOZOMO部ではAI Agentを活用した業務の効率化や本番運用にAIへの積極的活用に力を入れており、re:Inventでは多数のAgentサービスの新発表や既存サービスのアップデートが行われ、それに関するセッションも多く行われました。 Kiroを用いた仕様書駆動開発のWorkshopに参加したのでそのセッション内容をご紹介します。また、「Ditch your old SRE playbook: AI SRE for root cause in minutes」のセッションも合わせて紹介します。 Workshopの概要 このWorkshopは、KiroというエージェントネイティブIDEを使った実践的なコーディングチャレンジです。難易度が徐々に上がる10個のコーディングチャレンジをKiroの支援を受けながら課題を解決していきます。参加者は約70〜80人ほどで、他のWorkshopと比較してもとても人気のセッションとなっていました。 The Kiro coding challengeの会場 Workshopの冒頭ではKiroや仕様書駆動開発についての簡単な説明が行われました。仕様書駆動開発では、PLANNING DESIGN → IMPLEMENTATION → TESTING & QA まで一貫してカバーし、仕様を先に定義してから開発するので、手戻りが少なく高品質な製品を出荷できるような説明が図とともに行われました。 仕様書駆動開発に関する説明 実践 Kiroの説明と、Workshopの説明が終わった後、AWSが用意してくれたWorkshopの環境に接続し、今回のWorkshopの概要等を確認できます。必要に応じてセットアップなど行なっていきます。 今回のWorkshopでは1から10のタスクが用意されており、それらをKiroを使って解決していきます。 Workshopの様子 #1 Workshopの様子 #2 タスクを解決するプロンプトをKiroで叩き、解決していってもらいます。序盤はプロジェクトのセットアップをメインに行うタスクが多く存在しました。 タスク6では、ついに仕様書駆動開発を使用するタスクがでてきました。Kiroに対し、仕様を伝えそれを仕様書として作成するように依頼することで、Kiroの管理下に仕様書が作成されます。仕様書を作成したのち、Kiroは仕様書を元に実装を行なっていきます。 Workshopの様子 #3 Workshopの様子 #4 タスク8では、AgentHooksを利用しコードの変更をトリガーに、対応のドキュメントを併せて更新するような指示を追加できました。AgentHooksを利用するとドキュメント更新以外のアクションも実行できるので色々と夢が広がる機能ですね！ Workshopの様子 #5 また、このWorkshop中は常にTOP10の順位が前のスクリーンに投影されていて、エンジニア全員で競い合い会場が熱気に包まれていました。 Workshop中は常にTOP 10までの順位がスクリーンに投影されていた まとめ 本セッションを通じて、仕様書駆動開発がどのように行われていくのか、またKiroを利用した仕様書駆動開発をどのように行なっていくのかを学べました！　実際にWorkshopで利用したリポジトリはこちらです。どのような仕様書が作られたか気になった際はぜひ確認してみてください！ github.com Ditch your old SRE playbook: AI SRE for root cause in minutes (sponsored by Resolve AI) (AIM260-S) 概要 このセッションでは、 Resolve AI社 により、SRE領域におけるAIエージェントの活用についてBreakout session形式で実施されました。本番環境の運用やインシデントの根本的な原因の分析を数分で実行するなど、開発でなく運用面にフォーカスをおいていました。SREという文字が含まれるセッションは少なく、こちらもとても人気でした。 AIM260-S セッション会場の様子 内容 ソフトウェアエンジニアリングの進化 セッション冒頭では、数年ほど前からAIがソフトウェアエンジニアリングに与えている大きな影響、進化を3段階に分けて説明されました。 1段階目ではAIがコードを書くのでなく、人間が書いたものを自動補完するようなところから始まり当初は人間がオペレーターとなって作業を行なっていました。 2段階目ではAgentが登場した頃で、AIがオペレーターとなり作業し、それを人間が管理、監視するという、現段階で多くのエンジニアが行なっていることなのだと思います。今はこの段階の進化レベルにあると考えられています。 3段階目はすでに移行の過程である、またはこれからAIの進化が到達すると考えられており、AIが開発だけなく、今までエンジニアが扱ってきた様々な監視ツールや本番でのインフラ構成など運用に必要なあらゆるツールを人間同様に使いこなせるという話がされました。 セッションの様子 AI for prod Resolve AI社が提供するAI Agentを用いて実際にインシデント対応するデモが実施されました。このAgentは事前にアプリのコードはもちろん、インフラの構成等全てを知識として把握しています。GrafanaからSlackのアラートチャンネルにエラーが通知された時にそれをトリガーにAgentが起動しエラーを調査します。 Slackでは何が原因でどうすれば解決できるかを提案してくれます。しかしなぜその結論になったのかを知りたい場合は、Resolve AIのWeb UIを確認しAgentがどのような調査を行なったか詳細な情報を確認できます。 デモでの調査内容は次の通りです。 ログクエリの生成 履歴の確認 トレースの調査 インフラストラクチャイベントの確認 チャート・ダッシュボードの分析 コードのチェック Resolve AIの3つの重要な特徴 セッションではResolve AIの構築にあたり、3つの重要な特徴について説明されました。特にマルチエージェントを生かして本番環境での実用性を説明しているように感じられました。 理解（Understand） Knowledge graphを用いてシステム全体を理解する 優秀なプリンシパルエンジニアが持つような知識を再現 システムの歴史 障害パターン 過去のポストモーテム 学習（Learn） ツール使用履歴からの学習 ダッシュボードの使用頻度など、ツールの使われ方から学習 アラートの優先度ラベル（P1など）を評価基準として活用 インシデントチャンネルでの議論から原因究明・修復プロセスを学習 チーム・組織レベルでカスタムコンテキストを追加可能 推論（Reason） マルチエージェントアーキテクチャ プランナーが「何をすべきか」を判断 専門化されたサブエージェントがエビデンスを収集 レート制限やペイロードの処理を理解 人間のフィードバックループを組み込み、継続的に改善 AIエージェント構築のアプローチ比較 このセクションでは、インシデント対応を自動化するAIエージェントの構築には、大きく4つのアプローチがあると説明をされました。セッションを聞いた内容を簡単に要約してみました。 LLMs エラーをそのままLLMに投げる最もシンプルな方法。時には正解するが、複雑なシステムではコンテキスト不足で機能しない。 セッションの様子 LLMS + tools(MCP) MCPサーバー経由でObservabilityツールにアクセス。データは取れるが、状態管理がなく「1時間分見るべきか、1週間か」の判断ができない。 Single Agent ランブックやコンテキストを詰め込んだ単一エージェント。肥大化して遅くなり、未知のインシデントに対応できなくなる。 Multi-Agent Systems 専門化されたエージェント群の協調動作。最も柔軟だが、オーケストレーションの複雑さがマイクロサービス同様の課題になる。 セッションの様子 感想 今回のセッションでSREにフォーカスを当てたAIエージェントのサービスを初めて知りました。確かにインシデントの調査や一部対応は既存のAIエージェントでもできますが、既存の情報のみでしか判断等できずに自律的な成長などをエージェントにさせようとすると、とても難しいことだと改めて感じました。 セッションの内容はAWS公式のYouTubeチャンネルに公開されているので、さらに細かい内容を知りたい方はぜひそちらの動画をご覧ください！ www.youtube.com [NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agent [REPEAT] (DVT337-R1) 計測システム部 バックエンドブロックの髙橋です。普段はZOZOMETRY、ZOZOGLASS、ZOZOMATなどの計測プロダクトのバックエンドの開発・運用を担当しています。 今回、Keynoteで新たに発表された「 AWS DevOps Agent 」について、Keynoteをリアルで聞きながら興味を持ちました。発表後にハンズオンを受けてきましたので、ハンズオンの内容とAWS DevOps Agentの使いどころについてご紹介します。 まず、AWS DevOps Agent（以下、DevOps Agent）とは、今回のre:Inventで発表された Frontier Agents の一角を成すAIエージェントです。主に運用上発生する障害などのインシデントに対し迅速に原因を調査し、それに対する解決策を提案してくれます（2025年12月の記事公開時ではPublic Preview）。その上で、今回のハンズオンでは用意されたシナリオを通じ、DevOps Agentの実際の使い所について学んできました。 AWS DevOps Agentができること - AWS上のリソースの可視化 現在ログイン中のアカウントのAWSリソースのトポロジが表示される DevOps Agentでは、最初のステップとしてAgent Spaceというスペースを作成します。作成し、用意されたWebポータルにアクセスすると、現在ログイン中のアカウントのAWSリソースのトポロジが表示されます。 AWS DevOps Agentができること - 障害調査 今回のWorkshopでは、DynamoDBの書き込みキャパシティを意図的に大幅に絞り、システムに障害を発生させました。すると、予めセットされていたCloudWatch Alarmが発報します。 予めセットされていたCloudWatch Alarmが発報する 発報された後、DevOps Agentの「Start an investigation」ページで、「Investigate the DynamoDBWriteThrottleAlarm（CloudWatchで発報されたアラーム名）alarm」と入力し、調査してもらいます。 Start an investigationで調査してもらう 調査が進むと、「Root cause」という部分でDynamoDBの書き込みキャパシティの小ささが根本原因として書かれていることがわかります。 DynamoDBの書き込みキャパシティが小さい旨が根本原因とわかる さらに、「Mitigation Plan」で実際の復旧に必要な作業の計画を立ててくれます。 実際の復旧に必要な作業の計画を立ててくれる このように、今までは人間がやっていた障害内容の調査→原因究明→復旧のための計画までをDevOps Agentにアウトソースできます。 実際の使い所 DevOps Agentでは人間が先ほどの画像のように指示して調査させるだけではなく、Datadogなどのツールから異常検知されたことをトリガーとして自動的に調査を開始できます。 docs.aws.amazon.com 実際の運用現場では、アラートが鳴り、人間が気付いてからの初動対応は数秒レベルの即時とはいかない場合が多いですし、その時のメンバーによってシステムに対する習熟度や調査時に見る観点も違うでしょう。そのような場合にDevOps Agentが先回りして即時に自動で調査を開始し、人間に対して原因と復旧計画を提供することによってより高品質かつ、迅速な障害対応を行えると考えています。 現在DevOps Agentは現在Public Preview期間であるため、いきなり本番環境に組み込まずともチームのカオスエンジニアリング・障害訓練等からまず使ってみることもおすすめです。チームでのカオスエンジニアリングの記事は以下をご覧ください。 techblog.zozo.com おわりに セッションや展示ブースで多くのことを学べるのはもちろん、AWSのエキスパートや他社のエンジニアの方々と交流し、多くの刺激を受けられるのが現地参加の醍醐味です。今回得た知見を社内外に共有しながら、これからもAWSを活用してプロダクトとビジネスの成長に貢献していきます。 ZOZOではAWSが大好きなエンジニアを募集しています。奮ってご応募ください！ corp.zozo.com