アーカイブ動画

■登壇者プロフィール

株式会社ＮＴＴデータ
製造ITイノベーション事業本部
第五製造事業部　コネクティッド統括部
第一開発担当　部長　千葉 祐氏
NTTデータ入社後、研究開発部門で様々な外部パートナーと連携しながら大規模ミッションクリティカルシステムのオープン化の技術開発に従事。その後、クラウドサービスを企画・立ち上げを担当。データセンターの営業や、広報部にグローバルでの全社ブランディングを経験。2018年から現職で、次世代コネクティッドカー基盤の技術開発プロジェクトをリードしている。

株式会社ＮＴＴデータ
製造ITイノベーション事業本部
第五製造事業部　コネクティッド統括部
第一開発担当　課長　竹内 一弓氏
大学ではオペレーティングシステムを研究。入社後、オープンソースソフトウェアの様々な業種(テレコム、製造、金融etc.)への導入に取り組む。現在は、コネクティッド領域で、特に大規模で高性能・低コストが求められるシステムの研究開発および商用導入に従事。

株式会社ＮＴＴデータ
製造ITイノベーション事業本部
第五製造事業部　コネクティッド統括部
第一開発担当　課長　柿沼 基樹氏
NTTデータ入社後、オープンソースによるIT基盤技術のR&Dを通じた現場支援（公共分野、法人分野等）、NTT研究所の研究成果の事業適用などを実施。現在は、スマートシティにおけるプラットフォーム技術開発、サービス開発に資する技術開発に従事。

パネルディスカッション モデレーター

樽石デジタル技術研究所合同会社　代表社員
Retty Innovation Lab　ラボ長　樽石 将人氏
Google、RedHat 等でソフトウェアエンジニア、SRE、SA として、OS、ミドルウェア、ナビ等の開発を担当。東日本大震災時には Google パーソンファインダの開発リーダー。その後楽天にて次世代プラットフォーム開発の一翼を担い、14年6月よりRettyにCTOとして参画。18年より脱炭素xITの個人事業を展開し、2021/12に樽石デジタル技術研究所設立。ヤフーギグパートナー・テクノロジースペシャリスト、早稲田大学データサイエンス研究所招聘研究員、PowerX技術顧問、他。

トヨタ自動車とコネクティッドカーの研究・実装に取り組む

最初に登壇した千葉祐氏は、まずコネクティッドカーについての概要や現状を説明した。 ここ数年でコネクティッドカーは、一般社会にも浸透してきたが、サービスとしてはまだ発展途上の段階である。具体的にはどのような付加価値を生み出すのか。考えていかなければならない技術課題もあると、千葉氏は語る。

コネクティッドカーにはカメラや高精度のセンサーが搭載されており、多様かつ大量のデータを取得する。得たデータは無線ネットワークを通じてサーバーに蓄積し、分析するなどして、様々な付加価値を生み出していく。当然、サーバーから車に対してのデータ通信も行われる。

現在、世界で販売される新車約9000万台の3割、約3000万台をコネクティッドカーが占める。国内でもすでに数百万台規模に上っており、今後も増大傾向にある。

「コネクティッドカーのOTAという機能は、無線ネットワークを通じて車両のソフトウェアをアップデートします。スマートフォンなどのデバイスでは当たり前に搭載されている機能であり、自動車メーカーではテスラがすでに導入しています」（千葉氏）

続いて千葉氏は、コネクティッドカーが生み出す価値を紹介した。１つ目は部品の摩耗状態を事前に検知することで、「ドライバーの安心・安全」を高めること。2つ目はカメラ画像を活用し渋滞を緩和することで都市部で多発する「社会課題を解決する」。3つ目の「新たなモビリティサービスの創出」では、ドライバーの運転特性を洗い出し、安全運転の人は保険料を安くする、といったもので、すでに同サービスは実現している。

また、信号機と連動することで排気量を減らすといった「カーボンニュートラルな社会の実現」も、コネクティッドカーが広がることで生み出す価値のひとつだと説明した。

