OpenSRE:AIがインシデントを自動調査するオープンソースSREエージェントフレームワーク
OpenSRE:AIがインシデントを自動調査するオープンソースSREエージェントフレームワーク
ひとことでいうと
OpenSRE(オープンエスアールイー)は、本番環境で起きたシステム障害をAIが自動で調べてくれるオープンソースのフレームワークです。GrafanaやDatadog、Kubernetesなど60以上のツールと連携し、散らばったログ・メトリクス・トレース(システムの動作記録)を横断して分析します。そして障害の根本原因を特定したレポートを自動で作成し、SlackやPagerDutyへ送ることができます。さらに「AIエージェントの精度を評価するためのベンチマーク基盤」としても使えるよう、合成インシデントのシミュレーション機能も備えています。Apache 2.0ライセンスで完全公開されており、自社のサーバー上でそのまま動かせます。
こんな人におすすめ
深夜のアラート対応に疲れているSREチーム・インフラ担当者 「また夜中にアラートが来た」という場面で、OpenSREがアラートの受信から調査・Slack通知まで自動でこなします。エンジニアが手作業で調査を始める前に全体像が共有されるため、平均復旧時間(MTTR)の大幅な短縮が見込めます。
AIエージェントの性能を定量的に測りたい研究者・MLエンジニア OpenSREには「合成インシデント(実際のシステム障害をシミュレートしたテストデータ)」が付属しており、根本原因の特定精度・証拠の収集力・誤検知の少なさを数値で評価できます。本番インフラ障害対応に特化したベンチマーク基盤として活用できます。
GrafanaやDatadogなど既存のツールと連携したいプラットフォームエンジニア・DevOps担当者 60以上のインテグレーション(ツール連携)に対応しており、すでに使っている監視環境をほぼそのまま活かせます。Railway・Vercel・AWS EC2・ECSへのデプロイもコマンド1本で行えます。
インストール・使い方
Step 1: インストール
ターミナル(文字を入力してパソコンに命令を送る画面)を開き、以下のコマンドをコピー&ペーストして実行します。このコマンドはインターネットからインストールスクリプトを取得して自動で実行します。
curl -fsSL https://raw.githubusercontent.com/Tracer-Cloud/opensre/main/install.sh | bash
macOSを使っている場合は、パッケージ管理ツールのHomebrewからインストールする方法もあります。
brew install Tracer-Cloud/opensre/opensre
どちらの方法でも opensre コマンドが使えるようになります。
Step 2: 初期設定(オンボーディング)
次のコマンドを実行すると、画面の質問に答えていく対話形式で、LLM(大規模言語モデル、いわゆるAI)プロバイダーや各種ツールとの接続設定ができます。
opensre onboard
Anthropic・OpenAI・Ollama・Google Gemini・OpenRouter・NVIDIA NIM・Bedrockなど主要なAIサービスに対応しています。APIキー(サービスを使うための合言葉のような文字列)を画面の指示にしたがって入力するだけで設定が完了します。
Step 3: インシデント調査を実行
アラートの情報をJSON形式(データを整理して保存する書き方)のファイルで用意し、以下のコマンドで調査を開始します。リポジトリ(ソースコードの置き場)にはKubernetesとDatadogのサンプルアラートが同梱されているので、外部サービスに接続しなくてもすぐ試せます。
opensre investigate -i tests/e2e/kubernetes/fixtures/datadog_k8s_alert.json
実行すると、根本原因の推定・根拠となったメトリクス・推奨アクションを含む構造化レポートが出力されます。--interactive フラグを付けると、調査中に追加の質問や指示ができるインタラクティブモードになります。
Step 4: ソースコードからビルドしたい場合(開発者向け)
リポジトリをクローン(手元にコピー)して自分でビルドする方法もあります。VS Code用のdevcontainer(開発環境をまるごと用意する仕組み)も同梱されており、Python 3.13環境がすぐに立ち上がります。
git clone https://github.com/Tracer-Cloud/opensre
cd opensre
make install
opensre onboard
動かしてみた
実行環境としてPython 3.12が正常に動作することを確認しました。リポジトリの docs/ フォルダには、Grafana・Datadog・Sentry・Slack・PostgreSQL・MongoDBなど主要ツールのインテグレーションドキュメント(.mdx ファイル)が一通りそろっており、各ツールとの接続方法をすぐに参照できます。Dockerfile も用意されており、Dockerコンテナ(アプリケーションの実行環境をひとまとめにした箱)での実行もサポートされています。
Railwayなどのクラウドサービスへのデプロイは opensre deploy railway コマンド1本で完了します。デプロイ後は opensre remote ops コマンドを使い、ログの確認や再起動などの運用操作をリモートから実行できることも確認しています。opensre remote ops logs --follow を使えばリアルタイムでログをストリーミング表示できます。
ブラウザで試す
OpenSREのブラウザデモでは、インストールなしでインシデント調査ワークフローのシミュレーションが体験できます。サンプルのKubernetesアラートJSONを入力として使い、調査ステップがどのように進むか、最終的にどんなレポートが生成されるかをインタラクティブに確認できます。LLMのAPIキーや外部サービスへの接続は一切不要なので、インストール前に全体の流れをつかむのに最適です。
実践のコツ
実際に動かしはじめるときに役立つポイントをまとめます。
- まずサンプルアラートで試す: 同梱の
tests/e2e/kubernetes/fixtures/datadog_k8s_alert.jsonを使えば、GrafanaやDatadogがなくても調査の流れをすぐに体験できます。最初の一歩として最適です。 - LLMはAnthropicかOpenAIが手軽:
opensre onboardでAPIキーを入力するだけで設定完了です。ローカル環境でコストをかけずに試したい場合はOllamaも選べます。 --interactiveフラグで深掘り調査:opensre investigateに--interactiveを付けると、調査中に追加の質問や方向転換ができます。気になる箇所を対話形式で掘り下げるのに役立ちます。- Railwayへのデプロイで常時稼働化:
opensre deploy railwayを実行するとクラウドに常駐エージェントが立ち上がります。opensre remote ops logs --followでリアルタイムにログを確認できます。 - 合成インシデントで精度を測る:
tests/synthetic/配下のテストデータを使い、自社カスタマイズしたエージェントの根本原因特定精度を採点機能で客観的に測定できます。改善サイクルを回すのに役立ちます。
活用アイデア
-
Slackへの自動インシデントレポート投稿: アラートが届いたらOpenSREが自動調査し、根本原因と推奨アクションをSlackチャンネルに投稿します。オンコールエンジニアが手作業で調査を始める前に全体像が共有されるため、対応時間を大きく短縮できます。
-
AIエージェントのベンチマーク構築: 合成インシデントスイートと採点機能(根本原因の精度・必要な証拠の収集率・誤検知の検出)を使い、自社開発のAIエージェントを定量評価・改善するための研究基盤として利用できます。
-
Railway/Vercelに常時稼働SREボットをデプロイ:
opensre deploy railwayでクラウドに24時間365日動くSREエージェントを立ち上げます。PostgreSQLとRedisをバックエンドとして組み合わせることで、本番品質の運用が実現できます。 -
既存の監視スタックへのAI調査機能の追加: すでにGrafana LokiやDatadogを使っているチームは、設定をほとんど変えずにOpenSREを追加できます。60以上のインテグレーションが揃っており、既存ツールを活かしたままAI自動調査の恩恵を受けられます。
-
MLチームによるインフラ障害対応モデルの研究: SWE-benchがコーディングエージェントの標準ベンチマークになったように、OpenSREは本番インフラ障害対応に特化したAI研究の基盤を目指しています。独自の合成インシデントを作成してモデルの性能を評価する用途にも活用できます。
用語とポイント解説
SRE(Site Reliability Engineering) かんたんに言うと、「システムを安定させるために、ソフトウェアエンジニアリングの手法で運用する考え方」です。Googleが提唱したアプローチで、障害を減らし、回復を速くすることを目標とします。「インフラ運用もコードで管理する」という姿勢が特徴です。
RCA(Root Cause Analysis) かんたんに言うと、「障害の本当の原因を掘り下げて突き止めるプロセス」です。表面的な症状(サーバーが落ちた)だけでなく、背後にある原因(メモリリークが連続発生していた)まで追います。OpenSREが最終的に出力するレポートの核心部分がこのRCAです。
MTTR(Mean Time To Recovery) かんたんに言うと、「障害が起きてから直るまでの平均時間」です。この数値が短いほど運用が優れているとされます。OpenSREはアラート受信から根本原因の特定・通知までを自動化することで、MTTRの短縮に直接貢献します。
オブザーバビリティ(Observability) かんたんに言うと、「システムの内部で何が起きているかを外から見える状態にすること」です。ログ・メトリクス・トレースの3種類のデータを組み合わせて、問題の原因を素早く特定できるようにします。GrafanaやDatadogはオブザーバビリティを実現するための代表的なツールです。
MCP(Model Context Protocol) かんたんに言うと、「AIモデルと外部ツールをつなぐための共通規格」です。OpenSREはGitHub MCPなどに対応しており、AIエージェントがGitHubのコードやIssueを参照しながら調査を進めることができます。
LangGraph かんたんに言うと、「AIエージェントが複数のステップを経て判断・行動できるようにするフレームワーク」です。LangChainが開発しており、OpenSREのコンテナ化ランタイムの中核として組み込まれています。PostgreSQLとRedisと連携して動作します。
インテグレーション(Integration) かんたんに言うと、「複数のツールやシステムを連携させる仕組み」のことです。OpenSREはGrafana・Datadog・Slack・PagerDutyなど60以上のサービスと接続でき、既存の監視環境に追加する形でスムーズに導入できます。
オンコール(On-Call) かんたんに言うと、「システム障害に備えて当番制で待機するエンジニアの体制」のことです。夜中や休日でもアラートが来たら対応しなければならず、担当者の負担が大きいとされています。OpenSREはこのオンコール対応の自動化を主要な目的の一つとしています。
アラート(Alert) かんたんに言うと、「システムが異常を検知したときに出す通知」のことです。CPU使用率の急上昇やAPIエラー率の増加など、あらかじめ設定した閾値を超えると発火します。OpenSREはこのアラートを受け取ることをきっかけに自動調査を開始します。
OpenSREは、深夜のオンコール対応の負担軽減や、AIエージェントの本番インフラ対応能力の評価・改善など、SREチームからAI研究者まで幅広い立場で活用できるフレームワークです。ぜひSlackへの自動インシデントレポート投稿や、Railwayへの常時稼働SREボットのデプロイなどに活用してみてはいかがでしょうか。