Neon買収でDatabricksとGoogleのデータベース競争が激化

Databricksは、報じられた10億ドル規模の契約を経てNeonを買収し、databricks googleの競争を運用データベース市場へと押し広げた。この取引は2025年5月に発表され、その後完了した。Neonの技術がDatabricks内でLakebaseとして姿を現したことで、その影響はより明確になった。

これは単なるデータベース買収ではなかった。Databricksは、分析、機械学習、大規模処理向けに保存されたデータを中心に地位を築いてきた。Neonは、アプリケーションが毎秒生成するリアルタイムのトランザクションに対応するPostgreSQL互換システムをもたらした。

この動きにより、DatabricksはGoogle Cloud、Amazon Web Services、Microsoft、Snowflakeに一段と近づく。各社はAIエージェントを支えるデータレイヤーの主導権を握ろうとしている。GoogleはすでにAlloyDB、Cloud SQL、Spanner、BigQuery、Vertex AI、そしてエージェント開発ツールを提供している。

中心的な問いは、Databricksが企業データを分析できるかどうかではなくなった。Databricksが、AIアプリケーションがデータを作成、更新、管理、分析する場になれるかどうかである。

Neonの取引が埋めた重要な空白

Neonは、Databricksのレイクハウス・プラットフォームにこれまで欠けていた運用データベース・アーキテクチャをもたらした。

Databricksは2025年5月14日、Neonを買収する契約を発表した。その買収声明では、Neonを開発者とAIエージェント向けに構築されたサーバーレスPostgreSQL企業と説明している。

PostgreSQLは、アプリケーションが構造化され頻繁に変化する情報を保存するために用いるオープンソースのリレーショナルデータベースである。一般的なSQLクエリ、トランザクション、拡張機能、そして大規模な開発者エコシステムをサポートする。

Neonは、コンピュートとストレージを分離することで、PostgreSQLをクラウドインフラ向けに再設計した。永続的な情報を共有ストレージに保持したまま、データベース処理は独立して拡張できる。ワークロードは、停止中のコンピュートを縮小し、分離されたブランチを作成し、データベース全体を複製せずに新しい環境をプロビジョニングできる。

このモデルは、AIが生成するソフトウェアにとって重要だ。人間の開発チームは、本番、テスト、ステージング用に複数のデータベースを作成するかもしれない。自動コーディングエージェントは、同じ期間に多数の一時的なプロジェクト、ブランチ、テスト、データベース・インスタンスを生成できる。

Neonは、この取引が発表された時点で、同サービス上の新規データベースの大半をAIエージェントが作成していたと述べた。DatabricksのCEOであるAli Ghodsiは後にAxiosに対し、Neonではエージェントがデータベースの80％を作成していたと報告した。

この統計は独立監査ではなく、Neonによるものだった。しかし、戦略的な論理を説明するものではあった。Databricksが買収したのは、従来型のエンタープライズアプリケーション向けのPostgreSQL互換性だけではない。ソフトウェアを機械の速度で作成するために設計されたインフラだった。

Neonの創業者らは、2021年の会社設立以来、このアーキテクチャを追求してきた。同社の取引発表によれば、当初の目標は、開発者が使うことを楽しめるクラウドネイティブなPostgreSQLサービスを作ることだった。

Databricksにとって、Neonは3つの不足していた要素を提供した。

第1に、トランザクション向けストレージである。Databricksは、企業が大量の履歴データやストリーミングデータを処理する分析ワークロードに重点を置いてきた。運用アプリケーションには、信頼性の高いトランザクション処理を伴う、より低遅延な読み書きが必要となる。

第2に、Neonは開発者向けのプロビジョニングモデルを提供した。データベースは、手作業で管理するインフラプロジェクトではなく、アプリケーションのリソースとして利用できる。この違いは、エージェントが環境を自動的に作成する際に重要になる。

第3に、NeonはPostgreSQL市場への入口をもたらした。開発者はすでにPostgreSQLのツール、ドライバー、拡張機能、クエリ構文を理解している。Databricksは、まったく未知のプログラミングモデルを要求せずに、自社プラットフォームを拡張できる。

この買収はまた、基盤技術を買収してきたDatabricksのパターンを継続するものでもある。MosaicMLは生成AIトレーニング機能を追加し、TabularはApache Icebergやオープンデータ形式に関わる専門性を加えた。Neonは運用データベースを加えた。

