追跡対象の全11ツールを対象とした構造監査を、2026年10月23日に直接HTTPチェックで実施した。プレゼンスの数値はDevTuneの公開テーブルに基づく。90日レポートと30日間のライブページは異なる期間を使っており、決して混在させていない。
AIの回答は、インシデント管理ツールの候補を少数に絞って購入者に提示する。大半の枠を占めるのはincident.io、Rootly、PagerDutyだ。このカテゴリで追跡している11ツールが、引用可能な資産を実際にどれだけ整備しているかを調べると、不都合な傾向が見えてきた。購入者に知られていないツールがすべて基本要素を欠いているわけではなく、基本要素を備えていても引用されるとは限らない。機械可読な設定が最も整っているツールのプレゼンスは、ほぼゼロかゼロだ。
これが短い答えだ。このノートの残りでは、その根拠となるデータを示す。AIが現在、インシデント管理とオンコール対応に何を推奨しているか、11ツールそれぞれがどんな機械可読資産や比較ページを整備しているか、そして自社ツールが候補から外れている場合、その差が何を意味するかだ。
これは診断であり、ランキングではない。こうしたツールの順位はすでに他の媒体が付けている。ここで問うのは別のことだ。引用されないツールはなぜ負けるのか?
現在、AIがインシデント管理に推奨するもの
ChatGPT Search、Perplexity、Gemini Search、Google AI Mode、Bing Copilotは、主に3つのブランドを購入者に案内する。incident.io、Rootly、PagerDutyだ。DevTuneの公開AI検索の現状レポートは2026年4月2日から6月30日まで、このカテゴリの回答を1,255件測定し、incident.ioが47.9%、Rootlyが32.7%、PagerDutyが26.8%に出現したことを示した。追跡対象ブランド全体のカテゴリ中央値は12.4%だった。
DevTuneはこのカテゴリの公開ライブページローリング30日間のウィンドウを設けた公開ページを運営している。2026年10月下旬時点でも同じ3社が先頭だ。incident.ioのプレゼンスは42.7%、Rootlyは36.7%、PagerDutyは34.0%。このページの注目点は2つある。
- 残りのツールはほぼ姿を消している。30日間の期間では、ilertのプレゼンスは2.0%、OneUptimeは0.7%、Spike.shとSquadcastはどちらも0%だ。
- 引用されることと名前を挙げられることは違う。DevTuneはプレゼンス(ページが情報源として引用されること)とブランドへの言及(回答で選択肢として名前が挙がること)を区別している。PagerDutyは回答の34%に存在したが、名前が挙がったのは0%。incident.ioは42.7%に存在し、66%で名前が挙がった。
30日間の全体像はDevTuneの公開ブランド表:
| 順位 | ブランド | 掲載状況 | ブランドへの言及 | 引用ペア数 |
|---|---|---|---|---|
| 1 | incident.io | 42.7% | 66.0% | 64 |
| 2 | Rootly | 36.7% | 0% | 55 |
| 3 | PagerDuty | 34.0% | 0% | 51 |
| 4 | Opsgenie | 14.7% | 0% | 22 |
| 5 | FireHydrant | 11.3% | 27.3% | 17 |
| 6 | Better Stack | 4.7% | 20.0% | 7 |
| 7 | Grafana (IRM) | 4.0% | 1.3% | 6 |
| 8 | ilert | 2.0% | 0% | 3 |
| 9 | OneUptime | 0.7% | 0.7% | 1 |
| 10 | Spike.sh | 0% | 0.7% | 0 |
| 11 | Squadcast | 0% | 0% | 0 |
この表で4位なのはOpsgenieです。Atlassianの製品で、販売を終了した— 販売は2025年6月4日に終了し、サポートは2027年4月5日に終了する。これはAtlassian自身の移行ページによる。30日間の期間中も、そのページは約7件に1件の回答で引用されている。AIの回答は、情報源が書かれた時点で存在した証拠に基づくため、文書が大量にある製品は市場が移り変わった後も長く引用され続ける。
(このセクションのDevTuneの数値はすべて、末尾にリンクした2つの公開ページから取得したもので、それぞれ異なる期間を対象としています。90日レポートと30日間のライブページではサンプル数が異なるため、小さな差は測定ノイズとして扱ってください。)
確認した内容と方法
このカテゴリで追跡している各ブランドについて、回答エンジンが実際に利用できる引用可能なコンテンツを確認しました。11個のツールをそれぞれ6項目ずつ、すべて2026年10月23日に直接HTTPリクエストを送って調査しました:
- llms.txt ドメインのルートに置かれる、機械可読向けの新しいインデックスファイル
- llms-full.txt 単一ファイル版
- robots.txt AIクローラー向けのルール(GPTBot、ClaudeBot、PerplexityBot など)
- 競合比較または代替案のページ サイトマップ内
- 公開ベンチマークまたは独自調査のコンテンツ
- ドキュメントポータルへのアクセス性(HTTPステータスとページタイトル)
これはモデルのサンプリングではなく、構造上の事実だ。各チェックでは、ステータスコードと確認可能なコンテンツが返されたか、何も返されなかった。サーバーがステータス200のHTMLエラーページを返した場合は、存在しないものとして数えた。
監査で分かったこと
11個中7個のツールが有効なllms.txtを公開している。4個がllms-full.txtを公開している。2個はrobots.txtでAIクローラーを名前で明示的に歓迎しており、残りの大半はデフォルトで許可している。1個のツールのドキュメントはログイン壁の内側にある。
| 項目 | 該当するツール(11個中) | 対象 |
|---|---|---|
| 有効な llms.txt | 7 | incident.io、Rootly、FireHydrant、Grafana、ilert、OneUptime、Spike.sh |
| llms-full.txt | 4 | Rootly、Grafana、OneUptime、Spike.sh |
| robots.txtでAIボットを明示的に歓迎 | 2 | Rootly、OneUptime |
| 比較または代替案のページ | 6 | incident.io(7ページ)、ilert(25)、OneUptime(30)、Rootly(4)、Spike.sh(2)、Better Stack(1) |
| ログインなしでアクセスできるドキュメント | 10 | Squadcast以外のすべて |
| 公開ベンチマークコンテンツ | 5 | Rootly(投稿6件)、PagerDuty(レポート1件)、incident.io(投稿1件)、Grafana(ダッシュボード13個)、OneUptime(投稿56件、インフラベンチマーク) |
PagerDuty、Opsgenie、FireHydrant、Grafanaは比較ページをまったく公開していない。SquadcastのsitemapはSolarWinds全体のsitemapにリダイレクトされるため、監査できなかった。
この表を存在率の数値と照らし合わせると、2つの点が際立つ。
発見1:基本要素の欠落は最下位を説明するが、中位は説明できない。Squadcastが最もわかりやすい例だ。ドメインには有効なrobots.txtもllms.txtもなく、sitemapはSolarWinds全体のsitemapにリダイレクトされ、ドキュメント用ドメインはGoogleのログインページにリダイレクトされる。この構成では機械が読みやすいとは言えない。存在率は0%。診断は簡単だ。クローラーがログインなしでドキュメントにアクセスできなければ、競争に参加できていない。
発見2:これらの資産だけでは引用につながらない。Spike.shはllms.txt、llms-full.txt、2つの比較ページ、完全に公開されたrobots.txtを維持している。30日間のウィンドウで存在率は0%。OneUptimeはさらに徹底している。robots.txtに"AI / LLM crawlers are welcome"と記し、両方のllmsファイルに加えてドキュメント用のllms.txtも公開し、30の比較ページを維持している。存在率は0.7%。チェックリストは前提条件のように働く。引用は別のところから来る。
引用データによると、勝者を実際に支えているものは何だろうか。30日間のウィンドウで、DevTuneはこのカテゴリの2,487件の引用の内訳を記録した。ブログ記事31.6%、ドキュメント24.8%、比較ページ19.1%、ベスト製品リスト10.0%、製品ページ8.1%。引用元のうち、企業所有および商用ソースが85.5%、編集記事が9.1%、コミュニティのスレッドが1.3%を占める。90日間のレポートでは、incident.ioの首位についてDevTune自身がこう説明している。"カテゴリの教育コンテンツが、リーダーへの引用の大半を生み出している。"リーダーが得る引用の約88%は、ドキュメントや製品ページではなくブログ記事を指している。
これが本当の差だ。負けているツールに欠けているのは設定ファイルではない。買い手が質問したときに回答が参照する、周辺の証拠群が不足しているのだ。カテゴリの解説、詳しい比較、第三者のリスト、手法を示したベンチマーク記事などがそれに当たる。incident.ioはブログで勝つ。RootlyはGemini Searchが引用する比較ページで勝つ。PagerDutyはドキュメントだけで勝つため、情報源として引用されても選択肢として名前が挙がることはない。回答に登場する道は複数あり、いずれも公開され、見つけられる証拠を通る。
引用されないツールが負ける理由
2つのデータセットを合わせて見ると、このカテゴリで負けているツールには次の傾向がある。
- 存在率ゼロのツールは、内容の薄いサイトを機械可読にした程度にとどまる。回答エンジンが"最高のインシデント管理ツール"をまとめる際、カテゴリ解説や比較資料を参照する。上位に表示されるコンテンツを何も公開していなければ、候補に入らない。
- 扉があるべき場所に壁がある。ログイン必須のドキュメント(Squadcast)、robots.txtの欠落、親ブランドに統合されたドメイン(OpsgenieはAtlassianに、SquadcastはSolarWindsに)が、コンテンツから回答への経路を断っている。
- 機械はSpike.shとOneUptimeを読めるが、引用する理由がない。周囲の証拠がなければ、llmsファイルはまだ誰も主張していない論点をインデックス化するだけだ。
- 古い選択肢は残り続ける。販売終了から18か月経ってもOpsgenieが表示されることは、回答が自動で更新されないことを示している。これは両面に作用する。今日のAI回答における自社ツールの位置は、誰かがより良い証拠を公開するまで維持される。
記録しておきたい注意点がある。この監査で測定したのは構造であり、カバレッジではない。第三者による言及、レビューサイト、コミュニティのスレッドは数えていないが、DevTuneのデータはそれらも役割を果たすことを示している。構造面の調査結果は、各ツール自身のドメインに何が欠けているかを示すものだ。特定ブランドの数値をどの施策が動かすかを証明することはできないし、決まったチェックリストで引用が保証されると主張する人を信頼するつもりもない。
自社ツールが選ばれない場合にすべきこと
このカテゴリのデータに沿った手順:
- まず入口を開く。有効なrobots.txt、主要ページを列挙したllms.txt、そしてクローラーがログインなしでアクセスできるドキュメントを用意する。11ツールの大半はすでにこの基準を満たしている。自社ツールが満たしていないなら、リストの他の項目はあまり意味を持たない。
- 引用の内訳が求めているページを作る。このカテゴリでは、カテゴリの解説(インシデント対応とは何か、選び方)と誠実な比較ページを意味する。リーダーの引用プロファイルは、まさにこれらの形式が中心だ。
- 第三者のリストに載る。このカテゴリの引用の10件に1件は次を指している:ベスト製品リストとレビュー記事。そのページが同じ3つのブランドしか知らなければ、同じ3つのブランドを推奨し続ける。
- 情報を新しく保つ。Opsgenieが引き続き表示されることは、回答が古い証拠に長期間依存することを示している。公開日、現在の価格、更新された比較ページがあれば、回答エンジンが説明を更新する理由になる。
自社ツールにも同じチェックを行いたい場合は、CiteGapの無料監査を提供している。ドメイン上の引用可能な資産を調べ、カテゴリ内で実際に引用されているものと比較し、ギャップをわかりやすい言葉で伝える。
よくある質問
AIが最もよく推奨するインシデント管理ツールは何か。
DevTuneの90日間のレポート期間と、現在の30日間のライブテーブルでは、同じ3つのツールが上位を占めている。incident.io、Rootly、PagerDutyだ。incident.ioは両方の期間で首位。PagerDutyは推奨ツールとして挙げられるより、出典として引用されることのほうが多い。
AIはなぜ私のインシデント管理ツールに一度も言及しないのか?
このカテゴリで最も一般的な構造上の原因は、根拠となる情報の網がないこと(カテゴリ解説ページや比較ページがない)、技術的な障壁(ログインが必要なドキュメント、llms.txtがない、制限の厳しいrobots.txt)、またはAIの回答が確立された情報源に依存する分野でブランドが新しいことだ。追跡対象の11ツールすべてを監査したところ、11のうち7に有効なllms.txtがあり、11のうち6に比較ページがあった。存在感がゼロのツールには、構造か根拠、またはその両方が欠けていた。
llms.txtを公開すれば、AIに引用されることが保証されるのか?
いいえ。Spike.shとOneUptimeはどちらも充実したllms資産を整えているが、存在感はほぼゼロかゼロだ。llms.txtと公開されたrobots.txtは、最低限の条件にすぎないようだ。このカテゴリの引用データが評価しているのは、回答が引用できるカテゴリ解説や比較コンテンツだ。
自分の開発者向けツールが引用されやすいか、どうすれば確認できる?
自分で構造チェックを自分で再現する(llms.txt、robots.txt、ドキュメントへのアクセス、sitemap内の比較ページを確認する)、またはCiteGapの無料監査。このツールはチェックを実行し、カテゴリ単位の比較も追加する。ブランド単位の存在感の数値については、DevTuneがライブテーブルを公開しているのこのカテゴリのテーブルを公開しており、この記事はそのデータに基づいている。
出典
- DevTune、State of AI Search for Dev Tools(データ期間:2026年4月2日から6月30日まで。43カテゴリ、このカテゴリで測定した回答は1,255件):devtune.ai/dev-tools-state-of-ai-search
- DevTune、Incident Management & On-Callのライブブランドテーブル(ローリング30日間、2026年10月23日閲覧):devtune.ai/verticals/incident-management-and-on-call
- Atlassian、Opsgenieの移行ページ(販売終了:2025年6月4日、サポート終了:2027年4月5日):atlassian.com/software/opsgenie/migration
- インシデント管理ツール11件の構造監査:CiteGapが2026年10月23日に実施した直接HTTPチェック(llms.txt、llms-full.txt、robots.txt、サイトマップ、ドキュメントへのアクセス)