航空MRO最適化ソフトウェア, 2025年2月

Last modified: February 2nd, 2025

はじめに

航空整備、修理、およびオーバーホール（MRO）のサプライチェーンは非常に複雑です。航空会社とMROプロバイダーは、膨大なロングテール部品の在庫を、断続的でまばらな需要や高度に変動するリードタイムと価格の中で管理しています。予測不能な故障や修理用のランダムなBOMにより、使用量が警告なしに急増することがあります。部品には厳格なライフサイクル（例：最大サイクル数や飛行時間）や、航空機を地上に留める「使用不可」部品と、使用可能または延期可能なアイテムという重要度分類が設けられていることが多いです。これらの要因により、AOG（航空機地上事故）を回避し、余剰在庫を最小限に抑えるという微妙なバランスの下で、予測と在庫管理の判断を下すことが非常に困難になります。

複数のソフトウェアベンダーが、これらの課題を解決するための専門的な最適化ツールを提供していると主張しています。本調査では、主要な「航空MRO最適化」ソリューションに対して懐疑的な立場から徹底的に分析を行います。各ベンダーの技術について厳しく評価し、彼らが本当に確率論的予測（需要とリードタイムの両方に対して）、経済最適化（在庫管理における費用対効果の最大化）、および数万から数十万の部品番号に対応するための高度な自動化など、最先端の機能を提供しているかどうかを検証します。「AI/ML駆動」の改善効果―たとえば、劇的な在庫削減率やサービスレベルの向上―などのマーケティング主張についても、その中身を精査します。特に、これらの主張の裏付けとなる先進的なエンジニアリング（またはその欠如）や、ツールが面倒なユーザー定義パラメータに頼るのではなく自動分析に基づいているかどうかに注目します。最後に、航空MROの混沌としたIT環境における統合の現実性を考慮し、「プラグ・アンド・プレイ」といった主張にも厳しい目を向けます。

本稿の目的は、技術に精通したMROの経営者に対して、真のイノベーションと流行語を区別しながら、市場で提供されている製品の無駄のない、詳細な概要を提供することです。

ベンダーランキング（概要）

1. Lokad – 航空向けの最先端の確率論的予測と自動化。Lokadは、確率論的な需要・リードタイム予測や微分可能なプログラミングといった、航空分野での長年の研究開発により構築された最先端技術を駆使してリードしています。経済最適化（コスト対サービス）と最小限の手動チューニングを強調しており、真の最先端のMRO在庫計画の先駆けとなっています。

2. PTC Servigistics – 現代的な強化を施した包括的なレガシースイート。Servigisticsは、最も幅広い機能セット（多階層最適化、高度な予測、IoT統合）を提供し、航空宇宙および防衛分野で広く使用されています ¹。内部では「AI/ML」を適用し、複雑なシナリオに対応しますが、いくつかのアルゴリズムは数十年前の開発に遡ります。非常に強力ですが、その複雑さはより多くの設定と専門家によるセットアップへの依存を意味する可能性があります。

3. Syncron – 成長するAI機能を備えたサービス部品の専門家。Syncronのクラウドプラットフォームは、メーカーおよび現在航空宇宙向けのサービス部品計画に特化しています。複雑で断続的な需要パターンに対応するため、AI、機械学習、そして高度なシミュレーションを謳っています ²。確率論的な機能が徐々に現れており、経済的な在庫最適化に注力していますが、航空特有の細かな点に関してはまだ進化の途上にあります（歴史的にはOEMのアフターマーケットで強みを発揮）。

4. ToolsGroup (SO99+) – 実績ある確率論的モデリング、しかし古びた「AI」論調。ToolsGroupは、断続的な需要予測と多階層在庫最適化の先駆者です ³。その確率論的モデルは、スペア部品の「ロングテール」を適切に処理します。しかし、「AI搭載」という主張は誇張されているように見え、技術は主に伝統的な統計手法（2000年以前のモデル）に一部の更新が加えられたものと分析されています ⁴。それでも、大規模な部品計画のための堅実な自動化を実現しています。

5. Armac Systems (RIOsys) – 回転部品及びスペア向けの航空専用最適化ツール。Armac（SR Technics傘下）は、航空会社/MRO在庫に特化したニッチなリーダーです。そのRIOsysツールは、予告なしの（ランダムな）需要や複数拠点ネットワーク下においても、回転部品と消耗品の最適な在庫レベルを算出します ⁵。運用上の知識（例：信頼性データ）をモデルに組み込み、推奨事項を継続的に精緻化します。領域特有の強みは高いものの、企業規模は小さく、技術的な詳細（AI/ML）はあまり公に強調されていません。

6. Baxter Planning (Prophet by Baxter) – コストに焦点を当てたサービス部品計画の基本。Baxterのソリューションは、予測、在庫計画、自動補充を網羅しています。部品の重要度、配置、顧客の緊急性を考慮した「総所有コスト最適化」アプローチを用いて、サービスとコストのバランスを取ります ⁶。実務的で堅実なツールですが、真のAI駆動の自動化というより、従来の予測手法やユーザー定義のパラメータに依存しています。（サービス部品の運用歴は20年以上）

7. Smart Software (Smart IP&O) – 高度な断続的需要予測エンジン。Smart Softwareは、特許取得済みのブートストラップ法を用いたスペア部品の確率論的予測で知られています ⁷。変動性を捉えるために数千の需要シナリオを生成し、リードタイム全体にわたる正確な需要分布を算出します。これにより、断続的な部品に対して最適な在庫レベルが実現されます。しかし、Smartの注力は予測と安全在庫計算にあり、完全なエンドツーエンドのMROプラットフォームというよりも、（多くの場合ERPを補完する形で）狭いソリューションです。予測に基づいた行動を取るための統合やユーザーの対応は依然として必要です。

8. IBM (MRO Inventory Optimization, formerly Oniqua) – 分析主導、資産集約型産業向け。IBMのMRO IO（Oniquaからの買収）は、統計分析、処方的分析、およびメンテナンス用スペア部品の最適化を組み合わせたクラウドプラットフォームです ⁸。内蔵の予測機能と重要度に基づく推奨により、断続的な需要に対応し、ダウンタイムの最小化を目指します ⁹。このツールは、余剰と不足の識別や「スコア」および作業キューを通してプランナーを導く点で優れており、一部自動化を取り入れているものの、そのアプローチは意思決定支援ダッシュボード寄りで、ユーザーが（例：重要度、リードタイム別に）洞察を確認し、行動することを求められます ¹⁰。その技術は堅実ですが、派手さはなく、「AIマジック」というよりも重厚な分析に依存し、しばしば大規模なデータクレンジング（IBMの得意分野）や統合作業が必要です。

9. SAP Service Parts Planning (SPP) – 高度な設定が必要な有能なモジュール。SAP自体のスペア部品計画ソリューション（SAP SCM/APOの一部で、現在はIBPへ移行中）は、多階層在庫最適化を提供し、断続的な需要に対してCroston法などの手法をサポートします ¹¹。理論上は航空規模の複雑さに対応でき、大手OEMの一部もその機能設計に寄与しています。実際には、SAP SPPは航空ニーズに合わせるために広範なユーザー定義設定（予測モデルの選択、サービスクラス目標など）と大幅なカスタマイズを必要とし、通常はシステムが自己学習するのではなく、プランナーがパラメータ（例：ライフサイクルコード、後継チェーン、最小/最大）を設定する必要があるため、自動化はあまり進んでいません。ERPと統合されたオプションとしては信頼性がありますが、アルゴリズム革新の最前線には立っていません。

10. Oracle Spares Management – Oracle ERP内の基本的なスペア部品計画。Oracleは、E-Business SuiteおよびCloud SCM内でサービス部品モジュールを提供し、需要予測、在庫レベル計画などをカバーします ¹²。標準的な断続的需要技法とネットワーク全体での注文最適化を含んでおり、SAPと同様にルールベースの設定とユーザー入力に依存する傾向があります（例：プランナーが予測戦略（Croston法、指数平滑法）や在庫方針を定義）。Oracleのソリューションは一部の用途では十分に機能しますが、最先端のAIや確率論的最適化の証拠は見受けられず、技術面では専門ベンダーに一歩劣っています。

次に、各ベンダーの技術、機能、そして主張について詳細な分析に踏み込み、その優れている点と懐疑的に検討すべき点を明らかにしていきます。

ロカド – 航空向け確率論的「定量的サプライチェーン」

Lokadは、2010年代に設立された新興企業であり、航空宇宙およびMRO最適化に積極的に注力するコア専門企業です。そのアプローチは躊躇なくデータサイエンス主導です。Lokadのプラットフォームは、確率論的予測と彼らが「予測最適化」と称する手法を中心に構築されています。単一点の需要を予測するのではなく、需要、リードタイム、さらには部品のスクラップ率の全確率分布をモデル化します ¹³。これは航空業界の高い不確実性に対して極めて重要であり、例えば、通常は5,000時間持続する部品が、時にはそれよりも早く故障する可能性がある―確率論的モデルはそのリスクを捉えます。Lokadはこれらの不確実性を踏まえ、在庫保持コスト、品切れコスト、AOGペナルティを最小化する在庫ポリシーを算出します。

Astrakな特徴として、Lokadの技術は微分可能なプログラミングを採用している点が挙げられます ¹³。これは本質的に、機械学習の手法を用いて複雑なサプライチェーンのデータパターンから「学習」することを意味します。例えば、メンテナンススケジュール、信頼性曲線（MTBUR ― 予告なしの除去間の平均時間）、修理サイクルタイムなどを、固定したルールではなく、ニューラルネットワークのようなモデルに組み込むことが可能です。Lokadは、これにより従来のハードコーディングされた数式では捉えきれないパターンを自動的に抽出できると主張しています ¹³。これはサプライチェーンにおける革新的な概念であり、外部からの検証は困難ですが、バズワードを超えた真剣なエンジニアリングを示唆しています。

重要なのは、Lokadがそのアプローチについてエンジニアリングの詳細を提供している点です―あいまいなAI主張からの爽やかな変化と言えます。Revima（APU/ランディングギアMRO）とのプレスリリースでは、需要、リードタイム、スクラップに対する確率論的予測と、複雑な修理プロセスをモデル化するための微分可能なプログラミングを組み合わせたことが明示されています ^{13 13}。これらは具体的な技術であり、単なるマーケティングの言葉ではありません。さらに、LokadのCEOがサプライチェーン数学について積極的にブログを執筆していることは、信頼性を高める要素となっています（彼らは従来の手法を頻繁に批評し、比較検証も行っています）。

