# AIエージェント 事例 SRE | 4つの形

URL: https://upstreamapi.com/ja/journal/ai-agent-examples-sre
Type: blog
Locale: ja
Published: 2026-07-14
Updated: 2026-07-16

---

> 本番環境で動作するAIエージェント事例とは何か。SRE/Platform Engineerが実際に採用している4つの形態と、各パターンの成功事例・失敗パターンを詳しく解説します。

## AIエージェント 事例 SRE | 4つの形

いま「AI agent examples」を検索すると、チャットボット、営業支援ツール、HR bot...といった何でも屋エージェントばかりが目に入ります。しかしプラットフォームエンジニアが本当に知りたいのは、デプロイメントパイプラインの近くで動作するエージェントは何か、ということです。正直な答えは、マーケティング資料が示唆するより、ずっと限定的で地味です。本番インフラで実装されているAIエージェントは、たった4つの形に分かれます。ロールバックエージェント、トリアージエージェント、診断エージェント、ランブック実行エージェント。その他は全て、言い方がマシなだけのチャットボットです。

これらは公開されているケーススタディ、ベンダー事後検証、そして私たちのSLO制御ロールアウト実装から引き出したものです。完全に自律分散型のものはありません。全て範囲が限定されており、監査可能で、1つの仕事に特化しています。

## 本番環境におけるAIエージェントの定義

メトリクスの異常を検知するダッシュボードはエージェントではありません。p99が閾値を超えたらSlackでping飛ばすボットも、結局はcron jobに化粧直しをしたものに過ぎません。プラットフォームチームにとって重要な区別はこれです。エージェントとは、複数のシステムにまたがるアクション列を計画し、発見した内容に基づいてその計画を適応させ、人間が1ステップずつ確認することなく実行するもの。この定義で見ると、世にある「AI DevOps」ツールの大半は、支援的な段階に留まっています。情報を素早く表出させるだけです。以下の4つのカテゴリーだけが、実際に行動するラインを越えています。

## ロールバックエージェント: 人間が気付く前に自動リバート

これは私たちが構築しているパターンに最も近い形です。エージェントはロールアウト中のSLOバーンレートを監視し、予算が閾値を超えたとき、人間がダッシュボードを開く前にデプロイメントをリバートします。判断の余地はありません。深夜3時のSlackでのやりとり「これリバートするレベル?」もありません。閾値は昼間に、誰も興奮していない状態で決まっています。

最小限のゲートはこのようなコードです。

`type RolloutState = {
  errorBudgetBurn: number; // SLO予算消費率
  windowMinutes: number;
  canaryPercent: number;
};

function shouldAutoRollback(state: RolloutState): boolean {
  const burnRateThreshold = 0.14; // 月次予算の14%を1ウィンドウで消費
  const fastBurn = state.errorBudgetBurn / state.windowMinutes > burnRateThreshold / 60;
  return fastBurn && state.canaryPercent > 0;
}`これが全てです。エージェント部分は、その周辺全体です。可観測性スタックからlive error rateとlatencyを引き出し、事前宣告されたSLOと比較し、デプロイメントAPIでリバートを実行し、何が引き金になったか、何を見たかを説明する構造化ノートをインシデントチャネルに書き込むこと。このパターンは1日約40デプロイを行うシリーズC段階のフィンテック企業で本番稼働しています。バーン検知からリバートまでの中央値は90秒未満です。チーム自体による手動の中央値は、過去6ヶ月の事後検証から測定すると11分でした。

デプロイ頻度が低く、全デプロイを人間がライブで見守っている環境なら、このパターンはスキップしてもよいでしょう。このエージェントは、低頻度では役に立たず、高頻度で力を発揮します。

![Close-up of a monitor showing abstract metric graphs, representing observability data an AI agent correlates during an investigation](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-07/03d611-inline1.webp)

## 根本原因トリアージエージェント: アラートからSlackスレッドまで数分