一方で、まだまだ技術課題は多く存在するという千葉氏。代表的な技術課題を紹介した。例えば、開発期間やライフサイクルが長いという課題だ。現在の車は高性能になっており、10年ほど乗れる。対して一般的なIoTデバイスで、10年保つものは稀である。

つまり、コネクティッドカーを実現するには10年という長いライフサイクルを意識した技術開発が求められる。また、常に高速で移動している点も他のIoTデバイスではあまり見られない特徴であり、特にトンネル内など電波が届きにくい状況を考慮する必要がある。

「NTTデータでは、こうした技術課題を解決するために2016年ごろから、トヨタ自動車さんと共同で技術開発の取り組みをスタートさせており、発足当初から週に一度の頻度で、技術検討ワーキンググループを開催しています」（千葉氏）

技術検討のワーキンググループには、NTTコミュニケーションズなど、グループ各社や研究所も参加している。ワーキンググループで得られた先の課題を解決する要素技術を、実機で社会実装可能なレベルであるかの検証も行う。

両取り組みを短期間でサイクルすることで、技術開発や課題解決を進めており、この取り組みは現在も継続中である。

ITエンジニアの腕が鳴る。インフラ技術の飽くなきベストプラクティス

続いて登壇した竹内一弓氏は、実際にコネクティッドカーのシステム構成図やデータの流れを紹介した。車両が得たデータは以下のスライドのように、ストリームもしくはバッチ処理した後、外部のアプリケーションと連携する。

「コネクティッドカーや自動運転を支えるシステムですが、スマートフォンなど、一般的なサーバーサイドのITシステムとそれほど変わりません」（竹内氏）

  コネクティッドカーならではのコンポーネントとしては、道路状況や標識といった詳細データが記載される高精度な3次元地図「ダイナミックマップ」とも連携することだ。

「重要なのはデータの規模です。日本だけでもすでに数百万台走っていますから、膨大な規模に対応できるシステムを構築する必要があります。技術やプロダクトを選定していくと、ベストプラクティスがあるようでない世界だと、分かってきました」（竹内氏）

竹内氏は各技術領域でどのような技術選定を行っているのか、意図や成果と合わせて紹介していった。

１）通信プロトコル

現在の通信の仕組みを考えると「常時接続型」がいいと竹内氏は語る。HTTP2、MQTTv5、HTTP3などが候補に挙がったそうで、それぞれの特徴をスライドで紹介した。

また、QUIC技術がベースとなるHTTP3であれば、TCP/IPをベースとしたHTTP2、MQTTv5で問題となっていた、ヘッドオブラインブロッキングが起きない。その他にも、新しい通信プロトコルということで魅力的な機能が多く盛り込まれており、当初はベストプラクティスだと考えていたと、竹内氏は語る。

ヘッドオブラインブロッキングとは、スライドの下部でも説明しているとおり、1つのデータ処理で問題が生じた場合、続く処理に影響が出る事象だ。ただ実際にはHTTP2でも最適なロードバランサーを介せば、問題ないことが分かった。

一方でHTTP3に関しては、最新のプロトコルであるからこそ、いつから安定的に使えるのか、1つのコネクションをどこまで共用させるべきかといった問題がある。実際の選択ではどれを選ぶべきか悩ましいと説明した。

２）大規模データ蓄積・バッチ処理

コネクティッドカーからのデータは大量となるため、蓄積・バッチ処理では大規模分散バッチ処理に強いHadoop系のツール、SparkやFlinkを挙げた。

クラウド利用が前提であれば、オブジェクトストレージが直接クエリを処理するタイプの製品が有効な場合もあり、こちらでは、BigQuery（GCP）やAthena（AWS）などを紹介した。技術の選定についてはこちらも通信プロトコルと同様に悩ましいが、技術者の好みや強み、AWS/GCPどちらを使っているかなどを考慮した上で選定すればいい、と説明した。

分散処理エンジンの選択は重要だが、それ以上に重要なのがデータフォーマット。蓄積と分散SQLクエリエンジンとの相性を考えると、カラムナ型が最有力であり、今はParquet一択だという。

