AWS IoT×機械学習で“海”の課題を解決　急成長を遂げる水産養殖スタートアップの挑戦

水産養殖に特化したテクノロジーカンパニー

岡本拓磨氏：それでは「いかにしてスタートアップは水産養殖の現実の課題を解決するか―ウミトロンにおけるIoTと機械学習の取り組み―」について、お話ししたいと思います。

私、ウミトロン株式会社共同創業者／取締役CTOの岡本拓磨と申します。学生時代はコンピューターサイエンスを学び、社会人としてはWeb業界スタートアップで、主にWebエンジニアとしてキャリアを歩んできました。

2016年に3人でウミトロンを創業し、1人目のソフトウェアエンジニアとして、プロダクトとエンジニア組織を作ってきました。今まではWeb業界でオフィスで働いていましたが、現在のフィールドは海ということもあり、国内外を問わず実際に海に出て、ユーザーである生産者と話し、時には実際の生産者のオペレーションを体験したりもしています。

我々ウミトロンは「install Sustainable Aquaculture on Earth」をミッションとしています。水産養殖に特化したテクノロジーカンパニーです。

現在、世界では人口が日々増加しています。2050年には100億人の人々が生き、私たちの青い惑星・地球で進化を続けます。

人は主に陸で生活をしています。地球の70パーセントは海に覆われていますが、そのほとんどがまだ利用されていません。

ウミトロンの使命は、地球に持続可能な水産養殖を実装し、養殖を次世代の食料生産方法に移行させることです。

現在、世界では水産養殖という産業は急成長を続けています。特にアジアを中心として、人口増加と中間所得層が増加したことにより、動物性たんぱく質の需要が増加したことが背景としてあります。

人類が魚介類を得る手段として、野生の魚を捕まえる「漁獲」と、魚を育てる「養殖」の2つがあります。現在、漁獲で捕れる魚の量は拡大を止め、停滞しています。それは海にいる天然資源である野生の魚の生産量と漁獲量が均衡しつつあるということです。一部の魚は乱獲が進み、絶滅危惧種にも指定されています。そこで、今まで漁獲でまかなっていた魚の需要を満たすため、水産養殖が急速に発展しています。

現在、世界で急速に成長している水産養殖ですが、将来はどうなのか。水産養殖は将来にわたっても、まだ成長していく余地があると考えられています。これはある研究なんですが、地図上の青い地域が「現在水産養殖を行っている地域」、そして赤い地域は「現在の技術を使って水産養殖ができるが、まだ行われていない地域」となり、この赤い地域が青い地域の100倍あると考えられています。このように、地理的に考えても、現在の100倍以上成長するポテンシャルを備えた産業であると言えます。

これは日本の愛媛県の水産養殖場です。洋上に浮かんでいる、規則正しく並んでいる四角いものが生け簀です。10～15メートル四方の鉄枠が浮きで浮いていて、それを口にするように水中には網がぶら下がっています。中には数千匹の魚が泳いでいます。

生け簀の中の水中はこのようになっています。たくさん泳いでいる色鮮やかな魚は真鯛です。これから水中に魚の餌が投下されます。空腹状態の魚は水中に餌が投下されると争うように群がってきます。このように、人間の目から見ても、魚の行動で魚の空腹状態は判別することが可能で、生産者は水上からこの様子を見て、あげる餌の量を日々調整しています。

水産養殖の最大の課題は「高騰する魚の餌代」

では、水産養殖における実際の課題とは何か。水産養殖という産業にはさまざまな課題がありますが、その中で最も大きくグローバルに普遍的に存在する課題は、高騰する魚の餌代です。

現在、魚の餌代は、魚を作るのに関わる総生産コストのうちの半分を占めます。これは魚種によって変わり、多いものだと餌代が7～8割にのぼると言われています。なぜこのようなコスト構造になっているかというと、この15年で魚の餌の原料になっている魚粉が3倍に高騰したからです。これは、餌に使われている魚粉は漁獲で捕れた魚を原料にしているためです。現在、海の天然資源は減少しているものもあり、漁獲で魚を捕るのが難しくなっているため、価格も高騰してしまっています。

