Elasticは検索会社から「企業AIのデータ基盤」へ進めるか
この資料の日時
元資料の日付と、その本文が公に存在した確認日時は別の記録です。
この資料を根拠にした分析カード（試験中）: 画面の実装と運用基盤の成立を分ける
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.09.23.4
- 記事内容のSHA-256
bbc859f4e04a43f66e3a99c0d0e902501149c8863813754a4701d7bfd2c02984- 保存版のSHA-256
f77455d8be36e360d8c8f163ffc7d35a36c21fa484c1facc7128ff01b71386a4
外部証明の最終検査結果は詳細を開くと表示します。
Elasticは検索会社から「企業AIのデータ基盤」へ進めるか
#FY2027 Q1決算・ガイダンス・カンファレンスコールから、Search & AI・Security・Observability、Elastic 9.5の技術まで読み解く
#Elasticという会社を「Elasticsearchを売っている検索会社」と理解すると、現在の事業構造をかなり見誤る。
#同社はいま、
#Search & AI
#Security
#Observability
#という三つの主要領域を、共通のElasticsearch Platformの上へ統合しようとしている。
#検索では企業内に散らばった非構造データをAIが使えるContextへ変換する。
#Securityでは、膨大なログやEndpoint Eventから攻撃を発見し、AIによる調査・対応まで自動化する。
#Observabilityでは、Logs・Metrics・Tracesを集約してシステムやAI Agentの動作を監視し、障害原因を自動調査する。
#そしてFY2027 Q1決算では、この戦略が単なる製品ロードマップではなく、大口顧客、RPO、cRPO、Cloud Consumption、AI利用率という数字に表れ始めた。
#Q1売上高は4億7,811万ドル、前年比15%増。Sales-led Subscription Revenueは3億9,900万ドル、18%増だった。一方、cRPOは11億5,300万ドルで21%増、RPOは18億5,400万ドルで27%増となった。10万ドル超ACV顧客は1,800社を超え、前四半期から80社以上増加し、過去最大の純増となった。(Elastic)
#注目すべきなのは単に「売上15%増」ではない。
#と、現在の売上より未来側の指標ほど高い成長率になっている。
#今回の記事では、この決算を入り口として、Elasticの三事業が実際には何をしているのか、Prometheus、PromQL、Security Event、Semantic Search、Columnar Modeとは何なのか、そして「CodexやClaude CodeのようなコーディングAgentが進歩したらElasticそのものを簡単に作り直せるのではないか」という問題まで掘り下げていく。
#1．FY2027 Q1――売上15%より重要なもの
#ElasticのFY2027 Q1は2026年7月31日までの四半期である。
#売上高は、
#前年比約15%。
#Subscription Revenueは、
#前年比15%。
#そのうちMonthly Elastic Cloudを除いたSales-led Subscription Revenueは、
#前年比18%だった。
#Non-GAAP Operating Marginは16.2%、Adjusted Free Cash Flowは1億4,300万ドルとなった。(Elastic)
#前四半期に会社が示していたQ1 Revenue Guideは4億6,900万～4億7,000万ドルだったため、実績は約800万～900万ドル上振れした。前回の通期Revenue Guideも19億8,500万～20億ドルだったが、今回19億9,800万～20億1,000万ドルへ引き上げられた。(Elastic) (Elastic)
#つまり単なるBeatではなく、
#Beat & Raise
#になっている。
#ただし、これだけなら非常に良いSoftware決算という程度である。
#今回のElasticでさらに重要なのが、
#RPO
#cRPO
#ACV
#である。
#2．RPOとは何か
#RPOは、
#Remaining Performance Obligations
#残存履行義務。
#直感的には、
#顧客とはすでに契約しているが、Elasticがまだサービスを提供しておらず、売上として認識していない契約部分
#である。
#例えば3年間300万ドルの契約を締結し、100万ドル分のサービス提供が終わっているとする。
#概念的には、
#なので、
#が残る。
#厳密な会計処理には契約条件等が関係するが、投資家の直感としては、
#すでに契約済みの将来売上ストック
#と考えるとよい。
#そしてcRPOのcは、
#Current
#である。
#一般には今後12か月以内に売上認識される予定のRPOを指す。
#したがって、
#となる。
#3．成長率だけではなく「RPOの大きさ」を見る
#ここがElasticを見るうえで非常に重要である。
#例えば売上規模が30あり、すでに29を売上計上していてRPOが1しかない企業を考える。
#RPOが20%増えても、
#である。
#増えたのは0.2しかない。
#この場合、
#RPO +20%
#という見出しほど企業全体への影響は大きくない。
#ところがElasticは違う。
#Q1 Revenueが、
#なのに対し、
#cRPOは、
#RPOは、
#ある。(Elastic)
#四半期売上を1とすると、
#である。
#つまり、
#四半期売上の約4倍に相当する巨大なRPOストックが存在していて、そのRPO自体が27%増えている。
#ここが強い。
#4．ドル金額で見るとRPO成長の意味が変わる
#現在のRPOは18億5,400万ドル、前年比27%増。
#前年同期を逆算すると、
#である。
#つまりおよそ、
#となった。
#増加額は、
#である。
#Elasticの四半期Revenueが約4億7,800万ドルなので、RPOの前年比増加額だけで直近四半期売上の約82%に相当する。
#cRPOも同様である。
#現在11億5,300万ドル、21%増なので、前年同期は概算で、
#だった。
#つまり、
#で、
#約2億ドル増えている。
#単に「+21%」「+27%」を見るのではなく、
#を見る必要がある。
#この考え方をすると、ElasticのRPO成長の印象はかなり変わる。
#5．年間売上規模とほぼ同じRPOがある
#FY2027通期Revenue Guideの中央値は約20億400万ドル。
#それに対しRPOは18億5,400万ドルなので、
#となる。
#つまり、
#現在の年間Revenue規模の約93%に相当する未認識契約残高
#を持っている。
#cRPOだけでも、
#である。
#もちろん、
#RPOが年間Revenueの93%あるから翌年売上が93%確定している
#という意味ではない。
#Revenue Recognitionの時期、契約期間、Consumptionなどがある。
#しかし、
#大きなRPOが存在し、その大きなRPOがRevenueを上回る速度で成長している
#ということ自体には大きな意味がある。
#6．ただしRPO +27%をそのままRevenue +27%とは読めない
#ここには重要な注意点もある。
#RPOは、
#顧客が増えた場合だけでなく、
#1年契約
#から、
#3年契約
#へ変わった場合にも増えやすい。
#CEO自身、今回のCallで顧客がより大きく、より長期のCommitmentを行っていることを説明している。
#したがって、
#である。
#だからこそRPOだけでなくcRPOを見る。
#cRPOも20%前後で成長しているため、
#「単に長期契約化したからRPOが増えただけ」
#という説明では不足する。
#さらにCFOは、過去に獲得したCommitmentが実際にConsumptionされ、Revenueへ変換されている動きも良好だったと説明している。
#現在のElasticでは、
#↓
#↓
#↓
#↓
#という変換が進み始めている。
#7．ACVとは何か
#ACVは、
#Annual Contract Value
#年間契約価値。
#例えば3年間300万ドルなら、単純化すれば、
#となる。
#Elasticが開示している、
#$100K ACV Customers
#とは、
#1年間の契約価値が10万ドルを超える大型顧客
#である。
#今回この顧客数が1,800社を超えた。
#前四半期は1,720社超、前年同期は1,550社超だった。(Elastic)
#しかもQ1だけで80社以上純増しており、過去最大。
#さらに、この>$100K ACV cohortだけでSales-led Subscription Revenueの90%を占める。前年は87%だった。
#したがってElasticの成長は、
#小さなWeb Search利用者が大量に増えている
#というより、
#Enterprise Customerの中へより深く入っている
#と理解した方がよい。
#8．大型顧客の37%がAIを利用
#さらに重要なのがAI penetrationである。
#$100K ACV顧客のうちElasticをAI用途で利用する割合は、
#前年約21%
#から、
#37%
#へ上昇した。
#現在670社以上で、Q1だけで70社純増した。
#CFOによれば、AI機能を利用する顧客は、AIを利用していない顧客よりもExpansion propensityが高い。
#ここは「SaaSの死」という観点でも重要である。
#もしAIがElasticを急速に代替しているなら、
#とともに、
#が起きてもよい。
#現在は逆に、
#↓
#という相関が出ている。
#まだ因果関係まで完全に証明されたわけではないが、少なくともAIがElastic需要を直ちに破壊している兆候ではない。
#9．Elasticの三つの事業
#現在のElasticを理解するには、三本柱を分けて考える必要がある。
#Search & AI
#必要な企業データを検索し、AIへ正確なContextを与える。
#Observability
#Logs・Metrics・Tracesを用いて、ApplicationやInfrastructureが正常に動作しているか調べる。
#Security
#Endpoint、Identity、Cloud、Networkなどから生まれるEventを相関し、攻撃を検出・調査・対応する。
#しかし、この三つは完全に独立した製品ではない。
#下にあるElasticsearchというData Platformを共有している。
#これがElasticのPlatform戦略の中心である。
#10．Search & AI――散らばった企業データを「検索できる状態」にする
#企業には大量のデータがある。
#PDF。
#Word。
#社内Wiki。
#問い合わせTicket。
#GitHub Issue。
#商品Catalog。
#Slackの会話。
#ログ。
#画像。
#音声。
#動画。
#これらを、
#一瞬で完璧に整った一つのSQL Databaseへ変換する
#ことはできない。
#同じ顧客が、
#「山田太郎」
#「Taro Yamada」
#「customer_83291」
#として別々に記録されていることもある。
#どの文書が最新版なのか、正式版なのか、誰が閲覧できるのかも異なる。
#Elasticがやっているのは、
#世界中の散らばったデータを完璧に一つのSchemaへ正規化すること
#ではない。
#むしろ、
#検索に必要な形へ取り込み、索引を作り、高速にRetrievalできる状態にすること
#である。
#CEOも今回、Elasticの差別化として「messy data」「unstructured data」への長年の最適化を強調している。ElasticはもともとDocument StoreとInverted Indexから始まり、Schemaが変化する非構造データを扱ってきたという説明である。
#11．Connectorとは何か
#企業データをElasticへ入れる最初の入口がConnectorである。
#Connectorは、
#別のData SourceとElasticsearchの間をつなぐ取り込み部品
#である。
#Google DriveならGoogle Drive APIへ接続し、
#ファイル一覧、
#本文、
#タイトル、
#更新日時、
#所有者、
#Access Permission
#などを取得する。
#そしてElasticへ投入する。
#最初にFull Syncした後、変更分だけIncremental Syncすることもできる。
#したがって概念的には、
#↓
#↓
#↓
#↓
#となる。
#重要なのは、元のGoogle DriveやSharePointがSystem of Recordとして残ることだ。
#Elasticはそのコピーを、
#検索用Replica
#として保持する場合が多い。
#12．全文検索――Inverted Index
#Elasticsearchの原点が全文検索である。
#例えば1億件の文書がある。
#ユーザーが、
#「semiconductor package failure」
#と検索したとき、毎回1億文書をすべて読むのは遅すぎる。
#そこで事前に、
#という索引を作る。
#例えば、
#semiconductor → 文書4、文書51、文書900
#failure → 文書51、文書93、文書900
#という対応表を持っておく。
#これが、
#Inverted Index――転置インデックス
#である。
#だから全文検索では、すべてのDocumentを最初から読む必要がない。
#この「事前計算された検索構造」がElasticsearchの基本である。
#13．Semantic Searchとは何か
#従来のKeyword Searchでは、
#「car」
#と、
#「automobile」
#は別の単語である。
#人間には同じような意味だと分かるが、単純な文字一致では分からない。
#そこでEmbedding Modelを使う。
#文章を、
#へ変換する。
#意味が近い文章はVector空間でも近くなる。
#これがSemantic Searchの基本である。
#したがって、
#「GPUが熱で性能低下した事例」
#と検索しても、
#文書側に、
#thermal throttling
#としか書いていなくても見つけられる可能性が高くなる。
#14．しかしVector Searchだけでは足りない
#企業検索では固有名詞が非常に多い。
#Part Number。
#Chip Model。
#Customer ID。
#契約番号。
#特定エラーコード。
#こうしたものはKeyword Searchの方が強い。
#一方、
#「意味の近さ」
#はSemantic Searchが強い。
#そこで、
#を使う。
#さらに最初に取得した20～100件を、
#Reranker
#で再評価し、LLMへ本当に必要な数件だけ渡す。
#すると、
#を狙える。
#CEOはカンファレンスコールで、企業がpetabyteからexabyte規模の情報を抱える場合、毎回全データをモデルへ渡すことは高コストかつ低速であり、Contextを事前計算して必要な情報だけを取得するRetrieval Layerが必要になると説明している。
#15．AI時代のElasticは「Context Layer」を狙う
#LLMは非常に賢くなっても、企業の最新内部情報を知らなければ正確な業務はできない。
#例えば、
#「この顧客が購入可能な半導体部品を教えて」
#という問いに対して、
#製品Catalog、
#在庫、
#顧客契約、
#輸出規制、
#過去の購入履歴
#などを取得する必要がある。
#しかもユーザーAが読めるDocumentと、ユーザーBが読めるDocumentは違う。
#そこで、
#↓
#↓
#↓
#↓
#というContext Layerが必要になる。
#今回実際にGlobal 2000の半導体企業が7桁ドル規模でElastic Serverlessを採用し、大規模Product CatalogをAI Context Layerとして利用する案件が出た。Document-level Securityによって顧客ごとに参照可能な情報を制御する設計である。
#16．Security――Metricsとは違う「Event」の世界
#Securityでは、Observabilityと少し違うデータが中心になる。
#Prometheus Metricなら、
#のように、
#ログイン失敗が異常に増えた
#ことを知る。
#しかしSecurity Eventは、
#誰が、いつ、どこから、何をしたか
#を記録する。
#例えば一つのLogin Eventには、
#timestamp、
#user、
#source IP、
#destination host、
#authentication method、
#result
#などが入る。
#Process Eventなら、
#process name、
#parent process、
#command line、
#hash、
#user、
#destination IP
#などまで持つ。
#つまり、
#であり、
#である。
#PrometheusのLabelsにもhostやregionなどの情報は付くが、Security Eventの方が一般に遥かにRichなContextを持つ。
#17．SIEMとは何か
#Elastic Securityの中核の一つがSIEMである。
#Security Information and Event Management
#企業中の、
#Windows Event、
#Linux Log、
#Firewall、
#Cloud Audit Log、
#Identity Event、
#Endpoint Event、
#Network Event
#などを集める。
#そして、
#同じUserが別地域から不自然にLoginした
#その直後PowerShellが起動した
#Credential Storeへアクセスした
#外部IPへ大量転送した
#という複数のEventを関連付ける。
#一つ一つなら正常に見えるEventでも、
#とつなぐとAttack Storyになる。
#この大量Eventの検索と相関は、Elasticsearchの得意分野と非常に相性が良い。
#18．XDRとEndpoint Protection
#SIEMが企業中のSecurity Eventを集めるのに対し、XDRは、
#Endpoint、
#Identity、
#Network、
#Cloud
#など複数のDetection and Responseを横断する。
#例えば、
#Login anomaly
#↓
#Malware process
#↓
#Credential access
#↓
#Cloud resource access
#↓
#External upload
#を一つのAttackとして追う。
#ElasticはEndpoint Protectionも持っているため、
#検知する
#だけでなく、
#Host Isolationなどの対応
#へ進むことができる。
#今回経営陣はSecurityを現在の主要事業の中でも特に強いGrowth Vectorとして説明した。Solution別の売上高は開示していないが、Q&Aでは概ねSecurity、Search & AI、Observabilityの順で強いという趣旨の説明がなされた。
#19．Attack DiscoveryとAlert Zero
#Elastic 9.5ではSecurity AIがさらに進んだ。
#従来のSOCでは大量のAlertが出る。
#そのほとんどを人間が順番に調査すると、重要なAttackへたどり着く前に時間を消費する。
#Elasticが掲げるAlert Zeroは、
#すべてのAlertをゼロにする
#という意味ではない。
#AI AgentとAnalystが、
#大量Alert
#↓
#False Positive分類
#↓
#関連AlertのCorrelation
#↓
#Attack Chain化
#↓
#本当に重要なAttack
#へ絞り込む考え方である。
#Attack Discoveryは単にAlertを要約するだけでなく、Raw EventやEntity Riskなどを追加検索し、Attack Narrativeを検証する方向へ拡張された。(Elastic)
#つまり、
#までAgentが入ってくる。
#今回CEOは、これらAI SOC capabilitiesがすでにStrong Commitmentにつながり、そのCommitmentに対するConsumptionも始まっていると説明した。
#Security AIはすでに「将来の研究」だけではなくCommercial tractionへ移り始めている。
#20．Observability――Logs・Metrics・Traces
#Observabilityとは、
#複雑なITシステム内部で何が起きているのかを外部から推測・調査できる状態を作ること
#である。
#中心となるのが、
#Logs、
#Metrics、
#Traces。
#Logsは、
#具体的に何が起きたか
#を文章やEventとして残す。
#Metricsは、
#CPU 85%
#Memory 72GB
#Requests/sec 12,000
#p99 Latency 900ms
#のような数値時系列。
#Tracesは、
#User Request
#↓
#Frontend
#↓
#API
#↓
#Search Service
#↓
#Database
#という1回の処理経路を追う。
#概念的には、
#という役割分担になる。
#21．Prometheusとは何か
#PrometheusはCloud Native環境で広く使われているOpen Source Metrics Monitoring Systemである。
#ApplicationやExporterが、
#/metrics
#というHTTP Endpointを公開する。
#Prometheusがそこへ定期的にアクセスしてMetricを取得する。
#この取得を、
#Scrape
#という。
#例えば、
#CPU Usage、
#Memory、
#Request Count、
#Error Count
#などを15秒ごとに取る。
#データは、
#で表現される。
#Labelsには、
#host、
#service、
#region、
#pod、
#environment
#などが付く。
#22．PromQLとは何か
#PromQLは、
#Prometheus Query Language
#である。
#例えばCounterとして累積Request数が保存されている場合、
#過去5分の1秒あたりRequest数
#を求める。
#Serviceごとにsumする。
#Error Rateを計算する。
#p95やp99を計算する。
#といった時系列処理に使う。
#企業には何年も使われてきたPromQL Query、Grafana Dashboard、Alert Ruleが大量に蓄積している。
#だから、
#「Elasticへ移るので全部書き直してください」
#ではMigration Costが高すぎる。
#Elastic 9.5ではPrometheus remote-write endpointとNative PromQL SupportがGAとなり、既存Prometheus/Grafana workflowを大きく変更せずElasticへ移す戦略が強化された。ElasticはGrafanaやDatadogのDashboard・Alert移行ツールも提供している。(Elastic)
#23．なぜKubernetesとPrometheusは相性が良いのか
#KubernetesではPodという実行単位が頻繁に生まれ、消える。
#Podは永続Serverではない。
#負荷が増えれば、
#5 Pods
#から、
#30 Pods
#へ増える。
#負荷が減れば戻る。
#Deployment更新時には古いPodが消え、新しいPodへ置き換わる。
#したがって固定IP Server一覧を人間が管理する従来Monitoringでは追いつきにくい。
#PrometheusはKubernetes Service Discoveryを利用して、
#新しいPodを発見
#↓
#/metricsをScrape
#↓
#Podが消えれば対象から外す
#という処理ができる。
#AI AgentやAI ApplicationがKubernetes上へ大量展開されると、これらのMetrics・Logs・Tracesも急増する。
#Elasticは今回、KubernetesのAgentic Investigationも拡張しており、Metrics、Logs、Cluster EventなどをAgentが横断してRoot Causeを探す方向へ進んでいる。(Elastic)
#24．Metricsの最大の問題――量が多すぎる
#Metricは1件あたりの情報量は小さい。
#しかし、
#100万Series
#×
#10秒ごと
#×
#24時間
#となると膨大になる。
#さらにLabelsの組み合わせが増えると、
#High Cardinality
#問題も起きる。
#User IDやRequest IDのように種類がほぼ無限に増えるLabelを付けると、保存・検索コストが急増する。
#Observability企業にとって、
#どれだけ多くのTelemetryを安く保存できるか
#は極めて重要である。
#25．Elastic 9.5のColumnar Mode
#ここでElastic 9.5の重要機能、
#Columnar Mode
#が出てくる。
#従来Elasticsearchは検索性能を高めるためにInverted Indexなど複数の検索構造を持つ。
#これは全文検索には非常に強いが、Metricのように、
#CPU、
#Memory、
#Latency
#という同種数値を何兆件も集計するWorkloadでは、必ずしも全Fieldに強力な全文検索Indexは必要ない。
#Columnar Modeでは、原則としてFieldをColumn Storeへ一度だけ保存し、デフォルトではInverted Indexを作らない。
#Elastic 9.5ではTechnical Previewとして導入された。(Elastic)
#26．なぜColumnarはMetricsに向くのか
#例えば、
#CPU列
#70, 71, 72, 70, 69……
#Memory列
#62, 63, 62, 64……
#のように同じ種類の値をまとめる。
#似たデータが連続するので圧縮しやすい。
#また、
#過去24時間の平均CPUを計算
#するときにはCPU列とTimestampだけ読めばよい。
#他の何十Fieldも読む必要がない。
#そのため、
#を狙える。
#Columnar Logsではさらに折衷案を採用する。
#ログ本文のmessageだけにはInverted Indexを残し、
#全文検索性能
#を維持。
#その他FieldはColumnarで保存する。
#つまり、
#を両立しようとしている。(Elastic)
#27．「3 bytes per metric」の意味
#今回のCallではElasticがMetrics Storageを約3 bytes/sampleまで改善したことを強調している。
#ただし技術的には、
#Columnar Modeそのものだけで3 bytesになった
#と理解するより、
#ElasticのColumnar Metrics Architectureと9.5のES95 codecなど一連の改善で約3 bytes/sampleまで押し下げた
#と考える方が正確である。
#Elastic公式の9.5説明では、新Codecによって従来からさらに約20%下げ、概ね3 bytes/sampleと説明している。(Elastic)
#これはElastic自身のBenchmarkなので、競合比較は第三者検証と分けて考える必要がある。
#それでも自社世代間での改善幅は大きい。
#28．Columnar ModeはElasticの利益率にも関係する
#Elastic CloudはElastic自身の巨大DCで動いているわけではない。
#AWS、Azure、Google CloudなどのCloud Provider上で提供されている。(Elastic)
#したがってElastic Cloudが大量データを保存すれば、
#Compute、
#Storage、
#Network
#のInfrastructure Costが発生する。
#同じ顧客のTelemetryを半分のStorageで保持できれば、
#となる。
#Elasticがコスト低下分をPriceに反映せず維持すれば、
#余地がある。
#逆に顧客へ還元すれば、
#↓
#↓
#というMarket Share戦略にも使える。
#今回CFOはSubscription Gross Marginが80%以上を維持しており、ServerlessがScaleすることで長期的なGross Margin改善を期待していると説明した。
#29．Elastic 9.5――Search & AIの詳細
#Elastic 9.5は2026年8月4日にGAされた。
#Q1の期末は7月31日なので、9.5そのものの本格的なRevenue寄与は今回Q1にはほぼ入っていないと考えるべきである。(Elastic)
#Search & AI側では大きく、
#Columnar Mode、
#VectorDB index mode、
#Auto Calibration、
#Multimodal Semantic Search、
#Agent Builder強化
#が入った。
#VectorDB index modeはVector Workload向けのQuantization、Merge Policy、Cache loadingなどを自動設定し、専門家が大量のIndex TuningをしなくてもVector Searchを開始しやすくする。
#DiskBBQのAuto Calibrationでは、Vectorの統計的特徴に応じてQuantization depthやOversamplingなどを自動調整する。(Elastic)
#30．Multimodal Semantic Search
#AIが扱う企業データはTextだけではない。
#画像。
#PDF。
#音声。
#動画。
#Elastic 9.5ではSemantic Fieldを拡張し、Multimodal Searchの導入を簡略化する方向へ進んでいる。(Elastic)
#これは企業AIのContext Layerという観点では重要である。
#将来Agentが、
#この設計図に似た過去の故障写真を探す
#この会議録と関連する音声部分を探す
#といった検索をする場合、Textだけでは足りない。
#31．Agent Builderも「作る」から「運用する」へ
#AI Agentは作るだけなら簡単になっていく。
#企業で難しいのは、
#何を実行したか
#どのToolを呼んだか
#どのLLMを使ったか
#誰が承認したか
#を追跡することだ。
#Elastic 9.5ではAgent Observability and MonitoringがTechnical Previewとして入り、LLM CallやTool CallをOpenTelemetry TraceとしてElasticsearchに保存できる。
#さらにHuman-in-the-loop Approvalにより、Sensitive Actionを人間が承認し、その判断をAudit Trailへ残せる。(Elastic)
#AIが実際の企業業務を実行し始めるほど、
#より、
#が重要になる。
#32．Elastic 9.5――Observabilityの詳細
#Observability側の大きな要素は、
#Native Prometheus ingestion、
#PromQL、
#Columnar Metrics、
#Kubernetes Agentic Investigation、
#APM改善、
#LLM Observability
#である。
#Prometheus remote-writeとPromQLをNativeに受けることで、
#Prometheusを捨ててElastic専用形式に変えてください
#ではなく、
#Prometheus ecosystemを維持したままStorageとAnalysisをElasticへ持ってくる
#戦略が取れる。
#さらにGrafana/DatadogのDashboardやAlert migration automationも進めている。(Elastic)
#実際、今回のConference Callでは大手保険会社が既存Elastic Security環境へObservabilityを追加し、7桁ドル規模のExpansionとなった事例が紹介された。
#もともとLogsはElastic、MetricsとTracesは別Vendorだった。
#Native Prometheus ingestionとPromQL対応が移行の重要要因となった。
#33．Elastic 9.5――Securityの詳細
#Security 9.5では、
#Attack Discovery、
#Alert Zero、
#Endpoint Protection、
#Workflows、
#Agentic Investigation
#が中心になる。
#Attack Discoveryは複数Alertを単にGroupingするだけではなく、その背後のRaw Eventを追加検索し、Entity Contextを調べ、実際のAttackかを検証する。(Elastic)
#WorkflowsはDeterministic AutomationとAgentic Reasoningを組み合わせる。
#例えば、
#Attack発見
#↓
#関連Host確認
#↓
#Case作成
#↓
#Analystへ通知
#↓
#人間承認
#↓
#Host isolate
#といった処理につなげられる。
#Elasticの方向性は、
#である。
#34．なぜこれらの基盤は簡単に代替できないのか
#ここで最も重要な疑問が出てくる。
#CodexやClaude CodeのようなCoding Agentがこれだけ強くなったなら、
#「同じものを自社で作ればよいのではないか」
#という疑問である。
#これは半分正しい。
#そして半分間違っている。
#35．CodexでSearch Appを作ることはかなり簡単になった
#例えば、
#PDFを読む。
#Chunk化する。
#Embeddingを作る。
#Vector DBに保存する。
#Search APIを書く。
#RAGする。
#Web UIを作る。
#Google Drive Connectorを書く。
#こうしたApplication LayerはCoding Agentによって急速に安くなっている。
#OpenAI自身も、Codexを使って人間がコードを直接書かずに大規模な内部Software Productを構築した実験を公開している。重要なのは、そこで人間の役割が消えたのではなく、Architecture、Environment、Test、Guardrail、Feedback Loopの設計へ移ったことだ。(OpenAI)
#Codexは現在、機能実装、Refactoring、Migration、Test、Bug Fixなどをエンドツーエンドで扱える。(OpenAI)
#Claude Codeについても、Anthropicの調査では、人間が主に「何をするか」を決め、Agentが「どう実行するか」を担う傾向が確認されている。Domain Expertiseが高いほど成功率も高くなる。(Anthropic)
#つまり、
#Search Applicationを作るコスト
#は確実に下がっている。
#これはElasticにとってコモディティ化圧力になる。
#36．しかし「Elasticsearchそのもの」は別問題
#検索画面を作ることと、
#Production Grade Distributed Search Engineを作ることは違う。
#Elastic級の基盤では、
#Inverted Index、
#Vector ANN Index、
#Quantization、
#Shard、
#Replication、
#Distributed Query、
#Cluster Rebalancing、
#Failure Recovery、
#Snapshot、
#Rolling Upgrade、
#Access Control、
#Encryption、
#Query Planner、
#Compression、
#Backpressure、
#Cache、
#Hot/Warm/Cold Tier、
#Multi-cloud、
#On-prem、
#Air-gap
#まで扱う。
#さらに、
#1億Documentなら動く
#だけでは足りない。
#数十億・数百億Document。
#PB級Data。
#Node障害。
#Network Partition。
#Version Upgrade。
#Schema Evolution。
#Security Incident。
#これらが起きても止まらないことが必要である。
#AIがコードを一瞬で書けても、
#5年間Productionで何百回壊れて改善されたDistributed Systemの経験
#まで一瞬で再現できるわけではない。
#37．Securityはさらに難しい
#SecurityではEngineを書くだけで終わらない。
#Endpointから正確なEventを取る。
#OS Version差を吸収する。
#Attack Techniqueを理解する。
#False Positiveを減らす。
#Detection Ruleを保守する。
#Threat Intelligenceを更新する。
#Incidentを相関する。
#Auditを残す。
#Endpointを安全にIsolationする。
#さらにSOCで誤動作を起こせば、
#本物の攻撃を見逃す
#か、
#正常な業務を停止する
#危険がある。
#ここでは、
#だけではなく、
#が極めて重要になる。
#38．Observabilityも「Dashboardを作る」のと「基盤を作る」のは違う
#Grafana風DashboardをCodexで作ること自体は難しくない。
#しかし、
#毎秒数千万MetricをIngest。
#High Cardinalityを処理。
#30日、90日、1年Retention。
#p99 Queryを高速処理。
#Kubernetes Podを自動発見。
#LogsとTraceを同じ時間軸で結合。
#複数Region障害に耐える。
#という基盤を安定運用することは別の問題である。
#ElasticがColumnar Modeへ投資している理由もここにある。
#表面的なDashboardではなく、
#という物理的に近い部分で競争している。
#39．ただしAIはElasticの堀を永久保証しない
#重要なのは、
#「難しいからElasticは絶対安全」
#とはならないことである。
#Coding Agentが進歩すると、
#Migration Codeを書く。
#Detection Ruleを変換する。
#Grafana Dashboardを移す。
#PromQLを変換する。
#OpenSearchへ移す。
#独自Connectorを書く。
#といったSwitching Costは確実に下がる。
#実際、Elastic自身がその力を攻撃側に使っている。
#今回大規模政府機関の複雑なSIEM基盤を、Automated Migration Toolを使って1か月未満でElasticへ移行した事例が紹介された。
#これは非常に象徴的である。
#AIとAutomationは、
#Elasticから出ていくMigration
#も、
#Elasticへ入ってくるMigration
#も簡単にする。
#40．だからElasticの本当の競争は「ロックイン」ではなくなる
#以前のEnterprise Softwareでは、
#が非常に大きな堀だった。
#しかしAIでMigration Costが下がるなら、
#ただ移行が面倒だから残る
#という堀は弱くなる。
#そこで必要になるのが、
#である。
#保存単価が安い。
#Prometheusから入りやすい。
#Search、Security、Observabilityが一つにつながる。
#結果としてDataが集まる。
#Dataが集まるほどさらに別Workloadを動かす価値が増える。
#このPositive Loopを作れるかが重要になる。
#41．Land and Expandがその経済モデル
#ElasticはConference Callで、三事業のLand and Expand戦略を明確に説明している。
#例えば最初に、
#Security
#で入る。
#その後、
#Observability
#へ拡張する。
#さらに、
#Search & AI
#を使う。
#あるいはその逆でもよい。
#CEOによれば三Solutionすべてを使う顧客が最も速く成長する。CFOもRevenueの多くはLandよりExpandから生まれると説明した。
#つまりElasticの理想モデルは、
#↓
#↓
#↓
#↓
#↓
#↓
#↓
#である。
#今回>$100K ACV顧客が過去最大純増となったことは、この戦略が少なくとも現在かなり機能していることを示す。
#42．Securityはすでに強い、Search & AIも商用化、Observabilityはこれから
#今回の決算から三事業の現在地を整理すると、かなり分かりやすい。
#Security
#最もCommercial tractionが強い。
#AI SOC、SIEM、XDRがCommitmentだけでなくConsumptionへ来ている。
#Search & AI
#AI Context Layerとして大型案件が出始めている。
#$100K顧客のAI Penetration 37%も強い。
#Observability
#Logsは元々強いが、Metricsは歴史的に弱かった。
#Columnar、Prometheus、PromQL、Kubernetes、Deductive AIによってその穴を埋めようとしている。
#CEO自身、MetricsについてまだEarlyとしながら、今後1年から複数年でMeaningful Growth Areaになる可能性を示した。
#つまりObservability Metricsは、
#今回の売上を作ったDriver
#というより、
#これからのOption Value
#として見る方が正しい。
#43．ガイダンス――会社は何を見てRaiseしたのか
#Q2 Revenue Guideは、
#4億8,600万～4億8,700万ドル。
#前年比14.9%程度。
#Sales-led Subscriptionは、
#4億750万～4億850万ドル。
#前年比16.9%。
#Non-GAAP Operating Marginは約19%。
#FY2027通期Revenueは、
#19億9,800万～20億1,000万ドル。
#Sales-led Subscriptionは、
#16億8,200万～16億9,400万ドル。
#Non-GAAP Operating Marginは19.4%。
#Adjusted FCF Marginは21.5%。(Elastic)
#Revenue Guideはまだ15%程度なので、
#「もう20%成長へ戻った」
#わけではない。
#44．しかしGuidance Raiseの理由が良い
#Barclaysから、
#Q1だけなのになぜFull-year GuideをBeat以上にRaiseできたのか
#という質問が出た。
#CFOは三つを挙げた。
#Pipeline build。
#cRPO Commitmentsに対するConsumption。
#Sales capacityとProductivity改善。
#つまり、
#↓
#↓
#↓
#という複数段階でデータが良かった。
#単に、
#AIテーマが盛り上がっているから
#Guidanceを上げたわけではない。
#45．一方でNER 111%はまだ確認が必要
#NER――Net Expansion Rateは、既存顧客群が契約をどれだけ拡大・縮小したかを見る指標である。
#今回NERは、
#112%
#から、
#111%
#へ低下した。
#会社はTrailing Four-quarter Metricであり、過去の低成長四半期がまだ含まれていることが原因で、FY27の成長加速が進めば4四半期以内に改善すると予想している。
#理屈は通る。
#しかしここは今後数字で確認する必要がある。
#もし、
#cRPO +20%
#大口顧客急増
#AI利用率上昇
#なのに、
#NERが110%付近から上がらないなら、
#既存顧客Expansionの強さについて再検討する必要がある。
#46．今回の決算から見える投資上の核心
#Elasticの現在地を最も単純に表すと、
#である。
#まだ超高成長企業ではない。
#しかしその一段前では、
#さらに、
#さらに、
#となっている。
#$100K ACV顧客は過去最大純増。
#AI penetrationは21%から37%。
#SecurityはStrong Growth Vector。
#Search & AIでも7桁ドル級Context案件。
#ObservabilityにはColumnar + Prometheus + Agentic SREという新しい攻め手が入った。
#したがって今のElasticは、
#20%成長が実現した会社
#ではない。
#むしろ、
#20%近辺への再加速を示す先行指標が揃い始めた会社
#である。
#47．Elastic 9.5は今回の決算の原因ではなく「次の検証対象」
#ここも時間軸を間違えてはいけない。
#FY27 Q1期末は7月31日。
#Elastic 9.5 GAは8月4日。
#OpenAIとの拡大協業発表は7月30日だった。ElasticとOpenAIは、OpenAIのReasoning ModelとElasticsearchの企業Context、Governanceを組み合わせ、AI Application、Security、Observabilityへ展開する協業を発表している。(Elastic)
#したがって今回のQ1の強さを、
#9.5が売れたから
#OpenAI案件が売上になったから
#と解釈するのは適切ではない。
#今回確認できたのは、
#それらが本格寄与する前からElasticの基礎事業が改善していた
#ということだ。
#むしろ9.5はこれから検証される。
#48．今後何を見れば仮説が証明されるのか
#今後の最重要ポイントは、cRPO +20%前後が本当にRevenueへ変換されるかである。
#理想的には、
#↓
#↓
#↓
#となる。
#同時に、>$100K ACV顧客の増加、AI利用率37%からの上昇、Security Consumption、Prometheus移行案件、Observability大型Expansion、ServerlessとColumnarによるEconomics改善まで確認できれば、Elasticの評価軸そのものが変わり得る。
#結論――Elasticを代替するのは「コードを書くこと」ではない
#AI Coding Agentの進歩によって、
#検索UI、
#RAG Application、
#Dashboard、
#Connector、
#Migration Script、
#PromQL変換、
#Detection Rule変換
#などを作るコストは確実に下がっている。
#この部分ではElasticにもSaaSコモディティ化圧力がかかる。
#しかし企業AIで本当に難しいのは、
#UIを作ること
#ではない。
#何PBもの散らばったDataを取り込む。
#Indexを維持する。
#Permissionを守る。
#リアルタイム更新する。
#何兆件のMetricを保存する。
#High Cardinalityを処理する。
#Security Eventを相関する。
#Nodeが落ちても動き続ける。
#AgentのTool Callを監査する。
#On-prem、Cloud、Air-gapで同じ基盤を動かす。
#この部分である。
#つまり、
#であり、
#であり、
#である。
#CodexやClaude CodeはApplication Layerを急速にコモディティ化する。
#しかし同時に、それらAgentが作るApplication、Tool Call、Telemetry、企業Data検索が増えるほど、下にあるData Infrastructureへの需要は増える可能性がある。
#Elasticが賭けているのはそこだ。
#検索画面を守るのではない。
#を一つのElasticsearch Platformへ集め、
#の基盤になることを狙っている。
#今回のFY2027 Q1で確認できたのは、その戦略が完全に成功したことではない。
#しかし、
#大きなRPOがさらに27%伸びている。
#cRPOも21%伸びている。
#大型顧客純増が過去最高。
#大型顧客のAI利用率が21%から37%へ上昇。
#SecurityではAI機能がCommitmentからConsumptionへ進んでいる。
#Search & AIでは7桁ドル級のContext Layer案件が出ている。
#というところまで来た。
#次の論点は、
#「ElasticはAI時代に必要か」
#から、
#「AI時代に必要になるData・Context・Telemetry・Security需要を、ElasticがRevenue 20%級の成長へ変換できるほど大きく取り込めるか」
#へ移り始めている。
#Elastic 9.5のColumnar Mode、VectorDB、Prometheus/PromQL、Agent Builder、Alert Zeroは、その問いに対する会社側の技術的な回答である。
#そして今後数四半期は、その回答が技術Blogではなく、ACV、cRPO、RPO、NER、Consumption、Revenueとして表れるかを見る期間になる。
#ElasticをHKMGA仮説で見る――ElasticはAIの「次のFunction」を何によって拡張するのか
#ここまでElasticを、Search & AI、Security、Observabilityという三つの事業から見てきた。
#しかし、これをさらに一段抽象化してHKMGA仮説から見ると、Elasticの位置づけは少し違って見えてくる。
#HKMGA仮説では、知能を単なる推論性能としてではなく、
#すなわち、世界の不確実性、内部モデルとの差、Memory、Goal、Actionからなる適応系として考える。そして重要なのは、これらが新しいFunctionを生み、そのFunctionが次のHKMGAをさらに拡張するという再帰構造である。
#簡略化すれば、
#である。
#この観点に立つと、ElasticはAIのReasoningそのものを作る企業ではない。
#GPUのように計算能力を直接増やすわけでも、Foundation Modelそのものを学習するわけでもない。
#Elasticが拡張しようとしているのは、むしろAIの外側にある、
#Searchable Memory、Context、Observation、Verification、Feedback、Safe Action
#である。
#これは、AIがChatbotからPersistent Agent、Multi-Agent、Autonomous Systemへ進むほど重要になるFunction群でもある。
#ElasticはAIのMemoryを「増やす」のではなく、「使えるMemory」に変える
#現在のLLMは非常に多くの知識をParameter内部に保持している。
#しかし企業で実際にAIを使おうとすると、そこには大きな制約がある。
#最新の契約書。
#社内Wiki。
#GitHub。
#Jira。
#Security Event。
#Logs。
#Metrics。
#Traces。
#商品Catalog。
#顧客情報。
#これらはModel Weightの中にはない。
#しかも企業Dataは、常に更新され続ける。
#したがってAIにとって必要なのは、単純なMemory容量ではない。
#必要なのは、
#である。
#100PBのDataを保存できても、その中から今必要な10KBを正確に取り出せなければ、実用的なMemoryとは言いにくい。
#Elastic Search & AIが提供しているのは、この、
#への変換Functionである。
#ConnectorによってDataを取得し、Indexを作り、Keyword Search、Semantic Search、Hybrid Search、Permission Filter、Rerankingによって必要なContextだけを取り出す。
#つまりElasticは、
#だけではなく、
#を作る。
#HKMGA仮説では、現在のAIが「非常に賢いが忘れる」というBottleneckに対し、Persistent Memoryを次のFunction候補として置いている。
#この意味ではElasticは、Persistent Memoryそのものというより、
#Persistent Memoryを検索可能・権限制御可能・リアルタイム利用可能にするInfrastructure
#に近い。
#Search & AIは「Context Construction Function」を作る
#ここからもう一段進める。
#LLMにはContext Windowがある。
#しかし企業に存在する全Dataを毎回Context Windowへ投入することはできない。
#そこで必要になるのが、
#というFunctionである。
#例えばAI Agentが、
#「この顧客が購入可能な製品と、その理由を調べて」
#と命令されたとする。
#必要なのは単に検索結果を100件返すことではない。
#顧客情報。
#契約条件。
#Product Catalog。
#在庫。
#輸出規制。
#過去の購入履歴。
#現在のPermission。
#などを検索し、その中から質問に必要な情報だけを選ばなければならない。
#そこで、
#が働く。
#この処理は、HKMGAで考えると、
#を支援するFunctionである。
#AIの内部Modelを、
#世界側を、
#とすれば、AIが最新の企業Dataへアクセスできないほど、
#は大きくなりやすい。
#ElasticはModel自体を再Trainingするのではなく、必要なContextを外部から供給することで、その瞬間の実用的なModel Errorを小さくする。
#つまりElastic Search & AIは、
#AIの知識量を増やすFunctionというより、世界と内部ModelのズレをRetrievalによって補正するFunction
#として見ることができる。
#Semantic SearchはAIのObservation Spaceを拡張する
#Keyword Searchしか使えない場合、
#「car」
#と、
#「automobile」
#は異なる文字列である。
#Semantic SearchではEmbeddingによって意味的な近さを見ることができる。
#すると、
#「GPUが熱で遅くなる」
#という質問から、
#「thermal throttling」
#という表現を含むDocumentを発見できる。
#つまり、
#から、
#へObservation可能な範囲が広がる。
#Elastic 9.5ではTextだけでなくVectorやMultimodal Dataも扱う方向がさらに強くなっている。
#するとAIが観測できる世界は、
#Text
#から、
#Image、
#Audio、
#Video、
#Telemetry
#へ広がっていく。
#HKMGA的には、
#である。
#これは単なる検索機能追加ではない。
#AIが「何を世界として観測可能か」という入力空間そのものを広げるFunctionと考えられる。
#ObservabilityはAIに「自己観測Function」を与える
#ここがElasticをHKMGAで見るうえで特に重要である。
#Chatbotであれば、
#User Question
#↓
#Answer
#で終わる。
#しかしAgentになると、
#LLM
#↓
#Search
#↓
#API
#↓
#Database
#↓
#Tool
#↓
#別Agent
#↓
#External System
#という長いAction Chainを持つ。
#すると新しい問題が生まれる。
#「どこで失敗したのか。」
#「どのToolが遅かったのか。」
#「どのAPIがErrorを返したのか。」
#「どのAgentが不正なActionをしたのか。」
#つまりAIのAction能力、
#が拡張されるほど、
#そのActionを観測するFunctionも必要になる。
#ここでObservabilityが出てくる。
#Logs。
#Metrics。
#Traces。
#Prometheus。
#OpenTelemetry。
#Agent Tool Calls。
#LLM Calls。
#Kubernetes Event。
#これらによって、
#のFeedback Loopを作る。
#HKMGA仮説では、適応系を、
#というLoopとして見ることができる。
#Observabilityは、このLoopを閉じるための重要なInfrastructureになる。
#AIが行動した結果をAI自身や別のAgentが観測できなければ、Error Correctionは難しい。
#したがってElastic Observabilityは、
#AIが外界を見るFunctionだけでなく、自分自身のAction結果を見るFunction
#を拡張しているとも考えられる。
#PrometheusはAIに大量の「Sensor」を与える
#Prometheusによって取得されるMetricsも、この文脈では単なるMonitoring Dataではない。
#CPU。
#Memory。
#GPU Utilization。
#Latency。
#Request Rate。
#Error Rate。
#Pod Count。
#Queue Depth。
#これらはAI Agentから見ると、
#Sensor Data
#である。
#例えばSRE Agentが、
#CPU使用率上昇
#↓
#p99 Latency上昇
#↓
#Pod Restart増加
#↓
#Database Connection不足
#という状態を読み取る。
#これは、
#というObservation Channelである。
#つまりPrometheus対応は、
#とも表現できる。
#AI Agentが操作できる世界が増えるほど、観測しなければならないSignalも増える。
#このため、
#という関係が生まれる。
#Security Eventは「高解像度Observation」を与える
#Metricsでは、
#「Login失敗が800件/秒になった」
#ことは分かる。
#しかし、それだけでは、
#誰が、
#どこから、
#どのAccountへ、
#どのMethodで、
#何回試したのか、
#その後成功したLoginがあったのか、
#までは分からない。
#Security Eventでは、
#Timestamp、
#User、
#Source IP、
#Process、
#Parent Process、
#Command Line、
#Destination、
#File Hash
#などの詳細情報を持つことができる。
#つまり、
#に対して、
#に近い。
#AI Security Agentから見ると、
#低解像度の異常Signalだけでなく、
#何が起きたのかを再構成するための高解像度Observation
#が得られることになる。
#これも、
#へ効く。
#曖昧な異常を、具体的なAttack Storyへ変換できるからである。
#SecurityはAIのVerification Functionを拡張する
#HKMGA仮説では、AIの次の重要Function候補としてVerificationを挙げている。
#この観点から見るとElastic Securityはかなり興味深い。
#AIが、
#「これはAttackです」
#と一度推論するだけでは不十分である。
#本当にAttackなのか。
#False Positiveではないか。
#関連Eventは存在するか。
#そのUserの過去行動は正常か。
#同じHostに不審なProcessはあるか。
#こうしたEvidenceを再検索しなければならない。
#つまり、
#というFunctionが必要になる。
#Attack DiscoveryやAI SOCは、このVerification Loopを人間だけではなくAgentにも回させようとしている。
#これは単なるSecurity Automationではない。
#AI全体のFunction Ladderから見ると、
#GenerationからVerificationへ進むためのInfrastructure
#とも考えられる。
#ElasticはAction能力ではなく「安全に使えるAction能力」を増やす
#AI Agentが、
#検索する。
#Fileを読む。
#Ticketを作る。
#APIを呼ぶ。
#Hostを隔離する。
#Configurationを変更する。
#というActionを持つようになると、
#する。
#しかしAction能力が高いほど、誤動作のDamageも大きくなる。
#そこで、
#Permission。
#Human-in-the-loop。
#Audit。
#Security Policy。
#Observability。
#が必要になる。
#Elastic 9.5のAgent ObservabilityやHuman Approval、Security Workflowは、この問題に対応している。
#つまりElasticが拡張するのは単純な、
#ではなく、
#と考えた方がよい。
#AIのAction Spaceが広がっても、企業がそのActionを信用できなければFunctionとしてDeployできない。
#したがって、
#である。
#Elasticは、
#への変換を支える。
#ElasticはLong-Horizon Agentの前提Infrastructureにもなる
#HKMGA仮説ではFunction Ladderの一例として、
#↓
#↓
#↓
#↓
#↓
#という流れを想定している。
#ElasticはこのLadderのかなり前半から中盤を横断する。
#Long-Horizon Agentは、数分だけ動くAgentとは違う。
#昨日何をしたか。
#一週間前に何が失敗したか。
#過去のIncidentで何を学んだか。
#今のInfrastructure状態はどうか。
#どのUserからApprovalを得たか。
#といったStateを持つ必要がある。
#すると、
#が必要になる。
#Elastic自体がLong-Horizon Plannerになるわけではない。
#しかし、
#Long-Horizon Agentが長時間にわたって世界との整合性を維持するための外部MemoryとObservation Layer
#になり得る。
#Multi-Agent化すると「共有Context」が新しいBottleneckになる
#一つのAIが、
#Research Agent、
#Coding Agent、
#Verification Agent、
#Security Agent、
#Execution Agent
#へ分化するとする。
#すると新しい問題が生まれる。
#各Agentが何を知っているのか。
#誰が何を実行したのか。
#どの情報が最新なのか。
#どのAgentがどの権限を持つのか。
#つまり、
#がBottleneckになる。
#この場合Elasticは、
#として使える。
#Research Agentが取得した情報をCoding Agentが検索し、Security AgentがExecution結果を監視し、Verification Agentが過去のEvidenceを再取得する。
#すると、
#という需要が生まれる。
#HKMGA仮説でもMulti-AgentはFunction Ladderの一段として考えられている。
#Columnar Modeは「Observation Functionの単価」を下げる
#Elastic 9.5のColumnar ModeをHKMGAから見ると、これも単なるStorage Optimizationではなくなる。
#HKMGA仮説ではFunction Jevonsとして、
#↓
#↓
#↓
#↓
#という構造を考えている。
#Metricsを保存するCostが下がる。
#すると、より多くのMetricsを保存できる。
#Retentionを長くできる。
#より多くのServiceを監視できる。
#Agentがより長期間のTelemetryを参照できる。
#より高度なInvestigationが可能になる。
#したがってColumnar Modeは、
#を通じて、
#を作る。
#そして観測できる量が増えると、新しい異常や新しいBottleneckも発見される。
#これはHKMGAの、
#という構造とも相性がよい。知識が増えるほど未知が減るだけではなく、新しく観測可能になった世界から別の未知が現れるという考えである。
#Elastic 9.5をFunction Expansionとして見る
#Elastic 9.5の各機能をこのFrameworkへ置くと、かなり一貫して見える。
#VectorDB Index ModeはSemantic Retrieval Function。
#Multimodal SearchはObservation Space。
#Hybrid SearchとRerankingはContext Accuracy。
#PrometheusとPromQLはInfrastructure Observation。
#Columnar ModeはCheap Persistent Observation。
#Agent ObservabilityはSelf-Observation。
#Human-in-the-loopはSafe Action。
#Attack DiscoveryはVerification。
#Alert ZeroはAutonomous Investigation。
#Kubernetes IntegrationはDynamic Infrastructure Observation。
#Deductive AIはIncident ReasoningとFeedback Loop。
#つまりElastic 9.5全体は、
#AIそのものを賢くするReleaseというより、AIが世界を観測し、記憶し、検索し、検証し、安全に行動し、その結果を再び観測できるようにするRelease
#と見ることができる。
#ElasticはHKMGAのどこを拡張しているのか
#HKMGAへ直接当てはめれば、Elasticの役割はかなり明確になる。
#については、Entropyそのものを消すわけではない。
#むしろ、それまで見えなかったDataを検索・観測可能にすることで、
#する場合がある。
#については、Search、Retrieval、Observability、Security Investigationによって、
#を支援する。
#については、企業Data、Logs、Metrics、Traces、Security Eventsを検索可能な形で保持するため、
#する。
#については、Elastic自体がGoalを作るわけではない。
#しかし利用可能なFunctionが増えれば、新しいGoalが実現可能になる。
#HKMGA仮説では、
#という関係を置いている。
#例えばObservabilityがなければ、
#「数万Podを跨いでAIが自律的にRoot Causeを調査する」
#というGoal自体が実用的ではない。
#Observation Functionが増えたことで、そのGoalが現実的になる。
#そして、
#については、Agent BuilderやSecurity Workflowによって、
#を支える。
#Elasticが拡張する最も重要なFunctionは何か
#一つだけ選ぶなら、
#だと考えられる。
#日本語にすれば、
#「必要な記憶を現在の状況に応じて取り出し、行動結果を観測し、その情報を次の判断へ返す能力」
#である。
#これは単なるSearchではない。
#である。
#AIが一問一答のChatbotなら、このFunctionの価値は限定的である。
#しかし、
#と進むほど、このFunctionの重要度は高くなる。
#HKMGAから見るElastic需要の連鎖
#このFrameworkに従うなら、Elastic需要は単独で発生するのではない。
#まずFoundation ModelのReasoning能力が上がる。
#すると、より複雑なTaskへAIを使う。
#↓
#Agentが長時間動く。
#↓
#Memoryが必要。
#↓
#Search & AI。
#Agentが大量にActionする。
#↓
#Logs、Metrics、Tracesが増える。
#↓
#Observability。
#AgentがFile、API、InfrastructureへActionする。
#↓
#Attack Surfaceも拡大する。
#↓
#Security。
#Security AgentやSRE Agent自体もActionする。
#↓
#さらにTelemetryが増える。
#したがって、
#↓
#↓
#という連鎖を考えることができる。
#これはHKMGA仮説の、
#という原則そのものである。
#ElasticはAIのFunction Supply Chainのどこにいるのか
#この観点で見ると、AI Infrastructure企業の役割も整理しやすい。
#GPUは、
#を支える。
#HBMは、
#を支える。
#OpticalやNetworkは、
#を支える。
#Storageは、
#を支える。
#Elasticはより上位Layerで、
#を支える。
#つまりElasticは、
#AIそのものの知能を供給する企業というより、AIが次のFunctionを獲得するための外部HKMGA Infrastructureを供給する企業
#と表現できる。
#そしてElastic自身もMeta-Function化する可能性がある
#HKMGA仮説では特に重要なFunctionとして、
#つまり、
#Functionを改善するFunction
#を考えている。
#Elasticが単にDataを保存するだけならMeta-Functionではない。
#しかし、
#Incidentを観測する。
#↓
#原因を調査する。
#↓
#過去のInvestigationを参照する。
#↓
#次回のInvestigation方法を改善する。
#↓
#さらに速くRoot Causeを発見する。
#というLoopへ進めば話が変わる。
#Deductive AIを利用したAgentic SREなどは、この方向に近い。
#つまり、
#となる。
#これは小さな形ではあるが、
#を支える。
#もし今後、Security AgentやSRE Agentが自ら、
#「自分に不足しているTelemetryは何か」
#「どのDetection Ruleを追加すべきか」
#「どのMetricを新しく収集すべきか」
#「どのConnectorが不足しているか」
#まで発見するようになれば、
#Elasticは単なるObservation Platformではなく、
#Observation Function自体を改善するPlatform
#へ近づいていく。
#ここまで進めばHKMGA仮説でいうRecursive Leverageも高くなる。
#Elasticの投資仮説も変わってくる
#この視点に立つと、Elasticを見る問いも変わる。
#従来なら、
#Search市場は何%成長するのか。
#Observability市場はどれほど大きいのか。
#SIEMで何%のShareを取れるのか。
#という見方になる。
#HKMGA的には、
#AIが次にどのFunctionを獲得するか。
#から始める。
#もしAIが、
#Persistent Agent、
#Long-Horizon Agent、
#Multi-Agent、
#Autonomous Security、
#Agentic SRE
#へ進むなら、そのFunctionが要求するWorkloadを見る。
#さらに、
#へ降ろす。
#そこでElasticがどれだけShareを取れるかを見る。
#これはHKMGA記事で示した、
#という分析方法をSoftware Infrastructureへ適用した形である。
#Elasticは「AIによって消えるSaaS」なのか、それともFunction Expansion Infrastructureなのか
#最終的にはここが最も重要になる。
#CodexやClaude Codeによって、
#Search UI。
#Dashboard。
#Connector。
#RAG Application。
#Workflow。
#Migration Script。
#は急速に安く作れるようになる。
#その意味ではElasticのApplication Layerには強いコモディティ化圧力がかかる。
#しかしHKMGA仮説が正しく、AI Functionが拡張し続けるなら、同時に、
#Agent数。
#Action数。
#State量。
#Context取得。
#Telemetry。
#Security Event。
#Verification。
#が増える。
#つまり、
#によって、
#し、
#結果として、
#する可能性がある。
#これはFunction Jevonsそのものである。
#したがってElasticにとって本当の問題は、
#CodexでElastic風のSearch Appを作れるか
#ではない。
#より重要なのは、
#AIがFunctionを拡張するほど生じるContext・Memory・Telemetry・Security需要を、Elasticが共通Infrastructureとして取り込めるか
#である。
#この仮説に従えば、Elasticの本質的な賭けは、
#↓
#↓
#というLoopを成立させられるかにある。
#ElasticはAIの「脳」そのものではない。
#しかしAIの外側に、
#検索可能な長期Memory、世界を観測するSensor、行動結果を記録するTelemetry、判断を検証するEvidence、行動を制御するSecurity
#を加える。
#そしてそれらが次のAI Functionを可能にする。
#HKMGA仮説で言えば、
#という見方ができる。
#もしAIがChatbotで止まらず、Persistent Agent、Multi-Agent、Autonomous Operationへ進むなら、Elasticにとって重要なのは「検索需要が増えるか」だけではない。
#AI Function Expansionそのものが、Searchable Memory・Context・Observation・Verification・Securityをどれほど必要とするか。
#今後のElasticを見るうえでは、こちらの問いの方が本質的なのかもしれない。
#Deductive AI買収――Elasticは「監視する」から「AIが原因を調査する」へ
#ElasticのObservability戦略を見るうえで、もう一つ重要なのがDeductive AIの買収である。
#報道では買収額は最大8,500万ドルとされている。一方、Elasticの買収後の開示では株式100%取得に対する現金対価として約7,000万ドルが計上されているため、「最大8,500万ドル」は報道ベースの上限額、「約7,000万ドル」は現時点で会計上確認できる取得対価、と分けて考えた方がよい。
#金額だけを見ればElastic全体を左右するほど巨大な買収ではない。
#しかし、戦略的にはかなり重要である。
#Deductive AIが作っていたのは、
#AI SRE
#である。
#SRE――Site Reliability Engineeringとは、ApplicationやInfrastructureを安定して稼働させ、障害が起きた場合にその原因を発見し、復旧させるEngineering領域である。
#従来のObservability Platformは、
#「CPU使用率が急上昇した」
#「p99 Latencyが悪化した」
#「Kubernetes PodがRestartを繰り返している」
#といった異常を発見し、人間へ提示することが中心だった。
#つまり、
#↓
#↓
#↓
#という構造である。
#しかしDeductive AIが狙っているのは、その最後のHuman Investigation自体をAgent化することである。
#例えばWeb ApplicationのLatencyが突然悪化したとする。
#人間のSREなら、
#Metricsを見る。
#Logsを見る。
#Traceを見る。
#直前のDeployを見る。
#Code Repositoryを見る。
#Slackを検索する。
#PagerDuty Incidentを見る。
#ServiceNowの過去Ticketを見る。
#類似障害を探す。
#そして、
#「Database Connection Poolが枯渇したのではないか」
#「Networkではないか」
#「直前のCode Changeが原因ではないか」
#という仮説を立て、追加Evidenceによって一つずつ検証していく。
#Deductive AIは、このInvestigative LoopそのものをAI Agentへ移そうとしている。
#概念的には、
#↓
#↓
#↓
#↓
#という流れになる。
#重要なのは、単純にAlertをLLMへ渡して、
#「この障害について要約してください」
#とするだけではないことである。
#Code、Metrics、Logs、Traces、Alert、過去Incident、Slack、PagerDuty、ServiceNowなど複数Sourceを探索し、そのEvidenceから仮説を作り、追加情報によって検証する。
#つまりObservabilityの価値を、
#から、
#へ移そうとしている。
#Deductive AIとElasticはなぜ相性がよいのか
#ここでElasticとの組み合わせが重要になる。
#AI Agentがどれほど賢くても、障害を調査するにはEvidenceが必要である。
#Elasticにはすでに、
#Logs。
#Metrics。
#Traces。
#Kubernetes Events。
#Application Events。
#Security Events。
#Alert。
#Search Index。
#といった巨大なTelemetry Dataが存在する。
#つまりElasticは、
#を持っている。
#一方Deductive AIが持つのは、
#である。
#したがって、
#という組み合わせになる。
#これは単なるStartup買収というより、
#Elasticが持っていた「Dataを検索する能力」の上に、「そのDataを使って自律的に原因を調査する能力」を追加する買収
#と見る方が分かりやすい。
#Columnar Mode、Prometheus、Deductive AIは一つの戦略としてつながる
#この買収はElastic 9.5のMetrics強化と切り離して考えるより、一つの流れとして見た方がよい。
#Elasticは歴史的にLogsには強かったが、Metricsではそれほど強い立場ではなかった。今回の記事で見てきたように、Elastic 9.5ではColumnar Mode、Native Prometheus ingestion、PromQL Supportなどを追加し、Metricsを低コストかつ大規模に扱えるPlatformへ変えようとしている。
#これをDeductive AIまでつなぐと、
#↓
#↓
#↓
#↓
#↓
#という構造が見えてくる。
#つまり、
#Prometheus対応はDataを入れるための入口。
#Columnar ModeはDataを大量かつ安価に保持するためのBackend。
#Deductive AIは、そのDataを使って考えるReasoning Layer。
#である。
#これが揃えば、Elastic Observabilityの競争軸は、
#「Dashboardが見やすいか」
#だけではなく、
#大量TelemetryからRoot Causeへどれだけ速く到達できるか
#へ変わってくる。
#Observabilityの価値単位そのものが変わる可能性
#これはSoftware Businessとしても重要である。
#従来Observabilityは、
#Storage量。
#Ingest量。
#Host数。
#Telemetry量。
#などと強く結びついていた。
#しかしAI SREが本当に機能すれば、顧客が買っている価値を、
#から、
#へ引き上げられる可能性がある。
#例えば年間1万件のIncidentが存在し、平均して人間が1件30分調査しているとする。
#年間調査時間は、
#である。
#AI SREによって初期調査の80%を自動化できるなら、理論上は、
#のEngineering Timeが自動化対象になる。
#もちろん実際の効果はIncidentの複雑さや精度によって大きく異なるため、この数値は説明用の単純例にすぎない。
#しかし顧客が評価するものが、
#「1GBをいくらで保存できるか」
#だけではなく、
#「MTTR――Mean Time To Resolutionを何%縮められるか」
#になるなら、ElasticがCaptureできるValue Poolは大きく変わる。
#MTTRとは何か
#MTTRは、
#Mean Time To Resolution
#あるいは文脈によってMean Time To Repairなどと呼ばれる。
#簡単に言えば、
#障害が発生してから復旧・解決するまでにどれくらい時間が必要か
#を見る指標である。
#概念的には、
#となる。
#Observabilityの最終目的はDashboardを見ることではない。
#本来は、
#によって、
#させることである。
#Deductive AIは、このうち特に、
#を狙っている。
#Reinforcement Learning Harnessが意味するもの
#Deductive AIについてElasticが強調しているもう一つの特徴が、
#Reinforcement Learning Harness
#である。
#ここでいうHarnessはFoundation Modelそのものではない。
#LLMの周囲に、
#どのToolを使うか。
#どのData Sourceを調べるか。
#どの順番でEvidenceを集めるか。
#どのHypothesisを検証するか。
#過去の調査結果をどう再利用するか。
#という仕組みを作る。
#例えば過去のIncidentで、
#Latency急増
#↓
#Kubernetes確認
#↓
#Database Metrics確認
#↓
#Connection Pool確認
#↓
#Root Cause発見
#という調査経路が成功したとする。
#すると新しい類似Incidentで、その経験を次のInvestigationへ利用できる。
#概念的には、
#↓
#↓
#↓
#となる。
#これは単純なLLM Callとはかなり性質が違う。
#HKMGA仮説で見ると、Deductive AI買収はさらに重要に見える
#ここまでの記事で扱っているHKMGA仮説へ戻すと、この買収の意味はさらに明確になる。
#通常のObservabilityは主として、
#を拡張する。
#Metrics、Logs、Tracesによって、
#「システム内部で何が起きているのか」
#を見えるようにするからである。
#しかしDeductive AIが入ると、
#↓
#↓
#↓
#↓
#へ変わる。
#つまりElasticは、
#Observation Function
#だけでなく、
#Verification Function
#さらに、
#Feedback Function
#を取り込み始める。
#これはHKMGAでいう、
#というMeta-Functionへ少し近づく。
#現在の記事でも、ElasticはAIそのものの知能を供給するというより、Context、Searchable Memory、Observation、Verification、Governed Actionを提供する外部HKMGA Infrastructureとして整理している。
#Deductive AIはこの中でも、
#を接続する技術だと考えられる。
#「過去のIncidentから次のInvestigationを改善する」はMeta-Functionに近い
#HKMGA仮説では、
#つまり、
#Functionを改善するFunction
#を重要なConceptとしている。
#ElasticがDataを保存して検索するだけなら、これには該当しにくい。
#しかし、
#Incidentを観測する。
#↓
#原因を調査する。
#↓
#成功・失敗した調査経路を保存する。
#↓
#次のIncidentでそれを利用する。
#↓
#調査Function自体が改善する。
#となれば、
#というLoopになる。
#実際、現在の記事でもDeductive AIを利用したAgentic SREを、このMeta-Function化に近い例として位置づけている。
#この買収は、その抽象的な仮説に対して、Elasticが実際にProductとして投資している具体例と見ることもできる。
#将来的には「自分に足りないObservationを発見するAgent」へ進めるか
#さらに先を考えると興味深い。
#現在のAI SREは基本的に、
#与えられたTelemetryを使って障害原因を調査する
#段階である。
#しかし将来Agentが、
#「この障害を判別するには現在のMetricsでは不足している」
#「このServiceには新しいTraceが必要だ」
#「このApplication Logに新しいFieldを追加すべきだ」
#「このAlert RuleはFalse Positiveが多い」
#「このConnectorが不足している」
#と自ら発見するようになれば、
#単に既存DataからRoot Causeを探すだけではなく、
#そのものを改善する。
#すると、
#↓
#↓
#↓
#↓
#↓
#という再帰Loopになる。
#ここまで来れば、Elasticは単なるObservability Platformではなく、
#Observability Function自体を改善するPlatform
#へ近づく。
#これはHKMGA仮説でいうRecursive Leverageが高いFunctionになる可能性がある。
#なぜ現在Revenueの小さいStartupへ数千万ドルを払うのか
#この視点から見ると、買収価格の意味も変わる。
#Deductive AIの現在売上だけを基準に考えると、報道されている最大8,500万ドルという買収価格は高く見える可能性がある。
#しかしElasticが買っているものを、
#現在ARR
#だけではなく、
#AI SRE Technology
#Investigation Harness
#Knowledge Representation
#Engineering Team
#Agentic SREのTime to Market
#と見るなら意味が違う。
#つまり、
#であり、
#に近い。
#Elasticが自社だけで同じTechnologyを作るより1～2年早くAgentic SREを市場投入できるなら、そのTime Advantageにも価値がある。
#特にAI Software市場ではBottleneck Migrationの速度そのものが速くなっているため、
#正しいTechnologyを持っているか
#だけではなく、
#いつ持てるか
#の価値が上昇している。
#Deductive AI買収はObservabilityのOption Valueを大きくする
#今回の決算分析では、Elasticの三事業について、
#SecurityはすでにCommercial tractionが強い。
#Search & AIも大型Context案件が出始めた。
#ObservabilityはMetrics強化によってこれから追いつけるかを見る段階。
#と整理した。
#Deductive AI買収は、この三番目のObservabilityに対するOption Valueをさらに大きくする。
#つまりElasticのObservability仮説は、
#だけではない。
#へ広げ、
#さらに、
#へ進もうとしている。
#最終的には、
#というAgentic SRE Stackを狙っていると見ることができる。
#そのためDeductive AI買収は、単なる小規模M&Aとして見るより、
#ElasticがObservabilityを「人間がTelemetryを読むSoftware」から「AIがTelemetryを使って原因を調査するSystem」へ変えるためにReasoning Layerを取得した
#取引として見る方が重要である。
#そしてHKMGA仮説から見れば、
#だけを供給していたPlatformが、
#へ進み始めた事例でもある。
#Elasticが本当にこのLoopを成立させられるなら、Deductive AIの価値は「買収時点の売上」より、Elastic Platform上に蓄積される膨大なTelemetryを、どれだけ次のAI Functionへ変換できるかによって決まることになる。
#