みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 いよいよ 8 月、夏本番ですね。連日の暑さに負けず、今週も生成 AI 界隈のアップデートをキャッチアップしていきましょう。 8 月の builders.flash 記事が出ていますので生成AI関連のものをピックアップしてみます。今月も多くの生成AIに関する記事が出ています。 AWS Summit Japan 2026 Builders’ Fair 人気投票第 1 位「ペン字見ます ! ~ AI Agent 先生の辛口査定 ~」の裏側 ! 少量のレガシー言語プログラムを Amazon Quick で解読してみた Amazon Bedrock AgentCore harness と AWS Step Functions を組み合わせて安全に AI エージェントを構築してみよう ! Kiro、1 歳。コードを書く IDE から、仕事を任せるチームへ どの記事も実践的かつ生成AI活用の観点が異なっており参考になりますね。 また新しい AWS Black Belt オンラインセミナー資料・動画 も続々と出ています。生成 AI 関連では「Amazon Bedrock AgentCore Runtime Dive Deep」と「AWS FinOps Agent (preview)」の資料が公開されています。是非チェックしてみてください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、7 月 27 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「全従業員の行動変容を目指すAstemo が自己破壊を経て見つけたAI駆動開発の実効性」を公開 Astemo 様は、自動車部品・システムを手がけるグローバルメガサプライヤーです。自動車のソフトウェア定義化 (SDV) が進む中、全従業員の行動変容を目指し、44 名・7 チームが実業務テーマで AI 駆動開発ライフサイクル (AI-DLC) を 3 日間体験しました。人間はレビューと意思決定に集中するスタイルで、3 日間で 9 マイクロサービス / 4,500 行超を開発し、開発スピードは約 200% 向上しています。7 チーム全てがデモ可能なプロトタイプを完成させ、あるチームは翌週に本番リリースまで到達しました。 ブログ記事「Outpost VFX が ビジュアルエフェクト向けに AI モデルのトレーニングを AWS で加速した方法」を公開 Outpost VFX 様は、英国、カナダ、インドにスタジオを構える VFX 制作会社です。フェイスリプレースメント用 AI モデルの学習がシングル GPU の制約で 1〜2 週間かかり、制作のボトルネックになっていました。AWS Generative AI Innovation Center と連携し、Amazon EC2 P5 インスタンスでの分散トレーニングへ移行した結果、学習速度は最大 8 倍に向上しています。初回レビュー用の納品期間も 1〜2 週間から 2 日間へ短縮されました。 ブログ記事「【開催報告】AWS Summit Japan 2026 物流業界向けブース展示「スマートグラス×生成AIエージェントで倉庫業務を革新」」を公開 AWS Summit Japan 2026 の物流業界向けブースで展示した、スマートグラスと生成 AI エージェントによる倉庫ピッキング支援デモの解説記事です。「ピッキングリストをください」と話しかけるだけで、Amazon Nova 2 Sonic が音声のまま理解して WMS から作業リストを取得し、QR スキャンで完了記録まで自動化します。1 会話あたり約 8.9 円というコスト試算まで公開されているのが実践的です。 ブログ記事「【開催報告】AWS Summit Japan 2026 〜 流通小売・消費財・飲食業界向けブース」を公開 「AI エージェントが業務の主役になる日」をテーマにした流通小売・消費財・飲食業界向けブースの開催報告です。バーチャル AI エキスパートから Agentic Commerce まで 6 テーマ 7 デモに加え、株式会社ユナイテッドアローズ様と株式会社カインズ様の事例展示も紹介されています。各デモの詳細解説ブログへのリンク集としても便利です。 ブログ記事「AWS Summit Japan 2026：完全自律型 AI Agent が変える SaaS の世界」を公開 AWS Summit Japan 2026 で展示した、Amazon Bedrock AgentCore を活用したマルチテナント AI CRM デモの解説記事です。メールの分類から回答生成、担当者アサインまでを 6 種類の Agent が協働で処理し、人間は承認のみを行うことで、従来 2 時間かかっていた対応が 5 分以内で完了します。「Agent を取り込む SaaS」設計の 4 つのポイントが整理されており、SaaS 事業者の方におすすめです。 ブログ記事「エージェンティック AI と AWS Transform でメインフレームアプリケーションを再構想 (reimagine) する」を公開 メインフレームのレガシーアプリケーションを、エージェンティック AI でクラウドネイティブに作り変える reimagine パターンの解説記事です。AWS Transform for mainframe が COBOL からビジネスロジックを抽出し、Kiro がマイクロサービス仕様とコードを生成する 3 フェーズの方法論を紹介しています。Human in the Loop の検証を挟み、スピードとリスク低減を両立させる考え方が参考になります。 ブログ記事「Amazon GuardDuty 調査エージェントのご紹介: オンデマンドの AI を活用した脅威評価」を公開 Amazon GuardDuty の調査エージェント (パブリックプレビュー) の紹介記事です。AI がセキュリティ検出結果の調査を自動化し、数時間かかっていた調査を数分に短縮します。リスクレベルや MITRE ATT&CK マッピング、推奨アクションが構造化された形で得られ、AWS MCP サーバー経由で AI ワークフローにも統合できます。 ブログ記事「Security Hub が AI ワークロード保護と Microsoft Azure 対応のマルチクラウドサポートを追加」を公開 AWS Security Hub の 2 つの大きな拡張が発表されました。AI ワークロード保護として、異常なモデル呼び出しやコストハーベスティングを検出する GuardDuty AI Protection、調査を自動化する AI-powered investigations、AI 資産を可視化する Security Hub AI inventory が加わります。マルチクラウド対応では、Microsoft Azure の検出結果を AWS と並べて優先順位付けできるようになりました。 ブログ記事「オープンソースサプライチェーン攻撃の背後にいる北朝鮮のハッカーグループを Amazon が特定」を公開 Amazon Threat Intelligence が、axios、debug、chalk、typo-crypto という人気 NPM パッケージの侵害が同一の北朝鮮関連脅威アクターによるものと初めて特定した調査記事です。生成 AI で悪意のあるパッケージの「見た目の不自然さ」が消えつつあることや、スロップスクワッティングといった新たな脅威も解説されています。OSS に依存する全ての開発者に関係する内容です。 サービスアップデート Amazon Bedrock が OpenAI GPT-5.6 モデルの最大 80% 値下げを発表 Amazon Bedrock 上の OpenAI GPT-5.6 のオンデマンド推論価格が値下げされました。高速・低コストの Luna は 80%、バランス型の Terra は 20% の値下げで、設定変更なしで新価格が自動適用されます (Sol は据え置き)。あわせて Kiro でも GPT-5.6 のクレジット倍率が引き下げ られました (Luna 0.6x → 0.1x、Terra 1.2x → 1.0x)。詳細は こちらのドキュメント をご参照ください。 Grok 4.3 が AWS GovCloud (US-West) の Amazon Bedrock で利用可能に xAI の Grok 4.3 が AWS GovCloud (US-West) の Amazon Bedrock で利用可能になりました。GovCloud への xAI モデルの提供は今回が初めてです。推論の深さを 4 段階で設定でき、ツール利用と指示追従、トークン効率に強みがあります。 Gemma 4 モデルが AWS GovCloud (US-West) の Amazon Bedrock で利用可能に Google DeepMind のオープンウェイトモデル Gemma 4 ファミリーが AWS GovCloud (US-West) の Amazon Bedrock で利用可能になりました。256K トークンコンテキストの 31B、コスト重視の MoE 構成 26B-A4B、低遅延の E2B の 3 バリアント構成です。35 以上の言語と、テキスト・画像・動画・音声のマルチモーダル入力に対応します。 Amazon SageMaker Unified Studio が全プロジェクトツールで Git バージョン管理を強化 Amazon SageMaker Unified Studio の全プロジェクトツール (Query Editor、Visual ETL、Workflows、Notebooks) で、ファイルレベルの Git バージョン管理が利用できるようになりました。これまで Git 非対応だった Notebooks も対象になり、ブランチ作成や競合解決までプロジェクト内で完結します。詳細は こちらのドキュメント をご参照ください。 Amazon OpenSearch Service が OpenSearch 3.7 をサポート Amazon OpenSearch Service で OpenSearch 3.7 が利用可能になりました。1-bit スカラー量子化により、検索精度を維持しながらベクトルワークロードのストレージとメモリ使用量を削減できます。RAG の検索基盤のコストとパフォーマンスに効くアップデートです。詳細は こちらのドキュメント をご参照ください。 AWS Security Hub MCP App がプレビュー公開 Security Hub のエクスポージャー検出結果を Claude Desktop から直接扱える、ローカル実行の MCP サーバーがプレビューになりました。自然言語で上位のエクスポージャーを確認し、攻撃パスの掘り下げから修復の推奨事項まで得られます。全ツールが読み取り専用のため、環境に変更が加わる心配なく試せます。詳細は こちらのドキュメント をご参照ください。 Kiro CLI 2.16.0 / 2.15.0 と IDE 1.0.242 が公開 Kiro CLI 2.16.0 では、会話履歴を引き継いだままサイド会話に分岐できる /tangent コマンドと、/context のツール別トークン内訳表示が追加されました。CLI 2.15.0 では /spec new のガイド付きステップと、Plan モードでの承認後の自動実行が入っています。IDE 1.0.242 では、右クリックメニューの Kiro サブメニューや、エラーに対する「Ask Kiro to Fix」クイックフィックスが加わりました。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 はじめに、7月28日に熊本県で発生した地震(令和8年熊本地震)により被害に遭われた皆様に、心よりお見舞い申し上げます。被災された皆様の安全と、一日も早い復旧を心よりお祈りしております。 話題は変わりますが、AWS 認定をこれから取得したい方、あるいはスキルアップを考えている方に向けたキャンペーンのご案内です。現在、 AWS 認定 AI スキルアップキャンペーン が実施されており、AWS Certified AI Practitioner (AIF-C01) を 2026 年 9 月 30 日までに受験すると試験料が 50% 割引になります。さらに合格すると、AWS Certified Cloud Practitioner (CLF-C02) を無料で受験できます。この夏、AI 分野の認定取得にチャレンジしてみるのはいかがでしょうか。 それでは、先週の主なアップデートについて振り返っていきましょう！ 2026年7月27日週の主要なアップデート 7/27(月) Amazon RDS for SQL Server が Multi-AZ インスタンスでの TDE データベース復元に対応 Amazon RDS for SQL Server で、TDE (Transparent Data Encryption) を有効にした SQL Server データベースを Multi-AZ インスタンスおよび同一リージョン内のリードレプリカを構成したインスタンスに復元できるようになりました。ネイティブバックアップ・リストア機能を使用します。従来は Single-AZ インスタンスでのみ TDE 有効データベースの復元が可能で、暗号化データを復元するには TDE を無効化するか Single-AZ 構成への移行が必要でした。今回の対応により、保存時暗号化 (TDE) と Multi-AZ の高可用性の両方を必要とする移行・復旧のワークフローを簡素化できます。この機能は Amazon RDS for SQL Server が提供されるすべての AWS リージョンで利用できます。 AWS Security Hub MCP App で、エクスポージャー検出結果を自然言語で調査可能に (プレビュー) AWS Security Hub MCP App のパブリックプレビューが開始されました。これは Claude Desktop 内で動作するローカルの Model Context Protocol (MCP) サーバーで、Security Hub のエクスポージャー検出結果について、攻撃パスの深掘りや修復方法の提案などを自然言語で調査できます。すべてのツールは読み取り専用 (read-only) で、環境に変更を加えずに利用できます。Security Hub の利用者は追加費用なしで使うことができます。 Amazon EKS がクラスター OIDC エンドポイント向けの AWS PrivateLink に対応 Amazon EKS が、クラスターの OIDC ディスカバリおよび JWKS エンドポイント向けの AWS PrivateLink に対応しました。インターフェイス型 VPC エンドポイント (サービス名 `com.amazonaws.[リージョン名].oidc-eks`) を作成することで、VPC 内の eksctl や Terraform、独自のトークン検証ツールが、IAM roles for service accounts (IRSA) のセットアップやトークン検証を、インターネットに出ることなく閉域 VPC 内で実行できるようになりました。追加料金はなく、標準の AWS PrivateLink 料金のみが適用されます。 7/28(火) Amazon S3 Tables が Apache Iceberg V3 の Variant データ型に対応 Amazon S3 Tables が Apache Iceberg V3 仕様の Variant データ型に対応しました。JSON などの半構造化データを事前にスキーマを固定せずに直接書き込めます。書き込み時に Iceberg V3 対応エンジンが Variant データを隠しカラムに分解 (shredding) し、Parquet のカラム統計を生成します。クエリエンジンはこの統計を使ってファイルプルーニングを行い、分析クエリがスキャンするデータ量を減らします。S3 Tables は Variant カラムに対してもコンパクションを含むテーブルメンテナンスを継続実行します。東京を含む、15 の AWS リージョンで利用できます。 AWS DataSync Enhanced mode が HDFS、Azure Blob、オブジェクトストレージのロケーションと Hyper-V エージェントに対応 AWS DataSync の Enhanced mode が、エージェント経由での HDFS (Hadoop Distributed File System)、Microsoft Azure Blob Storage、および自己管理型オブジェクトストレージへの転送に対応しました。あわせて Enhanced mode のエージェントを Microsoft Hyper-V 上に展開できるようになりました。HDFS 転送では複数 NameNode 構成 (High Availability) と Kerberos 認証を用いた TDE (Transparent Data Encryption) に対応します。これにより規制業界の組織が、可用性を維持したままペタバイト級の暗号化 Hadoop データを移行できます。この機能は DataSync が提供されているすべての AWS リージョンで利用できます。 AWS DataSync Enhanced mode が Amazon EFS および Amazon FSx for Lustre をサポート AWS DataSync の Enhanced mode が、転送元・転送先として Amazon EFS と Amazon FSx for Lustre に対応しました。従来これらのストレージへの転送は Basic mode に限定されていましたが、今回のアップデートで Enhanced mode を選択できるようになりました。Enhanced mode はデータを並列に処理し、ファイル数の上限がなく、詳細な転送メトリクスを提供します。大規模なデータ移行や AI/ML の学習データ準備、HPC、ゲノム解析、メディアレンダリングといったワークロードで利用できます。AWS DataSync が提供されているすべての AWS リージョンで利用可能です。 7/29(水) IAM Identity Center が Identity Center ディレクトリのマルチリージョン対応を拡張 AWS IAM Identity Center が、ID ソースとして Identity Center ディレクトリを使用する組織インスタンスでもマルチリージョンレプリケーションに対応しました。これまで外部 IdP 接続のインスタンスに限られていた機能が拡張されています。プライマリリージョンで有効化したインスタンスを、デフォルトで有効化されている 17 の商用リージョンから選んだリージョンへ複製できます。ユーザー ID、権限セット、割り当て、セッションなどが自動でレプリケートされ、プライマリリージョンで障害が発生してもプロビジョニング済みのアクセスを維持できます。利用にはマルチリージョン対応の customer managed KMS key (CMK) が必要です。 AWS Interconnect – multicloud (Oracle Cloud Infrastructure 対応) が一般提供を開始 AWS は AWS Interconnect – multicloud の Oracle Cloud Infrastructure (OCI) 対応を一般提供 (GA) しました。この機能を使うと、AWS の VPC と OCI の VCN (Virtual Cloud Network) の間に、専用帯域を持つプライベート接続を短時間で作成できます。従来は複数クラウド間の相互接続を自前で構築する必要がありましたが、その運用負荷を AWS と接続先プロバイダーが肩代わりします。GA 時点では OCI と Google Cloud に対応し、米国東部 (バージニア北部) リージョンで利用できます。Microsoft Azure は 2026 年後半に対応予定です。 AWS Glue の REST API コネクタが VPC 接続、フィルタプッシュダウン、パーティションに対応 AWS Glue の REST API コネクタに 3 つの機能が追加されました。プライベートサブネットや VPN、AWS PrivateLink 経由の非公開 REST API に接続できる VPC 対応、クエリ条件を API ネイティブのパラメータに変換して転送量を減らすフィルタプッシュダウン、大規模データを複数の Spark ワーカーに分割して並列読み取りするパーティション対応です。これにより REST API を持つ任意のデータソースから、カスタムコードを書かずに ETL パイプラインを構築できます。 7/30(木) AWS Managed Microsoft AD が Standard から Enterprise Edition へのアップグレードに対応 AWS Directory Service は、AWS Managed Microsoft AD の Standard Edition ディレクトリを Enterprise Edition へ直接アップグレードする機能に対応しました。AWS Management Console、AWS CLI、API、AWS Tools for PowerShell から実行でき、新しいディレクトリへの移行や既存ワークロードのドメイン再参加は不要です。信頼関係、アプリケーション統合、グループポリシー、DNS 設定はそのまま維持されます。所要時間は 4 時間から 5 時間で、ドメインコントローラー (DC) を 1 台ずつ入れ替えるため、その間は性能低下とダウンタイムが発生する可能性があります。アップグレードは不可逆であり、以前のスナップショットはアップグレード後のディレクトリには使用できません。アップグレードには追加料金が発生するため、詳細は Directory Service の料金ページをご確認ください。 AWS Transit Gateway のポリシーベースルーティングが一般提供開始 AWS Transit Gateway (TGW) でポリシーベースルーティング (PBR) の一般提供が開始されました。従来の宛先 IP アドレスのみによる転送判断に加えて、送信元 IP、宛先 IP、送信元ポート、宛先ポート、プロトコルの組み合わせでトラフィックを分類し、転送先の TGW ルートテーブルを選択できます。設定はポリシーテーブルという新しいリソースで行い、アタッチメントに関連付けます。ルールは番号の昇順に評価され、最初に一致したルールが適用されます (first-match-wins)。TGW が提供されているすべての商用リージョンで利用でき、標準の TGW 料金を超える追加課金はありません。ただしポリシーテーブルを関連付けたアタッチメントでは Site-to-Site VPN と Connect への BGP 経路広報が停止するため、導入前に影響確認が必要です。 Amazon SageMaker Unified Studio が全プロジェクトツールで Git バージョン管理を拡充 Amazon SageMaker Unified Studio のリポジトリ機能が更新され、Query Editor、Visual ETL、Workflows、Notebooks の 4 ツールでファイル単位の Git バージョン管理に対応しました。従来の自動同期 (保存ごとにリモートへ force push する方式) を置き換え、コミットメッセージ付きの push とブランチ操作ができるようになりました。これまで Git 非対応だった Notebooks も対象に含まれます。リポジトリはプロジェクト作成時ではなく任意のタイミングで追加でき、1 つのプロジェクトから複数のリポジトリとブランチへ同時に接続できます。既存プロジェクトへの適用はオプトインで、プロジェクトの更新を実行して切り替えます。 7/31(金) Amazon CloudWatch がマネージド Prometheus コレクターを発表 Amazon CloudWatch が、エージェントを配置せずに Prometheus 互換メトリクスを収集するマネージドコレクターに対応しました。従来は自己管理の OpenTelemetry Collector を配置、スケール、保守する必要がありましたが、スクレイプ設定とサブネット、セキュリティグループを指定すれば AWS 側がプロビジョニングとスケーリングを行います。対応対象は Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、Amazon OpenSearch Service です。収集したメトリクスは OpenTelemetry 形式で CloudWatch のデータセットに配信され、PromQL でクエリできます。AWS ベンダーメトリクスと同じ画面でアラームとダッシュボードを構成できます。 Amazon RDS for Oracle が R8i および M8i インスタンスのリザーブドインスタンスを提供開始 Amazon RDS for Oracle で、R8i および M8i インスタンスに対する 1 年および 3 年のリザーブドインスタンス (RI) を購入できるようになりました。オンデマンド価格と比較して最大 53% のコスト削減となります。RI の割引は Multi-AZ 構成と Single-AZ 構成の双方に適用され、同一インスタンスクラスタイプ内であれば構成を変更できます。BYOL ライセンスモデルではサイズ柔軟性が働き、同一インスタンスファミリー内のどのサイズの使用量にも割引レートが自動適用されます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

