こんにちは！製造業のお客様を中心に技術支援をしているソリューションアーキテクトの伊藤ジャッジです。だんだん梅雨らしい気候になってきましたね。この時期といえば今年も  AWS Summit Japan 2026  です！今年も IoT の展示の出展はもりだくさんで、 こちら のブログに概要を掲載しています。ぜひ遊びに来てください。このブログでは IoT 展示内の ロボットの遠隔テレオペレーションの ブースの展示について紹介します。 背景 2026 年のものづくり白書 には、政府主導の AI ロボティクス戦略がその中にありました。AI で賢くなったロボットが、これまで自動化が難しかった市場を広げる「フィジカル AI 時代」を見据えた戦略の発表となりました。政府主導のロボティクス推進方針が明確になったことはロボットを製造する側にも使う側にも喜ばしいことですが、一方で、AI の学習に必要なデータがなければ、どんなに性能の良いロボットでも、AI を使って期待した動作をしてもらうことができません。また、学習には高品質なデータが必要となります。幸いなことに日本の産業ロボットの製造業における活用は世界でも最高水準です。そのため、産業ロボットの動作データは潤沢に存在します。政府も日本の強みとして、産業用ロボット、部品・素材、高品質な現場データを土台に、「まず社会実装してデータを取り、モデルを改善し、他分野へ横展開」という循環を確立することを勝ち筋として、上述のものづくり白書で提案しています。 データが必要ということは理解できますが、このデータ収集において大きな壁があります。実は、ロボット開発では、センサー・モーター・カメラなど多数のハードウェアを組み合わせる必要があります。しかし今までは、ロボットメーカーごとにインターフェースが異なり、各社それぞれのロボット制御言語を使用してきました。そのため、ロボットを新規導入する際は、あるロボット向けに書いたソフトを別機種に移植することはできず、一から動作、通信制御、またはデータ連携を作り込むことになり、膨大な開発コストがかかっていました。この状態は各種ロボットが連携する将来を見据えたロボットの動作データの収集という観点では、障壁と言えるでしょう。 このサイロ化したロボット開発環境の問題を解決するため、ROS が登場しました。ROS（Robot Operating System）は、上記の課題を解決するオープンソースの共通フレームワークです。標準化された通信の仕組みとツール群を提供し、開発者はハードウェアの違いを意識せずにロボットの機能開発に集中できます。さらに、ROS2 の登場をきっかけに近年では産業用ロボットメーカーも ROS2 のサポートを発表する機会が増えてきました。 デモの内容 デモのタイトルにある「遠隔テレオペレーション」（テレオペ）とは、離れた場所にあるロボットや機械を、人間がリアルタイムに操作する技術です。オペレーターは手元のコントローラーやモニター映像を通じて現場の状況を把握し、ロボットに動作指示を送ります。ロボット側のカメラやセンサーの情報がネットワーク経由でオペレーターに返されることで、あたかも現場にいるかのように作業できます。この技術により危険な環境（災害現場、高所、有害物質のある場所）や、人がすぐに行けない遠隔地での作業を安全に行えています。 このテレオペのデモでは AWS の IoT サービスを利用し、 Web の UI を見ながらゲームコントローラーを操作することで、クラウド経由でロボットを操作します。 このデモで利用している実機のロボットは、世界中の生産現場でも利用されているセイコーエプソン株式会社製の高速・高精度な垂直多関節（6軸）ロボット( CX4-A601S )を利用しています。セイコーエプソン株式会社では自社のロボットに対応した ROS2 パッケージ を公開しており、デモでは ROS2 経由で操作しています。 このデモでは同時にデジタルツインとしての Amazon EC2 上で実行されている NVIDIA Isaac SIM にも情報が送られるため、カメラの映像だけではなく、シミュレーション環境上でもロボットの動作を確認することができます。 セイコーエプソン株式会社の ROS2 パッケージ では実機を利用せず、Rviz (3D 可視化ツール)で動かすモードも用意されているため、シミュレーション環境の中だけで動かすこともできます。それゆえ、ロボットの操作に不慣れな人でも安心して操作することが可能です。 このデモでは操作時のデータを rosbag 形式 (ROS2 上でやり取りされるメッセージを記録し、後で利用できる) に保存することも可能で、作成された rosbag は記録後にクラウドに保存されます。このデータを使うことで、クラウド上のシミュレーション環境で、同じ様に再現することもできます。また、保存された操作データは、Physical AI で利用される VLA（Vision-Language-Action）モデルの模倣学習データとして活用することができます。 今回のデモの全体の構成は下記となっています。 ぜひ、 6 月 25 日、26 日に幕張メッセで開催される AWS Summit に来場いただき、実際にご自身の手でコントローラーを操作 し、Physical AI の時代に必須となるロボット動作データ生成と収集を体験しに来てください！ デモは AWS Expo の AWS for Industries Zone に展示しています。 伊藤ジャッジ向子 (Ito, Judge Sakiko) 米国での開発者経験を経て、AWSのサポートに入社し、異動しエンタープライズ事業本部でソリューションアーキテクトとして製造業のお客様をご支援しています。趣味は山登り、クラッシックバレエと愛犬のお世話です。 Muhammad Fikko Fadjrimiratno（ふぃっこ） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 不動産・建設業界のお客様を中心に、AWS 利用をご支援しているソリューションアーキテクトです。好きな領域はロボットとIoTと機械学習であり、最近はロボット分野での生成AIの活用にチャレンジしています。趣味はフライトシミュレーター、冬はスノーボードです。 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。

　 みなさんこんにちは！ 猫や犬に癒されるより AI bou (相棒) に助けられる日々を送る Solutions Architect の高野です。一昨年、昨年と AWS Summit Japan でご好評いただいた Chaos Kitty が、今年はさらにパワーアップした「対戦モード」を引っさげて 4 回目の登場です！ 　 この記事では、2026 年の AWS Summit Japan の AWS Builders’ Fair で展示される「人間 vs AI 障害対応バトル – Chaos Kitty Challenge」についてご紹介します。今年のテーマは、システム運用保守業務における AI Agent の活用による効率化です。参加者と AI エージェントが同じ障害に同時に挑み、対戦を通じて AI Agent がインシデント対応をどのように効率化するかを体感できる体験型コンテンツとなっています。 　 AWS Summit Japan 2026 の開催期間は 2026 年 6 月 25 日 (水) と 26 日 (木) の 2 日間で、会場は幕張メッセになります。 本展示は両日ともご体験いただけます。 まだ AWS Summit Japan 2026 に登録してない方は こちらのページ からご登録ください。Chaos Kitty は、AWS Expo の AWS Builders’ Fair の中にあります。 Chaos Kitty とは？ 　 Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、インシデント対応の体験学習ができるソリューションです。Web 3 層アプリケーションに異常を注入し、異常を修正するまでのタイムを競うことで、ゲーム感覚でインシデント対応を学ぶことができます。 　 2023 年の初登場 以来、 2024 年 、 2025 年 と 3 年連続で AWS Summit Japan に登場し、毎年パワーアップを重ねてきました。昨年は IoT 機器なしで利用可能な Web アプリケーション化や、 AWS Cloud Development Kit (AWS CDK) による Infrastructure as Code (IaC) 化を実施し、 AWS Samples として公開 しています。どなたでもご自身の AWS 環境にデプロイしてお試しいただけます。また、Amazon CloudWatch ダッシュボードや Amazon CloudWatch Application Signals を活用したモニタリングも組み込まれており、インシデント発生時の状況把握を体験いただけます。 新機能紹介: 対戦モード 　 4 回目となる今回は、 システム運用保守における AI Agent 活用 をテーマに、対戦モードを新たに追加しました。AI Agent がインシデント対応をどのように効率化するかを楽しみながら体感いただけるよう、参加者と AI が同じ障害に同時に挑むゲーム形式にしています。 図 1 : AWS Summit Tokyo 2026 版 Chaos Kitty 外観 図 2 : 障害注入対象の Web 3 層アプリケーション画面 対戦モードの概要 　 同じ障害が発生した 2 つの環境で、参加者と AI エージェントが同時に対応を開始します。人間の直感と経験 vs AI の分析力と速度 — リアルタイムで両者の対応プロセスが可視化され、どちらが早く正確に障害を解決できるかを競います。AI 時代のインシデント対応の未来を、対戦を通じて体感できるモードです。 　 日々システムを運用されている皆様であれば、障害発生時にログを追い、メトリクスを確認し、構成変更を洗い出し、根本原因を突き止めるまでの緊張感と難しさをよくご存知かと思います。その一連のプロセスを、AI Agent はどれほどの速さでこなすのか。そして、あなたは AI Agent に勝てるのか。今年は従来の Easy モード、Hard モードに加えて、上級者向けの Extreme モードも追加しています。長年の経験と勘で培ったインシデント対応力を、ぜひ AI にぶつけてみてください。勝っても負けても、AI 時代のシステム運用のあり方を肌で感じていただけるはずです。腕に自信のある方、お待ちしております！ 図 3 : 対戦モード初期画面 図 4 : ゲーム中画面 図 5 : 勝敗確定画面 (AI WIN) 図 6 : 結果画面 インシデント調査・分析用 AI Agent に AWS DevOps Agent を採用 　 対戦モードで参加者と競う AI Agent には、 AWS DevOps Agent を採用しています。 　 AWS DevOps Agent は、インシデント対応を自動化するフルマネージドサービスです。インシデントが発生すると、Amazon CloudWatch のメトリクス、ログ、トレース、さらにはデプロイ履歴や API 変更履歴など、複数のデータソースを横断的に分析し、根本原因の特定から修復アクションの提案までを自動で行います。人間のオンコールエンジニアが手動で相関分析に費やしていた時間を、数分レベルに短縮できるのが特徴です。 　 AWS DevOps Agent は API 経由で調査タスクの開始や状態取得ができるため、今回の Chaos Kitty ではアプリケーションから API を呼び出し、対戦モードの画面上に AI Agent の調査プロセスをリアルタイムで表示しています。参加者は、自分が手動で調査を進める横で、AI Agent がどのような手順で原因を特定していくかを目の前で確認できます。 　 また、AWS DevOps Agent が標準で提供する Web 画面 (DevOps Agent Space) もブースでご覧いただけます。実際の運用で AWS DevOps Agent をどのように活用できるかのイメージを掴んでいただけると思います。 図 7 : AWS DevOps Agent Space の画面 体験を通じて学べること 　 この対戦モードを通じて、以下のことを体感いただけます。 1. AI Agent がどのようにインシデントを調査・分析するか — AWS DevOps Agent の動作を目の前で確認できます 2. AIOps による迅速化の効果 — 手動対応と AI 支援対応の所要時間の差を実体験で理解できます 3. AI Agent を活用したインシデント対応の実践イメージ — 日々のシステム運用にどう活かせるかのヒントを得られます さいごに 　 今年の Chaos Kitty は、システム運用保守における AI Agent 活用をテーマに、対戦モードを通じてその効果を楽しみながら体感いただける内容になっています。AI Agent がインシデントをどのように調査・分析するのか、そして日々の運用業務にどう活かせるのか、ぜひブースで実際に体験してみてください。 　 AI に勝てた方も、負けてしまった方も、AI 時代のシステム運用のあり方について新たな気づきを持ち帰っていただければ幸いです。AWS Summit Japan 2026 の AWS Builders’ Fair で、皆様のご来場をお待ちしております！ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 高野 翔史 Chaos Kitty は AWS Japan ソリューションアーキテクトの服部 一成、堀 貴裕、佐々 拓也、津郷 光明、河角 修、黒木 琢央、高野 翔史が中心となって開発しております。

