TECH PLAY

AWS

AWS の技術ブログ

3418

2026 年 6 月 1 日、アマゾン ウェブ サービス ジャパン合同会社(以下、AWS ジャパン)は、「フィジカル AI 開発支援プログラム by AWS ジャパン」の第 1 回コミュニティイベント「Community Meetup #1」を、 AWS ジャパン 麻布台オフィス にて開催しました。本プログラムは 2026 年 1 月 27 日に発表し 、 3 月 3 日にキックオフイベント を開催しました。今回の Community Meetup は、約 6 ヶ月間の開発支援期間のなかで、採択企業同士の交流を主な目的として開いた初めてのコミュニティイベントです。 フィジカル AI 開発支援プログラムとは フィジカル AI とは、物理世界で動作する AI の総称です。 AWS では、これを「物理世界と相互作用するために知覚、理解、推論、学習を統合したハードウェアとソフトウェアのシステム」と定義しています。大規模言語モデル(LLM)の進化を背景に、視覚情報と言語、行動を統合的に扱う Vision-Language-Action(VLA)モデルをはじめとしたロボット基盤モデルの研究開発が、世界的に加速しています。 本プログラムは、AWS 上でこうしたロボット基盤モデルを開発する、日本に法人または拠点を持つ企業・団体を支援する取り組みです。データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまで、開発の一連のパイプラインづくりを、技術支援・コスト支援・コミュニティ形成・GTM 支援の 4 つの柱で支えます。 本プログラムが大切にしているのは、技術的な側面にとどまらず、一つのコミュニティとして共に取り組み、育てていくという考え方です。今回の Community Meetup は、その実践の第一歩として企画しました。 イベント概要 当日のアジェンダは以下のとおりです。 オープニング パネルディスカッション(採択企業 3 社が登壇) アンカンファレンス(テーマ別のグループディスカッション) クロージング ネットワーキング 以降では、パネルディスカッションとアンカンファレンスの様子をご紹介します。 パネルディスカッション 前半は、本プログラムに参画いただいている 3 社の方々によるパネルディスカッションです。AWSの針原をモデレーターとして、それぞれ異なる立場からフィジカル AI に取り組む登壇者をお迎えしました。 小堀 訓成 様 (株式会社メルカリ 研究開発組織R4D 所長) 末永 匡 様(株式会社Enactic オープンソース事業部長) 鈴木 徳馬 様(株式会社JDSC データサイエンティスト) 各社の取り組み 3 社それぞれ立場は異なりますが、「現実世界のデータをどう集め、どう活かすか」という共通の課題に向き合っています。 株式会社メルカリの小堀 訓成 様は、自社倉庫の作業をロボットに置き換える取り組みを紹介しました。海外向け出荷では、届いた商品の検品や、ブランド品が本物かを確かめる真贋判定、梱包までを人手で行っていますが、これらをロボットで担うことを目指しています。中古品はバリエーションが大きいため、まずはばらつきの小さい品目から着手しているといいます。たとえば靴、なかでもスニーカーのように形状が比較的安定したものを選び、テレオペレーション(遠隔操作)でロボットを動かして学習用データを集めています。 続いて、株式会社Enacticの末永 匡 様は、同社が開発するオープンソースのロボットアーム「OpenArm」について語りました。末永様が強調したのは、Sim-to-Real ギャップは大きく、実機でのデータ収集が重要だという点です。そのうえで、実機データの「質」と「量」をいかに確保するかが課題になるといいます。データの「質」は、操作者のスキルだけでなく、映像とロボットの関節データのタイムスタンプのずれといった見えにくい要素にも左右されるそうです。「量」を確保するには、収集作業の自動化や、並列に集める工夫が効くといいます。2026 年 5 月にリリースされた OpenArm 2.0では、アーム本体の改良に加え、照明や電源などをパッケージ化し、同じ条件でモデルを評価できる標準実験環境「OpenArm Cell」が含まれており、データの「質」と「量」の改善に寄与するとアピール。さらに、人間の肩にかけられる軽量かつ高精度な教示デバイス「OpenArm KER」の開発も進めているとのことです。OpenArm の GitHub スター数は、登壇時点で 2,500 ほどに達しており、オープンソースを起点にコミュニティが広がっています。 株式会社JDSCの鈴木 徳馬 様は、物流分野のパートナー企業と連携して参加しています。フィジカルAIの研究開発を行っていたタイミングで本プログラムの話が重なり、共同での参加に至ったそうです。実機でのデータ収集は重要です。一方で、人手作業はどうしてもばらつき、時間もかかります。そこで、シミュレーター内で合成データを生成し、量をスケールさせるアプローチを採用したといいます。実機とシミュレーションのそれぞれの長所をどう組み合わせるかが、議論の焦点となりました。 技術的な課題と AWS の支援 フィジカル AI の開発には、シミュレーションや大規模な学習など、つまずきやすい局面が数多くあります。パネルでは、そうした課題に直面したときに AWS がどう支援したかが語られました。 その一例として、株式会社JDSCの鈴木様がシミュレーションの事例を紹介しました。同社では、シミュレーター「Isaac Sim」での合成データ生成が GPU でうまく高速化できず、開発が思うように進みませんでした。社内の定例会で議論しても解決しきれなかったため、AWS を通じて NVIDIA に問い合わせ、一緒に原因を探ったところ、Isaac Sim 自体ではなく、その土台となる物理シミュレーターに起因する問題だと分かったといいます。これを踏まえ、同社は現在、使い慣れた別のシミュレーターと AWS Batch を組み合わせて合成データの生成を進めています。 この事例のように、一社では解決が難しい課題に対しても、AWS は日本の担当チームに加え、AWS グローバルのスペシャリストや NVIDIA のようなパートナーと連携して支援にあたります。株式会社メルカリの小堀様も、分散学習について個別にレクチャーを受けられた経験に触れ、「困っていることを相談すると、課題に適したエンジニアを呼んでくれる。かゆいところに手が届く」と語ってくださいました。答えを示すだけでなく、お客様とともに考えながら解決策を探っていくことを、本プログラムの技術支援では大切にしています。 会場との質疑応答 会場との質疑も活発でした。たとえば「現在の VLA モデルは英語ベースのものが多いが、日本語への対応は必要か」という問いには、登壇者から「英語で作って日本語に変換しても問題なく動くことが多く、現時点で言語は大きな障壁ではない。ただし触覚を表すオノマトペのような日本語特有の表現には工夫が要るかもしれない」といった実感が共有されました。照明の条件が学習データの質を左右するといった、現場ならではの作り込みについても質問が交わされました。 終盤には、「身体性があるからこそ生まれる知性はあるのか」「そもそもフィジカル AI とは何か」といった、より本質的な問いも飛び交いました。「入力か出力のどちらかに物理が関わっていればフィジカル AI ではないか」「ヒューマノイドに限らず、ロボットアームも、さらには工作機械も含まれるのではないか」など、登壇者それぞれの定義が語られました。 アンカンファレンス 後半は「アンカンファレンス」を行いました。これは、決まった発表を聞くのではなく、参加者が実際に困っていることや関心を本音で語り合うグループディスカッションの形式で、AWS の Tech コミュニティでも好評の進め方です。 まず全体で各社の開発進捗を共有したところ、多くのチームがまだ実機を導入して動作確認する段階にあり、本格的なモデル開発はこれからプログラム後半にかけて行うという状況が各社に共通していました。その後、希望の多かったテーマごとに分かれて議論を深めました。たとえばシミュレーションの活用場面については、多数を並列に回せる強化学習では有効な一方、実機で丁寧にデータを取りたい模倣学習とは相性が異なるといった使い分けが話題になりました。また、公開モデルはベンチマークでは高性能でも実機や異なる環境では期待どおり動かないことがあり、何を基準に選ぶか悩ましいという声も挙がりました。 普段はなかなか共有しづらい悩みや知見が、率直に語り合われました。 コミュニティとしての意義 パネルディスカッションとアンカンファレンスを通じて、各社が共通の課題に直面している様子が浮かび上がりました。データ収集の難しさ、ハードウェアとソフトウェアの融合、研究と社会実装のギャップ、計算資源へのアクセスなど、その多くは一社だけで解決するのが難しいものです。立場の異なる開発者が本音で知見を交換できる場は、こうした課題に向き合ううえで一つの助けになります。実際に、参加企業同士が連携して開発に取り組む動きも生まれています。 AWS は、開発者の皆さまが課題を持ち寄り、ともに議論を深められる伴走者でありたいと考えています。今後もこうしたコミュニティの場を重ねていきます。 今後のスケジュール 支援期間中、引き続き各種イベントを予定しています。 ※ 以下の日程・内容は調整中のものを含みます。最新の情報は各社の担当チームよりご案内します。 時期 イベント 内容 2026年6月12日 GENIAC ロボット基盤モデルの研究開発応募者向け勉強会 ロボット基盤モデルをスケーラブルに開発するための環境について、応募者向けに情報を提供します 2026年6月24日 ロボット勉強会 AWSのフィジカルAIスペシャリストがグローバルの動向を紹介するほか、ロボットメーカーを招き、協働ロボットの活用について学びます 2026年6月25–26日 AWS Summit Japan 幕張メッセにて開催。本プログラムの開発成果のデモ展示などを予定しています 2026年8月31日(調整中) 最終成果報告会 プログラムの成果発表と、採択企業による開発内容の共有を予定しています おわりに 第 1 回 Community Meetup を通じて、日本のフィジカル AI を担う多様な企業・関係者が一堂に会し、率直な対話を交わすことができました。ご登壇いただいた 3 社の皆さま、そしてご参加いただいた採択企業の皆さまに、心より御礼申し上げます。 AWS は、本プログラムを通じて日本のフィジカル AI エコシステムの発展に貢献してまいります。次回のコミュニティイベント、そして成果発表会をどうぞご期待ください。 関連リンク フィジカル AI 開発支援プログラム by AWS ジャパン 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました 「Physical AI on AWS 勉強会 #1」を開催しました   「NVIDIA Robotics Solutions 勉強会」を開催しました
本記事は 2026 年 6 月 8 日 に公開された「 Announcing Amazon RDS for Db2 12.1 with additional community edition 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 で IBM Db2 12.1 がサポートされました。Db2 データベースエンジンの最新世代です。今回のアップグレードに加えて、新しいエディション Community Edition (db2-ce) も導入され、Amazon RDS for Db2 インスタンスのプロビジョニング時に、3 つのエディションから選択できるようになりました。 本記事では、Db2 12.1 の新機能の紹介、Community Edition の概要と活用シーン、AWS マネジメントコンソール・AWS Command Line Interface (AWS CLI)・Terraform を使った開始方法、そして Db2 11.5 からのアップグレードパスについて説明します。 エディション エンジン識別子 推奨用途 Community Edition (new) db2-ce 開発、テスト、非本番ワークロード Standard Edition db2-se 汎用的な本番ワークロード Advanced Edition db2-ae より多くの CPU とメモリリソースを必要とするミッションクリティカルなワークロード Db2 12.1 の新機能 IBM Db2 12.1 は、 200 以上の新機能と機能強化 を含むメジャーリリースです。RDS ユーザーに特に関連するハイライトを紹介します。 AI を活用したクエリ最適化 Db2 12.1 には、機械学習 (ML) でカーディナリティ推定を改善する AI Query Optimizer が統合されています。カーディナリティ推定とは、クエリプランの各ステップで何行のデータが処理されるかをエンジンが予測することです。推定精度が向上すると、より適切なクエリプランが生成され、手動チューニングなしで複雑な分析やミックスワークロードのパフォーマンスが向上します。モデルのトレーニングは高速化され、よりコンパクトになり、mod pack (マイナーバージョン)リリースごとに精度も向上しています。 名前空間の分離とマルチテナンシー Db2 12.1 では論理的な名前空間の分離が導入されました。単一のデータベース内で、異なるデータベーススキーマのセットを互いに分離できます。データベース管理者は、別々のデータベースインスタンスを用意する手間なく、複数のチームやアプリケーション層のデータオブジェクトをきれいに分割できます。 セキュリティの強化 今回のリリースでは、テーブルスペース管理権限が追加されました。DBA はストレージグループ内でのテーブルスペースの作成と管理を委任できます。最小権限アクセスモデルにとって大きな改善です。既存の RDS for Db2 と AWS Key Management Service (AWS KMS) および AWS Secrets Manager の統合と組み合わせることで、データベースエンジンと AWS インフラストラクチャ層の両方にまたがる多層的なセキュリティ体制を構築できます。 管理性の向上 12.1 のその他の機能強化には、外部テーブル管理、KMIP クライアント証明書の一元管理、カラムナーテーブルのオンライン移動などがあります。本日 RDS for Db2 で提供開始される 12.1.4 mod pack は、運用の効率化と最新のデータプラットフォームへのデータ接続性の拡張に重点を置いています。 Community Edition (db2-ce) の紹介 Community Edition は ライセンス無料 の Db2 エディションで、RDSでは12.1から利用可能になります。開発者、パートナー、小規模ワークロードを運用するチーム向けに設計されています。Standard Edition や Advanced Edition と同じ Db2 コードベースを使用しており、違いは機能の深さではなくリソースのエンタイトルメントにあります。 Community Edition には、IBM ライセンスによる以下のリソース制限があります。 リソース 制限 メモリ 8 GB CPU コア 4 vCPU この制限は、基盤となる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスサイズに関係なく、Db2 エンジンレベルで適用されます。Community Edition デプロイ用のインスタンスクラスを選択する際は、この範囲内に収まるものを選択してください。例えば、Community Edition で利用可能なインスタンスは db.t3.small、db.t3.medium、db.t3.large、db.m7i.large (m7i が利用できないリージョンでは db.m6i.large) です。 注意 : 上記のリソース制限を超えるインスタンスクラスはプロビジョニング時にブロックされませんが、Db2 はライセンス制限までのリソースしか使用しません。 Amazon RDS for Db2 の Community Edition を使えば、IBM ソフトウェアライセンス費用なしでフルマネージドの Db2 12.1 インスタンスを起動できます。支払いは、標準の RDS 料金モデルに従い、基盤となる AWS インフラストラクチャ (インスタンス、ストレージ、I/O) のみです。 注意: Community Edition には IBM ライセンス料がかかりませんが、Amazon RDS for Db2 では db2-ce を含むすべてのエディションで、DB パラメータグループに IBM カスタマー ID と IBM サイト ID が必要です。IBM が使用状況とエンタイトルメントの追跡に使用します。IBM アカウントを使って IBM の Web サイトで無料登録して取得できます。各 ID の用途と入力場所について詳しくは、 Amazon RDS for Db2 のライセンス を参照してください。 Community Edition により、以下のような用途で Db2 on AWS を始めやすくなります。 アプリケーションの開発とテスト – ライセンスコストを気にせず、ブランチやスプリントごとに Db2 インスタンスをプロビジョニングできます。 概念実証 (PoC) – 本番ライセンスを契約する前に Db2 の機能を評価できます。 小規模な非本番ワークロード – Community Edition のリソース範囲で十分な小規模アプリケーションを実行し、必要に応じて Standard Edition や Advanced Edition に切り替えられます。 要件が拡大した場合、Community Edition から Standard Edition または Advanced Edition へのアップグレードは、インプレースのエンジンエディション変更で簡単に行えます。データの移行やインフラストラクチャの再構築は不要です。 既存の RDS for Db2 機能はすべて Db2 12.1 に適用 Db2 11.5 で利用されてきたフルマネージド機能のすべてが、3 つのエディション共通で Db2 12.1 に引き継がれます。 高可用性 同期スタンバイと自動フェイルオーバーによる Multi-AZ デプロイメント。 災害復旧とリードスケーリング リードレプリカとスタンバイレプリカ。地理的な災害復旧のためのクロスリージョンレプリカも含みます。 運用の自動化 ポイントインタイムリカバリ (PITR) 付きの自動バックアップ、マイナーバージョンの自動パッチ適用、ストレージの自動スケーリング。 セキュリティ AWS KMS カスタマーマネージドキーによる保存時の暗号化。 SSL/TLS による転送時の暗号化。 AWS Directory Service for Microsoft Active Directory またはオンプレミスの Active Directory を使用した Kerberos 認証。 モニタリング、Amazon Simple Storage Service (Amazon S3) 統合、ディレクトリサービスアクセス、監査ログに対する AWS Identity and Access Management (IAM) ベースのロール分離。 ライセンスの柔軟性 Bring Your Own License (BYOL) – AWS License Manager で追跡される既存の IBM Db2 ライセンスを使用。 AWS Marketplace 経由の時間課金ライセンス – Standard Edition と Advanced Edition で利用可能な従量制の IBM ライセンス課金。 Community Edition (db2-ce) – IBM ソフトウェアライセンス料なし。ただし IBM カスタマー ID とサイト ID は引き続き必要です。 IBM の Web サイトで無料で取得できます。 可観測性(オブザーバビリティ) Amazon CloudWatch メトリクスとログによるデータベースパフォーマンスモニタリング。 OS レベルのメトリクスの拡張モニタリング。 AWS Lambda 関数を使用した Db2 モニタリングのセルフ構築 。 開始方法 RDS for Db2 12.1 インスタンスは、AWS マネジメントコンソール、AWS CLI、AWS CloudFormation、または Terraform で今すぐ起動できます。 コンソール AWS コンソールで Amazon RDS に移動し、 データベースの作成 を選択します。 エンジンとして IBM Db2 を選択します。 エンジンバージョン 12.1.4 を選び、エディション ( db2-ce 、 db2-se 、 db2-ae ) を選択します。 インスタンスクラス、ストレージ、Multi-AZ、VPC 設定を構成します。 IBM カスタマー ID と IBM サイト ID を入力します。Community Edition を含むすべてのエディションで必須です。Standard Edition と Advanced Edition では、時間課金用の AWS Marketplace ライセンスオプションも選択できます。 データベースの作成 を選択します。 CLI aws rds create-db-instance \ --db-instance-identifier my-db2-12-1 \ --engine db2-ce \ --engine-version 12.1.4.0.sb00080714.r1 \ --db-instance-class db.r6i.xlarge \ --master-username admin \ --manage-master-user-password \ --allocated-storage 100 \ --storage-type gp3 \ --db-subnet-group-name my-subnet-group \ --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \ --no-publicly-accessible 注意: デプロイ時に最新のエンジンバージョンを確認するには、以下のコマンドを使用してください。 aws rds describe-db-engine-versions \ --query "DBEngineVersions[?contains(Engine,'db2')].{Engine:Engine,Version:EngineVersion,Family:DBParameterGroupFamily}" \ --region <RegionName> --output table Terraform Infrastructure as Code を使用する場合、RDS for Db2 のモジュラー Terraform テンプレートが GitHub リポジトリで公開されています。このテンプレートは、リモートステート、ネットワーキング、IAM ロール、AWS KMS 暗号化、パラメータグループ、RDS インスタンス、AWS License Manager 統合を 7 つの組み合わせ可能なモジュールでカバーしています。詳しい手順は、 Deploying Amazon RDS for Db2 using Terraform を参照してください。 Community Edition を選択するには、 5-rds/terraform.tfvars でエンジンとエディションを設定します。 engine = "db2-ce" engine_version = "12.1.4" 4-parameter-group/terraform.tfvars では、パラメータグループモジュールが Db2 12.1 の有効なエディションとして ce を受け付けます。Community Edition でも IBM カスタマー ID とサイト ID は必須です。Standard Edition や Advanced Edition と同様に、パラメータグループの tfvars で設定してください。両方の ID は Create an IBMid ページで無料で取得できます。 Db2 11.5.9 からのアップグレード 現在 RDS for Db2 でエンジンバージョン 11.5.9 を実行している場合、標準の RDS メジャーバージョンアップグレードパスで 12.1 にアップグレードできます。アップグレード前に、 Db2 エンジンバージョンのアップグレード のドキュメントでアップグレード前のチェック事項とアプリケーションの互換性に関する注意事項を確認してください。 注意点: Community Edition (db2-ce) は 12.1 で新たに追加されたもので、11.5.9 には同等のエディションがありません。11.5.9 の Standard Edition または Advanced Edition インスタンスを移行する場合、アップグレード時にエディションを変更できます。ただし、Community Edition を選択すると、IBM のリソース制限 (4 vCPU、8 GB RAM) が適用されます。 ソース DB インスタンスがアップグレードされると、レプリカも自動的にアップグレードされます。 パラメータグループの IBM カスタマー ID とサイト ID のパラメータは、Standard Edition と Advanced Edition のアップグレードで引き続き必須です。 提供リージョン Amazon RDS for Db2 12.1.4+ (Community Edition と db2-se、db2-ae) は、AWS GovCloud (US) リージョンを含む、RDS for Db2 がサポートされているすべての AWS リージョンで本日から利用可能です。完全なリストは、 Amazon RDS for Db2 の提供リージョン を参照してください。 まとめ Amazon RDS for Db2 12.1 は、IBM の最新データベースエンジンをフルマネージドサービスとして提供します。AI Query Optimizer、名前空間の分離、テーブルスペース管理権限といった新機能と、Multi-AZ 高可用性、リードレプリカとスタンバイレプリカ、自動バックアップ、AWS KMS による暗号化といった既存の運用機能を組み合わせています。新しい Community Edition (db2-ce) により、利用の障壁が下がりました。開発、テスト、非本番ワークロード向けに IBM ソフトウェアライセンス料なしでフルマネージドの Db2 12.1 インスタンスを実行でき、ニーズの拡大に応じて Standard Edition や Advanced Edition にアップグレードできます。コンソール、AWS CLI、 GitHub リポジトリの Terraform テンプレートのいずれを使っても、数分で開始できます。始めるには、 Amazon RDS コンソール にアクセスするか、 Amazon RDS for Db2 のドキュメント を参照してください。ぜひ Amazon RDS for Db2 12.1 をお試しいただき、ご質問やフィードバックはコメント欄にお寄せください。 謝辞 Rajib Sarkar 氏にこの記事のレビューを感謝します。 著者について Vikram S Khatri Vikram は、Amazon RDS for Db2 のシニアエンジニア。プロダクトマネジメント、アーキテクト、リーダーシップ、AI エキスパートユーザーなど複数の役割を担当。20 年以上の経験を持ち、ゼロから新しいプロダクトを生み出すことに情熱を注いでいます。 Ashish Saraswat Ashish は、Amazon RDS for Db2 のシニアソフトウェア開発エンジニア。10 年以上のソフトウェア開発経験があります。 Umair Hussain Umair は、Amazon RDS for Db2 チームのシニアデータベースエンジニア。20 年以上のテクニカルリーダーシップと Db2 および Oracle の深い専門知識を活かし、お客様のクラウドでの高パフォーマンスデータベースワークロードの構築と運用を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。
本ブログは、コニカミノルタ株式会社と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。AWS Japan ソリューションアーキテクトの森下です。 本記事では、コニカミノルタ株式会社 ( 以下、コニカミノルタ ) が AWS と共同で 6 年以上にわたり推進してきたクラウド人財育成の歩みと、その最新の到達点の 1 つである事業課題解決型プログラム「AWS Boost Camp!」の取り組み、そして 2026 年 5 月 22 日に開催された最終成果報告会の模様についてご紹介します。 2025 年度 AWS Boost Camp! 最終成果報告会の参加メンバー及びテーマオーナーの皆様。約半年間の取り組みを終えて一堂に会しました。 1. はじめに ─ コニカミノルタについて コニカミノルタは、 1873 年創業の写真材料事業をルーツとし、現在では複合機・プロダクションプリントや、ヘルスケアやセンシングなど多様な事業を展開するグローバル企業です。「Imaging to the People」を長期経営ビジョンに掲げ、長年培ってきた光学・画像・材料などのコア技術に AI を掛け合わせ、既存領域に加えて成長領域へと事業を広げています。 近年では、自社プロダクトのクラウド化や生成 AI の業務活用を進めるとともに、AI とデータの活用を全社的な経営の軸に据えて事業変革を加速しています。こうした取り組みを支える土台として、社内の DX 専門技術者を計画的に育成する取り組みを長年にわたり継続して進めてきました。2024 年度末時点で、コニカミノルタの DX 専門技術者の登録人数は 1,000 名を超える規模に達しています。 2. コニカミノルタの人財育成の歩み コニカミノルタと AWS の人財育成における共同の取り組みは、2019 年にCloud Center of Excellence(以下 CCoE)構想の議論として始まりました。当時から一貫して掲げてきたのは、「座学や資格取得で終わらせず、実プロジェクトで成果を出せる人財を育てる」という思想です。最終的なゴールは、各事業部門が自走してクラウドを活用できる組織能力の獲得に置いてきました。 2020 年からは、AWS が伴走する形で、座学型のクラウド研修と実プロジェクトを題材にした OJT を組み合わせた集中投資型のプログラムを、シーズン制で複数回にわたり実施してきました。各シーズンでは数名規模のチームを並列に編成し、コニカミノルタ独自の DX ロール認定制度と紐付けて受講者のスキル変化を可視化することで、人財育成施策を経営層に KPI として説明できる形に整理しました。 このプログラムは、社内の DX 専門技術者数の急速な拡大とそれに伴う事業部門の多様な課題への対応の必要性から、2024 年度に新たな枠組みである「AWS Boost Camp!」へと進化しました。最大の特徴は、参加者が自部門の実プロジェクト ( 事業課題そのもの ) を題材として持ち込み、AWS のソリューションアーキテクト ( 以下、SA ) と Training and Certification ( 以下、T&C ) チームのインストラクター、そしてコニカミノルタの CCoE メンバーが三位一体で伴走する点です。これにより、研修中に設計したアーキテクチャや実装したプロトタイプが、そのまま事業部門の本番開発へ直結する構造が生まれます。人財育成だけでは予算を確保しづらいという事情を、事業課題の解決と同時に達成する形で解いた試みでもありました。 3. 事業課題解決型プログラム「AWS Boost Camp!」 3.1 プログラム概要 AWS Boost Camp! は、コニカミノルタの人財強化委員会傘下のソフト・ICT 部会を主管とし CCoE メンバーが運営に参画する形で実施しています。第 2 回 (2025 年度) は 2025 年 10 月にキックオフし、 2026 年 5 月の最終成果報告会までのおよそ半年間にわたって実施されました。 カリキュラムは、前半 3 ヶ月でアーキテクチャ設計、後半 3 ヶ月でプロトタイプ実装を進め、これに並行する形で AWS 認定資格取得を目指した自学自習を AWS Skill Builder や T&C インストラクターによる技術サポートを活用して支援する構造としています。各テーマには、AWS SA と CCoE メンバーが定例レビューおよびアーキテクチャ討議を行い、T&C のインストラクターが個別の学習プラン策定や認定試験対策、テーマ共通のオフィスアワー開催などにて支援する体制を組んでいます。 AWS Boost Camp! のカリキュラム構造。 3.2 AWS と コニカミノルタ社 CCoE の役割分担 AWS Boost Camp! の運営においては、 AWS とコニカミノルタ社 CCoE の役割分担を設計しています。 AWS 側は、SA によるアーキテクチャの議論やベストプラクティスの伝達、最新アップデートも踏まえたソリューションの提案 、T&C インストラクターによる認定試験対策・学習進捗のフォローを担います。一方、コニカミノルタ社 CCoE は、社内のセキュリティ・ネットワーク・運用ガイドラインとの整合を確認した上で、各テーマのアーキテクチャ設計にも参画し、社内事情を踏まえた現実解の提示と、プログラム終了後の自走を見据えた知見の社内蓄積を担います。 なおコニカミノルタの CCoE は固定の所属組織ではなく、各事業部門から有志が参画する組織横断のバーチャル組織です。発足当初は10名弱の規模でしたが、その後幅広い事業部門から有志が加わり、現在は 30 名近くにまで広がっています。 AWS Boost Camp! の運営に CCoE の一部が伴走者として参画することは、 CCoE 自体の運営力強化と次世代の AWS 推進人財の育成にもつながっています。 3.3 第 2 回 ( 2025 年度 ) の取り組みテーマ 本プログラムは 2024 年度の第 1 回から同じ枠組みで実施しています。クラウドを活用してどうシステムを構築するかという点は第 1 回・第 2 回に共通していますが、第 2 回ではそこに機械学習や生成 AI に関連したテーマが大半を占めるようになりました。 今回は、コニカミノルタの 4 つの事業領域から、それぞれ 1 テーマずつが取り組み対象として持ち込まれました。それぞれのテーマはいずれも、各事業部門が実際に推進している事業上の課題であり、プログラム終了後にそのまま本番開発へ繋がる前提で設計しています。 具体的な題材は、生産系データに関する AI SaaS の実現、研究開発部門における機械学習パイプラインの再構築、専門ドメイン向けデータ管理基盤、組織横断の生成 AI 活用基盤など、いずれも事業インパクトの大きい課題です。すでにクラウド上で PoC を進めているものもあれば、一から開発する新規プロジェクトもあり、進度はテーマによって様々でした。 4. 最終成果報告会の模様 2026 年 5 月 22 日、2025 年度 AWS Boost Camp! の最終成果報告会を開催しました。各テーマの参加者・テーマオーナー ( 参加者の上長にあたり、各テーマを持ち込んだ事業部門の責任者 ) ・ CCoE メンバー・運営事務局が一堂に会し、4 テーマの成果発表と質疑応答、フィードバックが交わされました。 4.1 テーマ全体の成果 最終成果報告会では、設計を語るだけでなく、必ず「動くもの」をプロトタイプとして開発しデモで示すことが達成基準となっています。各テーマの発表では、初期構想からプロトタイプ完成までの設計判断の過程と技術選定の理由、成果物のデモが共有されました。前提や制約が事業部門ごとに異なる中、Amazon が実践する顧客起点の開発手法である Working Backwards の考え方に基づいて「解くべき課題」を定義し、複数の選択肢を比較して現実解を選び取り、動作するプロトタイプへと結実させる過程は、座学だけでは得られない実践的なアーキテクト思考を養う機会となりました。 Amazon EC2 ベースで構築していた機械学習システムを、 コンテナ x Amazon SageMaker Pipelines を用いて MLOps ワークフローへと再構築した例。いずれのテーマも、 AWS マネージドサービスを組み合わせたエンドツーエンドの構成をもって最終発表に臨みました。 4 つのテーマを横断して、特に評価したいポイントが 3 つ浮かび上がりました。第一に、 Amazon SageMaker AI 、 Amazon Cognito 、 AWS Fargate 、 Amazon Bedrock など AWS の幅広いマネージドサービスを実践的に活用された点です。PoC では Amazon EC2 ベースだったプロジェクトも、マネージドサービスの意義や複数の選択肢のトレードオフを理解した上で設計に落とし込み、実装までを完遂しました。第二に、 AWS 認定試験に向けた学習と実プロジェクトでのアーキテクチャ設計・実装を並行して進められた点です。第 2 回では、プログラムを通じて 7 名が AWS SAA ( AWS Certified Solutions Architect – Associate) に新たに合格し、実務で触れた知識を体系的な学習で補強する学習サイクルが回りました。第三に、CCoE や関係部門との密な連携により、コニカミノルタ独自のポリシーやセキュリティ・ネットワーク観点を設計へ反映できた点です。 特筆すべきは、複数のチームから「AI コーディングエージェントを業務に取り入れる動き」が生まれたことです。 Kiro や Claude Code on Amazon Bedrock 、 Amazon Q Developer などを使いこなして従来の数十倍以上のスピードで開発を進められた経験は、参加者の発表でも強調されました。「一週間ほどを見込んでいたタスクが数時間で完了した」といった声からも、AI ネイティブ開発が現場で着実に浸透し始めていることがうかがえます。 4.2 参加者の声 参加者からは次のような声が寄せられました。 「 AWS のアーキテクトとの議論を通して、複数の選択肢からアーキテクチャを選択する際の考え方を学ぶことができた。」 「AWS には便利な選択肢が多いからこそ取捨選択しなければいけないことを実感した。最適なシステムの構築の重要性と難しさを実感した。」 「 Kiro を活用することで、これまでドキュメント調査に費やしていた時間を、本来の設計判断に充てられるようになった。開発のスピードが従来の数十倍になった実感がある。」 「 AI コーディングエージェントを使いこなすことで、ドキュメントの調査も開発も爆速になった。何より『自分が AWS でモノを作れる』という自信がついた。」 これらに共通するのは、「AWS の知識が増えた」というスキルアップにとどまらない、「クラウドでモノを作るうえでの判断軸」を獲得したという点であり、本プログラムが目指してきた「実践的に活かせる人財」の到達像と言えます。テーマオーナーや運営からも、AWS と CCoE の伴走により各テーマで実用に足る成果を形にできたと高く評価され、参加者が今後は各事業部門で先頭を切ってクラウド活用を主導することへの期待が寄せられました。 5. AI ネイティブ開発への移行に向けた今後の展望 2026 年現在、ソフトウェア開発のあり方そのものが大きく変容しつつあります。従来 AI はコード補完などで開発者を支援する役割が中心でしたが、近年では AI コーディングエージェントが自律的にコードを探索・編集・テストするようになりました。これに伴い、エンジニアの役割はコードを一行ずつ書くことから、解くべき課題を定義し、エージェントに与える仕様やルールを設計し、生成された成果の品質を高めながらレビューし、意思決定を下すことへと比重を移しつつあります。この潮流は、コニカミノルタが 2026 年 4 月に発表した中期経営計画「 Corporate Plan 2026-2028 」が掲げる「AI ネイティブ開発への移行」とも軌を一にしており、本プログラムが今後進化していくべき方向性も、この経営計画と密接に整合する形で検討しています。 私たちは、AI 時代だからこそ人を育てる重要性はむしろ高まっていると考えています。AI エージェントの出力の妥当性を見極めて意思決定につなげるには、クラウドやソフトウェア開発の基礎知識とアーキテクチャ設計の素養が欠かせず、その土台を備えた人が使いこなしてこそ、生産性と品質はともに高まるからです。 このような認識のもと、私たちは現在の AWS Boost Camp! のかたちが完成形だとは考えていません。技術や事業環境、参加者のスキルの変化に応じて、プログラムも柔軟に進化させる必要があります。第 3 回以降に向けては、AWS が提唱する AI-DLC ( AI-Driven Development Lifecycle ) の推進や、Claude Code や Kiro を活用した開発実践の組織的な組込み、CCoE メンバーがより主体的に伴走する設計など、複数の方向性を両社で議論しています。 私たちが見据えているのは、本プログラムを「修了して終わり」にしないことです。力をつけた参加者が、今度はクラウドに不慣れなメンバーを育てる側へ回り、各事業部門のクラウド活用を主導していく。こうして育成と実践のサイクルが自走的に回り続ける体制をつくることが、コニカミノルタが中期経営計画で掲げる持続的成長を、人財の面から支えることにつながると考えています。 中期経営計画「Corporate Plan 2026-2028」が掲げる人財ビジョン。 「すべての参加者にとって本プログラムが AWS への深い理解と AI ネイティブ開発への自信を得るための最良の機会となること」を目標に、コニカミノルタと AWS はこれからも対話と試行錯誤を続けていきます。 6. まとめ 最終成果報告会で見せた 4 テーマの成果は、 AWS のマネージドサービスを実践的に使いこなす力、認定試験を通じた体系的な知見、そして AI エージェントを駆使した開発スピードの劇的な向上が、各事業部門の現場で確実に獲得されたことを示しています。事業課題そのものを題材に持ち込む事業課題解決型へと本質をアップデートした AWS Boost Camp! は、コニカミノルタの中期経営計画が掲げる人財ビジョンを実現していく上で、その役割をますます大きくしていきます。 最後に、本プログラムを半年間にわたり全力で走り抜けてくださった参加者の皆様、テーマオーナーの皆様、運営事務局の皆様、そして CCoE メンバーの皆様に心から感謝を申し上げます。 執筆者 コニカミノルタ株式会社 Cloud CoE 吉田 宏樹 新田 祐士 ソフト・ICT 部会 五寳 匡郎 西村 有史 Amazon Web Services Japan ソリューションアーキテクト 森下 裕介  
こんにちは!製造業のお客様を中心に技術支援をしているソリューションアーキテクトの伊藤ジャッジです。だんだん梅雨らしい気候になってきましたね。この時期といえば今年も  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、カメラの3つのソースを統合して、最終的に 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 のビルドを共同設計することです。