本ブログは 2026 年 7 月 30 日に公開された AWS Blog “ Extend Amazon Inspector SBOM Generator with Plugins ” を翻訳したものです。 Amazon Inspector は、 Amazon Web Services (AWS) のワークロードを継続的にスキャンしてソフトウェアの脆弱性を検出する、自動化された脆弱性管理サービスです。Amazon Inspector の脆弱性管理機能は、 Amazon Inspector SBOM Generator (inspector-sbomgen) と呼ばれる資産インベントリエンジンによって支えられています。これはスタンドアロンのコマンドラインツールで、コンテナイメージ、ディレクトリ、アーカイブ、ローカルシステム、コンパイル済みバイナリなどから ソフトウェア部品表 (SBOM) を生成します。過去 2 年間で、AWS は inspector-sbomgen のカバレッジを数十のプログラミング言語エコシステム、オペレーティングシステム、広く導入されているアプリケーションへと拡大してきました。 今回、inspector-sbomgen を利用するビルダー向けの新機能として、独自のカスタムパッケージコレクターを記述できる プラグインシステム を発表します。ソースコードのコンパイルや公式リリースを待つ必要はなく、すぐに使い始めることができます。 inspector-sbomgen の最新バージョンは、 Amazon Inspector ユーザーガイド からダウンロードできます。 この記事では、inspector-sbomgen プラグインシステムでできること、これを構築した理由、そして数分で最初のプラグインを書く方法を紹介します。あわせて、プラグインが生成したパッケージコンポーネントを Amazon Inspector の脆弱性スキャンと統合する方法や、セキュリティが強化された予測可能なプラグイン動作を実現するプラグインの安全性モデルについても解説します。 プラグインシステムを構築した理由 ソフトウェアのエコシステムは動的です。新しい言語パッケージマネージャー、ロックファイル形式、エンドユーザーアプリケーションが絶えずリリースされ、その多くは迅速に採用されます。中にはセキュリティの検証がほとんど行われないまま使われるものもあります。その結果、セキュリティチームには可視性のギャップが残ります。つまり、SBOM ツールがまだ認識できないソフトウェアが本番ワークロードで動いているという状態です。お客様からは、こうしたエコシステムの多くを直接インベントリ化したいという要望をいただいてきました。最近まで、それを実現する唯一の方法は、機能リクエストを出して inspector-sbomgen チームがエコシステムに対応し、新しいリリースをデプロイするのを待つことでした。 inspector-sbomgen プラグインシステムは、この状況を変えます。プラグインを使うと、次のことができます。 inspector-sbomgen が標準では対応していないエコシステムへの対応 – 新しいオープンソースエコシステム、ニッチまたは変化の速いパッケージ形式、組織独自のツールなど、inspector-sbomgen を変更することなくインベントリ化できます エコシステム検出の迅速なプロトタイピング – 開発者にも AI コーディングアシスタントにも扱いやすいプラグインシステムを設計しました。プラグインは Lua で記述され、実行時にロードされるため、Go ツールチェーンもコンパイルも不要です。組み込みのテストハーネスを使ってプラグインを繰り返し改善し、すぐに結果を確認できます 安定した基盤の上での構築 – プラグイン API はアーティファクトの種類による違いを抽象化するため、検出ロジックを一度書くだけで、コンテナイメージ、アーカイブ、ローカルシステムなどでシームレスに動作します。また、プラグインは sbomgen の内部構造から分離されているため、コアツールでリグレッションが発生した場合の影響範囲も小さく抑えられます 実際、私たち自身もこのプラグインシステムを内部で活用し、新しいエコシステムのカバレッジを以前より速く提供できるようになりました。 1.13 リリース では、Apache Tomcat、NGINX、MySQL、Redis、WordPress、OpenSSH ツールチェーンなど、これまで Go で実装されていた 20 以上のエコシステムが、プラグインとして sbomgen バイナリに組み込まれています。同じリリースでは、Apache Cassandra、Apache Struts、Conda、Swift パッケージ、AI エージェントコレクター (Amazon Q Developer、Kiro CLI、Claude Code、GitHub Copilot、Ollama) など、10 を超える新しいエコシステムもプラグインとして追加されました。 inspector-sbomgen プラグインの仕組み sbomgen プラグインは 2 段階のパイプラインで動作します。 検出 (discovery) – アーティファクトのファイルシステムをスキャンし、インストール済みパッケージのメタデータを含むファイルを特定します 収集 (collection) – 検出された各ファイルを開き、ファイルの内容を解析して、結果を SBOM にパブリッシュします 内部では、イベントバスが検出プラグインと収集プラグインをつないでいます。検出プラグインは検出したファイルの一覧をイベントとしてパブリッシュし、1 つ以上の収集プラグインがそのイベントをサブスクライブして、パッケージ収集をトリガーします。開発者にとっては、これは オブザーバーパターン としておなじみの動作でしょう。 この分離により、1 つの検出プラグインが複数のコレクターにデータを供給できます。例えば、あるコレクターはパッケージメタデータを抽出し、別のコレクターはシークレットをスキャンし、さらに別のコレクターはポリシーをチェックする、といった構成が可能です。各収集プラグインは、計算コストの高いアーティファクトファイルシステムの再走査を行うことなく、同じファイルリストを利用できます。 5 分で書ける最初のプラグイン inspector-sbomgen を使えば、プラグイン環境を簡単にセットアップできます。 plugin new コマンドで sbomgen に新しいプラグインワークスペースを作成させ、 --with-example フラグを指定すると、すぐに実行できる検出プラグインと収集プラグインのペアがワークスペースに用意されます。 inspector-sbomgen plugin new --with-example 上記のコマンドを実行すると、プラグイン名と、プラグインワークスペースを格納するディレクトリの入力を求められます。カスタム値を指定することも、デフォルト値をそのまま使うこともできます。 Plugin name (identifies the software ecosystem your plugin will inventory, e.g. debian-dpkg, rhel-rpm, python-pip, cmake) [my-custom-ecosystem]: <enter> Project directory [my-sbomgen-plugins]: <enter> Created plugin "my-custom-ecosystem" in my-sbomgen-plugins/ なお、対応するコマンドラインインターフェイス (CLI) 引数でプラグイン名とディレクトリを指定すれば、対話形式のプロンプトをスキップできます。 inspector-sbomgen plugin new \ --with-example \ --name my-custom-ecosystem \ --path my-sbomgen-plugins プラグインワークスペースを作成すると、inspector-sbomgen は次のステップを案内する画面を表示します。開発者や AI コーディングアシスタントに対して、変更が必要なソースファイルや関連ドキュメントの場所を示してくれます。 Next steps: Get started: 1. Open plugin folder in a code editor (VS Code recommended) 2. Add test files that your plugin will discover and parse (e.g., config files, lockfiles, binaries, etc.): my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/ Develop: 3. Edit discovery: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua 4. Edit collection: my-sbomgen-plugins/collection/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua Test: 5. Write unit tests: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init_test.lua 6. Run unit tests: inspector-sbomgen plugin test --path my-sbomgen-plugins Deploy: 7. Distribute your plugin directory wherever you run inspector-sbomgen: inspector-sbomgen <arguments> --plugin-dir /path/to/my-sbomgen-plugins Example: inspector-sbomgen container --image alpine:latest -o /tmp/sbom.json --plugin-dir /path/to/my-sbomgen-plugins For code completion, install the VS Code Lua language server extension: https://luals.github.io/#vscode-install For more information: - Plugin guide: my-sbomgen-plugins/docs/sbomgen-plugin-developer-guide.md - Testing guide: my-sbomgen-plugins/docs/sbomgen-plugin-testing-guide.md - API reference: my-sbomgen-plugins/docs/sbomgen-plugin-api-reference.md - Documentation: https://docs.aws.amazon.com/inspector/latest/user/sbom-generator.html プラグインワークスペースができたので、その中身を詳しく見てみましょう。 tree my-sbomgen-plugins ├── AGENTS.md ├── collection │   └── cross-platform │   └── extra-ecosystems │   └── my-custom-ecosystem │   └── init.lua ├── discovery │   └── cross-platform │   └── extra-ecosystems │   └── my-custom-ecosystem │   ├── _testdata │   │   ├── empty │   │   └── example.lock │   ├── init_test.lua │   └── init.lua ├── docs │   ├── sbomgen-plugin-api-reference.md │   ├── sbomgen-plugin-developer-guide.md │   └── sbomgen-plugin-testing-guide.md ├── library │   └── sbomgen.lua └── README.md スキャフォールディングされたプロジェクトには、動作する検出プラグインと収集プラグインのペア、 _testdata/ 配下のテストフィクスチャを使ってパスするユニットテスト、統合開発環境 (IDE) 連携用の .vscode/settings.json 、開発者ドキュメントのローカルコピーが含まれています。 スキャフォールディングは、人間と AI コーディングアシスタントの両方が読みやすいように、意図的に簡潔で完結した内容になっています。各ファイルには、それぞれの関数の役割と、プラグイン作成者が記述すべき箇所を説明する明確なコメントが付いています。 プラグインをテストするには、まずパッケージロックファイルやコンパイル済みバイナリなど、スキャン対象となるものが必要です。サンプルプラグインは、次の内容を持つ架空の example.lock をインベントリ化します。 my-package-alpha==1.0.0 my-package-beta==2.3.1 my-package-gamma==0.9.5 付属の検出プラグインは、アーティファクトのファイルシステム内で example.lock のインスタンスを探す方法を知っています。 -- my-custom-ecosystem discovery plugin -- Discovers example.lock files in the artifact file list. function discover() return sbomgen.find_files_by_name({"example.lock"}) end そして、付属の収集プラグインは、 example.lock の内容を解析し、パッケージ情報を出力 SBOM にパブリッシュする方法を知っています。 -- my-custom-ecosystem collection plugin -- Parses example.lock files and extracts package name and version. function collect(file_path) local content = sbomgen.read_file(file_path) if content == nil then return end for line in content:gmatch("[^\n]+") do local name, ver = line:match("^(.+)==(.+)$") if name and ver then sbomgen.push_package({ name = name, version = ver, purl_type = "generic", namespace = "my-custom-ecosystem", component_type = sbomgen.component_types.APPLICATION, }) end end end テストの実行 プラグインにはテストフレームワークが組み込まれているため、実際のアーティファクトをスキャンする前にロジックを検証できます。テストは Lua で記述し、プラグインと同じ場所の init_test.lua に配置して、 _testdata/ 内のフィクスチャデータを参照します。 function test_discovers_packages() local result = testing.scan_directory("_testdata") testing.assert_equals(3, #result.findings) testing.assert_equals("my-package-alpha", result.findings[1].name) testing.assert_equals("1.0.0", result.findings[1].version) end function test_no_findings_for_empty_directory() local result = testing.scan_directory("_testdata/empty") testing.assert_equals(0, #result.findings) end 次のコマンドでテストを実行します。 inspector-sbomgen plugin test --path my-sbomgen-plugins -v === RUN my-custom-ecosystem/discovery/init_test/test_discovers_packages --- PASS: my-custom-ecosystem/discovery/init_test/test_discovers_packages (0.04s) === RUN my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory --- PASS: my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory (0.04s) ok 2 tests passed これは、私たちが設計し得た最も短い開発ループです。Go ツールチェーンも、再ビルドも、コンテナの起動も不要です。テストを書き、実行し、繰り返し改善するだけです。 実際のアーティファクトのスキャン プラグインが結果を生成するには、プラグインが探すファイルを含むアーティファクトを inspector-sbomgen に与える必要があります。サンプルプラグインの場合、 example.lock ファイルを含む任意のディレクトリが対象になります。先ほど生成したフィクスチャがちょうど良い題材です。 inspector-sbomgen directory \ --plugin-dir ./my-sbomgen-plugins \ --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ -o sbom.json --plugin-dir フラグは、Lua プラグインの読み込み元を inspector-sbomgen に伝えます。生成される SBOM には、 example.lock 内の 3 つのパッケージそれぞれに対応する CycloneDX コンポーネントが含まれます。例を以下に示します。 { "bom-ref": "comp-2", "type": "application", "name": "my-package-alpha", "version": "1.0.0", "scope": "optional", "purl": "pkg:generic/my-sbomgen-plugin/my-package-alpha@1.0.0", "properties": [ { "name": "amazon:inspector:sbom_generator:source_path", "value": "./my-sbomgen-plugins/example.lock" } ] } プラグインが生成するすべてのコンポーネントには、収集元のファイルを記録する amazon:inspector:sbom_generator:source_path プロパティが付いています。そのため、コンポーネントを生成元のアーティファクトまで常にたどることができます。 Amazon Inspector による脆弱性スキャン プラグインが生成したパッケージ情報は、他のコンポーネントと同等の正式な SBOM コンポーネントとして扱われます。Amazon Inspector を含め、CycloneDX SBOM を読み取るあらゆる下流のツールで利用できます。SBOM を Amazon Inspector に送信して脆弱性分析を行うには、 --scan-sbom フラグを追加します (有効な AWS アカウントが必要です)。 inspector-sbomgen directory \ --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ --plugin-dir ./my-sbomgen-plugins \ --scan-sbom \ --aws-profile your_profile \ --aws-region your_region \ -o /tmp/sbom.json まったく新しいエコシステムに対応する際の重要な注意点 : プラグイン作成者は任意のエコシステムをインベントリ化できますが、Amazon Inspector が脆弱性を報告できるのは、アドバイザリが存在するコンポーネントに限られます。アドバイザリフィードにまだ含まれていないエコシステムのコンポーネントを Amazon Inspector に渡すと、Amazon Inspector は Component skipped: no supported rules found (コンポーネントはスキップされました: サポートされるルールが見つかりません) というプロパティ付きでコンポーネントを返します。以下に例を示します。 { "bom-ref": "comp-1", "name": "my-package-alpha", "properties": [ { "name": "amazon:inspector:sbom_scanner:path", "value": "my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/example.lock" }, { "name": "amazon:inspector:sbom_scanner:info", "value": "Component skipped: no supported rules found." } ], "purl": "pkg:generic/my-custom-ecosystem/my-package-alpha@1.0.0", "type": "application", "version": "1.0.0" } これはエラーではなく、想定どおりの動作です。SBOM は正しく生成され、コンポーネントは引き続き追跡され、 source_path によってどのファイルから生成されたかを正確に把握できます。Amazon Inspector がそのエコシステムのアドバイザリカバレッジを追加すれば、プラグインを一切変更することなく、同じ SBOM から脆弱性の検出結果が生成されるようになります。Amazon Inspector がすでにサポートしているエコシステムについては、プラグインが生成したコンポーネントは組み込みスキャナーが生成したコンポーネントと区別なく扱われます。 ファーストクラスの IDE サポート AWS は、プラグインを書くときの生産性と効率を重視しています。オートコンプリートのようなモダンな便利機能なしで Lua を書くのは快適とは言えません。そのため、 plugin new コマンドでスキャフォールディングされたすべてのプラグインプロジェクトには、 library/sbomgen.lua 定義ファイルと、それを VS Code の Lua Language Server 拡張機能に自動的に接続する .vscode/settings.json が付属します。 コード補完と IDE サポートを利用するには、まず sumneko.lua 拡張機能をインストールし、VS Code でプラグインプロジェクトを開きます。これにより、すべての sbomgen.* 関数で次の機能が使えるようになります。 型情報付きのパラメータヒント ホバー時のドキュメント表示 定数のオートコンプリート ( sbomgen.component_types.* 、 sbomgen.groups.* 、 sbomgen.platform.* ) 関数呼び出しの型チェック push_package() に必須フィールドが欠けている場合のインライン警告 この定義ファイルのおかげで、AI コーディングアシスタントによるプラグイン開発もうまく機能します。型情報とドキュメントがツールで読み取れる形式で埋め込まれているため、アシスタントは、素の Lua で記述する場合に比べてはるかに少ない人手の確認で正しいプラグインコードを生成できます。 安全な基盤 プラグインは inspector-sbomgen と同じプロセス内で実際のコードを実行するため、そのコードが安定し、セキュリティが強化された状態を保てるように実行環境を設計しました。すべての Lua プラグインは隔離されたサンドボックス内で実行されます。各 Lua 仮想マシン (VM) は、安全な操作のみが許可されるように、Lua 標準ライブラリの制限されたサブセットにのみアクセスできます。 ファイルシステムへの直接アクセスの禁止 – Lua の io ライブラリはロードされません。すべてのファイル操作は sbomgen.* 関数を経由して sbomgen の内部処理にルーティングされるため、ディスク上のディレクトリ、コンテナイメージ、圧縮アーカイブ、マウントされたボリュームのいずれをスキャンする場合でも、プラグインは同じように動作します サブプロセスの実行や環境の変更の禁止 – Lua の os ライブラリはブロックされているため、プラグインはプロセスの起動、環境変数の変更、アーティファクト外のファイルへのアクセスができません VM のイントロスペクションの禁止 – Lua の debug ライブラリはブロックされています 無制限なコードロードの禁止 – dofile 、 loadfile 、 loadstring は削除されています。 require() は利用できますが、プラグイン自身のディレクトリツリーに制限されているため、プラグインは自身のヘルパーモジュールを共有できる一方、他のプラグインやシステムパスからコードをロードすることはできません プラグインが未処理の Lua エラーを発生させた場合、inspector-sbomgen は警告をログに記録し、次のファイルまたはプラグインの処理を続行します。1 つの不具合のあるプラグインが他のプラグインの実行を妨げることはありません。また、プラグインが inspector-sbomgen の組み込みパッケージコレクターを上書きすることもありません。すべてのプラグインは一意の名前を宣言する必要があり、カスタムプラグインが公式の組み込みプラグインですでに使われている名前を使用した場合、そのカスタムプラグインは警告付きでスキップされます。組み込みプラグインが常に優先されるため、カスタムプラグインがツール自身の検出動作をひそかに置き換えたり隠したりすることはできません。 次のステップ 今すぐ独自のプラグインの構築を始めるには、次の手順に従ってください。 Amazon Inspector ユーザーガイド から最新の inspector-sbomgen をインストールします inspector-sbomgen plugin new --with-example を実行し、プロンプトに従います inspector-sbomgen plugin test --path ./my-sbomgen-plugins -v を実行し、サンプルテストがパスすることを確認します サンプルのロジックを、独自のエコシステム向けの検出ロジックに置き換えます すべての関数、定数、コマンドについては、以下の完全なリファレンスドキュメントで詳しく説明しています。 Lua プラグイン開発者ガイド : プラグインの概念、ディレクトリ構造、ライフサイクル Lua プラグインテストガイド : テストフレームワークのリファレンスとフィクスチャの規約 Lua プラグイン API リファレンス : sbomgen.* API の完全なカタログ まとめ 組織独自のロックファイル形式への対応の追加、新しいオープンソースエコシステム向け検出のプロトタイピング、あるいは自作スキャナーから組織全体で大規模に運用できる仕組みへの置き換えなど、どのような用途であっても、このプラグインシステムは、アイデアから動作する SBOM までの道のりをできる限り短くするように設計されています。皆さんがこれを使って何を作るのか、とても楽しみにしています。 この記事に関するご質問がある場合は、 AWS サポートにお問い合わせください 。 Michael Long Michael は AWS の Amazon Inspector 担当 Senior Security Researcher です。Amazon Inspector SBOM Generator と Amazon Inspector for GitHub Actions の研究開発を率いています。AWS 入社前は、MITRE ATT&CK チームで principal adversary emulation engineer を務めていました。また、U.S. Army (米国陸軍) で約 10 年間、軍事情報およびサイバー作戦に従事しました。 Charlie Bacon Charlie は AWS の Amazon Inspector 担当 Head of Security Engineering and Research です。Amazon Inspector や他の Amazon Security の脆弱性管理ツールを支える脆弱性スキャンおよびインベントリ収集サービスを担当するチームを率いています。AWS 入社前は、金融業界とセキュリティ業界で 20 年間にわたり、研究と製品開発の両分野で上級職を務めました。 Anthony Verleysen Anthony は Amazon Inspector 担当の Senior Technical Product Management です。Amazon Inspector の前は、AWS Systems Manager の Product Manager として Node Management 機能を担当していました。仕事以外では、テニスとサッカーに熱心に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 2 月 12 日に公開された AWS Blog “ Identify Java nested dependencies with Amazon Inspector SBOM Generator ” を翻訳したものです。公開後のサービスアップデートを訳注として補足しています。 Amazon Inspector は自動化された脆弱性管理サービスであり、 Amazon Web Services (AWS) のワークロードを継続的にスキャンして、ソフトウェアの脆弱性や意図しないネットワークの露出を検出します。Amazon Inspector は現在、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Container Registry (Amazon ECR) に保存されたコンテナイメージ、および AWS Lambda に対する脆弱性レポートをサポートしています。 訳注: 2025 年 6 月の Code Security 機能の一般提供開始 により、現在は GitHub および GitLab 上のソースコードリポジトリ (SAST / SCA / IaC スキャン) も対象となっています。 Java アーカイブファイル (JAR、WAR、EAR) は、Java アプリケーションやライブラリのパッケージングに広く使用されています。これらのファイルには、アプリケーションが正しく動作するために必要なさまざまな依存関係を含めることができます。場合によっては、JAR ファイルの構造の中に別の JAR ファイルが含まれ、ネストされた依存関係が生じることがあります。Java アプリケーションのセキュリティと安定性を維持するには、こうしたネストされた依存関係を特定し、管理することが不可欠です。 本記事では、ネストされた Java 依存関係を発見する際の課題への対処方法を紹介し、JAR ファイルを分析してこれらの依存関係を明らかにするプロセスを解説します。ここでは、 Amazon Inspector SBOM Generator を使用して Amazon Inspector が特定する脆弱性に焦点を当てます。 ネストされた Java 依存関係を発見する際の課題 Java アプリケーションのネストされた依存関係には、古くなっているものや、 共通脆弱性識別子 (CVE) に関連付けられた既知の脆弱性を含むものが存在することがあります。ここでお客様が直面する重要な問題は、分析やトリアージの際にネストされた依存関係が見落とされがちなことです。この見落としにより、脆弱性が誤検知と判断され、セキュリティリスクにつながる可能性があります。 この課題は、以下のような複数の要因から生じます。 脆弱性の量 : 大量の脆弱性に直面すると、その数の多さに圧倒され、それぞれを徹底的に分析するための十分な時間とリソースを確保することが難しくなります ツールの不足または不十分なツール : ネストされた依存関係を効果的に特定できるツール ( mvn dependency:tree や OWASP Dependency-Check など) が十分に整備されていないことがよくあります。適切なツールがなければ、アプリケーションの深部に隠れた重要な依存関係を見逃す可能性があります 複雑さの理解 : 複雑に絡み合ったネストされた依存関係を理解するには、特定のスキルセットと知識が必要です。こうしたスキルや知識が不足していると、効果的な分析とリスク緩和の妨げになる可能性があります ネストされた依存関係の概要 ネストされた依存関係は、アプリケーションが必要とするライブラリやモジュールが、さらに別のライブラリやモジュールに依存している場合に発生します。これはモダンなソフトウェア開発では一般的なシナリオです。開発者は、既存のソリューションを土台にし、オープンソースコミュニティに蓄積された知見を活用するために、サードパーティライブラリを頻繁に使用するからです。 JAR ファイルの文脈では、JAR ファイルの構造の一部として別の JAR ファイルが含まれる場合に、ネストされた依存関係が生じることがあります。これらのネストされたファイルは独自の依存関係を持つことがあり、それがさらに別のライブラリに依存して、依存関係の連鎖を作り出します。ネストされた依存関係はコードのモジュール化と再利用を促進する一方で、適切に管理されないと複雑さが増し、セキュリティ上の脆弱性が生じる可能性が高まります。 JAR ファイルで使用されている依存関係を把握することが重要な理由 ネストされた依存関係がどのように構成されているかを示すために、Java アプリケーションの典型的なファイル構造を表す以下の例を見てみましょう。 例 1: Log4J の依存関係 MyWebApp/ |-- mywebapp-1.0-SNAPSHOT.jar | |-- spring-boot-3.0.2.jar | | |-- spring-boot-autoconfigure-3.0.2.jar | | | |-- ... | | | | |-- log4j-to-slf4j.jar この構造には、以下のファイルと依存関係が含まれています。 mywebapp-1.0-SNAPSHOT.jar はメインのアプリケーション JAR ファイルです mywebapp-1.0-SNAPSHOT.jar の中には、メインアプリケーションの依存関係である spring-boot-3.0.2.jar があります spring-boot-3.0.2.jar の中には、推移的依存関係である spring-boot-autoconfigure-3.0.2.jar がネストされています spring-boot-autoconfigure-3.0.2.jar の中には、ネストされた Log4J の依存関係である log4j-to-slf4j.jar があります この構造は、Log4J が他のライブラリの中にネストされる形で、Java アプリケーションにネストされた依存関係が含まれる仕組みを示しています。実際のネストの深さや依存関係は、プロジェクトで使用する特定のライブラリとバージョンによって異なります。 例 2: Jackson の依存関係 MyFinanceApp/ |-- myfinanceapp-2.5.jar | |-- jackson-databind-2.9.10.jar | | |-- jackson-core-2.9.10.jar | | | |-- ... | | |-- jackson-annotations-2.9.10.jar | | | |-- ... この構造には、以下のファイルと依存関係が含まれています。 myfinanceapp-2.5.jar はアプリケーションのプライマリ JAR ファイルです myfinanceapp-2.5.jar の中には、メインアプリケーションが JSON 処理のために利用するライブラリである jackson-databind-2.9.10.jar があります jackson-databind-2.9.10.jar の中には、 jackson-core-2.9.10.jar や jackson-annotations-2.9.10.jar などの他の Jackson コンポーネントがネストされています。これらは jackson-databind 自体が動作するために必要な依存関係です この構造は、JSON 操作に Jackson を使用する Java アプリケーションの例です。Jackson ライブラリは、パフォーマンスの最適化やセキュリティ修正など、さまざまな問題に対応するために頻繁に更新されるため、開発者はアプリケーションを最新かつ安全な状態に保つうえで、これらのネストされた依存関係を把握しておく必要があります。これらのコンポーネントがアプリケーション内のどこにネストされているかを詳しく把握していれば、保守やアップグレードが容易になります。 例 3: Hibernate の依存関係 MyERPSystem/ |-- myerpsystem-3.1.jar | |-- hibernate-core-5.4.18.Final.jar | | |-- hibernate-validator-6.1.5.Final.jar | | | |-- ... | | |-- hibernate-entitymanager-5.4.18.Final.jar | | | |-- ... この構造には、以下のファイルと依存関係が含まれています。 myerpsystem-3.1.jar はアプリケーションのプライマリ JAR ファイルです myerpsystem-3.1.jar の中では、 hibernate-core-5.4.18.Final.jar がオブジェクトリレーショナルマッピング (ORM) 機能の依存関係として機能します hibernate-validator-6.1.5.Final.jar や hibernate-entitymanager-5.4.18.Final.jar などのネストされた依存関係は、Hibernate が提供するバリデーションおよびエンティティ管理機能に不可欠です MyERPSystem が Hibernate のバージョンと別のライブラリとの不一致 (例えば、新しいバージョンの Spring が異なるバージョンの Hibernate を想定している場合など) により運用上の問題に直面した場合、開発者は Amazon Inspector SBOM Generator が提供する詳細な情報を活用できます。このツールを使用すれば、Hibernate とそのネストされた依存関係の正確なバージョンを迅速に特定でき、互換性の問題をより早く解決できます。 JAR ファイル内で使用されている依存関係を理解することが重要な理由を、いくつか挙げます。 セキュリティ : ネストされた依存関係が古い、または既知のセキュリティ問題を抱えている場合、脆弱性をもたらす可能性があります。代表的な例は、 2021 年後半に発見された Log4J の脆弱性 (CVE-2021-44228) です。Log4J は広く使用されているロギングフレームワークであり、脅威アクターがこの欠陥をリモートから悪用でき、深刻な結果を招く恐れがあったため、この脆弱性は重大なものとなりました。さらに問題を悪化させたのは、Log4J がさまざまな Java アプリケーションにネストされた依存関係として存在することが多く ( 例 1 を参照)、組織が Log4J を含む箇所をすべて洗い出してパッチを適用するのが困難だったことです コンプライアンス : 多くの組織は、ライセンス、規制、またはセキュリティ上の理由から、サードパーティライブラリに関する厳格なポリシーを順守する必要があります。依存関係、特に Log4J のケースのようなネストされた依存関係を把握していないと、これらのポリシーに違反する可能性があります 保守性 : 適切なタイミングで更新や置き換えを行うためには、プロジェクト内の依存関係を常に把握しておくことが不可欠です。Jackson ライブラリ ( 例 2 ) は、新機能の導入やセキュリティ脆弱性の修正のために頻繁に更新されます。特にライブラリがネストされた依存関係である場合、これらの更新の管理は複雑になる可能性があります トラブルシューティング : 依存関係の特定は、運用上の問題を迅速に解決するうえで重要な役割を果たします。その一例が、バージョンの不一致に起因する、アプリケーション内の Hibernate と他の Java ライブラリやフレームワーク間の互換性問題への対処です ( 例 3 )。このような問題は、予期しない例外やパフォーマンスの低下として現れることが多いため、関係するライブラリを正確に把握する必要があります これらの例からわかるように、目の前の脅威から保護し、アプリケーションの長期的な健全性とコンプライアンスを確保するには、JAR ファイルの内容を詳細に把握できる状態にしておく必要があります。 既存ツールの限界 Java アプリケーションのネストされた依存関係を分析する際の主な課題の 1 つは、既存のツールではこれらの依存関係の正確な場所を効率的に絞り込めないことです。この問題は、 mvn dependency:tree や OWASP Dependency-Check をはじめとする同様の依存関係分析ソリューションで特に顕著です。 Java アプリケーションのネストされた依存関係を分析するツールは存在するものの、いくつかの重要な領域で不十分なことがよくあります。以下に、これらのツールの一般的な限界を挙げます。 依存関係ツリーの深さの不足 : 既存のツールはプロジェクトの依存関係を階層的に表示しますが、多くの場合、ネストされた依存関係、特に他の JAR ファイル内に埋め込まれているものを明らかにするほど深くは掘り下げられません。ネストされた依存関係はライブラリ内に再パッケージ化されており、標準の依存関係ツリーではすぐには見えません 具体的な場所情報の欠如 : これらのツールは通常、JAR ファイル内のネストされた依存関係の正確な場所を特定するために必要な粒度の情報を提供しません。大規模で複雑な Java アプリケーションでは、特定の依存関係、特に深く埋め込まれているものを特定して対処するのが難しい場合があります 大規模プロジェクトにおける複雑さ : 依存関係が広範かつ複雑に絡み合ったプロジェクトでは、これらのツールは明確で実用的な洞察を提供するのに苦労することがあります。出力が複雑で扱いにくくなり、重要な依存関係を特定するための明確な道筋が得られないことがあります Amazon Inspector SBOM Generator によるツールの限界への対処 Amazon Inspector SBOM Generator (Sbomgen) は、Java アプリケーションのネストされた依存関係の特定において大きな進歩をもたらします。依存関係の監視という概念自体はソフトウェア開発において十分確立されていますが、AWS はソフトウェア構成の複雑さに対する可視性を高めるためにこのツールを設計しました。コンテナイメージのソフトウェア部品表 (SBOM) を生成することで、Sbomgen は、従来のツールでは見落とされがちな隠れたネストされた依存関係を含む、システムにインストールされたソフトウェアの詳細なインベントリを提供します。この機能は既存のツールキットを補完し、アプリケーションの依存関係構造をより詳細かつ実用的に理解できるようにします。 Sbomgen は、インストールされたパッケージに関する情報を含むファイルをスキャンすることで動作します。該当するファイルが見つかると、パッケージ名、バージョン、その他のメタデータなどの重要なデータを抽出します。その後、このメタデータを CycloneDX SBOM に変換し、依存関係の構造化された詳細なビューを提供します。 Sbomgen のインストール方法については、Amazon Inspector ユーザーガイドの「 Sbomgen のインストール 」を参照してください。 訳注: 本記事公開時点の Amazon Inspector SBOM Generator は v1.0 系ですが、2026 年 8 月時点の最新は v1.13 系です。対応エコシステムは Go / Rust バイナリや Windows アプリケーションなどに大幅に拡大しているほか、v1.13 では Lua で独自のパッケージコレクタを追加できるプラグインシステムが導入されました。詳細は “ Amazon Inspector SBOM Generator をプラグインで拡張 ” を参照してください。本記事のコマンドは翻訳時点の最新バージョン(v1.13 系)で動作することを確認していますが、最新の構文は Amazon Inspector SBOM Generator のドキュメント を参照してください。 Sbomgen の主要な機能の 1 つは、各依存関係への明示的なパスを提供できることです。 例えば、コンパイル済みの JAR アプリケーション MyWebApp-0.0.1-SNAPSHOT.jar がある場合、Sbomgen で以下の CLI コマンドを実行できます。 ./inspector-sbomgen localhost --path /path/to/MyWebApp-0.0.1-SNAPSHOT.jar --scanners java-jar 出力は以下のようになります。 { "bom-ref": "comp-11", "type": "library", "name": "org.apache.logging.log4j/log4j-to-slf4j", "version": "2.19.0", "hashes": [ { "alg": "SHA-1", "content": "30f4812e43172ecca5041da2cb6b965cc4777c19" } ], "purl": "pkg:maven/org.apache.logging.log4j/log4j-to-slf4j@2.19.0", "properties": [ ... { "name": "amazon:inspector:sbom_generator:source_path", "value": "/tmp/MyWebApp-0.0.1-SNAPSHOT.jar/BOOT-INF/lib/spring-boot-3.0.2.jar/BOOT-INF/lib/spring-boot-autoconfigure-3.0.2.jar/BOOT-INF/lib/logback-classic-1.4.5.jar/BOOT-INF/lib/logback-core-1.4.5.jar/BOOT-INF/lib/log4j-to-slf4j-2.19.0.jar/META-INF/maven/org.apache.logging.log4j/log4j-to-slf4j/pom.properties" } ] } この出力では、 amazon:inspector:sbom_generator:source_path プロパティが特に重要です。このプロパティは、アプリケーションの構造内における特定の依存関係 (この場合は log4j-to-slf4j ) の場所への明確で完全なパスを提供します。このレベルの詳細な情報は、以下のような理由から極めて重要です。 正確な場所の特定 : 各依存関係の正確な場所を迅速かつ正確に特定できます。これは、通常は見つけにくいネストされた依存関係の場合に特に役立ちます 効果的なリスク管理 : 依存関係の正確なパスがわかると、これらの依存関係に関連するセキュリティリスクをより効率的に評価し、対処できます 時間とリソースの効率化 : 依存関係を手動で追跡・分析するために必要な時間とリソースを削減し、脆弱性管理プロセスを効率化します 可視性と透明性の向上 : アプリケーションの依存関係構造をより明確に理解できるようになり、全体的な管理と保守の改善に貢献します 包括的なパッケージ情報 : Sbomgen が提供する名前、バージョン、ハッシュ、 パッケージ URL を含む詳細なパッケージ情報により、各依存関係の詳細を十分に理解でき、正確な脆弱性の追跡とソフトウェアの整合性検証に役立ちます 脆弱な依存関係への対処 Java JAR ファイル内のネストされた依存関係を特定したら、次はそれらの依存関係が古くなっていないか、脆弱性がないかを検証する必要があります。Amazon Inspector は以下を行うことで、この検証を支援します。 発見された依存関係を既知の脆弱性のデータベースと比較する 脆弱な可能性のある依存関係のリストを、関連する CVE の詳細情報とともに提供する 依存関係をより新しく安全なバージョンに更新するなど、リスクを緩和する方法についての推奨事項を提供する Amazon Inspector をソフトウェア開発ライフサイクルに統合することで、Java アプリケーション内の脆弱なネストされた依存関係を継続的に監視し、アプリケーションの安全性とコンプライアンスの維持に必要な措置を講じることができます。 まとめ Java アプリケーションの安全性を高めるには、ネストされた依存関係の管理が欠かせません。Amazon Inspector は、JAR ファイル内の脆弱な可能性のある依存関係を自動的かつ効率的に検出し、対処する方法を提供します。Amazon Inspector の機能を活用することで、Java アプリケーションのセキュリティポスチャを改善し、ベストプラクティスに準拠させることができます。   本記事に関するご質問がある場合は、 AWS サポートにお問い合わせください 。 Chi Tran Chi はセキュリティリサーチャーとして、AWS のサービス、アプリケーション、ウェブサイトが最高のセキュリティ基準で設計・実装されるよう支援しています。Amazon Inspector の分野専門家 (SME) として、高度な問題やユースケースを抱えるお客様を熱心にサポートしています。Chi が情熱を注いでいるのは情報セキュリティです。具体的には、API セキュリティ、ペネトレーションテスト (OSCP、OSCE、OSWE、GPEN の認定を保持)、アプリケーションセキュリティ、クラウドセキュリティです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は「 GPT‑5.6 update: lower credit multipliers for Terra and Luna 」を翻訳したものです。 OpenAI が GPT‑5.6 Terra および Luna の価格を引き下げたため、その値下げ分を Kiro のお客様に還元します。OpenAI の新価格を反映した最新のクレジット倍率が、現在すでに適用されています。 GPT‑5.6 Luna は 0.6x から 0.1x に引き下げ GPT‑5.6 Terra は 1.2x から 1.0x に引き下げ GPT‑5.6 Sol は 2.4x のまま変更なし GPT‑5.6 Sol、Terra、Luna は、Kiro Pro、Pro+、Pro Max、Power の お客様向けに実験的サポート として提供されています。Kiro における GPT‑5.6 の詳細については、 最初のリリース記事 をご覧ください。

