こんにちは😺アプリケーションサービス部の山本です。 いつも読んでくださり、ありがとうございます！ ALB のラウンドロビンは「どこ」で行われるのか 前提：load balancer node とは 結論：振り分け先は 2 か所で決まる 1. ① どの load balancer node に届くのか node は AZ ごとに 1 つ、ではない どの IP を使うかを決めるのはクライアント DNS 応答に載るのは最大 8 個 Route 53 はどこに登場するのか 2. ② node の中で何が起きるのか ターゲット選択は 2 段構え ラウンドロビンの定義 他のアルゴリズムと注意点 3. クロ…

本記事は 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: 企画からステージ制作、アプリケーション開発まで Physical AI – AI エージェントが現実世界で「見て、考えて、動かす」自律オペレーションの実現 Remote AWS Development Station (RADS) 著者について 河田 武之（Takeyuki Kawata） 河田 武之（Takeyuki Kawata）は、製造業のお客様をご支援しているソリューションアーキテクトです。電機メーカーやロボットベンチャーでロボット開発に携わったのち AWS に入社し、現在も Physical AI の領域で、VLA モデルの学習からシミュレーション、実機検証まで自ら手を動かしています。 大前 遼（Ryo Omae） 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習やロボティクスで、最近は Physical AI に注力するあまり、部屋にロボットが溢れています。 西亀 真之（Saneyuki Nishigame） 西亀 真之（Saneyuki Nishigame）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。好きな領域は IoT とロボットで、Physical AI に注力しています。 原田 裕平（Yuhei Harada） 原田 裕平（Yuhei Harada）は、製薬業界のお客様を中心にご支援しているソリューションアーキテクトです。技術領域では Physical AI や AI for Science を軸に、最近は自律開発や自律実験など、AI の自律性をどこまで高められるかの実践に取り組んでいます。

はじめに デジタルテクノロジー戦略本部 AI戦略室のT.Sです。 2026年7月、オーストラリア・メルボルンで開催されたSIGIR 2026（49th International ACM SIGIR Conference on Research and Development in Information Retrieval）とICTIR 2026（ACM Conference on Innovative Concepts and Theories in Information Retrieval）に参加してきました。学生時代に取り組んでいた研究の成果をICTIRで発表するとともに、SIGIRでは世界中の研究者や企業が発表する最新の研究に触れることができました。 今回の記事では、現地の雰囲気や印象に残った研究、そして実際に参加して感じたことを紹介します。 SIGIRとは？ SIGIRは、情報検索（Information Retrieval: IR）分野を代表する国際会議の一つです。 検索エンジンやレコメンドシステム、RAG、LLMを用いた検索技術など、私たちが日常的に利用している情報サービスを支える最先端の研究成果が発表されます。 2026年はオーストラリア・メルボルンで開催され、会場には世界各国から多くの参加者が集まりました。会場には大学の研究者だけではなく、企業研究者も数多く参加しており、アカデミアと産業界が密接につながっていることを実感しました。 印象に残った発表 今回聴講した発表の中で、特に印象に残ったのがLinkedInによる Policy-Grounded Dynamic Facet Suggestions for Job Search という発表です。 求人検索では、「Data Scientist」や「Software Engineer」のような短い検索クエリが多く、検索キーワードだけからユーザーの本当の意図を理解することは簡単ではありません。 例えば、「AIエンジニア」という検索でも、 新卒なのか 経験者なのか 勤務地はどこなのか どの技術領域を求めているのか によって、ユーザーが求める求人は大きく異なります。 この発表では、検索ランキングモデルを改善するだけではなく、ユーザー自身が検索意図を具体化できる仕組みを導入していました。具体的には、検索窓の下にユーザーの特徴や入力した検索クエリに応じた動的なファセット（検索条件候補）を表示します。ユーザーが提示された条件を選択すると、その情報が検索条件へ追加され、より明確な検索意図で求人を探せるようになります。 私が特に興味深いと感じた点は、「検索システムがユーザーの意図を一方的に推測する」のではなく、「ユーザーとのインタラクションを通じて検索意図を明確化する」という考え方です。検索技術というとランキングモデルや検索アルゴリズムに注目しがちですが、良い検索体験を実現するためには、ユーザーがどのように情報を探すのかまで含めて設計することが重要だと感じました。求人サービスにおいては、ユーザーと企業のより良いマッチングを実現することが重要です。その観点でも、このような検索意図を引き出す仕組みは非常に参考になる取り組みだと感じました。 ICTIRでポスター発表 SIGIR開催後には、併催国際会議であるICTIRにも参加しました。私は、学生時代に取り組んだモデルマージを情報検索分野に応用する研究について、ポスター発表を行いました。 本研究では、各ドメイン向けに個別に学習したDense Retrieverをモデルマージによって統合することで、複数ドメインに対応可能な単一のDense Retrieverを構築できるか検証しました。 発表では、 モデルマージの有効性 Mixture of Expertsとの違い ドメイン数を増やした場合の性能変化 などについて議論を行いました。 自分の研究内容を英語で説明し、質問やコメントをいただきながら議論できたことはとても良い経験になりました。 メルボルンの街並み 学会期間中にはメルボルン市内も少し散策しました。 街中には歴史ある建築物と近代的な高層ビルが共存しており、とても魅力的な都市でした。 参加して感じたこと 今回で海外での研究発表は2回目でした。日本生まれ日本育ちの私にとって、英語で自分の研究内容を伝え、海外の研究者と議論することは決して簡単なことではありませんでした。それでも、自分の研究についてさまざまな視点から意見をいただいたり、世界中の研究者による最新の研究成果を直接聞いたりできたことは、非常に貴重な経験となりました。 またSIGIRでは、検索とLLMの融合がさらに加速していることを強く感じました。今回は、Deep Researchに関連する研究をはじめ、検索技術にAgentやReasoningを取り入れた研究が数多く発表されていました。情報検索の分野も新たな技術が登場するたびに形を変えていることを実感しました。 おわりに SIGIR・ICTIRへの参加は学生時代に取り組んだ研究の発表が主な目的でしたが、企業に勤めるデータサイエンティストとしても大きな学びになりました。世界中の研究者が取り組む課題や最新技術を直接知ることで、自分自身の視野が大きく広がったと感じています。今回得た知見を今後の業務に活かしながら、引き続き検索・推薦・生成AI分野の技術をキャッチアップしていきたいと思います。 最後までお読みいただき、ありがとうございました。