ONNX Runtime

ONNX Runtimeとは

ONNX Runtime（通称ORT）は、Microsoftが開発・メンテナンスするオープンソースのクロスプラットフォーム推論エンジンです。ONNX（Open Neural Network Exchange）という共通フォーマットで表現されたAIモデルを読み込み、Windows、Linux、macOS、iOS、Android上のCPU・GPU・NPUなど多様なハードウェアで実行します。2018年にMicrosoftがGitHubでOSS公開し、現在はLinux Foundation AI & Data配下のプロジェクトとして開発が続いています。

PyTorchやTensorFlowは「モデルを学習させる」ためのフレームワークですが、ONNX Runtimeは学習済みモデルを本番環境や端末上で「効率よく動かす（推論する）」ことに特化したランタイムである点が最大の違いです。Copilot+ PCにおいては、Windows標準のDirectMLを経由してNPUに処理を橋渡しする中核コンポーネントとして採用されており、Windows自体のAI機能（RecallやWindows Studio Effectsなど）の裏側でも使われています。

仕組み（アーキテクチャ）

ONNX Runtimeの処理は大きく2段階に分かれます。

1. グラフ最適化（コンパイル前処理）

ONNXモデルは「ノード（演算子）」と「エッジ（テンソルの流れ）」からなる計算グラフです。ONNX RuntimeはInferenceSessionの生成時にこのグラフを解析し、定数畳み込み（Constant Folding）、不要ノードの除去、Conv+BatchNorm+ReLUのような複数演算の融合（Operator Fusion）などを自動で行い、実行前にグラフそのものを軽量化します。最適化レベルはORT_DISABLE_ALL／ORT_ENABLE_BASIC／ORT_ENABLE_EXTENDED／ORT_ENABLE_ALLの4段階から選択できます。

2. Execution Provider（EP）によるハードウェア割り当て

最適化されたグラフの各ノードは、Execution Provider（EP）と呼ばれる抽象化層を通じて実際のハードウェアに割り当てられます。EPはCUDA、TensorRT、DirectML、OpenVINO、CoreML、CPUなどベンダーごとに用意されており、providers引数に優先順位付きで並べておくと、ONNX Runtimeは先頭のEPが対応していない演算子だけを次のEPへ自動的にフォールバックさせます。この「対応していないところだけ後段に回す」仕組みにより、モデル全体を書き換えなくても新しいハードウェアに段階的に対応できるのがONNX Runtimeの設計上の強みです。

Execution Provider	主な対象	備考
CPUExecutionProvider	すべてのCPU	標準搭載。他EPが未対応の演算子はここに自動フォールバック
DmlExecutionProvider	Windows GPU/NPU（Intel/AMD/Qualcomm横断）	Copilot+ PCでNPUを使う際の主経路
CUDAExecutionProvider / TensorrtExecutionProvider	NVIDIA GPU	Linux/データセンター向け。AI PCのNPUとは対象が異なる
OpenVINOExecutionProvider	Intel CPU/GPU/NPU	Intel環境で追加最適化したい場合の選択肢
CoreMLExecutionProvider	Apple Silicon（Neural Engine）	macOS/iOSでの推論に使用
QNNExecutionProvider	Hexagon NPU（Snapdragon）	Qualcomm SDK（QNN）を直接呼び出すEP。DirectML経由より低レイヤ

主な特徴

1. クロスプラットフォーム

• Windows：DirectML経由でGPU/NPU対応
• Linux：CUDA、TensorRT、OpenVINO対応
• macOS：Core ML対応（Apple Neural Engineを活用）
• モバイル：iOS、Android対応（NNAPI経由でスマホのAIチップも利用可）
• ブラウザ：ONNX Runtime Web（WebAssembly／WebGPU／WebNN）でJavaScriptからも実行可能

2. 幅広いハードウェア対応