これらの取引は合わせて、より広範な野心を示している。Databricksは、生の企業データから本番AIアプリケーションに至るまでの道筋を、より多く管理したいと考えている。

同社は依然として基盤となるクラウドインフラに依存している。DatabricksはAWS、Microsoft Azure、Google Cloud上で稼働する。Neonはその依存をなくすものではない。顧客によるこれらのクラウドの利用方法を形作る、もう1つのソフトウェアレイヤーをDatabricksに与える。

この区別が、本記事の中心的な緊張関係を生む。Databricksは主要クラウドプロバイダーのパートナーであり続ける一方、それらのデータベースおよびAIサービスとの競争を強めている。

DatabricksとGoogleの競争にPostgreSQLが加わった理由

databricks googleの関係は、インフラ面での提携と、AIアプリケーション・ワークロードを巡る直接競争を併せ持つ。

DatabricksとGoogle Cloudは長年にわたり協力してきた。顧客はGoogle Cloud上でDatabricksを実行し、クラウドストレージと接続し、BigQueryやVertex AIなどのサービスとワークロードを統合できる。

この提携は商業的に依然重要である。1社が新しいデータベースを導入したからといって、企業がクラウド環境全体を置き換えることはめったにない。インフラ、データプラットフォーム、モデル、アプリケーションを複数のプロバイダーから組み合わせることが多い。

それでもNeonは、Googleが独自のPostgreSQLサービスを販売しているため、競争圧力を生む。Cloud SQLはマネージドPostgreSQLを提供し、AlloyDBは要求の厳しいクラウドワークロード向けに設計されたPostgreSQL互換データベースを提供する。

Googleはまた、AlloyDBを生成AIアプリケーションの基盤として位置付けている。そのAlloyDB AIロードマップには、セマンティック検索、ベクトルインデックス、自然言語クエリ、モデルサービスとの接続が含まれる。

ベクトルインデックスは、テキスト、画像、その他のコンテンツの数値表現を整理する。アプリケーションはこれらの表現を用いて、ユーザーの要求に関連する情報を取得する。

Googleの優位性は垂直統合にある。顧客はAlloyDBをGeminiモデル、Vertex AI、ID管理、ネットワーク、オブザーバビリティ、Googleのエージェント開発ツールと組み合わせられる。スタックの大部分を1社のプロバイダーが運用する。

Databricksは異なる提案を打ち出している。同社は、インフラプロバイダーをまたいで機能するマルチクラウドのデータ・AIレイヤーとして自らを位置付ける。Lakebaseは、その提案を運用PostgreSQLへと拡張する。

これにより、企業の購買担当者には2つの競合する道筋が生まれる。

Googleの道筋はクラウドから始まる。顧客はGoogleのインフラ、Googleのデータベース、Googleのモデル、Googleの管理サービスを利用する。統合の深さが主な魅力となる。

Databricksの道筋はデータプラットフォームから始まる。顧客はDatabricksを通じてガバナンスが適用された情報を利用し、クラウドプロバイダーやモデルプロバイダーを選択し、既存の分析ワークロードの隣でアプリケーションを構築する。

どちらのアプローチも複雑さをなくすわけではない。Googleの顧客は、アプリケーションを1つのクラウドとどこまで密接に結び付けるかを決めなければならない。Databricksの顧客は、同社のクロスクラウド抽象化が十分な運用上の一貫性を提供するかを評価する必要がある。

アプリケーション用データベースは、しばしば長期にわたるアーキテクチャ上のコミットメントとなるため、Neonの買収は重要性を高める。モデルエンドポイントの移行は管理可能な場合があるが、長年のアプリケーション依存関係を持つトランザクションデータベースの移行は、はるかに困難である。

PostgreSQL互換性は、移行時の摩擦をいくらか軽減する。しかし、ポータビリティを保証するものではない。マネージドサービスは、コアデータベースの周辺に独自の認証、ネットワーク、監視、ブランチ、レプリケーション、AI統合を導入する。

Googleは、AlloyDBがクラウド管理機能とGeminiサービスとの成熟した統合を提供すると主張できる。Databricksは、Lakebaseが運用データを分析、ガバナンス、AIと自社プラットフォーム内で結び付けると主張できる。