はじめに 通信業界の主要 MNO 4 社（NTTドコモ、KDDI、ソフトバンク、楽天モバイル）に NTT、ソニーを加えた通信関連事業者の皆様、121 名 / 6 グループの方々が一堂に会したワークショップを、2026 年 4 月 23 日に AWS Startup Loft Tokyo で開催しました。テーマは、ネットワーク開発・運用を変える「カスタム AI エージェント」。本記事では、Autonomous Network 実現に向けた参考アーキテクチャ、NTTドコモ／NTTドコモビジネス両社の事例、Strands Agents・Amazon Bedrock AgentCore のハンズオン、そしてユースケース議論まで、当日の内容をレポートします。「自社のどの業務に、どう適用できるか」を考えるヒントとして、お役立ていただけますと幸いです。 ワークショップ参加者の集合写真 AWS ジャパンでは、こうしたテーマに向き合う場として 2025 年 11 月に「 通信ネットワーク運用向け AI エージェントワークショップ 」を開催し、参加された通信事業者の皆様から大きな反響をいただきました。今回はその第 2 回として、対象を ネットワーク開発・運用全般 に広げ、開発工程での AI エージェント活用も新たに取り上げました。 通信業界のネットワーク開発・運用では、より高品質で柔軟なサービスを継続的に提供するために、設計・構築・障害対応・改善といった多岐にわたる業務を効率化することが求められています。一方で、ネットワークの拡張や複雑化に従来のオペレーションだけで追従することは難しくなりつつあり、自動化・高度化・自律化の取り組みが加速しています。その実現手段の 1 つとして AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する業務ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった共通の課題があります。本ワークショップは、こうした課題に対して「学ぶ・知る・触る・議論する」を 1 日に凝縮した場を提供するものです。 アジェンダ 時間 セッション 登壇者 13:00–13:10 オープニング Yuki Miyazaki (AWS / SA) 13:10–14:15 セッション1：複雑な開発/運用業務でAIエージェントを活用しよう Yuki Miyazaki (AWS / SA) 13:10–14:15 事例登壇：AIとGitOpsを用いた5Gコアネットワークの設計構築自動化への取り組み NTTドコモ 宮本氏 13:10–14:15 事例登壇：ルータ統合型AIエージェントによるネットワーク開発の取り組み NTTドコモビジネス 門脇氏 14:30–16:00 セッション2：AWSで実現するカスタムAIエージェント（Strands Agents / Amazon Bedrock AgentCore ハンズオン） Atsushi Okamoto (AWS / SA), Yuta Tanaka (AWS / SA) 16:15–17:50 セッション3：ネットワーク開発運用エージェントを触ってみよう（ハンズオン＋ユースケース議論） Naohito Yoshikawa (AWS / SA) 17:50–18:00 クロージング Yuki Miyazaki (AWS / SA) 18:00–19:30 ネットワーキングパーティ — セッション1：複雑な開発/運用業務でAIエージェントを活用しよう 宮崎 友貴 Solutions Architect Autonomous Network 参考アーキテクチャ 本セッションでは、通信業界のオペレーションの標準化団体である TM Forum が定義する Autonomous Network （自律ネットワーク）の自律レベル L4/L5 の実現に向けて、AI エージェントとデータの活用が不可欠であることを解説しました。まず、AI エージェントが自律的な行動を行えるようになった基礎技術の変遷と、ネットワークの開発者や運用者に近い動きが実現可能であることを説明し、AWS で実現する参考アーキテクチャをご紹介しました。このアーキテクチャのキーは AI エージェント × 自律的な判断に必要なデータであり、ネットワークのトポロジーや時系列データ、構成情報、設計書、手順書といったネットワークデータと AI エージェントを組み合わせることで、ネットワークの設計や構築、運用開始後の障害検知から根本原因分析といった複雑なオペレーションを自律的に行える仕組みが構築できることをお伝えしました。最後に、グローバルおよび国内の通信事業者における AI エージェントの活用事例をご紹介し、Autonomous Network が既に商用で実現しつつあることを参加者の皆様にお伝えしました。 本セッションの資料（PDF）をダウンロード 事例登壇：NTTドコモ 「AIとGitOpsを用いた5Gコアネットワークの設計・構築自動化への取り組み」 宮本 克真 氏 株式会社 NTTドコモ コアネットワークデザイン部 AI エージェントを使ったネットワーク設計構築自動化の事例として、株式会社 NTTドコモ コアネットワークデザイン部の宮本克真氏にご登壇いただきました。 NTTドコモでは、国内で初めて 5G コアネットワーク（5GC）を AWS 上に構築し、2026 年 2 月より商用サービスを開始 しています。従来の 5GC 設計・構築プロセスでは、膨大なマニュアルや仕様書の確認、多種の設定ファイル作成、煩雑な構築手順の実施に約 4〜6ヶ月を要し、需要増への迅速な追従が課題でした。 AI×GitOps による設計・構築の自動化 そこで AI エージェントと GitOps を組み合わせた設計・構築自動化を導入しました。AI エージェントがマニュアルや仕様書をナレッジベースとして参照し、インフラ設定・アプリ設定・5GC コンフィグなどの設定ファイルを自動生成します。生成されたファイルは Git で管理され、CI/CD パイプラインを通じて自動デプロイされます。アーキテクチャとしては Amazon Bedrock AgentCore 上のオーケストレータエージェントが、Git 担当・インフラ担当・アプリ担当・コンフィグ担当の各専門エージェントを統括する構成です。各エージェントは Strands Agents SDK で構築され、Amazon Bedrock Knowledge Base を MCP 経由で参照します。デモでは、オペレータが「5GC NF を構築して」と指示するだけで 5GC が構築される様子をご覧いただきました。 AI×GitOps の活用による効果 この取り組みにより設計から構築までのリードタイムを約 80% 短縮することに成功し、工数削減と共に人為ミスの低減にも繋がりました。今後は、試験自動化や保守・運用領域などへの拡大を目指しています。 事例登壇：NTTドコモビジネス「ルータ統合型AIエージェントによるネットワーク開発の取り組み」 門脇 伸明 氏 NTTドコモビジネス株式会社 ルータ連携 AI エージェントのネットワーク開発への活用事例として、NTTドコモビジネス株式会社の門脇氏にご登壇いただきました。同社では、映像伝送ネットワークサービスを提供しており、全国の専用線網にて数百台規模のルータを運用しています。従来、突発的なネットワーク設定変更（例：ファイアウォール強化）が必要な際には、エンジニアがマニュアルや仕様書を確認し、ルータの状態を手動で調査した上で設定を作成・検証し、さらにレポート資料を作成するまでに約 6 日を要していました。 AIエージェントによるルータ設定検討支援 そこで、ルータの MCP を活用してルータと直接連携する AI エージェントを導入しました。エンジニアが設定要件を自然言語で指示するだけで、AI エージェントがルータから必要な情報を自律的に収集し、既存の設定や環境に合わせてコンフィグを設計・生成します。さらに、コンフィグ投入後の動作確認やレポートの作成まで自動化することで、所要日数を 6 日から 1 日へと大幅に短縮しました。また、AI エージェントのメリットとして、自律的にルータから自動で必要情報を収集するため、ルータ情報をプロンプトで与えずにルータの専門知識さえあれば活用できる点と、AI エージェントの振る舞いの定義をコードではなく自然言語で記述できるため可読性が高く実装が容易である点が紹介されました。 AIエージェント開発環境 AWS の構成としては、社内のセキュリティ規約に基づき閉域接続（AWS コンソール以外はインターネット接続なし）で構築することで安全な AI エージェント運用を実現しています。今後は、試験自動化やメーカー問い合わせの自動化など、さらなる AI エージェント活用のユースケース拡大を目指します。 セッション2：AWSで実現するカスタムAIエージェント — Strands Agents と Amazon Bedrock AgentCore 本セッションの前半では、カスタム AI エージェントを「素早く構築する」ことと「安全に大規模運用する」ことの両方を実現する AWS のアプローチとして、 Strands Agents と Amazon Bedrock AgentCore を最新アップデートとともにご紹介しました。 岡本 篤志 Solutions Architect まず AI エージェントの構成要素を、推論を担うモデル・振る舞いを定義するプロンプト・外部システムと連携するツールの 3 つに整理した上で、これを本番稼働させるにはメモリ管理やオブザーバビリティ、セキュリティ、スケーラビリティなど多くの周辺機能の実装が必要になることを示しました。Strands Agents はこの「構築」の負担を大幅に軽減するオープンソース SDK であり、わずか数行のコードでエージェントを実装できます。MCP をはじめとする多様な接続方式による外部システム連携や、エージェント同士を組み合わせるマルチエージェント構成にも対応しています。さらに、複雑なマルチステップタスクにおける再現性や品質の一貫性を確保する仕組みとして Agent SOP （自然言語で記述するワークフロー定義）を紹介し、チーム間での知見共有と品質統一が可能であることをお伝えしました。 続いて、「大規模運用」を担う Amazon Bedrock AgentCore について解説しました。任意のフレームワークやモデルで構築したエージェントを本番環境にデプロイし、会話コンテキストの維持、アクセス制御、実行トレースの可視化、品質の継続的な評価まで、エンタープライズグレードの運用基盤を包括的に提供します。下図のように、通信ネットワーク運用の文脈では、ネットワーク機器や構成管理システムとのツール連携、インシデント対応ナレッジの長期記憶としての蓄積・活用が可能であり、ネットワーク運用の自律化に向けた基盤として特にフィットすることを示しました。 通信ネットワークにおける Amazon Bedrock AgentCore の価値 その後、Strands Agents と Amazon Bedrock AgentCore の両方の実装を体験できるワークショップを実施させていただきました。 田中 優多 Solutions Architect このワークショップでは、Strands Agents 及び Amazon Bedrock AgentCore の機能を最大限に活用した、包括的で本番環境に対応したカスタマーサポートエージェントを構築しました。単なるチャットボットではなく、複雑なカスタマーサービスのワークフローを処理し、複数の企業システムと連携し、同時に数千人の顧客にサービスを提供できるような高度なエージェントシステムです。 まずは、Strands Agents をローカル環境に実装することをご体験いただきました。幾つかの用途特化機能をツールとして定義 → 独自のデータをナレッジベースとして連携 → エージェントの役割を自然言語で定義といった簡易なステップで、AI エージェントを作成できることを確認しました。 Lab1 の構成 ただしこの状態のプロトタイプには、以下のような課題がある状態でした。 永続的なメモリがない — エージェントは過去の会話を忘れる スケーラビリティがない — ローカル開発環境でのみ実行 こうした課題を解決するソリューションとして、Amazon Bedrock AgentCore の実装へと進みました。数ある AgentCore モジュール群の中でも、 AgentCore Memory と AgentCore Runtime に焦点を当てて、コードベースでその設定やデプロイ方法をご体感頂きました。AgentCore Memory を実装することで、ユーザとのやり取りの記憶や好みの自動学習、長期間のコンテキスト維持が可能になります。そして AgentCore Runtime の活用により、常に変化する需要に合わせて自動的にスケールするサーバーレスソリューションが実現できます。数多くのフレームワーク、モデル、プロトコルをサポートし、開発者は最小限のコード変更でローカルプロトタイプを本番対応ソリューションに変換できます。 Lab4 の構成（〜Runtime 上へのデプロイまで） これらをお客様の手でカスタムで作り上げることにより、業務に即した実用性の高い AI エージェントが実装できることを、ご体感いただきました。 ワークショップ会場の様子 本セッションの資料（PDF）をダウンロード セッション3：ネットワーク開発運用エージェントを触ってみよう 吉川 直仁 Solutions Architect 前段のセッション2で学んだ Strands Agents と Amazon Bedrock AgentCore の知識を、通信ネットワークというドメインに当てはめるとどうなるか、を体感していただくのが本セッションの位置付けです。前回ワークショップでは保守運用業務にフォーカスしましたが、今回はそこに 開発・構築工程 のシナリオを 2 本追加し、参加者の皆様に「物理ネットワークの設計・開発者」「5G コアネットワークの設計・開発者」「ネットワーク保守運用者」の 3 つの立場を順に体験していただきました。 シナリオ① ネットワーク機器の設定、構築、検証 シナリオ ① は、複数台のルータから構成されるネットワークの Config 設定・接続確認・バグ検証の自動化です。実機の設定情報、大量のログ、仕様書を参照しながら対応する必要がある業務を、AI エージェント × ナレッジ（SOP）の組み合わせで実装します。 デモ動画：シナリオ ①（ネットワーク機器の設定・構築・検証） オペレータが「ネットワークの状態を確認して、疎通不可の原因を調査・修正してほしい」と自然言語で指示するだけで、AI エージェントが SOP に従って ① 構成情報の確認 → ② ヘルスチェック → ③ Config 修正 → ④ レポート作成までを自律的に実行する様子をご覧いただけます。 シナリオ② コアネットワークのパラメータ設計、構築 シナリオ ② は、5G コアネットワークのパラメータ設計とデプロイです。複数の NF（Network Function）から構成されるコアネットワーク網に対するネットワークスライス追加を、Strands Agents が IaC とパラメータを生成し、Git を介してインフラ（Amazon EC2）からその上で動くアプリ、さらにアプリのパラメータ設定までを一気通貫でデプロイする流れを体験していただきました。 デモ動画：シナリオ ②（コアネットワークのパラメータ設計・デプロイ） オペレータが「新しいネットワークスライスを追加してほしい」と自然言語で指示するだけで、AI エージェントが現在の構成を確認し、SOP に従って IaC とパラメータを生成、Git を介してインフラ（Amazon EC2）→アプリ→アプリのパラメータ設定までを一気通貫でデプロイする様子をご覧いただけます。 シナリオ ③ は前回ワークショップでもご紹介した、ネットワーク障害発生時のアラーム分析・切り分け・措置レコメンド・チケット起票です。今回はマルチエージェント構成を前回からアップデートして実演しました（構成の詳細は 前回ブログ をご参照ください）。 シナリオ ①／② デモアプリケーション構成図 シナリオ ①／② のデモアプリケーションは、Strands Agents で実装したエージェントを Amazon Bedrock AgentCore Runtime 上で動かし、AgentCore Memory（STM/LTM）と AgentCore Observability も統合した構成です。エージェントは利用者からの一つの指示に対し、ネットワーク機器の操作・IaC のデプロイ・Git への変更反映といった複数の外部アクションを自律的に組み合わせて実行し、本番運用を想定した記憶・観測の仕組みも合わせて体験いただけるようにしています。 通信業界における SOP とは？ 通信業界では、仕様書、詳細設計書、ベンダードキュメント、手順書、パラメータ設計規則など、独自フォーマットの大量のドキュメントが存在します。本ハンズオンではこれらを SOP（Standard Operating Procedure） という形式に標準化し、Markdown ファイルとして AI エージェントに与えることで、「人間も AI も同じ手順を読み、同じ成功基準で評価できる」状態を作り出しています。SOP の生成・評価・修正自体も AI エージェントで自動化でき、エラーの有無・ポリシー順守・効率性などを別の SOP 評価エージェントで自動チェックする運用も実演しました。 本セッションの資料（PDF）をダウンロード ユースケース議論ワークショップ ユースケース議論ワークショップの様子 セッション 3 のハンズオンを終えた後半 30 分は、参加者の皆様にご自身の業務に当てはめて考えていただくユースケース議論の時間としました。テーブルごとに AWS SA も加わり、模造紙と付箋を使って「AI エージェントに任せたい業務は何か」「任せるために必要なデータ・指示は何か」「自担当で導入するならどんなアーキテクチャになるか」の 3 つの問いを順に議論いただきました。 各テーブルから出てきたアーキテクチャ図と付箋を AWS 側で見渡して整理すると、参加企業・担当領域は様々であるにもかかわらず、いくつかの共通した観点が浮かび上がってきました。 1. 業務領域ごとに専門エージェントを切り出す発想は共通 多くのテーブルで、AI エージェントを 1 つの巨大な万能エージェントとして描くのではなく、業務領域ごとに専門エージェント（パラメータ設計／Config 設定／検証／監視／チケット起票など）を切り出す構成が描かれていました。配置の仕方はテーブルによって、上位のオーケストレータが束ねる階層型、業務フローに沿ったパイプライン型、業務ごとに独立した並列型と様々でしたが、「役割を分けて、それぞれに SOP を持たせる」という発想は多くのテーブルで共通していました。 2. 既存の社内ツール・データとどう接続するかが、最大の現実論点 多くのテーブルで挙がったのが「既存の社内ツールとの接続」です。チケット管理、ナレッジ共有、ログ分析、構成管理、コミュニケーション基盤、構成情報 DB ― 各社それぞれの現場で長く使われてきたツール群があり、AI エージェントをどう “そこ” に組み込むかが、ハンズオンを「自社で動くもの」にするための最大の現実論点として浮かび上がっていました。 3. AI に任せきれない判断ポイントの設計が、各社共通の論点になっていた SOP の切り替え判断、Human-in-the-loop による承認・エスカレポイント、検証環境から商用環境への段階的適用 ― 「AI エージェントに任せきれない判断をどう設計に組み込むか」が、開発・運用業務における AI エージェント活用の論点として、複数のテーブルで共通して議論されていました。あるテーブルのホワイトボードには、エスカレポイントに 赤字で「ココが課題」 と書き込まれた付箋が貼られており、本番運用を見据えたときの設計上の難所がここに集約されていることを象徴する一場面でした。 技術を学ぶだけで終わらせず、自社・自業務への適用イメージを「絵」として描き、共通の課題感を他社の方と共有するところまで踏み込めたことが、本セッションの大きな狙いでした。各テーブルで描かれたアーキテクチャや書き出された課題の数々は、AWS として今後の支援活動を組み立てる上で、非常に貴重なインプットとなりました。 参加者の声 「AWS のイベントにドコモ／KDDI／ソフトバンク／楽天／ソニーと多くのネットワーク事業者が揃っていることに驚いたし、AWS が通信業界に深く浸透していることを実感した。」 「具体的なイメージが湧く内容でよかったです。具体化に向けて引き続きご相談させていただければと思います。」 「AI エージェントを作るためのハンズオンが丁寧に作られていて短時間でも内容が理解できました。」 「出来上がった AI Agent を体験するよりも、作る過程で AWS を使うメリットをもっと体験したかった。」 「テスト環境を触れる期間がもう少し長いと、チームメンバーにも共有しやすい。」 おわりに 本記事では、「通信事業者向けカスタム AI エージェントワークショップ」についてレポートしました。事例登壇・ハンズオン・ユースケース議論を通じて、参加された皆様にとってカスタム AI エージェントの活用イメージが具体化される一日となっていれば幸いです。また、各テーブルでの議論や他社・他部署の方との交流を通じて、業界共通の課題感を共有する貴重な機会にもなったのではないかと考えております。ご参加頂いた皆様、本当にありがとうございました。本ワークショップを通じて得られた知見やフィードバックは、今後の AWS の支援活動にも活かしてまいります。ネットワーク開発・運用 AI エージェントの導入に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。 著者紹介 宮崎 友貴 (Yuki Miyazaki) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 岡本 篤志 (Atsushi Okamoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 田中 優多 (Yuta Tanaka) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 吉川 直仁 (Naohito Yoshikawa) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。

1. はじめに こんにちは、ソリューションアーキテクトの戸塚と中本と宇加治です。 AWS Summit Japan 2026 の AWS Builders’ Fair にて、パデルフォーム分析アプリを展示します。パデルを知らない方向けに簡単に説明すると、テニスとスカッシュを合わせたような、壁に囲まれた小さめコートで 2 対 2 のダブルスだけで行うラケットスポーツです。この展示は、テクノロジーでスポーツ体験を拡張し、競技者の感覚や経験だけでは捉えにくいフォームの違いを可視化する取り組みとして、多くの方に触っていただきたい内容となっています。 このブログでは、展示の概要、使用している技術スタック、AI 駆動の開発手法、そしてこのシステムが解決する課題と他インダストリーへの応用可能性についてご紹介します。エンジニアの方もたくさん参加されていると思うので、ぜひ技術的な観点からも楽しんでいただければ嬉しいです。 2. AWS Summit Japan 2026 について AWS Summit Japan 2026 は、2026年6月25日から26日まで幕張メッセで開催される、クラウドと AI イノベーションの最前線を体験できる 2 日間の無料イベントです。260 以上のセッションに加え、AWS Village、ワークショップ、Partner Solution Expo など多彩なコンテンツが用意されています。AWS Builders’ Fair エリアは、AWS エンジニアが自作した “遊べる” デモを体験しながら、AI・IoT・サーバーレスなどの活用事例を学べるハンズオン型の展示ゾーンとなっています。来場者は自由にブースを回り、生成AI・IoT・サーバーレスなどを組み合わせたインタラクティブなデモを、実際に触ったり遊んだりしながら体験できます。 3. パデフォーム分析アプリ展示概要 このアプリは、 Meta Quest （VR ヘッドセット）、 HaritoraX （モーションキャプチャデバイス）、カメラによる骨格推定技術（ MoveNet ）を組み合わせ、バーチャル空間でパデルの球出しを受けた際の動作を計測・分析する仕組みです。 単にスイングを記録するだけではなく、身体の各部位の動きやタイミングの差分をとらえ、トッププレーヤーのフォームと比較評価できるように設計しています。 3.1 体験の流れ VR 空間で球出しを受ける — Godot で構築された 3D 空間内でプレー リアルタイムモーションキャプチャ — HaritoraX + カメラで動作データを取得 フォーム分析 — DTW(Dynamic Time Wrapping) アルゴリズムでトッププレーヤーのフォームと比較　※ 結果表示 — 5 指標のスコアカード + 生成 AI によるアドバイス VR、Haritora、カメラの３つのソースを統合して、最終的に 5 つの指標として評価するように実装しています。 写真: VR 空間でプレーする体験者の様子 図: 5つの評価指標を算出するための各データソースの役割 ※骨格推定には OpenPose や MoveNet といったスポーツ動作分析の標準手法を使っています。時系列比較の DTW は、 Ba č i ćらが 2022 年の VISAPP でストローク分類に使用しています。プロとの比較は Stanford の Liu が 2025 年に DTW によるプロ対アマ比較 を行っています。フェーズ分割はバイオメカニクスの標準的なアプローチとなっています。 写真: リアルタイムモーションキャプチャのデータ確認画面 ゲームとして楽しめるだけでなく、トレーニングにもなる設計を目指しています。プレイヤーは VR 空間の中でさまざまなボール（レボテやコントラパレットを含む）に対応することになり、楽しみながらフォームの改善ポイントを発見できます。 3.3 トッププレーヤーの教師データ 事前計測には、パデルトッププレーヤーとして久留広平選手、内海信仁選手、瀧田瑞月選手、内海和心選手に AWS オフィスへお越しいただきました。計測で取得したデータは、すでにアプリ内の教師データとして実装されており、体験者は彼らのフォームとの差異を比較できるようになっています。 この仕組みの面白さは、単に「上手い・下手」を判定することではありません。トッププレーヤーの動作を基準にすることで、打点の入り方、身体の回旋、重心移動、準備動作の速さなど、普段は言語化しにくい技術要素を、比較可能な形で捉えられる点にあります。 また、コーチングや自己改善の文脈でも活用しやすいのが特徴です。感覚に頼りがちなフォーム指導に対して、再現性のある比較軸を持ち込めるため、競技経験者はもちろん、これから上達したいプレーヤーにとっても新しい学習体験になり得ます。 写真: 計測結果のスコアカード画面（数値化 + 生成 AI アドバイス） 3.4 トッププレーヤーからのコメント 教師データ計測に協力いただいた選手から、本システムを実際に使用した感想をいただきました。システムの可能性を評価する前向きなコメントに加え、今後の活用方法に関するアイデアも頂戴しました。 ■ 久留 広平選手(日本代表) コーチの視点では、フォームや身体の使い方を指導する際に選手がイメージしている動作と実際の動作に乖離が見られるケースがあり、そのような場面でデータに基づくフォーム分析を活用することで、効果的な指導につなげられると感じました。 ■ 内海 信仁選手(ベテラン日本代表) 日本は世界から30年のビハインドがあり、中東、東南アジアは英語が話せるアドバンテージでどんどん差を埋めていますが、日本はそれが出来ていません。それをテクノロジーで埋めていくというのは日本らしさがあってとても素晴らしいと感じました。 ■ 瀧田 瑞月選手(2018〜2023 日本代表 2025年 Jr 日本代表サブコーチ) 率直に、これからの可能性にとてもワクワクしました。パデルに限らず、エンターテインメントやコーチング、競技力向上など、さまざまなカテゴリーで活用できる可能性を感じました。今後どのように発展していくのか、とても楽しみです。 ■ 内海 和心選手(日本代表) 自分の足りないところやいいところを見つけてくれるところが面白いと感じました。プロと比べて何が劣っているかとか見つかるところが今後の成長に繋がりそうだと思いました。 4. システムアーキテクチャ 4.1 全体構成 この展示は、スポーツテック、XR、センシング、コンピュータビジョンを横断する実験でもあります。Meta Quest による没入的な体験、HaritoraX によるモーションキャプチャ、カメラベースの骨格推定による姿勢解析を組み合わせることで、単一センサーだけでは捉えきれないフォーム情報を多面的に扱えるようにしています。VR アプリ構築には、Unity や Unreal Engine なども候補にあがりましたが、今回は費用も極力抑えることを考え、完全無料でオープンソースの Godot を採用しました。Godot は、Python に似た独自の言語「GDScript」を使います。文法がシンプルで読みやすいため初心者でも学習しやすい設計になっています。もちろん C# や C++ も使うことができます。今回はこの GDScript 等を Kiro の力を活用することで、自然言語でのやりとりでこのような VR アプリのオブジェクトや VR 空間での挙動までもプログラミングしているので、GDScript の学習コストはかかりませんでした。 本システムは以下のコンポーネントで構成されています: 図: システム全体概要 レイヤー 技術 用途 VR / 3D 空間 Godot Engine VR空間内でのパデル球出しシミュレーション。自然言語（Kiro）で開発 VR デバイス Meta Quest VR ヘッドセットによる没入体験 モーションキャプチャ HaritoraX 身体トラッキング（全身の動きを取得） 骨格推定 MoveNet (TensorFlow Hub) カメラ映像からリアルタイム骨格推定（17 キーポイント） フロントエンド Tauri v2 + React + TypeScript + Vite デスクトップアプリ（結果表示・操作 UI） バックエンド バックエンド Python FastAPI + Uvicorn リアルタイム分析 API（WebSocket 対応） フォーム比較 DTW (Dynamic Time Warping) 時系列データの非線形マッチングによるフォーム比較 クラウド AWS CDK (ECS Fargate + ALB + S3 + DynamoDB) 評価処理のオフロード、スコア永続化、ランキング AI フィードバック Amazon Bedrock スコアに基づくパーソナライズされた改善アドバイス エッジ側で動くアプリケーションは AWS IoT Greengrass の OTA (Over the Air)アップデート を使ってアプリ配信をする仕組みをとっており、複数拠点にあるアプリを遠隔で更新できる様にしています。また計測後のフィードバックは骨格推定を含んだ動画も見れるようになっており、動画配信は Amazon CloudFront を活用してレイテンシーが抑えられる形にしています。 図: エッジ側を含めた AWS 構成 4.2 AI 駆動の 3D 開発: Kiro × Godot 今後、3D や VR の需要はさらに高まっていくと見られます。一方で、3D プログラミングは従来、空間座標やベクトル演算、物理エンジンの理解など専門性が高く、参入障壁が高い領域でした。 今回のプロジェクトでは、Godot Engine を使った 3D 空間のプログラミングを、Kiro（AI コーディングアシスタント）を用いた自然言語プログラミングで実施しています。たとえば「ボールを放物線で飛ばしてラケットの当たり判定を追加して」「壁に当たったらレボテ（跳ね返り）する物理を実装して」といった指示で、3D 空間の挙動や空間認識のロジックを実装できました。 これにより、3D/VR 開発の経験が浅いエンジニアでも、アイデアを素早くプロトタイピングし、スポーツシミュレーションのような複雑な 3D アプリケーションを構築できることを示しています。AI 駆動の開発が、従来は専門家の領域だった 3D プログラミングの民主化を進める一例と言えます。 4.3 モーションキャプチャデータ連携の技術的課題 本システムの開発で最も技術的に挑戦的だったのは、異なるモーションキャプチャソースからのデータ統合です。 具体的には以下の課題がありました: 座標系の統一: HaritoraX（慣性式）、Meta Quest（光学式）、MoveNet（画像ベース）はそれぞれ異なる座標系・スケールで動作データを出力します。これらを統一的な骨格表現に変換する必要がありました。 データ同期: デバイスごとにサンプリングレートが異なり（カメラ 30fps、HaritoraX 100Hz 等）、時刻同期とリサンプリングの仕組みが必要でした。 欠損補間: オクルージョン（身体の一部が隠れる）時のデータ欠損を、他デバイスのデータで補間する戦略を設計しました。 リアルタイム性: 分析結果を体験者にすぐフィードバックするため、WebSocket 経由でのストリーミング処理パイプラインを構築しました。 これらの課題に対して、Kinesis 経由でデータを送りつつ UNIX タイムの時間同期、骨格情報との相対位置によるキャリブレーションにより統合し、クラウドと連携して分析する — これはまさに AWS が得意とする領域です。 5. 今後の可能性 5.1 このアプリが解決する課題 スポーツの世界では、トップ選手の技術は見えているようで、細部まではなかなか共有されません。コーチングの現場でも、「もっと腰を回して」「タイミングが遅い」といったフィードバックは、指導者の主観に依存し、再現性に乏しいものでした。 本システムは以下の課題を解決します: フォーム指導の属人化: 感覚的な指導を定量データに置き換え、再現性のある比較軸を提供 上達実感の欠如: スコアの時系列推移を記録し、小さな改善も可視化 トップ選手の技術の暗黙知化: 動作データとして記録し、比較可能な形でアクセス可能に フィードバックの即時性: リアルタイム計測 → 即座にスコア表示、改善ポイントを AI が提示 エンゲージメントの低下: VR ゲームとして楽しみながらトレーニングできる体験設計 5.2 他インダストリーへの応用可能性 本システムのコアである「モーションキャプチャ × AI 比較分析 × リアルタイムフィードバック」は、パデルに限らず幅広い分野に応用可能だと考えています。以下にユースケースを示します。 インダストリー 応用例 期待効果 スポーツ全般 テニス、ゴルフ、野球のスイング分析、サッカーのキック分析 定量的なフォーム改善、怪我予防 リハビリ・ヘルスケア 理学療法での動作評価、リハビリ進捗の定量モニタリング 回復度の客観的評価、遠隔リハビリ 製造業 作業員の動作分析、熟練工の技能伝承 品質向上、教育期間短縮 エンターテインメント ダンスや演技のフォーム評価、モーションキャプチャ活用 パフォーマンス向上、ゲーミフィケーション フィットネス パーソナルトレーニングのフォームチェック、ヨガのポーズ評価 トレーナー不在時の自己改善 介護・高齢者支援 歩行分析、転倒リスク評価 早期異常検知、予防介護 技術的には、DTW による時系列比較は人間の動作全般に適用可能であり、教師データ（基準動作）を差し替えるだけで異なるドメインに展開できます。AWS のクラウドインフラ（AWS Lambda, Amazon S3, Amazon DynamoDB,Amazon Bedrock, AWS IoT Greengrass等）を活用することで、スケーラブルかつ低コストな運用が可能です。 5.3 今後の展望 今回の展示はデモでありながら、今後の展開余地が大きい取り組みでもあります。 プレーヤーごとの癖や成長過程の可視化 ショット別の比較分析（フォアハンド / バックハンド / ボレー / バンデッハ） レベル別の推奨フィードバック コーチとの振り返り支援（セッション動画 + スコアの共有） 「どのトッププレーヤーのフォームに近いか」のパーソナライズ分析 マルチスポーツ対応（テニス、バドミントン、ゴルフ等） 写真: 教師データとして協力いただいたパデルトッププレイヤーの皆様 6. ぜひ会場で体験してください AWS Summit Japan 2026 の AWS Builders’ Fair は、遊び心あふれるテクノロジー展示を実際に見て、触って、開発者と会話できる場です。パデルフォーム分析アプリも、スポーツとテクノロジーが交わる体験を、できるだけ直感的に楽しんでいただけるよう準備しています。 ブースでアプリを体験いただいた方には、Amazon Padel ステッカーを配布予定です。AWS Summit Japan 2026 に参加される方は、ぜひ Builders’ Fair に立ち寄って、トッププレーヤーとのフォーム比較を体験してみてください。 AWS Summit Japan 2026 公式サイト: https://aws.amazon.com/jp/summits/japan/ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 中本 翔太(Shota Nakamoto) ネットワークチームに所属するソリューションアーキテクトで、サービス業界のお客様を中心にご支援をしています。 宇加治 邦生(Housei Ukaji) サービス業界のお客様を中心にご支援をしています。好きな AWS サービスは Kiro CLI です。

2025 年 3 月に Amazon OpenSearch Service による検索ワークショップ（日本語版）のご紹介 という記事を公開し、OpenSearch の基本概念から AI を活用した検索までを学べる日本語ワークショップをご案内しました。 このたび、2 つの日本語版ワークショップが仲間入りいたしましたので、ご紹介いたします。 EC サイト検索ワークショップ ：架空の EC サイトを題材に、検索機能を全文検索からセマンティック検索、マルチモーダル検索、エージェント検索へと段階的に育てていくワークショップです。また、ユーザーの行動ログを使った品質計測、機械学習による最適化を体験いただける実験的なラボも付属しています。 OpenSearch Observability Stack ワークショップ ：OpenSearch を Observability のバックエンドとして使い、マイクロサービスの APM・ログ・メトリクスを横断しながら、Agentic AI も活用して障害の原因を調査するワークショップです。Agent Trace といった新しい OpenSearch の Observability 関連機能もお試しいただけます。 以降、2 つのワークショップの概要について説明してまいります。 EC サイト検索ワークショップ 架空の企業「AnyCompany」が運営する EC サイトを題材に、商品検索を少しずつ改善していくシナリオ形式のワークショップです。OpenSearch の全文検索の導入からスタートし、ファセットやセマンティック検索、エージェント検索に至るまで検索機能を段階的に進化させていきます。 FastAPI + htmx による EC サイト風の検索 UI が付属しており、機能追加によって検索結果がどのように変化していくかを実際に比較・確認しながら進めることが可能です。 本ラボは Amazon SageMaker Studio の JupyterLab 上でノートブックを順次実行しながら進めていきます。商品のマスター情報は Amazon Aurora PostgreSQL に、検索インデックスは Amazon OpenSearch Service に格納されています。各種 ML モデルへのアクセスは、OpenSearch の connector を経由して行われます。 主要なリソースは以下のとおりです。 リソース 用途 Amazon OpenSearch Service 検索エンジン Amazon Aurora Serverless v2 商品マスターデータ（PostgreSQL） Amazon SageMaker Studio ノートブック実行環境（JupyterLab） Amazon SageMaker AI Embedding モデルのホスティング Amazon Bedrock LLM の利用（Agentic Query） ワークショップの構成 本ワークショップは 2 つのトラックが存在します。トラック A のみでもお楽しみいただけますが、トラック B まで実行することでより検索に対する理解を深めることができます。 トラック A: 検索機能の改善 トラック A は機能の改善にフォーカスしています。4 つのラボで構成されています。 全文検索の導入: OpenSearch の全文検索を導入し、形態素解析器 Sudachi による日本語トークナイズ、複数フィールドをまたいで検索する multi_match 、関連度スコアによるランキングを実装します。検索エンジンがなぜ高速に全文検索できるのか、その心臓部にあたる転置インデックスの仕組みにも触れます。 セマンティック検索の導入: テキストの「意味」で探すセマンティック検索を導入します。OpenSearch 3.1 で追加された semantic フィールドを使えば、インジェストパイプラインを書かずにベクトル検索を実現できます。Embedding モデルには日本語特化の ruri-v3-310m（Apache 2.0）を SageMaker エンドポイントで利用し、BM25 とセマンティック検索を組み合わせたハイブリッド検索も体験します。 マルチモーダル検索の導入: テキストだけでなく、画像で商品を探す体験を追加します。「この写真に似た商品を探して」といったユースケースに応えるため、画像とテキストを同じベクトル空間にマッピングする CLIP（clip-japanese-base-v2）を使います。Ingest Pipeline の text_image_embedding プロセッサが投入時に画像を自動でベクトル化するので、テキストから画像を探す検索と、画像から似た画像を探す検索の両方を、1 つのベクトルフィールドだけで実現できます。 エージェント検索の導入: OpenSearch 3.2 で追加された Agentic Query を使い、自然言語で商品を検索できるようにします。ユーザーの質問を LLM が QueryDSL に変換し、思考の過程も含めた結果を出力します。Amazon Bedrock 上の Anthropic Claude モデルと組み合わせて、検索バーに軽量な Flow Agent（Claude Haiku 4.5）を、チャット UI にはメモリ機能をサポートした Conversational Agent（Claude Sonnet 4.6）を搭載し、その違いを比較します。 トラック B: 計測と改善 トラック B は計測と精度改善にフォーカスしています。3 つのラボで構成されています。 ユーザー行動ログの蓄積と分析: UBI（User Behavior Insights）は、検索クエリ・クリック・カート追加・購入といったユーザー行動を、標準スキーマで記録する仕組みです。本ワークショップではサンプルの行動データを使った分析を実際に体験します。 検索品質評価: UBI データを使って、検索品質を数値で評価します。Search Relevance Workbench（SRW）と呼ばれるツールを活用し、テキスト検索やハイブリッド検索等の各種検索手法がどのようなクエリで有効であるかを評価指標に基づいて分析します。人間による分析に加えて、MCP + Strands Agent を活用したエージェントによる分析も応用パートとして提供しています。 Learning to Rank: UBI データと SRW の判定セットを学習データに使い、XGBoost（LambdaMART）でモデルを学習します。そして、ハイブリッド検索で絞り込んだ上位を LTR で並べ替える 2 段階ランキングを構築します。特徴量は BM25 派生のものから始め、人気度や在庫といったビジネス特徴量、さらにユーザーのペルソナを段階的に組み込んでいきます。 OpenSearch Observability Stack ワークショップ OpenSearch Observability Stack は、OpenSearch と Prometheus をバックエンドとした、Observability プラットフォームです。Piped Processing Language (PPL) によるトレース・ログ・メトリクスの分析、ダッシュボード上での可視化、Agent Trace、アラートや異常検知といった機能を OpenSearch UI と呼ばれるダッシュボードを通じて利用することができます。Ask AI と呼ばれる機能を活用した AI によるインシデント分析も可能です。 このワークショップでは、16 のマイクロサービスで構成されている EC サイトで発生した問題を、OpenSearch Dashboards の Observability 機能と Agentic AI（AI アシスタント）を用いて調査を行いながら各機能についての理解を深めていく内容となっています。 OpenTelemetry Demo （EC サイトを模した 16 のマイクロサービス）を Amazon EKS 上にデプロイし、OpenTelemetry Collector が集めたトレース・ログ・メトリクスを Amazon OpenSearch Ingestion（OSIS）と Amazon Managed Service for Prometheus（AMP）に送り込む構成となっています。 OSS 版ではセルフホストが必要な部分を AWS マネージドサービスに置き換えているため、参加者はインフラの構築ではなく、Observability の体験そのものに集中できます。 ワークショップの流れ ラボは基本的に任意の個所から開始することが可能ですが、順番に進めることでよりスムーズに理解を深めることができます。 ラボ 1. Application Performance Monitoring による調査 Application Map でサービス間の依存関係とエラー率を一目で把握し、RED メトリクス（Rate, Errors, Duration）から問題のあるサービスを判定、関連するトレースやログを確認していきます。 ラボ 2. Ask AI によるサービス障害調査 OpenSearch Dashboards に組み込まれた Ask AI に、「直近で一番エラーの多いサービスは？」と自然言語で尋ねるところから始めます。Investigation Agent が、複数のデータソースを自律的に横断して根本原因の仮説を立て、その調査過程をノートブックとしてまとめる様子を見ることができます。 ラボ 3. Discover による分析 ログ・トレース・メトリクスを、PPL（Piped Processing Language）や PromQL を活用して横断的に掘り下げて分析します。 ラボ 4. Dashboard に集約する Discover で作成した Visualization を Dashboard に集約し、チームで共有できる運用ダッシュボードを構築します。 ラボ 5. 異常検知・アラート・Forecast OpenSearch の組み込み ML を使い、Anomaly Detection（Random Cut Forest）による異常検知、Alerting による通知、Forecasting による将来の予測を設定します。 その他のラボ 本ワークショップでは、他にも応用的なラボをいくつか提供しています。 例えば、Agent Trace と呼ばれる機能を活用して、Amazon Bedrock 上の Anthropic Claude を使った商品レコメンドエージェントが生成する gen_ai.* スパンを分析し、Agent の思考の流れ（Agent Graph）やトークン使用量の可視化などを体験することができます。 ワークショップの始め方 Workshop Studio にアクセスし、トップページから取り組みたいワークショップを選んでください。 各ワークショップには CloudFormation テンプレートが付属しており、ご自身の環境に必要な AWS リソースを簡単にデプロイすることが可能です。ご自身の AWS アカウントでも、AWS イベント会場で Workshop Studio が払い出す一時アカウントでも実施できます。 リソース展開後は、SageMaker Studio（JupyterLab）もしくは OpenSearch Dashboards にアクセスし、ノートブックや Workshop Studio サイトの手順に沿って学習を進めていきます。 なお、ご自身の AWS アカウントで実施する場合は、OpenSearch・Aurora・SageMaker・EKS などのリソース利用に応じた料金が発生します。ワークショップを終えたら、クリーンアップ手順に従ってリソースを削除してください。 まとめ 今回追加された二つのワークショップはいずれもユースケースに即した内容となっており、一連のラボを通して OpenSearch に関する最新の知見や活用イメージの把握に繋げることができます。 EC サイト検索ワークショップでは、検索機能を段階的に育て、その効果を計測し、機械学習で改善するまでの一連のサイクルを体験できます。OpenSearch Observability Stack ワークショップでは、検索エンジンとは違う一面、Observability のバックエンドとしての OpenSearch と、Agentic AI を取り入れた分析を体験することができます。 検索から Observability、そして AI Agent の活用まで、ハンズオンを通して OpenSearch の可能性に是非触れてみてください。 関連リンク Amazon OpenSearch Service Amazon OpenSearch Service Workshops [Japanese] 前回のブログ：Amazon OpenSearch Service による検索ワークショップ（日本語版）のご紹介 OpenSearch Observability Stack OpenTelemetry Demo ソリューションアーキテクト 榎本 貴之 (X: @tkykenmt )

2026 年 6 月 17 日、 ニューヨーク市で開催された AWS Summit では、AWS VP of Agentic AI である Swami Sivasubramanian が基調講演を行いました。 このイベントでの主な発表のまとめをご紹介したいと思います。 Amazon Bedrock AgentCore の新機能 Amazon Bedrock AgentCore に新機能を導入します。AI エージェントを組織、ウェブ、有料のナレッジにつなげたり、チームが本番環境で起きている問題を発見して修正できるようにしたり、エージェントの能力が向上するにつれてスケールできる制御を適用したりできるようになります。 これらの機能を組み合わせることで、より有能なエージェントを迅速に構築し、スケール可能な制御を使用してエージェントを管理し、継続的に改善することができます。詳細については、すべての新機能を網羅した ブログ記事 をご覧ください。 より高速で正確なエンタープライズ AI アプリケーションのための Amazon Bedrock Managed Knowledge Base のご紹介 – Bedrock のマネージドナレッジベースを使用してエンタープライズ RAG パイプラインを構築できます。ネイティブデータコネクター、自動マルチフォーマットデータ準備用のスマート解析、複雑な複数ステップのクエリ用のエージェンティックリトリーバーが提供され、これらはすべて AgentCore Gateway と統合されているため、開発者はインフラストラクチャ管理ではなくビジネス成果に集中できます。 Amazon Bedrock AgentCore でのウェブ検索の発表:AI エージェントに最新の正確なウェブ知識を身につけさせる – フルマネージド型のウェブ検索ツールを使用すると、エージェントはお客様の安全な AWS 環境からのデータ流出なしに、最新の引用ウェブ知識に基づいて回答を行うことができます。Bedrock AgentCore のエージェントに手動でウェブ検索を追加してインフラストラクチャを管理するのではなく、エージェントの構築に集中できます。 AWS WAF に AI トラフィック収益化機能が追加され、コンテンツ所有者による AI ボットへのコンテンツアクセス料金の請求が可能に – コンテンツプロバイダーやパブリッシャーは、コンテンツや API にアクセスする AI ボットとエージェントに請求する料金を調べ、計測し、支払いを回収する新しい Bot Control 機能を使用できます。AWS WAF では、そのアクセスの料金を設定したり、サードパーティープロバイダーを通じて支払いを受け付けたり、範囲を指定したアクセスをエッジで直接付与したりできるようになりました。 Amazon Bedrock AgentCore ハーネスを一般公開 – Bedrock AgentCore ハーネスを使用してエージェントのモデル、ツール、スキル、設定手順を定義することで、オーケストレーションループをコーディングすることなく、プロダクショングレードの AI エージェントを数分で構築して実行できます。 AI ベースのセキュリティツールの新機能 AWS Continuum のご紹介: マシンスピードのセキュリティ – コードの脆弱性に対応する AWS Continuum では、ゲーテッドプレビュー形式で環境全体から調査結果を取得し、ビジネスへの影響に基づいて優先順位を付け、悪用可能なものを証明し、お客様独自のプロセスで修正を行うことができます。 AWS セキュリティエージェント (現在は AWS Continuum の一部) が脅威モデリング、Kiro パワー、Claude Code プラグインなどを追加 – 新しい脅威モデリング (プレビュー) を生成すると、アプリケーションのコンテキスト全体を理解し、STRIDE フレームワークを使用して推奨される緩和策で脅威を特定できます。また、主要な Git プラットフォーム全体でプルリクエストコードスキャンと修復機能を利用したり、Kiro パワー、Claude Code プラグイン、MCP を介して IDE を統合したりすることもできます。これにより、開発者はコンテキストを切り替えることなくセキュリティレビューを実行して問題を解決できます。 AI ベースのアプリケーション構築の新機能 Kiro for iOSのご紹介 – Kiroは、ゲーテッドプレビューで利用できるネイティブ iOS アプリを発表しました。これは実際のエンジニアリング作業向けに構築されており、Kiro セッションをスマートフォンから直接開始、監視、操作できる新しい画面が開発者に提供されます。つまり、ノートパソコンを起動していなくても、セッションを開始したり、完了したら確認したり、差分を確認したり、変更を承認したりできます。 AWS DevOps エージェントが、本番前にコードの変更を評価するリリース管理機能を追加 – コード変更の新しいリリース準備状況レビューと自律リリーステストを利用できます。これらの新機能は、すべての変更を DevOps Agent に提供する自然言語標準に照らして検証し、本番環境と同様の環境で変更固有のテストを実行します。 AWS Transform で自律的に技術的負債を積極的に削減 – 継続的なモダナイズ – 継続的分析 (プレビュー) を使用して、設定可能なベースラインと照らし合わせてコードリポジトリを自動的にスキャンし、数週間ではなく数時間で結果を生成できます。検出結果を特定して優先順位を付けたら、影響を受けるリポジトリのプルリクエストを自動的に生成する自律的な修復を設定できます。 基調講演に加えて、今週は他にも重要な発表があります。 Amazon S3 アノテーション: 豊富でクエリ可能なコンテキストをオブジェクトに直接アタッチ – Amazon S3 ではアノテーションを使用して、最大 1 GB のリッチで変更可能かつクエリ可能なコンテキストをオブジェクトに直接アタッチできるようになりました。これは、個別のメタデータシステムを維持することなく大規模なデータを発見、理解、処理する必要のある AI エージェントや自律型ワークフロー向けに構築されています。 原文は こちら です。

AWS では、AI を活用した新しいソフトウェア開発手法「 AI-DLC（AI-Driven Development Life Cycle） 」を提唱しています。AI-DLC は、AI を単なる補助ツールとしてではなく、要件定義から設計・実装・テストまでの開発ライフサイクル全体に組み込みながら、人間が主導権を握る（Human-in-the-Loop）ことを前提とした開発手法です。そして、この AI-DLC を 3 日間で体験・実践いただくワークショップが「AI-DLC Unicorn Gym（以下 UG）」です。 2026 年 5 月 18 日〜20 日、日立のオフィスにて「日立グループ合同 AI-DLC UG」を開催しました。本記事では、その開催レポートをお届けするとともに、ワークショップを企画・伴走した AWS Japan カスタマーソリューションズ マネージャー 早川 康平が、日立グループ社内で AI 駆動開発ワーキンググループの立ち上げを牽引されるキーマン、株式会社日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 チーフクラウドアーキテクト 早川 裕志 氏にお話を伺いました。 1. 日立グループ合同 AI-DLC Unicorn Gym 開催レポート 日立グループ合同 AI-DLC Unicorn Gym（2026 年 5 月 18〜20 日）。3 社・8 チーム・52 名が参加した 今回の合同開催に先立ち、2026 年 1 月には株式会社日立産業制御ソリューションズが AI-DLC Unicorn Gym に参加され、従来 3 人月規模の開発を、わずか 2 日間で動くものとして作り、AWS にデプロイするところまで完了させるという成果を出されています（詳細は こちらの記事 ）。この先行事例での手応えが、今回の日立グループ合同開催へとつながりました。 当日は、日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 事業主管 鈴木 肇 氏、AWS Japan エンタープライズ事業統括本部 Hitachi事業部本部長 吉井の開会の挨拶から始まりました。 今回の UG には、日立製作所、日立ハイテク、日立産業制御ソリューションズの 3 社・8 チーム・52 名にご参加いただきました。顧客向け Web ポータル、半導体製造向け検査支援ツールなど、各チームが実際の業務テーマを持ち寄りました。 各チームに AWS のメンバーが伴走し、実テーマの開発を進めた 開催後のアンケートでは、他社での UG 実績と比較しても非常に高い評価をいただきました。 全体満足度：5 点満点中 4.67 日立グループへの推奨意向：回答者の 100% が「ぜひ／強く薦めたい」 「AI-DLC は働き方を変える可能性がある」：回答者の 92% が肯定 開発工数の削減について、回答者の 90% が「70% 以上の削減」を、72% が「85% 以上の削減」を体感 回答者の 95% が、3 日間で「動作する成果物」に到達または部分到達 参加者からは「AI 駆動開発の威力に驚いた（推論プロセスの追跡や影響範囲の可視化）」「製造スピードが段違い」といった声が寄せられた一方、「Coding Agent の社内払い出しの簡素化」「大規模開発のプラクティス」「品質保証との両立」といった、本番適用に向けた改善の要望もいただきました。 この結果は、日立グループが掲げる成長エンジン「Lumada 3.0」をより高速に生み出すための開発手法の 1 つとして、AI-DLC の可能性を示すことができたものと考えています。 2. 推進キーマンインタビュー ここからは、AI-DLC UG にも参加され、日立グループ展開に向けた AI 駆動開発ワーキンググループの立ち上げを牽引される早川 裕志 氏と、今回の AI-DLC UG をリードした AWS Japan カスタマーソリューションズ マネージャー 早川 康平との対談をお届けします。 株式会社日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 チーフクラウドアーキテクト 早川 裕志 氏 アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションズ マネージャー 早川 康平 想像を超えた、社内の反響 早川 康平（AWS） では、お願いします。「早川対談」、ようやく実現しましたね。 早川 裕志（日立） 早川 × 早川、楽しみにしていました（笑）。 早川 康平（AWS） ブログにするときは、お二人が区別しやすいように工夫します（笑）。では、さっそく。第 1 回となる日立グループ合同 AI-DLC UG、開催後の反響はいかがでしたか。 早川 裕志（日立） 実は私どもでもアンケートを取らせていただいたのですが、満足度は 5 点満点で 4.7 を超えていました。社内で改善というと「2 割」「15%」といった数字が並ぶなかで、 開発工数が大幅に減ったという結果は劇的で、インパクトがすごかった 。一方で、数字が大きすぎたことで「小さなテーマだからそうなんでしょ」という声も生まれました。それをどう払拭していくか、というところに、むしろモチベーションが湧いてきた感覚です。 早川 康平（AWS） 先日、今回ご参加いただいたチームの本部長の方にもご報告したのですが、同じような反応をいただきました。「2 カ月の開発が 2 日になった、と聞いたが、本当なのか」と。ここは正直にお伝えしています。今回 UG で各チームが取り組んだのは、実際の業務テーマで動くものを作り、AWS にデプロイするところまでで、その速さは確かな成果です。ただ、それをお客様に提供する本番システムとして世に出すには、日立が積み上げてこられた品質保証の工程──テスト、承認、レビューなど──を通す必要があります。つまり 「動くものをデプロイするまでの速さ」と「本番リリースまでの工数」は別物 で、今回の数字は前者にあたります。だからこそ、その品質保証の工程まで織り込んだ「日立版 AI-DLC」にしていく必要がある、と考えています。 最大の壁は、技術ではなくマインドセット 早川 裕志（日立） 今回、参加者の多くが AI-DLC にとても前向きで、感銘を受けました。その一方で、「AI に仕事を奪われるのではないか」という、いわば積み重ねてきたアイデンティティへの不安を抱える人もいます。どんなにいいと思っていても、どこかに反発するラインがある。そこをどう越えるかは、トップダウンでもボトムアップでも、 技術だけでは解決できない問題だと感じています 。 早川 康平（AWS） 大事なのは発想の転換だと思っています。たとえば 10 人で 1 年かけて 1 つのプロダクトを作っていたなら、これからは同じ 10 人で 1 年に 10 プロダクト作ろう、と。リリースと改善のスピードを何倍にも上げていく。とくに AI 時代はあらゆるプレイヤーが一気に立ち上がる群雄割拠の世界です。これまでのリリーススピードのままでは、もう他社に太刀打ちできない。AI-DLC は、 人を減らすための手法ではなく、生み出す価値を増やしスピードを上げるための手法 です。そういうポジティブな方向に向けられたら、と思っています。 早川 裕志（日立） UG を見学していて、最初はみんなギクシャクしているなと感じました。でも、どこかで一気に盛り上がるラインがある。AI-DLC UG では、ビジネスサイド（PdM）とエンジニアが膝を突き合わせて、常に議論しながら一緒に意思決定していきます。「誰が何を、どう決めるか」というプロセスそのものが従来と変わるので、最初は慣れないんですね。でも、そのラインを越えると一気に変わります。その場で議論して決めたことが、すぐ目の前で形になっていく。 役割の壁を越えて一緒に作っている感覚 があって、見ていてもチームが生き生きしてくるのが分かりました。この協働の体験そのものが、何よりの価値だと思いました。 AI-DLC は「品質を犠牲にスピードを出す」手法ではない 早川 康平（AWS） ここはよく誤解されるところなので、この場でもはっきり言っておきたいのですが、AI-DLC を「品質を犠牲にして生産性を爆上げする手法」だと捉える方がとても多い。それは違います。 AI-DLC の本質は、人間が開発の主導権を握り続けること（Human-in-the-Loop）にあります 。AI が計画や実装の草案を担い、何を作るか・採用するかという重要な判断は人間が下す。だからこそ、AI が解釈した「それっぽいもの」ではなく、意図したとおりのものを、速く作れるのです。 では、どこで品質を担保するのか。AI-DLC では開発ステップを明確化し、工程ごとに人間の承認ゲートを設けます。AI が作るのはあくまで草案で、承認を経て初めて人間の成果物になる。速さのために品質を犠牲にしているわけではなく、 むしろ人間が要所を押さえることで、速さと品質を両立させる ──ここは正確にお伝えしていく必要があると考えています。 早川 裕志（日立） そこは私も強く共感するところです。今後、必ず「AI が生成するコードの品質はどうなんだ」という指摘が出てきます。ただ、これは「人間のほうが AI より品質が高い」という単純な話ではないんですよね。日立には、長年積み上げてきた品質保証のプロセスがあります。事業部によってそのかたちは違いますが、その積み重ねこそが私たちの強みです。AI に任せきりにするのではなく、 その品質保証のプロセスを AI-DLC の進め方そのものに織り込んでいく 。そこができて初めて、日立として安心して本番に使える、と言えるのだと思います。 早川 康平（AWS） おっしゃるとおりで、まさにそこが「日立版 AI-DLC」の肝になります。 「日立版 AI-DLC ワークフロー」を、各現場で育てる 早川 康平（AWS） そのために、日立版の AI-DLC ワークフローを作る必要があります。AWS が GitHub で公開している AI-DLC Workflows をベースに、まずは日立として最低限守るべきものを 1 つの「汎用版」として整える。 それを各事業部・グループ会社が Fork（複製）して、それぞれに合わせてカスタマイズしていく ──というのが現実的だと考えています。 早川 裕志（日立） 日立グループは幅広いんです。SIer としての顔もあれば、事業会社としての顔もある。金融、公共、鉄道……それぞれ品質基準がまったく違います。共通化できる「ベーシックなライン」は AI-DLC で一緒に作り、 最後のカスタマイズ（ラストワンマイル）は各現場が地道に埋めていく 。そのバランスが大事だと思っています。 日立 AI 駆動開発ワーキンググループの構想を語る 早川 裕志 氏 日立 AI 駆動開発ワーキンググループの立ち上げ 早川 康平（AWS） その推進母体として、日立社内に AI 駆動開発ワーキンググループを立ち上げる、と。 早川 裕志（日立） はい。詳細は今後発表していきますが、特定の事業部に閉じず、各 BU・グループ会社から広くメンバーを集めたいと考えています。AI-DLC を一緒にやりたいと言ってくれている熱意あるフロントのメンバー、そして品質保証の担当者を巻き込んで。「小さく始めて大きくする」とよく言いますが、私はむしろ 「広く、小さく」始めたい 。熱意のある人たちで、AI 駆動開発をグループ全体に広めていきましょう。やり方はいくつもありますが、そのなかでも最も有力なアプローチとして、AI-DLC を使って始めていく考えです。 もう「AI を活用するかどうか」を議論する時代は終わった と思っています。AI が当たり前になる時代です。AI の効果は複利で効きます。早くやらないと本当についていけなくなるし、早く動けば、その分だけ事業リターンも大きい。だからこそ、AWS さんには単に支援していただくというより、 日立グループのための AI 活用パートナーになってほしい 。ぜひ、ご一緒させてください。 3. AWS の今後の支援 日立グループの AI 駆動開発を、ともに前へ進めていく AWS は、日立グループの AI 活用パートナーとして、全力で支援してまいります。 まず認知を広げるために、今後日立グループ向けの AI イベントを毎月企画していきます。Coding Agent（Kiro、Claude Code）のハンズオン、AWS Ambassadors と連動した社内向けイベント、AI 活用事例の紹介などを予定しています。あわせて、人材育成の研修プログラムについても提案していきます。 認知の次は実践です。UG の定期開催で実プロジェクトへの適用を進め、日立版 AI-DLC ワークフローの策定にも並走します。日立グループの AI 活用を全力で支援し、日立が掲げる Lumada 3.0 の実現に向けたパートナーとして、これからもご一緒させていただきます。 早川 裕志 氏、本日はありがとうございました。 本記事は、2026 年 5 月 18〜20 日に開催した「日立グループ合同 AI-DLC Unicorn Gym」の開催レポート、および 2026 年 6 月 9 日に実施した開催後インタビューをもとに構成しました。 著者 早川 康平 アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションズ マネージャー。金融勘定系システムの PM、Web エンジニア、SaaS プロダクトマネージャー、ソリューションアーキテクトを経て現職。幅広い経験を活かし、日立グループ専任の CSM として、SaaS アプリケーション開発や AI 活用を含むクラウド活用と開発プロセスの変革を支援している。宮城県仙台市出身。

2026 年 6 月 16 日、 Amazon Simple Storage Service (Amazon S3) 向けの新しいメタデータ機能であるアノテーションを発表しました。これにより、大規模かつリッチなビジネスコンテキストをオブジェクトに直接アタッチできるようになります。オブジェクトごとに最大 1,000 個の名前付きアノテーションを保存できます。各アノテーションのサイズは最大 1 MB、合計でオブジェクトあたり最大 1 GB です。JSON、XML、YAML、プレーンテキストなど、柔軟な形式に対応しています。オブジェクトを書き換えることなく、いつでもアノテーションを変更または削除できるため、オブジェクトのコンテキストを常に最新の状態に保つことができます。 組織は、人間の介入なしにデータを検索および理解し、データに基づいてアクションを実行する必要がある AI エージェントや自律型ワークフローを構築しています。これらのエージェンティックワークフローをサポートするには、データとともに進化し、ペタバイト規模のオブジェクトにスケールでき、高コストの取得なしでクエリ可能な状態を維持できるメタデータが必要です。 S3 アノテーションを使用することで、AI が生成したトランスクリプト、コンテンツの評価、技術仕様などのコンテキストを、オブジェクトとともに保存できます。コンテキストは、コピー、レプリケーション、クロスリージョン転送中に自動的にオブジェクトとともに移動し、オブジェクトを削除すると S3 によって削除されます。 S3 Metadata を有効にすると、アノテーションは自動的にフルマネージドアノテーションテーブルに反映され、 Amazon Athena や他の分析エンジンでクエリできます。 一般的なユースケース アノテーションは、業界を問わず、複雑なメタデータの課題を解決します: メディア & エンターテイメント : 動画アセットで、トランスクリプト、コンテンツモデレーションの結果、字幕ファイル、ライセンスメタデータを個別のアノテーションとして追跡することで、複数のメディアアセット管理システムでメタデータを同期する必要がなくなります。 金融サービス : AI が生成した投資の要約と感情分析を調査ドキュメントにアタッチすることで、自律型調査エージェントが個別のメタデータデータベースを維持することなく、自然言語クエリを通じて関連データセットを検出できるようになります。 ライフサイエンス : 臨床試験データに、規制関連のステータス、患者コホートの詳細、承認履歴などのアノテーションを付加することで、Amazon S3 Glacier ストレージクラスにアーカイブされたデータについての完全なコンテキストに取得料金なしでアクセスできるようにしながら、コンプライアンス監査を迅速化できます。 アノテーションがメタデータに関する課題をどのように解決するか Amazon S3 は、オブジェクトを記述するための複数の方法を既にサポートしています。システム定義メタデータは、サイズやストレージクラスなどのプロパティをキャプチャします。オブジェクトタグは、アクセスコントロールやライフサイクル管理などの運用タスクをサポートします。ユーザー定義メタデータを使用すると、アップロード時に少量のカスタム情報を追加できます。 これらの機能はそれぞれの目的には適していますが、別途メタデータシステムを構築および維持することなく、よりリッチなコンテキストをアタッチする必要がある場合には限界があります。アノテーションは、根本的に異なる規模と柔軟性でメタデータ機能を提供することで、これらのニーズに対応します。10 個のイミュータブルなタグや 2 KB のヘッダーとは異なり、オブジェクトごとにミュータブルかつクエリ可能なコンテキストを提供します。 機能 最大サイズ ミュータブル? 最適な用途 システム定義メタデータ 固定 いいえ オブジェクトのプロパティ (サイズ、ストレージクラス、作成時刻) ユーザー定義メタデータ 2 KB いいえ (アップロード時に設定) 小規模な key-value ペア オブジェクトタグ 10 個のタグ、キー/値ごとに 128/256 文字 はい アクセスコントロール、ライフサイクルルール、コスト配分 アノテーション 1 GB (1,000 × 1 MB) はい リッチなビジネスコンテキスト (JSON、XML、YAML、プレーンテキスト) 現在、S3 オブジェクトを記述するメタデータは、多くの場合、別のデータベースまたはサイドカーファイルに格納されており、データストレージよりも高いコストがかかる可能性がある、複雑な同期ワークフローが必要となります。S3 Metadata アノテーションテーブルを有効にすると、このコンテキストは Amazon Athena を通じて大規模にクエリ可能になります。AI エージェントは、 S3 Tables MCP サーバー を使用して自然言語を通じてデータを検出できます。このサーバーは、AI モデルがアノテーションをクエリするための標準化されたインターフェイスを提供します。あらゆるストレージクラスのオブジェクトのアノテーションを、オブジェクトを復元したり、取得料金を支払ったりすることなくクエリできます。 アノテーションの開始方法 アノテーションの使用を開始するには、 AWS Identity and Access Management (IAM) ポリシーまたはバケットポリシーが、 s3:PutObjectAnnotation アクションと s3:GetObjectAnnotation アクションの許可を付与していることを確認してください。その後、 PutObjectAnnotation API を使用して、既存または新規の S3 オブジェクトにアノテーションを追加できます。 例えば、メディア企業は、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、技術仕様と AI が生成した要約を動画アセットにアタッチできます。 # 技術メタデータを含む JSON ファイルを作成します cat > mediainfo.json << 'EOF' {"codec":"H.265","resolution":"3840x2160","audio_tracks":8,"frame_rate":29.97} EOF # それをアノテーションとしてアタッチします aws s3api put-object-annotation \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 \ --annotation-name mediainfo \ --annotation-payload ./mediainfo.json # AI が生成したプレーンテキストの要約を、別のアノテーションとしてアタッチします echo "A 90-minute nature documentary covering wildlife migration patterns across three continents, featuring aerial footage and underwater sequences.Languages: English, Spanish, Portuguese." > ai_summary.txt aws s3api put-object-annotation \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 \ --annotation-name ai_summary \ --annotation-payload ./ai_summary.txt これらのコマンドは、2 つの別々のアノテーションを同じ動画オブジェクトにアタッチします。 mediainfo アノテーションには構造化された技術仕様が JSON 形式で格納され、 ai_summary アノテーションにはテキストの説明が格納されます。各アノテーションは一意の名前で識別され、それぞれを個別に読み取り、変更できます。各アノテーションの一意の名前により、異なるアノテーションを使用して、複数の同時実行エンリッチメントワークフローをサポートできます。例えば、あるチームが技術メタデータを追加し、別のチームがコンテンツ分類を追加するといった作業を、互いに干渉することなく行うことができます。 GetObjectAnnotation API を使用して特定のアノテーションを取得します。 aws s3api get-object-annotation \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 \ --annotation-name mediainfo \ ./mediainfo-output.json オブジェクトにアタッチされているすべてのアノテーションを表示するには、 ListObjectAnnotations API を使用します。 aws s3api list-object-annotations \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 特定のアノテーションが不要になった場合は、 DeleteObjectAnnotation API を使用して削除します。 aws s3api delete-object-annotation \ --bucket my-media-bucket \ --key videos/documentary-2026.mp4 \ --annotation-name mediainfo 既存のアノテーションは、同じアノテーション名を指定して PutObjectAnnotation API を再度呼び出すことで、いつでも更新できます。マルチパートアップロードを使用してアップロードされた大きなオブジェクトの場合、マルチパートアップロードの完了後に PutObjectAnnotation API を使用してアノテーションをアタッチします。 S3 Metadata テーブルを使用した、アノテーションの大規模なクエリ 個々のオブジェクトにアノテーションをアタッチすることは便利ですが、その真の力は、すべてのアノテーションを大規模にクエリする際に発揮されます。バケットで S3 Metadata のアノテーションテーブルを有効にすると、S3 は、アノテーションテーブルと呼ばれるフルマネージド Apache Iceberg テーブルにアノテーションを自動でインデックス化します。Amazon Athena または Iceberg 互換のエンジンを使用して、アノテーションテーブルをクエリできます。 アノテーションテーブルを有効にするには、S3 コンソールまたは CreateBucketMetadataConfiguration API を使用します。次の例では、変更追跡用のジャーナルテーブルを保持し、ライブインベントリテーブルを無効にしつつ、アノテーションテーブルを有効にした新しいメタデータ設定を作成します。 { "JournalTableConfiguration": { "RecordExpiration": { "Expiration": "DISABLED" } }, "InventoryTableConfiguration": { "ConfigurationState": "DISABLED" }, "AnnotationTableConfiguration": { "ConfigurationState": "ENABLED", "Role": "arn:aws:iam::123456789012:role/S3MetadataAnnotationRole" } } この設定により、S3 は、クエリ可能なテーブルのすべてのアノテーションを自動的にキャプチャします。適用されると、このバケット内のオブジェクトにアタッチしたアノテーションは、約 1 時間以内にテーブルに表示されます。 メタデータ設定が既にバケットに存在している場合は、 UpdateBucketMetadataAnnotationTableConfiguration API を使用します。 aws s3api update-bucket-metadata-annotation-table-configuration \ --bucket my-media-bucket \ --annotation-table-configuration '{"ConfigurationState":"ENABLED","Role":"arn:aws:iam::123456789012:role/S3MetadataAnnotationRole"}' 有効にすると、アノテーションは自動的にアノテーションテーブルに反映されます。ジャーナルテーブルはほぼリアルタイムで更新されますが、アノテーションテーブルは 1 時間以内に更新されます。事前定義済みのスキーマを必要とする従来のメタデータテーブルとは異なり、アノテーションテーブルは、記述した JSON、XML、または YAML 構造に自動的に適応します。各アノテーションはテーブルの行となり、その内容は [text_value] 列に格納されます。これにより、スキーマ移行なしで、すべてのアノテーションをクエリできます。 既にアノテーション付きオブジェクトが存在するバケットでアノテーションテーブルを有効にすると、S3 は、既存のアノテーションを自動的にテーブルにバックフィルします。バックフィルプロセスはバックグラウンドで実行され、オブジェクトの数によっては数時間から数日かかる場合があります。 例えば、Amazon Athena を利用してバケット全体で 8 個を超える音声トラックを含むすべての動画アセットを検索するには、次のクエリを使用します: SELECT DISTINCT bucket, object_key FROM "s3tablescatalog/aws-s3"."b_my_media_bucket"."annotation" WHERE name = 'mediainfo' AND CAST(json_extract_scalar(text_value, '$.audio_tracks') AS INTEGER) > 8 このクエリは、アノテーションテーブルをスキャンして mediainfo という名前のすべてのアノテーションを検索し、JSON コンテンツから [audio_tracks] フィールドを抽出して、カウントが 8 を超えるオブジェクトを返します。 あるいは、ジャーナルテーブルを通じて直近 24 時間以内に新しいアノテーションを受け取ったすべてのオブジェクトを検索するには、次のクエリを使用します: SELECT bucket, key, version_id, record_timestamp, annotation.name FROM "s3tablescatalog/aws-s3"."b_my_media_bucket"."journal" WHERE record_timestamp >= (current_date - interval '1' day) AND annotation.name IS NOT NULL AND record_type IN ('CREATE_ANNOTATION', 'DELETE_ANNOTATION') このクエリはジャーナルテーブルを使用して、アノテーションの変更をほぼリアルタイムで追跡します。これは、新規または削除されたアノテーションに対応するイベントドリブンのワークフローの構築に最適です。 また、 Amazon SageMaker Unified Studio または S3 Tables MCP サーバーを備えた任意の IDE でエージェントを使用して、自然言語でアノテーションによるオブジェクト検索を実行することもできます。例えば、「2023 年に公開されたスペイン語の字幕付き PG 指定映画をすべて検索してください」と指示すると、数秒で結果が返されます。接続されていない複数のシステムにクエリする場合には数時間かかるでしょう。 今すぐ始めましょう Amazon S3 アノテーションは、AWS 中国リージョンを含むすべての AWS リージョンで今すぐご利用いただけます。アノテーションテーブルは、S3 Metadata が利用可能なすべての AWS リージョンで利用可能です。 自律的にデータを検出する必要がある AI エージェントの構築、複雑なメタデータを持つペタバイト規模のメディアアセットの管理、アーカイブされたデータセットのコンプライアンスコンテキストの追跡のいずれを行う場合でも、アノテーションを使用することで、個別のシステムを管理することなく、リッチなメタデータをオブジェクトに直接アタッチできるスケールと柔軟性を活用できます。 アノテーションのストレージは、親オブジェクトが S3 Glacier または他のストレージクラスにある場合でも、常に S3 Standard 料金で課金されます。料金の詳細については、 Amazon S3 の料金ページ にアクセスしてください。 さらに詳しく知りたい場合や利用を開始するには、 Amazon S3 Metadata の概要ページ および Amazon S3 ドキュメント にアクセスしてください。フィードバックは、 AWS re:Post for S3 宛てに、または通常の AWS サポート担当者を通じてお寄せください。 Daniel Abib 原文は こちら です。

本記事は 2026 年 6 月 17 日に公開された Kyle Seaman による “ Introducing Kiro for iOS ” を翻訳したものです。 2026 年 6 月 17 日、本格的な開発業務に対応するネイティブ iOS アプリとして Kiro を提供開始します。これにより、開発者へ自分のスマートフォンから直接、Kiro セッションの起動、監視、軌道修正、対話を行える新たなインターフェースをご提供します。つまり、ノート PC を起動していなくても、セッションを開始し、完了したら戻って確認し、差分をレビューし、変更を承認するといった作業を、作業から離れずに行えるようになります。 リモートセッションが Kiro を使う標準的な方法になるにつれて、スマートフォンは仕事とつながり続ける自然な場所になります。Web セッションの延長線上にあるものとお考えください。短い確認を入れるだけでセッションを前に進められ、不要な手戻りを防ぎ、適切なコンテキストでエージェントが作業を進められるよう支援できます。選択できるモードは chat、spec、autonomous の 3 つです。質問するために短時間のチャットセッションを開く、要件を同期し続けるために仕様 (spec) 駆動のワークフローを継続する、タスクを完全に委譲するために autonomous セッションを開始するなど、いずれの場合も、電車の中やランチが届くのを待っている間に、ノート PC を一度も開くことなく行えるようになりました。 止まらないクラウドセッション アプリを開くと、Kiro はクラウドセッションのライブな状態を読み込み、アクティブなスレッド、承認、プロジェクトのコンテキストを横断して作業できるようにします。エージェントの応答はリアルタイムにストリーミング表示され、ツールの実行状況もインラインで表示されます。また、autonomous モードでは、計画からコードレビューまでの実行ステータスが、人間の介入なしに表示されます。エージェントはクラウド上で独立して動作するため、起動状態を保つデスクトップ、接続用の VPN、夜通し動かしておくマシンを必要とせず、常時稼働かつ常時アクセス可能です。 モバイルのために設計された差分表示 差分はファイルヘッダー付きのネイティブな差分カード（追加 / 削除）として描画されるため、小さな画面でもコードが読みやすく、全体をすばやく見渡せます。PR とコードレビューのステータスは、すべてのセッション行で一目で確認できます。レスポンシブな Web レイアウトはスマートフォンでコードを読むのに適した形ではないと分かっているからこそ、私たちはネイティブで作りました。 作業を開始して、後で確認する Kiro では、作業を委譲し、その場を離れ、PR として戻ってくることができるようになりました。仕様駆動のワークフローを継続すれば、Kiro が中断したところから引き継ぎます。あるいは、スマートフォンまたは Web から autonomous セッションを起動すれば、Kiro はクラウドサンドボックス内で独立して動作し、ファイルを調査してテストを実行します。Kiro が入力を必要とすると、いったん停止します。あなたはどこからでも応答して方向性を選べば、中断した地点から作業が再開されます。 同じエージェント、同じコンテキスト Kiro Web で開始したセッションは、同じ ID、同じ設定、同じモデルで自動的に表示されます。Google、GitHub、IAM、または Builder ID でサインインすれば、リポジトリ、認証情報、サンドボックスの状態がそのまま保持され、更新内容はリアルタイムでスマートフォンに表示されます。 単一のビューから、異なるリポジトリをまたいで動作する複数のセッションを管理し、プルリクエストを監視し、セッション単位でフロンティアモデルとオープンウェイトモデルから選択できます。すべてが Kiro から自動的に同期されるため、接点をまたいでも失われるものはありません。 新しいアイデアがふと浮かんだら、chat、spec、autonomous のいずれかのモードを選び、GitHub からリポジトリを接続し、モデルを選択してメッセージを送信するだけで、その場で直接セッションを作成できます。別のコンテキストウィンドウを持つ別アプリではなく、あなたについてくる 1 つのエージェントです。 はじめる Kiro の iOS は、Kiro Pro、Pro+、Pro Max、Power のお客様向けに提供いたします。 早期アクセスをリクエスト いただければ、順番にご案内します。Kiro CLI、Web、IDE で利用しているものと同じ ID でサインインでき、セッション、モデル設定、接続済みリポジトリが自動的に同期されます。iOS 26 以降が必要です。 翻訳は Solutions Architect の吉村 が担当いたしました。

大規模なデータ量を運用するうえで、運用面での重要な課題に直面します。Similarweb では Apache HBase でこれらの課題に直面し、 Amazon DynamoDB で解決策を見出しました。 Similarweb は、 Web サイトのトラフィック、アプリの利用状況、市場トレンドに関する AI 駆動のインサイト を提供するデジタルインテリジェンスプラットフォームであり、企業が競合をベンチマークし、成長戦略を最適化するのに役立ちます。 私たちは既存の Apache HBase インフラストラクチャでスケーラビリティと運用上の複雑さの問題が増大しており、より柔軟で効率的な代替案を模索することになりました。本記事では、データストレージを Apache HBase から DynamoDB へ移行した過程を紹介します。技術的な課題、移行アプローチ、データモデリング戦略、コスト最適化テクニック、そして得られた主なメリットについて議論します。DynamoDB へ移行することで、パフォーマンスとスケーラビリティが向上し、メンテナンス負荷が軽減され、チームはインフラ管理よりもイノベーションに注力できるようになりました。学んだ教訓と、この移行が業務オペレーションに与えた影響についても探っていきます。 背景 私たちの Web アプリケーションでは、ユーザーに大量のデータを提供するために堅牢なデータベースソリューションが必要です。そのソリューションは、データを効果的に保存し、迅速に取得し、ユーザーインターフェイスに結果を返す前に集計、グルーピング、ソートなどの操作を実行する必要があります。これを実現するため、データの性質とクエリパターンに基づいた 2 つのアプローチを採用し、Web アプリケーションを応答性が高くインタラクティブに保つよう設計しています。 最初のアプローチは、ユーザー入力に依存する動的クエリや、サイトグループのべき集合のデータを計算するような複雑な計算に関するものです。これは膨大な数の組み合わせとなり、事前計算は現実的ではありません。そのため、これらのクエリには Firebolt のようなクラウド分析データベース (OLAP システム) を使用しています。Firebolt は、JOIN、GROUP BY、その他の SQL ライクなクエリ操作を含む複雑なクエリパターンにも使用しています。これらのデータベースは、ETL ベースの事前集計に適さない大規模データセットのオンザフライ処理に優れています。 一方、2 つ目のアプローチでは、予測可能で事前計算可能なアクセスパターンを持つ機能について、DynamoDB のようなキーバリュー (KV) ストアを使用しています。定期的な ETL プロセスでデータを事前計算することにより、DynamoDB は集計情報への高速で簡素なアクセスを提供し、パフォーマンスとスケーラビリティのバランスを取りながらユーザーに応答性の高い体験を提供します。 トラフィックとエンゲージメントデータを取得するための要件 事前計算データの利用方法を示すために、プラットフォームの UI で表示している、Web サイトのトラフィックとエンゲージメントの経時的な推移という典型的なユースケースを見てみましょう。 図 1: Similarweb の Traffic and Engagement レポートでは、ユーザーは分析するサイト (1) を選択し、日付範囲 (2) を選び、世界全体または特定の国などの地理的範囲 (3) を設定できます。これらの選択を行うと、グラフには選択した期間における訪問数やユニークユーザーといった主要メトリクスが表示されます。 例えば example.com などの Web サイトの訪問統計を、サイト名、日付、国 (ISO コード)、訪問数といった詳細とともに保存しています。   Site Country (ISO) Date Visits TimeOnSite BounceRate … example.com 840 2026-01-22 7 15.2 7 example.com 840 2026-01-23 11 11.7 1 example.com 840 2026-01-24 3 20.3 4 example.com 840 2026-01-25 12 13.2 5 example.com 840 2026-01-26 9 19.1 7 アクセスパターンとしては、example.com の特定の日付範囲における全国の訪問データを取得したり、米国 (840) のような特定の国の訪問データをクエリしたりすることが考えられます。このシナリオでは、ETL プロセス中に日付、国、サイトの各組み合わせに対する訪問数を事前に計算して保存することで、これらの一般的なアクセスパターンに対して迅速な応答時間を実現しつつ、クエリ時の計算オーバーヘッドを最小限に抑えることができます。 これらの事前計算されたメトリクスは単純に見えますが、Similarweb の規模では、その背後にある書き込み負荷とクエリの多様性が既存の HBase クラスタを限界まで押し上げました。私たちのケースでは、データは継続的に書き込まれるのではなく、Spark ジョブを使用して日次、週次、月次といったスケジュールされた間隔で大規模なバッチで取り込まれます。 大規模スケールと柔軟なアクセス Similarweb のトラフィックとエンゲージメントデータセットは膨大で、合計 255 テラバイト (TB) を超えます。データを継続的に取り込むトランザクションアプリケーションとは異なり、私たちの分析パイプラインは大きなバーストで呼吸します。データを新鮮に保つため、 1 テーブルあたり約 70 億レコード を、数時間で完了させる必要があるタイトなスケジュールのバッチで取り込んでいます。 しかし、データを書き込むことは戦いの半分にすぎません。保存後、このデータは多様で複雑な読み取りパターンに対して即座に利用可能でなければなりません。ユーザーは単純なキー検索以上のことを行います。彼らは複数の次元でデータを切り分けて、競合をベンチマークし、トレンドを分析します。 次の図は、移行前のハイレベルなデータフローを示しています。 図 2 (移行前): 生のイベントはデータレイクに到達し、Spark ETL が日次集計を計算し、バルク書き込みで結果を HBase に保存します。.NET バックエンドはサイトと国のメトリクスをキー (および日付) で読み取り、Traffic and Engagement UI に提供します。すべての矢印はデータフローを表しています。 単純なキーバリュー検索を超えて 特定のフィルタリングパターンに対して 1 桁ミリ秒の読み取りを提供しながら、大規模な書き込みスパイクに対応できるデータベースソリューションが必要でした。具体的には、任意のサイトに対して以下の 4 つのアクセスパターンをサポートする必要がありました。 サイトレベルの集計: サイトの全トラフィックを取得。 SELECT * WHERE Site = {site} 特定の国の内訳: 特定の国にドリルダウン。 SELECT * WHERE Site = {site} AND Country = {country} 時系列トレンド: 特定の期間の履歴を取得。 SELECT * WHERE Site = {site} AND Date BETWEEN {start} AND {end} 複雑な組み合わせ: 国と日付範囲の両方でフィルタリング。 SELECT * WHERE Site = {site} AND Country = {country} AND Date BETWEEN {start} AND {end} これを達成するために、理想的なデータベースは以下の 4 つの厳格な基準を満たす必要がありました。 高い書き込みスループット: 数時間で数十億レコードを取り込む。 多用途なクエリサポート: テーブル全体をスキャンせずに、前述の次元ベースのクエリを処理。 パフォーマンスを保ったスケーラビリティ: ピーク書き込み時でも高い読み取りパフォーマンスを維持。 コストの透明性: 請求書で驚くのではなく、実行 前に コストを見積もれる予測可能な料金モデルを提供。 HBase が壁にぶつかった理由 HBase は長年にわたって私たちに役立ってきましたが、Similarweb の規模では、徐々に「使用するデータベース」から「運用するシステム」へと変化していきました。中核的な制限は生の能力ではありませんでした。それは、非常に大規模なバッチ書き込みと常時稼働の読み取りに対する厳しい期待を組み合わせた後に現れた運用リスクと不安定さでした。 1. RegionServer の不安定性がオンコール対応の原因に 繰り返し発生するインシデントの原因は、HBase の RegionServer がクラスタの他の部分と同期しなくなったり、ダウンしたりすることでした。RegionServer がドリフトしたり誤動作したりすると、ホストするリージョンの可用性とレイテンシに影響を与える可能性があります。回復が可能な場合でも、それは不安で時間がかかるものであり、頻繁に発生したため、実質的な運用負担となっていました。 2. ストレージとディスクのアップグレードが悪夢 大規模な HBase 環境におけるディスク管理とアップグレードは、常に非常に摩擦の大きいものでした。分散システムにおけるディスク変更は単独のイベントではありません。それはパフォーマンス、安定性、運用手順に波及します。ルーチンとなるべきインフラ作業がしばしば実質的なリスクを伴う複数ステップのメンテナンスに変わり、特に取り込みウィンドウや読み取り SLA を保護しようとしているときには厳しいものでした。 3. アーキテクチャの利点が私たちのアクセスパターンと一致しなかった HBase のワイドカラムモデルは、大きな行から列のサブセットを読み取るときに真価を発揮します。私たちの場合、アクセスパターンはしばしばキーに対するメトリクスの完全なセットを読み取ることを必要としていたため、システムの最も強力な設計上の利点を一貫して享受することなく、システムの運用コストを支払っていることになっていました。 4. データベースがピーク向けにサイジングされていたため高コスト テラバイト規模のバッチロードは短く激しい書き込みピークを生み出す一方で、製品は依然として高速で予測可能な読み取りを必要としていました。ピーク向けにサイジングされた常時稼働クラスタを維持することは、1 日のほとんどで実際に使用していないキャパシティに対して支払うことを意味していました。 これらの課題は単一の壊滅的な障害として現れたわけではありません。それらは累積する運用負荷として現れました。深夜の呼び出しが増え、クラスタの健全性に費やす時間が増え、ルーチンメンテナンスのリスクが増加しました。その複合化するオーバーヘッドが、フルマネージドな代替案を探すことを促しました。 DynamoDB がこれらの課題にどう対処するか DynamoDB により、以下が可能になりました。 クリティカルパスからクラスタ運用を排除。 DynamoDB では、リージョンサーバーをプロビジョニングする必要がなく、リバランスもなく、インフラ層でのキャパシティプランニングも手動で行う必要がありません。それにより、データベースの健全性に関連する日常的な運用作業と障害モードの数が直接削減されました。 永続的なオーバープロビジョニングなしでバッチ取り込み向けにスケール。 私たちの書き込みパターンは予測可能です。書き込むレコード数と完了までの時間ウィンドウがわかっています。DynamoDB ではキャパシティをダイヤルとして扱うことができます。取り込み実行の直前に プロビジョンド書き込みキャパシティユニット (WCU) を即座にスケールアップし、完了次第すぐにスケールダウンします。これにより、24 時間 365 日大規模なクラスタを稼働させ続けるのではなく、コストをバッチウィンドウに合わせることができました。 書き込みスパイク中も読み取りパフォーマンスを安定的に維持。 UI の背後にあるアクセスパターンは、主にキーベースの検索と日付範囲クエリです。DynamoDB のパーティション化されたアーキテクチャと、 パーティションキーとソートキー に対する Query 操作 により、テーブルが非常に大きく成長し、取り込みジョブが並列実行されている場合でも、これらの読み取りを一貫して低レイテンシで提供できます。 コスト動作を明示的かつ予測可能に。 DynamoDB のキャパシティとリクエストパターンが私たちのワークロードにきれいにマップされるため、レコード数、アイテムサイズ、予想されるクエリの形状から書き込みと読み取りのコストを見積もることができます。これにより、コストモデリングは事後的な驚きではなく、設計の一部となりました。 耐障害性とディザスタリカバリオプションの改善。 DynamoDB は、すぐに使えるマネージドバックアップとリカバリプリミティブを提供します。マルチリージョンのニーズに対しては、 DynamoDB Global Tables でリージョン間でデータをレプリケートできるため、読み取りをローカルで提供でき、リカバリは大規模クラスタを圧力下で再構築することに依存しません。 この基盤が整ったことで、私たちのワークロード固有の部分、つまり高スループットで効率的に取り込む方法と、低コストでアクセスパターンを満たすためのキーモデリングに集中できるようになりました。次の図は、移行後のデータフローを示しています。 図 3 (移行後) : 事前計算されたトラフィックとエンゲージメントメトリクスは、2 つのパスを通じて提供されます。予測可能で低レイテンシのアクセスのための DynamoDB に支えられたキーバリューレーンと、動的でアドホックなクエリのための Firebolt を使用する分析レーンです。.NET バックエンドはそれに応じてリクエストをルーティングします。歴史的に、レーン A は HBase を使用していました。それを DynamoDB に置き換えました。 データモデリング DynamoDB のパフォーマンスとコストのメリットを最大限に引き出すためには、実際のクエリパターンに基づいてデータモデルを設計することが重要でした。私たちの目標は、応答時間と読み取り/書き込みキャパシティ使用量の両方を最小化する効率的なアクセスパスを作成することでした。 Traffic and Engagement の例を再度見てみましょう。コアアクセスパターンには、日付範囲全体にわたるサイトの訪問データの取得と、オプションで国によるフィルタリングが含まれます。 単純なアプローチ: パーティションキー 最初のアプローチは、次のようなフラットでユニークなパーティションキーを作成することかもしれません。 PK = {site}_{country}_{date} Primary key Visits TimeOnSite BounceRate PK example.com_840_2026-01-21 4 24 12.31 1 か月分のデータ、例えば 2026 年 1 月の米国 (国コード 840) における example.com への訪問を取得するには、31 個の個別のキーを生成し、BatchGetItem リクエストを発行します。 example.com_840_2026-01-01 example.com_840_2026-01-02 ... example.com_840_2026-01-31 この設計は機能しますが、スケールでは非効率でコストがかかります。単一の BatchGetItem リクエスト内では、各アイテムの取得が個別の読み取り操作としてカウントされ、ペイロードサイズが小さくてもアイテムごとに 1 つの読み取りキャパシティユニットを消費します。 最適な設計: パーティションキーとソートキーを持つコンポジットキー よりスケーラブルなモデルでは、パーティションキーとソートキーを持つ コンポジットプライマリキー を使用します。 パーティションキー (PK): {site}_{country} ソートキー (SK): {date} Primary key Visits TimeOnSite BounceRate PK SK example.com_840 2026-01-21 4 24 12.31 このセットアップでは、DynamoDB の効率的な Query API を使用して、日付範囲にわたるサイトと国のペアのすべてのレコードをクエリできます。 Query(PK="example.com_840", SK BETWEEN "2026-01-01" AND "2026-01-31") これにより API コールの数が減り、ソートキーに対する範囲クエリを使用することで読み取りコストが大幅に削減されます。 コスト比較: Query 対 BatchGetItem サイトと国の組み合わせごとに 500 日分のデータを取得し、各エントリが約 200 バイトであるユースケースを考えてみましょう。 注: RCU はアイテムサイズに応じて 4 KB チャンクでスケールします。結果整合性のある読み取りでは RCU が半分になります。 アプローチ 読み取り API RCU 計算 推定コスト フラット PK BatchGetItem 500 アイテム × 1 RCU = 500 RCU $0.065 コンポジット PK + SK Query 100 KB / 4 KB = 25 RCU $0.00325 節約: コンポジットキー設計を使用することで 20 倍以上安価 。 全世界のユースケース コンポジットキーモデル ( PK = {site}_{country} 、 SK = {date} ) は、サイト、国、日付範囲でフィルタリングされた一般的なクエリを効率的にサポートしますが、 全国にわたる訪問データをクエリ する必要がある場合に課題が生じます。例えば、example.com の全世界の訪問を、全期間または特定の日付範囲で取得する場合です。 SELECT * WHERE Site = 'example.com' SELECT * WHERE Site = 'example.com' AND Date BETWEEN '2026-01-01' AND '2026-01-31' 既存のスキーマでは、 国コードがパーティションキーに埋め込まれて おり、これはパーティション間で書き込みと読み取りの負荷を均等に分散するために不可欠です。しかしこれは、 データをクエリするには国を知る必要がある ことも意味し、グローバル集計のユースケースには望ましくありません。 シンプルですが非効率な解決策は、すべての国別パーティションにわたって Query API コールをファンアウト することです。 # ファンアウト Query: すべての国にわたるサイトの訪問を取得 results = [] for country in country_codes: # ~200 ISO 3166 コード pk = f"example.com_{country}" response = query( TableName='TrafficTable', KeyConditionExpression="PK = :pk AND SK BETWEEN :start AND :end", ExpressionAttributeValues={ ":pk": pk, ":start": "2026-01-01", ":end": "2026-01-31" } ) results.extend(response['Items']) # 国レベルのレコードを集計して単一の世界規模ビューにする worldwide = {} for item in results: date = item['SK'] visits = item['visits'] worldwide[date] = worldwide.get(date, 0) + visits # worldwide = {"2026-01-01": 148200, "2026-01-02": 136400, ...} 機能的には正しいものの、このアプローチにはいくつかの欠点があります。 高コスト : サイト/日付クエリごとに 200 以上の Query リクエスト。 増加したレイテンシ : 200 のクエリにわたって結果をクエリし集計することで、応答時間が大幅に増加する可能性があります。 BatchQueryItem なし : BatchGetItem とは異なり、複数の Query リクエストを単一の API コールにバッチ処理するネイティブな方法はありません。 運用オーバーヘッド : 200 以上の並列クエリの管理は、アプリケーションに負荷をかけ、スロットリングのリスクを増加させる可能性があります。 ファンアウトのコストと複雑さを発生させずに効率的なグローバルクエリをサポートするため、ETL プロセス中に特別な合成国コード (例: 999) を導入しました。実際には、ETL パイプラインの一環として集計された世界規模メトリクスを事前計算して保存し、専用の「グローバル」パーティションに書き込みます。これは、世界規模データに指定されたパーティションキー PK = {site}_999 を使用することで実現します。 Primary key Visits TimeOnSite BounceRate PK SK example.com_840 2026-01-21 4 24 12.31 example.com_999 2026-01-23 33 17 16.5 これにより、 単一の Query リクエスト で世界規模データをクエリできます。 Query(PK="example.com_999", SK BETWEEN "2026-01-01" AND "2026-01-31") このようにして、読み取り時のパフォーマンスオーバーヘッドがなく、複数ではなく 1 つの Query リクエストを使用するためコストも削減されます。 もちろん、「999」アプローチにもコストがかかります。サイトと日付ごとに追加の世界規模ロールアップを計算する必要があるため ETL の複雑さが増し、サイト国レコードごとに追加のアイテムを永続化するためストレージも増えます。それでも、システムをエンドツーエンドで見ると、明らかな勝利です。読み取り時から書き込み時に作業をシフトし、200 以上のファンアウトクエリの必要性を排除し、アプリケーション側のオーケストレーションを減らし、一貫してより高速な世界規模読み取りを実現します。実際には、追加の ETL とストレージコストはクエリコストとレイテンシの節約によって上回られるため、ソリューション全体としてはより安価で高速になります。 次のセクションでは、初期データ移行と毎月のデータ取り込み中に時間とコストを節約するために、DynamoDB の機能をさらにどのように利用しているかを探ります。 DynamoDB への書き込み バッチ取り込みは私たちの分析パイプラインの心拍です。継続的なストリームではなく、Databricks 上で日次、週次、月次のスケジュールで ETL Spark ジョブをトリガーするスケジュールされた Apache Airflow Directed Acyclic Graphs (DAGs) に依存しており、それぞれが下流機能の鮮度要件に合わせて調整されています。すべての実行で、テーブルが読み取りトラフィックに対してできるだけ早く準備できるように、短い時間ウィンドウ内に DynamoDB に数十億のアイテム、しばしば数テラバイトをプッシュします。 DynamoDB は、異なるワークロードパターンに対応する 2 つの異なる キャパシティモード を提供しています。オンデマンドモードはサーバーレスで従量課金型のモデルで、トラフィック需要に合わせて自動的にスケールし、キャパシティプランニングは不要で、使用した分のみ支払います。一方、プロビジョンドモードでは、希望する読み取りと書き込みのスループットを事前に指定する必要があり、課金はこのプロビジョンされたキャパシティに基づいて行われます (完全に使用されたかどうかにかかわらず)。私たちのケースでは、書き込むレコードの総数と取り込みの時間ウィンドウが既にわかっているため、必要な書き込みキャパシティユニットを正確に計算して設定できます。これにより、スケジュールされたバッチロードに対しては、プロビジョンドモードのほうがオンデマンドよりも大幅にコスト効率が良くなります。 エンドツーエンドのバッチワークフロー Airflow がロードをスケジュール DAG パラメータには、テーブル名とソースから読み取る日付範囲が含まれます。 ジョブはピークの重複を避けるためにずらされます。 Databricks Spark が ETL を実行 Spark のパーティションは、並列処理を最大化するために DynamoDB のパーティションキーと整合します。 DynamoDB Connector for Apache Spark を使用しており、これは書き込みをバッチ化し、指数バックオフによるリトライロジックを処理します。 キャパシティはジャストインタイムでスケールアップ ターゲット DynamoDB テーブルへの最初の書き込みの前に、インフラスクリプトが UpdateTable を呼び出してテーブルのプロビジョンド書き込みキャパシティ、つまり書き込みキャパシティユニット (WCU) を計算されたピークまで引き上げます。スクリプトは、目標期間とレコード数に基づいてこのレベルを自動的に設定します。 データを並列に書き込み DynamoDB Connector for Apache Spark を使用し、プロビジョンドキャパシティに密接に整合したスループットでデータを書き込みます。通常、プロビジョンド書き込みキャパシティの約 1.1 倍を目標とし、リソースを十分に活用しつつ最適な利用率を達成するため、制御されたレベルのスロットリングを受け入れます。 キャパシティは自動的にスケールバックダウン ETL がすべてのレコードの書き込みを終えると、UpdateTable を再度呼び出してプロビジョンドキャパシティ書き込みレベルを下げる後続タスクをスケジュールします。 def run_etl(table_name, records_count, target_duration_hours=1): # ステップ 3 -- キャパシティをジャストインタイムで計算してスケールアップ desired_wcu = ceil(records_count / (target_duration_hours * 3600)) desired_wcu = clamp(desired_wcu, MIN_WCU, MAX_WCU) wait_until_table_is_active(table_name) current_wcu = describe_table(table_name).provisioned_write_capacity update_table(table_name, wcu=current_wcu + desired_wcu) # UpdateTable API wait_until_table_is_active(table_name) try: # ステップ 4 -- Spark DynamoDB Connector を介してデータを並列に書き込み spark.write(target_table=table_name, write_throughput_ratio=1.1) # プロビジョンド WCU の約 110% finally: # ステップ 5 -- キャパシティを自動的にスケールバックダウン update_table(table_name, wcu=current_wcu) # UpdateTable API wait_until_table_is_active(table_name) DynamoDB テーブルのプロビジョンドキャパシティを計算してスケールアップする Python 疑似コード Amazon Simple Storage Service (Amazon S3) からの Import Table を使用する DynamoDB への書き込みの時間とコストをさらに削減するため、HBase からの移行時および一部の定期的な書き込みに、 DynamoDB Import from S3 機能を使用して、Amazon Simple Storage Service (Amazon S3) から直接データをインポートしました。これにより、レコードごとの書き込みが不要になり、取り込み時に書き込みキャパシティユニットを消費することがなくなります。 メリット バルク取り込みで 最大 90% のコスト削減 。 ETL 取り込みのための Databricks コンピューティング使用が不要 。 ネイティブインポートによってリトライロジックが隠蔽され、運用オーバーヘッドが取り除かれた 簡素化された運用 。 従来の Spark ジョブと比較して より高速な取り込み 。 Import Table 機能は、アイテムごとの書き込み操作ではなく、取り込まれたデータの総量に基づいて課金されるため、特に私たちのケースのように小さなアイテムを持つ大きなテーブルを移行する場合、大幅なコスト削減を実現します。 S3 からのインポートワークフロー ETL 前の自動化の一環として、データは指定された S3 パスから読み取られ、Import from S3 機能でサポートされている DYNAMODB_JSON 形式に変換されます。 整形されたデータの S3 パスとテーブル定義を指定して ImportTable API を呼び出します。 モニタリングタスクがインポート完了まで進捗を追跡します。 期間ごとに別々のテーブルにデータを保存するタイミング DynamoDB の Import from S3 機能は、大規模なバックフィルにとってゲームチェンジャーですが、重要な制約があります。新しいテーブルにのみインポートできるという点です。その制限は、データセットが自然に時間でパーティション化されており、主に最近の期間でアクセスされる場合には機会となります。 月次のデータセットでは、意図的な設計を採用しました。月ごとに 1 つのテーブルを作成し、Import from S3 を使用してその月のデータをインポートし、データが古くなるにつれてそれらのテーブルのライフサイクルを管理します。 月次データに適している理由 このアプローチが特に月次ワークロードに適している理由は以下のとおりです。 バルクロードが離散的 : 各月のデータセットは通常完全なバッチとして生成されるため、インポートのクリーンな単位になります。 クエリ時の運用の簡素さ : アプリケーションは、コールドデータとホットデータを 1 つの大きなテーブルで混在させる代わりに、関連する期間テーブルにクエリをルーティングできます。 保存期間管理が簡単に : 古いアイテムを削除する代わりに、期限切れになったテーブル全体を削除できます。 コスト最適化が容易 : 古い月次テーブルは、アプリケーションロジックを変更することなく、年齢を重ねるにつれて Standard-IA テーブルクラス に移行でき、ストレージコストを削減できます。 実用的な命名規則によって自動化が容易になります。例: {table_name}_2026-01 。 エンドツーエンドの実行方法 各月について、データセットを生成し、サポートされているインポート形式の 1 つである DynamoDB JSON に変換し、新しい月次テーブルに ImportTable を実行します。 インポート後、不要になったテーブルを削除する保存期間ポリシーを適用します。 古くなった月次テーブルを Table Class Standard-IA に移行してストレージコストを節約します。 要求された日付範囲が複数の月にまたがる場合、API は関連する月次テーブルにわたってクエリをファンアウトし、結果をマージします。 期間ベースのテーブルを使用すべきでない場合 このパターンは強力ですが、万能ではありません。 日次のデータセット の場合、1 日ごとにテーブルを作成するとテーブル数が爆発し、不必要な運用オーバーヘッドが発生します。そのような場合は、単一の長期間有効なテーブルを維持し、標準的な取り込みパス (Spark 書き込み + プロビジョンドキャパシティスケーリング) を続けるほうが良いです。 経験則 期間が粗い (月次以上) で、データがバルクでロードされ、保存期間がテーブルレベルで強制できる場合は、 期間ごとに別々のテーブルを優先 してください。 期間が細かすぎる (日次) 場合、または同じ物理テーブルへの継続的な増分書き込みが必要な場合は、 単一のテーブルを優先 してください。 結論 本記事では、Similarweb が Apache HBase から DynamoDB に移行した経緯を紹介しました。この移行は、運用を簡素化し、効率的にスケールし、インフラオーバーヘッドを削減しながら、大規模に高速で信頼性の高いインサイトを提供し続ける必要性によって推進されました。 レガシーの HBase セットアップは強力ではありましたが、増大するバッチ取り込みワークフローと動的クエリ要件のニーズに応えるのに苦労していました。安定性、運用メンテナンス、スケーリングの限界などの課題が、よりモダンなサーバーレスの代替案を求めるきっかけになりました。 DynamoDB を採用することで、以下を達成しました。 インテリジェントな書き込みプロビジョニングを伴う ETL ジョブを使用した 高パフォーマンスなバッチ取り込み 。 大規模で多様なクエリパターンをサポートする 柔軟でコスト効率の高いデータモデリング 。 フルマネージドでサーバーレスな DynamoDB アーキテクチャによる 運用負担の削減 。 Amazon S3 から直接インポートすることによる 低い運用負担と高速な履歴データ移行 。 手動のクラスタ管理なしでの システム信頼性とスケーラビリティの向上 。 この移行は、データインフラのパフォーマンスと安定性を向上させ、エンジニアリングチームが機能の構築とイノベーションの推進に集中できるようにしました。DynamoDB は、私たちの分析パイプラインの強靭でコスト効率の高い基盤であることが証明されており、Similarweb がお客様にタイムリーで実行可能なデジタルインサイトを提供するというミッションを支えています。 本記事は 2026 年 06 月 16 日 に公開された “Similarweb’s migration from HBase to Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/similarwebs-migration-from-hbase-to-amazon-dynamodb/ 著者について Idan Lahav Idan はテルアビブを拠点とする Similarweb の R&D ディレクターです。バックエンドインフラ、プラットフォーム基盤、データエンジニアリングに深い専門知識を持ち、スケーラブルなデータパイプラインアーキテクチャの設計と、高スループットプラットフォームの複雑な課題の解決に注力しています。最近の HBase から DynamoDB への移行において、Idan は移行を可能にした基盤となるインフラ基盤の設計と管理を担当しました。 Leonid Koren Leonid は AWS のプリンシパル NoSQL ソリューションアーキテクトで、お客様が NoSQL データベースを使用して既存のアプリケーションをモダナイズし、新しいアプリケーションを設計するのを支援しています。AWS に入社する前は、2000 年代初頭からバックエンドシステムの設計と開発を行ってきました。

本ブログは 2026 年 6 月 17 日に公開された AWS Blog “ Introducing AWS Continuum: Security at machine speed ” を翻訳したものです。 AWS が確信していること AWS はエンタープライズセキュリティについて深く考え続けてきました。この 10 年間役立ってきた運用モデル、つまりテレメトリを収集して保存し、クエリを実行し、それらを監視するためのダッシュボードを構築するというアプローチは、もはや時代に追いついていません。AWS は、テレメトリを起点にコンテキストで意味づけし、推論を重ね、アクションへとつなげる新しい世界へ移行する必要があります。それは成果を生み出すアプローチです。最新のサイバーセキュリティ向けフロンティアモデルの登場により、この移行は一層急務となりました。Claude Mythos のようなモデルがソフトウェアの脆弱性を発見し、複雑な攻撃経路をマシンスピードで推論できるようになった結果、脆弱性のバックログが指数関数的に増加しているからです。 コードの脆弱性に対応する AWS Continuum のご紹介 本日 (2026 年 6 月 17 日)、AWS はコードの脆弱性に対応する AWS Continuum を発表します。現在限定プレビューでご利用いただけます。コードの脆弱性に対応する Continuum は、発見からアクションに至るまで、コードの脆弱性のライフサイクル全体にマシンスピードで対応します。お客様の環境を推論し、何が現実の問題なのかを見極め、解決へと導きます。Continuum はモデルに依存しない設計になっており、それぞれが最も得意とする領域で複数のフロンティアモデルを使用します。さらに、より新しく高性能なモデルが登場するたびに取り込めるよう構築されています。 Continuum は、AWS と Amazon.com 全体でセキュリティを運用してきた経験から得た教訓をもとに構築されています。さまざまな業界で事業を展開するビジネスを保護するには、汎用的なルールを一律に適用するのではなく、ビジネスコンテキストを理解するシステムが必要でした。 仕組み コードの脆弱性に対応する Continuum は、お客様の環境全体を推論します。ここで活用するコンテキストには、すでに Amazon Web Service (AWS) 内に存在する構造化データ (インフラストラクチャ、アクセス許可、ネットワークトポロジ、コード) と、組織の運用方法やリスクプロファイルを捉えた非構造化データ (ドキュメント、コミュニケーション、ビジネス上の優先事項) が含まれます。 コードの脆弱性に対応する Continuum は、次の 4 つの継続的なフェーズで動作します。 発見: セキュリティチームは脆弱性のバックログに取り組んでおり、多くのチームがすでにフロンティアモデルを使ってさらに多くの脆弱性を発見しています。Continuum は、まずその既存のバックログを取り込み、お客様の環境に対して独自の脆弱性スキャンを実行します。これにより、脆弱性とそれに関連する攻撃経路をより包括的に把握できます。 優先順位付け: Continuum はコンテキストを活用して、すべての検出結果を評価、強化、優先順位付けします。影響を受けるコンポーネントがデプロイされているか、到達可能か、本番環境の経路上にあるか、エクスプロイトされた場合のビジネスへの影響はどうか、といった観点で確認します。その結果、証拠に裏付けられた優先事項のリストが得られ、Continuum とお客様のチームは最も重要なことに集中できます。 検証: Continuum は検出結果を検証し、チームの時間を浪費する前に誤検出を明らかにします。脆弱性をお客様の環境に照らしてコンテキスト化したうえで、サンドボックス環境で実際に動作するエクスプロイトの例を構築し、問題の具体的で再現可能な証拠を提供します。 緩和と修復: Continuum は、検証済みの問題に対する既存の防御策を評価します。これには、ブロック型および代替コントロールと検出メカニズムが含まれます。次に、コードベース、コンテキスト、検出結果に関する理解に基づいて、ネットワークの変更、ポリシーの変更、またはコードパッチによる脆弱性の緩和または修復を推奨します。パッチの推奨は、脆弱性を確認したのと同じシステムを使って検証されます。また、可能な場合は影響範囲の可視化とロールバック経路も提供します。 これはほんの始まりにすぎません。AWS はコード (ファーストパーティおよびサードパーティ) から着手し、その後セキュリティの他の側面へと拡大していきます。 信頼は段階的に高まる Continuum は、人間が介在する learn モード (学習モード) から始まります。すべての推奨には、その背景にある推論が含まれています。お客様が信頼を高めるにつれて、Continuum を enforce モード (適用モード) へ引き上げることができ、お客様が定義したカテゴリやリスクプロファイルに基づいて、ますます自動化された修復を有効にできます。 Continuum の機能 コードの脆弱性に対応する Continuum に加えて、Continuum にはお客様がすでにご存知かもしれない機能も含まれています。 AWS Security Agent のペネトレーションテストとコードスキャンの機能は、Continuum for penetration testing および Continuum for code scanning (プレビュー) として Continuum の一部になりました。AWS はまた、Continuum for threat modeling もプレビューで提供開始します。これは、設計ドキュメントやソースコードから包括的な脅威モデルを自動生成し、STRIDE 形式で結果を出力する機能です。これらの機能は、発見、優先順位付け、検証、修復という、より広範な Continuum のループに供給される検出および分析のソースとして機能します。 使ってみる AWS は、金融サービス、自動車、テクノロジー業界のお客様と協力して AWS Continuum を形作ってきました。お客様からのフィードバックは、その方向性を裏付けるものでした。セキュリティチームは、信頼を獲得し、アクションを起こせるツールを求めています。 コードの脆弱性に対応する AWS Continuum は、限定プレビューでご利用いただけます。アクセスをリクエストするには、 AWS Continuum でサインアップしてください。 Chet Kapoor Chet は Amazon Web Services の Vice President of Search, Security, and Observability です。エンタープライズテクノロジーの分野で 20 年以上の経験を持ち、API やオープンソースからクラウドや AI に至るまで、業界で最も重要なプラットフォームの転換期において企業を率いてきました。急速な成長、変革、買収、IPO の時期を通じて、ビジネスの構築とスケーリングに携わってきました。Chet は、ビルダーとしての考え方、深い運用経験、そして強い顧客志向を持ち、組織が新しいテクノロジーを安全かつ大規模に導入できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

2026 年 05 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Cost Optimization Hub AWS Cost Optimization Hub はコスト最適化の推進に役立つ機能で、組織内の全アカウント・全リージョンのコスト最適化の推奨事項を一元的に集約・表示し、推定削減額を確認できます。本セッションでは、AWS Cost Optimization Hub の概要や利用方法、よくあるご質問についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Cost Optimization Hub の概要・基本的な利⽤⽅法を知りたい⽅ AWS におけるコスト最適化を推進したい⽅ 本 BlackBelt で学習できること AWS におけるコスト最適化の課題と AWS Cost Optimization Hub の役割を理解する AWS Cost Optimization Hub の機能概要と基本的な利用方法を把握する 関連 AWS サービスとの使い分けについて知る スピーカー 西村 美由紀 テクニカルアカウントマネージャー Amazon EKS ネットワーキング Deep Dive シリーズ Amazon EKS を利用するためには、AWS（VPC）と Kubernetes の両方のネットワーク設定および要件を理解する必要があります。 本セミナーでは、EKS クラスターを構成するコントロールプレーンとデータプレーンのネットワーク設定・要件を整理して紹介することで、お客様の要件に適した構成を選択いただけるようになることを目的としています。 また、ネットワーキングアドオン（CoreDNS, kube-proxy, Amazon VPC CNI plugin）の紹介により、クラスター内の名前解決や Kubernetes ネットワークおよび Pod ネットワークの理解を深めることができます。 クラスターネットワーキング編 – 資料（ PDF ）  Kubernetes ネットワーキング編 – 資料（ PDF ） Pod ネットワーキング前編 – 資料（ PDF ） Pod ネットワーキング後編 – 資料（ PDF ）  対象者 Amazon EKS を利用している方、または利用を検討している方​ Amazon EKS のネットワーキングについて学びたい方​ 本 BlackBelt で学習できること Amazon EKS クラスターのネットワーク要件や設計ポイント 各ネットワーキングアドオン（CoreDNS, kube-proxy, Amazon VPC CNI plugin）の役割やアーキテクチャ スピーカー 原 雅貴 クラウドサポートエンジニア Amazon CloudWatch Part1 Observability の基本・メトリクス・アラーム編 Amazon CloudWatch の概要と Observability の基本、メトリクス・アラームについて解説します。これから AWS で監視を始める方向けに、オブザーバビリティの概念から CloudWatch 全体像、メトリクスの仕組み、アラーム設定のベストプラクティスまでを網羅的にご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS で監視・ Observability（可観測性）を始めたい方、Amazon CloudWatch の概要を把握したい方、メトリクスやアラームの基本を学びたい方 本 BlackBelt で学習できること 本セッションでは、オブザーバビリティ（可観測性）の基本概念と、AWS における監視の全体像を学ぶことができます。Amazon CloudWatch の機能一覧を俯瞰した上で、メトリクスの仕組み・ Metric Insights ・ Metric Math といった分析機能、CloudWatch Alarms によるアラーム設定のベストプラクティスや Alarm Recommendations の活用方法を解説します。 スピーカー 津和崎 美希 ソリューションアーキテクト AWS Elemental Media Services を利用した動画配信について（応用編 – 大規模配信イベント対応） AWS Elemental Media Services を利用した動画配信についての「応用編」として、100 万人規模の同時視聴者数を想定した大規模配信イベントを成功させるための設計判断と留意事項をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 基礎編を視聴済みで、AWS Elemental Media Services の基本機能や構成、動画配信全般の基本的な知識を有している方 同時視聴 100 万人規模が想定されるようなミッションクリティカルなライブ動画配信基盤の設計・構築に携わる方 高可用構成、スケール設計、大規模イベント運用の実践的な知識を身に付けたい方 本 BlackBelt で学習できること AWS Elemental Media Services を利用して、100 万人規模の同時視聴者数を想定した大規模配信イベントを成功させるための設計判断と留意事項を学ぶことができます。 スピーカー 石井　悠太 ソリューションアーキテクト NAB Show 2026 recap 世界最大の放送機器展 NAB Show 2026 で AWS が披露した 30 を超えるデモから注目トピックを厳選して解説します。AWS Elemental Inference によるリアルタイム縦動画変換、ハイライト自動抽出、MXL/TAMS によるクラウドネイティブ放送基盤、AWS Elemental MediaConnect Router によるライブ映像のクラウドルーティング、AI エージェントを活用したライブ配信障害の自律診断など、制作/配信/管理/収益化の4領域における最新技術を現地参加メンバーがお伝えします。 資料（ PDF ） | 動画（ YouTube ） 対象者 放送局/動画配信事業者/メディアテクノロジー企業で、クラウド移行や AI 活用による制作ワークフロー効率化を検討されている技術者・企画担当の方を対象としています。AWS のメディア系サービスの基本的な役割を理解されていると、より深くお楽しみいただけます。 本 BlackBelt で学習できること NAB Show 2026 での AWS 最新発表と放送・配信業界のトレンドを短時間で把握できます。AWS Elemental Inference や AWS Elemental MediaConnect Router など新サービスの技術詳細と採用事例、AI エージェントによるライブ障害診断や超低遅延配信といった次世代メディアワークフローの実装アプローチを学べます。 スピーカー 小南 英司 ソリューションアーキテクト Amazon Cognito 基礎編 Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションにユーザー認証、認可、ユーザー管理機能を簡単に追加できる認証サービスです。複雑な認証システムの構築や運用が不要になることから、多くのお客様のアプリケーション開発で採用頂いています。本セッションでは、Amazon Cognito を使用するユースケースや基本的な機能についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 アイデンティティ管理に AWS の利用を検討している方 Amazon Cognito でできることを理解されたい方 Cognito ユーザープールと ID プールの違いや使い方を理解されたい方 本 BlackBelt で学習できること アイデンティティ管理における Amazon Cognito の使い方を学習いただけます Amazon Cognito ユーザープールと ID プールの違いについて理解を深めていただけます Amazon Cognito の機能や認証フローを習得いただけます スピーカー 沼田 裕太郎 クラウドサポートエンジニア Amazon Cognito 実装編 Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションにユーザー認証、認可、ユーザー管理機能を簡単に追加できる認証サービスです。複雑な認証システムの構築や運用が不要になることから、多くのお客様のアプリケーション開発で採用頂いています。本セッションでは、Amazon Cognito ユーザープールの具体的な利用方法やユースケースについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 アイデンティティ管理に Amazon Cognito の利用を検討している方 Amazon Cognito ユーザープールでできることを理解されたい方 本 BlackBelt で学習できること アイデンティティ管理における Amazon Cognito ユーザープールの実践的な使い方を学習いただけます Amazon Cognito ユーザープールの機能や認証フローを習得いただけます スピーカー 谷 祐貴 クラウドサポートエンジニア Amazon Connect AI agents Connect assistant 基礎編 Amazon Connect AI agents は生成 AI を活用したカスタマーサービスアシスタントです。 本セミナーでは、人間のエージェントの対応を強化する コネクトアシスタント機能をご紹介します。) ぜひコンタクトセンターへの導入をご検討ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect ご利用中のお客様、パートナーの方 コンタクトセンター での AI 活用や業務効率化に関心のある方 スピーカー 杉野 喬生 クラウドサポートエンジニア Amazon Connect AI agents self-service 基礎編 Amazon Connect AI agents は生成 AI を活用したカスタマーサービスアシスタントです。 本セミナーでは、顧客からの問い合わせに AI エージェントが自律的に対応するセルフサービス機能をご紹介します。 ぜひコンタクトセンターへの導入をご検討ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 対象者： Amazon Connect ご利用中のお客様、パートナーの方 コンタクトセンター での AI 活用や業務効率化に関心のある方 本 BlackBelt で学習できること Amazon Connect の AI エージェントが自律的に対応するセルフサービス機能を使用したユースケースや機能の概要について スピーカー 中嶋桃香 クラウドサポートエンジニア Amazon Connect Cases Amazon Connect Cases は、顧客の問題を追跡し、エージェント間で協力してすばやく解決するための機能です。 顧客とのやり取りをエージェント間で確認し、必要なタスクの作成やケースの受け渡しができます。 本セミナーでは、コンタクトセンターにおけるケース管理の課題を解決する Cases の機能についてデモを交えて解説します。 https://youtu.be/ytost3jnHFw 資料（ PDF ） | 動画（ YouTube ） 対象者 カスタマーセンターのシステムを検討、実装する方 Amazon Connect を利用しているが、Cases はまだ利用していない方 本 BlackBelt で学習できること Amazon Connect Cases の機能、他の Connect 機能との組み合わせた顧客体験の実現方法 スピーカー 松本　和久 シニアソリューションアーキテクト Amazon Connect Tasks update Amazon Connect Tasks は、コンタクトセンターのエージェントに単一かつ柔軟な UI を提供することで、顧客の問題解決に必要なすべての作業を一つの画面で効率的に処理できる環境を実現します。 本セミナーでは前回 2022 年以降のアップデートと、新機能を活用して部門をまたいだ一貫性のある顧客サポートの実現についてデモを交えて解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 カスタマーセンターのシステムを検討、実装する⽅ カスタマーセンターでの効率的なタスク管理を模索している方 Amazon Connect を利用しているが、Tasks はまだ利用していない⽅ 本 BlackBelt で学習できること Amazon Connect Tasks の機能、他の Connect 機能との組み合わせた顧客体験の実現方法 スピーカー 松本　和久 シニアソリューションアーキテクト

