SaaSの生存を採点する（Part 5）：データドッグ徹底解剖——12ファクター採点とモデル層検証で見るテレメトリの強さ

※本記事は「Part 1：エージェント型AIが迫る三つの経路」「Part 2：価格決定力・マージン・受益者と、22社のVAR耐性スコア」「Part 3：VAR耐性スコアカードの採点フレームワーク」「Part 4：Palantir徹底解剖」の続編となります。三つの経路と12ファクターの採点フレームワークを先にお読みいただくと、本稿の内容がより明確になります。

Part 4ではPalantir（PLTR）を取り上げ、経路3——経験層・ワークフロー・データの三層すべてを保有する経路——にとどまり続ける理由と、モデル層レバレッジ（B1）・バリュエーションの非対称性（C2）を引き上げた根拠を検証しました。本稿では、精査対象の2社目としてデータドッグ（DDOG）を取り上げます。

バケットと経路

データドッグの分類は据え置きです。バケットは成果連動型プラミング（OLP）、割り当てられた経路は成果レバレッジを伴う経路2——サードパーティのエージェント型経験層の下でヘッドレスのまま生き延びつつ、エージェントの量そのものから対価を得る形です。

SCORECARDの数値

• A1 システム・オブ・レコードの深さとデータ重力：4.0（前稿の暫定3から精査後に引き上げ）
• A2 ワークフロー吸収性（大脳テスト）：4.5
• A3 提供職能の需要弾力性：3.5（前稿の暫定4から精査後に引き下げ）
• A4 経路の運命と経路の質：4.0
• A5 成果への貢献度（天井テスト）：5.0
• B1 モデル層レバレッジ：3.5（前稿の暫定3から精査後に引き上げ）
• B2 組織の代謝：4.0
• B3 価格モデルの俊敏性：5.0
• B4 信頼・セキュリティ・ガバナンスの態勢：4.0
• B5 出荷ケイデンス：5.0
• C1 トークン経済下のマージン軌道：4.0
• C2 倍率に織り込まれたシナリオ（Rule of Xグリッド）：3.0

(出典: Convequity)

これは弱い結果ではありません。高いA5（無界で量に対して弾力的な成果）と高いB3（既に効いている従量課金）の組み合わせこそが、フレームワークが定義する成果連動型プラミングそのものです。大脳はその資産を必要とし、エージェントはその資産がこなす仕事の量を何倍にも増やし、従量課金がその成長を収益へと変換します。データドッグは、カバレッジ・ユニバースの中でこのパターンを最も明確に体現する大型株です。

同時に経路3でもありません。フレームワークの規定では、A4を5.0にするにはB1が4以上であるか、支配的な規制の堀があることが必要です。データドッグはそのいずれも持っていません。オブザーバビリティとSRE（サイト信頼性エンジニアリング）は深いものの、企業全体のSaaSの幅に比べれば相対的に狭いドメインです。Bits AIはデータドッグのデータプレーン上で調査と是正を保有しうる一方、顧客はCRM・人事・財務・IDなど、Bitsが置き換えない他のシステムを依然として横断的に運用しています。これはPalantir型の経路3が定義する、複数ドメインにまたがる経験層の保有ではありません。

データドッグの製品戦略も、この経路2という判定を明確にしています。Bits AIは、検知・調査・是正のためのデータドッグ自身のエージェント型インターフェースです。一方でMCPサーバーは、Cursor、Claude Code、Codex、AWS DevOps Agentなどのサードパーティ製エージェントが、データドッグのUIを使わずに生のテレメトリへ直接問い合わせることを可能にします。これは意図的な配管設計です——運用担当者がデータドッグのUIを使おうと、Bits AIを使おうと、外部のコーディングエージェントを使おうと、データプレーンはワークフローの中に残り続けます。

経路2——なぜデータドッグは経路3ではなく成果連動型プラミングなのか

VAR耐性フレームワークにおいて経路3とは、既存企業が経験層・ワークフロー・データのすべてを端から端まで保有することを意味します。経路1は完全な内製置き換え、経路2はサードパーティのエージェント型経験層の下でのヘッドレスな生存であり、ベンダーはワークフローとデータの層を保持し続けます。データドッグは成果レバレッジを伴う経路2——単に耐えるだけでなく、エージェントの取引量そのものに参加していく、経路2の商業的・アーキテクチャ的な形——と評価されます。

ホスト起点のテレメトリという吸収境界線

中心となる構造的な主張は、オブザーバビリティが、AIモデルにとって容易に吸収できるワークフローと機能の集合ではない、という点です。

データドッグのアーキテクチャは、ホストを起点にエージェント・ファーストで設計されています。アプリケーション・仮想マシン・ベアメタルが動く場所に、ソフトウェア・エージェントがインストールされます。それらのエージェントはメトリクス・ログ・トレース・セキュリティ信号などのテレメトリを収集し、一元化された統合データプレーンへ送り込みます。そのプレーンは深いシングルペインのUIを通じて、そして次第にはエージェント向けのインターフェースを通じても提示されます。シングルペイン・オブ・グラスは単なるダッシュボード製品ではなく、調査を分断するサイロを持たない、その背後にある多信号のデータ層そのものの証拠です。AIエージェントは、まさにこの種の相関の取れた、問い合わせ可能な文脈の上で力を発揮します。