違いは、AIを活用した顧客サポートアプリケーションで具体的になる。このアプリケーションは、アカウント、会話状態、権限、ワークフローの状態をPostgreSQLに保存するかもしれない。また、過去のやり取りを分析し、エージェント向けに関連文書を取得することもできる。

Googleでは、アプリケーションはAlloyDB、Vertex AI、BigQueryを組み合わせるかもしれない。Databricksでは、Lakebaseがトランザクションを処理し、レイクハウスが分析、モデル評価、ガバナンスが適用された情報取得を支えることができる。

買い手が選ぶのは、データベース性能だけではない。この決定は、アプリケーション状態をどこに置くか、エージェントがどのようにコンテキストを受け取るか、どのプラットフォームがアクセスを管理するかに影響する。

そのため、主要キーワードは単一の買収よりも広い意味を持つ。databricks googleの競争は、企業向けAIアプリケーションを支える制御点を巡る争いを反映している。

Databricksが圧力を生むためにGoogle Cloudのインフラを置き換える必要はない。顧客がDatabricksを主要なデータ・AIコントロールプレーンとして扱えばよい。

AIエージェントがデータベースに求めるものを変える

Neonの真の戦略的価値は、自動化されたソフトウェアワークフロー向けにデータベースをプロビジョニング、ブランチ、スケーリングできる点にある。

従来のデータベース運用では、人間がインフラに関する意思決定の大半を担うことを前提としている。エンジニアはデータベースを申請し、アクセスを設定し、バックアップを整備し、開発環境を作成する。

AIコーディングエージェントは、このサイクルを短縮する。人間の介入を限定しながら、アプリケーションを生成し、テストを実行し、スキーマを改訂し、プレビュー環境をデプロイできる。データベースレイヤーは、管理上のボトルネックにならずに対応しなければならない。

サーバーレスのプロビジョニングは、長い手作業のプロセスを通じて容量を割り当てる必要がないため役立つ。ワークロードが到着した時点でコンピュートを開始し、活動が停止すれば縮小できる。

ブランチも同様に重要である。データベースブランチは、既存の状態から派生した、開発者またはエージェント向けの分離環境を提供する。本番レコードを変更せずに変更をテストできる。

社内アプリケーションにサブスクリプション管理を追加するよう指示されたエージェントを考えてみよう。スキーマを変更し、テストアカウントを作成し、移行スクリプトを実行し、クエリを検証するかもしれない。

これらの手順を本番データベースで実行するのは危険である。試行のたびに従来型のコピーを作成すれば、時間とストレージを消費する。ブランチベースのワークフローは、より明確な境界を提供する。

このアーキテクチャは、プレビューアプリケーションも支援する。提案された各コード変更に、独自のアプリケーションデプロイメントと関連するデータベース状態を割り当てられる。レビュアーは、変更が本番に到達する前に動作するソフトウェアを確認できる。

こうしたパターンは、Databricksが汎用的なPostgreSQLホスティング以上のものを求めた理由を説明する。Neonは、迅速な作成、独立したコンピュート、データベースブランチを中心にサービスを設計していた。

Lakebaseは、この設計をDatabricksへ持ち込む。PostgreSQL互換の運用データベースを、すでにデータエンジニアリング、ガバナンス、分析、機械学習に使われているプラットフォームと接続する。

期待される利点は、アプリケーションのライブ状態と分析コンテキストの間の経路が短くなることだ。エージェントは、より広範な企業データセットからガバナンスが適用された情報を取り出しながら、現在のトランザクションレコードを利用できる可能性がある。

Databricksは自社のガバナンスレイヤーをUnity Catalogと呼ぶ。この文脈でのガバナンスには、データおよびAI資産に関する発見、権限、リネージ、ポリシー管理が含まれる。

統合カタログを導入しても、アプリケーションのセキュリティが自動的に解決されるわけではありません。運用データベースには独自のユーザー、接続ルール、トランザクション境界、障害モードがあります。それでも、アイデンティティとポリシーの統合によって、管理の重複を減らすことはできます。

Googleも異なるアーキテクチャで、同様の到達点を目指しています。AlloyDBはPostgreSQLワークロードをサポートし、GoogleはデータベースをGemini、Vertex AI、エージェントフレームワークと接続しています。