メインフレーム基幹系システムの移行を真剣にご検討中のお客様をお迎えし、「AWS Mainframe Modernization Day Tokyo 2026」を開催します。メインフレームの価値は伝統的に RAS (Reliability, Availability, Serviceability) に象徴されます。本イベントでは、重要なシステムの安定稼働のために AWS が提供しているサービスや機能を各エリアの専門家が説明し、基幹システムを AWS クラウド上で稼働する際の懸念を解消します。 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ、セキュリティ、レジリエンシー、運用の高度化(オブザーバビリティと自動化)など、メインフレームからの移行後の安定稼働において最も重要な技術領域を、初めての方にもわかりやすく網羅的にカバーします。さらに、既に AWS 移行を推進されている先進的なお客様の生の声をお届けし、社内コンセンサス確立のための具体的なヒントを提供します。参加者同士の交流会では、AWS のスペシャリストやメインフレーム専門チームメンバーも交え、同じ課題に直面する企業間での直接的な情報交換の場を設けます。 背景と位置付け お客様が直面している課題 メインフレームを運用する多くのお客様は、安定稼働の継続、体制の転換、ノウハウの継承という構造的課題に直面していると考えられます。 ミッションクリティカルワークロードはメインフレーム上で過去数十年にわたり安定稼働してきました。それをクラウド移行後も同様に安定稼働することは、最も重要な移行要件の一つと考えられます。メインフレーム上の大規模なバッチワークロードはクラウド上でも同等の性能を示す必要があります。メインフレームは単一筐体内の構成要素の冗長化により高可用性を実現していますが、同等の安定稼働をクラウドでも実現できなくてはなりません。しかし、現在メインフレームのクラウド移行を検討しているお客様は、過去にその実績が少なく、経験者が社内に居ないケースが多くあります。そのため、移行後の安定稼働とセキュリティに確証を持てず、慎重になりがちです。関係者からクラウド移行の支持を獲得し、コンセンサスを確立するのは容易ではありません。 また、メインフレーム担当者は、自分達がリタイアした後も基幹系システムの安定稼働を継続できるよう、お客様社内で上層部から指示されているケースもあります。しかし、メインフレーム人材の減少により運用体制の維持が困難になりつつあり、希少スキルを持つ人材の育成や調達は容易ではありません。メインフレーム人材の育成は若手社員の動機付けが難しく、単純なクラウド移行は ROI が説明できず、板挟みになりがちです。メインフレーム担当者が持つ業務知識や、安定稼働のためのインフラの知識、運用ノウハウ等は、テクノロジーが変わっても有用なはずです。このままだと、経験を通じて得られた貴重なナレッジが引継ぎ先も無いまま喪失する危機に直面していると思われます。 本イベントの意義 本イベントは大規模開催ではなく、通常のセッションや打ち合わせでは得られない情報を、各領域の専門家から直接聞くことができる貴重な機会です。 特に以下のような方々に最適なイベントとなっており、日頃クラウドに接点のないメインフレーム担当組織からの参加を期待しています。 メインフレーム基幹系システムの AWS クラウド移行を具体的に計画されている方 専任のプロジェクトチームを立ち上げ、次期システム更改等のタイミングまでに AWS 移行を実施したい方 メインフレームの高可用性・高信頼性と同等の安定稼働を AWS クラウド上で実現する方法を知りたい方 AWS 移行に向けた予算申請や稟議を進めるにあたり、技術的な裏付けを得たい方 先進企業がどのように社内のステークホルダーの理解と賛同を得たか、具体的なアプローチを学びたい方 本イベントに参加することで、クラウド移行に漠然とした不安を感じていた方にも、AWS クラウド移行を前向きに考える機会にして頂ければと思います。 対象 IBM z/OS および富士通 GS21 OSIV/MSP で稼働する基幹系システムを担当する組織のリーダー的な役割の方を対象としています。基幹系システムの安定稼働を実現する AWS の技術的価値、先進的なお客様の移行経験や社内合意形成の工夫に焦点を当てますので、メインフレーム基幹系システムの AWS 移行を計画的に実施したい方にご参加頂きたいイベントです。 なお、本イベントはメインフレームの知識を前提とするセッションで構成されています。 イベントの構成 本イベントは 3 部構成で実施します。Part 1 の AWS セッションでは、メインフレームの RAS とは別のアプローチで基幹系システムの安定稼働を実現する AWS のテクノロジーや機能を各エリアの専門家が提示します。Part 2 のお客様セッションでは、先進的なお客様による移行経験を共有します。Part 3 の交流会では、参加者間の直接対話を通じて課題と解決方法を共有します。 Part 1: AWS セッション メインフレームの価値は伝統的に RAS (Reliability, Availability, Serviceability) に象徴されます。Reliability はハードウェアの自己診断・自己回復能力とソフトウェアの信頼性を、Availability は障害コンポーネントからの無停止回復を、Serviceability は障害原因の特定と影響を最小化した交換を意味します。 これと異なる方法で基幹系システムの安定稼働を実現する AWS のアプローチを、以下の 4 セッションで紹介します。 (1) 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ (2) セキュリティ (3) レジリエンシー (4) 運用の高度化 本セッションを通じて、メインフレーム利用者が基幹系システムを AWS クラウド上で稼働する際に感じる懸念を解消したいと考えます。 加えて、クラウド移行には、スケーラビリティ (需要に応じたリソースの弾力的な拡張/縮小)、コスト最適化 (従量課金モデルによる固定費からの脱却)、ベストプラクティスの豊富さ (開発および運用における膨大なナレッジとツール群)、人材の調達容易性(クラウドスキル人材市場の厚み)といった、積極的なメリットがあることは言うまでもありません。 Part 2: お客様セッション 基幹系システムの AWS 移行を既に実施しつつある先進的なお客様に登壇いただくべく、調整中です。そして、「Why (何故クラウド移行を決断したか)」と「How (どのようにして社内外の理解と賛同を得たか)」を語っていただきたいと考えています。 Part 3: お客様同士の交流会 同じ課題に直面するお客様同士で会話し、直接的な情報交換の場を設けます。 AWS セッションに登壇したスペシャリストや、メインフレーム専門チームメンバーも交え、ディープな Q&A を通じて日頃の疑問を投げ掛けて頂き、より実践的な情報を得ることができます。 イベント概要 開催日時 2026 年 9 月 17 日(木) 13:30 – 18:00 (13:00 受付開始) 開催場所 麻布台ヒルズ (東京) AWS オフィス 〒106-0041 東京都港区麻布台 1 丁目 3-1 麻布台ヒルズ 森 JP タワー 東京メトロ日比谷線 神谷町駅より徒歩約 9 分、東京メトロ南北線 六本木一丁目駅より徒歩約 7 分 ※入退館等詳細は別途ご連絡いたします 定員 15 社 (1 社あたり 2〜3 名) 可能であれば、アプリケーション担当者と基盤担当者のペアでお越しください 同一グループ企業内の事業会社および子会社は合わせて 1 社として扱わせて頂きます 前提となる知識/経験 メインフレーム (IBM z/OS または富士通 GS21 OSIV/MSP) 上の基幹系システムの開発や保守運用経験があることを前提に、AWSクラウドのインフラストラクチャ、セキュリティ、レジリエンシー、運用に関連したセッションを実施します。AWSの事前知識は不要です。 参加費 無料 参加申込方法 参加希望される方は、 イベント情報 のページの「今すぐ登録する」からお申込下さい。 なお、参加申込される方の代表者は、 事前アンケート のページで、基幹システムの概要や移行予定時期 (目標) 等についての情報提供をお願い致します。 ご留意事項 会場の収容人数に限りがあるため、お申込みいただいてもご参加をお受けできない場合がございます。あらかじめご了承ください。 募集期間: 2026 年 8 月 21 日 (金) まで 参加可否のご連絡: 2026 年 8 月 31 日 (月) まで プログラム内容 時間 内容 13:00 – 13:30 受付 13:30 – 13:40 オープニング・ご挨拶 Part 1: AWS セッション 13:40 – 14:20 (1) 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ 14:20 – 14:35 休憩 14:35 – 14:55 (2) セキュリティ 14:55 – 15:15 (3) レジリエンシー 15:15 – 15:35 (4) 運用の高度化 15:35 – 15:50 総括 15:50 – 16:05 休憩 Part 2: お客様セッション 16:05 – 16:45 お客様によるプレゼンテーションと Q&A (講師調整中) 16:45 – 17:00 オフィスツアー Part 3: 交流会 17:00 – 18:00 お客様同士の交流会

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 みなさんは AWS Builder Center を活用されていますか? AWS Builder Center は、世界中のビルダーが書いた記事や動画などのコンテンツ、コミュニティ、学習リソースがひとつに集まったプラットフォームです。トピックごとにコンテンツがまとまっているのが便利で、例えば agent-to-agent のトピックページ では、AI エージェント同士を連携させる A2A に関する記事を一覧で読むことができます。気になる技術分野のトピックをフォローしておくと、最新のノウハウを効率よくキャッチアップできるので、ぜひ覗いてみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月20日週の主要なアップデート 7/20(月) KNFSD File Cache のプレビュー提供を開始 AWS は NFS キャッシュソリューション KNFSD File Cache のプレビュー提供を開始しました。Apache-2.0 ライセンスのオープンソースで、オンプレミスや別リージョン、他クラウドの NFS サーバーをマウントし、AWS 内の NFS クライアントに再エクスポートします。頻繁に読み取られるデータをメモリとローカル NVMe にキャッシュし、高レイテンシー回線を越えるアクセスを 1 回に抑えて VPC 内速度で配信します。Linux カーネル標準の nfs-kernel-server と FS-Cache を利用し、Packer で AMI を構築後 Terraform でクラスターをデプロイします。全 AWS リージョンで利用でき、ライセンス費用はかからず消費した AWS リソースにのみ課金されます。 Amazon CloudWatch が Coding Agent Insights を発表 Amazon CloudWatch は、AI コーディングエージェントの利用状況を可視化する Coding Agent Insights を発表しました。Claude Code、OpenAI Codex、GitHub Copilot の OpenTelemetry (OTel) メトリクスを CloudWatch に取り込み、組織/部門/チーム/ユーザー単位で利用状況やコストを確認できます。Claude apps gateway for AWS と連携すると、追加の計装なしで Claude Code のテレメトリを収集できます。ダッシュボードは CloudWatch コンソールの GenAI Observability 配下に自動で表示され、料金は標準の CloudWatch OTel メトリクス取り込み料金が適用されます。 Amazon WorkSpaces Applications がマルチセッションフリートで Microsoft OneDrive と Google Drive に対応 Amazon WorkSpaces Applications のマルチセッションフリートで、永続ストレージオプションとして Microsoft OneDrive for Business と Google Drive が利用できるようになりました。従来はマルチセッションフリートで Amazon S3 バックエンドの home folder のみが選択肢でしたが、今回のアップデートでユーザーは自身の OneDrive / Google Drive アカウントを接続し、ストリーミングセッション内でクラウドファイルを直接参照・保存・同期できます。マルチセッションフリートは 1 つのフリートインスタンスを複数ユーザーで共有してセッション密度を高める構成で、コストを抑えながらクラウドストレージ体験を提供できます。機能の追加料金はなく、標準の WorkSpaces Applications 利用料金のみが適用されます。有効化には 2026 年 6 月 29 日以降にリリースされたエージェントを含むイメージが必要です。 Amazon Connect のエージェント型音声機能を対応言語と発話制御の拡張により強化 Amazon Connect は、agentic voice (エージェント型音声) 機能で 50 以上のロケール (言語) と 100 を超える音声オプションに対応しました。Spanish、French、Italian、Japanese、Korean、Portuguese、Thai などが含まれます。発話のペーシング、話者交替 (turn-taking) の精度向上に加え、速度/音量/感情を調整できる発話制御 (speech controls) を利用できます。この機能は Amazon Connect Customer のデフォルト音声プロバイダーとして提供され、米国/欧州/アジアパシフィックの 9 リージョンで利用できます。 AWS CloudTrail で ID 別にネットワークアクティビティイベントを選択的にログ記録 AWS は CloudTrail のネットワークアクティビティイベント (VPC エンドポイント向け) に対して、IAM ユーザー ID に基づくイベントフィルタリングを追加しました。API を呼び出した ID を条件にして、ログを記録するイベントを絞り込めます。例えば信頼済み IAM ロール以外からの VpceAccessDenied イベントだけを記録する、といった設定ができます。これにより、承認済みプリンシパルからの正常なトラフィックを除外し、ログ量とコストを抑えられます。この機能は AWS Management Console、AWS CLI、AWS SDK から利用でき、CloudTrail ネットワークアクティビティイベントが対応する全リージョンで使えます。 7/21(火) Amazon RDS for SQL Server が Microsoft SQL Server 2025 に対応 Amazon RDS for SQL Server が Microsoft SQL Server 2025 (Enterprise、Standard、Developer の各エディション) に対応しました。RDS で提供される最新マイナーバージョンは 17.0.4045.5 (CU5) です。SQL Server 2025 は T-SQL から外部 REST エンドポイントを呼び出す機能をデータベースエンジンに組み込んでおり、Amazon Bedrock や Amazon SageMaker、Amazon S3、AWS Lambda といった AWS サービスとアプリケーションを再設計せずに連携できます。また native vector データ型による埋め込みベクトルの格納/検索に対応し、Standard Edition は最大 32 コア/256 GB バッファプールへ拡張され Resource Governor も利用できるようになりました。既存の RDS インスタンスは DB エンジンバージョンの変更でアップグレードでき、オンプレミスからの移行も可能です。 Amazon ECS が Action Logs を提供開始 (デプロイとオーケストレーションの可視化) Amazon ECS は、サービスデプロイと ECS Managed Daemon 更新の際に ECS がユーザーに代わって実行する操作を、タイムスタンプ付きで記録する Action Logs を提供開始しました。従来は開始状態と終了状態しか観測できなかった中間操作 (コンテナイメージのダウンロード、ロードバランサー登録、セキュリティグループ設定など) を確認できるようになりました。ログはクラスターレベルで opt-in し、CloudWatch Logs、Amazon S3、Amazon Data Firehose のいずれかへ配信できます。Amazon Q が Action Logs と連携し、circuit breaker によるロールバックなどの原因分析をコンソール内で提供します。AWS GovCloud (US) を含む全 AWS リージョンで利用できます。 Amazon SES が料金プランを導入 Amazon SES は、個別のアドオンとして販売されていたメール到達性関連の機能を 3 段階の料金プラン (Essentials、Pro、Enterprise) にまとめて提供する仕組みを導入しました。各プランは下位プランの機能をすべて含み、上位ほど機能が増えます。従来の従量課金と比べて割引が適用されます。プランはアカウント単位かつ AWS リージョン単位で選択し、中東 (UAE) および中東 (バーレーン) を除く Amazon SES 提供リージョンで利用できます。新規アカウントは 2026 年 7 月 21 日以降 Essentials から開始します。 7/22(水) Amazon EKS の EKS Auto Mode と Karpenter で EFA と Placement Group をサポート Amazon EKS の EKS Auto Mode とオープンソースの Karpenter で、ノードプールの EC2 Placement Group (配置グループ) と Elastic Fabric Adapter (EFA) のネットワークインターフェース設定に対応しました。NodeClass または EC2NodeClass の定義から、EFA-only インターフェースの構成と、cluster / spread / partition の 3 種類の配置戦略を指定できます。EFA-only インターフェースは IP アドレスを消費しないため、VPC 内の IP 使用量を抑えながら EFA の帯域を利用できます。分散学習や分散推論のスループット最適化と、本番サービスの障害範囲 (blast radius) 縮小の両方に対応します。この機能は Amazon EKS が利用可能なすべての AWS リージョンで使えます。 Network Load Balancer がカスタムトラフィックルーティング向けのリスナールールに対応 Network Load Balancer (NLB) が、送信元 IP アドレスタイプ (IPv4 / IPv6) に基づいて接続を別々のターゲットグループへ振り分けるリスナールールに対応しました。1 台のデュアルスタック NLB で IPv6 クライアントの通信を IPv6 ターゲットへ、IPv4 クライアントの通信を IPv4 ターゲットへ送り、両方のアドレスファミリでクライアント元 IP をエンドツーエンドで保持できます。従来はロードバランサーを 2 台に分ける方法か、プロトコル変換で元 IP を失う方法のいずれかを選ぶ必要がありましたが、この機能でその制約がなくなりました。既存のデュアルスタック NLB に作り直しなしでルールを追加できます。全 AWS 商用リージョンと AWS GovCloud (US) リージョンで追加料金なしで利用できます。 7/23(木) Amazon CloudWatch Logs が Application Load Balancer ログに対応 Amazon CloudWatch Logs が Application Load Balancer (ALB) のログを vended logs として受け取れるようになりました。ALB のアクセスログ、接続 (connection) ログ、ヘルスチェックログの 3 種類を CloudWatch に直接配信し、Logs Insights クエリ、メトリクスフィルタ、Live Tail で分析できます。配信先は CloudWatch Logs のほか Amazon Data Firehose と Amazon S3 (Apache Parquet 形式対応) を選択できます。CloudWatch telemetry enablement rules を使うと、既存および新規の ALB に対してログ設定を自動適用できます。ALB と CloudWatch が利用可能なすべての AWS 商用および GovCloud リージョンで利用できます。 7/24(金) aws-bench (AWS 上の AI エージェント向けオープンソースベンチマーク) を発表 AWS は 2026 年、AI エージェントが実際の AWS タスクをどれだけ正確かつ効率的に完了できるかを測定するオープンソースベンチマーク aws-bench をリサーチプレビューとして公開しました。実際の AWS 環境を都度払い出し、エージェントに調査・トラブルシューティング・インフラ作成のタスクを実行させて採点します。テストケースは自然言語クエリ、クラウドリソースの状態、正解データの 3 点で構成され、任意のエージェントやモデルを一貫した基準で比較できます。テスト環境の構築・実行・採点・リセットを行う CLI が同梱され、GitHub (Apache License 2.0) で入手できます。 AWS で Claude Opus 5 が利用可能に AWS は 2026 年 7 月 23 日に Anthropic の最新モデル Claude Opus 5 の提供を開始しました。コーディング、長時間稼働エージェント、文書量の多い業務での推論精度が向上しています。提供経路は Amazon Bedrock と Claude Platform on AWS の 2 つで、Bedrock 版はゼロデータ保持 (ZDR) がデフォルトで有効です。コンテキストウィンドウは 1M トークン、最大出力は 128K トークンで、東京リージョン (ap-northeast-1) からは Global クロスリージョン推論経由で利用できます。入力 $5 / 出力 $25 (100 万トークンあたり) の価格で、前世代 Opus 4.8 と同水準の単価に据え置かれています。 Amazon EC2 Dedicated Hosts がセルフマネージドライセンスなしでホストリソースグループに対応 EC2 Dedicated Hosts のホストリソースグループ (Host Resource Groups, HRG) を、これまで必須だったセルフマネージドライセンス (Self-Managed Licenses, SML) の作成と AMI 関連付けなしで作成できるようになりました。ハードウェアレベルの分離だけを目的とする顧客や EC2 Mac インスタンスの顧客は、AWS License Manager でのライセンス設定手順を省略できます。BYOL (Bring Your Own License) ワークロードでは従来どおり SML 付きの HRG も作成でき、起動できる AMI の制限とホスト単位のライセンス消費追跡を継続できます。HRG がサポートされる全ての AWS リージョンで利用できます。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

