LOG38HRI2026/1/16

薬剤搬送ロボットハコブくんのデジタルワイヤーフレームによる検証プロセス

ヒューマノイド時代の「用途開発」の最前線

2025年11月、内閣府（CSTI）はムーンショット目標3の抜本的方針転換を決定し、リソースを汎用自律人型AI（ヒューマノイド）の開発へ一本化することを発表しました。この劇的な変化に伴い、機体そのものの開発以上に、日本固有の現場（介護・医療・オフィス）へロボットをどう適応させるかという用途開発（Use-case Design）の重要性が急速に高まっています。

薬剤搬送ロボットハコブくんプロジェクトにおいて実機稼働イメージするために、デジタル空間での「極限まで抽象化されたワイヤーフレーム検証」を導入します。これは、見た目の装飾に惑わされず、人間とロボットの間合いや振る舞いというHRIの本質を科学的に設計するためのプロセスです。

※薬剤搬送ロボットハコブくんは技術検証用の仮想設定です。実用化目的ではなく、制御・UIデザイン・HRI（人間とロボットの相互作用）の本質を探求するコンセプトとして定義しています。

ロボティクスデザインワイヤーフレーム

Web/UIデザインにおいて、ワイヤーフレームが「情報の骨組み」を確認するように、ロボティクスにおいても物理的な骨組みのみを抽出した検証が必要です。

手法：Unity × ROS 2 によるシステム連携

ロボットの制御脳（ROS 2）と物理演算シミュレーター（Unity）を高度に連携させ、極限まで抽象化されたワイヤーフレーム環境を構築します。

設計要素：環境の「変数化」

空間の定義: 日本の標準的な医療施設やオフィスを模した1.8m幅の通路を立方体のみで構成。
存在の抽象化: ロボットと人間をそれぞれ色の異なるカプセルとして配置。
パーソナルスペースの可視化: 各カプセルの周囲に、人間が心理的抵抗を感じない境界線（衝突判定ゾーン）を等同心円状のラインで描写。

意図：「振る舞い」にフォーカスする

あえてハコブくんのキャラクター性や内装のテクスチャを一切排したのは、「ロボットの加減速」や「回避のタイミング」そのものが人間に与える心理的影響のみを純粋に抽出するためです。

デザインが生む「作業効率」を数値化する

現在、国内のロボティクス産業では、従来の生産技術ではなく、AI技術とシステム構築に通じたデザイナーが渇望されています。このシミュレーションでは、デザインを以下の「経営・現場視点の数値」へと変換します。

作業完了時間（TCT）の乖離: ロボットが最短経路を優先した際、人間側がどれだけ足を止め、現場全体の効率が低下したかの計測。
心理的侵害頻度: ロボットが人間のパーソナルゾーンを侵害した回数と時間。
予測可能性の評価: ロボットが予備動作（忖度）を見せた際、人間側の回避行動がどれだけスムーズになったかのデータ化。

物理世界を繋ぐ「フィジカルAI体験設計者」の価値

記事によれば、ムーンショットから放出される若手研究者は事業会社やベンチャーに好待遇で迎えられると見込まれています。その中で提供できる価値は単なるロボットの見た目の設計ではありません。

デジタルワイヤーフレームを用いて実機導入前のUXを定量的に検証し、開発の手戻りを最小限に抑えつつ、現場の信頼（ROI）を最大化するという、システム全体を見通すデザインプロセスそのものです。

極限までの抽象化を伝えるポイント

Webデザイナーのメタファーを活用: 採用担当者に「ワイヤーフレーム＝ロジックの検証」という共通言語を提示することで専門性が伝わりやすくなります。
技術的な厚み: UnityとROS 2の連携に触れることで、システム構築を担う技術者としての要件を満たしていることを示唆します。
「ハコブくん」という具体性: 抽象的な話だけで終わらせず、薬剤搬送ロボットという具体的なユースケースに紐付けることで、ビジネスインパクトをイメージさせます。

グラフ・図解の具体的なイメージ案

極限まで抽象化したワイヤーフレーム環境だからこそ純粋なデータの差異が際立つデザインを提案します。

比較グラフ案：HRIデザインによる現場効率の可視化

単なるロボットの速さではなく、現場（人間）を含めた全体の最適化を証明するグラフです。

グラフタイトル：HRI設計による作業阻害の低減効果

形式: 並列棒グラフ（Plan A：標準制御 vs Plan B：ハコブくん設計）

評価指標

人側の作業ロス時間: ロボットを避けるために人間が立ち止まったり遠回りした合計秒数。
心理的侵入頻度: ロボットが人間のパーソナルゾーン（半径1.2m）に侵入した回数。
予測可能性: ロボットの挙動から人間が次にどこへ行くかを直感的に理解できた割合（シミュレーション内の回避行動の滑らかさから算出）。

デザインのポイント: ワイヤーフレームのトーンに合わせ、背景はダークグレー、グラフはネオンカラー（Plan Aは赤、Plan Bはハコブくんのブランドカラーなど）を用いることで、「データ駆動型デザイン」の印象を強めます。

デジタルワイヤーフレーム図解：抽象化された「間合い」の設計

記事の手法セクションに挿入する、検証環境そのものの設計図イメージです。

物理世界のワイヤーフレーム：変数としての「空間」と「振る舞い」

Abstract Entities: ロボットと人間をそれぞれ単色のカプセルで描写。
Dynamic Zones: 各カプセルの足元に、リアルタイムで大きさが変化する心理的境界線を半透明の同心円で描画。
Trajectory Lines: ロボットが数秒後に通過する予定の予測経路を床にプロット。

