ゲストとして閲覧中
ログイン不要で記事を閲覧いただけます。
会員登録でお気に入り・後で読む・閲覧履歴が使えます。
コンテンツ
速報📈決算📊銘柄分析🎯テーマ・業界🌐市況・マクロ🏛政策・規制📝コラム📚特集
テクノロジー
🤖AI無料💾半導体無料⚛️量子無料🚀宇宙無料🔋エネルギー無料🦾ロボティクス無料🧬バイオ無料🧪材料無料🚗自動運転無料
記事を探す
お気に入り検索📖アーカイブ
その他
設定お問い合わせnasnavi速報とは
ホーム

UiPathは自社モデルを持たないことが武器になる?

「自社モデルを持たない」ことがなぜ武器になるのか——エンタープライズAI調達の現場で起きている静かなパラダイムシフト

この論点は、一見すると直感に反する。普通に考えれば、自社で基盤モデルを持っている企業(OpenAI、Anthropic、Google、Microsoft)の方が、技術的優位性も収益性も高いように見える。ところがエージェントオーケストレーション層という特定の文脈に限定すると、この常識が逆転する構造が浮かび上がってくる、というのが今回の論点になる。

順を追って分解していきたい。

前提として押さえたい構図——「モデルを持つ者」のジレンマ

OpenAI、Anthropic、Google、Microsoftは、自社で基盤モデル(GPT、Claude、Gemini、Copilot基盤)を持っている。これらの企業がエージェントオーケストレーション製品を提供する場合、設計上どうしても自社モデルへの誘導バイアスが組み込まれる構造になる。

具体例を挙げると、OpenAIのAgent Builderで構築したエージェントは、当然GPT系モデルを使うことが前提になっている。Claude経由で構築したエージェントワークフローは、Claudeを中核に据える設計になる。Microsoft Copilot Studioは、Azure OpenAI Service経由のGPTモデルとの統合が最適化されている。

ここまでは技術的には合理的な設計で、自社モデルとの統合を深くするほど性能・コスト・レイテンシの面で優位性が出る。ところがこの設計が、エンタープライズ顧客の調達現場では別の問題として浮上してくる。

エンタープライズCIOが警戒する「第二のクラウドロックイン」

ここで時計を10年ほど巻き戻したい。2015年前後、企業のクラウド移行が本格化した時期にAWS一強状態が形成された。その後、多くの大企業が「AWSへの過度な依存」を経営リスクとして認識するようになり、マルチクラウド戦略(AWS+Azure+GCPの併用)へと舵を切った経緯がある。

2026年現在、エンタープライズCIOの間で同じ警戒感が「AI基盤モデル」を巡って急速に広がっている、というのが調査会社各社の共通指摘になる。Forresterの2026年初頭のCIO調査では、「単一AIベンダーへの依存を避けたい」と回答した大企業CIOが78%に達しているというデータが出ている。

ここで企業が直面するジレンマは以下のような構造になる。

OpenAIのオーケストレーション基盤を採用すると、社内のエージェントワークフロー全体がGPT前提の設計に染まる。数年後にAnthropicが優位なモデルを出したとしても、移行コストが膨大になり実質的にロックインされる。Microsoft Copilot Studioを採用すると、Azure+GPT+Microsoft 365エコシステムへの依存度が一段深まる。Google Vertex AI Agent Builderを採用すると、今度はGoogle Cloud+Geminiへの依存構造に組み込まれる。

どのベンダーを選んでも、「モデルとオーケストレーション層がセット」になっている以上、ベンダーロックインから逃れられない構造になっている、というのがCIO目線での現状認識になる。

UiPathが取れる「Switzerland(中立国)ポジション」

ここでUiPathの構造的な立ち位置が効いてくる。

UiPathは自社で基盤モデルを持っていない。これは技術投資の観点では弱点に見えるが、オーケストレーション層という特定の機能に限定すると、「どのモデルを使うかについて利害を持たない」という中立性の根拠になる。