そこで、我々ウミトロンは、高騰する餌代という現実の課題を解決するために、テクノロジーを用いて飼料効率・給餌効率を改善することに取り組んでいます。

アプローチは2つで、1つは魚の摂餌行動からムダ餌を検知して、自動的に削減すること。これは先ほどの水中の動画からわかるように、人間が目で見て判断していることを、動画像処理と機械学習を用いて自動化することで行います。

もう1つは、人間の制約を受けない給餌で、魚の生育に最適な給餌を行うことです。現在、魚の給餌は人間が行わなくてはいけない、人間によって計画されなければいけないという制約があるため、必ずしも魚にとって最適化されているわけではありません。

例えば、早朝や夕方といった時間帯で餌やりが難しいといった制限や、気候変動などの環境要因における急な魚の食欲変動。このような日々変わる魚の食欲に対して、柔軟に給餌計画を変更して実行することが魚にとって必要で、魚の成長促進につながります。この2つのアプローチで、給餌効率の向上に取り組んでいます。

IoTと機械学習を用いた給餌効率改善デバイス

給餌効率改善のために我々ウミトロンが開発したのが、「UMITRON CELL」というIoTと、機械学習を用いた自動給餌器です。中には400キロ以上の餌が入るタンク、タンクの中の餌を送り出すモーターとスクリュー、魚の様子を常時撮影するカメラ、そしてこのデバイスをコントロールするための基盤が入っています。デバイスの天板にソーラーパネルがついており、太陽光のみで動きます。ネットワークにはSORACOMを利用しており、携帯回線につながっています。

生産者は、洋上の生け簀の上の「渡り」と呼ばれる橋の上にこのIoTデバイスを設置します。デバイスのタンクの中に餌を入れ、モバイルアプリやWebブラウザから遠隔で操作して魚に餌をあげたり、カメラでリアルタイムに魚の様子を見ることができます。

主な機能は、魚の様子をリアルタイムに観察できるモニタリング機能、遠隔で給餌を制御する機能、タンクの中の餌の重量が取得できるため、それらをもとにどれだけの餌を魚に与えたかを図表で可視化する生育管理。常時録画された魚のデータは定期的にアップロードされ、データが蓄積されています。

また、蓄積されたデータをもとに魚の行動から食欲を解析しており、動画から魚が餌を食べているかどうか、これ以上餌をあげ続けるとムダになるかどうかなどを、リアルタイムで反映しています。

魚は餌を食べなくなると目に見えて行動力が少なくなり、活性が落ちます。給餌中にも関わらず魚の活性が落ち、これ以上餌を与えても食べないと判断された場合、自動的に給餌を停止し、ユーザーのモバイルアプリに通知を送ります。

このようなプロダクトを開発し、給餌の最適化を実現するには、Webやモバイルアプリ以外にも、IoTと機械学習といったテクノロジーを用いる必要があります。IoTは給餌器という洋上のIoTデバイスの操作、デバイスからの継続的な安定したデータ取得、そしてデバイスのソフトウェアの遠隔アップデートに必要です。

機械学習では給餌中にリアルタイムに取得したデータから、魚の行動に基づく食欲解析と、日々取得できるデータから継続的に食欲解析判定のモデル改善を行います。このIoTと機械学習について、ウミトロンでどのように取り組んでいるか、AWSのサービスをどのように使っているかについて、お話ししていきたいと思います。

IoTデバイスで実現したいこと

まずIoTについての取り組みについてお話しします。我々は先ほど紹介したように、給餌の最適化のために「UMITRON CELL」というIoTデバイスを開発しました。このIoTデバイスで実現したいことが3つあります。