データは一度蓄積させるとその後変更することが難しいため、最初のフォーマット選定が重要だと竹内氏。カラムナ型を勧める理由についてはスライドの下部に、同じカラムが整列されていること。ヘッダー・フッダーがついており、メタ情報も記載されていることを挙げた。

ただし、車のセンサーは数百から数千におよぶため、対応できるのかどうか不安もあった。データ構造はコストとスピードの直結するため、チューニングの一丁目一番地だと竹内氏。標準的な仕様を検討する一方で、独自のバイナリーデータ構造を考えることも重要であり、実際に取り組んでいる。

「将来バージョンアップした際のことを考慮すると、やはりフレームワークやツールといった透過性のある技術として実装することが重要です。普段から社内に多くいるHadoopのコミッターから情報を得ることを心がけています」（竹内氏）

セッションを通じて何度も繰り返し発していたメッセージでもあったが、ベストプラクティスだと思っても実際にやってみること。その上で新たな技術を検討すること。「PoCとR＆Dを繰り返すことが重要」と述べた。

３）リアルタイムストリーミング処理

車両を制御するストリーミング処理設計のポイントは、メッセージングシステム、ストリーミング処理エンジン、メッセージ形式の選定。そして、同時に悩みどころでもあると述べ、それぞれで検討した技術サービスを紹介していった。

メッセージングシステムについては、OSSからAmazon、Google、Microsoft各社のサービスを挙げ、「どれも似たような機能であり、再取得の可否で変わる程度で選択肢がない」と、説明する。

エンジンにおいては、システムに合致したものを選ぶことが重要である。具体的には、Hadoopをルーツとしたプロダクトが多数あり、データ量により課金されるものもあると、こちらもスライドで細かく紹介すると共に、次のように補足した。

「ストリーミング処理はバッチ処理と比べて難しいです。システムが壊れたときには、データがもうなくなってしまった、ということもあるからです。業務SLAを考慮しつつ、どこまで特殊ケースに対応するか、よくよく検討が必要です」（竹内氏）

メッセージ形式においては「No IDL、No Message！」という強いメッセージと共に、実際にIDL（Interface Description Language）を使うことが多いと説明。ただIDLも奥が深く、ここでもPoCとR＆Dを繰り返し、ベストプラクティスを見つけることが重要だと強調した。

最後に竹内氏は、AmazonのメッセージングシステムKinesis Data Streamsに、Apacheの Sparkストリーミングのリアルタイム処理を実装したところ、動かなかった失敗事例を紹介し、その理由と教訓を説明しセッションをまとめた。

「理由はEMRのライブラリバージョンが古いという、今となっては笑い話的な理由でした。ただこの失敗から学んだのは、当たり前のことをきちんと検証するということ。PoCはもちろん、R＆Dが重要だということです。実際、現在もFPGA、WebAssembly、Snowflakeといった各種技術領域の開発に取り組んでいます」（竹内氏）

コネクティッド基盤が抱えるクラウドの技術課題

次に、登壇した柿沼基樹氏は「コネクティッドカー基盤を構築する上では、現在のクラウドでは不十分だと、数年前からずっと考えていた」と切り出し、何が不十分なのか、大きく4つの点について説明していった。まずはリージョン不足である。

柿沼氏は上記のように、「190」「21」という2つの数字を掲げた。190はグローバルナンバーワンの自動車メーカーが車を輸出している国数。対して21は、グローバルナンバーワンのクラウドベンダーが展開しているリージョン数である。日本、北米、欧州などの先進国ではそこそこ足りているが、発展途上国では圧倒的にクラウドが足りない事実を示した。

2つ目の課題はコストだ。1000万台のモビリティからドライブレコーダーで仮に5分間データを集めると、データの収集量は1日約90TBとなる。つまり、月で2.7PB、年間約32PBとなり、クラウドコストが保存費だけで約10億円かかる。さらにexabyte（エクサバイト）クラスのデータ保存では、1EBで年間約326億円もかかると指摘する。