これはアプリケーション系SaaSとは異なる吸収境界を作ります。フロンティアモデルとエージェント・フレームワークは、コネクタ・API・MCPのようなプロトコルを通じてSaaS製品へ接続し、アプリ内・アプリ間のワークフローを縫い合わせることを、ますます容易にしています。ホスト発のテレメトリはこれとは違います。データドッグのクラスの作業を代替するには、モデルラボが顧客のクラウド・オンプレミス環境にオブザーバビリティ・エージェントを構築・展開し、企業規模のマルチテナント・テレメトリ・プレーンを運用し、再計装と過去の基準値の喪失によって切り替えが非常に高コストになる顧客を勝ち取る必要があります。これはファウンデーションモデル企業にとって、自然な副業ではなく、完全なインフラ製品の事業そのものです。以下で扱う未解決の問いは、コーディングエージェントがこのインセンティブを変え、本番環境のフィードバックとポストデプロイの学習のために、ラボがそれでもホスト側の収集に乗り出すのかどうかです。

より単純に言えば、AIモデルはシステムに接続されているがゆえに、アプリ内のワークフローとアプリ間のワークフローを吸収していきます。一方、ホスト上のテレメトリとして発生するワークフローは、物理的なオブザーバビリティ・エージェントをホストに展開する必要があるため、容易には吸収されません。オブザーバビリティは、AIエージェントが吸収するものではなく、必要とするものです。ワークフロー吸収性（A2）が高い水準——4.5——にある理由はここにあります。完全な5.0ではない理由は後述します。

AIコーディング、複雑性、そして成果の天井

クラウドとAIはソフトウェア創出のスピードを加速させています。その二次的な効果として、開発者やチームが、AI以前の手書きコードベースの時代ほど本番システムを完全には理解していない可能性があります。より広い表面積、より不透明な依存関係、人間が1行ずつ書いたわけではないままに本番で壊れうるものが増えているのです。これは運用上の複雑性と、観測する価値のあるものの量を押し上げます。

エージェントの増殖も同じ方向に働きます。より自律的なソフトウェアは、時間とともに——場合によっては大きな倍率で——サービス・スパン・LLM呼び出し・ツール呼び出し・ホスト信号の増加を意味します。コードの所有感がより希薄なまま、より速くソフトウェアが作られることは、オブザーバビリティにとって構造的な量の追い風です。その量がデータドッグに留まり続けるのか、それとも一部がコーディングエージェント・ネイティブなツールへ移っていくのかは、別の問いです。これが成果の天井の物語です——価値あるオブザーバビリティ作業の量は拡大し続けうる、という点であり、A5の5.0を支え、既に消費従量型の商業モデル（B3の5.0）に養分を与えます。これは単体では、SRE人員やオペレーション機能の需要弾力性についての主張ではありません。それは別途A3として扱います。

A3とA5——監視すべき量ではなく、その職能への需要そのもの

A3とA5は、インフラ系ベンダーにとって混同されやすく、切り分けておくべきものです。

A5が問うのは、価値ある成果の量が無界かどうかです。データドッグにとって答えは「はい」です。ホスト・サービス・テレメトリ・エージェントが増えるほど、価値ある監視の量が増えます。これが天井テストであり、5.0と採点されます。

A3が問うのは異なる問いです。AIによって人がその職能でより生産的になったとき、その職能への需要はそれでも拡大するのか、というものです。営業や製品エンジニアリングのような収益を生む職能ではジェヴォンズのパラドックスがしばしば当てはまり、生産性の向上がそのまま同じ仕事の増加、同じ役割の増加につながりえます。オブザーバビリティはコストセンター寄りの運用職能に近い性質を持ちます。インフラとエージェントの量を固定したまま、経験層のAIが検知・調査・是正を速くするだけだと仮定すると、企業がそれだけの理由でIT要員を増やす可能性は低いでしょう。トリアージが速くなることで、より多くのアプリケーションや機能を出荷する余力が生まれ、それが後により多くの監視対象を作るかもしれませんが、その経路は間接的で不確実です。オブザーバビリティは製品スタックと信頼性に結びついているため、収益への連動は間接的なものにとどまります——CRMのような純粋な収益エンジンではなく、損失防止とイネーブルメントの性格が強いのです。

本稿ではしたがって、A3を4.0ではなく3.5と採点します。このスコアは、信頼性がデジタル製品にとって不可欠であり続けるため、純粋なバックオフィスのITサービス管理（ITSM）圧縮の水準よりは上に位置します。一方で、経験層のAI生産性がops要員の需要を確実に拡大するとは言えないため、強いジェヴォンズ効果を持つ銘柄群よりは下に位置します。成果連動型プラミングという評価は揺らぎません。成長エンジンは高いA5と高いB3——監視対象の量が拡大し、それが消費量に応じて課金される——であり、企業がダッシュボードを見る人員を増やし続けるという賭けではありません。

検知・調査・是正——三つの層がルート上のどこに位置するか

VAR耐性の三つの経路は、製品を三つの層に分けます。経験層（利用者やエージェントがどう操作するか）、ワークフローと機能の層（何が実行されるか）、データの層（何に対して作業が行われるか）です。データドッグのエージェント型製品の言葉——検知・調査・是正——は、この三層がエージェントの圧力の下でどこに位置するかを示す有用な地図になります。