本稿は、2026 年 06 月 04 日に公開された “ Gain visibility into DDoS attacks with flow logs in AWS Shield Advanced ” を翻訳したものです。 これまで、分散型サービス妨害 (DDoS) 攻撃のトラフィックを再構成するには、事後に複数のデータソースを組み合わせる必要がありました。 AWS Shield Advanced の攻撃フローログは、これを変革します。攻撃中にトラフィックのメタデータをキャプチャするため、送信元の特定、緩和策の検証、既存の分析パイプラインへのデータ投入が可能になります。 Shield は、他の AWS フローログと同じ CloudWatch Logs の配信インフラストラクチャを使用して、 Amazon Simple Storage Service (Amazon S3) 、 Amazon CloudWatch Logs 、または Amazon Data Firehose にログを発行します。そのため、すでに使用しているモニタリングおよび分析ツールに直接組み込めます。 この記事では、 Shield Advanced 攻撃フローログ が DDoS イベント中にどのようにメタデータをキャプチャするか、フローログエントリの各フィールドが何を意味するか、そして保護対象リソースに対してフローログを有効化および設定する方法を説明します。 DDoS 攻撃がアプリケーションに与える影響 DDoS 攻撃は、アプリケーションをトラフィックであふれさせ、ユーザーが利用できない状態にします。インフラストラクチャ層の攻撃は帯域幅を飽和させ、接続テーブルを枯渇させるため、パケットロスやタイムアウトが発生します。 Shield Advanced は、 Amazon CloudFront ディストリビューション、 Elastic Load Balancing のロードバランサー、 Amazon Route 53 のホストゾーン、 AWS Global Accelerator の標準アクセラレーター、および Elastic IP (EIP) アドレスに対して、攻撃を検出して緩和するマネージド型の DDoS 保護サービスです。対応範囲の詳細については、 AWS Shield Advanced のドキュメント を参照してください。 Shield Advanced では、まず EIP 保護を対象としたインフラストラクチャレイヤーの攻撃フローログが提供され、その後、対応するリソースタイプが順次拡大される予定です。 主な利点 フローログは、攻撃を以下のようなさまざまな観点から理解するのに役立ちます。 トラフィックパターンの再構築 – 攻撃発生後にログをクエリすることで、トラフィック量、送信元の分布、プロトコルの構成比を分析でき、CloudWatch の集約メトリクスだけに頼る必要がなくなります。 攻撃元の特定 – srccountry および location フィールドは、トラフィックがどこから発生し、どの AWS エッジロケーションに入ってきたかを示します。 緩和動作の検証 – action フィールドは、Shield が各フローに対して行った処理を記録します。 ログは Amazon S3、CloudWatch Logs、または Data Firehose に送られます。その後、新しいインフラストラクチャをデプロイすることなく、 Amazon Athena (Amazon S3 内のデータを分析するためのサーバーレスのクエリサービス) でクエリしたり、サードパーティのセキュリティ情報イベント管理 (SIEM) プラットフォームにルーティングしたり、 CloudWatch Logs Insights (対話型のログ分析機能) のクエリを構築したりできます。 攻撃フローログがキャプチャする内容 ログレコードは、送信元と送信先の IP アドレスおよびポート、プロトコル、パケット数とバイト数、Shield Advanced が実行したアクション、TCP フラグをキャプチャします。また、トラフィックが入ってきた AWS イングレスロケーションと、可能な場合はトラフィック送信元の 2 文字の国コードも含まれます。ログは 5 分間隔で書き込まれ、攻撃の進行中および終了後に利用できます。 ファイルの最大サイズは 75 MB です。5 分間のウィンドウ内にファイルがその上限に達した場合、そのファイルはクローズされて転送され、新しいファイルが開始されます。フローログは JSON、プレーンテキスト、W3C、Parquet の出力形式に対応しており、以下のフィールドを含みます。 フィールド 説明 protection_arn Shield 保護の Amazon リソースネーム (ARN) event_timestamp ログ生成のタイムスタンプ version フローログのバージョン番号 srcaddr 送信元 IP アドレス dstaddr 送信先 IP アドレス srcport 送信元ポート dstport 送信先ポート protocol プロトコル番号 packets 集約ウィンドウ内のパケット数 bytes 集約ウィンドウ内のバイト数 starttime 集約ウィンドウの開始時刻 endtime 集約ウィンドウの終了時刻 action Shield が実行したアクション location AWS イングレスロケーション sampling_rate パケット処理中に使用されたサンプリングレート tcp_flags パケットの TCP フラグ srccountry トラフィック送信元の 2 文字の国コード Shield Advanced 保護対象リソースに対するフローログの設定方法 以下の手順では、Shield Advanced 保護を任意のログ送信先に接続する CloudWatch Logs 配信リソースの作成方法を説明します。 前提条件 フローログを設定する前に、以下を準備してください。 有効な Shield Advanced サブスクリプション 少なくとも 1 つの既存の Shield Advanced 保護 CloudWatch Logs 配信リソースを作成するための AWS Identity and Access Management (IAM) 権限 ( logs:PutDeliverySource 、 logs:PutDeliveryDestination 、 logs:CreateDelivery ) フローログには標準の CloudWatch Logs のベンドログ料金が発生し、送信先リソース (S3 バケットのストレージ、CloudWatch Logs のロググループのストレージ、または Firehose のデータ処理) には別途料金が発生します。トラフィックの多いリソースでフローログを有効化する前に、 CloudWatch の料金ページ のベンドログの項目と、選択した送信先サービスの料金を確認してください。 仕組み ログ配信には 3 つのオブジェクトが必要です。 DeliverySource – ログを生成する Shield Advanced 保護を表します DeliveryDestination – ログの送信先 (Amazon S3、CloudWatch Logs、または Amazon Data Firehose) を表します Delivery – ソースと送信先を接続します この 3 オブジェクトモデルにより、複数のソース間で送信先を再利用したり、配信パイプラインを個別に管理したりできます。たとえば、同じ DeliveryDestination を参照する複数の DeliverySource オブジェクトを作成することで、複数の Shield 保護からのログを同じ S3 バケットに送信できます。 Shield Advanced 攻撃フローログは CloudWatch Logs 配信インフラストラクチャを使用するため、他のベンドログと同様に、アカウントやリージョンをまたいで集約できます。 クロスアカウントポリシーを使用して一元管理された S3 バケット へ直接配信したり、 クロスアカウント・クロスリージョンの集約ルール を使用して CloudWatch Logs のロググループをレプリケートしたり、 クロスアカウントサブスクリプション を使用して共有 Firehose ストリームにストリーミングしたりできます。これらのオプションを活用して、マルチアカウント・マルチリージョン環境全体にわたる DDoS 攻撃トラフィックの統合ビューを構築することができます。 ステップ 1: 送信先リソースを作成する 送信先を選択します。 オプション A – S3 バケット : 長期保存と Athena クエリに最適です。 S3 バケットの作成 を参照してください。 オプション B – CloudWatch Logs ロググループ : リアルタイムモニタリングと CloudWatch Logs Insights に最適です。 CloudWatch Logs でのロググループの作成 を参照してください。 オプション C – Data Firehose 配信ストリーム : サードパーティツールや SIEM へのストリーミングに最適です。 Firehose ストリームの作成 を参照してください。 ステップ 2: 送信先リソースポリシーを設定する (必要な場合) 送信先リソースには、CloudWatch Logs 配信サービスに書き込み権限を付与するポリシーが必要です。ポリシーは送信先のタイプによって異なります。詳細については、 Amazon S3 に送信されるログ 、 CloudWatch Logs に送信されるログ 、または Firehose に送信されるログ を参照してください。 Amazon S3 を送信先とする場合は、2 つのオプションがあります。 自動ポリシー作成: バケットに既存のリソースポリシーがなく、 s3:GetBucketPolicy および s3:PutBucketPolicy 権限を持っている場合、ステップ 6 で配信を作成する際に AWS が必要なポリシーを自動的に作成します。ステップ 3 に進んでかまいません。 手動ポリシー更新: ポリシーをカスタマイズする必要がある場合や、組織で事前承認済みのポリシーが必要な場合は、 Amazon S3 に送信されるログ の手順に従って手動でポリシーを作成してください。 ステップ 3: 保護 ARN を取得する Shield Advanced はグローバルサービスであり、管理には us-east-1 リージョンを使用します。次のコマンドを実行して、 Shield Advanced 保護の一覧を表示 します。 aws shield list-protections \ --region us-east-1 出力から、ログを記録したい保護の ProtectionArn の値をコピーします。 ステップ 4: 配信ソースを作成する 次のコマンドを実行して配信ソースを作成します。 <protection-arn> をステップ 3 の ProtectionArn の値に置き換えてください。 aws logs put-delivery-source \ --name my-shield-delivery-source \ --resource-arn <protection-arn> \ --log-type FLOW_LOGS \ --region us-east-1 --resource-arn には、保護対象のリソースそのものの ARN ではなく、Shield Advanced の保護オブジェクトの ARN を指定します。Shield Advanced は、リソースをラップする個別の保護オブジェクトを作成し、フローログはその保護レイヤーから生成されます (基盤となるリソースからではありません)。 ステップ 5: 配信先を作成する 次のコマンドを実行して配信先を作成します。 <resource-arn> をステップ 1 で作成した送信先リソースの ARN に置き換えてください。 aws logs put-delivery-destination \ --name my-shield-delivery-destination \ --output-format plain \ --delivery-destination-configuration '{"destinationResourceArn":"<resource-arn>"}' \ --region us-east-1 --delivery-destination-configuration パラメーターは、 destinationResourceArn キーを持つ JSON オブジェクトを指定します。 その値には、S3 バケット、ロググループ、または Firehose ストリームの ARN を設定します。 出力結果から、トップレベル (レスポンス直下) の ARN フィールドの値をコピーしてください。これは配信先 ARN (バケット ARN とは異なります) です。この値はステップ 6 で使用します。 ステップ 6: 配信を作成する 次のコマンドを実行して、配信ソースと配信先を接続します。 <delivery-destination-arn> をステップ 5 の配信先 ARN に置き換えてください。 aws logs create-delivery \ --delivery-source-name my-shield-delivery-source \ --delivery-destination-arn <delivery-destination-arn> \ --region us-east-1 ステップ 7: 配信を検証する 次のコマンドを実行して、配信が有効であることを確認します。 aws logs describe-deliveries \ --region us-east-1 配信が有効になると、Shield Advanced は DDoS イベント中にフローログレコードを送信先に転送します。 クリーンアップ 継続的な料金が発生しないように、作成したリソースを削除します。 配信を削除します。 aws logs delete-delivery \ --id <delivery-id> \ --region us-east-1 配信ソースを削除します。 aws logs delete-delivery-source \ --name my-shield-delivery-source \ --region us-east-1 配信先を削除します。 aws logs delete-delivery-destination \ --name my-shield-delivery-destination \ --region us-east-1 (任意) コンプライアンスや分析のためにログを保持する必要がある場合は、フローログのデータをバックアップします。 送信先リソースを削除します。 警告: 送信先リソースを削除すると、すべてのフローログデータが完全に削除されます。 S3 バケットの場合: aws s3 rb s3://<bucket-name> \ --force \ --region <region> CloudWatch Logs のロググループの場合: aws logs delete-log-group \ --log-group-name <log-group-name> \ --region <region> Firehose ストリームの場合: aws firehose delete-delivery-stream \ --delivery-stream-name <stream-name> \ --region <region> まとめ Shield Advanced の攻撃フローログは、DDoS 攻撃を効果的に理解し対応するために必要な可視性を提供します。既存のオブザーバビリティ基盤と統合できるため、新しいツールの導入や複雑なセットアップを必要とせず、すぐに活用できるインサイトを得ることができます。今すぐ Shield Advanced の保護でフローログを有効にして、攻撃パターンへの即時の可視性を確保し、DDoS 防御態勢を強化しましょう。 次のステップ Amazon S3 内のログをクエリするための Athena テーブルの構築 Amazon CloudWatch Logs でのログデータの対話的な検索と分析 攻撃パターンに対する CloudWatch アラームの作成 フローログ設定に関する完全なリファレンスについては、 AWS Shield Advanced のドキュメント を参照してください。 Ken Kitts Ken は、Amazon Web Services (AWS) のテクニカルアカウントマネージャーであり、フィンテック分野におけるソフトウェア定義ネットワーキング (SDN) を含む、20 年以上のコンピューターネットワーキングの経験を持っています。仕事以外では、遺跡や博物館を巡ることが好きな旅行愛好家で、メキシコのテオティワカンがお気に入りの場所です。 翻訳は Solutions Architect の 長谷川 純也 が担当しました。

