HolmesGPT を導入すべきか: 調査ループとツールセットで読む SRE エージェント
SRE Agent - CNCF Sandbox Project
ひと目でわかる
- これは何？
- CNCF サンドボックスの SRE エージェント HolmesGPT について、agentic loop とツールセットという実際の仕組みから、導入判断で確認すべき点と向かないケースまでを整理する。
- 誰に向いている？
- 採用を検討すべきなのは、すでに Prometheus や Kubernetes、Datadog などの観測基盤を持ち、インシデント調査の初動を自動化したい SRE チームだ。観測データが整っていない組織や、調査結果を人手で検証する余力のない小規模チームには向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
インシデント調査の初動を誰が始めるかという問題
HolmesGPT が解くのは、障害が起きたときに「どのデータソースをどの順番で見るか」を人間が組み立てている時間の問題である。README はこれを、Kubernetes、VM、クラウド、データベース、SaaS をまたいで根本原因を調査するオープンソースの AI エージェントと説明している。想定読者は、アラートを受け取ったあとに Prometheus のメトリクス、Kubernetes のイベント、Datadog のログを順に開いて回るような運用をしている SRE である。Kubernetes は必須ではないと明記されており、VM やベアメタル、コンテナ上でも動くとされている点は、Kubernetes 前提のツールが多い中では対象範囲が広い。
agentic loop が複数の観測データを横断する仕組み
HolmesGPT の中核は agentic loop と呼ばれる反復である。README は、複数のソースからライブの観測データを問い合わせて根本原因を特定する、とだけ書いており、ループの内部アルゴリズムまでは公開していない。読み取れるのは、データソースが toolset という単位で組み込まれ、エージェントがそれらを呼び出しながら調査を進めるという構造である。組み込みの toolset には Prometheus、Grafana、Datadog、Kubernetes のほか、AWS、Azure、GCP、ArgoCD、Crossplane、Elasticsearch/OpenSearch、Coralogix、Docker、GitHub、GitLab、Confluence、Jira 系が並ぶ。REST API 経由で独自の toolset を追加できるとされているため、一覧にない社内システムも接続対象にできる。
巨大な観測データをコンテキストに入れないための設計
機能一覧で目を引くのは、ペタバイト規模のデータへの言及である。これは保存量の話ではなく、クエリ結果をそのまま LLM のコンテキストへ流し込まないための仕組みを指す。README はサーバーサイドフィルタリング、JSON ツリーの走査、ツール出力の変換を挙げ、大きなペイロードをコンテキストウィンドウの外に留めると説明している。加えてツール単位のメモリ上限、大きな結果のディスクへのストリーミング、出力バジェットの自動調整によって OOM キルを防ぐとしている。観測基盤のクエリは数万行を返すことが珍しくないため、この層の作り込みは実運用での成否を分ける。ただし具体的な上限値やバジェットの計算方法は README からは分からず、実測しないと挙動は判断できない。
インストールと設定で実際に触るもの
README の Installation リンクと公式ドキュメントが導入の入口になる。設定の実体は、どの LLM プロバイダを使うかと、どの toolset を有効にするかの2点である。プロバイダは OpenAI、Anthropic、Azure、Bedrock、Gemini などから選べると記載されている。toolset は個別のドキュメントページが用意されており、たとえば GitHub 連携は github-mcp、Atlassian は atlassian-rovo-mcp、AWS は aws、Azure は azure-mcp という名前で参照されている。MCP 版と非 MCP 版が併存する連携（Confluence など）があるため、どちらのページを見ているかを意識しないと設定キーを取り違える。アラート連携は双方向で、AlertManager、PagerDuty、OpsGenie、Jira からアラートを取得し、調査結果を書き戻せるとされている。
Operator モードが変える運用の前提
Operator モードは、人間が異常に気づいて調査を起動する流れを不要にする試みである。README によれば、HolmesGPT がバックグラウンドで 24 時間動き続け、顧客が気づく前に問題を検出して Slack に通知する。GitHub 連携を有効にすると、検出した問題を修正する PR を開くところまで行うとされている。Operator 自体は Kubernetes 上で動くが、ヘルスチェックのクエリ先は VM、クラウド、データベース、SaaS など Holmes が接続している任意のデータソースでよい。用途として、デプロイ検証（新バージョンが健全かを確認する）と、スケジュール実行のヘルスチェック（継続的に監視してリグレッションを拾う）の2つが示されている。ここは導入効果が大きい一方で、常時実行と自動 PR という権限の広い動作を伴う。
向かないケースと、代替となるアプローチ
HolmesGPT が力を発揮するのは、調査対象のデータソースがすでに整備されている現場である。逆に、メトリクスもログも散在していて Prometheus のような一元的なクエリ先がない場合、エージェントが呼び出せる toolset が実質的に空になり、LLM の推論だけが残る。この構成では根本原因の特定精度は期待できない。代替としては、Grafana のダッシュボードとアラートルールを人手で整備し、オンコールの手順書に「どのパネルをどの順で見るか」を書き下す運用がある。HolmesGPT が調査の順序決定と横断クエリを自動化するのに対し、この方法は人間が決めた固定の手順をなぞる。柔軟性は落ちるが、LLM のトークン費用もデータ送信も発生せず、結果の再現性は高い。どちらが優れているかではなく、調査手順がまだ言語化できていない段階では後者から始めるほうが安全である。
ライセンスとメンテナンスの見取り図
ライセンスは Apache-2.0 で、特許許諾条項を含む寛容な条件である。CNCF サンドボックスプロジェクトであり、Robusta.Dev が作成し、Microsoft が主要な貢献をしていると README は述べている。リリースは 0.40.0、0.41.0-alpha、0.41.0 と短期間で続いており、alpha 版が本版の直前に切られていることから、開発速度は速いと推測できる。そのぶん、toolset の設定方法やドキュメントの構成が変わる可能性を前提に置いたほうがよい。Apache-2.0 は再配布や改変を許すが、NOTICE の扱いや商標の利用は別途確認が必要で、ここは法務の判断領域である。アップグレード時は、使用中の toolset に対応するドキュメントページをリリースごとに読み直す運用が現実的である。
編集部の結論
採用を検討すべきなのは、すでに Prometheus や Kubernetes、Datadog などの観測基盤を持ち、インシデント調査の初動を自動化したい SRE チームだ。観測データが整っていない組織や、調査結果を人手で検証する余力のない小規模チームには向かない。導入前に確認すべきは、使う LLM プロバイダのデータ送信条件、Operator モードで常時実行するヘルスチェックの対象範囲、そして Apache-2.0 の許諾条件が自社の再配布方針と衝突しないかである。
コミュニティノート