検知は、運用上の形をとったデータ層です。ホストと製品のセンサー——オブザーバビリティ・エージェント、Watchdog、セキュリティ信号——が、生のテレメトリから問題を浮かび上がらせます。この収集の工程は、信号が顧客のホスト・仮想マシン・ベアメタル上で発生するため、モデル企業にとって吸収しにくいものです。データドッグのようなエージェントが環境内に展開されていなければ、そこには推論の対象となる継続的な多信号フィードが存在しません。したがって検知は持続的な基盤です——拡大する大脳はこのテレメトリ・プレーンを必要としますが、SaaSのAPIとチャットで再現できるものではありません。より困難な経路——ラボが自前のホスト・コレクターを展開する——は現実にありえますが無償ではなく、後述するようにベースケースというより監視すべきリスク経路として扱います。

調査と是正は、ワークフローと機能の層です。Bits InvestigationとBits AI SREは自律的なオンコール要員のように振る舞い、メトリクス・ログ・トレース・変更履歴・コードの文脈などを横断した複数仮説の根本原因分析を行い、その結果をSlack・オンコール・ケース管理システムへ届けます。Bitsは単なるダッシュボードの上のチャットボックスではありません。人間がノートパソコンを開く前に、多くの仮説を並行して探索できます。Bits Codeと関連するアクションは、プルリクエスト形式の是正提案を含む修正の提案にまで広がり、ワークフローのアクションにも及ぶため、ループはデータドッグの文脈の内側で閉じられます。ここでデータドッグは、単なるログの受動的なデータベースではなく、トリアージ・相関・ランブック主導の調査、そして修正への道筋という、本物の運用ワークフローを保有しています。

Bits Database Optimizationは、本番環境への深い足場が、モデル企業に対する堀になっていることのさらなる証拠です。データドッグのエージェントは既にホスト上に存在し、データベースが実際にどう振る舞うかを見ています。その足場があるからこそ、データドッグは顧客のデータベースのシミュレーション・コピーを立ち上げ、最適化案を出荷する前にテストできます——書き換えは、LLMが提案しただけのものではなく、実際のパフォーマンス数値によって検証されるのです。モデル企業は既にMCP経由でデータドッグのテレメトリを取得し、外部から調査や是正を助けることができ、実際にそうしています。彼らが持っていないのは、そうしたテストを支える、本番環境内に既に存在する同じ足場です。データドッグの優位性は、モデルがデータに触れられないことにあるのではなく、既に環境内にあるエージェントが、データベース最適化を安全にテストするといった工程に、追加のノウハウを与えてくれることにあります。この機能はまだ初期段階でPostgresを主対象にしていますが、戦略的な論点は明確です。

(出典: Convequity)

この区別は経路2にとって重要です。弱い経路2のベンダーは、経験層とワークフロー層の両方がサードパーティのエージェントに吸収された後、薄いデータ残余しか手元に残りません。データドッグはそうした形ではありません。データ層（検知／ホストのテレメトリ）は、アプリ層のSaaSよりも構造的に安全です——ただし、ラボがグリーンフィールドやエージェント・ネイティブな作業向けに自前のコレクターを出荷すれば、まったく挑戦を受けないわけではありません。ワークフロー層のかなりの部分も、そのテレメトリに引き続きつながれています。調査と是正は、相関の取れたメトリクス・ログ・トレース・トポロジー・履歴があって初めて機能するからです。AIモデルは、本番システムの別の物理法則を発明することでこれらのワークフローを「破壊」するのではなく、既に収集済みのテレメトリの上で動くか、そうでなければ環境そのものが見えないかのどちらかです。その意味で、ホストのテレメトリを起点とするワークフローは、完全に空洞化させることが難しいものです。動きうるのは誰がそのワークフローを実行するか——データドッグのBits、データドッグのUI上の人間、あるいは外部のエージェント——であって、そのワークフローがテレメトリ・プレーンに依存し続けるかどうかではありません。

サードパーティのエージェント型インターフェースは、既にこの点を示しています。MCPサーバーを通じて、Claude Code、Codex、Cursor、AWS DevOps Agentのようなエージェントは、データドッグ自身のUIを使わずに、生のデータドッグのデータへ問い合わせ、調査に近い作業を実行できます。これは経験層における本物の競争であり、ワークフロー層でも部分的な競争です——別のエージェントも仮説を立て、信号を引き出し、次の手を提案できます。しかしそれは、データ層が吸収されたことを意味しません。それらの外部エージェントは、データドッグのプレーンの消費者であって、ホスト収集・多信号相関・長期にわたる運用文脈の代替ではありません。データドッグが意図的にデータ層を露出させているのは、経験層が複数のインターフェースにまたがったとしても、エージェントが呼び出すシステムであり続けるためです。

Bitsは、検知・調査・是正を一つ屋根の下に置く、そのプレーン上での第一義的な経験とワークフローを保持するためのデータドッグの賭けです。MCPは、経験がどこか他の場所にあっても、必須の配管であり続けるためのデータドッグの賭けです。合わせると、これは質の高い成果レバレッジを伴う経路2です——データ層は安全で、ワークフロー層は依然として意味を持ち、経験層は競争にさらされており、そしてCRM・人事・財務など残りのスタックにまたがる企業全体のエージェント型インターフェースをデータドッグが保有しているわけではないため、経路3ではありません。

モデルラボの拡張テスト——コーディングエージェントのための第一義的オブザーバビリティ

ホスト起点のエージェント吸収境界は、一つの問いにはよく答えます——モデル企業はSaaSのAPIとチャットするだけでデータドッグを気軽に置き換えるだろうか。ほぼ確実に否です。より鋭い問いは、コーディングエージェントがバイブコーディングを超えて企業の本番品質へ進化するために、モデルラボ自身がオブザーバビリティへ拡張していく必要があるかどうかです。これは別の拡張経路です——インセンティブに駆動され、第一義的で、データドッグの企業向けの本を一夜にして奪うことよりも、ラボ自身の製品品質を狙ったものです。