「クラウドが登場したころ、インフラエンジニアは手軽に容量を増やすことができるクラウドに魅力を感じました。ところが、自動車メーカのように半端なくクラウドを使うユーザにとっては、コストがネックとなり、ビジネス上の足かせになっています」（柿沼氏）

またAmazonS3は、IOPS（Input/Output Per Second）の制限があり、無限に使えるわけではない。4つ目の課題は、エリアごとによる要件の差異だ。

例えば日本で、クラウドサーバーレス環境でアプリを実装したとする。そのアプリを他国で使おうとしても、リージョンにより利用できるサービスの差異があったり、機能が限定されてしまい、日本と同一構成で構築できない場合もあるため、サーバーレスアプリが使えない。あるいは交通ルールや標識など、データの仕様も各国によって異なる。

従来の思考を捨て、新たな開発DNAを。Cloud Abstraction Layerが解決

では、これらの課題を解決するにはどうすればいいのか。柿沼氏はセッションの根幹とも言える想いを明かした。

「これまで課題解決に取り組むことを業務として、日々取り組んできました。しかしコネクティッドカー基盤の開発では、従来の思考や開発プロセスでは到底太刀打ちできないと考えています。これまでの常識や前例を捨て、マクロな視点で未来を考えるDNAを育み、取り組む必要があります」（柿沼氏）

柿沼氏は思想的な変化に加えて、実際にイメージしている案についても説明した。ポイントはAbstract（抽象化）である。クラウドはあくまで部品であり、どのクラウドサービスを使っているかは問題でなく、利用者も特に意識する必要はない。

大切なことはまさに先の課題解決。必要なときに適切な価格で、いくらでも使えるクラウドプラットフォームを構築することだからだ。柿沼氏はこのシステム構成を実現するには「Cloud Abstraction Layer（抽象化レイヤー)」が必要だと強調。ただそ、このレイヤーやシステムを実現、実装するのは難しい段階だとも補足した。

「思想的にはMesosphere（メソソフィア）が最も近く、具体的な取り組みとしては、Apache Jcloudsが近い。ただどちらも現在はまだ現実的ではありません。KubernetesベースならAnthosやSpinnakerを使って実現する対策や、Terraform寄りのアプリやツール、フレームワークを選定することなどを考えています」（柿沼氏）

柿沼氏は改めて、思想の転換が重要であり、とりあえずデータを集めて後から抜き出すのではなく、必要なときに必要なデータのみを収集・処理するシステム基盤が重要だと説明。「JIT（ジャストインタイム） IoT基盤」と名づけた構想も紹介し、次のように述べて、セッションを締めた。

「コネクティッドカー基盤開発に対するアプローチも含め、これからの技術者に求められるものは、いまある技術をどう活用するかだけでなく、今後のパラダイムシフトについても考える必要があるでしょう。そうした目線や思考で仕事に取り組むことのできる方と、一緒に働きたいと考えています」（柿沼氏）

コネクテッドカーに対するデータ活用と最新技術の取り組み

ここからは樽石将人氏がモデレーターを務め、Q＆Aをからめながら登壇者たちとパネルディスカッションを行った。

●収集したデータの活用について

樽石：コネクティッドカーから収集されたデータは、メーカー間でも共有されているのでしょうか。

千葉：障害物検知などのデータは、1社よりも多くの自動車メーカーで共有した方がコネクティッドカーの価値が高まります。トヨタ自動車さんを中心に商用車のデータを集めるCJP（Commercial Japan Partnership）という取り組みを開始しています。

将来的にはCJPのように、データは統合されていくでしょう。その際に扱うデータは膨大な量になるので、こうした取り組みが間違いなく必要になると思います。

竹内：技術的にも面白いテーマだと考えています。データに関する認証認可や管理といった技術が関連してくるからです。

樽石：収集したデータは母数を更新したら捨てるのか、それとも更新するのでしょうか。