AWS WAF に AI トラフィック収益化機能が含まれるようになりました。これにより、デジタルコンテンツの所有者とパブリッシャーは、保護されたウェブコンテンツに AI ボットやエージェントがネットワークエッジで直接アクセスした場合に課金できます。この機能により、コンテンツ所有者とパブリッシャーは、オリジンインフラストラクチャを変更したり、アプリケーションコードを作成したりすることなく、コンテンツパス、ボットカテゴリ、または検証階層ごとにリクエストごとの料金を設定できます。コンテンツ所有者は、エージェントタイプごとにきめ細かなアクセスポリシーを定義したり、ステーブルコインで好みのウォレットに支払いを回収したり、収益やボットアクティビティを単一のダッシュボードから監視したりできます。 現在、多くのコンテンツプロバイダーにおいて AI ボットのトラフィックがウェブトラフィックの 50% 以上を占めており、AI 固有のクローラーは前年比で 300% 以上増加しています。コンテンツをインデックスし、測定可能な参照トラフィックをパブリッシャーのウェブサイトに返す従来の検索エンジンのクローラーとは異なり、AI ボットは同じコンテンツを消費して AI インターフェイスで要約と回答を生成するため、元のソースにトラフィックをほとんどまたはまったく送り返しません。パブリッシャーは、そのトラフィックを処理するためのインフラストラクチャ費用を負担しますが、通常はこれらの費用を相殺するページビュー、広告インプレッション、またはサブスクリプションコンバージョンは発生しません。 AWS WAF Bot Control では、既にボットのアクティビティを可視化し、トラフィックをブロックまたはレート制限する機能をお客様に提供していますが、料金設定や AI エージェントからの支払いの回収は、これまで不可能でした。AI トラフィック収益化は、そのギャップを埋める新しい Bot Control 機能です。コンテンツ所有者とパブリッシャーは、カスタムの支払いインフラストラクチャを構築したり個別のライセンス契約を交渉したりすることなく、AWS WAF コンソールから直接料金ルールを設定し、サードパーティーの支払い統合を通じて AI エージェントから支払いを回収できます。支払い決済および検証フローは、Coinbase の x402 Facilitator によって提供されます。アカウントへの直接支払いと Machine Payments Protocol (MPP) サポートのための Stripe との統合が間もなく開始されます。 AI トラフィック収益化の開始方法 収益化を設定する前に、CloudFront ディストリビューションに関連付けられているウェブ ACL で AWS WAF Bot Control が共通レベルまたはターゲットレベルで有効になっていることを確認します。Bot Control は、収益化ルールが依存するエージェント分類を提供します。まだ設定していない場合は、「 ウェブ ACL への AWS WAF Bot Control マネージドルールグループの追加 」ドキュメントを参照してください。AWS マネジメントコンソールで [WAF & Shield] に移動し、左側のナビゲーションペインで [保護パック (ウェブ ACL)] を選択して開始します。 保護パックは、AI トラフィック収益化の中核となる構成単位です。収益化の対象となるコンテンツパス、各エージェント検証階層に課金される内容、受け入れる支払い方法、適用されるライセンス条件を定義します。作成するには、 [保護パック (ウェブ ACL) を作成] を選択します。 [アプリについて教えてください] で、コンテンツを説明するアプリカテゴリを 1 つ以上選択し ([コンテンツと公開システム]、[E コマースとトランザクションプラットフォーム]、[エンタープライズとビジネスアプリケーション] など)、 [アプリフォーカス] を選択します。AWS WAF はこれらの選択を使用して、お客様の設定に適したセキュリティ保護を推奨します。 [保護するリソースを選択] で [リソースを追加] を選択し、CloudFront ディストリビューションなどのリージョンリソースまたはグローバルリソースをこの保護パックに関連付けます。このステップはスキップして、後でリソースを追加することができます。 [初期保護を選択] で、アプリのカテゴリとリソースの選択に基づいて、AWS WAF マネージドルールパッケージから選択します。パッケージの代わりに個別のルールを選択することもできます。 [名前と説明] に、保護パックの名前と任意の説明を入力します。 オプションで、 [カスタマイズ保護パック (ウェブ ACL)] を展開し、料金階層、支払い方法、コンテンツ範囲、ライセンス条件などの追加設定を行います。 終了したら、 [保護パック (ウェブ ACL) を作成] を選択します。 保護パックが導入されたら、料金戦略を立てる前に、AI トラフィック分析ダッシュボードを確認して、AI ボットトラフィックがコンテンツに与える影響を理解してください。WAF & Shield コンソールで、左側のナビゲーションペインの [AI トラフィック分析] に移動します。ドロップダウンから保護パック (ウェブ ACL) を選択し、ダッシュボードに入力します。 AI トラフィック分析ダッシュボードは、ボットトラフィック概要パネルに表示されるトラフィックを、 すべてのボットリクエスト 、 AI ボットリクエスト 、 検証済み AI ボットトラフィック 、 未検証 AI ボットトラフィック の 4 つのカテゴリに分類します。ダッシュボードには、消費された帯域幅、推定月間コスト、ピークリクエスト率などのインフラストラクチャへの影響メトリクスが表示されます。パスごとのヒートマップには、AI ボットのアクティビティが最も多いコンテンツパスが時間単位で示され、情報に基づいた料金決定を行うために必要なデータを取得できます。 AWS WAF Bot Control は、GptBot、Claude-Web、Perplexity-Bot を含む 650 種類以上の AI ボットとエージェントを分類し、それぞれに検証階層を割り当てます。 検証済み – ウェブボット認証 (WBA) Ed25519 暗号署名によって身元が確認されたか、ユーザーエージェントとドメイン名の既知のセットを使用して文書化されたIP範囲から取得されたエージェント。 未検証 – ユーザーエージェントマッチング、行動フィンガープリンティング、IP レピュテーションによって認識されるが、身元は暗号で確認されていないエージェント。 トラフィックパターンを確認したら、 [保護パック (ウェブ ACL)] に戻り、リストから保護パックを選択し、右側のパネルで [AI 収益化を設定] を選択して料金設定とアクセスポリシーを設定します。各保護パックは、定義された一連のコンテンツパスに適用される料金、エージェントポリシー、利用可能な支払い方法、ライセンス条件を定義します。複数の保護パックを作成し、同じディストリビューション内のさまざまなコンテンツゾーンに異なる価格を適用できます。作成したら、ウェブ ACL を開いて [保護パックを追加] を選択して、保護パックをウェブ ACL に関連付けます。 パック内のエージェント検証レベルごとに、 [収益化] (402 を料金付きで返す)、 [許可 (無料アクセスを許可)] 、 [ブロック (アクセスを完全に拒否)] 、 [カウント (課金せずにログ記録)] 、 [CAPTCHA (パズルを提示して人間の送信者であることを検証)] 、 [チャレンジ (クライアントがボットではなくブラウザであることを確認)] の 6 つのアクションのいずれかを割り当てることができます。 [収益化設定を編集] ページで、次の内容を設定します。 [支払い決済] で、ステーブルコイン決済用のブロックチェーンネットワークを 1 つ以上選択します。自社で管理されているか、コインベースなどのウォレットプロバイダーがホストしているかにかかわらず、サポートされているネットワーク上のすべてのウォレットアドレスを使用できます。ネットワークごとに、ウォレットアドレスを入力し、USDC で 1 ページあたりの基本料金 を設定します。 [ネットワークを追加] を使用して複数のネットワークを追加できます。AWS はコンテンツ収益に対する支払い処理や手数料の徴収は行いません。支払いは自己管理されるか、ウォレットプロバイダーによって管理されます。 収益化 ルールが受信リクエストと一致すると、AWS WAF は HTTP 402 支払いが必要な応答を返します。レスポンス本体には、マシン間決済用の x402 オープンプロトコルを使用した JSON 形式の機械可読価格マニフェストが含まれます。マニフェストには、USDC でのコンテンツ料金、Base や Solana などの受け入れ可能なブロックチェーンネットワーク、宛先ウォレットアドレス、最大支払いタイムアウト、支払いスキームが含まれます。 x402 互換のエージェントランタイムであれば、このフローを自律的に完了できます。クライアントは、選択した支払いネットワークで署名済みの支払い承認を送信します。AWS WAF はそれを検証し、コンテンツを取得し、サードパーティーのファシリテーターサービスと統合してオンチェーンでの支払いを行い、応答を提供します。 収益化 アクションは、Amazon CloudFront ディストリビューションに関連付けられたウェブ ACL でのみサポートされていることに注意してください。リージョナルウェブ ACL への 収益化 ルールの追加はサポートされていません。 通貨モード の切り替えは収益化設定ページから直接利用できるため、 リアル モードと テスト モードはいつでも切り替えることができます。本番環境に移行する前に、非プロダクショントラフィックでテストモードを使用し、料金設定、ウォレット設定、x402 決済フローを検証してください。なお、テストモードでは引き続き x402 の支払いが適用されますが、これらの支払いは、faucet.circle.com などの蛇口から取得したテスト資金を使用して、Base Sepolia や Solana Devnet などのテストネットで行うことができます。テストモードを有効にするには、保護パック設定で [通貨モード] を [テスト] に切り替えます。AWS WAF は実際の価格マニフェストを返し、設定されたテストチェーンで本番環境と同じように支払いフロー全体を実行します。すべてのイベントは CurrencyMode: TEST を使用してログ記録されます。設定に問題がなければ、通貨モードをリアルに戻して実際の支払いの処理を開始します。 [通貨モード] を [リアル] に切り替えたら、左側のナビゲーションペインで [AI アクセス収益化] に移動して、収益化の結果をリアルタイムで追跡します。 AI アクセス収益化 ダッシュボードには、実際の通貨モードからのアクティビティのみが反映され、テストトランザクションは表示されないことに注意してください。 収益ダッシュボードには、 総収益 、 検証済みボット と 未検証ボット 別の収益、 リクエストあたりの平均が表示されます。 上位収益源 パネルでは収益をボットカテゴリ別にグループ化し、AI アクセスパターンパネルでは発生した収益に基づいてコンテンツパスをランク付けします。 決済 タブを使用して、プロバイダーごとに支払いを調整し、支払い方法の配分と失敗した支払い試行を確認します。 今すぐご利用いただけます AI トラフィックの収益化は、Amazon CloudFront のお客様において、標準の AWS WAF 料金を超える追加料金なしでご利用いただけるようになりました。この機能は、AWS WAF ウェブ ACL が Amazon CloudFront ディストリビューションに関連付けられているすべてのエッジロケーションで利用できます。 AI トラフィックの収益化の詳細については、「 AWS WAF デベロッパーガイド 」を参照してください。 – Esra 原文は こちら です。

