InstacartのAI「Blueberry」が変えるSREの現場とインシデント対応の未来

深夜2時、突然鳴り響くPagerDutyの通知音。エンジニアにとって、これほど心拍数を跳ね上げる音はないだろう。眠い目をこすりながらSlackを開き、ダッシュボードを巡回し、ログを追いかけ、デプロイ履歴を突き合わせる。この「初期調査」という名の泥臭い作業に、我々はこれまでどれほどの時間を浪費してきただろうか。Instacartが開発した「Blueberry」は、まさにこのエンジニアの苦痛を解消するために生まれた、現場直結型のAIエージェントだ。

Blueberryの真価は、単なるチャットボットではない点にある。インシデントが発生すると、即座に約10個のサブエージェントが並列起動し、ログ、メトリクス、サービス所有権データ、そして過去14年分に及ぶインシデント履歴を横断的に分析する。わずか3分以内に、Slackのスレッド上で「根拠に基づいた仮説」を提示するのだ。これは、エンジニアが手作業で情報を集める時間を大幅に短縮し、本来の「解決」というクリエイティブな作業に集中できる環境を整えることを意味している。

特筆すべきは、その精度だ。初期のモデルでは精度が60%台だったものが、14年分のインシデントデータでグラウンディング（根拠付け）を行うことで、90%台後半まで向上したという。これは、AIが「過去の障害の文脈」を理解し、現在の事象と紐付けられるようになったことを示唆している。我々エンジニアが「あの時のあの障害に似ている」と直感的に感じる経験則を、AIがデータとして再現しているのだ。2026年4月には25,000回もの診断パスを実行し、99.9%という驚異的なワークフロー成功率を記録している。これは単なる実験的プロジェクトではなく、すでに大規模な本番環境を支える「インフラ」として機能している証左である。

Blueberryのアーキテクチャを紐解くと、現代のAIエンジニアリングにおける「あるべき姿」が見えてくる。それは、汎用的なLLMに頼り切るのではなく、組織固有の operational knowledge（運用知識）をいかにAIに接続するかという点だ。Instacartは、Model Context Protocol (MCP) を活用し、ツールを認識するエージェント群を構築した。これにより、AIは単にテキストを生成するだけでなく、内部システムから必要な情報を能動的に取得し、状態を保持しながら調査を進めることができる。

以下の表は、Blueberryがインシデント対応において提供する具体的な価値を整理したものだ。

私が特に注目するのは、Blueberryが「自動修正」を行わないという設計思想だ。AIが勝手に本番環境を書き換えることは、往々にして「二次災害」を招く。Blueberryはあくまで「調査の補助」に徹し、最終的な判断と修正は人間が行う。この「Human-in-the-loop」の原則を徹底しているからこそ、現場のエンジニアはAIを信頼し、パートナーとして受け入れることができるのだ。技術的負債をAIで解消しようとする動きは、単なる自動化の追求ではなく、エンジニアの認知負荷をいかに下げるかという「Developer Experience」の最適化そのものである。

Blueberryの登場は、我々エンジニアの役割が「情報の収集者」から「AIが提示した仮説の検証者」へとシフトすることを意味している。しかし、ここで一つの懸念が浮かび上がる。AIが提示する仮説が「もっともらしい嘘（ハルシネーション）」であった場合、我々はそれを即座に見抜くことができるだろうか？AIに依存すればするほど、我々自身の「障害を直感的に嗅ぎ分ける力」が衰えていくのではないかという恐怖を、シニアエンジニアとして抱かざるを得ない。

明日から我々が取るべき対策は明確だ。まず、自社の運用ナレッジを構造化し、AIが参照可能な形式で蓄積すること。そして、AIの出力を鵜呑みにせず、常に「なぜその結論に至ったのか」という根拠を問い続ける姿勢を持つことだ。Blueberryが示したのは、AIは魔法の杖ではなく、あくまで「優れたツール」であるという事実である。我々エンジニアは、AIを使いこなすための「コンテキスト」をいかに設計し、維持し続けるかという、より高度なアーキテクチャ設計能力を求められている。

最後に、読者であるあなたに問いかけたい。あなたのチームが抱える「過去の障害対応の知見」は、AIが学習可能な形で整理されているだろうか？それとも、個人の脳内やSlackの奥底に埋もれたまま、次回の障害発生を待っているのだろうか？AI時代において、真の競争力はモデルの性能ではなく、その組織が持つ「運用データの質と構造」によって決まる。あなたは、AIをただの自動化ツールとして使うのか、それとも自らのエンジニアリング能力を拡張するパートナーとして育て上げるのか。その選択が、数年後のあなたのキャリアを決定づけることになるだろう。