2026/4/20 – 4/24 に世界最大規模の産業向け展示会ハノーバーメッセが開催されました。AWS は今年も “Built for Industrial AI” というテーマを掲げ、フィジカル AI を筆頭に、AI とクラウドを活用し製造業の業務を変革するアイディアを提供しました。AWS の製造のリーダーである Ozgur Tohumcu から、”産業 AI は大規模展開してこそ意味がある”というメッセージを基調講演で語りました。イベント全体での AWS の活動は、別途 月刊 AWS 製造ブログ でもご紹介しています。このブログでは AWS ブースの概要と展示ソリューションについてご紹介します。 AWS の展示ブース AWS は “Built for Industrial AI” を体現するブースとして「スマート生産」「サプライチェーン」と「製品設計・開発」「スマートプロダクト」の４領域を２つに分けて展示しました。フィジカル AI やシミュレーションへの注目により製品開発系の展示が大きく増えています。 今年度も昨年同様、SIEMENS, QAD, Zoomilion といった様々な業界パートナーが AWS ブース内で展示を行うとともに、AWS 自身の展示を大きく増やしました。本年も、日本チームが現地で日本語でお客様をご案内しました。 本ブログでは、フィジカル AI と主要な４領域の展示についてご紹介します。 フィジカル AI 写真: フィジカル AI デモ “AI-Driven Product Journey” フィジカル AI は本年 AWS ブースで最も注目を集めたエリアの一つで、来場者の足が絶えない人気を博していました。目玉となったのが、”AI-Driven Product Journey” と題された大型デモです。このデモは、来場者がキオスク端末でデザインを選択・入力すると、生成 AI がオリジナルデザインを生成し、AMR(自律走行ロボット)・協働ロボットアーム・レーザー彫刻機・AI 画像検査装置・ヒューマノイドロボットが協調しながら金属製コースターを製造、最終的にヒューマノイドが完成品を来場者に手渡すという一連のプロダクトジャーニーを実演するものです。AMR が LiDAR で周囲を知覚し自律走行する、ロボットアームが 3D ビジョンで部材を認識し把持する、ヒューマノイドが強化学習で獲得した歩行で物を運ぶなど、それぞれが物理世界を知覚・理解し、直接作用するという フィジカル AI の異なる側面を体現しており、フィジカル AI が役割分担して働く姿を一望できる構成になっています。 写真: エージェント AI による工程のオーケストレーション 本デモのもう一つの注目点は、工程全体を エージェント AI が自律的にオーケストレーションしている点です。各装置・ロボットの操作がツールとして定義され、エージェント AI が状況をリアルタイムに判断しながら全工程を指揮します。事前にハードコードされたシナリオをなぞるだけではなく、状況に応じて柔軟に振る舞える点が従来の産業オートメーションとの大きな違いであり、産業 AI を実運用へスケールさせていく上での重要なステップを示すデモとなっていました。 スマート生産 (Smart Manufacturing) Smart Manufacturing エリアは今年も AWS ブースの中で最も広いスペースが割かれており、上記の AI-Driven Product Journey を中心に多くの来場者で賑わっていました。また Rockwell Automation、HighByte、Databricks、Snowflake、Palantir といったパートナー各社との協業展示が目立ち、AWS 単独ではなくエコシステム全体でスマート製造を実現するという姿勢が強く打ち出されていました。技術面では AI エージェントが自律的に複数システムを横断して分析・判断を行うアーキテクチャが前面に出てきたのが昨年からの大きな変化です。ここではその中から、Agentic Workflow Automation と Real-Time Plant Analytics の 2 つのデモをご紹介します。 写真: Agentic Workflow Automation — AI エージェントが製造現場の意思決定を自律支援する内容のデモ Amazon Bedrock AgentCore を基盤に、複数の AI エージェントが MES・ERP・CMMS・IoT を横断して製造データを分析するデモです。「3 工場の生産実績とオーダー目標を比較してほしい」「納期リスクのある顧客オーダーはどれか」といった質問を自然言語で投げかけると、エージェントがグラフデータベースの関係性を元に複数システムからデータを取得し、レポートを自動生成します。エージェントの推論過程がステップごとにリアルタイム表示される “Investigation Trace” 機能もあり、AI がどのデータソースにアクセスしてどう判断したかが透明に追跡できる点が印象的でした。 写真: Real-Time Plant Analytics — 工場 KPI（OEE、不良率等）のリアルタイム監視と、AI によるシフト交代レポートの自動生成デモ Amazon Quick を基盤とした Manufacturing Dashboard の展示です。Overview 画面では OEE や Defect Rate、First Pass Yield といった主要 KPI がリアルタイムで一覧表示されます。中でも注目したいのが Shift Handoff Report 機能で、シフト交代時に AI がワークセンター別の OEE・欠陥分布・保全状況を自動分析し、引き継ぎレポートを生成します。画面右側には Manufacturing Assistant チャットも統合されており、レポートの内容を対話形式でさらに深掘りすることも可能です。 サプライチェーン (Supply Chain) 写真：Supply Chain のデモ 今年も AWS ブース内の他のデモと連携した、Supply Chain のデモをご紹介しました。昨年も同じ AWS ブース内にある製造デモと情報連携し、Supply Chain に関わる情報の可視化や需要予測などを展示しておりましたが、昨年からの大きな変更点として、今回は Kiro で開発したアプリケーションを展示させていただきました。 業務仕様書とデータの構成を元にアプリケーションを自動生成することで、企業におけるカスタムアプリケーション導入/利用の柔軟性を上げ、開発/導入の時間および難易度を下げていく例をご紹介しました。また、同ブース内では、パートナー企業である QAD の ERP・Redzone の展示や、会期中には、こちらもパートナー企業である Infor が製造業における エージェント AI の活用に関する協業の発表を行い、パッケージアプリケーションとカスタムアプリケーションを選択していただく、または組み合わせて利用するといった、お客様の状況に合わせて選択していただける選択肢を AWS が提供している様子をお伝えしました。 製品設計・開発 (Product Engineering) 今回、フィジカル AI の注目により製品設計・開発領域の内容を大きく増やしました。Engineering & Development Tunnel という展示では、AI によるデザインの提案 –> エンジニアリングツールを仮想化 –> デジタルスレッドで設計開発データの連携 –> AI によるパラメータ空間探索(サロゲートモデル)という流れをご紹介しました。AI ( Amazon Nova ) が提案した意匠は、Smart Manufacturing のデモに連携され、レーザー加工によりコースターとして生産されます。 製品設計に必要な様々なエンジニアリングツールを仮想化する例として、 PTC の CAD (Creo) と、開発中の CAD へのアドバイスを行う紹介がありました。全体に、Engineering Development Hub (EDH) という新しいエンジニアリング環境が使われ、様々な CAD/CAE の環境を仮想化し、呼び出し、管理し、VDI で接続することで計算リソースやワークステーションを柔軟に増減させ管理の手間を減らすことができる様をご紹介しました。 写真：Engineering & Development Tunnel (左) と Creo のデモ (右) 設計されたデータはシミュレーションにより性能を検証しますが、設計パラメータを変更して都度シミュレーションを行うとそのための計算量やコストも膨大になります。そこで、過去のシミュレーション結果から異なる設計パラメータのシミュレーション結果を AI で予測する手法がサロゲートモデルです。パートナーの Neural Concept との共同展示で、データセンターの冷却を題材としたパラメータスタディを行うデモを展示しました。 SIEMENS との共同展示では、設計データから強度シミュレーションを行い、その結果を元に生成 AI に設計改善のアドバイスをさせるデモが示されました。また、“OT Modernization” という展示では、シミュレーションを製品開発だけではなく生産設備のエンジニアリングに活用し、生産ラインにおけるアームロボットの動作を生成 AI で最適化してタクトタイムを縮めるという提案を行いました。 写真：SIEMENS との共同展示 (左) と OT Modernization の展示 (右) 他にも、CAD の展示として完全クラウドベースのアーキテクチャにより無限 Undo や PDM の統合を可能にし、オペレーションを中間言語で記述することで AI による支援を容易にするといった意欲的な機能を搭載した PTC の Onshape が紹介されました。 スマートプロダクト (Smart Products & Services) 今年のスマートプロダクトエリアのトレンドは、「売って終わり」から「売った後も継続改善」への転換が現実的になってきたことです。開発面では、AI エージェントが設計からリリースまで全フェーズに介入し、組み込みソフトの開発サイクルを劇的に短縮。出荷後も迅速にアップデートを続けられる体制が整いつつあります。サービス面では、テレメトリ・保守履歴・顧客問い合わせなど複数データソースを AI が統合解析し、故障予兆検知やプロアクティブなサポートを実現。予防保守サブスクやリモート診断など新収益ストリームの創出と顧客関係強化につながっています。スマートプロダクトでも DevOps の継続改善サイクルが回せる時代に入った — これが今年最大の変化です。この記事では、”Accelerate embedded software development and equipment” と “Smart Products Telemetry Driven ‘X'”の 2 デモをご紹介します。 写真: Accelerate embedded software development and equipment — 組み込みソフトウェア開発の課題を示すスライドと、Kiro が 30 分以内で実装した 空調管理システム UI の実機（右下） Kiro （AI 駆動 IDE）による組み込みソフト開発ライフサイクル全体の加速デモです。空調管理システム（C++ で実装/ 7 インチ HMI 画面）を題材に、Research・Plan・Development・Release の 4 フェーズを一気通貫で実演します。注目すべきは、画像右下の空調管理システム実装において、リモートデバッグ・UI チェック・デプロイをすべて Kiro が自律実行し、30 分以内で完了させている点です。従来 1 週間以上かかる作業が、コード生成→デプロイ→スクリーンショット評価→改善のフィードバックループで劇的に短縮されています。 デモの内容を体験できるワークショップ も公開されています。 写真: Smart Products Telemetry Driven “X” — デバイス障害検知時に Amazon Connect へリアルタイムのテレメトリとアラートが自動連携される様子 AWS IoT Core と Amazon Connect を組み合わせたサービス改善の展示です。産業機器（デモでは 3D プリンター）のテレメトリをリアルタイム収集・監視し、エラー発生時にはデバイスデータがサポートエージェントに自動連携されます。顧客にシリアル番号や症状を確認する手間なく即座に問題解決に着手できます。AI エージェントが解決できない場合は自動でタスク生成し、熟練技術者や専門 AI エージェントへエスカレーションする仕組みも備えています。 まとめ 本年のハノーバーメッセでは、”Built for Industrial AI” のテーマのもと、フィジカル AI と エージェント AI が製造業のバリューチェーン全体に広がりつつある姿が印象的でした。生成 AI による意匠提案から エージェント AI による工程オーケストレーション、ロボットによる物理世界での実行までが一つのシナリオで繋がる “AI-Driven Product Journey” は、その象徴的な事例です。Smart Manufacturing・Supply Chain・Product Engineering・Smart Product の各領域でも、AI エージェントが複数システムを横断して人の意思決定を支援するアーキテクチャが共通の方向性となりつつあり、産業 AI が実証から実運用フェーズへ着実に進みつつあることを感じる場となりました。AWS は引き続き、産業 AI を実運用にスケールさせていくお客様の取り組みを支援してまいります。 なお、6 月 25, 26 日に開催される AWS Summit Japan 2026 でも フィジカル AI や産業 AI の展示をご用意しています。Summit 向けに企画した新たなデモを通じて、製造業における AI の可能性を体感いただけます。ぜひご登録のうえ、会場でお会いできれば幸いです。 AWS Summit Japan 2026 の登録は こちら 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI エージェントと毎日戯れており、AI エージェント無しでは生きていけなくなっています。好きなうどんは’かけ’です。

