（この記事はもともとForbes.comに掲載されたものです）
Yu Fang氏は、Sonatus の共同創業者兼CTOであり、分散システムおよびAI 対応の車両アーキテクチャを専門としています。
何十年もの間、エンタープライズソフトウェアは「1つの製品を開発し、多くの組織に販売する」という単純な前提に基づいて機能してきました。Microsoft Office、SAP、Lotus Notesなどがその例です。中核となるソフトウェアは、幅広い用途に対応できるよう設計されていました。カスタマイズは、どちらかといえば顧客側の課題とされていました。
ソフトウェアが高価で、開発に時間がかかっていた時代には、その前提は理にかなっていました。顧客ごとに異なるソリューションを開発する余裕などなかったのです。標準化こそが、経済的に唯一合理的な選択でした。しかし、ソフトウェア開発の経済性が根本的に変化した今、その論理はもはや成り立ちません。
「画一的な対応」の代償
汎用ソフトウェアには、常に隠れたコストが伴っています。それは、特定のユースケースやワークフローに合わせて汎用製品を調整するために費やされる時間や、その過程で生じるエラーによって測られるものです。こうしたコストは現実のものであり、単に請求書には記載されていないだけなのです。
ユースケースやワークフローが複雑な業界では、その負担が積み重なり、さらに増大する可能性があります。自動車の不具合診断をその代表的な例として挙げましょう。 北米の大手自動車メーカー（OEM）は、400億ドルを超える保証引当金を計上しています。2026年第1四半期だけでも、米国では1,210万台の車両がリコールされ、その47％は無線（OTA）によるソフトウェア更新で修正されました。一般的なユースケース向けに設計された汎用ツールでは、特定のユースケースに対応することはできません。
車両が整備ベイに入庫すると、整備士は診断上の難題に直面します。サスペンションに異常な挙動が見られたことはわかっているものの、その原因は何か？ 部品の故障か？ それともソフトウェアの不具合か？ 一般的な診断ツールでは症状は特定できても、原因を突き止めることはほとんどできません。その結果、多くの場合、手間のかかる手作業による診断プロセスを余儀なくされ、整備士が退職すると、その専門知識も一緒に失われてしまうのです。
今日における「カスタム」の意味
AI ソフトウェア開発の経済性を根本的に変えた――それは漸進的な変化ではなく、構造的な変化である。
かつては、ソフトウェアの開発に時間がかかったため、カスタムソリューションは高価なものだった。しかし、その制約は薄れつつある。AI は、コード生成、パターン抽出、自動化されたワークフロー設計を通じて、開発を加速させる。かつては数ヶ月もの開発期間を要していた作業も、今ではその数分の1の時間で範囲を定義し、構築することが可能になった。
しかし、カスタマイズを正当化する理由はスピードだけではありません。より重要な理由は、AI を基盤とした変革は、顧客の既存の現実――つまり、顧客のデータ、ツール、ワークフロー――に根ざしていなければならないということです。すべてを置き換えて、組織に一から学び直させるようなことはしません。既存の環境にAI を組み込むのです。既存のプロセスをそのまま受け入れ、それをより高速に、より一貫性のある、そしてよりスケーラブルなものにしていくのです。
こう考えてみてください。空白のスプレッドシートも、あらかじめ設定されたテンプレートも、どちらも数値を保存するものです。しかし、ビジネスに合わせて適切なフィールドや数式がすでに組み込まれているテンプレートを使えば、答えを数時間でなく、数分で導き出すことができます。この原理を、診断ワークフローやサプライヤーの品質管理プロセス、あるいは車両管理システムに当てはめてみてください。一般的な出発点と、特定の目的に合わせて構築された出発点との違いは、表面的なものではなく、運用上のものです。
並行して実行される2つの変換
AI を基盤としたカスタムソリューションのアプローチにより、汎用ソフトウェアではこれまで同時に実現することが困難だった2つの変革が可能になります。
第一に、人間の専門知識を実用化することです。経験豊富なエンジニアが培ってきた知識、意思決定のパターン、診断的判断は、AI システムにますます取り込むことが可能になり、組織全体で活用できるようになります。その結果、組織の能力が向上し、知識がサイロ化されることなく共有され、専門知識が組織を去るのではなく、蓄積されていくようになります。
2つ目は、手動によるワークフローをエージェント主導のワークフローへと転換することです。多くの運用プロセスでは、依然として人が意思決定の調整、システム間の業務の引き継ぎ、日常的な例外処理を担当しています。エージェント主導のワークフローでは、こうした調整業務の多くをAI に移行させることで、定義されたガイドラインの範囲内で運用しつつ、より自律的で適応性が高く、拡張性のあるプロセスを実現します。
機械知能が主体的なワークフローを支えています。これらがつながることで、個々のタスクの自動化にとどまらず、仕事の進め方そのものを再構築するほどの生産性向上の基盤が生まれます。
なぜ汎用的なAI では不十分なのか
汎用AI は高性能で、利用しやすく、急速に進化しています。しかし、それだけでは、リスクの高い環境の多くにおいて十分とは言えません。
その理由は次のとおりです。汎用的なAI は、パターンの認識や、質問と意味的に類似した情報の検索に優れています。また、類似した状況で有効だった対策を要約することも可能です。しかし、自社の製品、プロセス、運用環境に関するモデルがなければ、特定の条件下で発生した特定の不具合を何が解決するかを確実に判断することはできません。
これは、「AI 」というカテゴリー自体の制限ではありません。これは、そのタスクに必要な専門知識や運用上の文脈を欠いている「AI 」の制限なのです。
一方、専用に開発されたAI は、表面的な類似性だけでなく、システムやコンポーネント間の関係性を理解する「構造化検索」を採用しています。このツールは、ドメイン固有のデータ、運用上のコンテキスト、およびエンジニアリングの知見を組み合わせることで、診断精度を向上させ、事案の複雑さに応じてアプローチを適応させ、経験豊富な従業員が退職した際に失われてしまう可能性のある組織の知見を蓄積します。
新たな基準
カスタマイズはもはや、多額の予算や長い期間を要する贅沢な選択肢ではありません。複雑でリスクの高い環境で事業を展開する組織にとって、カスタマイズはますます効果的な前進の道の一つとなりつつありますが、適切なアプローチは依然として、ユースケース、既存のインフラ、および組織の準備状況によって異なります。
保証やリコール費用に数十億を費やしているOEMメーカーで、ソフトウェアが不足しているケースはめったにありません。課題となっているのは、それらのソフトウェアの多くが、情報を管理するために構築されたものであり、そうしたコストの要因となる具体的な故障モードや技術的背景、サービスワークフローを理解するために設計されたものではないという点です。
そのギャップを埋められる組織は、自社の業務実態に基づいた解決策を構築し、誤りが生じた場合のコストが「リコール車両」や「利益率の低下」といった結果として数値化されるプロセスに、AI を取り入れることで、それを実現するだろうと私は考えています。
そこで、汎用的なAI ツールに投資する前に、どの分野において専門知識、ワークフローの複雑さ、組織内のノウハウが最大の障害となっているかを検討してください。そうした分野こそが、専用に設計されたAI の導入が最も適している場合が多いのです。その上で、基盤となるデータがソリューションの学習に十分なほど構造化され、アクセス可能であるか、また既存のツールやワークフローを全面的に置き換えることなく統合が可能かどうかを評価してください。
かつてはカスタムソフトウェアは例外的な存在でしたが、今ではそれが標準になりつつあると私は考えています。それは、目標が変わったからではなく、経済的な状況が変わったからです。カスタムソリューションが最も付加価値をもたらす分野を見極め、それに応じて構築しようとする組織にとっては、大きなチャンスがあります。