エンジニアが語る特許出願中AIサービス開発の裏側【対談企画 Vol.2】

今回は対談企画第2弾！ AIの運用を管理する専用アプリケーション「Hutzper Insight」について、特徴や開発経緯など、詳しく深堀していきます！

～対談者紹介～

大西洋 / 代表取締役兼CEO

兵庫県出身。広島大学工学部卒業。専攻テーマは製造プロセスの最適化。新卒で日東電工に入社し、ICT部門の法人営業に従事。退社後はWebサービスを開発し、イスラエルで起業を試みるも失敗。その後工場向けAI/IoTベンチャーの事業開発グループリーダーを経て、弊社を設立。

山田裕太郎 / エンジニア

福井県出身。大阪大学基礎工学部情報科学科卒業。専攻テーマはマルチコアCPU搭載デバイスの高速化。卒業後はシマノに入社し、電動変速機のファームウェア開発を担当。退職後は自作センサの開発等に取り組み、2021年2月よりフツパーに参画。

山本祐己 / エンジニア

大阪府四條畷市出身。神戸大学卒業。大学在学中からNPO法人での活動やインドでの長期インターンシップを経験、その後スタートアップ複数社でリードエンジニアとしてWebサービス立ち上げを経て、フリーランスエンジニアとして独立し、AI開発案件に従事。2022年2月よりフツパーに参画。

鈴木雅之 / エンジニア

学生時代、エンジニアのインターンとして働く中で岡山でフツパーCEO大西と出会い、大西とともにイスラエルで起業。イスラエルから帰国後は、株式会社Branding Engineerでエンジニアとして勤務。 その後フリーランスのエンジニアとなり、複数の企業で業務委託としてシステム開発に従事。また2020年に株式会社Positive Spiralを創業し、主にIoT関連システムの受託開発を行っている。

Hutzper Insight とは？

山田：Hutzper Insightとは、製造現場で収集したデータをWeb上で可視化できるようにするサービスです。

Hutzper Insightには、AIが不良と判定した画像を人の手で本当に不良かどうかを振り分け直す「画像分類」という機能があります。お客様ご自身に不良画像を正しく振り分けて頂くことで、AIの精度が上がっていきます。こちらがHutzper Insightの一番重要な機能となっています。

その他には「統計一覧」と「通知一覧」という機能があります。「通知一覧」は過去に収集したデータを全て閲覧できる機能で、「統計一覧」は過去の収集データをより分かりやすく可視化する機能です。例えば良品・不良品が1日あたり、1週間あたりで何個生産されているか等、様々なデータを確認することができます。

山本：Hutzper Insightには、最近「GUI」の機能も追加されました。いわゆるノーコードAIといわれるツールで、GUIを用いて簡単な操作でAIモデルを学習させることができるんです。

GUIの機能では、任意の画像データを使ってデータセットを作成し、それを使ってAIモデルの作成が出来るという特徴があります。お客様の現場で収集したデータをクラウドにアップして頂くと、その画像データを使っていろんなAIモデルを試すことができます。アップロードしたデータセットをAIに学習させて、精度がどれくらい出るかをテストすることも可能となっています。

Hutzper Insightの開発秘話

大西：Hutzper Insightの概要が分かったところで、Hutzper Insightの開発の経緯などについて聞いていきたいと思います！

山本：僕も気になります！僕が入社した時にはすでにリリースした状態だったので。

山田：初期バージョンの大半は鈴木さんが作られてますけどね(笑)

鈴木：どういう感じで作ってたのかとか、裏話もしていきたいですね。

大西：Hutzper Insightの開発は、たしか2020年5月ごろ、鈴木くんに「3か月くらいでプロトタイプ版の作成をお願いしまーす！」って依頼したのがスタートだったよね。

鈴木：はい、そうですね。すごく懐かしいです。

大西：当初はどんな感じで進めていったんだっけ。

鈴木：大西さんがモックを作ってくださってましたよね。

大西：そうそう。「エッジデバイス内でAIが判定した情報を、現場に行かずともリアルタイムで見れて、複数の工場があっても問題なく見れる画面の構築がしたい」「SaaS形式で提供できるIoTのサービスを作りたい」というのが最初の要望だったね。

鈴木：はい。その頂いたモックをもとに、私がデザインを作りました。

大西：創業当時の初期構想のホワイトペーパーにもHutzper Insightのイメージが書いてあって、当時、鈴木くんに口頭で話したことは全て、このホワイトペーパーのど真ん中に書いてます。

