データ発生源の近くで処理するエッジコンピューティング
あらゆるデバイスがインターネットにつながる時代が到来し、従来のようにクラウド側で集中的に処理するだけではなく、エッジ、つまりユーザーに近い場所でデータを処理する「エッジコンピューティング」が昨今注目されている。
エッジAIはエッジコンピューティングから派生した用語で、AIの学習モデルを用いてエッジで推論することを指す。
エッジコンピューティングは処理の内容によって、ほかにもエッジアナリティクスなどさまざまな用語が存在するが、基本的にデータの発生源に近いところでデータを処理するというコンセプトはどれも同じである。
エッジでAIモデルを動かす
エッジAIはAIの学習モデルを使い、画像認識などの技術を用いてエッジコンピュータ上で推論結果を出すことである。
画像認識にはさまざまな定義があるが、本稿では「画像処理の技術を用いて、画像を理解・認識し、有意な情報を取り出すこと」とする。画像の理解・認識の代表例として、物体認識と物体検出などがある。
たとえばデータの発生源の近くで推論できるようになると、製造ラインなどでエッジAIによって得られた推論結果により、その場で製品のOK／NGを仕分けし、NG判定の製品を取り除き、OK判定の製品を次の工程へ回すなど、リアルタイムに次のアクションにつなげることが可能になる。
図表1にあるように、エッジAIが従来の方法と異なる点は2つある。1つはデータを処理する物理的な距離、もう1つは事前にAIの学習モデルを作成してエッジ・デバイスに配布しておくことである。
実際にデータが発生して処理する場合、従来型ではデータをクラウドに送って結果を得るのに対し、エッジAIではその場で結果を受け取ることが可能である。
エッジAIのメリット・デメリット
もちろんすべての画像認識系システムをエッジで実装すればよい、というわけではない。エッジAIにもメリット・デメリットがあり、それらを踏まえたうえで、システムの採用を検討すべきである。
エッジAIのメリット
・分析パフォーマンスの向上
・通信コストの削減
・セキュリティ
・導入コストの削減
・ポータビリティ
エッジAIの1番の特徴として挙げられるのが、データ発生源の近くで処理することで、リアルタイムに近いレスポンスを得られ、分析パフォーマンスを向上できる点にある。
またデータをクラウドに送信しないので、通信コストの削減も可能である。クラウドにデータを上げる場合は、発生したデータをエッジでサマリーすることでセキュリティも担保でき、さらなる分析をクラウド側で実行することも可能である。
また、エッジ・デバイス自体が安価なことから低コストで始められる点や、通常サーバーを配置できないような場所に設置できるなど、ポータビリティの高さもエッジAIの特徴である。
一方で、デメリットも存在する。
エッジAIのデメリット
・管理コストの増大
・エッジ・デバイスのリソース不足
エッジというくらいなので末端側には無数のデバイスがあり、それら大量のエッジ・デバイスを効率的に管理する仕組みが必要になる。
またエッジ・デバイスは1台当たりのコストを抑えるために、リソースは低く設計されており、サーバーのような強力なリソースは当然ながら積んでいない。エッジ・デバイスの能力を超えるような重い処理は、従来どおりサーバーのリソースを使用するのがよいと考えられる。
ただし近年では、手のひらサイズの小さなエッジ・デバイスでもディープラーニングで作成したAIモデルを効率よく処理できるようなデバイスが登場したり、エッジ・デバイス用にAIモデルをコンバートして高速に推論を行うエンジンが開発されたりと、一昔前に比べるとエッジで処理可能な選択肢が広がっている。
大量のエッジ・デバイスを管理するためのソリューション
デメリットの部分で言及した「管理コストの増大」であるが、今後は必要なエッジ・デバイスに必要なアプリを配布して管理する仕組みが必要になると考えられる。
各社ともに、前述したような機能を備える製品をリリースしている。IBMでは、「IBM Edge Application Manager」（以下、IEAM）という製品を提供している（図表2）。
これは、エッジ・デバイスやサーバーのコンテナ・アプリを一元管理するソリューションである。
大まかな流れを説明しよう。最初にエッジ・デバイスに対してIEAMのエージェントを導入し、IEAMにエッジ・デバイスを認識させる（図表2の①）。
次にIEAMでポリシーを作成し、デプロイする（図表2の②）。
図表3が実際にポリシーを作成している画面である。使用しているエッジ・デバイスに事前にjetsonagxというノード・ポリシー（エッジ・デバイスを認識させるタグのようなもの）を設定している。
ポリシーをデプロイすることで、条件に合致するエッジ・デバイスに対してのみサービス（docker形式のコンテナ・アプリ）を自動的に配布することが可能になる（図表2の③）。
大量のデバイスに対しアプリを配布するには、エッジ・デバイス上で１つ１つアプリを開発するのではなく、コンテナ形式でアプリを配布する仕組みが効率的である。
今後、世の中でエッジ・デバイスを使用したソリューションが増えていくと考えられるが、いかに効率的にエッジ・デバイスを管理していくかがプロジェクトを成功に導く要因の1つになると考えられる。
IEAMと連携したエッジAIのデモ
日本アイ・ビー・エム システムズ・エンジニアリングで検討したエッジAIの開発～運用の構成例を、図表4で紹介する。
エッジAIというと推論する部分に注目しがちだが、他のAIと同じく、AIモデルを作成する部分も重要である。図表4の構成例では、学習に要する時間を極力省力化しつつ精度を出すため、GUI上で簡易的に操作可能な「IBM Maximo Visual Inspection」（以下、MVI）を使用している（図表4の①）。
次に、作成したAIモデルをアプリに連携する。MVIはエッジでのAIモデル使用を想定し、推論を高速化するTensorRTという推論エンジンで使用でき、モデルをエクスポートすることも可能である。
アプリの開発は、実際に使用するデバイス上で開発するのが互換性などの観点からよいと考えられる（図表4の②）。
アプリがdocker上で稼働することを確認したら、IEAMにdocker形式のアプリを登録する（図表4の③）。
最後に、IEAMでアプリを配布するエッジ・デバイスに対して合致するポリシーを作成し、デプロイする（図表4の④）。
これにより、特定のエッジ・デバイスにアプリを自動配布することが可能である。末端のエッジには大量のエッジ・デバイスが存在しても、IEAMを使用することでロケーションや用途に応じて必要なアプリを必要なデバイスに自動で配布できる。
またIEAMには配布管理機能があり、精度を向上させたAIモデルのバージョンを容易に配布できる（図表4の⑤）。
図表5と図表6は、実際にデモで使用した機材や検出している様子である。
図表5ではエッジ・デバイス（黒いボックス）をWebカメラに接続している。
図表6では対象の物体（今回はガラスのビン）を撮影して、その状態が正常か異常かを判別している（フタが閉まっていないビンを異常と判定している）。
エッジ・デバイスを人手で個々に管理していくのは限界があるので、IEAMのような製品を用いて一元管理することで、アプリ開発やAIモデル開発の部分にリソースを集中できると考えられる。
エッジコンピューティングの今後
本稿ではエッジAIに話題をフォーカスしてきたが、将来的には5Gの技術と絡めたエッジコンピューティングのソリューションが一般に普及していくだろう。
5Gの備える「超高速・大容量」「同時多数接続」「超低遅延」の特徴とエッジコンピューティングの親和性は高いと言われており、今後はIT・通信産業、製造業をはじめ、自動車・医療・教育など幅広い分野でエッジコンピューティングの導入事例が増加していくと期待される。
本稿執筆時点では、エッジAIを含むエッジコンピューティングの事例はまだ少なく、導入を検討している各企業も展開の方法に頭を悩ませていると考えられる。
要件や目的に応じてエッジのソリューションが最適かどうかを検討すると同時に、エッジの利点を活かし、安価なエッジ・デバイスで簡単なアプリを開発するところから始めてみてはいかがだろうか。
著者
岩﨑 真悟氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
IoTソリューション
シニアITスペシャリスト
2010年に日本アイ・ビー・エム システムズ・エンジニアリングへ入社。Db2、Replicationなどデータ周りの技術支援を担当。近年ではディープラーニングや画像認識技術を活用したプロジェクトに参画しており、活動の領域をエッジコンピューティングなどにも広げている。
［i Magazine・IS magazine］
