研究と社会

ロボットが動く前に、利用者の年齢などで動作の可否を判定する。ドコモが「Physical AI連携基盤」を開発

NTTドコモが2026年10月27日、利用者のAIエージェントとさまざまなロボットをA2Aプロトコルでつなぐ「Physical AI連携基盤」を開発したと発表した。年齢などの属性と利用場面ごとのルールを照合して許可されない動作を実行前に止め、誰の指示で何を動かしたかを記録する。11月18日からのNTT R&D FORUM 2026でデモを展示する。

飲食店で、客が自分のAIエージェントに注文を伝える。配膳ロボットが動き出す前に、その注文を運んでよいかを誰かが判定する。客が未成年ならお酒は運ばず、アレルギーがあればその料理も出さない。NTTドコモが2026年10月27日に発表した「Physical AI連携基盤」は、この判定をロボットの手前に置く仕組みで、同社はこうした飲食店での配膳を将来の利用例に挙げている。同じ内容のリリースはPR TIMESからも配信されている。

ドコモはこの基盤を、人が日常で使うAI(同社の言う「パーソナルエージェント」)とさまざまなロボットをつなぎ、人と同じ空間でロボットが安全かつ快適に動くためのものと説明する。デモは11月18日から始まる「NTT R&D FORUM 2026」で展示される。

Physical AI連携基盤の技術概念図。ユーザーの属性情報とタスク依頼がパーソナルエージェントを経てA2A Gatewayに届き、権限チェックで許可・拒否を分け、メーカーの異なるロボットにつなぐ(NTTドコモ)

連携・制御・配慮の3つを1つの基盤に

リリースは、人の生活空間でAIとロボットを組み合わせるときの課題を3つ挙げる。ロボットごとに接続方法が違い、個別開発が要ること(連携)。利用者や場面に応じて、その動作をしてよいかを判断して止める仕組みがないこと(制御)。ロボットの動きが人に不安や不快感を与えること(配慮)。基盤はこの3つに対応する機能を1つにまとめた。

機能リリースの説明開発
連携エージェント同士をつなぐ標準プロトコルA2Aで、パーソナルエージェントと多様なロボットを接続する既存のA2Aを利用
制御(権限制御)年齢などの属性と利用場面ごとのルールを照合し、許可されない動作は実行前に止めるドコモ独自
制御(動作履歴の追跡)いつ、どの利用者の指示で、どの動作を実行したかを記録するドコモ独自
配慮(EQ)周囲の状況に合わせ、人に不安や不快感を与えない動作を自動で生成して実行するドコモ独自

判定を担うのは、基盤の中核にある「A2A Gateway」だ。利用者がパーソナルエージェントに指示を出すと、Gatewayが属性情報とルールを照らし合わせ、許可された指示だけをロボットに送る。属性情報は基盤の中で管理し、ロボットには動作の指示しか渡さない。ロボットの側は、客が何歳かを知らないまま「このテーブルにこの皿を運ぶ」という命令だけを受け取ることになる。

概念図には、ロボットやエージェントの「Agent Card」(自己紹介や名刺にあたるデータ)を登録するレジストリも描かれている。登録する側として社内技術者と社外の両方が示され、既存サービスやMCP(Model Context Protocol)のツール、他社のエージェントも「A2A対応のみで接続可能」とされる。制御の欄には「段階的な権限委譲」「追跡ログ」「ユーザー属性に基づく動的判定」と並ぶ。

連携・制御・配慮の関係図。連携の「つなぐ部分は業界標準A2Aが担う」に対し、制御と配慮は「A2Aにはない仕組みでドコモが独自開発」と書かれている(NTTドコモ)

A2Aは「何を許すか」を実装に委ねている

A2A(Agent2Agent)は、Googleが2025年4月9日に発表したエージェント間通信のオープンなプロトコルだ。エージェントはJSON形式の「Agent Card」で自分にできることを公開し、依頼する側はそれを読んで適した相手を選ぶ。HTTPやJSON-RPCといった既存の規格の上に組まれている。同年6月23日にはLinux Foundationのプロジェクトになり、特定の企業に依存しない運営に移った。仕様の最新版は1.0.0である。

