8月7日、InfoQがLeela Kumiliによる記事「Instacart Builds Blueberry, an AI-Powered Assistant to Help On-Call Engineers Investigate Incidents」を公開した。この記事では、Instacartが社内のオンコールエンジニア向けに構築したAIインシデント対応アシスタント「Blueberry」の設計と実績について詳しく紹介されている。
インシデント対応の「最初の3分」を変える
大規模なシステム運用において、インシデント発生直後のエンジニアはまず「状況把握」に時間を取られる。サービスのオーナーは誰か、直近のデプロイは何か、ログやメトリクスは何を示しているか——実際の診断に入る前の「コンテキスト収集」フェーズだ。
Instacartが開発したBlueberryはこの問題に直接アプローチする。アラートが発火すると、Blueberryは約10個のサブエージェントを並列起動し、約3分以内に根本原因の仮説をSlackスレッドに投稿する。エンジニアは既存のコラボレーションチャネルを離れることなく、収集済みのコンテキスト（ログ、デプロイ履歴、関連システム情報）から調査を始められる。
同社CTOのAnirban KunduはBlueberryをエージェント型AIシステムの実践事例として位置づけており、4月単月で約270のSlackチャンネルにまたがる約25,000回の診断パスを処理したと報告している。
/filters:no_upscale()/news/2026/08/instacart-blueberry-sre-ai/en/resources/1instacartslack-1785721385389.jpeg)
BlueberryによるSlackスレッドの自動トリアージ画面（出典: Instacart Blog Post）
精度を90%台後半に引き上げた「14年分の歴史」
汎用LLMをそのまま使うのではなく、組織固有のオペレーショナルナレッジで接地（グラウンディング）している点がアーキテクチャの核心だ。Blueberryのエージェントは以下の内部ソースに接続する。
- インシデント履歴（14年以上分）
- サービスオーナーシップデータ
- ログ・デプロイ情報
- その他のデバッグシグナル
この歴史的インシデントデータによるグラウンディングが、診断精度を90%台後半まで改善した要因としている。一般的な知識だけに頼るモデルでは、自社サービス固有の障害パターンへの対応に限界がある——という現場の知見がそのまま設計に反映されている。
/news/2026/08/instacart-blueberry-sre-ai/en/resources/1Screenshot 2026-08-02 at 4.06.45 PM-1785721385389.png)
ツール対応ハーネス（tool-enabled harness）の構成：プロダクションパス、MCPカタログ、永続化された状態管理、改善フィードバックループ（出典: Instacart Blog Post）
アーキテクチャはMCP（Model Context Protocol）ベースのツールカタログを採用している。MCPはAnthropicが策定しAIエージェントと外部ツール・データソースを接続するための標準プロトコルであり、元記事でもその仕様に基づく実装として紹介されている。エージェントが調査状態を維持しながら接続システムから情報を取得する「ツール対応ハーネス（tool-enabled harness）」と呼ばれる設計を取っており、4月の実績では58,000回以上のMCPツールディスパッチ、ワークフロー成功率99.9%、約60チームプロファイルへの対応が記録されている。
AIは「判断」しない、「情報提供」に徹する設計
重要な設計判断として、Blueberryは自律的に本番環境を変更しない。診断、緩和判断、修復の責任は引き続きエンジニアが担う。AIが仮説と情報を提供し、人間が意思決定する構造だ。
Vice President of EngineeringのSiby Alappattはこう述べている。
Blueberry has proven to be a force multiplier in harnessing AI to help transform on-call and help us quickly troubleshoot and mitigate complex issues in production.
Director of Software EngineeringのAlan Wongは、Blueberryがオンコールエンジニアの「調査の出発点」を変えたと強調している。従来は空の状態から情報収集を始めていたところが、すでに整理されたコンテキストから分析に入れるようになった。
また、インシデント対応中に生まれた知識を将来の調査に活かす「オペレーショナルナレッジの保全」も設計目標に含まれており、チーム固有のコンテキストが蓄積されていく仕組みになっている。
なお、元記事ではBlueberryが利用するベースLLMの具体的な名称や、システム導入にあたっての初期コスト・課題については言及されていない。同様のアーキテクチャを検討する際は、グラウンディング用データの整備コストやエージェント並列実行に伴うレイテンシ管理なども実装上の考慮点となりうる点に留意したい。
Instacartの事例が示すのは、運用系AIの実効性がモデル性能だけで決まるわけではない、という点だ。オペレーショナルコンテキスト、専用ワークフロー、ツール統合、フィードバックループ——その周辺エンジニアリング全体が精度と信頼性を支えている。
詳細はInstacart Builds Blueberry, an AI-Powered Assistant to Help On-Call Engineers Investigate Incidentsを参照していただきたい。
