現在、 AWS Graviton5 プロセッサを搭載した  Amazon EC2 の R9g インスタンスと R9gd インスタンスが一般的に利用できるようになっています。R9g インスタンスはメモリ最適化されており、AWS がこれまでに構築した中で最もエネルギー効率の高いプロセッサを搭載した Graviton4 ベースの R8g インスタンスと比較して、コンピューティングパフォーマンスが最大 25% 向上します。 R9g インスタンスは、データベース、インメモリキャッシュ (Valkey、Redis、MemCached)、リアルタイムのビッグデータ分析、コンテナ化されたマイクロサービスベースのアプリケーション (Kubernetes、Docker、EKS、ECS など) を含む Linux ベースのワークロード、C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションなど、メモリを大量に消費するワークロードに最適です。 R9gd インスタンスには、ローカルの NVMe ベースの SSD ブロックレベルストレージが含まれており、オープンソースデータベース、分散型リアルタイムビッグデータ分析、大規模なインメモリデータベース、大規模なキャッシュワークロードなど、高速で低レイテンシーのローカルストレージを必要とするメモリ集約型のワークロードに最適です。 現在 R8g インスタンスでワークロードを実行している場合、R9g を使用すると、消費電力を抑えながら、より高速なメモリ、より高いネットワークと Amazon EBS の帯域幅、大きな L3 キャッシュにより、vCPU あたりのパフォーマンスが向上します。 R9g は何が違うのか Graviton5 プロセッサは、Graviton4 に比べていくつかのハードウェア改善をもたらしています。 vCPU あたりのコンピューティングパフォーマンスが最大 25% 向上 DDR5 8800 MT/s メモリ（Graviton4 の 5600 MT/s から増加）、クラウドで利用可能な最速のメモリ L3 キャッシュが 5 倍大きく、データの局所性が向上 最大のインスタンスサイズでは最大 2 倍のネットワークと EBS 帯域幅 (最大 100 Gbps のネットワーク、48 xlarge では最大 72 Gbps の EBS) 最大 3 倍のパケット処理パフォーマンス R9g インスタンスと R9gd インスタンスは、Amazon EBS と Amazon VPC ネットワーキング間の帯域幅割り当てを 25% 調整できるインスタンス帯域幅設定 (IBC) をサポートしています。これにより、データベースやキャッシュなど、特定の帯域幅要件を持つワークロードのパフォーマンスを最適化できます。 すべての R9g および R9gd インスタンスは AWS Nitro System 上で動作し、仮想化、ストレージ、ネットワーキングを専用ハードウェアにオフロードします。これにより、インスタンス間の強固なセキュリティ分離を維持しながら、アプリケーションはベアメタルに近いパフォーマンスを実現できます。 R9g インスタンスと R9gd インスタンスには、今年初めに C9g と M9g インスタンスで導入された Nitro System と同じ拡張機能である Nitro Isolation Engine (NIE) が搭載されています。Nitro Isolation Engine (NIE) は、インスタンスの分離を強制し、正式な検証を利用して数学的な精度で分離を保証します。Nitro Isolation Engine は、仮想マシン間の分離を強制する役割を担う専用コンポーネントです。その役割には、最小限の一連の API を通じて、仮想マシンのメモリ、CPU レジスタ状態、I/O デバイスに対するあらゆるアクセスを仲介することが含まれます。Nitro Isolation Engine は形式検証を活用しています。形式検証とは、ハードウェアまたはソフトウェアが、特定のテストケースにおいてだけでなく、意図されたとおりに動作することを数学的に証明する手法です。この高度な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなっており、数学的に証明されたクラウドセキュリティの新たな標準を打ち立てています。Nitro Isolation Engine の詳細については、 ブログ投稿 をご覧ください。対象範囲や前提条件を含む形式検証の結果の詳細については、 テクニカルホワイトペーパー を参照してください。 EC2 R9g および R9gd インスタンスの仕様 R9gとR9gdのインスタンスはそれぞれ、ミディアムからメタル 48XL まで、11種類のサイズでご利用いただけます。次の表は、各サイズの完全な仕様を示しています。 インスタンスサイズ vCPU メモリ (GiB) インスタンスストレージ ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) r9g.medium 1 8 EBS のみ 最大 15 最大 12 r9g.large 2 16 EBS のみ 最大 15 最大 12 r9g.xlarge 4 32 EBS のみ 最大 15 最大 12 r9g.2xlarge 8 64 EBS のみ 最大 17 最大 12 r9g.4xlarge 16 128 EBS のみ 最大 17 最大 12 r9g.8xlarge 32 256 EBS のみ 17 12 r9g.12xlarge 48 384 EBS のみ 25 18 r9g.16xlarge 64 512 EBS のみ 34 24 r9g.24xlarge 96 768 EBS のみ 50 36 r9g.48xlarge 192 1536 EBS のみ 100 72 r9g.metal‑48xl 192 1536 EBS のみ 100 72 R9gd インスタンスは、高速で低レイテンシーのスクラッチスペースまたは一時キャッシュを必要とするワークロード向けに、ローカル NVMe ベースの SSD ストレージを追加することで、R9g と同じコンピューティング性能とネットワークパフォーマンスを提供します。 インスタンスサイズ vCPU メモリ (GiB) インスタンスストレージ (NVMe SSD) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) r9gd.medium 1 8 1 x 59 GB 最大 15 最大 12 r9gd.large 2 16 1 x 118 GB 最大 15 最大 12 r9gd.xlarge 4 32 1 x 237 GB 最大 15 最大 12 r9gd.2xlarg 8 64 1 x 474 GB 最大 17 最大 12 r9gd.4xlarge 16 128 1 x 950 GB 最大 17 最大 12 r9gd.8xlarge 32 256 1 x 1900 GB 17 12 r9gd.12xlarge 48 384 3 x 950 GB 25 18 r9gd.16xlarge 64 512 1 x 3800 GB 34 24 r9gd.24xlarge 96 768 3 x 1900 GB 50 36 r9gd.48xlarge 192 1536 3 x 3800 GB 100 72 r9gd.metal‑48xl 192 1536 3 x 3800 GB 100 72 使用の開始 サポートされている任意の ARM ベースの AMI を使用して、 Amazon EC2 コンソールから R9g インスタンスと R9gd インスタンスを起動できます。R9g インスタンスは、Amazon Linux 2023、Amazon Linux 2、Ubuntu 22.04+、RHEL 8.4+、SUSE Linux エンタープライズサーバー 15 SP3+、Debian 12+、およびその他の主要な Linux ディストリビューションをサポートしています。 R8g から移行する場合、ほとんどのアプリケーションではコードを変更する必要はありません。同等の R9g インスタンスサイズを選択すると、アプリケーションのパフォーマンスが向上します。コンテナ化されたワークロードの場合、R9g は Amazon EKS、 Amazon   ECS 、および標準の Kubernetes デプロイメントと連携します。Arm64 用に構築されたマルチアーキテクチャコンテナイメージは変更なしで動作します。 始めるのに役立つリソースはいくつかあります。 AWS Graviton 入門ガイドでは 、Graviton ベースのインスタンスでワークロードを構築、実行、最適化する方法について説明しています。 Graviton節約ダッシュボードは 、コスト削減を追跡するのに役立ちます。 AWS Transform は Java アプリケーションを x86 から Graviton に移行するためのコード変換を自動化します。詳細については、 AWS Graviton プロセッサをご覧になるか、AWS Graviton でコンピューティングをレベルアップしてください 。 料金と利用可能なリージョン Amazon EC2 R9g および R9gd インスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、および欧州 (フランクフルト) リージョンで利用可能です。 R9g および R9gd インスタンスは、Savings Plans、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、または専有ホストを通じて購入できます。詳細な料金については、「 Amazon EC2 の料金 」ページにアクセスしてください。 始める準備はできましたか? Amazon EC2 コンソール から R9g インスタンスを起動してください。詳細については、 Amazon EC2 R9g インスタンスページを参照してください 。 API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 Amazon EC2 用 AWS re:Post でフィードバックを共有するか、通常の AWS サポートの連絡先から連絡してください 。 – Daniel Abib 原文は こちら です。

2026 年 8 月 24 日週に私が最も興味を持ったニュースは、DuckLabs の買収でした。 AWS は、Parquet、CSV、JSON などのファイルに対してインプロセスで実行され、SQL を直接実行する人気のオープンソース分析データベースである DuckDB の背後にあるアムステルダムを拠点とする企業である DuckLabs を買収する最終契約を締結しました 。DuckDB は、独立した基盤と MIT ライセンスの下でオープンソースを維持しており、時間の経過とともに、AWS は日常のクエリの速度と、Amazon S3、Amazon Redshift、Amazon Athena などのエンタープライズ規模のサービスを組み合わせる予定です。 ハネス・ミューライゼンとマーク・ラースベルトが共同設立した DuckDB は、ローカルまたは Amazon S3 上で稼働しています。そのため、現実世界の分析の大部分を占める日常のクエリ (1 テラバイト以下) の処理速度が非常に速くなります。また、AI エージェントとの相性も抜群です。AI エージェントは、人間と同じようにデータを「調べて」実験します。AWS が DuckDB のスピードと Amazon EMR、AWS Glue、Amazon SageMaker などの分析サービスを組み合わせている間、共同創設者は引き続き技術的な方向性をリードしていきます。なぜこれが重要なのかをより大局的に説明するために、バイスプレジデント兼著名なエンジニアであるアンディ・ウォーフィールドが、 ポスト DuckDB と All Things Distributed で変化する分析 の物理現象についての考えを共有しました。 それでは、8 月 31 日週の AWS ニュースを見ていきましょう… 8 月 24 日週のローンチ 8 月 24 日週のローンチのうち、私が注目したリリースをいくつかご紹介します: Amazon ECS は、エージェントとの接続を失ったコンテナインスタンスを自動的に検出して回復するようになりました。Amazon ECS は、エージェントのコントロールプレーンへの接続を継続的に監視し、新しい AGENT_CONNECTIVITY ヘルスイベントを AWS Fargate、Amazon ECS マネージドインスタンス、および EC2 上の Amazon ECS 全体にわたって検出するようになりました。Fargate とマネージドインスタンスでは、ECS が自動的にリカバリ、タスクの排出、代替インスタンスの起動、障害のあるインスタンスの登録解除を行います。EC2 では、イベントを独自のワークフローに接続できます。すべての AWS コマーシャルおよび AWS GovCloud (米国) リージョンで追加料金なしで利用できます。 AWS Lambda では、Node.js 26 と Python 3.15 からパブリックプレビューランタイムが導入されました。今後の Lambda ランタイムが一般公開される前にテストできるようになりました。プレビューランタイムは最終的な GA バージョンと同じ識別子を使用するため、関数はアクションなしで自動的に段階的に終了します。サードパーティのツールやデプロイメントフレームワークでも、GA に先立って互換性を検証できます。まだ本番環境向けではありませんが（重大な変更が可能です）、次のアップグレードに先んじるには最適な方法です。すべての AWS コマーシャル、AWS GovCloud (米国)、および中国リージョンでご利用いただけます。 AWS IoT Core にネイティブ InfluxDB ルールアクションが追加されました — カスタムコードを記述したり、中間サービスをセットアップしたりしなくても、IoT デバイスから InfluxDB (Amazon TimeStream マネージドまたはセルフホスト) に時系列データを直接ルーティングできるようになりました。IoT Core はデータを InfluxDB のラインプロトコルにフォーマットし、デバイス側とサーバー側のバッチ処理をサポートします。Amazon Timestream for InfluxDB が提供されているすべての AWS リージョンで利用できます。 Amazon GameLift Servers に DDoS 保護機能が強化されました — ゲームサーバーは、ネットワークとトランスポートレイヤー (レイヤー 3 と 4) の DDoS 攻撃 (UDP リフレクション、SYN フラッド、および同様のベクトル) から自動的に保護されるようになりました。有効にしたりオプトインしたりする必要はありません。ゲーム用に最適化されたトラフィックシェーピング機能を備えた AWS Shield Standard 上に構築されているため、追加費用なしでサーバーの稼働を開始した瞬間 (Server SDK 5) に起動します。中国 (北京) と中国 (寧夏) を除き、サポートされているすべてのGameLift Serversリージョンで利用できます。 Amazon SageMaker HyperPod が Ray のサポートを拡大する — 組み込みのオブザーバビリティ、レジリエントなトレーニング、高速推論により、SageMaker HyperPod で Ray ワークロードを実行できるようになりました。Amazon SageMaker Studio から Ray クラスターを作成および管理し、JupyterLab またはローカル IDE をアタッチしてマルチノードクラスターがローカル開発環境のように動作するようにし、Grafana ダッシュボードを自動プロビジョニングします。ノードの自動リカバリ、ハングジョブの検出、階層化されたチェックポイントにより、大規模なトレーニングを正常に実行できる一方、Ray Serve は推論用に階層化された KV キャッシュを追加します。既存のオープンソース Ray コードは変更されずに動作します。Amazon EKS によってオーケストレーションされたハイパーポッドクラスターで使用できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: 20 歳の誕生日おめでとう、Amazon EC2! — アマゾン EC2 が 20 周年を迎えます。Channy Yun は、EC2 が 1 つのリージョンの単一の m1.small インスタンスタイプから 39 のリージョンにわたって 1,200 を超えるインスタンスタイプに成長した経緯と、最初の Graviton から Graviton5 と Trainium3 へのカスタムシリコンの移行について振り返ります。Amazon ECS、Amazon EKS、AWS Lambda、Amazon SageMaker、Amazon Bedrockなど、今でも AWS の多くを支えているこのサービスについて、楽しくて読む価値があります。 エージェントリソースディスカバリー (ARD): エージェントディスカバリーのオープン仕様 — 組織がエージェント 、ツール、MCP サーバーをスケールアップするにつれて、これらのリソースはクラウド、オンプレミスインフラストラクチャ、SaaS プラットフォームに分散し、それぞれが独自のレジストリとメタデータを持つことになります。ARD は新しいオープン仕様（Apache 2.0）で、エージェントのリソースを記述して発見する一般的な方法を定義しています。そのため、パブリッシャーは「一度説明すると」、コンシューマーは「あらゆる場所で発見する」ことができます。DNS はエージェント向けです。AWS はフィードバックを提供しましたが、この仕様は独自のものではありません。また、移行せずに複数のカタログを統合できるため、AWS Agent Registry が補完されます。 AWS CLI で Agent Toolkit for AWS を使い始めましょう – 単一の AWS CLI コマンド ( aws configure agent-toolkit ) で、Kiro、Claude Code、Codex、Cursor などの AI コーディングエージェントに、厳選された最新の AWS 知識と AWS MCP サーバーを介した何千もの AWS API への安全な接続が可能になりました。AI コーディングアシスタントを使用してビルドすると、適切なサービスを選択し、最新の API を使用し、セキュリティのベストプラクティスに従うのに役立ちます。そのため、初めてでも AWS コードを正しく理解できることが多くなります。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 開発者が集まってクラウドと AI の最新情報を学び、交流し、探求する無料の対面イベント。開催予定: チューリッヒ (9 月 2 日)、 サンパウロ (9 月 3 日)、 テルアビブ (9 月 10 日)、 ドバイ (9 月 30 日)。直接参加できない場合 セッションは、 グローバルライブストリームとオンデマンドハブ からストリーミングできます。サンパウロサミットでは、生成 AI と Amazon Bedrock に関する2つのセッションを発表します。参加されたら、ぜひご挨拶ください。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。今後のイベントとして、 東京（9月5日）および ポーランドのワルシャワ （9月8日）での「JAWS SONIC 2026」が予定されています。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 8 月 31 日週のニュースは以上です。9 月 7 日週の次回 Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

イベント概要 Amazon Aurora DSQL に関心をお持ちのお客様に向けて、「Aurora DSQL Day Tokyo」を開催します。本イベントでは、Aurora DSQL の開発を率いる Eric Kraemer のキーノートと AWS のスペシャリストによる Deep Dive セッション、そして日本のお客様 4 社から DSQL の採用事例についてお話いただきます。Aurora DSQL がどう動いているのか、実際の現場でどのように使われているか――ぜひこの機会に体感してください。 皆さまのご参加を心よりお待ちしております。 開催情報 開催日時 2026年9月14日（月）14:00 – 18:00 （13:30 受付開始） 開催場所 AWS 麻布台オフィス（麻布台ヒルズ 35F） 〒106-0041 東京都港区麻布台1丁目3-1 麻布台ヒルズ 森JPタワー 東京メトロ日比谷線 神谷町駅 直結・東京メトロ南北線 六本木一丁目駅より徒歩約4分 ※入退館等詳細は別途ご連絡いたします 参加対象者 分散データベースやマルチリージョン構成に関心のあるエンジニア、アーキテクト、技術リーダーの方々 言語 Keynote: 英語（逐次通訳）、他セッション: 日本語 参加申し込みについて 以下のページよりお申し込みください。 お申し込みはこちら 特にこのような方々に最適なイベントです マルチリージョンでの高可用性データベース構成を検討されている方 分散 SQL データベースのアーキテクチャや設計パターンに興味のある方 Aurora DSQL の具体的な実装方法やベストプラクティスを知りたい方 既存のリレーショナルデータベースからの移行を検討されている方 他社の Aurora DSQL 導入事例を参考にしたい方 プログラム内容 時間 内容 13:30-14:00 受付 14:00-14:05 オープニング 14:05-14:50 What’s Next for Aurora DSQL ― Aurora DSQL が目指す世界 Aurora DSQL サービスチームのプロダクトマネージャーから、プロダクトビジョンや設計思想、今後の方向性、海外のお客様による採用事例などをご紹介します。※逐次通訳付き AWS, Senior Manager PMT – Aurora Distributed SQL Eric Kraemer 14:50-15:40 将来不要になるデータベースタスクから考える Aurora DSQL ― アーキテクチャ・制約・適用判断 ― DB を選定するアーキテクトやエンジニア向けに、Aurora DSQL を「選定後に不要になるタスク」という観点から解説。キャパシティプランニング、シャーディング設計、スキーマ変更に伴う停止時間の調整、フェイルオーバー設計がなぜ不要になるのか、分散アーキテクチャから説明します。同時に、トランザクション競合時のリトライ設計や処理サイズの制限など、アプリケーション設計上の考慮点と適用判断のチェックリストもお持ち帰りいただきます。 アマゾンウェブサービスジャパン合同会社, データベース スペシャリスト ソリューション アーキテクト 永末 健太 15:40-15:50 休憩 15:50-16:15 実践 Rails + Aurora DSQL Ruby on Rails で実際に Aurora DSQL を利用して customer facing なシステムを新規開発・運用する中でのハマり所や工夫、また既存データの AWS Database Migration Service を利用した移行といった様々なエピソードを紹介します。 株式会社 IVRy, Platform & Systems Principal Software Engineer Sorah Fukumori 氏 16:15-16:40 ネットスーパーサービスにおいて AWS DSQL を選定した理由とその後の運用についてのリアル retail HUB ネットスーパーサービスにおいて商品のピッキングシステムを新規に開発する際、ストレージサービスとして DSQL を選定。選定時の検討内容や、開発で遭遇した課題、その後の運用の状況について小売業界の実態も含めつつ実際のところをお話しします。 株式会社エブリー, 開発本部 開発2部 部長 内原 章 氏 16:40-17:05 サッカークラブの広報写真選定システムと Aurora DSQL FC 東京では試合のたびに大量の写真が発生し、記事や SNS に適した写真を探す作業に多くの労力がかかっていました。Amazon Rekognition による人物特定と Amazon Bedrock のマルチモーダル LLM によるシーン・表情・パートナー企業露出の分類を組み合わせた写真選定システムを開発。分類結果を保存する DB として採用した Aurora DSQL について、運用のしやすさや負荷変動が大きい場合のコスト面でのメリットなど、実際に利用して得られた知見をご紹介します。 株式会社 MIXI, ライブエクスペリエンス事業本部 企画推進部 エンジニアリング支援グループ マネージャー 數藤 智幸 氏 17:05-17:30 有事の”切り替え判断”を、なくす。 ― Aurora DSQL で実現する Active-Active DR 戦略 2026年4月の AWS Data & AI イノベーションフォーラムで「DR 戦略の進化」として DSQL 採用の第一歩をお話しいただきました。あれから数ヶ月、検証は着実に進んでいます。マルチリージョン稼働のシステムを構築する中で直面した、ロングトランザクション制限やマルチリージョン設計での整合といった技術課題を、AWS と共に乗り越えている現在地をアップデートしてご紹介いただきます。 東京海上日動システムズ株式会社, IT インフラサービス本部 スペシャリスト 松本 幸大 氏 17:30-17:35 クロージング 17:35-18:00 個別アーキテクチャ相談会 AWS スペシャリストに直接ご相談いただけます。Aurora DSQL に関する具体的な設計・導入のご質問にお答えします。 Amazon Aurora DSQL とは Amazon Aurora DSQL は、事実上無制限のスケーラビリティ、最高の可用性、ゼロインフラ管理を備えた、PostgreSQL 互換のサーバーレス分散 SQL データベースです。Active-Active のマルチリージョン構成で 99.999% の可用性を提供し、従来のデータベースに必要だったインフラストラクチャの管理、キャパシティプランニング、パッチ適用、レプリカ管理などのタスクが不要になります。 強力な一貫性を持つ分散トランザクションを、リージョン内では低レイテンシー（数ミリ秒）で、マルチリージョンでもインタラクティブなレイテンシーで処理できます。PostgreSQL のワイヤプロトコルに対応しているため、既存の PostgreSQL 互換ドライバーやツールをそのまま利用可能です。 お申し込みはこちら

こんにちは、AWSの嶺、篠原、鈴木です。2026年5月、DeNAのヘルスケア事業部門のDeSCヘルスケア株式会社（以下、DeSC）の皆さまと、AI-DLC（AI-Driven Development Life Cycle）の3日間プログラム「Unicorn Gym」に取り組みました。AI-DLC は、AWS が提唱する「ソフトウェア開発に対する AI 中心の革新的なアプローチ」であり、AI の能力を開発プロセスの構造そのものに組み込む新しい方法論ですが、その方法論をソフトウェア開発ではなく「データ分析業務」へ適用しました。 AI-DLC では、要件定義や実装の主役を AI が担い、人間は「何を作るか」という意図のすり合わせと重要な判断に集中します。詳しくは  AI 駆動開発ライフサイクル：ソフトウェアエンジニアリングの再構築  をご覧ください。また、この AI-DLC を座学ではなく自社の実テーマで3日間走り切る形で体験するプログラムが Unicorn Gym です。 3日間を終えて印象に残ったのは、AI の性能そのものよりも、部署をまたいでメンバーの認識をそろえていく営みに対してAIを用いるポテンシャルの大きさです。 インタビューさせていただいた DeSC ヘルスケア株式会社の皆様。 左より、嶺（AWS） 山田真里香（インダストリー統括部分析企画部）、伊藤 康太郎（製品開発統括部 統括部長） 、香村 和宏（インダストリー統括部分析企画部 部長） 、河野 愛樹（製品開発統括部プロダクトマネジメント室） 、鈴木（AWS） 1. なぜ「データ分析業務」を選んだのか 嶺: まず、AI-DLC に取り組むことになった経緯を教えてください。 河野 氏: AWS さんから「AI-DLC というものがある」とご提案いただいたのが最初です。実は、最初に話を聞いた伊藤は「これがどこにはまるのか、他の研修と何が違うのか」とピンときていない様子でした。一方で私は、これまで組織を俯瞰して見る中で感じていた大きな「壁」を乗り越えるきっかけになるのでは、という期待を感じていました。 部門間、特にビジネス側とシステム側のように大きくロールが異なる組織の間でコミュニケーションギャップが昔から各所で存在しており、認識合わせに時間がかかったり、同じ言葉を使っていても「これって実はこんな認識だった」というズレが起きている。同じベクトルを向ききれていない、一体感を作りたいのに作り切れていない、といったモヤモヤを感じていました。そこに拍車をかけたのがAIです。DeNA社長の南場が「AIオールイン」と発したのを皮切りに、ヘルスケア事業部門でも「AI活用をやっていくぞ」と掲げたものの、前のめりで使う人と、様子を見ながらゆっくり始める人とで差がある。その差がどんどん開いていっていることに危機感を感じていました。 「同じ体験を共にすることで、共通言語を持てるようになるのではないか」、「できる人がどう使っているのか、どう指示や操作をしているのかを、ちょっと隣で見せてもらうだけでも変わるんじゃないか」と思っていたところに、AI-DLC と Unicorn Gym を耳にして、「これははまるんじゃないか」と伊藤に持ちかけたんです。 嶺: 最初に検討されたテーマは、実はシステム開発だったと伺いました。 河野 氏: そうなんです。ちょうどその頃、新しい分析環境を作るプロジェクトが走っていました。分析環境そのものや運用ツールセットを作る必要があったので、そこに適用するのがテーマ的にも丁度良いのではないか、というところから始まりました。でも伊藤から「システム開発でやるなら別にUnicorn Gymじゃなくてもいい。どうせやるなら、その新しいシステム上で行う予定の分析業務にフォーカスを当てるのはどうか」とカウンターが来たんです。 伊藤 氏: できるかできないかよりも「どうせやるならペインが強いところをやった方がいい」と。参加者全員が自分事にできるテーマならば、面白い取り組みになるだろうという直感がありました。そしてもう一つ。AI活用のボトルネックは組織・部門の繋ぎ目で発生することは分かっていました。当時はデータサイエンス部とビジネス部門である分析企画部間の連携の難しさが表面化していた時期でした。私たちはハイブリッドワークで、顔を突き合わせて作業する機会が普段は多くありません。部門を跨いだ共同作業の機会や経験は特に少ない。お互いのバックグラウンドも実はよく分かっていない。一方で、新しい業務・新しいプロジェクトだからこそ「最悪、失うとしてもこの3日間だ。だったらやってみよう」と、リスクをとって動くことにしました。 嶺: まさにそこなんです。AI-DLC はソフトウェア開発の文脈で語られがちですが、本当に言いたいのは、実装を AI が担うようになると、ボトルネックが実装から「人と人の合意形成」に移る、ということなんです。別々に動いていると意思疎通がうまくいかず、手戻りが起きる。これはソフトウェアに限らず、どの業界でも起きています。だから、データ分析でも同じことが起きているはずで、そこで成立すれば AI-DLC の使いどころは大きく広がる、と考えていました。 AI-DLC に取り組んだ経緯を語る河野氏（右） 2. 3日間で、何をしたのか 嶺: どのようなメンバーで、どんな3日間だったのか教えてください。 河野 氏: Unicorn Gymには、分析企画部と、データサイエンス部を中心に、合わせて24名で参加し、部門混成・AI活用の度合い混成で4チームを編成しました。 香村 氏: 分析企画部は、ヘルスビッグデータを用いた分析の企画を行っている部署です。私たちが製薬企業様などのニーズ（ある疾患の治療実態把握など）をヒアリングし、そこで定義したお客様の問いから、どのデータをどう集計・加工すれば答えになるのかに翻訳した「要件定義書」を作成します。この要件定義書を元に、データサイエンス部が実際の集計を行います。 河野 氏: 今回のUnicorn Gymは、AIを活用した要件定義書作成をメインコンテンツにしました。初日の午前は座学の時間。AWSさんからAI-DLCの考え方を教わりながら、簡単なハンズオンを行いました。以降はチームごとに分かれ、モブワーク（1つの画面を全員で見ながら、同じ作業を一緒に進める進め方）の時間。AIをフル活用して、質の高い要件定義書をどれだけ無駄なく苦労なく作れるかを試行錯誤しました。 山田 氏: モブワークを通して、「AI にどこまで任せるか」が具体的になりました。最初は自分たちで考えた結果を AI に渡していたのですが、AWS さんから「それだと AI が待っている時間が多い。もっと AI に考えさせて」とアドバイスを貰って。全部いったん AI に投げて、その間に自分たちで議論する形に変えたら、スピードが一気に上がった。これを初日に教われたのは大きかったです。 3. ビジネス部門へ波及した影響 嶺: 実際にやってみて、いかがでしたか。ビジネス部門からの視点でお伺いさせてください。 香村 氏: 私は正直なところ、Unicorn Gymに参加して起きることの解像度が、河野や伊藤よりも更に低かったです。「参加した結果、具体的にどんな変化が起きますか」と伊藤に確認したら、「やってみないと分からない部分もあるけど、信じて飛び乗ってくれ」と。弊社メンバーとAWS さんへの信頼だけで飛び乗った、というのが正直なところです。 ですが、やってよかったと自信を持って言えます。私たち分析企画部は、データサイエンス部やエンジニアと比べるとAI 活用では一歩後ろにいました。それが、一緒に作業することで、ミーティングで話すだけでは分からない「こういうときに使えば良いんだ、という具体的な使い所」、「こういう時は、こう AI に聞けばいいのか」という手触り感まで得られました。 嶺: 分析企画とデータサイエンス、普段は分業されている両者が同じチームで動いた意味は大きかったのでしょうか。 山田 氏: 大きかったです。これまでは分業制で、私たち分析企画部が定義を決めてからデータサイエンス部にパスしていました。私たちが書く定義書は、お客様との対話に必要な情報としては十分に書けているつもりなんです。ただ、SQL の設計という目線で見ているデータサイエンス部からすると「ここはもっと細かく決めておかないと書けない」と映ることがある。 一緒に動いてみて改めて感じたのは、必要な詳細さの基準が立場によって違うということでした。私たちはお客様と向き合う立場から、データサイエンス部はデータを集計する立場から、同じテーマを見ている。その上で、お互いがどう情報を組み立てているのかを理解できたので、どこをどう補い合えばいいのかが見えてきました。「その組み立て方なら、業務フローをこう変えた方がいいよね」という気づきも生まれましたし、私たちがお客様とどう情報を組み立てているかを共有できたことで、要件定義書を作る AI をどう組み立てればいいかのヒントも見えました。データサイエンス部が普段どう AI を使っているかも学べて、お互いにいい影響がありました。 嶺: Unicorn Gymの3日間で、特に印象に残っている場面はありますか。 香村 氏: コンペ形式となった最終成果発表です。各チームがそれぞれの工夫を施したAIエージェントに要件定義書を作らせ、できあがった要件定義書を元に別のAIエージェントに集計作業を行わせました。ここでは、AIエージェントの実力を測る目的で、実業務では必ず入れる「人の目による要件定義書のレビュー」を外すルールで実施しました。 4チームそれぞれの画面を大きなスクリーンに並べ、4つのAIエージェントが動いている様子をみんなで眺めていた時が特に印象的でした。正直、最初は「AI が質の高い要件定義書を作るのは難しいのではないか」と思っていたんです。それが次々と要件定義・集計を進めていき、その光景は圧巻で素直に驚きつつ、データ分析業務の品質やスピード感を高める具体的なイメージを持つことができました。この会社に入ってから、一番ワクワクした時間だったと思います。 最終成果発表。4チームのAIエージェントが動く様子 4. DeNAの事業への向き合い方 嶺: 今回、印象的だったのは、皆さんが「何をやるか」から自分たちで考え、全体を引っ張っていかれたことです。他のお客様ではなかなか見られません。このオーナーシップはどこから来ているのでしょうか。 伊藤 氏: 大前提として、ノープランで挑むと期待した成果は出ないと思ったので、拠り所になるベースラインは用意しました。ただ「作るけれど、出たとこ勝負になる」というのは織り込み済みでした。私たちは普段から、仮説を立てて、観察した事実から軌道修正していく進め方が体に染みついているんです。だから、計画どおりに進まないこと自体には抵抗がなかった。 嶺: 通常の Unicorn Gym では、チームごとの進行はお客様が、全体を束ねる役割は AWS が担うことがほとんどです。その全体を束ねる役割まで、お客様側が担われたのは珍しいことでした。 伊藤 氏: AI 活用や開発生産性の話は、トップマネジメントのコミットメントが決定的に重要だと考えています。組織にとっての未知の経験はリーダーが前に立ってリスクを取らないと物事は進まない。「よく分からないだろうけど、まず信じて3日間を賭けてくれ」と言えるかどうかです。失敗を許容できない組織だと、このやり方は取りづらいと思います。 AI-DLC への向き合い方を語る伊藤氏 5. AI-DLC Unicorn Gymを経た変化 嶺: 3日間を経て、業務にはどんな変化が出ていますか。 香村 氏: Unicorn Gymで各チームが作成したClaude CodeのSkills（業務の手順やノウハウをまとめてAIに読み込ませる仕組み）から厳選したものを、実業務にも取り入れて活用しています。また、分析企画部内でもSkillsを新たに作成・部内で共有される光景が日常的なものとなりました。今年に入ってUnicorn Gymの前までの5か月間では1件だったのが、その後2か月で6件が共有され、今後もこの流れは加速する見込みです。Skillsの共有を通して、属人化していた勘所や専門性が組織の資産となり、我々が提供するサービス品質の安定・向上に寄与し始めています。 山田 氏: ビジネス側は GitHub に馴染みがないところからのスタートでしたが、Skills を GitHub で共有して使う、という動きが浸透しました。「これは自分でやるしかないか」と思っていた課題を「AI で解けるかも」とスキル化する発想も増えました。そして何より、データサイエンス部とのやり取りが円滑になりました。以前はお客様と合意した要件定義書を渡すだけだったのですが、「顧客面談に同席しませんか」と声を掛けることが増えました。要件定義書が決まり切る前段階でのコミュニケーションが増えたことで、よりスピード感を持った対応ができるケースも実際にありました。 伊藤 氏: この流れは社内で連鎖しています。AI-DLC で手応えがあったので、続けて業務プロセスをAIで革新する「AI-BPR」も進めていて、次回は参加人数が40名規模になりそうなほど期待が高まっています。参加した人が手応えを持ち帰り、役職関係なく周囲を巻き込んで、あちこちで動きが広がっています。 3日間を経た変化について語る香村氏（右） 6. 製薬・ヘルスケア業界へのメッセージ 嶺: 最後に、AI 活用を検討されている製薬・ヘルスケア業界の方々へメッセージをお願いします。 香村 氏: 私たちはサービスを通じた生活者の健康増進を目指していますが、データを分析するだけでは、その実現にはつながりません。製薬・ヘルスケア業界の皆さまとヘルスビッグデータを活用し、生活者の健康増進に繋がるエビデンスを創出し、社会に還元していきたい。AIについても、それを加速させるために、皆さまと活用方法を学び合っていけたらと思います。 伊藤 氏: 近年は、1社だけでは解けない課題が増えています。医療機関、自治体、健康保険組合、そして私たちのようにデータソリューションを提供する立場と、それぞれに得意・不得意がある。健康寿命の延伸も医療費の適正化も、各社の強みを持ち寄らないと解けません。AI はあくまで手段です。どの会社にもある組織の壁を、モブワークで取り払って初めて課題解決が進む。それを社内だけでなく、業界全体に広げていきたいと考えています。 まとめ AI-DLC の中心にあるのは、人と人が認識をそろえていく営みです。「何を作るか」、「どのように人と人の合意形成をするのか」という命題に対して、AIを介在者として活用する威力を大いに実感した3日間でした。今回はデータ分析ドメインでのAI-DLCの活用でしたが、ソフトウェア開発におけるAI-DLCについての記事もぜひご覧ください。現在DeNA様はAI-BPRも推進されておりますので、そちらについての記事もお待ちください。 Unicorn Gym には DeSC から24名が参加した 著者自己紹介 伊藤 康太郎 DeNA の主要子会社であるDeSCヘルスケアの最高技術責任者兼製品開発統括部長。彼はDeSCヘルスケアが提供するデータヘルス関連サービス及びデータ利活用サービスの製品・技術・データサイエンスを統括しています。     香村 和宏 DeSCヘルスケア株式会社インダストリー統括部分析企画部部長。健康・医療データの利活用を推進する事業において、製薬企業、アカデミア、生命保険会社のお客様を中心に、DeSCデータベース等のリアルワールドデータを用いた分析のニーズヒアリングから要件定義、結果のご報告までを担当しています。     嶺 行伸 Developer TransformationチームのスペシャリストSAとして、主にAI-DLCを中心に、お客様の開発チームを支援しています。       鈴木 賢人 デジタル・エンターテインメント領域のお客様を担当するAccount Managerです。趣味は旅行と身体作りです。       篠原 聡志 ゲーム企業を経て AWS に入社。ソリューションアーキテクトとしてゲーム業界のお客様を担当し、ゲームバックエンドの設計や生成 AI の活用をご支援しています。好きな AWS サービスは Amazon Bedrock、Amazon S3 です。趣味はリズムゲームと VR ゲームです。

