エッジ AI とフィジカル AI の違いとは
エッジ AI は、リソースの限られたハードウェア上で推論を実行し、分類・予測・スコアといった情報を出力します。フィジカル AI は、その推論結果をもとに、モーター、バルブ、ブレーキ、手術器具などを実際に動かします。
モデル自体はどちらも同じでも、その下で動くファームウェアが負うリスクは同じではありません。
自動車・医療・産業機器向けの製品を開発する組込み開発チームにとって、この違いは「きちんと動けばよいシステム」と「認証を取得できなければならないシステム」の分かれ目です。推論の出力が物理的な動作を引き起こした時点で、モデルを支えるソフトウェアスタックは安全関連の成果物となり、IEC 61508、ISO 26262、IEC 62304 といった既存の規格が適用されます。
フィジカル AI は、これらの規格の外にあるのではなく、その内側に位置しています。
組込み開発のリーダーが今、押さえておくべき理由
現在のフィジカル AI システムの多くは、これまで共通言語を持たなかった 2 つのエンジニアリング文化の接点で開発されています。
- 機械学習チームは、モデルの精度、学習パイプライン、推論レイテンシーの最適化に注力します。
- 組込みの安全チームは、ASIL レベル、ツール認定、静的解析、決定論的な実行といった観点で考えます。
どちらのチームも、それぞれの領域では高い専門性を持っています。リスクが潜むのは両者が重なる部分、つまりホストファームウェアです。ホストファームウェアは、システムの初期化、メモリ管理、割り込み処理、推論エンジンの呼び出し、そして出力をアクチュエーターへ渡す処理までを担います。このコードは C または C++ で記述され、他のセーフティクリティカルなファームウェアと同じ要件が課されます。MISRA への準拠、静的解析、実行時検証、トレーサビリティのあるテストです。
フィジカル AI 製品の開発を担うエンジニアリングリーダーやプログラムマネージャーの皆さまが問うべきは、次の点です。ファームウェア層の責任者は誰か。その層は、他のセーフティクリティカルなコードと同じ厳格さで開発されているか。それとも、モデルの周辺をつなぐだけの「接着コード」として扱われていないか。
プロトタイプ段階で見落とされがちな認証の問題
デモ段階では、フィジカル AI システムは機能面で評価されます。
- ロボットアームは障害物を避けられるか
- 予知保全モデルは異常を検知できるか
- 義肢のコントローラーは 10 ミリ秒以内に応答できるか
いずれもプロトタイプでは妥当な問いですが、規制市場で製品を出荷できるかどうかを左右する問いではありません。
認証の可否を決めるのは、次の問いです。
そのソフトウェアが、管理・文書化されたプロセスのもとで、認定済みのツールチェーンを使って開発され、定められたコーディング規約に照らして解析され、トレーサビリティのあるカバレッジでテストされたことを示せますか。
この問いをモデルの実証が済んだ後に回したチームは、過去の判断が覆ることに気づくケースが少なくありません。ツールチェーンの選定、推論ラッパー内でテストされていない実行パス、監査で初めて表面化する解析の抜けなどです。発見が遅れるほど対応コストは大きくなります。これは技術上の課題にとどまらず、プロジェクト計画上のリスクでもあります。
組込み開発ワークフローで変わること
フィジカル AI に合わせて組込みワークフローを見直すといっても、既存の安全対策を捨てるわけではありません。AI モデルが関わるシステムのあらゆる部分へ、それらを広げていくことです。
1. ホストファームウェアを初日からセーフティクリティカルとして扱う
MISRA C/C++、CERT C/C++、CWE に対応した静的解析は、監査の後工程ではなく、コミットのたびに実行します。
2. 静的解析に加えて実行時検証も行う
モデル実行中のメモリアクセス違反、推論負荷がピークに達したときのスタックオーバーフロー、推論出力からアクチュエーター指令までの制御パスにおける未定義動作は、静的解析では検出できません。開発中の実行時テストであれば検出できます。
3. 開発者が見落としがちなパスをテストする
コードカバレッジでは、エラー処理の分岐が実際に実行されていることを示す必要があります。「モデルが異常な出力を返すことはない」という思い込みから、開発者が軽視しやすいパスです。しかし、モデルは異常な出力を返すことがあります。
4. デバイスのライフサイクル全体を見据えてツールチェーンの安定性を確保する
現在出荷するフィジカル AI 製品は、10 年後も工場で稼働している可能性があります。その間に提供するすべてのパッチや安全アップデートを、認証取得済みの初回リリースと同じ認定済みツールチェーン構成にさかのぼって追跡できなければなりません。ツールチェーンの長期提供は、調達の付随事項ではなく、製品ライフサイクルに関わる意思決定です。
CI/CD が DevOps の利便性ではなく、安全基盤になる理由
フィジカル AI のアーキテクチャが世代を重ねるごとに複雑化するにつれ、難しくなるのは個々のビルドを正しく仕上げることよりも、一貫性を保つことです。
ここで CI/CD は、あると便利なものから必須の要件に変わります。コミットのたびに、ビルド、静的解析、全テストの実行、構造化されたコンプライアンス成果物の生成が自動で行われれば、品質基準は開発者個人の規律ではなくパイプラインによって担保されます。エビデンスは最初のコミットから蓄積されるため、監査の前に再構築する必要がありません。
コンテナ化されたビルド環境は、フィジカル AI において次のような保証を加えます。
- ツールチェーン、コンパイラーの設定、解析ツールを、バージョン管理されたコンテナイメージにまとめます。
- 開発者のワークステーション、クラウドランナー、オンプレミスの CI サーバーのいずれでも、パイプラインが同一に実行されます。
- あるバイナリをどのバージョンのツールで、どの構成により生成したのかを規制当局から問われても、答えは担当者の記憶ではなくコンテナイメージの中にあります。
これにより、複数のプロセッサーアーキテクチャにまたがるファームウェアの調整という、実務上の課題も解消されます。Arm Cortex-M と RISC-V にまたがる単一のコンテナ化パイプラインであれば、Renesas RA、RX、RZ、RH850、RL78、RZ/Five などの MCU ファミリーを含め、ハードウェアが変わってもコンプライアンスの水準を一定に保てます。
規制市場の組込みチームがツールチェーンに求めるもの
後から付け足すのではなく、最初からワークフローに組み込むことを検討しているチームのために、ツールチェーン層がカバーすべき要件を挙げます。
- 認証済みツールチェーン（例：TÜV SÜD 認証取得済みで、IEC 61508、ISO 26262、IEC 62304 に対応）。監査の際にツールの動作を自社で検証する必要がなくなります。
- ヘッドレスのビルドツール。主要な CI プラットフォーム（GitHub Actions、GitLab CI、Jenkins）と連携し、CI 上のビルドを開発者のローカルビルドと完全に一致させます。
- ビルドステップに組み込まれた静的解析。MISRA C/C++、CERT C/C++、CWE の各規格を適用し、コミット時に違反を検出します。
- テスト実行中のランタイム解析。メモリ違反、スタックの逼迫、アクチュエーション経路の未定義動作など、静的解析だけでは到達できない動的な不具合を検出します。
- 長期サポート版。デバイス稼働 6 年目に提供するパッチでも、初回リリースと同じ認定済みツールチェーン構成にさかのぼって追跡できます。
IAR プラットフォームは、こうした要件に直接応えるために作られています。認証済みツールチェーン、静的解析と実行時解析を統合した C-STAT と C-RUN、そしてこのワークフローのために設計されたCI ネイティブのビルドツールを、組込みチームに提供します。
まとめ：両者を分ける一線
エッジ AI とフィジカル AI は、インフラを共有していますが、リスクの度合いは異なります。認証審査を通過できるのは、モデルの最適化に力を注いでファームウェアが追いつくのを待つチームではなく、最初のコミットからファームウェアを安全関連の成果物として扱うチームです。