本ブログは 2026 年 7 月 29 日に公開された AWS Blog「 Amazon identifies North Korean hacker group behind open-source supply chain attacks 」を翻訳したものです。 Amazon は、北朝鮮 (朝鮮民主主義人民共和国、DPRK) に関連する脅威アクターが、世界中の企業がアプリケーション開発に利用する共有ビルディングブロックであるオープンソースソフトウェアライブラリを標的にしている実態について、新たな調査結果を公開します。Amazon Threat Intelligence は、最近発生した複数の人気 Node Package Manager (NPM) ライブラリの侵害が、同一の北朝鮮に関連する脅威アクターによるものであることを特定しました。この関連性はこれまで公に報告されていませんでした。また、この分析では、生成 AI が悪意のあるソフトウェアパッケージの姿をどのように変化させているか、そして脅威アクターが AI ベースのコードシステムをどのように探り始めているかについても説明します。この調査結果を公開することで、オープンソースコミュニティやセキュリティチームが、こうした事象をより的確に検知し、対処できるよう支援します。 これらの動きは、XZ Utils バックドア事件から 2 年後に発生しています。この事件は、忍耐強い攻撃者がボランティアのメンテナーの信頼や時間的な制約を悪用することで、重要なオープンソースソフトウェアをどのように侵害できるかを示しました。オープンソースソフトウェアは、オペレーティングシステム、ウェブサーバー、暗号化ライブラリ、そして企業が日常的に利用しているアプリケーションフレームワークなど、インターネットインフラの多くを支えています。攻撃者が広く使われているオープンソースパッケージを侵害すると、そのパッケージに依存するすべての組織が影響を受ける可能性があります。それ以降、Amazon Threat Intelligence は、北朝鮮に関連する脅威アクターやサイバー犯罪グループが大きく関与する形で、ソフトウェアサプライチェーン攻撃の件数と巧妙さが増していることを確認しています。 この記事では、Amazon Threat Intelligence と Amazon Inspector チームが、人気の NPM パッケージを狙った最近の攻撃活動について新たな詳細を共有します。これには、axios、debug、chalk、typo-crypto の各ライブラリの侵害が、同一の北朝鮮に関連する脅威アクターによって行われたという証拠が含まれます。この脅威アクターは、セキュリティコミュニティでは SAPPHIRE SLEET、STARDUST CHOLLIMA、BlueNoroff、CageyChameleon、Alluring Pisces として追跡されています。また、オープンソースリポジトリを侵害する手法がどのように進化しているか、そしてこうした変化がオープンソースソフトウェアに依存する組織にとってなぜ重要なのか、さらに、お客様がこれらの脅威を検知して対応できるよう、 Amazon Web Services (AWS) がどのような取り組みを行っているかについても説明します。 複数の NPM 侵害の背後にいる単一の北朝鮮関連グループ 2025 年 3 月、北朝鮮に関連する脅威アクターは typo-crypto パッケージを侵害しました。2025 年 9 月には、同じ脅威アクターが debug と chalk の NPM パッケージを侵害しました。2026 年 3 月には、同じ手口が axios パッケージの侵害でも確認されました。axios は、週間ダウンロード数が 1 億回を超える、最も広く使われている JavaScript ライブラリの 1 つです。いずれのケースでも、脅威アクターはパッケージの信頼されたメンテナーに対してソーシャルエンジニアリングを行うことでアクセス権を獲得し、その後、悪意のあるコードを含むソフトウェアアップデートを公開しました。これらのパッケージの最新バージョンを自動的に取得していた組織は、すべて侵害されたアップデートを受け取ったことになります。 axios の侵害については既に公にこの北朝鮮に関連する脅威アクターによるものと特定されていましたが、typo-crypto、debug、chalk の各インシデントについては、これまでこの脅威アクターとの関連が指摘されていませんでした。Amazon Threat Intelligence は、これらのサプライチェーン攻撃活動全体に共通する戦術、技術、手順 (TTP) を特定しました。具体的には、トロイの木馬化された NPM パッケージ、インストール後フック (パッケージのインストール時に自動的に実行されるスクリプト) の利用、そしてコードの再利用です。コマンドアンドコントロール (C2) の痕跡や TTP の分析に基づき、Amazon Threat Intelligence は、これらの攻撃活動が SAPPHIRE SLEET、STARDUST CHOLLIMA、BlueNoroff、CageyChameleon、Alluring Pisces として追跡されている北朝鮮に関連する脅威アクターによるものであると、中程度の確度で評価しています。これらの侵害がこの北朝鮮に関連する脅威アクターと公に結び付けられるのは、今回が初めてです。 Amazon Threat Intelligence は、これを金銭目的の攻撃パターンの一部と評価しています。少数の非常に人気の高いパッケージを侵害することで、このグループは数千もの下流環境に同時にアクセスできる可能性を得ます。金銭目的の脅威アクターにとって、このアプローチは組織を 1 つずつ標的にするよりもはるかに効率的です。 これらのインシデントの累積的な影響は、共有される依存関係を狙うことの効率性を浮き立たせています。Wiz Research の報告によると、debug と chalk のサプライチェーン事件では、わずか 2 時間の間に、クラウド環境の約 10 分の 1 が影響を受けました。 後の攻撃活動の前兆となった小規模な攻撃活動 axios の脅威アクターに関連する痕跡や TTP を定常的に分析していた際、Amazon Threat Intelligence は 2025 年に登録されたドメインとの関連性を発見し、その過去の活動について本格的な調査を行いました。その調査により、同一の北朝鮮に関連する脅威アクターが、2025 年 3 月に typo-crypto の NPM パッケージにトロイの木馬化されたファイルをコミットしていたことが判明しました。この悪意のあるファイル core.js は、typo-crypto リポジトリ内で正規の core-js NPM パッケージになりすましています。 確認されたダウンロード数が限られていることから、Amazon Threat Intelligence は、この攻撃活動が小規模なものであり、2025 年後半から 2026 年にかけて発生した、より大きく注目を集めたサプライチェーン攻撃活動の実験場となった可能性が高いと評価しています。このグループは、公に注目を集めた大規模な攻撃活動よりも 1 年以上前から、サプライチェーンの手法を洗練させていたようです。Amazon Inspector は、より広範なセキュリティコミュニティがこの調査結果を活用できるよう、このマルウェアを Open Source Vulnerabilities (OSV) データベースに報告し、現在は MAL-2026-3400 として追跡されています。 このトロイの木馬化されたファイルは、値 0098273 で始まるハッシュ入力を受け取ると実行されます。トリガーされると、ハードコードされた C2 サーバーから第 2 段階のペイロードをダウンロードし、被害者のオペレーティングシステムに応じて実行します。Windows、macOS、Linux それぞれに合わせた挙動が用意されています。このマルウェアは、ペイロードのローテーションを伴うファイルベースの永続性を実装しており、base64 エンコードされたテキストと 01042025 をキーとする XOR 暗号を組み合わせた多層難読化を使用しています。 関連する侵害の痕跡 (IoC) は以下のとおりです。 ドメイン : npmjs[.]store IP アドレス : 216[.]74[.]123[.]126 NPM パッケージ : typo-crypto (SHA256: 24604384b0e748ada07923630b3d037489e696284a98c4409fb9b6763565571f) トロイの木馬化されたファイル : core.js (SHA256: 2014d09c7ded74d89c885b5f11693865224116f1b25df9330e61fe528f419d73) Amazon Threat Intelligence は、このグループが、その後 axios、debug、chalk に対して行われた、より影響の大きい攻撃活動で使われた手法を、当時実験していたと評価しています。確認されたダウンロード数は少なかったものの、そのトレードクラフト (攻撃者に特徴的な手口や行動様式) は、より人気の高いパッケージへの攻撃で後に確認されたものと一致しています。 攻撃者のトレードクラフトの変化 過去 1 年間、Amazon Threat Intelligence と Amazon Inspector は、脅威アクターがオープンソースライブラリを標的にする際の手法を変化させていることを確認してきました。この変化は重要です。オープンソースパッケージは今なお魅力的な標的であり続けているからです。広く信頼されており、多くの環境で自動的に更新され、新しい貢献者を歓迎するコミュニティによって維持管理されています。以下のパターンは、攻撃者が最新の防御策を回避するために手法を適応させている様子を示しています。いずれの手法も、依存関係が検査される瞬間と、実際に実行される瞬間の間にあるギャップを悪用するように設計されています。1 年前は、悪意のあるパッケージそのものを探すのが主な手法でした。現在では、単体では無害に見えるパッケージ群に分割された、悪意のある挙動を探しています。 パッケージ単位の攻撃から、フラグメント単位の攻撃へ Amazon Inspector は、攻撃者が 1 つの悪意のあるワークフローを、一見ごく普通に見える複数のパッケージに分割するケースが増えていることを確認しています。あるパッケージは、設定ファイルを装った暗号化データを保持します。2 つ目のパッケージは、その復号ロジックを提供します。多くの場合、後から公開される 3 つ目のパッケージが、ペイロードを取得して実行します。 それぞれのパッケージを単独で見ると、無害に見えます。目立つインストールフックもなく、信頼できない入力を評価する明らかな処理もなく、不審に見えるネットワーク呼び出しもありません。悪意のある挙動は、これらのコンポーネントが意図された順序で組み合わせて使われたときにのみ現れます。このアプローチは、実際の依存関係グラフの中でパッケージ同士がどのように相互作用するかを考慮せず、1 つずつパッケージを評価するスキャナーを回避するように設計されています。 信頼の蓄積に投資する、長期にわたる攻撃活動 また、脅威アクターが信頼の蓄積を長期的な視点で捉えている様子も確認しています。明らかに悪意のあるコードを公開してダウンロードを待つのではなく、実際に有用なものを公開し、それを維持管理するのです。こうした攻撃者は、数週間から数か月にわたって、本物のメンテナーのように振る舞います。機能を追加し、バグを修正し、依存するプロジェクトを増やしていきます。 同じ忍耐強さは、人間側の行動にも表れています。場合によっては、目的は新しいパッケージを立ち上げることそのものではなく、既存プロジェクトの貢献者になることです。これは、XZ Utils バックドアから debug、chalk、axios のメンテナー侵害まで一貫して見られる流れです。いずれのケースでも、攻撃者は正当性を、アクセス権が最大になる瞬間に一度だけ使う資産として扱っていました。 パッケージとその挙動の分離 最近の多くのケースでは、公開されているレジストリ上ではパッケージがクリーンに見えても、実際には危険な場合があります。これは、パッケージの実際の挙動が、攻撃者が別の場所で管理しているリソースに依存しているためです。これには、実行時に外部リポジトリから取得される guard や license スクリプト、特定の挙動を制御する設定ファイル、起動時に参照されるリモートエンドポイントなどが含まれます。 これらの外部リソースが無害な状態を保っている限り、コードレビューは通過し、自動スキャンもクリーンな結果を返します。しかし、攻撃者がそのコンテンツを切り替えたり、それまでプレースホルダーを返していたエンドポイントを実際に機能させたりすると、新たなパッケージのリリースを行わなくても、既にインストールされているすべてのコピーが一斉に悪意のあるものになる可能性があります。現時点で悪意のある挙動を示していないパッケージは、設計上安全なパッケージと同じではありません。 基本的な難読化から、本格的な暗号技術へ 以前、攻撃者はミニファイや単層の base64 エンコードといった単純な難読化に依存していましたが、現在ではより強力な暗号技術を使う多段階のペイロードが確認されています。例としては、パスフレーズで保護された AES-GCM 暗号化データ、呼び出しごとに異なるキーを使う RC4 形式の文字列配列、base64 の上に重ねられた XOR 暗号、そして次の段階を暗号化されたフィールドとして保持し、メモリ内でのみ復号するネイティブローダーなどが挙げられます。 これらに共通する設計上の選択は、復号キーがパッケージ自体には決して保存されないという点です。復号キーは実行時のコンテキストから導出されたり、実行時にサーバーから取得されたり、ライセンスキーとして提供されたりします。つまり、ソースへの完全なアクセス権を持つアナリストであっても、静的な方法でペイロードを確実に復号することはできません。第 1 段階は単純な復号器に見えますが、悪意のあるコンテンツは、実際のターゲット上で実際のキーを使って実行されるまで暗号文のままです。 サンドボックスでの実行を回避するペイロード 防御側がクラウドサンドボックスでの自動分析をスケールさせるにつれて、攻撃者は自分たちのコードをより環境認識型にしてきました。ペイロードは、実行に先立って、自分が分析対象になっているかどうかを判断します。実際のパッケージインストールライフサイクルを経た場合にのみ実行されるようにしたり、1 回限りしか使えない環境変数を使ったり、本物の開発環境やビルド環境であることを示すシグナルを確認したりする挙動が確認されています。これには、対話型ターミナル、現実的なユーザー名やホスト名、ドメインへの参加状況、妥当なアップタイム、ローカルのファイル履歴、特定のオペレーティングシステム、そして分析用インフラストラクチャと通常のワークロードを区別するのに役立つクラウドメタデータなどが含まれます。 一部の配信サーバーは、クライアントに応じて提供する内容を変えることもあります。一般的なブラウザらしいリクエストには無害なデコイが返され、実際のペイロードは、マルウェアが使う正確なユーザーエージェントに対してのみ配信されます。その結果、クラウドサンドボックスから「安全」という判定が出たとしても、そのパッケージが本当に安全であることよりも、環境がどれだけ「本物らしく」見えるかを示している場合が多いのです。 生成 AI が攻撃と防御の両方を変えている 生成 AI は、攻撃者が作り出せるものと、防御側が頼れるものの両方を変化させています。攻撃者は今や、大規模に新しいコードやコンテンツを生成できます。これまで、多くの悪意のあるパッケージは、不自然な文章、内容の乏しいドキュメント、明らかなコピー & ペースト、サンプル間で再利用される特徴的な関数など、「見た目がおかしい」ことによって検知されてきました。生成 AI は、こうしたシグナルの多くを消し去ってしまいます。 現在、攻撃者は、説得力のあるドキュメント、妥当性のあるコミット履歴、架空のメンテナーの身元情報を伴う、一貫性があり、自然で、コメントが丁寧に付けられた数千行のコードをバックドアの周りに用意できます。それぞれのバリアントを変異させ、名前を変え、再構成し、再暗号化できるため、一致させるための単一の安定したシグネチャは存在しません。パターンベースの検知は、デプロイごとに一点物のように見えるマルウェアに対して、劣勢に立たされています。 AI はまた、新しい初期アクセスの経路も生み出しています。その 1 つが スロップスクワッティング (slopsquatting) です。これは、AI コーディングアシスタントが幻覚として生成した、実在しないパッケージ名を攻撃者があらかじめ登録しておく手法です。開発者や自律型コーディングエージェントが支援を求め、モデルが自信を持って存在しないパッケージを推奨してしまうと、攻撃者はその名前を事前に登録して待つことができます。その推奨に従った次の人物は、タイプミスをしたわけでも悪意のあるサイトを訪れたわけでもないにもかかわらず、マルウェアを受け取ってしまう可能性があります。実質的に、AI がその悪意のある依存関係を代わりに配信してしまったことになるからです。組織が、人によるレビューを限定的にしか行わずに依存関係をインストールするエージェントへと移行するにつれて、この経路は単なる興味深い事例ではなく、大規模に展開可能な配信チャネルとしての性格を強めていくと考えられます。 最も重要な点として、AI は防御の自動化における前提そのものを変えています。攻撃者はもはや、人間の目を欺くためだけにマルウェアを書いているわけではありません。AI レビューシステムが承認してしまうようなマルウェアを書いているのです。組織がコードのレビューやパッケージのトリアージに AI システムを頼るようになるにつれて、その AI システム自体がアタックサーフェスの一部になります。隠された指示によって AI システムに意図しない行動を取らせる手法である間接プロンプトインジェクションが、AI ベースのコードスキャナーを欺くために悪意のあるパッケージに組み込まれるケースが今後増えていくと予想しています。これらの指示は、ソースコードのコメント、README ファイル、docstring、テストフィクスチャなどに隠され、自動化システムを説得して、悪意のあるコードを安全と判定させたり、特定のファイルをスキップさせたり、分析中に意図しない動作を実行させたりするように作り込まれます。マルウェアが動作するために必要なコンテンツそのものが、それを検査する機械に向けた、もう 1 つの別のメッセージを同時に運んでいる可能性があるのです。 AWS の対応 Amazon Threat Intelligence と Amazon Inspector は、こうしたソフトウェアサプライチェーンリスクの変化する状況にお客様が適応できるよう、投資を続けています。Amazon は、巧妙な脅威アクターによる脅威を積極的に検知・軽減することで、お客様とインターネット全体のセキュリティ保護に貢献することに、引き続き取り組んでいます。Amazon は、Amazon 内の各チーム、業界パートナー、そしてセキュリティコミュニティと連携し、インテリジェンスを共有し、脅威を軽減する取り組みを続けていきます。この攻撃活動を発見した際、Amazon Threat Intelligence は Amazon Inspector と協力し、この悪意のあるパッケージを追跡してその脅威を軽減し、OSV データベースを通じてコミュニティに情報を共有しました。さらに、確認された侵害の痕跡は Amazon GuardDuty にも共有され、お客様にこの活動について警告できるようにしています。 Amazon Inspector は、これらの知見を活用して検知ロジックを改善し、レジストリ全体でのカバレッジを拡大し、この記事で説明したトレードクラフトの変化を反映するシグナルを優先しています。また、パッケージレジストリや Open Source Security Foundation (OpenSSF) といった業界パートナーとも連携し、調査結果を共有しています。 また、Amazon は、オープンソースのメンテナーがプロジェクトをより安全に保護できるようにするための取り組みにも投資しています。2026 年、AWS は Linux Foundation および他の業界のリーダー企業とともに、AI を悪用したサイバー脅威から重要なオープンソースソフトウェアを守るための協力イニシアチブである Akrites の立ち上げに参加しました。AWS はまた、AI を悪用した攻撃からオープンソースエコシステムを守るため、他の組織とともに 1,250 万ドルを共同で投資しています。これらの取り組みは、より大きな理念を反映しています。オープンソースソフトウェアのセキュリティは共有の責任であり、それを守るためには、それに依存する組織による継続的な投資が必要だという理念です。 Amazon の目標は、お客様の環境がオープンソースコンポーネントにどのように依存しているかを理解できるように支援し、不審な挙動を早期に特定し、ソフトウェアサプライチェーンが侵入経路として利用された際に迅速に対応できるようにすることです。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。この役割において、CJ は Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。セキュリティの利点を「最も抵抗の少ない道」にすることで、Amazon の各事業を支えることを使命としています。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO や、直近では AWS CISO など複数の役職を務めた後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 Amazon 入社以前、CJ は連邦捜査局 (FBI) の Cyber Division で、コンピュータおよびネットワーク侵入に関する技術分析を主導していました。また、空軍特別捜査局 (AFOSI) の特別捜査官としても勤務した経験があります。CJ は、現在のセキュリティ業界の基盤となっているとされる、複数のコンピュータ侵入捜査を主導してきました。 CJ は、コンピュータサイエンスと刑事司法の学位を保持しており、SRO GT America の GT2 クラスで現役のレースカードライバーとしても活動しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 11 日に公開された AWS Blog “ AWS Nitro Isolation Engine: Formally verifying the hypervisor in the AWS Nitro System ” を翻訳したものです。 Ali Saidi は AWS の VP 兼 Distinguished Engineer です 何百万ものお客様が、最も機密性の高いワークロードの保護に AWS Nitro System を利用しており、AWS はお客様のデータを保護するイノベーションにおいて業界をリードしています。お客様のデータの安全性と機密性を守ることは AWS の最優先事項であり、データの分離と保護のための専用ハードウェアとソフトウェアへの投資を継続しています。 2017 年、AWS は Nitro System をリリースしました。これは、ゼロオペレーターアクセス (オペレーターがお客様のデータに一切アクセスできない状態) を前提に設計された、初の主要なクラウドプラットフォームです。Nitro System は、次世代のすべての Amazon EC2 インスタンス の基盤となる専用のハードウェアとソフトウェアであり、仮想化、ストレージ、ネットワーキングの機能を専用ハードウェアと最小限のハイパーバイザーにオフロードします。Nitro System では、最も高い権限を持つ AWS オペレーターであっても、認証と監査が行われる管理用 API を通じてのみシステムとやり取りでき、これらの API からお客様のワークロードにアクセスすることはできません。このアーキテクチャはクラウドセキュリティの業界標準を確立し、NCC Group などの第三者機関が独立した立場でこのアプローチの妥当性を確認してきました。 そして今、AWS はさらに水準を高めます。AWS Nitro System の主な役割の 1 つは、インスタンスを互いに分離し、AWS オペレーターからも分離することです。これは 10 年以上にわたり Nitro System アーキテクチャの基盤となってきました。AWS Nitro Isolation Engine は、AWS re:Invent 2025 で初めて発表され、本日 (2026 年 6 月 11 日) よりすべての Graviton5 ベースのインスタンスで一般提供を開始しました。これは Nitro Hypervisor 内の専用コンポーネントであり、この分離を実施し、それを数学的な厳密さで証明する役割を担います。Nitro Isolation Engine は形式的検証を採用しています。形式的検証とは、ハードウェアやソフトウェアが特定のテストケースだけでなく、あらゆる状況で意図したとおりに動作することを数学的に証明する手法です。この徹底的な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなり、数学的に証明されたクラウドセキュリティの新しい標準を確立しました。 AWS Nitro Isolation Engine Nitro System において、AWS Nitro Hypervisor は、すべての仮想マシンについて、権限のないエンティティがお客様のデータを読み取ったり変更したりできないように設計されています。Nitro Isolation Engine は Nitro Hypervisor の専用コンポーネントであり、これらの仮想マシン間の分離を実施します。仮想マシンのメモリ、CPU レジスタの状態、および I/O デバイスへのすべてのアクセスを、Nitro Hypervisor の他の部分に公開される最小限の API セットを通じて仲介します。Nitro Isolation Engine は、お客様のデータへのアクセスを仲介する唯一のシステムコンポーネントです。Nitro Hypervisor の他のコンポーネントは、この制限されたインターフェイスを通じて動作する必要があり、お客様のワークロードに直接アクセスすることはできません。Nitro Isolation Engine のコードベースは最小限に抑えられているため、人による監査が容易になり、バグが混入し得る範囲が減り、その設計と実装に形式的検証を適用することが現実的になっています。 形式的検証 形式的検証は、数学的証明を用いて、システムの形式的モデルの特性が、あり得るすべてのシステム状態とすべての入力において成立することを示します。これは、あり得る状態と入力のうち (場合によっては大規模な) 一部に対してシステムの動作を確認するテストとは対照的です。形式的検証は、従来のテストよりも正確性についてはるかに強い根拠を提供します。Nitro Isolation Engine の場合、分離特性は、あり得るすべてのシステムの動作にわたって保証されます。テストと検証は相互補完的な関係にあります。検証はテストを補強し、テストはまだ検証されていないシステムの領域をカバーして、システムが意図したとおりに動作しているという経験的な裏付けを与えます。 お客様にとって、分離を実施するコードが形式的に検証されていることは、包括的なテストを超える保証となります。テストは引き続き不可欠であり、AWS はテストにおいても高い基準を維持していますが、テストで確認できるのは特定のシナリオに限られます。形式的検証はこれを補完するものであり、テストでカバーされるシナリオだけでなく、あり得るすべてのシナリオにわたって分離特性が数学的に保証されることを意味します。 形式的に検証された特性 Nitro Isolation Engine の形式的検証により、4 つの主要な特性が確立されます。 1. 機密性と完全性 – Nitro Isolation Engine は、ゲスト仮想マシン (VM) の機密性と完全性を維持します。機密性とは、ゲスト VM のプライベートデータが権限のないエンティティによって読み取られないことを意味し、完全性とは、ゲスト VM のプライベートデータが権限のないエンティティによって変更されないことを意味します。 2. 機能的正確性 – 検証されたすべてのハイパーコールは、仕様で定義された期待される動作と一致します。仕様には各ハイパーコールの事前条件と事後条件が記述されており、証明によって、実装がそれらから決して逸脱しないことが立証されます。 3. ランタイムエラーが発生しないこと – コードがランタイムエラーに遭遇することはなく、実装は仕様どおりに動作します。これらの特性の形式的検証を組み合わせることで、検証の対象となるあらゆる一連のイベントに対して Nitro System が分離を維持することが、数学的に厳密に保証されます。現時点では、この検証は、VM の起動、実行、および終了を担う VM のコアライフサイクルのハイパーコールを対象としています。 4. メモリ安全性 – バッファオーバーフロー、NULL ポインタ逆参照、範囲外アクセスなどのメモリ安全性違反が存在しないことを立証します。すべての検証済みソフトウェアと同様に、Nitro Isolation Engine の証明は、Rust コンパイラやハードウェアの正確性などの前提に基づいています。これらの前提、およびエンジニアリングと検証に対する AWS のアプローチについては、Nitro Isolation Engine のホワイトペーパーで詳しく説明されています。 Rust による実装 Nitro Isolation Engine は Rust で実装されています。Rust は、機密性の高いソフトウェアにおけるセキュリティ脆弱性の根本原因となってきた、よくあるプログラミング上の落とし穴を防ぐように設計されたシステムプログラミング言語です。Nitro Isolation Engine に Rust を採用したことで、複数の種類のバグを設計上まとめて排除しています。Rust が適している理由はその型システムにあります。型システムが厳格な所有権規則を適用するため、形式的検証の一部が容易になり、コンパイル時に第一段階の保証が得られます。 まとめ Nitro Isolation Engine は、お客様のデータの機密性を守るという AWS の継続的なコミットメントを体現するものです。そして、これはまだ出発点にすぎません。AWS は、セキュリティに影響を与える Nitro Isolation Engine のすべての主要コンポーネントに形式的検証を拡張し、新機能が導入されてもそれらの証明を維持し続けます。さらに、Nitro Isolation Engine のソースコードと形式的証明を第三者に提供し、独立した検査およびレビューを受けられるようにする予定です。このレベルの透明性は、クラウドプロバイダーが開かれた姿勢、コード品質、形式的検証をどのように示せるかについて、新しい標準を確立するものと考えています。 AWS Nitro System とコンフィデンシャルコンピューティングの詳細については、以下のリソースをご覧ください。 AWS Nitro Isolation Engine Whitepaper コンフィデンシャルコンピューティング： AWS の視点 (2021) AWS Nitro System のコンフィデンシャルコンピューティングに対する第三者評価の獲得 (2023) AWS Nitro Whitepaper AWS re:Invent 2025 presentation – Introducing Nitro Isolation Engine: Transparency through Mathematics 著者について Ali Saidi Ali は Amazon Web Services (AWS) のバイスプレジデント兼 Distinguished Engineer です。ミシガン大学でコンピュータサイエンスおよび工学の博士号を取得しています。2017 年に AWS に入社して以来、AWS Nitro System、AWS Graviton、および幅広い EC2 インスタンスファミリーのポートフォリオの設計と開発に注力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 10 日に公開された Amazon Science Blog “ EC2’s formally verified “isolation engine” provides mathematical assurance of virtual-machine isolation ” を翻訳したものです。 「分離カーネル (separation kernel)」を Nitro セキュリティシステムの他の部分から切り離し、Rust プログラミング言語のサブセットのみを使用して実装したことで、形式的検証が可能になりました。 本日 (2026 年 6 月 10 日)、AWS は Amazon Elastic Compute Cloud (Amazon EC2) の新しい M9g および M9gd インスタンスの一般提供開始を発表しました。これらは、汎用 CPU の最新世代である Graviton5 を搭載した初のインスタンスタイプです。Graviton5 では、コア数が前世代の 96 から 192 に倍増しています。 また、これらは新しい Nitro Isolation Engine を使用する初のインスタンスタイプでもあります。Nitro Isolation Engine は Nitro Hypervisor のコンポーネントであり、その唯一の役割は仮想マシン (VM) を相互に分離することです。この記事では、推論の各ステップが論理法則に従っているかを機械的にチェックするソフトウェアである Isabelle/HOL (高階論理) 定理証明支援系 (proof assistant) を使って、Nitro Isolation Engine が正しく動作し、VM 間の分離を強制することをどのように証明したかを解説します。Nitro Isolation Engine は、商用クラウド環境にデプロイされた初の形式的検証済みハイパーバイザーの重要なコンポーネントです。 Isabelle/HOL によるモデルと証明は、機械的に検証された 330,000 行の数学的記述から成ります。これは、現実的なオペレーティングシステムの検証が実現可能であることを初めて実証した画期的なプロジェクトであり、私たちの取り組みの着想源ともなった seL4 に匹敵する規模です。ただし seL4 とは異なり、Nitro Isolation Engine は商用クラウド環境向けに設計されており、Graviton5 のユーザーに対して常時有効な機能として本番ハードウェア上で提供されます。 2025 年の Amazon re:Invent カンファレンスで行った 講演 では、形式的検証の方法論を紹介しています。また、 ホワイトペーパー では、検証の範囲や前提条件など、結果の重要な側面をより詳しく解説しています。このブログ記事では、形式的検証の取り組みにおける主要な要素と、それらがどのように組み合わさっているかの概要を、わかりやすくご紹介します。 分離カーネルとは何か 「分離カーネル」という用語は、John Rushby 氏が 1981 年に生み出しました。これは、システムを分離されたコンパートメントに分割する最小限の OS コンポーネントを指します。重要なアイデアは、 ポリシー と メカニズム の分離です。分離カーネルは、何を分離するか、リソースをどう割り当てるか、どの VM をスケジュールするかを決定しません。それらの決定は別の場所で行われます。その代わり、分離の強制だけに専念します。この目的の明確さにより、分離カーネルはフル機能の OS カーネルよりもはるかにシンプルに実装できます。 2017 年の導入以来、Nitro Hypervisor は Amazon EC2 における分離の強制を担ってきましたが、同時にビジネスロジック、デバイスドライバー、AWS 固有の機能も処理しています。この複雑さが、正当性の証明を大幅に難しくしています。さらに、Nitro Hypervisor は当初から検証を想定して設計されたものではありませんでした。 ハイパーバイザーの重要な分離ロジックを Nitro Isolation Engine という最小限のコンポーネントに抽出したことで、検証と監査が可能な小さなサイズになり、分離がどのように強制されているかについて、お客様はかつてないレベルの可視性を得られます。また、Nitro Isolation Engine は、形式的検証との相性がより良い言語である Rust で記述しました。 Nitro Hypervisor は引き続きポリシー (VM の作成、リソース割り当て、移行、スケジューリング) を処理しますが、現在は権限が引き下げられており、ゲストの状態に触れるあらゆる操作を Nitro Isolation Engine に依頼する必要があります。Nitro Isolation Engine は、実行前にすべてのリクエストをチェックします。 Nitro Isolation Engine を有効にしたサーバーのシステムアーキテクチャ。 仕様と証明 この取り組みの 2 つの重要な要素は、仕様と証明です。形式仕様はシステムに期待される動作を正確に記述し、証明は実装がその仕様を満たしていることを立証します。 Nitro Isolation Engine に関する定理は、次の 4 種類の性質を対象としています。 機密性と完全性。 許可された情報フローのみが発生します。例えば、ゲストに割り当てられたメモリ領域は、再利用の前に必ずスクラブされます 機能的正当性。 実装は仕様どおりに正確に動作します ランタイムエラーの不在。 Rust における None オプション値の unwrap (プログラムの実行を停止させる誤ったコマンド呼び出し) のようなランタイムエラーが存在しません メモリ安全性。 バッファオーバーフローや NULL ポインタ参照といった問題が存在しません 実際には、後者の 3 つの性質は機能検証の結果としてまとめて扱い、機密性と完全性は別途扱います。これは、それぞれに異なる証明手法を用いるためです。 機能検証 機能検証における重要な要素は次のとおりです。1 つ目は μRust (マイクロ Rust) と呼ばれる Rust 言語のコアサブセットの形式化、2 つ目は仕様を正確に記述するための分離論理 (Separation Logic) を用いた表現力の高い仕様記述言語、3 つ目はプログラムが仕様に対して正しいことを証明するための検証手法である最弱事前条件計算 (weakest-precondition calculus) と独自の証明自動化です。これらはいずれも汎用的な証明インフラストラクチャの一部であり、2025 年に AutoCorrode ライブラリ としてオープンソース化しました。 より詳しく説明すると、μRust は Rust プログラミング言語の制限されたサブセットで、Nitro Isolation Engine を記述するのに十分な表現力を持ちながら、形式的な推論にも適しています。これは、トレイトや動的ディスパッチといった高度な Rust の機能を意図的に除外しているためです。μRust の形式的意味論は、Isabelle/HOL への 浅い埋め込み (shallow embedding) として定義されています。つまり、μRust の意味は、Isabelle/HOL の「ホスト言語」である高階論理を使って定義されます。 μRust プログラムの仕様は、事前条件と事後条件を持つ契約として定義されます。これらは、プログラム実行前後のシステム状態に関する表明です。この契約は「全正当性 (total correctness)」を規定しています。つまり、事前条件を満たすすべての状態において、プログラムは必ず終了し、その結果の状態は事後条件を満たします。この全正当性の条件は、プログラムがメモリ安全であり、ランタイムエラーがないことも意味します。仕様は、低レベルのポインタ操作プログラムについて推論するために設計された論理である 分離論理 を使って記述されています。 分離カーネルは比較的シンプルとはいえ、Nitro Isolation Engine の検証は、形式的検証で可能な範囲の限界に近い取り組みであり、仕様も証明も非常に大規模になります。例えば、以下の仕様は、実行中のゲスト仮想 CPU が自分自身の電源をオンにしようとした場合 (誤ったリクエスト) に何が起こるかを記述したものです。 対象の CPU をオンにするための電源状態関数 PSCI_CPU_ON の仕様。 上記の仕様は複雑ですが、その内容は直感的にはシンプルです。この状況では、Nitro Isolation Engine は、呼び出し元として動作するには当該の仮想 CPU が既にオンになっているはずだと判断し、定義済みのエラーコード AlreadyOn を返します。それ以外のシステム状態はすべて変更されません。仕様の複雑さは、モデリングの深さと、Nitro Isolation Engine の実装においてこの時点に到達するまでに他の複数のエラーチェックが既に実行されているという事実を反映したものです。 μRust プログラムが仕様に対して正しいことを証明するには、標準的な 最弱事前条件計算 を使用します。最弱事前条件計算とは、特定の操作の後のプログラムの状態が、指定された状態の範囲から外れないことを保証できる、最も制約の少ない条件を体系的に特定する方法です。例えば、式 x + y の最弱事前条件は、 x と y の値の加算がオーバーフローしない状態です。そのうえで、契約の事前条件が計算された最弱事前条件を含意することを示すのが証明義務となります。 機密性と完全性 機密性と完全性に関する 1 つ目の重要な要素は、Nitro Isolation Engine の動作を遷移関係として記述する高レベルの仕様です。ここでは、システムの各「高レベル」ステップ (ハイパーコールなど) が 1 つのアトミックな遷移となります。この仕様は、リファインメント (Refinement) と呼ばれる別の証明のアイデアを用いて、機能検証の結果で使用されるより具体的な分離論理の仕様と厳密に結び付けられています。2 つ目の重要な要素は、 非干渉性 (noninterference) という考え方です。 非干渉性とは、機密性と完全性を数学的に厳密なものにするために使用する、識別不能性の保存という考え方です。あるステップの前に 2 つの状態が観測者にとって識別不能であれば、ステップの後も識別不能なままでなければならない、というものです。これが機密性を表す直感的な理由は、そのステップによって観測者が新しい情報を何も得ていないためです。 識別不能性の保存がなぜ機密性を保証するのかは、少しわかりにくいところです。パブリックレジスタとプライベートレジスタを 1 つずつ持つ、2 つのシンプルなマシン A と B を考えてみましょう。プライベートレジスタは隠されているため、観測者は、パブリックレジスタが一致していれば 2 つのマシンを識別不能とみなします。以下の図では、A と B は識別不能です。 機密性違反の例。 ここで、プライベートレジスタの値によって分岐し、パブリックレジスタに 1 を代入するプログラムを実行するとどうなるかを考えてみましょう。結果として得られるマシン A’ と B’ は、パブリックレジスタの値が異なるため、 識別可能 になってしまいます。賢い観測者はこれを利用して元のプライベートレジスタの値を導き出せてしまいます。つまり、識別不能性が保存されないということは、観測者への不正な情報フローが生じていることを意味します。 今後の展開 ここまで、検証の取り組みにおける主要な要素の概要をご紹介しました。この取り組みには、適合性テストや、並行コードに関する推論の扱い方など、他にも多くの側面があります。今後の記事でお伝えできることを楽しみにしています。 著者について Dominic Mulligan Dominic Mulligan は、Amazon の Automated Reasoning Group の principal applied scientist です。 Nathan Chong Nathan Chong は、Amazon の Automated Reasoning Group の principal applied scientist です。並行システムコードの正当性、特にハードウェアとソフトウェアの境界領域を専門としています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 4 月 17 日に公開された Amazon Science Blog “ Isabelle/HOL: The proof assistant behind the Nitro Isolation Engine ” を翻訳したものです。 Isabelle/HOL は、数学的な記述の表現力、自動化、スケーラビリティのバランスによって、世界初の形式的に検証されたクラウドハイパーバイザーを実現しました。 2025 年の Amazon re:Invent カンファレンスにおいて、Amazon Web Services (AWS) は Nitro Isolation Engine (NIE) を発表しました。NIE は、お客様のデータのセキュリティを確保しながら AWS のお客様にリソースを提供する役割を担うソフトウェアモジュールです。あわせて AWS は、 Isabelle/HOL という定理証明支援系 (proof assistant) を使用して、この Isolation Engine の正当性とセキュリティ保証を形式的に検証したことも発表しました。世界初の形式的に検証されたクラウドハイパーバイザーとして、NIE はクラウドセキュリティの新しい標準を打ち立てています。 Isabelle はもともと ケンブリッジ大学 と ミュンヘン工科大学 で開発され、現在は世界中の機関や個人による数多くのコントリビューションを取り込んでいます。 定理証明支援系とは、人間のユーザーが形式的証明を構築するのを支援する自動化ツールです。その対象は、数学の定理からハードウェアやソフトウェアシステムの妥当性まで、あらゆるものに及びます。広く使われている定理証明支援系はいくつかありますが、私たちが Isabelle/HOL を選んだのは、表現力、自動化、証明の読みやすさ、スケーラビリティのバランスが私たちの用途に最も適していたからです。これは具体的にどういうことなのでしょうか? コンピュータによる論理的推論 数学に決まった言語というものはありませんが、プログラミング言語が計算タスクを表現するのと同じように、数学的推論を表現するための言語を作ることができます。そして、プログラミング言語に表現力とパフォーマンスのトレードオフがあるように、数学的言語にも表現力と自動化のしやすさのトレードオフがあります。形式的証明の構築は時間がかかり、極めて根気のいる作業であるため (ボトルの中に船を組み立てる作業に似ています)、自動化は不可欠です。 形式的証明の構築は、ボトルの中に船を組み立てる作業に似ています。厳格な論理的制約の中で、すべての部品を正確に組み立てなければなりません。Isabelle/HOL は、この緻密な作業を可能にするツールを提供します。 最も初歩的な数学的言語はブール論理です。これは、AND、OR、NOT といった論理演算子の世界です。この言語は非常にシンプルであるため、強力な自動ソルバーが存在します。2016 年、カーネギーメロン大学の Marijn Heule 教授 (現在は Amazon Scholar ) とその同僚たちは、未解決の数学的問題であるブール・ピタゴラス数問題をブール論理に符号化し、自動ソルバーを使って、200 テラバイトという 史上最大の証明 を作り上げました。 一階述語論理 と呼ばれるより豊かな数学的言語では、整数などの対象領域について語り、その領域上の関数を定義できます。また、「すべての～について」や「～が存在する」という 量化子 を主張に含めることで、ブール論理を超える表現が可能になります。この種の言語では、「2 より大きいすべての素数は奇数である」といった文を表現できます。また、Lewis Carroll による次の定理を証明することもできます。 ワルツを踊るアヒルはいない。ワルツを断る士官はいない。私の家禽はすべてアヒルである。ゆえに、私の家禽の中に士官はいない。 しかし、ほとんどの人は、プログラミングと同じように型を定義できる、さらに強力な数学的言語を好みます。 高階論理 には、 Haskell などの関数型プログラミング言語に見られるような関数型さえ存在します。高階論理は一階述語論理よりもはるかに豊かで、「 数 1 を含み、加法について閉じているすべての集合は、すべての正の整数を含む 」といった文を表現できます。数学の大部分を表現できるほど豊かであると考えられています。 最も豊かな数学的言語である 依存型理論 では、型が任意の値をパラメータとして取ることさえ可能です。例えば T(i) のように、 i を整数とすることができます。この種の言語で最もよく知られているのは Lean と Rocq です。 一階述語論理には強力な自動定理証明器が存在しますが、高階論理やそれ以上の言語では、完全な自動化は利用できません。これが表現力の代償です。 定理証明支援系 を使えば、ユーザーは部分的な自動化の支援を受けながら対話的に証明を構築でき、独自の証明探索をコーディングすることも可能です。定理証明支援系は、論理法則への厳格な準拠を強制します。これは通常、定理を作成する権限をコードの限られた部分にのみ与えるカーネルアーキテクチャによって実現されます。 定理証明支援系は、非常に大規模になり得る形式的仕様の階層を対話的に開発することもサポートします。例えば、Nitro Isolation Engine (NIE) の検証は、Graviton-5 プロセッサのアーキテクチャの仕様、ハイパーコールの Rust コードとその機能的正当性、そして証明すべきセキュリティ特性の仕様の上に成り立っています。形式的証明を構成する 25 万行の大部分は、これらの仕様が占めています。 高階論理は、密接に関連する 2 つの定理証明支援系である HOL と HOL Light でサポートされており、1990 年代からハードウェア設計、浮動小数点アルゴリズム、純粋数学の検証に使われてきました。AWS のシニアプリンシパルアプライドサイエンティストである John Harrison は HOL Light を開発し、暗号アルゴリズムの最適化バージョンを検証することで、Amazon の Graviton2 チップにおけるデジタル署名の パフォーマンスを最大 94% 向上 させました。このコードは繊細であり、網羅的なテストは 現実的ではありません 。このような重要なソフトウェアをデプロイする前に取り得る手段は、完全な機能的正当性の形式的検証しかありませんでした。しかし、ここで注目したいのは Isabelle/HOL です。 Isabelle/HOL の概要 Isabelle/HOL と他の HOL システム (いずれも高階論理に基づいています) の最も目に見える違いは、その仕様記述言語と証明言語です。ほとんどの定理証明支援系では、ユーザーは証明したいことを記述した後、一種のモグラたたきゲームのように、元のゴールを一連のサブゴールに置き換えるコマンドを次々と続けていきます。Isabelle では (Lean でもある程度は)、証明言語によって望ましい中間ゴールを明示的に書き出すことができるため、証明プロセスをより適切に制御でき、より読みやすい証明ドキュメントが得られます。 オンラインには多くの例 があります。 その他の 注目すべき機能 は以下のとおりです。 Rust 言語のかなりの部分を仕様に埋め込むことを可能にした ユーザー設定可能なパーサー 例えば + に、さまざまな数値型だけでなくマシンワードやその他の適切な文脈でも自然な意味を与える、原則に基づいたオーバーロードのための 型クラス 仕様の階層を定義し、証明の中でさえさまざまな方法で解釈できる軽量なモジュールシステムである ロケール (locales) 単純化と後ろ向き連鎖による証明探索を通じた、強力な 組み込みの自動化 さらに強力な外部の自動化にワンクリックでアクセスできる sledgehammer 実際には偽である主張を特定するための 反例発見ツール 適合性のテストに使用した、実行可能な高階仕様からの コード生成 NIE の検証にあたっては、まず 分離論理 (separation logic) と呼ばれる特化した言語を Isabelle/HOL の上に実装することから始めました。分離論理は、共有リソースを操作するプログラムコードの検証のために設計されたものです。私たちは独自の証明自動化をコーディングし、組み込みの自動化も活用しました。そのため、分離論理を使いつつ、必要に応じて通常の高階論理も使うことができました。Isabelle は、非常に巨大なサブゴールにも対処できるほど堅牢かつ効率的であることがわかりました。市販のラップトップを使って、25 万行の証明を 30 分で実行できたのです。 Isabelle/HOL の応用事例 NIE 以前の Isabelle の応用事例として最も印象的なのは、おそらく広く使われているマイクロカーネルである seL4 の検証 でしょう。この証明も最初に発表された時点では約 25 万行でしたが、現在ではさらに長くなっています。seL4 の開発者たちは、マイクロカーネルの C 実装が抽象的仕様を詳細化したものであることを証明し、コア操作の完全な機能的正当性を実現しました。そして、検証されたコード部分ではバグが一切観測されていません。ただし、未検証の部分や形式化できない一部の前提条件をカバーするために、テストは依然として重要な役割を果たしています。 Isabelle は以下のプロジェクトでも使用されました。 エラーの特定、特にその型システムの 健全性の証明 を目的とした、 WebAssembly 言語のセマンティクスの形式化 Cogent プログラミング言語のための 検証フレームワーク の作成 分散編集に使用される、競合のないレプリケートデータ型 (CRDT) のアルゴリズムの 正当性の証明 純粋数学における 数多くの結果の形式化 抽象レベルでの 暗号プロトコルの検証 Isabelle は無料のオープンソースソフトウェアであり、 ダウンロードして利用 できます。十分なメモリを備えたマシンであれば、主要なオペレーティングシステムすべてで動作します。 著者について Larry Paulson Larry Paulson は、ケンブリッジ大学の計算論理学の名誉教授であり、Amazon Scholar です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本稿は、Japan Digital Design 株式会社 佐藤様による「三菱UFJフィナンシャル・グループの DX を牽引する Japan Digital Design、Aurora DSQL の採用で DB コストを約 87% 削減し、運用負荷ほぼゼロを実現」に関する寄稿記事となります。 こんにちは。Japan Digital Design 株式会社 Technology & Development Division で Technical Project Manager を務めている佐藤です。 Japan Digital Design 株式会社は「金融の新しいあたりまえを創造し人々の成長に貢献する」というミッションのもと、AI・CX・Tech の各領域を組み合わせて三菱UFJフィナンシャル・グループの DX を支援しています。私が所属する Technology & Development Division では、システムの開発・運用からプラットフォーム構築、アーキテクチャ設計までを担っています。 今回、ドキュメント検索システムを新規構築するにあたり、データベースとして  Amazon Aurora DSQL  を採用しました。パートナーを介さず自社開発チームのみで導入を完了し、結果として  Aurora Serverless 比で約 87% のコスト削減と DB 運用負荷ほぼゼロ を実現できています。本記事では、私たちが Aurora DSQL を選定した背景、開発時に直面した課題とその対処、そして導入後に得られた効果をご紹介します。これから DSQL の採用を検討される方の参考になれば幸いです。 対象システム Aurora DSQL は、Japan Digital Design 株式会社が運営するドキュメント検索システムの一部である文書管理データベースとして利用しています。 本システムは、夜間バッチ連携される PDF や Web サイトの情報を取り込み・加工し、ユーザーが取込履歴や取込データ一覧を CSV としてダウンロードできる機能を提供しています。 アーキテクチャ 本システムは 2 つのワークロードで構成されています。 夜間バッチ処理 : 翌朝の Web アプリケーションの開局時間までに全ての取り込み・加工処理を終わらせる必要があるため、AWS Step Functions にて約 1,800 の Amazon ECS タスク（EC2 上で稼働）を並列起動。上流から取り込んだデータを各タスクが処理して、取込結果を Aurora DSQL に書き込む Web アプリケーション : Amazon CloudFront + ALB + Amazon ECS で構成された Web アプリケーションから Aurora DSQL のデータを読み取り、取込データ一覧を CSV として提供 夜間バッチでは、 ピーク時に 1 晩あたり 10 万件超 のファイル／レコードを処理します。バッチはユーザーが利用しない夜間にのみ稼働し、日中の Web アプリケーションからの読み取りとは時間帯が分離されています。 データベース選定の背景 本システムは新規開発だったため、システムの特性に合わせてデータベースをゼロベースで検討できました。私たちがデータベースに求めた要件は以下の 3 点です。 1. 複数環境運用におけるコスト効率 本番・ステージング・開発など複数環境を運用するため、未使用環境にも固定費が発生するインスタンス課金型 DB ではコストが見合わないという課題がありました。 2. スパイクワークロードへの対応 夜間に約 1,800 の ECS タスクが並列書き込みを行うスパイクワークロードへの対応が必要でした。書き込みが夜間に集中する特性上、スケーラブルなアーキテクチャが望ましいと考えていました。 3. 将来のデータ拡大への備え 将来的にデータ量を 10 倍規模に拡大する計画があり、その都度性能調査・性能試験を行う工数は避けたいと考えていました。 Aurora DSQL を選択した理由 他の候補として Aurora Serverless、Aurora、DynamoDB を比較検討し、以下の理由から Aurora DSQL を選択しました。 サーバーレス・従量課金 夜間バッチ時のみコストが発生し、未使用環境の固定費を解消できます。Aurora Serverless では、コールドスタートを避けるために最小 ACU を 0.5 に設定すると環境ごとに固定費が発生しますが、DSQL では利用しない環境にほとんど料金がかかりません。 さらに、Aurora DSQL はアイドル状態が長期間続いても接続時の遅延が極めて小さく抑えられます。Aurora DSQL のクラスターライフサイクルでは、一定期間アイドル状態が続くとリソースを縮小（Idle 状態）し、さらに長期間接続がないとリソースをゼロにスケール（Inactive 状態）しますが、接続するだけで自動的に Active 状態に復帰します。一方、Aurora Serverless の自動一時停止機能（0 ACU へのスケーリング）では、再開時に通常約 15 秒、24 時間以上の一時停止後は 30 秒以上の待機が発生します。Web システムでこの遅延を許容できない場合、最小 ACU を 0.5 以上に維持する（＝固定費が発生する）か、定期的な ping 処理でウォームアップを維持する必要があります。DSQL ではこうした考慮が大幅に軽減され、週に 1 回程度しか動かないようなワークロードでも実用的な応答速度で利用できます。 メンテナンスゼロ パッチ適用やキャパシティ管理が不要で、DB 運用負荷を最小化できます。 SQL 互換性 — DynamoDB ではなく DSQL を選んだ理由 DynamoDB も検討しましたが、テーブル設計の特性と SQL 互換性を重視して Aurora DSQL を選択しました。 本システムは業務システムとしてある程度の複雑性を持ちます。DynamoDB でも構築は可能ですが、アクセスパターンに合わせたテーブル設計が求められる NoSQL のアプローチよりも、やりたいことを素直に SQL で表現できる RDB の方が健全なシステムを構築できると判断しました。開発チームの SQL への習熟度が高く、これまでの RDB の知見をそのまま活かせることも大きな要因でした。 そのうえで、RDB の選択肢の中でコスト面で最も優れていたのが Aurora DSQL でした。 スモールスタートから大規模まで、再設計なしに拡張できる 本システムは社内の利用者が使うためのシステムのため、最大ユーザー数は限定的です。Aurora DSQL は GA 当初、マルチリージョンの大規模スケーラビリティが注目されがちでしたが、私たちはむしろ「小さく始められ、必要に応じて再設計なしに大規模まで成長できる」点を評価しました。完全サーバーレスでゼロまでスケールダウンできるため、間欠的・小規模なワークロードでも無理なく利用でき、その後データ量やスループットが拡大しても、同じデータベースの特性・体験のまま使い続けられます。 Aurora DSQL に向いているワークロードかを見極める 採用にあたっては、本システムのワークロード特性が DSQL の設計思想に合致するかを、以下の 3 つの観点で事前に評価しました。DSQL の導入を検討されている方にも、そのまま使える判断基準だと思います。 判断基準 本システムでの評価 楽観的同時実行制御（OCC）で問題ないか 1 タスク = 1 ドキュメントで各タスクが独立した処理対象を扱い、同一レコードへの同時更新が発生しない。さらに書き込み（夜間バッチ）と読み取り（日中）が同時に発生しない OLAP（分析・集計クエリ）のユースケースがないか データの格納と CSV 出力が主用途で、分析・集計クエリは不要 スパイク型ワークロードか 夜間のみ集中した書き込み処理が発生し、日中の負荷は限定的 この 3 条件を満たすワークロードであれば、Aurora DSQL の特性を最大限に活かせると判断し、採用を決定しました。 開発スケジュール 2025 年 5 月末の Aurora DSQL GA（一般提供開始）を受けて検討を開始し、以下のスケジュールで開発を進めました。 時期 マイルストーン 2025 年 6 月 AWS Summit で Aurora DSQL の実動作を確認し、採用検討を開始 2025 年 8 月 事前検証開始（マイグレーションツールの動作確認等） 2025 年 10 月 設計・開発開始 2026 年 1 月 本番ローンチ GA から約 3 ヶ月で事前検証を経て開発に着手し、約 3 ヶ月の開発期間で本番ローンチを迎えることができました。 開発時の取り組みとハマりどころ 私たちはパートナーを介さず、すべて自社開発で Aurora DSQL を導入しました。AWS 公式ドキュメントを主な技術情報源とし、約 3〜4 ヶ月で習熟に至っています。 PostgreSQL 互換とはいえ DSQL 固有の制約はいくつかあり、開発中に検討した内容、および直面した課題と対処法を共有します。 ORM として SQLAlchemy、マイグレーションツールとして Alembic を採用 DSQL を利用する際の ORM とマイグレーションツールの選定前に、ORM とマイグレーションツールによる各 DB 操作で実施できるもの・できないものを一通り確認していきました。その上で、最終的に SQLAlchemy + Alembic を採用しました。 SQLAlchemy については、AWS が公開している aws-samples リポジトリに利用例が掲載されていることが決め手となりました。 https://github.com/aws-samples/aurora-dsql-samples/tree/main/python/sqlalchemy また、SQLAlchemy、Alembic のいずれも必要に応じて生 SQL の実行をサポートしている点も採用理由の一つでした。 大量データのフェッチとメモリ制限 十数万レコードを CSV 化する要件に対して、当初 LIMIT OFFSET 構文による分割取得を試みたところ、トランザクションあたりのワークメモリ上限 128 MiB の制約に抵触しました。LIMIT OFFSET の仕組み上、不要な OFFSET 分のデータもすべて取得してから最終的な結果を返すためです。 対処法: Primary Key として UUIDv7 や連番など一意で時系列なキーを採用しました。データ取得方法についても Keyset Pagination（WHERE 句で前回取得した ID 以降のデータを抽出）に切り替えることで解決可能です。 トランザクションサイズの制限 Aurora DSQL には、トランザクションブロックで変更できるテーブル行の最大数 3,000 件、書き込みトランザクションで変更されるデータの最大サイズ 10 MiB といった制限があります。 対処法: 設計段階からトランザクションサイズを意識し、処理を分割する方式を採用しました。後から気づくと手戻りが大きいため、設計初期にこの制約を織り込んでおくことをお勧めします。 列の変更対応 DSQL では DROP COLUMN、ALTER COLUMN、NOT NULL カラムの追加といった列定義の変更ができません。変更が必要な場合は、別テーブルを用意してデータを移行する対応が必要でした。 ローカル開発環境の整備 現時点では、Aurora DSQL の制約まで再現したローカルエミュレータは存在しません。PostgreSQL コンテナで代替すると、DSQL 固有の制約にローカルでは気づけないケースがありました。 対処法: 制約に抵触しやすい開発モジュールについては、ローカル環境から直接 DSQL に接続して開発する手法を取り入れました。 振り返って：AWS への早期相談は有効 私たちは自社開発のみで導入を完了しましたが、振り返ると、開発段階から AWS アカウントチームに相談していれば、DSQL 固有の制約やノウハウ（フェッチの取り方など）をより早く把握でき、改善要望も早期に提出できたと感じています。AWS 側でも DSQL の制約に関するナレッジを蓄積しており、開発段階から共有いただける体制があるとのことです。これから導入を検討される方には、開発の早い段階でのアカウントチームへの相談をお勧めします。 導入後の効果 コスト約 87% 削減 Aurora Serverless（コールドスタート回避のため最小 ACU を 0.5 に設定した場合）比で、約 87% のコスト削減を実現しました。多数の環境を運用するエンタープライズ案件では、利用しない環境にほとんど料金がかからない DSQL の料金体系により、環境数に比例したコスト増加を回避できています。稼働していなければ放置しても課金が発生しないため、開発環境の上げ下げを管理するバッチ処理やスクリプトも不要になりました。 運用工数ほぼゼロ キャパシティ管理・パッチ適用が不要となり、DB 運用工数がほぼゼロになりました。他のシステムでは、開発環境の上げ下げのバッチ作成、インスタンスの容量拡張、コールドスタート回避のための ping 処理など、細かな運用タスクがどうしても発生します。DSQL ではこれらがすべて不要です。DB 周りの運用管理にリソースがほぼ発生しなくなり、チームは開発や上流工程のタスクに集中できるようになりました。 小規模なシステム、たとえば週に 1 回程度しか動かないようなワークロードでも、コールドスタートなしで即座に応答できる点は、運用の手間を大きく削減してくれています。 データ 10 倍拡大も設定変更・性能チューニングなし データ量を約 10 倍（現在数十 GB 規模）に拡大した際も、DB 側の設定変更や性能チューニングは一切不要でした。DSQL 側には何も影響がなく、性能劣化も発生していません。今後もデータ格納量やバッチ利用時のスループットは拡大していく見込みですが、性能調査や性能試験に時間を取られることなく、DSQL の自動スケーリングで対応できる見通しです。 Multi-AZ 標準装備 デフォルトで Multi-AZ が担保されており、追加設定なしで AZ 障害耐性を確保できています。 総括すると、 コストと運用負荷の削減が Aurora DSQL 導入の最大のメリット でした。環境数がかなり多い本システムでは、利用しない環境にほとんど料金がかからない DSQL の料金体系がマッチしていました。データ量を約 10 倍に拡大した際も、DB 周りは追加の設定変更なく対応できています。 最後に データ格納量やバッチ利用時のスループットは今後も継続的に拡大していく見込みであり、Aurora DSQL の強みを引き続き有効活用していく方針です。また、三菱UFJフィナンシャル・グループ各社への AI 活用展開に向けて、Amazon Bedrock をはじめとする AWS の AI 関連サービスの拡充にも期待しています。 Aurora DSQL 自体に対しては、クエリログ（監査ログ）の実装や ALTER TABLE/COLUMN 対応による列定義変更の柔軟性向上を期待しています。 本記事が、Aurora DSQL の採用を検討されている方の一助になれば幸いです。 執筆者 佐藤 慎 Japan Digital Design 株式会社 Technology & Development Division テクニカルプロジェクトマネージャ Japan Digital Design 株式会社にて金融機関向けシステム・AI導入案件のプロジェクトマネージャを担当。 Amazon Aurora DSQLをはじめとするクラウドネイティブ技術を活用したプロダクトの本番導入に取り組んでいる。