大西：現場にエッジデバイスを設置して、カメラと繋いで、画像認識のAIが良否判定を行う。その時にIoTに特化したMQTTっていうプロトコルを利用して、データの通信量を少なくして、工場のネットワーク環境が悪くてもデータを送れるようにしたいと考えていて。そして、AWSのIoT CoreやLAMBDA関数を経由してデータを送って、AWSのS3に画像を保存する。そのうえでリアルタイムの良品・不良品のテキストデータの判定情報だけはすぐに画面に出るようにする。

AIのモデルもクラウドで学習して保存しておいて、AIが学習したものについてはAWSのGreengrassという機能を使って、現場にあるエッジデバイスに更新をかける。こんな風に「集まったデータでクラウド上で再学習を行いモデルの精度を上げていき、遠隔で現場に設置されたエッジ機器の中のモデルを更新していく」みたいな構想があったわけです。あとは何かあったらメールで通知してくれたりとか、PLC等の現場の機器類とも連携して後工程の処理をさせたりとか。

これが当初のHutzper Insightの構想でしたね。

初期構想～Hutzper Insightのプロトタイプが出来るまで

鈴木：実際に開発をしてみたら、わりと最初の構想の通りに実装できた感じはありました。でも最初、大西さんから構想のお話を聞くまで、僕はMQTTやAWSのサービスについて熟知していた訳ではなかったので、どういう風に実装しようか…と悩みましたね。AWSの中には、メジャーでトレンドのあるサービスに使われる機能であれば、どんなサービスでもあるんです。でも僕がそれを知らなくて、なんか変な感じに実装しようとしてたんですよね。

そこでAWSのIoT Coreを使うと、もっとシンプルに実装できたんです。

もともとHutzper Insightで使われる機能自体はすごくシンプルなんですよ。見る、編集する、削除する、更新する、といった基本的な機能なので。だから、一旦そういった機能はフレームワークを利用して綺麗に実装しました。

その中で意識していたのは「レガシーなコードを作らない」ということと「リプレイスが簡単になるようにAWSを使い回そう」ということです。まだプロトタイプの段階だったので、早い段階でリプレイスされて全部機能が消える可能性もありましたし。違う機能を加えたくなった時にすぐ実装したり、機能が要らなくなった時にすぐ捨てたりできるように、とにかくリプレイスがしやすいようにAWSを上手く使って実装していきました。

あ、ちなみにInsightのプログラミング言語はRubyを使っていて、フレームワークもRuby on Railsを使ってます。

大西：そんな感じでしたね。

大西：そういえばプロトタイプが完成するまで、鈴木くんとの打合せって数えるほどしかしてなかったよね。1時間くらいのミーティングを2～3回しただけで。それなのに、鈴木くんが「こんな感じですか」って出してきたプロトタイプがほぼ100%構想通りのものだったんですよね。

鈴木：今思うと、ありえないくらい少なかったですよね、打合せの時間。

大西：まぁ、ほぼ機能が変わる前提で作ってたもんね。

鈴木：そうですね。デザインについてはすぐに変わるだろうなって話してて。だからホントにスピード重視で作ってました。

Hutzper Insightのインフラ構成

大西：鈴木くんは当時「インフラ構成については、ひらめきました！」って言ってたよね。Hutzper Insightのインフラ構成について、簡単に説明をお願いしてもよい？

鈴木：もともとは、工場にあるエッジデバイスから送られるデータを普通にWebサーバで受け取るようにしてたんです。でもそれだと、サーバが死んだ時に全ての機能が落ちてしまう。なので、とにかく分散させることを意識して、もしサーバが落ちてもデータ保持だけは絶対に出来るようにしたいと思って。IoT CoreなどのAWSの仕組みを上手く使って、冗長性のある構成にしました。

大西：あとセキュリティも結構固めの構成にしてくれてたよね確か。

鈴木：そうですね。セキュリティに関してもAWSの機能を利用しました。

Hutzper Insightの場合「リアルタイムで見続ける」っていう要件がありました。でもWebサーバ側でリアルタイムで見るとなると、サーバが1秒間に1回とかのペースで毎回リクエストを処理して返さないといけない。この場合、もしお客様が20社、30社と増えてきて同時に見る人が30人くらいになったときに、サーバが絶対に落ちてしまうのは目に見えてました。だからHutzper Insightでは、IoT Coreのブローカーを通じて、サーバやデータベースを経由せずに、お客様のブラウザに直接データが届くようにしてるんです。そのインフラの仕組みをひらめいた時には「これだ！」と思いましたね。