1つは、デバイスとのリアルタイムな双方向通信です。デバイスから採れるデータを継続して取得するだけでなく、遠隔からの給餌を実現するために、サーバからデバイス方向への通信もリアルタイムで行えなければいけません。

2つ目は、洋上での独立した安定稼働です。我々のIoTデバイスは、電源は太陽光のみで稼働しています。また洋上という環境であり、デバイスを利用するユーザーも常に近くにいるわけではない、すぐに行けるわけではないという特徴があります。また、ネットワークも常に万全な状態というわけではありません。このような厳しい環境で、安定してソフトウェアが稼働・通信できる必要があります。

3つ目は、デバイスを設置してからも、デバイス上のソフトウェアを容易に改善し続けられることです。現実世界というのは想像していなかったさまざまな自然環境があり、デバイスを設置してから初めて遭遇する問題も少なくありません。また、魚の生育期間は、長いものだと稚魚を生け簀に入れてから集荷するまで2年以上あります。このように、デバイス設置前にすべての状況に対応できる、すべての要望を満たすソフトウェアは開発できないため、洋上にデバイスを設置したあとも遠隔でアップデートできる必要があります。

それらを実現するため、我々はIoTの基盤にAWS IoTを採用しました。IoTデバイス、Webサーバ、ユーザーが操作するモバイルアプリやWebブラウザの3者が、MQTT over WebSocketのプロトコルを用いて、リアルタイムで双方向通信をすることができます。このようなインフラがフルマネージドで提供されているため安定稼働し、インフラ運用コストがほとんど必要ありません。

また、AWS IoTは、AWSのさまざまなサービスと連携して使うことができます。例えば、AWS IoT Ruleを使ってデバイスから送信したログデータをさまざまなストレージサービスに直接保存することができます。IoTプロダクトの通信のうち、ほとんどがこのログデータの送信なので、大部分のリクエストが自分たちのサーバを経由しないというのは、インフラコストがかからないという面で大きなメリットです。インフラに手がかからないぶん、エンジニアはソフトウェアの開発と事業ドメイン固有のビジネスロジックに集中できます。

ハードウェアにGo言語を採用した理由

我々のIoTデバイスは、ハードウェアとしてRaspberry Pi、OSとしてDebianベースのRaspbian OS、そしてGo言語で書かれたソフトウェアで構成されています。Raspberry PiとRaspbianを採用した理由は3つあります。

1つはソフトウェアの変更が簡単なアーキテクチャを実現するためです。マイコンなどOSのない環境と比べて、追加でライブラリを利用したり、ソフトウェアをアップデートすることが容易に行えます。

2つ目はRaspberry Piという汎用品、Linuxという既存資産を利用することで、学習コストを低く抑え、開発速度を速くすることができます。我々はWeb業界出身のエンジニアがほとんどですが、組み込みエンジニアでなくても、Web業界で培ったインフラ運用の知識・経験を活かして、スピード感を持って開発することができました。

3つ目は、遠隔でのトラブルシューティングができるように、SSHを利用したログインをできるようにするためです。実際に洋上にデバイスを設置してから、初めて遭遇する問題はたくさんあり、それらを陸上でテストすることは難しかったりします。トラブルが起きたデバイスでも、ログインしてログを調査できれば、デバイスを設置してからも対応できる場合が多いです。

IoTデバイスは、電力的に厳しい要件の場合は、マイコンを使う場合もよくあります。しかし、我々のデバイスの場合、基盤部分よりも餌を送り出すモーターという駆動部分のほうが大きく電力を消費するため、基盤で電力消費を抑えた場合のインパクトが大きくありません。そこで、多少の消費電力の増加はあるものの、設置前・設置後含めた継続開発速度を上げるために、このような構成にしました。

ソフトウェア言語としてGo言語を採用したのは、高い生産性とパフォーマンスを備えた言語だからです。デバイスの組み込みに使う言語として、C、C＋＋がメジャーですが、それらの言語に比べて、近年に作られたということもあり開発が容易で生産性が高く保てます。