2026 年 7 月 20 日週、私はサンパウロで中南米各地のテクニカルビルダーと 3 日間過ごす機会に恵まれました。ここでは、深く掘り下げたセッション、ハンズオンワークショップ、お客様やパートナーとの会話が盛りだくさんの地域の技術イベントに参加しました。私が最も感銘を受けたのは、単一のセッションではなく、同じ部屋にいる機会はめったにない技術コミュニティのエネルギーでした。人々はコーヒーを飲みながらアーキテクチャのアイデアを交換し、ホワイトボードに解決策をスケッチし、到着したときよりも長い「試してみたいこと」のリストを手にして帰っていきました。私たちが構築するすべてのツールにおいて、それを取り巻くコミュニティこそがテクノロジーを定着させていることを思い出させてくれます。 このコミュニティの精神は、 7 月 27 日週の最大のインフラストラクチャニュースとうまく結びついています。それは、AWS をビルダーが実際にいる場所の近くに届けることに関するものです。 それでは、7 月 27 日週の AWS ニュースを見ていきましょう… 主なトピック ギリシャのアテネの AWS ローカルゾーン : AWS はギリシャのアテネに新しいローカルゾーンを開設しました。これは、Amazon S3 と Amazon EBS ローカルスナップショットをサポートする EMEA の 2 番目のローカルゾーンです。これにより、ギリシャ国内でデータを保存および処理して、ローカルのデータレジデンシー要件を満たすのに役立ちます。アテネローカルゾーンは、Amazon EC2 (C7i、M7i、および R7i インスタンス)、ワンゾーン低頻度アクセスストレージクラスの Amazon S3、Amazon EBS、および Amazon ECS をサポートしています。 AWS ローカルゾーンは、AWS インフラストラクチャを大勢の人口や業界のハブの近くに配置しています。これにより、リアルタイムゲーム、メディア制作、金融サービスなど、数ミリ秒のレイテンシーを必要とするアプリケーションを、エンドユーザーが実際にいる場所で実行できるようになります。ギリシャのビルダーは、レイテンシーの影響を受けやすいワークロードをローカルで実行すると同時に、低レイテンシーを必要としないサービスのために最も近い AWS リージョンにシームレスに接続できるようになりました。これにより、独自のデータセンターインフラストラクチャを管理しなくても、レイテンシーが最適化されたハイブリッドアプリケーションを柔軟に設計できます。詳細については、 AWS グローバルインフラストラクチャと持続可能性に関するブログ投稿 をご覧ください。 7 月 20 日週のリリース 7 月 20 日週のリリースのうち、私が注目したリリースをいくつかご紹介します: AWS 上の Claude Opus 5 : Anthropic の Claude Opus 5 を使用できます。これは、これまでで最も先進的な Opus モデルであり、多くの分野で Claude Fable 5 のトップクラスのインテリジェンスに匹敵する、Opus レベルの料金体系でご利用いただけます。Amazon Bedrock では、デフォルトでゼロデータ保持 (ZDR) が有効になっている Claude Opus 5 を提供しています。これにより、Claude Fable 5 とは異なり、データガバナンス要件を満たしながら、Opus の最高レベルのインテリジェンスを提供できます。Claude Opus 5 にアクセスするには、Amazon Bedrock と Claude Platform on AWS の 2 つの方法があります。詳細については、 詳細なブログ投稿 にアクセスしてください。 .NET 用の AWS Lambda 永続実行 SDK が一般公開されました : カスタムの進捗追跡を実装したり、外部のオーケストレーションサービスを統合したりしなくても、Lambda の永続関数を使用して、回復力のある長時間実行ワークフローを C# で構築できるようになりました。SDKは、支払い処理パイプライン、AI エージェントオーケストレーション、ヒューマンインザループ承認などの複数ステップのアプリケーションに最適です。進行状況を自動的にチェックポイントで確認し、実行を最大 1 年間停止できます。お客様がサーバーレスワークフローを構築している .NET 開発者である場合、これによって手作業で記述していたプラミングの大部分が不要になります。 Amazon Bedrock AgentCore では、トレースとログを 1 つのロググループにまとめることで、統一されたオブザーバビリティを実現できるようになりました : Amazon Bedrock AgentCore は、エージェントのトレースとプロンプトを、エージェントのログと同じ Amazon CloudWatch ロググループに配信するようになりました。以前は、テレメトリは送信先に分散され、トレーススパンは共有ロググループに送られ、プロンプト、入力、出力は別のロググループに送られました。そのため、1 回のエージェント呼び出しをデバッグするには複数の場所を検索する必要がありました。呼び出しを 1 か所でデバッグし、きめ細かなアクセス制御とカスタマーマネージドキー (CMK) 暗号化を個々のエージェントレベルで適用できるようになりました。 Amazon Connect がより自然なエージェント音声体験を提供 : Amazon Connect は、現在、ポルトガル語、スペイン語、フランス語、イタリア語、日本語、韓国語、タイ語を含む 50 以上の言語で、より自然で人間に聞こえるエージェント型音声体験をサポートするようになりました。100 を超える新しい音声オプションと会話の改善により、AI インタラクションがよりスムーズに聞こえるようになりました。Connect のエージェント型セルフサービスにより、AI エージェントは顧客の口調や感情に合わせて、音声やデジタルチャネル全体で理解し、推論し、行動に移すことができます。顧客が実際に話す言語のうち、これまでよりもはるかに多くの言語で、発信者に対して自然に感じられるコンタクトセンター体験を構築できるようになりました。 Amazon SageMaker Unified Studio が Amazon OpenSearch をサポートするようになりました : Amazon OpenSearch の検索データやログ分析データを、Amazon SageMaker Unified Studio の他のデータ資産と一緒に直接クエリして分析できるようになりました。この接続により、OpenSearch の運用検索データを Amazon Redshift、Amazon S3、リレーショナルデータベースなどのソースからのデータと、すべて単一の管理された環境内で組み合わせることができます。アプリケーションログをトランザクションデータと組み合わせてインサイトを引き出すなど、分析ワークロードと運用ワークロードを相互に関連付ける必要がある場合に特に役立ちます。 Amazon CloudWatch がコーディングエージェントのインサイトを発表 : Amazon CloudWatch により、エンジニアリングリーダーは AI コーディングツールが組織全体でどのように価値をもたらしているかを把握できるようになりました。コーディングエージェントインサイトは AWS 用の Claude アプリゲートウェイと統合されているため、追加のインストルメンテーションなしで Claude Code からテレメトリを収集できます。また、Codex や GitHub Copilot などのエージェントもサポートしています。チームが AI コーディングの採用を拡大するにつれて、OpenTelemetry で構築されたメトリクスを使用してその投資収益率を測定できるようになりました。カスタムインストルメンテーションは必要ありません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: AI エージェントの評価: Strands と AgentCore を使った本番環境ブループリント : Strands Agents と Amazon Bedrock AgentCore を使用して、本番環境に移行する前後に AI エージェントを評価するための実践ガイド。エージェントをプロトタイプから本番環境に移行している場合、この投稿は上記の AgentCore Observability のアップデートに役立ちます。エージェントの品質を直感ではなく体系的に測定する方法を説明しています。 AWS CloudFormation カスタムリソースデプロイのためのマルチリージョンの耐障害性の構築 : 単一リージョンに問題が発生した場合でも、コードとしてのインフラストラクチャのデプロイの信頼性が維持されるように、マルチリージョンの耐障害性を実現するために CloudFormation カスタムリソースを設計する方法を学んでください。 Amazon Simple Email Service (SES) 料金プランのご紹介 : Amazon SES では、E メールの量が増えてもコストを予測できる料金プランが提供されるようになりました。大量に送信する場合、請求が大幅に簡素化されます。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits : AWS Summits は、クラウドや AI のコミュニティが一堂に会し、つながり、学び、最新のテクノロジーを探求するための無料のイベントです。カレンダー全体をご覧になって、2026 年後半にお近くで開催されるサミットを見つけてください。 AWS Community Days : コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの方は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受付中です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 7 月 27 日週のニュースは以上です。８ 月 3 日週の Weekly Roundup もお楽しみに! この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