A2Aの仕様は、認可の中身を決めていない。タスクの途中で追加の認可が必要になったことを示す状態は定義しているが、その認可の範囲や表現、有効性、取り消しの意味は「定義しない」と明記し、実装や拡張の側で決めるよう求めている。つまり、つなぐ規格はあっても、「この利用者にこの動作を許すか」を決める層は各社が作る必要がある。ドコモが独自開発と位置づけた権限制御は、ちょうどこの空白に当たる。

ロボットにAIを載せる側でも、安全を何層かに分けて考える流れがある。Google DeepMindは2025年3月のGemini Robotics発表で、衝突回避などの低レベルの安全制御と、文脈の中で行動が安全かを判断する「意味的な安全」を分け、自然言語で書いた規則(ロボット憲法)でふるまいを導く研究や評価用データセット「ASIMOV」を示した。こちらはモデル自身に判断させる方向で、ドコモの基盤はロボットの外、指示が届く手前の関所で判定する。両者は排他ではなく、重ねて使う層と見るのが自然だ。

権限制御・動作履歴の追跡・周囲状況に応じた振る舞い生成の図解。許可・拒否の結果はログとして記録される(NTTドコモ)

「配慮」は前日の高EQ音声対話とつながる

配慮の機能に付いた「EQ」は、ドコモが会話AIで先に打ち出していた言葉だ。前日の10月26日には、AIに「EQ(感情指数)」の要素を加えるための評価指針「AI EQ+1 Framework」と共通設計図「EQリファレンスアーキテクチャ」、4つの要素技術を発表している。要素技術には、場面に応じて同調する内容と禁止する内容を判断する「EQガードレール技術」が含まれ、適用先にはカスタマーサポートや介護、教育が挙がる。

10月26日の発表は表情や声のトーン、話の内容から相手の状態を判断する対話の技術で、今回は同じ「EQ」という言葉をロボットの動き方に使っている。図解の「将来」の欄には、人と同じ空間でタスクをこなしながら、周囲の人に配慮して動きを変えるロボットが描かれている。

飲食・介護・家庭の現場で確かめたいこと

公表されているのは、仕組みの構成と飲食店での将来の利用例、今後の進め方までだ。現場に入れる側が知りたい点の多くは、まだ発表資料にない。

  • どのロボットで動くか: デモに使う機種やメーカー、既存の配膳ロボットがA2Aに対応するための改修の規模
  • 判定にかかる時間: Gatewayを経由することで、指示からロボットが動くまでにどれだけ遅れるか
  • ルールを誰が書くか: 利用場面ごとのルールを店舗、施設、メーカー、ドコモのどこが作り、誰が承認するか
  • 属性情報の扱い: 年齢やアレルギーをどこから取得し、利用者がどう同意し、どこに保存されるか
  • 止められなかったとき: 判定をすり抜けて誤配膳が起きた場合に、店、ロボットメーカー、基盤提供者の責任をどう分けるか

飲食店の例でいえば、基盤が使う「年齢」が自己申告なのか、本人確認を経た情報なのかで、判定の重みは変わる。介護施設なら、食事の形態や制限、移動の介助範囲が利用者ごとに違い、ルールは利用者単位で細かくなる。家庭では、子どもが親のエージェントを通じて指示した場合にどの属性で判定するかが問われる。どの場面でも、記録された動作履歴は事故後の検証に使える一方、誰がいつ閲覧できるかの設計が要る。

同じ10月27日には、KDDIとELYZAがフィジカルAIの新会社ELYZA Roboticsの事業開始を発表し、KDDIグループとして2030年度までに1,000台以上のロボットを現場に入れる目標を掲げた。こちらはロボットの「頭脳」となる基盤モデルと現場導入が軸で、ドコモはエージェントとロボットの間の交通整理から入った。10月15日・16日には東京・大手町で、ロボットが人に飲み物を手渡す実証も予定されていた。人の手元まで物を運ぶ場面が増えるほど、運ぶ前に「この人に、これを渡してよいか」を確かめる層の出番は増える。

ドコモは今後、基盤の社内展開、ロボットメーカーとの共同研究、さまざまな事業者との実証を視野に、実用性を検証するとしている。武蔵野のブースで、ロボットがどの指示で止まり、どう人をよけるのか。ルールを書く人の姿まで見えてくると、この基盤を店や施設に置いたときの風景が描きやすくなる。


出典