拡張を支持する論拠は本物です。コーディングエージェントは既にコードを書き、出荷し、デプロイしています。さらなる品質向上を阻む制約は、もはや最初のコード草稿ではなく、検証・本番フィードバック、そしてコード・デプロイ・観測・改善という閉じたループです。コードだけを生成し、そのコードに関連するテレメトリとメトリクスを所有しないラボは、半分目隠しで飛んでいるようなものです。本番で何が壊れ、何が自己修復し、どの是正が定着したのかを体系的に学習できません。この見立てに立てば、ラボは自前のコーディングデータと関連する実行時信号を社内で計装する意志を持つはずであり、そうしなければコーディングエージェントの能力はそれ以上改善できません。そのループを閉じられる者だけが、バイブコーディングのデモではなく、本番品質のコーディングエージェントを主張できます。第一義的な競争がそもそも起こりうるという事実そのものが、誰かがデータドッグの企業規模のプラットフォームより優れたAIネイティブなオブザーバビリティ製品を作れると証明する前から、データドッグにとってのリスク・スコアになります。

価格設定も同じリスクを鋭くします。データドッグは高価です。人間のopsチームが完全なプラットフォームを購入する分には、それはしばしば問題になりません。エージェントがサービス・トレース・デプロイを何倍にも増やし、請求額もそれに応じて上がるとなると、話は難しくなります。モデルラボがコーディングエージェントやクラウドの請求に軽量なオブザーバビリティを含めるなら、顧客は、データドッグの方が広い環境全体には優れているとしても、エージェント負荷の高い作業をそちらに置く可能性があります。

Convequityの回答は、リスクをゼロだと装うことなく、構造的なベースケースを維持するものです。企業向けオブザーバビリティは「コレクターを書く」だけの話ではありません。異種混在のマルチクラウド、ベアメタル、規制環境にまたがる特権的な展開、多信号の相関、長期の基準値、コンプライアンスとベンダーリスクのレビュー、そして名指しのサポートを伴う24時間365日の信頼性です。コーディングエージェントは主に、自らがデプロイするグリーンフィールドのコードを見るのであって、エージェント以前から存在するレガシーなアプリやサードパーティ製ソフトウェア、インフラを自動的に計装するわけではありません。その環境全体を勝ち取ることは、モデルラボが歴史的に運営したがらなかった、運用・信頼・営業体制の事業です。ベースケースは、コーディングエージェントがオブザーバビリティ・プレーンの顧客であり続ける——MCPサーバー経由も含めて——というものであり、これが量とOLPを支えます。ラボがデータドッグの検知・調査・是正スタックより優れたAIネイティブ製品をエンジニアリングできるかどうかは、本当に不確実です。データドッグに対する製品品質での敗北を前提とはしていません。

不確実ではないのは、二つの時間軸にわたる残余リスクです。第一に製品とシェアです。大手ラボが、コーディングエージェントに紐づいた本番品質・企業サポート付きのオブザーバビリティ・ハーネスをパッケージ化すれば、レガシー環境がデータドッグに留まったままでも、グリーンフィールドとエージェント・ネイティブなワークロードは剥がれうるでしょう。第二に、そしてエクイティのリスクとしてはより直近のものとして、市場と投資家の反応があります。データドッグの倍率にとっての真の短期リスクは、証明済みの企業内での置き換えだけではありません。コーディングエージェントに第一義的なオブザーバビリティ能力を持たせるという、ラボによる信頼性の高い発表そのものです。それだけで、製品が企業での牽引力をどれほどゆっくり得るかにかかわらず、「モデルがワークフローを吸収する」という物語をデータドッグに不利な形で再構成し、投資家を動揺させかねません。コンセンサスはこの物語のリスクをなお過小評価しており、先入観のない分析はそれを採点に反映する必要があります。

A2が5.0ではなく4.5と評価される理由はここにあります。ホスト発のテレメトリ・プレーン、統合された多信号のデータ層、そしてオブザーバビリティ・エージェントを物理的に展開する必要性は、モデル企業が片手間の副業として吸収するには依然として困難です。もはや完璧な盾ではありません——コーディングエージェントの品質のために本番フィードバックを所有したいというモデルラボのインセンティブは本物であり、第一義的な競争はゼロではない確率であり、プレミアム価格はエージェント規模において一段と鋭い脆弱性であり、市場の再評価リスクは製品のシェアより先に株価を直撃しうるからです。4.0以下への完全な引き下げには、環境全体の吸収を監視すべき拡張経路ではなくベースケースとして扱う必要があり、我々はそこまでは踏み込みません。

Bitsメモリと、散らばった運用知識

調査の成否は、システムとテレメトリのデータだけから生まれるわけではありません。IT・SRE・アプリケーションチームが持つ運用知識——誰がそのサービスを所有しているか、前四半期に何が壊れたか、どのランブックが効いたか、どのSlackスレッドが似た障害を既に診断していたか——と組み合わさっています。その知識は微妙で、何年もかけて積み上がり、企業内に散らばっています。呼び出された担当者が答えを知らないこともあれば、答えを持つ担当者が問題の存在自体を知らないこともあります。

