ニュース
トヨタ自動車傘下のウーブン・アルファ、GitHubを活用したソフトウェア開発事例を紹介
GitHubのセキュリティ機能群などを効果的に活用
2021年2月4日 11:38
ギットハブ・ジャパン合同会社（以下、GitHub Japan）は1月28日、オンラインイベント「Best of GitHub Universe Live」を開催した。2020年12月にオンラインで開催されたGitHubの年次イベント「GitHub Universe 2020」のハイライトを、GitHub Japan社員の解説により紹介した。
このイベントの中で、GitHub Universe 2020でもセッションを持ったウーブン・アルファ株式会社（旧社名：TRI-AD）が登場。同社による車両ソフトウェア開発プラットフォーム「Arene」におけるCI/CDワークフローシステムと、そこでのGitHub Advanced Securityのコードスキャニングの利用を紹介した。
車両ソフトウェア開発プラットフォームArene
ウーブン・アルファの元になったTRI-AD（トヨタ・リサーチ・インスティテュート・アドバンスト・デベロップメント株式会社）は、自動運転技術の実用化に向けたソフトウェアを提供するため、トヨタ自動車、デンソー、アイシン精機の共同出資により2018年に設立された。
2021年1月より、TRI-ADは持ち株会社の「ウーブン・プラネット・ホールディングス」と、「ウーブン・コア」「ウーブン・アルファ」の3社に分社化した。ウーブン・コアは自動運転技術の開発を担当。ウーブン・アルファは、トヨタのコネクテッドシティ「Woven City」や、高精度3D地図、車両ソフトウェア開発プラットフォームなどを受け持つ。
ウーブン・アルファのDaniel Hebberd氏（シニア・インフラストラクチャー・エンジニア）は、同社の目標を「シリコンバレーの開発と日本の品質重視を融合して、世界で最も安全な車を作る」ことだと説明した。
Areneは、ウーブン・アルファが開発しているオープンな車両ソフトウェア開発プラットフォームだ。Hebberd氏は「車両プログラミングを開かれたものにすることが目標」として、車両ソフトウェア開発を簡素化し、安全性とセキュリティを維持しながらデプロイサイクルを短縮すると説明。「それにより車両アプリ開発者向けの新しい市場が生まれる」と語った。
Areneは、最新のツールやSDK、安全性のためのビルディングブロックを備えている。Hebberd氏は「速やかに開発を繰り返せるのでコンセプトからデプロイまでの期間を短縮できる」と説明。さらに、ハードウェア抽象化レイヤー（HAL）により「同じコードをどんな乗り物でも動かせるようになる」と語った。
自動車特有の規格をCodeQL化しコードを自動検査
Hebberd氏は、現在の車両ソフトウェア開発の課題として、長期に及ぶ計画と開発サイクルに悩まされ限定的にしかコードをデプロイしてテストできない「開発のアジリティが低いこと」、車両開発にはさまざまな独自ツールを使う必要があり「連係しておらず使い慣れたものでもないツール」、それも含めて「車両以外のソフトウェアから車両ソフトウェア開発に移行するのは大変なこと」を挙げた。
そして、必要になることとして、開発に使うツールやサービスの「拡張性（Scalability）」、要件から成果物に至るまですべての「追跡可能性（Traceability）」、成果物が改変不可である「不変性（Immutability）」を挙げた。
Areneでは、これらの問題をGitHub Advanced Securityで解決しているとHebberd氏は主張した。GitHub Advanced Securityは、GitHub Enterpriseのセキュリティ機能群だ。その中のコードスキャンは、GitHubに置かれているソースコードを静的解析してセキュリティ脆弱性などを発見する機能で、用意されたルールのほか、CodeQLというクエリー言語で独自のルールを記述することもできる。
1つめは、ツールを“使い慣れたGitHub”のインターフェイスに統合できること。例えば、コードスキャンの結果への対応をSARIF形式で指定できることや、LGTM EnterpriseでGitHub環境のほかGitLab環境もスキャンできることがあるという。
2つめは、IDEとの統合。Visual Studio Code（VScode）でCodeQL拡張機能を使うことにより、GitHubによる静的分析スキャンを開発者のIDEから実行できる。
3つめはカスタムルールで、「これは当社にとってとても重要」とHebberd氏。CodeQLを使ってコードスキャンのカスタムルールを作成することで、安全性やセキュリティに関する自動車特有の要件や規格をスキャンできる。
自動車のソフトウェアについては、自動車の機能安全に関するISO 26262や、自動車のサイバーセキュリティに関するISO 21434といった規格がある。そして、これらの規格を順守するためのコーディングのルールセットに、AUTOSAR C++ 14や、SEI CERT C++ 134がある。
ウーブン・アルファでは、GitHubと協力して、このルールセットからCodeQLのルールを作成して、コードスキャンをかけているという。さらに、このルールをオープンソース化して、コミュニティでの利用拡大とプラットフォームの迅速な導入を図っているとのこと。
なお、ルールを公開する意図については、ウーブン・アルファの坂口翔太氏（シニア・エンジニア）が質疑応答において説明。「ツールはオープンソースにしないが、ルールをオープンソース化する。それにより、モビリティ業界を盛り上げ、開発者を増やして高品質を保ち、業界に貢献する」と述べた。
Tektonでワークフローを構築
続いて、コードスキャンを含む同社のCI/DDなどのワークフローについて、ウーブン・アルファ株式会社のGwenn Etourneau氏（シニア・エンジニア）が解説した。
Etourneau氏はまず、通常のソフトウェア開発からデプロイのワークフローと、車両ソフトウェアのワークフローとを比較した。通常のソフトウェアでは、コードを基に、単体テスト、結合テスト、デプロイ、機能テストと直列で進む。ここで、長い中断（待ち）が発生しない同期処理であること、たいていは承認プロセスがなくあっても数分～数時間の中断で済むこと、特別なプラットフォームは必要ないことをEtourneau氏は取り上げた。
それに対して車両ソフトウェアは複雑だ。ワークフローの中に、多数のCPUやGPUを使うソフトウェアシミュレーションや、特定のハードウェア（センサーなど）を使うハードウェアシミュレーションなどが入ってくる。シミュレーションは数時間から1日かかることもあるため、ワークフローを一時停止する非同期な手段が必要になる。
さらに、セキュリティの承認、法的な承認、安全性の承認、規制に関する承認などの複数の承認ステップが入る。このプロセスでは、認証（certificate）のため外部企業と組むこともあり、また日本ではソフトの追加に政府の許可が必要になる。そのため、ここでも非同期な対応が必要になる。
ウーブン・アルファでのワークフローシステム構築で重視したこととして、Etourneau氏は、追跡可能性と不変性を挙げた。すべてを追跡できる必要があり、ログは何年間かまたは無期限で保管しなくてはならず、車にデプロイしたコードのコミットを追跡できる必要があるという。また、ログ、バイナリー、カバレッジ結果、テスト結果などを含む成果物はすべて不変でなくてはならないという。
こうした要件から、ワークフローシステムにTekton（TektonCD）を採用した。TektonはKubernetes上で動き、クラウド上またはオンプレミスで利用できる。Etourneau氏はTekonの特徴として、柔軟性を挙げた。「ワークフローを完全にカスタマイズしてプロセスを強化できる。パイプラインエンジンでありワークフローエンジンでもあるということで、Tektonはそれらのフレームワークといえる」（Etourneau氏）。
TektonはKubernetesの拡張機能のようなものであるCRD（カスタムリソース定義）として動作し、ほかのCRDをネイティブに呼び出すことで必要に応じてワークフローを拡張することもできる。これにより、承認プロセスやシミュレーションなどをワークフローに組み込める。そのほか、KubernetesによってコンピューティングノードやGPU、自動スケーリングなどにも対応している。
このTektonによるワークフローの中に、GitHubのコードスキャンを組み込むことで、規格やルールのチェックを自動化可能だ。セキュリティチームは、自動車業界の規格などを元に独自のルールを作成して適用する。開発者も自分独自のルールを組み込めるほか、GitHubが提供するデフォルトのルールも利用できる。
Etourneau氏は、開発者がCI/CDワークフローシステムにコードをプッシュするとどうなるかについて概要を説明した。
GitHubには、アプリケーションコードのリポジトリに加えて、ルールのリポジトリも設けられている。開発者がコードをリポジトリにプッシュすると、よくあるように、チェックアウト、単体テスト、ビルドのプロセスが実行される。
この中のビルドのプロセスで、コードのチェックが実行される。ルールリポジトリからルールをチェックアウトし、SARIF形式でコードスキャンを初期化し、CodeQLでコードをチェックする。
問題があると、GitHubのissueに自動的に登録される。このときに「Warning」など問題のレベルが付加される。このレベルは開発者だけでなくCI/CDパイプラインでも利用し、例えば高レベルの問題があればデプロイしないといったことができるという。
最後にEtourneau氏は、こうしたワークフローの整備の意義について、「重要なのは開発者の体験を高めること。われわれは開発者にコーディングに専念してもらいたい。Webアプリケーションの開発と同じように自動車アプリケーションを開発してもらいたい。開発者が煩雑なことをしなくてすむようにしたい」と説明し、「これにより開発者のCode to Car体験が向上するだろう」と語った。
