クルマとIT業界の“埋まらぬギャップ”をどう解消するか　共用プラットフォーム利用の課題に対するトヨタ社の取り組み

登壇者の自己紹介

竹岡航司氏：私は、トヨタ自動車の竹岡と申します。まずは、このような華やかな場所でお話しさせていただく機会をくださりました、Akamaiのみなさま、関係者のみなさまに感謝を申し上げたいと思います。ありがとうございます。

来場のみなさまには、「クルマとIT業界の埋まらぬGapと突破のカギ」というテーマで、今私たちが直面している、開発におけるコネクティッドカーの困りごとをご紹介したいと思います。

少しだけ自己紹介させていただきます。私は今、コネクティッド先行開発部で、5年から10年先のクルマに対して、どのようなコネクティビティを提供するのがいいのかというところを先行開発しています。

転職組で、3年前まではソフトバンクでIoTの事業を企画・開発していました。この2つの経験を活かして、IT業界から見えるクラウド、車業界から見えるクラウド、この違いについて今日はお話ししたいと思っています。

セキュリティ対策としてAkamaiのソリューションを活用

最初に、私の部署の担当ではないので伝聞になるのですが、トヨタでAkamaiのソリューションを使わせていただいているということをご紹介させていただきます。

セキュリティの分野で WAFを使っています。全世界から来る攻撃をしっかりと防御していただいていると聞いています。特に、（スライドを示して）この表の④番、Reputationのところで、全世界で何が起きているかというのがすぐに私たちのサイトに適用されるので、しっかりとしたセキュリティを提供していただいていると聞いています。

数字については公開できない部分があるので、表は切り取っているのですが、およそ150サイト、700TBほどのトラフィックに対してAkamaiのソリューションが適用されています。

私たちもいくつかサイトを持っているのですが、その中でも代表的な「toyota.jp」や「lexus.jp」というサイトに対して、トヨタのお客さまがセキュアに使える環境を提供していただいています。

そういった環境を考慮して、今後も新しいソリューションを入れていく予定です。「Client-Side Protection & Compliance（旧称 Page Integrity Manager）」という、Web ページに埋め込まれた悪意のあるコードなどを検知して、排除していくためのソリューションを採用する予定です。

ここまではちょっと伝聞チックになっていて、「YouTube」だと、もうこのあたりに「プロモーションを含みます」という文字が出る感じの話にはなりますが、今日この場に立つにあたり、少し勉強させていただきました。私の言葉で言うと……ちょっと（スライドが）戻るのですが、（スライドを示して）ここですね、④番のReputationのところ。全世界の攻撃が、全自動で学習されてポリシーが適用されるというのは納得できる仕組みだと思います。

ただ、IPアドレス単位のリスクを見ていると、今日は悪意のある人が使っているIPだったとしても、数日経てば、正常なユーザーが使っている可能性があります。そのあたりをどうやって解決しているのかと質問しましたら、弊社とAkamaiのみなさんで定期的にミーティングをして、そういったところの意識をしっかり合わせて訂正しているとのことでした。

（※Akamai注：Akamai Client Reputationは、共有型IPから行われた攻撃でいったん上がったリスクスコアを、正規のユーザーが同じIPを利用した際に影響が及ばないよう、攻撃の種類によって自動的にリスクスコアを下げる基本的な仕組みを備えています。そのスコア変化の精度を高めるために、上記のような個別のフィードバックも反映しています。）

そういう運用の状況を聞いて、技術だけでなく、そういった人間によるフォローが、信じられるソリューションになっている秘訣なんだなと思いました。

直面している課題は「低遅延以外のエッジの活用」と「カーボンニュートラル」

では、ここから、私がやっている業務をみなさまにお伝えしながら、直面している困りごとを共有できればなと思っています。

（スライド）これが、今弊社が提供しているコネクティッドカーのサービスの一覧です。だいたいここに書いてあるとおりですが、ここで言いたいのは、あまり遅延に厳しくないサービスが今は主であるということです。誤解を恐れずに言うと数秒ぐらい遅れても、特に問題はありません。物によっては、数日遅れても問題がないというサービスを提供しているのが、現在の状況です。

ちょっと弊社のサービスから離れて、セルラーネットワークの基本の技術背景について説明します。

4Gと呼ばれている、みなさまがスマホで使っているサービスは、日本でいうと、セルラーの出口がだいたい2ヶ所になっています。詳しい場所は機密なので言えませんが、東京と大阪に1ヶ所ずつぐらいの粒度になっています。

