クラウドロボティクス×群制御技術 　Rapyuta Robotics（以下、ラピュタ）は、米アマゾン・ドット・コムの物流倉庫ロボットを開発した米キバシステムズ（Kiva Systems、現・アマゾンロボティクス）の共同創業者Raffaello D'Andrea氏が教鞭を執るチューリッヒ工科大（ETH Zürich）からスピンオフした大学発ベンチャーだ。
共に東京工業大で学んだGajan Mohanarajah（ＣＥＯ）とArudchelvan Krishnamoorthy（ＣＦＯ）の２人により、２０１４年に日本で設立された。
　ＩｏＴによりさまざまな情報が収集されることで、ＩＴと現実世界が融合する〝サイバーフィジカルシステム〟の実現が期待されている。
収集した情報は人工知能（ＡＩ）が知識化し、機器を通して現実世界に判断や指示をフィードバックすることになる。
その前提はクラウドコンピューティングだ。
高速で安全なネットワーク、演算処理技術、多様なコンピューターリソースの管理といった要素技術の実用化に伴い、今や身近になってきた。
　ラピュタは「ロボットを便利で身近に」をビジョンに掲げて、最先端の制御技術およびＡＩ技術を活用した“世界初のクラウドロボティクス・プラットフォーム”を自負する「rapyuta.io」を、物流現場向けに提供している。
高度な演算処理をクラウドにオフロードするため、ユーザーは比較的安価なセンサーやコンピューターをそろえればよい。
その結果、ロボットはより賢く、より安価になり、進化と普及が進むと期待される。
　rapyuta.ioのもうひとつの特徴は“群制御技術”だ。
　ロボット技術はいまだ黎明期にあり、さまざまなベンダーが用途に応じたさまざまなロボットを競って開発している。
「ロボットを便利で身近に」するには、ロボット同士が相互に通信して協調作業を行うことが求められる。
　しかし、異なるベンダーのロボットを連携させるのは容易ではない。
ロボットの導入に関わる総費用の半分程度はインテグレーションソフトウエアの開発にかかっているともいわれている。
そのため、物流現場において異なるベンダーのロボットを同時に導入している事例はごく少数にとどまっている。
連携となるとほとんど行われていないのが現状だ。
　rapyuta.ioに含まれている群制御ＡＩはもともとは、ロボット同士がサッカーで競い合う国際的なロボット競技大会「ロボカップ」用に開発された技術であった。
ラピュタはそのテクノロジーを練り上げて物流ロボットの群制御に適用した。
その結果、ユーザーはrapyuta.ioを経由することにより、多種多様な複数のロボットのインテグレーションと連携を最小の負荷で実現できることになった。
　物量の増加や技術の進歩に応じてロボットの構成を変更する際にも、インテグレーションと連携をrapyuta.ioが担保することで、インテグレーション・ソフトウェアの修正が不要になる。
拡張性や荷姿やレイアウトの変更に対応する柔軟性が担保されることになる。
ＲＯＳをベースにした階層構造 　rapyuta.ioはロボットソフトウエア開発のデファクトスタンダードとなっている「ＲＯＳ（Robot Operating System）」を拡張した階層構造で構築されている。
ＲＯＳはＯＳと名が付いているが、通常のＯＳとは異なり、既存のＯＳ上で稼働するオープンソースのミドルウエアやソフトウエアのフレームワークのことを指しており、ハードウエアの抽象化やデバイス制御などの機能を、プロセス間でメッセージ通信を相互に行いながら処理を進める分散コンピューティングの仕組みを提供するものである。
　それは次の四つの階層で構成され、全てがクラウド上で動作する（図１）。
●インテリジェンスレイヤー（Intelligence Layer）：ロボット、自動化機器、クラウド上で動作するソフトウェアなどの動作をモデリングして実行するための分散型ＡＩレイヤー。
●演算レイヤー（Computation Layer）：ロボットアプリケーションのビルド、デプロイ、スケーリング、管理を実行するためのレイヤー。
システムへのリモートアクセスや制御も可能。
●通信レイヤー（Communications Layer）：ＲＯＳとの互換性を備えた、安全でスケーラブルなロボット間およびロボットとクラウド間の通信のためのレイヤー。
●マシンレイヤー（Machine Layer）：分散しているマシンからログとメトリクスを一カ所に収集し、保存および可視化することで、ロボットなど自動化機器をデジタル空間上で表現するマシン管理のためのレイヤー。
　これら四つの階層のうち、インテリジェンスレイヤーと演算レイヤーは、いわば頭脳系のレイヤーであり、現状を理解してどのように協調動作させるのかを最適化する役割を担う。
一方、通信レイヤーとマシンレイヤーは、いわば制御系のレイヤーである。
頭脳系レイヤーの指示に基づいて規格の異なるロボットを制御する。
　マシンレイヤーには、さまざまなロボットの差分を吸収するハードウエアカタログ（Hardware Catalog）が備えられており、上位のレイヤーは異なるベンダー間のロボットの規格の差異を意識せずにすむ。
　同様に、演算レイヤーに備えられたソフトウエアカタログ（Software Catalog）を経由して、インターネット上のさまざまなソフトウエア、例えば画像認識ＡＩやレーザーによるロボットの位置認識ツールなどにアクセスすることができる。
導入までの流れと期待効果 　ピッキング作業を行っている現場に、ピッキングアシストロボット（ＡＭＲ）を導入する場合を想定して、そのプロセスと期待される効果を確認してみよう。
　ラピュタ自身もrapyuta.ioに対応したＡＭＲの製造を手掛けているが、他社のＡＭＲを導入する場合にはＲＯＳベースでシステムが構築されているか、またはＲＯＳのドライバー（ＲＯＳのメッセージを基にロボットを動かすソフトウエア）がインストールされていることが前提になる。
その上でロボットメーカーは、ハードウエアカタログから対象ロボットに最適なカタログを選択するか、新たに登録することにより、自社のロボットをrapyuta.ioに接続できる。
　庫内の在庫情報とオーダー情報を管理しているＷＭＳはＡＰＩ経由でrapyuta.ioに接続される。
それらの情報は頭脳系レイヤーに送られて最適な作業計画が作成され、制御系レイヤーを経由して各ロボットに割り当てられる。
このときの標準的な導入手順は下記の通りである。
１．フィット＆ギャップ：ＡＭＲによる作業支援が導入予定の環境（現状の商材やピッキングシステムなど）に適するか、効果が期待できるか、という二つの軸で検証する。
２．要件定義：在庫ロケーション、作業動線、オーダー受信タイミングなどのオペレーション設計とrapyuta.ioの要件定義を行う。
３．導入効果検証：シミュレーターにより運用可能性と導入効果を予想する。
４．インフラ・システム構築：ネットワークおよびＷｉ－Ｆｉ環境の構築、ＷＭＳとrayuta.ioの連携を行う。
５．受入テスト（ＵＡＴ）：統合テストとパフォーマンス検証を行う。
６．本稼働 　ＡＭＲの動きはrapyuta.ioの頭脳系レイヤー上にモデリングされているため、ユーザーがあらためてモデリングする必要はない。
本稼働の際に用いられるこの動作モデルは、上記「３．導入効果検証」のシミュレーションと同じものであるため、ロボット導入後の期待生産性を予測するシミュレーションの精度は非常に高い。
つまり、本稼働時のパフォーマンスと計画時のパフォーマンスの差は非常に小さいという。
　全体の工期は一概には言えないが、「４．インフラ・システム構築」に要する期間は通常であれば３カ月程度だ。
　rapyuta.ioの導入により、庫内オペレーションの最適化や省人化といったコスト面の効果や、人依存からの脱却といった効果があるのは当然として、需要の変動や新しいロボットの導入などの環境の変化に合わせて常に最適な作業指示が立案されることの意味は大きい。
過去に構築したオペレーションが硬直化して、環境変化に取り残されることは庫内作業に限らず業務効率の低下を招く一因だからだ。
ノウハウの外部依存にリスクはないか 　rapyuta.ioのユーザーが増えるほど、さまざまなロボットや現場のデータが収集されて、ラピュタのロボットは賢くなっていく。
従来は個々のベテラン担当者によって属人化されていて、社内であっても体系化や共有化が容易でなかったノウハウが、データ化されてラピュタのサーバーに蓄積される。
　データが多いところにユーザーが集まり、さらにデータが増えていくという、指数関数的増加はインターネットビジネスに共通する現象であり、後発企業が追いつくのは容易でない。
今のところラピュタと同様のサービスを提供する目立った競合はなく、しばらくは一人旅が続くだろう。
　しかし、本来ならば他社との差別化につながるノウハウがrapyuta.ioに集約されるということは、現場力による差別化が難しくなることを意味するのではないだろうか。
そもそもそのような重要なノウハウを外部に依存することは危険ではないだろうか。
　ＩＴ業界では、四半世紀前に同じようなことが議論された。
優れた業務の進め方、いわゆる“ベストプラクティス”が組み込まれた統合業務システム（ＥＲＰ）を導入すれば業務効率が向上するとか、最先端の最適化技術が実装されたサプライチェーン計画システム（ＳＣＰ）を導入すればサプライチェーン効率が向上する、といった話が当時盛んに宣伝された。
　このような主張に対して「他社の仕事の仕方が自社に当てはまるはずがない」「汎用的なツールでは自社のサプライチェーンには適さない」といった懐疑的な意見もあった。
また「誰でも最善・最適な業務が可能になってしまったら、どこで差別化すればよいのか」といった懸念の声も上がっていた。
　その結果はどうだろうか。
今日ＥＲＰやＳＣＰをスクラッチで導入することはほとんどない。
いまだにスクラッチ開発が一定比率を保っているのは、ＣＲＭ（既存顧客管理）領域くらいだ（その理由としては各企業とも自社の製品やサービスそのものでの差別化が難しくなり、顧客接点での差別化に工夫を凝らしているため標準化が容易でないことが考えられる）。
　その他は表に示すようにＯＳやデータベースなどのカテゴリＡから始まり、さまざまなカテゴリのソフトウエアがパッケージ化されて導入されてきている。
この流れを見るとＥＲＰやＳＣＰパッケージの活用も必然であったことになる。
　その結果として業務やサプライチェーンの効率がどの企業も同じレベルになったのかといえば、もちろんそんなことはない。
企業のＩＴによる差別化要因は、システムの開発力から“システムの活用力”に移ったのだ。
その結果として新システムの導入に際しては次の四つが特に重要になった。
●既存業務が可視化されており、業務設計やシステム要件定義がすぐにできる。
●既存業務と導入済みの各種システムの対応関係が可視化されており、既存システムとのインターフェイス設計がすぐにできる。
●顧客や製品、技術など企業の知的資産が相互に関連付けられデータ化されており、システムで扱うことができる。
●社員のＩＴリテラシーが一定レベルあり、新システムの教育展開が円滑にできる。
　右のような条件が整った状況であれば、各業務をモジュール化してネットワークを介して組み替えたり、新たなソリューションと連携したりすることが容易になる。
この一連の流れを作ることをデジタル化という。
　デジタル化されたサイクルはナレッジマネジメントのコアモデルといわれる野中郁次郎氏による「ＳＥＣＩプロセス」そのものだ（図２）。
　すなわち、業務ノウハウや顧客情報といった暗黙知（組織のノウハウ）を形式知化（データ化）する「表出化」、形式知（データやシステム）同士を組み合わせて新たな形式知（新しい仕事の仕組み）を生み出す「連結化」、新たな形式知を体得して自分の暗黙知（個人のノウハウ）とする「内面化」、暗黙知（個人のノウハウ）を組織のなかで共有して新たな暗黙知（組織のノウハウ）を生み出す「共同化」というサイクルである。
　つまり、デジタル化されると、イノベーションを生み出すサイクルが回り出すのである。
ＤＸとは、デジタル化された状態に移行することであり、その本質は、さまざまなソリューションの組み合わせによりイノベーションを生み出すことだといえる。
ＤＸ時代の物流差別化戦略 　インダストリー４・０は製造業におけるＤＸだ。
製造現場を物流現場と比較すると、前者は加工や組み立てを伴うため、より精度や信頼性が要求される。
後者は扱うものが多様であり、より高い柔軟性を求められる。
イノベーションサイクルの肝である暗黙知の形式知化（データ化）は、もちろん後者の方が難易度は高い。
物流現場のＤＸ化はこれからが勝負だ。
　あらためて庫内作業に目を向けると、これから効率的なオペレーションを目指す二つのＤＸが同時に進行していく。
一つはさまざまなロボットや物流機器を組み合わせるrapyuta.ioなどのクラウドロボティクスの働きである。
そして、もうひとつはクラウドロボティクスと、ＳＣＰ・ＷＭＳ・輸配送システム、画像認識やＡＩ技術といった他の物流ソリューションを組み合わせるユーザー企業の取り組みだ。
　クラウドロボティクス、そしてクラウドロボティクスと組み合わせる物流ソリューションも、自らノウハウを蓄積して開発投資するスクラッチ開発のようなアプローチは時代遅れになる。
よほどニッチな領域でない限り、四半世紀前のＩＴ業界と同様のパッケージ化、今日のクラウド時代での言葉で表せばサービス化が急速に進んでいく。
　ユーザー企業は、システムの活用力に関連して前述した四つのポイントと同様の能力、いわば“物流ソリューションの活用力”を高めることにより、クラウドロボティクスの活用を進めるべきだ。
　物流現場に求められるソリューションはクラウドロボティクスだけではない。
業種・業態・荷姿・物量など千差万別の現場に求められるソリューションもまた一様ではない。
ユーザー企業は、必要なソリューションを取捨選択して組み合わせることで、他社との差別化を図ることができる。
そのために、自らのニッチで蓄積したノウハウのデータ化を始めることが、ＤＸ時代に即した差別化の第一歩となる。