Bitsは、この調整コストを減らすために設計されています。文書化された知識源には、ランブック、bits.mdのような環境の文脈、過去の調査からのフィードバックと記憶が含まれます。Slackやケース管理システム（サービスナウ（NOW）やJiraのパターンを含む）への統合により、調査の文脈が既に業務担当者が働いている場所に置かれます。時間の経過とともに、これはスイッチングコストを積み上げます。データドッグを離れることは、再計装と基準値の喪失だけでなく、調査の記憶と多信号の履歴の喪失も意味するからです。これが、A1が3.0ではなく4.0と評価される重要な理由です——組織的な知識の蓄積によって強化された運用上の重力であり、規制対象の取引系システム・オブ・レコードの深さには依然として及びません。

同じ頭脳を共有するエージェント群——それでもサードパーティ製プラットフォームは必要か

データドッグを別の角度から検証する方法は、「ラボはコレクターを出荷できるか」ではなく、「エージェント化されたチームは、そもそもサードパーティのオブザーバビリティ・プラットフォームを必要とし続けるのか」という問いです。

一元化されたサードパーティのプレーンが必要な、人間側の事情は明確です。1000人の開発者を抱える部署は、1000通りの異なる頭脳です——習慣も、注意深さの水準も、出荷とデバッグのやり方も異なります。彼らには、チームが1000通りのローカルな物語から言い争うのではなく、協調できるよう、共有された「地上の真実」の場所——メトリクス・ログ・トレース・履歴の相関の取れた単一の見取り図——が必要です。Bitsメモリは、部分的にはこの人間の調整問題へのデータドッグの回答です。

では、同じ部署を1000体のエージェントが、同じモデルラボから運営していると想像してください——1000体のClaude級のエージェントがコーディング・デプロイ・調査・是正の作業を行うのです。彼らは本質的に同じ頭脳を共有しています。なぜデータドッグが必要でしょうか。SlackなどのチャネルでAI同士が話し合い、文脈をネイティブに共有し、間にベンダーを挟まずにパフォーマンスとインフラの問題を閉じられます。一部のモデルラボは既に、社内のチャットツールで重厚なエージェント連携を運用しています。この見方に立てば、サードパーティのオブザーバビリティ・プラットフォームは、人間の多様性と人間の帯域幅を修正するためのものでした。同じ頭脳を共有するエージェント群には、同じ調整の失敗モードがないかもしれません。

これへの反論は、客観性と判断の多様性です。独立したサードパーティのプラットフォームは、単なるチャット・バスではなく、コードを書いて出荷したのと同じスタックに属さない、共有の測定システムです。1体のモデルの1000個のコピーが自らの出力を調査・是正するのは、デプロイし、デバッグし、パッチを当てる1人の熟練開発者が、大規模並列の速度で動いているのに近いものです。それはうまくいくこともあります。しかし同時に、同じ盲点を規模を伴って再生産することもありえます——バグを書いたモデル自身には良く見える場当たり的な修正、根本原因への弱い異議申し立て、そして別のチームや別のツールが異なる信号を見たときに得られるはずの押し戻しの乏しさです。頭脳の多様性は、単なる人間の調整コストではなく、悪い診断や狭い診断へのチェック機能でもあります。同質なエージェント群は、集合場所としてのプラットフォームの必要性を減らす一方で、1つのモデルの習慣に捉われない独立した「地上の真実」の層の必要性を高めうるのです。

エージェント群が多様化していれば、この構図は再び反転します。多くの企業は、1つのモデルの1000個のコピーを運用するわけではありません。既に人間の開発者やツールを混在させているのと同じように、異なるラボ由来のコーディングエージェント——異なる頭脳、異なる習慣、異なる強み——を組み合わせるでしょう。その世界では、調整の問題は人間の場合により近く見えます。エージェントたちは、それぞれ自社ラボの文脈だけから議論するのではなく、共有のサードパーティの地上の真実を必要とします。データドッグのプラットフォームは、その役割のために構築されています。同一頭脳のモノカルチャーは、サードパーティのプレーンの必要性に最も強く挑戦するシナリオであり、複数ラボにまたがるエージェントの多様性は、データドッグが必要とされ続ける構造的な理由です。

Convequityの立場は両極の中間にあります。チャット・ネイティブなエージェント連携は、Bitsメモリとチケッティング統合が今日対処している人間の調整コストの一部を吸収しうるでしょう。これはopsツールの経験層とワークフロー層に対する本物の圧力です。しかしそれは、サードパーティのデータプレーンの意義を消し去るものではありません——客観的な多信号の履歴、どの1つのエージェント・セッションよりも長生きする基準値、そして変更を出荷したのと同じ頭脳が所有していない場所で本番を測定する場所です。同一頭脳のエージェント群は、このリスクの最も鋭いバージョンであり、異なるモデル企業由来の多様なエージェントは、データドッグが必要とされ続ける構造的な理由です。残余のケースは、エージェント同士が話せないということではなく、独立した測定が依然として重要であり、複数ラボのエージェント・チームが共有のプレーンを必要とし、短期的な自己是正は持続的な信頼性と同じではない、ということです。

Toto、Bits、Adaptive ML——モデル層の実態

自然に浮かぶ疑問は、Bits AIがデータドッグ独自のデータ層で事後学習されたデータドッグ製の基盤モデルなのか、というものです。公開されている証拠が示すのは、単一の閉じたデータドッグ製フロンティアLLMではなく、ハイブリッド型のスタックです。Totoと Bitsは同じ層ではなく、補完関係にあります。Totoはメトリクスの時系列に特化し、Bitsはより広いテレメトリと運用の文脈を横断して推論するエージェント型インターフェースです。

