PoCから事業化へ。自動運転草刈りシステムをサーバーレス化し、開発スピードと保守性を高める

福島県いわき市に本社を置く株式会社東日本計算センターは、1965年の設立以来、ICTサービス事業を通じて地域やお客様の課題解決に取り組んできました。組み込み系の開発に携わるエンジニアも擁し、R&Dセンターではロボットテクノロジーなどの研究開発を進めています。

「当社には組み込み系の開発をしているエンジニアも在籍しています。そうしたエンジニアの力を借りて、これまでまったく手がけたことのない草刈りの自動運転に挑戦し、一つの商品として世に出してみたいと考えました。研究開発を事業化する、その一つの事例として取り組んだのが自動運転草刈りシステムです」と、取締役 AAMPプロジェクトマネージャーの荒川 英雄氏は語ります。

自動運転草刈りシステム「AWCS（Automatic Weed Cutting System）」は、地元の福島工業高等専門学校と連携して事業化を目指して開発しているシステムです。同社は草刈り機を製造するのではなく、自社のICTで草刈り機を自動運転させるプラットフォームを提供します。地図情報をもとに作成した経路に沿って、メーカーの異なる複数台の機体を同時に走行させられるのが特長です。大きさの異なる2台の草刈り機を同時に走らせる実証もおこないました。

「高齢化で人手が減っているうえ、草刈りは夏場の重労働で、担い手の負担は大きいのが実情です。空港、河川敷、農場など、広い場所の草刈りを自動化することを想定しています」（荒川氏）。全体のコントロールの中心はAWS上にあり、経路の連携やタブレットからの操作もすべてAWSを経由してやり取りしています。今回サーバーレス化したのは、まさにこの中核部分です。

AWCSのクラウド側の検討が始まったのは、機械本体のコントロールがPoCレベルである程度できた段階でした。次のステップとして、それをAWS上でどう動かすかを考えることになったのです。ITインフラセキュリティ事業部 プロフェッショナル エンジニアで、本プロジェクトのクラウド全般とアーキテクチャを担当した大島 富夫氏は、当時をこう振り返ります。

「開発エンジニアの提案で、フロントエンドはReact、WebサーバーはPythonで構築する方針となりました。まずは動くものを優先し、Amazon EC2の仮想マシン上にWebサーバーを用意しました」

短期間で技術的な成立性を確かめるうえで、自由度の高いAmazon EC2は理にかなった選択でした。一方で、検証が進むにつれ、事業化に向けた課題も見えてきます。1つ目はメンテナンス性です。「当時はAmazon EC2の上にいろいろなものを載せようとしていたので、1台のサーバーに多くのモジュールを集約する構成になっていました。これではメンテナンス性が低下してしまいます」（大島氏）。

2つ目は稼働効率です。草刈り機が実際に動くのは、要望のある限られたタイミングだけ。それにもかかわらずサーバーを常時稼働させておくのは効率的ではありません。「理想は、草刈り機の電源を入れたタイミングでクラウド側も起動する仕組みです。それが検討の出発点でした。実用化・事業化を目指すにあたって、Amazon EC2のままではコストと保守の両面で課題になると考えていました」（大島氏）。

さらに、同社の開発部隊はこれまで機器の制御を中心に手がけてきました。取締役 R&Dセンター長で、草刈りシステム全体の開発責任者を務める中野 修三氏は「もともとWeb系の開発経験は限られており、クラウドの利用も初めてでした。そこで大島を通してサーバーワークスに知見を仰ぎ、さまざまな面で全面的に支援をお願いしました」と話します。

相談先として真っ先に名前が挙がったのが、サーバーワークスでした。

「長年のお付き合いがあり、技術力や対応力をよく理解しています。こちらの要望を汲み取り、期待どおりの提案を出してくれる点を評価しています。これまでいくつかのベンダーとお付き合いしてきましたが、その中でもサーバーワークスは特に相談しやすい存在です」（大島氏）。今回は比較検討をおこなわず、「ほぼサーバーワークス一択だった」といいます。

大島氏は以前、Amazon EC2で提供していたサービスをコンテナへ移行した経験があり、当初は「すべてコンテナ系に移す」ことも視野に入れていました。サーバーワークスは、こうした構想段階からディスカッションに参加。方向性を一緒に固めていきました。

「完成した環境を納品してもらうだけでなく、『なぜこの構成にするのか』という設計の考え方を学べることも重要でした」と大島氏は語ります。