• CPU：Intel、AMD、ARM（x64／ARM64双方に対応）
• GPU：NVIDIA（CUDA）、AMD、Intel
• NPU：Intel AI Boost、AMD XDNA、Hexagon NPU（いずれもDirectMLまたは専用EP経由）

3. フレームワーク互換性

以下のフレームワークで学習したモデルをONNX形式に変換して実行します。

• PyTorch：torch.onnx.export、または新しいtorch.onnx.dynamo_exportで変換
• TensorFlow：tf2onnxで変換
• Scikit-learn：sklearn-onnxで変換
• Hugging Face Transformers：optimumライブラリのONNX対応機能で変換

4. 言語バインディングの豊富さ

推論部分はC++で実装されており、Python、C#、C/C++、Java、Node.js（JavaScript）向けの公式APIが用意されています。学習はPythonでPyTorchやTensorFlowを使い、推論だけはC#やC++のアプリに組み込む、という「学習と実行環境を分離する」使い方がしやすいのも実務上のメリットです。

Copilot+ PCでの活用（具体例）

DirectMLとの統合

ONNX RuntimeはDirectMLをExecution Providerとしてサポートしており、以下が可能になります。

• 自動NPU活用：ExecutionProviderに'DmlExecutionProvider'を指定するだけで、ドライバが対応するNPU/GPUに処理を委譲
• ベンダー横断：同じコードでIntel・AMD・Qualcommいずれのハードウェアでも動作（DirectMLがベンダー差を吸収）
• ハイブリッド実行：EPが対応しない演算子だけ自動的にCPUへフォールバック

使用例（基本形）

import onnxruntime as ort

# DirectML（NPU/GPU）を優先し、非対応演算子はCPUへフォールバック
providers = ['DmlExecutionProvider', 'CPUExecutionProvider']
session = ort.InferenceSession('model.onnx', providers=providers)

# 推論実行
outputs = session.run(None, {'input': input_data})

# 実際にどのEPが有効化されたかを確認（想定通りNPU/GPUが使われているかの検証に必須）
print(session.get_providers())

量子化モデルの実行例

NPUは一般にINT8／INT4のような低精度整数演算を得意とするため、Copilot+ PCでの実運用ではFP32モデルをそのまま使わず、量子化してからNPUに載せるのが定石です。ONNX Runtimeには量子化ツール（onnxruntime.quantization）が付属しています。

from onnxruntime.quantization import quantize_dynamic, QuantType

# FP32モデルをINT8に動的量子化（NPU/CPUでの実行を軽量化）
quantize_dynamic(
    model_input='model.onnx',
    model_output='model_int8.onnx',
    weight_type=QuantType.QInt8
)

生成AI（LLM／SLM）用途では、通常のonnxruntimeに加えてONNX Runtime GenAI（onnxruntime-genai）パッケージを使います。これはKVキャッシュ管理やトークン生成ループ、サンプリング処理までを一括で扱う拡張で、Phiのような小型言語モデル（SLM）をCopilot+ PCのNPU上で動かす際の標準的な選択肢になっています。

メリット・デメリット

メリット

• ハードウェア非依存：一度ONNXに変換すれば、CPU/GPU/NPU、Windows/Linux/macOSを問わず同じモデル資産を使い回せる
• ベンダーロックインの回避：Intel・AMD・Qualcommのどれを積んだPCでも同じコードで動くため、特定チップ専用SDKに縛られない
• 成熟した最適化基盤：グラフ最適化・演算子融合・量子化ツールが標準搭載で、自前実装なしに高速化できる
• 本番実績：Microsoft自身がWindows、Office、Bing、Azure Cognitive Servicesなど大規模プロダクトで採用しており、枯れた実行基盤として信頼性が高い
• ライセンスが軽い：MIT Licenseで商用利用の制約が少ない

デメリット・注意点