本ブログは、株式会社アドバンスト・メディア様と Amazon Web Services Japan が共同で執筆いたしました。 1. はじめに みなさま、こんにちは。AWS ソリューションアーキテクトの本田・戸塚と、アカウントマネージャーの兼子です。 本ブログでは、 AWS Summit Japan 2026  で展示した、食品調理現場における業務課題を、音声 AI とマネージドエージェント基盤で解決するアーキテクチャをご紹介します。 Amazon Bedrock AgentCore Runtime と Strands Agents SDK による AI エージェント、 AmiVoice による高精度な日本語音声認識、 Amazon DynamoDB や AWS Lambda によるサーバーレスバックエンドを組み合わせ、「手を使わずにレシピを操作できる」ハンズフリーオペレーションを実現しています。 AWS 側ではエージェント設計・クラウドアーキテクチャ・リアルタイム通信の観点から、アドバンスト・メディア社側では音声認識エンジン AmiVoice の技術特性・業界特化チューニング・認識精度向上の観点から、それぞれ解説します。 2. 飲食業界における現場オペレーションの課題 食品調理の現場、特にセントラルキッチン（複数店舗向けの集中調理施設）では、以下の構造的な課題が存在します。 2.1 手が塞がる環境でのデータ入力障壁 調理作業上、両手は鍋・包丁・計量器などで塞がっています。加えて、衛生管理の厳しい調理現場では衛生手袋を着用しながら調理するため、レシピ確認や在庫記録のたびに手袋を外してタブレットを操作する必要があります。セントラルキッチンでは複数ホテル・複数レシピ向けに大量の食材を一括管理する必要があり、在庫記録の重要性がより高い一方で、以下の問題が連鎖的に発生します: 手袋着脱による作業中断と衛生リスクの増大。また、食品安全のために中心温度の測定・記録が義務付けられているが、手作業での記録は漏れやすく、コンプライアンス違反のリスクがある 紙・Excel 依存によりデータがデジタル化されず、経営判断に活用できない 配布されたレシピを調理現場で調整しているが、現場でカスタマイズされ、記録されずに属人化している レシピは調理現場に持ち込まず、バックヤードに置いているため、新人や不慣れなメニューの場合は頻繁にバックヤードと調理場を往復することになり、作業効率の低下を招く 調理工程の進行状況が在庫管理システムと連動しておらず、食材の消費を都度手入力で記録する必要がある。入力が漏れると在庫の把握精度が下がり、食材切れへの対応が遅れる 2.2 音声認識活用のハードル 音声入力は「手が塞がる環境」の自然な解決策ですが、キッチン特有の課題があります。換気扇・鍋の音などの騒音環境、食材名の専門用語（食品業界固有の表現や略称）、そして方言やイントネーションの多様性です。汎用の音声認識エンジンでは認識精度が業務品質に達しないことが多く、業界特化の音声認識技術が求められます。また、騒音やノイズのある環境下で、正確に発話の意図を把握して操作する精度も求められます。 2.3 レシピ一括管理の困難さ これらの課題は、「現場で変更された変更がレシピ側に伝達されないこと」につながります。調理器具の違いや材料不足、その日の気温といった外的要因からしばしばレシピの変更が発生しますが、手袋着脱や両手作業による入力障壁がデータ不在を生み、それが管理者の可視性欠如、ひいては経営判断の根拠不足へと連鎖していきます。本ソリューションは、高精度な音声認識とAI エージェントによる入力障壁の解消とオペレーションの容易さを起点に、アプリの利用を通じてデータを構造化して蓄積することでこの課題を解決します。 2.4 調理工程の分担・シフト管理の非効率 セントラルキッチンでは、複数の調理スタッフが並行して異なる工程を担当します。しかし担当者の割り当てやシフトの組み合わせは現状では管理者が手動で判断・調整しており、以下の問題が生じやすい状況です: 各スタッフの習熟レベルや当日の人員状況を考慮した工程分担の最適化が属人化しており、担当管理者の経験と勘に依存している 突発的な欠員や工程の遅れが発生した場合の再割り当て判断に時間がかかり、他工程への連鎖遅延が発生する 調理実績データ（誰がどの工程に何分かけたか）が記録されないため、シフト最適化のための根拠データが蓄積されない 3. ソリューション概要 本ソリューションは、ハンズフリーで操作できるレシピ管理ソリューションです。調理者が音声だけで指示した内容を汲み取り、レシピ工程を進め、AIエージェントが次の工程へのナビゲーションや原材料チェック、工程メモといった操作を判断します。 AmiVoice が調理スタッフの発話を高精度にテキスト化し、AI エージェント（Amazon Bedrock AgentCore + Strands Agents）が意図を解釈して、レシピナビゲーション・在庫減算・履歴記録を自律的に実行します。調理スタッフは「ちょっと楽になった」と感じるだけですが、裏側では構造化データが自動的に蓄積され、管理者のリアルタイム可視化と意思決定を支援します。 3.1 主要機能 レシピ操作機能 音声レシピナビゲーション — 「次へ」「戻る」で工程を進め、工程完了時に使用食材の在庫を自動減算 AI 代替食材提案 — 「玉ねぎがない」と伝えると、レシピ文脈と在庫を踏まえた代替案を提示 原材料チェック — 「原材料チェック、玉ねぎ300グラム」で食材を照合。玉ねぎ/タマネギ/オニオンといった発話の表記ゆれも吸収 調理タイマー — 音声で開始・停止・リセット 工程メモ — 音声でレシピ工程にメモを追加し、ナレッジの蓄積に繋げる 図1 : 個別レシピ画面 レシピの変換機能 現状、Excelで管理しているレシピから、システム管理できる形式への変換 紙管理しているレシピを読み取り、システムで管理できる形に変換 図2 : レシピ取り込み画面 ダッシュボード機能 調理工程ごとの時間をアプリ側で測っておき、ダッシュボード上で可視化 図3 : ダッシュボード画面 アプリケーションは以下のように動作します。 4. システムアーキテクチャ 4.1 全体構成 図4 : システムアーキテクチャ システムは以下の 3 層で構成されています。 層 担当 主要技術 通信プロトコル プレゼンテーション層 ブラウザ画面・音声UI・BLE連携 Amazon S3 + Amazon CloudFront + AmiVoice API HTTPS / WebSocket / Web Bluetooth AI 判断層 音声コマンド解釈・ツール選択・応答生成 Bedrock AgentCore Runtime + Claude Sonnet 4 WebSocket (双方向ストリーミング) データ層 レシピ・在庫・履歴・チェック記録 Amazon DynamoDB + AWS Lambda + API Gateway HTTPS REST アーキテクチャはAI Agent基盤をはじめ、フルサーバレス構成を採用しています。そのため、インフラストラクチャの管理をAWSにオフロードすることができ、運用負荷を抑えつつ、使われていない時間帯のコストも低く抑えながら利用できます。 AI エージェントを通さない単純な読み取り操作は Amazon API Gateway から AWS Lambda を介して処理し、レイテンシを数百ミリ秒に抑えています。一方、音声を通じた操作は、 AmiVoice API を介して発話内容をテキストに起こしたのち、Amazon Bedrock AgentCore で処理しています。なお、ビジネスロジックは同等の Lambda 関数を呼ぶことで、同じロジックを複数の入口から再利用しています。 4.2 AWS リソース構成 全リソースは AWS CDK で定義しています。 カテゴリ リソース 用途 AI エージェント Bedrock AgentCore Runtime (Docker/Python) Strands Agent + Bedrock Claude Sonnet 4 コンピュート AWS Lambda (Python 3.12, ARM64) ビジネスロジックを実行 データベース Amazon DynamoDB Recipes / Inventory / History / IngredientChecks といったデータを保存 API Amazon API Gateway REST API Cognito Authorizer 付きデータ読み取りエンドポイント 認証 Amazon Cognito User Pool + Managed Login OAuth2 PKCE フロー、JWT 発行 CDN Amazon CloudFront, Amazon S3 SPA配信 + AgentCore リバースプロキシ + 画像CDN シークレット AWS Secrets Manager AmiVoice 認証情報を格納 IaC 補助 CloudFront Function SPA フォールバック + AgentCore パス書き換え 音声合成 Amazon Polly レシピ工程の読み上げ音声生成 4.3 AI エージェント設計 本システムの核となる AI エージェントは、Amazon Bedrock AgentCore Runtime 上で動作する Strands Agentsで実装しています。 エージェントは、中央のオーケストレーターがいて、ツールを @tool デコレータ でラップし、必要に応じて呼ぶ構造です。プログラマが分岐を記載するのではなく、判断そのものを LLM に任せるのが従来との大きな違いです。@tool は Strands SDK のデコレータで、関数の引数名・型とdocstringが自動的に LLM 向けの「ツール仕様」に変換されます。したがって、docstring は人間が読む際のコメントであると同時に、LLM が呼び方を理解するための仕様書にもなります。 ■ ツール定義 ツール名 役割 get_recipes レシピ一覧取得 get_recipe レシピ詳細取得 update_step_memo 工程メモ更新 get_inventory 在庫一覧取得 get_inventory_item 食材単品在庫取得 deduct_inventory 在庫減算（工程完了時） rollback_inventory 在庫ロールバック（戻る時） record_history 調理履歴記録 get_history 調理履歴取得 check_ingredient 原材料チェック照合 record_step_time 工程実績時間の記録 clear_ingredient_checks セッション配下の原材料チェックを全削除 invalidate_step_time 「戻る」時に工程の実時間記録を無効化 answer_recipe_question 調理に関する質問をナレッジベースから検索して返答 ■ プロンプト設計 システムプロンプトはハイブリッド方式を採用しています: 指示文（条件分岐、制約、スキーマ定義）: 英語で記載。トークン効率が高い コマンド例、出力メッセージ、食材名 : 日本語。ユーザー体験を優先 message フィールドは必ず日本語で出力するよう明示的に制約 この設計により、日本語のみのプロンプトと比較して入力トークン削減を実現しつつ、日本語での自然な応答品質を維持しています。 ■ 音声認識から画面操作までのフロー 図5:音声の発話からAI Agentが動作するイメージ 発話した内容をもとにページ操作を行うまでのフローは、下記の通りです。 音声入力 マイクまたはテキスト入力で文字列を受け取ります。 コンテキストの付与 発話テキストだけ送っても、LLMは「今どのレシピの何工程目か」という情報を知りません。そのため、コンテキストとしてページの位置情報、工程の調理内容や使用する食材も送付しています。このような構成にすることで、ユーザーが「省略した言葉」を補うことができます。人間同士の会話で「次」と言えば通じるのは、お互いが状況を共有しているからです。LLMにも同じ状況を渡すことで、人間相手のように省略して発話しても操作することができます。また、騒音で音声認識が乱れてユーザーの発話を正確に書き起こしできない場合でも、表記ゆれや誤変換を吸収してLLMが意図を汲んで操作することができます。 LLMが遷移先を判断 システムプロンプトのルールに従い、context を見て遷移先を決定します。JSON形式で返答します。 { "action": "navigate", "page": "recipe", "params": { "recipeId": "recipe-001", "stepNumber": 4 } } しばしばLLMの出力をアプリケーションで扱うとき、プロンプトで「JSON形式で出力して」と指示しても、余分な説明文が付加されていたり、フォーマットが微妙に崩れていたりと出力がぶれることがあります。そこで、Amazon Bedrock の Structured outputs を利用して一貫性のあるJSON出力に強制しています。Structured outputs は、必要な形式を事前に指定してそれに一致するレスポンスを受け取ることができる機能です。 フロントエンド側でページを遷移 フロントエンド側のコードで、返ってきたJSONの action を見て処理を振り分けます。対応するページコンポーネントの再描画や、ページ遷移を実施します。 4.4 AI エージェント設計アプリケーションへの AmiVoice の組み込み 音声の認識には、アドバンスト・メディア社の提供する AmiVoice を採用しています。 マイクの起動 音声認識特化型Bluetoothマイク AmiVoice Front WT01 を介してマイクを起動します。AmiVoice Front WT01は物理ボタン付きのデバイスで、ボタンを押すと Web Bluetooth API を介してブラウザ上のアプリケーションに接続します。Web Bluetooth APIはブラウザからBluetooth機器に接続する仕組みです。 発話内容の読み取りと発話区間の自動検出 AmiVoice APIを利用して発話した内容をテキスト化します。AmiVoice APIには同期・非同期 HTTP と、WebSocket インタフェースがありますが、WebSocketインタフェースを利用して中間認識結果をリアルタイムで表示しています。ユーザーの体感速度を大きく左右する要因です。 また、音声の中で発話区間を自動検出しているため、話し終えたタイミングでボタンを押すことなく発話の終了を検知しています。AmiVoiceの発話検出では深層学習モデルを使って、 人の声とそれ以外を区別していることが特徴 です。 最終的に、テキスト化されたコマンドを Amazon Bedrock AgentCore に送信します。 5. 音声認識エンジン: AmiVoice の技術 (1) AmiVoice の技術的特徴 音声認識には、音声から特徴量を抽出する音響分析と、特徴量を入力として認識結果のテキストを得る認識デコーダの二つのステップがあります。様々な周波数で構成されている波形データを音響分析で音の特徴に数値化して、その特徴量を認識デコーダに入力しています。 AmiVoice APIは、認識デコーダのタイプにより、「DNN-HMMハイブリッド型（以下、ハイブリッド型）」「End-to-End型」の2つのタイプがあります。伝統的な統計モデルである、「発音辞書」「音響モデル」「言語モデル」を組み合わせて音声認識を行うハイブリッド型に対して、End-to-End型は音声入力から直接文字列を出力する一体型の処理という大きな違いがあるのですが、どちらのタイプでもDNNというディープラーニングモデルが使われています。 図6 : ハイブリッド型認識デコーダのイメージ DNN（Deep Neural Network：ディープニューラルネットワーク）は、多層構造を持つニューラルネットワークです。ニューラルネットワークは、生物の神経回路網を計算機上で模した技術であり、音声認識の分野ではDNNを用いた音響モデルが、音声特徴量から音素を推定する仕組みとして従来のGMM-HMMに代わって主流となりました。その後、音声認識技術は、時系列データを扱いやすいLSTMやBiLSTM、さらに広範囲の文脈を効率的に学習できるTransformerへと発展してきました。これらのモデルは構造こそ異なりますが、いずれも音声と発話内容の関係を学習し、入力音声から発話内容を推定するという基本原理は共通しています。 AmiVoice APIは、音声認識技術をシンプルにご利用いただけるAPIサービスです。インターネットからの簡単な登録だけで、すぐに利用を開始できるため、音声認識機能を手軽かつスピーディーにアプリケーションやサービスへ組み込むことができます。日本語に対する高い認識精度を特長とし、ビジネス利用を想定した言語モデルにより誤認識の低減を実現しています。また、医療・金融・保険・コンタクトセンターなどの業界特有の専門用語に強く、製品名や固有名詞の登録にも対応しています。特別な知識や発声の訓練を必要とせず、普段どおりの自然な会話を高精度に認識できます。また、話者による発音の傾向やイントネーションの違いの影響を受けにくく、騒音環境や電話音声でも安定した認識性能を発揮します。国内で開発・運用されているため、音声データを国内環境で安全に管理できる点も大きな特長で、セキュリティを重要視するお客様にも多数選ばれています。 図7 : AmiVoiceの音声認識技術 AmiVoice APIを選んでいただいたお客様に高く評価されているのがリアルタイム性を追求したWebSocket API のストリーミング型音声認識です。AmiVoice APIのWebSocketインタフェースでは、クライアントが開始s・音声送信p・終了eの各コマンドを段階的に送る一方、サーバーは発話開始S、終話E、認識開始C、途中結果U、確定結果Aをイベントとして逐次返します。これにより、音声を最後まで送り切ってから一括変換するのではなく、発話区間ごとに認識を進めながらテキストを即時更新できます。さらに、発話検出で無音と発話を細かく切り分け、resultUpdatedIntervalなどの設定で途中結果の返却タイミングを制御できるため、ユーザー画面には短い間隔で認識文が反映されます。結果として、リアルタイム音声送信に対して遅延のない逐次テキスト化を実現できる点が大きな特長です。 3つの発話区間を検出した場合の、コマンドとイベントのシーケンスは以下のようになります。 図8 : コマンドとイベントのシーケンス (2) 食品製造現場への適用と認識精度の向上 アプリケーションはキッチン等の騒音の多い環境で利用されることが想定されるため、人の声と不要音を分別して認識できる精度が必要不可欠です。AmiVoice APIは、セグメンタ（VAD）により人の発話区間を高精度に検出し、調理場などノイズの多い環境でも不要音の影響を抑制。背景音・機械音・保留音などを認識対象から適切に除外し、必要な音声だけをテキスト化します。さらに利用シーンに応じたパラメータ調整も可能で、現場で使える安定した音声認識を実現します。 AmiVoice APIは、長年にわたって蓄積した音声認識のノウハウをもとに、高精度な言語モデルを構築しています。最新のニュースや業界文書などのテキストコーパスを活用し、新語や業界特有の用語にも迅速に対応します。また、不要データの除去、専門用語の読み登録、表記統一、誤認識分析、パラメータチューニングなどを継続的に実施することで、変化する言語環境に適応しながら高い認識精度を維持します。これにより、食材名・調理用語など業界特化の語彙への対応も可能です。 同じ用語の表記ゆれに対応する際、音声認識だけでなく生成AI（LLM）を活用する方が効果的な場合があります。例えば、品種名である「ヒノヒカリ」を単語登録し、”ひのひかり”の認識精度を上げることは有用と思われます。しかし、”なす”を「茄子」や「ナス」に変換する目的で単語登録すると、意図しない箇所で「茄子」や「ナス」が誤って出現する可能性があります。このような場合の表記ゆれの統一は、単語登録ではなく、文脈を理解できるLLMに任せることで副作用を抑えながら「なす」「茄子」「ナス」を同じ食材として柔軟に扱うことができ、より高い効果が期待できます。 (3) 今後の展望 AmiVoiceは、クラウド環境だけでなく、スマートフォンやタブレット上で動作するオンデバイス型、お客様環境内で音声認識を完結できるオンプレミス型SDKも提供しています*1。音声データを外部へ送信できないセキュリティ要件の厳しい環境や、ネットワーク帯域が限られる現場でも、高精度な音声認識を実現します。利用環境や運用ポリシーに応じて最適な構成を選択できるため、製造、物流、医療、食品業界など幅広い業務シーンにおいて、安心・安全な音声活用による業務効率化を支援します。 今後は、これまで進めてきた業種・業務に特化したSaaSソリューションとの連携・組み込みをさらに拡大し、音声認識技術の活用シーンを広げていきます。加えて、新たな取り組みとして、AIエージェントが業務プロセスの中で音声認識を活用し、自律的に業務を遂行できる次世代ワークフローの実現を目指していきます。 *1 AWSMarketPlaceではクラウド型AmiVoiceAPI(AmiVoiceCloud Platform)のみの提供となっております 6. 他インダストリーへの応用可能性 本ソリューションのコアパターン「音声認識 (AmiVoice) × AI エージェント (Bedrock AgentCore) × 構造化データ自動記録」は、手が塞がる業務環境全般に適用可能です: インダストリー 応用例 期待効果 食品製造全般 外食チェーンのセントラルキッチン、給食センター、食品工場 在庫自動管理、HACCP 準拠記録、熟練者依存の解消 ホテル・宿泊業 ルームメイキング手順ナビ、備品在庫管理、設備点検記録 品質標準化、記録工数削減 医療・介護 手術室での手順確認、投薬チェック、バイタル記録 衛生環境維持しつつ情報アクセス、記録自動化 製造業 組立作業手順ナビ、品質検査記録、設備保全チェック 教育期間短縮、技能伝承のデータ化 物流・倉庫 ピッキング指示、検品記録、入出庫管理 ハンズフリーオペレーション、誤出荷防止 フィットネス・スポーツ トレーニング指示、フォームチェック、セッション記録 指導品質の標準化、データドリブンな改善 技術的な拡張ポイント: Strands Agents のツール定義 (@tool デコレータ) を差し替えるだけで異なるドメインのエージェントを構築可能 AmiVoice の単語登録を実施することで、医療用語・製造用語などの独自の用語にも精度改善が期待できる AgentCore Runtime のマネージド環境でスケーラブルに運用でき、マルチテナント化も容易 7. まとめ 本ブログでは、セントラルキッチンの業務課題を、AmiVoice による高精度音声認識と Amazon Bedrock AgentCore による AI エージェントの組み合わせで解決するアーキテクチャを紹介しました: AmiVoice — 騒音環境・食品業界用語に対応した高精度な日本語音声認識で、現場の「声」を確実にテキスト化 Amazon Bedrock AgentCore Runtime + Strands Agents SDK — マネージド環境で AI エージェントを運用し、WebSocket ストリーミングによるリアルタイム対話を実現 Claude Sonnet 4 の Tool Use — 14 個のツールを自律的に使い分け、曖昧な音声コマンドから適切なアクションを導出 構造化 JSON レスポンス設計 — エージェントとフロントエンドの明確なインターフェース契約により、UI 制御の信頼性を確保 サーバーレス従量課金構成 — DynamoDB On-Demand + Lambda ARM64 + CloudFront でコスト効率を最大化 「手が塞がっている環境でのデータ入力障壁」は、食品製造に限らず多くの業界で共通する課題です。高精度な音声認識と AI エージェントの組み合わせは、この課題に対する有力なソリューションパターンです。本アーキテクチャが、音声 AI エージェントシステムの設計を検討されている方の参考になれば幸いです。 著者について 戸塚 智哉 (Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 本田 光来 (Miku Honda) 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行っているソリューション アーキテクトです。サーバーレス領域が得意で、好きな AWS サービスは AWS Lambda です。 兼子 友里朱 (Yuria Kaneko) AWS Japanのアカウントマネージャーです。主にサービス業・SIer業界のエンタープライズ企業をご支援しています。新規案件創出数アジア太平洋地域1位（FY24 第1四半期・上半期）、生成AI案件創出金額日本1位（FY25 第4四半期）。趣味はクラシックバレエで、コンクールでは第2位を受賞しました。薬剤師免許保有。 吉田 明日香 (Asuka Yoshida) 株式会社アドバンスト・メディアのセールスマネージャーです。音声認識サービス「AmiVoice API」の提案・活用支援・協業推進を担当しています。幅広い業界においてお客様の音声データ活用や生成AI活用をご支援しています。 小出 泰久 (Yasuhisa Koide) 株式会社アドバンスト・メディアのエンジニアです。オフィスソリューションや医療機器開発のプロジェクトマネージャーとしての経験を活かし、現場視点での音声認識技術の活用に注力しています。

AWS Japan パブリックセクター技術統括本部では、2026年4月よりセキュリティワークショップを月次で開催しています。第1回・第2回では「 ランサムウェア対策ワークショップ 」として Amazon GuardDuty による脅威検知と AWS Security Hub による統合セキュリティ管理を、第3回・第4回では「 Claude Mythos 時代の脅威対策ワークショップ 」としてフロンティア AI を悪用した攻撃への対策と脆弱性管理をテーマにしてきました。 第5回となる今回はテーマを「信頼性」に拡大し、システムの 「耐障害性（レジリエンス）」 を継続的に向上させるアプローチをお伝えしました。 サイバー攻撃への「防御」と並び、障害が発生しても迅速に回復できる「耐障害性」は、ミッションクリティカルなシステムを運用するうえで不可欠な要素です。近年はリリース頻度の増加や AI を活用した開発の加速により、システム環境の変化がこれまで以上に速くなっています。故障しないことを前提とする堅牢なシステムを目指すだけでは十分ではなく、 継続的にレジリエンスを強化し続ける仕組み が求められています。 本記事では第5回の開催レポートと、次回（第6回）のご案内をお届けします。 ワークショップの概要 項目 内容 テーマ FlyWheel で回す継続的なレジリエンス強化 日時 2026年8月21日（金）14:30 – 17:30 形式 オンライン（WebEx） 主催 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 対象 システムアーキテクト、運用担当者、耐障害性（レジリエンス）向上に関心がある方 関連サービス AWS Resilience Hub, AWS Fault Injection Service, Amazon CloudWatch など 座学では「耐障害性ライフサイクル」と「FlyWheel」の考え方を学び、AI を活用した各ステージの効率化や AWS 支援プログラムもご紹介しました。ワークショップでは、たこ焼き注文システムを題材に、耐障害性ライフサイクルの各ステージを実際に体験いただきました。講師はシニア ソリューションアーキテクトの小本昌兵が務めました。 座学: 耐障害性ライフサイクルと Resilience FlyWheel 「壊れない」から「壊れても素早く回復する」へ Amazon CTO の Werner Vogels が語る “Everything fails, all the time.”（すべてのものは、いつでも壊れうる）という原則に基づき、稼働期間中に要件が変化していく中で、故障しないことを前提とする堅牢なシステムを目指すのではなく、 障害が起きても素早く回復するシステム を目指すことが重要になっていきます。座学では、まずこのメンタルモデルの変化をお伝えしました。 耐障害性ライフサイクルフレームワーク — 5つのステージで具体的に取り組む この考え方を実践に移すために、AWS が規範的ガイダンスとして公開している「 耐障害性ライフサイクルフレームワーク 」に沿って、5つのステージを解説しました。 目標を設定 — ビジネスインパクト分析（BIA） を通じて RTO（目標復旧時間）/RPO（目標復旧時点）/SLO（サービスレベル目標）を設定し、ユーザージャーニーとクリティカルパスの視点で目標を定義します。サービス視点で、「どのサービスが止まると、どれだけの影響が出るか」を定量的に把握するところから始めます。 設計と実装 — AWS Well-Architected Framework の信頼性の柱を基に、障害分離境界（データプレーン/コントロールプレーン）の区分、静的安定性（障害時にコントロールプレーンに依存せず、元の設定のままワークロードが動き続ける設計）の確保といった設計原則を適用します。座学では耐障害性モデリング（SEEMS: 5つの一般的な障害カテゴリ）についても具体的に紹介しました。 評価とテスト — 「目標を達成できるか？」を本番相当の環境で検証していきます。評価は、一度きりではなく、継続的に仮説検証を行います。AWS Fault Injection Service（AWS FIS）による障害注入の実行/管理や、AWS Resilience Hub を活用した耐障害性の評価が役に立ちます。 運用 — オブザーバビリティ（可観測性）を確保し、カスタマーエクスペリエンス指標を継続的にモニタリングします。異常を早期に検知し、影響が拡大する前に対処するための体制を整えます。 対応と学習 — インシデントが発生した場合、その体験から学ぶことが重要になります。インシデント発生後に、CoE（Correction of Errors）を使って振り返りと再発防止策を文書化し、組織として学びを蓄積します。この学びが次のサイクルの「目標設定」にフィードバックされます。 Resilience FlyWheel — 継続的に回し続け、加速する 上記5ステージを1回実施して終わりではなく、 FlyWheel（フライホイール）として継続的に回し続ける ことが本ワークショップのコアメッセージです。Amazon のビジネスモデルフライホイールに着想を得たこのアプローチでは、初回のサイクルこそ重たいですが、サイクルを回すたびに複利でレジリエンスが向上し、回転が加速していきます。 さらに、 AI を活用して耐障害性フレームワークを効率化する方法 や 次世代の AWS Resilience Hub 、ビジネスインパクト分析(BIA)、レジリエンススコアプログラム(RCP)など、AWS の支援サービスもご紹介しました。BIA は耐障害性ライフサイクルフレームワークを開始するための目標設定をサポートするプログラムです。ご関心ある方は担当の AWS アカウントチームにお問い合わせください。 ワークショップ: たこ焼き注文システムで体験する耐障害性ライフサイクル ワークショップの狙い 座学で学んだ耐障害性ライフサイクルの各ステージを、参加者自身が実際に手を動かして体験することが本ハンズオンの狙いです。抽象的なフレームワークを具体的なプロセスとして体感し、自組織のシステムに当てはめてイメージしていただくことを目指しました。ワークショップ教材は こちら からご確認いただけます。 具体的に何を体験できるか 架空の「たこ焼き注文システム」を題材に、耐障害性ライフサイクルに基づき、Active/Active アプリケーションの目標設定から運用まで、包括的に体験をしました。 目標の設定 : アプリケーションのダウンタイムにより発生する売上の損失から、具体的なRTOとRPOの値を決定。レジリエンスポリシーを作成して、Resilience Hub に設定 設計の見直し : マルチAZ で自動復旧を実現するため、オートゾーンシフトの有効化 運用監視の設定 : アプリケーションの監視のための、Amazon CloudWatch Synthetics Canary の作成とアラート設計 評価とテスト : Resilience Hub による評価と回復力テストの実践（AZ で電源が中断されたというシナリオで、ゾーンシフトが設計通りに動作するかを確認する） インシデント対応 : 障害発生時の対応フローのレビュー 参加者からのフィードバック 参加者からは、「ハンズオンについては、やや難しかったが、更に耐障害性を高めていく上で参考になった」など、ポジティブなご意見をいただけました。また、AWS Resilience Hub の利用状況を伺ったところ、大半の方がまだ利用されていない状況でした。ワークショップ後には、約70%の方が Resilience Hub を「利用してみたい」と回答いただきました。定量的な目標設定と継続的な評価はレジリエンス改善の基礎となります。今後も個別案件の支援などを通じて、耐障害性を高めるお手伝いをしていきたいと考えています。 まとめと次回のご案内 本ワークショップのキーメッセージ 本ワークショップを通じて、以下の3点をお伝えしました。 メンタルモデルの変化 : 「障害がおきないシステムを作る」アプローチの限界を認識し、「障害がおきても素早く回復するシステムを作る」ことに意識を向ける。障害は起こりえる前提で備える。 実践のフレームワーク : AWS 規範的ガイダンス「耐障害性ライフサイクルフレームワーク」（目標設定→設計・実装→評価・テスト→運用→対応・学習）の5つのステージが、具体的な取り組みの指針となる。 継続的な改善 : ライフサイクルを一度回して終わりではなく、FlyWheel として継続的に回し続けることで、レジリエンスを加速度的に向上させる。AI や AWS の支援サービスを使って、このサイクルをさらに効率化する。 耐障害性の向上は、一度きりの対策ではなく日々の運用の中で磨き続けるものです。本記事がその第一歩を踏み出すきっかけになれば幸いです。ミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド活用で課題をお持ちの場合は、担当の AWS アカウントチームにご連絡ください。 第6回: AWS WAF 実践ワークショップ — AI時代のWebアプリケーション防御を学ぶ 項目 内容 日時 2026年9月28日（月）14:30〜17:30 形式 オンライン（WebEx） 座学 AWS WAF を活用した Web アプリケーションの保護 ハンズオン WAF ルールの設定からログ分析・可視化 対象 システムアーキテクト、セキュリティ担当者、Web アプリケーション運用担当者 関連サービス AWS WAF, AWS Shield, Amazon CloudWatch, Amazon Athena AI Bot の急増や DDoS 攻撃の高度化により、Web アプリケーション防御の重要性は、ますます高まっています。次回は AWS WAF のマネージドルール、Bot 対策、各種 AWS サービスと連携したログ管理の仕組みなど、実践的な AWS WAF の活用手法をご紹介します。座学のみ、ハンズオンのみのご参加も可能です。ご関心ある方は担当の AWS アカウントチームにお問い合わせください。 著者 日吉 康仁 (Koji Hiyoshi) — AWS Japan, Public Sector, Senior Solutions Architect 今井 真宏 (Masahiro Imai) — AWS Japan, Public Sector, Senior Solutions Architect

本記事は 2026 年 8 月 27 日 に公開された「 A year of expanding choice for VMware customers on AWS 」を翻訳したものです。 Amazon EVS が一般提供 (GA) を開始してから 1 年以上が経ちました。人材やツール、運用ワークフローへの既存の投資を維持しながらクラウドでより多くの選択肢を求めていた VMware ワークロードのお客様にとって、Amazon EVS の GA 開始は大きな節目でした。Amazon EVS を使用すると、AWS 環境と統合された Amazon EC2 ベアメタルインスタンス上で VMware Cloud Foundation (VCF) を実行できます。チームは VMware のソリューションを継続して使用しながら、AWS の機能とグローバルな展開力を活用できます。 この 1 年間で新しい VCF バージョンのサポートを追加し、デプロイの自動化機能をリリースし、新しい EC2 インスタンスへの対応も拡大してきました。VCF 9 の Memory Tiering や NSX Federation の設定に関するガイダンスも公開し、新しい Windows Server ライセンスの権利オプションも導入しました。これらの機能追加により AWS で稼働する VMware ワークロードのデプロイ、運用、スケーリング、保護をお客様がより細かく制御できるように取り組んでいます。 ここからは最初の 1 年間でお届けした内容を詳しく紹介します。 VCF 9 を思い通りにデプロイ 今年に入って Amazon EVS での VCF 9.0 および 9.1 のサポート を発表しました。VCF 9 では Amazon EVS が VPC 内に EC2 ベアメタルインフラストラクチャをプロビジョニングし、アーキテクチャや設定はネイティブの VCF Installer でお客様自身が管理します。この制御レベルは VCF のライフサイクル全体に及ぶため、オンプレミスと同じ VCF の機能を Amazon EVS でも利用できます。 自動インストールを好むチーム向けには Solutions for Amazon EVS GitHub リポジトリ で Amazon EVS Deployment Orchestrator を公開しました。Amazon EVS Deployment Orchestrator には Amazon EVS 上に完全に構成された VCF 9 環境をデプロイするためのエンドツーエンドの自動化が含まれています。今後も計画、デプロイ、移行、運用のための新しいソリューションを追加していきます。 新しい i7i.metal-48xl、AWS リージョンの拡大、より大規模な環境でスケール 4 月には i7i.metal-24xl のサポート を追加して EC2 インスタンスの選択肢を拡大し、本日 i7i.metal-48xl のサポート を発表します。この新しいインスタンスは物理コア 96 個、メモリ 1.5 TB、ローカル NVMe ストレージ 45 TB を備え、負荷の高い VMware ワークロードに対応する大きなキャパシティを提供します。 第 5 世代 Intel Xeon Scalable プロセッサーを搭載した i7i インスタンスは、i4i インスタンスと比べてコンピューティング性能が最大 23% 向上し、料金性能比も 10% 以上向上しています。i7i.metal-48xl はコア数とメモリ容量が増えているため、ホストあたりでより多くの VM を実行でき、少ないホスト数でも環境を拡張できます。 また Amazon EVS の対応リージョンを 22 の AWS リージョンに拡大し、エンドユーザーの近くにワークロードを配置したり、ビジネス目標やデータ主権の要件に合わせたデプロイができるようになりました。さらに環境の最大サイズを 16 ホストから 32 ホストに増やしました。1 つの環境内で大規模な単一クラスターを構築することも、複数の小規模クラスターに分けることも、要件に合わせて自由に組み合わせることもできます。 Memory Tiering でクラスター密度を向上 VCF 9 は、ホストがローカル NVMe ストレージを追加メモリとして利用できる Memory Tiering を導入しました。同じホスト数でもクラスターが実質的に最大 2 倍のメモリを扱えるようになり、VM の密度を高めながらハードウェアとライセンスのコストを削減できます。Memory Tiering は i4i および i7i の両インスタンスファミリーに対応しています。 Memory Tiering の詳細解説 ではこの機能の仕組みや、Amazon EVS でのサイジングと有効化について説明しています。 Windows Server のライセンスをシンプルに Windows Server のライセンスは VMware の移行を計画する際に障壁となることがあります。 Amazon EVS Windows Server Licensing では Windows VM を実行するための 2 つの選択肢を用意しています。対象となる Windows Server ライセンスと移行権を持つお客様は、そのライセンスをそのまま Amazon EVS に持ち込めます。移行権のない VM については、Amazon EVS で Windows Server ライセンスの権利を追加し、使用した分だけ vCPU 時間単位で料金を支払えます。権利は環境の変化に応じて追加・削除できるため、個々の VM 単位でライセンスを付与し、ホスト全体にライセンスを付与するコストを回避できます。 Amazon EVS で VMware ワークロードを保護・復旧 Amazon EVS を使うと、チームが既に使い慣れた VMware のツールとプロセスのまま、AWS 上で VMware ワークロードを柔軟に保護・復旧できます。オンデマンドで復旧環境をデプロイし、ワークロードを変更せずに稼働させ、復旧目標に合わせてキャパシティをスケールできます。 Amazon EVS における VMware ワークロードの災害復旧ガイド では復旧方法と保護オプションを比較しており、ワークロードごとに復旧時間、復旧時点、コスト、運用要件のバランスを取れます。 サイト間でネットワークとセキュリティを拡張 またオンプレミスの NSX 環境と Amazon EVS 環境を単一のコントロールプレーンで管理できる NSX Federation のサポートも発表しました。NSX Federation により拠点をまたいでネットワークセグメントとセキュリティポリシーを拡張し、データセンターと AWS の間で統一されたネットワーキング基盤を構築できます。大規模なレイヤー 2 拡張、統一された Distributed Firewall ポリシー、簡素化された災害復旧のフェイルオーバーを必要とするお客様にとって、NSX Federation は HCX の移行ワークフローを補完する長期的なネットワーキングと復旧の基盤となります。 NSX Federation の詳細解説 では両方の技術がどのように連携し、それぞれがどのような場面に適しているかを説明しています。 より広い選択肢を提供した 1 年間 今年リリースしたすべての機能はチームが使い慣れた VMware のツールと運用ワークフローを維持しながら、Amazon EVS でより多くの制御、選択肢、柔軟性を提供するという目標を支えるものです。VMware を利用している組織であれば、Amazon EVS を VMware ベースのワークロードを実行する世界最高の場所にしたいと考えています。 次のステップ: VMware Explore 2026 で Amazon EVS をご覧ください 最新の取り組みを実際にご覧になりたい方は、8 月 31 日から 9 月 3 日までラスベガスの The Venetian で開催される VMware Explore 2026 にぜひお越しください。 今すぐセッションをスケジュールに追加してください 。 ブレイクアウトセッション [CLOB2172LVS] Amazon EVS with VCF 9: Expanding choice and flexibility for VMware on AWS – 9 月 2 日(水) | 午後 3:15 – 午後 4:00 | Level 3, San Polo 3505 20 分間シアターセッション [CLOQT2319LVS] 20-minute guide to running VMware Cloud Foundation 9 on Amazon EVS – 8 月 31 日(月) | 午後 5:30 – 午後 5:50 | The Hub Theater VMware Explore にご参加の有無を問わず、皆様が取り組んでいる内容についてぜひお聞かせください。 Amazon EVS の製品ページ にアクセスして利用を開始するか、AWS のアカウントチームに連絡して次のステップを検討してください。 著者について Bianca Velasco AWS のプロダクトマーケティングマネージャーとして、VMware ベースのワークロードの AWS への移行とトランスフォーメーションを担当しています。マーケティングとテクノロジー分野で7年以上の経験を持ち、複雑な技術を分かりやすく伝えるストーリーづくりに情熱を注いでいます。AWS の業務以外では、ボランティア活動、ダンス、ボルダリングを楽しんでいます。 Andy Reedy EC2 Commercial Applications のシニアプロダクトマネジメントマネージャーとして、VMware、SAP、Red Hat OpenShift のワークロードを担当するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェアの分野で25年以上の経験を持ち、お客様のビジネスクリティカルなアプリケーションの移行とモダナイゼーションを支援することに情熱を注いでいます。 Spiros Tsitsonis AWS のシニアテクニカルプロダクトマネージャーとして、インフラストラクチャの移行と Amazon Elastic VMware Service を担当しています。以前は Amazon Elastic Container Service とサーバーレスの Fargate チームを管理しており、AWS のサービスを活用してお客様がビジネス成果を達成することを支援することに情熱を注いでいます。プライベートでは、旅行を通じて様々な場所や人々、文化に触れることを楽しんでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

AI 駆動開発ライフサイクル (AI-DLC) の基礎を体系的に学べるコース「 AI-DLC Foundations 」の日本語版として「 AI 駆動開発ライフサイクル (AI-DLC) ナレッジバッジ 」が、AWS Skill Builder で公開されました。この記事では、コースの概要と全 8 モジュールの内容を紹介します。 今すぐコースを受講する場合はこちら コースの概要 AI 駆動開発ライフサイクル (AI-DLC) ナレッジバッジ は、AI-DLC について基礎から体系的に学べる全 8 モジュールのオンラインコースです。動画とスライドを使い、自分のペースで受講できます。概念の理解から始まり、原則、ワークフロー、ベストプラクティス、そしてインセプション・コンストラクション各フェーズの Deep Dive まで段階的に学びます。全モジュール完了後の Assessment に合格すると AI-Driven Development Lifecycle Knowledge Badge を取得できます。どなたでも無料で受講可能です。 AI 駆動開発ライフサイクル(AI-Driven Development Lifecycle, AI-DLC) とは 多くの企業が AI コーディングツールを導入していますが、「コーディング工程の時短は実現できても、開発ライフサイクル全体のアジリティには繋がっていない」という課題が聞かれます。AI-DLC は、この課題に対する AWS の回答です。 AI-DLC (AI 駆動開発ライフサイクル) は、AWS が提唱している、AI 駆動型ソフトウェア開発の方法論です。AI が開発プロセス全体をオーケストレーション (計画策定、タスク分解、アーキテクチャ提案など) し、人間が検証・意思決定・監督の責任を保持します。 これは、既存のプロセスに AI を狭い範囲で後付けする「AI 支援型 (AI-Assisted)」アプローチとも、AI が自律的にソフトウェアを構築する「AI 管理型 (AI-Managed)」アプローチとも異なります。AI-DLC では、AI がプロセス全体をオーケストレーションしながらも、人間が意思決定と監督に集中することで、開発速度・品質・アジリティのパラダイムシフトを実現します。 開発はインセプション (Inception) フェーズ、コンストラクション (Construction) フェーズ、オペレーション (Operation) フェーズの 3 つのフェーズで進みます。インセプションではビジネスの意図を精緻な要件・設計・作業計画に変換し、コンストラクションでは AI がコード・テスト・設計を生成して人間が検証し、オペレーションではデプロイ・監視・運用を自動化します。 AI-DLC の方法論について詳しくは「 AI-DLC 入門 ― 開発の未来を形づくる新しいアプローチ 」および「 AI駆動開発ライフサイクル（AI-DLC）の本質は組織、文化、プロセスの変革 〜AI-DLC導入のアンチパターン〜 」もご参照ください。 モジュールの一覧と概要 本コースは以下の 8 モジュールとAssessment で構成されています。 1. AI-DLC の概要: AI-DLC とは何か、なぜ必要なのか、AI-DLC の中核となる概念を学びます AI コーディングツールが普及した今、なぜ組織全体のアジリティが上がらないのか – その問いへの答えから始まります。AI 支援型・AI 管理型とは何が根本的に異なるのかを明確にし、AI-DLC の中核であるワークフローの全体像を掴みます。 2. 従来の SDLC (ソフトウェア開発ライフサイクル) からの進化: ソフトウェア開発の方法論の歴史を振り返り、なぜ AI 時代に「再構築」が求められるかを学びます ウォーターフォールからアジャイルへの転換は、ハードウェアの高速化やインターネットの普及がビジネスのスピードを変えた結果として現れました。同じ構造が今、AI によって繰り返されています。AI が数時間でコードを生成・検証できるのに、翌日のスタンドアップミーティングまで議論を待つ意味があるのか ? この問いを通じて、開発プロセスへの再構築が必要な理由を理解します。 3. AI-DLC の原則: AI-DLC を定義する 9 つの原則を学びます AI-DLC は「既存プロセスを速くする」のではなく「AI 時代にネイティブな新しいプロセスを作る」という根本的な発想の転換に基づいています。このモジュールでは、AI がリードし人間が意思決定に集中する対話モデル、設計を方法論の DNA として組み込む考え方、AI の強みと限界に合わせてプロセスを最適化するアプローチなど、AI-DLC を支える 9 つの原則を一つずつ解説します。 4. AI-DLC ワークフローとコラボレーション: AI と人間の継続的なワークフローと、チームのコラボレーションパターンを学びます AI が数時間で十分な実装を生成する世界では、チームが迅速で質の高い決定を下す能力がボトルネックになります。このモジュールでは、AI が計画を作成し人間が承認するサイクルの詳細と、プロダクトオーナー・開発者・セキュリティ・運用が一体となって意思決定を加速するコラボレーションパターンを学びます。Amazon の リーダーシッププリンシプル に由来する One-Way Door / Two-Way Door の意思決定フレームワークも扱います。 5. AI-DLC ベストプラクティス: 実践で検証された 7 つのベストプラクティスを学びます AI-DLC を実プロジェクトで運用してきたチームが蓄積した知見をご紹介します。AI に一度にすべてを解決させようとしない、AI に渡すコンテキストの質を高める、AI が勝手に範囲を広げないよう境界を設定する、レガシーシステムを扱う際の注意点など、明日から使える実践的なガイドラインを学びます。 6. AI-DLC の準備、測定: 組織で AI-DLC を始めるための準備と、成功の測定方法を学びます AI-DLC を組織で始めるには何が必要で、その効果をどう測るかを解説します。まず事前準備として、技術環境の整備、役割を横断した同じ場所での作業体制、ドメイン固有の知識の 3 つの要素を確認します。そして効果の測定では、各フェーズでの削減時間と、要件の精度・設計の安定性・コードの受け入れ率の 2 つの軸で評価する方法を学びます。重要なのは、作業ごとの AI のスピードではなく、開発ライフサイクル全体への影響を測定するという考え方です。 7. インセプションフェーズ Deep Dive: インセプション (Inception) フェーズを深掘りします 「何を作ろうか」という会話から、チーム全員が「何を作るべきか」を明確に共有するまでのプロセスを、従来の数日〜数週間から数時間レベルに圧縮します。チーム全員が AI と共にリアルタイムで要件を精緻化するモブエラボレーション (Mob Elaboration) や、インテント (意図) から作業ユニット (Unit of Work) への分解手法を具体的に学びます。 8. コンストラクションフェーズ Deep Dive: コンストラクション (Construction) フェーズを深掘りします インセプションで定義した作業ユニットを、テスト済みでデプロイ可能なソフトウェアへ変換するフェーズです。従来のスプリントに代わる高速イテレーション「ボルト (Bolt)」の進め方、最初のボルトで End-to-End のアーキテクチャを証明する Walking Skeleton、そしてチーム全体がリアルタイムで設計に取り組むモブコンストラクション (Mob Construction) の実践方法を学びます。 Assessment: 全モジュール完了後に受験できる理解度確認テストです。合格すると AI-Driven Development Lifecycle Knowledge Badge を取得できます。 受講方法 AWS Skill Builder に無料アカウントを作成 (または既存アカウントでサインイン) こちらのリンク からコースに直接アクセス、または「AI-DLC」で検索 各モジュールは動画＋テキストコンテンツで構成されています。自分のペースで受講してください まとめ AI-DLC 学習コースの日本語版が無料で利用可能になりました。AI を活用した開発の新しいアプローチに興味がある方は、ぜひ受講してみてください。 コースを受講する (日本語) AI-DLC のさらに詳しい実践方法に興味がある方は、「 AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化 」もご覧ください。

本記事は Physical AI デモ開発の技術解説シリーズ Part 2 です。 Part 1: 企画からステージ制作、アプリケーション開発まで では、企画からクラウド側アプリケーションまでの開発と、その過程での生成 AI 活用を紹介しました。Part 1 のまとめに「プロセスの型が品質を守る」という言葉があります。本記事はその続きです。実機のロボット開発では、この型に安全と物理世界の検証が加わります。 AWS Summit Japan 2026 の展示エリア「AWS EXPO」で私たちは、FANUC の協働ロボット CRX-20iA/L （以下、CRX）2 台と配送車両を使い、AI エージェントが配送経路上の障害物を見つけ、つかんで運び、配送を復旧するデモを展示しました（ 展示紹介記事 ）。2 日間の Summit 期間中、障害物のピックは失敗ゼロでした。ロボット向けの追加学習は行っていません。 本記事でわかることは次の 3 つです。 クラウド上で動く AI エージェントと、従来のロボット制御の役割分担 — 何を任せ、何を任せなかったか 開発者の手元で動くコーディングエージェント（Kiro や Claude Code のような AI コーディング支援ツール）を、実機が動く開発で安全に使うためのルール ROS 2 ベースの標準スタックとシミュレーター上での検証で、実機の試行錯誤を最小にする方法 — 豊富な公開情報がある OSS を活用することで、コーディングエージェントによる適切な提案が可能になります 図 1: AWS Summit Japan 2026 の展示フィールド。2 台の協働ロボットと配送車両、周回路を配置 ロボットシステムの構成 — 2 台の CRX と 1 つの AI エージェント このデモの設計は一言で表せます。判断はクラウド、実行はエッジ。状況を見て次の行動を決めるのは、 Amazon Bedrock AgentCore （AI エージェントの実行基盤）の上で動く AI エージェント（Claude Sonnet 4.6 / Claude Haiku 4.5）で、その判断が物理世界の動作に変わります。指令は AWS IoT Core を経由してエッジの ROS 2（センサーや制御機能を連携させるロボット向けのソフトウェア基盤）へ届き、その上で動作計画と衝突判定を担うライブラリである MoveIt 2 が軌道を計画して実機が動きます。本記事で扱うのは、このクラウドからエッジまでの一本の経路の作り込みです。クラウド側の作りは Part 1 をご覧ください。 エッジ側の構成はシンプルです。この ROS 2 スタックを載せた Ubuntu 24.04 の制御 PC が、CRX のコントローラーと 1 対 1 で接続します。1 対 1 に固定したのは、同じコントローラーへの二重接続を構成上防ぎ、トラブル時の切り分けを単純にするためです。アーム先端のカメラは、障害物の観察と位置・向きの計測の両方に使います。 このロボット側の仕組みは、ロボットチーム 4 名、およそ 2 か月の集中開発で作りました。以降の章では、この体制で本番 2 日間を走り切るために、どのようにエッジとクラウドの役割分担を決め、何を検証したかを工程順に紹介します。 図 2: 開発フィールドの全体像。2 台のロボットを背中合わせに配置し、中央の ChArUco ボード（チェスボードとマーカーを組み合わせた校正ボード）を共通の原点にした 設計 — 何をどこに任せるか 判断と動作の分離 クラウドの AI エージェントは、「アームを動かしてカメラの視点を変え、状況をさらに調べる」「アームで障害物を持ち上げて取り除く」「人に支援を求める」という選択肢から、次の行動を一つずつ選びます。観察も除去も実体はアームの動作であり、AI エージェントの選択がそのまま実機の動きになります。 ただし、任せるのは判断だけです。画像と言語による指示を入力として、動作指令までを一つのモデルで生成する VLA（Vision-Language-Action）モデルは採用せず、クラウドとエッジで役割を分けました。クラウド側では、Claude Haiku 4.5 がアーム先端のカメラ画像から障害物が何かを認識し、その結果を踏まえて Claude Sonnet 4.6 が次の手順を決めます。決めるのは「どの動作を、地図上のどこに対して行うか」までです。指令は、あらかじめ実装した動作（通路の探索、障害物の把持と搬送など）の指定と、フィールド共通の地図座標の組で届きます。受け取ったエッジ側は、その地図座標を自分のロボット座標系に読み替えます。そこへ至る軌道は、MoveIt 2 がその都度計画して実行します。 アームの姿勢や移動経路を AI エージェントに生成させることはありません。AI エージェントが指す障害物の位置も地図上の大まかな指定にとどめ、把持に使う正確な位置と向きは、エッジ側で、障害物に付けたマーカーをアーム先端のカメラで捉え、その見え方から OpenCV で計算した値で確定させます。クラウドが状況を見て意図を決め、エッジが意図を安全な動作に翻訳します。 この分け方で足りるかどうかは、扱う対象の性質で決まります。VLA が向くとされるのは、布を畳むように対象の形が変わり続け、見た目に応じて動きを作り続ける必要がある操作です。一方、今回のデモで扱う把持対象の障害物は形の変わらない剛体としました。把持の直前に位置と向きを計測してしまえば、あとの動きは事前に定義した把持動作と動作計画で組み立てられるため、AI エージェントの出力をロボットの動作指令に直結させる必要はありません。汎用モデルの判断と既存のロボット制御を組み合わせることで、追加学習なしに、柔軟な判断と実績ある制御の確実な動きを両立しました。 図 3: Claude Haiku 4.5 が画像から障害物を認識し、Claude Sonnet 4.6 が次の手順を判断する。クラウドの指令は AWS IoT Core を介してエッジ側の 2 台のロボットへ届く インターフェース仕様の先行合意 — 座標系・単位・通信 クラウドとロボットのインターフェース仕様で、機能一覧より先に固定したのは座標系と単位です。原点の位置、各軸の向き、右手系か左手系か、位置の単位（mm の整数）、角度の表現（度ではなくラジアン）。とくに座標軸の向きの取り決めが食い違うと、同じ数値が鏡写しの別の位置を指します。こうした座標系や単位の誤りは、数値としては正常なまま、ロボットが誤った場所へ動く形で現れるため、JSON の形式検証では見つかりません。 2 台のロボットの座標系は、フィールド中央に固定した校正ボード（図 2）を共通の原点として突き合わせています。障害物の位置計測に使うマーカーとは別物です。マーカーで測った位置を自分のロボットの座標へ正しく変換できるかは、この校正の精度で決まります。本番前に校正をやり直した際の実測は、校正点への当てはまり（RMSE）で 1〜4 mm でした。校正のずれは実行時のエラーとしては現れず、静かに精度だけを損ないます。 そこで、合意した値が現物と一致しているかを起動時に検証します。たとえば位置計測に使うマーカーは、印刷倍率が少しずれていても検出自体は成功してしまい、座標だけが誤った値になります。マーカー寸法の実測値と設定値を照合して、一致しなければ先へは進まず、担当者が設定を直して測り直すか、中止するかを選びます。人の注意力に頼らず、機械が先に気づく形にしておくのが要点です。 座標系と単位に加えて、通信も用途で分けました。 用途 手段 指令 AWS IoT Core の MQTT 5 Request/Response 配送車両の状態 AWS IoT Device Shadow （デバイスの最新状態をクラウドに写しとして保持する機能） 画像・深度 Amazon Simple Storage Service (Amazon S3) （大きなデータは指令の経路に載せない） 指令の配信方式では同じメッセージが重複して届き得るため、識別子を記録して重複実行を防いでいます。認証には AWS IoT Core の証明書ベースの仕組みを使い、長期のアクセスキーをデバイスに埋め込まずに一時的な認証情報を取得する構成にしています。 自前実装の最小化 ロボット制御スタックは、 FANUC 公式の ROS 2 ドライバー を土台に、エンドエフェクター（開閉式グリッパー）、仮想壁、クラウド連携などデモ固有の機能だけをパッケージとして追加しました。ドライバーは、Stream Motion という通信機能を使って動作データをやり取りします。これは FANUC のロボットコントローラー向けに提供される固有のインターフェースで、外部 PC から短い周期で動作指令を送り続けることで、コントローラーの外からリアルタイムに近い制御を可能にするものです。MoveIt 2 が計画した軌道は、この周期通信に載って実機で実行されます。ドライバー本体のコードは 1 行も変えず、設定の変更だけで 2 台を運用しました。動作計画・衝突判定は MoveIt 2、座標変換は ROS 2 の標準機能です。 図 4: MoveIt 2 による動作計画の様子（ROS 2 標準の可視化ツール RViz の画面）。白が現在姿勢、オレンジが目標姿勢で、黄色の線が自動生成された軌道。仮想壁（フィールド境界）などの制約を考慮した経路を自動で計画する 標準スタックを選んだ効果は、もう一つあります。ROS 2 も MoveIt 2 も OpenCV も公式ドライバーも、公開情報が豊富な OSS です。コーディングエージェントが学習し、参照できる情報が最も多い土俵であり、次章で紹介するコーディングエージェント活用の効果は、この選択に支えられています。 実装 — コーディングエージェントに任せる範囲の線引き ロボット側の開発でも、設計文書、実装、テスト、運用手順の多くをコーディングエージェントとともに作りました。実装リポジトリだけを数えても、約 7 週間で 400 を超えるコミットを重ねています。新規実装（feat）と修正（fix）が同数規模で回った週もあります。会場での現地調整も含めた追い込みの 3 日間には、100 件を超えるコミットが入りました。この開発スピードを維持しながら、実機の安全をどう確保するか。それが本章の主題です。Part 1 で紹介したクラウドアプリケーションの開発と違うのは、誤った変更が物理的な事故につながり得ることと、検証の最終段に「実機で動かす」という共有リソースの制約があることです。そこで、コーディングエージェントを速く走らせる工夫より先に、守るべき前提を毎回読み込ませる形で渡すことに時間を使いました。 開発ルールの文書化 多くのコーディングエージェントには、リポジトリに置いた文書を作業の最初に読み込む仕組みがあります。この文書に、コーディング規約だけでなく次を明文化しました。 一次情報の参照ルール: ロボット固有の挙動に関わる変更は、公式ドキュメントと公式ドライバーの実装を確認してから行う 禁則: 過去の事故につながった変更は、経緯とともに禁止事項として残す 完了条件: コード上のテストが通っただけでは不十分とする。実機をつながず、シミュレーター上のロボットモデルに軌道を実行させ、関節が動くことを RViz（ROS 2 標準の可視化ツール・図 4）の画面で確認する。スクリーンショットやログを検証エビデンスとしてリポジトリの所定の場所に残すところまでを条件とする この確認を回すために、シミュレーション用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを検証環境として用意しました。環境の構築には、開発者ごとのリモート開発環境を AWS 上に用意するサンプルソリューション Remote AWS Development Station (RADS) を使っています。ROS 2 や MoveIt 2、コーディングエージェントまでセットアップ済みの GPU 環境をチームの各メンバーがすぐに使えるため、検証環境の整備に時間を取られません。この手順を開発ルールの文書に書いておくことで、コーディングエージェントは自分が書いた変更をこの環境で自律的に検証します。問題がなければリポジトリに push します。エッジ PC への接続とデプロイも AWS Systems Manager のセッション経由で同じ環境から行い、実機での実行だけは人の承認を得たうえで行います。実機に触れられる時間が限られていても、コードを書く速度と検証の速度を釣り合わせられます。 この文書はコーディングエージェントへの指示であると同時に、4 名のチームの合意の置き場でもあります。人もコーディングエージェントも同じ文書を参照するため、誰の作業でも判断が揃います。あわせて、影響の大きい設計判断は ADR（Architecture Decision Record、設計判断の記録）として残しました。クラウドと ROS 2 の間の通信で「一度目は動くのに二度目から応答しなくなる」問題にはまった際も、原因と結論を ADR に残したことで、以後の変更で同じ議論を繰り返さずに済んでいます。 影響範囲の大きい変更では、いきなりコードを書き始めず、まず仕様と設計上の懸念をコーディングエージェントに徹底的に洗い出させ、設計を固めてから実装に進むのも有効でした。2 台のロボットの座標系を統一する変更では、この段階で、誤った座標でも後述の安全制約を通過してしまう設計バグを実機に触れる前の机上で検出できています。 安全制約の先行実装 アームの進入を禁じる仮想壁、手先の向きを保つ姿勢拘束、関節角のリミットといった安全制約は、コーディングエージェントに考えさせる対象ではなく、人が最初に設計して実装しました。その上で、コーディングエージェントの作業範囲を 3 つに分けています。 変更できる: ROS 2 ノードの実装、説明ドキュメント 人の承認が要る: 座標系、校正値、プランナー設定、テストの変更、仮想壁や姿勢拘束など先行実装した安全制約の変更・無効化、開発ルール文書の禁則と完了条件の変更、実機での実行 コーディングエージェントの外で強制される: ロボットに標準搭載の接触停止機能、非常停止ボタンなどの物理 E-stop コーディングエージェントが必ず安全な変更をするとは限りません。先に制約を実装し、変更できる範囲と実行できる範囲を分けたため、その内側では思い切って任せられます。試行錯誤の速度と実機の安全は、この権限の分離で両立しました。 シミュレーションでの検証の必須化 実機を占有できる時間は限られます。個々の機能はコード上のテストで、動作計画はシミュレーター上での実行と RViz での目視で確認し、実機の時間は、グリッパーの把持力の加減や画像認識の精度といった、実物でしか確かめられない項目に充てました。 あわせて、軌道計算まわりの変更には、シミュレーター上での確認を検証ゲートとして毎回適用するのをチームのルールにしました。実機に触れる前に、シミュレーター上での実行が門番になる形です。 ただし、シミュレーター上の合格をそのまま信用はできません。シミュレーター上のロボットモデルは受け取った指令にそのまま応答するだけで、実機の条件の一部を省略しているからです。実際、ロボットに取り付けた周辺機器のケーブルやコネクターは、挙動のモデル化が難しく衝突判定に含めていませんでした。計画上は問題のない経路でも、実機ではこのコネクターがロボット自身の機体に当たりかけ、人が気づいて止める場面がありました。対処として、コネクターを覆う少し大きめの円柱を衝突判定のモデルに加え、計画の段階で自己干渉として避けるようにしています。シミュレーターが省略している条件は仕様に明記し、シミュレーター上で確認できる範囲と実機で確認すべき範囲を線引きしました。 安全要件の多層防護 開発中、動作計画が失敗し続けた際に、コーディングエージェントが原因を「手先を下向きに保つ」姿勢拘束だと誤判断し、一度無効化したことがあります。計画は通るようになりましたが、実機では障害物を持ったまま大回りして手先の向きが崩れる経路が選ばれてしまいました。原因は 2 つあり、別の変更で到達判定の許容誤差が厳しくなりすぎていたことと、姿勢を拘束した状態では既定の経路探索が解を見つけにくいことでした。許容誤差を直したうえで、探索アルゴリズムの変更や、失敗時に経由点を挿入する工夫によって、拘束を外さずに解決しています。「安全制約の先行実装」で述べた権限区分が、まだ固まっていなかった頃の出来事です。 トラブル対応では、コーディングエージェントも人も、早く解決するために制約を緩めがちです。だからこそ、安全要件は個々のプロンプトや作業指示に委ねず、層で守る形にしました。 動作計画上の制約: 仮想壁、姿勢拘束、関節角のリミット（「安全制約の先行実装」で人が先に実装したもの） ロボット側の保護機能: 接触停止機能、非常停止ボタンなどの物理 E-stop リポジトリの規約: 失敗の切り分け手段として拘束を外すことの禁止と、代わりに試す手順（規約自体の変更には人の承認が要ります） 検証: 実機に送る前の plan-only（実機へ送らず経路だけを計画）確認 この一件を機に、「禁止」と「代替手順」をセットで開発ルールに追記しました。禁止だけを書くと、行き詰まったコーディングエージェントや開発者は制約を回避しやすくなります。代替手順とセットで残すことで、次に同じ症状に出会っても、同じ近道を選ばずに済みます。なお、ここで挙げた拘束や仮想壁は動作計画上の制約であり、安全規格に基づく安全機能ではありません。接触停止や物理 E-stop の代わりにはならず、生産環境への適用では別途リスクアセスメントが必要です。 図 5: 姿勢拘束を維持しながら障害物を把持して退避させる動作 まとめ 今回の実装で重要だったのは、AI エージェントとコーディングエージェントに任せる範囲を広げることではなく、線を引くことと、検証することでした。AI エージェントには判断だけを任せ、動作は既存のロボット制御に。コーディングエージェントにはルールを文書で渡し、先に実装した安全制約の内側だけを任せる。そしてシミュレーター上での検証と起動時検証が、実機と本番を守ります。 同じ構成での検証は、実機がなくても今日から始められます。 ROS 2 と、その上で動く MoveIt 2 をセットアップする（いずれも公開されています。RADS を使うと、ROS 2 / MoveIt 2 / コーディングエージェント入りの環境を AWS 上にすぐ用意できます。実機をつなぐ段階で、ロボットのメーカー公式ドライバーやカメラのドライバーを加えます） コーディングエージェントに開発ルールの文書を渡し、シミュレーター上のロボットモデルで動作計画が解けるところまで作る AWS IoT Core でエッジとクラウドをつなぎ、Amazon Bedrock AgentCore 上の AI エージェントから動作の指令を受け取れるようにする（クラウド側の作りは Part 1 で紹介しています） 想定外への対応など、事前のルールでは書き切れない判断を含む業務（検査で不合格になった製品を、状態に応じて手直し・再検査・廃棄に振り分ける作業など）を一つ選び、判断を AI エージェントに、動作を既存制御に割り当てる クラウドに判断を置く構成は、この先に広がります。ロボットへの指令のインターフェースを揃えれば、判断の仕組みはそのままに、AI エージェントが扱うロボットの種類や台数を増やしていけます。生産管理や倉庫管理といった業務システムと連携した例外対応の仕組みも組めます。そしてコーディングエージェントが使う検証環境も、シミュレーターも、実機へのデプロイも、AWS の上で揃えられます。今回の開発で使った検証環境の仕組みは、 RADS として aws-samples で公開しています。 本記事が、お手元の産業用ロボットと AI エージェントを組み合わせる検討の出発点になれば幸いです。進め方や構成に迷う点があれば、ぜひ AWS にご相談ください。 関連リンク AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで Physical AI – AI エージェントが現実世界で「見て、考えて、動かす」自律オペレーションの実現 Remote AWS Development Station (RADS) 著者について 河田 武之（Takeyuki Kawata） 河田 武之（Takeyuki Kawata）は、製造業のお客様をご支援しているソリューションアーキテクトです。電機メーカーやロボットベンチャーでロボット開発に携わったのち AWS に入社し、現在も Physical AI の領域で、VLA モデルの学習からシミュレーション、実機検証まで自ら手を動かしています。 大前 遼（Ryo Omae） 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習やロボティクスで、最近は Physical AI に注力するあまり、部屋にロボットが溢れています。 西亀 真之（Saneyuki Nishigame） 西亀 真之（Saneyuki Nishigame）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。好きな領域は IoT とロボットで、Physical AI に注力しています。 原田 裕平（Yuhei Harada） 原田 裕平（Yuhei Harada）は、製薬業界のお客様を中心にご支援しているソリューションアーキテクトです。技術領域では Physical AI や AI for Science を軸に、最近は自律開発や自律実験など、AI の自律性をどこまで高められるかの実践に取り組んでいます。

本記事は、AWS Summit Japan 2026 で展示した Physical AI デモの開発の裏側を紹介する技術解説シリーズの Part 1（企画立案、ジオラマステージ制作、クラウド側アプリケーション開発）です。 Part 2 では ROS 2 + MoveIt 2 によるロボットアーム制御を解説します。デモのコンセプトとアーキテクチャは 事前紹介ブログ をご覧ください。 はじめに AWS Summit Japan 2026（2026年6月25日〜26日、幕張メッセ）の展示エリア「 AWS EXPO 」で、私たちは「Physical AI — AI エージェントが現実世界で『見て、考えて、動かす』自律オペレーション」と題したデモを展示しました。ミニチュアの街を舞台に、来場者が自由に配置した障害物を AI エージェントが自律的に発見・除去し、配送を復旧させるデモです。 ▲ 図1: 企画段階で画像生成 AI を使って作成したブースのコンセプトイメージ。ミニチュアの街をロボットアームと配達車両が動き回り、奥の 3 画面に「現実の障害」「AI エージェントの認識世界」「AI の思考」を映す構想。本番ブースはほぼこのイメージ通りに実現した Summit 開催前に公開した 事前紹介ブログ では、デモのコンセプトとシステムアーキテクチャの概要をお伝えしました。本シリーズでは、その開発の裏側——「どうやって作ったのか」に焦点を当てて振り返ります。 テーマは「 AI を活用した開発プロセス 」です。「AI がロボットを動かすデモ」を「AI を使って作る」。デモの中身だけでなく、デモを作る過程そのものでも AI をどう使い倒したかをお伝えします。この記事でわかることは次の 3 つです。 企画・設計・モデリング・実装・ドキュメントの 全フェーズで生成 AI をどう使ったか の具体例 ジオラマステージ制作の舞台裏—— 3 回の方向転換 と 3D プリントの試行錯誤から得た教訓 Kiro を使ったクラウドアプリケーション開発の実践ノウハウ（Design Doc を正とした Issue 駆動開発・Steering・Mob Construction） 開発タイムライン — 実質 1 ヶ月の統合戦 企画は 2026 年 2 月の初回ブレスト会議から始まり、4 月にはシナリオの大枠が決まりました。チームは 10 名、全員がふだんの業務と兼務です。そして 5 月 18 日に 麻布台オフィスへの移転 があり、実際のロボットを使った開発が本格化できたのは、新オフィスにロボット開発拠点を構えてからになります。 Summit 本番（6 月 25 日）まで約 1 ヶ月 です。この 1 ヶ月で、各コンポーネントの統合・連続運転テスト・ステージ制作・搬入準備のすべてをやり切る必要がありました。 ▲ 図2: 開発タイムライン（2026年2月〜6月）。オフィス移転から本番までの約 1 ヶ月が実機統合の期間だった（本図は生成 AI で作成） この短期決戦を可能にしたのが、次章で紹介する「生成 AI をあらゆるフェーズに組み込んだ開発プロセス」と、実機がなくても開発を止めない「Mock ファースト設計」（アプリケーション開発の章で後述）でした。 生成 AI をどこで使ったか — 全フェーズ一覧 本デモの開発では、企画から本番までのあらゆるフェーズで生成 AI を活用しました。全体像を 4 つのフェーズに分けて示します。気になる項目があれば、本文の該当章で詳しく紹介しています。 1. 企画・設計 コンセプトの可視化 — 画像生成 AI でイメージ画像（図1）を作り、言葉より先に世界観を共有 シナリオの壁打ち — 対話型 AI と案を出し合い「配送網の障害復旧」に絞り込み 寸法・制約の整理 — ステージや障害物のサイズ条件を AI と洗い出し、結合時のずれを防止 2. ステージ制作 3D モデリング — 建物や小物のモデルは、AI にスクリプトを書かせる方法で量産（Kiro + Blender） レイアウト設計 — 4 つの通りと建物の配置を AI と対話しながら検討 塗装の参考画像 — 街の色合いのリファレンスも Kiro + Blender で作成し、作業の方向性を統一 3. コーディング・テスト アプリ実装 — クラウド側アプリ一式を Kiro で実装 並行開発 — チーム間のインターフェース仕様を AI と先に固め、実機なしで同時開発 コード読解・テスト生成 — 既存コードの把握やテストケース作成を AI に任せて時短 4. ドキュメント FAQ・説明員資料 — 来場者からの想定質問と回答、デモの説明トークを AI と推敲 設計ドキュメント — 設計書の初稿を AI と共同執筆し、チームレビューで仕上げ ブログ執筆 — 事前紹介ブログや本記事の構成・草案づくりも AI と一緒に AI を使ったデモの企画立案 「配送網の障害復旧」コンセプトに至るまで デモの企画は「Physical AI で何を伝えたいか」の議論から始まりました。チームで議論を重ねて出した体験要件は次の 3 つです。 来場者が参加できる — 見るだけでなく触れる体験 AI の思考が見える — ブラックボックスではなく、判断過程を可視化 毎回違う結果になる — 決められた台本の再生ではなく、AI 自身の判断で動く 技術的な方向性としては、カメラ映像から直接ロボットの動きを生成する VLA（Vision-Language-Action）のような最先端のモデルではなく、 LLM（大規模言語モデル）による計画 + 実績ある従来のロボット制御 の組み合わせに絞り込みました。現時点で産業現場に適用可能な堅実なアプローチを示すことが、来場者にとっての持ち帰り価値になると判断したためです。 AI との壁打ちで磨いたデモシナリオ シナリオづくりの序盤は、AI を「発散」に使いました。製造・物流・建設・農業・小売といった産業別に「AI エージェント + ロボットが活きる障害対応シナリオ」を網羅的に挙げさせ、「ブースの広さで再現できるか」「1 サイクル 3〜4 分に収まるか」「来場者が介入できる余地があるか」の 3 つの物差しで評価していきます。人間だけのブレストでは案が数件で止まりがちですが、AI との壁打ちなら 1 時間で数十パターンの棚卸しができます。 最終的に「ラストワンマイル配送の障害復旧」を選んだ決め手は、次の 3 点です。 説明が要らない — 荷物が届く/届かないは誰でも知っている世界。専門知識ゼロで状況が伝わる 起承転結が短い — 「配送中 → 障害発生 → 調査・復旧 → 配送再開」が 3〜4 分で一周する 来場者が主役になれる — 障害物を「どこに置くか」は来場者の自由。毎回違う展開が生まれる 一方で「収束」はアナログでした。2026 年 4 月 21 日、会議室のホワイトボードの前にチームで集まり、AI と広げた案を物理的な制約に照らして刈り込んでいきました。配送ルートと障害ポイント、アーム 2 台の担当範囲といったデモフローの原型に加えて、「カメラは 2 台必要」「ハンドは 2 本指」というハードウェア構成の決定も、この日のホワイトボードから生まれています。発散は AI、意思決定は全員が同じ盤面を見られる対面で——この役割分担は、以降のフェーズでも繰り返し使いました。 ▲ 図3: 2026年4月21日のシナリオ検討ホワイトボード。FC（配送拠点）から目的地 A / B への配送ルート、障害物の発生ポイント、除去した障害物を運ぶ「ガレキ置場」、アーム A / B の担当範囲など、本番のデモフローの原型がすでに見えている 生成 AI による企画の可視化 企画の初期段階から、画像生成 AI でデモのイメージ画像を作成しました。冒頭の図 1 のような「ミニチュアの街 + ロボット + 配送車両」のビジュアルを言葉での説明より先に見せることで、社内の関係者・協力会社との認識合わせが一気に進みます。「よく分からないが面白そう」から「これならこう手伝える」へ。 絵が先、仕様が後 。これが少人数プロジェクトで多くの協力を引き出せた理由のひとつだと考えています。 ジオラマステージの設計と制作 木工ステージ — 市販合板 8 枚の「加工最小化」設計 まず土台となるステージです。設計の前提には、展示ならではの制約がありました。 オフィスの会議室で組み立てて動作検証し、 分解して幕張メッセへ搬入し、再度組み立てる 必要がある ロボットアームは可搬質量 20kg 級。 アームの荷重や反力をステージに載せるのは危険 制作は本職の大工ではなくチームメンバー。 加工の腕前に頼らない設計 にしたい この制約を AI と対話しながら整理し、たどり着いたのが「市販のサブロク合板（910 × 1,820mm）8 枚を ほぼ無加工で並べる 」という設計です。 方針 実現手段 加工最小化（市販品そのまま） 合板 8 枚のうち、切り抜き加工が必要なのは 4 枚のみ。総加工時間は 約 60 分 組立・分解・再組立できる 骨組みの棒材はすべて 910mm 以下・全ボルト接合。合板はオフィスのドアを通過できるサイズ ロボット荷重は受けない アーム 2 台は専用の台座で床に自立。ステージ側は開口部でアームを避け、構造的に独立 ▲ 表1: ステージ設計の 3 本柱 ▲ 図4: ステージ上面図（設計書より）。合板 8 枚（2 列 × 4 列）で 3,640mm 四方を構成し、ロボットの台座が入る開口部を 2 箇所確保。左右 2 ユニットに分離でき、搬送時はユニット単位で運べる ▲ 図5: 分解図。2×4 材の格子フレームに合板を載せてボルト・金物で固定する。全部材が 910mm 以下なので、エレベーターと会議室のドアを通り、再組立は約 1 時間 天板高さは 765mm。アーム台座の上面（795mm）とジオラマ表面がほぼ同じ高さになるよう、柱底のアジャスターボルトで ±30mm 調整できるようにしています。アームがミニチュアの街から「生えている」ように見えるのはこの高さ合わせのおかげです。精度が必要な箇所（ロボット周辺の高さ、走行路の白線）と、多少ずれても問題ない箇所（外装、建物の配置）を最初に区別しておいたことで、統合時の現物合わせを最小限にできました。 ▲ 図6: オフィスの会議室で組み上げたステージ（2026年5月末）。ロボットアーム 2 台は専用台座（レオンアルミ製）で床に自立し、ステージの開口部から「生えて」いる。荷重と動作反力はステージに一切伝わらない ミニチュアの街 — コンセプトは 3 回変わった ステージの上に載る「街」のほうは、木工のように一直線には進みませんでした。企画から完成までの約 6.5 週間の間に、コンセプトレベルの方向転換を 3 回経験しています。 ▲ 図7: ミニチュアの街 — コンセプトの変遷（2026年5月〜6月）。「配送拠点から住宅街へ届ける」というデモの文脈が一目で伝わる構成が最後の決め手になった（本図は生成 AI で作成） 特に案 2 は、公開されている 3D 都市モデルから建物の形状データを取り出して 1/200 スケールで印刷する工程まで確立していたのですが、実在の建物を商業イベントで展示することの権利面の確認に時間がかかると分かったことに加え、街のすべてを 3D プリントで作ると工数・コスト・時間が見合わないという判断もあり、約 1 週間分の作り込みごと手放しました。案 3 も机上の比較では最有力だったものの、試作と配置検証を重ねるうちに、「配送拠点から住宅街へ荷物を届ける」というデモの文脈が直感的に伝わる 機能別 4 エリア構成 へ自然に置き換わっていきました。紙の上の評価はプロトタイプ 1 回でひっくり返る——方向転換 3 回は迷走ではなく、検証が機能していた証だと捉えています。 3D プリンタによるミニチュア制作 — AI アシストの実際 街のミニチュア（建物・車・木・信号機・道路サイン）は、有志メンバーが家庭用 3D プリンタで分担製作しました。3D モデリングソフト（Blender）はほぼ全員が未経験でしたが、モデルを手で作る代わりに 「モデルを生成するスクリプト」を AI に書かせる 方法で量産しています。「サイズと意図を日本語で伝える → AI がスクリプトを生成 → 実行して形を確認 → 直してほしい点を指示」というループです。 下の図は、実際に本番ステージを構成した 4 エリアの建物モデルです。この記事のために、当時の制作データをそのままレンダリングしました。トラックドックを備えた配送拠点から、のこぎり屋根の工場、住宅と公園、高層ビルが並ぶオフィス街まで、すべて AI が生成したスクリプトから生まれています。 ▲ 図8: 本番ステージを構成した 4 エリアの 3D モデル（AI が生成したスクリプトによる制作データを、本記事用にレンダリング）。左上: FC（配送拠点）、右上: 工場エリア、左下: 住宅街 + 公園、右下: オフィス街 もうひとつ、小物の例として道路名プレートも紹介します。4 つの通りの名前を彫り込んだ三角柱のプレートです。一見シンプルですが、最初のバージョンは文字の彫りが深すぎて裏面まで貫通してしまい、彫りの深さと壁の厚みをスクリプトで管理する方式に改めて作り直しました。 ▲ 図9: 道路名プレートの 3D モデル（AI が生成したスクリプトによる制作データを、本記事用にレンダリング）。シンプルな見た目に反して「文字の彫り込み」は失敗の多い難所だった 「型抜き」で形が壊れる — モデリング最大の難所と乗り越え方 モデリングで最も苦しんだのが、窓やドアの作成です。3D モデルでは、壁のかたまりから窓の形を 「型抜き」 して作ります（Blender では Boolean 演算と呼ばれる処理）。ところがこの型抜きは繊細で、条件が悪いと抜きたい場所以外が消えたり、モデル全体が崩れたりします。数十回の失敗から得た教訓は、次の 3 つに集約できます。 一度に大きく抜かない — 型抜きは回数と範囲を小さく分けるほど壊れにくい 細かい部品は避難させる — 屋上設備などの小さな部品は一度外し、型抜き後に戻す 抜き型は最小限の深さに — 壁を突き抜ける深さで抜くと、反対側の面まで消えてしまう この試行錯誤も AI との二人三脚でした。壊れたモデルのスクリーンショットとスクリプトを AI に渡して原因の見当をつけさせ、対策を反映したスクリプトを再生成する。人間は「どれが正しく印刷できる形か」の判断に集中する。この分業により、モデリング未経験のチームでも約 6 週間で建物・小物あわせて数十パーツを完成させました。 対象 経緯 作り直し FC（配送拠点） 初版 → 改良版 → 最終版とファイル名の世代が進んだ 3 回 道路名プレート 彫りの貫通事故を経て、彫り深さ管理方式で再作成 2 回 工場 スケール拡大 → のこぎり屋根化 → 印刷用の分割 3 段階 ▲ 表2: 主要パーツの作り直しの記録。一発では決まらない前提で、作り直しやすい仕組み（スクリプト生成）にしておいたことが効いた 走行路の設計 — 配達車両が迷わない道 配達車両（TurtleBot3 Burger という小型の自律走行ロボット）は、カメラではなく赤外線センサーで路面の白線をたどって走ります。派手さのない仕組みですが、2 日間確実に動き続けることを最優先にした選択です。道路側の設計要素は次の 3 つです。 白線 — 幅 30mm。黒地マット仕上げの道路面に敷き、センサーが検知する明暗差を最大化 停止線 — 3 つのセンサーが同時に白を検知する横断ラインで、配送先・積荷ポイントを識別 障害物検知 — 前方のセンサーが障害物を検知すると停止し、クラウドの AI エージェントに通知 ▲ 図10: 走行路シートを敷いた状態（会議室での検証時）。白線・停止線・コーナーの曲率は、この面材に印刷して敷くだけで再現できる。ステージ 8 分割に合わせてシートも分割されている 道路幅は 250mm（車体幅 178mm + 左右の余裕 36mm）、コーナーは半径 200mm。この数値も机上で決めた後、実走で「曲がりきれるか」「白線を見失わないか」を検証して確定しています。障害物を検知した車両が停止する——この瞬間こそが、事前紹介ブログで紹介した AI エージェントの自律調査フローが動き出すトリガーです。 アプリケーション開発 — Kiro との二人三脚 システムアーキテクチャ — 3 レイヤー構成のおさらい 事前紹介ブログ で解説したアーキテクチャを、実装の観点から一枚に整理します。設計原則は次の 3 つです。 知性はクラウド — 状況判断・計画立案は LLM の推論力を活かしてクラウドで実行 動作はエッジ — ロボットの動作計算やセンサー処理は、現場に置いた PC（エッジ）で実行 通信断耐性 — クラウドとの通信が切れてもアームは安全停止し、復旧後に再開 ▲ 図11: 3 レイヤー構成 — 知性はクラウド、動作はエッジ。AWS IoT Core がクラウドとエッジを安全につなぐ（本図は生成 AI で作成） Kiro を使ったアプリケーション開発の実際 クラウド側の AI アプリケーション（インフラ、AI エージェント、ダッシュボード画面）は、AI エージェント型 IDE の Kiro を使って実装しました。単に「コードを書かせた」のではなく、開発プロセスの型として活用したのがポイントです。 Design Doc を正とした Issue 駆動開発 — 「仕様が先、コードが後」を AI と徹底する 「仕様を固めてから実装に入る」という進め方は守りつつ、要件・設計・タスクを形式的に分けて管理するのではなく、 チームで共有していた Design Doc を唯一の「正」とする 運用にしました。実装したい機能が出てきたら、Design Doc に沿った実装計画を GitLab の Issue に書き出し、Issue 単位で実装を進めます。Coding Agent には GitLab の CLI ツール経由で GitLab を操作させ、Issue の参照から実装までを一連の流れとして回しました。 効果が大きかったのは 並行開発 です。アームロボットチーム・TurtleBot チーム・フロントエンドチーム・バックエンドチームの 4 チーム間の結合点は、通信メッセージの仕様として Design Doc に固定されているため、実機がなくても各チームが同時に走れます。アプリケーションの内部でも、担当者同士が干渉しないように領域を分けた担当分けを最初に設計し、お互いの作業を邪魔せず並行開発できるようにしました。仕様の議論は Design Doc に、個々の実装計画は Issue に残るので、「なぜこの仕様なのか」を後から追跡でき、キャッチアップも速くなりました。 Steering — プロジェクトの「暗黙知」を明文化してブレを防ぐ Kiro の Steering（プロジェクト固有のルールを Markdown で記述し、AI が常に参照する仕組み）には、次のようなルールを書き込みました。 通信メッセージの型定義ルールと命名規約 インフラ資源（AWS CDK で管理）の命名規約と分割方針 複数人が同じコードベースで AI にコードを書かせると、通常は書き手ごとの流儀が混ざって崩れていきます。Steering に規約を集約したことで、「誰が Kiro に書かせても同じ流儀のコードが出てくる」状態を維持できました。 Mob Construction — 3 日間 109 コミットの裏側 統合フェーズの山場では、チームで同じ部屋に集まり、その場で仕様を決めながら Coding Agent を回し続ける「Mob Construction」と呼ぶ進め方をとりました。ホワイトボードで仕様を合意 → その場で Kiro に実装させる → 実機つなぎ込みで検証 → 次の仕様へ。この高速ループで 3 日間 109 コミット （コードの変更履歴 109 件）を積み上げています。人間がキーボードを打つ時間ではなく、意思決定の速度が開発速度を決める体験でした。 デバッグでも AI が活躍しています。エージェントとロボットがお互いの応答を待ち続けて処理が止まる問題では、Kiro にコード全体を読ませて待ち合わせが衝突しうる箇所を列挙させ、原因を特定。また、エージェントの判断が不安定だった時期には、AI への指示文の中の曖昧な表現（「適切に」「必要に応じて」など）を AI 自身に洗い出させて具体的な条件に書き換え、判断のブレを抑えました。 実機がなくても開発は止めない — Mock ファースト ロボット実機に触れる時間は本番前の約 1 ヶ月だけ。そこで、ロボットと同じインターフェースで応答する疑似デバイス（Mock）を AWS Lambda で実装し、クラウド側はデモシナリオ全体を実機なしで回せるようにしました。あわせてデモ当日の調整パラメータ（タイムアウト、リトライ回数、走行速度など）を AWS Systems Manager Parameter Store に外出しし、プログラムを配布し直さずに現地チューニングできる構成に。本番 2 日間の運用でこの仕込みが効きました。 使用した主なサービス・フレームワーク コンポーネント 技術スタック AI エージェント実行基盤 Amazon Bedrock AgentCore Runtime エージェント SDK Strands Agents SDK （Python） 推論モデル Claude Sonnet 4.6（計画・判断） / Claude Haiku 4.5（画像認識） インフラ AWS CDK （TypeScript）— 60 以上のリソースを一括デプロイ フロントエンド React + Cloudscape Design System + Vite 通信 AWS IoT Core （MQTT 5 + Device Shadow） 音声 Amazon Polly ▲ 表3: クラウドアプリケーションの技術スタック ▲ 図12: 本番デモより。AI エージェントの指示を受けたロボットアームが障害物をつかみ、回収エリアへ移動させて道路を開通させる。このアーム制御の実装は Part 2 で詳しく解説する まとめ 約 5 ヶ月間で「AI エージェントが現実世界で自律的に問題を解決する」デモを作り上げました。振り返って強調したいのは次の 3 点です。 生成 AI は「作る対象」であり「作る道具」だった — 企画の可視化、シナリオの壁打ち、3D モデリング、コーディング、ドキュメントまで、AI を全フェーズに組み込むことで、少人数・兼務・実質統合 1 ヶ月という条件でも本番に間に合わせることができました。 方向転換を恐れない — ミニチュアの街はコンセプトが 3 回変わりました。早く作って早く見る。紙上の評価より実物の説得力です。 プロセスの型が品質を守る — Design Doc と Issue で仕様と結合点を固定し、Steering で規約を明文化し、Mock で実機依存を断つ。AI に書かせる開発だからこそ、人間は「型の設計」に力を注ぐ価値があります。 Part 2（ロボット開発編） では、ROS 2 + MoveIt 2 によるアーム制御、クラウド連携、マーカーを使った精密な位置合わせ、つかむ動作の実装について詳しく解説します。クラウドの「判断」が物理世界の「動作」に変わる瞬間の作り込みを、ぜひご覧ください。 このブログは AWS Japan のソリューションアーキテクト 西田 光彦 、水野 貴博 が執筆しました。 西田 光彦は、エンタープライズのお客様をご支援しているソリューションアーキテクトです。自動車・製造業を専門領域とし、Generative AI/Physical AI など最新テクノロジーを活用してお客様の組織と業務変革のお手伝いしています。 Kiro と 信頼できる同僚達 に支えられながら仕事しています。 水野 貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは Amazon Connect Decisions (旧AWS Supply Chain) です。趣味は、ドラマや映画のエキストラに参加することです。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 8月26日に AWS と NVIDIA が戦略的協業の大幅な拡大を発表 しました。2027 年から 2028 年にかけて NVIDIA GPU を新たに 200 万基 AWS のグローバルインフラに追加配備する計画で、エージェント型 AI ワークロード向けの NVIDIA Vera CPU の AWS への導入も進められます。16 年にわたる両社の協業がフルスタックへと広がっていく動きで、お客様のワークロードに合わせて NVIDIA GPU と AWS Trainium を自由に選べる環境がさらに強化されていきそうです。気になる方はニュースリリースをチェックしてみてください。 それでは 8月 24日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 株式会社 Sapeet がプロダクトの成長に合わせて生成 AI 基盤をコードベースへ ― Dify で築いた資産を活かし、Amazon Bedrock AgentCore と Strands Agents SDK への移行を 2 週間で実現 」 ノーコード AI プラットフォームの Dify で立ち上げた監査業務向けの生成 AI 環境分析ツールを、プロダクトの成長に合わせて Amazon Bedrock AgentCore と Strands Agents SDK によるコードベースのアーキテクチャへ移行した事例です。Dify のブロック繋ぎ型ワークフローと Strands Agents SDK のノードベース実行が構造的に類似する「ノード親和性」により、約 1 年間かけて磨き上げたワークフローの設計思想をそのまま移行資産として活かし、実質 2 週間で基盤移行を完了しました。移行後は Git ベースの差分管理とプルリクエストベースのコードレビューフローが確立され、AWS CDK の L2 Construct によりインフラを含めた一元管理を実現しています。 AWS生成AI国内事例ブログ「 株式会社 JAPANNEXT 様の AWS 生成 AI 事例「Amazon Connect と Amazon Bedrock で営業業務とカスタマーサポート業務を刷新。対応件数を 15% 増加、引き継ぎ工数ゼロを実現」のご紹介 」 液晶ディスプレイメーカーの JAPANNEXT 様が、クラウド型コンタクトセンターサービスの Amazon Connect Customer と Amazon Bedrock を活用し、営業とカスタマーサポートの電話対応業務を刷新した事例です。通話の文字起こしと Amazon Bedrock によるカスタマイズされた要約を組み合わせ、AWS Lambda で担当者が日常的に使うチャットツールへ終話後数分で連携する仕組みを構築しました。先行して運用を開始した営業部門では、1 日の電話対応件数が 15% 増加し、自動ルーティング機能により担当者への電話引き継ぎに要していた時間がゼロになったほか、担当者の残業時間も 15% 削減されています。 イベントレポート「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 札幌編（#7/8）開催レポート 」 2026 年 4 月から 5 月にかけて全国 5 拠点・計 8 回で開催された「AWS Local Executive Roadshow」の第 7 回、札幌開催のレポートです。事例セッションでは、クラスメソッド株式会社が開発した、個人の知見・思考パターン・判断基準をインタビューと分析を通じて AI エージェントとして再現するデジタルツインサービス「ghoost」と、北海道文化放送株式会社（UHB）が視聴率分析などで生じていたナレッジの属人化の解決に向けて取り組んだ PoC が紹介されました。クラスメソッドでの早期検証では、生成された ghoost の回答の 92.3% が「本人らしい」と第三者に評価されています。検証前に撤退基準を設け、ROI の見える化と本人らしさの二軸で評価する UHB 様の進め方など、導入判断の実践的な知見が語られています。 イベントレポート「 AI ツールで実現する継続収益ビジネス​ 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 札幌編（#8/8）開催レポート 」 同シリーズ最終回となる第 8 回、札幌での IT 企業向け開催のレポートです。株式会社アドウイック様は、5 名の少人数チームで複数のコーディングエージェントを比較検証して Cursor を採用し、取り組み開始からの 1 年でファイル送受信サービス、名刺管理アプリ、議事録作成アプリという 3 つのサービスをゼロから開発しました。名刺管理アプリでは、従来の OCR サービスから Amazon Bedrock 上の Claude による文字認識に切り替えたことで、縦書きも横書きも問題なく読み取れるほど精度が向上しています。「低い点数でもいいのでまず試してみる」「小さく始める」「メンバーを巻き込む」という 3 つの考え方のもと、小さな成功体験の積み重ねが、AWS 資格の取得数がメンバー全体で 1 年に 20 個近くにのぼるといった組織の変化につながった様子が語られています。 ブログ記事「 Amazon Quick と Snowflake Cortex AI によるマネーロンダリング対策のアラートトリアージの自動化 」 金融サービスで最も労働集約的なワークフローの 1 つであるマネーロンダリング対策（AML）のアラートトリアージを、Amazon Quick Flows と Snowflake Cortex を Amazon Quick の MCP（Model Context Protocol）統合で接続して自動化する手順を解説しています。アナリストがアラート ID を入力すると、フローが Snowflake Cortex Agent を呼び出して取引データやコンプライアンス文書を横断的に調査し、リスクスコアと対応判断の推奨を含む構造化された調査ブリーフを生成します。テスト環境では、アラート調査に要する時間が 30〜90 分から 5 分未満に短縮されました（実際の結果はアラートの複雑さやデータ量によって異なる場合があります）。プロンプトの表現によって出力が変動するチャットエージェントと異なり、誰が実行しても同じ構造化されたステップをたどるため、監査対応可能な一貫した調査ブリーフが得られる点もポイントです。 ブログ記事「 パート2: Amazon AthenaとCUDOSを使用したAmazon Bedrockのコスト配分 」 Amazon Bedrock のきめ細かなコスト配分機能で得られる IAM プリンシパル別のコストデータを、Amazon Athena と CUDOS ダッシュボードで可視化・分析する方法を解説する記事です。IAM プリンシパルデータを含む CUR 2.0（Cost and Usage Report）データエクスポートの設定から、Athena による SQL クエリパターン、CUDOS ダッシュボード バージョン 5.8 の AI/ML タブに追加された Amazon Bedrock セクションまでを段階的に紹介しています。ユーザー別・使用タイプ別のコスト分解や、IAM プリンシパルタグによるチーム・プロジェクト別の集計、100 万トークンあたりのコストのトレンド追跡ができ、「誰がどのモデルを呼び出していて、いくら使っているか」という質問に答えられるようになります。（ パート1はこちら ） ブログ記事「 Amazon Bedrock のきめ細かなコスト配分の導入 」 Amazon Bedrock が、推論コストを API コールを実行した IAM プリンシパル（IAM ユーザー、アプリケーションが引き受けたロール、フェデレーテッド ID）に自動的に紐付けるようになりました。CUR 2.0 のデータエクスポートで IAM プリンシパルデータを有効にすると、line_item_iam_principal 列でユーザーごと・アプリケーションごとの支出を確認でき、オプションのコスト配分タグを使えば AWS Cost Explorer や CUR 2.0 でチーム別・プロジェクト別に集計することもできます。記事では、IAM ユーザーや API キーを使う開発者、IAM ロールを使うアプリケーション、フェデレーテッド認証、LLM ゲートウェイという 4 つのアクセスパターン別にセットアップ方法を解説しています。本機能は追加費用なしで商用リージョンで利用できます。 ブログ記事「 ラップトップを閉じても、エージェントは動き続ける。cloud sessions で開発する 」 Kiro がリリースした cloud sessions（プレビュー）は、AI エージェントをローカルマシンではなくクラウドのサンドボックス上で実行する機能です。エージェントがリポジトリをクローンして作業を進めるため、ラップトップを閉じても処理は継続し、CLI・IDE・ブラウザーのどれからでも同じセッションの進捗確認と再開ができます。記事では、既存の EC アプリに決済 API を追加するタスクを題材に、CLI から --cloud フラグでセッションを起動し、音声入力機能 /voice でプロンプトを伝え、Kiro Web で進捗を確認して IDE で成果物をレビューするまでの一連の流れを紹介しています。Cloud Sessions は米国東部（バージニア北部）の us-east-1 リージョンでのみ利用できます。 ブログ記事「 継続的なプロンプト評価: LLM ジャッジとライブシグナルを使って Kiro エージェントの品質を高める方法 」 Kiro の開発チームが、システムプロンプトの変更を LLM ジャッジと実際の利用データで継続的に評価している仕組みを解説した記事です。診断・設計・テスト・評価の 4 ステージからなるサイクルを回し、社内の会話をタスクの完遂度や主張の正確性など 15 の挙動ディメンションでスコアリングして、プロンプト変更の効果を A/B 実験で検証します。社内の実験レベルの比較では、Kiro IDE で挙動品質の問題が 20% 減少、コードスタイルの不一致が 54% 減少するなどの結果が観測されました。同じプロンプト変更でも効果はモデルに依存するため、モデルアップグレードのたびに再検証が必要になるという知見も共有されています。 ブログ記事「 本番インシデントのトリアージを AI エージェントに任せられるようになるまで 」 Kiro のデータプレーンを運用するチームが、本番チケットキューのトリアージを Kiro CLI 上で動く AI エージェントに任せられるようになるまでの道のりを紹介しています。システムは専用のオーケストレーションフレームワークやファインチューニングしたモデルを使わず、Kiro CLI と markdown のステアリングファイル、MCP（Model Context Protocol）サーバー、スキルで構成されています。ある日曜日の深夜に発報したアラームでは、13 分 35 秒後には根拠のある診断がチケットに投稿されており、オンコールエンジニアの仕事は調査を始めることから、完了した調査をレビューして意思決定することへと変わりました。代表的な 1 か月では約 250 件の調査が無人で、中央値 13.6 分で完了しています。ドキュメントのバグをエージェントがマシンの速度で受け継いでしまうといった失敗談も含めて共有されています。 ブログ記事「 AI コーディングエージェントは本当に良くなっているのか？ 」 Kiro IDE の diagnostics ツール（エージェントがコードを書いたり変更したりした際に静的解析器で出力をチェックする仕組み）の呼び出しデータ約 40.6 万件を、2026 年 1 月から 6 月までの 6 か月間・7 つの Claude モデルにわたって分析した記事です。ファイルあたりのエラー数は両モデルファミリーとも最新版で約 1.2 に収束して低下傾向にある一方、エラーの構成は変化しており、解決できない import が全エラーの約 30〜58% を占めること、テストコードは実装コードより正しく書くのが 3〜4 倍難しいように見えること、言語別では Java のファイルエラー率（26.7%）が Python（4.0%）の 6.7 倍にのぼることなどが明らかになっています。 サービスアップデート OpenAI GPT-5.6 Terra および Luna が AWS GovCloud (US) の Amazon Bedrock で利用可能に OpenAI の GPT-5.6 Terra と Luna が、AWS GovCloud (US-West) および AWS GovCloud (US-East) の Amazon Bedrock で一般提供を開始しました。バランスの取れた性能の Terra と、高速でコスト効率の高い推論の Luna という 2 つの能力ティアをカバーし、Terra は GPT-5.5 レベルの性能を半分のコストで提供します。両モデルとも 100 万トークンのコンテキストウィンドウをサポートするため、コードベース全体や長大なドキュメントを 1 回のリクエストで処理できます。明示的なキャッシュブレークポイントによるプロンプトキャッシュにも対応しており、繰り返し利用されるコンテキストは 90% 割引で課金されます。 SpaceXAI Grok 4.6 が AWS GovCloud (US) の Amazon Bedrock で利用可能に AWS GovCloud (US) の Amazon Bedrock が、コーディング・エージェントタスク・ナレッジワーク向けに構築されたフロンティアモデルである SpaceXAI Grok 4.6 をサポートしました。500K のコンテキストウィンドウと、4 段階（low / medium / high / xhigh）で設定可能な推論エフォートを備えています。 bedrock-runtime エンドポイントで Responses、Chat Completions、Converse の各 API をサポートし、両方の AWS GovCloud (US) リージョンにまたがるクロスリージョン推論により大規模に利用できます。AWS GovCloud (US-East) では bedrock-mantle エンドポイント経由でも利用可能です。 Amazon Bedrock AgentCore Memory がきめ細かなアクセス制御をサポート Amazon Bedrock AgentCore Memory が、きめ細かなアクセス制御（FGAC）をサポートしました。カスタムの認可ロジックを構築することなく、AgentCore Gateway を通じてユーザー単位・テナント単位のメモリ分離を実現できます。OAuth（JWT）認証を構成した AgentCore Gateway を Memory リソースの前段に配置し、Cedar ポリシーをアタッチすることで、認証された呼び出し元のアイデンティティに基づくアクセス制限が可能になり、アクセス制御の実施をアプリケーションコードからインフラレイヤーに移せます。 Amazon Bedrock AgentCore Memory が柔軟な名前空間変数をサポート Amazon Bedrock AgentCore Memory で、柔軟な名前空間変数を定義できるようになりました。組織・テナント・チーム・環境といったアプリケーション固有のディメンションで長期メモリをスコープでき、メモリ戦略（会話から抽出する情報の種類を決める設定）の重複作成や組み込み変数の使い回しが不要になります。メモリリソースにキーを定義し、メモリ戦略の名前空間テンプレートで参照して、実行時に CreateEvent API で値を渡す仕組みで、メモリリソースあたり最大 5 つのキーを定義できます。AgentCore Memory が一般提供されているすべての AWS リージョンで、追加料金なしで利用できます。 Amazon Bedrock AgentCore が新たに 2 つのリージョンに拡大 AI エージェントの構築・接続・最適化のためのプラットフォームである Amazon Bedrock AgentCore が、米国西部（北カリフォルニア）リージョンとアジアパシフィック（ハイデラバード）リージョンで新たに利用可能になりました。エージェントランタイム、アイデンティティとアクセス制御、ポリシー管理、セッション永続化、ツール接続、評価、可観測性といった AgentCore の機能を提供開始時点から利用でき、これらのリージョンの顧客はエンドユーザーにより近い場所で低レイテンシーにエージェントを構築・実行できます。 Amazon SageMaker HyperPod が Ray のサポートを強化 Amazon SageMaker HyperPod が、AI ワークロードをスケールさせる人気のオープンソースフレームワーク Ray のサポートを強化しました。Amazon SageMaker Studio の Web ベースのインターフェイスから Ray クラスターを作成・管理し、JupyterLab や Code Editor、ローカル IDE を実行中のクラスターに接続して対話的に開発できます。可観測性では Grafana ダッシュボードのプロビジョニングと Ray Dashboard へのワンクリックアクセスが提供され、大規模学習ではノード自動復旧・ハングジョブ検知・階層化チェックポイントが長時間の学習を障害から守ります。Ray Serve による推論では、階層化された KV キャッシュが最初のトークンまでの時間を短縮します。Amazon EKS でオーケストレーションされる HyperPod クラスターを対象に、SageMaker HyperPod がサポートされる AWS リージョンで利用できます。 SageMaker MLflow がカスタマーマネージドキーをサポート SageMaker MLflow が、AWS Key Management Service（KMS）のカスタマーマネージドキー（CMK）によるデータの暗号化に対応しました。厳格なセキュリティ・コンプライアンス要件を持つ組織が自らの暗号化キーを管理できるようになり、AWS CloudTrail との統合によりデータアクセスをトレースする監査も可能です。キーは MLflow App と同じ AWS アカウント・リージョンで作成する必要があり、対称 KMS キーのみがサポートされます。MLflow App が利用できるすべての AWS リージョンで一般提供されています。 Muse-Glimmer-30B および Qwen 3.8-27B モデルが Amazon SageMaker JumpStart で利用可能に Meta の Muse-Glimmer-30B と Alibaba の Qwen 3.8-27B が Amazon SageMaker JumpStart で利用可能になりました。Muse-Glimmer-30B は、複数ステップの推論・ツール利用・失敗からの回復を備えた自律的なエージェントタスク向けに設計された 30B パラメータの密モデルで、131K 超のコンテキストウィンドウと選択可能な推論強度（low〜extra-high）を持ち、Apache 2.0 ライセンスで公開されています。Qwen 3.8-27B は、コーディング・複数ステップのエージェントタスク・テキスト/画像/動画にわたるマルチモーダル理解に優れた 27B パラメータのネイティブなビジョン言語モデルで、262K のコンテキストウィンドウ（YaRN スケーリングで約 1M まで拡張可能）を備え、SWE-bench Pro で 61.7 のスコアを記録しています。 Cosmos3-Edge、Cosmos3-Nano、Cosmos3-Super モデルが Amazon SageMaker JumpStart で利用可能に NVIDIA の Cosmos3-Edge、Cosmos3-Nano、Cosmos3-Super が Amazon SageMaker JumpStart で利用可能になりました。3 つのモデルは、フィジカル AI（物理世界を知覚・推論・計画・行動する AI）向けのオープンなオムニモーダル世界モデル「Cosmos 3」ファミリーを構成し、ロボット・自律走行車・ビジョン AI の構築に活用できます。Cosmos3-Edge はエッジハードウェア上でのオンデバイスのロボット制御とリアルタイムの視覚推論向けの 4B パラメータモデル、Cosmos3-Nano は物理法則の理解を踏まえた世界生成と物理推論に優れる 16B パラメータモデル、Cosmos3-Super はファミリー内で最高精度の世界生成・シミュレーションを担う 64B パラメータモデルです。 Kiro CLI : フルスクリーンのスペックタスク実行とスクロールバックの保持 Kiro CLI の本リリースでは、V3 のスペック実行に、リアルタイムの進捗表示とタスクスコープ選択を備えたフルスクリーンのタスク実行ビューが追加されました。 /spec run でスペックを実行すると専用のフルスクリーンビューが開き、実行開始前にタスクの範囲を選択して、進捗をリアルタイムに追跡できます。また、新しい「Preserve scrollback」トグルを有効にすると、画面のオーバーフローやリサイズによる再描画が発生してもターミナルの履歴が保持されます。 Kiro IDE : サードパーティ拡張機能との互換性と、より信頼性の高い MCP サインイン Kiro IDE の本バージョンでは、サードパーティ製の拡張機能を Kiro と併用できるようになりました。あわせて、最新の MCP（Model Context Protocol）プロトコルリビジョンのサポートによりサインインの信頼性が向上したほか、大きなエージェントレスポンスの処理中に発生していた拡張機能ホストのクラッシュが減少し、ネットワークが一時的に切断されてもエージェントのターンが継続されるようになっています。 生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「 AWS ジャパン生成 AI 実用化推進プログラム 」をご用意しています。ぜひご活用ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近燻製づくりにハマってます。

2026 年 8 月 31 日、AWS ジャパンは「フィジカル AI 開発支援プログラム by AWS ジャパン」の最終成果発表会を AWS 麻布台ヒルズオフィスで開催しました。 1 月 27 日に発表 し、 51 社 ( うち半数以上がスタートアップ ) を採択、 3 月 3 日のキックオフ から約 6 ヶ月支援してきました。 6 ヶ月をふりかえって プログラムでは、フィジカル AI 領域スペシャリストによる技術支援、コスト最適化支援、ロボティクス・生成 AI コミュニティ形成、Go-To-Market 支援の 4 つの柱で参画企業への支援を行いました。アマゾングループが世界 300 以上の施設で約 100 万台のロボットを運用してきた経験も、この 4 つの柱の設計に反映しています。 技術支援の中心は、アカウント担当とスペシャリスト Solutions Architect (SA) チームによる個別の伴走です。週次の定例を設けたり、開発の現場まで伺った企業もありました。あわせて Prototyping & AI Customer Engineering (PACE) チームによるプロトタイピング支援やサンプルコード Physical AI Scaffolding Kit (PASK) の公開、 生成 AI イノベーションセンター (GenAIIC) による支援も進めています。 コスト最適化の面では、開発の初期段階での試行錯誤がしやすいよう総額 600 万 US ドル規模の AWS クレジットをご用意しました。 コミュニティ形成では、 Physical AI on AWS のアーキテクチャ や NVIDIA Robotics Solutions 、グローバルトレンドとロボットに関する勉強会と、 コミュニティミートアップ を開催しました。 Go-to-market の面では、AWS Summit Japan 2026 でのデモ展示など、採択企業の露出と連携の機会づくりを行いました。参加企業からは、AWS 経由で紹介した顧客との商談につながったという声もいただいています。 以下では、8 月 31 日最終成果発表会について、第一部 (記者向け成果発表会)・第二部 (参加企業向け成果発表会) にわけて紹介します。 記者向け成果発表会 冒頭、AWS ジャパン 代表執行役員社長の白幡 晶彦が登壇し、プログラムを総括しました。 AWS ジャパンは、日本への投資を「技術」「信頼性」「人と社会」の 3 本柱で進めており、本プログラムはその 1 つ目である技術への投資の中核にあたります。今年 1 月には「日本のために、社会のために、その先へ」という目標を掲げました。日本はロボティクスで世界をリードしてきており、ハードウェア設計、精密制御、製造技術には数十年の蓄積があります。この強みに生成 AI を掛け合わせることが日本にとって最大の機会であり、世界に対する最大の競争力になる。この領域は日本政府も重要施策のひとつとして位置づけており、AWS はクラウドでフィジカル AI の実用化を支えていると話しました。 そのうえで、フィジカル AI による日本の社会課題解決に不可欠な要素を 3 つ挙げました。1 つ目はスピードです。採択した 51 社のうち半数以上がスタートアップで、完璧な計画を立ててから動くのではなく、仮説を立てて試し、学んで改善するサイクルを高速に回す機動力が社会実装を牽引しています。ハードウェアの開発から手がける企業も複数ありました。2 つ目は現場の力です。テクノロジーだけでは現場で役に立つロボットは生まれません。物流や建設、製造の現場で数十年にわたり蓄積されてきた知見とデータ、そしてスケールが、スタートアップの機動力と組み合わさることで一気に前へ進みます。3 つ目はクラウドです。基盤モデルの学習、大量のデータの収集と前処理、何百通りものシミュレーションを並列で走らせることをオンプレミスだけで行うのは、時間もコストも現実的ではありません。必要なときに必要な規模の計算資源を確保できることは、フィジカル AI の開発において選択肢のひとつではなく不可欠である、と述べました。 最後に「日本発のフィジカル AI イノベーションが、ここから生まれることを期待しています」と締めました。 各社の取り組み 13 プロジェクト・14 社が成果を発表しました。以下社名 敬称略、五十音順。文中の専門用語と固有名は末尾の注釈にまとめています。 株式会社アトム — 日本発のヒューマノイドメーカーを目指すスタートアップです。歩行と全身の制御をシミュレーター※1 の上で学習させ、実機で通常歩行と早歩きを確認しました。あわせて、人が遠隔操作した動きを記録し、そのデータから研究開発用途の自社モデル※2 を学習させて、荷物の仕分け作業などで一定の精度に到達。人の視点で撮影した映像のみを用いる学習は難航しましたが、遠隔操作のデータに加えることで学習が進むことを確認し、現在その精度を検証しています。8 月 28 日には物流作業を対象に 24 時間の連続稼働デモを実施しました。AWS は計算リソースの計画と提供、フィジカル AI チームとの技術ディスカッションで支援しています。今後は 200 台規模のロボットと 30 万時間のデータ、数十億パラメーターの基盤モデルという規模で、台数・データ量・モデルの規模を増やせば性能が向上するのかを検証する計画です。同社はこれを、日本で初めてのロボット基盤モデルのスケーリング則の証明と位置づけています。 オムロン サイニックエックス株式会社 — オムロングループで先端技術の研究開発を担う会社です。今回は、フィジカル AI の土台にあたる研究の成果を発表しました。現在のフィジカル AI 開発では、AI の能力評価、動作データの準備、大規模モデルの構築に多くの人手と計算資源が必要です。そのハードルを下げるため、「理解・行動・振り返り」に対応する 3 つの成果を示しました。1 つ目は、AI がどの程度まで動画を正しく理解できるかを測る評価用ベンチマークの開発です。規模の大きいモデルでも時間の前後関係を取り違えやすく、しかも自身が生成した誤りには気づけないことが明らかになっています。2 つ目は、規模の小さいモデルでも言葉を理解する能力を活かしてロボットを動作させる手法。3 つ目は、動作中の失敗をその場で検出して理由を出力し、その失敗を活かして精度を自己改善する仕組みです。この 3 つは「状況を理解する」「行動を生成する」「振り返る」という一連のループの各工程に対応しており、ループとしてつなぐことで動作の精度が自ら上がり、モデルの軽量化によって速く安く回せるようになる、という構想が示されました。AWS からは高性能な GPU リソースの提供と、AWS 環境を利用するための補助 (コンソールの操作ガイド、GPU をまとまった期間確実に予約できる Amazon EC2 Capacity Blocks for ML の活用提案) を受けており、約 3 ヶ月の利用を通じて特許・論文を 3 件投稿しました。インスタンスの確保からセットアップまでを通した支援やガイダンスの充実があれば研究開発をさらに加速できる、という要望もあわせて示されました。 株式会社ZEALS — ヒューマノイド本体から専用のソフトウェア基盤、動作用のモデルまでを自社で開発するスタートアップです。3 月の採択時点ではソフトウェアに特化し、他社製の機体を活用していました。現場のデータを取得するには現場に入れる身体が必要ですが、日本の狭い廊下を通れ、人と同じ空間で安全に動き、現場が導入できる価格の機体は、当時中国にもアメリカにも見つからず、自社開発に踏み切りました。8 月にローンチした準国産コンパクトヒューマノイド「D1」は、全高 129.3〜159.3cm、走行ベース幅 48cm で、2 本の腕を備えます。機体に加え、会話や自律移動を支える「Omakase OS」、物の操作を担う AI と学習・改善を支えるモデル・データ基盤「Omakase Zen」を揃え、現場データの収集から学習・評価、現場への再投入までを回す土台が整いました。AWS はモデル開発に使うデータ処理基盤の構築、学習の分散処理への対応、データ変換の高速化を支援しており、データ変換は 10 倍に高速化しています。発表会の直前には病院で 3 日間の実証を行い、自律移動、受付前での案内、配茶機の操作、ドアの開閉を D1 が実行しました。2026 年度は販売台数ではなく現場での稼働時間を指標に置き、100 台の量産と 10,000 時間の稼働を掲げました。 株式会社ダイフク・株式会社JDSC — 物流現場の完全無人化に向けて、マテリアルハンドリングのリーディングカンパニーと、AX・データ活用を手がける企業が共同で取り組みました。物流では入荷から出荷まで各工程に人の判断と手作業が残っており、加えて事前に登録したものしか扱えず、品目が変わるたびに設定を作り直す必要があることが、完全無人化の障壁の一つになっています。今回取り組んだのは、ロボットの基本動作と安全条件をあらかじめ用意しておき、作業手順は事前に定義しない方式です。「棚 A の 3 段目に品を 2 個補充して」という作業者の言葉を AI がその場で作業単位に分解し、各段階で成否を判定して失敗した部分のみを再実行します。学習は Amazon SageMaker AI、検証済みアセットの展開は CI/CD で自動化し、シミュレーションでの検証サイクルを高速に回す構成を AWS 上に構築しました。検証では、指示に沿って仕分け先を判断するタスクを対象に、シミュレーション環境において、学習していない商品と仕分け先の組み合わせでも 100 回中 97 回、適切な仕分けまで成功しました。物流における完全無人化の実現に向け、今後は実機での検証を含むフィジカル AI の研究開発を進めていきます。 株式会社竹中工務店 — 日本建設業連合会の長期ビジョンでは、建設業の技能労働者が 2035 年度に 129 万人不足すると見込まれる一方、建設投資額は拡大が見込まれています。この人手不足を補う手段のひとつとして、建設業に特化したモデル※2 を開発し、塗装作業への適用可能性を検証しました。難所はデータでした。建設現場で使う道具の 3D データが存在しないため、道具の 3D データを自社で用意し、実際の現場を撮影した映像から三次元で再現したデータと組み合わせて「壁をローラーで塗装する」作業の学習データを構築しています。遠隔からデータを収集できる環境も整えました。AWS 上に構築したシミュレーション環境のなかに、収集から公開モデル※3 の調整、検証までを一貫して行う仕組みを構築しました。シミュレーション上での塗装動作 (物体操作の部分) の精度は現時点で 10〜15% 程度で、移動をともなう動作は検証中です。残る課題は、学習データが不足していて収集も難しいこと、そして検証と、シミュレーションで学習した動きを実機で通用させること※4 です。今後は建設技能労働者を支援するロボットの実現に向けて、言語モデルを介した人とロボットの会話にも取り組む方針です。 Telexistence 株式会社 — ロボットの基盤モデルを自社で開発するスタートアップです。基盤モデルには、言語モデルを土台にする方式と、動画生成モデルを土台に世界の動き方そのものを学習する方式※5 の 2 系統があり、同社は両方を開発しています。今回は後者を実機に載る形で確かめるため、10 億パラメータの軽量なモデルを自社開発しました。Amazon の研究チーム (Frontier AI & Robotics) の成果も取り込んでいます。AWS 上には、データの蓄積から学習、構成とデータの指紋を記録して再現性を担保するチェックポイント管理、学習を止めずにシミュレーション上で性能を測る評価までをつないだ仕組みを構築。設計の異なるモデルを同時に学習させ、条件を揃えて比較できるようにしたことが検証速度に直結したとのことです。結果として、大量のロボット動作データによる事前の学習を経ていない自社モデルの成功率が 86% となり、事前学習を済ませた公開モデル※6 の 80%、同じモデルを事前学習なしで初期化した場合の 50% に対して、事前学習済みのモデルと同等の水準に到達しました。大量のロボット動作データに依存せずに動作するモデルを構築できれば、開発の初期投資を抑えられます。 株式会社野村総合研究所 — フィジカル AI という言葉が広まる前からロボティクスに取り組んでおり、環境や用途に応じて適切な技術を選定できることを強みに挙げています。2025 年 10 月から 12 月には成田空港にお土産販売のロボット店舗を出店し、完全無人での販売を実施した実績があります。今回は 3 つのアプローチを並行して探索しました。実機を使った学習ではペットボトルのピッキングに成功。実環境を再現したシミュレーションで学習させて実機を動かす手法※7 では、映像の質感が実環境と異なるという課題を改善し、シミュレーション上で学習したモデルで実機を動かせる可能性が見えています。3 つ目は人の一人称視点で作業を記録したデータを用いる方法で、人の作業データからロボットのモデルを構築できることを確認しています。将来的には、現場スタッフの作業データによってロボットを導入できる状態を目指しています。データ収集からチーム内でのデータ共有、モデルの訓練と評価までを AWS 上に構築し、必要な計算資源を短期間で確保できたとのことです。 株式会社Highlanders — 四足歩行ロボットとヒューマノイドを、機体から AI、量産までを一体で開発する 2023 年創業のスタートアップです。危険・過酷な現場の「移動」を四足歩行ロボット「HLQ PRO」で置き換え、その先の「作業」をヒューマノイド「N」で担う二本立ての事業を掲げ、機械設計、電装・制御、通信・クラウド、AI、量産・品質までを同じチームで手がけています。今回は、自社開発のモデル「Kepler」を支える一連の仕組みを AWS 上に構築しました。「Kepler」は、ロボットが周囲を捉えて次に起きることを予測し、行動を決める 100 億パラメータのモデルで、じっくり計画を立てる層と素早く反応する層を組み合わせ、量産で集まるデータをもとに自ら改善していく構成です。AWS 上には、遠隔操作などで生まれる大量のロボット動作データを集約して整える処理、実機での収録だけでは足りない例外的な状況をシミュレーター※1 の並列実行で補って学習用のデータを生成する処理、AWS ParallelCluster による大規模な GPU クラスタでモデルを学習させる処理までをつなぎ、学習を 24 時間 365 日動かし続ける体制を実現しています。構築にあたっては AWS の Solutions Architect とフィジカル AI の専門チームが議論に加わりました。あわせて 2026 年 6 月 25 日・26 日の AWS Summit Japan では、四足歩行ロボット「HLQ PRO」の実機による実演デモを行いました。 FastLabel 株式会社 — AI 開発用のデータを専門に扱う会社です。フィジカル AI でも、学習データを増やせば性能が伸びるという関係が示されつつありますが、ロボットを実際に動かして集めるデータは容易には増やせません。そこで、シミュレーター※1 上で作成した少量の動きのデータを大量に増やし、実データと混ぜて学習データセットを作る仕組みを構築し、その効果を検証しました。遠隔操作により作成した 90 パターンの動きを約 100 倍に拡張し、不正な動作や失敗を除いて 10,000 パターンを取得。シミュレーション上で条件をランダムに変えることで、規模だけでなく多様性も確保しました。実データのみで学習した場合と比べ、データを収集した環境での作業成功率が平均 14.2% 向上し、データを収集した環境とは異なる環境でも、対象物に手を伸ばす動作の達成率が改善して汎化性の向上が確認されています。学習したときの環境から条件が変わると精度が落ちるという、現場導入の障害となる課題に対して改善が見られたことになります。一方で、シミュレーションデータの量が最も多い条件では成功率が下がっており、シミュレーション環境への過適合の可能性が残るとして、現在も分析と検証が進められています。データ構築の費用と性能の関係も定量化され、シミュレーションによってデータ収集のコストを下げられる可能性が示されました。学習は AWS 上の GPU インスタンスで行い、AWS からはシミュレーション技術の知見と計算リソースの提供を受けています。 株式会社豆蔵 — システム工学・ソフトウェア工学・ロボット工学を強みとし、ソフトウェアから AI、機構、電気までを自社で手がける技術者集団です。産業向けに開発してきた「ヒューマノイドロボットでの板金整列アプリ」について、これまで対応できていなかった 2 つのテーマに取り組みました。上半身は、遠隔操作で 359 パターンの動きを収集してモデル※2 に学習させました。ただし映像だけを頼りにした制御では衝突が発生したため、力の強さを測るセンサーを使って柔らかく当てる制御を追加しています。無作為に積まれた部品から 1 枚を取り出す動作はモデルでは成功率が低かったため、取り出しは従来のプログラム、整列はモデルという分担にして、整列の成功率は板金の上下整列で 85%、左右整列で 80% を達成。下半身は、メーカー標準の制御では実現できなかったしゃがみ動作・前傾動作を、シミュレーション上での強化学習によって独自に実現しました。全身の制御も、作業に必要な 10 の関節に絞ることで 43 パターンの動きで実現しています。全身の関節すべてを使って同じことを行う場合には一般に 2,000 パターン以上が必要とされる (NVIDIA Isaac GR00T の FAQ による目安) ので、学習に必要なデータを大幅に減らせたことになります。公開モデル※3 の調整は約 8 時間、下半身の強化学習は約 32 時間で、いずれも AWS 上の GPU インスタンスで回しました。すべてをモデルで解決せず、従来のプログラムと相互に補完するハイブリッド構成が現実的だという結論は、産業での実用を前提に置いた発表でした。 株式会社MW — 住宅そのものを開発し、そこに AI とロボットを組み込む会社です。照明やエアコンの制御は同社のスマートホーム基盤「MW intelligence」によって自動化できていますが、物理的な作業をともなう家事は依然として人の時間を奪っています。ここを自動化するために開発しているのが、住宅に組み込むガントリー型の半人型ロボット「MW bot」です。人のように動きながら、家具のように暮らしに溶け込みます。家事は手順の決まっていない非定型の作業なので、そのためのモデル※2 を自社で開発しています。データ収集の専用拠点を設け、年間 5 万時間規模の家事データの収集を開始しました。最終的には 2.5 PB の学習データを集める予定です。本プログラムではモデルの追加学習までを実施し、日次で集まるデータを Amazon S3 に蓄積し、Amazon SageMaker HyperPod で学習したモデルを実機で検証して次の学習に戻す循環を構築しています。今後は大量の学習データの管理と、大規模なモデル学習の面で AWS との連携を深めていく方針です。 株式会社メルカリ — 越境取引の拡大にともない、海外へ発送する商品をいったん国内の自社倉庫に集めて検品する作業が増え続けています。検品は倉庫の他の工程に比べて約 10〜60 倍の時間を要し、ロボットを投入したときの効果が最も大きい工程です。今回はこの検品・出品作業の自動化に取り組みました。いまのロボットを動かすモデル※2 には、力加減の制御が難しい、カメラの位置が変わると精度が落ちる、学習データを集めるのが困難という 3 つの限界があります。それぞれに対して、力の強さを測るセンサーと触った感触を捉えるセンサーをモデルに統合する、どの位置から撮った映像でも学習したときの視点に投影しなおしてからモデルに入力する、力加減や触感も一緒に記録できる専用の収集機器で人の作業を取り込む、という 3 つの手法でモデルの開発に取り組んでいます。まずは同じカテゴリのなかでばらつきが小さい靴の検品に注力し、箱を開けて靴を取り出し、全面を確認して戻し、箱を閉じて元の位置に戻すまでの 9 工程を対象としました。学習は AWS 上の分散学習で進め、立ち上げをスムーズに行えたとのことです。靴の検品については 2026 年度中の実証実験に向けて製品設計を進めている段階で、2028 年には自社倉庫の約 20% を自動化し、社内コストを年間最大 2 億円削減する計画です。 株式会社リコー — 現場の文書の AI 化から始め、定型業務、非定型業務へと AI の適用範囲を広げ、その 4 段目として現場作業への実装を掲げています。課題として置かれたのは、ロボットの行動データが質・量・多様性のいずれの面でも不足していること、さらにロボットの機種 (アーム型や人型など本体の構成) が変わるたびにデータ収集と学習を繰り返す必要があり、それが規模の拡大と普及の足かせになっている点でした。そこで、公開されているモデルを土台に、機種に依存しない共通の動作表現をいったん学習し、機種ごとに差し替えるのは出力側だけにする方式を検証しています。AWS 上に GPU サーバー 5 台の学習環境を構築し、1 回の試行を約 4 日、モデル改良を週 1 サイクル回せる体制を確立しました。結果として、ひとつの共通表現をもとに 3 種類のロボットをシミュレーション上で動作させられることを確認し、うち 1 機種は実機でも自社部品のピックアンドプレースを実行できることを確認しました。あわせて公開ベンチマークでの評価では、モデルの規模※8 を約 3 分の 1 に抑えても性能が保たれることを示しました。同じ性能を小さなモデルで出せれば、ロボット側に載せる計算資源の選択肢が広がります。本プログラムでの実施範囲は技術の蓄積までで、共通の動作表現を用いたモデルの使いこなしと改良のノウハウを獲得した段階です。今後は自社工場での事例づくりを進めたうえで、お客様との共創に移り、自社とお客様の環境に適したハードウェアへ広げていく方針です。 注釈 ※1 シミュレーター: NVIDIA Isaac Sim / Isaac Lab。ロボットと現場をソフトウェア上に再現し、実機を損傷させずに大量の試行を行える環境です。アトムはこれに MuJoCo を併用しています。 ※2 ロボットを動かすモデル: 正式には Vision-Language-Action (VLA) モデル。カメラの映像と人の言葉を受け取り、ロボットの動きを直接出力するモデルを指します。 ※3 公開モデル (竹中工務店・豆蔵): NVIDIA Isaac GR00T。NVIDIA が公開しているロボット向けの基盤モデルで、各社が自社の作業に合わせて調整のうえ利用します。 ※4 シミュレーションで学習した動きを実機で通用させること: Sim2Real と呼ばれます。シミュレーション上では成功しても、摩擦や照明などの条件の違いにより実機では動作しないことが多く、フィジカル AI 共通の課題です。 ※5 動画生成モデルを土台に世界の動き方そのものを学習する方式: World Action Model と呼ばれる系統で、Diffusion Transformer と呼ばれる構造を用います。言語モデルを土台にする方式と比べ、時間の流れを扱いやすい一方で、推論にかかる計算コストが大きくなります。 ※6 事前学習を済ませた公開モデル (Telexistence): Physical Intelligence の π0.5。大量のロボット動作データで事前に学習された基盤モデルです。 ※7 実環境を再現したシミュレーションで学習させて実機を動かす手法: real2sim2real と呼ばれます。 ※8 モデルの規模: パラメータ数で表します。今回は共通の動作表現を用いない 70 億パラメータのモデル (81.3pt) と、20 億パラメータのモデルに共通の動作表現を加えたもの (81.5pt) を、ロボット操作の公開ベンチマーク LIBERO-10 で比較しています。 総括 13 プロジェクトの発表のあと、AWS ジャパン プリンシパル スタートアップ ソリューションアーキテクトの針原 佳貴がまとめを話しました。 AWS ジャパンの生成 AI 開発支援は、2023 年に日本のスタートアップから「日本語に特化した基盤モデル・大規模言語モデルを自社で開発したい」という声を受け、4 つの柱で LLM 開発支援プログラムを立ち上げ、国内 17 社のモデル開発を支援したことから始まりました。その後、モデル開発だけでなく利活用を支援する生成 AI 実用化推進プログラムやグローバルのアクセラレータでも支援を行い、並行して経済産業省 GENIAC に採択されたお客様の基盤モデル開発を支えるなど、官民で連携した取り組みを続けてきました。 フィジカル AI 開発支援プログラムは、その延長線上にあります。昨年秋ごろからスタートアップの皆様と話すなかで、日本にも画像や動画を扱う基盤モデルの開発実績があり、現場のデータを使えば国産の VLA を作れるのではないか、ただしスタートアップ単独では難しいので AWS からの支援があると嬉しい、という声をいただいたことが出発点でした。お客様のニーズから逆算してプログラムを設計し、1 月に発表、3 月から半年間の開発を進めてきたことになります。プログラム期間中に AWS 社内でもフィジカル AI のワークロードを支援する体制が手厚くなったため、今後は生成 AI 実用化推進プログラムの枠組みのなかでフィジカル AI の支援を続けていきます。 閉会後は、ロボット展示会場へ移動しました。展示したのは 2 機です。 ZEALS の準国産コンパクトヒューマノイド「D1」は、病院・商業施設・物流施設・製造現場などへの導入を前提に設計された機体で、日本の病院の廊下を通れるコンパクトさと、人がぶつかっても安全な柔軟さが特徴です。 Highlanders のヒューマノイド「N」は、人向けの設備や道具をそのまま扱える身体と 5 指ハンドを備え、製造や物流の現場での軽作業を想定しています。いずれも動作に必要なデータ処理とモデル開発に AWS のクラウドをご活用いただいています。 参加企業向け成果発表会 参加企業向けの成果発表会では、冒頭 AWS ジャパンの針原と、経済産業省 商務情報政策局 AI 産業戦略課 課長補佐の秋元氏による挨拶の後、AWS ジャパンの木村がモデレーターを務め、以下の企業の成果が発表されました。以下社名 敬称略、五十音順。 株式会社アイシン／ブレインズテクノロジー株式会社 株式会社ACCESS 株式会社APTO SCSK株式会社 株式会社Enactic 株式会社カミナシ カラクリ株式会社・Upstage Co., Ltd.・株式会社ジェイテクト クラスメソッド株式会社 大日本印刷株式会社 株式会社PKSHA Technology 株式会社MIXI 三菱電機株式会社 Muso Action株式会社 株式会社メルカリ 得られた知見 3 月のキックオフの時点では、現場のデータを使って国産の VLA を作れるのか、作れたとして現場で使えるのかが、まだ見通せていませんでした。第一部の発表を通して見えたことを、白幡が挙げた 3 つの要素に沿って整理します。 まずスピードです。アトム、ZEALS、Highlanders、MW と、自社ハードウェアの開発から取り組んだ企業が複数ありました。ZEALS は 3 月時点では他社製の機体を活用していましたが、8 月に「D1」をローンチし、発表会の直前には病院での実証まで行いました。アトムは発表会の 3 日前に、物流作業で 24 時間の連続稼働デモを実施しています。速く回すには、安く早く測れることが前提になります。オムロン サイニックエックスは動作中の失敗をその場で検出して次の動作に反映するループを設計し、Telexistence は設計の異なるモデルを同時に学習させて条件を揃えて比較できるようにしたうえで、学習を止めずにシミュレーション上で評価を回す仕組みを組みました。FastLabel はデータ構築の費用と性能の関係まで定量化し、リコーは 1 回の試行を約 4 日に収めてモデル改良を週 1 サイクル回せる体制を作りました。何を測れば「できた」と言えるのかを先に決めて評価側を作り込むことが、複数の発表で共通していました。 次に現場の力です。技術だけでは足りないという認識が、具体的な形で出てきました。竹中工務店は、建設現場で使う道具の 3D データが世の中に存在しないという壁にぶつかり、自分たちで用意しています。メルカリは自社倉庫を実証環境として使い、他の工程の約 10〜60 倍の時間がかかる検品を対象に選びました。そして AI だけで解こうとしない判断も共通していました。ロボットの基本動作と安全条件を用意したうえで、手順の組み立てと各段階の成否判定をモデルに任せたダイフク・JDSC、古典的なロボット制御と AI を組み合わせて従来は難しかった柔軟な作業に取り組んだ野村総合研究所、取り出しは従来のプログラム・整列はモデルという分担にした豆蔵。とくに豆蔵は、学習した環境と実際に動かす環境が同じでないと成功率が落ちる、対象物がカメラから見えなくなると動作が破綻する、複数の作業を学習させると成功率が下がるといった限界を挙げたうえで、90 点でも許される作業やリトライできる作業がモデルに向く、という切り分けの基準まで示しました。どこを学習に任せ、どこを作り込み、どうつなぐかが、そのままシステムの構成を決めます。 そしてクラウドです。計算の規模で制約を押し返した例が並びました。Telexistence は複数 GPU での分散学習で軽量モデルを学習させ、FastLabel は 90 パターンの動きを 10,000 パターンに拡張してタスク成功率を平均 14.2% 改善しました。MW は年間 5 万時間規模で集まる家事のデータを日次で蓄積して学習に回す循環を組み、リコーは GPU サーバー 5 台の学習環境で 1 試行を約 4 日に収めています。必要な規模を必要なときだけ確保する使い方も見られ、オムロン サイニックエックスは GPU をまとまった期間確実に予約できる仕組みを使って 3 ヶ月分の計算資源を確保しました。 3 要素の外側では、コミュニティが具体的な成果につながりました。野村総合研究所からは、勉強会での最新情報の共有が助かったという声をいただきました。豆蔵は、類似の取り組みを行う参加企業とのコミュニティが形成されて情報交換ができたこと、相互に得意分野を活かした協業関係の構築が進んでいること、AWS から紹介した顧客との商談につながったことを挙げています。 これから フィジカル AI の開発支援は今回で終了ではありません。お客様からいただいたご要望を踏まえ、 生成 AI 実用化推進プログラム に統合して引き継ぎます。 3 月のキックオフイベントで、私たちは日本発のフィジカル AI イノベーションが生まれる大きな可能性があるとお話ししました。6 ヶ月後の今日、第一部と第二部をあわせて 26 のプロジェクトと、実際に現場で動くロボットを紹介できることとなりました。ものづくりと現場の技術に生成 AI を掛け合わせるという道筋が見えたことが、このプログラムの成果です。AWS は引き続き、日本のお客様とともにこの領域に取り組んでまいります。 関連リンク プログラム発表 / キックオフ Physical AI Scaffolding Kit 生成 AI 実用化推進プログラム 木村 公哉（Kimura, Koya） アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 技術統括部 シニアスタートアップソリューションアーキテクト 2023 年よりディープテックスタートアップを担当。支援プログラムの立ち上げなどに尽力し、2025 年よりフィジカル AI をはじめとしたロボティクス関連領域にも支援を拡大。2026 年 1 月に「フィジカル AI 開発支援プログラム by AWS ジャパン」を発足。VC・政府とのディスカッションを通じ、フィジカル AI・ディープテック領域のエコシステム形成にも取り組んでいる。 針原 佳貴（Haribara, Yoshitaka） アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 技術統括部 プリンシパル スタートアップ ソリューションアーキテクト AWS Japan にて、ユニコーン企業を含む生成 AI スタートアップ企業を中心に 2019 年頃から技術支援を担当。2020 年よりマルチモーダル生成 AI 技術に携わり、生成 AI 大喜利「写真で一言 ボケて電笑戦」を企画・開催、広告賞である ACC ブロンズを受賞。2023 年の「AWS LLM 開発支援プログラム」立ち上げ、2024 年に発表された Amazon Bedrock Marketplace への日本発の基盤モデルのクラウド公開、2026 年発表の「フィジカル AI 開発支援プログラム」などを通じて、日本国内の生成 AI 技術発展に携わる。 生成 AI 分野に加え、日本におけるクラウド量子コンピューティングサービス Amazon Braket の普及や、量子スタートアップ・ハードウェア開発コミュニティとの連携により国産量子コンピュータのクラウド公開にも尽力。2024 年 11 月より、大阪大学 量子情報・量子生命研究センター 招へい准教授。東京大学 大学院 情報理工学系研究科 博士課程修了。博士 (情報理工学)。

はじめに AWS Resilience Day は、ワークロードの回復力向上に役立つアーキテクチャのベストプラクティスや AWS サービスを学べる無料のワークショップです。座学とハンズオンを通じて、高可用性ワークロード、災害復旧の設計、エラー修正プロセスの実装について学んでいただけます。重要なアプリケーションの回復力を IT 運用のライフサイクルの中で継続的に改善したい開発者様、運用者様に特に役立つ内容です。 過去の開催状況は以下の Blog をご参照下さい。 【開催報告】AWS Resilience Day in Tokyo を開催しました！！（2024年10月24日） 【開催報告】AWS Resilience Day in Osaka を開催しました！！（2025年3月17日） レジリエンスについて レジリエンス（Resilience）とは、回復力・抵抗力・弾力性を意味する言葉です。IT 分野におけるレジリエンスとは、IT システムが障害や災害によってサービスの停止・劣化に至った際、迅速に正常な状態へ復旧する能力のことです。昨今、FISC 安全対策基準や金融庁ガイドラインでもレジリエンスに関する指針が示されており、その重要性の認知が広がっています。 レジリエンスにおける課題 しかしながら、レジリエンスの重要性は認識しつつも、いざ自社のシステムに実装するとなると何からどう手を付ければよいのか分からない、という声を多く聞きます。AWS Resilience Day では、Resilience Lifecycle というフレームワークに沿って進めます。Resilience を引き上げるには、目標設定、設計と実装、評価とテスト、運用、対応と学習といったライフサイクルの各項目において、各フェーズで求められる施策を確実に実行することが重要です。本ワークショップでは、そのノウハウを座学とハンズオンで段階的に学び、現場ですぐ活かせる構成としています。 ワークショップのご提供 クレディセゾン様では、クレジットカードをはじめ、ファイナンス・デジタル・グローバルへと多角的に事業を展開される中で、複数のサービス基盤として AWS をご活用いただいています。レジリエンスについても前述の通りの課題感をお持ちでした。また、レジリエンス関連の AWS サービスについても理解を深めたいというご意向があり、本ワークショップ開催の運びとなりました。ワークショップは半日の構成で、クレディセゾン様のオフィスにて個社向けに実施しました。 アジェンダ 本セミナーは レジリエンスライフサイクル からピックアップしたトピックを座学のコンテンツとして共有し、 ハンズオン を交互に織り交ぜて進行しました。 形式 セッション 担当 座学 AWS におけるレジリエンス入門、レジリエンスの目標を設定する 中戸川 浩 ハンズオン RPO / RTOの目標設定、高可用性のための設計と実装、評価とテスト 中戸川 浩 座学 レジリエンスの設計と実装 石倉 徹 ハンズオン ディザスタリカバリに備えた設計と実装 石倉 徹 座学 レジリエンスの評価とテスト Yun Suwon ハンズオン AWS Fault Injection Service を用いたレジリエンス評価とテスト Yun Suwon 【座学】AWS におけるレジリエンス入門、レジリエンスの目標を設定する 最初のセッションでは、事例紹介、レジリエンスの基礎、レジリエンスライフサイクルにおける目標設定について説明いたしました。 事例としては、金融業界においてレジリエンスの重要性を理解し、その実践に取り組まれている企業様の事例を紹介しました。 レジリエンスの基礎としては、メンタルモデルおよびレジリエンスの責任共有モデルについてお伝えしました。AWS の責任範囲については、クラウド基盤のレジリエンスを支えるサービスオーナーシップモデルや CoE プロセスなどの取り組みを紹介しました。お客様の責任範囲については、レジリエンスライフサイクルフレームワークを用いた実践方法をご説明しました。 レジリエンスライフサイクルの説明では、はじめの第一歩となる目標設定についてご説明しました。目標がなく測定もできなければ、何をどこまで改善すべきか判断できません。ここではアプリケーションの重要度に応じてどの程度の回復力が必要かを見極め、RTO / RPO として測定可能な形で定めることを推奨しました。RTO / RPO は長く設定するほどシステム障害時のビジネス影響が大きくなり、短くするほどコストと実装難易度が上がるというトレードオフがあります。そのため、エンジニア部門だけで決めるのではなく、ビジネス部門を含めて利用者目線で適切な水準を選ぶことが重要であるという点を強調しました。 中戸川 浩（Technical Account Manager） 【ハンズオン】AWS Resilience Hub を活用した RPO / RTO の設定 AWS 上で稼働するアプリケーションのレジリエンシーを、具体的にどう高めていくか。ハンズオンでは、アプリケーションの回復力を分析・管理・改善できる AWS Resilience Hub の使い方を学びました。 ※ 本ワークショップで利用している AWS Resilience Hub は旧バージョンとなります。現在の最新バージョンは「次世代の AWS Resilience Hub 」です。 AWS Resilience Hub – 目標 RTO / RPO を入力 まずは AWS Resilience Hub にアプリケーションの目標 RTO / RPO を登録します。 【座学】レジリエンスの設計と実装 次のセッションでは、レジリエンスの設計原則を踏まえ、AWS におけるレジリエンスアーキテクチャのベストプラクティスと実装パターンをお伝えしました。 まず AWS の障害分離境界として、AWS サービスにおけるコントロールプレーンとデータプレーンの動作、静的安定性の重要性について、ベストプラクティスとバッドプラクティスの両面を交えて説明いたしました。続いて、セルベースアーキテクチャ、グレースフルデグラデーション、バイモーダル動作など、回復力を高めるアーキテクチャとソフトウェアデザインパターンを具体例とともに解説しました。あわせて、アーキテクチャの選択には要件とコストのトレードオフが伴うことも、重要な観点としてお伝えしました。 石倉 徹（Sr. Solutions Architect） 【ハンズオン】高可用性とディザスタリカバリのための設計と実装 続くハンズオンでは、AWS Resilience Hub を使ってアプリケーションのレジリエンシーを評価しました。 AWS Resilience Hub – レジリエンシーの評価結果（改善前） アプリケーションが目標 RTO / RPO を満たしているかが可視化されます。この時点では、リージョン障害時の RTO / RPO がいずれも目標値（2 時間 / 1 時間）に届かず、Unrecoverable と判定されました。また、判定理由についても確認が可能です。 AWS Resilience Hub – レジリエンシーの評価結果（改善後） AWS Resilience Hub が提示する改善案に沿ってアプリケーションを修正した結果、目標 RTO / RPO を満たす状態になったことを確認できました。 【座学】レジリエンスの評価とテスト 設計と実装の次は、評価とテストです。このセッションでは、カオスエンジニアリングを用いてシステムの弱点・脆弱性・障害モードを特定する方法を紹介しました。 システムが分散し規模が大きくなるほど、起こりうる障害の予測は難しくなります。カオスエンジニアリングは、想定外の状況でも回復力を発揮するアプリケーションを構築するために欠かせない手法です。本番で問題が顕在化する前に、さまざまな障害シナリオへ意図的にさらして潜在的な弱点を洗い出す進め方と、その意義について理解を深めていただきました。 Yun Suwon（Sr. Technical Account Manager） 【ハンズオン】AWS Fault Injection Service を用いたレジリエンス評価とテスト AWS Resilience Hub は、目標 RTO / RPO を満たすアーキテクチャを提案するだけでなく、障害注入実験用の AWS CloudFormation テンプレートも提供します。ここでは AWS Fault Injection Service が利用されます。 AWS Resilience Hub – 障害注入実験のテンプレート Amazon CloudWatch ダッシュボード – バックエンドの応答状況 推奨テンプレートから必要なものを選び、「RDS インスタンスがフェイルオーバーしても、フロントエンドとバックエンドは2分以上オフラインにならない」という仮説を検証しました。 お客様の声 今回はテクノロジーセンターとエンタープライズ開発センター部門の 26 名の方にご参加いただきました。ご参加いただいたお客様からは、座学で学んだ後にハンズオンへ進む構成だったので分かりやすかった、AWS Resilience Hub や AWS Fault Injection Service に実際に触れて理解が深まった、といった声をいただきました。ご参加くださったみなさま、ありがとうございました。 おわりに AWS Resilience Day は、レジリエンスの実践を体系的に学ぶことができるワークショップです。レジリエンスの取り組みを始めたい、チームの理解を底上げしたいといったご要望がございましたら、ぜひ担当のアカウントチームへお気軽にお声がけください。本記事の内容が、みなさまの業務のお役に立てば幸いです。 著者について 中戸川 浩（Nakatogawa Hiroshi） Technical Account Manager テクニカルアカウントマネージャーとして Enterprise Support にご加入頂いている金融業のお客様を担当しております。コスト最適化、運用効率化、セキュリティ改善など AWS の運用面での課題に対しての支援を行っています。

本記事は 2026 年 8 月 28 日 に公開された「 Razor Group’s journey to a modern data lakehouse on AWS 」を翻訳したものです。 Razor Group は、複数のグローバルマーケットプレイスで 250 以上のブランドを展開する、欧州有数の EC アグリゲーターです。売上高は 4 億ドルを超え、ダイナミックプライシングや在庫最適化から広告費の配分、サプライチェーンの制御に至るまで、あらゆる重要な経営判断をデータで支えています。 事業の中心にあるのが、独自プラットフォームの Razor Operating System (ROS) です。9,300 以上のデータパイプラインを通じて月間 3 億 7,000 万件を超える API 呼び出しを処理し、マーケットプレイスのシグナルを大規模な自動アクションへと変換しています。 本記事では、Razor Group が AWS 上に レイクハウスアーキテクチャ を構築し、データプラットフォームを最適化した方法を紹介します。アーキテクチャ上の意思決定、段階的な移行アプローチ、そして測定可能なビジネス成果を取り上げます。ワークロードのパフォーマンス向上、インフラコストの削減、分析基盤でのマルチエンジン対応、いずれを目指す場合でも、本記事の設計図から自社に合わせて応用できる具体的な知見が得られます。 ビジネス課題: 急成長を支えるデータ基盤のスケーリング Razor Group のブランドポートフォリオが急速に拡大するにつれ、データプラットフォームへの要求も大きく高まりました。価格決定、在庫補充、広告入札がほぼリアルタイムで行われる EC のスピードに、分析基盤を追随させる必要があったのです。 Amazon Redshift のプロビジョンドクラスターで構築した既存アーキテクチャは、初期の成長段階では十分に役割を果たしていました。しかしワークロードが多様化しデータ量が急増すると、いくつかの最適化の余地が見えてきました。 図 1: 移行前の Razor Operating System データアーキテクチャ ワークロードの競合 : ETL、変換、分析用の 1,000 を超える SQL モデルが同じコンピューティングリソースを取り合い、処理のピーク時に競合が発生していました。 コストと使用率のミスマッチ : クラスターは 24 時間 365 日稼働し続けていましたが、ワークロードを分析すると、コンピューティング需要の 98% はインタラクティブな分析ではなくバッチ ETL によるものでした。その結果、オフピーク時に大量のアイドル容量が生じていました。 データ鮮度のギャップ : バッチ中心のパイプラインではデータの反映に 4〜6 時間の遅延があり、動きの速いマーケットプレイスの状況にチームが対応しきれませんでした。 スケーリングの制約 : 同時利用ユーザーとパイプラインの複雑さが増すなか、垂直スケーリングだけでは、ワークロードを分離したい、容量を柔軟に調整したいというニーズには応えられませんでした。 いずれも特定のサービスの欠陥ではありません。Razor Group のワークロードの規模と多様性に合わせて、アーキテクチャを進化させる時期に来ていることを示すものでした。 なぜレイクハウスアーキテクチャなのか Razor Group は既存の投資を置き換えるのではなく、モダンなレイクハウスアーキテクチャを採用して ワークロードの配置を最適化する 機会があると捉えました。意思決定を後押しした基本原則は次のとおりです。 オープンテーブルフォーマット : Apache Iceberg は ACID トランザクション、タイムトラベル、スキーマ進化を備えています。データは一度だけ保存され、互換性のあるどのエンジンからも重複なくアクセスできます。 ワークロード単位の柔軟なスケーリング : データを Amazon Simple Storage Service (Amazon S3) に永続化することで、各エンジンが自身のワークロードに合わせて独立してコンピューティングをスケールできます。各エンジンはピーク処理時に起動し、アイドル時にはゼロまでスケールダウンするため、共有インフラを過剰にプロビジョニングせずに済みます。 マルチエンジンの柔軟性 : ワークロードごとに要件は異なります。負荷の高い ETL は分散 Spark 処理、アドホックな探索はサーバーレスクエリ、ビジネスインテリジェンス (BI) ダッシュボードは高性能なウェアハウスエンジンと、それぞれの目的に最適なエンジンを活用できます。 こうした方針により、Razor Group はプラットフォーム全体からアクセスできる、ガバナンスの効いた単一のデータコピーを維持しつつ、 各ワークロードを最適なエンジンに適正配置 できるようになりました。 ソリューションの概要 Razor Group は AWS と協力し、複数の AWS サービスがそれぞれ補完的な役割を担う包括的なレイクハウスアーキテクチャを構築しました。 図 2: AWS 上のエンドツーエンドのレイクハウスアーキテクチャ スケールを見据えた設計: レイクハウスのビジョン Razor Group の新アーキテクチャを支えた核心はシンプルでした。どのエンジンからもクエリできる、単一のオープンフォーマットデータレイクを構築することです。旧モデルでは、ツールごとに独自のデータコピーを保持していました。新モデルでは、Amazon S3 上の単一のオープンフォーマットデータレイクが信頼できる唯一の情報源となり、目的別に用意した複数のコンピューティングエンジンが、その時々のワークロードに応じてそこからデータを読み取ります。 一般にレイクハウスアーキテクチャと呼ばれるこの転換は、データレイクのコスト効率とスケーラビリティに、データウェアハウスのクエリ性能とガバナンスを組み合わせたものです。レイクハウスのオープンテーブルフォーマットである Apache Iceberg は、ACID トランザクション、スキーマ進化、タイムトラベルを提供し、ベンダーロックインもありません。 ストレージとガバナンス: オープンなデータ基盤 Apache Iceberg を用いた Amazon S3 Tables (Amazon S3 の機能) — 主要なストレージレイヤーであり、ACID トランザクション、パーティション進化、タイムトラベルを備えたオープンフォーマットのテーブルを提供します。データは一度だけ保存され、Iceberg 互換のどのエンジンからもアクセスできます。 AWS Glue Data Catalog — すべてのコンピューティングエンジンで一貫したデータ探索を実現する、統合メタデータリポジトリです。 AWS Lake Formation — 列レベル・行レベルのセキュリティによるきめ細かなアクセス制御を提供し、ガバナンスをプラットフォームの成長に合わせてスケールさせます。 コンピューティング: 適切なワークロードに適切なエンジンを Amazon Elastic Compute Cloud (Amazon EC2) 上の Apache Spark — 負荷の高い ETL や変換ワークロード向けの、柔軟な分散コンピューティングです。コスト最適化のために AWS Graviton インスタンスと Amazon EC2 スポットインスタンスを利用します。 Amazon Athena — アドホックな探索や軽量なクエリを、Iceberg テーブルに対して直接実行できるサーバーレス SQL です。管理すべきインフラはありません。 Amazon Redshift Serverless — BI ダッシュボード、Tableau のワークロード、インタラクティブ分析向けの高性能なサービングレイヤーです。Amazon Redshift Serverless は需要に応じて自動的にスケールし、アイドル時には一時停止するため、最も得意とする分析ワークロードでコスト効率を保ちます。 オーケストレーションとオブザーバビリティ Apache Airflow — 依存関係の追跡とサービスレベルアグリーメント (SLA) の監視により、9,300 を超えるデータパイプラインを管理するパイプラインオーケストレーションです。 包括的なオブザーバビリティスタック — すべてのレイヤーにわたるコスト配賦、パイプラインの正常性監視、データ品質チェックを実現します。 注: このアーキテクチャを当初設計した時点では、Amazon Redshift が Iceberg への書き込みに対応していなかったため、セルフマネージドの Spark が唯一実現可能な取り込み経路でした。この制約はすでに解消されています。 Amazon Redshift は現在、Apache Iceberg の DML (UPDATE、DELETE、MERGE) を完全にサポート しており、従来の CREATE/INSERT 機能や AWS Glue の Iceberg マテリアライズドビューを補完します。これにより、読み書きの両方に対応した完全な Iceberg エンジンとなりました。 移行アプローチ Razor Group は、リスクの高い一括切り替えではなく、5 つのステージからなる段階的な移行を採用しました。各ステージはそれ単体で価値を生みながら、次のステージの土台を築きます。移行期間中は Amazon Redshift と Spark の両パイプラインを並行稼働させ、事業継続性を保ちつつ、チームが出力を確実に比較できるようにしました。本番パイプラインが停止したり、ダッシュボードが利用できなくなったりする瞬間は一度もありませんでした。 移行の道のり: 5 つのフェーズ 移行は体系化された 5 つのフェーズで進み、各フェーズが前段を土台としつつ、次に進む前に段階的な価値を提供しました。 フェーズ 1: レイクハウスの基盤を確立する クエリを 1 つ移行する前に、Razor Group は 3 つの問いに答える必要がありました。データはどこに置くのか、どう管理するのか、そしてどうクエリするのか、という問いです。 セルフマネージドの Iceberg ではなく S3 Tables を選んだ理由 Razor Group はすでに、テーブルフォーマットとして Apache Iceberg の採用を決めていました。オープンでエンジンに依存せず、ACID トランザクションとタイムトラベルを備えているためです。残る問いは、標準の S3 バケット上で Iceberg をセルフマネージドで運用するか、Amazon S3 Tables を使うかでした。 セルフマネージドの Iceberg は強力ですが、運用コストがかさみます。スモールファイルの増殖を防ぐためにコンパクションジョブを回す担当者が必要です。メタデータの肥大化がクエリプランニングを劣化させる前に、古いスナップショットを期限切れにする担当者も必要です。書き込みが中断した後に残る孤立したデータファイルを片付ける担当者も要ります。40 以上のスキーマにまたがる 700 以上のモデルが稼働し、その多くが 1 日に複数回マテリアライズされる環境では、こうした保守負荷はプラットフォームの成長とともに縮小するどころか拡大してしまいます。 S3 Tables は、こうした一連の作業をまるごと不要にしました。コンパクション、スナップショット管理、参照されないファイルの削除が、継続的かつ自動的に実行されます。統合された Iceberg REST Catalog API により、Spark、Trino、Athena、Amazon Redshift、Flink など互換性のあるエンジンは、個別のメタストアを維持することなくテーブルを検出してクエリできます。探索は AWS Glue Data Catalog を通じて統一されており、同カタログは現在、Iceberg REST Catalog プロトコルをアクセスインターフェイスとして公開しています。テーブルがファーストクラスの AWS リソースであるため、アクセス制御、暗号化、ライフサイクルポリシーは、ファイルパスの命名規則の上に複雑な S3 バケットポリシーを重ねるのではなく、テーブルレベルで機能します。 オープンテーブルフォーマットの保守をセルフマネージドで抱え込みたくない企業にとって、これが決め手となりました。 AWS Glue Data Catalog は、すべての階層にわたる統合メタデータ探索を提供します。Lake Formation は列レベル・テーブルレベルのアクセス制御を担い、最小権限の原則に従う AWS Identity and Access Management (IAM) ロールと、完全な監査証跡のために有効化した AWS CloudTrail を組み合わせています。 クエリプロトコルの選択 アーキテクチャの再設計前、Amazon Redshift クラスターの処理は 98% が ETL で、アナリストの SELECT クエリはコンピューティング時間のごく一部にすぎませんでした。置き換えるエンジンには、負荷の高いバッチ変換と、インタラクティブなアドホッククエリの両方に対応できることが求められました。 従来の Spark (spark-submit) はバッチ ETL をうまく処理しますが、クライアントとクラスターが密結合になります。ジョブごとにドライバー JAR のパッケージング、クラスパスの管理、クラスター内部からの投入が必要です。日々膨大なデータ量を処理する 200 以上の本番用有向非巡回グラフ (DAG) を運用するプラットフォームにとって、こうした運用上の摩擦は受け入れがたいものでした。 Spark Connect は、Spark 3.4 で導入された gRPC ベースのクライアント/サーバープロトコルであり、この密結合の問題を完全に解決しました。クラスターは永続的な gRPC エンドポイントを稼働させます。クライアントはリモートで接続し、クエリをネットワーク越しに投入します。Airflow のオペレーターはシンクライアントになります。セッションを開き、SQL を投入して結果を受け取り、成功と失敗がそのままタスクの状態に対応します。ドライバー JAR もポーリングも不要です。パイプラインのオーケストレーター、ウェブアプリケーション、開発者のノートブックなど複数の利用者が、いずれもローカルに Spark をインストールすることなく 1 つのクラスターを共有できます。 Spark Connect のデプロイ Razor Group は、Amazon EC2 上にセルフホストの Spark クラスターをデプロイしました。オンデマンドの AWS Graviton リーダーノード、約 70% のコスト削減となるスポットワーカー、そして内部の Network Load Balancer を通じて公開した Spark Connect エンドポイントで構成されています。カスタムの Amazon マシンイメージ (AMI) に Spark、Iceberg、S3 Tables の一式を組み込んであるため、プライベートサブネットのノードは実行時にインターネットへアクセスしなくても必要なものをすべて備えています。 このフェーズ自体は直ちにビジネス価値を生むものではありませんでしたが、その後のすべてを可能にしました。 フェーズ 2: データ取り込みを移行する Razor Group の取り込みレイヤーは、Amazon Selling Partner API、Seller Central ポータル、NetSuite ERP、そして独自のウェブスクレイパーからデータを取得します。旧アーキテクチャでは、これらすべてが COPY コマンドを通じて Amazon Redshift に取り込まれていました。そのためデータ鮮度はバッチジョブのスケジュールに左右され、分析クエリを処理するのと同じクラスター上でリソースを奪い合っていました。 Razor Group は取り込みパイプラインを、Apache Airflow がオーケストレーションする AWS Lambda 関数へ移行し、データを Iceberg 形式で S3 Tables に直接書き込むようにしました。スケジュール駆動からイベント駆動への転換により、鮮度が大幅に向上しました。Lambda 関数は処理すべきデータがあるときにのみ起動し、Airflow のセンサーは新しいデータが到着した瞬間に下流の変換をトリガーします。その結果、1 時間ごとの固定的なバッチウィンドウは、分単位で測れるデータ鮮度に置き換わりました。 オーケストレーションレイヤーは、90 以上のフローにまたがる 200 以上の DAG を管理し、数十のソースからのデータを大規模に処理します。移行にあたっては、書き込み先を Amazon Redshift の COPY から Iceberg 書き込みへ配線し直す必要がありましたが、オーケストレーションのロジック自体は最小限の変更で引き継げました。 このフェーズだけで、取り込みにおける常時稼働クラスターへの依存を断ち切り、コンピューティングコストを約 40% 削減しました。 フェーズ 3: 処理パイプラインを変換する フェーズ 3 は技術的に最も難易度が高く、Razor Group が最も多くを学んだフェーズでもありました。チームは 1,000 以上の SQL モデルを Amazon Redshift から Apache Spark へ移行し、40 以上のスキーマにまたがる依存関係の連鎖を段階的にたどりながら進めました。モデルはメダリオン構造に沿って移行しました。取り込んだ生データの Bronze、クレンジングして整形したデータの Silver、そしてビジネスで即利用できる集計データの Gold です。 Razor Group は自動変換ツールと検証フレームワークを構築し、Amazon Redshift と Spark の出力を並行して実行して、何かを廃止する前に結果を 1 行ずつ比較しました。いくつかの種類の変換は、自動化で対応できる限界を試すものでした。 ウィンドウ関数 : Amazon Redshift の QUALIFY 句には Spark に相当するものがありません。使用箇所ごとに明示的な行番号付けを伴うサブクエリでラップする必要があり、在庫スキーマだけでも数十のモデルに影響しました。 JSON のシリアライズ : 最も時間を要したカテゴリです。Amazon Redshift で JSON STRING として格納されていた複雑な列は、Spark では手書きの STRUCT 定義を伴う from_json() が必要でした。広告、注文、取引の各パイプラインにわたるネストされたペイロード列はいずれもスキーマの調査を要し、近道はありませんでした。 関数の方言 : NVL から COALESCE、DATEADD からインターバル演算、LISTAGG から ARRAY_JOIN(COLLECT_LIST()) など、20 を超える関数レベルの変換がありました。 スナップショットの排除 : 最大の隠れたコストでした。ある時点の状態を保存するためだけに 1 日に複数回実行されるテーブル全体のコピーは、週あたり 35 時間を超える Amazon Redshift のコンピューティングを消費していました。Iceberg のネイティブなタイムトラベルにより、これらは一夜にしてコストゼロの操作になりました。 1,000 以上の SQL モデルを移行する際、機械的な構文変換は自動化ツールでうまく処理できます。しかしモデルの約 30% は人間の判断を必要としました。複雑な JSON ペイロード、深くネストされたウィンドウ関数、スキーマをまたぐスナップショット依存を含むモデルです。これらのモデルが移行工数の 70% を占めました。 Razor Group は、この作業を加速するために Claude を活用した構造化された移行ワークフローを構築しました。ソース SQL を読み取り、依存関係を特定し、構文を変換し、不足しているベーステーブルを解決し、JSON パースを追加し、出力を検証してレイクハウスに書き込む、という流れです。このシステムは単に SQL を変換するだけではありませんでした。スキーマのコンテキストを適用し、モデル間の依存関係をたどり、エンジニアが手作業で見つけるには何時間もかかるようなエッジケースを検出しました。数年がかりになりかねなかった取り組みが、数週間で測れる体系的かつ再現可能なプロセスになったのです。このアプローチは移行のスピードを根本から変えました。 フェーズ 4: サービングレイヤーを統一する データが Iceberg テーブルを流れるようになったことで、Razor Group はサービングレイヤーを 1 つに集約しました。エンドユーザーは Amazon Redshift Serverless を通じて Gold レイヤーの Iceberg テーブルにクエリを実行し、社内の探索や機械学習 (ML) のワークロードは Spark Connect を通じて同じテーブルを読み取ります。利用者ごとに別々のデータコピー、マテリアライズドビュー、抽出ジョブを維持する必要はなくなりました。 これがオープンテーブルフォーマットの戦略的な成果です。S3 上の Iceberg テーブルはエンジンに依存しません。今日はバッチ変換に Spark、明日はインタラクティブクエリに Trino、来四半期はストリーミングに Flink といった具合です。Iceberg を扱えるエンジンであれば、変換や移行なしにデータを読み取れます。Razor Group は単一ベンダーの SQL 方言に縛られていた状態から、ストレージレイヤーに手を加えることなく新しいエンジンを採用できる自由を手に入れました。 フェーズ 5: 運用体制とオブザーバビリティを整える 最後のフェーズで、レイクハウスを本番グレードに仕上げました。Razor Group は、すべてのパイプラインコンポーネントからメトリクス、トレース、ログを集約し、統一されたビューにまとめる包括的なオブザーバビリティスタックを構築しました。このビューは、一元的なログ検索、異常検知、そしてデータプラットフォーム全体にわたる障害を関連付ける自動アラートを支えます。 このオブザーバビリティレイヤーは、単に可視性を提供する以上のものでした。チームに自信をもたらしたのです。1 日に何千ものパイプライン実行を回しているとき、何かが壊れたら数分以内に、それが何によって引き起こされ、どの下流の利用者が影響を受けるのかを把握する必要があります。それが、後手に回る火消しと、先手を打つ運用との違いです。 パイプラインのオーケストレーションは 3 つのパターンに集約されました。日次パイプライン (取り込みからマテリアライズ、エクスポート、AI エージェントによる分析まで)、15 分ごとにポーリングする運用ワーカー、そして週次のスクレイパージョブです。 切り替えは設計上ゼロダウンタイムでした。2 週間にわたって両方のスケジューラーを並行稼働させ、旧アーキテクチャのシステムを無効化する前に、すべてのパイプラインが同一の出力を生成することを自動比較チェックで検証しました。 成果とビジネスインパクト レイクハウスアーキテクチャは、あらゆる面で測定可能な改善をもたらしました。 指標 移行前 移行後 改善 P95 クエリ実行時間 180 秒 63 秒 65% 高速化 インフラコスト 常時稼働のプロビジョンドクラスター 柔軟でワークロード最適化された構成 63% 削減 データ鮮度 4〜6 時間のバッチサイクル イベント駆動のパイプライン 15 分の鮮度 同時処理容量 クラスターサイズによる制約 柔軟で独立したスケーリング 無制限 エンジンの柔軟性 単一エンジン マルチエンジン (Spark、Athena、Amazon Redshift) オープンフォーマットによる移植性 63% の削減は、レイクハウス稼働後のコスト (2026 年 1〜3 月) と、再設計前のコスト (直前の 3 か月間にあたる 2025 年 10〜12 月) を比較したものです。この数値は、両アーキテクチャのコンピューティングとストレージを含む、同一条件で比較したインフラの総合値です。移行前の列は Amazon Redshift クラスターのコンピューティングとマネージドストレージを対象としています。移行後の列は Amazon EC2 (オンデマンドとスポットの両方の Spark ワーカー)、AWS Lambda、AWS Glue、Amazon Athena、Amazon Redshift Serverless、S3 Tables のストレージを対象としています。データ転送や付随サービスは、2 つの期間で大きな差がなかったため除外しています。ワークロードの構成 (パイプライン数、モデル数、エンドユーザーのクエリ量) は、2 つの期間でおおむね同等に保ちました。 学んだこと ツールではなく意思決定のループから始め、ウェアハウスを置き換える前に自社のワークロードを把握する。 移行全体で最も価値のあった活動は、コードを 1 行書くことではありませんでした。アーキテクチャ上の意思決定を下す前に実施した、Amazon Redshift のワークロード分析です。コンピューティングの 98% が ETL で、アナリストのクエリに回っているのはごくわずかだと判明したことが、オンデマンドの Spark への移行を裏付けました。同時に、ほとんど存在しないインタラクティブワークロードのために置き換え先のインフラを過剰にプロビジョニングすることも防げました。アーキテクチャの意思決定は常に、価格精度、プロモーションへの即応性、日中の損益の可視性といった、事業の根幹にある要件にさかのぼるべきです。テクノロジーではなく、そこから始めましょう。 複数のコンピューティングエンジンを前提に設計し、ワークロードごとに適切なエンジンを選ぶ。 単一エンジンのアーキテクチャを運用して得られた最も明確な教訓は、それによって何を手放すことになるかということです。BI、取り込み、バックフィル、ML のすべてを 1 つのコンピューティングレイヤーに縛りつけるのは避けましょう。それぞれコストとパフォーマンスの特性が根本的に異なるからです。いったん移行してしまえば、Iceberg、Spark、S3 Tables は最初から問題なく連携します。難しいのはテクノロジーではありません。難しいのは、40 以上のスキーマにまたがる 1,000 以上のモデルを対応付け、200 以上の DAG を通じて依存関係をたどり、ある列が実は 2 つのエンジン間で密かに異なる形でシリアライズされた JSON 文字列だったと突き止めることです。移行は、エンジニアリングであると同時に発掘プロジェクトでもあります。 変換は自動化しつつ、残る 30% を見込んでおく。 自動化ツールは機械的な構文変換をうまく処理するので、まず手を伸ばすべきツールです。しかし複雑な JSON ペイロード、深くネストされたウィンドウ関数、スキーマをまたぐスナップショット依存を含むモデルは人間の判断を要し、その作業は圧縮できません。当社のモデルの約 30% が大幅な手作業を必要とし、それらが移行工数全体の 70% を占めました。最初から正直に見込んでおきましょう。 オブザーバビリティにはコスト配賦を含めなければならない。そして思わぬコストの落とし穴に注意する。 スナップショット操作は最大の想定外でした。ある時点の状態を保存するために 1 日に複数回実行されるテーブル全体のコピーが、週 35 時間を超えるコンピューティングを消費していたのですが、「スナップショットとはそういうもの」だと誰も疑いませんでした。Iceberg のタイムトラベル機能がそのコストを解消し、この 1 つの機能だけで移行のかなりの部分が正当化できました。より広く言えば、見えないものは最適化できないので、クエリレベルの使用状況を追跡し、チームや機能に配賦しましょう。コストのオブザーバビリティはあれば嬉しいものではなく、基盤そのものです。 ガバナンスは任意ではない。基盤に組み込み、初日からステークホルダーの足並みをそろえる。 カタログとアクセス制御は、採用を拡大した後ではなく、その前に整える必要があります。同じ原則が人にも当てはまります。移行はインフラプロジェクトではなく、部門横断のプログラムです。当社の 2 週間の並行稼働は、行レベルの検証ではまったく捉えられなかったエッジケースを検出しました。Amazon Redshift と Spark の間のタイムゾーンの違い、同時書き込み時のパーティションプルーニングの挙動、非決定的なウィンドウ関数における微妙な並び順の違いです。並行稼働は単なるセーフティネットではありませんでした。移行の真価が実証された場そのものでした。適切なステークホルダーが最初から関与し、足並みをそろえていなければ、何ひとつ成り立ちません。 まとめ Razor Group の道のりは、データアーキテクチャの最適化を目指す組織に貴重な教訓を提供します。 まずワークロードの構成を分析する。 コンピューティングの 98% がインタラクティブクエリではなく ETL だと理解できたことが、負荷の高い処理を柔軟な Spark にオフロードしつつ、最も得意とするインタラクティブ分析には Amazon Redshift Serverless を残すという判断を導きました。 マルチエンジンの柔軟性を前提に設計する。 Apache Iceberg のようなオープンテーブルフォーマットは、単一エンジンを選ぶ必要をなくします。各ワークロードは、アクセスパターン、コスト特性、パフォーマンス要件に最も適したエンジンで動きます。 移行を自動化しつつ、複雑さを見込む。 自動トランスパイルは SQL モデルの 70% を処理しましたが、残る 30% がエンジニアリング工数の 70% を占めました。それを踏まえて計画しましょう。 オブザーバビリティにはコスト配賦を含める。 ワークロード単位のコストが見えなければ、最適化は当て推量になります。Razor Group は、Iceberg のスナップショット保守だけで週 35 時間を超えるコンピューティングを消費していたことを突き止めました。オブザーバビリティが表面化させ、自動化が解決した隠れたコストです。 ガバナンスを基盤に組み込む。 AWS Lake Formation と AWS Glue Data Catalog は、移行後に後付けするのではなく、初日からきめ細かなアクセス制御を提供しました。 並行システムで検証する。 新旧アーキテクチャの 2 週間の並行稼働は、自動テストが見逃したエッジケースを検出し、自信をもった本番切り替えを支えました。 今後の展望 レイクハウスの基盤が整ったことで、Razor Group は AWS 上の統一されたオープンでガバナンスの効いたデータプラットフォームを原動力に、リアルタイムの価格モデルから AI 主導の在庫最適化まで、イノベーションを加速できる体制になりました。 同社の変革は、モダンなデータアーキテクチャがサービスの二者択一ではないことを示しています。それは 各ワークロードを最もパフォーマンスの高い場所に配置し 、オープンフォーマットでサイロを解消し、ビジネスの成長に応じて各レイヤーを独立してスケールさせることなのです。 他の組織が AWS 上で同様のレイクハウスアーキテクチャをどう実装しているかについては、 How BigBasket uses the Iceberg-based lakehouse architecture on AWS to power lightning-fast grocery delivery across India を参照してください。 著者について Yaswanth Kothainti Yaswanth は、売上高 4 億ドル超の EC 企業 Razor Group で VP of Data Engineering & Platform を務めています。同社のデータプラットフォームをゼロから構築し、65 名からなるグローバルなエンジニアリング組織を率いています。専門はエンタープライズデータプラットフォーム、データガバナンス、FinOps、エージェント型 AI システムで、複雑なプラットフォーム投資を測定可能なビジネス成果へと結びつけてきた実績があります。 Shubham Purwar Shubham は、AWS の Analytics Specialist Solutions Architect です。スケーラブルでセキュア、かつ高性能な分析ソリューションを AWS 上で設計・実装し、組織がデータの潜在能力を最大限に引き出せるよう支援しています。余暇には家族と過ごしたり、世界各地を旅したりするのが好きです。 Ravi Kompella Ravi は Principal Analytics Specialist です。インドの多様な業界において、スタートアップや SaaS プロバイダーを含むあらゆるセグメントを対象に、モダンなデータアーキテクチャ、エンタープライズデータレイクハウス、リアルタイムデータシステムの採用を推進してきた経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 「スキーマ変更は利用の少ない深夜に、フェイルオーバー試験は休日に。」データベースを止めないための調整に、エンジニアの時間が少しずつ削られていく。そんな場面に直面することはありませんか。9/14(月) 14:00 から麻布台ヒルズで開催する 「Amazon Aurora DSQL Day Tokyo」 では、こうした運用調整からエンジニアを解放する分散 SQL データベース Amazon Aurora DSQL について、来日するプロダクトマネージャーと日本のスペシャリスト SA が、技術詳細から適用判断のポイントまでを解説します。IVRy 様、MIXI 様、東京海上日動システムズ様など、実際に本番システムで採用されたお客様の生の知見を聞ける現地開催イベントです。深夜や休日の調整にあてていた時間をサービス開発に使えるようになるための第一歩としてご活用いただけます。参加には事前登録が必要ですので、ぜひ上記のリンクからお申し込みください。 それでは、先週の主なアップデートについて振り返っていきましょう！ 2026年8月24日週の主要なアップデート 8/24(月) Amazon Connect Customer がエージェントの音声およびチャット会話からの情報抽出に対応 Amazon Connect Customer (旧 Amazon Connect) の会話分析に、生成 AI による情報抽出機能が追加されました。音声およびチャットの会話から、口座番号や予約 ID などの発話どおりの値 (verbatim) と、問い合わせ理由や約束したネクストステップなどの推論による値 (derived) を構造化データとして自動取得できます。抽出は機密情報のマスキング前の生データに対して実行されるため、録音や文字起こしから機密情報を秘匿しつつ、業務に必要な値だけを取り出せます。抽出結果は After Contact Work 中のエージェント画面、コンタクト検索、API、Kinesis Data Streams、S3 出力ファイルで利用でき、メール送信、タスク作成、ケース作成などのルールアクションにも直接渡せます。東京リージョンを含む対応リージョンで利用できます。 Amazon EKS がクラスターあたり複数の外部 OIDC ID プロバイダーをサポート Amazon EKS が、1 つのクラスターに複数の外部 OpenID Connect (OIDC) ID プロバイダーを関連付けられるようになりました。Kubernetes 1.32 以降のクラスターでは最大 10 個のプロバイダーを関連付けられます。従業員、契約社員、CI/CD システムなど、認証基盤が分かれているユーザー層をそれぞれのプロバイダーで直接認証できるため、Dex や Keycloak のような中間 ID ブローカーの運用や、単一プロバイダーへのユーザー統合が不要になります。追加料金はなく、Amazon EKS が利用可能なすべての AWS リージョンで利用できます。 Amazon ECS がエージェント接続に障害のあるコンテナインスタンスを自動検出・修復 Amazon ECS が、コンテナインスタンス全体のエージェント接続を継続的にモニタリングし、エージェント接続に障害のあるコンテナインスタンスを自動的に検出、修復するようになりました。これにより、検出されないまま残るワークロード障害を減らし、アプリケーションの可用性を高められます。EBS ボリューム劣化、ホストの熱イベント、ネットワーク障害などで ECS エージェントとコントロールプレーン間の接続が切断されると、新しいヘルスチェックタイプ AGENT_CONNECTIVITY として検出されます。検出後の動作はコンピューティングオプションによって異なり、AWS Fargate と Amazon ECS Managed Instances では、タスクのドレイン、代替キャパシティの起動、障害インスタンスの登録解除までを ECS が自動で行います。一方 ECS on EC2 では自動修復は行われず、EventBridge に配信されるヘルス変更イベントをもとに、ユーザー自身がインスタンス置き換えワークフローを構築します。 8/25(火) AWS Lambda 関数が IAM リソースベースポリシーをフルサポート AWS Lambda 関数が、IAM リソースベースポリシーをフルサポートしました。これにより、プラットフォーム管理者やセキュリティチームは、IAM の機能をフルに活用してきめ細かなアクセス許可を定義できるようになります。従来は AddPermission API でプリンシパルごとに Allow ステートメントを 1 つずつ追加する方式で、使える条件キーも aws:SourceArn、aws:SourceAccount、aws:PrincipalOrgID の 3 種類に限られており、マルチアカウント環境などでの大規模な権限管理には柔軟性が不足していました。今回追加された PutResourcePolicy API では、複数プリンシパル・複数アクションを 1 つのポリシードキュメントにまとめられるほか、IAM 条件キーをフルに活用して送信元 IP やプリンシパルタグに基づくアクセス制限が可能になります。 AWS Batch が Amazon ECS Managed Instances をサポート AWS Batch のコンピューティング環境として Amazon ECS Managed Instances (ECS MI) を選択できるようになり、GPU を使うジョブや計算負荷の高いバッチワークロードを AWS 管理のインフラで実行できるようになりました。これまで GPU を使うジョブや 32 vCPU / 244 GiB を超えるジョブは EC2 コンピューティング環境が必要で、AMI の更新やインスタンスの管理を利用者側で担う必要がありましたが、本アップデートによりこうしたインフラ管理なしで GPU インスタンスを利用できます。料金は EC2 インスタンス料金に加えてインスタンスタイプごとの管理料金が発生します。AWS Batch が利用可能なすべての AWS リージョンでサポートされます。 8/26(水) AWS Backup が Amazon DocumentDB のクロスリージョンバックアップコピーと論理的エアギャップボールトを 9 リージョンで追加サポート AWS Backup が、Amazon DocumentDB バックアップのクロスリージョンコピーと論理的エアギャップボールト (Logically Air-gapped Vault) への保管を、香港、ジャカルタ、メルボルン、大阪、スペイン、ストックホルム、チューリッヒ、ケープタウン、テルアビブの 9 リージョンで追加サポートしました。バックアッププランまたはオンデマンドコピージョブにより、これらのリージョンとの間で DocumentDB バックアップをコピーできます。また、論理的エアギャップボールトはデフォルトでロックされた不変ストレージであり、AWS RAM でボールトを共有して別アカウントから復旧できるほか、アカウント侵害時にはマルチパーティ承認 (Multi-party approval) でボールトへのアクセスを保護できます。日本のユーザーにとっては大阪リージョンが対象に含まれた点が重要で、東京 – 大阪間の国内完結型 DR 構成を DocumentDB でも構築できます。 Mountpoint for Amazon S3 がメモリ使用量の制御機能を追加 Mountpoint for Amazon S3 の v1.24.0 で、メモリ使用量を制御する機能が追加されました。新しい –memory-target オプションでメモリ使用量の目標値を MiB 単位で指定できるほか、指定しない場合は実行環境 (システム全体または cgroup によるコンテナのメモリ上限) を自動検出し、その 95% をデフォルト値として使用します。これまで Mountpoint はプリフェッチなどの動作によりメモリ使用量が使用パターンに応じて増加し、ML トレーニングや分析ワークロードなどメモリを多く使うアプリケーションと同居させると、パフォーマンスや安定性の問題を引き起こすことがありました。今回の機能により、Amazon EKS などメモリ割り当てが厳格なコンテナ環境でも Mountpoint を安定して運用できます。 Amazon Connect Customer がエージェントスケジュールで計画外シュリンケージをサポート Amazon Connect Customer のエージェントスケジューリング機能で、計画外シュリンケージを入力できるようになりました。遅刻ログインや急な病欠など、事前にスケジュールへ組み込めないエージェントの不在率の想定をアップロードすると、スケジュール済みヘッドカウント、ネットスタッフィング、予測サービスレベルなどのメトリクスが即座に再計算されます。WFM 管理者はスケジュール上の人員不足を事前に把握し、対策を打てるようになります。 8/27(木) Amazon Aurora DSQL が外部キー制約をサポート Amazon Aurora DSQL で、新規テーブルおよび既存テーブルに外部キー制約 (FOREIGN KEY) を定義できるようになりました。これまでアプリケーション側で実装する必要があった参照整合性のチェックを、データベース側に任せられます。参照先の行が削除・更新されたときの動作として、NO ACTION、RESTRICT、CASCADE、SET NULL、SET DEFAULT の 5 種類の参照アクションを指定できます。なお、Aurora DSQL はロックではなく楽観的同時実行制御 (OCC) によりコミット時に競合を検証する設計のため、競合時は直列化エラーが返り、アプリケーション側でのリトライ実装が前提になる点は外部キーの利用時も変わりません。 AWS Backup が Amazon FSx for NetApp ONTAP のクロスリージョンおよびクロスアカウントバックアップに対応 AWS Backup で作成した Amazon FSx for NetApp ONTAP のバックアップを、別の AWS リージョンや別の AWS アカウントにコピーできるようになりました。コピーはバックアッププランによるポリシーベースの自動実行と、オンデマンドのコピージョブの両方に対応します。これまで AWS Backup では FSx for ONTAP バックアップのリージョン間・アカウント間コピーは非対応でしたが、今回の対応によりコピーを AWS Backup で一元管理できます。AWS Organizations と組み合わせることで、組織全体でコピーを自動化することも可能です。 Amazon Redshift が Agent Toolkit for AWS と統合、AI 支援によるデータウェアハウス管理に対応 Amazon Redshift が Agent Toolkit for AWS と統合され、Claude Code、Kiro、Cursor などの AI コーディングエージェントから Redshift データウェアハウスおよびデータレイクの構築、クエリ、トラブルシューティング、Redshift への移行を実行できるようになりました。この統合は 2 つの要素で構成されます。ユーザーの認証情報を使って AWS API を実行する AWS MCP Server と、AI エージェントが Redshift のタスクを確実にこなせるよう検証済みの手順や参照情報をパッケージ化した Redshift skills です。導入は、利用中のエージェントに aws-data-analytics プラグインをインストールするだけで、MCP Server の設定と Redshift skills が 1 ステップでまとめてセットアップできます。 8/28(金) Amazon CloudWatch agent が journald ログのサポートを追加 Amazon CloudWatch agent が、systemd journal (journald) のログを直接読み取って Amazon CloudWatch Logs に送信できるようになりました。Amazon Linux 2023 のように systemd journal を主要なログ基盤とし、/var/log/messages などのテキストログをデフォルトでは書き出さないディストリビューションでも、ファイルへのエクスポート設定なしで OS ログを収集できます。systemd ユニット、journal 優先度、journal フィールドマッチ、正規表現の 4 種類のフィルターを送信前に適用できるため、取り込み量とコストを制御できます。すべての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用できます。 Amazon Bedrock AgentCore Memory がきめ細かなアクセス制御をサポート Amazon Bedrock AgentCore Memory が、きめ細かなアクセス制御 (FGAC) に対応し、独自の認可ロジックを実装することなく、ユーザー単位・テナント単位のメモリ分離を強制できるようになりました。具体的には、Memory リソースの前段に OAuth (JWT) 認証を構成した AgentCore Gateway を配置し、Cedar ポリシー (AWS が開発したオープンソースの認可ポリシー言語) を適用することで、分離をインフラ層で強制します。従来はアプリケーションコードが actorId や namespace を正しく設定することに依存していた分離処理を、認証済みトークンのクレームに基づくポリシー評価に置き換えられます。基盤となる AgentCore Memory connector は、12 の Memory 操作を Cedar アクションとして公開します。 Amazon Bedrock AgentCore Memory がフレキシブルな namespace 変数をサポート Amazon Bedrock AgentCore Memory で、長期メモリの namespace テンプレートにカスタム変数を定義できるようになりました。従来は actorId、sessionId、memoryStrategyId の 3 つの組み込み変数しか使えませんでしたが、組織、テナント、チーム、環境といったアプリケーション固有の軸でメモリを分離できます。メモリリソースごとに最大 5 個のキーを定義し、CreateEvent API 実行時に値を渡すと、長期メモリ抽出時に namespace テンプレートへ代入されます。あわせて、IAM 条件キー bedrock-agentcore:namespaceVariable/<キー名> を使うと、書き込みパスでのテナント分離をポリシーで強制できます。AgentCore Memory が利用可能なすべての AWS リージョンで追加料金なしで利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWS サービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

本記事は 2026 年 05 月 12 日に公開された “ Filter, transform, and load your DynamoDB table exports using AWS Glue ” を翻訳したものです。翻訳は Solutions Architect の嶋田 朱里が担当しました。 この記事では、 Amazon DynamoDB のフルまたはインクリメンタルテーブルエクスポートを 2 つ目の DynamoDB テーブルにロード（インポート）する方法を紹介します。何をロードするか、どの書き込みレートでロードするかを正確にコントロールでき、進捗を観察する機能も備えています。この技術は、最大限の制御が必要な大規模なデータマイグレーションや同期を推進するのに役立ちます。ここで説明するメカニズムは、オープンソースの Bulk Executor for DynamoDB のコマンドとして提供されています。これは、DynamoDB テーブルに対してバルクコマンドを実行するためのユーティリティセットです。このコマンドを使用することで、DynamoDB のエクスポート（済みデータ）を細かく制御しながらロードでき、アイテムを変換したり、データをフィルタリングしたり、コマンドのオプションの transform パラメータを使用して宛先テーブルに何を配置するかをカスタマイズしたりできます。 背景 DynamoDB はフルおよびインクリメンタル両方の テーブルエクスポート をサポートしています。両タイプのエクスポートはサービス駆動型で、読み込みキャパシティを消費せず、AWS マネジメントコンソール、コマンドライン、または SDK を通じて開始できます。エクスポートを実行するには、テーブルでポイントインタイムリカバリ (Point in Time Recovery, PITR) を有効にする必要があります。 フルエクスポートには、指定された時点でのテーブル内のすべてのアイテムが含まれます。エクスポートプロセスは、データを一連のオブジェクトとして Amazon Simple Storage Service (Amazon S3) に送信します。 ファイルは DDB-JSON フォーマットまたは Ion フォーマットで、1 行に 1 アイテムずつ記録されます 。インクリメンタルエクスポートのフォーマットは少し異なります。指定された期間中に変更されたアイテムのみが含まれ、各アイテムのプライマリキー、指定された期間内の最終変更時刻、（オプションで）期間開始時のアイテムの変更前イメージ、期間終了時のアイテムの変更後イメージが含まれます。アイテムの変更前と変更後の両方のイメージを確認できるため、エクスポートされた期間中にそのアイテムがどのように変化したかを把握できます。 ネイティブ機能として、DynamoDB は、S3 にフルエクスポートされたデータを新しいテーブル（ロードの過程で作成されます）に取り込む機能をサポートしています。AWS は、ロード中に処理された圧縮されていないデータの GB 単位でこの機能を価格設定しています。この記事で説明する技術は、この機能を補完し、ロードレート制御、カスタムアイテム操作、フィルタリングされたアイテムロード、既存テーブルの進捗追跡の機能を提供します。 なお、DynamoDB には現在、インクリメンタルエクスポートに基づいてデータをロードするネイティブ機能はありません。ここで説明する技術を使用すると、フルエクスポートと同じ柔軟性でこれらのファイルをロードできます。 使用方法 Bulk Executor は、”load-export” コマンドを使用してフルおよびインクリメンタルエクスポートされたデータのロードをサポートしています。 インストール手順 では、ツールのセットアップ方法を説明しています。セットアップ後の使用方法は次のとおりです。 ./bulk load-export --table <target> --s3-path <s3://bucket/path/to/data> [--transform <transform_module>] <target> を宛先テーブルの名前に置き換えます。このテーブルは既に存在している必要があります。空でもデータがあっても構いません。ロードはプライマリキーが一致する既存のアイテムを上書きします。 s3-path パラメータには、エクスポートされたデータを含む Amazon S3 のロケーションへのフルパスを指定します（例: s3://<bucket-name>/prod/AWSDynamoDB/01716790307109-5f9d6aaa ）。エクスポートされたデータは、フルまたはインクリメンタルエクスポートのいずれかです。データフォーマットは自動的に検出され処理されます。 オプションの transform パラメータは、各アイテムをロードする前に加工を加えるためのユーザー定義ロジックを含む Python ファイルの名前を受け取ります。ロードが各アイテムを処理する際、フルロードかインクリメンタルロードかに応じて、Python ファイルの transform_full_record(FullExportRecord) または transform_incremental_record(IncrementalExportRecord) 関数を呼び出します。この関数内で、以下を返すことができます。 レコード: 調整なしでアイテムをロード（または削除） 空のリスト: このアイテムのロード（または削除）を抑制 変更されたレコード: 調整付きでアイテムをロード 複数のアイテムのリスト: 1 つのソースレコードから複数のアイテムを書き込むためにファンアウト この関数は完全にカスタマイズ可能なので、これから行うアクションのあらゆる側面を操作できます。transform モジュールコードのブートストラップに関する詳細情報については、リポジトリ内の readme ファイルを参照してください。 AWS Glue ジョブは、任意の大きさのデータセットを処理するために並列実行でロードを実行し、標準の Bulk Executor のレート制限パラメータを介してレート制限が利用可能です。 ユースケース フルおよびインクリメンタルエクスポートをロードする機能は、さまざまなユースケースをサポートします。次のセクションでは、2 つの一般的なユースケースを概説します。 独立したテーブル同期 一般的なユースケースは、 グローバルテーブル とそのアクティブ-アクティブ伝播を使用せずに、一連のインクリメンタルエクスポートをロードして、2 つのテーブルを切り離された一方向の方法で同期することです。これは、ステージングまたは開発テーブルを本番と一致させたり、サードパーティのテーブルコピーを自分のものと同期させたり、隔離された環境内のテーブルコピーを維持したりするのに有用です。通常、毎回 2 つ目のテーブルを完全に作成するよりも、インクリメンタルエクスポートを適用する方がコスト効率と時間効率が高くなります。 以前の記事では、 継続的なデータ保持を推進する方法 について説明しています。 データの変換 もう 1 つの一般的なユースケースは、変換機能を使用して、あるテーブルから別のテーブルにデータを移動する際にデータをフィルタリングまたは変更することです。 例えば、フィルタリング関数を使用して、フルエクスポートを実行し、属性駆動型のフィルタリングで変換を行うことで、あるテーブルから別のテーブルにデータの一部をコピーできます。ロード中に各アイテムの属性を評価し、そのアイテムが 2 つ目のテーブルに伝播するかどうかを判断できます。SaaS (software as a service) 企業で、複数のテナントを持つテーブルがあり、1 つのテナントを切り出したい場合などに使用できます。これを実現するには、そのテナントのデータのみをロードします。または、最近のデータのみを保持する新しいテーブルのコピーが必要な場合は、最近のタイムスタンプを持つアイテムのみを許可する変換でロードを実行できます。 別の用途は、修飾子としての使用です。SSN や DOB 属性などの個人を特定できる情報 (Personally Identifiable Information, PII) をダウンストリームテーブルにロードする際にロードを抑制できます。また、タイムスタンプ属性を ISO 8601 文字列から数値エポック形式に調整することもできます。ファンアウト関数を使用すると、単一のアイテムから値のリストを個々の値の個別アイテムに分割できます。キースキーマを調整することもできます。 transform 関数を使用して、新しいキースキーマに移行することもできます。例えば、エクスポートされたデータで last_name と first_name がそれぞれパーティションキー (PK) とソートキー (SK) として含まれている場合などです。宛先テーブルには、PK として user_id という新しいフィールドがあります。transform 関数を使用すると、ロード中に各アイテムに GUID を user_id として正常に注入し、他の既存の属性を維持できるため、新しいキースキーマに効果的に移行できます。 技術的な内部構造 load-export コマンドは、Bulk Executor フレームワークを使用して実行されます。Bulk Executor は差し込み式のコマンドをサポートしているため、最初に load-export コマンドをカスタムコマンドとして作成し、その後公式リポジトリに貢献しました。 検証 ロードプロセスが開始される前に、コードはマニフェストに基づいてエクスポート全体を検証し、すべてのファイルが存在し、その署名がマニフェストと一致することを確認します。これにより、エクスポートデータに偶発的に生じた破損を防ぎます。 読み込み ロードプロセスは AWS Glue を使用して、Amazon S3 オブジェクトを Spark Resilient Distributed Dataset (RDD) にロードし、フルまたはインクリメンタルエクスポートかどうかを検出します。 変換 transform 機能は、2 つの主要な関数を公開します。1 つはフルロード中にレコードを変換するためのもので、もう 1 つはインクリメンタルロードのためのものです。現在処理中のソース Amazon S3 レコードがこの関数にパラメータとして渡されます。このレコードはすべての内部データを辞書型で公開するため、ロードプロセスを完全に制御できます。次の例は、 status 属性が active 値を持つアイテムのみを含める方法を示しています。 def transform_full_record(record: FullExportRecord) -> list[FullExportRecord]: """ Example: Only load items where 'status' attribute is 'active'. Args: record: record.item is the deserialized Item dict, record.table_key_schema has key info. Returns: list[FullExportRecord]: Single-element list to keep, empty list to skip """ if record.item.get("status") == "active": return [record] return [] def transform_incremental_record(record: IncrementalExportRecord) -> list[IncrementalExportRecord]: """ Example: Only load items where 'status' attribute is 'active'. Behavior: - If new_image exists and status is 'active': load the item (PUT) - If new_image exists but status is not 'active': skip the item - If new_image is None (a delete): return the record, i.e. respect the delete Args: record: record.keys, record.new_image, record.old_image, record.table_key_schema, record.write_timestamp_micros Returns: list[IncrementalExportRecord]: Single-element list to keep, empty list to skip """ if record.new_image: if record.new_image.get("status") == "active": return [record] else: return [] return [record] transform コードは完全にあなたの管理下にあります。通常、効率のために単純なアルゴリズムチェックを実行させますが、レイテンシーを許容できる場合は、決定を下しながら CRM や別のデータベースにクエリを実行するなど、外部ソースをクエリすることもできます。 並列化とレート制限 次に、コマンドはデータを AWS Glue ワーカーに分散して、DynamoDB に並列で書き込みます。各 AWS Glue スロットは独立したライターとして動作します。この大量並列化がテーブルのスループット容量を超えるのを防ぐために、Bulk Executor の 分散レート制限 機能を使用します。これにより、設定可能な読み込みまたは書き込みキャパシティを使用できます。 検証 ロードが完了した後、 bulk diff ツール機能を使用して 2 つのテーブルを比較する ことで、データの整合性を検証できます。両方のテーブルが一致する場合、次のような出力が表示されます。 ./bulk diff --table source --table2 destination … No differences found コストに関する考慮事項 ロード中にコストを左右する主な要因は、次の 2 つです。 DynamoDB テーブルの書き込み消費: 書き込まれるアイテムの数とサイズに基づきます。 AWS Glue データ処理ユニット (Data Processing Unit, DPU): AWS Glue ジョブ中のワーカーの数、ワーカーのタイプ、実行時間に基づきます。 次の実行は、1 億レコードを保持するフルエクスポートに対するフルロードのテスト実行を示しています。デフォルトのワーカータイプ (G.1X) と デフォルトの AWS Glue ワーカー数 (220 までオートスケーリング) を使用しました。ロード速度を上げるために、毎秒 240,000 書き込みユニットで 事前ウォームアップ されたオンデマンドテーブルを作成しました。bulk ツールに 240,000 すべてを使用するよう指示しました。総実行時間は 12 分 27 秒でした。 >> ./bulk load-export \ --XMaxWriteRate 240000 \ --table ... \ --s3-path s3://... \ --XTimeout 10080 \ --XWaitForDPU … Destination Table: … S3 export: 100,000,000 items across 512 files (FULL_EXPORT, DYNAMODB_JSON) DynamoDB write costs depend on how many items are being written and the size of the items. Here we estimate the command will write 100,000,000 items with average size 256 bytes; each write incurs an average of 1 write units Write units required (approx): 100,000,000 This does not include costs for secondary indexes! Approx DynamoDB cost for on-demand writes consuming 100,000,000 WRUs (using us-east-1 prices): $69.50 Writing items to DynamoDB... =============================================================== JOB COMPLETED SUCCESSFULLY - Total items in export: 100,000,000 - Total items written: 100,000,000 - Execution time: 707.3 seconds … Waiting 40 seconds for DPU metrics to gather... Job completed successfully. Job duration: 0:12:27 (24.06 DPU hours) 実行では、ロードのサイズに基づいて DynamoDB のコストを早期に見積もり、ここでは小さなアイテムの約 1 億回の書き込みに対して $69.50 となっています。出力には最後に AWS Glue のコストが表示されます。 us-east-1 で 1 DPU 時間あたり $0.44 の価格 で、約 $10 です。 制限事項 load-export コマンドは DDB-JSON フォーマットを使用したエクスポートのみをサポートし、ロードは同じプライマリキーを持つ既存のアイテムを上書きします。異なる動作が必要な場合は、コードを変更できます。 まとめ この記事では、Bulk Executor を使用して DynamoDB のフルおよびインクリメンタルエクスポートをバルクロードする方法を概説しました。オプションの変換機能を使用して、ロードするデータとその構造を思いどおりに選択でき、組み込みの レート制限 が書き込みキャパシティの飽和を防ぎます。Bulk Executor の リポジトリ をクローンして、今日最初のロードを実行することから始めましょう。 著者について Ruskin Dantra Ruskin はカリフォルニアを拠点とするソリューションアーキテクトです。彼は元々「長く白い雲のたなびく地」ニュージーランド出身で、アプリケーション開発の 18 年のベテランで、ネットワークを愛しています。彼の人生における情熱は、AWS を使用して複雑なものをシンプルにすることです。 Jason Hunter Jason はカリフォルニアを拠点とする Amazon DynamoDB を専門とするプリンシパルソリューションアーキテクトです。彼は 2003 年から NoSQL データベースに取り組んでいます。Java、オープンソース、XML への貢献で知られています。 AWS Database Blog で、より多くの DynamoDB の投稿 や Jason Hunter が書いた 他の投稿を見つけることができます。

本稿は、2026 年 8 月 18 日に公開された “ Amazon EVS with NSX Federation for Disaster Recovery and Multi-site Networking ” を翻訳したものです。 はじめに Amazon Elastic VMware Service (Amazon EVS) が NSX Federation をサポートしました。これにより、AWS 上で VMware ワークロードを実行する際のエンタープライズ規模のネットワーク、ディザスタリカバリ (DR)、マルチサイトネットワークのための強力な新しいオプションが利用可能になります。 NSX Federation は、複数の NSX 環境を単一の Global Manager コントロールプレーンの下で接続する VMware のネットワーク機能です。オーバーレイネットワーク、セキュリティポリシー、ゲートウェイサービスを複数のロケーションに拡張し、各サイトを個別に設定するのではなく、複数サイトのネットワークを統一されたファブリックとして管理できます。 VMware Cloud Foundation Operations HCX (HCX) は、マイグレーションおよびマイグレーション中のネットワーク拡張のための VMware のソリューションです。NSX Federation は、大規模な Layer 2 拡張、ロケーション間での統一されたセキュリティポリシー、マルチサイトメッシュ接続、および 1 分未満のフェイルオーバーによるネイティブ DR を必要とするシナリオに対応することで、HCX を補完します。 この記事では、これが重要である理由、NSX Federation が HCX 単体では提供できないネットワーク機能をどのように拡張するか、そしてワークロードの真のマルチサイトネットワークをどのように実現するかを説明します。 課題: エンタープライズネットワークが単一ソリューションの範囲を超える場合 VMware HCX Network Extension (NE) は、マイグレーション中にサイト間で Layer 2 セグメントを延伸するための実績のある専用技術です。マイグレーションワークフローや小規模な DR シナリオでは効果的かつ迅速にデプロイできます。しかし、企業がスケールするにつれて、HCX に加えて追加の機能が必要になることがあります。 大量の VLAN 数 – 数百の VLAN を持つ環境では、アプライアンスペアごとの拡張ではなく、ファブリックレベルのアプローチが有効です。 統一されたセキュリティポリシー – 単一サイト内だけでなく、すべてのロケーションで一貫して適用される Distributed Firewall (DFW) ルール。 マルチサイトメッシュネットワーク – 複雑なハブアンドスポークトポロジなしに 3 つ以上のロケーションをネイティブにサポート。Federation により、ネットワーク全体を再設計することなく、設定ステップとして新しいサイトを追加できます。 ステートフル DR フェイルオーバー – フェイルオーバー中にステートフルサービスが完全に保持された状態での 1 分未満のネットワーク接続復旧。 ここで NSX Federation が登場します。HCX の代替ではなく、これらのエンタープライズ規模の要件に対応する補完機能です。 ソリューション: Amazon EVS 上の NSX Federation NSX Federation は、参加するすべてのロケーションにまたがる 単一の Global Manager によって管理される 、統一されたオーバーレイネットワークファブリックを作成します。HCX と並行して動作し、それぞれの技術がその強みを発揮します。 NSX Federation が提供する機能 機能 メリット 数千のセグメント Global Segments はフェデレーションファブリック全体で 数千にスケール 統一された Distributed Firewall (DFW) DFW ルールは Global Manager 上で一度定義され、すべてのロケーションで一貫して適用 マルチサイトメッシュ Federation は複数のロケーションをネイティブにサポート。3 番目や 4 番目のサイトの追加は設定ステップであり、複雑なポイントツーポイントリンクを構築することなく真のマルチサイト接続を実現 ステートフルゲートウェイフェイルオーバー Active-Standby Tier-0 ゲートウェイがステートフルサービス (NAT、Gateway Firewall) を含む 1 分未満のフェイルオーバー を提供 シングルペインオブグラス Global Manager がすべてのフェデレーションロケーションの一元管理を提供 マルチサイトネットワークの実践 Federation の大きな利点の 1 つは、マルチサイト接続です。従来のアプローチでは、3 つ以上のサイトを接続するには、個別のポイントツーポイントリンクを構築し、各ペア間のルーティングを管理する必要がありました。Federation は、すべてのロケーションを単一ファブリックのメンバーとして扱うことで、この複雑さを排除します。 サイト A のワークロードは、追加の設定なしに同じ Global Segment 上でサイト B またはサイト C と通信できます。 DFW ポリシーは、ファブリック内のどのサイトで実行されているかに関係なく、ワークロードに追従します。 Global Manager に登録してローカル Edge ノードをデプロイすることで、新しいサイトの追加ができます。既存ネットワークのオブジェクト (セグメント、ファイアウォールルール、ゲートウェイ) は自動的に新しいロケーションに拡張されます。 これにより、Federation は複数の AWS リージョンやアベイラビリティーゾーンをまたいで運用する組織や、オンプレミスデータセンターとのハイブリッド接続を維持する組織にとって特に価値があります。 ビジネス価値: エンタープライズクラウド導入にとって重要な理由 1. 停滞しているマイグレーションの解消 複数の企業が、マルチサイト DR および数百のネットワークセグメントにまたがる IP 保持接続の要件が、マイグレーションツールで実現可能ではあるものの、大規模であれば非実用的なリソースコストでしか達成できないため、Amazon EVS の採用がブロックされていました。NSX Federation はこれらの組織のブロックを直接解消し、本番環境のデプロイメントを進めることを可能にします。 2. 運用複雑性の削減 Federation は大規模な L2 拡張を単一のマネージドファブリックに統合します。運用負荷は大幅に低下します。 1 つの Global Manager がすべてのロケーションにわたる一元的な制御を提供 1 つの DFW ポリシーセット がどこでも一貫して適用 1 つのフェイルオーバーメカニズム (Active-Standby T0) がネットワークフェイルオーバーをネイティブに処理 3. 真のビジネス継続性 Amazon EVS 上の NSX Federation は以下を実現します。 ネットワーク RTO: 1 分未満の Active-Standby Tier-0 ゲートウェイフェイルオーバー 。これを実現するには、NSX フェイルオーバーおよびルートテーブルの更新などの AWS 側のネットワーク変更のためのオートメーションが必要です。 RPO: Amazon FSx for NetApp ONTAP SnapMirror レプリケーションで 約 5 分 (またはマルチ AZ デプロイメントで RPO 0) フェイルオーバーの前、最中、後において、両サイトで DFW ルールがアクティブな状態での 一貫したセキュリティポスチャ HCX と NSX Federation: 組み合わせによる相乗効果 HCX と NSX Federation は補完的な目的を持ち、組み合わせて効果的に機能します。それぞれが適しているユースケースは以下の通りです。 ユースケース 推奨アプローチ マイグレーション (バルク vMotion/レプリケーション) HCX、マイグレーションワークフロー向けに専用設計 少数の VLAN での 2 サイト間 L2 拡張 HCX Network Extension、シンプルかつ迅速にデプロイ可能 大規模な L2 拡張 (大量の VLAN 数または 3 サイト以上) NSX Federation、アプライアンスごとの上限なしのファブリックレベルアプローチ ステートフルフェイルオーバーによるマルチサイト DR NSX Federation、Active-Standby T0 で 1 分未満の RTO サイト間で一貫した DFW ポリシー NSX Federation、Global Manager からの統一されたセキュリティ 3 サイト以上 NSX Federation、ネイティブマルチロケーションメッシュ マイグレーション + DR (組み合わせ) 両方: HCX でマイグレーション処理、Federation で恒久的なネットワークと DR エンタープライズ企業は HCX と NSX Federation の両方を使用できます。HCX がマイグレーションの過程を処理し、NSX Federation がワークロードの配置後に長期的なネットワークと DR の基盤を提供します。 まとめ この記事では、Amazon EVS 上の NSX Federation が AWS 上のエンタープライズ VMware ネットワークの可能性をどのように拡大するかを紹介しました。ファブリックレベルの L2 拡張、統一されたセキュリティポリシー、ネイティブマルチサイトメッシュ接続、1 分未満の DR フェイルオーバーにより、HCX を補完します。これらの機能を組み合わせることで、マイグレーションを超えたエンタープライズ規模の要件に対応するためのツールが提供されます。 大規模なマイグレーションを計画している場合でも、マルチサイト DR アーキテクチャを構築している場合でも、複数の AWS ロケーションとオンプレミスデータセンター間でワークロードを接続している場合でも、Amazon EVS 上の HCX と NSX Federation の組み合わせが、それを正しく実現するためのネットワーク基盤を提供します。 始める準備はできましたか？ お使いの環境での NSX Federation デプロイメントについては、AWS アカウントチームにお問い合わせいただくか、 Amazon EVS のドキュメント で詳細をご確認ください。 著者について Ron Wedel Ron Wedel は AWS のシニアソリューションアーキテクトです。20 年以上にわたり仮想化技術に携わっており、パートナーやお客様が AWS への次のステップを踏み出す支援を楽しんでいます。AWS ソリューションアーキテクトとして、VMware 環境、ネットワーク、コンピューティングインフラストラクチャの最適化を専門としています。これらの技術に関する包括的なバックグラウンドが、AWS のお客様が AWS 上でモダンインフラストラクチャを構築・成長させるためのアプローチの基盤となっています。 Jay Scheponik Jay Scheponik は AWS のシニアスペシャリストソリューションアーキテクトで、マイグレーションとモダナイゼーションを担当しています。エンタープライズ IT およびインフラストラクチャにおける長年の実践経験を活かし、お客様の VMware ワークロードの AWS への移行を支援しています。Jay は 12 の AWS 認定資格を保有し、VMware Certified Design Expert (VCDX) でもあります。仕事以外では、ゴルフ、レコードを回すこと、ゲーム、家族との時間を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。

NEC は 2026 年 6 月 1 日、全社員（最大 12 万人）が利用できる Claude Cowork の本番環境を Amazon Bedrock 上で稼働させました。設計着手は 5 月 18 日、要件定義から全社リリースまで 2 週間です。検討を進めていた 2026 年 5 月の時点では、この構成はまだ一般提供（GA）開始前 (*1) でした。前例の少ない構成を採用しながら、国内完結の推論・監査証跡・コスト管理を備えた環境を立ち上げています。本記事では、現場を率いた NEC 野口氏の視点と、AWS が担った役割の両面から振り返ります。 本記事は、日本電気株式会社（以下、NEC）コーポレートIT・AIイノベーション部門 AIプラットフォーム統括部 ディレクター 野口 忠則 氏と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 吉川 晃平の共著です。 はじめに（AWS 吉川） 生成 AI アシスタントの全社導入では、 「使えるようにする」ことと「統制の効いた状態で使えるようにする」ことの間に大きな隔たりがあります。データの所在、認証・認可、監査ログ、コストの可視化といった非機能要件は、利用者が数万人規模になると難易度が跳ね上がり、多くの場合は後から足すことができません。 2026 年 7 月 28 日に開催された AWS Bedrock LLM Day Japan にて、NEC の野口氏が「Anthropic 協業の舞台裏 〜 AI ネイティブ化に向けた Cowork on Bedrock 適用 〜」と題して登壇されました。私は本プロジェクトを担当するソリューションアーキテクトとして、NEC のプロジェクトチームをご支援してきました。そのセッションで語られた内容を軸に、NEC が何に挑み、どう乗り切り、Amazon Bedrock を選んで何を得たのかをお伝えします。 なお、本記事で扱う構成は、Anthropic のデスクトップアプリ Claude Desktop（Chat・Claude Cowork・Claude Code を含みます）の推論を Amazon Bedrock に向けるもので、正式名称は Claude Desktop on Amazon Bedrock です。NEC が全社展開されたのは Claude Cowork の利用であるため、本記事では通称の Claude Cowork on Amazon Bedrock を用い、機能そのものを指す場合は Claude Cowork と表記します。 ここからは、NEC の野口氏にバトンを渡します。 全社が使い始める、その日までに（NEC 野口） NEC は 2026 年 4 月 23 日に Anthropic との協業を発表し、6 月 1 日から社内での利用を開始しました（図 1）。発表から利用開始までの期間は限られており、準備に使える時間は多くありませんでした。ここからお話しするのは、5 月の連休明けから 6 月 1 日のリリースまで、展開の現場で何が起きていたかです。 図 1: 協業発表から全社利用開始、その後の展開までのタイムライン（出典: AWS 作成） Claude Cowork を社内で利用する方式は 2 つあります。Anthropic のサービスプラン Claude Enterprise を契約する方式と、Amazon Bedrock に接続する方式です。5 月中旬の時点で、私たちは社内利用に必要な技術検証を進めていました。プロキシ経由の通信など社内ネットワーク特有の課題は、どちらの方式でも共通の検討事項です。その頃、Amazon Bedrock に接続する方式についても AWS への相談を始めました。ただし 2026 年 5 月の時点では一般提供前であり、このときは「いずれ AWS 上でも構築しよう」という受け止めでした。 その 1 週間後、全社の利用開始に合わせて AWS 上にセキュアな環境を構築する方針が決まりました。期限は 6 月 1 日です。当初の想定より前倒しの判断でしたが、私たちはこれを妥当だと受け止めました。理由は 2 つあります。 1 つは、Amazon Bedrock であれば推論とデータを国内に閉じられることです。これが私たちにとって最も重い要件でした。 もう 1 つは、利用者が自分の手で作り上げていく設定を、後から移すコストです。会話履歴やメモリ、プロジェクトの設定には、方式をまたいで引き継ぐ仕組みがありません。スキルは中身がファイルなので移植そのものは可能ですが、一括で取り出す手段は用意されておらず、どれを登録し有効にしていたかという状態も引き継げません。人手での再構築が必要になります。数万人が使い始めた後にそれをやるのかと考えたとき、答えは決まっていました。利用者にとっての「使い始め」に、その後も使い続ける環境を用意しておく。それが 6 月 1 日という期限の意味でした。 2 週間で本番環境をつくるということ（NEC 野口） 方針が決まっても、それだけで現場が動くわけではありません。セキュリティ設計、動作確認、社内認証連携といった工程は、通常であれば数か月をかけるものです。大規模システムの本番構築を経験された方であれば、2 週間という期間がどれほど過酷かご想像いただけると思います。短い期間で進めることに対して、慎重な意見もありました。当然です。だからこそ、精神論ではなく段取りで通すしかないと考えました。状況を共有しながら一緒に進めるほかありません。私自身、プロジェクトマネジメント（PM）とシステムアーキテクト（SA）の経験はありますが、この部署に来てまだ 1 年。頼れる関係を一から築きながらの 2 週間でもありました。 それでも「一緒にやりましょう」と手を挙げてくれたメンバーが数名いました。この数名がいなければ、6 月 1 日はありませんでした。徹底したのは、 作業の優先順位を明確にすること 、 タスクの範囲を限定すること 、 構築状況を踏まえて次に実施すべきことを判断し共有すること です。加えて、短期間で新しい技術を扱う案件では、経営層の理解と後押しが欠かせません。組織全体が AI 活用に前向きだったことは、成功の要因の一つでした。こうして出来上がったのが図 2 の構成です。 図 2: 完成したアーキテクチャ。推論は日本国内リージョンで完結し、利用者 ID は Microsoft Entra ID で連携する（出典: AWS 作成、NEC 登壇資料に基づく） 技術面で注意したのは 2 点です。1 つは、国内完結の推論を要件としたため、海外リージョンへ推論を分散できないこと。事前に把握していたので、性能設計と負荷テストを 2 週間の中に組み込みました。もう 1 つは外部システムと接続するコネクタ部分で、これが最も工数を要しました。 最も苦労した点 — MCP サーバーの OAuth 実装差異への対応（NEC 野口） Amazon Bedrock 利用時は、管理者が MCP（Model Context Protocol）サーバーの設定を端末へ配布することで、利用者はアプリの UI からコネクタを簡単に追加できます。ところが、簡単に安定稼働させられるかというと、そうではありませんでした。接続先の SaaS ごとに MCP や OAuth の実装が細かく異なるため、接続が成立することと期待どおりに動作することは、それぞれ確認が必要でした。 2026 年 5〜6 月時点では、Claude Desktop on Amazon Bedrock が対応する方式と接続先の実装との間に複数の差異がありました。DCR（Dynamic Client Registration）による OAuth クライアントの動的登録に対応していない接続先では事前の手動登録が必要になり、クライアント認証方式にも違いがありました。そこで NEC は、 これらの差を吸収する認可中継サーバーを独自に設計・構築 しました。このサーバーは 7 月 18 日に社内リリースし、接続可能なサービスを順次広げています。 リリース 1 週間前に判明した認可動作の差異 最初の 1 週間が過ぎた 5 月 22 日金曜の夜、メンバーから、想定と異なる挙動があるという報告が入りました。自社だけでは原因の切り分けができず、その夜のうちに AWS のアカウントチームへ連絡しました。翌日の土曜から調査に入ってもらえることになりましたが、リリースまで 1 週間しかありません。正直に申し上げると、その週末は崖っぷちに立たされた気分で、6 月 1 日のリリースは無理だと思っていました。 それが、日曜の夕方には問題の所在が判明します。AWS の担当チームが全力で入ってくれたおかげでした。原因は、OAuth クライアントの登録と認可フローの動作が私たちの理解と異なっていたことでした。公開情報だけでは判断が難しい部分があり、AWS のエンジニアと一緒に実機で確認して初めて整理できた内容です。 もっとも、分かったのは「なぜ動かないのか」であって、そこから 6 月 1 日までの対応は決して楽ではありませんでした。新しい領域の技術を早い段階で採用するうえでは起こり得ることですが、リリース前に把握できたことは大きかったと考えています。 プロジェクトの目的と体制（NEC 野口） プレスリリースでは「Claude を利用する AI ネイティブエンジニア体制」として発表しましたが、Claude Cowork は全員が業務で使うため、最大 12 万人規模で使える環境を構築しました。目的は単なる AI ツールの導入ではなく、大きく 2 つあります。1 つは 独自構築 で、コアとなる要件まで自ら設計・構築し、環境のコントロールを自社で握ることです。もう 1 つは Client Zero 、つまり自社を最初の顧客として実践し、日本企業共通の課題に対する先駆的なリファレンスを確立することです。 体制は、NEC の 統括チーム （中央官庁の大規模 SI でのプロジェクトマネージャー・システムアーキテクト 経験者）と 社内 SE チーム （社内 IT ・インフラシステムエンジニア）、そして本プロジェクトのために AWS 側で編成した AWS チーム という、3 つの専門性を持ち寄る編成としました（図 3）。これが短納期での実現につながったと考えています。 図 3: 要件定義・設計/構築・テスト・運用を 2 週間に凝縮したスケジュール（出典: NEC 登壇資料） Claude Cowork on Amazon Bedrock の適用価値（NEC 野口） Claude を Amazon Bedrock 経由で利用する以外の選択肢もありましたが、要件を整理した結果、国内利用限定という私たちの要件を満たせると判断できたのは Amazon Bedrock でした。図 4 の 3 つの適用価値のうち、最も重視したのは国内データ保管です。 図 4: ①NEC 基準にカスタマイズ可能なセキュアクラウド、②データを国内に閉じた構成、③早期リリースによる先行利用とノウハウ獲得（出典: NEC 登壇資料） 機能面では、Claude Enterprise（Anthropic のサービスプラン。AWS Marketplace 経由でも調達できます）を契約する方式のほうが先に提供される機能や、Amazon Bedrock 接続では提供されない機能もあり、利用者から要望をいただくこともあります。それでも情報システム部門としては、 国内データ保管とガバナンスを最優先とする要件のため、Claude Cowork を Amazon Bedrock に接続する構成を選びました 。判断にあたっては、AWS から提供を受けた 2 つの方式の整理（図 5）を材料としています。 図 5: NEC が Amazon Bedrock 接続を選んだ理由。左は NEC が優先した要件、右は Claude Enterprise 契約で提供され利用者から要望のあった機能。NEC の要件に照らした整理であり、一般的な優劣を示すものではない（出典: AWS 作成、2026 年 7 月時点の公開情報および NEC 登壇内容に基づく） 成果と成功のポイント（NEC 野口） 綱渡りの連続でした。一つひとつの判断が結果に直結し、退路のない 2 週間でした。無事に立ち上がったと言えるようになったのは、しばらく経ってからです。6 月 1 日のリリースから 2026 年 7 月時点までの約 2 か月間、大きなトラブルなく安定稼働しています。利用者は 8 月 18 日時点で 11,000 名まで広がっています。国内完結の推論・監査証跡・コスト管理を完備し、国内大手 IT ベンダーとして先行事例をつくれたと考えています。業務効果の定量的な測定は今後の課題です。成功のポイントは 3 点です。 組織の後押しと許容 — AI 領域は技術の進化が速く、評価の段階では想定どおりに動かない場面も出てきます。経営層の理解と許容があってこそ、提供スピードは上がります。 大規模システムの PM 力 × アーキテクト力 — 重要タスクを見極め、優先順位をつけて執行し続けること。リード役は細部の完璧さより全体を前に進める判断を優先すべきです。 One Team 体制の推進 — 前例の少ない構築では、地道な検証と改善の繰り返しが必要です。ベンダーと一体で進める体制は、経営層の関与があって初めて成り立ちます。 今後は AI 基盤をさらに進化させ、エージェントの本番活用へ拡張していきます（図 6）。 図 6: 大規模・短納期での構築の成果、成功ポイント、今後の展望をまとめた登壇資料のスライド（出典: NEC 登壇資料） 同じような判断を前にされている方に、少しでも参考になればと思います。 ここからは、AWS の吉川に戻ります。 AWS の支援内容（AWS 吉川） 本プロジェクトで AWS が担った役割は 4 つです。 利用方式の提示と、ご要件に対する事実の回答。 Claude Cowork には Claude Enterprise を契約する方式と Amazon Bedrock に接続する方式があり、いずれも AWS からご利用いただけます。この 2 つの選択肢があることをお伝えしたうえで、NEC からご照会のあった観点について、Amazon Bedrock 接続での構成・運用に関する事実をお答えしました（図 5）。データレジデンシー、閉域網構成、キャパシティ、AI ガードレール、マルチモデル対応、各種のセキュリティ・コンプライアンス認証、MDM による環境設定の大規模展開、MCP サーバーの設定や Agent Skills の利用者への展開などです。Amazon Bedrock 接続では利用できない機能とその代替手段もお伝えしています。両方式の機能差分は Anthropic の公式ドキュメント に一覧が公開されています。要件の定義と優先順位付け、方式の選択はいずれも NEC のご判断です。 国内完結の推論構成の設計支援。 日本国内のリージョン間で推論を完結させるクロスリージョン推論プロファイル（cross-Region inference profile。推論プロファイル ID が jp. で始まるもの。以下、JP-CRIS）を用いた構成をご提案しました。プロンプトと応答は国内にとどまり、リージョン間通信も AWS のプライベートネットワーク内で完結します。認証は Microsoft Entra ID による利用者 ID 連携とし、AWS Identity and Access Management (IAM) による認可など AWS のセキュリティ機能と一体で運用する設計としています。 大規模キャパシティの設計と実測検証。 国内完結の推論を要件とすると、利用できる推論プロファイルが国内に限られ、モデルごとの TPM（Tokens Per Minute）クォータが実効的な上限になります。野口氏が挙げられた「海外リージョンへ推論を分散できない」という制約はこの点を指します。モデル別のクォータ設計とパイロット実測に基づく容量計画をご支援し、リリース後も使用率を継続モニタリングしています。2026 年 7 月時点では、いずれのモデルも上限に十分な余裕があり、スロットリングは発生していません。 週末を含む切り分けの伴走。 5 月 22 日金曜夜のご連絡を受け、本件では土曜の朝からアカウントマネージャーとソリューションアーキテクトでチームを組み、日曜の夕方までに切り分けを完了しました。前例の少ない構成をご採用いただくことは、お客様だけにリスクを負っていただくことではありません。ここは AWS が前に出るべき場面だと考えています。 おわりに（AWS 吉川） 本事例の示唆は技術選定に留まりません。後から足せない要件は何か、後から移すと人手のかかるものは何かを見極め、「使い始めの日」から逆算する。そしてその判断を実行に移せる体制と経営の後押しを確保する。NEC が 2 週間でやり切られたのは、この順序を間違えなかったからだと感じています。 本記事で述べた Claude Desktop の Amazon Bedrock 経由での利用は、 2026 年 7 月 9 日に一般提供が開始されています 。Claude Desktop の機能追加も続いており、例えば 2026 年 6 月 30 日のアップデート では、Amazon Bedrock 接続の構成でも プラグインマーケットプレイス （ベータ）が使えるようになりました。社内の Git リポジトリを配布元として指定し、任意の導入・自動導入・必須指定の 3 段階で配布を統制できます。 NEC でも、こうした機能の追加を踏まえ、統制と利用者の利便性を両立させるスキル配布のあり方について、継続して検討を進められています。一般提供の開始前に始まった取り組みは、早期のリリースを実現した後も社内サービスの改善として続いており、AWS も新機能の評価や運用設計の面で継続して支援しています。 Amazon Bedrock は、Claude をはじめ複数ベンダーの基盤モデルを AWS のセキュリティ・ガバナンス機能と一体で運用できる AWS サービスです。閉域網、ガードレール、監査ログ、支出管理といった運用設計は、将来別の AI エージェントを導入する際にもほぼそのまま再利用できます。NEC が次に注力されるテーマについても、引き続きご一緒していきます。 Claude と Amazon Bedrock のエンタープライズ活用にご関心のある方は、 Amazon Bedrock をご覧いただくか、担当のアカウントチームまでお問い合わせください。 日本電気株式会社について NECは、125年以上の歴史を有する、AIやサイバーセキュリティ、通信などの技術を強みとするグローバルテクノロジー企業です。社会と産業のAIトランスフォーメーションを推進するITサービス事業と、日本をはじめ世界の安全保障に貢献する社会インフラ事業を展開しています。業種横断の先進的な知見と最先端技術を結集し体系化した価値創造モデル「BluStellar(ブルーステラ)」を中核に、世界に革新と安心を届け、誰もが人間性を十分に発揮できる社会の実現を目指します。 著者について 野口 忠則 — 日本電気株式会社 コーポレートIT・AIイノベーション部門 AIプラットフォーム統括部 ディレクター。1999 年 NEC 入社。IP-PBX の開発を経て、19 年間にわたり中央官庁向け SI のプロジェクトマネジメントとシステムアーキテクトを担当（2016 年システム部長）。2025 年より社内 IT の AI 業務変革に従事。 吉川 晃平 — ソフトウェア開発者およびシステムインテグレーターとして 20 年以上従事した後、2020 年から AWS Japan でソリューションアーキテクトとして活動中。日本の多くの製造業や SI 事業のお客様の AWS 活用を支援してきた。最近は AI 開発エージェントを用いた製品開発ライフサイクルの加速に取り組んでおり、お客様との会話のネタが尽きない毎日を送っている。 (*1) : Claude Desktop の推論を Amazon Bedrock などの外部の推論基盤に向ける構成（Claude Desktop on third-party）は、2026 年 7 月 9 日に一般提供が開始されました。詳細は Anthropic の公式ドキュメント Claude Desktop on third-party (3P) の概要 を参照してください。

本記事は 2025 年 3 月 18 日 に公開された「 Streamlining access to tabular datasets stored in Amazon S3 Tables with DuckDB 」を翻訳したものです。 データドリブンな意思決定への依存が高まるなか、データ分析のプロセスを効率化・高速化するツールへの需要が増しています。重要な意思決定を進める場面では、アプリケーションアーキテクチャの効率性とシンプルさが競争優位につながります。開発者は、既存のアプリケーションスタックとスムーズに統合できる軽量で柔軟なツールを求めています。特に、データレイクに保存されたデータセットを素早く効率的にクエリするための手段が重視されています。 こうした状況において、 DuckDB は複雑なインストールなしにデータを素早く分析できる実用的な選択肢として注目されています。DuckDB はホストプロセスに完全に組み込まれ、別プロセスとして動作しないため、インストール・更新・保守が必要な別サーバーやソフトウェアを用意する必要がありません。軽量な設計により、Python、Java、その他の環境に容易に統合でき、対話型のデータ分析に適しています。DuckDB には最近、 Apache Iceberg REST API を利用して Amazon S3 Tables に格納されたテーブルを読み取る プレビューサポート が追加されました。S3 Tables は表形式ストレージ専用に設計されており、Apache Iceberg 形式のデータを直接、高性能かつ低コストで保存・クエリできます。S3 Tables はストレージを継続的に最適化してクエリ性能を最大化し、コストを最小化するため、追加のインフラ構築なしにデータレイク運用を効率化したい企業に適しています。DuckDB と S3 Tables の統合により、開発者は Amazon S3 に格納されたデータをクエリでき、複雑なデータ移動や追加のインフラなしにテーブルへアクセスしながら、企業はデータレイクを効率化・集約できます。 本記事では、 Amazon SageMaker Lakehouse Iceberg REST エンドポイント と AWS Lake Formation のアクセス許可を利用して、ローカルマシンから DuckDB で S3 テーブルバケット内の Iceberg テーブルを読み取る方法を紹介します。同じデータ利用ワークフローは、リソースが限られた小型のエッジデバイスから、100 コア超の CPU を搭載する数テラバイトメモリの大型サーバーまで、幅広い環境で適用できます。DuckDB と S3 Tables の組み合わせは、AWS 上でスケーラブルなデータレイク構築を始めるための、直接的で堅牢な基盤になります。 ソリューションの概要 本記事では、 AWS CloudShell の CLI で DuckDB を使い、ローカルシステムから S3 バケットのテーブルを読み取る方法を紹介します。ここではコマンドラインインターフェイスを使いますが、DuckDB は複数のプログラミング言語とクライアント API をサポートしています。対応言語と統合オプションの一覧は、 DuckDB 公式ドキュメント を参照してください。また、本記事では、開発者やデータサイエンティストがローカル環境でクエリをテスト・反復してから本番規模でデプロイするという、一般的なパターンを扱います。まずクライアントに DuckDB をインストールし、次の図のように S3 テーブルバケットに格納されたテーブルへアクセスするための Lake Formation のアクセス許可を接続します。その後、クライアント上の DuckDB インスタンスにカタログをアタッチし、テーブルに対するクエリを試します。 前提条件 本記事の手順を実行するには、次の AWS サービスにアクセスできる AWS アカウントが必要です。 Amazon S3 Tables AWS Identity and Access Management (IAM) Amazon SageMaker Lakehouse Amazon Athena AWS Lake Formation ウォークスルー 本ソリューションを実装するには、S3 テーブルバケットにテーブルを用意し、テーブルを読み取るためのアクセス許可を設定し、ローカルクライアントに DuckDB インスタンスを構成する必要があります。以降のセクションで各ステップを説明します。 Part A: S3 Tables のセットアップ Part B: アクセス許可のセットアップ (オプション) Part C: DuckDB のセットアップ Part A: S3 Tables のセットアップ DuckDB は現時点で S3 Tables を読み取り専用モードでサポートしています。アカウントにテーブルがない、または AWS 分析サービスとの統合が未設定の場合は、以下の手順に従ってください。すでに設定済みであれば、本セクションはスキップできます。本セクションでは、テーブルバケットの作成、テーブルのセットアップ、データ追加を通じて、DuckDB で分析するためのデータを準備する手順を説明します。すでにデータが入ったテーブルがある場合は、本セクションをスキップして次のセクションに進んでください。 1. S3 テーブルバケットを作成し、AWS 分析サービスとの統合をセットアップする 1.1. AWS マネジメントコンソール で S3 に移動します。左のナビゲーションメニューから Table buckets を選択し、 Create table bucket を選びます。テーブルバケット名を指定し、次の図のように AWS 分析サービスとの統合が未有効の場合は Enable integration を選択します。この統合により、この AWS リージョン とこのアカウントで作成されたすべてのテーブルを SageMaker Lakehouse と Lake Formation で検出でき、 Amazon Data Firehose 、Athena、 Amazon Redshift 、 Amazon EMR などの AWS 分析サービスからアクセスできるようになります。統合の詳細は、 Using Amazon S3 with analytics services を参照してください。 1.2. テーブルバケット mytraveldata が作成されました。DuckDB のセットアップで後ほど使うため、コピーアイコンでテーブルバケットの Amazon リソースネーム (ARN) をコピーしておきます。 2. テーブルバケットに新しいテーブルを作成する 2.1. S3 コンソールで対象のバケットに移動し、 Create table with Athena を選択します。 2.2. テーブルバケット内に名前空間とテーブルを作成する Create table ワークフローで Namespace name を追加します。 続けて Create table with Athena に進みます。 SageMaker Lakehouse に nyc という名前のデータベースが作成されます。 2.3. Athena クエリエディタで、次の SQL コマンドを使ってテーブルを作成します。 CREATE TABLE nyc.nyc_trips (trip_id INT, pickup_datetime TIMESTAMP, dropoff_datetime TIMESTAMP, passenger_count INT, trip_distance DOUBLE, fare_amount DOUBLE, payment_type STRING, pickup_zone STRING) TBLPROPERTIES ( 'table_type'='ICEBERG' ); 3. S3 Tables にデータを挿入する ここでは、次の SQL コマンドを使い、ニューヨーク市のタクシー走行に関するサンプルデータを、作成済みのテーブルに挿入します。 INSERT INTO nyc.nyc_trips (trip_id, pickup_datetime, dropoff_datetime, passenger_count, trip_distance, fare_amount, payment_type, pickup_zone) VALUES (1, TIMESTAMP '2023-03-01 08:30:00', TIMESTAMP '2023-03-01 09:15:00', 2, 5.8, 22.50, 'Credit Card', 'Midtown'), (2, TIMESTAMP '2023-03-01 12:15:00', TIMESTAMP '2023-03-01 12:45:00', 1, 3.2, 15.00, 'Cash', 'Upper East Side'), (3, TIMESTAMP '2023-03-01 17:00:00', TIMESTAMP '2023-03-01 17:45:00', 3, 7.1, 28.75, 'Credit Card', 'Financial District'), (4, TIMESTAMP '2023-03-02 09:45:00', TIMESTAMP '2023-03-02 10:30:00', 1, 4.5, 18.25, 'Credit Card', 'Chelsea'), (5, TIMESTAMP '2023-03-02 14:30:00', TIMESTAMP '2023-03-02 15:15:00', 2, 6.3, 24.50, 'Cash', 'Greenwich Village'), (6, TIMESTAMP '2023-03-02 20:00:00', TIMESTAMP '2023-03-02 20:30:00', 4, 2.8, 14.75, 'Credit Card', 'Times Square'), (7, TIMESTAMP '2023-03-03 07:15:00', TIMESTAMP '2023-03-03 08:00:00', 1, 8.2, 32.00, 'Credit Card', 'Brooklyn Heights'), (8, TIMESTAMP '2023-03-03 11:30:00', TIMESTAMP '2023-03-03 12:15:00', 2, 5.5, 21.75, 'Cash', 'East Village'), (9, TIMESTAMP '2023-03-03 16:45:00', TIMESTAMP '2023-03-03 17:30:00', 3, 6.7, 26.25, 'Credit Card', 'SoHo'), (10, TIMESTAMP '2023-03-03 22:00:00', TIMESTAMP '2023-03-03 22:45:00', 1, 4.9, 19.50, 'Cash', 'Upper West Side'); この SQL コマンドを実行すると、データが nyc_trips テーブルに取り込まれます。 Part B: アクセス許可のセットアップ (オプション) 当該アカウントで AWS 分析サービスとテーブルバケットの統合を行ったユーザーとは別のユーザーの場合、テーブルに対する Lake Formation のアクセス許可を付与してもらう必要があります。詳細は Grant permission on a table or database を参照してください。本記事では、コンソール上で AWS 分析サービスとの統合を行った同じユーザーが、DuckDB インスタンス経由でテーブルにアクセスすることを前提とします。 Part C: DuckDB のセットアップ 1. DuckDB をインストールする DuckDB のインストールページ にアクセスし、最新の DuckDB Command line (執筆時点は v1.2.1) を入手します。 Installation セクションの curl コマンドをコピーします。 AWS マネジメントコンソールで CloudShell 環境に移動します。 次の curl コマンドを実行します。 curl https://install.duckdb.org | sh 次の図は curl コマンドの実行例です。 2. CloudShell インスタンスで DuckDB インスタンスを実行する DuckDB インスタンスを起動するには、AWS Command Line Interface (AWS CLI) で次のコマンドを入力します。 /home/cloudshell-user/.duckdb/cli/latest/duckdb 3. Iceberg 拡張機能をロードする S3 Tables の DuckDB サポートは、現時点では nightly 拡張ビルドの一部として提供されています。最新の Iceberg 拡張機能をインストールするには、次のコマンドを実行します。 FORCE INSTALL iceberg FROM core_nightly; ここまでで DuckDB インスタンスのセットアップは完了です。 4. AWS 認証情報を登録する AWS 認証情報を含むシークレットを作成します。CloudShell を使用している場合、これは AWS コンソールの認証情報にあたります。DuckDB はこのシークレットを使ってテーブルデータにアクセスします。設定オプションの詳細は DuckDB のドキュメント を参照してください。 CREATE SECRET (   TYPE S3,   PROVIDER credential_chain ); 5. カタログをデータベースとしてアタッチする ここでは、テーブルバケットをデータベースインスタンスとして DuckDB にアタッチします。 ATTACH '<account-id>:s3tablescatalog/mytraveldata' AS duck_db (TYPE ICEBERG, ENDPOINT_TYPE 'GLUE'); 6. テーブルバケットに格納されたデータにアクセスする 次のコマンドを使い、DuckDB がテーブルバケット内のテーブルを検出できることを確認します。 SHOW ALL TABLES; 結果から、 mytraveldata には nyc という名前空間が 1 つあり、その中に nyc_trips というテーブルが 1 つ存在することがわかります。以下はテーブルに格納されたデータを分析するサンプルクエリの例です。 6.1. テーブルに格納されたすべてのデータを表示します。 SELECT * from duck_db.nyc.nyc_trips 6.2. 支払い方法別の運賃合計を取得します。 SELECT payment_type, SUM(fare_amount) AS total_fare FROM duck_db.nyc.nyc_trips GROUP BY payment_type; 6.3. 2023 年 3 月 1 日の走行に対する運賃合計を取得します。 SELECT SUM(fare_amount) AS total_fare FROM duck_db.nyc.nyc_trips WHERE pickup_datetime BETWEEN '2023-03-01 00:00:00' AND '2023-03-01 23:59:59'; 本記事では、DuckDB インスタンスへの接続に Amazon SageMaker Lakehouse Iceberg REST エンドポイント を利用しました。もう 1 つの選択肢として、 S3 Tables Iceberg REST Catalog API で DuckDB に接続することもできます。この場合は、次の ATTACH コマンドを使用します。 ATTACH '<table-bucket-arn>' AS duck_db (TYPE ICEBERG, ENDPOINT_TYPE 'S3_Tables'); 1 つの S3 テーブルバケット内の表形式データに基本的な読み取りアクセスが必要な場合は S3 Tables Iceberg REST Catalog API を使い、すべての表形式データを対象とした統一的なデータ管理、データガバナンス、きめ細かなアクセス制御が必要な場合は S3 Tables を SageMaker Lakehouse と組み合わせて利用できます。 クリーンアップ リソースをクリーンアップするには、次の手順を実行してください。 S3 テーブルを 削除 する。 テーブルバケット内の名前空間を 削除 する。 S3 テーブルバケットを 削除 する。 まとめ 本記事では、Amazon SageMaker Lakehouse と AWS Lake Formation のアクセス許可を活用し、DuckDB で Amazon S3 上の Iceberg テーブルを読み取る方法を紹介しました。S3 テーブルバケットにテーブルを作成し、データを投入し、DuckDB クライアントからテーブルにアクセスする流れをウォークスルーしました。DuckDB と Amazon S3 Tables を組み合わせることで、小規模から大規模までのあらゆる環境で、追加のインフラなしにデータレイク内のテーブルを扱えます。 著者について Anupriti Warade Anupriti Warade は AWS の Amazon S3 チームで Senior Technical Product Manager を務めています。お客様のイノベーションと課題解決につながるソリューションの構築に情熱を注いでいます。ワシントン州シアトルを拠点に、家族や友人との時間、料理、DIY クラフトを楽しんでいます。 Yuri Zarubin Yuri Zarubin は AWS の Amazon S3 チームで Principal Engineer を務めています。データ保護を専門とし、S3 Replication のエキスパートです。現在は S3 Tables を Apache Iceberg テーブル向けにもっとも高性能なストレージソリューションとするための開発に取り組んでいます。余暇は旅行と、子どもと一緒に遊ぶ次の PC ゲーム探しを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2026 年 4 月 15 日 に公開された「 Get to insights faster using Notebooks in Amazon SageMaker Unified Studio 」を翻訳したものです。 本記事では、Amazon SageMaker Unified Studio のノートブックがインフラの設定を簡素化し、インサイト獲得までの時間を短縮する仕組みを紹介します。住宅価格データの分析、スケーラブルなデータテーブルの作成、分散プロファイリング、機械学習 (ML) モデルの学習を、単一のノートブック環境で行う流れをご覧いただけます。 データサイエンティストやアナリストは、分析を始めるまでにインフラ設定と複数データソースの認証管理に何日も費やすことがしばしばあります。Amazon Simple Storage Service (Amazon S3)、Amazon Redshift、Snowflake、ローカルファイルにまたがるデータを扱う場合、認証設定の繰り返し、コンピュートスケーリングの手動判断、ツール切り替えの手間が積み重なり、インサイト獲得が遅れます。 Amazon SageMaker Unified Studio のノートブックは、12 以上のデータソースへの即時アクセス、ローカルから分散処理までのコンピュートスケーリング、AI によるコード生成を、単一のブラウザベース環境で提供します。ポリグロットプログラミング、マルチエンジンコンピュート、AI 支援による開発を活用し、疑問からインサイトまでの道のりを短縮する方法を解説します。 Amazon SageMaker Unified Studio のノートブックとは Amazon SageMaker Unified Studio のノートブックは、データ分析、探索、エンジニアリング、機械学習ワークフローのためのインタラクティブな環境を提供します。統合された 5 つの機能を備えています。 ポリグロットプログラミング : 同じノートブック環境で Python と SQL を相互に切り替えながらコードを書けます 統合されたデータアクセス : Amazon S3、AWS Glue Data Catalog、Apache Iceberg テーブル、Snowflake や BigQuery などのサードパーティソースに保存されたデータへ即座に接続できます ネイティブな可視化 : Python や SQL の結果から直接チャートを作成し、没入感のあるデータ分析ができます AI による開発支援 : SageMaker Data Agent を通じて自然言語プロンプトでコードを生成できます。データ分析、データサイエンス、ML タスク向けの的確なチャットインターフェイスを備えています 柔軟なコンピュート : ニーズの拡大に応じて、基本的なインスタンスから GPU 搭載環境までスケールできます アーキテクチャ 本セクションでは、ノートブックのアーキテクチャを説明します。ノートブックは、複数のコンピュートエンジン、多様なデータソース、AI アシスタントを統合したクラウドネイティブアーキテクチャにより、ブラウザベースのシンプルさでエンタープライズ規模の分析を実現します。 プレゼンテーション層 Amazon SageMaker Unified Studio 経由でノートブックインターフェイスにアクセスします。コード実行用のコードセル、ドキュメント用のマークダウンセル、チャートやテーブル用の可視化セルを備えた、使い慣れたインターフェイスで操作できます。 コンピュート層 専用のノートブックサーバーがカーネルのライフサイクルとセッション状態を管理します。主要コンポーネントには、コード補完用の Language Server、データサイエンスライブラリをプリロードした Python 3.11 ランタイム、Python、PySpark、SQL の実行を同じノートブック内で処理する Polyglot Kernel が含まれます。作成した各ノートブックは、永続的な Amazon Elastic Block Store (Amazon EBS) ストレージにバックアップされます。 実行層 ノートブックは複数の実行エンジンをサポートし、コードを最適な処理エンジンに自動的にルーティングします。インメモリ実行は、小規模なデータセットや迅速なプロトタイピングを処理します。Amazon Athena 経由の Apache Spark は、Spark Connect を介した大規模分析向けの分散処理を提供します。Amazon Athena (Trino)、Amazon Redshift、Snowflake、BigQuery へのネイティブ接続により、SQL クエリを処理します。 データ統合 AWS ネイティブ (Amazon S3、AWS Glue、Amazon Athena、Amazon Redshift) とサードパーティ (Snowflake、BigQuery、PostgreSQL、MySQL) を含む 12 以上のデータソースに統一的にアクセスできます。サポートされている最新のデータソースについては、 Connect to data sources を参照してください。 AI 層 SageMaker Data Agent は、2 つのモードで利用できます。複数ステップの分析ワークフロー向けの Agent Panel と、セル単位のコード生成に特化した Inline Assistance です。詳細は Accelerate context-aware data analysis and ML workflows with Amazon SageMaker Data Agent を参照してください。 作業を保護するため、セキュリティはアーキテクチャ全体に組み込まれています。データアクセスは AWS Identity and Access Management (AWS IAM) の権限に従います。ノートブックとエージェントは、利用が許可されたデータソースにのみアクセスできます。コンポーネント間の通信は暗号化チャネルを使用し、ノートブックのストレージは保存時に暗号化されます。AI エージェントには、破壊的な操作を防ぐガードレールが組み込まれており、コンプライアンスと監査のためにやり取りをログに記録します。 前提条件 始める前に、以下が必要です。 Amazon SageMaker Unified Studio のリソースを作成する権限を持つ AWS アカウント。必要な権限の詳細は、 Set up IAM-based domains を参照してください。 Python プログラミングと SQL クエリの基本的な知識 データ分析の概念と ML ワークフローの理解 サンプルの住宅データセットへのアクセス (ウォークスルー内で提供) ノートブックを使い始める まず、 Amazon SageMaker コンソール を開き、 Get started を選択します。 データとコンピュートへのアクセス権を持つ既存の AWS Identity and Access Management (AWS IAM) ロールを選択するか、新規ロールを作成するかを求められます。本ウォークスルーでは、 Create a new role を選択し、他のオプションはデフォルトのままにします。 Set up を選択します。環境の準備には数分かかります。 ユースケース 本記事では、ノートブックと SageMaker Data Agent を使って以下を実行します。 データセットの操作: サンプルデータセット housing.csv をアップロードし、データエクスプローラーで探索 ポリグロットプログラミング: DuckDB 経由で SQL によるデータフレームのクエリ AWS Glue によるマルチエンジンアクセス: AWS Glue テーブルを作成し、Athena SQL/Spark エンジンで分散処理を実行 高度な分析: Athena Spark でデータプロファイリング AI 支援による開発: Data Agent でプロファイリングと ML のコードを生成 ML ワークフロー: Random Forest モデルを学習し、結果を評価 まずインターフェイスを見て、コア機能を確認しましょう。 インターフェイスの理解 ノートブックのインターフェイスは、コード実行用のセルとドキュメント用のマークダウンという、使い慣れたノートブック規約に従っています。ノートブック内では、現在のプログラミング環境 (Python 3.11 など) とコンピュートプロファイルの仕様を確認できます。このインターフェイスでは以下ができます。 ファイルの参照、データカタログの探索、サードパーティ接続の管理を通じてデータにアクセス ノートブックのコンテキスト内で作成された変数を監視 ワークロード要件に応じて仮想 CPU と RAM を調整し、GPU インスタンスまでオンデマンドでコンピュートリソースをスケール Python パッケージを必要に応じてインストールおよび設定してパッケージを管理 データセットの操作 本ウォークスルーでは、 このページ からダウンロードできる housing.csv サンプルデータセットを使用します (リンク先ではファイル名が canvas-sample-housing.csv になっています)。左パネルの Files アイコンを選択し、 Local タブを選択します。 Local タブでノートブックに CSV ファイルをアップロードします。 ノートブックはデータ資産への即時アクセスを提供します。データエクスプローラーを使えば、AWS Glue Data Catalog、Amazon S3 テーブルカタログ、Amazon S3 バケット、設定済みのサードパーティ接続を参照できます。 3 点リーダーのオプションメニューを選択します。 Read as dataframe を選択し、ノートブックに挿入されたセルを実行して結果を確認します。 import pandas as pd <<df_csv_xxxx>> = pd.read_csv('housing.csv') <<df_csv_xxxx>> データフレームを返すと、ノートブックは自動的なデータプロファイリングを備えたリッチなテーブル形式で表示します。 ポリグロットプログラミング: Python と SQL を同時に ノートブックのもっとも強力な機能の 1 つが、Python と SQL の相互運用性です。データを Python のデータフレームに読み込んだ後、すぐに SQL でクエリできます。たとえば、海への近さ別に人口と世帯数の合計を計算するには、次のように実行します。 select sum(population) ,sum(households),ocean_proximity from<<df_csv_xxxx>> group byocean_proximity ノートブックのオートコンプリート機能はコンテキスト内のデータフレームを認識するため、SQL クエリを直感的に書けます。 この SQL クエリは DuckDB (インメモリの SQL データベースエンジン) 上で実行され、個別のインストールやサーバー保守は不要です。DuckDB は軽量な設計で、Python、Java、その他の環境に組み込めるため、迅速な対話型データ分析に適しています。分散処理が必要な場合は、データセット用の AWS Glue テーブルを作成した後、Apache Spark や Trino などのエンジンを使用できます。 データセット用の AWS Glue テーブルを作成する AWS Glue テーブルを作成すると、Amazon Athena SQL (Trino) や Amazon Athena Spark など、AWS Glue カタログ対応のさまざまなエンジンでデータセットをクエリできます。これらのエンジンは、それぞれのワークロード要件に対して最適な価格性能比を提供します。 まず AWS Glue データベースを作成します。ノートブックで新しいセルを作成するために SQL を選択し、 Amazon Athena (SQL) を選びます。 次の SQL を実行してデータベースを作成します: create database demo; 次に、データエクスプローラーに移動し、左上の +Add を選択して Create table を選びます。先ほど作成したデータベースを選択し、テーブル名を入力します。先ほど使用した housing.csv データセットファイルをアップロードします。サイドパネルで Next を選択して、テーブルを作成します。 次に、Amazon Athena SQL を使って新しいセルでサンプル SQL クエリを実行してみましょう。 select sum(population) , sum(households), ocean_proximity fromdemo.housing group by ocean_proximity Athena Spark による高度な機能 住宅価格を予測する ML モデルを構築する前に、データセットをさらに分析し、追加のインサイトを得るためにデータプロファイリングを実行しましょう。高度な探索には、ノートブック内で Amazon Athena Spark を使用できます。そのために、組み込みの Spark セッションを持つ新しい Python セルを作成します。次のコードを実行して Spark のバージョンを確認します。 # Verify Spark version spark.version SageMaker Data Agent によるデータプロファイリング 定型的なコードを手動で書く代わりに、組み込みの生成 AI 機能を活用できます。 プロンプト : 「Perform data profiling and create visualization for housing table」 AI アシスタントは、基本統計の算出、列単位のプロファイリング、データ型の分析、欠損値の検出を含む、包括的なプロファイリングコードを生成します。 エージェントは AWS Glue Data Catalog にアクセスし、housing テーブルの構造を把握したうえで、対象の列とデータ型に合わせたプロファイリングコードを生成しました。この文脈認識により、汎用的なコードスニペットを自環境向けに調整する際にありがちな試行錯誤が減ります。生成されたコードを確認して実行します。応答が速いため、分析を効率的に反復できます。 エラーが発生した場合は、次の図のように Fix with AI で解決できます。実行時にエラーが発生すると、 Fix with AI 機能がトレースバックを分析し、根本原因を診断して修正済みコードを生成するため、分析を止めずに進められます。 ML モデルの学習 次に、Data Agent を使って住宅価格を予測するモデルの学習コードを生成します。 プロンプト: 「Generate code to train a model that predicts housing prices. Use table housing.」 AI アシスタントは、次のようなエンドツーエンドのコードを生成します。 Amazon Athena Spark を使って AWS Glue カタログから住宅データを読み込み、pandas に変換 文字列型の列を数値化し、One-Hot エンコーディングでエンコードし、欠損値を除去 Random Forest モデルを学習して住宅価格の中央値を予測 モデル性能を評価 (RMSE、MAE、R-square) 予測に対する重要度が高い上位 10 個の特徴量を表示 この複数ステップのオーケストレーションにより、データアクセスからモデル評価までのワークフロー全体を任せられ、開発時間を数時間短縮できます。 エラーが発生した場合は、結果のトレースバックセクションにある Fix with AI で解決できます。 このワークフローでは、ノートブックの統合機能を紹介しました。ローカルからファイルをアップロードし、マルチエンジンアクセス用に AWS Glue テーブルを作成し、Amazon Athena Spark で分散プロファイリングを実行し、AI 支援による ML 開発で住宅価格を予測しました。これらすべてを、ツールを切り替えずに 1 つのノートブック環境で行いました。 主なメリットとベストプラクティス Amazon SageMaker Unified Studio のノートブックには、いくつかの利点があります。 インサイト獲得までの時間短縮 : 従来の環境では、分析を始める前に設定に数時間かかることもあります。ノートブックはこうした負荷を回避し、すぐに作業を始められます。 コラボレーションの向上 : 一貫した環境でノートブックを共有でき、再現性が確保され、「自分の環境では動く」問題が減ります。 複雑性の低減 : データソースや処理エンジンごとに別々のツールを使い分けるのではなく、複数のデータソースとコンピュートエンジンに 1 つのインターフェイスからアクセスできます。 AI による開発の加速 : タスク特化型のコードを生成し、的確な提案を受けられるため、繰り返しのコーディング作業にかかる時間を減らせます。 スケーラブルな性能 : メガバイトからペタバイト規模のデータセットを、適切なコンピュートリソースで処理できます。データ量の増加に応じてシステムが自動的にスケールします。 ベストプラクティス まずは小さめのインスタンスから始め、ニーズの拡大に合わせてスケールアップする形で、適切な コンピュートプロファイル で開始する。 繰り返し作業や複雑な操作には、自然言語プロンプトで AI アシスタントを活用する 。 大規模処理には Amazon Athena Spark、データウェアハウスには Amazon Redshift、その他特定のワークロードには専用エンジンを使うなど、 エンジンを戦略的に組み合わせる 。 マークダウンセルを使い、コードと並行して 作業内容を文書化する ことで、生きたドキュメントを作る。 複雑なワークフローを論理的なステップに分割し、 複数のセルで整理する ことで、可読性とデバッグ性を高める。 クリーンアップ 今後の課金を避けるため、本ウォークスルーで作成したリソースを削除します。 Amazon SageMaker Unified Studio コンソールで、Notebook ページに移動する ノートブックを削除する AWS Glue Data Catalog から demo データベースと housing テーブルを削除する 本ウォークスルーで作成した Amazon SageMaker Unified Studio ドメインを削除する 本ウォークスルー用に新しい IAM ロールを作成した場合は、IAM コンソールから削除する まとめ 本記事では、Amazon SageMaker Unified Studio のノートブックが作業効率を高め、インサイトをより速く提供する仕組みを紹介しました。使い慣れたノートブックインターフェイスに、エンタープライズ規模のコンピュート、マルチエンジンサポート、生成 AI 支援を組み合わせることで、チームはデータと AI のワークフローを効率化できます。 Python と SQL の統合、多様なデータソースへの即時アクセス、的確なコード生成機能により、ノートブックは現代のデータチームにとって価値あるツールになります。探索的データ分析、複雑なデータパイプラインの構築、ML モデルの学習を、単一の直感的な環境で必要な柔軟性とパワーを備えて実行できます。 使い始める準備はできましたか? Amazon SageMaker Unified Studio で最初のノートブックを作成 し、数分でデータ分析を始めましょう。 追加機能を探る: 季節分解と予測を用いた時系列分析ワークフロー テキスト分類や感情分析のための自然言語処理パイプライン ML モデルのバージョン管理のための Amazon SageMaker Model Registry との統合 ペタバイト規模の処理に対応する高度な Spark 最適化手法 詳細情報: Amazon SageMaker Unified Studio Administrator Guide Amazon SageMaker Unified Studio User Guide Notebooks in SageMaker Unified Studio Use the SageMaker Data Agent Pricing information 著者について Praveen Kumar Praveen Kumar は AWS の Principal Analytics Solutions Architect で、クラウドベースのサービスを用いた最新のデータおよび分析アプリケーションの設計、構築、実装に精通しています。関心領域はサーバーレステクノロジー、データガバナンス、データドリブンな AI アプリケーションです。 Majisha Namath Parambath Majisha Namath Parambath は Amazon SageMaker の Principal Engineer で、AWS で 10 年以上の経験を積んでいます。エージェント型システムを重視した包括的なデータ分析とインタラクティブな機械学習機能を提供する次世代サービス、Amazon SageMaker Unified Studio の重要な取り組みを主導しています。専門はシステム設計、アーキテクチャ、部門横断の実行で、エンタープライズ規模でのセキュリティ、パフォーマンス、信頼性に注力しています。エンジニアリング以外では、読書、料理、スキーを楽しんでいます。 Siddharth Gupta Siddharth Gupta は SageMaker の Unified Experiences で生成 AI を率いており、AI システムが複雑なタスクをユーザーに代わって自律的に実行する、エージェント型体験の推進に注力しています。以前は AWS でエッジ機械学習ソリューションを率いていました。彼の仕事は、開発者やデータサイエンティストが AI とやり取りする方法の改善、より直感的なデータ統合の実現、機械学習モデルを構築・デプロイするためのより良いツール作りに焦点を当てています。University of Illinois at Urbana-Champaign 出身で、Yahoo、Glassdoor、Twitch で豊富な経験を積んでいます。 LinkedIn で連絡できます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。