こんにちは。流通小売・消費財・飲食業界を担当するソリューションアーキテクトチームです。 6 月 25 日（木）、26 日（金）の 2 日間にわたり、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されました。会場には Day 1 に 22,000 名以上、Day 2 に 20,000 名以上、Executive Forum も合わせると延べ 43,000 名以上の方にご来場いただきました。基調講演や数多くの事例セッションとともに、AWS Expo エリアでは AWS サービス・ソリューションの最新活用事例や、実際に AWS に触れられるデモを、さまざまな角度から体験いただきました。 AWS Expo エリア内の AWS Industries Zone では、製造、金融、自動車、そして私たちの担当する流通小売・消費財・飲食など、業界別に特化したソリューションをご紹介しました。私たち流通小売・消費財・飲食業界担当チームのブースには、両日ともに終日、途切れることなく多くのお客様に足を運んでいただきました。デモを体験いただいたお客様からの多くのフィードバックを通じて、私たち自身もまた新しいアイデアと気づきを得ることができました。ご来場いただいた皆さま、本当にありがとうございました。 流通小売・消費財・飲食業界向けブースの様子。両日とも終日、多くのお客様にお立ち寄りいただきました 本ブログでは、流通小売・消費財・飲食業界向けブースの展示内容と当日の様子をダイジェストでご紹介します。展示内容に使われている AWS サービスやアーキテクチャの詳細については個別の解説ブログも公開しており、本ブログの中からそれらのブログもご案内しています。（ 事前のご案内ブログはこちら ） AWS 展示ブーステーマ 「AI エージェントが業務の主役になる日」 昨年の Summit では「The Future of Retail」をテーマに、カスタマージャーニーを軸とした店舗体験の “少し先の未来” をご紹介しました。今年、私たちが皆さまにお届けしたのは、その一歩先 — AI エージェントが、業務そのものの主役になっていく世界 です。 生成 AI を「試してみた」というお客様は、この一年で本当に増えました。一方で、実務での大規模な活用にまで踏み込めている企業は、まだ決して多くありません。そのあいだに横たわっているのは、多くの場合「いまの業務プロセスを全部つくり変えなければならないのではないか」という、心理的なブロッカーです。 今年のブースでご提案したのは、その逆の発想です。既存のプロセスはそのままに、まずは業務の “一部” に AI を組み込んでみる。そこから自律エージェント、そして複数のエージェントが連携するマルチエージェントへ少しずつ広げていくことで、やがて業務全体の最適化へたどり着く — この段階的な進化のステップを、実機デモで体感いただきました。 商品をつくり、届け、そして売る。流通小売・消費財・飲食業界のバリューチェーンのそれぞれの現場で、AI エージェントがどのように働き始めているのか。本ブースでは 「商品をつくる」「商品を届ける」「商品を売る・つながる」 の 3 つの切り口で、合計 6 つの展示テーマ（7 デモ）と 2 社のお客様事例展示をお届けしました。それでは、当日の様子を順にご紹介していきます。 商品をつくる — AI と共創する、これからの商品開発 バーチャル AI エキスパート — 専門家ペルソナたちが、あなたのアイデアを形にする CEO 視点、IT Director 視点、店舗マネージャー視点、顧客価値視点 — それぞれ異なる専門性と立場を持つ個性豊かな AI ペルソナたちが「バーチャル専門家チーム」を構成し、来場者が音声で伝えたビジネステーマについて、並列で Deep Research とディスカッションを重ねてベストなアイデアを提案するデモです。各ペルソナが独立に調査した結果を持ち寄り、モデレーターが議論を取りまとめ、レッドチームが厳しい指摘と改善案を入れる — その過程が縦型ホログラムディスプレイと 3D アバター、カード型 UI でリアルタイムに可視化され、エグゼクティブサマリーからアーキテクチャ案・コスト試算、さらには PoC 用サンプルアプリケーションまでが「数分の対話」で立ち上がります。 縦型ホログラムディスプレイに映る AI ペルソナたちの議論。可視化されるプロセスに多くの方が足を止めました 最も反響が大きかったのは「AI が議論する」という体験そのものでした。単なる Q&A ではなく、複数の視点が交わり「考えが深まっていくプロセス」が目の前で可視化される様子に、来場者からは「すごい壁打ちができるということですね」「社長に見せたら、やるって言いそう」といった声をいただきました。また、実在人物のペルソナ（上司や取引先など）を再現して壁打ち相手にしたい、という声も複数いただいています。マルチエージェントという概念が昨年より自然に受け入れられていることも印象的でした。 技術的には Amazon Bedrock AgentCore Runtime 上で Amazon Nova 2 Sonic による音声対話、 Strands Agents によるマルチエージェント、A2A / AG-UI プロトコルによるエージェント間通信と UI 可視化を組み合わせています。開発の裏側は以下のブログで詳しく解説しています。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 — 「AI ペルソナ達がビジネス課題解決を加速する」バーチャル AI エキスパート AI で加速する製品イノベーション — マルチエージェントで実現する製品開発 架空の鞄メーカー・アパレルメーカーを題材に、リサーチ・デザイン・製造の各工程を担う複数の AI エージェントが連携し、市場調査からターゲットの特定、デザイン生成、仮想ペルソナによる検証、そして製造コスト・収益予測まで — 通常であれば半年から 1 年を要する一連のプロセスを、わずか数分で駆け抜けるデモです。各フェーズで AI が多様な選択肢を提示し、戦略的な意思決定は人間が下す「Human-in-the-Loop」の考え方によって、スピードと品質を両立させる新しい商品開発の姿をご覧いただきました。 数分で製品デザイン案が生成される様子を体験いただきました 会場では、多くの来場者が数分のうちにオリジナルの製品デザインが生み出される様子をご覧になりました。製品開発やマーケティングに携わる方々からは「市場調査からデザイン、原価試算までを短時間で回せる」ことへの手応えの声が、経営層・事業責任者の方からは「専任チームがなくてもイノベーションを実行できる体制を作れる」という受け止めが、そして少人数のスタートアップの方からは「大手と同等の製品開発力を持てる、イノベーションの民主化だ」という反応もいただきました。自社の経営戦略資料や販売実績を Amazon Bedrock Knowledge Bases に連携することで「一般解」ではなく「わが社の解」が得られる、という点にも多くの関心が寄せられました。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 — AI で加速する製品イノベーション 〜マルチエージェントで実現する製品開発 商品を届ける — 止めない物流とサプライチェーンのために AI エージェントで危機対応 — 小売×消費財の混乱を AI と人が即座に解決 台風による広域配送停止、ドライバー不足、SNS でのバイラル化による需要急増、原材料の調達難。「想定外」が起きたそのとき、AI エージェントが外乱を検知し、影響を分析し、代替案を探索・提示し、人間が承認したうえで実行と通知までを一気通貫で行う — この次世代のサプライチェーン管理オペレーションをライブで実演しました。小売シナリオ（店舗の在庫不足に対する最適な振替ルートの提案）と消費財シナリオ（原材料供給停止時の代替サプライヤー探索）の 2 パターンをご覧いただき、Amazon Bedrock AgentCore と Strands Agents SDK の Interrupt 機能による Human-in-the-Loop の協調モデルがリアルな課題シナリオの中でどう機能するのかをお見せしました。 AI エージェントの思考プロセスと Human-in-the-Loop の承認フローをライブで実演 ブースを訪れたお客様のほぼ全員が、危機管理や BCP 訓練を「やりたいがリソースや手段がなくてできていない」とおっしゃっていたのが印象的でした。大雪や台風などで実際に困っている企業様からは「これまで担当者が各所に何本も電話をかけて対応していた。AI が初動を担ってくれるだけでもありがたい」という声をいただきました。エージェントの思考プロセスの可視化により「具体的なイメージが湧いた」「エージェントの処理を見て初めて理解できた」というフィードバックも多く、1 回あたり数百円程度というシミュレーションコストの低さにも「想像より安い」と好意的な反応をいただきました。既存システムを置き換えることなく、AI による分析の仕組みを「外付け」し、シミュレーション（レベル 1）から段階的に自動化レベルを上げていけるアプローチに、多くの共感が集まりました。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 — AI エージェントで危機対応：小売×消費財の混乱を AI と人が即座に解決 物流異常を Amazon Quick が自動解決 — 配送在庫の異常検知〜問合せまで一気通貫 基幹システム、受発注、在庫、配送 — 複数のシステムに分散しがちな物流のデータを Amazon Quick に統合し、業務の自動化と可視化を実現するデモです。Quick Automate が業務システムを横断的に監視して異常を自律的に検知し、Microsoft Teams へリアルタイムに通知。Quick Sight のダッシュボードで滞留の状況を一目で把握し、「ABC 運輸の大阪→福岡の遅延率を週別で出して」とチャットで聞けばその場でグラフが生成されます。物流専門家の Chat Agent が構造化データと SharePoint 上の報告書・SLA 合意書などの非構造化データをセキュアに横断して根本原因を深掘りし、最後は業者へのメール問い合わせまで自動生成・送信 — 「発見」から「対応」までが途切れなくつながる体験をご覧いただきました。 Quick Sight のダッシュボードで配送の滞留状況をご覧いただきました 従来なら報告書を探し、データを手動で突き合わせ、ベテランに聞いて半日かかっていた原因究明作業が、チャットで聞くだけで数分で完了する。データの散在・発見の遅れ・属人化という物流現場の普遍的な課題に対し、可視化・AI 分析・自動化・外部連携をひとつのサービス上で統合的に提供する Amazon Quick の姿に、多くのお客様から関心をお寄せいただきました。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 — 物流異常を Amazon Quick が自動解決：配送在庫の異常検知〜問合せまで一気通貫 商品を売る・つながる — コマースと店舗の、新しいかたち Future of Agentic Commerce — AWS で実現する新しい E-Commerce の形 いま US で吹き荒れている Agentic Commerce の旋風。AI プラットフォーマー側の Incoming Agent から EC サイトに流入し、自社 EC サイト上の Onsite Agent による接客を経て購入に至るまで、そして裏側で動く EC バックエンド・バックオフィスの仕組みまでを、一つの Demo システムとして統合してご覧いただきました。UCP、AP2、ECP、MCP Apps といった 2026 年に入って急速に整備が進むコマースプロトコル群への対応、エージェントへの決済権限の委任、さらには友達同士の AI エージェントが購入前に相談し合うコンセプトデモまで、6 つのストーリーで「来たる Agentic Commerce 時代」の実装イメージを具体的にお見せしました。 Incoming Agent から自社 EC への流入・購入までを一つの Demo システムで体験 印象的だったのは、「AI エージェントに決済まで任せたい」という声はそれほど多くなく、むしろ「AI プラットフォーマーに自社の商品を推薦してもらい、自社の EC サイトへ流入させたい」 — まず「見つけてもらうこと」への関心の高さでした。また「Agentic Commerce という名前しか知らず、何のことかよくわからなかったが、このブースを見て完全に理解できた。自分たちが何を検討すればいいかが分かった」と言って帰られたお客様もいらっしゃいました。実際に触れられる実装例がまだ少ない日本市場において、ブースが一つの「アンサー」を示せたことは大きな成果だったと感じています。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 〜 Future of Agentic Commerce ブース Eyes On, Voice On — スマートグラスと音声 AI が融合する、フード・現場業務の未来形 実店舗やキッチンなど「手が使えない現場」の業務を、音声 AI エージェントとウェアラブルデバイスで支援する 2 つのライブデモをお届けしました。 スマートグラスでの音声問い合わせ、音声でキッチン工程を進める体験デモ 一つ目は スマートグラスによる店舗業務支援 です。店員がスマートグラスを装着し、「コーヒーはどこですか」「今日のセール品を教えて」と声で聞くだけで、 Amazon Nova 2 Sonic （Speech-to-Speech 統合モデル）と Amazon Bedrock AgentCore Gateway 経由の MCP Tools が連携して棚位置・在庫・セール情報を即座に音声とグラス表示で案内します。自店舗に在庫がなければ他店舗や EC サイトの在庫まで一声で案内し、タスク管理や英語対応、飲食店での予約確認・リマインド通知まで、スーパー・アパレル・飲食の 8 つのシナリオを体験いただきました。GPS やビーコンは不要、商品マスターと棚位置マッピングデータだけで実現できる導入ハードルの低さも、来場者への大きな訴求ポイントとなりました。併設した Agent Monitor で AI の思考プロセス（AG-UI）がリアルタイムに流れる様子は、このデモ最大の「おおっ」ポイントとして多くの注目を集めました。 詳細解説ブログ： スマートグラス × 音声 AI エージェントで実現する店舗業務のハンズフリー支援 二つ目は キッチン音声レシピナビ です。衛生手袋を着用したまま両手が塞がるセントラルキッチンの調理現場で、「次へ」「戻る」の音声だけでレシピ工程を進め、工程完了時には使用食材の在庫を自動減算。「玉ねぎがない」と伝えれば AI が代替食材を提案し、原材料チェックでは「玉ねぎ/タマネギ/オニオン」といった表記ゆれも吸収します。騒音の多い調理環境でも高精度な日本語音声認識を実現するアドバンスト・メディア社の AmiVoice と、 Amazon Bedrock AgentCore Runtime + Strands Agents による AI エージェントの組み合わせで、レシピ確認・在庫記録・HACCP 対応記録といった現場のデータ入力障壁を解消するアーキテクチャをご紹介しました。 「手が塞がっている環境でのデータ入力障壁」は食品製造に限らず、物流のピッキング、医療の手術室、製造の組立ラインなど多くの業界に共通する課題であり、幅広い業種のお客様から自社現場への適用イメージについてご相談をいただきました。 詳細解説ブログ： 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション お客様事例展示 — すでに現場で動いている、生成 AI コンセプトのご紹介だけではありません。展示エリアには、生成 AI を実際の現場で活用されているお客様 2 社の事例展示も併設しました。会期中はお客様ご自身による解説とその場での Q&A も行われ、実装の裏側や運用してみて初めて見えてきた気づきなど、現場の生の声を直接お聞きいただける貴重な機会となり、両日とも大変盛況となりました。 ユナイテッドアローズ様・カインズ様の事例展示。お客様ご自身による解説に質問が絶えませんでした 株式会社ユナイテッドアローズ 「Amazon Bedrock で実現 対話で深まる日報 AI」 日報につきものの「書く負担」と「うまく伝わらない」という相反する 2 つの悩みに対し、 Amazon Bedrock を活用した対話型 AI が店舗スタッフの思考整理を支援し、日報を自動で要約する PoC をご紹介いただきました。AI が深掘りの質問を投げかけることで報告内容の粒度と一貫性が高まり、本部の状況把握や店舗の行動改善にもつながる — 現場と本部、その双方の業務品質を高める生成 AI の活用事例に、多くの来場者が熱心に耳を傾け、質問が絶えない展示となりました。 本事例の元となっている AWS のサンプルアセット「SMART（Store Manager Agent for Retail Tech）」は GitHub で公開されており、どなたでもお試しいただけます。仕組みの詳細とユナイテッドアローズ様での取り組みは、以下のブログでご紹介しています。 詳細解説ブログ： 店舗の気づきを本部に届ける AI エージェント SMART のご紹介 — Amazon Bedrock AgentCore × Strands Agents によるユナイテッドアローズでの取り組み 株式会社カインズ 「AI で進化する顧客体験 Amazon Bedrock 活用事例」 ホームセンター大手のカインズ様には、 Amazon Bedrock の画像生成 AI を活用した店頭サイネージ「CAINZ Fitting Room」による、インテリアの疑似 “試着” 体験の取り組みをご紹介いただきました。サイネージ上に表示された部屋の写真の中の家具・ラグ・カーテンなどをカインズ製品の画像に AI で置き換えることで、購入前に「自分の部屋に置いたらどう見えるか」をイメージしやすくし、店頭での訴求力向上と売上・客単価の引き上げを狙う取り組みです。2026 年 4 月ごろから埼玉県の吉川美南店など 3 店舗で試験運用を開始されています。 「お客様が実際に欲しいのは、自分の部屋にあるところを見ること」というご担当者の言葉のとおり、将来的には顧客自身の部屋写真を使った体験への進化も構想されており、画像生成 AI を “購買体験そのもの” に組み込む小売業ならではの活用事例に、多くのお客様にお立ち寄りいただきました。 おわりに — ご来場ありがとうございました 「まだ早い」から「もう始めている」へ。幕張メッセの AWS Industries Zone での 2 日間を通じて強く感じたのは、流通小売・消費財・飲食業界の現場で、AI エージェントが業務の主役になっていく日が、すぐそこまで来ているということです。 昨年と比べ、マルチエージェントという概念が特別な説明なしに受け入れられるようになったこと。「AI エージェントで何ができるのか」という問いが、「自社のどの業務から始めるか」という問いへと変わりつつあること。そして、エージェントの思考プロセスの可視化や Human-in-the-Loop といった仕組みが、AI 活用への心理的なハードルを確かに下げていること。これらは、ブースで数多くのお客様と対話させていただいたからこそ得られた実感です。 今年のデモでお伝えしたかったのは、新しい技術を次々と取り込まなければならない、ということではありません。AWS のサービスを組み合わせれば、皆さまの中にすでに蓄積されてきた知識と経験を起点に、業務の “一部” から無理なく始めていける — そんなアイデアばかりをご用意しました。ご参加いただけなかった皆さまも、「試してみたい！」と思われた方は、ぜひ AWS の担当者までお気軽にご相談ください。 今後も、流通小売・消費財・飲食業界の皆さまに向けたイベントの企画と情報発信を継続していきます。それではまた、来年の Summit でお会いしましょう！ 関連ブログ（各デモの詳細解説） 【開催報告】AWS Summit Japan 2026 — 「AI ペルソナ達がビジネス課題解決を加速する」バーチャル AI エキスパート 【開催報告】AWS Summit Japan 2026 — AI で加速する製品イノベーション 〜マルチエージェントで実現する製品開発 【開催報告】AWS Summit Japan 2026 — AI エージェントで危機対応：小売×消費財の混乱を AI と人が即座に解決 【開催報告】AWS Summit Japan 2026 — 物流異常を Amazon Quick が自動解決：配送在庫の異常検知〜問合せまで一気通貫 【開催報告】AWS Summit Japan 2026 〜 Future of Agentic Commerce ブース スマートグラス × 音声 AI エージェントで実現する店舗業務のハンズフリー支援 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション 参考情報 AWS ブログ “流通小売” カテゴリー AWS ブログ “消費財” カテゴリー AWS 消費財・流通・小売業向けソリューション 紹介ページ 事前のご案内ブログ：AWS Summit Japan 2026 〜 流通小売・消費財・飲食業界向けブースのご案内 昨年の開催報告：【開催報告】AWS Summit Japan 2025 〜 流通小売消費財業界ブース 本ブログは AWS Japan のソリューションアーキテクト 山下 智之 が執筆しました。