Googleの公開ドキュメントでは、AlloyDB AIはベクトル検索、自然言語による操作、複数のモデルプロバイダーの呼び出しをサポートすると説明されています。この幅広さは、NeonがDatabricksにもたらすAIデータベースのカテゴリーが唯一無二だという主張を弱めます。

むしろNeonは、Databricksがワークフロー設計で競争する助けとなります。同社はデータベース作成を、ノートブック、データパイプライン、アプリケーション、モデルエンドポイント、ガバナンスの効いた企業記録と並べて配置できます。

買収の見出しよりも重要なのは、その仕組みです。AIエージェントは、開発者一人当たりに実行されるインフラ操作の数を増やします。データベースは、自動化されたワークフローを通じて出現し、分岐し、廃止できるプログラマブルなリソースにならなければなりません。

データグラビティの効果もあります。アプリケーションが、分析とAIに使われる同じプラットフォーム上にライブ状態を保存すると、どちらのワークロードも移行が難しくなります。

Databricksは、既存アカウント内で拡大する機会を得ます。分析用途で同プラットフォームを利用している顧客は、新たなAIアプリケーション向けにLakebaseを採用できます。この決定により、ストレージ、コンピュート、ガバナンス、モデルサービス全体での利用量が増える可能性があります。

Googleには逆方向の機会があります。すでにGoogle Cloudにコミットしている顧客は、別のプラットフォームのコントロールプレーンを追加することなく、AlloyDBとVertex AIで構築できます。

したがって、databricks googleの競争は、開発者の利便性とエンタープライズ制御を中心に展開されます。両社は、AIアプリケーションが信頼できるビジネスデータと出会う場所として、自社プラットフォームを標準的な選択肢にしたい考えです。

勝つデータベースは、エージェントというブランドだけで選ばれることはありません。実際のワークロードの下で、予測可能なトランザクション、復旧、可観測性、ネットワークセキュリティ、リージョンでの可用性、管理可能なコストを提供しなければなりません。

買収は運用リスクを取り除かない

Databricksは依然として、Neonの開発者に優しいアーキテクチャが大規模なエンタープライズ本番要件を満たせることを証明しなければなりません。

この買収によって技術とエンジニアリング人材は得られました。しかし、それだけでDatabricksが数十年にわたる運用データベースの信頼性を手にしたわけではありません。

分析プラットフォームとトランザクションシステムでは、障害の起こり方が異なります。分析クエリであれば、遅延後に再試行できる場合があります。失敗したトランザクションは、支払いを中断したり、操作を重複させたり、アプリケーションの状態を不整合にしたりするおそれがあります。

エンタープライズの購入担当者は、復旧目標、レプリケーション、メンテナンス時の挙動、接続処理、リージョンのカバレッジ、ワークロード分離を精査します。また、エージェントが生み出す突発的な負荷増大時の性能も検証するでしょう。

コンピュートとストレージの分離は柔軟性をもたらしますが、トレードオフも伴います。データベースは、永続ストレージとアクティブなコンピュートの間で情報を効率的に移動させなければなりません。コールドスタート、キャッシュの挙動、ネットワーク経路はレイテンシに影響を及ぼす可能性があります。

分岐にも明確な制御が必要です。エージェントが隔離されたデータベース環境を作成できるからといって、本番レコードへの無制限のアクセスを得るべきではありません。

組織には、機密情報のマスキング、ブランチ作成の制限、一時リソースの期限切れ処理、自動変更の監査に関するポリシーが必要になります。環境数の増加自体がガバナンス上の問題になり得ます。

オープンソースに関する問題も、不確実性を加えます。NeonはPostgreSQLと公開技術を中心にアイデンティティを築いてきました。大規模プラットフォームによる買収は、将来の互換性や製品の方向性への懸念を生む可能性があります。

Databricksには、Apache SparkやDelta Lakeを含むオープンソースプロジェクトに根差した歴史があります。この背景は同社の信頼性を支えますが、顧客が判断するのは歴史ではなく行動です。

コアとなるNeon開発が引き続き利用可能か、標準的なPostgreSQLツールが大幅な変更なしに使い続けられるかを注視すべきです。独自統合は価値を加えられる一方、乗り換えコストを高める可能性があります。

Googleも同じ信頼の問題に直面しています。AlloyDBはPostgreSQL互換であり、あらゆる細部で完全に同一の挙動を示すディストリビューションではありません。その最も強力な機能は、Googleのマネージド環境に依存しています。