2026 年 6 月 15 日週、ニューヨーク市では AWS Summit が開催されます。これは、Javits Center での 1 日間のイベントであり、発表、デモ、テクニカルセッションを目的として、ビルダー、お客様、AWS チームが一堂に会します。私は Summit でのいくつかのリリースについてブログ記事を書いたので、今週それらが Go Live になるのを楽しみにしています。ただ、私は Javits Center には行くことができません。4 日間の音楽フェスティバルに参加し、テントをどのように設営しようか考えながら、スマートフォンでリリース内容をチェックする予定です。私のように現地参加できない方々のために、6 月 17 日に基調講演の ライブ配信 が行われます。VP of Agentic AI である Dr.Swami Sivasubramanian と、VP of Security Services and Observability である Chet Kapoor 氏が、デベロッパーツール、AI インフラストラクチャ、セキュリティにおける新機能について解説します。 2026 年 6 月 15 日週の主なトピックは以下のとおりです。 主なトピック フロンティアチームが AI ネイティブ開発をいかに革新しているか – Swami は今週、数百の Amazon エンジニアリングチームでの実験から得られたデータに基づく詳細な記事を公開しました。自社チームでの AI 導入の仕組みを検討しているなら、この記事の内容をじっくりお読みいただく価値があります。 6 人のエンジニアで構成されるチームは、Amazon Bedrock 推論エンジンをわずか 76 日間で再構築しました。このプロジェクトは、当初 30 人のデベロッパーが 12～18 か月間かけて取り組む予定だったものです。Amazon Stores チームとの体系的なパイロットでは、正規化されたデプロイ速度で、生産性向上の中央値が 4.5 倍となり、中には 10 倍を超えるチームもありました。Perfect Order Experience では、2 週間の機能サイクルが、午後だけで完了するようになりました。WW Grocery では、設計ドキュメントの作成期間が 5 日間から数時間に短縮されました。 この記事では、これらの結果を、フロンティアチームになるための 5 つの実践にまとめています。第 1 に、エージェントコンテキストに投資しましょう。本番コードを記述する前に、ステアリングファイル、コーディング標準、構造化されたリポジトリを構築しましょう。第 2 に、ワークフローの再構築中には初期の処理速度低下が想定されますが、それを乗り越えましょう。第 3 に、エージェントが逐次監視なしで並列実行できるように、適切にスコープ設定されたタスクのバックログを安定的に維持しましょう。第 4 に、コード生成を開始する前に、構造化された仕様を通じて意図を明確にしましょう。第 5 に、コードがパイプラインに到達する前にエージェントが自己修正できるよう、テストをシフトレフトしましょう。 記事の最後には、コミット速度は全体像の一部に過ぎず、リリース管理、運用、セキュリティ運用、および EOL アップグレードについて後続の記事で解説する予定である旨が記載されています。 AWS FinOps Agent がプレビューで利用可能に – AWS FinOps Agent は、FinOps の実践者とエンジニアリングチーム向けの新しいエージェントです。このエージェントは、コストに関する質問への回答、最適化の機会の提示、コスト異常の調査、および定義されたスケジュールに基づく定期的な FinOps ワークフローの実行を行います。AWS コストの照会、財務チームとエンジニアリングチーム向けのコストレポートの生成、AWS Cost Optimization Hub と AWS Compute Optimizer からの適切なサイジング、アイドル状態のリソース、および Savings Plans に関するレコメンデーションの提示に使用できます。エージェントは、これらのレコメンデーションに基づいて、お客様のために Jira チケットをオープンできます。コスト異常が検出されると、FinOps Agent は根本原因を自動的に調査し、検出結果を Slack チャンネルに投稿します。 2026 年 6 月 8 日週のリリース まずは 6 月 15 日週に私が書いた記事から始めて、その後に私が注目した他のリリースについてご紹介します: Amazon EC2 M9g および M9gd インスタンスの一般提供を開始 – AWS Graviton5 プロセッサを搭載し、第 6 世代 AWS Nitro System 上に構築された M9g インスタンスは、Graviton4 ベースのインスタンスと比較して、最大 25% 優れたコンピューティングパフォーマンスを提供します。ウェブアプリケーションでは最大 35%、機械学習推論では最大 35%、データベースでは最大 30% 高速なパフォーマンスを実現します。Graviton5 は、AWS フリートで初めて PCIe Gen6 と DDR5-8800 メモリをサポートするプロセッサであり、前世代と比較して 5 倍大きい L3 キャッシュを含みます。M9g および M9gd インスタンスは、M8g と比較して、サイズを問わず平均で最大 15% 広いネットワーク帯域幅と 20% 広い Amazon EBS 帯域幅を提供します。また、今回のリリースでは、Nitro System の機能強化である Nitro Isolation Engine も導入されました。これは、形式検証を用いて仮想マシン間の数学的に証明された分離を提供するものであり、Nitro を初の形式検証済みのクラウドハイパーバイザーとして位置づけるものです。M9gd インスタンスは、M8gd と比較して最大 11.4 TB の NVMe SSD ローカルストレージと 30% 高い IOPS を追加します。両インスタンスタイプとも、EBS と VPC ネットワーキング間の帯域幅の割り当てを最大 25% 調整できるよう、Instance Bandwidth Configuration (IBC) をサポートしています。 Amazon Bedrock での Anthropic Claude Fable 5 – Claude Fable 5 は 6 月 9 日に Amazon Bedrock でリリースされました。これは、拡張された非同期タスク実行、図表、チャート、PDF 全体にわたる高度な視覚的機能、およびプロアクティブな自己検証を提供します。アクセスするには、モデルを呼び出す前に Data Retention API を介してデータ共有をオプトインする必要があります。Anthropic は、Mythos クラスのモデルで入出力の 30 日間の保持を要求しています。 可用性に関する重要なお知らせ: 6 月 12 日、Anthropic から AWS に対して、米国政府の輸出管理指令を遵守するため、すべてのユーザーについて、Claude Fable 5 および Claude Mythos 5 へのアクセスを取り消すよう要請がありました。Opus 4.8 を含む他のすべてのモデルは影響を受けません。詳細については、 Anthropic の声明 をお読みください。AWS は、今後新たな情報が入り次第、共有します。 Amazon Bedrock で Gemma 4 モデルが利用可能に – Google DeepMind の Gemma 4 ファミリーが、Amazon Bedrock において 3 つのバリアント、すなわち、Gemma 4 31B (Dense、256K トークンのコンテキストウィンドウ、推論およびコーディングワークロードに適しています)、Gemma 4 26B-A4B (Mixture of Experts、コストとレイテンシーが重要な要素となるワークロードを対象としています)、Gemma 4 E2B (最小バリアント、低レイテンシーのインタラクティブなユースケース向けに設計されています) で利用可能になりました。これらの 3 つはすべて、ネイティブ関数呼び出し、構造化された出力、推論、レスポンスストリーミング、テキスト、画像、動画、音声にわたるマルチモーダル入力、35 を超える言語をサポートしています。 Amazon OpenSearch Service がエージェンティックオブザーバビリティのための MCP アプリケーションをリリース – Amazon OpenSearch Service が MCP アプリケーションをサポートするようになりました。これにより、Claude Desktop や VS Code などの互換性のあるエージェンティック IDE 内でオブザーバビリティワークフローを実現できます。ローカル環境の AI エージェントは、OpenSearch ドメイン、コレクション、および Amazon Managed Service for Prometheus に保存されているログ、トレース、メトリクス、アラートを使用してインシデントを調査できます。MCP アプリケーションツールの呼び出しごとに、エージェントが推論するためのテキスト要約と、同じ会話スレッドにレンダリングされるインタラクティブなビジュアライゼーションという 2 つの応答が返されます。使用可能な MCP アプリケーションツールは、ログ、メトリクス、トレースの調査、サービスパフォーマンス、トポロジ、動的ビジュアライゼーション、エージェントの状態、クラスターの状態、およびインストルメンテーションスコアリングをカバーしています。 その他の AWS ニュース お客様に役立つ可能性のある他の記事や最新情報をいくつか次に示します: AWS CLI v1 がメンテナンスモードに移行 – CLI v1 がメンテナンスモードに移行すると、botocore と s3transfer の依存関係は、個別のパッケージとしてインストールされるのではなく、CLI v1 のコードベースに直接組み込まれるようになります。これは、CLI v1 をアップグレードしても、スタンドアロンの botocore または s3transfer パッケージは更新されなくなり、これらのパッケージを個別にインストールしても、CLI v1 によって使用されるバージョンには影響しないことを意味します。CLI v1 と boto3 の両方がインストールされている環境には、これらのライブラリの個別のコピーが含まれます。CLI v1 の新しいリリースは、重大なバグ修正とセキュリティ問題に限定されます。推奨パスは、AWS CLI v2 に移行することです。 AWS Workload Credentials Provider が利用可能に – AWS は、ワークロードが長期アクセスキーを必要とせずに短期的な AWS 認証情報を取得できるようにする、新しい Workload Credentials Provider をリリースしました。これは、AWS 外で実行されているアプリケーションの認証情報の管理をサポートします。これにより、チームは、サードパーティーまたはオンプレミス環境のワークロードのために、最小特権アクセスパターンに従うことができます。 Kiro Pro Max が利用可能に – Kiro は、より高い使用制限、最新のフロンティアモデルへのアクセス、および開発チーム向けの追加のエージェンティック機能を追加した新しい Pro Max 階層を導入しました。Kiro Pro Max は、コーディング、仕様の生成、エージェントドリブンのタスク全体で持続的かつ大量の使用を必要とするプロデベロッパー向けに設計されています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Summits – AWS Summits は、クラウドと AI をカバーする無料の実地イベントです。今後の開催予定: ニューヨーク市 (6 月 17 日)、 香港 (6 月 17 日)、 上海 (6 月 23 日～24 日)、 日本 (6 月 25 日)、 ワシントン D.C. (6 月 30 日～7 月 1 日)、 台北 (7 月 15 日)、 ボゴタ (7 月 30 日)。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 モントリオール (カナダ) (6 月 20 日)、 インディアナポリス (米国) (6 月 24 日)、 杭州 (中国) (6 月 28 日)、 ベンガルール (インド) (7 月 11 日)、 ヤウンデ (カメルーン) (7 月 25 日) が含まれます。 AWS Builder Center にアクセスして、他のビルダーと交流したり、ソリューションを提供したり、構築を継続するのに役立つリソースを見つけたりしましょう。また、今後開催される AWS 主導の実地およびオンラインイベント や、 デベロッパー向けセッション もご覧いただけます。 – Esra この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