このハイブリッドは、SaaS全体との比較ではそれでも強い回答です。モデル層への拡張——本物の時系列基盤モデル（TSFM）の構築に加え、事後学習と強化学習をopsデータへ適用していく経路——は稀です。大多数のSaaSベンダーはこれを行っていません。ほとんどは、他社のモデルの上に乗る薄いラッパー、RAG、あるいは薄いエージェントUIにとどまっています。データドッグは、精神的にはドメイン特化のNeolab——ドメインに偏った独自のコーパス（大規模なオブザーバビリティのメトリクス）を保有し、その上に基盤モデルを構築し、チャット機能だけでなく検証とRLのループへ向かう——のように見える、数少ない公開ソフトウェア企業の一社です。Convequityの見立てでは、データドッグはこの軸においてSaaS企業として達成しうる水準にほぼ近いところまでやっており——オブザーバビリティ向けに事後学習された基盤モデルの領域ではフロンティアかそれに近く、カバレッジ・ユニバースの中でもドメイン特化の基盤モデルの先頭集団に位置します——それでも、本物のモデルの取り組みを伴った、エージェント対応の配管を求める投資家にとって質の高い構造的な銘柄であり続けます。

留保すべきは独自性です。オブザーバビリティ領域の内側では、TSFM型やAIOps型のモデルの取り組みはデータドッグの専売特許ではありません。他のオブザーバビリティ・監視企業も、ドメインモデル・異常検知インテリジェンス・エージェント型opsを構築しています。したがって正しい捉え方は「これができるのはデータドッグだけだ」ではなく、「SaaS全体の中ではこの能力は稀だが、オブザーバビリティの内側では競争にさらされている」というものです。それでも高い適応スコアは支持されますが、Totoを競合に対する難攻不落の堀として扱うことまでは支持しません。

第一に、TotoとToto 2.0はデータドッグが構築した時系列基盤モデルであり、オープンウェイトで公開され、大規模なオブザーバビリティのメトリクスで事前学習されています。WatchdogやBitsクラスの能力に供給される予測と異常検知的なインテリジェンスを改善します。これは、自社の自然なコーパスの上での本物のドメイン基盤モデルの取り組みです——汎用的なメトリクス計算や薄いRAG以上のものです。自社の自然なコーパスの上でTSFMを出荷するという動きそのものが、大半のSaaSが決して手を付けないタイプのモデル層への拡張であり、賞賛に値します。

第二に、Bits Investigation、Code、Chat、Security Analyst、Agent Builderは、顧客のテレメトリ・トポロジー・ランブック・調査の記憶を使って調査と是正を行うエージェント型製品です。本番環境では、主にフロンティアの大規模言語モデルを呼び出しており、データドッグ自身のデータとツールを文脈として使う形であって、それらのフロンティアモデルを置き換える単一のデータドッグ製チャットモデルではありません。調査のフィードバックと記憶は学習の信号を作りますが、まだ独占的なopsワークフローに対する本格的な産業レベルのRLHFやRLAIFのループには至っていません。Bitsはコード修正を提案でき、それは本物の製品です。限界は構造的なものです。データドッグは本番環境を見ていますが、顧客のアプリケーション・コードを書いたわけではありません。

第三に、Adaptive MLの買収は、実世界のインフラとセキュリティ信号を使った世界モデルとエージェント型LLMの事後学習のための、RLOpsプラットフォームをデータドッグAIリサーチにもたらします。これは体系的な事後学習に向けた本物の一歩ですが、フライホイールが既にB1＝4の水準で回っている証拠ではありません。

より長期的で困難なモデル層のリスクは、ダイナトレース（DT）がより優れた異常検知モデルを出荷することではありません。コーディングエージェントが、いまやボトルネックとなっているソフトウェア・ライフサイクルの部分へ移動していくことです。コードの最初の草稿を書くことは容易になりつつあります。テスト、検証、そして本番からの学習——監視・検証・デプロイ後のフィードバック——が難しい部分です。さらなる改善のために、コーディングエージェントはこのループに手を出さざるをえません。本番でシステムを観測し、出荷したものをテストし、うまくいったものを強化するのです。そのループを閉じるモデルラボは、実質的にデプロイ後の強化学習を行っています——オフラインの評価だけでなく、コードが出荷された後にどう振る舞うかから学習するのです。データドッグに対する彼らの構造的な優位は、コードを知っていることです。コーディングエージェントは、自らが書いた変更の完全な文脈を持って観測し是正できます。データドッグは顧客のアプリケーション・コードを書かずにオブザーバビリティを行い、Bitsは修正を提案できますが、コードを書きかつその挙動を見るモデル企業は、コーディングの品質とオブザーバビリティの品質を一緒に複利で伸ばせます。これは、たとえドメインの時系列基盤モデルと企業規模の相関で先行していても、純粋なオブザーバビリティ・ベンダーにとって本物のシナジー・リスクです。