両陣営のポータビリティに関する主張は、慎重なテストに値します。SQL互換性だけでは、運用ツール、アイデンティティシステム、バックアップ、可観測性、AI固有の拡張機能まではカバーできません。

競争圧力はGoogleを超えて広がっています。DatabricksがNeon取引を発表した直後、SnowflakeはPostgreSQL専門企業Crunchy Dataを買収しました。

Snowflakeの規制当局向け提出書類によれば、同社は2025年6月にその買収を完了しました。そのタイミングは、運用PostgreSQLがデータプラットフォーム全体で戦略的に重要になったことを示しました。

Snowflakeの対応により、Databricksが市場を単独で定義することはできません。SnowflakeはCrunchy Dataの専門知識を、自社の分析、アプリケーション、AIサービスと組み合わせることができます。

AWSはAmazon Auroraと幅広いデータベースポートフォリオを通じて、依然として大きな力を持っています。MicrosoftはAzureデータベース、Fabric、Databricksサービス、そしてOpenAIとの関係を組み合わせることができます。

この混み合った市場は、開発の加速を促すため、購入者にとって有益です。一方で、製品比較はより難しくなります。すべてのプロバイダーが、自社のデータベースはAIエージェントに対応できていると説明しています。

購入者には、実際のワークロードに結び付いた証拠が必要です。有用な評価には、トランザクションレイテンシ、復旧テスト、ブランチ作成時間、接続上限、管理負荷、変動する需要下での挙動を含めるべきです。

チームはデータ移動もテストする必要があります。アプリケーションは、分析、モデル評価、リトリーバルのために運用レコードを必要とする場合があります。アーキテクチャは、それらのレコードがどれほど迅速に利用可能になるか、ガバナンスポリシーがどのように追随するかを示す必要があります。

エージェント導入に関するベンダーの主張にも同様の注意が必要です。自動化ツールによって作成されたデータベースが、必ずしも価値ある本番アプリケーションを支えているとは限りません。

重要な指標は、継続的なワークロード成長、本番稼働中のデータベース数、継続利用、信頼性、顧客内での拡大です。Databricksは、これらの問題を決着させるのに十分な詳細を公表していません。

戦略的な統合リスクもあります。買収された製品は、チームが認証、課金、サポート、ガバナンスシステムの適応に何カ月も費やすと、勢いを失うことがあります。

NeonはDatabricks参画後も製品アップデートを公開し続けており、活発な開発を示唆します。ただし、継続的なリリースは、すべてのDatabricks顧客がアーキテクチャ上の妥協なしにLakebaseを採用できることを証明するものではありません。

独立系の分析では、この買収はDatabricksをハイパースケーラーに近づける一歩と説明されました。あるデータベース評価は、PostgreSQL機能によってDatabricksが従来のデータ管理競争の範囲を超えたと指摘しています。

この拡大は戦略的に魅力的ですが、期待も高めます。Databricksは今や、長年にわたりビジネスクリティカルなデータベースを運用してきたプロバイダーと競争しなければなりません。

この買収によって、Databricksはその競争における信頼できる参加者となりました。本番環境での証拠が、持続的なデータベースリーダーになれるかを決定します。

勢力図の変化を示す3つのシグナル

製品の提供状況、本番導入、競合の統合が、Neonが市場を変えるかどうかを決定します。

最初のシグナルは、一般提供開始後のLakebase採用です。プレビュー段階での関心は実験を反映することがありますが、本番利用にはセキュリティレビュー、運用テスト、組織としてのコミットメントが必要です。

顧客は、顧客向けアプリケーションを支える実名の導入事例を探すべきです。最も強力な事例には、測定可能なワークロード特性、復旧要件、Databricksガバナンスとの統合が含まれます。

既存のDatabricksアカウント内で繰り返し拡大することは、同社の戦略を強化します。それは、分析顧客が運用ワークロードを同じプラットフォームに追加する価値を見いだしていることを示すでしょう。

採用が限定的であれば、この論拠は弱まります。企業が分析とAIにDatabricksを使っていても、確立されたデータベースサービスを好むことを示唆します。

2つ目のシグナルは、AlloyDBとエージェントプラットフォームを通じたGoogleの対応です。Googleはすでに幅広いデータベースポートフォリオを持つため、Databricksに直接言及する必要はありません。

