ストーリー

創業から成功に至るまでの道のり。

Neil Jagdish Patel、Gord、Seifの3人は、dev-ops teamが増え続けるmachine dataを扱う難しさに向き合うためAxiomを始めた。

初期の問題意識は、データ量が増えるほど保存・検索・運用のコストが膨らみ、必要なログを捨てることだった。出典

創業のきっかけ

Axiomは「simple to deploy, simple to manage, and incredibly efficient」を掲げ、dev-ops teamが自分たちのデータを制御できる基盤を作った。出典

転機・苦労

ログ基盤は、保存量・query速度・運用負荷の三つを同時に満たしにくい。

Axiomはschema-lessなevent storeと独自の圧縮・query設計へ進み、後にmetricsやtracesも同じconsoleで扱う方向へ広げた。出典

成長・成功の要因

2020年にはCrane Ventures、Fly Ventures、Mango Capital、LocalGlobeらから700万ドルを調達した。

さらに公式docsでは30,000以上のorganizationsに利用されると説明している。出典 出典

結び

Axiomの歩みは、observabilityを「一部のログを見る道具」から「機械データを残して横断的に問い直す基盤」へ置き換える試みだ。

全量保持を価値にするには、価格だけでなく収集とqueryの運用まで設計する必要がある。

独自分析

PMF (プロダクトマーケットフィット)

AxiomのPMFは、ログ・metrics・tracesを大量に扱う開発チームにある。

従来のobservabilityはデータ量が増えるほどサンプリングや高額なindexingに頼り、障害調査に必要な文脈が欠けやすい。

Axiomは全データを保持し、schema-lessなevent storeをqueryする発想でこの痛みを正面から解く。出典

公式pricingは無料枠とusage-based pricingを組み合わせ、初期導入を止めずに規模に応じて課金する設計を示す。

小規模チームからpetabyte-scaleまで同じ製品面で伸ばせる点が、導入と拡張の接続になる。出典

参入障壁 (Moat)

moatは、schema-lessなevent store、圧縮・query技術、収集integration、そして蓄積される運用データの組み合わせにある。

EventDBはtimestamped event data向け、MetricsDBはhigh-cardinality metrics向けに分化され、単一用途のログ製品より横展開しやすい。出典

ネットワーク効果

ネットワーク効果は中程度に弱い。

顧客同士が直接つながるmarketplaceではない一方、OpenTelemetryやGitHubのSDK・integrationが増えるほど導入経路は広がる。

データが蓄積されるほどquery・dashboard・monitorの価値も上がる。出典

ターゲット

主対象は、ログ・metrics・tracesの量が急増し、既存stackのsamplingやindexing費用に困るSRE・platform teamだ。

個人開発者や小規模teamにも無料枠はあるが、価値が最大化するのは複数サービスを横断して障害原因を追う組織である。出典

成功要因

第一に、ログだけでなくmetricsとtracesを同じevent dataの文脈で扱う製品設計。

第二に、OpenTelemetryやVectorなど既存の収集経路を受け入れ、移行コストを下げること。

第三に、usage-based pricingと自動volume discountでデータ量の増加を価格設計へ直接つなげている点だ。出典

公式blogでは、AxiomはCrane Ventures、Fly Ventures、Mango Capital、LocalGlobeらから700万ドルを調達したと説明している。

資金は大規模データ基盤と開発者向け体験の両方に投じられる。出典

失敗・課題

最大のリスクは、usage-based pricingでも高カーディナリティや長期保持の利用量を顧客が予測しにくいことだ。

公式pricingは無料枠とvolume discountを示すが、実請求はingest・query・storageの組み合わせになる。出典

また、全データを残す価値は収集設計とquery技能に依存する。

公式docsもCollectorやVectorによるresilience・enrichment・governanceを推奨しており、導入後の運用設計は利用者側に残る。出典

グロース戦略

成長戦略は、無料枠とdeveloper向け導入、docs・blog・SDK、そして大規模顧客向けの運用価値をつなぐことだ。

公式pricingはPersonalを永久無料とし、Axiom Cloudは月25ドルのplatform feeから始める。

sales callなしでenterprise add-onsを有効化できる点も、self-serveを維持する工夫だ。出典

一方で大規模移行では、OpenTelemetry CollectorやVectorを使うreference architectureと導入支援を用意し、個人開発者向けの簡単さからenterprise運用へ橋を架けている。出典

主要チャネル: content, developerCommunity, openSource, integrations, sales

学べること

Axiomから学べるのは、observabilityの差別化を「もっと多くの機能」ではなく「捨てないデータ」と「予測可能な利用課金」の組み合わせで定義することだ。

既存ツールを全否定せず、OpenTelemetryやVectorを入口にすることで、置き換えの摩擦を下げられる。出典

ただし、全量保持は顧客の収集・権限・query設計まで含めて初めて価値になる。

プロダクトの約束を運用レシピまで落とすことが重要だと考えられる。

日本で展開するなら

日本市場では、クラウド費用と障害対応の説明責任が同時に重くなるため、samplingで見えなくなったデータを残す価値はある。

特に多拠点・多サービス企業にはdata residency、SSO、audit logへの関心が強い。

Axiomはregion選択やSOC 2 Type II、GDPR、HIPAA BAAを掲げているが、日本の個別規制・社内審査への適合は要確認。出典

主な競合

Timeline

創業から成功に至る道のり。転機ごとの収益・調達・バリュエーション (出典あり) も併記します。

  1. Axiom創業。ログやevent dataを大規模に扱う基盤として開発を開始。出典

  2. ローンチ出典

  3. Crane Ventures、Fly Ventures、Mango Capital、LocalGlobeらから700万ドルを調達。出典

    • 調達 $7,000,000
    • seed
  4. BYOBを通じて顧客のストレージとAxiomのquery engineを組み合わせる構想を説明。出典

  5. 公式docsで30,000以上のorganizationsに利用され、EventDBとMetricsDBを提供。出典

    • ユーザー 30,000

ポジショニング

分析で挙げた競合プロダクトとの相対位置を示しています。

usage-basedで大規模event dataを扱うmanaged data platform

参考リンク

関連プロダクト