PoCの壁を越える?Siemens×AWSの『Envoy』セッションを見てきた #HM26

2026.05.11
 概要こんにちは、クラスメソッド製造ビジネステクノロジー部の田中聖也です。

HANNOVER MESSE 2026のDay2、AWSブースのシアターセッションでSiemensの「Envoy」発表を見てきました!
「Envoy」はSiemensが開発中の、本番環境向けエージェンティックAIフレームワーク(コードネーム)です。AWSブースの一角に構えられたシアタースペースで、SiemensのDave Mitchell氏(Senior Vice President, Foundational Services)とAWSのEmad Mankabady氏(Principal Partner Solutions Architect)がペアで登壇していました。
この記事では以下を扱います。
セッションの基本情報と登壇者
Siemensが「AI企業」へ舵を切っている話
「Envoy」とは何か、何が嬉しいのか
Envoyを支える4つの設計原則
SiemensとAWSの共創スピード(1週間で9エージェント開発)
 セッション基本情報イベント名: HANNOVER MESSE 2026 / AWSブース シアターセッション
タイトル: Agents at Scale: Inside Envoy — Siemens Production-Grade Agentic AI Services on AWS
登壇者:
Dave Mitchell氏(Siemens, SVP, Foundational Services)
Emad Mankabady氏(AWS, Principal Partner Solutions Architect)

時間: 15〜20分のショートセッション
AWSブースは会場でも大きなスペースで、ロボティクスやフィジカルAI、生産ラインの最適化など、AWSと各パートナーの展示が一箇所に集まっている感じでした
セッション冒頭で示されたのが、SiemensとAWSの取り組みの全体像です。
共に新しい仕組みを創る（Co-innovation）: 自社単独ではなく、両社の強み（Siemensの製造ノウハウとAWSのIT基盤）を掛け合わせ、現場の課題を解決する新しい技術を共同で生み出す
素早い現場導入（Swift）: 開発した仕組みを長期間眠らせるのではなく、現場へスピーディに導入し、いち早く効果を実感できるスピード感を重視する
効率化と工場全体への展開（Efficiency & Scale）: 一部の工程や特定のラインだけの「部分最適」に留めず、工場全体や世界中の複数拠点へと無駄なく仕組みを広げ、全体的な効率化を図る
上記3つの軸に
製造現場のデジタル化（Digital Industries）: 工場内の生産ラインの自動化や、工程管理の最適化など、モノづくりの心臓部を進化させる
次世代のインフラ設備（Smart Infrastructure）: ビル群の管理や電力網の制御など、工場を支えるエネルギーやインフラをより効率的で賢いものにする
交通・輸送システム（Mobility）: 鉄道や物流ネットワークなど、モノや人が移動する仕組みの安全性と効率性を高める
といった事業領域に展開していくという構造になっていました。
 Siemensは「産業企業」から「AI企業」へ舵を切っている冒頭でDave氏が話していたのが、ここ2年のSiemensの方向転換です。
Siemensは産業企業から、データ・AI駆動型の企業へとコンテキストを切り替えようとしている
これ、めっちゃ印象的でした。Siemensといえば製造業界では超多角化企業というイメージですが、その会社全体がAIカンパニーへとシフトしようとしているという宣言です。
そしてそのために何をやっているかというと、社内700以上のソフトウェア製品を共通基盤に乗せるという取り組みです。Dave氏が率いるFoundational Servicesチームは、この700製品すべてが消費する共通の土台を作っているとのこと。
その土台の上に乗るのが「Siemens Xcelerator」というブランドで、
簡単で、オープンで、相互運用可能
一貫した顧客体験(ログイン・ライセンスなど)
一つ買えば次が買いやすくなる(Land & Expandのセールスモーション)
というのを目指しているそうです。
 なぜ「Envoy」が必要なのか — 製造業ソフトウェアのリアルな課題Dave氏が話していた製造業ソフトウェアの課題、これがめっちゃ刺さりました。