大西：すばらしいですね。

鈴木：この構成をひらめいた時は嬉しかったですね。

山田：これ、めちゃくちゃすごいですよね。正直すごすぎてあまり外に言いたくないくらいなんですけど。この仕組みなら、データが欠損する可能性がほぼゼロですもんね。しかも、負荷をどれだけ増やしても耐えられる。

大西：データ欠損がない上に、スケール性も担保されてるという。

鈴木：わかりやすく言うと、お客様がHutzper Insightのリアルタイム画面を見てる最中にWebサーバが死んでも、お客様は最新のデータを取得できるんです。基本的にAWS IoT Coreが死なない限りはちゃんとデータベースに保存されますし。

大西：将来的には、データベースとAPI機能の裏側の仕組みを強化して、もっと色んな用途で使ってもらえるようなIoTサービスに振り切っても十分価値があると思う。

鈴木：Insightってもともと工場特化のイメージで開発してて、「工場から画像データを取って来てそれをリアルタイムで見る」っていうサービスのイメージがあったんですけど…。サイネージ広告のそばにカメラを置いて視聴者のデータを見る「ミワタス」っていうサービスの話が出た時から、もっと抽象的に言うと、Insightは「どこからでもデータを取って来て、スムーズに効率よくデータを保存して見せるサービス」だと言えるんじゃないかなと思っていて。

大西：ミワタスの裏側で動いてるのも、実はHutzper Insightだったりするんです。カメラに映っている人の属性データをプライバシーを保護した形式でHutzper Insight内に収集して、それをAPI機能を使って別のサイトから取得できるようにしていて。こんな風に、Hutzper Insightの、現場のデータを取って他のサイトに飛ばすっていう機能は、製造業以外の分野でも使えるようになってます。

鈴木：このAPI機能の実装をしたのが、創業1年目の終わりくらいでしたね。

あと僕が3か月でプロトタイプを作ったタイミングで、UIも一新しましょうという話が進んでて、それも合わせて行いました。現場で使用する人の要望を反映させつつ、画面のデザインを考えていきました。

フツパーではエッジデバイスにソフトを仕込んで、工場に設置して作業してると思うんですけど、その場合、エッジデバイスサイドの設定を変えるときにすごく手間が掛かってしまうんです。現地に行くか、遠隔で操作できるようなソフトを入れるかという方法になるので。でも、それを自動化できるような仕組みがAWSのGreengrassで作れると分かって、その時に実装しました。創業2年目には、リアルタイム映像を見れる機能も追加しました。これは結構時間がかかりましたね。

大西：画像分類の機能も確か2年目に実装したんだったね。

鈴木：はい。今のHutzper Insightの画面が出来ていった経緯としては、こんな感じですかね。

特許取得中の機能

大西：再学習機能についても話していきたいと思います。

山田：はい。エッジで画像を処理して、その生データをクラウドに全部送ると、データ通信料などのコストが高くなってしまいます。Hutzper Insightの再学習機能は、異常時の画像のみをクラウドにアップして再学習に利用することで、コスト削減を実現するような仕組みになってます。

大西：ちなみにこの再学習の機能は、いま特許取得中です。今まで「現場で処理をするだけでクラウドとは一切繋がってなくて、データを遠隔で見れないシステム」か「データを全部クラウドで処理して、全部クラウド上で見れる代わりに、処理速度が遅くてコストも高いシステム」のどちらかしか無かったんですけど、そこのいいとこ取りができるんです。それが特許を出願してる技術の特徴で、Hutzper Insight自体の強みでもありますね。

山田：機械的な処理は全てエッジ側で行って、仮に通信が止まっても動くような処理にしつつ、お客様が見たいデータに関してはいちいち現場に行かなくても遠隔でチェックできるようにしています！

GUI機能の実装

鈴木：Hutzper Insightの再学習機能に関しては、もともとフツパー側でお客様からデータを収集して再学習を行うという形でしか再学習ができなくて、それをお客様ご自身で不良品の画像を収集してAIの再学習まで出来るようにするため、山本さんにノーコードツールの開発をお願いしたんでしたよね。