ということは、沖縄で走っているクルマが、隣のクルマに対してなにか通知をしたい時に、トラフィックは1度大阪に行って、大阪のサーバーで処理してもらってから、もう1度沖縄に戻ってくるというのが、今までのトラフィックのルートになっています。

今は遅延に厳しくないサービスしか提供していないので、これでなんの問題もないのですが、今後、自動運転を筆頭とした遅延に厳しい通信をする時に、この構成では厳しいんじゃないか？　というのは、前々から思っていたところです。

今、5Gの導入が進んでいますが、5Gのネットワークスライシングという技術をベースにして、ローカルブレイクアウトをする素地が整ってきています。

これができると、日本においては都道府県に1ヶ所ぐらいの粒度でセルラーからの出口ができて、そこにサーバーを立てに行けば、低遅延のサービスができるんじゃないかと考えていたところです。

その5Gへの進化をベースに私たちも準備を始めています。エッジコンピューティングということで、エッジサーバーそのもの、クラウドサーバーそのもの、そしてクルマの中の計算リソースを自分たちで持って、エンドツーエンドで高品質なサービスを提供したいと考えていました。

ここが、過去形なのがポイントです。その準備をしていた中で見えてきたのが、次のページですね。

5Gの導入で遅延は4Gより小さくなるのではと思っていたのが、もともと日本は物理的な位置が短いわけですから、4Gでも小さかったです。日本のようにしっかりとインフラが整った状況においては、東京、札幌の区間で往復遅延は10ミリセカンド程度です。

一方で、処理させたいアプリケーションを考慮すると、その処理の時間に100ミリセカンドぐらいはかかってしまうという背景があります。こうなってくると、トータルで低遅延を実現したい場合、地理的に近いサーバーで処理させるよりは、計算リソースの多いクラウドに送ったほうが速いんじゃないか、低遅延だけでエッジサーバーを使い倒すというのには無理があるんじゃないか、というのが見えてきました。

併せて、各地域に物理的なサーバーを自前で立てれば、限られた地域をカバーするそのサーバーを弊社だけではなく、ほかの事業者さまと一緒に共用しないとそれが丸ごとその地域のクルマのユーザーさまのコスト負担になってしまうので、共用できる相手を見つける必要があります。

しかも地域を限定するということは、例えば同じ都道府県の中で共用で使ってくださる事業者さまがどれだけいるのか？　という点も問題になってきます。

併せて、カーボンニュートラルの問題もあります。クルマは走っている間が一番CO2を出すので、そこがメインではあるのですが、アウトカー（クルマのコネクト領域）のところで、こういった計算リソースもカーボンニュートラルにしたいと最近私たちは考えています。

ということは、カーボンフリーな電力で動いているサーバーを使いたいと（いうことになります）。具体的には、天候のいい地域で夏の間、太陽光発電がしっかり動いているところと、曇りで火力発電で補っている場所、こういったところをうまく使い分けて、カーボンフリーにも取り組んでいきたいと思います。

都道府県レベルに大きなサーバーを置きに行くと、その地域が用意している電力以上のものを要求してしまう場合もありますし、その時に提供してもらった電力がカーボンフリーではなく化石燃料をガンガン焚いた電力だった場合、少しちぐはぐになるのかなと考えています。

ほかの産業のユーザーとサーバーの夜間リソースを共用するための連携を模索

さらにリソースを共用していくうえで参考にしてみたいのが、（スライドを示して）左のJPNAPの絵は、みなさんも見たことがあるかなと思います。日本の代表的なIX（インターネットエクスチェンジ）の1つで、日本におけるインターネットの使われ方の傾向です。

右側は、国土交通省が交差点でカチカチ計測しているのを見たことがあると思いますが、あの統計情報が出ているサイトから引っ張ってきたデータで、ある地方都市でのクルマの使われ方の傾向です。

こちら、パッと見は、「昼間が使われていて夜は使われていない」というのが、両方同じように見えるかと思いますが、よく見ると、クルマは通勤に使われていて、朝の8時ぐらいと夕方の6時ぐらいがピークになっています。このピークが、JPNAPと微妙にズレているんです。

インターネットは、夜中に使われます。なので、インターネットやセルラーは夜中のピークに合わせてインフラが用意されていて、そのピークからちょっとズレたところでクルマは使われていますので、ネットワークインフラの共有という点では収まりが良かったという背景があります。