このカテゴリーが今、最も公開データが豊富です。簡単に売れて、簡単に測定できるからです。AWSのDevOps Agentは、CloudWatchアラームやPagerDutyページで起動され、原因仮説を立てログとトレースをクエリして検証し、異常を最近のデプロイタイムスタンプと相関させ、Slackに推奨緩和策とともに知見を投稿します。AWSは、文書化されたデプロイメント全体で最大75%低いMTTR報告しており、Western Governors University のケーススタディでは、解決時間がおよそ2時間から28分に短縮されたことを引用しています(参照: [https://aws.amazon.com/blogs/devops/leverage-agentic-ai-for-autonomous-incident-response-with-aws-devops-agent/)。](https://aws.amazon.com/blogs/devops/leverage-agentic-ai-for-autonomous-incident-response-with-aws-devops-agent/)。)

注目すべきは数字ではなく、監査証跡要件です。エージェントが取るすべての推論ステップは、自身が変更できない不変レコードに記録されます。これはオプションではなく、必須です。エージェントがあなたのデプロイ履歴と誤り急増を相関させ、オンコール担当者に「多分、チェックアウトサービスの変更が原因」と告げるなら、間違った時にエージェントどう到達したかを正確に再構成できる必要があります。そしてエージェントは時々間違うでしょう。

同じパターンが異なる名前で見られます。Wild Mooseは1分以内の根本原因表出を約束し、HolmesGPTは同じ検知-相関-説明ループで云々クラウドアラートを診断します。メカニクスが集約されるのは、問題が至る所で同じ形だからです。アラート発火、エージェント計測を読む、エージェント原因を提案、人間が確認か上書き。

セットアップ価値があるのは、チームが週に数回以上ページングを受け、事後検証で「原因特定に時間がかかった」が貢献要因として繰り返される場合です。インシデントが稀で、チューニング時間が次のアーキテクチャ変更でモデルの学習データが古くなる前に回収できないなら、スキップしてもよいでしょう。

## Kubernetes診断エージェント: より限定的で安全なスライス

Kubernetes デバッグが多くのこれらツールの出発点です。おそらく kubectl出力が、LLMが要約するのに適した密集した構造化テキストだからです。k8s-GPTはクラスタをスキャンし、平文で失敗を説明します。ポッドがなぜCrashLoopBackOffで止まっているのか、なぜPVCがバインドしないのか、なぜサービスにエンドポイントがないのか。行動しません、説明します。これは意図的なスコーピングであり、自分が完全に理解していないクラスタに対して実行する可能性のあるジュニアエンジニアのためのツールとしては正しい選択です。

次のレイヤーは注意深く行動します。Guardian形式エージェントは問題を検知し、根本原因を見つけ、クラスタに直接pushする代わりに修正PRをオープンします。そのたった1ステップ、live変更ではなくPRをいう違いが、「有用な自動化」と「先週の障害を引き起こしたもの」の全ての違いです。PRはレビューされます。エージェントからの直接kubectlはそうではありませんし、自分でレビューステップを組み込まない限り、ほとんどのチームはそうしていません。

ドキュメント層は予想より重要です。エージェントがKubernetes失敗を説明するか、修正PRをオープンするとき、それが暗黙的に従うランブックはチームの頭の中か、エージェント(と次のエンジニア)が実際に読める場所にあるかのいずれかです。ドキュメント・アズ・コード・ツールと照会可能なAIレイヤーを保つチームは6ヶ月後に「なぜこのようにしたのか」スレッドが減ります。これはエージェント固有のアドバイスではなく、エージェント出力が人間が読む場合より古いドキュメント明らかにします。

![An on-call engineer checking a laptop alert at 3am, the scenario an incident-response agent is built to intercept](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-07/b0774c-inline2.webp)

## ランブック実行エージェント: 本番にエージェントを触らせるとき

これが「完全自律型SREエージェント」と言う時に人々が意味するカテゴリーであり、また証拠の底が最も薄いものです。ピッチ: エージェントがメモリリークを検知し、低トラフィックウィンドウ中にローリング再起動をトリガーし、サービスが正常に戻ったことを確認し、誰もページングすることなくループを閉じます。マルチステップ修復プレイブック、2am実行順序での誤字のリスクなしで、昨年3月から最後にテストされたランブックでステップをスキップすること。

それは、プレイブックが限定的で、blast radiusが小さい時に機能します。低トラフィックウィンドウの間にステートレスサービスのローリング再起動は、自動化する妥当な対象です。営業時間中のデータベースフェイルオーバーは違います。エージェントの記録がデモでどんなに良く見えても。ここで焼かれるチームは再起動を自動化しているものではなく、初期の勝利が十分な本番評判を持つ前にデータ損失リスク付きで何かを自動化させるほど、その初期の勝利で話を止めたものです。

私たち自身の読み、プログレッシブロールアウトに AIパイロットをつなぐ顧客を観る: 最も逆転し易く、最も判断誤り難いアクションから始めます。フェイルオーバー前のリスタート。データベーススキーマ変更前のカナリア%ロールバック。低リスクアクションに対するエージェントのエラー率が、より高リスク者への場合を数週間、1日ではなく数ヶ月を測定する時間軸で作成します。

## 一般目的エージェントも現れます。そしてそれらはこのために間違った形です

「AI agent examples」を任意の場所で検索してみてください。opsコンテキスト外ではオンディマンドな開いたタスク全体を計画実行するために組まれた異なるカテゴリーエージェント上陸: 仮想ブラウザ、ターミナル、ファイルシステムを横断する。

Manusは完全仮想コンピュータの内側で動作し、チャット答え代わりに完了デリバラブルで報告し返します。本当に研究とマルチステップウェブタスクで有能です。それはまた本番ロールアウト決定のための間違ったツールであり、その価値提案は幅広さだからです。ほぼ何でも可能です、十分なステップと十分な時間を与えられて。ロールバック決定は反対のプロパティを必要とします。高速、限定的で、実行する前に正確に何をするかを予測できるほど退屈なこと。

Lindyはopsに隣接した中央に座ります。コード不要ワークフロー、 inbox triage、会議スケジュール、繰り返しフォローアップを扱います。オンコール回転の人間側(誰も6amでハンドオフを手動でリスケしたくない)で有用です、実インシデント対応では無用です。GensparkのコードなしSuper Agentと同じ話で、ブラウズ、呼び出し、要求時生成しますが、SLO予算やカナリア%の概念はありません。

これらはこれらプロダクトへの非難ではありません。異なる仕事のために構築されています。見かけられ続ける誤解はチームが一般目的エージェントをopsの狭い問題に対して評価し、感銘を受けず、結論づけます「AI agentsはインフラの準備ができていない」。間違ったカテゴリー、間違った結論。

## これらのエージェントがまだ失敗する所、そしてそれが興味深い部分である理由

根本原因特定で94%正確なエージェントの失敗モード、誰もケーススタディで言わない: 17に1度は間違っており、その間違った答えは通常、十分に自信を持っていて、オンコール技術者が正しいサービスを追いかけ続ける前にそれが誰か気付く前に20分間、相関をエージェントが見つけたのは因果ではなく、単なる偶然です。デプロイタイムスタンプ相関は実信号です。それは証拠ではありません。確実に聞こえるように訓練されたエージェントは、本当の原因と同じくらい偶然について確実に聞こえます。

2番目の失敗モードは静かです。エージェント増殖です。一度トリアージ、診断、ロールバックエージェントが全て走る時、誰かがエージェントを監視する必要があります。2026年初めデプロイメントは既に最大のオプwin成果がMTTR数値ではなく、エージェント層自体の可観測性構築であることを示しています。エージェントがサイレントにトリガーするのを止めるため、人間は気付かないのです。

誰かが気付かない可能性があるため、不可逆blast radiusのあるものでは完全自律性をスキップしてください。たとえ最後の20実行が見た通りに見えても。20実行はおり分布ではなくサンプルです。

![A dim server room corridor with rows of racks, representing the infrastructure layer AI agents monitor and act on](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-07/474040-inline3.webp)

## エージェントをロールアウトにつなぐべき? それとも1サイクル待つべき?

チームが月に数回以上ページングされ、事後検証で同じ根本原因が異なるサービス名で繰り返す場合、トリアージエージェントは予想より早く利益を払い戻します。ほとんど「何が変わったか」フェーズを短縮するため。デプロイ量が人間がすべてのロールアウトをライブで見守るほど高くない場合、SLO制御ロールバックエージェントは3am判断呼び出しを完全に削除します。これが実ポイントです。オンコール技術者が3amで考えることを望まず、昼間に設定されたボタンを押すことを望みます。
どちらもまだ当てはまらない場合、正直な動きはまずSLOを正しく計測することです。ノイズが多く定義されない誤差予算の上に座るエージェントは、人間が判断しただろうより悪い決定を自動化するだけです。エージェントは難しい部分ではありません。3amで疲れない何かに決定を渡す前に、正確に「行動するほど悪い」の意味が何か、数字で理解することです。

## FAQ

### 本番でAIエージェントを使用する前提条件は何ですか?

最小限の前提条件は、SLOが明確に定義されており、可観測性スタックから実時間でメトリクスを取得できることです。またエージェントが何をするかを完全に予測でき、その行動が監査ログに記録されている必要があります。

### ロールバックエージェントとトリアージエージェントの違いは?

ロールバックエージェントは自動的に本番環境を変更します(デプロイメントのリバート)。トリアージエージェントは情報を人間に提供し、判断は人間が行います。データ損失のリスク無しで段階的に開始するなら、トリアージから始めてください。

### エージェントのエラー率が高い場合はどうすべき?

完全自律性を進める前に、エージェントの低リスク行動に対するエラー率が十分に低いことを複数月にわたって検証してください。記録が何度も99%を超えることを証拠なしに進めないこと。

### Kubernetes診断エージェントはまず導入すべき選択肢ですか?

インシデント対応が遅い(根本原因特定に時間がかかる)場合は有効です。ただし診断のみで行動しないバージョン(k8s-GPT)から始めてください。PR作成(Guardian形式)は次のステップです。

### 一般目的エージェント(Manus, Lindy)がopsに向かない理由は?

一般目的エージェントは柔軟性と幅広さが強みですが、ロールバック決定などには速度と予測可能性が必要です。また、本番決定には監査可能性と狭い責任範囲が重要です。

### エージェント増殖とは具体的に何ですか?

複数のエージェントが展開されると、それらが正常に動作しているかどうかを監視する必要が生じます。サイレントに失敗し始めたエージェント(誰も気付かない)は、動作していないエージェントより悪いことがあります。

### エージェント根本原因推定の94%正確率で十分でしょう?

いいえ。17に1度の誤りは、自信を持ったが間違った推奨につながり、オンコール技術者を間違った方向に導きます。根本原因相関は実信号ですが、証拠ではありません。常に人間のレビューが必要です。

### 本番環境でのエージェント導入のロードマップは?

1.SLO定義を改善、2.低リスク行動用トリアージエージェント、3.複数月の記録取得、4.診断エージェント追加、5.低リスク自動化(再起動など)、6.より高リスク行動(フェイルオーバー)は6-12ヶ月後。