現場をAIで動かす「フィジカル AI」の組み込み設計の考え方【SORACOM Discovery 2026】

現実世界をAIで動かす「フィジカル AI」が注目される一方、エッジかクラウドか、どう設計すべきか悩む声も多く聞かれます。本セッションではロボットアームと音声AIのデモを題材に、実装手法を考える前に必要な「フィジカル AI」の基礎と設計の考え方、モデル更新や通信を含めた全体アーキテクチャの構成を解説します。

株式会社ソラコム ソリューションアーキテクト 服部 政洋

Transcript

1. 現場をAIで動かす「フィジカル AI」の 組み込み設計の考え方 株式会社ソラコム Solutions Architect 服部 政洋 (masa)
2. 自己紹介 株式会社ソラコム / Solutions Architect 服部 政洋 (masa) お客様のIoTシステム企画・開発の技術支援を担当 経歴: HWベンダー、クラウド事業者、SaaSなどの 技術営業畑を10数年経て現職 駐在主夫歴 1.5年、大阪生まれ大阪育ち Facebook, X: @toolyee
3. 本日のハッシュタグ #SORACOM 使用例 @SORACOM_PR fb.com/soracom.jp youtube.com/@SORACOM_Japan instagram.com/soracom.official 最新情報は #SORACOM で検索！
4. フィジカル AI = ロボ？自動運転？
5. 人間の行動 “OODA ループ” とフィジカル AI 現実を センサー・カメラ フィジカル AI の 一部分 IoT で デジタル化 見る 考える 物理世界 IoT 領域 基盤モデル (LLM・VLA) フィジカル AI 物理を ロボット・モビリティ 物事を 動かす 行動を IoT で 遠隔操作 決める AI エージェント デジタル空間 AI 領域
6. フィジカル AI 現実世界を動かす力に AI を使う考え方 エッジ AI クラウド AI データの発生源で使う データの集約先で使う 使用する AI の場所やシステムの作り方
7. サービスや製品に生成 AI を組み込む アーキテクチャー セルフホスト型 プラットフォーム型 API 型 基盤モデルを自前※で運用・利用 クラウドプロバイダーが運用・提供 開発元が直接 API を提供 • • • Llama (Facebook) Phi (Microsoft) DeepSeek [基盤モデル] データの完全なコントロールが可能、 ネットワーク接続に依存しない環境 ※ ローカルデバイス または IaaS クラウド AI エッジ AI • • • Amazon Bedrock Azure OpenAI Service Vertex AI (Google Cloud) 複数の基盤モデルや AIOps・ガードレール等の 非機能要件向けの機能も利用可能 • • • OpenAI API Anthropic API（Claude） DeepSeek [API] 最新の基盤モデルがマネージドで 提供され、API 呼び出しだけで 即時利用 クラウド AI
8. AI PET (クラウド AI) との “しりとり” 1回の応答に2-3秒かかっている (最短で2秒台前半) デバイス: Rider-Pi Two Wheel-legged Robot (Raspberry Pi CM5 core module) https://category.yahboom.net/products/rider-pi WebRTC – 閉域網 こんにちは！ API コンニチハ！ ユーザー ロボット LTEルーター SORACOM 通信・会話 制御サーバー AI, LLM
9. 音声認識を用いたフィジカル AI の アーキテクチャー プロンプト 入力 • マイク • カメラ ASR (自動音声認識) etc … 出力 ローカルで完結？ クラウド越し？ その理由は？ • スピーカー • アクチュエーター etc… LLM 認識と推論 音声や行動の生成 物理世界 デジタル空間 IoT 領域 AI 領域
10. 遅延の構造を理解する 無線＋クラウド経由で どう遅延が積み重なる？
11. 遠隔操作の遅延を比べる ３つのケース ① ローカルで直結 ローカル 完結 ② クラウド越し – 電波良好 ユーザー ロボット ユーザー ロボット ③ クラウド越し – 電波不良 クラウド 越し LTEルーター SORACOM 制御サーバー
12. ケース ① ローカルで直結 5ms 前後、遅延を感じない
13. ケース ② クラウド越し – 電波良好 50ms 前後、わずかな遅延
14. ケース ③ クラウド越し – 電波不良 まれに500ms 前後の遅延 あるいは制御信号が不達 (UDPの為) 始動しない or すぐに静止しない
15. 遅延を比べてみると… ローカル 完結 ユーザー ロボット ① ローカルで直結 →遅延が無視できる ② クラウド越し – 電波良好 →距離の遅延が発生 ③ クラウド越し – 電波不良 →距離と電波環境の遅延が発生 50-60ms + 通信不良時の処理遅延 クラウド 越し 距離の遅延が許容でき、安定した通信が確保できるなら、クラウド AI も検討できる そうではない場合は、エッジ AI を検討する。
16. AI PET では、どう対処していたか ・WebRTC通信 → 音声ストリーミング+パケットロス耐性があり低遅延 ・SORACOM Canal で閉域網通信 → インターネット区間を排除し通信を安定化 ・推論処理は OpenAI Realtime API → 音声処理(STT/TTS)とLLM を一元的に処理 ・デモ用の会話区切りの調整 → 一問一答を想定し短め (300ms) の無音検出で区切る ・短めのタイムアウトで早めに処理を停止 → 電波不良時には早めに諦めて安全側に倒す 1回の応答に2-3秒かかっている (最短で2秒台前半)
17. “全体” を見て、決めるべきアーキテクチャー クラウド 越し ローカル 完結 ネットワーク 上下 クラウド上での 推論時間 100 ms < 2000 ms ローカル上での 推論時間 = 2.1 秒 = ?? 秒 2.1秒以内で、同レベルの推論が可能か？ • 実現するためのハードウェアスペックは？コストは？ • 得られる即応性・自律性とのトレードオフを考えよう
18. フィジカル AI にとって… どのクラウドがいいの？ どの AI がいいの？
19. 進化し続ける AI を業務やサービスに用いる考え方 どの AI が 適しているのか？ どうやって AI を 更新するのか？ 進化する技術を扱うなら 更新の仕組みが必要 精度を上げたい コストを下げたい 多くのことをやらせたい
20. サービスや製品に生成 AI を組み込む アーキテクチャーと実装要素 セルフホスト型 プラットフォーム型 API 型 基盤モデルを自前※で運用・利用 クラウドプロバイダーが運用・提供 開発元が直接 API を提供 • • • Llama (Facebook) Phi (Microsoft) DeepSeek [基盤モデル] AI を エッジへ置く場合 更新の仕組み + 通信環境 • • • Amazon Bedrock Azure OpenAI Service Vertex AI (Google Cloud) • • • OpenAI API Anthropic API（Claude） DeepSeek [API] AI を クラウドへ置く場合 API 呼び出し + 通信環境
21. フィジカル AI に必要な通信の要件とは？ 大容量 マルチキャリア セキュリティ 管理 基盤モデルの配布や HD 画像送信 Wi-FI が無くても クラウド AI 閉じてる ネットワーク 1回線から Web / API で制御 フィジカル AI の通信環境は SORACOM で揃います
22. あらゆるIoTデバイスにネットワークレベルのセキュリティを VPG トラフィックフィルタリング機能 WiFi ファイバー 衛星通信 インターネット上 の業務システム 許可通信先をルールで定義 ドメイン名での指定もサポート SORACOM Arc Private Fiber オンプレミス VPG 5G 4G LTE 3G 2G ルールに含まれな い通信をブロック クラウド SORACOM Air ドメインルール IPルール クラウド
23. フィジカル AI の組み込み設計のポイント フィジカル AI とは 現実世界を動かす力に AI を使うこと • • • • • エッジ AI でもクラウド AI でもフィジカル AI はできる 遅延の構造を理解してクラウド AI とエッジ AI を検討する クラウド AI の遅延を感じさせない打ち手 (技術+ユーザー体験)を工夫 AI は更新し続ける必要があるため通信が不可欠 SORACOM は通信の、経路・セキュリティ・分析がコントローラブル フィジカル AI 向け「大容量・つながる・安心の通信」 ぜひご相談下さい！
24. IoTの「つなぐ」を簡単に Making Things Happen for a world that works together