この話を先ほどのエッジの話に適用すると、本当に各都道府県にサーバーを置いて、ネットワークのようにコンピューティングリソースのギャップを埋めるかたちで、効率的に利用することができるのか？　というのが問題になってきます。

このギャップを埋めるには、やはり車業界だけでがんばってもどうしようもないところがあるので、ほかの産業のユーザーと一緒に歩調を合わせていく必要があるのかなと思います。

先ほどプレゼンがありました、25年にわたるAkamaiさんの、各地域でのノウハウと、異業種ですでに使われているユーザーのビヘイビア解析や昼夜が逆の地球の裏側からのデータ転送による平準化などに期待をしています。

お客さまに「IoTシステム技術検定に合格してからまた来てください」とは言えない

併せて、「プラットフォームの幻影」ということで、プラットフォームを使い出す時に、私たちがどのように問題を見ているかをご紹介したいと思います。

いったん、私の前職であるソフトバンクでの経験をご説明します。IoTの商品を企画・開発していたのですが、IoTの商流というのは、（スライドを示して）だいたいこのようになっています。

下のレイヤーから、デバイス、通信、プラットフォーム、その集めたデータを見える化したり解析したりして、お客さまにサービスを提供するといったところになります。

お客さまは、だいたいはITの業界以外のお客さまなので、その事業に対してのプロフェッショナルではあるものの、ITのプロかというと、そこの知識は少し薄い感じです。

そのため、デバイス、通信、プラットフォーム、見える化、それぞれのベンダーと話をして、IoTのサービスを立ち上げるというのは、お客さまにとっては少しハードルが高く、「誰かワンストップで提供してくれないか？」と探しておられます。

右側のグラフでは、通信が下支えする位置に描いていますが、当時私は、ソフトバンクがプラットフォーマーの位置になれるようにがんばって営業していて、お客さまに対して「ワンストップですべて提供するのでIoTを始めてください」という活動をしていました。

この商流を基にして、2015年頃に総務省で立ち上がった「IoT推進コンソーシアム」で、日本のIoTのビジネスを加速させるには、お客さまの位置にいる人の知識が高まる必要があるという話になりました。

私は、ソフトバンク時代にMCPC（モバイルコンピューティング推進コンソーシアム）の委員も同時にやっていたのですが、それを受けて、MCPCが「資格試験を作ります、お客さまがIoTの知識を得られ、そしてその知識を得たことを証明する試験をやります」となりました。

ただ、この試験の受験者は想定より少なかったです。なぜかを後になって考えました。MCPCには最初に成功した資格試験があって、それは「モバイルシステム技術検定」というものです。

セルラーネットワークの基礎の試験ですね。先ほどお見せした、4G、5Gの中身とか、セルラーに関わらない方はなかなか見ない絵だと思いますが、ああいうものを勉強する入門の、取っ掛かりのいい試験ということで、モバイルシステム技術検定は成功しました。

その資格を持っていれば、いわゆる通信事業者に対して、「私たちは、モバイルシステム技術検定に出る程度の技術の知識を持っています」と訴求できるので、SIer、ベンダーも受験しますし、社員個人個人で見ると、転職をする時の箔付けになるので受験するという背景がありました。

一方、IoTは、お客さまに「勉強してください」と言わなければいけないんですね。

それはつまり、ようやくお客さまにIoTを使いたいと言ってもらえた時に、「お客さまの知識が足りないようです」「ついては、MCPCがやっているIoTシステム技術検定を受けて合格してからまた来てください。それまでは私たちは、あなたから発注はお受けできません」と言えってことなんですね。

そんなのが言えるならサラリーマンをやっていないですよね（笑）。これは、過ぎてみて思えばそうかなという感じなのですが、先ほどお話しした、総務省が立ち上げたIoT推進コンソーシアムでの結論が、「お客さまであるユーザー企業が、知識をつけるべき」ということで、人材育成のワーキングを担っていたMCPCが、「じゃあ、資格試験作りますわ」と言って作って、やってみて、やってみたらこういう感じだったというところです。

このあたりが難しいからIoTが進まなかったというのは、少し昔話チックでもありますし、私自身も、下のレイヤーから変えていくのは難しいんじゃないかなと思って、トヨタに転職しまして、（スライドを示して）今、赤い位置から全体を考えるということをしています。

共用プラットフォーム利用における、他産業とのライフサイクルの違いを実感