重要な指標は、AlloyDB、Gemini、エージェントツール、BigQuery、ガバナンスサービスの結び付きが強まることです。Googleは垂直統合を、Databricksに対する最も強力な回答にできます。

同社のPostgreSQL AI機能は現在、ベクトル検索、自然言語クエリ、モデル接続、エージェント指向ワークフローに及びます。統合が継続すれば、すでに同社クラウドにコミットしている顧客の間でGoogleの立場は強まるでしょう。

Databricksはマルチクラウドの一貫性で応じることができます。LakebaseがAWS、Azure、Google Cloudで同様に機能するなら、顧客はプロバイダー固有のアプリケーションアーキテクチャに代わる選択肢を得られます。

この主張には運用面での検証が必要です。提供開始日、リージョンカバレッジ、ネットワーキング機能、災害復旧の選択肢は、クラウド間で異なる可能性があります。

3つ目のシグナルは、Snowflakeや他のプロバイダーがPostgreSQLをどのようにパッケージ化するかです。SnowflakeによるCrunchy Data買収は、運用データベースを欠けていたレイヤーと見なしていたのがDatabricksだけではないことを確認しました。

Snowflake Postgresが、データプラットフォームと密接に接続された本番サービスになるかを注視してください。強い採用はエンタープライズ需要を分散させ、単純な二社対決という見方を弱めるでしょう。

AWSはAurora、Bedrock、そして確立された開発者基盤を通じて、すべての参加者に圧力をかけることができます。MicrosoftはAzureデータベースサービスをFabricおよびAzure Databricksと組み合わせることができます。

したがって、競争は複数の次元で展開されます。データベースの信頼性は依然として基礎ですが、プラットフォームガバナンス、モデルの選択肢、開発者ワークフロー、クラウドポータビリティが、今や同じ購買判断に影響します。

開発者にとって、当面の利点は選択肢が増えることです。チームは、慣れ親しんだSQL、ライブラリ、ツールを捨てることなく、統合型PostgreSQLの提供内容を比較できます。

エンタープライズの購入者にとって、この判断はより長期的な影響を持ちます。運用データベースは多くの場合、アプリケーションの記録システムになります。その周囲のプラットフォームは、セキュリティ、分析、AI開発を何年にもわたって形作る可能性があります。

AIプロダクトチームにとっては、データベース分岐に特に注意を払うべきです。ソフトウェアを編集するエージェントには、隔離されたデータ環境、制御された認証情報、自動クリーンアップが必要です。人間のペースでのプロビジョニングを前提としたデータベースでは、ワークフロー全体が遅くなる可能性があります。

databricks googleの対立は、一つのベンチマークや買収だけで決着しません。エージェントがどこに状態を保存し、どこでガバナンスの効いた情報にアクセスするかについて、繰り返される本番環境の判断によって決まります。

Neon取引が重要なのは、Databricksの役割を変えたからです。同社はもはや、アプリケーションデータベースの隣にある分析環境だけを提供するのではありません。両方を提供したいと考えています。

Googleはインフラの到達範囲と統合クラウドサービスで、依然として大きな優位性を持っています。Databricksはエンタープライズのデータチーム内で強い立場にあり、最大規模のクラウドを横断して運用できます。

これにより生産的な対立が生まれます。GoogleはクラウドプラットフォームにAIスタックを組織させたいと考えています。Databricksはデータプラットフォームを、その組織化レイヤーにしたいと考えています。

どちらのルートを評価するチームも、機能チェックリストではなく実際のアプリケーションから始めるべきです。想定される需要の下で、トランザクションの挙動、ブランチ分離、復旧、ガバナンス、モデル統合をテストしてください。

そして、最も重要なコンテキストを誰が管理しているかを問うべきだ。その答えがクラウドプロバイダーであれば、Googleの統合型アプローチは魅力的になる。データプラットフォームであれば、Databricksの影響力が増す。

この買収により、そのアーキテクチャ上の選択は即時の購買判断へと変わった。実運用におけるLakebaseの導入状況、AlloyDBとのより深い統合、そしてSnowflakeのPostgreSQL展開に注目したい。これらのシグナルは、Databricksが持続的なデータベース事業を築いたのか、それとも混み合った競争に参入しただけなのかを示すだろう。