ハノーバーメッセ2026 AWSブース訪問レポート — 製造業フィジカルAIの実装フェーズを見てきた #HM26
「re:Inventでは絶対見れない内容だし、去年のハノーバーメッセよりさらに進化してる…」
ハノーバーメッセ2026の三日目、Hall 15 / Booth D76のAWSブースに訪問しました。
事前にお願いしていて、AWSの担当の方からブースツアーという形式で丁寧にご案内いただいたのですが、展示内容が多すぎて、記事としての整理に時間がかかりました。
AWSブースは今回1,400㎡の規模で、25のパートナーキオスクと9つのAmazonキオスク、ブース内シアターまで備える大型ブース。会期中は50以上のセッションが連続開催されており、製造業向けへのコミットの大きさが規模からひしひしと伝わってきます。
本記事は、ハノーバーメッセ2026のブースツアーシリーズ第1弾として、いつも私がお世話になっているAWSブースで見聞きしてきた内容を一気に紹介していきます。
全体テーマは「Built for Industrial AI」
AWSブースの全体テーマは Built for Industrial AI。展示は「エンジニアリングと開発」「スマート製造とサプライチェーン」「スマート製品とサービス」という3つのソリューション領域に分かれていて、それぞれの中に複数のキオスクと体験型デモが配置されている構成です。
ハノーバーメッセ2026で個人的に一番注目していたのが、各社が「フィジカルAI」「Industrial AI」をどこまで本気で打ち出してくるかという点だったんですが、AWSブースは想像していた以上に「フィジカルと製造現場への適用」に踏み込んだ展示が並んでいて、去年と比べてもかなり驚いたというのが正直な感想です。
ここから、ブースツアーの流れにそって実際にブースを回っていく目線でお伝えしていきます。
ブース全体像 — 真ん中に「動くラインそのもの」を置いてくる
AWSの担当の方が、各エリアの背景まで踏み込んで説明してくださったので、本当に勉強になる時間でした。
このブース、まず立ち寄った瞬間に目を引くのが、ブース中央に組まれた「AI-powerd Production Lineと名付けられた、実際に動いている製造ライン」 です。
このラインのデモは、AWSが「AI駆動型プロダクトジャーニー」と呼んでいる体験型デモで、4つのステージで構成されています。
- ステージ1: エンジニアリングと開発 — 「エンジニアリングトンネル」と呼ばれる入り口エリアで、AIによるドリンクコースターデザイン生成・AI駆動型エンジニアリングワークフロー・製造デジタルスレッド・AIによるシミュレーションの4デモを展示
- ステージ2 & 3: 生産＆検証（Autonomous AI Manufacturing Cell） — 自律移動ロボット（AMR）→ 協働ロボット（Co-bot）→ レーザー彫刻機 → AI搭載品質検査カメラ → ヒューマノイドロボット による完全自律生産
- ステージ4: フィジカルAI — 大きな円形のフィジカルAIキオスクで、フィジカルAIの「5つの柱」を深掘り
来場者がエンジニアリングトンネルでコースターのデザインを注文すると、ライン側に発注がかかって、AMRが在庫から原材料を生産ラインに運び、Co-botがレーザー彫刻機にコースターを積み込み、AI搭載カメラが彫刻の明瞭さ・位置精度・表面品質を検査して合格品のみを承認、最後にヒューマノイドロボットが完成品をフルフィルメントテーブルへ運んできて来場者に手渡す、という流れまで通しでデモされていました。
「フィジカルAI」「Agentic AI」のキーワードを、全体の流れで体感させてくる作りで、非常にわかりやすくストーリーの作り込みに感動しました。
そして、このラインの先にあるフィジカルAIキオスクには「The Complete Stack for Physical AI」と題された5層のリファレンスアーキテクチャがパネルとして展開されている。これがブース全体の骨格として効いていて、後述するコーディングエージェントやお客様事例の展示も、すべてこの5層の中に位置づけて語られていました。
生成AIで作るプロダクトデザイン — Amazon Nova × CAD自動化
ラインの最初に置かれていたのが、生成AIによるプロダクトデザインのデモ。
来場者がタッチパネルでベースデザインを選び、入れたい文字や雰囲気をプロンプトとして入力すると、画像生成AIがいくつかのパターンを提案してくれる。気に入ったものを選ぶと、ライン側に発注がかかって製造工程に流れていく仕組みです。
担当の方によると、画像生成のコアモデルとして使われているのはAWSが独自開発するAmazon Nova。画像生成のNovaを利用しているとのことで、AWS自前モデルを実装の前面に出してくる打ち出し方が、最近のAWSの流れだなと感じます。
ここまでだと「画像生成のショーケース」で終わりそうなんですが、面白いのはこの先で、CADデザインそのものを生成AIで作っていくデモが流れていたところ。
コーディングエージェントが自然言語のチャットからコードを書いていくのと同じ感覚で、CADの構造化データを自然言語で生成していく。FreeCADのようなオープンソースCADや、各種オープンフォーマットを前提に、自然言語のやりとりからCADの形を作り上げていくイメージです。
しかも、CADデザインができたらそのままCAEシミュレーション（CFDによる空力解析など）に流して、複数のデザイン候補をシミュレーション結果込みで生成AI側が出してくる。人間側はヒューマン・イン・ザ・ループで取捨選択していく、という設計フロー全体まで含めて作られていました。
整理して見ると、ここで生成AIに任されているのは「最初のデザインを決める」段階に絞られていて、シミュレーション本体は既存のCAE/CFDソフトウェアを呼び出して結果を返す、というすみわけになっている。生成AIで設計工程を全部置き換えにいくのではなく、「設計の最初の選択肢を高速で並べる」ところに生成AIを差し込み、その先は実績のあるシミュレーション資産にきっちり繋ぐ、という構成です。設計のタイムトゥーマーケットを劇的に短くする方向に、生成AIを真正面から組み込んであります。
ブースの骨格 — The Complete Stack for Physical AI（5つの柱）
ブースの骨格にあたるのが、フィジカルAIシステムを開発・展開するためのフレームワークとしてAWSが整理した5層リファレンスアーキテクチャ「The Complete Stack for Physical AI」。Data → Training & Model Optimization → Simulation → Sim2Real & Edge Operations → Agentic AI、という5つの柱で構成されています。順番に紹介していきます。
01 Data — 現場データの取り込み
最初の層は、現場のあらゆるシグナルをクラウド側に集約するレイヤー。
温度・圧力・カメラ映像といったセンサーデータから、PLCのレジスタ値、設備のステータスまで、AWS IoT Coreなどの既存サービスの延長線上で取り込んでいく構成です。「ここはまさに既存サービスでカバー」という安定の構成ですが、フィジカルAIの起点として再整理されている、という位置づけでした。
02 Training and Model Optimization — モデル学習・最適化
集めたデータでモデルをトレーニングする層は、ご想像の通りNVIDIAさんのプラットフォーム前提が色濃く出ています。
担当の方の言葉を借りると、「ここはNVIDIAのプラットフォームを前提に、AWS上にすぐデプロイできる環境を作りこむのがAWS側の役割」とのこと。NVIDIA Cosmos WFMやIsaac Lab、GR00T N1.x FMといったフィジカルロボット向けの基盤モデル・プラットフォームを、AWS上のAWS Batch + Amazon SageMaker AIといった既存サービスと組み合わせて快適に立ち上げ・運用できるテンプレートやリファレンス構成を整えていく流れです。
去年のre:InventでAWSとNVIDIAの共同登壇があったのを思い出しましたが、その流れがハノーバーメッセでも続いていて、製造業の文脈でAWS×NVIDIA連携が一段と立体的になっている印象を受けました。
03 Simulation — シミュレーション環境
3層目はシミュレーション。フィジカルAI開発で「足りないデータを生成する」「実機を動かす前にシミュレーションで検証する」レイヤーです。NVIDIA Isaac Sim / Isaac Labを、Amazon EC2 + Amazon EKSの組み合わせで運用していく構成。
ここで興味深かったのが、AWSは「フィジカルAI専用の新サービス」を新設するというより、既存サービスの組み合わせをアーキテクチャとして整理し直す方向で見せていたこと。Kubernetes（Amazon EKS）、Amazon S3、コンピュート系といった、もともと持っているピースをフィジカルAI／AIエージェント向けに最適化していく整理になっていました。
最近リリースされたAmazon S3 Filesについても言及がありました。AIエージェントは大量のデータを高頻度に取り回すので、API利用料金や遅延が一気にネックになる。そこをアーキテクチャレベルで最適化する機能をS3に組み込んでいて、フィジカルAI／AIエージェント時代の現実解として、S3を再設計しにきている、というメッセージを強く感じました。
04 Sim2Real and Edge Operations — 実機展開
シミュレーションだけで終わらせず、実機にデプロイするのが4層目。
ここで活躍するのがAWS IoT Greengrassと、エッジ側のロボットに搭載されるNVIDIA Jetson Thorの組み合わせ。エッジ側のデバイスに学習済みモデルをデプロイし、実機からのデータ取得 → SageMaker AIでの再学習 → モデル再デプロイまでを、ライフサイクルとして回せる仕組みになっています。
「PoCはできたけど、現場で動かない」「現場で動いたけど、モデルの再学習・再デプロイが回らない」という、製造業でよくある詰み所に対するAWSなりの回答に見えました。
05 Agentic AI — 全体を束ねるエージェント
そして5層目が、ブース全体のキャラクターを決めている Agentic AI のレイヤー。AWSスタックとしてはAmazon Bedrock AgentCoreとStrands Agents、エッジ側で動くNVIDIA NIMがベースで、これがブース中央のAI-Powered Production Lineの頭脳役になっています。
ラインを動かしているのは、複数システムにまたがる中央エージェントで、MCP（Model Context Protocol）とSkills経由で各種システムに繋がる作りになっています。
担当の方の説明を、ざっくり整理するとこんな感じです。
- スケジューリング — MES／MOMといった製造管理システムと連携し、どの工程をいつ動かすかを判断
- 部品データ・在庫管理 — PDMや在庫管理システムと連携し、必要部品の有無・状態を確認
- 物理動作の制御 — ロボットアームやAMRに対するトリガーをエージェントから発行
- MCPで疎結合に繋ぐ — 個別システムごとにアダプタを書くのではなく、MCPで共通インタフェース化
「MES自体を新しく置き換える」のではなく、既存のシステムをエージェントから叩けるようにつないでいくスタンス。これは、レガシー資産を持っている日本の製造業のお客様にとって、めっちゃ現実的なアプローチだと思いました。
ぶっちゃけ、フィジカルAIっていうと「全部AWS／NVIDIAで作り直し」みたいなイメージが先行しがちなんですが、ブースで語られていたのは、現場のシステムを残しつつエージェントが上から束ねる、という方向。日本のお客様にもそのまま持っていける考え方だな、と感じます。
外観検査もAmazon Novaで — Few-shotで立ち上げる検査
ラインの最後にあった外観検査ステーション。ここは最近のAWSさんの展示でもよく見る内容ですね。
検査用にAmazon Novaを使っていて、正解データと実物データを比較して合否を判定するアプローチ。これ、いわゆる従来のディープラーニング型の外観検査AIだと、学習用データを大量に用意して、想定パターンも全部準備しないといけなかった世界が、生成AIによってFew-shotで立ち上げられるようになる、という話。
担当の方も冷静に「生成AIなのでレスポンスは秒単位になる。製造能力にマッチするかは要検討」と前置きしながら、
- 多品種・少量生産の製品ライン
- 抜き取り検査でOKな運用
- 高速性よりも立ち上げの速さが効く現場
といったところでは現実的に使える、という整理。並列化で投資を増やしてまで導入する必要があるかは、慎重に見極めるべきフェーズ、という話もしっかり添えてくれていました。
この割り切り感覚よいですね。「生成AIは万能じゃないけど、ハマるユースケースには劇的に効く」という現実路線が伝わってくる展示で、お客様への説明資料にもそのまま流用したい内容でした。
AWS Business Outcomes Xcelerator (BOX) Program — パートナー連携の制度化
5層アーキテクチャを支える次の柱として紹介されていたのが、AWS Business Outcomes Xcelerator (BOX) Program。
産業システムを作っていく上で、Siemens、Schneider Electric、ABBといった大手産業オートメーションベンダーとの連携は不可避です。お客様としては「どの組み合わせで作るのが正解？」となりがちなので、AWS側で代表的な座組をプログラム化して、お客様向けの構成を素早く設計するためのコミュニケーション体制を整えていく、というのがこのプログラムの狙い。これはグローバルプログラムなんですが、日本側でも産業機械メーカーとのコミュニケーションが進んでいるとのこと。
6月のAWS Summit Japanでは、フィジカルAIをテーマに産業機器メーカー各社と協議しながらデモを準備中、というニュアンスの予告もちらっと出ていたので、これは普通に楽しみにしておきたい。
Smart Products and Services — Kiroで組み込みアプリを構築
ここから、個人的にツボだったコーディングエージェント関連の展示。
プロダクト開発のリファレンスとして展示されていたのが、HVAC（空調機器）のコントロールパネルを想定したミニデバイス。中身の組み込みアプリを AWSのコーディングエージェントKiro と一緒に開発した、というデモでした。
産業機器の中に入っているHMIや制御盤のソフトウェアって、通常のITアプリケーションと比較してテスト・デプロイの自由度が低くて、開発・修正のサイクルがしんどいんですよね。これをKiroと一緒に、SSHでデバイスに入って、コードを書いて、コンパイルして、実機で動作確認、という流れですね。
このワークショップは、去年のre:Invent2025でも体験してブログも書いていました。
ワークショップから見える、組み込み領域でのKiro活用の可能性 | DevelopersIO
去年時点ではまだ未完成部分があったのですが、現時点では環境構築の時間が高速化され、全てのステップが構築されたとのことでした。是非改めて触って体感してみたいと思います。
仕様駆動開発で「バイブコーディング」から脱却する
Kiroの特徴として推されていたのが、コーディングエージェントとしての「開発プロセス」設計の部分。
最近よく言われる「バイブコーディング」（雰囲気で書いてもらう開発）ではなく、仕様（spec）→ 設計 → 実装、という開発プロセスを意識した作りになっていて、
- 仕様や設計のコンテキストをきっちり残す
- フックでイベント駆動の自動化（人がいちいち指示しなくてもOK）
- TDD・プロパティベーステストの考え方を組み込み済み
- ハルシネーション対策として「先にテストを書く」運用が自然に促される
といった部分が、「AIに任せて崩れるのではなく、AIに任せて回り続ける」ためのプロセスとして埋め込まれている、というのがメッセージの中心でした。
コーディング以外でも効いてくる
Kiroの使いどころは、コードを書くフェーズだけではなく、
- プロトタイピング
- 仕様書・設計ドキュメント作成
- CI/CDパイプラインのリリース準備（AWS提供のMCPサーバー経由で一発構築）
- 運用・プロダクト分析（CRMやテレメトリを集約し、原因分析と次アクション提案まで）
と、上流から運用までフルラインで効いてくる、という説明。実際にブースで展示されていたサプライチェーン最適化のデモでは、AWS Supply Chainサービスをそのまま使うのではなく、お客様固有のサプライチェーン戦略に合わせてコーディングエージェントとともにアプリを個別開発する方向に舵を切っていました。
「フィットトゥースタンダードでさっと作る」「個別開発でスピードを出す」 — このバランスを、コーディングエージェントの進化で行き来できるようになってきている、というのが今のAWSの肌感みたいです。
なお、このSmart Products and Servicesの一連のデモは、お客様側で再現できるワークショップとして用意されているとのこと。気になる方はAWSの担当営業さんにリクエストすれば展開してもらえる、というアナウンスもありました。
顧客事例 — Zoomlionの自社製造×AWS
ブース後半で紹介されていたのが、中国の建機・産業機械メーカーZoomlion（中聯重科）の事例。
Zoomlionは自社の製造工場でロボットを多用していて、そのAI開発環境としてAWSを採用。今回のブースでは、Zoomlionが構築した製造管理システムがAWS Marketplace経由で購入・デプロイできる、という展示も並んでいました。
担当の方の説明を整理すると、
- Zoomlionの製造現場で動くAIモデルはAWS基盤で開発・運用
- そのノウハウが詰まった製造管理システムは、AWS Marketplaceからクリックひとつで導入可能
- 他のお客様もスモールスタートで試せる
という流れ。海外の製造業の取り組みと、それを他のお客様が試せる仕組みがセットで紹介されている展示でした。
まとめ 「パートナーをフル活用しながら製造業の現場をおさえにいっている」
短い時間のブースツアー（それでも60分ありました。本当にあっという間）でしたが、AWSブースで語られていた内容は、現場で実際に回すための現実主義とパートナーのフル活用という姿勢が前面に出ていたのが印象的でした。
AWSは乱暴に言うとITソリューションの会社で、製造現場へのアプローチをどうするかという点は2〜3年前まではまだ試行錯誤かな？という印象だったのですが、今年のハノーバーメッセでは、本気で全部をおさえにいこうとしているように感じました。
- 5つの柱という整理 — 「Data／Training & Model Optimization／Simulation／Sim2Real & Edge Operations／Agentic AI」のフレームは、お客様への説明資料を作るときにそのまま骨組みとして使える整理。フィジカルAI／Industrial AIをどこから手をつければいいか分からない、という相談に対してフレームワークとして提示可能
- 既存システムを束ねるエージェントというアプローチ — MES／MOM／PDM／在庫管理を置き換えるのではなく、エージェントが上から束ねる。レガシー資産を持つ日本の製造業のリアルにフィットしていて、「全部やり直し」ではない移行ストーリー
- コーディングエージェントが「現場実装の質」まで届く段階に来た — HVACデモなど、PoCで止まっていたフェーズが、普通に「リリース前提」のフェーズに変わってくる。Kiroの仕様駆動な作りこみはSI現場でも利用可能
担当の方からも告知のあった通り、6月のAWS Summit JapanではフィジカルAIテーマで産業機器メーカー各社とコラボした展示が予定されているとのこと。ハノーバーメッセで仕入れた目線で、改めてSummitのブースを見て回るのも楽しそうです。
そして本記事は、ハノーバーメッセ2026のブースツアーシリーズ第1弾。これからシーメンス、マイクロソフト、SAPなど、他社ブースの訪問記事もまとめて出していく予定なので、楽しみにしてもらえればと思います。
それでは今日はこのへんで。濱田孝治（ハマコー）でした。
参考資料
AWSサービス・ソリューション
- Amazon Nova — AWSが独自開発する生成AIモデル群（テキスト・画像・動画ほか）
- Amazon Bedrock — 生成AI基盤サービス。AgentCoreでエージェント構築に対応
- Amazon SageMaker AI — モデル学習・最適化の統合プラットフォーム
- AWS IoT Core — 現場の各種IoTシグナルをクラウドに集約するマネージドサービス
- AWS IoT Greengrass — エッジデバイスへのモデルデプロイとライフサイクル管理
- Amazon EKS — マネージドKubernetes
- Amazon S3 — オブジェクトストレージ。AIエージェント向けの新機能群が拡充中
- Kiro — AWSが提供する仕様駆動型コーディングエージェント
- AWS Supply Chain — サプライチェーン管理向けマネージドサービス
- AWS Marketplace — パートナー製品・SaaSをワンクリックでデプロイできる流通基盤
- Guidance for Physical AI for Robotics on AWS — AWS公式のリファレンスアーキテクチャ（NVIDIAとの共同設計）
パートナーテクノロジー
- NVIDIA Cosmos — フィジカルAI向けの世界基盤モデル（World Foundation Model）
- NVIDIA Isaac Sim — ロボット開発向けシミュレーション環境
- NVIDIA Isaac GR00T — ヒューマノイドロボット向け基盤モデル
- NVIDIA Jetson Thor — エッジAI推論向けプラットフォーム
- NVIDIA NIM — 推論マイクロサービス
- Strands Agents — Amazon発のオープンソースAIエージェントSDK
- Siemens日本 — 産業オートメーションの総合ベンダー
- Schneider Electric日本 — エネルギーマネジメント・産業オートメーションベンダー
- ABB Group — ロボット・電動化・産業オートメーションベンダー
- Rockwell Automation日本 — OTTO100 AMRの提供元として生産ラインに登場
- 三菱電機 — 産業機器・ロボットメーカー（前年のAWSブース出展事例として言及）
- Zoomlion（中聯重科） — 中国の建設機械・産業機械メーカー
仕様・規格・OSS
- Model Context Protocol (MCP) — エージェントと外部システムを繋ぐオープンプロトコル
- FreeCAD — オープンソースの3D CADソフトウェア
イベント
- Hannover Messe 2026 — ドイツ・ハノーバーで開催される世界最大級の産業見本市
- AWS Summit Japan — 6月開催予定。フィジカルAIテーマの展示が予告されている