AI Agent が企業のワークフローに組み込まれ始めている中で、「エージェントにどこまでの権限を持たせるべきか」「ユーザーの操作として実行されるべきなのか、エージェント自身の権限で実行されるべきなのか」といった設計判断に悩まれている方は多いのではないでしょうか。従来のアプリケーションとは異なり、エージェントは自律的にツールを呼び出し外部リソースへアクセスするため、認証・認可の設計にも新しい考え方が必要になります。 こうした課題に取り組む開発者・セキュリティエンジニアの皆様を対象に、2026 年 5 月 22 日、AWS 麻布台ヒルズオフィスにて「Security for App Builders #2」を開催しました。ご参加いただきました皆様には、改めて御礼申し上げます。 本ブログでは、当日の各セッションの概要をお伝えするとともに、発表資料を公開いたします。AI Agent のアイデンティティ制御に関心をお持ちの方にとって、設計の出発点となる情報が得られる内容になっていますので、ぜひご覧ください。 Security for App Builders とは 「Security for App Builders」は、アプリケーション開発者・セキュリティエンジニアを対象としたセキュリティイベントシリーズです。アプリケーション開発や SDLC におけるセキュリティの原理原則とプラクティスを、セッションとハンズオンを通じて学んでいただくことを目的としています。 昨年 11 月に実施した第一回 では「Coding Agent が生成したコードの安全性をどう確保するか」を扱いました。第二回となる今回は、エージェント自体の開発をテーマとして取り上げ、自律的にアクションを起こす段階で必要になる 認証・認可・監査可能性 に焦点を当てています。 イベント概要 エージェント型 AI は、従来のソフトウェアと生成 AI の特徴を併せ持ちます。ユーザーの指示に基づいて自律的にツールを呼び出し外部リソースへアクセスする一方で、その挙動は非決定論的です。この自律性を維持しつつ、決定論的なセキュリティ制御を与えるためにはアイデンティティ（認証・認可）の設計が重要になります。 本イベントでは、AWS セッション・お客様事例・ハンズオンを通して、AI Agent における基本となる考え方、実際のお客様での実践例を学び、AWS のマネージドサービスでの実現方法を体験いただきました。セッション終了後にはネットワーキングの時間も設け、各社のプロダクトセキュリティに関心を持つ方同士での情報交換が行われました。ご参加いただきました皆様には、改めて御礼申し上げます。 以下、各セッションの概要と当日の様子を紹介いたします。 セッションの紹介 AWS Session : AI Agent のアイデンティティ制御 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 デジタルサービス技術本部 シニアソリューションアーキテクト 柴田 龍平 最初のセッションでは、AI Agent のセキュリティの考え方とその基礎となるアイデンティティについてベースとなる考え方についてお話しました。 エージェントティック AI は自律的にツールを呼び出し、人間の数十〜数百倍の速度でアクションを実行します。これにより生産性が大きく向上する反面、エージェントが予想外の動作をしないような制御も必要になります。ただし、LLM の内部にはセキュリティを強制するメカニズムが存在しないため、プロンプトでルールを与え、行動を制限するような実際には効果は限定的です。そこで、エージェントの外部に決定論的なコントロールを導入するというアプローチがセキュリティの出発点となります。その外部コントロールの中核となるアイデンティティについて「誰として認証されるのか」「何を許可し何を禁止するか」「その操作を後から追跡できるか」── この 3 つをAWS 上で設計するために Amazon Bedrock AgentCore Identity / Policyや AWS Verified Permissions がどのように活用いただけるかを解説を行いました。 セッション資料 Customer Session : Cedar × AI Agent の認可基盤 – ポリシー設計とアーキテクチャ 株式会社エクサウィザーズ アーキテクト 小島 和也 氏 続いてのセッションでは、エクサウィザーズの小島氏より、Cedar を用いた AI Agent の認可基盤についてお話しいただきました。 「飲み会の幹事をエージェントに任せたら、役員の非公開スケジュールまで読めてしまうとよくないですよね？」という問いかけから始まり、場合によっては上書きされうるプロンプトでは行動が縛れない以上、「認可（Authorization）」の仕組みで縛るというアプローチを説明いただきました。その具体的な実現として、①鍵を縛る（エージェントが持つクレデンシャルをユーザー本人のものに制御する）②呼び出し方を縛る（ツール 1 本ずつに認可をかける）③相手そのものを縛る（エージェントの起動自体を制御する）── という三層の認可モデルを Cedar で実装し、さらに業務管理者が GUI で Business Policy を 1 件作成するだけで裏側の Cedar Policy が自動生成される Translation Layer により、ポリシーの爆発を防ぎつつ非エンジニアでも運用できる基盤を実現されています。 また、Cedar をプロダクトに組み込むにあたり、ローカル開発では Cedar エンジンを直接使い、本番では環境変数を切り替えるだけで Amazon Verified Permissions（AVP）に移行できる設計の工夫など実践的な知見も共有いただきました。 セッション資料 Workshop : AI エージェントの認証・認可・ログ設計ハンズオン アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ソリューションアーキテクト 松井 僚太郎 Workshopで構築するアーキテクチャ 最後のワークショップでは、松井が講師を務め、参加者の皆様に以下の一連の流れを実際に手を動かしながら体験いただきました： AgentCore Identity を使ったエージェントへのアクセス制御 ツール利用時の認可フロー実装 監査ログの設計と出力 概念として理解していても、実際に実装してみると考慮すべきポイントが多いのがエージェントセキュリティの特徴です。本ワークショップでは、手を動かしながらそれらのポイントを体感いただくことを重視して設計しました。 Workshop まとめ AI Agent の活用が広がる中で、「何にアクセスできるか」「誰として操作するか」「その操作を後から追跡できるか」というアイデンティティの設計は、エージェントを本番環境に投入するうえで避けて通れないテーマです。本イベントでは、この課題に対する原理原則の理解から、AWS サービスを使った実装、そしてお客様のプロダクション事例まで、一連の流れを体験いただきました。AI Agent を活用しながらよりセキュアで信頼性の高いアプリケーションを構築するためのヒントを得ていただけていれば幸いです。 AWS では Amazon Bedrock AgentCore を通じて、エージェントのアイデンティティ制御をよりシンプルに実現するための仕組みを提供しています。各セッション資料もぜひ併せてご参考ください。 今後もこのようなイベントを継続的に企画・開催してまいります。ご興味をお持ちの方がいらっしゃいましたら、お近くの AWS 営業担当もしくは技術担当にお気軽にお声がけください。 アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 柴田 龍平 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 松井 僚太郎