サーバーワークスの営業担当である中嶋は、次のように振り返ります。「今回は案件化の前段階から、エンジニアの森山と木田がディスカッションに参加しました。要件が固まってから提案するのではなく、お客様と一緒にあるべき姿を描きながら方向性を決めていく。この進め方を大島様が前向きに受け入れてくださったことが、期限への対応と将来を見据えた構成の両立につながったと考えています」

サーバーワークスはまず既存環境のドキュメントを調査し、現状を整理したうえで構成案を検討しました。提案の特徴は、目の前の期限と将来のあるべき姿を両立させる段階的なアプローチです。

サーバーワークスのエンジニアである森山は、提案の意図をこう説明します。「お声がけいただいた時点でAmazon EC2でのPoCは完了しており、製品版リリースまでの期限が3ヶ月後に迫っている状況でした。短納期のため、まずはAmazon EC2から、コンテナサービスであるAWS App Runnerへの移行をご提案しました。一方で、草刈りにはシーズンがあり、目視していないと運転できないため、常時稼働するシステムではありません。こうした特性にはサーバーレスが最適だと考え、あるべき姿としてサーバーレスをご提案しました」

最終的に採用されたのは、AWS Lambda、Amazon DynamoDB、Amazon Aurora Serverless、Amazon API Gatewayを組み合わせたサーバーレス構成です。草刈り機との通信には当初からAWS IoT Coreを用い、MQTTプロトコルで制御する方針が決まっていました。

「重要なファクターは、経路をどう引くか、経路生成と地図をどうマッチングさせるかといった部分です。周りのコントロール系や管理系は、通常のWebの3層構造と同じ扱いで考えればよい、という発想でした」（大島氏）。

なお、一部のモジュールでは制約やコスト、処理スピードの観点からコンテナも併用し、最適な形を検証し続けています。

中野氏にとって、この提案は新鮮な驚きだったといいます。「Web系のシステムを作成するにはサーバーが絶対に必要だと思っていましたし、クラウドで構築するにしてもAmazon EC2を使うのが当たり前だろうと思っていました。AWS Lambdaを使ったサーバーレスで実現できると聞いたときは、『そんな組み込み方があるのか』というのが最初の感想です。仕組みを聞き、今回のように連続してずっと使うタイプではないサービスに対しては、とても有効なものだと強く感じました」

AWCSには、従来のWebシステムにはない機能も求められます。草刈り機は自律して走行するためカメラを搭載しており、人が現れたら検知して停止する仕組みや、斜面での転倒など万一の事故に備えたエビデンス用の録画が必要です。「これらは従来のWebシステムにはない機能なので、何度も議論を重ね、複数の案をご提示いただきました」（大島氏）。

映像にはAmazon Kinesis Video Streamsを活用しています。屋外で稼働する草刈り機は通信環境が常に安定しているとは限らないため、通信が不安定なときのリトライ処理や、動画を確実に保存する仕組みが課題でした。

サーバーワークスのエンジニアである木田は、次のように話します。「Amazon Kinesis Video Streamsは、公開されている導入事例が少ないサービスです。東日本計算センター様ですでに採用されていたため、その前提で動画の保存を標準機能で実現できるかを検証し、いくつかの案をご提案しました。情報がオープンになっていない部分もあり、検証に加えてAWSサポートにも問い合わせ、仕様や実現可能性の確認などをご支援しました」

提案を受けて複数の方式を試した結果、同社はAmazon Kinesis Video Streamsを使いつつ、受け取った動画をMP4に変換する部分を自社で実装する方式を選択しました。サーバーワークスの検証結果を土台に、自社の要件に最も合う形を自ら選び取った好例といえます。

構成管理には、サーバーワークスの提案によりAWS CDK（AWS Cloud Development Kit）を用いたInfrastructure as Code（IaC）を採用しました。

「複数のサービスにまたがる構成のため、手作業で1つずつ構築するのは現実的ではなく、できるだけIaCを使いたいと考えていました。AWS CDKは最終的にAWS CloudFormationのテンプレートとして出力されるため、内容を確認しながら管理できます。現状は私が担当していますが、今後誰かに引き継ぐことになった場合も、スムーズに引き継げるはずです」（大島氏）。