自動化の観点から見ると、Lokadのソリューションは、一度データが整えば非常に自動化されます。これは「コードとしてのサプライチェーン」概念に基づいた、ソフトウェアとサービスの融合として提供され、専用のスクリプト言語（Envision）を使ってカスタム最適化モデルの構築が支援されます。その後、システムは、日々の部品取引や除去などのデータを継続的に取り込み、最小限の手動介入で在庫レベルの推奨、発注書、修理注文の優先順位付けなどを再生成します。プランナーが数千の最小/最大設定を維持するのではなく、アルゴリズムが各部品番号について最適なポリシーを算出することで、数万または数十万の部品番号に対応できるよう設計されています。ある航空MROの幹部は、*「Lokadは、確率論的アプローチを取り入れることで不確実性を削減するための適切なツールとサポートを提供してくれた」*と確認し、要求の厳しい充足率目標を、リスク低減とともに達成しています ¹⁴。

Lokadは統合についても率直であり、航空データの複雑さを認めた上で、純粋な「プラグ・アンド・プレイ」の幻想を売り込むことはしません。むしろ、不完全であってもすべての利用可能なデータソースを活用します。例えば、OEM提供の信頼性指標（MTBUR）とオペレーターの過去の除去データを用い、各部品ごとにどちらがより予測力が高いかに応じて重み付けを行うことがあります ^{15 16}。このように複数のデータソースを用いて三角測量を行う手法は、航空特有の事情（例えば、在籍データが乏しい際にはOEMデータを利用し、その逆も然り）に対する高度な理解を示しています。

懐疑的見解： 一般に、Lokadの主張はエビデンス（Air France KLM、Revimaとのケーススタディおよび詳細な技術ブログ）によって裏付けられています。それでも、例えば、データサイエンティストのチームが伴わなくても一般的なMROがいかに容易にLokadのソリューションを採用できるのか、といった厳しい疑問を投げかける必要があります。Lokadは自社の専門家を通じて顧客と密接に連携する傾向があり、これは結果を出す上では非常に有益ですが、純粋なソフトウェアではなく、初めはコンサルティング重視のモデルとして見なされる可能性もあります。また、確率論的モデルは断続的な需要に理想的である一方、その精度はデータ品質に依存するため、「ゴミを入力すれば洗練されたゴミが出る」というリスクは常に存在します。ある事例で「在庫が60%削減された」というLokadの成果 ¹⁷ については、健全な懐疑心で受け止めるべきであり、そのような結果は例外的であるか、非常に低い基準と比較されたものかもしれません。それにもかかわらず、ベンダーの中では、Lokadは現代の予測と最適化科学において最も先端を推し進めているように見受けられます。ユーザーに任意のサービスレベル目標やABC分類を設定させるのではなく、各部品の経済的トレードオフを計算することで意思決定を自動化するため、この自動化と確率論的厳密さの高さが、新しいソリューションを受け入れたい企業にとって最も有力な選択肢となっています。

PTC Servigistics – 最新技術を取り入れた重量級チャンピオン

Servigisticsはこの分野におけるベテランであり、その系譜は業界の先駆者（Xelus、MCA Solutions）を経てServigisticsに統合され、2012年にPTCに買収されました ¹⁸。航空宇宙および防衛分野の大手組織の中で、最も広く展開されているサービス部品管理（SPM）ソフトウェアです。Qantas、Boeing、Lockheed Martin、米空軍などの名前がServigisticsのユーザーとして頻繁に挙がっています ¹⁹。この経歴により、Servigisticsは機能の広がりと深さの面で高い基準を打ち立てています。

機能の観点から、ServigisticsはMROまたはアフターマーケットの物流チームが求めるほぼすべての機能を網羅しています：低容量で断続的な需要に特化した需要予測、多階層在庫最適化（例えば、中央倉庫、前線拠点、修理工場などへの在庫配置）、複数調達先の計画、修理か購入かの判断、さらには統合された部品価格設定モジュールまで ²⁰。特筆すべきは、PTCがIoT統合を通じてServigisticsを拡張し、ThingWorxプラットフォームを用いて接続された機器データ（例：航空機/エンジンからの使用状況やセンサー情報）を取り込み、耐用制限のある部品の故障を予測し、先手を打った交換計画を立てている点です ^{21 22}。これにより、単なる履歴統計ではなく、実際の状態監視に基づいて部品の除去を予測することで、「ランダムなBOM」の問題に対処し始めています。

Servigisticsは現代のデータサイエンスを取り入れていると主張している： “予測、最適化、および分析モジュールはAI、機械学習、およびビッグデータの利点を活用している” ²³。しかし、AI/MLが具体的にどのように使用されているかの詳細は、公開資料にはほとんど示されていない。このツールの長い歴史を考えると、多くの予測エンジンは、Crostonの手法、不定需要に対する指数平滑法の変種、あるいは低需要の場合にはベイズ推定など、従来の統計手法に依然として依存しており、それらは徐々に改良されてきた可能性が高い。Dr. John Muckstadtのような学者と協力しているとの記述は、複数段階最適化のために実績のある解析モデルが使用されていることを示唆している ²⁴。Muckstadtのアルゴリズム（著書「Service Parts Management」より）は、機械学習よりもオペレーションズリサーチ（数理最適化）の領域に属しており、これらの問題に対しては最適である場合が多い。“AI/ML”は最近追加されたラッパー的なものであり、需給のコア予測というよりは、需要の異常検知や部品の分類（例：類似の需要パターンのグループ化）に機械学習が使われている可能性がある。Servigisticsが急に“AI”プラットフォームになったと考えるのは懐疑的であり、実際は非常に洗練されたOR（オペレーションズリサーチ）プラットフォームで、そのエッジに新たなAI機能が追加されているに過ぎない。

確率的予測: Servigisticsはそれを実施しているのだろうか？歴史的には、各部品ごとに需要分布（例えば、ブートストラップ法や事前定義された統計分布のフィッティングを通じて）を算出し、最適な安全在庫を計算することが可能であった。多段階最適化は、本質的に各ロケーションでの品切れ確率を計算するために確率的な入力を必要とする。PTCのドキュメントでは、在庫判断に用いられる「確率分布の種類」に言及しており ²⁵、システムが単一の平均予測以上の情報を考慮していることを示唆している。少なくとも何らかの形で確率的予測、あるいは散発的な需要に対するシナリオシミュレーションを行っていると合理的に推測できる（前身の一つであったMCA Solutionsは、計画においてモンテカルロシミュレーションで知られていた）。現代の手法との違いは、これらの分布が自動的に学習されるのか、あるいは規則に基づいて選択されるのかである。Servigisticsでは、プランナーが通常、各部品に予測手法を設定（もしくはシステムが複数の手法から自動的に選択）し、その後でサービスレベルの目標を決定する。ユーザー定義のポリシーも多く可能であり、例えばプランナーは部品を重要度や価値でセグメント化し、異なる充足率目標を割り当てることができる（システムには豊富なセグメンテーション機能がある） ²⁶。完全自動化されていなければ、これは弱点となりうる――パラメーターが入力されればツールは最適化できるものの、数万に上る部品それぞれに対してどのサービスレベルが適切かを決定するのは、ユーザーの判断や単純な規則（例：「非採用部品は95%、採用部品は80%」）に頼ることになってしまう。真に最適な解は、そのトレードオフを動的に計算するものであろう。例えば、ある予算内で全体の可用性を最大化する自動化された「サービスレベル最適化」がServigisticsに存在するかは不明であり、存在したとしても多くのユーザーは複雑さゆえにそのモードを使わないかもしれない。

Servigisticsは部品ライフサイクルおよび修理ループの側面にも対応している。回転可能な部品（修理可能部品）については、修理パイプラインの計画を立て、ターンアラウンドタイムや歩留まりを考慮することができる。新しい“Connected Forecasting”拡張機能は、残り寿命や使用データに基づいて寿命制限部品（LLP）の除去を明示的に予測する ²⁷。これは、航空の現場において、ある部品がXサイクル後に交換が必要であると確実に分かっている非常に重要な機能である。こうした決定論的なシグナル（例：予定された除去）を予測に組み込むことで、不規則な需要を緩和するのに役立つ。

統合に関して：PTCは、IFSやTraxのような主要なMRO ERPプロバイダーと提携してServigisticsを統合している ²⁸。それにもかかわらず、このような包括的なツールを航空会社のメンテナンスシステムと統合することは大規模なプロジェクトであり（しばしば6～12ヶ月以上かかる）、営業部門からの「プラグアンドプレイ」という主張は慎重に受け取るべきである。実際には、インストールベースデータ、部品カタログ、メンテナンス作業用BOM、修理サイクルデータなど、数十に及ぶデータフィールドのマッピングと、しばしばデータ品質の改善が必要となる。ServigisticsにはSAPやOracleなどのシステム向けの標準アダプターが用意されていると思われるが、カスタム作業が通常であり、これはあらゆるエンタープライズソリューションに共通している。

疑念の要点: Servigisticsは非常に強力であるが、それを使って実際に価値を引き出すのは容易と言えるだろうか？多くの旧来の導入例は、専門知識を持たないユーザーには完全な最適化が圧倒的であるため、単一段階の計画や設定済みの安全在庫といった基本機能だけが使われ、結果として十分に活用されない。ベンダーに対して、システムが実際にどれだけ自動化されているのかを確認する価値がある。例えば、リードタイムのばらつきの変化を自動で検出し再発注点を調整するのか、あるいはプランナーが介入する必要があるのか？多くの「計画パラメーター」が存在することは、多様なチューニングが可能であることを示唆しており ²⁹、これは良い面にも悪い面にもなりうる。例えば、Servigisticsでは計算されたEOQを上書きしたり、特定の予測期間を強制することが可能である ²⁹。これは、初期状態の計算結果が必ずしもユーザーに信頼されているわけではないことをほのめかしている。

まとめると、Servigisticsは最も機能が豊富なオプションであり、現代的な要素（IoTデータや一部のAI）を取り入れるように進化している。最先端の機能を提供するが、最先端のソリューションを実現できるかどうかは実行次第であり、注意が必要な分野である。完全に実装するためのリソースを持つMROにとっては、優れたパフォーマンス（Qantasで報告された部品可用率94% ³⁰）をもたらす可能性があるが、小規模な事業では重すぎると感じられるかもしれない。マーケティング上の主張（あらゆるアナリストレポートでのリーダーなど）は、市場シェアを考えると典型的で部分的に正しいが、潜在的な購入者は称賛の先に目を向け、この強力だが複雑なツールを活用するためのプロセス成熟度を確保すべきである。