• 変換工程が挟まる：PyTorch/TensorFlowのモデルをONNXへexportする際、動的な制御フローやカスタム演算子が正しく変換されず、手作業での調整が必要になることがある
• EPごとの対応状況にばらつき：新しい演算子や最新モデルアーキテクチャは、CPU EPでは動いてもDirectML/NPU向けEPではまだ未対応で、気づかないままCPUに静かにフォールバックし「NPUを使っているつもりが速くなっていない」状態が起こり得る
• デバッグのしづらさ：推論がEPという抽象化層を経由するため、PyTorchのように途中のテンソル値を素直に覗きにくく、性能問題の切り分けにはプロファイラ（onnxruntimeのプロファイリング機能や各社のパフォーマンスツール）が必要になる
• 最先端モデルへの追随に時間差がある：登場したばかりの生成AIモデルは、まずPyTorch実装が公開され、ONNX変換・NPU最適化はそれに数週間〜数ヶ月遅れることが多い
• ベンダー専用SDKとの性能差：同一ハードウェアに限れば、Qualcomm QNNやNVIDIA TensorRTのようなベンダー純正SDKを直接使う方がチューニングの余地が大きく、ピーク性能で上回ることがある（その代わり移植性を失う）

混同されやすい用語・類似技術との違い

「ONNX」と「ONNX Runtime」、あるいは「DirectML」「OpenVINO」「TensorRT」などは名前が似ていたり同じ文脈で登場するため混同されがちです。それぞれの役割を整理します。

名称	分類	役割・位置づけ
ONNX	フォーマット／仕様	モデルの構造を記述する共通ファイル形式。それ自体は「実行エンジン」ではない
ONNX Runtime	推論エンジン	ONNXファイルを読み込み、最適化してハードウェア上で実行するソフトウェア本体
PyTorch / TensorFlow	学習フレームワーク	モデルを学習・設計するためのツール。推論専用に絞って最適化されたものではない
DirectML	低レベルAPI	Windows上でGPU/NPUの計算命令を呼び出すAPI。ONNX Runtimeが内部で利用する部品の一つで、単体ではモデルファイルを扱わない
OpenVINO	ベンダー製推論エンジン	Intel製の推論エンジン。ONNX Runtimeとは独立に単体でも使えるし、ONNX RuntimeのEPとして組み込むこともできる
TensorRT	ベンダー製推論エンジン	NVIDIA GPU専用の高速推論エンジン。AI PCのNPUではなくGPU/データセンター向け
Qualcomm QNN / SNPE	ベンダー製SDK	Hexagon NPUを直接叩くQualcomm純正SDK。ONNX RuntimeのQNN EPからも、単体からも利用可能
ONNX Runtime GenAI	拡張パッケージ	ONNX Runtime本体に、LLM/SLM向けのトークン生成ループやKVキャッシュ管理を追加した派生パッケージ

要点をまとめると、ONNXは「共通の荷姿（フォーマット）」、ONNX Runtimeは「荷物を運ぶトラック（実行エンジン）」、DirectMLは「トラックが使う道路（低レベルAPI）」、OpenVINOやTensorRTは「特定の道専用の高性能車両（ベンダー製エンジン）」という関係です。

実務での選定・導入ポイント

Copilot+ PCやAI PCを選ぶ、あるいはONNX Runtimeを使ったローカルAIアプリを開発する際に確認すべきポイントを整理します。

端末選定時に見るべき指標

チップ例	NPU	NPU性能目安	ONNX Runtime経路
Qualcomm Snapdragon X Elite/Plus	Hexagon NPU	公表値でおおむね45TOPS程度	DirectML EP、またはQNN EP
Intel Core Ultra（Series 2/Lunar Lake以降）	Intel AI Boost	公表値でおおむね48TOPS程度	DirectML EP、またはOpenVINO EP
AMD Ryzen AI（300シリーズ以降）	AMD XDNA	公表値でおおむね50TOPS程度	DirectML EP、またはRyzen AI Software（Vitis AI）

Microsoftが定義するCopilot+ PCの要件はNPU性能40TOPS以上とされており、上記の主要チップはいずれもこの基準を満たしています。ただし同じ「40TOPS超」でも、実際のアプリ体感速度はEPのドライバ成熟度やメモリ帯域・容量に左右されるため、TOPSの数値だけで単純比較しない方が実務的です。