高い生産性という意味ではPythonなどのLL言語もありますが、これらのようなソフトウェアを動かすのに実行環境が必要な言語では、言語のバージョンアップが必要になった場合、各デバイスの環境をアップデートする必要があります。Go言語はコンパイルして1つのバイナリファイルになり、それらを動かすための実行環境を必要としません。1つのファイルを置くだけでソフトウェアのアップデートができるので、継続的な開発が非常に簡単です。

ウミトロンのAWSの構成

それでは、ウミトロンのAWSの構成図についてお話しします。こちらは一部ではありますが、左側は食欲判定の推論結果などを返す機会学習サービス、中央がユーザーに提供するアプリケーションとなるWebサービス、右側が洋上で動くIoTデバイス「UMITRON CELL」です。右下部分がモバイルアプリとWebブラウザという、ユーザーが操作する部分となります。

WebサービスとIoTデバイス、ユーザーが操作するモバイルアプリ、Webブラウザの3者が、AWS IoTを中心に双方向に通信しています。Webサービスは機械学習サービスをSageMakerのエンドポイントにリクエストを投げて利用しています。Webサーバ、ワーカーサーバはDockerで運用していて、ECSを利用しています。

ストレージにはデータの特性・利用ケースによって、RDS、ElastiCache、DynamoDB、S3を使い分けています。それではこれらを部分、部分にフォーカスしてお話ししていきたいと思います。

まずは、WebサービスとIoTデバイス、ユーザーが操作するモバイルアプリ、Webブラウザの3者の、AWS IoTを利用した双方向通信についてお話しします。このようにAWS IoTを中心として3者はつながっています。

AWS IoTによるリアルタイムタイム双方向通信は、主にDevice Shadowを用いて行います。Device ShadowはIoTデバイスの状態とAWS IoTのShadowを非同期に反映する機能です。Shadowにはdesiredとreportedの2つがあり、デバイス側で反映したい情報はdesiredに書き込み、デバイス側から反映された情報はreportedに書き込みます。

ウミトロンでは給餌の開始・停止、リアルタイムモニタリングの開始・停止といったIoTデバイスのリクエストはdesiredに書き込みます。Shadowはデバイスがオンラインになったタイミングで反映されるので、一時的にネットワークが瞬断している場合などにも有効です。

一方、デバイス側の給餌の進捗状況、オンライン・オフラインといった情報はreportedに書き込みます。これによりWebサーバ、モバイルアプリ、Webブラウザと、複数ヶ所からもShadowだけ見ればデバイスの最新状態がわかるので、非常に便利で、アーキテクチャをシンプルに保つことができます。

IoTデバイスからのデータ取得やデプロイについて

次に、IoTデバイスからのデータ取得についてお話しします。IoTデバイスから送られるデータは大きく分けて2つあり、カメラから得られる動画像といったメディアファイル、デバイス上で計算された数値やデバイスの情報といったテキストデータ、これらを用途に応じて各種ストレージに保存しています。

動画像のメディアファイルは直接S3に、テキストデータはAWS IoTに送信され、AWS IoT Ruleでアプリケーションで利用する場合はDynamoDB、機会学習・分析用途の場合はLambdaを通してS3に保存されます。

アプリケーションで利用するテキストデータは、AWS IoT RuleからDynamoDBに保存します。こうすることで、デバイスから一番多いリクエストがWebサーバを経由せず、AWS上のマネージドサービス連携だけで完結するので、安定稼働してインフラ運用コストがほとんどかかりません。

DynamoDBは大量のデータを保存でき、かつアプリケーションから参照できるほどの低レイテンシーを実現できます。動画像といったメディアファイルは、デバイスが直接S3にアップロードしています。サーバ側でPreSigned URLを発行し、デバイスが受け取り、そこに直接アップロードします。