Syncron – AIの約束を持つクラウドネイティブなサービス部品計画

Syncronは、別の角度から来る主要プレーヤーであり、もともとはメーカーのアフターマーケット向けサービス部品（特に自動車や産業機械）から始まり、近年では航空宇宙・防衛分野にも拡大している。Syncronの価値提案は、サービス部品のために目的別に構築された、クラウドベースのプラットフォームであることに焦点を当て、在庫最適化、価格最適化、さらにはIoTベースの稼働時間予測モジュールといった複数のモジュールを組み合わせて提供している ^{31 32}。航空MROの文脈では、Syncronは勢いを増しており、例えば地域航空機メーカーであるATRは、グローバルなフリートサポート全体の在庫管理のために最近Syncronを採用した ^{33 2}。

技術的には、Syncronはその部品計画ソリューションにおいてAI、機械学習、および高度な分析の使用を宣伝している ²。具体的には、ソフトウェアが「需要動向を追跡し、高度なシミュレーションを設定して部品のサービス需要を計画・予測する」と述べている ²。これは、Syncronが在庫最適化のために、モンテカルロシミュレーションまたは確率的計画の何らかの形態を用いて、需要と供給のシナリオを生成していることを示唆している。IDC MarketScapeでは、Syncronは「動的再補充、確率的計画／予測」を強みとして挙げられており ³⁴、単に決定論的またはルールベースの手法だけに頼っているわけではないことが示されている。古いツールとは異なり、Syncronがクラウドネイティブであるという事実は、顧客がITインフラを管理する必要なく、大規模なデータセットの処理や大規模なシミュレーションをバックグラウンドで実行できることを意味する。

Syncronの理念における注目すべき側面はサービタイゼーションであり、企業が稼働時間をサービスとして捉えるのを支援することである。実際、Syncronのプラットフォームは、サービス部品予測とフィールドサービス管理のデータおよびIoTによる予知保全シグナル（Uptime™モジュールを通じて）を統合している。航空業界においては、航空機の健康モニタリングデータを用いて部品の需要を先取りすることを意味し得る。これは、PTCがThingWorxで行っていることに概念的には似ているが、Syncronはこれをアフターセールス専用のスイートの一部としてパッケージ化している。このアプローチは、航空業界において可用性が全てである「パワーバイザアワー」といったトレンドに合致している。

最適化の観点では、Syncronは可用性とコストのバランスを取りながら在庫を最適化している。彼らは、部品可用性が12～17.5%向上し、在庫コストが15%削減されるといった改善効果を明示的に主張している ³⁵。これらの数字は、他の主張と同様に慎重に扱うべきであり、特定のケーススタディから得られた結果である可能性がある。Syncronの最適化アルゴリズムの技術的詳細は公開されているものが少ないが、統計的予測モデル、パターン認識のための機械学習、そして多段階在庫管理のための何らかのヒューリスティックまたはソルバーの組み合わせを利用していると推測できる。Syncron Inventoryは、歴史的にディーラーネットワークを有するOEM向けの流通ネットワーク最適化に強みを示しており、そのため複数拠点での最適化はシステムのDNAに組み込まれている。

自動化とユーザーの労力: Syncronは、多くの日常的なタスクを自動化している可能性が高い。最新のソフトウェアとしてクラウドと使いやすさを重視して設計されているため、各SKUの予測手法をユーザーが手動で調整する（旧システムの悩みの種）代わりに、適切な予測モデルを自動的に選択し、データの変化に応じて更新すると思われる。とはいえ、Syncronの典型的なユーザー（製造業者）は、部品をライフサイクルや重要度で分類して異なる方針を適用するなど、ビジネスルールを設定することが多い。Syncronが完全にハンズオフでの最適化を可能にしているかどうかは検証すべきである。なお、Syncronの価格および在庫モジュールが現在、統合を要する別々のデータベースを使用しているという記述があり ³²、これは一部で旧来の基盤が残っていることを示唆している。モジュール間の連携が、広告されているほどシームレスではないかもしれない。

Syncronが強調するもう一つの強みは部品ライフサイクル管理である。これは、新部品の導入、陳腐化、後継品への移行といったプロセスを扱うものであり、航空業界のように部品が新型やPMA代替品に置き換えられる環境では特に重要である。Syncronは、自動車分野において（モデルチェンジが部品需要に影響する）同様の課題に取り組んでおり、システムはおそらく、古い部品の需要の減退や新規部品の需要増加を、類推や連動予測を用いて予測できる。

主張の検証: Syncronは公開されている技術的なホワイトペーパーが比較的少ないため、私たちの懐疑論の一部は、彼らの主張や数少ない参考資料に頼らざるを得ない点にある。ATRのプレスリリースでは、このソリューションがサプライチェーンの不安定性や業務拡大に役立つと示されている ³⁶が、これは一般的な表現である。重要な技術的主張は、AI/MLとシミュレーションの組み合わせである ²。そこでSyncronに対して、実際に動作するMLモデルの証拠を提供しているのか？ 例えば、使用率や故障などの需要原因を検出するためにニューラルネットワークを使用しているのか、単に時系列手法に依存しているだけなのか？また、「AI」と掲げている場合、それは統計モデルのレッテルに過ぎないのか、本当に新しい技術を指しているのか？詳細が不足しているため、慎重な姿勢を取る必要がある。

しかし、いくつかの競合他社とは異なり、Syncronは古いアーキテクチャに依存しておらず、根本から構築された21世紀のプラットフォームである。これにより、より優れたUIや、現代的なAPIを用いたERPとの統合、さらには顧客に代わって重い処理を実施するなど、迅速な展開が可能となっている。それでも、「プラグアンドプレイ」は非現実的である。例えば、ATRの導入事例では、SyncronをATR独自のSAPやメンテナンスシステムにマッピングする必要があったと考えられる。Syncronのチームは、航空業界の“特有の要求”に合わせた機能拡張を行うためにATRと積極的に連携しており ³⁷、これは、初期状態では一部の航空特有のニーズが満たされていなかったことを示唆している。これは、ベンダーが柔軟に対応する良い面と、当初製品がすべての航空の複雑性に対応できていなかったという注意点の両面を含んでいる。

まとめると、Syncronは確率的手法とAI要素を取り入れながら最先端に向かって進化しており、強い自動化志向を示している。Servigisticsほどの深い航空実績はまだないかもしれないが、新たな航空顧客の獲得から、その有力な候補として急速に台頭している。MROの経営者は、SyncronのMLに関する主張を具体例やデモなどで検証し、約束された在庫やサービスの改善が単なる業界平均ではなく、実際のデータに基づいているかを確認すべきである。他の事例と同様に、「15%の在庫コスト削減」といった魅力的な数字はあくまで目安とし、実際の成果は初期プロセスの乱れ具合によって異なることを念頭に置くべきである。全体として、Syncronはその現代的なアーキテクチャとインテリジェントな自動化への注力から高く評価されるが、その技術が流行語以上のものであることを証明する必要がある。

ToolsGroup – 強力な断続的需要アルゴリズム、しかし「インテリジェント」はどこか？

ToolsGroupは1993年に設立された実績あるベンダーであり、主力製品であるSO99+ (Service Optimizer 99+)ソフトウェアで知られている。自動車の予備部品から産業機器に至るまで、各業界のアフターマーケット部品計画に大きな存在感を示し、航空宇宙や防衛の分野でも利用されている。ToolsGroupの核となる強みは、いわゆる確率モデルを用いて「ロングテール」の需要を処理する点に常にあった。伝統的なツールが断続的需要に対応できないのに対し、ToolsGroupは「断続的な需要を卓越した予測能力で捉え、複数段階の在庫をグローバルに最適化する」ことでサービス部品計画の問題を解決する ³。

ToolsGroupの予測技術は確かに確率的である。歴史的には、単一の数値を予測するのではなく、各SKUごとに需要を確率分布としてモデル化するという独自のアプローチを採用してきた。これは、モンテカルロシミュレーションや、分布を解析的にフィッティングする方法（情報源によれば、ToolsGroupはブートストラッピングの一種またはCrostonの手法の変種と変動性解析を組み合わせた手法を用いる可能性がある）で実施される。各部品について、需要分布とリードタイムを基に、ソフトウェアは目標サービスレベルを達成するために必要な在庫、または逆に、与えられた在庫予算で達成可能なサービスレベルを算出する。このアプローチは、1990年代や2000年代に他の多くの計画システムが単純な手法を用いていた時代には、いささか先駆的なものであった。これにより、動きが非常に遅い品目に対しても、サービスレベルを厳格に管理することが可能となる。さらに、ToolsGroupは、プランナーが安全在庫を推測するのではなく、各SKUごとに希望するサービスレベルを指定すると、必要な在庫量を自動で算出するという**「サービスレベル駆動型計画」**の概念も導入している。

しかし、現代の批判は、ToolsGroupが以前のモデルを大幅に革新したかどうかという点にある。同社は現在、自社を「AI搭載」と称し、「需要感知」や機械学習といった概念を語っている。しかし、Lokadによる市場調査は、ToolsGroupの公開資料が依然として旧来の手法をほのめかしており、矛盾すら指摘している。すなわち、ToolsGroupは確率的予測を宣伝し始めたにもかかわらず、MAPE（平均絶対パーセンテージ誤差）の改善を示しており、これは*「確率的予測には適用されない」* ⁴とされている。これは、マーケティングの外皮にすぎないことを示唆しており、本当に分布予測に注力しているならMAPEで予測誤差を測ることはないはずである。言い換えれば、ToolsGroupは依然として各品目に対して単一の予測（業務報告用）を主に生成し、その裏で在庫計算のために確率的な概念を活用している可能性がある。さらに、「需要感知」との言及（通常は、手元在庫やIoTデータのような非常に短期のシグナルを用いて予測を調整することを意味する）も、科学文献ではほとんど支持されていないとされており ³⁸、ToolsGroupが流行語だけを使っているに過ぎない可能性を示唆している。

とはいえ、ToolsGroupの能力は確固たるものである。同社は多段階最適化をサポートしており、最小限の在庫でサービス目標を達成するために、ネットワーク内のどこに部品を在庫すべきかを推奨できる。また、在庫の再配置や再配分にも対応しており、MROにおいて部品が拠点間または地域間で移動される際に有用である。ToolsGroupのソリューションはしばしばSAPなどのERPと統合されており、ある企業ではSAPの計画上の制約を克服するためにSO99+と共にSAPが使われている（ToolsGroupは、確率的予測によりSAP APOを拡張できるとまで提案している ³⁹）。一般的に高度に自動化されており、一度設定されるとプランナーは例外の監視に専念する。このツールは数千のSKUと拠点の組み合わせを処理し、サービスレベルが低下する可能性がある品目や、需要の急増が発生して介入が必要な品目のみを警告する。