本記事は 2026 年 6 月 3 日に AWS Migration & Modernization Blog で公開された Consistent Code Modernization at Scale with AWS Transform custom Knowledge Items を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 はじめに AWS Transform custom (ATX) は、コードモダナイゼーションを大規模に自動化します。各リポジトリで AI コーディングアシスタントを個別に実行する場合と異なるのは、ATX が 学習する ということです。各実行からパターン、修正、エッジケースを再利用可能なナレッジとして蓄積するため、変換は実行するたびに高速化し、信頼性も向上します。 Java 8 のリポジトリを数百個抱えていたり、非推奨 API を使った Spring Boot 2.x アプリ、あるいは AWS Graviton で動かせるにもかかわらず x86 に縛られたワークロードがある場合、こうした技術的負債こそがチームの開発速度を妨げている原因です。手動でのアップグレードはスケールしません。数百のリポジトリにまたがる Java のアップグレードは単調な繰り返し作業であり、この規模の繰り返しは一貫性の欠如を招きます。 AWS Transform custom は Agentic AI を活用してこれらの変換を自動化します。一般的なシナリオに対応する AWS マネージドな変換 が同梱されているほか、独自の カスタム変換定義 を構築することも可能です。改善の蓄積は ナレッジアイテム によって実現されます。ナレッジアイテムとは、各実行からパターン、修正、エッジケースを蓄積する再利用可能なアーティファクトであり、将来の実行で自動的に適用されます。 本記事では、サンプルの Spring Boot プロジェクトを Java 8 から 26 にアップグレードし、ナレッジアイテムがどのように生成・管理されるかを確認し、同じ変換をリポジトリのポートフォリオ全体に適用する方法をご紹介します。 開始方法 実際のプロジェクトで Java 8 から 26 へのアップグレードを実行し、Transform custom の動作を確認しましょう。 前提条件 AWS Transform custom へのアクセス が有効化された AWS アカウント ATX CLI の インストールおよび設定 Java 8 以上、Java 26、Maven のインストール（サンプルプロジェクトのビルド用） Git のインストール Java と Maven の基本的な知識 シナリオ 本記事では aws-appconfig-java-sample を使用します。これは Java 8 と Maven で構築された Spring Boot アプリケーションで、非推奨の Java API や古いフレームワークバージョンに依存している、典型的なモダナイゼーション候補です。 セットアップ リポジトリをクローンします: git clone --depth 1 https://github.com/aws-samples/aws-appconfig-java-sample.git ディレクトリに移動します: cd aws-appconfig-java-sample ローカル依存関係をインストールします: mvn install:install-file \ -Dfile=./movie-service-utils/built-library/0_1_0/movie-service-utils-0.1.0.jar \ -DgroupId=com.amazonaws.samples \ -DartifactId=movie-service-utils \ -Dversion=0.1.0 \ -Dpackaging=jar ビルドが通ることを確認します: mvn clean compile -DskipTests 変換定義 変換定義 (Transformation Definition) は、Transform custom に 何を どのように変換するかを指示する再利用可能なレシピです。ソースとターゲットのスタック、変換パターン、コーディング規約、そしてエージェントに従わせたい組織ナレッジが含まれます。AWS は Java のバージョンアップグレードなど一般的なアップグレード向けに マネージド変換定義 を提供しています。組織固有のニーズに合わせて 独自の変換定義を構築する ことも可能です。 変換定義の実行 インタラクティブモードと自律モードの 2 つから選択できます。インタラクティブモードでは、ツール使用の確認、計画のレビュー、ステップの承認が求められます。自律モード ( -x ) は確認なしですべてを実行するモードで、CI パイプラインや一括実行で使用します。 ここでは -x で自律モード、 -t ですべてのツールを信頼する設定で実行します。 -t は注意して使用してください。すべてのコンテキストでエージェントが任意のツールをトリガーすることを許容したくない場合もあります。 CLI コマンドリファレンス にオプションの一覧があります。 AWS/java-version-upgrade は、Java プロジェクトを Java 26 にアップグレードするマネージド変換定義です: atx custom def exec -n "AWS/java-version-upgrade" -p . -c "mvn clean compile -DskipTests" -x -t -g "additionalPlanContext=The target Java version to upgrade to is Java 26" 上記コマンドの出力を以下の画像に示します。 AWS/java-version-upgrade 変換定義は Java 26 をターゲットとし、アップグレードの全範囲を処理します。 javax.security.cert の移行、Spring Boot のメジャーバージョンアップグレード、テスト依存関係のモダナイゼーション、ビルドツールの更新など、POM ファイル内の Java バージョン番号を変更するだけではありません。 エージェントは依存関係グラフ全体を分析し、すべての変更を一括で適用し、コンパイルとテストの両方を検証した後、すべてを単一のアトミックなコミットとして記録しました。14 件の個別の変更（依存関係のアップグレード、API の移行、ビルドツールの更新）がすべて一緒に検証されました。実行ログには、実行内容、遭遇した問題（Spring Boot 3.2.12 の ASM が Java 26 と非互換、Mockito の ByteBuddy の問題）、およびそれらの解決方法が記録されています。 14 件の変更、1 つのアトミックコミット、完全なビルドとテストの検証。しかしエージェントはコードの変更を生成しただけではありません。何がうまくいき、何がうまくいかなかったかも観察しました。この観察こそがナレッジアイテムの源であり、別のリポジトリに対する次の実行が今回よりも高速になる理由です。 結果の確認 変更は専用のローカル Git ブランチに反映されます。Transform custom はリモートにプッシュしません。標準的な Git ツールで確認できる完全な監査証跡が得られます。コミットメッセージにはすべての変更が詳細に記載され、実行ログには遭遇した問題と解決方法が記録されます。インタラクティブモード（ -x なし）で実行した場合は、実行開始前に計画をレビュー・修正でき、検証ステップや外部ツールチェックなど必要なゲートを追加できます。 変換によるすべての変更を確認するには: git diff main diff --git a/pom.xml b/pom.xml --- a/pom.xml +++ b/pom.xml @@ -5,7 +5,7 @@ <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.0.5.RELEASE</version> + <version>3.5.14</version> </parent> diff --git a/src/main/java/.../movies/MoviesController.java b/src/main/java/.../movies/MoviesController.java --- a/src/main/java/.../movies/MoviesController.java +++ b/src/main/java/.../movies/MoviesController.java @@ -1,5 +1,5 @@ -import javax.validation.Valid; +import jakarta.validation.Valid; diff --git a/src/main/java/.../utils/Security.java b/src/main/java/.../utils/Security.java --- a/src/main/java/.../utils/Security.java +++ b/src/main/java/.../utils/Security.java @@ -1,5 +1,5 @@ -import javax.security.cert.*; +import java.security.cert.*; 代表的な 3 つの変更を示します。Spring Boot が 2.0.5.RELEASE から 3.5.14 に（エージェントは 3.2.12 の ASM が Java 26 のクラスフォーマットをサポートしないことを検出し、3.5.14 にアップグレードしました）、 javax.validation.Valid が jakarta.validation.Valid に移行、 javax.security.cert が java.security.cert に置き換えられました。完全な diff には Mockito と JUnit の依存関係更新、Gradle ビルドのモダナイゼーション、AWS SDK BOM のアップグレードも含まれます。 変更内容に問題がなければ、マージします: git checkout main git merge <transformation-branch-name> 変換の改善 最初の実行は動作します。面白くなるのは 2 回目からです。 リファレンスとナレッジアイテム Transform custom が変換精度を向上させる手段は 2 つあります。 リファレンス は、変換定義の作成時にアップロードする移行ガイド、API 仕様、コードサンプルなど、事前に提供するドキュメントです。即座に有効化され、完全にお客様の管理下にあります。 ナレッジアイテム は、実際の変換中に何が起こったかを観察することで、システムが自ら学習したものです。Transform custom は各実行後に非同期でナレッジアイテムを生成し、無効状態で開始し、お客様がレビューして承認した場合にのみ適用されます。 リファレンスが出発点を設定し、真に価値が積み上がるのはナレッジアイテムによってです。本記事の残りでは、このナレッジアイテムに焦点を当てます。 ナレッジアイテムの管理 どのナレッジアイテムを有効にするかは、お客様が制御します。承認なしに有効化されることはありません。 これまでに蓄積されたものを一覧表示するには: atx custom def list-ki -n "AWS/java-version-upgrade" 以下のナレッジアイテムは、先ほどの変換実行で生成されたものです。エージェントはプロジェクトのアップグレード中にこれらの問題に遭遇し、自動的に記録しました: KI - 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 - DISABLED Title: Mockito 5.14.2 ByteBuddy incompatible with Java 26 Description: Mockito 5.14.2 fails to mock standard library classes like ArrayList under Java 26. Error message indicates ByteBuddy cannot modify ArrayList and related collection classes. Mockito 5.15.2 resolves the compatibility issue. Fix: Upgrade Mockito to 5.15.2: <!-- Before - ByteBuddy in Mockito 5.14.2 can't handle Java 26 --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.14.2</version> <scope>test</scope> </dependency> <!-- After - Mockito 5.15.2 supports Java 26 bytecode --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.15.2</version> <scope>test</scope> </dependency> KI - adb1b8e6-4199-4d4d-964c-1eab5c94de1a - DISABLED Title: Spring Boot 3.2.12 ASM lacks Java 26 class format support Description: Spring Boot 3.2.12 uses ASM library version that cannot parse Java 26 class files (major version 70). Test execution fails with "Incompatible class format" during classpath scanning. Spring Boot 3.5.14 or newer required for Java 26 compatibility. Fix: Upgrade Spring Boot to 3.5.14: <!-- Before - ASM in Spring Boot 3.2.12 can't parse Java 26 classes --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.12</version> </parent> <!-- After - Spring Boot 3.5.14 includes ASM with Java 26 support --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.5.14</version> </parent> どちらもデフォルトでは DISABLED です。有効化する前にレビューを行います。各説明には、何が変更されたか、なぜ重要か、症状、そして正確な修正方法が記録されています。これらは、Java 26 アップグレード中にエージェントが遭遇した 2 つの異なるカテゴリの問題です: Mockito/ByteBuddy: バイトコード操作の失敗。Mockito にバンドルされた ByteBuddy が Java 26 のクラスフォーマットを処理できず、テスト時のモックが実行時に失敗する。 Spring Boot ASM: クラスフォーマット解析の失敗。Spring Boot の ASM ライブラリがクラスパススキャン中に Java 26 のバイトコードをスキャンできず、テスト実行が完全に破綻する。 どちらもコンパイルだけでは検出できません。アップグレード後のコードに対してテストを実行する必要があり、そのためビルド検証コマンドが重要になります。 ナレッジアイテムを有効化するには: atx custom def update-ki-status -n "AWS/java-version-upgrade" --id 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 --status ENABLED atx custom def update-ki-status -n "AWS/java-version-upgrade" --id adb1b8e6-4199-4d4d-964c-1eab5c94de1a --status ENABLED すべてのナレッジアイテムを Markdown にエクスポートしてオフラインでレビューすることもできます: atx custom def export-ki-markdown -n "AWS/java-version-upgrade" Markdown へのエクスポートは、チームがオフラインでナレッジアイテムをレビューしたり、スプリント計画や技術的負債レビューのセッションでどれを有効化するかを議論したりする場合に便利です。自分のコードベースに対して適用範囲が広すぎるナレッジアイテムがあれば、無効化してください。次回別のリポジトリで実行した際に、より限定的な修正パターンが生成されることがあります。そちらを有効化すれば、徐々に汎用的なアドバイスではなく、組織の実コードに即したナレッジアイテムを取捨選択していけます。 なお、これらのナレッジアイテムはお客様の組織に固有のものであり、他のお客様とは共有されません。 学習ループ Transform custom の価値はイテレーションにあります。実行し、エージェントが学習した内容を蓄積し、有効化し、再度実行する。先ほどの 2 つのナレッジアイテムを有効化した状態で、同じ変換定義を 2 番目のリポジトリに対して実行します: git clone --depth 1 <second-repo-url> cd <second-repo> atx custom def exec -n "AWS/java-version-upgrade" -p . -c "<build-command>" -x -t 最初のリポジトリでは、ビルド検証コマンドとして -DskipTests を渡しましたが、エージェントはアップグレードの検証のためにテストも独立して実行しました。そのテスト実行中に、反復的に解決した 2 つの問題に遭遇しました: Mockito 5.14.2 が標準ライブラリクラスのモックに失敗。バンドルされた ByteBuddy が Java 26 のバイトコード操作を処理できなかったため、エージェントは 5.15.2 にアップグレード。 クラスパススキャン中に「Incompatible class format」でテスト実行が失敗。エージェントが最初に行った Spring Boot 3.2.12 へのアップグレードでは、Java 26 のクラスファイル（メジャーバージョン 70）を解析できない ASM バージョンが使用されていた。3.5.14 にアップグレード。 Transform custom はこれらを観察し、先ほどレビューしたナレッジアイテムとして蓄積し、修正内容を記録しました。エージェントは問題を解決し、その経験から再利用可能なナレッジを生成しました。 これらを有効化して 2 番目のリポジトリで実行します: atx custom def update-ki-status -n "AWS/java-version-upgrade" --id 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 --status ENABLED atx custom def update-ki-status -n "AWS/java-version-upgrade" --id adb1b8e6-4199-4d4d-964c-1eab5c94de1a --status ENABLED Mockito 5.14.2 または Spring Boot 3.2.x を使用して Java 26 をターゲットとする後続のリポジトリでは、Transform custom がテスト実行前に事前に修正を適用します。Mockito は 5.15.2 にアップグレードされ、Spring Boot は 3.5.14 に引き上げられます。テストは通過し、手動介入は不要です。 以前のリポジトリではデバッグと手動修正が必要だったことが、その後のすべてのリポジトリで自動的な修正になります。各実行はより高速で信頼性が高くなり、次の実行のために新しいエッジケースを蓄積します。 具体的に説明します。この変換定義を 1 週間で 15 の Spring Boot リポジトリに実行するとします。4 番目のリポジトリまでに、Mockito 5.14.2 を使用するすべてのプロジェクトに対して事前にアップグレードが適用されます。6 番目のリポジトリまでに、Java 26 をターゲットとする古い 3.x バージョンを検出するたびに Spring Boot 3.5.14 へのバージョンアップが自動的に行われます。10 番目のリポジトリでは、カスタム @Query アノテーションを持つリポジトリで Hibernate 6 のダイアレクト変更が問題になるかもしれません。すべての実行で新しいナレッジアイテムが生成されるわけではなく、エージェントが何を発見するかに依存します。しかし生成されたものをレビューし、望ましいものを有効化すれば、後続のすべての実行がその恩恵を受けます。15 番目のリポジトリは、最初のリポジトリよりもクリーンな変換になります。なぜなら、それ以前の 14 個分の蓄積された経験を持っているからです。 大規模な実行 本記事では 2 つのリポジトリを扱いました。大規模に展開する場合は、同じ変換定義をポートフォリオ全体に適用します。これが Learn-Scale-Improve フライホイール です。各実行が新しいナレッジアイテムを蓄積し、後続のすべての実行がシステムのこれまでの学習内容から恩恵を受けます。20 番目のリポジトリでは、最初のリポジトリで手動介入が必要だったパターンを自動的に処理します。 数百のリポジトリにまたがる実行には自動化が必要です。 aws-transform-custom-samples リポジトリには 2 つのオープンソースアプローチがあります: Bash 自動化 : ワークステーションから並列実行、進捗ダッシュボード、自動リトライを備えて実行します。 コンテナベース実行 : AWS Batch + AWS Fargate 上で数百から数千のリポジトリに対して実行します。セットアップの手順は AWS DevOps ブログの記事 をご参照ください。 クリーンアップ 変換はローカルで実行され、AWS リソースはプロビジョニングされません。クリーンアップするには: cd .. rm -rf aws-appconfig-java-sample AWS Batch でスケール実行を行った場合は、 コンテナベース実行の README にあるクリーンアップ手順に従ってください。 まとめ ナレッジアイテムはポートフォリオ全体で蓄積されます。各実行はエージェントが遭遇した内容に応じて新しい学びを生成する可能性があり、有効化したものが後続のすべての実行を高速化します。単発のリファクタリングスプリントではなく、今日の負債削減が明日のデリバリーを直接加速させる継続的なループが得られます。 ぜひお試しください: ご自身のリポジトリをクローンし、 AWS/java-version-upgrade 変換定義を実行して、生成されるナレッジアイテムを確認してみてください。組織固有のパターン（フレームワーク移行、コーディング規約の強制、依存関係の置き換え）がある場合は、 カスタム変換定義を作成 し、いくつかのリポジトリで実行して学習ループの動作を確認してみてください。 AWS Transform custom ドキュメント AWS マネージド Java アップグレード変換定義 : ご自身のコードベースでお試しください 独自の変換定義を作成 して組織固有のパターンに対応 aws-transform-custom-samples : 大規模実行のためのスクリプトとインフラ 著者について Jean-Baptiste Guillois Jean-Baptiste は、AWS のシニアスペシャリストソリューションアーキテクトであり、アプリケーションの移行とモダナイゼーションを専門としています。エンタープライズおよびソフトウェアベンダーとの 20 年以上の経験を持ち、AI を活用したサービスを使ってお客様がアプリケーションをより効率的にモダナイズできるよう支援することに情熱を注いでいます。 Gengis Birsen Gengis Birsen は、AWS の AI/ML および Generative AI スペシャリストソリューションアーキテクトです。エンタープライズのお客様と連携し、エージェント、評価、強化ファインチューニング、検索に重点を置いて、現在の生成 AI に関する課題に取り組んでいます。仕事以外では、現在の趣味は娘と一緒に Connetix のビルドを共同設計することです。

お知らせ 2026年7月からオンラインでサーバーレスに関するワークショップを4件開催します。ぜひ、ご参加ください。 7/7 10:00〜12:00 Kiroによるサーバーレス開発 7/9 10:00〜12:00 イベント駆動アーキテクチャ・アプリケーションの構築 7/14 10:00〜12:00 AWS Lambda durable functions によるコード型ワークフロー 7/16 10:00〜12:00 AWS Lambda マネージドインスタンス 本記事は、2026 年 3 月 30 日に公開された Build high-performance apps with AWS Lambda Managed Instances を翻訳したものです。翻訳は Solutions Architect の 齋藤 拓巳 が担当しました。 最新のサーバーレスイノベーションを把握して、アプリケーションの変革に役立てましょう。 この第 31 回四半期レビューでは、2025 年第 4 四半期に発表された、見逃しているかもしれない AWS サーバーレスの重要なリリース、機能、リソースをご紹介します。 前回の ICYMI を見逃した方は、 2025 年第 3 四半期 の内容をご確認ください。 2025 年第 4 四半期カレンダー re:Invent 2025 におけるサーバーレス この記事では、re:Invent 2025 で発表された主要なサーバーレス関連のアナウンスを取り上げ、アプリケーションの改善に役立つ重要な機能アップデートを紹介するとともに、最新情報を把握するための有用なリソースを共有します。 AWS re:Invent 2025 には 60,000 人以上が現地参加し、基調講演には 200 万人以上のオンライン視聴者が集まりました。 イベントでは 3,000 人のスピーカーによる 3,500 のセッションが開催され、530 の AWS サービスおよび機能のアナウンスに関する情報が紹介されました。 基調講演 サーバーレスムーブメントの火付け役 サーバーレス関連のコンテンツは、Containers and Serverless (CNS) と Application Integration (API) の 2 つのトラックで構成されていました。 これらのトラックでは 150 種類のセッションが開催され、16,000 人を超える参加者が現地で視聴しました。 開発者向けの体験として、 Road to re:Invent Hackathon 、AWS Builder Loft、Builders Arena が用意されていました。 サーバーレステクノロジーで運営されるコーヒーショップ Serverlesspresso は、イベント期間中、Expo Hall と認定資格ラウンジの 2 か所で営業していました。 サーバーレスおよび開発者コミュニティの写真 厳選されたサーバーレス動画のリストは Serverless Land YouTube でご覧いただけます。 AWS Lambda durable functions マルチステップのサーバーレスワークフローにおける状態管理には、従来、複雑な外部オーケストレーションツールが必要でした。 AWS Lambda の durable functions は、開発者が Lambda を活用する方法を拡張します。 信頼性の高いマルチステップのアプリケーションや AI ワークフローを Lambda 内で直接構築できるようになりました。 AWS Lambda durable functions のコード durable functions は、実行中の重要なポイントで現在の状態と完了したステップを保存することで、自動的に進捗のチェックポイントを保存します。 これにより、長時間実行されるタスク中に最大 1 年間実行を一時停止でき、障害が発生した場合も最初からやり直すのではなく最後のチェックポイントから再開して復旧できます。しかも追加のインフラストラクチャ管理は一切不要です。 開発者は Python または TypeScript で構築し、自動リトライとチェックポイント機能を備えたステップで呼び出しをラップできるようになりました。 wait を使用すると、アイドル状態のコンピューティングに課金されることなく、数分、数時間、最大 1 年間まで実行を一時停止できます。 durable functions はリプレイメカニズムを使用して状態を維持し、障害を適切に処理します。 このメカニズムは、障害からの復旧時にチェックポイントから関数コードを再実行することで動作し、データを失うことなく状態の一貫性を確保します。 これにより、多くのユースケースで複雑な外部オーケストレーションツールが不要になります。 外部インフラストラクチャを管理することなく信頼性の高い状態管理が必要な AI ワークフローやマルチステップアプリケーションに特に役立ちます。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画をご覧ください: Deep Dive on AWS Lambda durable functions (CNS380) AWS Lambda Managed Instances Lambda は、 Lambda Managed Instances という新しいコンピューティングオプションを提供開始しました。これは Amazon EC2 の柔軟性とフルマネージドインフラストラクチャを組み合わせたものです。 AWS がインスタンスのプロビジョニング、スケーリング、メンテナンスを自動的に処理しながら、Graviton4、ネットワーク最適化インスタンス、その他の特殊なコンピューティングオプションを含む EC2 の幅広い機能にアクセスできます。 AWS Lambda Managed Instancesの設定 関数は、お客様のアカウントの専用 EC2 キャパシティ上で、お客様自身の Amazon Virtual Private Cloud (Amazon VPC) 内で実行されます。 OS パッチ適用、ロードバランシング、オートスケーリングなどの運用オーバーヘッドは引き続き AWS が管理します。 これにより、サーバーレスの運用モデルを維持しながら、特殊なハードウェアオプションにアクセスできます。 Compute Savings Plans や Reserved Instances などの EC2 料金モデルを Lambda ワークロードに活用することで、コストをさらに最適化できます。 各インスタンスは複数の同時リクエストを処理できるため、予測可能な料金体系と特定のハードウェア要件が重要な、大量かつ定常的なワークロードに特に適しています。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画 Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382) をご覧ください。 その他の Lambda に関する発表 マルチテナント SaaS アプリケーションには、テナント間のデータ漏洩や、あるテナントのワークロードが他のテナントに影響を与えるノイジーネイバー問題といった課題があります。 また、カスタムの分離メカニズムの実装にも苦労してきました。 テナント分離モード は、テナントごとに個別の実行環境で関数の呼び出しを処理することで、これらの課題に対処します。 これにより、テナントレベルのコンピューティング環境の分離が自動的に管理されます。 AWS Lambda tenant isolation Lambda は Amazon SQS イベントソースマッピングに Provisioned Mode を追加しました。これにより、高スループットの SQS 処理ワークロードにおいて、予測可能なパフォーマンスとコールドスタートの削減を実現します。 非同期 Lambda 呼び出しで 最大 1 MB のデータを送信 できるようになりました。 従来の 256 KB から引き上げられ、より複雑なデータ処理シナリオの構築が可能になります。 Lambda 関数は IPv6 ネットワーキング をサポートするようになったため、VPC に接続された関数からインターネットや他の AWS サービスにアクセスする際に NAT Gateway が不要になりました。 NAT Gateway を介した Lambda のインターネット接続 (IPv4) と、Egress-Only インターネットゲートウェイを介した Lambda のインターネット接続 (IPv6) です。 Lambda の Rust サポート が一般提供 (GA) になり、実験的ステータスから移行しました。 これは AWS サポートおよび Lambda の可用性 SLA の対象となります。 Lambda は、 Python 3.14 、 Node.js 24 、 Java 25 をマネージドランタイムおよびコンテナベースイメージとして追加し、ランタイムサポートを拡充しました。 これにより、最新の言語機能を利用でき、長期サポートも確保されます。 Amazon ECS Amazon Elastic Container Service (Amazon ECS) Express Mode は、従来開発者の作業を遅らせていたインフラストラクチャのセットアップを自動化することで、コンテナ化されたアプリケーションのデプロイと管理を効率化します。 Amazon ECS Express Mode デプロイメント これにより、AWS のベストプラクティスを活用して自信を持ってデプロイしながら、アプリケーションの構築に集中できます。 Express Mode では、単一のコマンドで本番環境対応のコンテナ化された Web アプリケーションと API をデプロイできます。 シンプルな API を通じて、ドメイン、ネットワーキング、ロードバランシング、 AWS Identity and Access Management (IAM) ロール、オートスケーリングが自動的に処理されます。 アプリケーションが進化し、高度な機能が必要になった場合は、Amazon ECS を含むリソースのすべての機能をシームレスに設定してアクセスできます。 詳細については、 発表ブログ記事 をご覧ください。 Amazon ECS は、AI を活用した開発・運用体験を実現するフルマネージド型の MCP サーバー のパブリックプレビューを発表しました。 この Model Context Protocol (MCP) サーバーは、自動更新とパッチ適用、AWS IAM 統合による一元的なセキュリティ管理、 AWS CloudTrail を通じた包括的な監査ログ、そして AWS が実証済みのスケーラビリティ、信頼性、サポートといったエンタープライズグレードの機能を提供します。 Amazon Elastic Container Registry (ECR) の マネージドコンテナイメージ署名 は、セキュリティ体制を強化し、署名のセットアップにかかる運用上のオーバーヘッドを排除します。 コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。 ECR は、イメージがプッシュされる際に、プッシュしたエンティティの ID を使用して自動的にイメージに署名します。 署名操作は CloudTrail を通じてログに記録されるため、完全な監査が可能です。 Amazon API Gateway Amazon API Gateway では、レスポンスペイロードをクライアントに 段階的にストリーミング することで、REST API の応答性を向上させることができます。 この新機能により、ストリーミングレスポンスを使用して、LLM 駆動のアプリケーション (AI エージェントやチャットボットなど) を構築する際のユーザーエクスペリエンスの向上、Web およびモバイルアプリケーションの Time-to-First-Byte (TTFB) パフォーマンスの改善、大容量ファイルのストリーミング、 Server-Sent Events (SSE) などのプロトコルを使用した増分的な進捗報告を伴う長時間実行オペレーションの実行が可能になります。 Amazon API Gateway streaming API Gateway は、 Application Load Balancer (ALB) との プライベート統合 を導入しました。 これにより、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API を通じて安全に公開できます。 API エンドポイントやカスタムドメイン名に 強化された TLS セキュリティポリシー を設定できるようになり、API のセキュリティ体制をより細かく制御できるようになりました。 Amazon EventBridge Amazon EventBridge に、カスタムアプリケーションや 200 以上の AWS サービスからのイベントを開発者が発見しサブスクライブできる 拡張ビジュアルルールビルダー が導入されました。 このコンソールベースのインターフェースは、EventBridge の スキーマレジストリ と包括的なイベントカタログ、直感的なドラッグアンドドロップキャンバスを統合し、イベント駆動型アプリケーションの構築を簡素化します。 開発者は、個々のサービスのドキュメントを探し回ることなく、すぐに利用可能なサンプルペイロードやスキーマを使ってイベントを閲覧・検索できます。 スキーマ対応のビジュアルビルダーが、イベントフィルターパターンやルールの作成をガイドし、構文エラーを削減して開発時間を短縮します。 EventBridge では、 SQS フェアキュー をターゲットとして指定することもできます。 AWS Step Functions AWS Step Functions では、 TestState API を通じて強化されたローカルテストが可能です。 AWS にデプロイすることなく、包括的なテスト機能にプログラムからアクセスできます。 これにより、開発マシン上でワークフロー定義をローカルに検証する自動テストスイートを構築できます。 お好みのテストフレームワークを使用して、エラーハンドリングパターン、データ変換、モックサービス統合をテストしましょう。 また、新しい メトリクスダッシュボード も追加され、アカウントレベルとステートマシンレベルの両方でワークフローの運用状況を可視化できるようになりました。 その他の発表 Savings Plans の柔軟な料金モデルが、 Database Savings Plans のローンチにより AWS マネージドデータベースサービスにも拡張されました。 1 年間の一定量の使用量 ($/時間) をコミットすることで、データベースコストを最大 35% 削減できます。 割引は毎時間、対象のデータベースサービス全体の適格な使用量に自動的に適用され、コミットメントを超える追加使用量はオンデマンド料金で課金されます。 Amazon DynamoDB が グローバルセカンダリインデックスでの複数属性複合キー をサポートするようになりました。 これまでは値を手動で連結して合成キーを作成する必要があり、新しいインデックスを追加する前にデータのバックフィルが必要になることもありました。 今後は、最大 8 つの既存属性を使用してプライマリキーを作成できるため、多様なアクセスパターンのモデリングや新しいクエリ要件への対応が容易になります。 Amazon Bedrock は、信頼性の高い AI エージェントを大規模にデプロイするための 品質評価とポリシーコントロールを備えた AgentCore を発表しました。 Bedrock には 18 のフルマネージドオープンウェイトモデル も追加され、開発者が利用できる AI モデルの選択肢が拡大しました。 Strands Agents SDK は、モデル駆動型のアプローチで AI エージェントをわずか数行のコードで構築・実行できるオープンソースフレームワークです。 TypeScript のサポートがプレビューとして 利用可能になり 、Strands Agents の構築に Python と TypeScript のどちらかを選択できるようになりました。 Amazon S3 Vectors が一般提供開始となりました。 S3 Vectors は、AI エージェント、推論、検索拡張生成 (RAG)、セマンティック検索を数十億ベクトル規模で実現する、専用設計されたコスト最適化済みのベクトルストレージを提供します。 サーバーレスに関するブログ記事 10 月 モノリスワークフローの分解: AWS Step Functions ワークフローのモジュール化 AWS Serverless MCP Server での AWS Lambda イベントソースマッピングツールの紹介 AWS Step Functions Distributed Map S3 プレフィックスを使用した Amazon S3 オブジェクトの大規模処理 11 月 AWS Lambda の IPv6 ネットワーキング AWS Step Functions Distributed Map によるビッグデータ処理のオーケストレーション AWS Step Functions Distributed Map を使用したネストされた JSON 配列処理の最適化 新しい Amazon API Gateway Portal で API の見つけやすさを向上させる Amazon API Gateway レスポンスストリーミングでレスポンシブな API を構築する AWS Lambda で Python 3.14 ランタイムが利用可能になりました AWS Lambda 上で Rust を使用したサーバーレスアプリケーションの構築 非同期 AWS サービスを AWS Step Functions ステートマシンと統合する際に、予測不能な処理時間を運用の一貫性を保ちながら処理する AWS Lambda が Java 25 をサポートしました Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化 Kafka 向けサーバーレスストリーミングワークロードのスループット向上 Amazon API Gateway と Application Load Balancer のプライベート統合を使用してスケーラブルな REST API を構築する LLM レスポンスのストリーミングにおけるサーバーレス戦略 AWS Lambda の新しいテナント分離モードを使用したマルチテナント SaaS アプリケーションの構築 AWS Step Functions と Amazon Bedrock バッチ推論による大規模ドキュメント処理のオーケストレーション AWS Lambda で Node.js 24 ランタイムが利用可能になりました Serverless Office Hours 毎週火曜日の午前 11 時 (太平洋時間) に開催されるライブストリームにぜひご参加ください。サーバーレステクノロジーに関するライブディスカッション、Q&A セッション、深掘りセッションを行っています。 エピソードは serverlessland.com/office-hours でオンデマンドでもご視聴いただけます。 10 月 10 月 7 日 – Amazon API Gateway Routing Rules 10 月 14 日 – Amazon DynamoDB Global Tables 10 月 21 日 – Building agents with Amazon Bedrock AgentCore 10 月 28 日 – What’s new with Observability 11 月 11 月 4 日 – AI 仕様を正しく定義する！ 11 月 11 日 – AWS Lambda で Swift を実行する 11 月 18 日 – EventCatalog の最新情報 11 月 24 日 – pre:Invent 2025 12 月 12 月 9 日 – AWS Lambda Managed Instances 12 月 16 日 – AWS Lambda durable functions さらに詳しく知りたい方へ サーバーレスのランディングページ には、サーバーレスアプリケーションの構築に関する全般的な情報があります。 Lambda リソースページ には、ケーススタディ、ウェビナー、ホワイトペーパー、お客様事例、リファレンスアーキテクチャ、さらに多くの入門チュートリアルが掲載されています。 Serverless Developer Advocacy チームをフォローして、最新ニュースの確認、会話のフォロー、チームとの交流もできます。 Julian Wood: @julian_wood , https://www.linkedin.com/in/julianrwood/ Eric Johnson: @edjgeek , https://www.linkedin.com/in/singledigit/ Gunnar Grosch: @GunnarGrosch , https://se.linkedin.com/in/gunnargrosch Erik Hanchet: @ErikCH , https://www.linkedin.com/in/erikhanchett/ Salih Gueler: @salihgueler , https://www.linkedin.com/in/salihgueler/ Marcia Villalba: @mavi888uy , https://www.linkedin.com/in/marciavillalba 最後に、サーバーレスに関するあらゆる情報については Serverless Land をご覧ください。