セキュリティ面でも、サーバーワークスは既存環境に対するアドバイスをおこないました。「個人で構築すると、どうしても判断に甘さが生じ、ロールやポリシーの設定が緩くなりがちです。テンプレート化していただいた部分をきちんと守って進めれば、そのあたりをコードで担保できる点も大きいと思います」（大島氏）。担当者が増えたり引き継いだりしても、ガバナンスの効いた状態を最初から維持できる基盤が整いました。

さらにサーバーワークスは、クラウド側だけでなく機械本体側の環境準備手順書も作成しました。機体の制御に用いるRaspberry PiとAWS IoT Coreの接続方法や、AWSとの通信に関するネットワーク設定などを、同社独自のモジュールも考慮したうえで手順化しています。「途中から参加した開発メンバーもいたので、その手順書を確認しながら作業してもらっています」（大島氏）。

AWCSは現在も開発・実証段階にあるため、運用費の実績値はまだ出ていませんが、複数の費用試算によると、Amazon EC2のまま運用する場合と比べて大幅に下がる見込みです。

すでに実感している効果が、メンテナンス性の向上です。「バックエンド側のモジュールは当初からいくつか変わっています。Amazon EC2であれば一度止めてすべてデプロイし直すところが、モジュール単位の入れ替えで済むようになりました。稼働中でも更新が可能です」（大島氏）。

処理を分離したことによる効果もあります。例えば経路生成は、機体の稼働とは独立して実行できます。オペレーターが現場でモニタリングしている間に、マネージャーが事務所で翌日の作業経路を作成することも可能です。「同じAmazon EC2の中で経路生成と機体管理を同時に処理すると、パフォーマンスに影響が出る場合もありますが、それぞれを同時に実行しても互いに影響しません。モジュールの追加も容易なため、メンテナンス性は格段に上がっています」（大島氏）。

開発フローも大きく変わりました。以前は開発環境とステージング環境の整合を取るのに手間がかかることもありましたが、現在は一部にCI/CDを導入し、経路生成ではソースコードをコミットすれば自動的にデプロイされます。「以前は経路生成の開発者に頼まれて私が更新作業をしていましたが、今は開発者が自分でコミットすればよくなりました。私に『デプロイして』という依頼はなくなりました」（大島氏）。

中野氏も「経路生成を担当しているチームと、バックエンドからフロントエンドの表示までを担当しているメンバーとでチームが分かれていますが、それぞれが互いの影響を気にせず開発できるようになったので、開発効率が大きく向上しました」と語ります。エンベデッドシステム事業部 エンベデッドシステム開発３部長(兼)Ｒ＆Ｄセンター 副センター長で、プロジェクト全体を見渡すPMOの鈴木 教文氏も「AWSやWeb系、クラウド系の開発については、進捗が大きく改善したと認識しています」と効果を実感しています。

今後に向けて、同社はAIの活用を見据えています。現在は国土交通省に提出する報告書など定型の出力に対応していますが、荒川氏は「機械から取得したデータなどのエビデンスを活用し、AIエージェントを組み合わせて、お客様が求める報告書を出力できるシステムを実現したい」と話します。経路生成でも、草に隠れたマンホールや石などに接触して止まった場合に、AIを組み合わせてその場で経路を引き直せる仕組みを目指しています。

コストの検証も重要なテーマです。「200m刈ったときにAWSの費用がいくらになるのかを検証しないと、お客様に『使った分だけの費用です』と言えません。サーバーレスの考え方でうまく組み合わせれば、お客様のコスト負担を抑えられることを、根拠をもって示せるようになると考えています」（荒川氏）。

さらに大島氏は、すでに次の構想に着手しているといいます。草刈り機の自動運転から範囲を広げ、過去の作業履歴や草の生育状況、人員計画までを含めて、草刈り業務・農作業全体をITで支える管理システムです。

「草刈り機だけでなく業務全体を対象とし、自動運転の草刈り機をその一部に位置付ける形で、試行を進める予定です」（大島氏）。

サーバーワークスへの期待について、中野氏は「これまではロボット単体の範疇でシステム開発をしてきましたが、今後はロボットを使った業務のシステムをお客様に提供していく形に範囲を拡大していきます。データベースなどWeb系の役割がより多くなりますので、引き続きご支援をお願いしたいと考えています」と話します。鈴木氏も「クラウドやAIの最新の知見に期待しています。AIを活用したロボットや自律走行などの研究においても、AWSを活用したご提案や伴走支援に大いに期待しています」と語ります。

研究開発の成果を事業へとつなげる東日本計算センターの挑戦は、地域の課題、そして社会の課題の解決へと広がろうとしています。