Amazon Web Services ブログ

AI-DLCで取り払った組織の壁 ― DeNAと取り組んだ分析業務領域での初事例

Satoshi Shinohara — Wed, 02 Sep 2026 06:32:03 +0000

こんにちは、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 ゲームです。

音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション

Miku Honda — Wed, 02 Sep 2026 01:28:02 +0000

本ブログは、株式会社アドバンスト・メディア様と 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 エージェントシステムの設計を検討されている方の参考になれば幸いです。

著者について

耐障害性ライフサイクル実践ワークショップ開催報告 & AWS WAF 実践ワークショップのご案内

Masahiro Imai — Tue, 01 Sep 2026 08:46:42 +0000

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

AWS で VMware のお客様の選択肢が広がった 1 年

Masayuki Toyoda — Tue, 01 Sep 2026 02:28:52 +0000

本記事は 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 のアカウントチームに連絡して次のステップを検討してください。

著者について

翻訳はパートナーソリューションアーキテクト豊田が担当しました。原文はこちらです。

AWS Skill Builder で AI 駆動開発ライフサイクル (AI-DLC) を学ぼう: 日本語版学習コースが公開されました

Hiroki Yamazaki — Tue, 01 Sep 2026 02:06:48 +0000

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へ：人間のボトルネックを解消する設計の進化」もご覧ください。

AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編

Yuhei Harada — Tue, 01 Sep 2026 00:41:20 +0000

本記事は 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: 企画からステージ制作、アプリケーション開発まで

Mitsuhiko Nishida — Tue, 01 Sep 2026 00:32:06 +0000

本記事は、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) です。趣味は、ドラマや映画のエキストラに参加することです。

週刊生成AI with AWS – 2026/8/24 週

Aiichiro Noma — Mon, 31 Aug 2026 07:20:17 +0000

みなさん、こんにちは。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 実用化推進プログラム」をご用意しています。ぜひご活用ください。

今週は以上です。それでは、また来週お会いしましょう！

著者について

「フィジカル AI 開発支援プログラム by AWS ジャパン」最終成果発表会を開催しました

Koya Kimura — Mon, 31 Aug 2026 07:06:36 +0000

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 は引き続き、日本のお客様とともにこの領域に取り組んでまいります。

【開催報告】AWS Resilience Day (個社向け)を開催しました！！（2026年7月3日）

Hiroshi Nakatogawa — Mon, 31 Aug 2026 06:56:08 +0000

はじめに

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 の運用面での課題に対しての支援を行っています。

Amazon Web Services ブログ

AI-DLCで取り払った組織の壁 ― DeNAと取り組んだ分析業務領域での初事例

1. なぜ「データ分析業務」を選んだのか

2. 3日間で、何をしたのか

3. ビジネス部門へ波及した影響

4. DeNAの事業への向き合い方

5. AI-DLC Unicorn Gymを経た変化

6. 製薬・ヘルスケア業界へのメッセージ

まとめ

著者自己紹介

音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション

1. はじめに

2. 飲食業界における現場オペレーションの課題

2.1 手が塞がる環境でのデータ入力障壁

2.2 音声認識活用のハードル

2.3 レシピ一括管理の困難さ

2.4 調理工程の分担・シフト管理の非効率

3. ソリューション概要

3.1 主要機能

4. システムアーキテクチャ

4.1 全体構成

4.2 AWS リソース構成

4.3 AI エージェント設計

4.4 AI エージェント設計アプリケーションへの AmiVoice の組み込み

5. 音声認識エンジン: AmiVoice の技術

6. 他インダストリーへの応用可能性

7. まとめ

著者について

耐障害性ライフサイクル実践ワークショップ開催報告 & AWS WAF 実践ワークショップのご案内

ワークショップの概要

座学: 耐障害性ライフサイクルと Resilience FlyWheel

「壊れない」から「壊れても素早く回復する」へ

耐障害性ライフサイクルフレームワーク — 5つのステージで具体的に取り組む

Resilience FlyWheel — 継続的に回し続け、加速する

ワークショップ: たこ焼き注文システムで体験する耐障害性ライフサイクル

ワークショップの狙い

具体的に何を体験できるか

参加者からのフィードバック

まとめと次回のご案内

本ワークショップのキーメッセージ

第6回: AWS WAF 実践ワークショップ — AI時代のWebアプリケーション防御を学ぶ

著者

AWS で VMware のお客様の選択肢が広がった 1 年

VCF 9 を思い通りにデプロイ

新しい i7i.metal-48xl、AWS リージョンの拡大、より大規模な環境でスケール

Memory Tiering でクラスター密度を向上

Windows Server のライセンスをシンプルに

Amazon EVS で VMware ワークロードを保護・復旧

サイト間でネットワークとセキュリティを拡張

より広い選択肢を提供した 1 年間

次のステップ: VMware Explore 2026 で Amazon EVS をご覧ください

著者について

AWS Skill Builder で AI 駆動開発ライフサイクル (AI-DLC) を学ぼう: 日本語版学習コースが公開されました

コースの概要

AI 駆動開発ライフサイクル(AI-Driven Development Lifecycle, AI-DLC) とは

モジュールの一覧と概要

1. AI-DLC の概要: AI-DLC とは何か、なぜ必要なのか、AI-DLC の中核となる概念を学びます

2. 従来の SDLC (ソフトウェア開発ライフサイクル) からの進化: ソフトウェア開発の方法論の歴史を振り返り、なぜ AI 時代に「再構築」が求められるかを学びます

3. AI-DLC の原則: AI-DLC を定義する 9 つの原則を学びます

4. AI-DLC ワークフローとコラボレーション: AI と人間の継続的なワークフローと、チームのコラボレーションパターンを学びます

5. AI-DLC ベストプラクティス: 実践で検証された 7 つのベストプラクティスを学びます

6. AI-DLC の準備、測定: 組織で AI-DLC を始めるための準備と、成功の測定方法を学びます

7. インセプションフェーズ Deep Dive: インセプション (Inception) フェーズを深掘りします

8. コンストラクションフェーズ Deep Dive: コンストラクション (Construction) フェーズを深掘りします

Assessment: 全モジュール完了後に受験できる理解度確認テストです。合格すると AI-Driven Development Lifecycle Knowledge Badge を取得できます。

受講方法

まとめ

AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編

ロボットシステムの構成 — 2 台の CRX と 1 つの AI エージェント

設計 — 何をどこに任せるか

判断と動作の分離

インターフェース仕様の先行合意 — 座標系・単位・通信

自前実装の最小化

実装 — コーディングエージェントに任せる範囲の線引き

開発ルールの文書化

安全制約の先行実装

シミュレーションでの検証の必須化

安全要件の多層防護

まとめ

関連リンク

木村公哉（Kimura, Koya）

針原佳貴（Haribara, Yoshitaka）