IoTデバイスはネットワーク状況が弱い場合もあり、アップロードに時間がかかったりします。このような状態でWebサーバに直接大容量ファイルをアップロードしてしまうと、コネクションがアップロードで占有され、本来さばくべきアクセスをさばけず、ユーザーに影響が出てしまいます。これを避けるために、大容量ファイルのアップロードがWebサーバを経由しないようにしています。

IoTデバイスのソフトウェアのアップデート・デプロイについてお話しします。デプロイするソフトウェアはDebian packageで管理していて、それをS3でホスティングし、CloudFrontを使って配信しています。デバイスへのアップデート命令は、AWS IoT jobsを介して行います。

Debian packageにはコンパイルしたGo言語のバイナリと、OSで使用しているライブラリの依存関係と、そのライブラリの設定ファイルが記述されています。このパッケージがS3上にホスティングしてあり、CloudFrontでアクセスコントロールを行っています。

AWS IoT jobsを使ったデプロイは、まずアップデートしたいIoT Thingに対してjobを作成します。デバイス側はAWS IoTを使い、このjobをsubscribeします。jobからはアップデートするべきDebian packageのバージョンが取得でき、取得したあとapt-getでソフトウェアのアップデートを行います。

AWS IoT jobsの利点は、jobを作った時にデバイスがオフライン状態でも、オンラインになったタイミングでjobをsubscribeして、非同期にアップデートを行えることです。洋上のデバイスなので、常にネットワークが万全なわけではなく、一時的に不通な場合や、また台風などの災害のために一時的にデバイスを陸に上げて、電源を落としている場合などがあり、それらのデバイスに対しても非同期にアップデートができます。

機械学習に取り組む上での2つの課題

続いて、機械学習についての取り組みについてお話しします。機械学習で実現したいこととして、給餌中にリアルタイムに取得したデータから魚の行動に基づく食欲解析と、日々取得できるデータから継続的に食欲解析判定のモデル改善がありました。

それらに取り組んでいくと、自分たちが取り組む前に課題だと思っていたけれど実際ではそうではなかったこと、想定していなかったけれど実際は課題だったことが浮かび上がってきました。

課題だったことは、継続的にアプリケーションを開発していく上でのチームとしての開発速度と、機械学習サービスのインフラパフォーマンス及び運用コストです。逆に課題ではなかったことは、継続的にデータを収集していくこと、実用に耐える精度を出すこと、アプリケーションで使用するといった、実際にアプリケーションとして動くものを作ることでした。つまり、動くものを作ることは簡単でしたが、それを継続して安定して開発・運用することが難しかったと言えます。

それでは、課題だった開発速度とインフラパフォーマンスを、どのように解決したかについてお話ししたいと思います。

これは最初に開発した機械学習を用いたシステムです。左側が食欲判定の推論結果などを返す機械学習サービス。右側がユーザーに提供するアプリケーションとなるWebサービスです。

弊社には大まかに分けて、機械学習サービスの開発を担当する機械学習エンジニアと、Webサービス及びデバイス上で動くソフトウェアを開発するバックエンドエンジニアの2種類のエンジニアがいます。

この初期構成は、実際にデバイスからリアルタイムに取得したデータを解析し、推論結果をアプリケーションで利用することを検証するために構築したものです。デバイスからのデータをWebサービスのWebサーバで受け取り、そのデータをML ServiceのWebサーバに渡します。Webサーバはデータを、gRPCを使いTensorFlowのサーバに入力を渡し、推論結果を受け取りWebサービスに返します。

TensorFlowで動くモデルは、EC2スポットインスタンス上、または機械学習エンジニアが使っているローカルのMac上で学習され、Dockerイメージに収められてECRにアップロードされます。学習に使うデータはWebサービスのRDSやS3から都度取得していました。

この初期システムで実際に動くアプリケーションは開発できましたが、さまざまな課題がわかりました。

