Table of Contents
この文字起こしは、2022 年 12 月 7 日に開催された Authlete Customer and Partner Meetup 2022 のプレゼンテーションのひとつです。 株式会社 EARTHBRAIN の、技術開発G テクニカルリード 赤澤仁士氏、技術開発G シニアエンジニア イェン ファン バク氏に、建設現場をはじめとする IoT 分野での OAuth の適用と、その中での Authlete の活用をご紹介いただきました。
EARTHBRAIN の赤澤と申します。よろしくお願いします。本日は Authlete for Digital Construction と題し、我々が行っている建設業界向けの開発でどのように Authlete を利用しているのかをご説明します。
まず建設業界、あるいは建設業界に対するデジタルソリューションについて、馴染みのないかたも多いと思います。そちらについて冒頭で説明します。
次に、我々が取り組んでおります、プラットフォーム開発プロジェクトについて、なぜそれをしているか、またそこでどのように Authlete を利用しているか説明します。
そして、我々が選定するにあたりどのようなことを考えたか、その採用までの経緯を説明いたします。
EARTHBRAIN は、設立されてまだ 1 年半、去年 7 月に設立した会社です。
建設業界のプロセスのデジタル化、いわゆる DX を進め、生産性、安全性、環境適合性を高めていくというビジョン・ミッションを掲げています。
成り立ちですが、建設機械の小松製作所の子会社です。合弁会社となっており、NTT コミュニケーションズ、ソニーセミコンダクタソリューションズ、そして野村総合研究所から出資を受けています。
我々はなぜ建設業界の DX を進めているのか。 左側の図にある通り、建設業界はどんどん人が減っています。とくに、技能を持ち現場で作業をしてくださる人が減っています。とはいえ建設の需要は減っておらず、やや微増ぐらいの状況です。その結果需給ギャップが発生してきますが、人を増やすのは難しいです。そこでデジタル技術を使って生産性を上げ、そのギャップを埋めていくのが、我々のやりたいことです。
また右の図表に示していますが、建設業界の 90% 以上が中小事業者です。デジタル化に取り組み辛いという状況にあります。そこに対してソリューションを提案し、業界全体の生産性を高めていきたいと考えています。
建設業界は他業種と比べて、生産性や安全性、またデジタル活用など、向上できる余地がある状態です。我々のソリューションが、寄与できればと考えています。
EARTHBRAIN は設立されてからまだ1年半ですが、前身はコマツの社内プロジェクトです。
2013 年に、コマツは「ICT 建機」を出しました。これはセンサーが付いたブルドーザーで、建機をデジタル化しました。これによって現場の生産性が上がると仮説を立てて行ったものの、十分には生産性が改善されないことに、気づきました。
建設のプロセスには、準備をして、計画を立て、そして実際に工事をして、その後検査をして、維持管理をしていくという、たくさんの工程があります。その中で実際に建機が動くのは「施工」部分だけ、さらに細かく分割していくともっと小さい部分のみであり、その部分だけの生産性を上げても全体の生産性向上は大きくならないことがわかりました。
2015 年から SmartConstruction を立ち上げ、建設プロセス全体の生産性向上の取組を始めました。
2021 年に、その取組をさらに加速するため EARTHBRAIN を立ち上げました。
我々が取り組んでいる内容をご説明します。
たとえば、道路などで人がやっている測量を、ドローンや GPS を使ってデジタル化する、というものがあります。
また、図面のひとつとして断面図を使用しますが、断面図はあくまで「断面」でしかなく、断面と断面の間は経験と勘で埋めるしかない、そのため熟練した人しかできないのが現状です。これが 3D として表現されると、経験が少なくても作業が出来るようになります。
そして、その 3D で表現されたデータを建機に読み込ませると、建機の画面上に、いまこれくらい掘りました、あとどれくらい掘りなさい、といったガイダンスを出せるようになります。これまでは経験によって調整していたところをガイドすることにより、経験が少ない人でもすぐに戦力になれるようになります。このようなかたちでも生産性を上げることができます。
また、3D で表現したものを建機に読み込ませると申し上げましたが、プロセスをまたがって共有すると、さらに生産性が上がっていくことがわかってきました。
提供している具体的なサービスをご紹介します。
まずこちらの油圧ショベル。道を歩いているとよく見かけると思います。もともと、センサーがついた「ICT 建機」がありましたが、高価であったり、すでに油圧ショベルを持っていたり、という状況がありました。そこで、すでにお持ちの油圧ショベルに後付けできるセンサーキットを提供しています。
また、建機やダンプカーの位置情報を知りたいというニーズがあります。これに対し、専用デバイスやスマホアプリを作り、それを載せておくと、その場所がリアルタイムにわかる、というソリューションを出しています。
こちらはさきほど申し上げた、3D で現場を表現するソリューションです。ブラウザ上で、現場を表現できます。このように現場を 3D で表現すると、たとえば、こんなふうに斜面を削ったら土の量はどれくらいになるだろう、というのが計算できます。また、面積をブラウザ上で計測したり、アノテーション（注釈）をつけたりできます。
ここからは我々が現在取り組んでいるプラットフォーム開発についてご説明します。
さきほど申し上げた 3 つの例や、開発中のものも含め、この図にある四角の一つひとつが、我々のソリューションです。
さきほど、横の連携が大事であると申し上げました。デバイス、ハードウェア、スマホアプリ、そして Web アプリなど、いろいろな提供形態があります。それをどうやって連携させるか。
我々はこの灰色の部分、プラットフォームのレイヤーを構築し、3 年ほど運用しています。役割としては、認証・認可、データの受け渡し、そしてユーザー、企業、建設業界特有の「現場」という概念、またライセンスの管理などを担っています。
今回 Authlete を採用させていただいたのは、このプラットフォーム開発プロジェクトです。
今稼働しているプラットフォームはベンダー主導で構築した経緯があったのですが、機能拡張・追加に迅速に対応したいというニーズが強くなってきました。
また、建設業界の標準規格に対応したいということもありました。
あと、さきほど申し上げた「現場」のような、建設業界特有の概念があります。それらに対応していく需要もありました。
そして、さきほど例を 3 つご紹介しましたが、我々はかなり幅広いアプリケーションを出しています。それらアプリからのプラットフォームに対する要件にも迅速に対応する必要がありました。
さらに、障害発生時に我々の手の内でコントロールしたい、あとは開発者向けの SDK やツールを充実させたい、といったことがありました。
そのようなことで、今回のプラットフォーム開発プロジェクトを進めています。ここからはエンジニアの Bach にバトンタッチして説明を続けます。
EARTHBRAIN の Bach と申します。ここからは開発についてお話しします。
こちらが我々のプラットフォームです。このプラットフォームの内製化プロジェクトをやっています。
いろいろな建機がプラットフォームへ、API 経由でデータを送信します。プラットフォーム内ではデータの保存・処理を行います。また、API 経由でアプリケーションと連携します。プラットフォームの API は OAuth 2.0 によって保護されています。またログイン処理が必要なアプリケーション向けに OpenID Connect も提供しています。API の本数はかなり多く、約 200 種類あります。
OpenID Connect や OAuth 2.0 については、詳しい人間が内部におらず、外部のサービスを使う予定でした。
外部サービスには 2 つの選択肢がありました。IDaaS (Identity as a Service) と BaaS (Backend as a Service) です。IDaaS は「あるソリューション」、BaaS は Authlete を指しています。
当初は、ある IDaaS を優先的に検討していました。IDaaS のほうが、メリットが多いと考えていたからです。
ただし一点、柔軟性に関しては、BaaS のほうにメリットがありました。IDaaS はそのまま使える機能をいろいろ提供していますが、我々のプラットフォームの必須要素と異なる部分があるため、IDaaS の柔軟性は △（三角）としました。BaaS ではそもそもそのような機能が提供されていないため、実装する必要はありますが、柔軟性は高いと言えます。
IDaaS の検討にあたり、PoC を実施しました。すると、IDaaS の機能を活かしきれないことが徐々にわかってきました。課題が 5 つありました。
IDaaS が提供するエンドポイントが現行プラットフォームのインターフェースと一致せず、OAuth の規格も満たしていません。IDaaS を使うためには、それらのエンドポイントをラップする必要があります。
パスワードを IDaaS 、もしくはカスタムのデータベースに保存するとした場合、IDaaS の対応可能なハッシュ方法が限られているため、現行プラットフォームのハッシュ方法に対応できません。こちらの部分も独自に実装する必要があります。
IDaaS にはサインアップ機能がありますが、その他のいろいろな機能、たとえば ユーザーのプロフィール画像や、現行プラットフォームが備えていたメール確認機能などはサポートしていないため、独自実装が必要です。
IDaaS では、アクセストークンに含めるクレームの要件を完全に満たせません。
アクセストークンを選択的に失効させる機能がありません。
こちらは IDaaS と BaaS の比較です。
IDaaS の機能はほとんど使えず、API をラップしたり、独自実装したり、といった作業が必要となります。
後半の2つの課題についてです。
IDaaS では、アクセストークンに含めるクレームに関し、要件を満たせません。任意クレームの追加はできますが、クレームのキーは URL 形式でなくてはなりません。そのため、既存のアプリケーションを修正する必要があります。それは我々としては望ましくありません。一方 BaaS では、任意クレームの追加が可能であり、かつ、キーは URL 形式である必要はありません。ただし利用可能なクレームの値は、当初は文字列型のみでした。そこで Authlete さんに相談したところ、配列型も Authlete 2.3からサポートされるようになりました。
最後の失効機能について、もともと IDaaS にはそのような機能が存在しません。一方 BaaS では提供されています。
結論として、開発コストに大幅な違いは無いが、IDaaS はその提供する機能がほとんど使えないために BaaS よりもかなりコストが高くなることがわかりました。
よって、IDaaS ではなく BaaS の検討を優先することにしました。
ということで、BaaS を優先的に検討することにしたのですが、しかし当初は Authlete もそのまま使えるかたちではありませんでした。そこで Authlete さんと議論し、いろいろな機能を追加してもらいました。具体的には次の4つです。
ひとつ目が JWT 認可グラントです。これは現行プラットフォームにある認可フローのひとつです。Authlete は当初このグラントをサポートしておらず、もしそのまま非対応となった場合には、認可サーバーの実装は困難になることが想定されました。
しかし Authlete さんに相談したところ、5 日間という非常に迅速な期間で実装していただけました。我々にとって大変役に立ちました。
次の機能は、先にお話ししたアクセストークンです。我々のプラットフォームでは、アクセストークンは JWT 形式であり、ペイロードに配列型の値を含んでいました。しかし Authlete バージョン 2.2 では、配列型の追加はできませんでした。つまり、このスライドの赤字で書いた部分の追加ができないことを意味していました。
しかし、Authlete バージョン 2.3 から jwtAtClaims パラメーターが追加され、こちらを経由して配列型を追加できるようになりました。
次はトークン交換の機能です。こちらは土木業界で必要とされる規格です。
具体的には、サブジェクトトークンとアクタートークンを用いて、新しい種類のトークンを発行するものです。詳しい内容は Authlete さんの記事を参考にしてください。
最後は PKCE です。我々のプラットフォームには、PKCE の利用が必須化されていない（任意とされている）クライアントも存在します。
そのため、PKCE の必須化をクライアント単位で設定できることが非常に重要です。Authlete さんに相談し、そのように設定できるようにしてもらいました。
開発の流れを少しお話しします。
当初、我々には OAuth 2.0 と OpenID Connect の知識がほとんどありませんでした。しかし Authlete さんがいろいろな言語の実装のリポジトリを提供しており、我々はその中から Go 系のライブラリを参考にして認可サーバーを実装できました。
Go 系のリポジトリには 3 つあります。ひとつは authlete-go です。こちらには DTO や const の定義があります。もうひとつは authlete-go-gin です。認可サーバーをかんたんに実装するためのコンポーネントを提供しています。最後に gin-oauth-server が、認可サーバー実装の例です。
PoC 的に実装してみたところ、すぐに Go で必要な API を動かせました。なお本番環境では、authlete-go のみを実装に用いています。
そして、きちんと認可サーバーを立ち上げて運用することができました。Authlete による多くのサポートは、我々にとって非常に役立ちました。
以上で発表を終わります。ご清聴ありがとうございました。