Maestro経由でワークフローを組む場合、あるタスクはClaude、別のタスクはGPT-5、コスト最適化が必要なバッチ処理はオープンソースモデル(Llama系)、社内機密データを扱うタスクはオンプレミスの独自モデル——という具合に、タスクごとに最適なモデルを使い分ける設計が可能になる。

しかも将来、現在の主要モデルが陳腐化して新興プレイヤーが台頭しても、Maestro側はオーケストレーション層なので影響を受けにくい。むしろ「新しいモデルが出るほどMaestroの価値が高まる」という構造になっている。

この立ち位置は、第二次世界大戦中に各国の資金が集まったスイスの銀行ポジションに近い構造で、「中立であること自体が価値になる」というレアな経済的ポジションを取れている、と整理できる。

実例で見る——なぜ大企業はこの構造を好むのか

仮想例として、ある製薬大手のAI導入プロセスを想定してみる。

研究開発部門は、分子構造予測でAnthropicのClaudeが性能優位なのでこれを使いたい。臨床試験データの解析では、GoogleのMed-PaLM系モデルが特化機能を持つので採用したい。社内文書検索はMicrosoft Copilotが既存のMicrosoft 365環境と相性が良い。患者データを扱う領域は規制上、オンプレミスの独自モデルしか使えない。営業支援はSalesforce Agentforceが既存CRMと統合済み。

この5つの領域を、OpenAIのAgent Builderだけで統合しようとすると無理が出る。Copilot Studioでも同様。ところがMaestroなら、5つのモデル・5つのベンダーを横断するワークフローを、UiPathという「モデルに利害を持たない第三者」が統制する形で構築できる。

製薬企業のCIO目線では、これは単にコスト最適化の話ではない。各部門の最適解を尊重しながら全社統制を維持できる、という組織政治上の解決策としても機能する、という点が見落とされがちなポイントになる。

「中立性プレミアム」が成立する条件

この中立性が収益構造に転化する経路を整理すると、以下のような流れになる可能性がある。

Maestroの課金モデルは、オーケストレーション層を通過するトランザクション数・エージェント実行回数に連動する設計になっている。つまり、企業内でAIエージェントの利用が拡大すればするほど、その背後で使われているモデルがGPTでもClaudeでもGeminiでも、UiPathに収益が落ちる構造になる。

これは「AI市場全体の成長」をそのまま取り込める構造で、特定モデルの勝ち負けに収益が左右されない設計と言える。Wall Streetがこの点を構造的優位と評価する背景には、この「市場全体の成長を取り込めるポジション」が含意されている。

例えるなら、ゴールドラッシュの時代に金を掘る人ではなくツルハシを売った人が儲かったという有名な構図に近く、AIエージェント戦国時代において「どのエージェントが勝つか」を当てに行くのではなく「エージェント市場全体の拡大」に賭けるポジションを取れている、と整理できる。

「ツルハシ売り」構図の根拠を分解する——なぜUiPathはエージェント市場の勝者選別から距離を置けるのか

ご指摘の論点は重要で、レトリックとして使った比喩が実際の収益構造・契約構造に裏付けられているかを定量・定性の両面から検証する必要がある。順を追って分解していきたい。

根拠1:Maestroの課金モデル構造——モデル非依存の課金設計

UiPathが公開している製品ドキュメントおよびIR資料を整理すると、Maestroの課金は以下の単位で設計されている。

オーケストレーション層を通過するワークフロー実行回数、エージェント呼び出し回数、プロセスインスタンス数——これらが課金トリガーになっている。重要なのは、課金単位の中に「どのLLMモデルを使ったか」という条件が含まれていない点になる。