1つは複雑な環境による継続的な開発の難しさです。学習環境が1ヶ所に統一されていないため、訓練データや学習プロセスがさまざまな方向で管理されることになり、新しくジョインしたメンバーのキャッチアップコストが高くなっていました。また、機械学習に対する深い知識が必要とされるため、Webエンジニアからはブラックボックス化され、手がつけられませんでした。

これが、もう1つの機械学習サービスのインフラ運用の難しさにもつながります。Webサービスからの推論リクエストを機械学習サービスでさばくのですが、そのインフラ運用を機械学習エンジニアがやる必要があります。しかし、機械学習エンジニアとWebエンジニアのスキルセットの違いから、パフォーマンスチューニングが難しく、時には機械学習サービスで推論リクエストをさばき切れないことで、ユーザーに影響を与えることもありました。

Amazon SageMakerを採用したメリット

この2つの課題を解決するために、我々は機械学習サービスの基盤としてAmazon SageMakerを採用することにしました。SageMakerを採用することでもたらされることが3つありました。

1つはフレームワークとしてのSageMakerで構成が定まっているため、人によって学習環境・訓練データの管理方法が違うといった問題を防げます。学習コストをSageMakerのみに集約することで、これさえわかれば誰でも理解できる状態にできます。AWSのサービスであるため、つまずいてもドキュメントやWeb上の記事、AWSのサポートなど、自社でしか使われていない環境よりも学習コストは低くなりました。

2つ目は、フルマネージドなインフラであることです。これはAWS IoTと同様に、こちらが管理しなければいけないことが減るため、運用コストが削減できます。また機械学習エンジニアもSageMakerさえ管理すればいいので、自分たちだけでサービスレベルで運用することが可能になりました。

3つ目は、弊社のインフラ構築において、SageMakerのエンドポイントで推論リクエストを受け付けることで、Webサービス部分と機械学習サービス部分を疎結合にすることができます。お互いのサービスを運用するエンジニアが知るべきことが、SageMakerに集約できました。

実際に、AWS上の機械学習サービスのインフラ構成はこのようになります。デバイスからリアルタイムにデータが、AWS IoT Ruleを通じてDynamoDB、S3に保存されます。推論リクエストはAWS IoT RuleからSQSに渡り、Webサービス上でリアルタイムにデバイスから取得できないほかの必要な情報を付随して、SageMakerのエンドポイントに投げられます。そのSageMakerから得られた推論結果は、再びAWS IoTを通って、デバイスに給餌命令として渡ります。

学習はSageMaker ノートブックインスタンス上で行います。訓練データはRDS上のものとS3上のデータを、Athenaを用いて加工したものを使います。学習してできたモデルは、Step Functionsでエンドポイントにデプロイされます。

このように学習からデプロイまでの部分を、すべてAWS上のマネージドサービスを用いて構築することができました。結果、開発環境は簡素化され学習コストも下がり、日々新しいメンバーが増えていくスタートアップにとって、開発速度を落とさずサービス改善を続けられるようになりました。インフラ運用コストも下がり、機械学習エンジニアだけで運用が可能になりました。

今後のウミトロンの機会学習の発展は、より高速にモデルを改善していくことを検討しています。洋上に設置されるデバイスが増えるほど日々取得でき、訓練データも増えていきます。

現状、Athenaやノートブックで人の手で訓練データを都度作成しているので、ここを自動化することで増えていくデータをより早く取り込めるようにする。訓練データのアノテーションも、現在定期的にMTurkなどのサービスを使って外部に依頼しているので、ここを自動化して自動的にアノテーションが増えていくようにする。また新しい訓練データを使って、作られたモデルのレポーティングを自動化することで、モデルの評価も高速化していく。

これらを行って、継続的に収集できる訓練データを使い、モデルの改善イテレーションを高速化していきたいと考えています。

以上がウミトロン株式会社の発表になります。ご清聴ありがとうございました。