MROの文脈において具体的に言えば、ToolsGroupは確かに断続的な需要をモデル化できるが、部品の重要度やライフサイクルといった要素は考慮しているのだろうか？ToolsGroupは一般的な傾向にあるが、ユーザーは部品カテゴリごとに異なるサービスレベル目標やコストを入力することが可能である。システムがネイティブに「go/no-go」の重要性を認識しているわけではないが、顧客は「no-go」品目に対してほぼ100%のサービス目標を設定し、他はそれより低い目標にすることで対応できる。その指示に従って最適化が行われる。同様にライフサイクルについても、ToolsGroupには残存寿命に基づいた予測を行うための標準モジュール（ServigisticsやSyncronがIoTデータを用いるようなもの）はないかもしれないが、既知の定期交換については手動で予測を調整することができる。これは航空専用のソリューションというより、さまざまなニーズに対応可能なツールキットである。

注意すべき点の一つは、ToolsGroupが主張する典型的な成果である。たとえば、同社はクライアントが失注の20～50%削減、在庫の10～30%削減、95～99%のサービスレベルを達成していると主張している ⁴⁰。これらの数値はもっともらしいが、範囲が広く、明らかにマーケティング主導である。このような改善は、これまで実質的な最適化を行っていなかった企業なら、どんな優れたツールを導入しても大きな向上が見込めるため、ToolsGroupが競合他社に比べて独自にこれらを達成していることを意味するわけではない。これらのパーセンテージを裏付ける独立した研究がないことが多いため、額面通りに受け取ることには懐疑的である（「何を基準と比較しているのか」や「どの期間にわたる成果なのか」といった文脈が欠如している点が示唆的である）。

ユーザー定義 vs. 自動化： ToolsGroupは予測において比較的自動化されているが、多くの設定が可能である。例えば、プランナーは品目やグループごとにサービスレベル目標を選択できる。もし企業がその設定方法を知らなければ、従来の習慣（ABC分類など）に戻ってしまい、これが技術の効果を制限することになる。理想的には、ToolsGroupの最適化機能を使ってこれらの目標を最適に設定するべきであり、同社には在庫投資とサービスのバランスをポートフォリオ全体で取るといった、経済的最適化の一形態の機能があると考えられる。しかし、これを適切にセットアップするためには、同社のコンサルティングや高度な機能を利用する必要があるかもしれない。

ToolsGroupの統合作業は中程度の労力を要する―使用履歴、部品表（BOM）などのデータフィードが必要である。これは、AMOSやRusada（一般的なMROシステム）のようなプラグアンドプレイではなく、プロジェクトとして進める必要があるが、ToolsGroupの長い歴史から、多くの統合コネクタが存在する。

結論： ToolsGroupは、スペアパーツ最適化において信頼できる有能なソリューションである。確かに2010年頃の最先端技術としての評価に値し、現在も十分に通用する。しかし、2025年においては、どれだけ新しいAI/ML技術が取り入れられているのか疑問視する必要がある。現存の証拠は、多くの流行語が散見される一方で、具体的な新しい手法はあまり発表されていないことを示唆している。これはシステムが機能しないという意味ではなく、実際に動作するが、「AI」というラベルは洗練された統計手法を利用しているに過ぎない可能性がある（これは問題ない）。MROの経営者にとって、ToolsGroupはリスクの低い選択肢となり得る（確立された製品であり、多くのリファレンスカスタマーが存在する）。ただし、真に次世代のシステムを手にしているわけではなく、非常に優れた伝統的システムを採用していることを認識しておくべきである。もし同社が「AI」を謳っているなら、具体的に何がAI駆動で、その結果として既に優れた確率的モデルをどのように改善しているのかを明確にするよう求めるべきである。また、貴社のチームがその強み（例えば多段階最適化など）を十分に活用できるようにし、単なる基本的な計画ツールに陥らないように注意することが重要である。

Armac Systems (RIOsys) – 航空に特化、回転部品と修理の最適化

Armac Systemsは、特に航空MROの現場から生まれたという点で、このリストの中で独自の存在である。同社は小規模なベンダーであり（アイルランドに拠点を置き、2010年代後半よりSR Technicsの傘下となっている ⁴¹）、航空在庫の最適化に100%注力している。Armacの看板製品であるRIOsys（回転在庫最適化システム）は、消耗品のスペアパーツと高価な回転部品の両方を扱う航空会社やMRO向けに設計されている。

Armacを際立たせるのは、その領域特化性である。このソフトウェアは「航空特化の在庫計画と最適化」として説明され、最も低い経済コストでスペアパーツの利用可能性を最大化することを目指している ⁵。また、典型的な航空の状況、すなわち*「予定外の部品需要、数多くのコンポーネント、複数拠点での運用が常態である」* ⁴² ことを明示している。このツールは、回転部品と消耗部品の最適な在庫レベルを計算するのに役立ち、購入数量だけでなく、スペアとして保持すべき数量や修理パイプライン用の数量など、出発信頼性目標を達成するための在庫管理が可能となる。また、運用知識が供給モデルに組み込まれ、継続的に洗練される ⁴³ と述べており、これはシステムが部品の実際の取り外し率などのデータに応じて、予測や推奨在庫量を更新していくことを示唆している。

Armacのアプローチの一側面として、信頼性工学のデータを活用している点が挙げられる。航空整備には、MTBF/MTBUR、信頼性曲線、1000飛行時間あたりの取り外し率などの概念がある。Armacは、単なる時系列外挿ではなく、これらのデータを利用して需要を予測している可能性が高い。たとえば、ある航空会社が100機のA320を運用し、特定のポンプのMTBURが5000飛行時間である場合、年間に発生する故障数を概ね予測することができる（ばらつきはあるが）。これはMROに特化したものであり、例えば顧客にスペアパーツを販売する際の予測とは異なる。Armacが学界との提携や「ビッグデータ・ビジネスインテリジェンス技術」 ⁴¹ を取り入れていることは、この種の信頼性に基づく予測モデルの研究と実装を示唆している。

Armacはまた、技術的な出発信頼性に焦点を当てることで、間接的に**「go/no-go」の重要性**に対応している。航空会社において、出発信頼性（整備による遅延やキャンセルなくフライトが出発する割合）は重要な指標である。特にno-go品目のスペアパーツの利用可能性がこれに直接影響する。Armacのケーススタディ（例えばイベリア航空）は、コスト削減と同時に資材の利用可能性向上を目指していることを示している ⁴⁴。ArmacのCEOは、最低限の経済コストでスペアの利用可能性を向上させる ことを強調しており ⁴⁵、これは明らかに経済的最適化を行っていることを示している。すなわち、重要部品を常に確保し（AOGを回避するため）、しかし全域で過剰在庫にならないよう管理しているのである。

興味深い点として、ArmacのRIOsysは既存のERP（SAPなど）と統合され、「追加のインテリジェンス層」を提供している ⁴⁶。これは、取引システムを置き換えるのではなく、補完する形で機能していることを示しており、最適化ソフトウェアの共通テーマである。SAPとの統合はセールスポイントであった（SAP認証を取得するなどしている）が、やはり統合には手間がかかる。

Armacは、プランナー向けに多くの自動化機能を提供している可能性が高い。すなわち、例えば「拠点Xにこの部品を在庫する」「拠点Yから拠点Zへ余剰品を移動する」「今すぐこの数の部品を修理する」といった推奨を自動で生成する。また、ユーザーフレンドリーなダッシュボードを備えており、余剰や不足を明示し、対策の優先順位付けを支援している ⁴⁷。これは、規模の小さい計画チームにとって非常に重要であり、ツールは今日何をすべきかを指示する必要がある。実際、イベリア航空がArmacを用いた事例では、在庫プランナーが*「余剰や不足を特定し、日々の活動の優先順位を決定する」* のに役立ったと報告されている ⁴⁷。これは、システム主導の高い意思決定支援、すなわち強力な自動化の証と言える。

懐疑的な見方として、Armacは規模が小さく、マーケティング上も目立たないため、独立した評価が少ない。航空分野では非常に有能に思えるが、本当に最先端のアルゴリズムを使用しているのか？あるいは、航空向けに特化した多数の専門家ルールやテンプレートによるカスタマイズが成功の要因になっているだけなのか。例えば、Armacは標準的な統計モデルを用いながらも、航空シナリオに適したパラメータがあらかじめ設定されている可能性がある。これでも十分価値はあるが、「魔法」とは言えない。また、継続的に洗練されるモデルの言及 ⁴³ は、何らかの機械学習、あるいは少なくとも反復的なキャリブレーションが行われていることを示唆しており、これは良い兆候である。

潜在的な弱点として、規模やリソースが挙げられる。小規模なベンダーであるArmacが、例えばPTCやLokadのように最新のAI研究に同じペースで投資できるのか疑問である。おそらくそうではないが、特定領域に集中しているため、既にその分野に適したソリューションを持っていれば、高度なAIは必ずしも必要としない。また、SR Technics（大手MRO）の傘下であることは、深い業界フィードバックを得られる一方で、その展望がオーナーのニーズに限定される可能性も示唆している。

Armacはプレスリリースで大々的に「AI」を謳ってはいない。むしろ「新世代のインテリジェントな在庫計画」や「ビッグデータ技術」といった用語を使用している ⁴¹が、これらは流行語に過ぎず具体性に欠ける。そこで、Armacに具体的な詳細を尋ねる価値がある。たとえば、修理サイクルの変動性をシミュレーションしているのか？充足率と資産活用率の両方を最適化しているのか？部品の陳腐化にはどのように対応しているのか（部品が段階的に廃止される際、過剰在庫とならないよう警告する仕組みがあるのか）？彼らのニッチな分野を考慮すると、エンドオブライフ計画や回転部品のプーリング最適化など、他社があまり強調しない機能を有している可能性が高い。

統合は依然として課題である。たとえSAPとの統合があっても、すべての航空会社が標準システムを使用しているわけではない。多くの航空会社はAMOS、Ultramainなどの専門的なMROシステムを採用しており、Armacはそれらに適合させるためのマッピングを行うか、データエクスポートに依存する必要がある。プラグアンドプレイではないが、同社のチームは同様のクライアント向けの統合実績を持っているはずである。