スライドにまとまっていた課題は以下の4つです。
System silos: PLM、MES、ERP、IoTシステムが分断されている
Manual orchestration: システム間の依存関係を人間がオーケストレーションしている
Unplanned outages: ソフトウェアの予測不能な障害や、連携不備による意図しないオーケストレーション障害
*Change execution delays: エンジニアリングやプロセスの変更がデザインから実行まで数日〜数週間かかってしまう
これ、お客様と話していてもよく聞く話で、現場の課題感としてかなりリアルだと感じました。
そしてもう一つ重要なポイントとして、Dave氏は「みんなPoCはたくさん持っている。でも本番運用にスケールするのは別の話」という話をしていました。
このスライドが個人的に一番グッときました。実験段階（PoC / Excitement and potential）と「ビジネスでの本格稼働（AI production agents / Meaningful business value）の間に 深い溝（壁） があり、そこを越えるためには
実用レベルの「品質・スピード」(Performance)
全社規模での「対応力」(Scalability)
情報の「安全性」(Security)
組織としての「管理体制・ルール」(Governance)
という4つの壁を乗り越える必要があるという整理でした。
PoCの段階で生まれたワクワク感を、本番運用の価値にちゃんと繋げる。Envoyはまさにこのキャズムを越えるためのフレームワークというわけです。
 「Envoy」とは何かEnvoyはAWSの「Agent Core」を土台として、その上にSiemensが構築している自律型AIフレームワークです。Dave氏いわく「正式名称は自分が決めるわけじゃないから変わるかも、今の愛称はEnvoy」とのことでした。
スライドではEnvoyのバリューが6つに整理されていました。
プログラミング不要で簡単設定(Configure more, code less): 複雑なコードを書かず、設定の変更のみで実務に適用できる
機能を部品化し、多様な用途に対応(Modularity supports varied use-cases): 機能がブロック化されており、現場ごとの異なる要件に合わせやすい
運用・管理の手間を最小化(Minimum Operational overhead): 導入後のシステム保守や管理にかかる労力を大きく削減する
稼働監視とセキュリティを標準装備(Observability & Security is Built-in): システムの異常検知や安全対策があらかじめ組み込まれている
規模の拡大に柔軟に対応(Scale effortlessly): 一部のラインで小さく始め、工場全体へ展開する際にもスムーズに拡張できる
導入から実稼働までを迅速化(Accelerates the Go-to-Market): 新しい仕組みを現場で素早く立ち上げることができる
スライドに添えられていた「An Agent Framework changes the game — Envoy further reduces the complexity」という言葉が、Envoyのポジショニングをよく表しているなと感じました。Agent Coreというフレームワークがゲームを変えたうえで、Envoyがさらに複雑性を減らしにいく、というレイヤー構造です。
Envoyが解決しようとしているのは、Siemens社内で各製品がワークフローもツールもデプロイも全部バラバラに作っているという状況です。これをEnvoyで橋渡しして、マルチプロダクトのワークフローを作れるようにする、という狙いでした。
そして、Envoy Agentic AIには3つのコア機能があります。
構築と現場展開(Build & Deploy): 複数の自律型AIを組み合わせた作業手順を作成し、現場のシステムに実装する
既存ツールやデータとの連携(Connect with Tools & Data): 現場で既に使っているシステムや、蓄積されたデータとAIを接続する
進行管理と効果測定(Orchestrate & Evaluate Workflows): 作業全体の流れを統括し、その手順が正しく機能しているかを評価・改善する
しかも重要なのが、これがすでに「先行提供」が開始されているになっていることでした。構想ではなく、もう触れる状態にあるというのが強調されていました。
 ユースケース — 設計変更の影響範囲を自動で捉える