2026 年 06 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS FinOps Agent (preview) AWS FinOps Agent は、クラウド環境全体に対して、コストを継続的にモニタリング、コスト異常を調査、コスト最適化機会の発見を行うフロンティアエージェントです。自然言語でコストに関して質問ができ、スケジューリングされたレポート作成やイベントトリガーによるコスト異常分析などが実行可能です。 資料（ PDF ）  対象者 AWS FinOps Agent の概要・ユースケースを知りたい方 AWS FinOps Agent の利用方法を知りたい方 効率的に FinOps を推進したい方 本 BlackBelt で学習できること AWS FinOps Agent の概要・ユースケースについて学んでいただけます AWS FinOps Agent の設定方法について学んでいただけます スピーカー 加須屋 悠己 テクニカルアカウントマネージャー Amazon RDS for Db2 へのマイグレーション戦略 本セミナーでは、Amazon RDS for Db2 へのマイグレーション戦略についてご紹介いたします。 マイグレーション戦略の重要性や、実際にご利用いただける機能やツールをご紹介していきます。 また、マイグレーションを成功に導くためのポイントについてもご案内いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 本セミナーでは、以下のような方を対象としています。 オンプレミス環境や Amazon Elastic Compute Cloud (Amazon EC2) 上の IBM Db2 から Amazon RDS for Db2 (RDS for Db2) へ移行を検討されている方 今後、RDS for Db2 のご利用をご検討されている方 本 BlackBelt で学習できること マイグレーション戦略の重要性 具体的なマイグレーション方法 マイグレーション成功のポイント スピーカー 松原 睦美 クラウドサポートエンジニア Amazon Bedrock AgentCore runtime Dive Deep Amazon Bedrcok AgentCore runtime は、AI エージェント実行のためのマネージドなホスティング基盤サービスとなっており、完全なセッション分離や認証管理、長時間実行などの便利な機能を持っております。 本セミナーでは Amazon Bedrock AgentCore runtime の基本および AgentCore runtime の各種機能、サンプルコード、お問い合わせでよくあるポイントについて解説しています。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから Amazon Bedrock AgentCore のご利用を検討している方 Amazon Bedrock AgentCore runtime の概要を把握されたい方 すでにエージェントのコードを持っており、AWS へのデプロイを検討している方 本 BlackBelt で学習できること Amazon Bedrock AgentCore runtime の基本および AgentCore runtime の各種機能、サンプルコード、お問い合わせでよくあるポイント スピーカー 花澤 周平 Cloud Support Engineer AWS Direct Connect 詳細編 〜オンプレミスとの冗長化接続〜 AWS Direct Connect を利用したオンプレミスと AWS 間の冗長化接続について解説します。要件に応じた冗長構成パターン、BGP によるトラフィックコントロール、AWS Site-to-Site VPN を用いたバックアップ経路、マルチリージョン構成、障害テスト手法、Amazon CloudWatch によるモニタリングまで、信頼性の高いハイブリッド接続設計に必要な知識を体系的にご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS を利用される予定のネットワーク担当者 AWS とオンプレミスのネットワーク設計を担当している方 AWS とオンプレミス間の冗長化設計について学びたい方 本 BlackBelt で学習できること AWS Direct Connect の冗長化構成のパターン AWS Direct Connect の障害テスト方法 AWS Direct Connect の CloudWatch モニタリング方法 スピーカー 齋藤 優弥 ソリューションアーキテクト Amazon GuardDuty Malware Protection for S3 Amazon GuardDuty Malware Protection for S3 は、S3 バケットにアップロードされたオブジェクトをスキャンし、マルウェアを検出する機能です。本セミナーでは、Amazon GuardDuty Malware Protection for S3 として、機能の概要、開始方法、また、本機能を用いた調査方法をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 S3 バケット内のマルウェア検出をご検討中の方 Amazon GuardDuty Malware Protection for S3 の機能や開始方法を知りたい方 本 BlackBelt で学習できること Amazon GuardDuty Malware Protection for S3 の機能や仕組みの理解 Amazon GuardDuty Malware Protection for S3 の開始方法について Amazon GuardDuty Malware Protection for S3 を使用した調査の流れについて スピーカー 岩垣 侑 クラウドサポートエンジニア AWS Network Firewall AWS Network Firewall の最新仕様を網羅的に解説する Black Belt セッションです。サービス概要から Firewall ポリシー設計、TLS インスペクション、主要アーキテクチャパターン（Egress/Ingress/East-West/ 複合構成）、モニタリング、クォータ、料金体系、コスト最適化まで幅広くカバーしています。 さらに 2025 年にリリースされた Transit Gateway ネイティブ統合や、プレビュー中の AWS Network Firewall Proxy についても紹介しており、新規導入から既存環境の設計見直しまで幅広くご活用いただける内容です。 資料（ PDF ） | 動画（ YouTube ） 対象者 本セッションは、これから AWS を利用予定でネットワークやセキュリティを担当される方、および既に AWS 環境のネットワーク・セキュリティの設計や運用を担当されている方を対象としています。 VPC、サブネット、ルートテーブルなど AWS ネットワーキングの基本概念を理解されていることを前提としており、 AWS Network Firewall の新規導入を検討されている方から、既存環境の設計見直しを行いたい方まで幅広くご活用いただける内容です。 本 BlackBelt で学習できること AWS Network Firewall の基本的な仕組みから、Firewall ポリシー・ルールグループの設計方針、TLS インスペクションの考慮点まで体系的に学ぶことができます。 また、Egress/Ingress/East-West/ 複合構成といった主要アーキテクチャパターンや、マルチ AZ ・対称ルーティングの設計ポイントを理解できます。 さらに、モニタリング手法、クォータ、料金体系とコスト最適化の考え方に加え、Transit Gateway ネイティブ統合や Network Firewall Proxy といった最新機能についても学習できます。 スピーカー 田中 優多 ソリューションアーキテクト AWS CloudHSM 基礎編 AWS CloudHSM は、FIPS 140-3 Level 3 に準拠したシングルテナントの汎用 HSM をクラウドで提供するサービスです。お客様のセキュリティやコンプライアンス要件への対応に活用いただけます。本セッションでは、AWS における鍵管理サービスの選び方、CloudHSM の基本概念やアーキテクチャ、クラスター構成のベストプラクティス、およびセットアップ手順についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 HSM を使用する要件があり、AWS CloudHSM の利用を検討している方 オンプレミスなど既存の HSM からクラウドへの移行を検討している方 AWS CloudHSM を使用中で、概念やベストプラクティスを再確認したい方 本 BlackBelt で学習できること AWS KMS と AWS CloudHSM の使い分けや、AWS CloudHSM が必要となる要件を理解できます クラスター構成、ユーザータイプ、鍵の生成・インポート・エクスポート、鍵の属性など基本概念を習得できます Multi-AZ 配置やバックアップ活用など、可用性・耐久性のベストプラクティスを学べます クラスターの作成から初期化・アクティブ化までのセットアップ手順を把握できます スピーカー 服部 創 クラウドサポートエンジニア AWS CloudHSM 実践編 AWS CloudHSM は、FIPS 140-3 Level 3 に準拠したシングルテナントの汎用 HSM をクラウドで提供するサービスです。本セッションでは、CloudHSM を用いたコード署名のユースケースを題材に、実装上のベストプラクティスやパフォーマンスの最適化手法、よくある質問とトラブルシューティングについて解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudHSM を用いたコード署名の実装方法を知りたい方 AWS CloudHSM を利用するアプリケーションの可用性やパフォーマンスを高めたい方 AWS CloudHSM の運用で発生しやすい問題とその対処法を知りたい方 本 BlackBelt で学習できること CloudHSM を使用したコード署名の具体的な流れや操作を確認できます リトライ実装、キーオブジェクトのキャッシュなど可用性のベストプラクティスやパフォーマンス最適化の手法を学べます HSM 台数の考え方、メンテナンス時の影響、キー耐久性チェックエラーなどよくある質問への回答を確認できます 接続エラーやパフォーマンス問題のトラブルシューティング手法を学べます スピーカー 沼田 裕太郎 クラウドサポートエンジニア

本記事は 2026 年 4 月 19 日 に公開された「 EngineLab AI: Production-ready AI for studios and creators on AWS 」を翻訳したものです。 スタジオは今、重大なジレンマに直面しています。AI ツールは制作ワークフローの加速を約束する一方で、導入にあたってはセキュリティ、知的財産 (IP) 保護、制作の安定性に関する現実的な懸念と向き合わなければなりません。本記事では、このトレードオフを解消するソリューションを紹介します。 ComfyUI のような AI ツールを活用すると、AI コンテンツ生成向けのオープンソースなノードベースのインターフェースを通じて、モデル、処理ツール、クリエイティブな操作を組み合わせ、本番グレードのワークフローとして複雑な AI 機能を視覚的に設計・制御できます。しかし、制作ワークフローの加速や新たな効率化をもたらす新興技術にありがちなように、リスクも伴います。急速に進化する AI の世界では、標準化、パイプライン統合、アプリケーションの安定性といった課題が生じます。セキュリティ面の懸念はさらに複雑です。使用するモデルの出所を把握して法的要件に対応しつつ、AI ワークフローを流れる IP を厳格なセキュリティ基準に従って保護する必要があるからです。モデルや関連アーティファクトを適切に審査・承認しなければ、未承認の、場合によっては悪意あるツールやコードが作業環境に持ち込まれるリスクがあります。 これまでクリエイターは、AI を本番環境に導入するにあたって、こうしたメリットとリスクのバランスを取ることを余儀なくされてきました。 AWS のメディア・エンターテインメント専門パートナーである EngineLab は、 EngineLab AI というマネージドデプロイメントプラットフォームを提供開始しました。AWS インフラストラクチャ上に構築され、ComfyUI などの AI アプリを安定した、セキュアで本番対応のツールセットとしてパッケージ化しています。メディア・エンターテインメント業界に特化して設計されており、ワークフローの特性を理解したうえで、ワークフローを高度に構築するユーザーから定型プロセスを活用したい一般ユーザーまで、チームのすべてのアーティストが強力な AI 機能を使えるようにします。 「スタジオからは、AI を本番環境で使いたいが、現状の不安定さとリスクは受け入れられないという声を聞いています。私たちは、そのハードルを取り除くプラットフォームを構築しています。業界が求めるセキュリティとコントロールを備えた形で、AI ツールをスタジオのワークフローに組み込んでいきます。」— Sam Reid、EngineLab 共同創業者 兼 CEO 本記事では、EngineLab AI でこれらの課題を解決する方法を紹介します。具体的には、完全なデータ主権を確保するために AWS アカウントへ直接デプロイする方法、最適な可用性とコストを実現するために AWS が提供するグローバル GPU リソースを活用する方法、そして IP を保護しながらワークフローに必要なクリエイティブな柔軟性を損なわないセキュリティ制御を統合する方法を説明します。 安定したスケーラブルな AI ワークフローの実現 スタジオにとって、高性能な GPU ハードウェアの調達はますます困難かつ高コストになっています。部品不足、価格上昇、オンプレミスインフラの維持管理にかかる負担により、AI ワークロードが必要とする GPU 容量を構築・維持することが難しくなっています。ハードウェアを調達できたとしても、多様なプロジェクトやチームにわたって安定的かつ効率的に割り当てるという課題が残ります。 ComfyUI の Web ベースアーキテクチャは、従来のリモートデスクトップソリューションに対して大きな優位性を持ちます。一般的なクラウドワークステーションは Virtual Desktop Infrastructure セッションを使用し、キーボード、マウス、Wacom タブレットなどの入力操作を含むデスクトップ画面をリモートからローカルクライアントにストリーミングします。一方、ComfyUI はローカルの Web ブラウザ上で動作し、処理負荷の高い演算はサーバー側で実行されます。ユーザーインターフェースはレイテンシーの影響を受けないため、重要なアーキテクチャ上の優位性が生まれます。つまり、レイテンシーを気にせずコンピューティングリソースをリモートでプロビジョニングできるのです。 EngineLab AI はこの柔軟性を活かし、 AWS グローバルインフラストラクチャ を動的に活用します。利用可能な Amazon Elastic Compute Cloud (Amazon EC2) 容量 (コンピューティング集約型ワークロード向けにオンデマンドの GPU インスタンスを提供する AWS のスケーラブルな仮想サーバーサービス) を持つ AWS リージョン (地理的に分離された AWS データセンターのクラスター) を活用します。これにより EngineLab AI は、 GPU 搭載の Amazon EC2 インスタンスタイプ のグローバルプールにアクセスできます。Blackwell、Ada Lovelace、Ampere などの NVIDIA GPU アーキテクチャを幅広くサポートし、vCPU 数やメモリ構成も多様なため、複数のリージョンにわたって可用性を高め、固定のローカルハードウェアをめぐるリソースの取り合いを減らせます。Amazon EC2 インスタンスを活用することで、AI ワークフローの固定費を削減し、必要なときに必要なだけ GPU リソースにオンデマンドでアクセスできます。 また、現在のタスクに合わせてコンピューティングリソースを最適化できます。クラウドインフラストラクチャが各ジョブに適切なリソースを動的に割り当てられるなら、すべてのアーティストがデスクの下に高性能グラフィックカードを置く必要はありません。GPU リソースを複数ユーザーで分割することでコストをさらに削減でき、パフォーマンスを犠牲にすることなく、オンプレミスハードウェアの固定費や運用負担なしに、大規模な GPU コンピューティングへの安定したアクセスを実現します。 EngineLab AI: スタジオとクリエイター向けマネージドプラットフォーム EngineLab は AWS グローバルインフラストラクチャを基盤に、メディア・エンターテインメント向けに一から設計されたマネージドプラットフォームを開発しました。AI ツールを本番環境に導入する際にスタジオが直面する固有の課題に対応しています。 図 1 に示すように、プロジェクト管理インターフェースではワークフローを一元的に把握できます。管理者はここから、アクティブなワークフローの確認、リソース使用状況の監視、アーティストのアクセス管理を行えます。 図 1: EngineLab AI のプロジェクト管理インターフェース。管理者がワークフローを追跡し、リソースを監視し、アーティストのアクセスを管理する様子を示しています 複雑な操作なしに即座にセッションを開始 AI ツールを使うためにクラウドインフラストラクチャの知識は不要です。EngineLab AI では、アプリを選択して起動するだけで AI アプリを使い始められます。適切なコンピューティングのプロビジョニング、環境の読み込み、安定したセッションの提供まで、すべてが自動で処理されます。セットアップも、トラブルシューティングも、待ち時間も不要です。スタジオはプロジェクト単位で作業を整理し、アーティストは必要なアプリをその中で起動するだけです。締め切りのある作業では、セッションが起動しなかったり途中で止まったりすることは許されません。一貫性と信頼性のある操作性が重要です。 アーティスト UI: すべてのアーティストが使える高度なワークフロー どのスタジオにも、複雑なノードグラフを使って高度なワークフローを構築する ComfyUI のエキスパート (技術的なパワーユーザー) がいます。しかし、大規模な運用では、アーティストは自分がエキスパートになることなく、そうしたワークフローの恩恵を受けたいと考えるのが一般的です。Artist UI は、入力・プロンプト・出力といった基本的なエンドポイントを提供することで、このギャップを埋めます。アーティストは画像をアップロードし、求めるものを言葉で伝えるだけで結果を得られます。ノードグラフを操作することなく、裏側でエキスパートのワークフローが動いているのです。 これはスタジオにとって重要な課題、すなわち IP の保護も解決します。カスタムワークフローは実質的な競争優位性を持つ資産であり、ワークフローとユーザーの間に何も介在しなければ、フリーランサーが次の仕事先にそれを持ち出すことを防ぐ手段がありません。Artist UI は境界として機能し、スタジオ全体がその機能を利用できる一方で、内部のワークフローが外部に露出することはありません。 データ主権: セキュリティの確保 本ソリューションはお客様自身の AWS アカウントおよび環境にのみデプロイされるため、包括的な制御とデータ主権が確保されます。顧客データがトレーニングに使用されることはなく、スタジオが制作したものはそのスタジオのものとして扱われます。その利用方法について曖昧さは一切ありません。多くのプラットフォームがデータの取り扱いについて意図的に曖昧な表現を用いる中、EngineLab AI は意図的に明確な姿勢を取っています。またこのアプローチは、コミュニティが開発した AI ワークフローを実行する際に生じるセキュリティリスク、特に不正かつ悪意のあるコードインジェクションへの対策も含んでいます。厳格なデータ要件を持つ主要クライアントと取引するスタジオにとって、これは本番環境に不可欠な要素です。 モデルトレーニング: セキュアな環境と完全な制御 プラットフォームにはトレーニングアプリが含まれており、スタジオは独自のコンテンツを取り込んで、ファインチューニング済みの基盤モデルや、特定のパラメーターのみを変更する Low-Rank Adaptation (LoRA) をトレーニングできます。LoRA はスタイルのカスタマイズにおいて、より高速かつコスト効率に優れています。トレーニングはプラットフォーム環境内で実行されるため、トレーニングデータがプライベートアカウントの外に出ることはありません。トレーニング完了後、カスタムモデルは ComfyUI ワークフローから直接利用可能になり、モデルとその作成に使用したデータの両方をスタジオが完全に管理します。これは、カスタム AI モデルの能力を活用しながらも、独自データが他の場所でのモデルトレーニングや競合他社への利益供与に使われるリスクを避けたいスタジオの重要なニーズに応えるものです。 完全な制御: アクセス管理とプロベナンス 管理者は最小権限モデルによってプラットフォームをきめ細かく制御できます。ユーザーとリソースには各タスクの実行に必要な権限のみが付与され、エキスパートと管理者はモデルのアップロードと承認が可能な一方、その他のユーザーのアクセスは制限されます。ベンダー固有の承認にも対応しており、特定のプロジェクトでは承認済みモデルのみが使用されます。これは、厳格なコンプライアンス要件を持つクライアントと取引するスタジオにとって不可欠な要件です。包括的な監査証跡によってプロジェクトごとのモデル使用状況を追跡し、クライアントへの報告やコンプライアンス検証に活用できます。また、プロベナンス追跡により、モデルの出所と組織全体での使用状況を正確に把握できます。 図 2 の AI Model Library インターフェイスは、モデルと LoRA の分類・承認・管理を一元的に行うビューを提供します。 図 2: EngineLab AI の AI Model Library 管理ページのスクリーンショット パイプライン統合: スタジオワークフロー全体でのコンピューティング EngineLab は、パイプラインに関する深い専門知識とハイエンドなクリエイティブワークフローにおける豊富な経験を持つチームをプラットフォームに結集しています。アーティストの時間が最も重要であるという認識のもと、チームは ComfyUI に関連する GPU および CPU コンピューティングを既存のレンダーファームワークフローに直接統合する取り組みを進めています。これには、ワークフローの需要に応じてコンピューティングリソースを自動的にスケールする完全マネージド型レンダーファームサービス AWS Deadline Cloud を活用しています。この統合により、ComfyUI フロントエンドは軽量なマシンで動作しながら、重い GPU タスクをレンダーファームにオフロードでき、インターフェイスと処理能力を切り離すことが可能になります。これは、ツールを本番環境に統合するための知見を持つ EngineLab が、その複雑さを引き受けることでスタジオの負担を軽減する、自然な進化の形です。 「私たちは EngineLab がプラットフォームを開発する過程でパートナーシップを築いてきました。社内にはすでに強力な ComfyUI の専門知識がありますが、スタジオ全体にそれをスケールできる、管理されたセキュアな環境、そしてクライアント業務に必要な制御とガバナンスを備えた環境こそ、私たちが求めていたものです。」– Sean Costelloe、マネージング・ディレクター、Selected Works まとめ EngineLab AI は ComfyUI を実験的なツールから本番対応のプラットフォームへと進化させ、スタジオが AI ツールを導入する際に直面する重要な課題に対応します。スタジオの AWS アカウントに直接デプロイすることで、包括的なデータ主権とセキュリティを確保しながら、AWS が提供するグローバルな GPU リソースを活用して最適な可用性と価格を実現します。スタジオは従来のアプローチに伴うリスクやコストなしに、本番グレードの AI 機能を手に入れられます。安定してセキュアな AI 生成へのアクセス、クライアント業務に必要な制御、そして使い慣れたワークフローへの統合が実現します。 AWS インフラストラクチャの詳細 EngineLab AI は、コンピューティング集約型のクリエイティブワークロード向けに設計された実績ある AWS サービス上に構築されています。 Amazon EC2 – AI およびレンダリングワークロード向け GPU インスタンスを備えたスケーラブルな仮想サーバー AWS Deadline Cloud – コンピューティングリソースのスケーリングに対応したマネージドレンダースケジューリングサービス 次のステップ AWS およびクリエイティブワークフローへのクラウドインフラストラクチャ活用の開始方法については、AWS アカウントチームにお問い合わせいただくか、 AWS for Media & Entertainment をご覧ください。 EngineLab AI にアクセスして、AWS 上でセキュアかつスケーラブルな AI ワークフローをスタジオで活用する方法をご確認ください。 Andy Hayes Andy Hayesは、AWSのシニア・ビジュアル・コンピューティング・ソリューション・アーキテクトです。VFX（視覚効果）とアニメーションの分野で20年にわたる経験を持ち、芸術・科学・技術の融合によって魅力的な映像を生み出すことに情熱を注いでいます。 Sam Reid SamはEngineLabのCEOであり、世界初となる完全クラウドネイティブなクリエイティブスタジオの立ち上げを主導しました。Untold StudiosではCTOとしてインフラをゼロから構築し、ロンドン、ロサンゼルス、ムンバイに拠点を置く500名以上のクリエイターを支える体制を整えました。現在は、テクノロジーを通じてクリエイティブなインパクトを生み出すことに注力し、EngineLabのビジョンと成長を牽引しています。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本記事は 2026 年 6 月 30 日 に公開された「 How Outpost VFX Uses AWS to Accelerate AI Model Training for Visual Effects 」を翻訳したものです。 Outpost VFX の Tim Chauncey と Dheeraj Bhadani との共同執筆です。 ビジュアルエフェクト (VFX) 向けの AI モデルトレーニングには数週間を要することがあり、制作スケジュールのボトルネックになりがちです。英国、カナダ、インドにスタジオを構え、高品質な映画やエピソードコンテンツを手がける Outpost VFX にとって、1 日の遅延がクライアントへの納品やプロジェクトスケジュールに直接影響します。 本記事では、Outpost VFX が AWS インフラを活用してフェイスリプレースメントのワークフローを刷新し、トレーニング速度を最大 8 倍に向上させた方法、シングル GPU の制約を克服するために実装した技術アーキテクチャ、そして AWS マルチ GPU トレーニングで得られた具体的な成果について紹介します。 課題: AI トレーニングにおけるシングル GPU のボトルネック VFX 制作における従来のフェイスリプレースメントワークフローでは、監督承認用の初期バージョンを作成するだけで、コンポジットや専門的なビューティ・デエイジング作業に 5 日以上かかります。この手法は有効ではあるものの、制作スケジュールで最も重要な反復承認プロセスの初期段階でボトルネックが生じます。VFX の現場では、AI トレーニングの遅さがそのまま納期遅延、コスト増加、クライアントへのフィードバックサイクルの長期化につながります。 Outpost VFX は、撮影現場の映像を学習してフェイスリプレースメントを高速化できる AI モデルを独自に開発していました。しかし、シングル GPU のコンピューティング制約により効率が頭打ちになっていました。既存のフェイススワップツールは同時に 1 つの GPU しか使えず、モデルトレーニングで利用できるビデオランダムアクセスメモリ (VRAM) と処理能力が限られていました。そのため、AI 支援アプローチの潜在能力を十分に引き出せずにいました。 設計上の考慮事項 Outpost VFX は、AI ワークフローを最適化するうえで技術的に重要な要件を 3 つ特定しました。 コンピューティングのスケーラビリティ – 意味のある効率改善を実現するには、フェイスリプレースメントモデルのトレーニングを複数の GPU に並列化する必要がありました。シングル GPU によるトレーニングでは、モデルの反復サイクルに毎回数週間の遅延が生じていました。 インフラのセキュリティ – 2022 年から AWS を利用し、完全仮想化された技術スタックを運用する Outpost VFX にとって、機密性の高い制作データを扱うソリューションは自社の厳格なセキュリティ要件を満たす必要がありました。 パフォーマンスの最適化 – 単純な速度向上にとどまらず、より大規模なデータセットや高解像度画像にも対応できるアーキテクチャが、出力品質の向上に不可欠でした。 これらの要件に対応するため、Outpost VFX は AWS Generative AI Innovation Center の開発者と連携しました。同チームは Outpost VFX の技術部門と一体となって AI 学習アルゴリズムの刷新に取り組みました。AWS Generative AI Innovation Center は、ストラテジスト、データサイエンティスト、エンジニア、ソリューションアーキテクトで構成されるチームで、顧客とともに生成 AI の力を活かしたカスタムソリューションを段階的に構築します。チームへの参加方法については、 Generative AI Innovation Center のページをご覧ください。 アーキテクチャの実装 このソリューションでは、Outpost VFX の既存フェイススワップモデルのコードベースを改修し、複数 GPU での分散トレーニングに対応させました。実装には、Outpost VFX の既存インフラ要件に沿った、分離されたセキュアなクラウド環境内に AWS マルチ GPU の Amazon Elastic Compute Cloud (Amazon EC2) P5 インスタンスを使用しました。 もともと Outpost VFX は、GPU アクセラレーション対応のワークステーションでフェイススワップモデルをトレーニングしていました。俳優とスタントダブルの小規模なデータセットを収集し、RTX 3090 GPU でベースモデルをファインチューニングする手法です。この方法は機能していたものの、ファインチューニング 1 回あたり約 1〜2 週間かかるなど、トレーニング時間が長いという課題がありました。また、クラウドワークステーションの管理オーバーヘッドを考えると、スケールアップも容易ではありませんでした。そこで、P5 インスタンスでのトレーニングを検討することになりました。 P5 インスタンスには、分散トレーニングワークロード向けに設計された NVIDIA H100 GPU が搭載されています。GPU 間の通信に PCIe を使用する G シリーズインスタンスとは異なり、P5 インスタンスは NVLink インターコネクトを備えており、勾配同期に必要な帯域幅が大幅に向上しています。これは複数 GPU でのトレーニングにおいて重要な要素です。また、H100 の 14,592 個の CUDA コアと 80 GB の高帯域幅 HBM3 メモリは、従来のローカル RTX 3090 環境から大きく進化しています。 Outpost VFX は Generative AI Innovation Center と協力し、P5 インスタンス上でモデルを動作させました。6 週間のアドバイザリー期間を通じて、AWS のサイエンティストがモデルコードを PyTorch Distributed Data Parallel (DDP) トレーニング戦略に対応するよう変換しました。DDP は、各 GPU にモデルの重みをコピーする並列化手法で、各トレーニングバッチで処理できる画像数を増やせます。バッチあたりの画像数が増えることで、トレーニングプロセスが直接高速化されます。 技術的な実装内容には、フェイスリプレースメントモデルトレーニングのマルチ GPU 並列化、機密性の高い制作データに対応したセキュリティアーキテクチャの強化、そして Outpost VFX の既存 AWS ベース技術スタックとの統合が含まれます。Outpost VFX は AI パイプラインの進化を続けており、今後は Amazon SageMaker AI のマネージドトレーニング、モデルバージョニング、ホスト型推論などのサービスを活用して、グローバルなスタジオ全体でのモデル開発・デプロイをさらに効率化できると見込んでいます。 パフォーマンス改善の測定 マルチ GPU トレーニングの速度向上を検証するため、Outpost VFX はトレーニング用の画像データセットを収集し、モデルのハイパーパラメータを固定したうえで、特定の損失閾値に達するまでの時間を計測しました。ベースラインは G5 インスタンス上のシングル GPU とし、P5 インスタンスでの結果と比較しました。 Outpost VFX と AWS の共同開発により、フェイスリプレースメントモデルの学習速度は最大 8 倍向上しました。このパフォーマンス向上は反復サイクルの短縮に直結し、初期バージョンに対する監督承認プロセスをより迅速に進められるようになりました。高解像度画像や大規模データセットでのモデルトレーニングが可能になったことで、出力品質も向上しました。特筆すべき点として、初回レビュー用のクライアントへの v001 納品にかかる期間が、従来の 1〜2 週間から 2 日間に短縮されました。 「並列化されたワークフローと複数のハイエンド GPU を同時に活用できるようになったことで、イテレーションのスピードが大幅に向上しました」 と Outpost VFX の CTO である Tim Chauncey は述べています。 「VFX の仕事においてイテレーションの速度は非常に重要であり、このアーキテクチャは将来の開発に向けて、より堅牢でスケーラブルな基盤を提供しています。」 今後の改善点としては、画像出力の品質向上が考えられます。Outpost はモデルに渡す画像の解像度を上げ、より多くの VRAM を搭載した新世代の Amazon EC2 P5 インスタンスを使用することで、より大きな画像や大規模なデータセットを処理できます。 まとめ AWS に最適化されたアーキテクチャにより、Outpost VFX はハイエンド VFX 制作に求められるセキュリティとスケーラビリティを維持しながら、AI を活用したフェイスリプレースメント機能をクライアントに提供できるようになりました。ローカルのコンシューマー向け NVIDIA GPU からエンタープライズ向け NVIDIA GPU への移行を含む並列化ワークフローアーキテクチャは、Outpost VFX のグローバルスタジオ運営における AI ツールの開発とスケーリングの基盤となっています。 「私が最も興奮しているのは、これらのモデルがもはや研究段階の実験ではなく、現代の VFX パイプラインに不可欠な要素になりつつあるという点です」 と Outpost VFX のリードソフトウェアアーキテクトである Dheeraj Bhadani は述べています。 「マルチ GPU アクセラレーションは、次世代のクリエイティブツールが構築される基盤です。」 次のステップ AI トレーニングワークフローの高速化を検討している場合は、以下のステップを参考にしてください。 現在の GPU 使用率を評価する: シングル GPU の制約がトレーニングのパフォーマンスを制限していないか確認する マルチ GPU アーキテクチャを検討する: Amazon EC2 P5 インスタンスは、分散トレーニングワークロードに対してスケーラブルなコンピューティングを提供する AWS Generative AI Innovation Center に相談する: Outpost VFX のトレーニングワークフロー並列化を支援したチームに問い合わせる ユースケースとインフラ要件に合わせた分散トレーニング戦略を実装することで、同様の成果を得ることができます。 謝辞 著者一同、本プロジェクトにご協力いただいた Josh Chappatte、Laksh Puri、Ruchi Bhatia の各氏に感謝いたします。 著者について Alex Newton Alex は AWS Generative AI Innovation Center のデータサイエンティストとして、生成 AI と機械学習を活用してお客様の複雑な課題解決を支援しています。最先端の ML ソリューションを現実の課題に応用することに情熱を持っています。 Hanno Bever Hanno はロンドンを拠点とする AWS Generative AI Innovation Center のシニア機械学習エンジニアです。Amazon での 6 年間で、あらゆる業界のお客様が AWS 上で機械学習ワークロードを実行できるよう支援してきました。AWS Trainium および GPU インスタンスにおける分散モデルトレーニングのスケーリングと推論の最適化を専門としています。 Stephen Smith Stephen は英国を拠点とする AWS のシニアソリューションアーキテクトです。さまざまな業界のエンタープライズ顧客と連携し、モダンでスケーラブル、かつコスト効率の高いクラウドアーキテクチャの設計を支援しています。AWS での 7 年以上の経験を持ち、最新のデータおよび AI ソリューションの導入を通じてお客様のビジネス課題を解決することに情熱を注いでいます。 Tim Chauncey Tim は 2022 年より英国に本社を置く Outpost VFX の最高技術責任者 (CTO) を務めています。在任中、スタジオによるハイエンドの映画・エピソード作品の制作方法に大きな変革をもたらし、従来のオンプレミス環境から AWS 上でグローバルに稼働する統合クラウドインフラへの移行を成功させました。現在は、最先端の ML プロダクションツールとエージェントシステムを Outpost の制作ワークフローに統合するチームを率いています。 Dheeraj Bhadani Dheeraj は Outpost VFX のリードソフトウェアアーキテクトであり、VFX およびアニメーション業界で 20 年以上の経験を持ちます。技術革新に精通したベテランアーキテクトとして、Academy Sci-Tech Awards で表彰された技術的進歩に重要な役割を果たしてきました。構想から実装まで、高度に分散化されたスケーラブルで耐障害性の高いシステムの設計・構築に情熱を持っています。近年は、デジタルコンテンツ制作アプリケーションに統合されるプロダクショングレードの AI・機械学習ツールや、スタンドアロンソリューションとして展開されるシステムのアーキテクチャ設計と開発に注力しています。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本記事は 2026 年 6 月 30 日 に公開された「 How Outpost VFX Uses AWS to Accelerate AI Model Training for Visual Effects 」を翻訳したものです。 Outpost VFX の Tim Chauncey と Dheeraj Bhadani との共同執筆です。 ビジュアルエフェクト (VFX) 向けの AI モデルトレーニングには数週間を要することがあり、制作スケジュールのボトルネックになりがちです。英国、カナダ、インドにスタジオを構え、高品質な映画やエピソードコンテンツを手がける Outpost VFX にとって、1 日の遅延がクライアントへの納品やプロジェクトスケジュールに直接影響します。 本記事では、Outpost VFX が AWS インフラを活用してフェイスリプレースメントのワークフローを刷新し、トレーニング速度を最大 8 倍に向上させた方法、シングル GPU の制約を克服するために実装した技術アーキテクチャ、そして AWS マルチ GPU トレーニングで得られた具体的な成果について紹介します。 課題: AI トレーニングにおけるシングル GPU のボトルネック VFX 制作における従来のフェイスリプレースメントワークフローでは、監督承認用の初期バージョンを作成するだけで、コンポジットや専門的なビューティ・デエイジング作業に 5 日以上かかります。この手法は有効ではあるものの、制作スケジュールで最も重要な反復承認プロセスの初期段階でボトルネックが生じます。VFX の現場では、AI トレーニングの遅さがそのまま納期遅延、コスト増加、クライアントへのフィードバックサイクルの長期化につながります。 Outpost VFX は、撮影現場の映像を学習してフェイスリプレースメントを高速化できる AI モデルを独自に開発していました。しかし、シングル GPU のコンピューティング制約により効率が頭打ちになっていました。既存のフェイススワップツールは同時に 1 つの GPU しか使えず、モデルトレーニングで利用できるビデオランダムアクセスメモリ (VRAM) と処理能力が限られていました。そのため、AI 支援アプローチの潜在能力を十分に引き出せずにいました。 設計上の考慮事項 Outpost VFX は、AI ワークフローを最適化するうえで技術的に重要な要件を 3 つ特定しました。 コンピューティングのスケーラビリティ – 意味のある効率改善を実現するには、フェイスリプレースメントモデルのトレーニングを複数の GPU に並列化する必要がありました。シングル GPU によるトレーニングでは、モデルの反復サイクルに毎回数週間の遅延が生じていました。 インフラのセキュリティ – 2022 年から AWS を利用し、完全仮想化された技術スタックを運用する Outpost VFX にとって、機密性の高い制作データを扱うソリューションは自社の厳格なセキュリティ要件を満たす必要がありました。 パフォーマンスの最適化 – 単純な速度向上にとどまらず、より大規模なデータセットや高解像度画像にも対応できるアーキテクチャが、出力品質の向上に不可欠でした。 これらの要件に対応するため、Outpost VFX は AWS Generative AI Innovation Center の開発者と連携しました。同チームは Outpost VFX の技術部門と一体となって AI 学習アルゴリズムの刷新に取り組みました。AWS Generative AI Innovation Center は、ストラテジスト、データサイエンティスト、エンジニア、ソリューションアーキテクトで構成されるチームで、顧客とともに生成 AI の力を活かしたカスタムソリューションを段階的に構築します。チームへの参加方法については、 Generative AI Innovation Center のページをご覧ください。 アーキテクチャの実装 このソリューションでは、Outpost VFX の既存フェイススワップモデルのコードベースを改修し、複数 GPU での分散トレーニングに対応させました。実装には、Outpost VFX の既存インフラ要件に沿った、分離されたセキュアなクラウド環境内に AWS マルチ GPU の Amazon Elastic Compute Cloud (Amazon EC2) P5 インスタンスを使用しました。 もともと Outpost VFX は、GPU アクセラレーション対応のワークステーションでフェイススワップモデルをトレーニングしていました。俳優とスタントダブルの小規模なデータセットを収集し、RTX 3090 GPU でベースモデルをファインチューニングする手法です。この方法は機能していたものの、ファインチューニング 1 回あたり約 1〜2 週間かかるなど、トレーニング時間が長いという課題がありました。また、クラウドワークステーションの管理オーバーヘッドを考えると、スケールアップも容易ではありませんでした。そこで、P5 インスタンスでのトレーニングを検討することになりました。 P5 インスタンスには、分散トレーニングワークロード向けに設計された NVIDIA H100 GPU が搭載されています。GPU 間の通信に PCIe を使用する G シリーズインスタンスとは異なり、P5 インスタンスは NVLink インターコネクトを備えており、勾配同期に必要な帯域幅が大幅に向上しています。これは複数 GPU でのトレーニングにおいて重要な要素です。また、H100 の 14,592 個の CUDA コアと 80 GB の高帯域幅 HBM3 メモリは、従来のローカル RTX 3090 環境から大きく進化しています。 Outpost VFX は Generative AI Innovation Center と協力し、P5 インスタンス上でモデルを動作させました。6 週間のアドバイザリー期間を通じて、AWS のサイエンティストがモデルコードを PyTorch Distributed Data Parallel (DDP) トレーニング戦略に対応するよう変換しました。DDP は、各 GPU にモデルの重みをコピーする並列化手法で、各トレーニングバッチで処理できる画像数を増やせます。バッチあたりの画像数が増えることで、トレーニングプロセスが直接高速化されます。 技術的な実装内容には、フェイスリプレースメントモデルトレーニングのマルチ GPU 並列化、機密性の高い制作データに対応したセキュリティアーキテクチャの強化、そして Outpost VFX の既存 AWS ベース技術スタックとの統合が含まれます。Outpost VFX は AI パイプラインの進化を続けており、今後は Amazon SageMaker AI のマネージドトレーニング、モデルバージョニング、ホスト型推論などのサービスを活用して、グローバルなスタジオ全体でのモデル開発・デプロイをさらに効率化できると見込んでいます。 パフォーマンス改善の測定 マルチ GPU トレーニングの速度向上を検証するため、Outpost VFX はトレーニング用の画像データセットを収集し、モデルのハイパーパラメータを固定したうえで、特定の損失閾値に達するまでの時間を計測しました。ベースラインは G5 インスタンス上のシングル GPU とし、P5 インスタンスでの結果と比較しました。 Outpost VFX と AWS の共同開発により、フェイスリプレースメントモデルの学習速度は最大 8 倍向上しました。このパフォーマンス向上は反復サイクルの短縮に直結し、初期バージョンに対する監督承認プロセスをより迅速に進められるようになりました。高解像度画像や大規模データセットでのモデルトレーニングが可能になったことで、出力品質も向上しました。特筆すべき点として、初回レビュー用のクライアントへの v001 納品にかかる期間が、従来の 1〜2 週間から 2 日間に短縮されました。 「並列化されたワークフローと複数のハイエンド GPU を同時に活用できるようになったことで、イテレーションのスピードが大幅に向上しました」 と Outpost VFX の CTO である Tim Chauncey は述べています。 「VFX の仕事においてイテレーションの速度は非常に重要であり、このアーキテクチャは将来の開発に向けて、より堅牢でスケーラブルな基盤を提供しています。」 今後の改善点としては、画像出力の品質向上が考えられます。Outpost はモデルに渡す画像の解像度を上げ、より多くの VRAM を搭載した新世代の Amazon EC2 P5 インスタンスを使用することで、より大きな画像や大規模なデータセットを処理できます。 まとめ AWS に最適化されたアーキテクチャにより、Outpost VFX はハイエンド VFX 制作に求められるセキュリティとスケーラビリティを維持しながら、AI を活用したフェイスリプレースメント機能をクライアントに提供できるようになりました。ローカルのコンシューマー向け NVIDIA GPU からエンタープライズ向け NVIDIA GPU への移行を含む並列化ワークフローアーキテクチャは、Outpost VFX のグローバルスタジオ運営における AI ツールの開発とスケーリングの基盤となっています。 「私が最も興奮しているのは、これらのモデルがもはや研究段階の実験ではなく、現代の VFX パイプラインに不可欠な要素になりつつあるという点です」 と Outpost VFX のリードソフトウェアアーキテクトである Dheeraj Bhadani は述べています。 「マルチ GPU アクセラレーションは、次世代のクリエイティブツールが構築される基盤です。」 次のステップ AI トレーニングワークフローの高速化を検討している場合は、以下のステップを参考にしてください。 現在の GPU 使用率を評価する: シングル GPU の制約がトレーニングのパフォーマンスを制限していないか確認する マルチ GPU アーキテクチャを検討する: Amazon EC2 P5 インスタンスは、分散トレーニングワークロードに対してスケーラブルなコンピューティングを提供する AWS Generative AI Innovation Center に相談する: Outpost VFX のトレーニングワークフロー並列化を支援したチームに問い合わせる ユースケースとインフラ要件に合わせた分散トレーニング戦略を実装することで、同様の成果を得ることができます。 謝辞 著者一同、本プロジェクトにご協力いただいた Josh Chappatte、Laksh Puri、Ruchi Bhatia の各氏に感謝いたします。 著者について Alex Newton Alex は AWS Generative AI Innovation Center のデータサイエンティストとして、生成 AI と機械学習を活用してお客様の複雑な課題解決を支援しています。最先端の ML ソリューションを現実の課題に応用することに情熱を持っています。 Hanno Bever Hanno はロンドンを拠点とする AWS Generative AI Innovation Center のシニア機械学習エンジニアです。Amazon での 6 年間で、あらゆる業界のお客様が AWS 上で機械学習ワークロードを実行できるよう支援してきました。AWS Trainium および GPU インスタンスにおける分散モデルトレーニングのスケーリングと推論の最適化を専門としています。 Stephen Smith Stephen は英国を拠点とする AWS のシニアソリューションアーキテクトです。さまざまな業界のエンタープライズ顧客と連携し、モダンでスケーラブル、かつコスト効率の高いクラウドアーキテクチャの設計を支援しています。AWS での 7 年以上の経験を持ち、最新のデータおよび AI ソリューションの導入を通じてお客様のビジネス課題を解決することに情熱を注いでいます。 Tim Chauncey Tim は 2022 年より英国に本社を置く Outpost VFX の最高技術責任者 (CTO) を務めています。在任中、スタジオによるハイエンドの映画・エピソード作品の制作方法に大きな変革をもたらし、従来のオンプレミス環境から AWS 上でグローバルに稼働する統合クラウドインフラへの移行を成功させました。現在は、最先端の ML プロダクションツールとエージェントシステムを Outpost の制作ワークフローに統合するチームを率いています。 Dheeraj Bhadani Dheeraj は Outpost VFX のリードソフトウェアアーキテクトであり、VFX およびアニメーション業界で 20 年以上の経験を持ちます。技術革新に精通したベテランアーキテクトとして、Academy Sci-Tech Awards で表彰された技術的進歩に重要な役割を果たしてきました。構想から実装まで、高度に分散化されたスケーラブルで耐障害性の高いシステムの設計・構築に情熱を持っています。近年は、デジタルコンテンツ制作アプリケーションに統合されるプロダクショングレードの AI・機械学習ツールや、スタンドアロンソリューションとして展開されるシステムのアーキテクチャ設計と開発に注力しています。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