千葉：ユースケース次第と考えています。必要なデータを必要なときだけ集めることも、コストの観点からは大事なことです。一方で、幹線道路を通過する車両の中から特定車両を発見するようなシーンでは、常にデータを蓄積しておく必要があるからです。コストや使用用途のトレードオフの見定めが必要になってくると考えています。

竹内：データを捨てるかどうかの判断は自動車メーカー次第ですし、法律上消せないデータもあります。個人的には、処理に最適な形で残す方向に向かうと思っています。

樽石：データを全て溜めるのは確かにコストの観点から難しいとは思います。一方で最近は圧縮技術が進歩しているので、活用できるとも考えています。特に着目しているのは、数キロバイトの粗い動画データを4Kなどの高画質に復元する「超解像技術」ですね。

●エッジコンピューティングに対する見解は？

樽石：クラウドが足りないという話題がありましたが、車に搭載しているコンピュータを活用する、エッジコンピューティングについての見解はいかがでしょう。

柿沼：現状ではソフトウェアの重い処理をバッテリーで行うには制限があると聞いています。千葉が紹介したOTAなどもそうです。ただしこの先、走行しながら充電が可能になったり、チップの消費電力が小さくなるといった技術のブレークスルーが起きればエッジ処理も加速し、クラウドに頼ることのない未来が実現するかもしれません。

竹内：車は安心安全が大前提ですので、どこまでサードパーティと協業していくかは、難しいところ。一方で、モビリティの競合はスマホになるため、車側で動かすアプリ開発は狙うべきアプローチであると考えています。

●技術を選択する基準は？

樽石：セッションで紹介された各種技術は、どのような基準で選定しているのでしょうか。

柿沼：コネクティッドカーは新しい技術領域ですから、判断基準は難しいところです。個別に判断基準を議論しながら決めているのが実情です。そのため普段から最新のOSSの技術動向をチェックし、その中から興味がある課題を解決できそうな技術を選定して、顧客に提案するようにしています。

竹内：新しい技術ですので正解がなく、比較的失敗を許容してくれる環境です。開発者が興味を持った技術を検証してみて、実装まで持っていくといったケースが多いです。

また、車の開発はレガシーなイメージを持つ人が多いと思いますが、実際にはモデルチェンジの度に開発体制も刷新されるので、その際に新しい技術やシステムを導入しています。

樽石：システム開発の内製化が進んでいますが、SIerの価値についてどのように考えていますか。

竹内：内製化自体は良い動きだと思います。一方で、NTTデータの場合はSIとしてはもちろん、NTTグループとしてのアセットが豊富にあることが大きな強みでありメリットだと考えています。

柿沼：内製化できるシステムの規模は限られていると考えています。つまり、NTTデータのような大規模システム開発（ソフトウェア開発）に長けている企業は、今後も需要があるのではないでしょうか。

千葉：私も内製化そのものは、良いトレンドだと捉えています。一方でSIerの価値、特にNTTデータのような規模であれば、様々な業界の知見や経験がありますから、クロスインダストリーで新たなサービスや価値を創造することができると思います。

●コネクティッドカー開発をやろうと思った理由は？

樽石：コネクティッドカープロジェクトに携わろうと思った理由を聞かせください。

千葉：自動車領域の技術開発はグローバルでもスピーディに進んでおり、ベンチャーも積極的です。そのため常に新しい技術を学んでいく必要があります。自身の好奇心にもつながっているし、仕事の面白味でもあります。また、マーケットをリードする存在でありたいと考えています。

竹内：以前、HadoopのOSS開発に携わったとき、パラダイムシフトを感じました。コネクティッドカー領域でも、同様なルールチェンジに立ち会えると期待しています。

柿沼：世の中にない、誰も作ったことないシステムで、同分野の第一人者になれるのではないかという想いで携わってきました。しかし実際に携わるうちに、自動車事故などの社会課題に対峙し、考えることのできる機会となっているからです。

NTTデータ モビリティチーム
https://mis-mobility.nttdata.com/team_m5_1.html

NTTデータ モビリティチームの採用情報
https://mis-mobility.nttdata.com/careers.html