はじめに
インシデント調査を LLM に任せる OSS が増えていますが、入れた直後に困るのは「どこまで自分の環境を見に行くのか」が分からない点です。対象読者は、AI SRE エージェントを自前サーバーやコンテナで動かしたい開発者・SRE の方です。
筆者は 2026-07-26 に OpenSRE v0.1 を Linux サーバーへ入れ、まだ何も設定していない状態で opensre health を実行しました。58 件の連携がチェックされ、57 件は「未設定」と表示されました。ところが残る 1 件だけが「失敗」として報告されました。設定していないものが、なぜ「未設定」ではなく「失敗」になったのでしょうか。
OpenSRE は何をするツールか
OpenSRE は Tracer が公開している AI SRE エージェントのツールキットで、アラートを受け取って根本原因分析（RCA）を走らせることを主目的にしています。README は「Connect the 60+ tools you already run, define your own workflows, and investigate incidents on your own infrastructure」と述べており、自前インフラで動かす前提の設計です。
エージェントの土台は、クローンした依存関係を見るかぎり LangChain 系のフレームワークではなく、anthropic 0.117.0 と openai 2.45.0、それらを束ねる litellm 1.90.6 の組み合わせでした。プロバイダ抽象を litellm に任せることで、Anthropic / OpenAI / Ollama / Gemini / Bedrock などを同じ経路で扱う構成になっています。
| 項目 | 実測値・確認値 |
|---|---|
| ライセンス | Apache-2.0 |
| GitHub スター | 9.2k（fork 1.3k） |
| バージョン | 0.1（Public Alpha） |
| 主要言語 | Python（requires-python = ">=3.12"） |
| 連携先の公称 | 60+ ツール |
スター数とライセンスは公式リポジトリ Tracer-Cloud/opensre の表示（2026-07-26 時点）です。バージョンと Python 要件は、クローンした pyproject.toml から直接読み取りました。
インストールは2経路あり、片方は外部 API に依存する
README が最初に案内するのはワンライナーのインストーラです。筆者の環境ではこれが最初のステップで止まりました。
$ curl -fsSL https://install.opensre.com -o opensre-install.sh
$ bash opensre-install.sh
[1/6] Fetching latest main build metadata
curl: (22) The requested URL returned error: 403
Error: Failed to query main build metadata from GitHub.
スクリプトを読むと、588 行目付近で https://api.github.com/repos/${REPO}/releases/... を叩いてビルドのメタデータを取得しています。つまり配布物そのものより先に GitHub REST API への到達性が必要です。筆者の検証環境は egress プロキシ経由で、GitHub API が 403 になる構成でした。CI コンテナや社内プロキシ配下でも同じ形で止まりえます。
このときはソースからの導入に切り替えます。こちらは GitHub API を使わず、git と uv だけで完結しました。
$ git clone --depth 1 https://github.com/Tracer-Cloud/opensre.git
Cloning into 'opensre'...
Updating files: 100% (4298/4298), done.
real 0m7.530s
$ cd opensre && uv sync --frozen --extra dev
real 0m11.540s
$ uv run opensre version
opensre 0.1
Python 3.12.3
OS linux (x86_64)
注意点は Python のバージョンです。検証機のシステム Python は 3.11.15 でしたが、pyproject.toml の requires-python = ">=3.12" により、そのままでは入りません。uv は不足分の Python 3.12.3 を自動で調達して仮想環境を作るため、ここが実質的に uv 前提の理由になっています。依存は 184 パッケージ、できあがった .venv は 835MB でした。軽量ツールではない点は最初に見積もっておくとよいでしょう。
起動から調査までの流れ
CLI は引数なしで起動すると対話シェルに入りますが、これは stdin と stdout が TTY のときだけです。非TTY のサーバーやパイプ越しでは、ランディングページを表示して終了コード 0 で戻ります。
この分岐は自動化に直結します。ジョブから opensre を素で叩くと、対話シェルではなくランディングページが出て正常終了してしまうため、サブコマンドの明示が必須です。
なお、そのランディングページの1行目は 🚧 OpenSRE is in Public Beta — features may change. でした。README のステータスバッジは status: public alpha を掲げているため、CLI と README で成熟度の表記が食い違っています。導入判断で「アルファかベータか」を根拠にするなら、どちらの表記を見ているかを揃えておくとよいでしょう。
doctor は警告を出しても終了コード 0 を返す
環境診断は opensre doctor です。何も設定していない状態では 5 項目のうち 2 項目が成功、3 項目が警告になりました。
$ uv run opensre doctor
✓ python Python 3.12.3
⚠ env_file .env not found
⚠ llm_provider provider=anthropic, auth missing (ANTHROPIC_API_KEY is not configured.)
⚠ integrations /root/.opensre/integrations.json not found — run 'opensre integrations setup'
✓ version 0.1 (editable install + uv run; skipped comparing to latest main build)
3 warnings — fix and rerun opensre doctor
$ echo $?
0
3 件の警告が出ていても終了コードは 0 でした。セットアップの検証を CI に置く場合、opensre doctor の exit code だけを見ると未設定を見逃します。機械判定するなら --json で構造化出力を取り、status を自前で評価するほうが安全です。
$ uv run opensre --json doctor
[
{
"check": "python",
"status": "ok",
"detail": "Python 3.12.3"
},
{
"check": "llm_provider",
"status": "warn",
"detail": "provider=anthropic, auth missing (ANTHROPIC_API_KEY is not configured.)"
}
]
health は環境変数の資格情報を拾って実 API を叩く
冒頭の疑問に戻ります。opensre health を JSON で取得すると、チェック対象は 58 件、内訳は passed 0 / missing 57 / failed 1 でした。
$ uv run opensre --json health | head -12
{
"environment": "development",
"integration_store": "/root/.opensre/integrations.json",
"summary": {
"passed": 0,
"missing": 57,
"failed": 1,
"other": 0
},
failed だった 1 件を抜き出すと aws でした。
$ uv run opensre --json health | python3 -c "
import sys,json
for r in json.load(sys.stdin)['results']:
if r['status'] != 'missing': print(json.dumps(r))
"
{"service": "aws", "source": "local env", "status": "failed",
"detail": "AWS STS check failed: An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid."}
source が local env になっている点が答えでした。OpenSRE は ~/.opensre/integrations.json に何も書かれていなくても、シェルにある環境変数を連携の資格情報として採用します。筆者の環境には Cloudflare R2 を S3 互換で扱うために AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY が入っていました。OpenSRE はそれを AWS の資格情報とみなし、STS の GetCallerIdentity を実際に呼び、R2 のキーでは通らないため InvalidClientTokenId で失敗した、という流れです。
ここから読み取れる挙動は2つあります。1つは、health が到達性チェックとして 実際の外部 API 呼び出しを行う こと。もう1つは、その対象が 明示設定ではなく周囲の環境変数から決まりうる ことです。共有ランナーや別用途の資格情報が載っている環境では、意図しない相手にリクエストが飛ぶ可能性があります。逆に言えば、疎通確認としては本物なので、設定済みの連携に対しては信頼できる結果が返ります。
なお investigate は資格情報が無ければ即座に落ちます。こちらは終了コード 1 が返るため、doctor とは対照的に自動化しやすい設計です。
$ uv run opensre investigate --input-json '{"title":"High 5xx on checkout","severity":"critical","service":"checkout-api"}'
✗ OpenSREError
LLM provider 'anthropic' credentials are missing: ANTHROPIC_API_KEY is not configured.
tools/investigation/session_runner.py:58 in check_llm_settings
Run `opensre auth verify anthropic` or `opensre auth login anthropic` before starting an investigation.
$ echo $?
1
アラートの入力形式に迷う場合は雛形が出せます。opensre investigate --print-template generic で alert_name や commonAnnotations を含む JSON が表示され、Datadog / Grafana / Honeycomb / Coralogix / Splunk 向けの雛形も選べました。
既定の推論モデルは Opus 4.7 のままだった
非TTY 起動時のランディングページに表示されるモデル名は claude-opus-4-7 でした。リポジトリを検索すると、config/config.py の 121 行目に ANTHROPIC_REASONING_MODEL = "claude-opus-4-7" と定義されています。検証に使ったクローンの HEAD は 6ece2fc（コミット日 2026-07-25）です。
公式チェンジログによると、Claude Code は 2026-07-24 リリースの v2.1.219 で「Added Claude Opus 5 (claude-opus-5), now the default Opus model」と記載しており、Opus 5 世代が既定になっています。OpenSRE 側の既定値はまだ追随していない状態でした。モデル指定は opensre config set や /model set で変更できるため、導入時に既定値を確認して明示指定しておくと、想定外の世代のモデルで課金が続く事態を避けられます。
著者視点の発見ポイント
-
「未設定」と「失敗」の差が、そのツールの実装思想を露出させます。 筆者が最初に驚いたのは failed の存在そのものではなく、設定した記憶がない連携が
source: "local env"として現れたことでした。連携の登録簿を空にしていても、シェルの環境変数が実質的な設定ファイルとして機能します。ローカルでは便利ですが、CI ランナーのように無関係な資格情報が同居する場所では、healthの実行前に環境変数の棚卸しをしておくべきだと感じました。 -
exit code の設計がサブコマンドごとに違います。
doctorは警告 3 件でも 0、investigateは資格情報不足で 1 でした。「診断は情報提供、実行は失敗させる」という切り分けは筋が通っていますが、セットアップ検証を CI に載せるなら--jsonのstatusを読む前提で組む必要があります。exit code だけを信じた自動化は、未設定のまま緑になります。 -
インストール経路が2つあることは、隔離環境ではむしろ利点でした。 ワンライナーは GitHub API に依存するため、外向き通信が絞られた環境では最初のステップで止まります。一方で
git cloneとuv syncは 20 秒弱で完了しました。Public Alpha の段階でソース導入が実用的に整備されている点は、検証環境を作りやすい設計だと評価しています。 - 835MB という重さは事前に見積もる価値があります。 184 パッケージには kubernetes クライアントや fastapi、uvicorn まで含まれます。RCA エージェント単体を試すつもりでも、ゲートウェイやスケジューラを含む一式が入る構成です。使い捨てコンテナで試すなら、イメージサイズへの影響を先に確認しておくと安全です。
おわりに
OpenSRE v0.1 は、インストールから診断までを 20 秒程度で通せる完成度がありました。同時に、health が環境変数を拾って実 API を叩く挙動と、doctor が警告時も 0 を返す挙動は、自動化に組み込む前に把握しておきたい性質です。導入時はまず --json 付きで doctor と health を実行し、意図しない source: "local env" が出ていないかを確認するところから始めるとよいでしょう。