従業員の家族を職場に招く「ファミリーデー」で、子どもたちに通信の仕組みを体験してもらうため、光ファイバーを使った音声通話装置を一から作りました。 この記事では、回路の試作やプリント基板・ケースの製作、人数分の量産、そして当日の実験教室の様子までをご紹介します。 はじめに AIロボット部とは 光ファイバーで「通信」を体験してもらう 通信装置を作る アナログ回路と格闘する プリント基板を作る ケースも3Dプリンターで作る そして量産へ…… 当日の様子 おわりに はじめに こんにちは、AIロボット部（社内サークル）部員の浅野秀平です。 普段はデジタル改革推進部で、社内のデータ分析の仕事をしています。 今回は、従業員の家族を職場に招き、普段働いている場所や仕事に触れてもらう「ファミリーデー」の企画の1つとして、子どもたちに「通信」を身近に感じてもらう体験教室を実施しました。 この記事では、その体験教室で使う実験装置を試作した過程から、当日の様子までをご紹介します。 AIロボット部とは AIロボット部は、ものづくりに興味のある社員が集まる社内サークルです。 普段はSlack上でゆるく情報交換をしたり、ハッカソンなどのイベントに参加したりしています。 これまでの活動については、以下の記事もご覧ください。 AIロボット部の活動記事一覧 光ファイバーで「通信」を体験してもらう 今年のファミリーデーでは、NTTドコモビジネスの事業とも深く関わる「通信」をテーマに、光ファイバーを使った音声通話の実験教室「ひかりでんわ」を企画しました。 コンセプトは、以下のようなものです。 私たちは普段、家族や友人と離れた場所にいても、電話やインターネットを通して当たり前のように会話をしたり、動画を見たりしています。 その「つながる」を支えているのが、通信の技術です。 この教室では、子どもたち自身の手で通信装置を組み立て、自分の声が「光」に変わり、光ファイバーを通って相手に届く仕組みを体験します。 「見て・作って・話して」楽しみながら、普段は意識することのない通信の仕組みや、私たちの暮らしを支える技術への興味を持ってもらうことを目指しました。 子どもたち自身に通信装置を組み立ててもらい、音が光になって伝わる様子を観察することで、ものづくりの楽しさと通信技術の面白さを体験してもらうのが狙いです。 通信装置を作る こちらが、今回製作した通信装置です。 仕組みは比較的シンプルです。 マイクから入った音声の電気信号を増幅し、LEDを光らせる LEDの光を、光ファイバーを通して反対側の光センサーへ届ける 光センサーで受け取った信号を再び増幅し、スピーカーから音として鳴らす つまり、声を一度「光」に変換し、光ファイバーの中を通してから、もう一度「声」に戻しています。 アナログ回路と格闘する 普段からArduinoなどのマイコンを使った電子工作には慣れていましたが、アナログ回路の経験はそれほどありませんでした。 そのため今回は、ChatGPTに回路について教えてもらいながら設計を進めました。 抵抗やコンデンサーの値を変えては試し、うまくいかなければまた回路を修正する、という作業の繰り返しです。 途中では、マイコンを使って音声をデジタル処理する方法も検討しました。 数日間の試行錯誤の末、光ファイバーの先につないだスピーカーから初めて自分の声が聞こえてきた瞬間は、かなり感動しました。 ちなみに当初は、テレビのリモコンのような赤外線LEDを使い、空間を飛ばして音声を送る方法も試していました。 しかし、どう調整しても1〜2m先へ安定して音声を届けることができず、最終的には断念しました。 もし同じような構成でうまくいった方がいたら、ぜひ教えてください。 プリント基板を作る 試作回路が動いたところで、次は回路を回路図に起こし、プリント基板を設計しました。 回路や基板データの詳細は、GitHubでも公開しています。 https://github.com/mikaka-robotics/hikari_denwa ケースも3Dプリンターで作る 基板を収めるケースはBlenderでモデリングし、3Dプリンターで製作しました。 今回特に工夫したのが、送信と受信を切り替える仕組みです。 本体中央には、送信用のLEDと受信用の光センサーが並んでいます。 中央にある水色のパーツをスライドさせると、光ファイバーの接続先が物理的に切り替わります。 同時に基板上の回路も送信／受信で切り替わるため、1つの操作で通信方向を変更できます。 なお、今回使用した光ファイバーは、本格的な通信用のものではありません。 安価で扱いやすい、照明・装飾用として販売されているプラスチック製の光ファイバーを使用しています。 そして量産へ…… 試作品が完成し、いよいよ参加する子どもたちの人数分を量産していきます。 ……が、ここで想像以上に大変なことに気づきました。 今回の基板は部品点数が多く、すべて手作業ではんだ付けすると、1枚を組み立てるだけで約30分かかります。 さらにケースにも3か所のネジ穴があり、3Dプリントしたケース一つひとつに、タップを使ってネジ山を切る必要があります。 今回の参加者は約50人。そして「電話」なので1人につき2台必要となり、用意する通信装置は合計100台です。 つまり、 基板も100枚。 ここからは、AIロボット部の部員総出による地獄の量産作業が始まりました。 ひたすら部品をはんだ付けし、ケースにタップを立て、組み立てる日々です。 途中からは、部品の取り付けやケース加工などを分担し、ちょっとした製造ラインのような状態になっていました。 それでも当日までになんとか必要な台数を完成させ、無事にファミリーデーを迎えることができました。 当日の様子 当日は、子どもたちに説明書を見ながら部品を組み立ててもらいました。 完成した装置を光ファイバーでつなぎ、最後は実際に会話してもらいます。 説明書を読みながら、 「これはどこにつけるんだろう？」 と、謎解きのように1つずつ部品を取り付けていきます。 そして、いよいよ完成した装置で通信実験です。 最初は「本当にこれで声が聞こえるの？」という様子だった子どもたちも、光ファイバーの先から相手の声が聞こえてくると、「聞こえた！」と驚いた表情を見せてくれました。 兄弟同士で話したり、親子で装置を挟んで会話したりと、それぞれ楽しみながら試してくれていました。 普段何気なく使っている「通信」は、音を別の信号へ変換し、離れた場所まで届け、再び音へ戻すことで成り立っています。 その仕組みを、自分で組み立てた装置を通して、少しでも実感してもらえたのではないかと思います。 おわりに 今回、一から実験装置を設計し、基板やケースを作り、人数分を量産して実験教室を開催するところまで、AIロボット部らしいものづくりができたと思います。 特に、実際に装置を使った子どもたちから「聞こえた！」という反応をもらえたのは、作った側としてもうれしい瞬間でした。 一方で、大量の基板を手ではんだ付けするのは想像以上に大変でした。 来年以降は準備をもう少し楽にするため、基板製造だけでなく、部品実装まで依頼できるサービスの利用も検討したいと思います。 今後もAIロボット部では、遊び心と技術を組み合わせたチャレンジを続けていきます。 次回の活動報告もお楽しみに！

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 9月に入り暑さもだいぶ和らいできましたね。秋の気配を感じる今日この頃ですが AI 関連サービスに多数の熱いアップデートが発表されております。また、今週の builders.flash では、9 月 2 日に生成 AI 関連の記事が 6 本公開されました。実際に動く仕組みの裏側を知りたい方は、ぜひご覧ください。 CAD の知識ゼロでも AI エージェントと自然言語で 3D モデリング — AWS Summit Japan 2026 展示の裏側 FreeCAD MCP サーバーを Kiro に接続し、自然言語の指示から 3D モデルを設計・出力する方法を紹介しています。CAD の専門知識がない方が、AI エージェントとオープンソースツールを組み合わせる際の入り口になります。 5人の AI 審査員が議論して優勝者を決める ! AWS Summit Japan 2026 Builders’ Fair「大喜利 Dojo」の裏側 Amazon Bedrock で回答生成と画像 OCR を行い、Amazon Bedrock AgentCore 上の 5 人の AI 審査員が採点・議論・投票する展示の構成を解説しています。AI エージェント同士の役割分担を体験に落とし込む例として楽しめます。 コードは一行も書かない。AI にタスク整理を任せる仕事術 ~ Amazon Quick のデスクトップアプリで始めるタスク自動管理 Amazon Quick のデスクトップアプリを使い、Slack、メール、カレンダーなどに分散したタスクを AI エージェントに見つけさせ、To-Do に整理する方法を紹介しています。定期実行と通知までコードなしで組み立てる実例です。 Amazon 社員 3.9 万人の日常業務を支える AI エージェント Kiro Crew の使い方大公開 ブラウザや Slack などから常駐実行できる Kiro Crew の活用例を紹介しています。Outlook の未読メール整理、定期ジョブ、メモリ、Skills を組み合わせ、判断は人に残したまま探す作業を自動化する考え方が参考になります。 AWS DevOps Agent の「スキル」を使いこなそう カスタム Skills とマネージド Skills の違い、発動条件となる説明文の書き方、調査時間を短縮する手順を解説しています。調査結果からエージェント自身に新しい Skill を作らせる運用方法も紹介されています。 「AI 現場監督『安全ヨシ！』」― AI に見守られながら作業する、フィジカル AI 時代のエッジ × クラウド エッジ上の視覚言語モデルで作業の前後関係を読み取り、リアルタイムに危険を警告し、Amazon Bedrock で記録全体を再監査・採点するデモを紹介しています。現場の安全支援とクラウド側の評価を分担する設計が見どころです。 それでは、8 月 31 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 2026年8月31日の週の主要なアップデート さまざまなニュース 「フィジカル AI 開発支援プログラム by AWS ジャパン」最終成果発表会を開催しました AWS ジャパンが 51 社を採択して約 6 か月支援したプログラムの最終成果発表会です。13 プロジェクト・14 社が、ロボットの動作データ、シミュレーション、GPU 学習、現場実証の成果を紹介しました。ZEALS 様の病院実証、FastLabel 様のシミュレーションデータ拡張、メルカリ様の検品自動化など、日本の現場技術と生成 AI を組み合わせる具体例が並んでいます。 2 週間で 12 万人規模へ – NEC が Claude Desktop on Amazon Bedrock で実現したセキュアな全社 AI 環境 NEC 様は、全社員が使える Claude Cowork の環境を、要件定義から全社リリースまで 2 週間で構築しました。Amazon Bedrock 経由で推論とデータを国内に閉じ、監査証跡やコスト管理も整備。2026 年 8 月 18 日時点で 11,000 名が利用しており、今後は AI エージェントの本番活用へ拡張する計画です。 AI-DLCで取り払った組織の壁 ― DeNAと取り組んだ分析業務領域での初事例 DeNA のヘルスケア事業部門にある DeSC ヘルスケア様は、分析企画部とデータサイエンス部など 24 名で 3 日間の AI-DLC Unicorn Gym に取り組みました。AI に要件定義書作成や集計を任せながら部門間の認識をそろえ、共有された Claude Code の Skills は 5 か月間の 1 件から、その後 2 か月で 6 件に増加。次は AI-BPR へ取り組みを広げています。 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション 手袋を外せない、騒音が大きい、レシピ変更が属人化するといったセントラルキッチンの課題に、AmiVoice と Amazon Bedrock AgentCore Runtime、Strands Agents を組み合わせました。調理スタッフは音声でレシピを進め、在庫を減算し、タイマーや工程メモを操作できます。Amazon DynamoDB と AWS Lambda に記録が蓄積され、現場の改善にもつながります。 【開催報告】AI エージェントは創薬研究をどう変えるか: 製薬企業向け Claude Code on AWS ワークショップ 10 社以上の製薬企業が参加したワークショップで、調査・分析から Web アプリケーションの構築までを Claude Code で実践しました。アンケートの総合満足度は 4.70 / 5.00。第一三共様では 92% の研究員が利用の影響を実感し、ＪＣＲファーマ様ではイベント体験から約 10 日で Amazon Bedrock 経由の環境をリリースしています。 構造化されたビジネスロジックとエージェンティック AI を組み合わせ、心地よい会話体験を届ける Amazon Connect Customer の agentic CX designer を使い、自然な会話や意図理解はエージェンティック AI に、本人確認やクレジット適用など正確さが必要な処理は決定論的なロジックに分担させる方法を紹介しています。REST と MCP の連携、テスト、ビルド、ロールバックまで一貫して設計する際の参考になります。 AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで 画像生成 AI による企画、Kiro と Blender による 3D モデリング、Design Doc と Steering を使ったクラウドアプリケーション開発を紹介しています。Mock-first 設計で実機がなくても開発を進め、短期間で展示を統合したプロセスを確認できます。 AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編 Amazon Bedrock AgentCore 上の AI エージェントが判断し、AWS IoT Core 経由で ROS 2 / MoveIt 2 のエッジ制御へ指示を渡す構成を解説しています。シミュレーション、安全制約、実機の検証を組み合わせ、Summit の 2 日間で障害物ピックを失敗ゼロにした考え方が学べます。 AWS Skill Builder で AI 駆動開発ライフサイクル (AI-DLC) を学ぼう: 日本語版学習コースが公開されました AWS Skill Builder に、AI-DLC の基礎からインセプション、コンストラクションの Deep Dive までを扱う全 8 モジュールの日本語コースが公開されました。無料で自分のペースで学べ、修了後の Assessment に合格するとナレッジバッジを取得できます。AI ツールを個別導入するだけでなく、開発プロセス全体を変えたい方に向いた教材です。 サービスアップデート サービスアップデート – エージェント基盤と Amazon Bedrock エージェントの検出とガバナンスを一元化する AWS Agent Registry の一般提供を開始 AWS Agent Registry が一般提供となり、組織内のエージェント、ツール、Skills、MCP サーバーなどを検索・統制するプライベートカタログとして利用できます。CloudFormation、Terraform、CDK、タグ、AWS RAM 共有、AgentCore の自動検出にも対応しました。既存の機能を見つけて再利用しやすくなります。 AWS Agent Registry のエージェントと MCP サーバーが Amazon Quick で利用可能に Amazon Quick から組織のレジストリにあるエージェントや MCP サーバーを検索し、接続情報を手入力せず数クリックで有効化できます。東京を含む Quick と AgentCore の提供リージョンが対象で、技術チームとビジネスユーザーの連携を簡単にします。 Anthropic の新しいフロンティアモデル Claude Fable 5.1 が AWS で利用可能に Claude Fable 5.1 が一般提供され、コーディング、科学研究、エンタープライズワークフロー向けの長時間タスクを扱えるようになりました。コードベース全体の作業やレビューを進め、行き詰まりを成功と誤報したり失敗テストを無効化したりする近道も抑えます。Amazon Bedrock と Claude Platform on AWS から利用できます。 Claude Fable 5.1、Anthropic の新しいフロンティアモデルが AWS GovCloud (US) で利用可能に Claude Fable 5.1 が規制産業向けの AWS GovCloud (US) にも提供されました。Covered Model として追加のデータ保持・安全性レビュー・アクセス制御の対象となり、Enterprise Frontier Safeguards によって顧客が管理するクラウド環境内にデータを保持して利用できます。 Amazon Bedrock Managed Knowledge Base が ServiceNow をネイティブデータソースコネクタとしてサポート ServiceNow のナレッジ記事やサービスカタログ、添付ファイルをクロールするネイティブコネクタが追加されました。メタデータ抽出と増分同期に対応し、対象ナレッジベースやカテゴリを sys ID で絞り込めます。社内 IT や HR のアシスタントを構築しやすくなります。 Amazon Bedrock Managed Knowledge Base が SharePoint、OneDrive、Confluence のデータソース向けユーザー管理セットアップを導入 既存のサードパーティー認証情報でサインインする 3LO 方式が追加されました。管理者に 2LO 用のサービスアカウントを用意してもらわなくても、SharePoint、OneDrive、Confluence のデータを数分で接続して試作できます。 Amazon Bedrock Managed Knowledge Base がデータソースコネクタの自動同期スケジュールをサポート ネイティブコネクタに日次・週次・月次の同期を設定できるようになりました。頻繁に変わるナレッジは日次、規程は週次、参照資料は月次というように、データの更新頻度に合わせて RAG の鮮度を保てます。 Amazon Bedrock の Web Search が AWS GovCloud (US-West) で利用可能に OpenAI GPT モデルが Web 情報を参照して回答をグラウンディングし、利用した出典を返す組み込みツールが GovCloud に広がりました。IAM で利用可否やリージョンを管理でき、リクエストデータを AWS 境界内に保ったまま、最近の出来事や最新リリースなど変化する情報を扱えます。 サービスアップデート – Amazon SageMaker AI と GPU Amazon SageMaker Unified Studio CI/CD がノートブックの昇格と AI 支援マニフェスト生成を追加 プロジェクトの接続、ストレージ、ワークフローを調べてデプロイ用マニフェストを生成する Agent Skill が加わりました。最小権限や環境変数を適用し、Notebook も開発・テスト・本番へ昇格できます。データチームが環境ごとの設定を手作業で整える負担を減らします。 Amazon SageMaker Unified Studio Workflows が Python および Bash オペレーターをサポート サーバーレスワークフローのキャンバスから Python 関数やシェルコマンドを直接実行できるようになりました。データ変換やスクリプト処理のために、別途 Lambda や ECS の実行環境を用意する必要を減らせます。既存のワークフローに処理を追加しやすくなるアップデートです。 Amazon SageMaker AI Batch Transform が G6e インスタンスをサポート 最大 8 基の NVIDIA L40S GPU を搭載する G6e を、永続エンドポイントを必要としない大規模バッチ推論に利用できます。S3 のデータセットに対して LLM や画像・動画・音声の拡散モデルを実行でき、米国、ムンバイ、ハイデラバードなどで提供されます。GPU を使うオフライン推論の選択肢が増えました。 サービスアップデート – Amazon Quick と Amazon Connect Amazon Quick で自然言語によるカスタムアプリケーションの構築が可能に 作りたいアプリケーションを自然言語で説明するだけで、Salesforce、Jira、Asana、ServiceNow、Microsoft 365 などのデータと接続した業務アプリを作成できるようになりました。既存の ID・認可・アクセス制御を引き継ぎ、データの変更も反映します。コードを書かずに、分断された表計算やツールを目的別アプリへ変えたい業務部門に適しています。 Amazon Connect Customer が agentic CX designer の一般提供を開始 ノーコードのキャンバスで、自然な会話や意図理解を AI に任せつつ、本人確認、承認、ルーティング、コンプライアンスなどは決定論的なステップで固定できます。設計、テスト、デプロイを同じ場所で行えるため、ビジネス部門がエンジニアリングへの引き渡しを待たずにセルフサービス体験を改善できます。東京を含む 9 リージョンで利用可能です。 Amazon Quick がコネクタ向けの新しいツール設定と Model Context Protocol (MCP) 同期を追加 管理者はコネクタ内の個別ツールを有効・無効化し、同意が必要な操作も設定できるようになりました。MCP サーバー側のツール追加や説明更新も同期されるため、承認済みの能力だけを提供しながら最新状態を保てます。 Amazon Quick Max を導入: Quick を最大限に活用したいパワーユーザー向けに利用量を 5 倍に Plus の 5 倍の利用量とストレージを持つパワーユーザー向けプランです。複数のエージェントやワークフローを同時に動かす利用者が、月途中の利用制限を気にせず Quick を活用しやすくなります。 サービスアップデート – その他の生成 AI 活用 Amazon WorkSpaces Applications が NVIDIA Blackwell GPU インスタンスのサポートを追加 Graphics G7 で NVIDIA RTX PRO 4500 Blackwell を利用でき、従来世代の G6 と比べて最大 2.1 倍のグラフィックス性能を発揮します。CAD、3D、科学可視化、動画編集、AI 支援設計などを高いフレームレートでストリーミングしたいチームに向いた選択肢です。 AWS MCP Server が AWS Lambda 関数向けのサーバーレス機能を追加 Claude Code や Kiro から、Lambda と API Gateway、EventBridge、S3、DynamoDB、SNS、SQS、Step Functions の接続関係をまとめて調査できます。7 日間の基準値との比較、エラー傾向、デプロイ設定、変更履歴、レイテンシを 1 回の呼び出しで確認でき、調査時のトークン消費も抑えます。追加料金なしで利用可能です。 AWS Transform が Amazon FSx for NetApp ONTAP の一般提供を開始 コンピュートやネットワークと同じ移行ウェーブで、ブロックストレージを FSx for NetApp ONTAP へ移行できるようになりました。中間ストレージや別ツールを組み合わせる工程を減らし、移行ワークフローを一本化できます。エージェントを活用した移行自動化を検討する際の対象範囲も広がります。 生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。3 つのコースから選べて、AWS クレジットの付与や技術支援も用意されています。ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

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