はじめに 本ブログは、株式会社丸千代山岡家と Fivetran Japan、Amazon Web Services Japan が共同で執筆しました。 みなさま、こんにちは。AWS ソリューションアーキテクトの大久保です。 昨今、Apache Iceberg を利用したレイクハウスアーキテクチャが AWS の Analytics ワークロードの中心となりつつあります。Iceberg テーブルを分析基盤の核に据える構成が広がる一方で、「データベースからどのように Iceberg テーブルにデータを連携するか」――この”データを投入するコンポーネント”の選定に悩まれている方も多いのではないでしょうか。特に、基幹データベースの変更をタイムリーに反映したい場合、 CDC（Change Data Capture） が有力な選択肢となります。CDC とは、データベースに対する変更（INSERT / UPDATE / DELETE）をリアルタイムまたはニアリアルタイムに検知・取得する手法です。従来のバッチ処理のようにテーブル全体を定期的にコピーするのではなく、変更差分のみを効率的に転送できるため、データの鮮度と転送効率を両立できます。しかし、実際に CDC パイプラインを構築しようとすると、複数サービスを組み合わせた運用負荷など、想定以上のハードルに直面することも少なくありません。 本記事では、ラーメンチェーン「山岡家」を展開する 株式会社丸千代山岡家 （以下、山岡家）が、Fivetran の CDC 機能を活用して Oracle から Amazon S3 上の Iceberg テーブルへのデータ同期を実現した事例をご紹介します。アーキテクチャの検討プロセスから Fivetran 導入後の効果まで解説しますので、同様の構成を検討されている方の参考になれば幸いです。 図 1：山岡家オリジナル看板ロゴ T シャツ。「ラーメンはスープが命。データは鮮度が命。」 山岡家のデータ活用と今回の課題 山岡家では、データ活用による経営の最適化に積極的に取り組んでいます。具体的には、以下のような取り組みを進めています。 仕入れ量の最適化 ：各店舗の売上・仕入れデータの分析による適正発注 人員配置の効率化 ：来客予測に基づくシフト最適化 キャッシュロジスティックスの最適化 ：店舗内現金の金種別増減予測 現金管理の差異分析 ：店舗ごとの現金過不足の検知・分析 これらのデータ活用を支える基盤として、Snowflake を中核に据え、AWS サービスと組み合わせたデータパイプラインを構築しています。Snowflake は分析・クエリだけでなく、パイプラインのオーケストレーション（タスク完了検知等）も担っており、データ基盤全体の中核的な役割を果たしています。 会計仕訳データのリアルタイム連携 こうしたデータ基盤をさらに発展させるにあたり、今回取り組んだのが 会計仕訳データのリアルタイム連携です。会計仕訳データは、現金管理の差異分析を含む幅広い用途で活用しています。現状は会計データを直接 BI に接続していますが、BI 層を分離し、データレイク経由での参照に移行することで、会計データを SSOT（Single Source of Truth）として一元管理したいと考えています。 今回の具体的な課題は Amazon RDS for Oracle 上の会計仕訳データを、ニアリアルタイム（数分間隔）で S3 上の Iceberg テーブルに同期し、 Snowflake からクエリ できるようにすること でした。このデータ連携の方式として CDC を採用した理由は以下の通りです。 ニアリアルタイムの反映が必要 ：店舗の現金出納データを BI で社内公開しており、数分単位でのデータ反映が求められていた 差分同期が必要 ：会計仕訳データは日々の入力に加えて過去データの修正・削除も発生するため、INSERT だけでなく UPDATE・DELETE を含むテーブル同期が必要だった 構築したアーキテクチャ この課題に対し、Fivetran の CDC 機能を採用して以下のアーキテクチャを構築しました。 図 2：RDS for Oracle から S3 Iceberg への CDC パイプラインアーキテクチャ Fivetran が RDS for Oracle から変更データを取得し、S3 上に Iceberg 形式で書き込みます。データカタログは Fivetran が管理する Polaris Catalog を利用しており、Snowflake はこのカタログを参照して S3 上の Iceberg テーブルを認識します。Tableau は Snowflake 経由でデータにアクセスする構成です。 以降のセクションでは、この構成に至った経緯と Fivetran を選択した理由、データの流れの詳細を解説します。 Fivetran の採用 検討した構成 当初は AWS のサービスを組み合わせた構成も検討しましたが、それぞれ課題がありました。 ストリーミング CDC（  AWS Database Migration Service → Amazon Kinesis Data Streams → Amazon Data Firehose → Amazon S3 ） ：DMS の CDC 機能自体は実績のある手法だが、今回の構成では DMS に加えて Kinesis Data Streams、Data Firehose、S3 と 4 つのサービスを組み合わせる必要があり、それぞれの設定・監視・障害対応を含めた運用負荷が課題だった。また、DMS の定期的なバージョンアップに伴うダウンタイムへの対応も継続運用上の考慮点だった バッチ ETL ：ニアリアルタイムでのデータ反映という要件を満たせなかった よりシンプルかつリアルタイム性を両立できる構成を模索する中で、Fivetran の CDC 機能に着目しました。 Fivetran とは Fivetran は、データの収集・転送を自動化するマネージドデータパイプラインサービスです。700 以上のデータソースに対応しており、ノーコードでデータパイプラインを構築できます。詳細は Fivetran 公式サイト をご参照ください。 図 3：Fivetran の全体像 — 多様なデータソースから Data Warehouse・Data Lake への連携を自動化する（出典: Fivetran） Fivetran の CDC 機能 は、ソースデータベースの変更（INSERT / UPDATE / DELETE）やスキーマの変更を検知し、ターゲットシステムへ自動的に反映します。Oracle を含む主要な RDB に対応しており、インフラの構築・管理なしに CDC パイプラインを実現できる点が特徴です。 Fivetran を選択した理由 山岡家が Fivetran を選択した背景には、以下のポイントがありました。 Oracle CDC の運用複雑性を吸収できる ：Oracle の CDC は、アーカイブログの管理や補足ロギングの設定など、他の RDB と比較して実装の複雑さが高い。Fivetran は Binary Log Reader 方式 でこれらを吸収し、Oracle 固有の設定を深く意識することなく CDC パイプラインを構築できる Iceberg 形式での書き込みと Snowflake と直接連携できる Polaris Catalog を提供している ：S3 に Iceberg 形式でデータを書き込み、カタログでメタデータを管理できる 複数データソースを統合管理できる ：Oracle の CDC だけでなく SmartHR 等の SaaS からの API 連携も同一プラットフォームで管理でき、データ基盤全体の統一性が向上する 運用コンポーネントが少ない ：SaaS として提供されるため、前述のストリーミング CDC 構成のように複数サービスの設定・監視・障害対応を個別に行う必要がない 山岡家では、本来単純な EL（Extract / Load）処理に社内リソースを割くのではなく、データ活用そのものに注力したいという背景がありました。データベースから Iceberg へ低い運用コストでニアリアルタイムに CDC が可能な Fivetran を選定し、短期間で目的を達成できました。 データの流れ 本記事で解説する CDC パイプラインのデータの流れは以下の通りです。 ソースからのデータキャプチャ ： Fivetran が Binary Log Reader 方式で RDS for Oracle の変更情報を取得し 、INSERT・UPDATE・DELETE の変更を検知します。初回実行時にはフルロードが行われ、以降は差分のみが転送されます。SmartHR からは API 経由で人事データを取得します（こちらは CDC ではなく API ポーリング）。 初回フルロードから差分同期への切り替えを含む具体的なセットアップ手順については「 Fivetran の Managed Data Lake Service の CDC で実現する業務システムから Apache Iceberg へのリアルタイムデータ連携 」をご参照ください Iceberg 形式での S3 書き込み ：キャプチャした変更データを Apache Iceberg 形式で Amazon S3 に書き込みます。データファイル（Parquet）とメタデータが S3 上に格納されます カタログでのメタデータ管理 ：Polaris Catalog に Iceberg テーブルのメタデータ（スキーマ情報、スナップショット履歴、パーティション情報など）が登録されます。分析エンジンはカタログを参照するだけでテーブルの構造と最新の状態を把握できます Snowflake からの分析クエリ ：Snowflake は Polaris Catalog を参照し、S3 上の Iceberg テーブルを Iceberg Tables として認識します。Fivetran が新しいデータを書き込むたびに Snowflake 側のテーブル情報が自動更新され、常に最新のデータに対してクエリを実行できます なお、CDC はデータ同期だけでなく、Snowflake 上の仕訳連携タスクの完了検知トリガーとしても活用しており、データ同期とパイプライン制御を一つの仕組みで兼ねています。 なお、S3 Tables ではなく S3 Standard を採用しています。これは、Fivetran の Iceberg 連携に必須となる Fivetran 管理の Polaris Catalog が、執筆時点で S3 Tables との統合に対応していないためです。S3 Tables の利用を検討される場合はこの点にご留意ください。 Fivetran 導入の効果 実際に Fivetran を導入した結果、山岡家が実感している効果は以下の通りです。 環境維持の負荷が低い 山岡家が最も評価しているポイントの一つです。維持すべきものは S3 バケットと Fivetran のデータカタログ環境のみであり、複数コンポーネントの監視・障害対応・バージョン管理が不要です。データエンジニアリングに専任チームを置かない組織でも無理なく運用できる構成になっています。 データ反映のレイテンシ Fivetran の CDC 機能により、会計仕訳データの変更が 約 5 分 で S3 上の Iceberg テーブルに反映され、Snowflake からクエリ可能になります。日々の仕訳入力から分析可能になるまでのタイムラグが大幅に短縮され、よりタイムリーな経営判断が可能になりました。 運用工数の大幅削減 Fivetran 導入後、データパイプラインの運用工数は月あたり約 0.5 日にまで削減されました。導入前は月あたり約 6 日の運用工数が発生していましたが、SaaS としてコンポーネントの監視・障害対応・バージョン管理が抽象化されたことで大幅に削減されています。 複数データソースの一元管理 Oracle の会計仕訳データ（CDC）に加えて SmartHR の人事データ（API 連携）も Fivetran 経由で連携しており、データ取得方式が異なるソースでも同一プラットフォームでデータパイプラインを管理できています。データソースが増えても Fivetran 上でコネクタを追加するだけで済むため、データ基盤の拡張が容易です。 ワークロードの規模感 採用を検討されている方の参考として、本パイプラインのワークロード規模を記載します。 # 項目 値 1 月間レコード数 約 20 万行 2 月間データサイズ 約 2 GB 3 日次平均レコード数 約 7,000 行 4 日次平均データサイズ 約 70 MB 5 ピーク（月初） 約 7,000 件 / 5 分 通常時は比較的少量のデータが継続的に連携されますが、月初の会計締め処理時にはバースト的にデータ量が増加します。Fivetran はこのようなピーク時にも安定して動作しており、レイテンシの悪化やエラーは発生していません。 今後の展望 今回の Fivetran CDC パイプラインは、山岡家のデータ基盤を発展させるための第一歩です。今後は既存の Snowflake 基盤を活かしつつ Iceberg の適用範囲を広げ、定型データがほぼすべて可視化された状態を目指していきます。 データ基盤の方向性：Snowflake + S3 Iceberg の併用 現状は Snowflake Internal Tables にデータを直接格納するケースが多くありますが、長期的にはデータ入力等にかかるコストとオープン性を見据え、活用できる箇所には Amazon S3 上の Apache Iceberg テーブルを採用していく方針です。Iceberg を採用する理由は主に 3 つあります。 Snowflake とのネイティブ連携 ：Snowflake が Iceberg テーブルをネイティブに参照できるため、既存の分析基盤との親和性が高い オープンフォーマットの拡張性 ：特定のエンジンにロックインされず、将来的に用途に応じた分析ツールを選択できる 運用の柔軟性 ：タイムトラベルやスキーマ進化といった機能により、データ管理の負荷を軽減できる S3 にデータを Iceberg 形式で集約しておくことで、Snowflake での分析に加え、将来的には他のサービスからもデータを活用できます。Snowflake 経由の分析についても、現在の Tableau に加え、Sigma BI や Streamlit など、用途に応じた分析ツールの活用を視野に入れており、データ活用の幅をさらに広げていく予定です。 まとめ 本記事では、山岡家が Fivetran の CDC 機能を活用して、RDS for Oracle から Amazon S3 上の Apache Iceberg テーブルへのデータ同期を実現した事例をご紹介しました。 当初は AWS のサービスを組み合わせたストリーミング CDC 構成も検討しましたが、複数コンポーネントの運用負荷を考慮し、Fivetran のマネージド CDC 機能を採用しました。その結果、約 5 分でのデータ反映、月あたりの運用工数を約 6 日から 0.5 日への削減、PoC から本番稼働まで約 1 ヶ月という短期導入を実現しています。 CDC × Iceberg on AWS の構成を検討されている方にとって、本記事がアーキテクチャ選定の一助となれば幸いです。 著者について 田中 陽里 株式会社丸千代山岡家 経営企画室 副室長 2023 年より現職。外食産業における DX を推進し、データドリブン経営を支えるデータ基盤の企画・構築を推進。 好きな AWS サービスは Amazon Elastic Container Service です。 大久保 裕太 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっています。IoT 領域が得意で、好きな AWS サービスは AWS IoT Core 。  

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 さて、みなさんはゴールデンウィークのご予定はお決まりでしょうか。今年は長期休暇にされる方も多いようですね。私はというと、6月24日・25日に幕張メッセで開催される AWS Summit の準備があり、飛び石連休をつなげての長期休暇は取れそうにありません。その代わり、趣味のパデルの大会にいくつかエントリーしているので、そこでリフレッシュしようと思っています。 AWS Summit では、パデルのフォームを VR で計測できる展示を予定しており、現在鋭意開発中です。VR の世界観も AI を活用して実現しており、日々多くの学びがあります。また、スマートグラスや音声を活用した業務効率化アプリも開発中で、そちらもご体験いただけます。ぜひご来場ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年4月20日週の主要なアップデート 4/20(月) Amazon CloudWatch Logs Insights が JOIN およびサブクエリコマンドを導入 Amazon CloudWatch Logs Insights で JOIN とサブクエリコマンドが利用可能になりました。これまで複数のロググループをまたいだ分析では、複数のクエリを実行して手動で結果を組み合わせる必要がありましたが、今回のアップデートで 1 つのクエリで完結できるようになりました。例えば、エラーが多いサービスを特定するサブクエリと、パフォーマンスデータを持つ別のロググループを JOIN することで、エラー頻度と応答時間を同時に分析し、優先対応すべきサービスを効率的に特定できます。詳細は こちらのドキュメントをご参照ください。 Amazon DocumentDB (MongoDB 互換) がバージョン 5.0 から 8.0 へのインプレースアップグレードをサポート Amazon DocumentDB で、バージョン 5.0 から 8.0 へのインプレースアップグレードが可能になりました。従来はクラスタを新規作成する必要がありましたが、今回のアップデートでクリック数回の操作だけでアップグレードできます。バージョン 8.0 ではクエリ処理が最大 7 倍高速化され、ストレージ圧縮も最大 5 倍向上するため、アプリケーションの応答速度改善とコスト削減を同時に実現できます。詳細は こちらのドキュメントをご参照ください。 4/21(火) AWS Lambda Durable Execution SDK for Java 一般提供開始 AWS Lambda Durable Execution SDK for Java が一般提供開始されました。Java 開発者が Lambda で長時間実行されるワークフローを構築できるようになります。注文処理パイプラインや AI エージェント連携、承認フローなどを外部サービスなしで作成可能です。実行を最大 1 年間一時停止でき、進捗も自動で保存されます。詳細は こちらの Document をご参照ください。 Amazon Aurora serverless: 最大 30% のパフォーマンス向上、よりスマートなスケーリング、そしてゼロまでのスケールダウンを継続 Amazon Aurora serverless がプラットフォームバージョン 4 で大幅にアップデートされ、最大 30% のパフォーマンス向上と賢いスケーリング機能を実現しました。従来は複数のタスクが同時実行される際にリソース競合が発生しやすかったビジネス用 Web アプリケーションや API サービスでも、効率的に動作するようになりました。特にエージェント型 AI アプリケーションのように、活動が集中する時間と長時間のアイドル状態が不規則に発生するワークロードに最適で、使用量に応じた自動スケーリングにより無駄なコストを削減できます。詳細は こちらの Blog 記事をご参照ください。 AWS Lambda 関数で Amazon S3 バケットを S3 Files によりファイルシステムとしてマウント可能に AWS Lambda で Amazon S3 バケットをファイルシステムとして直接マウントできる S3 Files 機能が提供開始されました。従来はデータ処理のためにオブジェクトをダウンロードする必要がありましたが、今回のアップデートによりファイル操作が直接可能になります。複数の Lambda 関数が同じファイルシステムに同時接続でき、AI や機械学習のワークフローでデータ共有が簡単になります。詳細は こちらの Blog 記事をご参照ください。 ハイブリッド Kubernetes ネットワーキング向け Amazon EKS Hybrid Nodes ゲートウェイの紹介 Amazon EKS で Hybrid Nodes gateway が提供開始されました。この機能により、クラウドとオンプレミス環境を跨ぐハイブリッド Kubernetes ネットワークが自動化されます。従来は複雑なルーティング設定やネットワークチームとの調整が必要でしたが、これらが不要になります。pod 間通信や AWS サービスとの接続も自動で処理され、EC2 インスタンスに Helm でデプロイするだけで利用できます。中国リージョン以外で追加料金なしで利用可能です。詳細は こちらのドキュメントをご参照ください。 4/22(水) Amazon Bedrock AgentCore が開発者のエージェント構築を高速化する新機能を追加 Amazon Bedrock AgentCore に新機能が追加され、AI エージェント開発が大幅に簡単になりました。新しい managed harness (プレビュー) により、従来必要だったオーケストレーションコードを書かずに、モデルとプロンプト、ツールを指定するだけでエージェントを即座に実行できます。セッション途中でのモデル変更や、タスクの中断・再開も可能で、プロトタイプから本格運用まで一貫してサポートします。追加料金は発生せず、オレゴン、バージニア北部、フランクフルト、シドニーの 4 リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 AWS Secrets Manager が MongoDB Atlas と Confluent Cloud への管理対象外部シークレット機能を拡張 AWS Secrets Manager が MongoDB Atlas と Confluent Cloud の外部シークレット管理に対応しました。従来は各サービスの認証情報を自動ローテーションするために Lambda 関数を自作する必要がありましたが、今回のアップデートで AWS が提供する機能だけで実現できるようになりました。データベースと Kafka を組み合わせたデータパイプラインなどで、複数のサービスのシークレットを一元管理し、運用負荷を大幅に削減できます。詳細は こちらのドキュメントをご参照ください。 Amazon ECS マネージドインスタンス向け GPU ヘルスモニタリングと自動修復機能の導入 Amazon ECS Managed Instances で NVIDIA GPU の健康監視と自動修復機能が提供開始されました。GenAI 推論などの GPU ワークロードでハードウェア故障が発生した際、自動的に故障を検知して問題のあるインスタンスを交換します。これまで GPU 故障時は手動での対応が必要でしたが、この機能により可用性が大幅に向上します。NVIDIA DCGM を使用して継続的に監視し、EventBridge 経由で通知も可能です。対応する NVIDIA GPU インスタンスタイプで追加料金なしで利用できます。詳細は こちらのドキュメントをご参照ください。 4/23(木) Amazon Redshift が Apache Iceberg テーブルに対する UPDATE、DELETE、MERGE をサポート Amazon Redshift で Apache Iceberg テーブルに対する UPDATE、DELETE、MERGE 操作がサポートされました。これまで Iceberg テーブルの個別行を修正するには外部エンジンが必要でしたが、今回のアップデートにより Redshift から直接データ操作が可能になります。データパイプラインの複雑さや遅延を削減でき、変更データキャプチャや緩やかに変化するディメンションなどの一般的なデータ統合パターンで活用できます。詳細は こちらのドキュメントをご参照ください。 AWS Client VPN が AWS Transit Gateway とのネイティブ統合をサポート AWS Client VPN が AWS Transit Gateway とのネイティブ統合をサポートしました。これまで複数の VPC にリモートアクセスするには中間 VPC の管理が必要でしたが、今回のアップデートで不要になり運用が大幅に簡素化されます。さらにエンドユーザーの IP アドレスが保持されるため、セキュリティ監査やトラブルシューティングが容易になります。詳細は こちらのドキュメントをご参照ください。 Amazon Athena がマネージドコネクタでフェデレーテッドクエリを簡素化 Amazon Athena で DynamoDB や PostgreSQL、MySQL、Snowflake など 12 のデータソースに対するマネージド コネクタが提供開始されました。従来は S3 以外のデータをクエリするためにコネクタリソースのデプロイや管理が必要でしたが、マネージド コネクタにより Athena が自動でセットアップと管理を行うため、この手間が不要になりました。データを移動することなく、複数のデータソースを横断してクエリできるため、分析作業が大幅に効率化されます。詳細は こちらのドキュメントをご参照ください。 4/24(金) Amazon Connect が AI エージェントのパフォーマンスを測定・改善するための 8 つの新しいメトリクスを提供開始 Amazon Connect で AI エージェントの性能を測定する 8 つの新しいメトリクスが利用可能になりました。ゴール成功率や忠実度スコア、ツール選択精度などを通じて、AI が顧客の問い合わせを正しく解決できているかを詳細に分析できます。従来は AI エージェントの品質評価が困難でしたが、今回のアップデートで定量的な改善が可能になります。専用ダッシュボードや API を通じてデータにアクセスでき、カスタマーサポートの質向上に活用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Gateway と Identity が VPC egress をサポート Amazon Bedrock AgentCore Gateway と Identity が VPC egress をサポートし、プライベートネットワーク内のリソースと安全に通信できるようになりました。従来は外部からアクセスできないプライベート環境のリソース呼び出しが困難でしたが、今回のアップデートにより EKS 上の MCP サーバーなどを直接利用可能になります。マネージド設定で簡単に開始でき、複雑な要件には自己管理も選択できます。東京リージョンを含む 14 リージョンで利用可能です。 詳細はこちらのドキュメントをご参照ください。 Amazon Q がワークフォースインテリジェンスのための Visier の Vee エージェントと統合 Amazon Quick が Visier の AI アシスタント Vee と統合されました。これにより HR や財務担当者が Amazon Quick 内で直接人事データにアクセスできるようになります。従来はツールを切り替える必要がありましたが、今回のアップデートで自然言語による質問で人員数や離職率などの情報を瞬時に取得可能です。詳細は こちらの Blog 記事をご参照ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。