結論として、Armac SystemsのRIOsysは、特に航空MRO向けの強力な選択肢であり、典型的なプロファイル（複数の整備拠点を持つ航空会社、回転部品と消耗品の混合）に適している場合、比較的少ない設定で大きな価値を提供する可能性が高い。これは領域適合性における最先端と考えられ、貴社の課題を深く理解している。技術面においても、高度な解析（最先端のAIでなくとも、非常に専門的なアルゴリズム）を使用している可能性がある。Armacを評価するMROの経営者は、このツールが現代の全てのニーズを確実にカバーしているかどうか（例えば、確率的予測や最適化ソルバーを使用しているかなど）を検証すべきである。航空組織において「数百万の節約」が達成されたという実績がArmacの信頼性を裏付けている ⁴¹。他のベンダーと同様に、そのROI主張には「信頼はするが検証する」という姿勢で臨み、貴社の環境に統合するためのIT支援体制が整っていることを確認することが重要である。

Baxter Planning (BaxterによるProphet) – 人間参加型コスト重視の計画

Baxter Planningは、1990年代からあるサービスパーツ管理の確立されたプロバイダーである。同社のソリューションはしばしばProphetと呼ばれ、テクノロジー、医療機器など幅広い業界を対象としているが、MRO/航空セクターにもある程度対応している（ただし、最も強い市場基盤はテクノロジーおよび通信ハードウェアのサービスパーツにある）。Baxterのアプローチは実践的な計画経験に根ざしており、創業者自身がサービスパーツプランナーであったため、ソフトウェアは現実のプロセスを反映している。つまり、これ1つのシステムで予測、在庫最適化、補充、修理計画、ライフサイクル管理、余剰管理など、エンドツーエンドの計画を網羅している ⁶.

Baxterの手法の主要な原則は、**「トータルコスト最適化」**である ⁴⁸。在庫計画にあたって、部品コスト、配置、顧客や資産の重要度を明確に考慮している。つまり、同社のシステムはサービス目標を達成しつつ、在庫の総コストを最小化しようとする。例えば、部品が非常に高価で、かつ重要度が低い場合、システムは棚卸しを多く持つのではなく、リードタイムの延長（緊急発注に依存するなど）を許容するかもしれない。逆に、離れた拠点におけるno-go部品の場合、在庫切れ（AOG、稼働停止）のコストが高いため、Prophetは需要が少なくともスペアパーツの在庫を推奨することがある。これは経済的最適化の考え方であり、在庫決定における「コストパフォーマンス」を追求するものと言える。Baxterはこの考え方を組み込んだ点で評価に値する。

しかし、Baxterがこれを実現する方法は、多くのユーザー主導の設定に自動化が補完されたものであるように見える。同社のシステムは、部品の重要度やサポートコミットメント（SLA）などの属性をプランナーが入力でき、その制約内で最適化を行う。しかし、確率的予測は実施しているのだろうか？公開情報からはあまり明確ではない。古いソリューションであるため、従来の予測手法（移動平均、指数平滑法）で始まり、その後、断続的需要に対応するためにCroston法やブートストラップ法を追加した可能性がある。LokadやSmartほど明確に確率的ではなく、シナリオ分析やサービスレベルの数式を用いて在庫を最適化している可能性がある。

断続的な需要の場合、Baxterはこの問題を確実に認識しており、その文献では、低速で動く部品には特別な対応が必要であると述べられています。疑問は、これらの部品を分類し手法を選択するのをプランナーに依存しているのか、それともシステムが自動的に適応するのかという点です。構築された時代を考えると、前者の可能性が高く、例えばプランナーがある予測手法（Prophetには「断続的需要予測」モジュールがあり、特定の技法を用いているかもしれません）を設定し、その後システムがそれを用いて在庫水準を計算する仕組みになっていると思われます。

Baxterのツールは実行の自動化を強調しています。例えば、供給注文の自動化（発注書や修理注文を自動生成する機能）や再配置（余剰在庫を必要な場所に自動的に移動する機能）といった機能がリストに含まれています ⁴⁹。これは数千もの部品を扱う場合に極めて重要で、システムが推奨されるアクションを自動的に開始し、例外的な場合にのみプランナーを関与させることが望まれます。多くの報告によれば、Prophetは多数の拠点にまたがる数万の部品にも対応できるとされ、これはグローバルなフィールドスペアを持つ大手テック企業が顧客に含まれているためです。

注意すべき点の一つは、Baxter Planningが歴史的にクライアントごとのカスタマイズを多く行っていたことです。小規模なプライベート企業として、特定のニーズに合わせて機能を調整・追加することがよくありました。つまり、利用状況は企業ごとに異なる可能性があり、ある会社ではBaxterの高度なミンマックス最適化を使用し、別の会社ではよりシンプルなミンマックスモードで利用するかもしれません。柔軟性はありますが、その柔軟性ゆえに初期状態では「ベストプラクティス」に強制されるわけではなく、あくまでツールを提供するに留まります。

BaxterはAI/MLを大々的に宣伝しているわけではありません。彼らは控えめな姿勢を取り（過剰な誇大広告が少ない点は評価できますが）、最先端の予測を求める場合には、新しい手法に追随しているかどうかを確認する必要があります。最近のバージョンで新しいアルゴリズムが組み込まれている可能性はありますが、それらはあまり広く公表されていません。

顧客層を鑑みると、Baxterには航空特有の機能があまり組み込まれていない可能性があります。例えば、使用回数が一定数に達した後に部品を廃棄するハードライフリミットに対応しているかどうかは不明です。カスタムフィールドとして対応している可能性はありますが、最適化プロセスで自然に考慮されるかは疑問です（交換時の需要予測を超えて）。ただし、ライフサイクルの状態（新規部品、終末期部品）には対応しており、生産終了に伴うラストタイムバイの計画も可能で、これは航空業界で部品の生産が終了する場合に重要です。

成果に関する主張において、Baxterは派手なパーセンテージを公表することはあまりなく、「在庫をX%削減した」というよりも、プランナーが目標を達成するのをどのように支援するかに焦点を当てています。これは実際的なアプローチを示しており、改善は起こるものの、その効果はツールの使用方法に依存することを意味しています。

統合: BaxterのProphetは通常、ERP/MROシステムと併用されます。統合は他のシステム同様に、使用実績、在庫、部品表（BOM）などの情報を取り込むものです。Baxterは一般的なシステム向けの事前構築されたコネクタを備えている可能性が高く（浅い供給ネットワークや他のエンタープライズシステムとの統合をサポートしていると述べています）が、プラグアンドプレイを期待するのではなく、ある程度のIT作業が必要となります。

懐疑的に見るならば、Baxterのソリューションが真に最適化を行っているのか、それとも重要な選択を人間に委ねる意思決定支援に留まっているのかを慎重に検証するべきです。多くのBaxter顧客がマルチエシェロンではなく前方在庫拠点のコスト最適化に焦点を当てているという言及は、ツールがしばしば各拠点を個別にコスト目標に合わせて最適化する、より単純なモードで使用されていることを示唆しています。一部の顧客のネットワークが浅いためマルチエシェロンが問題とならなかったとも考えられます。しかし、中央倉庫と分散拠点を持つ航空会社では、マルチエシェロンの問題は重要であり、必要に応じてBaxterがそれに対応できることが望まれます。

まとめると、Baxter Planningは伝統的ではあるがバランスの取れたサービス部品計画システムを提供します。信頼性が高く、コストとサービスのトレードオフに焦点を当て、数多くのタスクを自動化しています。最先端のAI機能は搭載していないかもしれませんが、実用的な機能に深みがあります。MROの経営者は、Baxterを**「安心できる頼みの綱」**ソリューションと捉え、実績ある手法を適用することで改善が期待できると見るべきです。ただし、最先端の分析に飛躍するわけではなく、堅実でやや保守的なアプローチとなる点に留意してください。もし貴社がブラックボックスのAIではなく、より多くのコントロールと透明性を重視するのであれば、Baxterのスタイルはむしろ好ましいかもしれません。懐疑的に検証する点として、システムが静的なユーザー入力に過度に依存していないか（例えば、多数の部品パラメータを手動で管理させることなく）を確認し、変化にどう適応するか（各サイクルで自動調整するのか、季節性や使用率を学習するのかなど）を問う必要があります。これらが確認できれば、Baxterは過剰な期待を抱かせることなく、着実な利益をもたらすでしょう。

Smart Software (Smart IP&O) – 断続的需要予測のニッチな専門家

Smart Softwareは、小規模なベンダーながら、問題の中でも最も困難な部分の一つである断続的な需要予測に取り組むことで評判を確立しています。彼らのソリューションは、現在Smart IP&O（在庫計画と最適化）という統合プラットフォームとして提供されており、Croston’s法の改善に関する学術的研究から生まれました。実際、Smart SoftwareはAPICSから賞を受賞した特許取得済みのブートストラッピング手法を断続的需要予測に導入しています ⁷。この手法は、ホワイトペーパーで十分に文書化されており、過去のデータに基づいて多数の合成需要シナリオを生成し、リードタイム全体にわたる需要分布全体を作り出すものです ^{7 50}。その結果、単一の予測値ではなく、必要とされるユニット数の確率曲線が得られ、所望のサービス確率に対してほぼ最適な在庫水準の計画が可能となります。

航空MROにおいては、部品の80%以上が低速で動き、需要にゼロが多数含まれる場合があり ^{51 52}、Smartの予測精度は画期的な効果を発揮します。従来の予測手法（移動平均など）は、このようなデータに対しては大きく失敗しますが、Smartの確率論的アプローチは、需要の「でこぼこ」な性質を平滑化するのではなく、むしろその特性を受け入れて対応します。たとえば、「通常は0で、稀に5ユニットのスパイクが発生する」といった奇妙なパターンも非常にうまくモデル化できます。

Smartの技術的詳細は非常に具体的で新鮮です。彼らは特定の分布（正規分布やポアソン分布など）を無条件に仮定するのではなく、実際のデータを用いてシミュレーションを行うと述べています ⁵³。また、需要はしばしば*「単純な正規分布に従わない」と明言しており、そのためにブートストラッピング手法を採用しているのです ⁷。その上で、アイテムのフルリードタイムにわたる累積需要の「全分布」*を生成します ⁵⁴。これにより、例えば95%のサービス水準に対する安全在庫の計算が、単にその分布の95パーセンタイルを用いるだけで、簡単かつ正確に行えます。