導入・開発時のチェックリスト

• メモリ容量：CPU・GPU・NPUがメモリを共有するユニファイドメモリ構成が主流のため、複数のSLM/LLMを同時に扱うなら16GBでは不足しがちで32GB以上を推奨
• ドライバ・OSバージョン：DirectMLのNPUサポートはWindowsのバージョンやベンダードライバの更新に依存するため、開発機と同じビルド番号で動作確認する
• 実行EPの検証を怠らない：session.get_providers()や実行時間計測で、想定通りNPU/GPUが使われているか（CPUに静かにフォールバックしていないか）を必ず確認する
• 静的シェイプ優先：NPU向けEPは可変長入力（動的シェイプ）に弱い場合があるため、可能な限り固定シェイプでexportする
• 量子化を前提に設計：INT8/INT4量子化を見込んでモデル選定・精度検証を行う（量子化による精度劣化の許容範囲を事前にテストする）
• ARM64版Windowsでの互換性：Snapdragon X搭載機はネイティブARM64だが、x86専用ライブラリに依存するアプリはPrismによるエミュレーションが必要になる場合がある

2025〜2026年の最新動向

• ONNX Runtime GenAI：LLM/SLMの生成AI処理に特化した拡張パッケージとして機能拡充が続いている
• Phi-4／Phi-3.5系のNPU実行：MicrosoftのSLMがONNX Runtime経由でCopilot+ PCのNPUで動作し、ローカルAIアシスタントの基盤として利用される事例が増加
• WebNN統合：ブラウザ（WebNN API）からもONNX Runtime Webを通じてNPU/GPUアクセラレーションが利用可能になりつつある
• 低ビット量子化の強化：INT4量子化（RTN、GPTQ、AWQ等の手法）への対応が進み、より軽量なモデル実行とNPUでの省電力化が図られている
• Execution Provider追加：Qualcomm QNN EPやベンダー各社のEPの機能改善が継続的に行われ、Copilot+ PC上での対応モデルの幅が広がっている

まとめ

ONNX Runtimeは、ONNXという共通フォーマットのモデルをCPU・GPU・NPU横断で動かすクロスプラットフォーム推論エンジンであり、「モデル資産をハードウェアの都合から切り離す」ための実務的な要となるソフトウェアです。Copilot+ PCではDirectMLと統合され、Intel・AMD・QualcommいずれのNPUでも同じコードでAI処理を実行できます。一方で、モデル変換の手間やEPごとの対応状況の差、静かなCPUフォールバックといった注意点もあるため、導入時は実際に使われているExecution Providerを検証しながら進めることが重要です。2025年以降はONNX Runtime GenAIによるLLM/SLM対応が加速しており、ローカルAI実行の標準的な推論エンジンとしての地位を確立しつつあります。

よくある質問（FAQ）

関連用語

• DirectML - ONNX RuntimeがWindows上でNPU/GPUを利用するための低レベルAPI
• NPU - ONNX Runtimeが活用する専用AIプロセッサ
• 量子化（Quantization） - ONNX Runtimeのモデル軽量化・高速化技術
• OpenVINO - Intelの推論エンジン（ONNX RuntimeのEPとしても単体としても利用可）
• SLM（Small Language Model） - ONNX Runtime GenAIで実行される小型言語モデル
• Copilot+ PC - ONNX Runtime／DirectMLによるNPU活用を前提としたPC規格
• TOPS - NPU性能を示す指標。Copilot+ PCの要件はNPU 40TOPS以上
• ハイブリッドAIアーキテクチャ - CPU/GPU/NPUを使い分ける実行モデル
• オンデバイスAI - ONNX Runtimeが支える端末上でのAI実行の考え方

外部リンク・参考資料

この用語についてもっと詳しく

ONNX Runtimeに関するご質問など、お気軽にお問い合わせください。