2026年6月10日〜12日、AWS Japan オフィスにて「AI-DLC UnicornGym」を開催しました。参加いただいたのは、自動車部品・システムのグローバルメガサプライヤー Astemo 。SDVソリューション開発本部と技術開発本部から44名が集まり、7チームが実業務テーマでAI駆動開発を3日間体験しました。 AI-DLC の全体像については「 AI駆動開発ライフサイクル（AI-DLC） 」をご覧ください。 なぜ Astemo が AI-DLC に取り組んだのか 「これまでの成功体験をアンラーンし、自己破壊をしてほしい」 ワークショップ冒頭、UnicornGym のゴールとして参加者に投げかけられた言葉です。自動車のソフトウェア定義化（SDV）が加速する中、エグゼクティブは「これまでにない生産性」を目標に掲げ、最重要ミッションは技術開発ではなく 全従業員の行動変容 であると明言しました。44 名の参加者は、その変革の起爆剤として位置づけられています。 自動車業界では品質基準やプロセスが厳格に定義されており、新しい開発手法の導入にはどうしても慎重になります。「生成 AI は使ってみたが思ったようにいかない」「自分で書いた方が早い」という声も現場にはありました。今回の Unicorn Gym は、全社展開に向けた行動変容のきっかけづくりとして企画しました。 3日間で何をしたのか 1日目は Inception（構想）です。各チームが持ち込んだ実業務テーマに対し、Claude Code との対話でビジネス意図をユーザーストーリーに落とし込みます。AI が生成したモック画面をチーム全員で見ながら「これが欲しかったもの？」「ここは違う」と認識を揃えていきます。テキストだけでは抽象度が高すぎて合意に時間がかかりますが、目に見える画面があると議論が具体化し、意思決定のスピードが格段に上がりました。 2〜3日目は Construction（構築）です。前日の要件をもとに Claude Code が設計・コードを提案し、チームで集中的に実装を進めます。人間の役割は「コードを書く」から「レビューと意思決定」に変わり、AI の成果物を次々にジャッジしていきます。AI の実装スピードが速いため、むしろ人間同士の認識合わせや意思決定がボトルネックになる場面もありました。 全チームが自社の実課題を持ち込みました。架空のお題ではなく「普段困っていること」をそのまま3 日間でプロトタイプにする形式が、参加者の本気度と成果物の実用性を引き上げました。 成果 ワークショップ後のアンケートは、「同僚にも薦めたい」の推奨度は 4.88/5.0、「自分の働き方が変わると感じた」は 4.67/5.0 という結果でした。 7チームのテーマは、組込みソフトウェアのモデル解析、開発環境の構築、テスト仕様書の自動生成、セキュリティツールの評価自動化など多岐にわたりました。いずれも「今まさに現場で工数がかかっている業務」ばかりです。 具体的には、組込みモデルの挙動を AI で解析するクラウドサービス、要件定義からテスト仕様書を自動生成する AI エージェント、複数ツールの評価レポートを画像認識も含めて自動生成する仕組み、開発メトリクスを収集・可視化するダッシュボード基盤、クラウド環境の運用を統一 UI で自動化するシステムなどが生まれました。 代表的な数字を紹介します。 3 日間で 9 マイクロサービス / 4,500 行超 / 174 コミット / 76 PR 開発スピード 約200 %向上 7チーム全てがデモ可能なプロトタイプを完成させました。 さらに、あるチームはワークショップ翌週に早くも 本番リリースしました。3日間で生まれたプロトタイプが「やって終わり」ではなく、翌週からイテレーションが回り始めた事例です。AI-DLC で身につけた開発サイクルがそのまま実務に直結することを示しています。 参加者の声 「今までの自分を破壊することが出来た！」 「人間は選択に集中し、AIに任せるべき。ストレートに開発に響く学び」 「記事で読んでも実感できなかったが、体験で腹落ちした」 「初学者の私が一つのシステムを作り上げた達成感」 ベテランから若手まで共通して出てきたのが「体験しないとわからない」です。どれだけ説明を聞いても、実際にAI がコードを生成し、自分がレビューと判断に集中する体験をしないと腹落ちしません。AI-DLC の価値は、実際に手を動かして初めて実感できるものだと改めて感じました。 学び ① 設計判断は人間が握る — AI に任せきりにすると、並行開発でアーキテクチャが混在しチーム間の成果物が結合できなくなるリスクがあります。「どのアーキテクチャで行くか」を Inception の段階で人間が合意しておくことが、Construction のスピードを決めました。 ② インセプションの質が全てを決める — ユーザーストーリーの精度が甘いと AI の出力も曖昧になります。コーディングから解放された分、要件の言語化に集中できるのが AI-DLC の強みです。事前に AI-DLC の用語集やコンセプト概要を配布しておけば、初日からさらにスピードを出せたという反省もあります。 ③ 自動車業界の品質基準との共存は次の論点 — 自動車固有のプロセスゲートに対して、AI-DLC の学びを活かすために、パイロットプロジェクトを通じて段階的に評価を進めたいと考えています。 ④ UnicornGym の3日間は「起爆剤」であり「ゴール」ではない — エグゼクティブが強調したのは「全従業員の行動変容」です。参加者が社内 Champion となり各部門に展開していく仕組みづくりが次の課題になっています。 今後の展開 44名の参加者は、全社展開の起点になります。ここから AI-DLC Champion の育成、AI ツールの組織定着、品質保証部門との連携などを段階的に進めていきます。 エグゼクティブが掲げたのは「全従業員の行動変容」と「これまでにない生産性」です。3日間で7プロトタイプを完成させた今回のワークショップは、その実現可能性を示す最初の一歩になったと考えています。 — AI-DLC に興味を持たれた方は、 aidlc-workflows（GitHub） をご覧ください。AI-DLC を始めるためのワークフローやテンプレートを公開しています。 著者 山崎 徹 アマゾン ウェブ サービス ジャパン合同会社 テクニカルカスタマーソリューションズ マネージャー

こんにちは、ソリューションアーキテクトの田邊です。2026 年 6 月 25 日から 26 日にかけて幕張メッセで開催された AWS Summit Japan 2026 の AWS for Industries Zone（ブース番号 044 ）にて、スマートグラスと生成 AI エージェントを組み合わせた倉庫ピッキング支援デモを展示しました。本ブログでは、展示内容とその裏で動いている AWS サービス構成を、デモの体験に沿ってご紹介します。 背景：倉庫ピッキング業務の課題 倉庫のピッキング業務は物流オペレーションの中でも人手に依存する割合が高く、ハンディターミナル（専用の携帯端末）の導入は進んでいるものの、以下のような課題が現場に残っています。 両手が塞がる : 商品を持つ・置く動作と端末操作が競合し、重量物のハンドリング時に効率が落ちる 視線の移動 : 端末画面と棚を交互に見る必要があり、ピッキングミスや作業テンポの低下につながる 教育コスト : 新人・パート作業者が端末操作や棚配置を覚えるまで時間がかかる 多言語対応 : 外国人作業者が増える中、日本語のみの指示系統ではオンボーディングに時間がかかる これらの課題に対して、スマートグラスと生成 AI エージェントを組み合わせ、「見るだけ・話すだけ」で業務システムにアクセスできる新しい業務体験を提案するデモを企画しました。 デモの全体像 今回のデモでは、倉庫のピッキング業務を題材に、スマートグラスと生成 AI エージェントによるハンズフリー業務支援を紹介しました。特徴は以下の2点です。 1. 音声だけで完結する業務システム操作 「ピッキングリストをください」と話しかけるだけで、倉庫管理システム（ WMS ）から作業リストを取得し、音声で案内 商品の QR コードをスマートグラスでスキャンするだけで、ピッキング完了が自動で記録 端末画面のタップは不要。両手で商品を扱いながら業務を進められる 2. 自然な多言語対話 Amazon Nova 2 Sonic により、人と話しているような低遅延で自然な音声対話を実現 英語・スペイン語・ドイツ語・フランス語・イタリア語・ポルトガル語・ヒンディー語に対応（話した言語を自動判定して同じ言語で応答） 商品の取扱注意など業務ナレッジも、社内マニュアルから探して読み上げ 使用したスマートグラス 本デモでは、Android を搭載したスマートグラス 2 機種を用意し、来場者に体験いただきました。両機種とも AI エージェントと対話するアプリを単体で動作させることができ、それぞれ形状・視認性・装着感に特徴があります。 Vuzix M400 — Android11 を搭載し単体で動作するモノキュラー（単眼）型のスマートグラスです。1,280 万画素のカメラでバーコード読み取りに対応し、本体 68 g、IP 67の防水防塵性能で倉庫環境にも適しています。ノイズキャンセリングマイクを搭載しており、周囲に環境音がある現場でも音声を正確に拾うことができます。 RayNeo X3 Pro — Android を搭載したフルカラー MicroLED ディスプレイを持つ眼鏡型のスマートグラスです。バーコード読み取りに加え、音声・映像を組み合わせたマルチモーダルな対話に対応します。輝度 6,000 ニットの高い視認性で、明るい場所でも表示内容がしっかり見えます。装着感が眼鏡に近く、より日常的なユースケースにも馴染むデザインです。 なお、本デモのアプリは Android で動作する仕組みのため、Vuzix・RayNeo に限らず、Android 対応の他のスマートグラスやタブレット・スマートフォンでも同様の体験を実現できます。 アーキテクチャ構成 デモのアーキテクチャは以下のような構成になっています。 スマートグラス上の Android アプリはシンプルな役割に絞り、会話の理解・業務データの取得・回答生成といったロジックはすべてクラウド側の Amazon Bedrock AgentCore Runtime に集約しています。全体の処理の流れは次のとおりです。 認証 : 端末にクラウドの長期パスワード的な情報を置かず、Amazon Cognito と AWS Lambda により一時的な接続 URL を発行するセキュアな仕組み 音声送受信 : スマートグラスから作業者の音声をリアルタイムに Amazon Bedrock AgentCore Runtime へ送信。Amazon Nova 2 Sonic が音声を直接理解し、応答の音声を返す 業務データへの問い合わせ : エージェントが必要に応じて Amazon Bedrock AgentCore Gateway を介し、ツール（関数）を呼び出し、Amazon DynamoDB （ WMS データ）や Amazon Bedrock Knowledge Bases （社内マニュアル）からデータを取得 この構成により、スマートグラス側は音声とカメラの入出力に専念でき、エージェントの機能追加やプロンプト調整はクラウド側の変更だけで反映されます。以下、デモのシナリオを順に追いながら、各ステップで動いているサービスを見ていきます。 ① 音声でタスク取得 作業者がスマートグラスに「ピッキングリストをください」と話しかけると、生成 AI エージェントが WMS から作業リストを取得し、棚番号・商品名・数量を音声と画面で案内します。 裏側では、スマートグラスから送られてきた音声をクラウド上の Amazon Nova 2 Sonic が受け取ります。Amazon Nova 2 Sonic は音声を直接理解し、そのまま音声で応答を返せる生成 AI モデルです。従来の「音声を一度文字に起こしてから生成 AI に渡し、生成された文章を再び音声にする」という 3 段階の処理と違い、音声のまま処理するため、人と話しているような自然で低遅延なやり取りが可能になります。作業者の意図が「ピッキングリストの取得」だと判断されると、エージェントが WMS 用のツールを呼び出し、Amazon Dynamo DB からリストを取り出して音声で読み上げ、同時にタスク一覧を画面に表示します。 ② QR スキャンで商品照合・完了 案内された棚に移動し、商品のQR コードをスキャンすると、エージェントが商品を照合し、ピッキング完了を WMS に自動で記録します。次のアイテムがある場合は続けて音声で棚の場所を案内し、全アイテム完了時には作業時間もフィードバックします。 ここでは、音声とカメラという異なる入力を、同じ会話の流れの中で扱っています。QR スキャンの結果はテキスト情報として Amazon Nova 2 Sonic に渡り、エージェントは「今、この作業者は音声で受けたタスクの商品をスキャンした」と文脈を理解した上で、Amazon Dynamo DB に完了記録を書き込みます。作業者は「モードを切り替える」といった意識をせず、話す・スキャン・話す、というテンポで作業を進められます。 ③ 視覚支援と業務ナレッジ照会 「棚の場所が分からない」と聞けば倉庫マップで棚位置をハイライト表示、「タイミングベルトの取扱注意点は?」と聞けば社内マニュアルから該当箇所を音声で読み上げます。 業務ナレッジの音声応答は、Amazon Bedrock Knowledge Bases という機能で実現しています。これは、事前に社内のピッキングマニュアルなどのドキュメントを Amazon S3 に置いておくと、生成 AI が質問の意図に合わせて関連する記述を意味的に検索してくれる仕組みです。エージェントは検索結果をもとに要点をまとめ、Amazon Nova 2 Sonic を通じて自然な音声で回答します。マニュアルを更新しても、それを取り込み直すだけで、エージェントの回答が常に最新の内容に保たれます。 1 会話あたりのコスト ブース来場者から多くいただいた質問がコスト面でした。本デモの構成で、ピッキング 4 アイテムを約 3 分で処理する会話1回あたりのコストは、およそ 8.9 円（ 1 USD = 160 円換算）です。1 端末あたり 100 会話/日 × 30 日で月額約 26,720 円と、実運用に耐える水準です。コストの大半（約 78 %）は音声の生成（ AI の応答音声）が占めるため、AI の応答を簡潔にする工夫がコスト削減に最も効きます。 期待される効果 本ソリューションの導入で、以下のような効果が期待できます。 作業者の身体的・認知的負荷の低減 : 端末操作から解放され、視線を作業対象に集中できる 教育コストの削減 : 音声で作業指示・マニュアル照会ができ、新人・短期雇用者の即戦力化が容易 多言語対応による人材活用 : 外国人作業者にも母語で指示・案内が可能 既存 WMS を活かした導入 : 現行の業務システムを置き換えず、生成 AI エージェントから連携 本デモのコアである「生成 AI エージェント × ウェアラブルデバイス × 音声インタラクション」の組み合わせは、倉庫ピッキングに限らず、「両手を使う現場作業×システム連携」が求められる幅広い領域に応用可能です。製造ラインでの作業指示と部品照合、医療現場での検体照合と電子カルテ入力、設備点検・警備での手順書参照とレポート入力、店舗のバックヤード在庫確認など、応用先は多岐にわたります。 まとめ AWS Summit Japan 2026 で展示した「スマートグラス × 生成 AI エージェント」は、倉庫ピッキング業務における「両手が塞がる」「教育コストが高い」「多言語対応が難しい」という課題に対し、見るだけ・話すだけで業務システムにアクセスできる新しい業務体験を提案するものです。Amazon Bedrock AgentCore Runtime と Amazon Nova2 Sonic の組み合わせで、サーバレスで実装できます。物流業界は 2024 年問題をはじめ様々な課題に直面していますが、生成 AI エージェントを既存の業務システムに繋ぐことで、現場の負荷を減らしながら生産性を高めることが可能です。ご興味のある方は、担当ソリューションアーキテクトまでお気軽にご相談ください。 会場では倉庫ピッキング以外のユースケースについても多くのご相談やディスカッションをいただき、このソリューションパターンへの関心の高さを実感しています。 この展示は、ソリューションアーキテクト横山、駒野、山本、田邊が担当しました。