OpenSREを触ってみた——SREの「夜中の呼び出し」をAIに任せるOSSの話
はじめに
本番障害対応、みなさんどのように運用されていますか？
筆者のチームでは、アラートが飛んできた後、Slackに「見てます」と書き込み、Grafanaを開き、ログを調査して原因を特定する、という流れを深夜に行うことがあります。エラーの文脈を把握するだけで30分かかることも珍しくありません。
こうした「初期調査フェーズ」は実はかなりパターン化されており、ログ確認、メトリクス分析、変更履歴の確認、既知事例との照合など、毎回似た作業を繰り返しています。ここに人間が常に介在する必要があるのか、という疑問を持っていました。
この記事では、そうした課題を解決する可能性を持つOSS「OpenSRE」を紹介します。この記事を読むことで、OpenSREの概要と実際にできること、導入の流れを理解できるようになります。
OpenSREとは
OpenSREは、本番インシデントの初期調査をAIエージェントに任せるためのOSSフレームワークです。
アラートのJSONを入力として渡すと、エージェントが自動的にログ収集、メトリクス分析、根本原因の仮説生成を行い、最終的にレポートとして返してくれます。設定次第では自動修復まで実行可能です。
プロジェクトのREADMEには「SWE-bench equivalent for production incidents」と記載されています。これは、コーディングタスクの評価基準であるSWE-benchに対して、インシデント対応を評価・訓練可能な基盤を目指していることを意味します。
単なる自動化ツールではなく、SRE領域におけるAIエージェントの研究・評価基盤として設計されている点が特徴です。
実際にできること
OpenSREの調査ワークフローは以下のようになっています。
- アラート受信（Alertmanager、PagerDutyなど）
- 関連ログ・メトリクス・トレースの自動収集
- システム間の異常相関分析
- 根本原因の特定と構造化レポート生成
- Slack / PagerDutyへの通知
- （オプション）自動修復の実行
また、既存のランブックを読み込ませることができるため、「このアラートが来たらこの手順で確認する」といった運用知識をそのまま活用できます。
豊富なインテグレーション
OpenSREは60以上のサービスと統合可能で、既存の観測基盤にそのまま組み込める可能性が高いです。
可観測性ツール
- Grafana（Loki / Mimir / Tempo）
- Datadog
- Honeycomb
- CloudWatch
- Sentry
インフラ
- Kubernetes
- AWS / GCP / Azure
通知
- Slack
- PagerDuty
- Jira
データベース
- MongoDB
- ClickHouse
さらに、対応LLMも柔軟です。
- Anthropic Claude
- OpenAI
- Gemini
- Ollama
特定のプロバイダーにロックインされない設計は、実運用上の大きなメリットです。
インストールと起動
以下の手順で簡単に試すことができます。
# macOS
brew install Tracer-Cloud/opensre/opensre
# Linux / curl
curl -fsSL https://raw.githubusercontent.com/Tracer-Cloud/opensre/main/install.sh | bash
# 初期設定
opensre onboard
# 調査実行
opensre investigate -i alert_fixture.json
初期設定では、接続するLLMや観測基盤を指定します。ローカル環境で試す場合はOllamaを利用することで、閉じた環境でも動作させることが可能です。
本番運用ではPostgreSQLとRedisが必要です。Railwayのワンクリックデプロイも用意されており、検証用途には便利です。
アーキテクチャ
OpenSREは内部的にLangGraphを利用して構築されています。
LangGraphは、エージェントの処理をグラフ構造として定義できるフレームワークで、各処理ステップをノードとして分離できるのが特徴です。
OpenSREでは以下のようなステップがノードとして定義されています。
- 証拠収集
- 相関分析
- 仮説生成
- レポート作成
この構造により、どのステップでどのような判断が行われたかをトレース可能になっています。
また、意図的に障害を発生させた「合成インシデント環境」を用いることで、エージェントの挙動を評価・スコアリングすることも可能です。
気になる点
セキュリティ
ログデータはデフォルトでローカルに保存され、外部には送信されない設計になっています。また、LLMへの入力も構造化されており監査可能です。
ただし、ログをLLMに渡す以上、機密情報の取り扱いについては慎重に設計する必要があります。
自動修復の範囲
自動修復機能は強力ですが、どこまで許可するかの設計が重要です。まずは読み取り専用で調査のみに限定する運用から始めるのが安全です。
合成インシデントの品質
評価基盤として利用する場合、合成インシデントのリアリティが重要になります。この点はまだ発展途上であり、今後の改善に期待したいところです。
所感
SRE領域におけるAIエージェント活用は、コーディングエージェントほど注目されていませんが、実務へのインパクトは非常に大きいと感じています。
特に、深夜の初動対応を自動化できれば、エンジニアの負担は大きく軽減されます。
現時点では完全自動化には至っていませんが、「証拠収集」と「仮説生成」を担い、人間の意思決定を支援する役割としては十分実用的です。
GitHubではスター数約2.8k、フォーク305と活発に開発が進んでおり、good first issueも用意されています。興味がある方はコントリビュートしやすいプロジェクトです。
まとめ
OpenSREは、SRE業務の中でも特に負荷の高い「初期調査」をAIに任せるという新しいアプローチを提供するOSSです。
運用負荷の軽減だけでなく、インシデント対応の標準化やナレッジの活用という観点でも大きな可能性があります。
今後の進化に注目しつつ、小さく試してみる価値は十分にあると感じました。