具体的なユースケースとして紹介されていたのが、エンジニアリング・製造領域での設計変更リクエスト(design change request)の管理でした。スライドには以下が並んでいました。
設計変更リクエストのE2Eインパクトを管理
どのサブパーツが変更/修正されるかを特定
複雑な階層型ワークフローを管理
長時間実行される非同期ワークフローのサポート
承認・モニタリングのためのHuman-in-the-loop割り込み
変更によるパフォーマンスへの影響評価
そしてスライド左下に書かれていた一文がめっちゃ刺さりました。
Envoyは、Siemens製品がエンジニアリング・製造のユースケースで問題を「検知して解決する」ことを可能にする — 単に通知するだけでなく、依存関係を通じて推論し、ERPとMESにまたがる変更を自律的に実行する
「通知する」と「推論して自律的に実行する」、この差分こそがエージェンティックAIの真価ですよね。設計変更が起きた時に、関連する部品・工程・サプライチェーンへの影響を自動で推論して、ERPやMESに変更を反映していく。製造業の人なら、この絵が動いた時のインパクトの大きさが想像できると思います。
初期に取り組んでいるのは製品エンジニアリングと製造のユースケースで、具体的には以下のSiemens製品群を横断するワークフローだそうです。
Design Center
Teamcenter
Opcenter
Simcenter
これらをEnvoyで連携させ、Human-in-the-loopを挟んだ階層型ワークフローを、ほぼコードレスに構築するというイメージでした。
 Envoyを支える4つの設計原則ここからはEmad氏のパートで、AWS視点から見たEnvoyの設計原則の話でした。
 1. Configurability(設定可能性)新しいLLMが出るたびに開発者がコードを書き直すのは現実的じゃない、というのがスタート地点でした。設定を追加するだけで切り替えられるようにする、というシンプルだけど大事な原則ですね。
 2. Memory(メモリ)「エージェントは脳(LLM)、メモリ、手(ツール)を持つ」という整理がわかりやすかったです。Agent Coreが短期・長期メモリを提供し、加えてS3やOpenSearchをプリミティブとして使い、より大規模なメモリ領域も確保しているとのこと。
 3. Integration & Extensibility(統合と拡張性)ツール、データベース、APIとの連携をMCP(Model Context Protocol)とAmazon EventBridgeで実現しているという話でした。MCPがちゃんと製造業のユースケースに組み込まれているの、なんかちょっと感慨深かったです。
 4. Security(セキュリティ)Agent Coreが提供する可観測性ツール、ガードレール、推論からツール実行までのトレーサビリティを丸ごと活用する形で、Envoy側で改めてセキュリティを作り込まなくていい設計になっているとのことでした。
そしてEmad氏のこの一言が印象的でした。
インフラの構築をやめて、インテリジェンスの構築を始められる
これ、本番運用を見据えたエージェンティックAIの真髄だと感じました。
 SiemensとAWSの共創スピードがすごいセッションの後半でEmad氏が話していたAWSとSiemensの協業の進み方、これが個人的に一番おもしろかったです。
スライドのタイムラインに沿うと、こんな感じの流れでした。
Envoy development started
AWS re:Invent 2025でSiemens & AWSのワークショップ実施
Amazon Bedrock AgentCoreリリース
AWS ProServe架電エンジニアリング進行中
Siemens & AWS workshop(続編)
Envoy launch
そして右側にKPIっぽくまとめられていたのがこちら。
5カ国から30名以上が参加するワークショップを2回開催
サービスローンチから1週間以内に12のPoCを開発、Siemens社内で2つのPrivate Previewと10件以上のフィードバックセッションを実施
SiemensはAgent Coreコンソーシアムにも参加し、製品ロードマップに直接フィードバック
1週間で12PoC、しかもそれを本番に向けて磨き込んでいるって、生成AI時代の開発スピードってこういうことかと感じました。
ちなみにEmad氏は「Today it's not just we talk about a road map, it's something that already runs in production today」と話していて、もう構想ではなく本番で動いているというのを強調していました。
 まとめAWSブースのシアターセッションで、Siemensが本気でAIカンパニーへ舵を切っているのを目の当たりにできて、めっちゃ刺激的でした!

PoCはあるけど本番までいかない、というのが今のエージェンティックAIのリアルな壁だと思っているので、Envoyのような「本番運用を前提にしたフレームワーク」の動きを引き続き追っていきたいと思います。