AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで

本記事は、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 つです。

1. 企画・設計・モデリング・実装・ドキュメントの全フェーズで生成 AI をどう使ったかの具体例
2. ジオラマステージ制作の舞台裏——3 回の方向転換と 3D プリントの試行錯誤から得た教訓
3. 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 つです。

1. 来場者が参加できる — 見るだけでなく触れる体験
2. AI の思考が見える — ブラックボックスではなく、判断過程を可視化
3. 毎回違う結果になる — 決められた台本の再生ではなく、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 枚をほぼ無加工で並べる」という設計です。

▲ 表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 週間で建物・小物あわせて数十パーツを完成させました。

▲ 表2: 主要パーツの作り直しの記録。一発では決まらない前提で、作り直しやすい仕組み（スクリプト生成）にしておいたことが効いた

走行路の設計 — 配達車両が迷わない道

配達車両（TurtleBot3 Burger という小型の自律走行ロボット）は、カメラではなく赤外線センサーで路面の白線をたどって走ります。派手さのない仕組みですが、2 日間確実に動き続けることを最優先にした選択です。道路側の設計要素は次の 3 つです。

• 白線 — 幅 30mm。黒地マット仕上げの道路面に敷き、センサーが検知する明暗差を最大化
• 停止線 — 3 つのセンサーが同時に白を検知する横断ラインで、配送先・積荷ポイントを識別
• 障害物検知 — 前方のセンサーが障害物を検知すると停止し、クラウドの AI エージェントに通知

▲ 図10: 走行路シートを敷いた状態（会議室での検証時）。白線・停止線・コーナーの曲率は、この面材に印刷して敷くだけで再現できる。ステージ 8 分割に合わせてシートも分割されている

道路幅は 250mm（車体幅 178mm + 左右の余裕 36mm）、コーナーは半径 200mm。この数値も机上で決めた後、実走で「曲がりきれるか」「白線を見失わないか」を検証して確定しています。障害物を検知した車両が停止する——この瞬間こそが、事前紹介ブログで紹介した AI エージェントの自律調査フローが動き出すトリガーです。

アプリケーション開発 — Kiro との二人三脚

システムアーキテクチャ — 3 レイヤー構成のおさらい

事前紹介ブログで解説したアーキテクチャを、実装の観点から一枚に整理します。設計原則は次の 3 つです。

1. 知性はクラウド — 状況判断・計画立案は LLM の推論力を活かしてクラウドで実行
2. 動作はエッジ — ロボットの動作計算やセンサー処理は、現場に置いた PC（エッジ）で実行
3. 通信断耐性 — クラウドとの通信が切れてもアームは安全停止し、復旧後に再開

▲ 図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 日間の運用でこの仕込みが効きました。

使用した主なサービス・フレームワーク

▲ 表3: クラウドアプリケーションの技術スタック

▲ 図12: 本番デモより。AI エージェントの指示を受けたロボットアームが障害物をつかみ、回収エリアへ移動させて道路を開通させる。このアーム制御の実装は Part 2 で詳しく解説する

まとめ

約 5 ヶ月間で「AI エージェントが現実世界で自律的に問題を解決する」デモを作り上げました。振り返って強調したいのは次の 3 点です。

1. 生成 AI は「作る対象」であり「作る道具」だった — 企画の可視化、シナリオの壁打ち、3D モデリング、コーディング、ドキュメントまで、AI を全フェーズに組み込むことで、少人数・兼務・実質統合 1 ヶ月という条件でも本番に間に合わせることができました。
2. 方向転換を恐れない — ミニチュアの街はコンセプトが 3 回変わりました。早く作って早く見る。紙上の評価より実物の説得力です。
3. プロセスの型が品質を守る — Design Doc と Issue で仕様と結合点を固定し、Steering で規約を明文化し、Mock で実機依存を断つ。AI に書かせる開発だからこそ、人間は「型の設計」に力を注ぐ価値があります。

Part 2（ロボット開発編）では、ROS 2 + MoveIt 2 によるアーム制御、クラウド連携、マーカーを使った精密な位置合わせ、つかむ動作の実装について詳しく解説します。クラウドの「判断」が物理世界の「動作」に変わる瞬間の作り込みを、ぜひご覧ください。

このブログは AWS Japan のソリューションアーキテクト 西田 光彦 、水野 貴博 が執筆しました。