***************************************************************************
基調講演
テーマ：自動運転の民主化
講師：加藤 真平 氏（東京大学 大学院情報理工学系研究科・株式会社TIER IV・
Autoware Foundation）
日時：2022/9/1 13:20～15:05
参加人数：71名（終了時・オンライン） ※現地参加者数は不明
***************************************************************************
■目的
・Autowareのビジネス・課題・狙いを紹介（TIER IVの立場から）
■「自動運転の民主化」の前に、そもそも自動運転って何だ？
●加藤氏の答え
・多くのコンピュータが多くのセンサとつながっている（車載・モバイル…）
・そのシステム上で多くのリアルタイムプロセスが動いている
・難しいのは、その上に有象無象のタスクが乗ってくること
（ロボット・AI・クラウド・メタバース…）
・それ故に、作ったシステムの妥当性の確認・検証が困難を極めている
■自動運転（Autoware）の現状
●運転席に人を乗せない場合
○都会ではないが走れる（例：長野県塩尻市）
・運行設計領域（どの地域なら自動運転ができるか）は幅広いのでは？
○なぜ都会ではできないか？
・自動運転車は運行センタとつながる必要あり
・画質・フレームレートが定められているため、5G相当の回線が必須
・スマートフォンを使っている人が周りにいない地域でも画像処理ミスが発生
・東京などスマートフォンを使う人が多い地域では、回線上の問題でまだ不可能
・トラブル発生時の対処
・想定内の運行であれば、都会でも無人運行が技術上可能かもしれない
・ただし、同乗者が体調不良になったり、車の部品が故障したりするリスクが存在
・トラブル発生時は、サポートセンタの方が遠隔で支援（呼びかけ・レッカー…）するの
だが、これらを東京で実施するのは困難
・技術面の課題：V2X
・見通しの悪い場所では車の代わりに、電柱などのインフラにもセンサ
（LiDAR・カメラ・レーザスキャナ…）を搭載
・都心部になると難しい交差点が増えるため、自動運転単体だけでなく周囲の技術が必要
●運転席に人を乗せる場合 → 何かあったらハンドルを握る
○交通量が多い場所でも運行可能（例：西新宿）
●技術面の話
○レーン（指定された走行ライン）が制約になりがち
・車は自分の場所を認識した後、基本的にはレーンに沿って走行
・レーンによって問題の難易度が変化
・交差点の場合、車は状況を認識することはできても、曲がって良いかどうかを判断する
ことが難しい
→ ここまではだれが作っても同じ（差別化しづらい）と考えているため、OSSにしている
■Autowareの機能
●認識処理：センサ処理・ディープラーニング・物体検出 → CPU使用率の半分程度
○何らかの方法（レーザ・レーダ…）でスキャン
○内蔵された3D地図データに基づいてレーンを判定
・（宗教論になるが）地図データを使えば標識認識は不要
○検出された物体の動作を予測（ディープラーニング・確率ロボティクス…）
●プランニング（経路計画）
○経験則による交通規則・深層学習など
○決定したプランは、ステアリング・アクセル・ブレーキ等のアクチュエータに反映
●アクチュエータへの伝達 → 最も苦戦する箇所
○乗り心地・重さの変動への対応
・タクシーは4人乗りだが、バスは20人程度乗るためトルクの出し方が変化
→（処理の構成図を見せながら）自動運転ソフトは大まかにこのような処理を行うため、
結局誰が作っても同じ
・これは前提条件であり、これを一から作っているようでは勝ち目無し
■技術的優位性を獲得するには？
●開発・運用のコストをどれだけ下げられるか？
・大きな市場では、自分とは異なる新しいアプローチが出たとき、それがデファクト
スタンダードになる可能性あり
○現在のトレンドは「クラウドネイティブ」
（自動運転システムと全く同じもの（ハードウェア含む）をクラウドへ）
・検証の二度手間を防止するため
・クラウドで行ったシミュレーションを車に展開したとき、車側のCPUが変更されると
妥当性を喪失
・クラウドで検証したことの妥当性を残すため、車とクラウドで同じアーキテクチャを
使用したい
・「クラウドネイティブ」が実現できる人は数少ないため、この流れに乗ることが差別化
ポイントになり得る
・自動車・組込業界では、コンピュータサイエンス周辺の技術でミスマッチが発生
●（宗教論だが）地図データを使うか使わないか？
○メンテナンスの課題
・環境が複雑になるほど高次の情報を載せる必要あり
・いかに新鮮な情報を提供できるかが、もう1つの差別化ポイント
●自動運転に必要なものの総合的な保持
○Autowareの例
・自動運転ソフトウェア
・地図データ
・DevOpsプラットフォーム
・走行場所ごとの不具合の分析
・遠隔での監視サービス
・不具合の自己診断
・デジタルツイン（クラウド上に仮想空間を作成・Unity）
●検証面の課題
○シナリオベース検証を様々な車両に適用
・自動運転車両の迅速な開発
・例えば、ロボットタクシーに適用したシステムを、自動運転バスに3日程度で適用できると
良い（現在は数年必要）
●他力本願にならざるを得ない要素
○通信の帯域幅
・ローカル5G（帯域と遅延の保証）
・人工衛星の数 → 6G・7Gになったときどうなるか？
●サービス面の課題
○現時点で収益を得ている事業
・工場の敷地内での搬送（24時間365日・無人）
・人を乗せるのはまだ厳しい
・以前は人がしていたことを、ロボットが24時間代行
→ 「人間にできないことができる」のは大きい
・ヤマハ発動機（合同ベンチャー）のハードウェアを使用
・こうしたプロセスを経て「過疎地域でのタクシー運用」などができるようになっていく
のでは？
→ TIER IVの見解であり、海外企業では順番が違うケースも
■自動運転技術のプロセス論
●技術をどのように保証するか？ ← ステークホルダからの要求
○第三者委員会でデファクト（標準）を作成：これが検証範囲
・シナリオを作成・表現・変換する方法
・運行設計領域
→ このようなプロセスにアーキテクチャが紐づいていく ← 新技術なのに古典的
●VRと自動運転の親和性
○センサでの検出物を別の形で表現
・歩行者を歩行者と表現する必要はなし
・メタバースではない
・（顧客に違う形でのUXを提供できるため）自動運転に対するVRの付加価値は高い？
○シミュレーションによるテスト：自動運転AIチャレンジ
・学生・ハッカー向け
・ハッカーはプログラミングスキルは高いが、（プロセスに即していないため）
検証スキルは低い
→ シミュレーション上の車でテストし、競い合うと盛り上がる
・仮想空間でレースに参加するのも付加価値になり得る
■自動運転の民主化に向けて
●プロダクトライフサイクル：要求 → 開発・テスト → 検証 → 展開 → 運用・保守
・従来の製品と大きくは変わらない（「クラウドネイティブ」等新しい技術を除く）
・研究→スタートアップをするときはいかにこれを早く回せるかが重要
（人・ツール・環境・資金…）
●人が介入しないテスト
○TIER IVのような少ない人員（300～400人）でテストを行うには？
・「クラウドネイティブ」の活用
・基本的な開発・単体テストはローカル
・git等でコミットしたときにテストを「自動で」実行することが大事
（これはクラウド・SaaSでないと成立しない）
・クラウド・インフラ業者と提携
・テストシナリオの削減
・膨大なシナリオが存在するため
・機械学習等を用いて、シナリオの発生頻度・発生時の危険度に関する確率分布を作成
・危険度の高いシナリオを集中的にテスト
・頻繁にテストに失敗するシナリオに関連する箇所を改善
・テスト順の変更
→ この分野は研究の余地があるのでは？
■実生活での課題（研究者・学生向け）
●ドメインスペシフィック
○ある機能（例：自動運転）専用のシステムづくり
・自動運転車・ロボットの台数はPCの台数より多い
・（PC向けを考えずに）あるシステムに特化したものを作った方が、価格・性能・電力の
面で優位
・クラウドとエッジをつなげることをあまり汎用的に考えない
・マイクロサービスアーキテクチャ
・コンポーネント間で、デプロイ（展開）できる単位を細かく分割
・自動運転に範囲を限定して抽象化
○「クラウドネイティブ」
・クラウドの研究
・クラウド-エッジ間をどの単位で合わせるか？
（ネイティブ・仮想マシンレベル・コンテナレベル…混合もあり？）
・遅延・利便性のトレードオフに関する評価
○スケジューリング・メモリマネジメント（OSの話）
・自動運転システムのプロセスには依存関係が存在
・古典的なアルゴリズム（例：優先度スケジューリング）が使えない
・前後のプロセスが分かっていればページフォールトも予測可能
・マルチコア・GPU・アクセラレータによる資源管理
○System on the chip（SoC）
・自動運転専用CPU
・（ある機能を実現するとき）CPUの遅さが問題を引き起こす可能性があるから
・自動運転以外にも使える、AIチップ・AIアクセラレータ・量子アクセラレータでは
汎用的過ぎて勝てない
・物体検出に特化したCNNなどを丸ごとアクセラレータ化
・今後10年で盛んになるテーマ？
・会社だけではできないため大学と提携（例：テープアウト作業）
・AutowareはOSSである分、ローパワー・ハイパフォーマンスで開発可能
・差別化ポイントに集中することでモチベーション向上
■スタートアップと大学が提携するメリット
●スタートアップ（産業界）と学術界とのギャップの埋め合わせ
○スタートアップは最先端ではない
・コンピュータの仕組みを熟知している人が少ない
（コンピュータサイエンス専攻の人とそうでない人で、「リアルタイム処理」の解釈が
違う）
・会社の勉強会では限界があるため、大学と提携することは重要
・大学では常に先端技術に触れられる
・ディープな話題（例：Linuxのコード）についていける
・TIER IVで学振のようなことをしている ← 自動運転・OSS分野
■自己紹介
●経歴とビジョン
○加藤氏について
・2015 TIER IV 設立
・2016 東京大学教職員
・2018 NPO法人 Autoware Foundation 設立
・座右の銘「協創と利益相反は表裏一体」：東大 - TIER IV - Autoware Foundation間
・NPOを持っておくことは重要
・スタートアップと研究を両立するための方策
・スタートアップの目的は先行開発・コミュニティづくり
（大手ができないことはするが…）
・大学では基礎研究を行いたい
○TIER IVについて
・ミッションは「創造と破壊」
・Co-create（協創）をOSSでdisruptively（破壊的）に行いたい
・ビジョン（ミッションにたどり着く方法）は「自動運転の民主化」
・求める人は「プロフェッショナル = 議論をする人たち」
■TIER IVのビジネス
●狙い
○OSS業界をリードする
・（ソフトウェアを自社開発する）大規模な競合が多く存在するから
・強みは、自分たちが作れないものを周りの人が作ってくれること
●OSSをどうやってビジネスにする？
○（自動運転の山の）9合目まで到達できるプロダクトづくり
・OSSは5合目まで行く手段
・1社だけでは10合目に到達することは不可能 → 共同開発
・9～10合目までは良くわからない（スクランブル状態）
・最善の方法を取る
・最も時間がかかる
○リファレンスデザインとプラットフォーム
・リファレンスデザイン = OSSのコンポーネントとセンサ等の組み合わせ方
（例：ロボットタクシーのレシピ）
・コピー・改変が可能
・プラットフォーム = モノづくりの土台（例：OS・DevOps）
・プラットフォーム・リファレンスデザインを顧客に提案 → プロダクトの迅速な開発
○事業の位置づけ
・TIER IVが最終プロダクトを作るわけではない
・テスラのような製品の9合目を、「EVを作りたい」と望む多くの人が作れるようになる
ことを提案
・具体例：9～10合目の世界
・ありあわせの物から、短期間だけ動く製品（Turnkey）を作る場合（例：自治体）
・自動車メーカではできないためTIER IVで請け負う
・より長期的かつ融通の利いた製品の場合
・自動車メーカから車両を入手し（車両を）カスタマイズ
・ソフトウェアは顧客のものを使う場合
・ツールのみ提供
・自動運転を丸ごと提供する場合（例：自動車メーカ・サービス会社）
・希望の車両に合わせ設計・実装・テスト
■Autoware Foundationについて
・皆さんと一緒にできると良いと思うのは、OSSの開発（SWESTは最適？）
・学会から見てもバリューがある？
・Autoware Foundation（NPO兼一般社団法人）の協賛も歓迎
・Software-Definedの世界を実現するための技術者を増やしたい
■質疑応答
Q.＜司会＞
リファレンスデザインは全てOSSか？一部お金を取るものも存在するのか？
A.＜加藤氏＞
ほとんどOSS。ただしクラウド上にあるものは、現状は非公開。
自分の仮説としては全てをオープンにしても良いのではと考えているが、会社には様々な
バックグラウンドの方がいるため（特に株主の方から）驚かれる。
このロジックをエンジニア以外の方に説明するのは難しい。
現状はAutowareとそれに付随するシミュレータ（周りのコンポーネント）のみがOSSで、
クラウド上にあるパイプライン等はオープンではない。
しかし、自分はOSSにしていきたい。
Q.＜北九州市立大学 山崎進 氏（slackより引用）＞
「誰が作っても同じになる」からOSSにする，この部分まではできていないと話にならない，
ということをおっしゃっていました．仮にフレームワークとしてはそうだとして，
その各要素については，より優れた技術に差し替える可能性があるということでしょうか．
あるいは，フレームワーク全体も技術の進歩とともに見直す可能性があるということ
でしょうか？
なぜこのような質問をするかというと，プログラミングパラダイムなど様々な理由で，
フレームワーク全体の構成の仕方が大きく変わることが歴史的に時々あったからです．
A.＜加藤氏＞
その通り。良いものに差し替えて行く（可能性がある）。
例えば先ほど言い忘れたが、OSSであるかどうかは顧客にとってはどうでも良い。
自分はAndroidを使っているが、それがOSSであるかどうかを気にしたことはない。
自分が気にするのは機能やスペックや品質。
TIER IVでも、(顧客にとって)「良いものが安く手に入る」なら、それがOSSである必要はなく、
良いものがあれば（OSSでないものに）差し替えていきたい。
プログラミングフレームワークの話でも、Pythonはここ10年ほどで出てきたものであるし、
システムの方面でもRust等が出てきたため、書き換えた方が良いのでは？となる。
ディープラーニング等でもフレームワークがどんどん変わるため、積極的に置き換えて
いきたい。
（OSSは）長い目で見れば誰が作っても同じだが、当然（その時々の局面に応じて）良いものが
あった方が良いため、例えばSWESTでやっているようなもの、特にFPGAなどをやりたいと
思っている。
Q.＜オムロン株式会社 祐源英俊 氏（slackより引用）＞
「誰が作っても同じになるので、OSSにしてしまった方がいい」と仰っていたところについて、
基本的なところで恐縮ですが質問をさせてください。
技術を秘密にしておく必要がない、ということだと理解したのですが、それはそれとしてOSSと
して公開をするのはどういったことが狙いなのでしょうか？
OSSとして公開することも手間がかかることだと思っているため、あえてその選択をすることが
気になったというのが質問の意図です。
↑後半のご説明の中で、コミュニティとしてはより多くの人が自動運転の開発に貢献できる
ようにしてコミュニティを活性化させるため、企業としてはオープンソースコミュニティの
力を借りることによりより良いものを作り出すため、と理解したのですが、正しい
でしょうか？
A.＜加藤氏＞
はい、まさに（その通り）。
ただし、「1番を狙うか2番を狙うか」という問題がまず存在すると思っており、2番を狙うので
あればOSSである必要はないと個人的には考えている。
現実的に考えて、スタートアップのような 300～400人の会社ならば2番のものが作れるが、
大きな自動車メーカ（テスラ・GAFA…）に対抗するとなると、手間はかかるがOSSにした方が
良い。
例えばARMの場合、OSS（を導入した）方が製品が広まりやすいため、提携の申し出があったり
する。同じ理由でAWSも。
OSSにすることによって、小さなスタートアップでも、これらの大きなメーカと提携しやすく
なる。
最近ではホンハイからも「EVを作ろう」という申し出があるが、これもOSSだからこそ成立
している。
OSSには、「（ソースコードレベルで）自分たちでできないことをできる」という技術としての
側面と、「ビッグプレイヤと提携できる」というビジネスとしての側面が存在すると思う。
Q.＜株式会社アイシン 間瀬順一 氏＞
素朴な疑問だが、マネタイズ・品質保証はどうするのか？
マネタイズについては講演で言及があった。
しかし、品質保証については、我々の業界では、（乗っている人が）ケガをしたり
亡くなったりというケースがあり、非常に難しい部分である。
こうした部分は9合目より上に置いているのか？
あるいは、（9合目より下なら）トレーサビリティなど、ある種の品質保証の責任を強く考える
ところ自体で考えると、少し難しいやり方のようにも捉えられる。
OSSと説明責任の両立について、TIER IVの方で何かアイデアがあるのか？
A.＜加藤氏＞
正解は1つではないが、我々が「これならばおそらく受け入れてもらえている」と思うものは
存在し、認可を取ろうとしている。
OSSの世界では、品質保証の前に、OSSそのものにも品質管理のためのプロセスを入れなければ
いけないと思っている。
ただし、OSSの開発者が認証を取りに行くわけではないため、各種ドキュメント（github履歴・
wikiのコーディングルール・ツール・解析方法…）について認証されているわけではない。
我々はプロセスを透明化することだけがOSSの世界と考えている。
TIER IVは、5～10合目まで行くときに、例えば認証されていないシミュレータ（ソフトウェア
本体は努力していても）を使用すると問題になってしまうため、自分たちで品質保証する
ツールを作成する。
OSSでプロセスが透明化されているため、このツールは使ってよいが、このツールは
差し替える…といったようなことをTIER IVは行っている。
とはいえ全ては満たせないため、ほとんどが9～10合目の段階で行われており、認可を出す団体
や顧客とも段階的に調整を行っている。
例えば、（顧客が）品質保証のできるツールを持っていないため、TIER IVのツールを使用する
ケースもある。
最も重要なのは「透明化すること」で、次に重要なのが「分かっていることについては
求められている品質保証をする」ということ。
分かっていないものについては品質保証のしようがないため、9～10合目の世界に入る。
また、この場合保険も考えており、保証されていない部分で不具合があったときに賠償する
能力（リスクの頻度・大きさによって額が変動）によって（品質保証問題を）乗り越えて
いこうとしている。
今後様々なことが分かるようになれば、保険の費用も抑えれていくのではないかという状態。
Q.＜間瀬氏＞
おそらく一言では言いにくいところで、自分たちも困っている。
自分の立場から思ったことだが、国内の伝統的な品質保証を行っていると、（海外企業に）
スピード面で負けてしまうと思っている。
例えばテスラや中国の新興メーカを見ていると負けてしまうかもしれないので、そのあたりを
埋められないものか？
A.＜加藤氏＞
我々の方でも意見が分かれている。
今仰られているのが（スライドの）ビジネススキームの辺りだと思うのだが、エンドユーザに
対して従来のメーカが製品を提供しようとすると、品質保証のレベルは下げられないと思う。
本質論ではないが、今はこれの逆の世界が良いと思っている。
高い品質保証を求めないといけない企業はTier1やTier2の位置におり、（TIER IVとしては）
「（品質保証がされていなかったとしても、何かあったときは）保険も含め全て補償をする」
という前提付きで顧客に売り出す。
例えば自治体でも、TIER IVが補償してくれるなら委託する（という流れになってきている）。
自動運転の世界では（補償問題は）TIER IVが決めて良い問題なのだが、従来メーカの場合、
こういった問題を解決するのはまだ先。
テスラはISO26262などの規格を全く取っていないが、プロセスを回しておりテストもしている
ため安全である。こういったことが自動運転の世界ではあるのかと思う。
テスラはDevOpsも回っており、不具合があれば直せばよいのでは？という考え方だと思うので、
それは真似しても良いのではないかと思う。
Q.＜株式会社シティネット 大崎充博 氏（slackより引用）＞
既存の自動車会社からの引き合い又は、新規参入のどちらを想定されているのでしょうか？
・自動車会社は独自で進めたいのでは。囲い込みたくならないでしょうか。
A.＜加藤氏＞
TIER IVの場合、同じ技術でも提供の仕方が違う。
例えば、DevOpsを提供したり、シナリオケース（自分たちが持っているもの・国交省などの基準
を満たすもの・他のメンバが集めたもの）を提供したりするようなやり方だと、既存のOEMでも
新しいEVメーカでもあまり変わらないのではと思っている。
しかし自動運転の世界では、（既存のOEMに売り込むとなると）OEMがすでにプロセスを持って
いるために、たとえTIER IVの技術が良くても、そのプロセスに合わなければ採用されない。
そういう意味では、テスラ等の新興メーカはプロセスが非常に柔軟なので（バグったら直せば
よい）、TIER IVとはとても相性が良い。
これはEVを作ろうとすると自然とそうなってくる。
EVは部品数が圧倒的に少なく、かつソフトウェアの比重が大きいため。
既存のサプライチェーンにこういった技術を投入しようとすると難しく、（OEMとは）ツールや
シナリオの面で協力するほうが多い。
Q.＜東京大学 高瀬英希 氏＞
今はShinpei Katoのアカウントではコミットやプッシュをしていない。
それは幸せなことだと思っている。
普通OSSにはクリエイタ等がいて、その人がマージするか・リリースするかなどを判断すると
いう仕組みが成立するはずなのに、Autowareは今はそうではない（Shinpei Katoは関わって
いない）。この体制でできると判断したのはいつか？
また、そうなるために何かやったことがあれば教えてほしい。
A.＜加藤氏＞
時代が違うから（開発者が変わった？）だと思う。
コミュニティや開発の進捗は「貢献度」で表せると考えているが、50%以上はまだ自分に依存
している。
Linux Foundationもそうだと思うが、理事長やチェアマンがすべて投票制（民主制）なので、
自分がコードを書くか書かないかというのは、メンバからはあまり関心がないと思う。
コミュニティの運営方法が民主化されていて、価値に対する貢献をメンバが投票する仕組みが
あり、メンバが理事長等に自由に意見を言えるようにしているかどうかが最も重要。
Q.＜高瀬氏＞
いちデベロッパからコミュニティへ、自分のプロダクトを預けられると感じた瞬間は？
OSSの開発者には、自分のプロダクトに対する愛着があると思うが…
A.＜加藤氏＞
あまりない。それは目指す目標の違いからくるものであり、自分のミッションが
「ソフトウェアを作る」ことではなく、「テスラやGAFAに勝つ」ということだったから。
Autowareはそれを実現する手段であり、そこは割り切るというよりも、もともとそのように
考えていた。
ソースコードを書くことが全てではないし、研究に関するいろいろなテクニック（プレゼン・
論文執筆・資金調達…）も存在する。
イメージでいうと、いち研究者が研究だけしていたものが、段々いろいろなことをしなければ
いけなくなってくる。そしてそれらに価値を置くようになる。
自分も以前はソースコードを書いていたが、ある瞬間から、自分よりプログラミング能力が
高い人はあまりいないと感じ、その時に別のことをしようと思った。後腐れはない。
■講演のまとめ
●自動運転（Autoware）の現状
○運転席に人を乗せないとなると様々な障壁が生じる
○運転席に人がいれば大幅にハードルが下がる
●Autowareの機能
○誰が作っても同じ（だからこそOSS）
○ビジネスにするには技術的優位性を持たせる必要がある
●TIER IVのビジネス
○「OSSを用いて、誰もが自動運転車を作れるように提案する」のが狙い
（自動運転の「9合目」）
○大学と提携して先端技術に触れる
以上