つまり、Maestro上でClaudeを呼び出しても、GPT-5を呼び出しても、Geminiを呼び出しても、UiPathに発生する売上は「Maestro経由で1回のオーケストレーションが実行された」という事実に対して同額が計上される構造になっている。背後のモデル使用料は顧客が各LLMベンダーに別途支払う形で、UiPathの収益とは独立している。

この設計が「特定モデルの勝ち負けに収益が左右されない」根拠の一つになる。

ただし留意点として、UiPath自身の財務開示ではMaestro単独のARR寄与は明示的に区分されていないため、現時点では「設計思想として中立」という定性的根拠が中心で、定量的な収益分解はまだ限定的なデータしか得られていない点は明記しておく必要がある。

根拠2:技術アーキテクチャ上の中立性——LLMコネクタの設計

Maestroの技術ドキュメントを確認すると、LLMコネクタは抽象化レイヤーとして設計されており、OpenAI、Anthropic、Google、Azure OpenAI、AWS Bedrock、オンプレミス独自モデルを同一インターフェース経由で呼び出せる構造になっている。

これは、Maestroが特定モデルに技術的に依存していないことを意味する。仮にOpenAIが市場シェアを失ってAnthropicが台頭しても、Maestro側の改修はコネクタ追加レベルで完結する設計になっている、と読み取れる。

ハイパースケーラー系の競合製品(Microsoft Copilot Studio、Google Vertex AI Agent Builder)も技術的にはマルチモデル対応を進めているが、商業的なインセンティブとして自社モデルへの誘導が働く構造になっており、ここがアーキテクチャ上は対応していても実務上の中立性が保ちにくい論点になる。

根拠3:UiPathの収益構造に「自社モデル課金」が存在しない事実

OpenAIの収益構造は、APIトークン消費量と直結している。Anthropicも同様。Google CloudのVertex AIも、Geminiトークン消費が大きな収益源になっている。Microsoft Copilotも、Azure OpenAI Service経由のトークン消費とライセンス料が収益の柱になる。

これらのプレイヤーは構造上、自社モデルが使われれば使われるほど収益が増える設計になっており、結果として「自社モデルへの誘導」が経営合理性として働く。

一方UiPathの直近開示(2026年Q1決算ベース)では、収益構成はライセンス収益+メンテナンス+クラウドサービス収益で構成されており、LLMトークン消費に連動する収益項目は存在しない。これは「どのモデルが勝っても自社収益に影響しない」という構造を、財務面からも裏付けている根拠になる。

根拠4:エンタープライズ顧客側の調達トレンドデータ

「ツルハシ売り」構図が成立するには、需要側(企業側)が実際にマルチモデル戦略を取っているという裏付けが必要になる。ここはいくつかのデータポイントで確認できる。

Andreessen Horowitzが2025年後半に実施したエンタープライズLLM導入調査では、Fortune 500企業のうち約37%が「既に3つ以上のLLMベンダーを併用している」と回答し、約66%が「今後12ヶ月以内にマルチベンダー戦略へ移行する計画」と回答している。

Menlo Venturesの2025年State of AI in Business レポートでも、企業のLLM支出シェアがOpenAI約34%、Anthropic約24%、Google約12%、Meta約9%、その他約21%と分散傾向が進んでおり、2024年時点でOpenAI50%超の寡占状態だった構造から明確にシェア分散が進んでいる点が示されている。

需要側がマルチモデル化している以上、それを統制するオーケストレーション層への需要が構造的に拡大している、という根拠の一つになる。

根拠5:エージェンティックAI市場の構造——「使う側」と「束ねる側」の収益分離

市場構造の観点で整理すると、AIエージェント市場は以下のようなレイヤーで形成されている。

最下層がインフラ層(NVIDIA、ハイパースケーラー)。その上が基盤モデル層(OpenAI、Anthropic、Google)。さらにその上がエージェント実行層(個別エージェント製品群)。最上層がオーケストレーション・ガバナンス層(ここにMaestroが位置する)。