あらためてユーザーの立場でプラットフォームを使い始めてみると、通信事業者から見ていた時と景色が違うことに気づきました。通信事業者をはじめ、ICT業界のみなさんは、いかに早くサービスを始められるか、「数ヶ月で始められます」「スモールスタートできます」「初期費用は少ないです」というところを訴求されます。

私自身もそういう営業をしたのでそれは事実なのですが、トヨタの立場で言うと、今検討している新しいソリューションは、数年後に出てくるクルマに適用するものであり、今日使いたいとはあまり思っていない、というのがまずあります。

そして数年後に販売が始まったモデルは、長ければ10年ぐらい同じモデルを売ります。さらに、一度販売したクルマは、だいたい10年ぐらい、長いお客さまだと20年、30年と使っていただきます。

そうなってくると、私たちは「今日から数えて30年、40年後まで同じサービスを提供したいんだ」というモチベーションを持っているというわけです。「数ヶ月で立ち上がるから！費用が安いから！」というセールストークは事実ですが、そういう営業が来てもトヨタには響かない。

かつ、この技術の切り替わりが早いIT業界において、おそらく「同じ技術で5年間サービスを提供しています」というのは、他産業の企業さまにおいてはユーザーに言えないことなんだなと思います。それは実際、最近経験していて、同じプラットフォームを使っていた他産業のお客さまが抜けていくというのを見ています。

プラットフォーマーの事業がうまくいかないというだけなら笑い話なのですが、プラットフォームを止められたら困るので「止めないでください」と言っていると、私たちに対して、「じゃあ、他産業分が抜けた分のコストアップをお願いします」というような話が来るようになります。このあたりが苦しいなと思います。

エッジサーバの所有の仕方・共用パートナーの募集・データの振り分けなどの課題解決にAkamaiのノウハウが不可欠

私たちは、クルマを作って売るという製造販売業だけではなくて、コネクティッドサービスも一緒にして、サービスプロバイダーになっていきたいと思っています。

サービスプロバイダーは、エンドユーザーにサービスを届けるにあたって、その中間に入っていただく何社もの事業者さんに協力を得ないといけません。この中から1社でも抜けるとサービスが提供できなくなります。

ということは、40年間同じサービスを続けたいと思ったら、この間に入ってもらった事業者さんには、「同じ会社名、同じソリューションで40年間サービスを続けてください」ということをお願いしないといけないということになります。

難しいな、ちょっと無理を言っているなというのは、自覚があります。通信産業でやっていた私個人の経験からも、「40年間同じサービスを続けろ」というのは苦しいなと思います。

20年でも苦しいですね。「20年前のCPUは何だったかな？」と思うと、IntelのCPUでいうと「Core 2 Duo」がまだ出ていないぐらいだと思います。でもクルマでいうと、2代目『プリウス』とか、初代『アルファード』が出てきた頃で、今もまだ街中を走っているので、やはり、クルマは20年走る。

でも、そのクルマを「Core 2 DuoのCPUでサービス提供しています」と言ったらちょっと「んっ？」とは思うので、このあたりのギャップは埋めたいなと思います。

右側のグラフですが、オレンジ色のなだらかに右肩下がりになっているのは、プラットフォームの事業者さんが毎年かけているコストと見てください。

青い線が、弊社が払う使用料です。最初の数年は、適正な利益を乗せてお支払いするし、隣で使っているお客さまも同時に使っているので、ビジネスは順調に進んでいるように見えます。

しかし、この間あったパンデミックのような事業環境の変化が起こって、我々が支払いをいったんグッと下げてしまうと、その数年間キャッシュが回らなくなる会社も出かねないということですね。もし（そういう会社が）出てしまうと、左のレイヤーを支えていただいている1枚のベンダーが抜けていってしまい、私たちがサービスを提供できないということになります。

このあたりに気づいたので、私たちが出していく台数にかかわらず、なるべく適正な利益を乗せた上で、各ベンダーにはお金を払っていくと。（スライドの）右側のようなグラフでお支払いするという覚悟は決めつつありますが、この覚悟を弊社だけで決めても、隣の産業のユーザーが抜けていったところまではカバーしきれない。

こういった観点からは、他社と共有して使うプラットフォーム、共有して使うエッジサーバー、コンピューティングリソースというのは、もしかしたら我々にとって適正ではないんではないか、とも考え始めています。

そんな考察をする中で、エッジコンピューティングのリソースの配分の仕方、同じサービスを20年以上維持する方法、Akamaiさんにはこのあたりのノウハウにすごく期待しています。