Smart Softwareのソリューションは単なる予測にとどまらず、IP&Oプラットフォームは在庫最適化および需要計画のモジュールも含んでいます。しかし、核心となる差別化要因は依然として予測部分です。最適化モジュールは、おそらくその予測分布を用いて再注文点や発注量などを算出し、サービス目標を達成しながら在庫を最小限に抑えます。ただし、マルチエシェロン最適化や修理可能部品のループなどに関しては、技術的にそれほど洗練されていない可能性があります。Smartの出力を他のシステムに統合するか、またはSmart内で各拠点を個別に管理することも可能ですが、歴史的にはシングルエシェロンに重点を置いており、IP&Oでは複数拠点対応の機能が加えられているかもしれません。

Smartの規模と専門性の利点の一つは、保守分野で人気のEAM/ERPシステムと頻繁に統合される点にあります。例えば、IBM Maximo、SAP、Oracleなどとの統合が挙げられており ⁵⁵、既存のシステムに彼らの予測エンジンを比較的容易に組み込むことができることを示唆しています。基本的には、Smartを用いて各部品の最小／最大在庫や安全在庫などの在庫パラメータを算出し、その結果をERPに戻して実行するという流れになります。これは、従来の計画システム全体を置き換えるというパラダイムとは異なります。

次に、彼らの主張を見てみると、Smartは自社ソリューションを利用した企業が「初年度に在庫を約20%削減し、部品の利用可能性を10～20%向上させる」としばしば述べています ⁵⁶。これらの数字は妥当な範囲であり、過剰に誇張されたものではなく、より優れた予測による典型的な改善と一致しています。これは、以前の企業が「万一に備えて」過剰在庫を抱えるか、誤った部品を在庫していたことを意味しており、最適化によって20%の在庫削減と実際のサービス向上が実現されたことを示唆しています。ただし、これらの数字がすべてのケースで独立して確認されているわけではないため、成功事例の平均値と考えるべきです。保証はされませんが、以前に確率的な計画を実施していなかった企業では十分にあり得る話です。

Smartは非常に専門的であるため、懐疑的に検討すべき点としては、航空MROの全てのニーズに完全に対応できるかどうかです。需要予測と在庫水準の設定は一面ではありますが、修理サイクルの管理、回転可能部品のプール、あるいは拠点間での在庫の動的な再配分についてはどうなのでしょうか。Smart IP&Oには、これらすべての機能が最初から組み込まれているわけではなく、各拠点の在庫が目標のサービス水準に合わせて計画されるという、かなり標準的なプロセスを前提としている可能性があります。ネットワーク全体でどの拠点が在庫を保持すべきかを最適化する機能は、少なくともマルチエシェロン専用のツールほどのレベルではないかもしれません。また、信頼性工学の指標を明示的に取り入れていない可能性もあります（需要履歴に何らかの形で入力しない限り）。

もう一つの注意点は、自動化 vs. ユーザー入力です。Smartのツールは数値を計算しますが、ユーザーはしばしばサービスレベル目標を設定しなければなりません（彼らは「ほぼ100%の精度」を謳っていますので、高いサービス水準を目指してコスト最適化を行っている可能性があります）。Smartは各SKUごとに予測モデルを選択させることはなく、アルゴリズムが自動的にデータを処理します。これは良い点ですが、例外の管理は依然必要です。たとえば、部品が廃盤になる場合には、システムにその旨を通知するか手動で予測を調整しなければなりません。彼らが言及する「Gen2」技術 ⁵⁷ には、需要の原因要素をより自動的に特定する機能が含まれているかもしれませんが、詳細は公開されていません。

統合には改めて努力が必要です。Smartは科学的根拠を提供しますが、データ（整備された過去の需要など）を投入し、その出力結果を受け取って実施する必要があります。もし、組織が生成された予測や安全在庫を信頼する準備ができていなければ、それらを上書きしてしまい、結果として効果が減少する可能性があります。Smartの成功事例は、通常、ツールの推奨を完全に活用する専任のチームによるものです。

全体として、Smart SoftwareはMROの計画能力を補完できる専門的なツールと言えます。断続的需要予測においては、最先端の技術を持っていると評価でき、特定の分野では大手ベンダーがそれほど進んだ手法を用いていない場合もあります。もし、MROが数千の散発的な部品に対する予測精度を最も大きな課題と感じるのであれば、Smartは魅力的なソリューションです。しかし、より大きな課題が複雑な修理サプライチェーン全体の最適化であるならば、Smart単体では不十分かもしれず、ERPや他の計画システムと併用される一部のピースに過ぎない可能性もあります。

技術に注目するMROの経営者にとって、Smart IP&Oは計画システムの完全な置き換えではなく、「ひと箱に詰められた予測エンジン」として検討する価値があります。懐疑すべき点としては、組織がこれらの予測に基づいて実際に行動できるか（在庫推奨を実行するプロセスは整っているか）、また、リードタイムの変動などにどのように対応しているかを確認する必要があります（需要変動には優れているため、リードタイムのシミュレーションが行われているか、あるいは変動に対するバッファが設定されているかを問うべきです）。さらに、データが新たに投入されてスパイクが確認された場合、どの程度迅速に反応し、過剰反応を避けるのかといった更新の仕組みも明確にするべきです。彼らの学術的厳密性を考えれば、これらの点は検討されている可能性が高いですが、確認することが望ましいです。

IBM MRO在庫最適化 (Oniqua) – データ駆動型意思決定支援

IBMのMRO在庫最適化は、基本的にはIBMが2018年にOniquaから買収した製品で、鉱業、エネルギー、製造業、そして航空宇宙といった資産集約型産業向けの分析プラットフォームとして位置づけられています。Oniquaは、鉱山企業向けのMRO在庫最適化において、稼働停止時間の最小化と在庫削減に注力するコンサルティング重視のアプローチで知られていました。IBMの一部となったことで、このツールはIBMのMaximoおよびサプライチェーンスイートに統合されましたが、単体でも使用可能です。

IBM MRO IOは、サービスレベルの向上とコスト削減を目的として、「統計分析、指示的分析、自動化および最適化アルゴリズムを組み合わせる」 製品として説明されています ⁸。実際には、使用状況と在庫データを分析し、過剰在庫や品切れのリスクがある箇所を特定した上で、「これを削減し、あれを増やす」といった対策を指示します。これは、賢明なアナリストが常にMRO在庫のKPIをチェックしているのに似たアプローチです。ソフトウェアには、アイテムのスコアリング（おそらく重要度またはリスク評価）や、プランナー向けのワークキューなどの機能も含まれており ⁹、ユーザーが確認すべき推奨アクションのリストを生成する、とても実用的な仕組みとなっています。

予測の側面では、IBMはMRO IOの機能として**「断続的需要予測」**を明示的に言及しています ⁹。Oniquaの背景から、部品の散発的な使用を予測するためにCroston’s法またはその変種を採用している可能性が高いです。Smartのブートストラップ手法ほど先進的ではないかもしれませんが、断続的な性質には少なくとも対処しています。さらに、IBMのソリューションは、歴史的データのレビュー時に重要度、リードタイムなどを考慮して洞察を導き出すよう設計されており ⁵⁸、例えば「重要部品Xはリードタイムが90日であり、安全在庫がない―高リスク」といったルールベースの分析を行い、システムがXの在庫増加を推奨し、逆に非重要部品の過剰在庫には警告を発するかもしれません。

また、IBMは「部品に関連する予定外ダウンタイムを50%削減」および「在庫コストを40%削減」といった成果も謳っています ⁵⁹。これらは非常に大胆で、最良ケースのシナリオを示している可能性が高いです。懐疑的に見るべき点として、ツールでダウンタイムを50%削減するというのは、部品の欠品によるダウンタイムを全て在庫改善で解消した場合を前提としている可能性があり、よく運営されている航空会社では部品起因のダウンタイム自体が極めて少ないため、50%削減は見込めないかもしれません。同様に、在庫コスト40%削減という数字も、企業が初めから過剰な在庫を抱えていた場合にのみ可能な数字であり（重工業などで予備在庫を積むケースはあるが、部品コストが高いために既に最適化されている商業航空ではあまり期待できません）、これらの数字は外れ値やマーケティング目的で厳選されたデータとして扱うべきです ⁵⁹。

技術的に見れば、IBMのツールは、使用状況データにおけるパターン認識程度を除いて、派手なAI/MLを利用している可能性は低い。IBM自体はAI（Watsonなど）に多く取り組んでいるが、ここに組み込まれているAIのレベルがそれを示唆するものではない。「予測的および処方的分析」という用語が使われている ⁶⁰ が、分析の専門用語では通常、予測＝何が起こりうるかを予測する（例：将来の部品故障や消費を予測する）、処方＝行動を提案する（例：この部品を今注文し、あの注文を減らす）ことを意味する。これらは価値があるが、比較的単純な統計モデルとビジネスルールで実現可能である。実際、Oniquaの従来のアプローチはかなりコンサルタティブで、各クライアントに合わせたルールや閾値を設定していた（例：ある部品が5年間動いていなければ余剰と判断し、昨年在庫切れを引き起こした部品であれば在庫を増やすなど）。IBMはそのロジックの一部を製品化した可能性が高い。

一部のユーザーにとっての欠点の一つは、IBM MRO IOが、あなたが保守や資産データをしっかり管理していることを前提としているかもしれない点である（これは多くの場合Maximoとともに販売されるため）。もし航空MROがMaximoを使用していなくてもMRO IOは利用可能だが、システムとの統合やデータの正確性の確保（設備の階層、重要資産の定義など）が重要となる。競合他社（Verusen）で見られた「データをそのまま取り込むことでデータ前提条件を排除する」という主張は、IBMが明示的に主張しているものではなく、IBMはデータクレンジングが必要であることを理解している。したがって、データ準備のフェーズが必要となるだろう。

IBMのソリューションは、おそらく特定の項目についてある程度ユーザー入力に依存している。例えば、システム上で部品を重要度（可否判定）に基づいて分類し、リードタイムやコストなどを設定する必要がある。その上で最適化が行われる。もし入力しなければ、部品の重要度を自動的に認識することはできない。つまり、その性能はあなたのデータガバナンスに依存する。

自動化の観点では、IBM IOは解析を自動化するが、必ずしも実行を自動化するわけではない。やるべきことのリストを提示するだけで、実際の発注はプランナーがERPで行う可能性がある。これは、例えば直接購買依頼書を作成するツールに比べると、統合された自動化というよりはマシなものだ。しかし、システムが独自に奇妙な決定を下すのを避けるために、「人間が介在する」アプローチを好む企業も存在する。

IBMの企業としての強みを考えれば、統合の側面はしっかりとサポートされている（特にIBM自身のMaximoや、IBMが頻繁に関わるSAPにおいては）。しかし改めて言えば、「プラグアンドプレイ」は期待できず、IBMまたはそのパートナーが、あなたの保守およびサプライチェーンのプロセスに合わせるために、かなり大規模なプロジェクトを実施する可能性が高い。