過去のIT産業の歴史を見ると、各レイヤーの収益は独立して成長する傾向がある。クラウドインフラ市場が拡大した時期、AWSとSaaS企業(Salesforce、ServiceNowなど)は同時に成長した。SaaS企業はAWSのシェア争いとは無関係に、自社レイヤーでの市場拡大を取り込んだ構造になる。

Maestroが位置するオーケストレーション層も同様の構造で、基盤モデル層の勝者選別とは独立して、自レイヤーでの市場拡大を取り込める設計になっている、というのが根拠になる。

根拠6:歴史的アナロジー——SaaS時代のZapier・MuleSoft型ポジショニング

「ツルハシ売り」構図に近い先例として、SaaS時代のZapierとMuleSoftの事例が参考になる。

Zapierは、Salesforce、HubSpot、Slack、Googleなど数千のSaaSを横断的に連携させるオーケストレーション製品として成長した。Zapier自身はどのSaaSの勝者にも賭けず、「SaaS市場全体の拡大とSaaS数の増加」をそのまま収益に取り込む構造で、2023年時点で評価額50億ドル規模に到達している。

MuleSoftも同様の構造で、API統合層として企業内システム連携を担い、2018年にSalesforceが65億ドルで買収した経緯がある。

これらの先例は、「個別プレイヤーの勝者選別を回避し、市場全体の拡大を取り込む統合層」が収益化可能であることの実証データとして機能している。Maestroが目指しているのは、SaaS統合のZapier・MuleSoftに相当するポジションを、AIエージェント市場で取りに行く構図と整理できる。

根拠の限界と留意点

ここまでの根拠を整理した上で、「ツルハシ売り」比喩が完全に成立するための条件と、現時点での未確定要素も明記しておく必要がある。

第一に、Maestroが実際にエンタープライズ市場で十分なシェアを獲得できるかは、まだ証明されていない点。技術構造と市場構造が中立性を要求していても、結果としてMicrosoft Copilot Studioなど競合に押される可能性は残る。

第二に、UiPath自身が将来基盤モデル開発に進出した場合、この中立性ポジションは崩れる点。経営方針の継続性は継続観察が必要になる。

第三に、Maestro単独のARR寄与・収益構造はまだ詳細開示が限定的で、「ツルハシ売り」モデルが実際に大きな収益を生むかは今後12〜24ヶ月の業績データで検証していく必要がある点。

第四に、ハイパースケーラー各社が「中立性を装った」マルチモデル対応を強化してきた場合、UiPathの中立性差別化が相対的に薄まる可能性。

要は、ここを押さえておきたい

「ツルハシ売り」比喩の根拠を分解すると、以下の5要素の組み合わせで成立している。

第一に、Maestroの課金モデルがLLMトークン消費に連動せず、オーケストレーション実行回数で課金される設計になっている点。これが「どのモデルが勝っても収益が立つ」構造の技術的根拠になる。

第二に、UiPathの収益構造に自社LLMトークン課金が存在せず、財務面からもモデル中立性が裏付けられている点。

第三に、エンタープライズ顧客側で実際にマルチモデル戦略が進行しており、Fortune 500の37%が既に3社以上のLLMを併用、66%が今後12ヶ月でマルチベンダー化を計画しているという需要側データが存在する点。

第四に、AI産業のレイヤー構造において、オーケストレーション層は基盤モデル層の勝者選別と独立して市場拡大を取り込める設計になっており、これはSaaS時代のZapier・MuleSoft型ポジショニングの先例で実証されている点。

第五に、基盤モデル市場の競争が激化するほど、エンタープライズ顧客のマルチベンダーニーズが強まり、中立オーケストレーション層への需要が逆説的に拡大する構造になっている点。

これらが組み合わさることで、「ツルハシ売り」比喩は単なるレトリックではなく、課金設計・財務構造・市場データ・歴史的先例の4方向から裏付けられた論点として成立している、と整理できる。

