自動車・産業・組込みの安全クリティカルなシステムにニューラルネットワークを展開するには、根本的に異なる二つのエンジニアリング哲学を調和させる必要がある：機械学習の確率的でデータ駆動の世界と、機能安全の決定論的でエビデンスに基づく世界である。本ガイドは、これらの環境を統制する規格 — ISO 26262、SOTIF/ISO 21448、IEC 61508、IEC 62443 — と、安全エンジニアが受け入れられる ML 展開をどう構成するかを解説する。
最終確認：2026年5月
機能安全とは、システム全体の安全性のうち、電気・電子・プログラマブル電子コンポーネントの正しい動作に依存する部分である。AI または ML コンポーネントが安全クリティカルなシステム — 自律緊急ブレーキ、産業用緊急停止、ロボットの動作計画 — に展開される場合、機能安全規格は、システムが安全に故障し、定義された運用条件内で正しく振る舞い、ハードウェアおよびソフトウェアの故障を許容することの証拠を要求する。機械学習にとっての課題は、これらの規格が決定論的ソフトウェア向けに設計されており、ニューラルネットワークが従来の意味で決定論的ではないことである。
自動車・産業システムを統制する機能安全規格 — ISO 26262、IEC 61508、IEC 62061 — は決定論的ソフトウェア向けに開発された：定義されたロジックを通じて入力を処理し、形式的に仕様化でき、構造カバレッジ基準に対してテストでき、システムの運用条件内で正しいと検証できる出力を生成するコードである。
ニューラルネットワークはこのモデルに当てはまらない。それらは（プログラムされるのではなく）訓練され、その振る舞いは明示的なロジックではなく数百万の学習済みパラメータから創発する。同じ入力を二度提示しても、ハードウェアの浮動小数点の振る舞いやスレッドのスケジューリングによって、わずかに異なる出力を生じることがある。その故障モードは決定論的ではなく統計的である：平均的には良好に動作するが、訓練データで過小に表現されていた特定の入力では失敗しうる。そして、形式的な仕様が存在しないため形式仕様に対して網羅的に検証することはできない — 仕様は訓練データに暗黙的に含まれている。
これは、安全クリティカルなシステムに AI を展開するすべてのエンジニアが解決しなければならない根本的な緊張を生む：従来の意味で振る舞いを形式的に仕様化も検証もできないコンポーネントに対して、どのように安全ケースを構築するのか。その答え — いま標準化団体、業界コンソーシアム、初期のプログラム経験から立ち現れつつある — は、アーキテクチャパターン（安全監視、ODD の定義、フォールバック経路）と統計的証拠（大規模な検証データセット、ロバストネス試験）を組み合わせ、両者が一体となって主張可能な安全ケースを構成する。
以下の六つの中核的緊張は、すべての安全クリティカルな ML 展開が対処しなければならないエンジニアリング上の課題を表している。
機能安全規格（ISO 26262、IEC 61508）は決定論的な振る舞いを前提とする：同じ入力に対して、安全機能は毎回同じ出力を生成する。確率的勾配降下とドロップアウトで訓練されたニューラルネットワークはこの保証を提供しない。同一の入力でさえ、ハードウェアの浮動小数点実装やスレッドのスケジューリングによってわずかに異なる出力を生じうる。
安全ケースはトレーサビリティを要求する — システムがなぜある判断を下すのかを説明でき、定義された運用設計領域（ODD）内で安全でない判断が起こりえないことを示せなければならない。深層ニューラルネットワークは根本的に不透明である。説明可能性の手法（SHAP、LIME、アテンションマップ）は近似を提供するのであって、証明ではない。
ある訓練データの分布で訓練されたモデルは、その分布の外にある入力に対して予期せぬ振る舞いをしうる — 分布シフトとして知られる問題である。安全規格は、システムが定義された運用条件の集合全体にわたって正しく振る舞うことを要求する。分布シフトはこの要件と根本的に相容れない。
従来の安全クリティカルなソフトウェアは、構造カバレッジ指標（ASIL D に対する MC/DC）を用いて形式仕様に対して検証される。ニューラルネットワークはこの方法で検証できない — 「仕様」は訓練データに暗黙的に含まれている。大規模なホールドアウトデータセットでの統計的検証が形式的検証に取って代わるが、何が十分な証拠を構成するかについて安全当局の見解は分かれている。
安全認証されたソフトウェアは厳格な変更管理の対象である：いかなる変更も再評価を要する。ニューラルネットワークのモデルは、データの蓄積に伴ってファインチューニング、更新、または置換されうる。各更新は既存の安全ケースを無効にしうるため再検証を要し、運用上の改善と認証維持との間に緊張を生む。
エッジの安全システムは厳しいエンドツーエンドのレイテンシ予算を持つ — リアルタイム制御ループではしばしば 10ms 未満である。制約のあるハードウェア（MCU、FPGA、小型 SoC）でのニューラルネットワーク推論は、制御経路の残りにマージンを残しつつこの予算内に収まらなければならない。量子化と枝刈りは助けになるが、それ自体の故障モードをもたらす。
ISO 26262 は自動車の機能安全規格であり、最大総質量（MGVM）3,500 kg までの道路車両に適用される。Automotive Safety Integrity Level（ASIL）フレームワーク — 所与の安全機能に必要な安全エンジニアリングプロセスの厳格さを規定する四つのレベル（A から D）— を定義する。ASIL D が最も厳格で、ASIL A が最も緩い。
ある機能の ASIL レベルは、三つの要因を考慮するハザード分析・リスクアセスメント（HARA）を通じて決定される：潜在的な危害の重大度（S）、危険状況への暴露（E）、運転者または操作者による制御可能性（C）である。S、E、C の組み合わせが ASIL の割り当てを決定する。
V-model は開発プロセスのフレームワークである：要件は V の左辺で仕様化・分解され、実装は底部にあり、統合・検証・妥当性確認テストは右辺にあって左辺の各成果物を鏡映する。すべての安全要件は、車両レベルの安全目標からシステム・ハードウェア・ソフトウェアの各レベルを通じてトレースされ、右辺の対応するレベルで検証されなければならない。
SOTIF（ISO 21448:2022）は ISO 26262 を拡張し、意図した機能そのものの限界から生じるハザード — 故障からではなく、システムが設計どおりに正確に振る舞うものの設計が実際の運用条件に対して不十分である状況から生じるもの — を扱う。これは ML に直接関係する：異常な照明下で歩行者を誤分類する知覚モデルは従来の意味で「故障している」のではない — 訓練どおりに動作しているが、その条件に対して訓練が不十分だったのである。SOTIF 分析は、これらのトリガー条件を特定し体系的にテストすることを要求する。
最も低い機能安全要件。ハザードの重大度が低い、または暴露が稀なシステムに適用される。
ML 展開への含意
中程度のテストセットでの統計的検証が受け入れられうる。基本的なランタイム監視で十分。
中程度の安全要件。中程度のハザード可能性を持つ運転支援機能に一般的に適用される。
ML 展開への含意
文書化された ODD、ODD 境界事例にわたる性能指標、分布外入力の監視を要する。
高い安全要件。外部の緩和なしに故障が重傷につながりうるシステムに適用される。
ML 展開への含意
包括的な安全ケースが必要。ランタイムアシュアランス監視、明示的なフォールバック経路、SOTIF 分析が必須。第三者レビューが通常期待される。
自動車の機能安全の最高レベル。故障が生命を脅かすハザードにつながりうるシステムに適用される。
ML 展開への含意
ニューラルネットワークのコンポーネントは通常、知覚/助言の役割に限定され、最終的な安全クリティカルな制御経路に置かれることは決してない。冗長な決定論的監視が必要。現在の業界コンセンサス：純粋な ML コンポーネントは単独の安全機能として ASIL D に認証できない。
IEC 61508 は、電気・電子・プログラマブル電子（E/E/PE）安全関連系のための汎用機能安全規格である。これは部門別規格 — IEC 62061（機械）、EN 50128（鉄道）、IEC 61511（プロセス産業）、IEC 61513（原子力）— が派生する親規格である。Safety Integrity Level（SIL）フレームワークは IEC 61508 における ASIL の相当物であり、安全機能に必要な要求時失敗確率（PFD）によって定義される四つのレベル（SIL 1–4）である。
産業システムへの AI 展開では、鍵となる問いはこうである：AI コンポーネントが寄与する安全機能にはどの SIL レベルが割り当てられるのか。これは、要求される検証証拠の厳格さと、その機能内で AI コンポーネントをどう使用できるかの制約を決定する。
一般原則は ISO 26262 と同じである：ニューラルネットワークのコンポーネントは、助言要素または起動要素としてより低い SIL の機能に寄与できるが、最高度の完全性を持つ安全機能には、決定論的な実装、または ML コンポーネントの出力をオーバーライドする決定論的な安全監視が必要である。
最も低い安全度水準。複数の寄与要因なしには単一の故障が危険事象を引き起こす可能性が低い機能に適用される。
ML に関する注記
SIL 1 の安全機能に入力される ML ベースの助言システムは、定義された運用条件内での統計的信頼性を実証しなければならない。
中間レベル。プロセス産業の安全計装機能に一般的：緊急停止、圧力逃がしの起動、火災・ガス検知。
ML に関する注記
SIL 2 の停止に入力される ML 異常検知は、安全ループにおける起動要素として扱われなければならない — その不要動作（危険側故障）の確率を実証しなければならない。
高い完全性水準。化学プラントの緊急系、鉄道信号、原子力計装の支援機能に見られる。
ML に関する注記
ニューラルネットワークのコンポーネントは現在、ほとんどの認証機関によって SIL 3 の安全機能実装として受け入れられていない。ML は、実証済みの決定論的安全層と並んで診断や非安全クリティカルなデータ経路を支援しうる。
IEC 61508 の最高レベル。原子炉保護系、鉄道の重要機能。実務では極めて稀。
ML に関する注記
現時点で、安全機能そのものの一部として SIL 4 で受け入れられる ML コンポーネントはない。
IEC 62443 は、産業オートメーション・制御システム（IACS）のサイバーセキュリティのための国際規格シリーズである。ゾーンとコンジットのモデルを定義する：OT ネットワークは、含まれる資産の重要度に基づいてゾーンに分割され、ゾーン間の通信は適切なセキュリティ制御を備えた定義されたコンジットを通過しなければならない。
AI 展開において、IEC 62443 の問いはこうである：AI 推論サーバーはどのゾーンに置かれ、制御ネットワークとの通信をどのセキュリティ制御が統制するのか。適切なコンジット制御なしに PLC やフィールド機器と直接通信する AI 推論サーバーを配置することはゾーンモデルに違反し、サイバーセキュリティリスクを生む — AI サーバーを侵害した攻撃者は制御ゾーンへの経路を得る。
加えて、AI システムは新たな攻撃面である：敵対的入力 — モデルに誤った出力を生成させるよう巧妙に作られた入力 — は、安全に関わる故障を引き起こしうる。AI システムに対する IEC 62443 のサイバーセキュリティ分析は、従来の IT セキュリティ制御に加えて敵対的ロバストネス試験を含めるべきである。
ビジネス IT ネットワーク — ERP、企業メール、クラウド接続。ここに展開された AI モデルは最も広い攻撃面を持ち、侵害された場合の OT への影響は最小だが、データの鮮度は最も弱く、レイテンシは最も高い。
AI 配置のガイダンス
レポーティング AI、文書要約、ビジネス分析に適する。リアルタイム制御や安全隣接の推論には適さない。
監視制御システム、ヒストリアンデータベース、SCADA サーバー。ここに展開された AI 推論は、フィールド機器に直接アクセスせず、OPC-UA や OSIsoft PI を介してリアルタイムのプロセスデータにアクセスできる。
AI 配置のガイダンス
予知保全、プロセス最適化の助言、異常検知に適する。ゾーン 2 への IEC 62443-3-3 コンジット制御を要する。
PLC、DCS、フィールドコントローラ。安全クリティカルな制御ループはここで動作する。ゾーン 2 での AI 推論は異例であり、SL（セキュリティレベル）2 のハードニング：認証、暗号化通信、監査ログを要する。
AI 配置のガイダンス
ハードウェアの制約が許せば、ランタイムアシュアランス監視と分布外検知器はここで動作できる。安全機能の直接的責任には機能安全分析（ISO 26262 / IEC 61508）を要する。
センサ、アクチュエータ、スマート計器。極めて制約の強い機器 — 通常は MCU や単純な RTU。ここでの AI 推論は、専用の推論コプロセッサ上の TinyML モデル（INT8 量子化、1MB 未満）に限定される。
AI 配置のガイダンス
生のセンサストリームに対する異常検知。SL 1 の MCU クラスのハードウェアで実現可能。この層での安全機能の責任には正式な IEC 61508 評価を要する。
Hyperion は AI とエッジのアーキテクチャ層について助言します：ML が安全アーキテクチャのどこに収まるか、安全監視とフォールバック経路をどう構成するか、どのエッジツールチェーンがハードウェアに適切か、安全エビデンスパッケージをどう準備するか。当社は認証機関ではありません — しかし、認証機関が受け入れられるアーキテクチャを構築するお手伝いをします。
安全ケースとは、あるシステムが所与の環境における所与の用途に対して許容できるほど安全であるという、証拠に裏付けられた構造化された議論である。ML コンポーネントについては、安全ケースはニューラルネットワーク固有の故障モード — 分布シフト、不透明性、非決定性 — を、形式的検証ではなくアーキテクチャパターンと統計的証拠を用いて扱わなければならない。以下の六つの要素は、エッジでの ML コンポーネントに対する主張可能な安全ケースの中核を構成する。
ML コンポーネントが有効となる正確な条件を定義する：環境条件、入力データ範囲、センサの動作範囲、速度/負荷のエンベロープ。ODD は ML システムと安全ケースとの間の契約である。ODD 外のいかなる入力も安全状態をトリガーしなければならない — ML システムは領域外の入力に対して安全でない出力を黙って生成してはならない。
並行する決定論的な監視 — 従来型のソフトウェアまたはハードウェアで実装される — が ML コンポーネントの出力を監視し、安全制約に違反するいかなる出力もブロックまたはオーバーライドする。これは安全クリティカルなシステムに ML を展開する標準パターンである：ML コンポーネントは助言的であり、決定論的な監視が権威を持つ。監視自体が要求される ASIL/SIL レベルに認証されていなければならない。
OOD 検知器 — 通常は入力の再構成誤差、アンサンブルの不一致、またはマハラノビス距離に基づく — は、訓練分布の外にある入力にフラグを立てる。OOD を検知すると、システムは推論を続行せずフォールバック経路へ移行する。OOD 検知器は、安全ケース内でそれ自体の偽陰性率について検証されなければならない。
すべての安全クリティカルな ML 展開は、定義されたフォールバックを備えなければならない：ML コンポーネントが故障したとき、安全監視によってオーバーライドされたとき、または OOD 入力を検知したときにシステムが入る安全状態である。安全状態への移行自体が ASIL/SIL 評価されなければならない。一般的なフォールバックパターン：制限/保守モード（低速、安全マージンの拡大）、運転者/操作者への引き継ぎ要求、制御された停止。
形式的検証（MC/DC カバレッジ）はニューラルネットワークに適用できないため、その代わりに大規模で独立した代表的なテストセットでの統計的検証が用いられる。テストセットのサイズと構成、性能指標、信頼区間は、文書化され安全当局によって受け入れられなければならない。ISO PAS 21448（SOTIF）および近く制定される ISO 8800 が新たなガイダンスを提供する。
全体の安全機能はサブ要素に分解され、それぞれに ASIL/SIL レベルが割り当てられる。ML コンポーネントには通常より低い ASIL/SIL レベルが割り当てられ、その差は決定論的な安全監視によって補われる。この ASIL 分解は正式に文書化・レビューされなければならない。システム全体は最上位の ASIL/SIL 要件を満たさなければならない。
規格に関する注記： ML コンポーネントの安全ケースを構築する方法論は活発に進化している。ISO/TR 4804、UL 4600、および開発中の ISO 8800（AI と道路車両）が最新のガイダンスを提供する。認証機関や自動車 OEM は、特定の技術 — 何が十分な統計的証拠を構成するか、どの OOD 検知手法が受け入れられるか、ASIL 分解が ML-従来型ソフトウェアの組に対してどう適用されるか — についての受容方針を依然として確立しつつある。エビデンスパッケージについて整合させるため、対象とする認証機関と常に早期に連携すること。
安全クリティカルなエッジシステムは、汎用 AI 展開パターンの大半を排除する制約を課す。以下は、自動車または産業の安全コンテキストにおけるすべてのエッジ AI 展開を形づくるエンジニアリング上の制約と、それらに対処するツールチェーンの選択である。
自動車の安全システムは通常、エンドツーエンドのレイテンシ 10–50ms 未満を要求する。産業用制御ループはより厳しいことがある：ハードリアルタイム機能では 1–10ms。エッジ AI 推論は、平均レイテンシではなく最悪ケースのレイテンシ（99 パーセンタイル）で、利用可能なタイミングマージンに対してプロファイルされなければならない。
安全クリティカルなエッジシステムは、リアルタイム推論をクラウド接続に依存してはならない。クラウドはモデル訓練、監視、OTA 更新のオーケストレーションに使えるが、推論経路は完全にオフラインで機能しなければならない。ネットワーク分断はエッジケースではなく設計条件である。
自動車の ECU や産業用 PLC/エッジコントローラは通常、256KB–4MB の RAM を備えた ARM Cortex-M/R または RISC-V コア上で動作する。完全な深層学習モデルは収まらない。手法：INT8 量子化（TensorFlow Lite Micro、MCU 向け ONNX Runtime）、構造的枝刈り、より小さなアーキテクチャ（MobileNet、EfficientNet-Lite、カスタム CNN）への知識蒸留。
制約環境におけるエッジ AI の主流の本番展開経路：PyTorch で訓練 → ONNX へエクスポート → TensorRT（NVIDIA Jetson / Drive）または XNNPACK/NNAPI デリゲート付き ONNX Runtime（ARM SoC）で最適化。ONNX Runtime は ONNX Runtime for Microcontrollers を介して MCU 展開もサポートする。これらのツールチェーンには、安全ケースで検証されなければならない文書化された振る舞いがある。
安全システムは、同じ入力が常に同じ出力を生成することを要求する。これには次が必要：固定小数点演算（FP32 ではなく INT8）、実行ごとに変動するランタイム最適化の無効化、固定スレッドアフィニティ、推論中の動的メモリ割り当ての排除。展開全体でビット精度の決定性を達成するには、慎重なツールチェーン構成とハードウェア検証を要する。
エッジの安全コントローラは固定のメモリエンベロープを持つ — しばしばアプリケーション全体で共有される 4–16MB の Flash と 1–4MB の RAM を超えない。バッテリ駆動または熱的に制約された機器の電力予算は推論頻度を制限する。モデル量子化と（連続ではなく）スケジュールされた推論が一般的な解決策である。
以下は、安全クリティカルなシステムにおけるエッジ AI に関する Hyperion の経歴についての事実に基づく記述である。これらは検証済みの事実であり、マーケティング上の主張ではない。
スコープの開示： Hyperion は AI とエッジのアーキテクチャのコンサルタンシーである。当社は AI/エッジ層について助言する — アーキテクチャ、ツールチェーン選定、安全監視の設計、ODD の定義、エビデンスパッケージの構成。当社は認証機関でも、公認機関でも、認定された安全評価者でもない。ASIL や SIL の認証を発行しない。正式な認証作業には認定された第三者を要する。
創業者の Mohammed Cherifi は、Renault-Nissan-Mitsubishi Alliance、Cisco、ABB での業務を含め、自動車・組込みシステムエンジニアリングで17年以上を過ごした。この経歴には、車両ソフトウェア開発における機能安全プロセス、組込み制御システム、安全クリティカルな環境の運用上の制約への直接的な関与が含まれる。Hyperion はこの経験を AI/エッジ層にもたらす — 認証機関としてではなく、その環境を理解するエンジニアリングチームとして。
Hyperion の旗艦ベンチャーである Auralink は、約20の AI エージェントを擁する 400 以上のマイクロサービス上に構築された、エッジ展開型のエージェントプラットフォームである。Auralink のアーキテクチャは、制約のあるエッジハードウェア上での AI 推論に必要なエンジニアリングパターン — 低レイテンシの推論経路、決定論的な制御境界、AI 助言層と権威ある制御層の分離 — を実証する。これは安全隣接のエッジ AI に必要なアーキテクチャ上の規律の移転可能な証拠であり、安全認証ではない。
Hyperion の physical-ai-deployment サービスは、エッジ AI アーキテクチャ、組込み推論ツールチェーンの選定、AI 推論と OT/組込み制御システムとの統合層をカバーする。当社の役割は AI とエッジのアーキテクチャ層である。ML コンポーネントが安全アーキテクチャのどこに収まるか、安全監視とフォールバック経路をどう構成するか、どのツールチェーンがハードウェアに適切かについて助言する。当社は認証機関ではなく、ASIL/SIL 認証を発行しない — その作業には公認機関を要する。
arXiv に公開されたプレプリントは、物理インフラ向けの自律的なエッジ展開型 AI エージェントを扱う。これは学術隣接の成果 — 査読付き学術誌の出版ではなくプレプリント — であるが、Hyperion が物理システムにおけるエッジ AI 展開に適用するアーキテクチャ上の深さを反映している。
Mohammed Cherifi はフランス政府の Osez l'IA プログラムから AI アンバサダーの資格を保持し、FranceNum によって認められている。これは、AI 政策および規制された産業・自動車環境に AI を展開する際の規制上の課題への関与を反映している。
単独の安全機能としてはできません — 現在の方法論およびほとんどの認証機関の受容方針では不可能です。標準的なアプローチは、ML コンポーネントをより低い ASIL/SIL レベル（例：ASIL B または QM）で展開し、より高いレベルに認証された決定論的な安全監視が ASIL 分解を通じてその差を補うことです。そうすればシステム全体は ASIL D を満たせますが、ML コンポーネント自体はその指定を持ちません。この立場は現行の ISO 26262-6:2018 のガイダンスおよび IEC TR 63069:2019 を反映しており、標準化団体が ML 固有のガイダンス（ISO/TR 4804、ISO 8800）を整備するにつれて進化します。
SOTIF（Safety of the Intended Function）は ISO 21448:2022 として公開され、システムの故障からではなく意図した機能そのものの限界から生じるハザード — 知覚のギャップ、予期せぬ環境条件、ODD 境界での振る舞い — を扱います。ISO 26262 は仕様に対するシステムの故障をカバーします。SOTIF は仕様そのものの不備をカバーします。ADAS や自律機能については両規格が適用されます：システムが安全に故障すること（ISO 26262）と、その意図した振る舞いが ODD 全体にわたって安全であること（SOTIF/ISO 21448）の両方を実証する必要があります。
安全監視とは、ML コンポーネントと並行して動作する、独立して検証された決定論的なソフトウェアまたはハードウェアのコンポーネントです。ML の出力を一連の形式的な安全制約 — 物理限界、変化率の境界、センサデータとの整合性 — に照らして検査し、これらの制約に違反するいかなる出力もブロックまたはオーバーライドします。安全監視は ML モデルとは独立に、要求される ASIL/SIL レベルに認証されます。この分離は、安全クリティカルなシステムに ML を展開するための鍵となるアーキテクチャパターンです：ML コンポーネントは助言的であり、監視が権威を持ちます。
ODD は、ML システムが有効となる特定の条件を定義します：環境パラメータ（温度、照明、天候）、入力データの特性（センサ範囲、データ形式、信号品質）、車両または機械の動作状態、地理的または用途固有の制約です。ODD の外にあるいかなる入力も ML コンポーネントによって処理されるべきではありません — システムはフォールバック状態へ移行しなければなりません。ODD 境界の定義・検証・監視は、安全クリティカルな ML 展開において最も重要なエンジニアリング作業の一つです。
IEC 62443 は産業サイバーセキュリティのためのゾーンとコンジットのモデルを定義します。AI 推論サーバーは、あらゆる IT 資産と同様に正しいゾーン（通常はゾーン 3 — 監視）に配置されなければならず、ゾーン 2（制御）とのすべての通信は、定義されたセキュリティ制御 — 認証、暗号化、メッセージ完全性の検証 — を備えたコンジットを通過しなければなりません。コンジット制御なしに PLC やフィールド機器と直接通信する AI 推論サーバーを展開することはゾーンモデルに違反します。AI サーバー自体は、パッチ管理、認証、監査ログを含め、そのゾーンのセキュリティレベル（SL）要件を満たさなければなりません。
受け入れられる構成の単一のリストはありません — 対象とする ASIL/SIL レベル、認証機関、具体的なユースケースによります。一般的には：NVIDIA Drive/Jetson プラットフォーム上の TensorRT 最適化モデルは、ランタイムアシュアランス監視とともに ASIL B までの ADAS プログラムで広く使われています。ARM SoC 上の ONNX Runtime は SIL 1–2 の産業用途で使われます。より高い完全性レベルでは、推論ランタイム自体の正式な適格性確認（ISO 26262-8 に基づくツール適格性確認）が必要になることがあります。Hyperion はツールチェーンの選定と適格性確認戦略について助言します — 正式な適格性確認作業にはツールチェーンベンダーの関与を要します。
いいえ。Hyperion は AI とエッジのアーキテクチャのコンサルタンシーです。ML コンポーネントが安全アーキテクチャのどこに収まるか、安全監視とフォールバック経路をどう構成するか、制約のあるハードウェアにどのエッジツールチェーンが適切か、機能安全および IEC 62443 の要件と整合する展開をどう設計するかについて助言します。実際の ASIL/SIL 認証評価 — 証明書を生み出す適合性評価作業 — は、認定された第三者評価者または公認機関によって実施されなければなりません。Hyperion はその評価への準備を支援し、それを実行可能にするようアーキテクチャを設計できますが、認証は発行しません。
機能安全（ISO 26262、IEC 61508）はこう問います：システムは安全に故障するか。ハードウェアおよびソフトウェアの故障モード、フォールトトレランス、コンポーネント故障時の安全機能の完全性に焦点を当てます。IEC 62443 はこう問います：システムは意図的な攻撃から保護されているか。サイバーセキュリティ制御 — 認証、暗号化、ネットワークセグメンテーション、脆弱性管理 — に焦点を当てます。産業用 AI システムには両方が必要です：システムは機能的に安全（優雅に故障する）でありながらサイバーセキュリティ上は脆弱（攻撃され故障させられうる）でありえます。AI システムに特有なのは、敵対的攻撃が重なり合う点であることです — 意図的に敵対的な入力は、機能安全評価だけでは表面化しない安全でない ML の振る舞いを引き起こしうるのです。
ISO 26262:2018 (2018). "Road vehicles — Functional safety (Parts 1–12)."
文脈： 自動車の主要な機能安全規格。Part 6 は ASIL 固有の構造カバレッジ指標を含むソフトウェア開発要件をカバーする。Part 10 は AI/ML コンポーネントに関するガイダンスを含む（公開時点では非規範的、以後の版で進化）。
ISO 21448:2022 (2022). "Road vehicles — Safety of the intended functionality (SOTIF)."
文脈： ADAS および自動運転システムにおけるセンサの限界や ODD 境界の振る舞いを含め、意図した機能の仕様または性能の機能的不十分性から生じるハザードを扱う。
ISO/TR 4804:2020 (2020). "Road vehicles — Safety and cybersecurity for automated driving systems — Design, verification and validation."
文脈： 自動運転のための機能安全とサイバーセキュリティ分析の結合に関するガイダンスを提供する技術報告書。SOTIF、ISO 26262、SAE J3061 への相互参照をカバーする。
IEC 61508:2010 (2010). "Functional safety of electrical/electronic/programmable electronic safety-related systems (Parts 1–7)."
文脈： E/E/PE 系の機能安全のための汎用国際規格。SIL 1–4、要求時失敗確率（PFD）、ソフトウェア開発・検証の要件を定義する。
IEC 62443 Series (2018–2024). "Industrial automation and control systems — Security."
文脈： 運用技術のサイバーセキュリティをカバーする複数部構成の規格。IEC 62443-3-3 はセキュリティレベル（SL）とゾーン/コンジットモデルを定義する。IEC 62443-4-2 は OT ネットワークの AI 推論サーバーに適用されるコンポーネントセキュリティ要件をカバーする。
IEC TR 63069:2019 (2019). "Industrial-process measurement, control and automation — Framework for functional safety and security."
文脈： 機能安全（IEC 61508）とサイバーセキュリティ（IEC 62443）の関係を扱う技術報告書。両領域にまたがる AI 展開に直接関係する。
UL 4600:2020 (2020). "Standard for Safety for the Evaluation of Autonomous Products."
文脈： ML ベースの自律システムを具体的に扱う初の包括的規格。安全ケースの構築、ODD の定義、運用監視、ML コンポーネントのランタイムアシュアランスをカバーする。北米の自動車プログラムで広く参照される。
ISO/IEC TR 24029-2:2023 (2023). "Artificial Intelligence — Assessment of the robustness of neural networks — Part 2: Methodology for use in formal methods."
文脈： 敵対的ロバストネスを含む、ニューラルネットワークのロバストネス試験方法論に関するガイダンスを提供する — 機能安全と IEC 62443 サイバーセキュリティ分析の双方に関係する。
創業者 兼 AI 戦略リード
Mohammed Cherifi は Hyperion Consulting の創業者であり、自動車・組込みシステムエンジニアリングで17年以上の経験を持つ。Renault-Nissan-Mitsubishi Alliance、Cisco、ABB — 機能安全プロセスがソフトウェア開発を統制する環境 — で勤務してきた。自動車および産業用 OT 環境における安全隣接の展開を含め、物理システムのためのエッジ AI アーキテクチャを専門とする。