incident.io、$62M調達でincident responseをAI investigationへ広げた転換

Stephen Whitworth、Chris Evans、Pete Hamiltonの3人は、Monzoで見たincident対応の不便さを出発点にincident.ioを始めた。

Peteは既存製品を調べても納得できず、ChrisがMonzoで作った小さなResponseの仕組みに接続した。

3人は2021年、ロンドンの元消防署でプロダクトを形にした。出典

創業前の違和感

Chris EvansはMonzoでincident用のSlack commandとchannelを作り、最初は2晩で動く小さな仕組みだった。

彼は「None of these feels great」と、既存のincident management製品への違和感を語っている。出典

PeteとStephenも、組織の障害対応が手作業と複数ツールに分かれる問題を別の立場から経験していた。

side projectから会社へ

当初は本業の早朝や夜に進めるside projectだった。

2022年の振り返りでChris Evansは、5時30分に起きて開発する日々と、GoCardlessへの最初のdemoを振り返っている。出典

最初の顧客を得ると、3人だけでは拡張できない現実に直面し、元同僚を採用する決断へ進んだ。

顧客の現場から広げる

2022年には34Mドルの調達を発表し、創業者3人から30人のチームへ成長した。出典

ただし資金調達だけで勝ったのではない。

週次changelogを4年間継続し、顧客の要望を出荷の習慣へ変えた。出典

ResponseからAI investigationへ

Response、Status Pages、On-callと隣接製品を積み上げた後、2025年には62MドルのSeries Bを発表した。

同社は250,000件超のincidentを扱い、AI agentsが調査や要約を支援する方向を明確にした。出典

ここでの転換は、人間を置き換えることではなく、2時の障害対応で必要なcontextを早く揃えることにある。

結び

incident.ioの道のりは、複雑なSRE機能を最初から全部作る話ではない。

創業者自身が痛みを知るworkflowを小さく作り、顧客の運用データと要望を次の製品へ接続した結果、incident responseを組織全体のreliability platformへ広げた事例だ。

incident.ioのPMFは、障害対応を一部のSREだけの専門作業にせず、Engineering・Security・Support・経営まで参加できる日常のworkflowへ落とした点にある。

Etsyではincident手順の95%をWorkflowsで自動化し、Netflixでは数千人のengineerと25以上のinternal status pagesに広がった。出典 出典

SlackやTeamsの中で宣言・連絡・記録を完結させるため、初動時の認知負荷を下げられる。

PagerDutyやJiraを置き換えること自体より、低重大度の事象も記録して学習する入口を作ることが価値の中心だと考えられる。

顧客のincident履歴、service catalog、workflow、postmortemを同じ文脈で蓄積する運用データの蓄積がmoatになる。

単なるpaging APIより、組織固有のサービス関係と対応知識を横断して使える点が模倣しにくい。

直接のnetwork effectは弱い。

一方、Incidentを宣言する人が増えるほど組織内のデータと共通言語が増え、他チームも導入しやすくなる間接効果はある。

顧客・社内チーム・連携サービスの接点が増えるほどplatform価値が上がる。

主な対象は、複数サービスを運用し、障害対応がEngineeringだけに閉じている中堅からEnterpriseのチーム。

PagerDuty等のpaging、Slackの手作業、status page、postmortemが分断している組織に向く。

単一サービスの小規模チームにはBasicや既存運用で十分な場合もある。

第一は、既存の作業場所であるSlack/Teamsに入ったこと。

第二は、毎週のchangelogと顧客の要望を短い開発サイクルで製品へ戻したこと。出典

第三はResponseからStatus Pages、On-call、Investigationsへ隣接領域を積み上げたこと。出典

課題は、incident responseの統合範囲が広がるほど設定・権限・データ連携の複雑さが増すことだ。

既存のPagerDuty、Jira、Slackを置換する移行コストも残る。

AI investigationは根本原因の提案を行うが、誤った仮説を人間が検証する運用と、顧客データを扱う際の信頼・セキュリティが不可欠である。

初期はMonzo由来の実務課題とfounder-led salesで顧客を得て、Slack-native UXと週次shippingで信頼を作った。

Customer storyではEtsy、Buffer、Trainline、Netflixの成果を具体化し、ResponseからOn-call、Status Pages、AI investigationsへcross-sellする。

広いplatform化はARPAを上げる一方、機能過多による導入負荷とのトレードオフを持つ。

主要チャネル: content, customer-stories, product-led-growth, community, sales

カテゴリを広げる前に、最初の顧客が毎週使う狭いworkflowを徹底的に磨くことが重要だ。

incident.ioはResponseから始め、顧客の「pagingも同じ文脈で扱いたい」という要望をOn-callへ反映した。出典

機能数より、対応速度と学習のループを顧客に見せることが再現可能な示唆になる。

日本では、障害対応の属人化だけでなく、開発・CS・情シス・経営間の連絡経路が分断されがちだ。

Slack/Teams起点のincident templateに、社内規程、顧客向けStatus Page、日本語のpostmortemを組み合わせれば導入余地がある。

AI提案は人間の承認を前提にし、監査ログと個人情報の扱いを先に設計したい。