AI SREエージェントにOpenSREが選ばれる理由とHolmesGPTとの違い

夜中の 3 時にアラートが飛んでくるたびに、同じコマンドを叩いて、同じダッシュボードを眺めて、同じログを掘る——そんなサイクルに疲れていませんか。

AI SRE エージェントは、まさにその繰り返し作業を自動化するために生まれた技術です。2024 年から 2025 年にかけて、この領域のオープンソースプロジェクトが一気に増えました。GitHub のスター数を競うように、複数のツールが「本番インシデントを AI に任せる」を掲げています。

その中でも注目を集めているのが OpenSRE（Tracer-Cloud が開発）です。スター数 2,963（2026年4月時点）、Apache 2.0 ライセンスの Python 製フレームワークで、デュアル LLM アーキテクチャと 60 以上のインテグレーションを武器に急速に支持を集めています。

しかし同じカテゴリには HolmesGPT（CNCF Sandbox プロジェクト）という強力な競合もあります。この 2 つはどう違うのか、どちらを選ぶべきなのか——本記事では OpenSRE の技術的な特徴を解説しながら、初見エンジニアが採用判断を下せるだけの情報を整理します。

なお本記事はドキュメントベースの解説です。実際にインストールして動作確認した体験談ではなく、公式 README・AGENTS.md・SETUP.md および公式ドキュメントに基づいた情報を提供しています。

執筆者

秋霜堂株式会社 代表 石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

OpenSRE とは — AI が本番インシデントを自動調査する OSS

OpenSRE は、AI SRE エージェントを自前インフラ上で構築・運用するためのオープンソースフレームワークです。

プロジェクトのキャッチコピーは「Build your own AI SRE agents. The open source toolkit for the AI era」。自前のインフラ上で AI がアラートを受け取り、ログ・メトリクス・トレースを横断的に参照しながら根本原因を特定し、Slack や PagerDuty にレポートを投稿する——その一連の流れを OSS で実現します。

開発元の Tracer-Cloud はスタートアップ企業で、プロジェクト全体をオープンソースとして公開・維持しています。

リポジトリの基本情報

Public Alpha という点は後述する導入検討時の重要な判断材料になります。

OpenSRE のアーキテクチャ — デュアル LLM と LangGraph の設計

OpenSRE の最大の技術的特徴は「デュアル LLM 戦略」と「LangGraph 基盤のパイプライン」の組み合わせです。AGENTS.md に詳細が記載されています。

デュアル LLM 戦略とコスト最適化

OpenSRE は 2 種類の LLM を用途別に使い分けます:

この設計によりコストを単一大型モデル使用時と比較して約 90% 削減できると公式ドキュメントは述べています（出典: OpenSRE: AI-Powered SRE Framework）。

「全部 GPT-4o でいいじゃないか」と思うかもしれませんが、インシデント調査では「どのツールを呼ぶか」というルーティング判断が大量に発生します。そこに高コストモデルを使い続けると費用が跳ね上がります。軽量モデルで判断し、複雑な推論が必要な場面でのみ重量モデルを使う設計は、実際のコスト管理の観点から合理的です。

LangGraph パイプラインの 6 ステップ

アラートが発火してから最終レポートが出るまでの処理は 6 ステップで構成されます:

1. 認証注入 — LLM・インテグレーションの認証情報を設定
2. アラート抽出・ノイズフィルタリング — 受信したアラートから調査対象を特定
3. インテグレーション解決 — 必要なデータソース（Datadog, CloudWatch など）を解決
4. アクション計画・調査（最大 4 反復ループ）— investigate ノードが実際のツールコールを実行
5. 証拠検証付き診断 — diagnose ノードが収集した証拠から根本原因を決定
6. ファイナルレポート公開 — Slack / PagerDuty にサマリを投稿

「最大 4 反復ループ」という設計がポイントです。1 回の調査で情報が足りなければ、追加ツールコールを行って証拠を補強してから診断に進みます。

ノード設計とツール自動検出

AGENTS.md によれば、ノードは単一責任の原則（SRP）に従って設計されており、app/nodes/ 配下に分離されています。ツールは app/tools/ モジュールから自動検出され、デコレータベースの軽量なファンクションツールや BaseTool サブクラスによるリッチな実装に対応しています。

RL 訓練環境としての OpenSRE

公式ドキュメントでは OpenSRE を「SWE-bench for SRE」と位置づけています。スコア付き合成 RCA（根本原因分析）テストスイートと、Kubernetes・AWS・その他クラウド環境にまたがるエンドツーエンドテストを通じて、AI SRE エージェントを強化学習させる環境として機能します。

