Instanaを売ったMirko Novakovicが、Dash0で作ったのは監視ではなく修復だった

Dash0は、OpenTelemetryを土台にしたobservability platformです。

logs、metrics、traces、profiles、events、RUMを1つのstoreに集め、人間とAIエージェントの両方が同じデータを読めるように設計されています。出典

Mirko Novakovicは2023年10月のローンチ記事で「After building Instana and taking a break from startups and observability, we were impressed by how much OpenTelemetry has matured」と書き、標準が揃ったのに得られる洞察はまだ少ない、という違和感からDash0を始めたと説明している。出典

標準は揃ったのに、読む人が足りない

Novakovicが観測したのは、OpenTelemetryとPrometheusが事実上の標準になり、semantic conventionsがtelemetryの意味を揃え始めたのに、そこから洞察を得るには依然として専門知識が要るという状態だった。

同記事は「You still need very specialized knowledge to gain insights」と述べ、相関と文脈づけを製品の中心に置くと宣言している。出典

6つの原則からplatformへ

ローンチ時の約束は、install・integrate・customize・use・controlのしやすさと、insightの得やすさの6原則だった。

最初に公開したのはOTelBinというOpenTelemetry collector設定の可視化ツールで、自社製品より先にコミュニティ向けの道具を出した。出典

この順番は、データ形式を囲い込まずに信頼を得る戦略として後まで一貫する。出典

Agent0という転換

2025年11月にAgent0を出し、2026年6月3日に一般提供へ移した。

ここでDash0は「AI SRE」という呼び方をやめている。

公式ブログは、実際に効いた場面は障害が起きた後ではなく、その前後の日常的な調査だったと説明し、「An AI that only activates when an alert fires is solving maybe twenty percent of the problem」と書いた。出典

監視から修復へ

2026年7月の「Beyond Observability」で、Novakovicは立場をさらに進める。

coding agentが書いたコードのせいでPRあたりのincidentが243%増えたというFaros AIの調査を引き、「Code is generated at machine speed. Production is still run at human speed.」と整理した。出典

ここから、AIが書く側を統制するDarkplane、AIが動かす側を自動化するAgent0、両者が読み書きするSignalStoreという3製品の形が決まった。出典

買収で内側を作り替える

2026年8月、Dash0はPolar Signalsを買収した。

発表によれば、動機は製品の足し算ではなく、ClickHouseを使っていたSignalStoreの内部を、Polar Signalsが5回作り直したデータベースGreat Lakesへ置き換えることだった。出典

Novakovicは買収発表で「Software is increasingly written and run by agents, and agents need ground truth about what code is actually doing」と語っている。出典

観測を作る会社が、観測対象そのものをAIへ移した時期に、自分のデータ基盤まで作り直したことになる。出典

observabilityの痛みは、telemetryが増えるほど請求が増え、障害対応の初動が人に依存することです。

Dash0はSignalControlで取り込み前にデータを絞り、storageは残した分だけ課金する構造にした。出典

「何を見るか」と「いくら払うか」を同じ画面で扱える点が、DatadogやGrafanaからの移行検討で比較材料になる。出典

さらにAgent0は、異常の検知で終わらず、原因のcommitを特定して修正のpull requestを出すところまでを1つの作業として扱う。出典

監視の価値が「気づける」から「直せる」へ移ると、導入の意思決定者はSREだけでなく開発チーム全体になる。出典

OpenTelemetryという共通規格の上に、SignalStoreという自前の保存層と、その上で動くAgent0を持つことが堀です。

データ形式を囲い込まないと宣言しつつ、保存と推論の実装は自社で持つため、乗り換えの摩擦が小さく、真似する側は保存層から作り直す必要がある。出典

ネットワーク効果は弱めです。

OTelBinやagent-skillsのようなOSSは認知と信頼を広げるが、顧客のtelemetryが増えるほど他社顧客の価値が上がる構造ではない。出典

強いて言えば、MCP経由でagentが使うほど社内の文脈がSignalStoreへ蓄積され、乗り換えコストが上がる点が緩やかな効果になります。出典

中心は、Kubernetesとserverlessが混在し、SREと開発の境界が薄い中規模以上のengineering組織です。

Zalando、Taco Bell、The Telegraphのような大企業のほか、ChargetripやcatchHRのようなプロダクト企業が導入事例として挙がっている。出典

第一に、OpenTelemetryを土台にしたことで、既存の計装を捨てずに乗り換えられた点です。

移行の主な作業がcollectorの向き先変更で済むため、比較検討から導入までの距離が短い。出典

第二に、透明な従量課金を製品の一部にした点です。

SignalControlで取り込み量を削り、storage課金を残した分だけに限定し、請求の予測可能性を売り文句にした。出典

第三に、買収を機能追加ではなく基盤の入れ替えに使った点です。

Polar SignalsのGreat LakesをSignalStoreのbackendへ据える判断は、コストと拡張性を同時に扱う狙いだと説明されている。出典

リスクは、AIが修正まで踏み込むほど、誤ったpull requestや見落としの責任範囲が曖昧になることです。

公式も「Agent0 drafts; you decide」と、人間の承認を前提に置いている。出典

もう一つは価格と価値の説明コストです。

ingestion・storage・Agent0 creditsという3種類の課金は、使われ方の変化に応じて請求の読み方が変わる。

利用が読みにくいと、透明性そのものが導入の障壁になり得る。出典

買収の連続も統合リスクを伴う。

LumigoとPolar Signalsの技術と人を1つのplatformへ畳む過程では、製品ごとの挙動差がサポート負荷として現れやすい。出典

成長の中心はtechnical contentとopen source、そして比較検討の入り口づくりです。

OpenTelemetryの解説記事やOTelBinのような道具を先に配り、collector設定の相談から導入へ入る流れを作った。出典

2026年はUS市場とエンタープライズへ軸を移し、Baldertonの発表ではDatadogやGrafanaの置き換えを狙うと明記された。

クラウドmarketplace経由の購入も用意し、既存のcommitted spendに乗せる販路を開いている。出典 出典

トレードオフは、買収による拡張が速いぶん、product messageが「observability」から「AIの制御」へ動き続け、既存顧客の理解が追いつく前に名前が変わり得ることです。出典

主要チャネル: technical blog, open source (OTelBin / agent-skills), conference (KubeCon / Signals), comparison pages (Datadog / Grafana 等), cloud marketplace (AWS / GCP / Azure / Vercel)

observabilityの差別化は、ダッシュボードの見た目ではなく請求の読みやすさとデータの持ち方で決まりつつあります。

Dash0は規格を開き、保存と推論を自社に残す形で、移行のしやすさと堀を両立させようとしている。出典

もう一点、AI機能を足す前に「誰が読むか」を設計した点は参考になります。

telemetryの読み手が人間からagentへ変わる前提でAPIとMCPを先に整えたことが、Agent0の価値につながった。出典

日本では、既存の監視ベンダーとの契約更新期に、OpenTelemetry準拠と従量課金の説明を通せるかが勝負になります。

特に通信・製造・小売のように複数クラウドとオンプレが混在する組織では、self-hostedのSignalControl Edgeを置けるかが導入可否を分けます。

加えて、Agent0が作ったpull requestを誰が承認するかの運用設計を先に決める必要があります。

日本の組織では権限と監査の説明がないとAIの修正提案が止まりやすいため、承認フローとログの提示が導入前の要件になります。