最初の問いは、どのロボットを買うかではありません
執筆: Sebastian Schmidt
サービスロボットのメーカーは、欧州市場、とりわけ医療分野への参入を望んでいます。需要は確かに存在します。病院は搬送業務や来訪者案内、案内対応での負担軽減を求めています。ハードウェアはその要求に応えられる水準にあります。ナビゲーション、積載量、稼働時間、製造品質は、すでに臨床現場の日常運用を支えられる段階に達しています。導入が進まない理由は、ほとんどの場合、機器そのものにはありません。
その理由は構造的に機器の外側にあります。現在のロボットソリューションのアーキテクチャと運用モデルは、機器が単独で動作し、そのデータをメーカーのクラウドで管理する市場を前提に発展してきました。そうした市場では、それは合理的な選択です。しかし欧州の病院運用はそれとは異なります。そこでのロボットは、エレベーター、ドア、入退室管理システム、病院のITシステムに接続された、機微な環境の中の一つのITシステムであり、データの流れを追跡でき、権限が文書化されていることが求められます。このギャップはロボティクス自体にあるのではなく、その上位にあるレイヤーにあります。
私たちが医療機関やシステムインテグレーターと話す際、ほぼ毎回同じ二つの問いが出てきます。第一に、ロボットと施設の間に、なぜ追加のソフトウェアレイヤーが必要なのかということ。第二に、ロボットメーカーが機器に付属させているソリューションを、そのまま使わない理由は何かということです。どちらも当然の問いであり、この記事ではそれぞれを、問いを投げかける二つの読者層に向けて別々にお答えします。Athegusは、TH Deggendorf(THD)発の研究プロジェクトSMART FOREST 5G Clinicsを母体とするスピンオフ企業です。私たちのプラットフォームAxionaは2023年から臨床現場で稼働しており、独立した査読を経た6件の論文でその成果が示されています。
医療機関の皆様へ
ロボティクス導入の検討で最初に問うべきは、どのロボットを買うかではありません。運用がどうあるべきか、つまりどの業務をロボットに任せるのか、そのためにどのシステムに接続する必要があるのか、誰がロボットに指示を出せるのか、そして事後に何を示せなければならないのかということです。ここが定まれば、機種選定は業務内容・寸法・適合性という技術的な検討事項にとどまります。この順序を逆にすると、最初に導入した機器が、その後の運用のあり方そのものを決めてしまいます。
効果はどこで生まれるか
廊下を走行するロボットは、それだけでは負担軽減にはなりません。効果が生まれるのは、ロボット / 建物設備 / ITが接点を持つ場面です。業務システムから発注が届くことで搬送が始まります。エレベーターの呼び出しが許可されているから3階に到達できます。防火扉の制御システムが開放するから通過できます。入退室管理システムがロボットを認識しているから検査室への立ち入りが認められます。そして受け渡しが記録されているから検体の所在を追跡できます。これらはすべて、機器そのものの外側にあるポイントです。
だからこそ、この追加レイヤーはそれ自体が目的なのではなく、こうした接続を一度構築すれば、それ以降に導入するすべての機器に適用できる場所なのです。エレベーター、ドア、入退室管理、HISとLIS、ロールと権限、ログとレポーティングは一度接続すれば足り、ロボットの機種ごとに構築し直す必要はありません。これにより、混合フリートが日常運用で必要とする発注管理・権限管理・レポーティングの一元化も、稼働している機種を問わず実現します。
このアプローチが実際に機能していることは、hospOSの実運用が示しています。そこでは、検査室向け検体搬送の80.68%をロボットが担っています。この数値は機器単体の性能だけによるものではなく、発注、エレベーター呼び出し、走行、受け渡しが、人手による中間工程を挟まずに連動していることによるものです。
主権はアーキテクチャの問題です
答えのもう一つの側面は、データに関わるものです。病棟の廊下を走るサービスロボットは、カメラとマイクを備えています。その機微性は、病室、受付、検査室、待合スペースといった場所そのものから生じます。氏名のリストがなくても、病棟の廊下で撮影された映像は個人情報に当たります。だからこそ病院では、データの流れに関する問いが他業種よりも早い段階で提起され、それがプロジェクトの着手可否そのものを左右することが少なくありません。
これに対する持続可能な答えは、追加の契約書ではなく、問いそのものを小さくするアーキテクチャです。
「施設の外に出ないものは、移転の根拠を必要としません。」
これは法的な工夫ではなく、データの持ち方そのものから導かれる帰結です。連携をローカルで完結させれば、地図データ、発注情報、テレメトリ、映像はお客様の環境内にとどまり、検討の焦点は「どの根拠で移転するか」から「そもそも何が施設の外に出るのか」へと移ります。Axionaはこの発想で設計されており、クラウド・オンプレミス・完全オフラインという3つの運用モードが同じ機能ロジックを共有します。どのモードを選ぶかは製品側が決めることではなく、貴施設の運用判断であり続けます。この仕組みが技術的にどのようなものかは、データを外に出さないサービスロボティクスで解説しています。
これによって、ソリューションの出身国という論点も、本来あるべき位置に収まります。サービスロボティクスの出身国の中には、EU委員会による十分性認定を受けている国もあり、日本や大韓民国はその例です。一方で、そうした認定を受けていない国もあります。これは法的状況についての事実の指摘であり、特定の国を評価するものではありません。カプセル化可能なアーキテクチャを採用すれば、メーカーごとにこの問いに一から答え直す必要がなくなり、こうした区分そのものから独立できます。
ここで見落とされがちな区別があります。データの保存場所と、遠隔からアクセスできるかどうかは別の問題だという点です。院内にサーバーを置いても、誰が遠隔から閲覧できるかまでは決まりません。欧州データ保護会議(EDPB)のガイドライン05/2021(バージョン2.0、2023年2月14日採択)は、第9項で「移転」に当たるための3つの累積要件を定めています。その上で第16項は、第三国からの遠隔アクセスについて、サポートやトラブルシューティング、管理作業のために画面表示されるだけの場合であっても、第9項の要件を満たすときは移転に当たり得るとしています。他方で第17項は、他の管理者・処理者に開示されない純粋に内部的な処理は、第5章にいう移転には当たらないとしています。個別の事案での該当性は、貴施設のデータ保護部門と法務顧問の判断に委ねられますが、アーキテクチャ次第で、その判断がそもそも必要になる頻度は変わります。
ここから私たちが導く設計原則は、不信の表明ではなく、常時接続のリモートアクセスを持たないという方針です。外部から施設内へ常時開いたチャネルは存在しません。リモートサポートはセッション単位で行われ、施設側が許可し、時間を区切り、記録が残ります。これはメーカーやインテグレーターにとってサービス対応力の低下を意味するものではなく、規制環境下でも遠隔支援を確実な形で合意し、入札の場でも提示できる形にするための仕組みです。
実際に何が起きたかを証明する
規制環境でロボティクスを導入する組織は、運用を確保するだけでなく、それを証明できなければなりません。誰が発注を行ったのか、その権限を持つ役割は何か、どの走行がいつ行われたのか、どのシステムが関与したのか。こうした証跡は、個々の機器の稼働データから事後的に組み立てられるものではなく、すべての発注を横断的に把握しているレイヤーで生まれます。ロールと権限、ログとレポートがそこに置かれるべき理由はここにあります。
私たちがあえてそのように設計した点があります。データの欠落は、欠落として示され、ゼロとしては示されません。ある期間の記録が欠けている場合、報告書にはその事実がそのまま記載されます。欠落をゼロ値に均してしまう指標は見栄えがよくなるだけで、監査においては無価値です。こうした発想は、規制環境で一般に求められる説明責任のあり方とも重なります。その背景にある原則は主権とセキュリティで解説しています。ログとレポートはコンプライアンス体制そのものに代わるものではありませんが、説明責任にかかる負担を軽減します。施設の外に出ないものは、多くの場合、移転の根拠という問いそのものを不要にします。
導入をご検討中であれば、具体的なところから始めるのが一番の近道です。貴施設の業務フローの一つをお見せいただければ、それが中立的なレイヤーを通じてどのように処理されるかを、貴施設が求める運用モードでご説明します。デモを依頼する。
システムインテグレーター・システムハウスの皆様へ
システムインテグレーターやシステムハウスにとって、追加レイヤーをめぐる問いは違った形で立ち現れます。そのレイヤーが必要かどうかではなく、誰がそれを構築し、維持するのかという問いです。自社開発のロボティクスソフトウェアは、多くの場合、最も低コストな選択肢ではありません。負荷が生じるのは最初の導入時ではなく、10件目の導入、そして継続的に維持しなければならないすべての要素、すなわちエレベーター連携プロトコル、ドア制御、入退室管理システム、ロールモデル、アップデートの経路、運用モードにおいてです。
役割分担
実務で機能する役割分担は、それぞれが実際に持っているものに沿って決まります。貴社が持つのは、顧客との関係、現場設備に関するノウハウ、検収、そして立ち上げ対応です。これは買って手に入れられる資産ではありません。プラットフォーム側が提供するのは、オーケストレーション、建物設備との連携、運用モデル、そして証跡です。GUI経由でも、REST API経由でヘッドレスに組み込む形でも利用できます。こうして貴社は、自社ブランドと自社の契約関係のもとで、独自のロボティクスチームを抱えることなく、独自の商用ソリューションを構築できます。
その鍵を握るのは、共有の統合ライブラリです。新しい統合、例えばあるエレベーター機種、ある入退室管理システム、あるロボット機種は、その後Axiona上のすべての業種向けソリューションで利用可能になります。hospOSはもちろん、shoppiOSも同様です。ある医療機関プロジェクトでの貴社の作業は、次の商業施設案件にも活きてきます。
混合フリート、機種変更、運用モデル
ここで第二の問いに移ります。機器に付属するソフトウェアだけでは、なぜ運用全体を支えきれないことが多いのでしょうか。それは、そのソフトウェアが弱いからではなく、一機種のために作られているのに対し、実際の運用は複数の機種から成り立っているからです。現場からの3つの観察を挙げます。
混合フリートは例外ではなく、通常のケースです。 FreyungにあるKliniken am Goldenen Steigでは、Keenon T3、Keenon W3、temi v2をはじめとする複数の機種が、一度構築されたKONE製エレベーター連携の上で、同一のプラットフォーム上で稼働しています。Technologie Campus Grafenauでは、同じ基盤が新機種やエレベーター制御の検証環境として使われています。あらゆる業務を一機種でまかなう施設はほとんどありません。検査室向けの搬送ロボット、受付案内用のロボット、清掃ロボットは、それぞれ別の機械であり、多くの場合、3社のメーカーにまたがります。機器に密着したソフトウェアが自らの機種を熟知しているのは当然のことですが、混合フリート全体を見渡すことはできません。それはそのソフトウェアの役割ではないからです。導入事例はリファレンスで紹介しています。
ハードウェアは入れ替わっても、業務フローは残ります。 ロボット機種のライフサイクルは、臨床業務フローのライフサイクルよりも短いものです。業務ロジックが機器側に組み込まれていれば、機種変更のたびに統合プロジェクトが発生します。業務ロジックが上位レイヤーにあれば、機種変更は調達手続きで済みます。貴社にとってこれは、一度きり販売するプロジェクトと、年々成長していく導入案件との違いを意味します。詳しくはシステムを変えずに、ロボットの選択肢を広げるをご覧ください。
運用モデルは前提条件であり、付加要素ではありません。 病院をはじめとする規制の厳しい環境では、データの保持、リモートアクセス、証跡の整備は、技術的な検討の最後ではなく最初に問われます。検収の段階になって初めて答えようとすれば、時間的制約のもとで交渉することになります。あらかじめ答えを用意していれば、入札対応の一部はすでに終えていることになります。
「カプセル化可能でオフライン対応のレイヤーがあれば、運用モデルはプロジェクトのリスクではなく、インテグレーターにとっての営業上の強みになります。」
これにより貴社は、後から埋め合わせなければならない約束ではなく、裏付けのある答えを持って商談に臨めます。これは、データ保護部門やIT、技術部門との議論を、「そもそも認められるのか」から「どの業務フローから始めるか」へと移す効果があります。ただし、施設側のデータ保護部門と法務顧問による個別の事案ごとの判断が不要になるわけではありません。
ロボティクスを貴社のポートフォリオに加えたい場合や、進行中のプロジェクトをより確かな基盤に乗せたい場合は、役割分担について一度お話ししましょう。パートナーになる。
オープンなエコシステム
新しいロボット機種はアダプターを介して接続され、プロジェクトごとの特注対応にはなりません。新しい統合は、そのたびにAxiona上のすべての業種向けソリューションに還元されます。優れたハードウェアを欧州の医療市場に届けたいメーカーは、自社のアーキテクチャを作り直す必要も、独自の欧州向け運用モデルをゼロから構築する必要もありません。より近道となるのは、2023年から臨床現場で稼働し、統合と証跡の部分を引き受けてくれる、すでに存在するレイヤーを使うことです。これにより、貴社の機器はより少なくではなく、より多くの入札案件の対象になります。パートナーになる。