本記事は 2026 年 4 月 15 日に Migration & Modernization Blog で公開された AWS Transform: Comprehensive Codebase Analysis for Modernization を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 アプリケーションのモダナイゼーションは、多くの場合、困難なタスクから始まります。それは、システムの仕組みを理解するための包括的なレガシーコードベース分析です。多くのレガシーアプリケーションは長年にわたる段階的な変更を経て進化しており、ドキュメントは限られ、依存関係は密結合し、ビジネスロジックは複数のサービスやモジュールに分散しています。エンジニアリングチームにとって、この可視性の欠如は共通の課題を生み出します。モダナイゼーションを開始する前に、開発者はソースコードを確認してアプリケーションアーキテクチャ、動作パターン、隠れた依存関係を理解するための時間を費やす必要があります。この作業を行っても、サービス間の依存関係、アーキテクチャ上の制約、埋め込まれたビジネスルールなどの重要な知見は、変更がより複雑でコストがかかるプロジェクトの後半で明らかになることがよくあります。 AWS Transform の包括的コードベース分析マネージド変換は、アプリケーションの明確でエビデンスに基づいた理解を提供することで、これらの課題に対処します。これにより、数か月分の手作業を節約し、モダナイゼーションへの取り組みを加速できます。この記事では、変換の仕組み、前提条件、実行手順、実践的なシナリオを含めた結果の解釈方法、より広範なモダナイゼーションの取り組みとの関係、ベストプラクティス、トラブルシューティングガイダンスについて説明します。この記事を読み終えた頃には、ドキュメントが不十分なレガシーコードベースを構造化されたナビゲーション可能なナレッジベースに変換するための再現可能なアプローチを習得できるでしょう。 AWS Transform の包括的コードベース分析の仕組み この変換は、静的コード解析に基づいて動作します。決定論的ツール、基盤モデル（FM）、大規模言語モデル（LLM）、グラフニューラルネットワーク、自動推論を組み合わせて、アプリケーションコードベースの 4 つの重要な側面を分析します。 システム全体のコンポーネントの関係と依存関係 コードがどのように機能するかを明らかにする動作パターン 実装に埋め込まれたアーキテクチャ上の決定 ステークホルダーとのコミュニケーションのために平易な言葉で抽出されたビジネスロジック この多層的な分析により、技術チームとビジネスリーダーの両方が、実装中に問題が発生する前に十分な情報に基づいたモダナイゼーションの意思決定を行うのに役立つ構造化されたドキュメントが生成されます。 前提条件 開始する前に、以下を確認してください。 AWS Transform コマンドラインインターフェース （CLI）がインストールされていること: 詳細は スタートガイド を参照。 AWS 認証情報が設定されていること: 適切な権限で AWS CLI をセットアップし、AWS 認証情報に AWS Transform サービスを呼び出す権限があることを こちら で確認。最低限、 transform-custom: * の権限が必要。 クリーンな状態の読み取り可能なファイルを含む Git ソースコードリポジトリを準備すること: コミットされていない変更はコミットまたはスタッシュ。 推定所要時間: 30〜45 分（分析の実行時間を除く。実行時間はコードベースのサイズによって異なります） ステップバイステップガイド: 包括的コードベース分析の実行 以下の手順では、レガシーアプリケーションに対して AWS Transform の包括的コードベース分析を実行し、主要なステークホルダーと結果を共有し、インサイトに基づいて行動するまでの完全なプロセスを説明します。 ステップ 1: 環境の確認 AWS Transform が正しくインストールおよび設定されていることを確認します。 atx -version atx custom def list 上記のコマンドは、 AWS/early-access-comprehensive-codebase-analysis などの利用可能な AWS Transform マネージド変換を表示します。 注: 早期アクセス変換 (early-access-*) は機能しますが、お客様のフィードバックに基づいて頻繁に更新される可能性があります。時間が経つと、変換の名前が「AWS/comprehensive-codebase-analysis」として一覧に表示されるようになります。 図 1: AWS マネージド変換のリストで包括的コードベース分析変換が利用可能であることを確認 ステップ 2: コードベースの準備 Git リポジトリがクリーンな状態であることを確認します。 git status 図 2: 分析を実行する前に Git リポジトリがクリーンな状態であることを確認 既存のソースコードリポジトリをクローンします。 git clone <repository-url> 図 3: 包括的分析のためにレガシーコードベースリポジトリをクローン ステップ 3: ターミナルで以下のコマンドを実行 AWS Transform を使用して包括的分析を開始します。これにより、リポジトリ内のすべてのファイルと依存関係に対して深い静的解析が実行されます。 cd /path/to/your/project atx custom def exec -p /path/to/your/repository -n AWS/early-access-comprehensive-codebase-analysis -c "noop" -x -t 注: -n は変換名を指定します -c "noop" – ビルドコマンド（no operation – ビルドステップをスキップ） -x – 確認プロンプトなしでツールを自動信頼/実行 -t – インタラクティブターミナルモードを有効化 図 4: AWS Transform CLI を使用して包括的コードベース分析変換を実行 ステップ 4: 追加コンテキストの提供（オプション） よりターゲットを絞った分析を行うために、設定ファイルを使用して追加のガイダンスを提供できます。 transform-config.yaml という名前のファイルを作成します。 cat > transform-config.yaml << 'EOF' codeRepositoryPath: /Users/milola/Prince-of-Persia-Apple-II transformationName: AWS/early-access-comprehensive-codebase-analysis buildCommand: noop additionalPlanContext: | Focus analysis on the following areas: - Document the overall architecture and code structure - Identify deprecated or outdated coding patterns - Highlight areas that may benefit from modernization - Analyze dependencies and their relationships EOF カスタム設定ファイルを実行します。 atx custom def exec -g file://transform-config.yaml -x -t 図 5: YAML 設定ファイルを使用して追加コンテキスト付きで分析を実行 ステップ 5: 分析のモニタリング 処理が進むにつれて、階層的なドキュメント構造にまとめられた分析結果、優先度付けされた技術的負債のインサイト、簡単にナビゲートできる相互参照されたナレッジベースが提供されます。コードベースのサイズと複雑さに応じて、完全なプロセスには通常 45 分から 2 時間以上かかります。 ステップ 6: 結果の確認 分析が完了すると、4 つの領域にわたって整理された包括的なドキュメントセットが表示されます。 技術的負債レポート: 古くなったコンポーネントの優先度付きビュー、重大度別にランク付けされたセキュリティの問題、長期的な影響について評価されたメンテナンスの懸念事項。 アーキテクチャドキュメント: コンポーネントの依存関係グラフ、サービスの相互作用パターン、データフロー図を含むシステム全体の概要。 ビジネスロジックの抽出: 複雑なプロセスのわかりやすい言葉での説明。主要なビジネスルール、バリデーションロジック、外部統合ポイントを浮き彫りにします。 コード分析: コードベースのファイルごとの内訳。複雑度メトリクス、コード品質の指標、具体的なリファクタリングの機会を提示します。 以下は、プロジェクト概要、技術的負債レポート、コード分析出力、システムアーキテクチャ概要のスクリーンショットです。 プロジェクト概要: 図 6: ビジネスコンテキストと技術的成果を含む、包括的コードベース分析によって生成されたプロジェクト概要ドキュメント 技術的負債レポート: 図 7: プラットフォームの陳腐化やハードウェア依存関係を含む、重大度別に優先度付けされた重要な問題を強調する技術的負債レポート コード分析: 図 8: 複雑度、保守性の指標、品質評価を示すコード分析メトリクス システムアーキテクチャ概要: 図 9: モジュール性と結合度の具体的な評価を含む、システムの強みと弱みを示すアーキテクチャドキュメント ステップ 7: ナレッジベースのナビゲーション 生成されたドキュメントは、ハイレベルなレビューと詳細な調査の両方をサポートするように構造化されています。 ルートレベルでは、エグゼクティブサマリーが最も重要な技術的負債の分析結果とともに表示され、即座に注意を要するインサイトが明らかになります。さらに掘り下げると、ドメインレベルでは関連するコンポーネントが論理的なクラスターにグループ化され、コンポーネントレベルでは個々のモジュールの詳細な分析が提供されます。 ドキュメント全体を通じて、相互参照が関連するコンポーネントと依存関係を接続し、チームがコンテキストを失うことなくシステム全体の関係を追跡しやすくなります。 トップから始めて、モダナイゼーションの優先事項に最も関連する領域を分析してください。 ステップ 8: エクスポートと共有 各グループが受け取る内容を、それぞれの責任と意思決定のニーズに基づいてカスタマイズします。このターゲットを絞ったアプローチにより、各チームはモダナイゼーションの取り組みにおける自分たちの役割に最も関連するインサイトに基づいて即座に行動できます。 まず、エンジニアリングチームに技術的負債レポートを提示してください。これにより、モダナイゼーション中に遭遇するリファクタリングの優先順位とアーキテクチャ上の制約が把握できます。 アーキテクチャチームは、ターゲット状態の計画と慎重な検討が必要な統合ポイントの特定に、システム全体のドキュメントが非常に有用であると感じるでしょう。 ビジネスステークホルダーは、わかりやすい言葉でのビジネスロジック抽出から大きな恩恵を受けます。これにより、変換中に重要なワークフローとルールが保持されていることを検証できます。 セキュリティチームも、依存関係の分析とアーキテクチャのインサイトを確認して、モダナイゼーションプロセスの早い段階でセキュリティに関する考慮事項を特定できます。 ステップ 9: インサイトに基づいた行動 出力は、それに基づいて何を行うかによってのみ価値が決まります。短期的には、関連するセキュリティの問題への対処、優先度の高い技術的負債の正式なドキュメント化、今後のスプリント計画への分析結果の組み込みに注力してください。戦略的には、アーキテクチャのインサイトがモノリシックシステムの分解の決定に情報を提供し、依存関係の分析に基づいてモダナイゼーションの各フェーズの実施順序を決定します。技術的負債データは、測定可能なリスクと影響に基づいた説得力のあるビジネスケースを構築するための基盤を提供します。 実践的なシナリオ 数十年の歴史を持ち、ドキュメントが最小限で、理解できる開発者が限られているモノリシックアプリケーションを引き継いだとします。そして、ビジネスステークホルダーは数か月ではなく数週間以内にモダナイゼーションのタイムラインを必要としています。包括的コードベース分析は、そうでなければ広範な手作業を必要とするディスカバリーフェーズを加速し、数週間ではなく数時間で実行可能な結果を提供します。コンポーネントの相互作用を示す完全な依存関係グラフを生成し、リスクと影響で優先度付けされた技術的負債のホットスポットを特定し、技術とビジネスの理解を橋渡しするビジネスロジックを抽出し、分解戦略に情報を提供するアーキテクチャのインサイトを提供します。この基盤により、特定のコンポーネントをリファクタリングするか、リプラットフォームするか、置き換えるかについて十分な情報に基づいた意思決定が可能になり、推測ではなくエビデンスに裏付けられた現実的なモダナイゼーションタイムラインをビジネスステークホルダーに提供できます。 より広範なモダナイゼーションの取り組みとの関係 包括的コードベース分析は、単独ではなく、より広範なモダナイゼーション機能と連携して動作するように設計されています。生成されるインサイトは、モダナイゼーションジャーニー全体を通じて使用できます。分解の計画では、インサイトが実際の依存関係とアーキテクチャの境界に基づいてモノリシックアプリケーションを管理可能なドメインに分解する方法の理解を提供します。技術的負債の分析は、リスク、影響、ビジネス価値に基づいた順序付きの作業を確保し、モダナイゼーションの各フェーズの優先順位を決定します。詳細なコンポーネント分析は、システムのどの部分が変換の候補であり、どの部分が完全な置き換えの候補であるかを示すことで、リファクタリングの決定を明確にします。ビジネスステークホルダーにとっては、抽出されたビジネスロジックがモダナイゼーション投資のビジネスケースを構築するために必要なナラティブを提供します。これを、後続のすべてのステップをより意図的でより良い情報に基づいたものにする基盤と考えてください。 ベストプラクティス 変換を実行する前に、結果に影響を与える可能性のある既知の問題や制限事項を文書化し、注力すべき特定の懸念領域を特定してください。 変換をターゲットを絞ったインサイトに導くために明確な追加コンテキストを提供し、出力を充実させることができる関連するアーキテクチャ図やドキュメントを含めてください。 分析が完了したら、チームとして技術的負債の分析結果をレビューし、技術的な重大度だけでなくビジネスへの影響に基づいて修正の優先順位を決定してください。 インサイトをスプリント計画と長期的なロードマップに活用し、技術者と非技術者の両方のステークホルダーとドキュメントを共有して、全員がシステムの全体像を理解できるようにしてください。 トラブルシューティング 結果に具体的なインサイトが不足している場合 出力が一般的すぎると感じる場合、最も効果的な修正方法は、エージェントにより明確な方向性を与える additionalPlanContext を通じてより詳細なコンテキストを提供することです。認証、決済処理、特定のサービスレイヤーなど、最も関心のある注力領域やドメインを指定し、エージェントがよりターゲットを絞った分析結果を生成できるように、既存のアーキテクチャドキュメントや図を参考資料として含めることを検討してください。 分析が完了しない場合 分析が完了できない場合は、エージェントが自力で解決できない可能性のある依存関係や設定ファイルの欠落を確認し、プロセスに干渉する可能性のあるコミットされていない変更がない、クリーンな状態の Git リポジトリであることを確認してください。大規模または複雑なコードベースの場合は、エージェントをガイドするために焦点を絞った additionalPlanContext を提供してください。 ドキュメントが広範すぎる場合 生成されたドキュメントが必要以上に広い範囲をカバーしている場合は、 additionalPlanContext でモジュールやドメインを指定してスコープを絞ってください。また、リポジトリ全体ではなく特定のサブディレクトリに対して分析を実行することもできます。これにより、システム全体の出力を確認する必要なく、最も重要な領域に焦点を当てた実行可能なインサイトを得ることができます。 まとめと次のステップ コードベースを理解することは、モダナイゼーション成功の基盤です。AWS Transform の包括的コードベース分析は、数か月の手動ドキュメント作成を数時間の AI によるインサイト生成に変換します。これにより、コードを変更する前に十分な情報に基づいた意思決定を行うための明確さが得られます。この基盤があれば、リアクティブではなく戦略的にモダナイズでき、レガシーアプリケーションをビジネスを推進するスケーラブルで保守可能なシステムに変えることができます。 次のステップとして、パイロットモダナイゼーションプロジェクトから始めてください。以下の追加リソースを確認し、レガシーコードベースに対して包括的コードベース分析を実行してください。アーキテクチャのインサイトを分解の計画に活用し、技術的負債の分析結果に基づいてモダナイゼーションの各フェーズの優先順位を決定し、抽出されたビジネスロジックをステークホルダーと共有してアラインメントを構築してください。定期的に再実行して進捗を追跡し、モダナイゼーションの取り組みが計画した成果を達成していることを検証できます。 追加リソース AWS Transform custom Documentation AWS Comprehensive Codebase Analysis Getting Started with AWS Transform Quotas for AWS Transform Ask questions on re:Post 著者について Damilola Odeleye Damilola Odeleye は、Amazon Web Services (AWS) のシニアテクニカルアカウントマネージャーです。エンタープライズ組織と連携し、クラウドのモダナイゼーションを加速させ、ビジネスに大きなインパクトをもたらす成果を推進しています。モダナイゼーションと AI/ML の両分野を専門とし、テクノロジーを長期的なビジネス成長と整合させることに注力しています。 Srinivas Ganapathi Srinivas Ganapathi は、Amazon Web Services のプリンシパルテクニカルアカウントマネージャーです。カナダのトロントを拠点とし、ゲーム業界のお客様と協力して、AWS 上で効率的にワークロードを実行できるよう支援しています。

本記事は 2026 年 4 月 26 日に AWS DevOps & Developer Productivity Blog で公開された AWS Transform custom: Enterprise Code Modernization with the Learn-Scale-Improve Flywheel を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 エンタープライズにおけるモダナイゼーションは、大きな転換点を迎えています。1 つのリポジトリを変換するだけなら容易です。 AWS Transform custom でも、他の既存のツールでも、個別のリポジトリに対して十分に機能し、プロセスも確立されています。しかし、50 のリポジトリではどうでしょうか。100、200 ではどうでしょうか。エンタープライズ規模でモダナイゼーションを進めようとすると、コードを変換することは課題全体の一部にすぎません。人員の調整、ナレッジの蓄積、そしてポートフォリオ全体における品質の維持も重要になります。 本記事では、AWS Transform custom の 大規模な自動化の仕組み が、インテリジェントな学習とスケール実行によって、エンタープライズにおける組織内連携の課題をどう解決するかをご紹介します。あるお客様は、モダナイゼーション全体の期間を 7-12 週間から 2.5 週間へと短縮し、デリバリー期間を 3-5 分の 1 に、総工数を 10-20 分の 1 に削減しました。そして何より、ご自身のモダナイゼーションの取り組みを今すぐ始めるための方法をお伝えします。 エンタープライズ規模における組織内連携の課題 エンタープライズのアーキテクトに直近の大規模モダナイゼーションについて尋ねると、きまって同じような話を耳にします。例えば、あるエンタープライズソフトウェア企業では、大規模なレガシーコードベースをモダンなプラットフォームへ移行する必要がありました。当初の見積りは、複数チームにまたがる調整作業を含めて 12 週間の集中的な作業でした。 コード変換そのものは数日で完了しました。しかし残りの数週間は、コード変換を取り巻く一連の作業に費やされました。具体的には、タイムゾーンをまたぐチームの調整、異なる経緯を持つコードベース間でのパターンの一貫性の確保、そして上流の変更が下流のシステムを壊さないよう依存関係を管理することです。各チームはミーティングやスプレッドシートでステータスを追跡し、シニア開発者の頭の中にしか存在しない暗黙知に頼っていました。 これがエンタープライズにおける組織内連携の課題です。1 つのリポジトリから数百のリポジトリへとスケールするとき、連携のオーバーヘッドは爆発的に増大します。リポジトリが 1 つ増えるごとに、そのリポジトリ自身の複雑さだけでなく、新たな連携箇所、エッジケース、そして想定外の調整要件が加わるのです。 見落とされがちな 70% のギャップ エンタープライズの案件において、私たちはコード変換がモダナイゼーション作業全体の約 30% にすぎないことを確認してきました。残りの 70% には、テスト生成、検証、包括的なドキュメント作成、ビジネス分析、そして数百の作業項目にまたがる組織的な調整などが含まれます。 このギャップこそが、変換ツールによる生産性向上がなかなか実を結ばない理由です。ツールがコードの変更は処理できても、組織は連携、検証、ナレッジの蓄積に依然として苦労しています。変換作業は迅速に終わるのに、プロジェクト全体は数か月を要するという状況です。 実際に私たちが目にしてきたのは、従来のアプローチがエンタープライズ規模で機能しないという事実です。各リポジトリを独立した課題として扱ってしまうからです。チームはコードベース間で同じ作業を繰り返し、一貫性のない判断を下し、開発者が別のプロジェクトへ異動するたびに学びを失っていきます。組織のナレッジは再利用可能な資産とならず、個人の頭の中に閉じ込められたままです。 エンタープライズモダナイゼーションへの新しいアプローチ AWS Transform custom は、エンタープライズモダナイゼーションに対して異なるアプローチをとります。同じ操作を何百回も繰り返すのではなく、すべての実行から学習し、そこで得た知見を次の変換の改善に活用します。 Learn-Scale-Improve フライホイール この Learn-Scale-Improve（学習・スケール・改善）フライホイール のワークフローは、リスクを最小化しつつ学習効果を最大化するよう綿密に設計されたステップで進みます。まず小規模な Learn (学習) パイロットから始め、一括自動化を通じて Scale (スケール) し、計画的なレビューによって Improve (改善) する。このサイクルを繰り返すフライホイールによって、イテレーションのたびに前回よりも良い結果を生み出します (図 1)。 図 1: AWS Transform custom の変換ワークフローにおける Learn-Scale-Improve フライホイール Learn (学習) : 代表的な 2-3 個のリポジトリを対象に、インタラクティブモードで変換を実行するところから始めます。AI エージェントと直接やり取りしながら、各ステップでの判断にフィードバックを提供し、品質を検証します。エージェントが曖昧な箇所に遭遇すると質問を投げかけ、お客様がガイダンスを与えると、システムがそのコンテキストを記録します。パイロットの最後には、蓄積されたフィードバックを確認して変換定義を修正します。その結果として得られるのは、お客様の組織のナレッジが組み込まれた、スケール実行の準備が整った変換定義です。 Scale (スケール) : 次に、自律モードへ切り替えて一括実行を行います。システムは数十、数百のリポジトリを一晩で、手動介入なしに処理し、パイロットで学習したパターンを適用します。ビルドコマンドやテストコマンドを使用して変換結果を検証し、ポートフォリオ全体の進捗状況をリアルタイムで追跡します。これまで数週間のチーム調整を要していた作業が、一晩で完了します。実行中、システムは新しいエッジケース、想定外のパターン、パイロットでは見えてこなかった最適化の機会などを発見事項として記録します。 Improve (改善) : 一括実行のラウンドが終わるごとに、処理中にシステムが記録したナレッジアイテムをレビューします。これらの発見事項は、パイロットではカバーできなかったリポジトリ特有のパターンやエッジケースを浮き彫りにします。その中から価値のある学びを承認することで、次のイテレーションに向けて変換定義が改善されます。このレビューステップが品質管理の役割を担います。システムは自己改変せず、どの学びを取り込むかを決めるのは、変換定義のオーナーです。 Scale と Improve のサイクルは繰り返されます。一括実行のラウンドごとに得られたインサイトが、次のラウンドをさらに効果的にします。変換の成功率は向上し、手動介入は減少し、エッジケースのハンドリングもイテレーションを重ねるたびに改善されます。 このフライホイールは、エンタープライズが組織としてナレッジをどう蓄積し共有するかを大きく変えます。変換定義は単なる自動化スクリプトではありません。特定のモダナイゼーションシナリオに対して、自社がどう取り組むかを体系化した組織資産です。アーキテクトが変換戦略を定義すると、その戦略は再利用可能な定義としてレジストリに保存されます。チームがベストプラクティスを特定すると、それらは変換定義の中に埋め込まれ、すべてのリポジトリに自動的に適用されるようになります。従来であれば、シニア開発者がチームを離れれば、そのナレッジも一緒に消えてしまっていました。AWS Transform custom を利用すれば、その専門知識を変換定義やナレッジアイテムとして蓄積し、組織全体で使える形にできます。個人の専門性が、組織のケイパビリティへと昇華するのです。 エンタープライズのお客様によるモダナイゼーション事例 これらの生産性向上は理論上の予測ではなく、実際の本番環境での成果です。あるエンタープライズソフトウェア企業では、本番環境で稼働する大量の Control-M（訳註: BMC Software 社のワークロード自動化プラットフォーム）のワークフローを Apache Airflow へ移行する必要がありました。このモダナイゼーションには、技術的な精密さと、複雑かつ相互依存するコードベース全体における一貫性の両方が求められました。当初の見積りでは、複数チームでの集中的な調整に 12 週間を要するとされ、一貫性の欠如や統合失敗のリスクも抱えていました。 この企業は、 AWS Transform custom を活用して Learn-Scale-Improve のイテレーション型ワークフローを実行しました。パイロットフェーズでは、代表的なリポジトリに対してインタラクティブモードでの変換を実行し、結果をレビューしたうえで変換定義を洗練させました。イテレーションを重ねるごとに、変換定義はエッジケースへの対応精度を高めていきました。その後、自律モードの一括実行へと移行し、ポートフォリオ全体の移行を 2.5 週間で完了しました。 検証の結果、対象となったすべてのワークフローで 100% の成功率を達成しました。エッジケースのハンドリングは従来のアプローチと比べて 60% 改善し、変換後のコードは業界の専門家が求めるコード品質基準を満たしながら、実行時のパフォーマンスも 19% 向上しました。この事例は、移行のスピードと本番品質の両立が可能であることを示しました。従来のアプローチと比較して、デリバリー期間を 3-5 分の 1 に、総工数は 10-20 分の 1 に削減しました。 ポートフォリオ全体の変換を始めましょう AWS Transform custom の大規模な自動化の仕組みは、 GitHub リポジトリ でソリューションとして提供されています。Learn-Scale-Improve ワークフローに沿って、モダナイゼーションの取り組みを始めてみてください。 前提条件 開始前に、以下をご確認ください。 AWS Transform custom へのアクセスが有効化された AWS アカウント 適切な認証情報で構成された AWS CLI ローカルマシンまたは CI/CD 環境にインストールされた Git AWS Transform custom の操作に必要な IAM 権限 実装の進め方 AWS Transform custom は、 Java のアップグレード (例: 8 から 17、17 から 21)、Python の移行 (例: 3.7 から 3.11)、Node.js のアップデート (例: 14 から 20)、AWS SDK の移行 (例: boto2 から boto3、SDK v1 から v2) など、多様な変換 をサポートしています。これらの AWS マネージドな変換に加えて、組織固有の標準、独自のフレームワーク移行、各環境特有のアーキテクチャパターンに対応するカスタム変換定義を作成することもできます。 AWS Transform custom は、既存の開発プロセスに自然に統合できます。CLI は Jenkins、GitLab CI、GitHub Actions といった CI/CD パイプラインと連携します。変換結果はローカルの Git ブランチとして生成され、お客様の標準的なコードレビュー・マージプロセスに沿って流れていきます。Web インターフェイスでは、チーム横断での進捗状況を一元的に可視化できます。検証コマンドは変換処理中に自動的に実行され、変更が完了したと見なされる前にコードが正常にビルドされ、テストが通過していることを保証します。変換処理の終了時に検証条件を満たさない場合、その変換は失敗として扱われます。 スケール実行までの道のりを加速するため、AWS は本番環境で利用できるスタート地点となるオープンソースのサンプルリポジトリを提供しています。複数のリポジトリと変換定義に対して同時に変換を実行するためのものです。 aws-transform-custom-samples の scaled-execution リポジトリには、一括実行をオーケストレーションするスクリプト、リポジトリのキューイングを管理する仕組み、ポートフォリオ全体のステータス追跡を扱うスクリプトが含まれています。オーケストレーションをゼロから構築するのではなく、サンプルをクローンし、ご自身のリポジトリリストと変換定義で設定すれば、すぐにスケール変換の実行を始められます。 まとめ エンタープライズ規模でのモダナイゼーションには、コード変換ツール以上のものが必要です。本当の課題は、チーム間の連携、実行からの学習、そしてナレッジを組織資産として蓄積することにあります。AWS Transform custom の Learn-Scale-Improve ワークフローは、これらの課題に対して、実行のたびに品質を高める継続的学習、暗黙知を再利用可能な資産へと変える組織ナレッジの捕捉、そして数百のリポジトリに一貫して適用できる一括自動化で応えます。次に重大なセキュリティ脆弱性が発見され、リポジトリ全体のフレームワーク更新が必要になったときも、新しいランタイムのバージョンでパフォーマンスを改善できるようになったときも、すでに効果を検証済みの変換定義を使って、数か月ではなく数日単位で対応できるようになります。 実際のお客様は、デリバリー期間を 3-5 分の 1、総工数を 10-20 分の 1 に削減し、モダナイゼーションを数か月から数週間に圧縮しています。これは願望ではなく、AWS Transform custom を活用している組織が本番環境で実現している成果です。 今すぐ変換を始めましょう まずは 2-3 個の代表的なリポジトリを対象に Learn-Scale-Improve ワークフローを実施し、変換定義を洗練させたうえで、ポートフォリオ全体へと展開してください。 AWS Transform custom の大規模な自動化の仕組みをさらに深く知るには、以下のリソースをご覧ください。 AWS Transform custom ドキュメント : 全機能、API リファレンス、統合ガイドを網羅した技術ドキュメント: AWS Transform custom Scaled Execution サンプルリポジトリ : 複数のリポジトリと変換定義に対して変換を実行するためのオープンソーススクリプト: aws-transform-custom-samples Transformation Registry : AWS マネージドな変換の発見と、カスタム定義の作成: aws-transform-custom-samples 取り組みを開始するには、AWS アカウントチームにお問い合わせいただくか、AWS Transform custom のドキュメントをご参照ください。 著者について Meghan Kothari Meghan Kothari は、Customer Experience and Business Trends チームのシニアテクニカルプロダクトマネージャーです。AWS のリーダーシップと連携し、Agentic AI を活用したアプリケーション開発とモダナイゼーションにおける進化するトレンドを発見するための戦略的な Deep Dive に取り組んでいます。ソリューションアーキテクトおよびフルスタック開発者としての経歴により、開発者体験の形成に貢献する独自の実践的な視点を持っています。 Venugopalan Vasudevan Venugopalan Vasudevan (Venu) は、AWS のプリンシパルスペシャリストソリューションアーキテクトであり、AWS Transform に焦点を当てた Agentic AI の取り組みを主導しています。お客様が AI を活用した開発者向けソリューションおよびモダナイゼーションソリューションを採用しスケールさせ、イノベーションとビジネス成果を加速できるよう支援しています。 Rodney Grilli Rodney Grilli は、AWS のプリンシパルテクノロジストであり、Agentic AI サービスを活用した製品およびコードのモダナイゼーションを専門としています。お客様が製品ポートフォリオをモダナイズし、AI-Native Enterprise への変革を加速できるソリューションを構築しています。