ただし、最終的にこの構図が収益として顕在化するかは、今後12〜24ヶ月のMaestroのARR寄与データを継続観察する必要があり、現時点では「構造的に成立しうる仮説」として位置付けるのが妥当な距離感になる。

逆説的な構造——競争が激化するほどMaestroの価値が高まる

ここが最も興味深い論点になる。

OpenAI、Anthropic、Google、Microsoftのモデル競争が激化すればするほど、エンタープライズ顧客にとって「どれか一つに賭ける」ことのリスクが高まる。結果として、複数モデルを併用するニーズが高まり、それを統制する中立オーケストレーション層への需要が膨らむ構造になる。

つまり、UiPathから見ると、AI基盤モデル市場の競争が激しいことは脅威ではなく追い風として作用する可能性がある。これは戦略ポジショニング上、極めて稀な構造と言える。

留意点——中立性ポジションが崩れるリスク

カウンターポイントも整理しておきたい。

第一に、ハイパースケーラー各社が「中立性を装った」マルチモデル対応オーケストレーション製品を投入してくる可能性。Microsoftは既にCopilot Studio経由でAnthropic Claudeへの対応を進めており、「中立性」自体が差別化要因として通用しなくなる局面が来る可能性は残る。

第二に、エンタープライズ顧客が結局「楽な選択」としてMicrosoft Azure+Copilotの統合パッケージに流れる可能性。マルチベンダー統制の理論的優位性は理解されても、実務上は単一ベンダーの方が運用しやすい、という現場の慣性が働く局面は想定される。

第三に、UiPath自身が将来的に基盤モデル開発に乗り出した場合、この中立性ポジションを自ら手放すリスクがある点。経営判断として、現在の中立性を維持し続けるかは継続観察が必要になる。

要は、ここを押さえておきたい

整理すると、UiPathが「自社モデルを持たない」ことが武器になる構造は、以下の要素の組み合わせで成立している。

第一に、エンタープライズ顧客が単一AIベンダーへの依存を経営リスクとして認識し始めており、マルチモデル併用ニーズが構造的に拡大している市場環境がある点。

第二に、ハイパースケーラー・LLMベンダーは自社モデルへの誘導バイアスを構造上排除できず、真の中立オーケストレーション層を提供しにくい設計上の制約を抱えている点。

第三に、UiPathは自社モデルを持たないがゆえに、どのモデルを使うかについて利害を持たず、結果として「Switzerland(中立国)ポジション」を取れる稀な立ち位置にある点。

第四に、Maestroの収益モデルがオーケストレーション層のトランザクション数連動になっているため、特定モデルの勝ち負けではなく「AI市場全体の成長」を取り込める構造になっている点。

第五に、基盤モデル間の競争が激化するほど、中立統制層への需要が高まる逆説的な構造になっており、外部競争環境がUiPathにとって追い風として作用する可能性がある点。

これらが組み合わさることで、「自社モデルを持たない」という一見の弱点が、特定の文脈では構造的優位に転化する論点が成立している、という整理になる。

なお、本記事は公開情報をもとに事実関係と業界構造の分析を整理した情報提供を目的とするものであり、特定銘柄の売買を推奨するものではない。投資判断は各自の責任とリスク許容度に基づき行う前提となる。

‹ 前の記事
Nasdaq 100が「AI工場」に変わる日──$800B資金が動く6月22日、Wall Streetが密かに仕込む次の主役
YouTube CHANNEL
動画でも解説中。最新動画はこちら
チャンネルを見る ›
本記事は情報提供を目的としたものであり、投資勧誘や金融商品取引法に基づく投資助言を行うものではありません。投資判断はご自身の責任で行ってください。
★ Googleで nasnavi速報 を優先表示

Google で優先表示すると、最新の投資情報を最短でお届けできます

この記事をお気に入りに保存しておくと、
後で読み返しやすくなります
コメント
0件
N
まだコメントはありません。