要するに、IBM MRO在庫最適化（Oniqua）は、堅牢な分析ソリューションであり、特に現状で在庫パフォーマンスの可視性が不足している場合には大きな改善効果をもたらす可能性がある。明らかな非効率（余剰在庫、潜在的な在庫切れ）を特定し、改善しやすい部分の最適化に強みを発揮する。断続的な需要や重要度は、統計的およびルールベースの手法で対応しているが、最新のAI技術を必ずしも採用しているわけではない。航空MROの管理者にとっては、これは画期的な新しいAIシステムではなく、むしろ漸進的な改善ツールと言える―基本をしっかり固める必要がある場合には全く問題ない。大幅な改善効果の主張には懐疑的になるべきであり、IBMにその数字が実際に何を意味するのかを問い、あなたの運用に類似した事例を求めるべきである。また、ツールの運用方法（分析ダッシュボードなど）があなたのチームに適しているかを確認すべきであり、プランナーがより分析的なワークフローを採用する必要があるかもしれない。もし企業文化がそれに対応できるなら、IBMのソリューションは体系的に改善を推進できる。しかし、監視なしにすべてを魔法のように最適化するブラックボックス型AIを期待しているなら、これはそのようなものではない（実のところ、そのようなプラグアンドプレイ形式のものはまだ存在していない）。

ERP 統合ソリューション（SAP SPPとOracle） ― 制限のある組み込みツール

専門ソフトを購入する前に既存のシステム機能を活用しようとする組織にとって、主要ERPベンダーからの選択肢を検討する価値はある。**SAP サービスパーツプランニング（SPP）**とOracleのスペアパーツモジュールが主要なものとなる。

SAP SPP: SAPのAPO（高度計画・最適化）スイートの一部であり、現在では部分的にSAP IBP（統合型ビジネスプランニング）でも利用可能なSPPは、2000年代半ばに大手産業企業と共同で開発された。マルチエシェロン在庫最適化、予測（断続的需要向けの特定のモデルを含む）およびサービスパーツ向けの流通必要量計画などの機能を含む。書面上は、SAP SPPは多くのことが可能であり、断続的需要に対してはクロストン予測手法を備えている（SAPはこれを「Forecast Strategy 80」として、部品のサイズと間隔に対してクロストンの指数平滑法を用いると文書化している） ¹¹。また、更新されたクロストンの変種（Croston-TSB）も備えている ⁶¹。このように、SAPは断続的需要に対する既知の学術的手法を取り入れている。また、横方向の再輸送のモデリング、統合された部品代替機能（製品互換性）を持ち、サービスレベルや充足率に基づいてネットワーク全体の在庫最適化を行うことが可能である。CaterpillarやFordが初期の影響力を持ち、ある時点ではSAP SPPが非常に高度な機能を備えていた（あるアナリストは、ベスト・オブ・ブリードのツールに匹敵すると考えた） ⁶²。

しかし、航空業界の現実は、多くの航空会社やMROがSAP SPPの潜在能力を十分に活用していないということである。その一因は、複雑さと必要な専門知識にある。SPPの設定には多くのパラメータの構成が必要で、各部品に対して予測モデルを割り当てる（真に断続的な需要にはクロストン法、その他には移動平均法など）、フェーズイン・フェーズアウトのフラグなどのマスターデータを維持し、そして何よりも各部品またはグループごとに目標とするサービスレベルを決定する必要がある。SAP SPPは必要なサービスレベルを自動で決定するものではなく、ユーザーが指示する。多くの場合、企業はABC/XYZ分類を用いて部品をグループ化し、グループごとにサービスレベル目標を設定する。このアプローチはユーザー定義であり、本当にトレードオフを最適化しているわけではない。本質的には最適化への入力となる。SAPはその入力を基に、最小在庫で目標を達成するための在庫要件を計算する（これは最適化部分であり、マルチエシェロン在庫に対してMILPソルバーを使用する可能性がある）が、もしその目標が適切でなければ、結果は経済的に全体最適とはならない。

もう一つの課題は、SPP用のSAPのUIとアラート機能が、専門ツールと比較して特にユーザーフレンドリーではなかった点である。これはSAP環境に統合されているため、IT部門には適しているが、プランナーの生産性向上には必ずしも寄与しなかった。多くの企業は、予測のみや流通計画のみなど、一部の機能だけを利用し、その他の業務はExcelで管理する結果となった。

今日の最先端という観点では、SAP SPPはある意味で時代に取り残されている。SAPの戦略的重点はIBPに移り、スペアパーツ向けのIBPは機能面でまだ追いついていない。例えば、高度なSPP機能が当初IBPに移行されなかった例もある。したがって、航空MROがSAPを利用して組み込みの計画ツールを採用する場合、すべてのニーズを満たすために多くのカスタマイズ（場合によってはサードパーティのアドオン）が必要になることに気付くだろう。例えば、ランダムな修理BOMへの対応や除去率の予測は標準機能では提供されず、飛行時間や使用量に基づいたカスタム予測を作成しなければならないかもしれない（消費履歴ではなく、稼働ベースからの予測について問い合わせたSAPユーザーもいる ⁶³ ― これはMRO特有の予測における標準機能のギャップを示している）。

Oracle: Oracleのサービスパーツプランニング（多くの場合、Oracle E-Business SuiteのValue Chain PlanningやOracle Cloud SCMの一部として提供される）もまた基本的な機能を提供する。予測（おそらくクロストン法または類似の断続的需要モデルの提供を含む）、マルチエシェロン在庫最適化、そして実行の統合をカバーしている。Oracleの強みは*Oracle eAM（エンタープライズ資産管理）*やそのERPとの統合にあるかもしれないが、この分野におけるリーダーとしてはあまり強調されていない。Oracleは一部のサービスパーツのベンチマーク調査にも参加しておらず ⁶⁴、積極的に推進されているわけではなさそうだ。適切に設定されれば十分に機能するものの、SAPと同様に古典的な手法と大規模なデータ準備に依存している。Oracleのアプローチは、最適化パックをライセンスしない限り通常は決定論的であり、特定の分布（しばしば正規分布またはポアソン分布）を仮定して信頼水準に基づいた安全在庫の計算などを行う。しかし、Oracleのシステムが自己調整したり、機械学習を利用したりすることを期待するのは非現実的である。

一般的な問題点（SAP/Oracle）： 両ERPソリューションは、航空MROが万能ではないという事実に苦しんでいる。これらのシステムは汎用的であるため、たとえば「交換を30日遅らせることのできる部品」といった項目を捉えるための標準パラメータは存在せず、そのためそのロジックを手動で組み込む必要がある（例えば、その部品のサービスレベルをやや低く設定するなど）。航空会社の保守プログラムを真にモデル化するためのカスタマイズは広範になり得る。例えば、SAPでランダムな保守BOMをモデル化するには、計画保守スケジュールを従属需要、計画外を統計的需要として取り込む必要があるなど、実現は可能だが複雑である。

また、ユーザー定義設定の過多も問題である。SAPやOracleでは、システムが期待どおりに動作しない場合があるため、プランナーはレビュー期間、ロットサイズルール、最低安全在庫など、多くの設定を維持しなければならない。これらの各設定は、エラーや最適でない選択のリスクとなる。このようにユーザーによる手動設定に依存するのは、より高度なソリューションが自動化によって排除しようとしている点である。

統合の利点： 既にSAPまたはOracleを利用している場合、そのモジュールを使用することで、マスターデータの大規模な統合作業が不要になり、すべてがひとつのシステムに収まる。これはデータの遅延や照合の問題がなくなるという利点がある。しかし、皮肉なことに、企業は依然としてインターフェースを構築する必要がある場合が多い―例えば、予測ツール（Smartなど）やERPモジュールでは対応できないカスタムデータウェアハウスにデータを引き出す場合などである。そのため、組み込みツールが十分な性能を発揮できず、他のツールで補完する場合には、統合の利点が相殺される可能性がある。

懐疑的に見ると、SAPやOracleの主張（主張する場合でも）は通常控えめで、大幅な％改善を公に示すことは少ない。これらのシステムの技術は堅実だが、最先端ではなく、主に20世紀後半の学術的手法をソフトウェアとして実装したものである。また、AI/MLに関する話題も乏しく（SAPが他の文脈で「機械学習を用いた需要駆動型MRP」について触れ始めた例はあるが、スペアパーツ計画に関しては特に言及していない）。

MROの重役にとっての結論は、もし既にこれらのシステムを持っているなら、それらを活用することは可能だが、チューニングのための長い道のりが予想され、専門ツールが提供するパフォーマンスレベルに到達しないかもしれないという点である。一方、ベンダーリスクは低い（SAPやOracleであれば長期にわたって存在し、すべてひとつのシステムに統合される）。懐疑的な調査では、SAPおよびOracleのソリューションは関連性を持つものの、自動化と洗練度の両面で専門ベンダーに遅れをとっているとの結論に達するだろう。これらは基準として機能し、多くの航空会社が最終的にこれらを補完または置き換えるために、前述の専門ツールのいずれかを採用してMROサプライチェーンを真に最適化する。

新興のAI参入企業（例：Verusen） ― バズワードから実態調査へ

2025年の市場調査は、サプライチェーン最適化のために登場するスタートアップ企業やAI駆動ソリューションの新たな波に触れずには終われない。MRO分野の一例としては、Verusenがあり、同社は自らを*「資産集約型製造業のMROサプライチェーンにおける在庫、支出、リスクを最適化するために特化して構築された唯一のAIプラットフォーム」* ⁶⁵と位置付けている。その大胆な主張は即座に懐疑心を呼び起こす―「唯一のAIプラットフォーム」という表現は明らかにマーケティングの誇張である（すでに見たように、多くの確立企業もさまざまな形でAIを主張している）。

Verusenのアプローチは、提供された資料に基づくと、データの取り込みとクレンジングに大きく注力している。彼らは*「ERP/EAMシステムからデータをそのまま取り込む」*といった点や、重複する資材を特定してデータを統合するためにAIを適用することを強調している ⁶⁶。これは、MROのデータがしばしば乱雑である（同じ部品がやや異なる名称で記録されるなど）という現実の問題に対処するものである。Verusenは機械学習（おそらくNLPやパターンマッチング）を用いて資材のマスターデータの合理化を図る。これは最適化の前提条件として価値があり、データが乱雑であれば、どんなに優れたアルゴリズムでも役に立たないからである。従って、Verusenは部品のための正確なシングルソース・オブ・トゥルースの構築と、最適化の機会（例えば、各プラント間で共有可能な余剰在庫の特定や、過剰供給時の安全在庫の削減）を見出すことに注力している。

