自動車メーカーやロボティクス企業が直面する共通の課題として、実験室の安定した電源と空調の下で動く「温室育ち」のデモ機と、過酷な温度変化や振動の中で数万時間稼働しなければならない量産機（ECU）とでは、求められる要件が根本的に異なるという点があります。
徳島で中学生からプログラミングに没頭し、35年以上の開発キャリアを積む中で、常に「まず動くものを作る」プロトタイプ思考の重要性を実感してきました。しかし、プロトタイプで動いたからといって、そのまま量産できるわけではありません。
特に、AIチップのカタログスペックに記載されている「TOPS（Trillions of Operations Per Second）」という数字だけを見てハードウェアを選定してしまうと、後で大規模な設計変更を迫られ、ビジネスへの最短距離を見失う可能性があります。
本記事では、経営者視点とエンジニア視点を融合させ、「環境制約から逆算する」車載AIコンピュータのハードウェア選定プロセスを解説します。皆さんのプロジェクトでは、要件定義の段階でどこまで「現実の壁」を想定できているでしょうか？これから紹介するステップを進めることで、手戻りを防ぐ「ハードウェア要件定義シート」が完成するはずです。
本チュートリアルのゴール：スペック表の「TOPS値」に惑わされない選定眼を持つ
まず認識すべきなのは、カタログに記載されている「200 TOPS」「1000 TOPS」といった数字は、いわば「理論上の最大瞬間風速」だということです。特定の条件下で達成可能な数値であり、実際のAIモデルがその性能を出せる保証はどこにもありません。
なぜPoCと同じ構成では量産できないのか
デスクトップGPU（例：NVIDIA GeForce RTXシリーズなど）を使って開発されたアルゴリズムを、そのまま車載グレードのSoC（System on Chip）に移植しようとすると、以下の3つの課題に直面します。
- 電力効率の課題：デスクトップGPUが300W消費して出す性能を、車載では30W〜60W程度で実現しなければなりません。
- 熱設計の課題：ファンで強制空冷できるPCと違い、車載ECUは密閉筐体やファンレス設計が求められることが多く、排熱能力がボトルネックになります。
- 信頼性の課題：エラー訂正機能（ECC）のないメモリや、振動に弱いコネクタは、人命に関わるシステムでは許容されません。
作成する成果物：ハードウェア要件定義シート
本記事では、以下の項目を埋めていく形式で進めていきます。
- 必要実効スループット（理論値ではなく実測予測値）
- 熱設計電力（TDP）上限と冷却方式
- センサー入力帯域幅とI/F規格
- 機能安全レベル（ASIL）と冗長構成
それでは、具体的な計算から始めていきましょう。準備はよろしいでしょうか？
Step 1：AIワークロードからの必要演算能力の算出
多くのエンジニアが「どのSoCが良いか？」から考え始めますが、ビジネスへの最短距離を描くには、ワークロードの定義が先決です。「どのくらいのデータを、どのくらいの速さで処理しなければならないか？」を明確にする必要があります。
センサー構成とデータ流量の計算
自動運転システムにおいて、最も帯域を消費するのはカメラデータです。例えば、レベル3程度の自動運転システムを想定し、以下のような構成で計算してみます。
【想定システム構成】
- カメラ: 8メガピクセル（4K相当: 3840 x 2160） × 8台
- フレームレート: 30 fps
- 色深度: RGB 24bit（3バイト）
この場合の生データ（RAWデータ）の流量を計算します。
[
\text{データ流量} = 3840 \times 2160 \times 3 \text{ (bytes)} \times 30 \text{ (fps)} \times 8 \text{ (台)}
]
計算すると、約 5.97 GB/s になります。
これにLiDAR（点群データ）やレーダーのデータが加わります。LiDARはカメラに比べればデータ量は少ないですが（数Mbps〜数百Mbps程度）、点群処理はCPU/GPU負荷が高いのが特徴です。
ここで重要なのは、「この約6GB/sのデータを遅延なくメモリに書き込み、同時にGPUが読み出して推論処理を行い、結果を書き戻すことができるか？」というメモリ帯域幅（Memory Bandwidth）の視点です。
例えば、LPDDR5メモリの帯域幅が理論値で50GB/s〜100GB/s程度あったとしても、複数のカメラからの書き込みとGPUの読み出しが競合すれば、実効帯域は低下します。TOPS値が高くても、メモリ帯域が細いSoCでは、高解像度画像の処理が間に合わない可能性があります。皆さんのシステムでは、メモリ帯域のボトルネックを考慮できているでしょうか？
モデルサイズと目標FPSからの逆算
次に、AIモデルの演算量（MACs: Multiply-Accumulate Operations）から必要TOPSを見積もります。
ここで考慮すべきなのが、使用するモデルの世代交代とアーキテクチャの根本的な変化です。物体検出のデファクトスタンダードであるYOLOシリーズを例にとると、最新のモデルでは推論速度を極限まで高めるため、従来は必須とされていたNMS（Non-Maximum Suppression）やDFLといった処理が廃止されるという大きな転換が起きています。
- 最新YOLOの特徴: 後処理が一切不要なNMS-free推論設計（One-to-One Headオプションなど）が採用され、エッジデバイスでのデプロイが劇的に最適化されました。これにより、1物体につき1つのバウンディングボックスが直接出力されるようになり、処理のボトルネックが解消されています。
- モデル選定と移行の視点: 従来のNMSに依存したパイプラインを構築している場合、最新モデルへの移行時には推論コードの後処理部分を大幅に書き換える必要があります。しかし、新しいアーキテクチャを採用することで、同じハードウェアでもより高いFPSを出せる、あるいはより小さなSoCで要件を満たせる可能性が高まります。
とはいえ、ハードウェア選定の段階では、余裕を持った見積もりが不可欠です。仮に、高精度な物体検出モデル（YOLOのラージモデル相当）を使用し、1フレームあたりの演算量が約100 GFLOPS（0.1 TFLOPS）だと仮定します。これを8台のカメラすべてで30fpsで回す場合：
[
\text{必要演算量} = 0.1 \text{ TOPS} \times 30 \text{ fps} \times 8 \text{ 台} = 24 \text{ TOPS}
]
「24 TOPSなら、エントリークラスのSoCでも十分ではないか」と思うかもしれませんが、ここに「実効効率係数（Utilization Factor）」という落とし穴があります。
スパース性と量子化を考慮した実効TOPSの見積もり
カタログスペックのTOPS値に対し、実際のアプリケーションで出せる性能は、一般的に 30%〜50% 程度と言われています。これは、ソフトウェアのオーバーヘッド、メモリアクセスの待ち時間、GPUコアの稼働率などが影響するためです。
したがって、理論上24 TOPS必要なら、ハードウェア選定時は安全率を見込んで、その2〜3倍のスペックを目指すべきです。
[
\text{選定基準TOPS} = \frac{\text{必要演算量}}{0.3 \sim 0.5}
]
つまり、最低でも 50〜80 TOPS クラスのSoCが必要という計算になります。
さらに、将来的なモデルの複雑化（Transformerベースのモデル導入など）やOTA（Over-The-Air）アップデートによる機能追加を見越すなら、100 TOPS以上 を確保するのが良いと考えられます。特に、Hugging Face Transformersなどの最新ライブラリ環境では、TensorFlowやFlaxのサポートが終了しPyTorch中心に最適化が進むという大きな変革が起きています。その一方で、モジュール型アーキテクチャの採用や、8bit/4bit量子化モデルの第一級サポートが強化され、メモリ効率を高めるキャッシュAPIの標準化も進んでいます。
こうしたソフトウェア側の急速な進化や、外部ツールとの連携強化に追従するためにも、ハードウェアには十分な余裕を持たせ、量子化技術の恩恵を最大限に引き出せるアーキテクチャを選定することが、結果的にビジネスの寿命を延ばすことにつながります。
【チェックリスト 1】
- 全センサーの合計データ流量（GB/s）は算出しましたか？
- 使用予定のAIモデル（最新のYOLOアーキテクチャ等）の演算量（MACs/FLOPS）を把握していますか？
- 実効効率（30-50%）を考慮して必要TOPSを補正しましたか？
- AIライブラリのサポート状況（PyTorchへの移行など）や量子化の適用可能性をハードウェア要件に反映していますか？
Step 2：物理的制約条件（SWaP-C）の定義
必要な性能が見えたところで、次はそれを「物理的に搭載できるか」という現実的な制約条件を定義します。これを業界では SWaP-C (Size, Weight, Power, and Cost) と呼びます。
電力バジェットの策定：EV航続距離への影響
電気自動車（EV）において、電力は航続距離に直結する貴重なリソースです。自動運転コンピュータが数百ワットも消費すれば、航続距離は短くなる可能性があります。
一般的に、乗用車向けのADAS/自動運転ECUに割り当てられる電力バジェットは以下のレンジが多いです。
- ADAS（レベル2/2+）: 10W 〜 30W
- 自動運転（レベル3）: 50W 〜 100W
- 完全自動運転（レベル4/ロボタクシー）: 200W 〜 500W以上
開発しているシステムがどのカテゴリに属するかで、選べるSoCは絞られます。例えば、30Wのバジェットしかないのに、TDP（熱設計電力）が60WのハイエンドSoCを選ぶことは難しいでしょう。
熱設計電力（TDP）と冷却方式の決定
電力よりもさらに厳しいのが「熱」です。半導体の寿命と信頼性は温度に依存します。
車載環境、特にエンジンルームや直射日光下のダッシュボード付近では、周囲温度（Ambient Temperature: Ta）が 85℃ や 105℃ に達することがあります。AEC-Q100グレード2（-40℃〜105℃）などの規格適合が求められるのはこのためです。
チップのジャンクション温度（Tj）は、以下の式で概算できます。
[
\text{Tj} = \text{Ta} + (\text{消費電力} \times \text{熱抵抗})
]
もし周囲温度（Ta）が85℃で、チップの上限温度（Tj max）が105℃だとすると、許容できる温度上昇はわずか20℃しかありません。この狭いマージンの中で数十ワットの熱を逃がすには、効率的な冷却システムが必要です。
- 自然空冷（ファンレス）: 信頼性は高いが、冷却能力は低い（〜15W程度が限界のケースが多い）。筐体のフィン設計が重要。
- 強制空冷（ファン）: 冷却能力は高いが、ファンの故障リスク（可動部品）があるため、車載では採用されない傾向にあります。採用する場合は高信頼性ファンが必要。
- 液冷: 冷却能力は高い。EVのバッテリー冷却システムと統合できる場合などに採用されますが、コストと複雑さが増します。
開発現場では「PoCではPC用のファンで冷やしていたが、製品ではファンレスにしたい」という無茶な要望がよく挙がりますが、物理法則は曲げられません。SoCのグレードを落とすか、巨大なヒートシンク（筐体）を用意するかの決断が必要です。
設置スペースと耐振動性の要件
トランクに積むのか、シート下に置くのか、ダッシュボード裏か。設置場所によってサイズ（Size）の制約が決まります。また、車は常に振動しています。PCIeカードのような「挿すだけ」の接続は、振動で抜けるリスクがあります。すべてのコンポーネントは基板にハンダ付けされるか、堅牢なコネクタで固定される必要があります。
【チェックリスト 2】
- システム全体で使える電力上限（W）は決まっていますか？
- 設置場所の最大周囲温度（Ta）は何度ですか？
- 冷却方式（ファンレス/液冷など）の方針は決まっていますか？
Step 3：システムアーキテクチャとインターフェース選定
SoC単体の性能だけでなく、データを出し入れする設計も重要です。
センサー入力I/Fの選定（GMSL2/FPD-Link III/Ethernet）
PoCではUSBカメラを使うことが多いですが、量産車載システムでUSBは推奨されません。コネクタの抜けやすさ、ケーブル長の制限、CPU負荷の高さが問題になるからです。
代わりに、GMSL2 (Gigabit Multimedia Serial Link) や FPD-Link III といった車載専用のSerDes（Serializer/Deserializer）規格を使用します。これらは同軸ケーブル1本で映像信号と電源供給（PoC: Power over Coax）を行い、10m以上の伝送が可能です。
選定するSoCやキャリアボードが、必要なチャンネル数のGMSLデシリアライザを搭載できるか、あるいはPCIe経由で拡張カードを接続できるかを確認する必要があります。
ドメインコントローラ型かゾーン型か
最近のトレンドとして、車両の配線を減らすために「ゾーンアーキテクチャ」が注目されています。これは、車両を物理的なゾーン（左前、右後など）に分け、そのゾーン内のセンサーやアクチュエータを統括するゲートウェイ（ゾーンECU）を置く考え方です。
一方、従来の「ドメインコントローラ型」は、自動運転機能なら自動運転ECUにすべてのセンサーを直接繋ぐ方式です。
システムがどちらのアーキテクチャを前提としているかで、必要なイーサネットポートの数やスピード（1GbEか10GbEか）が変わってきます。
ストレージとメモリの耐久性要件
OSやログデータを保存するストレージにも注意が必要です。一般的なSSDやSDカードは、書き込み回数制限（TBW）や温度特性が車載要件を満たさないことがあります。
特に、自動運転システムでは走行中のセンサーデータをログとして記録し続けるケースがあります。例えば1時間で数百GBのデータを書き込む場合、民生用のNANDフラッシュでは数ヶ月で寿命を迎えてしまうかもしれません。皆さんの設計では、10年後もストレージが生き残っている確証はありますか？
- SLC/pSLCモードの採用：容量は減るが耐久性を向上させる。
- はんだ付けeMMC/UFS: 振動対策としてソケット式ではなくBGA実装を選ぶ。
【チェックリスト 3】
- カメラI/Fは車載規格（GMSL等）に対応していますか？
- 必要なPCIeレーン数は足りていますか？（WiFiモジュールやNVMe SSD用など）
- ストレージの書き込み寿命は想定稼働期間（例：10年）を満たしますか？
Step 4：機能安全（Functional Safety）と冗長化設計
人が乗る、あるいは人の近くで動く機械には、故障しても安全を担保する設計（ISO 26262）が求められます。
ISO 26262 ASILレベルへの対応戦略
自動運転機能が誤動作した場合のリスクに応じて、ASIL (Automotive Safety Integrity Level) A〜Dのランクが決まります。ステアリングやブレーキに介入するシステムであれば、最も厳しい ASIL D が求められることが多いです。
選定するSoC自体がASILに対応しているかを確認しましょう。
- ASIL B対応SoC: 多くのインフォテインメント向けチップやエントリー向けADASチップ。
- ASIL D対応SoC: ミッションクリティカルな制御向け。内部にロックステップ動作（2つのコアで同じ計算をして結果を照合する）する安全島（Safety Island）を持っていることが多いです。
もしAI処理用のSoCがASIL Bまでしか対応していない場合、外部にASIL D対応のマイコン（Infineon Aurixなど）を配置し、監視させる構成が必要になることがあります。
フェイルオペレーショナルを実現する冗長構成
レベル3以上の自動運転では、システムの一部が故障しても、安全に路肩に停止するまでの間、機能を維持する「フェイルオペレーショナル（Fail-Operational）」が求められます。
これは単一のSoCでは実現が難しいため、二重化（Redundancy）が必要になることがあります。メインのSoCがダウンしたら、サブのSoCが最低限の制御を引き継ぐ構成です。ハードウェア選定時には、この「2つ目のチップ」を載せるスペースと電力も考慮に入れる必要があります。
ウォッチドッグと安全機構の実装要件
- ECC (Error Correction Code) メモリ: メモリ上のビット反転（ソフトエラー）を検知・訂正する機能。車載では必須です。
- 外部ウォッチドッグタイマー: SoCがフリーズしたことを外部から検知し、強制的にリセットをかけたり、安全リレーを遮断したりする回路。
これらがハードウェアレベルでサポートされているか、キャリアボード上に実装可能かを確認します。
【チェックリスト 4】
- ターゲットとするASILレベル（A/B/C/D）は明確ですか？
- 選定候補のSoCはECCメモリをサポートしていますか？
- 故障時のバックアップ体制（冗長化）は設計に含まれていますか？
Step 5：候補デバイスの比較評価と最終選定
要件が出揃ったら、具体的なデバイスの選定に入ります。NVIDIA Jetsonシリーズ（Orin, Xavier等）、Qualcomm Snapdragon Rideプラットフォーム、TI TDA4シリーズ、ルネサス R-Carシリーズなどが有力な候補となるでしょう。
ベンチマークテストの設計（MLPerf Automotive等の活用）
カタログスペック上のTOPS値だけでは、実際のアプリケーション性能は予測できません。「まず動くものを作る」プロトタイプ思考に基づき、必ず開発ボード（DevKit）を入手し、実際のモデルを用いた実機ベンチマークを行う必要があります。
- 実効レイテンシ（End-to-End Latency）: カメラ入力から推論結果が出力されるまでのトータル時間。平均値だけでなく、99パーセンタイル値（テールレイテンシ）を確認し、最悪ケースでも安全要件を満たせるか検証します。
- サーマルスロットリングの挙動: 高負荷状態で連続稼働させ、温度上昇に伴うクロックダウンが発生しないか、または発生時の性能低下が許容範囲内かを確認します。
開発エコシステムと長期供給性
ハードウェアのシリコン性能と同じくらい重要なのが、BSP（Board Support Package）の品質とソフトウェアエコシステムの成熟度です。
- SDKと推論エンジンの最適化: NVIDIAのTensorRTやQualcommのAI Stack（QNN/SNPE）など、ベンダー提供のツールチェーンは使いやすいか？ 特に最新のモデルアーキテクチャ（Transformer系など）への対応状況については、必ず公式ドキュメントで最新情報を確認してください。
- コミュニティとサポート体制: 開発者フォーラムは活発か？ ドキュメントは頻繁に更新されているか？ エラー発生時のトラブルシューティングの容易さは開発工数に直結します。
- 長期供給プログラム（LTS）: 車載製品のライフサイクルは長期間に及びます。選定したSoCが今後10年以上にわたり供給される保証があるか、メーカーのEnd of Life（EOL）ポリシーを確認することは、経営的なビジネスリスクを回避するために必須です。
要件定義シートの完成とレビュー
これまでのステップで収集・検証した情報を1枚のシートに集約します。これは、サプライヤーや社内のハードウェア設計チームと議論するための「共通言語」となります。
単に「高性能なAIチップ」という曖昧なオーダーではなく、「カメラ8台・合計6GB/sの入力帯域を持ち、YOLOv8モデルを合計200FPSで処理可能、かつTDP 50W以下でASIL B機能安全に対応したSoC」という具体的な要求仕様書を作成することで、プロジェクトの手戻りを最小限に抑え、ビジネスへの最短距離を歩むことができます。
まとめ：制約こそがエンジニアリングの醍醐味
PoC（概念実証）の段階では「何ができるか（Possibility）」を追求しますが、量産設計のフェーズでは「何ができないか（Constraint）」と真摯に向き合うことになります。熱、電力、コスト、安全性といった厳しい制約条件は、一見すると開発の障壁のように思えます。しかし、これらをエンジニアリングの力でクリアして初めて、AIは実験室を出て社会という実世界で真の価値を生み出すことができるのです。
徳島で中学生からプログラミングを始め、35年以上のキャリアを通じて数々のシステム開発に携わってきましたが、今回解説した「環境制約から逆算して最適解を導く」というシステム思考のプロセス自体は、技術トレンドが変化しても色褪せない普遍的なスキルだと確信しています。
ぜひ、このプロセスをチーム全体で共有し、量産化という高い壁を突破してください。皆さんのプロジェクトが、最短距離でビジネスの成功に辿り着くことを応援しています。
コメント