Elastic、OpenAI統合を拡大する一方でエンタープライズAIのモデル非依存戦略を維持
Elasticは、単一のモデルプロバイダーへの依存を避けるエンタープライズAI戦略を構築しながらも、OpenAI技術の活用を拡大した。この動きは、ElasticとOpenAIの連携深化を取り上げた投資家向けレポートを通じてGoogle Newsにも掲載された。
この捉え方は一面では正しいものの、誤った印象を与えるおそれもある。公開されている会社資料によれば、OpenAIはElasticが展開するモデル、クラウドサービス、検索ツール、オープン標準の幅広い組み合わせの一部に位置付けられている。新たな排他的提携が成立したことを示すものではない。
この違いは重要だ。Elasticは、エンタープライズAIアプリケーションの下層にあるコンテキストレイヤーの主導権を巡って競争している。このレイヤーは企業情報を検索し、権限を適用し、モデルの挙動を監視し、生成された回答を業務ワークフローへ接続する。
OpenAIはChatGPTを通じてモデルと大きなアプリケーション基盤を提供する。Elasticは、それらのモデルに必要なデータを準備し、管理するインフラであり続けたい考えだ。したがって主な競合相手は、単なる別の検索ベンダーではない。AIプラットフォームの所有者が、検索、オーケストレーション、インターフェース、ガバナンスを垂直統合型製品に取り込めるという発想そのものだ。
Elasticが実際に拡大したもの
Elasticは既存のOpenAI統合戦略を拡張しているのであり、自社プラットフォームをOpenAI中心の製品へ置き換えているわけではない。
最も明確な実例は、2025年7月にSlackで導入された社内アシスタント「ElasticGPT」だ。Elasticは、社内システムに保存された情報を用いて従業員の質問に答えるためにこれを構築した。
このアシスタントは、Elasticが検索拡張生成とMicrosoft Azure OpenAI経由のGPT-4oを組み合わせたものと説明するSmartSourceを使用している。検索拡張生成（RAG）は、言語モデルに回答を作成させる前に、関連するソース資料を探し出す仕組みだ。
このアーキテクチャでは、モデルが学習データだけで回答するのではなく、選別された企業コンテキストを受け取る。Elasticsearchがベクトルデータベースおよび検索システムとして機能し、GPT-4oが取得した資料を読みやすい回答に変換する。
Elasticによると、最初の実装では主要な2つの情報源を統合した。1つは、戦略、チーム、製品、プロセスに関する情報を含む社内Confluenceサイト。もう1つは、人事および情報技術のポリシーを扱うServiceNow記事のコレクションだった。
同社はさらに、シングルサインオン、アクセス制御、パフォーマンス監視、ガバナンスプロセスを追加した。エンタープライズ向けアシスタントは、取得する情報に付随する権限を尊重しなければならないため、これらの制御は不可欠だ。
Elasticは、3,000人を超える従業員がこのアシスタントを利用していると報告している。ElasticGPTの成果によると、従業員は年間平均63時間を節約し、従業員満足度は98％に達したという。
これらの数値は独立した評価ではなく、Elastic自身によるものだ。同社は、従業員の時間、ホスティング費用、開発労力を基に、このシステムは2カ月以内に投資を回収したとしている。
報告された成果は具体的なビジネスケースを示すが、別の企業でも同じ結果が得られることを証明するものではない。Elasticは、自社のプラットフォーム上で、自社の従業員向けに、時間節約に関する社内前提を用いてこのアシスタントを開発した。
より重要なのは、ElasticGPTが複数の言語モデルをサポートするよう設計されている点だ。Elasticは、複数のモデルへの安全なアクセスが、従業員が会社の管理外にある未承認サービスを利用することで生じるシャドーAIの抑制に役立つとしている。
この設計により、OpenAIとの接続は重要でありながら排他的ではないものとなる。現在のElasticGPT実装ではOpenAIが生成コンポーネントを提供する一方、検索、権限、データ準備、監視の責任はElasticが保持する。
この違いによって、Google Newsの見出しの読み方も変わる。Elasticは単にチャットボットを再販しているのではない。OpenAIや他の互換モデルにコンテキストを提供できる、管理されたデータレイヤーとしてElasticsearchを提示している。
ここに記事の中心的な緊張関係がある。ElasticがOpenAIとの連携を深めるほど、そのプラットフォームはOpenAI顧客にとって有用になる。しかし、独立したエンタープライズインフラプロバイダーであり続けるには、OpenAIを置き換え可能な存在として保つ必要もある。
Google Newsの見出しがエンタープライズ購入者にとって重要な理由
真の競争は、専有データと従業員が利用するAIアプリケーションの間で、どの企業が制御点となるかを巡るものだ。
企業が有能な言語モデルへアクセスすることに苦労することはほとんどない。課題は、別の制御されていないデータサイロを生み出すことなく、そのモデルを最新で、権限管理され、追跡可能な情報へ接続することにある。
汎用モデルは、どのポリシー文書が最新かを自動的には把握できない。従業員が法務メモ、顧客記録、セキュリティアラート、未公開の財務プレゼンテーションを閲覧すべきかも推論できない。
検索インフラは、クエリ時に情報を選択することでこの問題に対処する。アイデンティティ制御がユーザーのアクセス可能範囲を決定し、オブザーバビリティツールがシステムの性能と障害を記録する。
Elasticはすでに、検索、セキュリティ、オブザーバビリティにまたがる製品を販売している。同社のエンタープライズAIに関する主張は、こうした既存のデータおよび監視機能が、アシスタントやエージェントの共通基盤になり得るというものだ。
同社は2026年2月にリリースしたElastic 9.3で、その主張を強化した。このアップデートではAgent Builderが一般提供となり、テクニカルプレビューとして公開されたElastic Workflowsと接続された。
Agent Builderにより、開発者はElasticsearchデータを検索し、定義済みツールを使用するエージェントを作成できる。Workflowsはモデルの判断とルールベースの手順を組み合わせ、チームが予測可能なアクションを従来型の自動化に任せる手段を提供する。
Elasticのバージョン9.3リリースでは、多言語の埋め込みとリランキング向けに管理されたJina AIモデルも追加された。埋め込みはコンテンツを意味検索用の数値表現へ変換し、リランキングは取得結果を関連性に応じて並べ替える。
これらの追加機能は、モデルの多様性を重視する戦略を補強する。Elasticは商用モデル、クラウド管理サービス、自社の推論サービスを通じて配布されるモデルと連携できる。
これは、OpenAIもエンタープライズスタックの下層へ進出しているため重要だ。ChatGPTアプリケーションは、一般にMCPと呼ばれるModel Context Protocolを通じて、外部データやツールに接続できる。
MCPは、AIアプリケーションが外部ツールを発見し、呼び出すための標準的な方法を定義する。あらゆるモデルインターフェースとあらゆるエンタープライズサービスの間に固有の統合を構築する必要性を減らすものだ。
OpenAIのエンタープライズ製品は、検索、情報取得、インタラクティブなインターフェース、限定的な書き込みアクションを備えたカスタムMCPアプリケーションへの対応を拡大している。同社のMCPガイダンスによれば、ワークスペース管理者はアプリケーションを確認し、アクセスを制御し、個々のアクションを承認できる。
この拡張により、OpenAIはインターフェース、アプリケーションカタログ、権限設定の体験、エージェントワークフローに対してより大きな影響力を持つ。一方で、あらゆる有能なエージェントには信頼できる運用データが必要なため、Elasticにとっても機会を生む。
両社が同じ制御点の所有を目指すまでは、この関係は協調的だ。OpenAIは、従業員が検索、分析、行動を行う場としてChatGPTを位置付けたい。Elasticは、どの情報と運用コンテキストがそのインターフェースに到達するかを決めるシステムとしてElasticsearchを維持したい。
したがってエンタープライズ購入者は、この提携報道を単なるベンダー発表ではなく、アーキテクチャ上の判断として捉えるべきだ。OpenAIモデルを選択しても、企業コンテキストをどこに置くか、権限をどのように機能させるか、モデルの活動をどう監視するかは決まらない。
これらの判断が将来の切り替えコストを左右する。検索およびガバナンスレイヤーを独立させておけば、企業はモデルをより容易に変更できる。統合型AIスタックを導入すれば簡素化のメリットを得られる一方、1社のプロバイダーへの依存度は高まる。
賭けの対象は1つのOpenAIモデルではなくコンテキスト
Elasticの最も強い立場は、エンタープライズデータインフラを変更するよりもモデルを変更する方が混乱を少なくできるレイヤーにある。
言語モデルは、ユーザーがその回答と直接やり取りするため最も注目を集める。しかし、エンタープライズアプリケーションは、モデルがプロンプトを受け取る前に、目に見えにくい多くのコンポーネントに依存している。
文書は取り込み、整理、インデックス化され、アイデンティティと照合されなければならない。システムは有用な文章を取得し、無関係な資料を除外し、モデル呼び出しを記録し、障害を運用担当者に可視化する必要がある。
Elasticはすでに、そのうちいくつかの機能を担っている。同社のプラットフォームは構造化・非構造化情報をインデックス化し、セマンティック検索とキーワード検索をサポートし、セキュリティやアプリケーションのテレメトリーを収集する。
この組み合わせにより、Elasticはコンテキストエンジニアリングをプラットフォームのカテゴリーとして提案できる。コンテキストエンジニアリングとは、AIシステムがタスクのために受け取る指示、記録、ツール、その他の情報を選択するプロセスだ。
この戦略は社内従業員向けアシスタントにとどまらない。2026年4月、Elasticはセキュリティ、オブザーバビリティ、検索、データ探索向けのMCP Appsを発表した。
これらのアプリケーションは、対応するAIクライアント内でインタラクティブなインターフェースを表示する。セキュリティアナリストはアラートや調査グラフを確認でき、運用エンジニアはサービス依存関係や分散トレースを調査できる。
Elasticによると、同社のセキュリティアプリケーションはアラートのグループ化、プロセスツリーの表示、ES|QLクエリの実行、ケースの作成を行える。オブザーバビリティアプリケーションでは、Kubernetesの健全性、異常、サービストポロジー、障害の影響を表示できる。
検索アプリケーションは、自然言語によるリクエストをダッシュボードへ変換し、ユーザーが生成された可視化を編集またはエクスポートできるようにする。これは、生成テキストのブロックを返すだけにとどまらない。
ElasticのMCP Apps発表によると、これらのアプリケーションはClaude、Claude Desktop、VS Code、GitHub Copilot、Goose、Postman、MCPJamでパブリックプレビューに入った。
この一覧は示唆的だ。OpenAIはMCP Apps仕様の共同策定に参加したが、Elasticの初期提供は複数企業が運営する製品にまたがっている。
Elasticは、OpenAIがサポートする標準を利用して、競合するAI環境間でワークフローをポータブルにしている。したがってこの協業は、Elasticのモデル中立的な立場を弱めるのではなく、強化する。
これが見出しの背後にある中心的な逆転だ。OpenAIとの技術的な接続が深まっても、必ずしもOpenAIへの依存が強まるとは限らない。その接続がオープンプロトコルを利用するなら、Elasticが同じ機能を他の環境へ展開する助けになり得る。
このアプローチは、統合型データプラットフォームにも圧力をかける。Snowflake、Microsoft、Google、Amazonなどのプロバイダーは、データストレージ、モデル、開発ツール、ガバナンスを自社環境内で組み合わせることができる。
Elasticは、独立した検索・コンテキストレイヤーがより高い関連性、ポータビリティ、または運用上の可視性を生み出すと顧客に納得させなければならない。そうでなければ企業は、すでに利用しているプラットフォームにバンドルされたAI機能を受け入れる可能性がある。
Elasticの強みは、検索、ログ、セキュリティイベント、アプリケーションテレメトリーにまたがる導入基盤にある。これらのデータセットには、エージェントがインシデントを調査したり、企業固有の質問に答えたりするために必要な証拠が含まれていることが多い。
一方で弱みは、アーキテクチャが追加で必要になることだ。別個のプラットフォームを導入、運用、保護し、統合型の代替手段に対してその必要性を正当化しなければならない。
OpenAIとの関係は、その統合負荷を軽減できる場合に価値を持つ。購入者が、自社のモデルプロバイダーやクラウドプラットフォームですでに十分な検索・取得機能とガバナンスを得られると判断すれば、その価値は低下する。
開発者にとって実務上の論点は、アプリケーションロジックの可搬性をどこまで維持できるかだ。ソース情報をモデル非依存の検索・取得システムに保持すれば、異なる言語モデルを試す作業を簡素化できる。
同じ原則は、個人およびチームのワークフローにも当てはまる。適切に構造化されたAI knowledge baseは、問い合わせに使用するモデルとは切り離して、有用なソース資料を保持する。
Elasticはこの原則をエンタープライズ規模で追求している。モデルは変わり得る一方で、インデックス化された企業情報、アクセス方針、運用履歴は維持される。
OpenAIは重要だが、製品の本質は代替可能性にある
ElasticはOpenAIを効果的に機能させると同時に、顧客がデータレイヤーを再構築せずにモデルを切り替えられることを示さなければならない。
この要件は、難しい製品上のバランスを生む。深い統合はより優れた体験をもたらすが、プロバイダー固有の機能は可搬性を損なう可能性がある。
OpenAIが提供するのはテキスト生成だけではない。そのアプリケーションプラットフォームには、ツール呼び出し、接続データ、インタラクティブなインターフェース、管理コントロール、エージェントワークフローが含まれる。
こうした機能の利用は開発を加速できる。一方で、開発者がOpenAI固有の挙動、API、権限、インターフェースコンポーネントを中心にロジックを構築するよう促す可能性もある。
Elasticの答えはレイヤードアーキテクチャだ。Elasticsearchが情報を保持・検索し、その上位にあるコネクター、モデル、ユーザーインターフェースは変更できる。
同社の公開資料では、OpenAIを、Anthropic、Cohere、Hugging Face、LangChain、LlamaIndex、Mistral AI、NVIDIA、大手クラウドプロバイダーを含む、より広範なAIエコシステムの一部として位置付けている。
Elastic Agent Builderもモデル非依存であると説明されている。これにより、開発者はアプリケーションの下層にあるインデックス済みデータを変更せずに、マネージドモデルサービスを選択できる。
この約束には、互換性リスト以上のものが必要だ。ツールの選択、指示への追従、取得文書の解釈、長い会話の処理において、モデルの挙動は異なる。
2つのプロバイダーで動くアプリケーションであっても、精度、レイテンシー、安全性の成果は異なり得る。APIレベルでのモデル可搬性は、同等のアプリケーション性能を保証しない。
したがってElasticは、自社の検索・取得、再ランキング、ワークフロー制御がこうした差異を縮小することを示す必要がある。購入者が求めるのは一般的なベンチマークではなく、自社の文書とタスクに基づく評価だ。
同社はElasticGPTを通じて、1つの有用な社内ケーススタディを作成した。従業員は、会社方針、営業プロセス、技術サポート、会議、製品差異について質問できる。
ただし、この実装は依然としてElastic自身の測定に依存している。従業員1人当たり63時間の削減という報告は、アシスタントとのやり取りが他の業務に振り向けられる時間の回復を意味するという前提に立っている。
満足度も回答の正確性ではなく、ユーザーの感情を測る指標だ。例外事項を見落としたり、古い方針を取得したりする回答であっても、ユーザーは速い回答を好む可能性がある。
Elasticは、ユーザーがソース情報を修正することでナレッジベースを改善できるとしている。このフィードバックループは、見かけ上のモデル障害の多くが不完全または古いコンテンツに起因するため、RAGに共通する弱点に対応するものだ。
それでも、修正には所有権の問題が生じる。誰かがどのソースを正とするかを決め、競合する文書を整理し、従業員の役割変更に応じてアクセス権限を維持しなければならない。
これらは検索機能ではなく、組織運営上の課題である。ソフトウェアは競合を可視化できるが、情報ガバナンスの責任は顧客に残る。
OpenAIは別のリスク領域も持ち込む。取得したコンテンツを外部のモデルサービスへ送るには、顧客がデータ処理、保持、地域での提供状況、契約上の保護を理解する必要がある。
Azure OpenAIの利用は、既存のMicrosoftガバナンスプログラムに適合する可能性があるが、セキュリティレビューの必要性をなくすものではない。企業は、どのデータがElasticから出るのか、何がログに記録されるのか、それらの記録を誰が確認できるのかを整理しなければならない。
MCPアプリケーションは、検索・取得の域を超えてアクションを実行できるため、さらに複雑になる。侵害された指示が接続済みツールの不正利用を試みる可能性があり、過度に広い権限は機密性の高い結果を露出させ得る。
OpenAIは、組織がカスタムMCPサービスを審査し、アクション権限を設定する責任を負うと警告している。一部の書き込み操作には確認が必要だが、管理面でのレビューは依然として不可欠だ。
Elasticのセキュリティとオブザーバビリティのバックグラウンドは、この議論において同社に信頼に足る立場を与える。しかし、信頼性は、すべての新しいエージェントワークフローが安全であることを独立して証明するものではない。
製品としての試金石は、管理者がエージェントのデータ経路を理解し、その行動を再現し、権限を制限できるかどうかだ。このプロセスが依然として難しいままであれば、モデルの選択は導入上の問題を解決しない。
数字が裏付けるものと、裏付けないもの
Elasticの財務実績は同社のより広範なプラットフォームに対する需要を裏付けるが、OpenAIとの連携によって生み出された収益を切り分けてはいない。
Elasticは、2026年4月30日に終了した第4四半期の売上高を4億5,100万ドルと報告した。これは前年同期比16％の成長に相当する。
通期売上高は17％増の17億3,900万ドルに達した。サブスクリプション売上高は16億3,400万ドルで、営業主導のサブスクリプション売上高は20％増加した。
同社はまた、当期の残存履行義務が20％増の12億300万ドルだったと報告した。残存履行義務の総額は28％増の19億8,200万ドルに達した。
これらの義務は、まだ収益として認識されていない契約済み収益を表す。その増加は、顧客によるより大きい、あるいはより長期のコミットメントを示すが、すべての契約を牽引している製品を特定するものではない。
Elasticには、年間契約額が10万ドルを超える顧客が1,720社以上あった。これは1年前の1,510社以上と比べて増加している。
最高経営責任者のAsh Kulkarni氏は、Elasticが顧客のAIインフラの一部となるにつれ、顧客がより大きなコミットメントを行っていると述べた。同社のfiscal 2026 resultsでも、検索、セキュリティ、オブザーバビリティを横断する統合が強調された。
これらの結果は、ElasticがAI機能を提供するためのエンタープライズ向け販売基盤を持つという主張を強める。ただし、収益のうちどれだけがOpenAI関連アプリケーション、Agent Builder、ベクトル検索、または従来型ワークロードから生じているかは示していない。
Google Newsの拡大提携に関する見出しを読む投資家にとって、この帰属上の空白は重要だ。パートナーシップの物語は直接的な収益触媒を示唆し得るが、実際の経済効果はプラットフォームのサブスクリプションに組み込まれたままである可能性がある。
Elastic自身のリスクに関する表現は、引き続き適切に慎重だ。同社は、顧客受容性、AI競争、価格設定、クラウド構成、AI施策の成功を、将来の業績に影響し得る要因として挙げている。
経営陣は2027年度第1四半期の売上高を4億6,900万ドルから4億7,000万ドルの範囲と見込んだ。その中間値は前年同期比13.1％の成長で、前四半期に報告された16％を下回る。
通期では、Elasticは売上高を19億8,500万ドルから20億ドルの間と予測した。中間値は14.6％の成長を示唆する。
この見通しはAI戦略を否定するものではない。ただし、投資家が製品としての重要性と短期的な成長加速を分けて考えるべき理由を示している。
エンタープライズAIプロジェクトは、データ取り込み、ベクトル検索、セキュリティ監視、オブザーバビリティの利用を増やす可能性がある。一方で、プレビュー段階にとどまったり、ガバナンスレビューで停滞したり、バンドル型クラウドサービスへ移行したりすることもあり得る。
Elasticのパブリックプレビュー中のMCP Appsは、この不確実性を示している。利用可能な方向性を提示しているが、パブリックプレビューは広範な本番導入と同じではない。
同社は各MCP Appについて独立した利用状況の数値を開示していない。また、Elasticの顧客のうちどれほどが他のプロバイダーではなくOpenAIモデルへプラットフォームを接続しているかも定量化していない。
より強い投資判断の根拠には、AIワークロードの拡大率、本番導入、関連する利用量の成長、顧客維持率が含まれるだろう。こうした詳細がなければ、この提携は戦略的には興味深いものの、財務面で切り分けることは難しいままだ。
エンタープライズの購入者も、同様の測定上の問題に直面する。成功したデモは、大規模運用における運用コストの低下やインシデント対応成果の改善を証明するものではない。
彼らは、検索・取得精度、タスク完了率、権限エラー、応答レイテンシー、人間によるレビュー時間、ソース情報を維持するコストを測定すべきだ。
ElasticGPTは初期の社内参照点を提供する。報告された投資回収期間と従業員満足度は、Elasticがプラットフォームによって提供できると考える価値を示している。
次の段階は、異なる権限、文書、コンプライアンス義務、アプリケーション環境を持つ組織全体での外部検証だ。
Elasticの戦略が機能しているかを示す3つのシグナル
次の段階は、本番導入、モデル間の一貫性、AIワークロードがElasticの事業を改善するという証拠にかかっている。
第1のシグナルは、ElasticのMCP Appsがパブリックプレビューから一般提供へ移行することだ。一般提供により、より明確なサポートコミットメント、管理コントロール、互換性の詳細、本番環境での導入事例がもたらされるはずだ。
セキュリティおよびオブザーバビリティのチームは、顧客がアプリケーションをデモではなく実際の調査に使用しているかを注視すべきだ。本番インシデントでは、データ鮮度、追跡可能性、権限の強制、予測可能なアクションに対して、より厳格な要件が生じる。
Claude、ChatGPT、GitHub Copilot、その他のクライアントに広く導入されれば、Elasticのモデル中立という主張が強まる。導入が1つのインターフェースに集中すれば、戦略はそのプロバイダーへの依存度を高めることになる。
第2のシグナルは、同一のワークフローが複数のモデルで信頼性高く動作するという証拠だ。同じツールを呼び出しても精度が異なり得るため、互換性だけでは弱い基準である。
Elasticは、検索・取得品質、ツール選択、タスク完了、レイテンシー、安全でないアクションの試行を対象とする評価を公表すべきだ。顧客が実施するテストは、ベンダー単独で作成した結果よりも重みを持つ。
最も説得力のある証拠は、Elasticのコンテキストレイヤーがモデル間の性能差を縮小することを示すものだ。そうなれば、モデルの代替可能性は設計上の主張から、測定可能な製品上の利点へ変わる。
モデルが変わるたびにアプリケーションの大幅な書き換えが必要であれば、可搬性の主張は弱まる。その場合、購入者はコンポーネント数の少ない垂直統合型プラットフォームを好む可能性がある。
第3のシグナルは、AI活動とサブスクリプション拡大を結び付ける財務開示だ。投資家は、顧客数の増加、残存履行義務、クラウド消費、AIワークロードの本番運用に関するコメントを注視すべきだ。
より大きな契約は、企業が検索、セキュリティ、オブザーバビリティを1つのAIインフラプラットフォームと見なしているというElasticの主張を裏付けるだろう。消費の伸びが鈍い、または試験導入期間が長期化すれば、関心が持続的な利用へ転換していないことを示唆する。
競合他社の対応も、これらのシグナルの中で重要だ。クラウドおよびデータプロバイダーは、検索・取得、エージェント、ガバナンスを自社サービスへ組み込み続けるだろう。
Elasticは、統合型プラットフォームをすべて置き換える必要はない。複数のクラウド、モデル、AIインターフェースにまたがって独立したコンテキストレイヤーを運用するだけの価値があると、顧客に示す必要がある。
OpenAIとの関係は、ChatGPTによってElasticが大きなエンタープライズアプリケーションの接点にアクセスできるため、有利に働く。OpenAIがMCPをサポートしていることも、独自の統合標準を設けずにElasticのワークフローを接続しやすくしている。
しかし、このオープン性は競合他社にも同じ接点へのアクセスを与える。Elasticは、検索・取得の品質、運用データ、権限管理、ワークフローの深さで勝たなければならない。
だからこそ、元の見出しは見た目ほど単純ではない。重要なのは、ElasticがOpenAIを唯一のエンタープライズAIパートナーとして選んだことではない。入手可能な証拠は、むしろその逆を示している。
ElasticはOpenAIを統合しつつ、顧客が他のモデルやインターフェースを利用できる選択肢を維持している。OpenAIが避けられない依存先ではなく、価値ある選択肢となるとき、この戦略は成功する。
Google Newsを通じてこの動向を追う読者は今後、本番環境での導入、モデル横断の評価、AIワークロードに紐づく収益に注目すべきだ。これらのシグナルによって、Elasticが持続的なコンテキストレイヤーを保有しているのか、拡大するエンタープライズAIスタックにおける単なる接続の一つにすぎないのかが明らかになる。