Verusenや同様の新興企業が弱点とするのは、実際の予測や在庫アルゴリズムの深度が十分に証明されていない点である。彼らはAIについて広く言及するが、具体的な手法については触れていない。汎用的な機械学習モデルを用いて使用量を予測していると推測される（おそらく、消費量や他の要因を考慮するためのニューラルネットワークなど）が、詳細が示されていないため慎重になる必要がある。サプライチェーンにおいて、多くのスタートアップが純粋なML予測を試みたが、断続的需要に対して十分に調整された統計モデルに容易には勝てなかった（標準的なMLではゼロが多すぎるため予測が非常に困難である）。

Verusenはまた、クラウドベースで迅速な統合が可能であることを強調しており、従来のベンダーよりも**「プラグアンドプレイ」**に近いという約束を示唆している。しかし、ここで強い注意を促したい：どのプラットフォームであっても、企業のERPに接続し、関連するすべてのMROデータを取得することは決して真のプラグアンドプレイではない。 各ERPやMROシステムにはカスタムフィールドや拡張が存在し、データはしばしばクレンジング（重複部品、欠如したリードタイムなど）が必要となる。Verusenの「データをそのまま取り込む」⁶⁷という提案は興味深く、彼らのAIがノイズの中からも機能することを示唆している。おそらく、類似の項目をクラスタリングして重複を明らかにしたり、文脈から欠損リードタイムを推定したりできるかもしれない。これらは優れた機能であるが、経営層はそのAIが正しく動作するという証拠を求めるべきである。実際、2つの部品番号が、実際には異なる重要部品であるにもかかわらず、同一視されるアルゴリズムは望ましくない。

The 新規AI参入企業に対する懐疑的見解: 彼らは新しいアイデアと、多くの場合使いやすいインターフェース（モダンなUXやダッシュボード）をもたらします。彼らはデータ品質や簡単な「もし～ならどうなるか」の分析といった付随的な問題を解決するかもしれません。しかし、時として、古いソリューションに根付いた苦労して得たドメイン知識が不足していることもあります。AIスタートアップは、「部品ABCは飛行に使用できず、必要ならば3日延期可能」と明示的に教えない限り、その事実を知らないかもしれません。一方、業界特化型のツールはその論理を持っている可能性があります。したがって、どのAI新参者にも、航空特有の要求事項（ライフイング、認証の制約、規制遵守（適切な書類なしに代替部品を使用することはできない、など））をどのように考慮しているかを問い詰める必要があります。

とはいえ、新規参入者の中には、ドメインの専門家と提携したり、元MROプランナーを雇用してルールを構築する場合もあります。追いつくことは不可能ではありませんが、それは当たり前と考えるのではなく、検証すべき事項です。

その他の注目すべき新しいアプローチには、IoTや予知保全データを直接在庫計画に活用する方法が含まれます（一部のソリューションは、センサーデータを用いて部品の故障を予測し、その結果を在庫需要に結びつけます）。この分野は進化しており、在庫システムではなく、むしろ保全予測システムから生まれることが多いです。しかし統合は進行中であり、例えば、エンジンメーカーの予知保全ソフトウェアが、故障リスクの増加を「検出」したために特定のロケーションで特定のモジュールの在庫を推奨するかもしれません。MROの幹部は、設備のデータを活用して在庫最適化を含むエンドツーエンドのサービスを提供するOEMなど、より垂直統合された景色が現れるかもしれないことに注意する必要があります。

要するに、MRO向けのAI/MLを謳うスタートアップには注視すべきです – 彼らは全体の一部を提供するか、あるいは大手ツール（例えば、LokadやServigisticsにデータクリーニングAIを連携させるなど）と統合される可能性があります。成果を示すまでは、その大胆な主張に対して懐疑的な姿勢を保ちましょう。多くの場合、小規模な新規ベンダーは限られた事例研究しか持っておらず、それらはパイロットプロジェクトであり、完全導入ではありません。

また、これらの新システムが航空業界の広範なプロセスやレガシーシステムとどのように共存するかも考慮すべきです。既存のERPに結果を容易にエクスポートできなかったり、監査用に意思決定のログを記録しなかったりする派手なAIツールは、障害に直面するでしょう。幹部は、そのようなツールがワークフローに統合できることを確認したがるでしょう（これは皮肉にも、他のソフトウェアと同様に統合作業が必要になるかもしれません）。

結論と提言

この懐疑的な市場調査は、航空MRO予備部品の難解な最適化課題を解決しようとする様々なソリューションのエコシステムを明らかにします。どの解決策も万能ではありませんし、高尚な約束は常に技術的な疑問やパイロット試験によって検証されるべきです。

しかし、最先端の技術は存在します。すなわち、確率的予測、多段階最適化、そしてパターン認識のためのAI/MLは、適切に実装されればパフォーマンスを大幅に向上させる可能性があります。Lokadのようなベンダーは、航空向けにこれらの手法の最前線を推進しており、PTC ServigisticsやSyncronといった大手は、より曖昧なマーケティング言語の裏に多くの先進的な機能を組み込んでいます。ToolsGroup、Baxter、Smartなどは、組織のニーズに合致すれば大きな利益をもたらす強固な能力を持っています – ただし、スイッチを入れるだけで魔法が起こると期待してはいけません。内部プロセスの成熟度とデータ品質は依然として重要です。

共通するテーマは、自動化とユーザー制御のトレードオフです。高度に自動化されたAI駆動システムは、数万の部品番号という規模と複雑性に対応できますが、「ブラックボックス」のように感じられるかもしれません。一方、従来型や手動のシステムは、ユーザーにより多くの操作の自由度を与えますが、大規模カタログでは複雑性が増すという代償があります。理想は、（予測や最適在庫の計算といった）骨の折れる作業を自動化しながら、例外時にプランナーが透明性と上書きの能力を持つシステムです。ベンダー評価の際、MRO幹部はこう質問すべきです：システムは需要やリードタイムの変化に自動で対応するのか、それとも設定の微調整が必要か？ 多数の最小/最大または分類ルールの維持をあなたに委ねるベンダーは、技術が劣っている（あるいは、技術を十分に活用していない）兆候です。

あなたのMROシステムに「プラグ＆プレイ統合」を謳うベンダーには非常に懐疑的であるべきです。航空MROのIT環境は多様であり、AMOS、TRAX、Ultramain、Maximo、SAP、または自社開発のシステムを使用している場合でも、最適化ツールの統合にはデータフィールドのマッピングや、場合によってはデータクリーニングが必要となります。数週間で最小限のIT労力で展開できると主張するベンダーは、作業を過小評価しているか、非常に狭い範囲を前提としている可能性があります。統合とテストのための十分な時間を確保し、これらの主張を検証するために早い段階でIT担当者を巻き込むのが賢明です。

もう一つ注意すべき赤信号は、あまりにも良すぎる事例研究やアナリストレポートに依存していることです。多くの事例研究では、課題や基準値について触れられていません。例えば、「在庫が30％削減された」という話は素晴らしく聞こえますが、もしそもそも計画システムがなかったなら、どんな適切なプロセス改善でも30％の削減は達成可能です。同様に、「サービスレベルが99％に改善された」というのは、実際には過剰在庫を意味している可能性もあります。常にさらに深掘りし、文脈における前後の指標を求め、できれば磨かれた引用に頼るのではなく、直接参照クライアントに話を聞くようにしましょう。

逆に、ベンダーが具体的な技術的詳細や方法論を提供する場合、それは良い兆候です。すなわち、彼らには単なる流行語ではなく、具体的な手法があるということです。例えば、Smart Softwareが⁷でブートストラップ手法を公然と説明したり、Lokadが微分可能なプログラミングについて議論したりするのは、実質的な内容を示しています。「AI/ML」をただ並べ立て、問題への適用方法を説明しないベンダーは、購入者が疑問を呈さないことを前提にしている可能性がありますが、あなたは必ず質問すべきです。例えば、月の大半で使用実績がゼロの部品が突然必要になった場合、彼らの機械学習はどのように対応するのか – どのような入力を使用するのかを説明させましょう。専門用語だけで曖昧な場合は注意が必要です。もし彼らが「類似部品をクラスタリングし、艦隊の運用時間と過去の除去実績を組み合わせたベイジアンモデルを使用している」と明確に述べられるなら、少なくとも一定のアプローチを持っていると言えます。

要約すると、これらのソリューションを評価するMRO幹部のために：

• ツールと問題をマッチさせる：もし激しい需要変動や在庫切れに悩んでいるなら、実績のある確率的予測手法を持つベンダー（Lokad、ToolsGroup、Smart、およびある程度Syncron）を優先すべきです。もし問題が過剰在庫や可視性不足であるなら、処方型分析ツール（IBM/OniquaまたはBaxter）で無駄を削減できるかもしれません。
• チームの能力を評価する：非常に高度なシステムは、連携するために熟練したプランナーやアナリスト、あるいはベンダーの専門家のサポートが必要です。シンプルなシステムは、規模の小さいチームで運用できるかもしれませんが、最適化の隅々のメリットを引き出せない可能性があります。
• データと統合作業の計画：どのソフトウェアを選んだとしても、部品マスターや使用データのクリーンアップ、そしてインターフェースの確立に投資する必要があります。AIほど華やかではありませんが、これは基盤となる作業です。
• パイロットと検証：部品の一部または特定の拠点でパイロット試験を実施しましょう。ベンダーの派手なアルゴリズムが実際に妥当な提案を生み出すか確認してください（例：重要部品の在庫が全くない、または安価な部品が過剰に在庫されている等）。シナリオをシミュレーションして最適化をチェックしましょう。優れたベンダーはこれに協力しますが、疑わしいベンダーは過剰な検証を避けるでしょう。

航空MROの在庫問題はしばしば*「非常に困難」*⁶⁸と評されます – 実際、その通りです。しかし、今日のツールはその課題に立ち向かっています。誇大広告を払いのけ、検証可能な能力に焦点を当てることで、MROは部品管理を真に最適化し、具体的な信頼性向上とコスト削減を実現するソリューションを選ぶことができます。懐疑論者のモットーを忘れずに：神のみを信じ、他は―データを示せ。各ベンダーは、あなたの運用状況においてその主張を裏付けるデータを提示すべきです。適切な精査を行えば、単なるマーケティングの約束を超え、サプライチェーンにおける実績をもたらすソフトウェアパートナーを見つけることができます。

脚注