B1はしたがって3.5と評価されます——本物のドメインモデルの取り組み（3）と、独自の堀の上で回る体系的な事後学習・RLHF・RLAIF（4）の間です。Totoと関連するドメインモデルは本番環境で余裕を持ってドメインの基準を超えており、Adaptive MLと調査フィードバックのループは体系的な訓練へ向かいつつありますが、フロンティアラボをモデルそのもので出遅れさせるような、独占的なopsワークフローに対する閉じた強化学習フライホイールはまだ示されていません。満点の4.0には、独占的なopsワークフローに対する継続的な選好学習ないしRL訓練の証拠が必要でしょう。フロンティアラボは、汎用の言語モデルでは出遅れないままでも、ホスト側のエージェント展開の足場と企業規模の多信号相関では出遅れて始まることになります——一方、コーディングエージェントを保有していれば、コードを意識したデプロイ後の学習では先行して始まることになります。Adaptive MLの製品化と調査フィードバックの進展を、実行が証明されれば4.0への今後の一歩として注視します。要するに、データドッグのモデル層の取り組みはSaaSの中でも最良の部類にあり、質の高い成果連動型プラミングであり続けるはずです。残余のリスクはコーディングエージェントによるデプロイ後の強化学習であって、データドッグが基盤モデルに無頓着だということではありません。

SCORECARD READING（採点根拠の詳細）

A1（システム・オブ・レコードの深さとデータ重力）の4.0は、前稿の暫定3からの引き上げです。メトリクス・ログ・トレース・セキュリティ・RUM・LLMおよびエージェントのオブザーバビリティという複数製品にまたがるテレメトリに加え、ホスト側のエージェント展開とBitsメモリが、複数四半期にわたる再計装と基準値喪失のスイッチングコストを生み、蓄積された運用知識によってさらに強化されています。このスコアはERP・電子カルテ・コアバンキング級の破滅的なシステム・オブ・レコードの深さを主張するものではありません。他の高重力インフラ・セキュリティ銘柄との整合性が、3.0ではなく4.0を支持します。

A2（ワークフロー吸収性（大脳テスト））の4.5は中心的な評価です。ホスト発のテレメトリ、統合されたデータプレーン、そしてオブザーバビリティ・エージェントを物理的に展開する必要性は、エージェント型スタックが必要とするインフラです。SaaSのAPIへのツール呼び出しだけでエージェントが再現できる薄いワークフロー・ラッパーではありません。5.0を下回る0.5の理由は、コーディングエージェントが本番の観測・テスト・検証のループを自ら所有し、デプロイ後学習のために自前のコレクターを出荷しうるという、本物のインセンティブを反映しています。

A3（提供職能の需要弾力性）の3.5は、前稿の暫定4からの引き下げです。オブザーバビリティはコストセンター寄りの運用職能であり、収益との連動は間接的です。インフラの量を固定した場合、検知・調査・是正を速くする経験層のAIは、SRE人員の需要を確実に拡大するものではありません。製品スタックと信頼性の結びつきがスコアを純粋なITSMの床より上に保つ一方、量の成長はA3ではなくA5に属します。

A5（成果への貢献度（天井テスト））の5.0は、継続的で量に対して弾力的な成果を反映しています。より多くのホスト・サービス・スパン・セキュリティイベント・LLMやエージェントのセッションが、固定されたコンプライアンスの天井なしに、価値ある監視の量を押し上げます。これがB3とともに、成果連動型プラミングを定義する無界の天井です。

B1（モデル層レバレッジ）の3.5は、前稿の暫定3からの引き上げです。本物のドメインモデルの取り組み（3）と、独自の堀の上での体系的なRLHFやRLAIF（4）の間に位置します。本番環境のTotoと関連ドメインモデル、そしてAdaptive MLと調査フィードバックは、薄いRAG以上のものをクリアしていますが、まだ会社をエージェント型コンパウンダーへ再分類するほどの閉じたモデル・フライホイールには至っていません。

B2（組織の代謝）の4.0は、技術系創業文化、複数製品への展開、ログの経済性を再価格化・共食いしてでも量を取りに行く意志、そしてAdaptive MLを含む積極的なエージェント型の出荷を捉えています。

B3（価格モデルの俊敏性）の5.0は既に獲得済みです。商業モデルはホスト・量・取り込み量ベース——ホスト数、ログのギガバイト数、スパン数、カスタムメトリクス、BitsとLLMのクレジット——であり、コミット床とオンデマンドの超過分を伴う、座席課金SaaSからの移行途中ではない形です。

B4（信頼・セキュリティ・ガバナンスの態勢）の4.0は、エンタープライズRBAC、セキュリティ製品群、AI Guard、そして本番データへの安全なエージェント・アクセスのためのMCPガバナンスを反映しています。オブザーバビリティおよびセキュリティ・プラットフォームとしては高水準ですが、Palantir級の主権的でオントロジーに基づくガバナンスには及びません。

B5（出荷ケイデンス）の5.0は、Bitsスイートの拡張、MCPサーバー、LLMおよびエージェント・オブザーバビリティ、そしてTotoとAdaptive MLをめぐるリサーチとM&Aを含む、持続的なエージェント型の一般提供ケイデンスを反映しています。

C1（トークン経済下のマージン軌道）の4.0は、売上総利益率がおよそ80%近辺、フリーキャッシュフロー・マージンが20%台半ばの水準にあり、AI関連の量を収益化しうる従量課金を伴うことを反映しています。BitsにおけるトークンのCOGSは本物ですが、高いA5がトークンを純粋なコストではなく請求可能な成果へ変えます。

