AI PC・NPUの調達判断

AI PCやNPUの調達は、公称演算性能や「AI対応」という表示だけでは判断できません。対象アプリケーション、モデル、精度形式、入力長、同時実行、OS、runtime、ドライバ、実行プロバイダの組を固定し、実際の処理先、品質、応答時間、消費電力、メモリ、保守条件を確認して選びます。NPUが搭載されていること、利用可能であること、選択したこと、対象処理がNPUで実行されたことは異なります。

ONNX Runtimeは、Execution Provider（EP）のGetCapabilityを用いて、対応するnodeやsubgraphを実行先へ割り当てると説明しています[S1]。したがって一つの推論に複数の処理先が関与し得ます。モデルが読み込めたことやEPを登録したことだけで、全graphがNPU上にあるとは断定できません。

Windows MLは、deviceを列挙してEPを明示的に選択する方法と、方針による自動選択を区別しています。EPやドライバ更新によって利用可能deviceの一覧が変化し得ることも明記しています。資料のMAX_EFFICIENCY例はNPUを選べる場合に選び、CPU fallbackを含むと説明しています[S2]。自動選択の方針名をNPU限定の実行証明として扱わず、対象sessionの割当と実行を調べます。

AMD Ryzen AI Softwareの資料は、NPUの種類とVitisAI EP・ドライバ互換性を確認する条件を示し、EPやNPUドライバの版をまたいだcache directory再利用を避けるよう説明しています[S3][S4]。これはAMDの当該製品系列の仕様であり、すべてのベンダーが同じ互換表やcache規則を持つという意味ではありません。

以下は調達のために提案する受入項目です。ベンダー間の測定値や順位ではありません。

同じNPUを搭載した別OEM機種でも、メモリ構成、冷却、電源設定、firmwareなどの条件が異なり得るため、採用する機種と設定で検証します。この点は試験設計上の注意であり、本RUNで特定機種の差を実測したものではありません。

調達要件が単に「ローカルで動く」であれば、CPUを含む構成が許容される場合があります。一方「NPUで実行する」が要件なら、deviceの列挙結果、session構成、graphの割当、runtimeのprofilingを必要な範囲で保存します。NPU使用率が見えただけで、対象モデルの全処理や重要なoperatorがそこで動いたとは限りません。

unsupported operator、入力shape、精度形式、メモリ不足、driver/EP更新によって、compile失敗や別deviceへの移動が起こる範囲を確認します。fallbackを許す場合は、CPU/GPUへ移っても応答・品質・電力・offline条件を満たすかを検証します。クラウドfallbackはさらに別の情報送信境界を持ち、端末内のdevice切替と同一視しません。

モデルを量子化や別形式へ変換する際は、同じモデル名であっても評価対象を別artifactとして管理します。変換後の品質低下を速度向上で隠さず、日本語、長い入力、業務固有の失敗、代表外データも目的に応じて確認します。数値精度が異なるbenchmarkを、同じ品質条件の性能差として並べません。

最初のcompileやdownloadを含むcold startと、cache利用後のwarm startを分けます。短い一回の推論と、会議・文書処理など継続負荷、複数アプリの競合、batteryとAC電源を区別して測定します。平均値だけでは待ち時間のばらつきが隠れるため、利用件数と測定条件を付けて分布を確認します。単位はtokens/s、ms、Whなどを明記し、処理内容が異なる値を直接比較しません。

総費用は端末の差額に加え、モデル配布、EP/driver互換性検証、更新、incident対応、復旧、電力、必要なら外部API費用を含めます。既存PCのCPU/GPU、共用server、クラウドとの比較は同じ業務量・品質・情報管理条件で行います。本項では価格、電力、削減率、投資回収期間を実測していないため、特定端末の採用や費用優位を断定しません。

検証済みのmodel/runtime/EP/driver/OSの組を記録し、小規模配布から更新します。compiled artifactやcacheは互換性のある範囲で再利用し、版変更後の起動・割当・品質を確認します。失敗した更新から戻す手順と、更新を受けられない端末の処理継続条件を用意します。署名、配布元、ライセンス、管理権限、model保存容量も調達判断の一部です。

サポート期限、preview/betaの状態、商用配布の可否、driver提供経路、脆弱性対応は契約時点で再確認します。Windows ML、AMD製品、個別EPのライフサイクルをひとまとめにしません。メーカーが機能を説明していることと、対象組織のfleetで保守できることも別の証拠です。

代表的な失敗は、公称TOPSをアプリの速度へ読み替えること、NPUを選んだつもりでCPUへfallbackすること、変換後品質を評価しないこと、短時間だけのbenchmarkを継続利用へ一般化すること、更新後に不適合cacheを再利用すること、ローカルAIという名称から外部通信がないと推定することです。調達契約には、こうした状態を検出する証拠と不適合時の扱いを含めます。

NPUは効率のよい実行先になり得ますが、すべてのmodel・operator・業務量に最適とは限りません。CPU fallbackは互換性のための有効な仕組みでもあり、存在するだけで製品不良とはいえません。問題は要求した処理先・性能・情報管理の条件を実際に満たすかです。vendorの機能資料は実装条件の根拠ですが、独立したcross-vendor性能比較やfleetでの費用効果の証明ではありません。

対象機種の固定構成で、実業務を代表する非機密データを用いて、品質・cold/warm・継続負荷・同時負荷・電源条件を比較します。EP不在、互換性のないdriver、cache無効化、通信断など、想定するfallback経路も分けて確認します。本RUNでは端末、driver、NPUへアクセスした実測を行っていません。測定値や推奨機種は生成していません。

候補OEM機種、業務modelとlicense、独立したcross-vendor同条件benchmark、実際のgraph割当、熱・電力・memory挙動、fleetでの障害率、更新・support契約、総費用と投資回収条件は未確認です。旧研究に記録された特定CPU世代の仕様値は今回再確認していないため、最新製品比較として掲載していません。

「固定した端末・model・runtime条件で、対象業務の品質・実行先・応答・費用条件を確認した」とします。「NPU搭載ならすべてのAIが高速・安価・非送信になる」とは記述しません。

実行先、fallback、品質、配布・更新権限、support条件、外部送信先を確認できない場合は、組織全体への採用適合を断定しません。デモ成功とfleet受入は分けて扱います。

EA-475-R1-20261012および継続Doc 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewUのEA-475節を継承。2026-10-18に主要一次資料を確認。実装仕様、設計提案、未実測を分離しています。

• [S1] ONNX Runtime Execution Providers、GetCapability / node・subgraph allocation: https://onnxruntime.ai/docs/execution-providers/
• [S2] Microsoft Select execution providers using the ONNX Runtime included in Windows ML、明示選択・動的device一覧・Device Policies: https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/select-execution-providers
• [S3] AMD Ryzen AI Software 1.8.0 Application Development、NPU Utilities / VitisAI EP and NPU Driver Compatibility（latest URLの当日表示）: https://ryzenai.docs.amd.com/en/latest/app_development.html
• [S4] AMD Ryzen AI Software 1.8.0 Model Compilation and Deployment、VitisAI EP Cacheの版互換性: https://ryzenai.docs.amd.com/en/latest/modelrun.html