ターミナルに表示される真っ赤な ExportError の文字。胃がキリキリする瞬間ですよね。
「PyTorchでは問題なく学習できたのに、ONNXにエクスポートしようとした途端に突き返される」
「サポートされていない演算子が含まれているため、モデル構造を変更せざるを得ない」
もしあなたが今、深夜のオフィスや自宅のデスクでこの壁に直面しているなら、まずはお伝えしたいことがあります。それは、あなたの扱っているモデルが、それだけ最先端でユニークな価値を持っている証拠だということです。
AIの研究開発スピードはF1マシンのように速く、新しいレイヤー構造や活性化関数が毎日のように論文で発表されます。一方で、ONNX（Open Neural Network Exchange）の標準仕様策定プロセスは、多くの企業の合意形成が必要なため、どうしても研究のスピードには遅れを取ります。このタイムラグの間に、私たちエンジニアは挟まれて苦しむわけです。
このギャップに直面したとき、多くの現場では「ONNX標準にある演算子だけでモデルを再構築（書き換え）する」という選択がなされがちです。納期は迫っているし、とにかく動くものを作らなければならない。その気持ちは痛いほどわかります。
でも、実務の現場におけるエッジAIプロジェクトの「その後」を考慮すると、その判断はプロジェクトの未来を縛る危険な妥協かもしれません。
「とりあえず動く」ようにするために、本来得られたはずの推論速度を犠牲にし、モデルの表現力を歪めてしまっていませんか？
今回は、エラー回避のための「消極的な修正」ではなく、推論エンジンのポテンシャルを最大限に引き出すための「積極的なカスタム演算子実装」についてお話しします。これは単なるデバッグの話ではありません。AIモデルをビジネスで勝てるプロダクトとして成立させるための、アーキテクチャ設計における重要な意思決定の話です。
なぜあなたのモデルはONNXにならないのか：標準化の壁と「独自性」のジレンマ
まず、私たちが直面している問題の本質を、少し引いた視点から整理してみましょう。なぜ変換エラーが起きるのか。それはツールが未熟だからではなく、あなたのモデルが「標準」の枠に収まりきらない独自性を持っているからです。
変換エラーが示す「モデルの進化」とツールの遅れ
ONNXは、異なるフレームワーク間での相互運用性を高めるための共通規格です。しかし、共通規格である以上、そこには「最大公約数的な合意」が必要です。例えば、最新の自然言語処理モデルで提案されたばかりの特殊なAttentionメカニズムや、自律走行車向けのLiDAR点群処理で使われるドメイン特化型の非線形処理などは、当然ながら標準Opset（演算子セット）には含まれていません。
公式情報によると、最新のONNX Runtimeではメモリ管理機能の拡張（OrtMemoryInfoDeviceTypeによる詳細な制御など）や、デバイス間でのテンソル処理の効率化が進められています。しかし、こうしたランタイム側の進化をもってしても、日進月歩で生み出される新しいモデルアーキテクチャのすべてを即座に標準化することは不可能です。
変換時に ExportError: ... is not supported というメッセージが出たとき、それを「障害」と捉えるか、「差別化のチャンス」と捉えるかで、その後のエンジニアリングの質が大きく変わります。エラーが出るということは、競合他社が容易に真似できない（標準ツールだけでポータブルに扱えない）高度な処理を含んでいる可能性があるからです。
回避策としての「標準Opsへの書き換え」が招く見えないコスト
このエラーに直面した際、最も安易な解決策として採用されるのが、「標準演算子の組み合わせ（Composite Ops）」による書き換えです。
例えば、特殊な活性化関数や複雑な前処理ロジックを、Relu、Add、Mul といった基本的な行列演算のパッチワークで再現しようとするアプローチです。論理的には正しい結果が得られますし、テストもパスするでしょう。しかし、ここには大きな落とし穴があります。
計算グラフの肥大化と、それに伴うオーバーヘッドです。
1つのカスタム演算子を数十個の基本演算子に分解すると、ONNX Runtimeなどの推論エンジンは、その一つひとつに対してカーネルを起動し、メモリの読み書きを行います。これを「カーネルローンチのオーバーヘッド」と呼びます。GPUのような並列演算装置は、大量の単純計算を一気に処理するのは得意ですが、細切れの小さな処理を何度も呼び出すのは苦手です。
結果として、「論理的には同じ計算」をしているはずなのに、推論速度が大幅に低下するという現象が起きます。これはエッジデバイスのようなリソース制約のある環境では致命的です。綺麗な舗装道路（最適化されたカスタムOp）があるのに、わざわざ砂利道（基本Opsの集合）を通って目的地へ向かうようなものです。
デプロイ容易性とモデル性能のトレードオフを再考する
「標準Opsだけで構成されたモデルはデプロイが楽で、将来にわたって安定している」という考え方は、必ずしも正しくありません。
実際、プラットフォーム側の変更により、標準とされていた機能が利用できなくなるケースも報告されています。例えば、AMD GPU向けの環境（ROCm）において、最新バージョンでは従来のROCMExecutionProviderが廃止され、ONNXモデルを実行するためには特定の古いバージョン（ROCm 6系など）への固定が必要になるといった事例があります。標準機能に依存していても、インフラ側の都合で互換性の問題に直面することは避けられません。
また、最新のデータベース製品（Fujitsu Enterprise Postgresなど）ではONNXモデルを直接取り込んでベクトル変換を行う機能が登場するなど、活用の幅は広がっています。しかし、ビジネス要件として「ミリ秒単位の応答速度」が求められているなら、デプロイの手間を惜しんで性能を下げるのは本末転倒です。
カスタム演算子を実装することは、確かに実装コスト（技術的負債になり得る複雑性）を伴いますが、それを上回るパフォーマンスという「資産」を生み出すための投資なのです。私たちは「動くものを作る」だけでなく、「価値を生むものを作る」責任があります。そのために、時には標準のレールから外れる勇気が必要です。
ブラックボックスを開ける：ONNX Runtime拡張メカニズムの解剖学
「カスタム演算子を書く」というと、何か魔術的なハックが必要だと感じるかもしれません。カーネルのコードをバイナリエディタでいじるような……。いえいえ、安心してください。ONNX Runtimeは当初から拡張性を考慮して設計されています。ここでは、具体的なコードを書く前に、その仕組み（Why/What）を理解しましょう。仕組みがわかれば、恐れることはありません。
Custom Opは魔法ではない：登録と実行のライフサイクル
ONNX Runtimeにおいて、カスタム演算子は「外部から注入されるプラグイン」のようなものです。推論セッション（InferenceSession）を立ち上げる際、標準の演算子レジストリとは別に、カスタム演算子のレジストリを追加で登録します。
モデルファイル（.onnx）の中には、「このノードは MyCustomOp という名前で、ドメインは com.mycompany です」という情報だけが記録されています。言ってみれば、レストランの注文票に「シェフの気まぐれサラダ」と書いてあるようなものです。
ONNX Runtimeがグラフを読み込む際、この名前とドメインに一致する実装がレジストリ内に存在すれば、それを実行可能なカーネルとしてリンクします。もしレシピ（実装）が登録されていなければ、「作り方がわかりません」とエラーを吐くわけです。
つまり、モデルファイル自体は「設計図」に過ぎず、それを実行する「職人（カーネル実装）」をランタイム時に引き合わせるのが拡張の基本メカニズムです。この分離こそが、ポータビリティと拡張性を両立させる鍵なのです。
スキーマ定義とカーネル実装の分離が生む柔軟性
重要なのは、「どんな入力を受け取り、どんな出力を返すか（スキーマ）」と、「具体的にどう計算するか（カーネル）」が分離されている点です。
- スキーマ定義: ONNX形式として保存するために必要。入力テンソルの型や形状推論（Shape Inference）のロジックを定義します。「入力が[3, 224, 224]なら、出力は[1, 1000]になるはずだ」というルールです。
- カーネル実装: 実際にハードウェア上で計算を行うコード。基本はC++で記述しますが、GPUパフォーマンスを最大限に引き出すためにCUDAカーネルを直接実装することも一般的です。
この分離構造により、「モデル定義（スキーマ）はそのままに、バックエンドの実装（カーネル）だけを最新の環境に合わせて差し替える」といった運用が可能になります。
例えば、CUDAなどのGPUライブラリは頻繁にアップデートされ、バージョン間の互換性に注意が必要です。しかし、カーネル実装が分離されているため、最新のCUDA Toolkitの機能を使いたい場合でも、モデル全体を作り直す必要はなく、該当するカーネルコードを更新して再ビルドするだけで対応できます。これは、長期的な運用において非常に大きなメリットとなります。
推論エンジンが「未知の演算」を理解する仕組み
標準外の演算子を含むONNXモデルをNetronなどの可視化ツールで開くと、しばしば未知のノードとして表示されたり、赤い警告マークがついたりします。これは、可視化ツールがその演算子の「意味」を知らないからです。
しかし、ONNX Runtimeにとっては「意味」を知る必要はありません。「入力AとBを受け取って、登録された関数Fを実行し、出力Cを生成する」という手続きさえ明確なら実行できます。この「手続き的な割り切り」こそが、ONNX Runtimeの高い拡張性を支えています。
私たちはこの仕組みを利用して、ブラックボックス化された独自のアルゴリズムを、推論グラフの一部として安全に組み込むことができるのです。それはまるで、既製品のブロック玩具の中に、3Dプリンタで作った特注パーツを組み込むような自由さを私たちに与えてくれます。
実装アプローチの戦略的選択：Pythonで逃げるか、C++で攻めるか
さて、仕組みがわかったところで実装の話に移りましょう。カスタム演算子を実装する方法は一つではありません。大きく分けて「Pythonによる簡易実装」と「C++によるネイティブ実装」があります。これは単なる言語の好みではなく、プロジェクトのフェーズや要求性能に関わる戦略的な選択です。
Python Op：プロトタイピングと速度の狭間で
ONNX Runtimeのエコシステムでは、onnxruntime-extensionsなどを活用することで、Python関数をカスタム演算子としてバインディングする手法が存在します。
- メリット: 実装が比較的容易。PyTorchのロジックを流用しやすい。コンパイルの手間を最小限に抑えられる。
- デメリット: GIL（Global Interpreter Lock）の制約を受ける。また、推論環境にPythonランタイムが必須となるため、エッジデバイスへのデプロイには不向き。
推論実行中、データはいったんC++のランタイム領域からPythonインタプリタ領域へコピーされ、Pythonコードが実行され、またC++領域へ戻されます。このコンテキストスイッチとデータ転送のコストは無視できません。
「とりあえず動くものを早く作りたい」「推論速度はそこまでシビアではない（数秒かかっても良いバッチ処理など）」というケースでは、Pythonによるカスタム実装は有効な選択肢です。特にPoC（概念実証）段階では、C++の実装に時間をかけるよりも、まずはモデル全体の動作確認を優先すべき場面も多いでしょう。ただし、PyTorchのNightly版などで導入される最新機能を使用している場合、ONNX側の対応状況との互換性には注意が必要です。
C++ Custom Op：極限のパフォーマンスを引き出す本道
一方、C++でカスタム演算子を実装し、共有ライブラリ（.so / .dll）としてビルドする方法が、エッジAIにおける「本道」です。
- メリット: ネイティブレベルの速度。GILの影響を受けない。メモリ管理を細かく制御できる。最新のハードウェアアクセラレーション（FP8演算など）の恩恵を受けやすい。
- デメリット: 実装難易度が高い。ビルド環境の構築が必要。デバッグが難しい。
実際の開発現場では、PoC段階ではPython実装でロジックを検証し、量産フェーズに向けてC++実装へ書き換えるというプロセスが推奨されます。特に画像処理の前処理や後処理（NMSなど）をモデル内に含める場合、ここをC++化することで全体の処理時間を大幅に短縮できるケースが報告されています。
これは「逃げ」ではなく「戦略的撤退」からの「反転攻勢」です。最初はPythonで素早く作り、ボトルネックが確定したらC++で徹底的に叩く。このメリハリが重要です。
Contrib Opsへの寄与：OSSエコシステムを活用する第三の道
もしあなたが実装しようとしている演算子が、汎用性の高いものであれば、onnxruntime-extensions などのOSSプロジェクトにコントリビュート（寄与）するという選択肢もあります。
自社専用の実装をメンテナンスし続けるのはコストがかかります。ONNX Runtimeのバージョンが上がるたびにビルドし直すのは骨が折れる作業です。コミュニティ標準の一部に組み込んでもらえれば、メンテナンスの負荷は下がり、世界中の開発者の知見も得られます。
これは「技術的な情けは人のためならず」の精神です。戦略的にOSSを活用することも、アーキテクトの重要な資質です。自分のコードが世界中の推論エンジンで使われるかもしれないなんて、ちょっとワクワクしませんか？
「動けばいい」を超えて：持続可能なカスタム実装のための品質管理
カスタム演算子を導入すると、標準モデルに比べて「壊れやすく」なります。環境が変わると動かなくなったり、ランタイムの更新で挙動が変わったりするリスクがあるからです。ここで重要になるのがMLOps視点での品質管理です。「動いた！」でシャンパンを開けるのはまだ早いです。
バージョニング地獄を回避する互換性設計
ONNXには Opset Version という概念があり、標準演算子の仕様はバージョンごとに厳格に管理されています。カスタム演算子も同様にバージョニングすべきです。
モデルファイルには「このモデルはCustomOpのバージョン1.2を使用する」といった情報をメタデータとして埋め込んでおきましょう。そして、ランタイム側では後方互換性を意識した実装を行います。これを怠ると、「半年前のモデルが今の推論エンジンで動かない」という事態に陥ります。デプロイ当日にこの問題が発覚したときの絶望感といったら……想像するだけで胃が痛くなりますね。
異なるハードウェアバックエンド（CPU/CUDA/TensorRT）への対応戦略
ここが最も悩ましいポイントです。ONNX Runtimeは、CPUだけでなくCUDA（NVIDIA GPU）やTensorRTなどのExecution Provider（EP）を利用できます。
しかし、あなたがC++で書いたカスタム演算子は、通常CPUでしか動きません。GPUで高速化したい場合、CUDAカーネルも別途実装し、CUDAExecutionProvider に登録する必要があります。
さらに、TensorRTを使いたい場合は、ONNX RuntimeのカスタムOpとは別に、TensorRT独自のプラグイン機構（Plugin API）に準拠した実装が必要になるケースが大半です。「ONNXでカスタムOpを作ったから、TensorRTでも自動的に速くなる」わけではないのです。
TensorRTのプラグイン実装に関するインターフェースや推奨ワークフローは、バージョンによって変化する可能性があります。最新の実装要件については、必ずNVIDIAの公式開発者ドキュメントで確認してください。
このハードウェアごとの実装コストをどこまで許容するか。プロジェクトの予算と要求性能を天秤にかけ、アーキテクトが冷静に判断すべきポイントです。「CPU版だけで十分速い」という結論もあり得ますし、「いや、ここはコストをかけてでもCUDA化、あるいはTensorRTプラグインを実装すべきだ」という判断もあるでしょう。
カスタムOpを含むモデルのCI/CDパイプライン構築
カスタム演算子を含むモデルは、標準的なバリデータ（onnx.checker）だけでは検証しきれません。
CI/CDパイプラインの中に、以下のテストを組み込むことを強く推奨します。
- 数値的一致テスト: PyTorch等の学習フレームワークでの出力と、カスタムOpを含むONNXモデルの出力が、許容誤差（例えば1e-5）以内で一致するか。
- 形状推論テスト: 入力サイズを変えたときに（Dynamic Axes）、正しく出力サイズが計算されるか。
- 負荷テスト: メモリリークがないか、長時間稼働させて確認する。
「動いた！」で終わらせず、継続的に「動き続ける」状態を担保するのがプロの仕事です。特にカスタム実装部分はブラックボックスになりがちなので、自動テストという「監視カメラ」を設置しておくことが、安定運用の鍵となります。
結論：標準に縛られない「自由なモデリング」を取り戻す
ONNXへの変換エラーは、決して行き止まりではありません。それは、既存の枠組みを超えようとしているあなたのプロジェクトに対する「挑戦状」であり、エンジニアとしての真価が問われる瞬間です。
標準演算子への妥協的な書き換えでモデルの性能を殺してしまうのは、あまりにも勿体ないことです。カスタム演算子という武器を持てば、最新の研究成果も、独自のアイデアも、性能を落とすことなく本番環境へデプロイできます。
ツールに使われるな、ツールを拡張せよ
私たちエンジニアは、便利なツール（ONNXやPyTorch）を与えられると、無意識のうちにそのツールの制約の中で思考しがちです。「ONNXで変換できないから、このレイヤー構造は諦めよう」というのは、ツールに主導権を奪われている状態です。
本来あるべき姿は逆です。「このレイヤー構造がビジネスに必要だから、ONNXを拡張して対応しよう」。このマインドセットこそが、その他大勢のエンジニアと、真に価値を生み出すアーキテクトを分ける境界線です。
実際、ONNX Runtimeの最新動向を見ると、メモリ管理APIの拡張やデバイス情報の詳細な制御が可能になるなど、より「プログラマブル」な方向へ進化しています。また、エンタープライズ向けデータベース製品でもONNXモデルの直接取り込みやベクトル変換が可能になるなど、ONNXのエコシステムは推論エンジンを超えてインフラ全体へと拡大しています。この巨大なエコシステムの恩恵を受けつつ、独自の強みを維持するためには、標準規格を「使いこなし、拡張する」技術力が不可欠です。
AIエンジニアに求められる「低レイヤー」への理解
カスタム演算子の実装は、確かにC++や低レイヤーの知識を必要とするタフな領域です。ROCm環境におけるExecutionProviderの仕様変更など、ハードウェア周りの環境は常に変化しており、抽象化されたPythonライブラリだけに頼っていると、こうした基盤の変化に対応できなくなるリスクもあります。
泥臭いデバッグも必要になるでしょう。しかし、そこを乗り越えた先には、競合他社が真似できない、圧倒的に高速で高精度なAIプロダクトが待っています。
ぜひ、恐れずに「黒魔術」とも呼ばれるこの領域に踏み込んでみてください。その先にある自由なモデリングの世界は、苦労に見合うだけの価値があります。
コメント