山本：はい。本格的にGUIを作り出したのは今年の3月ごろで、まだ僕は入社したばかりでした。現場で弊社のエンジニアが行っている作業についてヒアリングして、それをどういった形でWeb上で出来るようにするかを考えていきました。

山田：鈴木さんから、僕と山本君がHutzper Insight関連の仕事を引き継いだんですけど、引継ぎ期間では僕と山本君の2人で鈴木さんに質問をしまくってましたね。

Hutzper Insightは元の設計がすごくシンプルで、フロント側は多少変わっているんですけど、インフラ構成については鈴木さんが最初に考えた構成が「これ以上のものはない」と思うくらい良かったので、ずっと変えていないです。

大西：創業2年目くらいから、ほぼ鈴木くん1人でInsightを作っていたところを、フツパーメンバーに徐々に業務を引き継いでいったという感じだよね。

鈴木：山本さんとお仕事していたときに、山本さんが要求仕様書をすごく細かく書いてくださったんですよ。あれが結構大きかったなと思っていて。それまでHutzper Insightの開発では「こういったものを作りたい」というのを結構なんとなくで進めてしまっていて…。これは認識の違いが起こってしまうので、本来は絶対に良くないことなんですけど。

そんな時に山本さんが「こんな機能が欲しいです」というのを要求仕様書の形でしっかりと書いてくださったので、僕もすごく実装しやすかったです。画像分類の機能を実装する時とか、僕自身もどんなUIにしようか迷ったりもしていて。そこで仕様書が共有されたことで、Insightの開発が格段に進めやすくなったなと感じました。

山本：鈴木さんから「話がややこしくなってきたので、これ書いてください」って要求仕様書のフォーマットが送られてきて、それを僕が社内で相談しながらゴリゴリと書いていったという感じです。その仕様書を書くのにはすごい時間が掛かったんですけど、仕様書が出来てからの開発はめちゃくちゃ早かったですよね。たしか1か月も掛からなかった。

鈴木：そうですよね。実装もすぐに出来ました。逆に仕様書が完成するまでの道のりは、確かにすごく長かった印象があります。

大西：仕様書を作ってる時に、これは1年目の頃からだけどもFigma (Webデザインツール)をみんなで使ったのも良かったよね。鈴木くんが最初にFigmaで画面のイメージ図をほぼ完成形の状態で見せてくれて。

鈴木：あれは良かったですね。Figmaで画面のデザインを共有しながら話すと、こういったところを押せばこういう機能が動く、みたいなイメージが伝わりやすいので、仕様書についての議論がスムーズに出来ました。

Hutzper Insight 今後の展望

大西：最後に、Hutzper Insightの今後の展望について話して対談を終わりたいと思います！

山本：はい！機能的な部分での展望では、ノーコードツールでの学習に使えるモデルを増やしていこうと思っています。今は分類モデルのみなんですけど、弊社の「良品のみ学習モデル」や物体検出のモデルも学習に使えるように実装していきたいですね。

山田：今、Hutzper Insightはメキキバイトの支援サービスのような位置づけなんですけど、今後もしHutzper Insight単体でサービスとして提供できるようになったら、めちゃくちゃ会社としてもインパクトが大きいなと思っていて。それを実現できるように頑張りたいと思ってます。

正直、まだ誰もHutuper Insightのすごさに気づいていないなと僕は思っているんです。Hutzper Insightって、普通にWebサービスとしてめちゃくちゃすごいんですよ！負荷が掛かってもデータが欠損しないっていうのは、普通のことのようで全然普通じゃないんです。エッジ端末を多く接続すると、普通のWebサービスならサーバに負荷がかかって落ちてしまう場合があります。でもHutzper Insightではそういった問題がこれまでに全く起こっていない。「データが失われることがない」って、本当にすごいことなんです。

それを実現するインフラ基盤が出来ていて、かつスケール性もある。データの保持は確実に出来て、あとは集めたデータをどう見せるかだけ考えれば、この基盤をどんなサービスにも活用できます。

だからHutzper Insight単体で売り出していく方法を、これからもっと営業陣とも協力して考えていきたいなと思っています。

大西：たしかに！Hutzper Insightのすごさをもっと広めていきたいね！

この記事を見て「フツパーで働いてみたい！」と感じてくださった方は、ぜひ以下のリンクからご応募ください！ 社員とのカジュアル面談や、正社員・インターンなどへのご応募が可能です！