C2（倍率に織り込まれたシナリオ（Rule of Xグリッド））の3.0は、非対称性というより評価の中立性を意味します。フレームワークのRule of X対応表では、65〜90がおおむねEV/売上高6〜10倍、90〜120が10〜16倍、120以上がおおむね16倍以上に対応します。データドッグの概算——成長率30%弱×2.3に加え、フリーキャッシュフロー・マージン20%台半ば——はおおむね90台半ばとなり、90〜120帯、公正なEV/売上高レンジではおおむね10〜16倍の内側に収まります。現在の株価はEV/売上高でおよそ21倍で取引されており、この写像された公正帯を上回り、フレームワークがRule of Xのおよそ120以上に対応づける倍率のゾーンに位置します。これは、実行の良い経路2のエージェント量受益者に対するプレミアムではありますが、Palantir型の完璧を織り込み済みという極端な乖離（C2の2.0）でも、評価倍率が過去平均を大きく下回るトールロード型の保有対象でもありません。市場とファンダメンタルズは十分に近く、非対称性としての強い採点ではなく3.0が妥当です。

リスク

主なリスクは、競争の激しさ、消費量のボラティリティ、モデル層の評価の誇張、そしてより長期にわたる吸収経路であり、オブザーバビリティの必要性が薄れることではありません。

Grafana、オープンソース・スタック、ハイパースケーラー・ネイティブな監視は、価格とDIYによる代替の圧力をかけます。ダイナトレース、New Relic、そして専業のLLM評価ツールは、自動化と専門的な深さで競います。ログの圧縮とコスト管理は、エージェント数が増えても量を縮小させうるものであり、エージェントの物語と同じくらい単位経済性が重要です。

利用の最適化は、構造的なテーゼを壊さないまま、短期的な収益のエアポケットを作りうるものです。Bitsの調査と是正はデモに遅れをとることがあり、AIが生成した根本原因やコード修正への信頼はなお成熟の途上です。

信頼に値する長期的なリスクは、既にコードを書き・出荷し・デプロイしているコーディングエージェントが、自ら管理するホストに軽量なコレクターを組み込み、コード・デプロイ・観測・改善というネイティブなループを閉じてしまうことです。このインセンティブは本物です——検証と本番フィードバックは、最初のコードを書くことに比べて既にボトルネックであり、モデルラボは自己修復と事後学習のための地上の真実を欲しがるはずです。その世界では、独立したオブザーバビリティ・プラットフォームは、同じエージェント型パイプラインが所有する計装ほど「ネイティブ」には見えなくなりえます。

我々はこの経路を、データドッグのプレーンの短期的な吸収としては扱っていません。コレクターを書くことは容易ですが、異種混在のマルチクラウド、ベアメタル、規制環境にまたがって特権的なエージェントを運用する企業の信頼を勝ち取ることは——多信号の相関、長期の基準値、コンプライアンス、24時間365日の信頼性を伴って——別の事業です。コーディングエージェントは主に、自らがデプロイするグリーンフィールドのコードをカバーするのであって、レガシー環境全体を自動的に計装するわけではありません。ベースケースは、コーディングエージェントがオブザーバビリティ・プレーンの顧客であり続ける（MCP経由を含む）というものであり、これが量を支えます。注視すべきリスクは、大手ラボやクラウドが、グリーンフィールドのサイドカーを超えた本番品質・企業サポート付きのオブザーバビリティ・ハーネスをパッケージ化することです。

もしAdaptive MLと調査フィードバックが体系的な独自の事後学習に至らなければ、B1は3.5近辺にとどまり、データドッグは強い成果連動型プラミングであり続けます——それは良い結果であって、経路3ではありません。Bitsにエージェント型のUIがあるという理由だけで、これを見誤って評価されたエージェント型コンパウンダーとして引き受けるべきではありません。

結論

データドッグは成果レバレッジを伴う経路2、そして成果連動型プラミングと評価されます。統合された多信号のデータプレーンへのホスト側エージェントの収集は、モデルラボによるオブザーバビリティへの垂直統合に対する、持続的な吸収境界を作ります。AI駆動のソフトウェアの複雑性とエージェントの増殖は、観測する価値のあるものの量を拡大させます。Bits AIはそのプレーン上で検知・調査・是正を完結させる一方、MCPサーバーは外部のエージェントにとってのヘッドレスな文脈として、データドッグを有用であり続けさせます。Convequityは、テレメトリとメモリの重力を理由にA1を前稿の暫定3から4.0へ引き上げ、エージェント型インターフェースと基盤モデルの問いを検証した後、A4を4.0、B1を3.5に据え置きました。構造的なストーリーは強固です。正しいバケットは、エージェントが必要とし、量に応じて対価を支払う配管であって、企業のエージェント型インターフェースの完全な保有ではありません。

経路2の銘柄群の中で、データドッグはワークフローと機能のさらなる浸食をモデル企業やサードパーティのエージェントに対して食い止める上で、大半の銘柄より良い位置にあります。検知は依然として離れがたいものであり続けます——テレメトリはなおホスト上から始まるからです。調査と是正はMCP経由で複数のインターフェースにまたがりうるものの、依然としてデータドッグの相関の取れた多信号プレーンに依存しており、Bitsはそのワークフローの大部分を社内に留めておくためのデータドッグ自身の賭けです。これは、経験層とワークフロー層がどこか他へ移った後、薄いデータAPIしか残らないベンダーよりも、強い経路2の姿勢です。主な注視項目は逆方向に働きます——コーディングエージェントには、本番の観測・テスト・検証ループを自ら所有する本物の製品インセンティブがあり、大手ラボがデプロイ後学習と本番品質のコーディングエージェントのためにコレクターを出荷する可能性があります。この結果について、我々は確実性を主張しているわけではありません。

続くPart 6ではクラウドフレアを取り上げ、同じ成果連動型プラミングというバケットの中でも、データドッグとは異なる形——エッジのネットワークとセキュリティという足場に根ざした形——を検証します。