これは「ツールを使うだけ」ではなく「AI SRE エージェントを継続的に改善する基盤」として設計されているということです。

60+ インテグレーション — どのスタックに接続できるか

OpenSRE が掲げる「60+ ツールとの連携」は、AI SRE エージェントとしての実用性を担保する重要な要素です。

オブザーバビリティ系

インフラ・インシデント管理系

AI プロバイダ

既存の観測基盤に Datadog や Grafana を使っている場合、OpenSRE を組み込む際に大きな変更なく接続できる可能性が高いです。Kubernetes や AWS との統合も含まれているため、クラウドネイティブな環境での採用には向いています。

OpenSRE vs HolmesGPT — 選定時の判断軸

AI SRE エージェントを検討する際、OpenSRE と最も比較される存在が HolmesGPT（HolmesGPT/holmesgpt）です。

機能・アーキテクチャの比較

ユースケース別の使い分け基準

OpenSRE が向いているケース:

• AI SRE エージェントをカスタマイズしながら自前インフラ上で育てたい
• LangGraph ベースのエージェント基盤を自社で発展させたい
• MCP サーバー経由で他エージェント（Claude Desktop など）と統合したい
• AI コストを最適化しながら AI SRE を導入したい

HolmesGPT が向いているケース:

• CNCF のエコシステムや企業サポートが重要な採用基準になる
• 24/7 でバックグラウンド監視する Operator Mode が必要
• Microsoft のサポートや CNCF Sandbox の安定性を重視する

Aurora など他の選択肢との位置づけ

3 番目の選択肢として Aurora（Arvo-AI/aurora）があります。スター数は 148 と成長途中ですが、Next.js 製のダッシュボード UI・Memgraph によるインフラ依存グラフ・PR 自動生成など、インシデント対応の可視化と改善自動化まで踏み込んだ機能を持ちます。「AI 調査 + UI + 改善まで一気通貫で欲しい」という場合の選択肢です。

導入前に把握すべき注意点（Public Alpha の現状）

OpenSRE を本番環境に採用する前に、Public Alpha であることの意味を正確に理解しておくことが重要です。

Public Alpha の現状

公式 README には「Currently in public alpha with usable core workflows, though APIs and integrations remain in active development」と明記されています。コアのワークフローは利用可能ですが、API とインテグレーションは変更の可能性があります。

つまり:

• 早期利用者としてフィードバックを出しながら使える
• 本番クリティカルなインシデント対応のプライマリシステムとして依存するのは慎重に
• バージョンアップで API が変わる可能性がある

導入前提条件

SETUP.md によれば、基本的な実行環境は以下の通りです:

• Python 3.11 以上（CI 環境は Python 3.13）
• Git
• Make（macOS/Linux は標準装備）

LangGraph Cloud を使う場合は Postgres と Redis のバッキングサービスが必要です。

コントリビュートや開発環境としては VS Code Dev Container が用意されており、Docker Desktop または互換ランタイムがあればすぐに環境を構築できます。

まとめ — OpenSRE を採用すべきエンジニア・チームとは

OpenSRE は「AI SRE エージェントの研究開発基盤」という位置づけが現時点では最も正確です。

採用を前向きに検討できるケース:

• 既存スタック（Datadog, Grafana, Kubernetes, AWS など）が OpenSRE のインテグレーション一覧に含まれている
• AI エージェントのカスタマイズ・自社仕様への適応を重視している
• LangGraph や Python ベースの技術スタックに知見がある
• Public Alpha のリスクを理解した上で、early adopter として活用できる

慎重になるべきケース:

• CNCF 認定や大企業のサポートがないと社内承認が取れない → HolmesGPT を検討
• 本番インシデントのプライマリシステムとして即座に依存したい → 安定性が GA になるまで待つか HolmesGPT を検討
• フロントエンドの管理 UI や PR 自動生成まで欲しい → Aurora を検討

OpenSRE のコミュニティは活発で、2026 年 4 月時点でも日次レベルでコードが更新されています。「今すぐ本番に使う」というより「将来の導入を見据えて検証環境で試しながら追う」という姿勢が、現段階での現実的なスタンスです。

リポジトリ本体（Tracer-Cloud/opensre）での Issue・PR 参加や、コントリビュートガイドを参照しながらプロジェクトに関わることが、最速でこのエコシステムの動向を把握する方法でもあります。