キャプションの意図: 装飾を削ぎ落とし、カプセル同士の距離・速度・タイミングという変数のみにフォーカスすることで、医療現場において最も重要かつ繊細な信頼の間合いをロジカルに設計しています。

ハコブくん特有の評価：忖度のROI

ハコブくんが進捗管理表で掲げているあえて動かない設計の価値を裏付ける図解です。

図解タイトル：「待機」がもたらすシステム全体のスループット向上

形式: タイムライン（ガントチャート風）の比較図
Plan A (Efficiency First): ロボットが強引に進み、通路で人間とお見合い（デッドロック）が発生。結果、両者が停止し合計時間が伸びる様子。
Plan B (Hakobu-kun HRI): ロボットが5m手前で人間を検知し、通路の端で待機。人間は止まることなく通過でき、最終的な現場全体のタスク完了時間はPlan Bの方が短くなる様子。

ROS 2とUnityを連携させ「動くワイヤーフレーム」を構築

システムアーキテクチャの設計

まず、ROS 2とUnityの間でデータをリアルタイムにやり取りするための通信の架け橋を構築します。

通信プロトコル: ROS-TCP-Connector（Unity公式）を使用するのが現在の標準です。
座標系の変換: ROS 2は「右手系（Z軸が上）」、Unityは「左手系（Y軸が上）」という異なるルールを持つため、座標変換ロジックを正確に挟む必要があります。

変換行列の定義:
UnityからROSへの変換は、以下の行列を用いて座標の入れ替え（YとZの交換）を行います。

1	0	0
0	0	1
0	1	0

メッセージ定義: 速度制御のための geometry_msgs/Twist や、周囲を検知する sensor_msgs/LaserScan など、ROS 2の標準メッセージを用いてデジタル空間の情報を同期させます。

極限まで抽象化された環境の構築

ハコブくんの検証に最適化された、変数を制御しやすい環境をUnity上に作ります。

Grid Systemの導入: 床に1m間隔のグリッドを敷き、距離感を視覚化します。
Primitive Assetsの配置: ハコブくんを物理演算を持つシリンダーとして配置。
看護師/歩行者: NavMeshAgentをアタッチしたカプセルとして配置。

Prototyping Shader: 陰影やテクスチャを排し、エッジのみを強調したワイヤーフレーム・シェーダーを適用し、検証の意図（振る舞いへの集中）を視覚的に伝えます。

ロボットの実装と制御

ハコブくんの身体性をUnity上で再現します。

URDFのインポート: Unity Robotics HubのURDF Importerを使用し、ハコブくんのCADデータをシミュレーション用モデルに変換します。
Sensor Simulation: UnityのRaycast機能を用いて、2D LiDARのデータをシミュレートし、ROS 2側へパブリッシュします。

Odometry: 車輪の回転数から、現在の自己位置を算出します。

Control Loop: ROS 2側のナビゲーションスタック（Nav2）からの指示を、Unity上のハコブくんが忠実に実行するループを確立します。

定量評価システムの実装

C#を用いて、検証データを自動収集する仕組みを作ります。

計測項目	実装方法	ビジネス価値
作業ロス時間	人間アバターが停止・回避した時間を累積	現場の生産性低下を数値化
接近距離	`Vector3.Distance`で毎フレーム最小値を記録	安全性と心理的障壁の評価
経路の乖離率	最短経路と実際の移動経路の差を積分	アルゴリズムの効率性を証明

CSV出力スクリプトの例（C#）

using System.IO;
using UnityEngine;

public class MetricsLogger : MonoBehaviour {
    void SaveMetrics(float timeLoss, float minDist) {
        string path = Application.dataPath + "/MetricsLog.csv";
        string content = $"{Time.time}, {timeLoss}, {minDist}\n";
        File.AppendAllText(path, content);
    }
}

なぜ極限の抽象化が必要なのか

ハコブくんの検証において、ビジュアルの作り込みを捨て、カプセルと立方体のみのワイヤーフレーム環境を構築しようとしたのには、2つの戦略的意図があります。

「視覚的ノイズ」を排し、HRIの本質を抽出するため

医療現場におけるロボットへの信頼は、見た目の可愛さだけで作られるものではありません。むしろ、多忙を極める看護師が直感的にこのロボットは自分の動きを察して、道を譲ってくれると感じる間合い（フィジカルAIの振る舞い）にこそ宿ります。

もし、精巧な3Dモデルやリアルな病院の内装を配置してしまうと、検証者の意識は「外見の好み」や「壁の色」といった非本質的なノイズに奪われてしまいます。カプセル同士の相互作用に絞り込むことで、「加減速のタイミング」「進路変更の角度」「停止の距離」という、UXを決定づける純粋な変数のみを研ぎ澄ますことが可能になると考えました。

「不確実性」を高速に解消し、手戻りを最小化するため

現在のロボティクス開発は米中との猛烈なスピード競争の中にあります。高精細なシミュレーターを構築するには膨大な時間がかかりますが、ワイヤーフレーム環境であれば、通路幅の変更やアルゴリズムの調整を数分単位で回すことができます。

ハコブくんにおいて、この抽象化された環境で何百回ものすれ違いテストを自動実行します。その結果、実機を製造する前のプロトタイプ段階であえて動かない（忖度する）という設計が、現場全体の作業ロスを最小化するという確信（データ）を得ることが可能になります。

見えない信頼をエンジニアリングする

抽象化は、情報の欠如ではなく、価値の凝縮です。

フィジカルAI体験設計者として、このワイヤーフレーム環境をエンジニアと共通言語で対話するための設計図そして経営層に投資対効果（ROI）を示すためのエビデンスとして活用します。