【2026年最新】AIエージェントの本番運用SRE｜監視・SLA設計・障害対応の7プラクティス

AIエージェントを社内ツールや顧客向け機能として本番運用しはじめると、「動いてはいるが、いつ壊れるか分からない」という不安が常につきまといます。LLMは確率的に動くため、従来のSRE手法（成功率99.9%・p99レイテンシ200ms以下）をそのまま当てはめても運用は破綻します。モデルAPIの障害、ツール接続のタイムアウト、プロンプト変更による品質劣化、無限ループによるコスト暴走、いずれも従来Webサービスにはなかった故障モードです。

本記事では、AIエージェントを本番運用するテックリード・SRE・情シスに向けて、SLO設計から障害対応までの7プラクティスを実装目線で解説します。LangSmith、Datadog、OpenTelemetryなど実プロダクトで採用されているスタックを前提に、設定例・プロンプト例・アラートルールを7本のコピペテンプレートで整理しました。

筆者は研修・コンサル業務でAIエージェントの本番運用を10社以上で支援してきました。その過程で見えてきた「SLO後付け」「モデルAPI単一依存」「無限ループ放置」「監視不在」の4大失敗パターンも併せて共有します。読み終わるころには、自社のエージェントに対して今週から動ける改善アクションが3つ以上見えているはずです。

SRE文化を持つ組織はもちろん、これからAIエージェントを本番に出そうとしているチームにとっても、最初に決めるべき指標と入れるべき監視の優先順位が分かる構成にしています。Google SRE Bookの考え方を踏襲しつつ、LLM特有の不確実性をどう吸収するかに踏み込みました。

結論：AIエージェントSREで最初にやる7つのこと

以下、それぞれを実装目線で深掘りします。

AIエージェントSREの全体マップ

従来のWebサービスSREは「インフラ＋アプリケーション」の2層で考えれば足りました。AIエージェントは、ここに「モデルAPI」「ツール群」「プロンプト」「コンテキスト管理」という4つのレイヤーが追加されます。それぞれが独立して壊れるため、SRE設計も多層化が必要です。

全体像を7領域に分解すると次のようになります。

• SLO設計：成功率・レイテンシ・コストの3軸で「許容範囲」を定義
• トレーシング：1リクエストの全行程（プロンプト→ツール呼び出し→レスポンス）を可視化
• 障害分類：5つの故障モードを区別し、それぞれに復旧手順を持つ
• 自動復旧：フォールバック・リトライ・Circuit Breakerの3層構造
• コスト監視：分単位の天井設定で暴走を即停止
• セキュリティ：プロンプトインジェクション・データ漏洩・権限境界の管理
• ユーザー影響評価：エラーバジェット消費とポストモーテムで継続改善

これらは独立ではなく、全部つながっています。たとえばトレーシングが入っていないとSLO達成率も測れないし、コスト分析もできません。最初に入れるべきはトレーシング、次にSLO、その次に自動復旧、という順序で組み立てるのが現実的です。

Google SRE Bookが提唱する「エラーバジェット」の考え方は、AIエージェントにも当てはまります。100%の成功率を狙うとコストもレイテンシも跳ね上がるので、たとえば「成功率95%・残り5%は許容してリトライさせる」という割り切りが、結果としてサービス品質を安定させます。

プラクティス1：SLO設計の3指標

SREの出発点はSLO（Service Level Objective）です。AIエージェントの場合、最低3つの指標を持つことを推奨します。

指標1：成功率

「タスクを完了できたリクエストの割合」と定義します。LLMの出力が空、ツール呼び出しが全失敗、無限ループでタイムアウトしたものはすべて「失敗」にカウントします。一般的なエージェントなら95%以上を目標にできれば及第点です。99.9%を目指すと、モデルAPIの揺らぎを全部吸収するためにフォールバック・リトライ・キャッシュを多層化する必要があり、開発コストが跳ね上がります。

指標2：p95レイテンシ

「ユーザーがリクエストしてから最終レスポンスを受け取るまで」の95パーセンタイルです。チャット型エージェントならp95＝15秒以下、バックグラウンドの定期処理ならp95＝3分以下などタスクの性質で決めます。p99ではなくp95を採用するのは、LLMには稀に極端に遅い応答が出るため、p99に振り回されると過剰最適化になるためです。

指標3：1リクエスト当たりコスト上限

「1リクエストで消費するトークンコストの上限」を金額で定義します。Claude Sonnet 4で標準的なエージェント処理なら0.5ドル以下、複雑な調査タスクなら2ドル以下といった具合です。これがないと、後述する無限ループや巨大コンテキスト読み込みでコストが青天井になります。

プロンプト/設定例1：SLO定義テンプレート

# SLO定義（YAML形式・社内Wikiに貼る）
service: customer-support-agent
slo:
  success_rate:
    target: 0.95
    window: 30d
    measurement: "completed_tasks / total_requests"
  latency_p95:
    target: 15s
    window: 7d
    measurement: "end_to_end_response_time"
  cost_per_request:
    target: 0.5
    currency: USD
    measurement: "total_token_cost + tool_api_cost"
error_budget:
  monthly: 5%
  alert_at: 80%  # 月の80%消費でPagerDuty
review_cadence: weekly

SLOは「決めて終わり」ではなく、毎週レビューしてエラーバジェットの消費率を見ます。エラーバジェットが月の途中で80%消費されたら、機能追加を止めて品質改善に集中する判断ができます。

プラクティス2：トレーシングをLangSmith/OpenTelemetryで必須化

AIエージェントのデバッグは、トレーシングがないと不可能と言って差し支えありません。1リクエストの中でLLMが何回呼ばれ、どのツールがどの順で実行され、各ステップで何トークン消費したか、これらを可視化しないと障害切り分けに何時間も溶かすことになります。

選択肢の比較

主な選択肢は次の3つです。

• LangSmith：LangChain社のSaaS。LangChain/LangGraphとの統合が最強。SDK追加だけで自動計装される
• OpenTelemetry（OTel）：ベンダーニュートラルな業界標準。Datadog、Grafana、Honeycombなど既存基盤に流せる
• Datadog LLM Observability：APMがすでにDatadogならこれが楽。コスト追跡も標準装備

すでにDatadogを使っているチームはDatadog LLM Observability、新規ならLangSmithかOpenTelemetryで始めるのが現実解です。LangSmithは無料枠で月5,000トレースまで使えるので、検証段階ではここから始めるチームが多い印象です。

プロンプト/設定例2：OpenTelemetryでLLMトレーシング

# Pythonでの実装例（OpenTelemetry + Anthropic SDK）
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
import anthropic
import time

trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4317"))
)
tracer = trace.get_tracer("agent")

def call_llm(user_message: str) -> str:
    with tracer.start_as_current_span("llm.call") as span:
        client = anthropic.Anthropic()
        start = time.time()
        response = client.messages.create(
            model="claude-sonnet-4-20250514",
            max_tokens=1024,
            messages=[{"role": "user", "content": user_message}],
        )
        # トレースに重要属性を載せる
        span.set_attribute("llm.model", "claude-sonnet-4-20250514")
        span.set_attribute("llm.input_tokens", response.usage.input_tokens)
        span.set_attribute("llm.output_tokens", response.usage.output_tokens)
        span.set_attribute("llm.cost_usd",
            response.usage.input_tokens * 0.000003 +
            response.usage.output_tokens * 0.000015)
        span.set_attribute("llm.latency_ms", int((time.time() - start) * 1000))
        return response.content[0].text

重要なのは「LLM呼び出しのspanに、モデル名・トークン数・コスト・レイテンシを属性として記録する」点です。これがあれば、後でDatadogやGrafanaのダッシュボードで「どのモデルがコストの何%を占めるか」「ツールごとのレイテンシ分布はどうか」を集計できます。

トレーシングで見るべき4つの観点

1. 1リクエスト当たりのLLM呼び出し回数（理想は5回以下、10回超は黄信号）
2. 各ツール呼び出しの成功率・p95レイテンシ
3. セッションごとの累積トークン数（コンテキスト膨張の検知）
4. 同一セッションでのリトライ回数（無限ループ検知）

プラクティス3：AIエージェント障害5分類とオンコール手順

従来のWebサービスでは「DB接続失敗」「メモリ枯渇」「タイムアウト」など障害パターンが定型化されていました。AIエージェントは故障モードが異なるので、まず5分類でオンコール手順を作ります。

分類1：モデルAPI障害

Anthropic、OpenAI、Googleなどモデル提供元の障害。500エラー、レートリミット、突然のレスポンス遅延が典型です。
対応：自動フォールバックでセカンダリモデルに切替（プラクティス4参照）。1社のステータスページに依存せず、複数モデルAPIの監視を入れる。

分類2：ツール接続障害

エージェントが呼び出す外部API（Slack、Notion、社内DB等）の障害。
対応：指数バックオフでリトライ。それでも復旧しなければCircuit Breakerで該当ツールを一時無効化し、エージェントが「このツールは今使えないので別の方法を提案します」と応答できるようにする。

分類3：プロンプト不安定

プロンプト変更後にハルシネーション率や指示不遵守率が上がる現象。コードのデプロイより検知が難しい。
対応：プロンプト変更は必ずA/Bテストかカナリアリリースで段階展開。LangSmithのデータセットで回帰テストを回す。

分類4：無限ループ

エージェントが「ツール呼び出し→失敗→再試行→ツール呼び出し→失敗」を延々と繰り返す。LLM呼び出し回数だけが膨れ上がり、レイテンシもコストも青天井になる。
対応：1リクエスト当たりのLLM呼び出し上限（例：20回）を強制設定。超えたら強制終了。

分類5：コスト暴走

巨大なファイル読み込み、長すぎる会話履歴、リトライ嵐などでトークン消費が跳ね上がる。1ユーザーで1日数百ドル消費した事例もある。
対応：ユーザーごと・セッションごとのコスト上限を設定し、超えたら通知して停止する。

プロンプト/設定例3：アラートルール（Datadog）

# Datadog Monitor設定（YAML/Terraform想定）
- name: "AI Agent: Success rate below 95%"
  type: metric alert
  query: "avg(last_15m):avg:agent.success_rate{*} < 0.95"
  message: "@pagerduty-oncall Success rate dropped. Check LangSmith for trace failures."
  options:
    notify_no_data: true
    no_data_timeframe: 30

- name: "AI Agent: Cost spike per user"
  type: metric alert
  query: "max(last_1h):max:agent.cost_per_user{*} by {user_id} > 10"
  message: "@slack-sre User $1 exceeded $10/hour. Auto-throttling triggered."

- name: "AI Agent: Infinite loop suspected"
  type: metric alert
  query: "avg(last_5m):avg:agent.llm_calls_per_request{*} > 15"
  message: "@pagerduty-oncall Average LLM calls per request exceeded 15. Possible infinite loop."

注意点として、SREアラートは「鳴ったらすぐ動く必要があるもの」だけに絞ります。ノイズが多いとアラート疲れが起き、本当に重要な通知を見落とします。Google SRE Bookでも「Symptom-Based Alerting（症状ベースのアラート）」が推奨されているように、「LLM呼び出し回数が多い」ではなく「ユーザーが影響を受けている」を起点に組みます。

プラクティス4：自動復旧の3層構造

AIエージェントの自動復旧は、3層で組むのが現実解です。

層1：モデルAPIフォールバック

主モデル（例：Claude Sonnet 4）が失敗したら、自動でセカンダリ（GPT-5）→ターシャリ（Gemini 2.5 Pro）に切り替えます。3社全部が同時に落ちる確率は実質ゼロなので、これだけで稼働率を1〜2桁改善できます。

層2：ツール呼び出しリトライ

外部API呼び出しは、指数バックオフでリトライします。初回1秒→2秒→4秒→8秒。4回失敗したら諦めてエラーを返し、ユーザーには「現在このツールが使えません」と返答させます。

層3：Circuit Breaker

あるツールの失敗率が閾値（例：30%）を超えたら、一定時間（例：5分）そのツールへのリクエストを止めます。これにより、依存先の障害がエージェント全体に波及するのを防ぎます。

プロンプト/設定例4：フォールバック実装（Python）

import anthropic
import openai
import google.generativeai as genai
from typing import Optional

class FallbackLLM:
    def __init__(self):
        self.anthropic = anthropic.Anthropic()
        self.openai = openai.OpenAI()
        genai.configure()

    def call(self, prompt: str) -> Optional[str]:
        # Layer 1: Claude
        try:
            r = self.anthropic.messages.create(
                model="claude-sonnet-4-20250514",
                max_tokens=1024,
                messages=[{"role": "user", "content": prompt}],
            )
            return r.content[0].text
        except Exception as e:
            print(f"Claude failed: {e}, falling back to GPT-5")
        # Layer 2: GPT-5
        try:
            r = self.openai.chat.completions.create(
                model="gpt-5",
                messages=[{"role": "user", "content": prompt}],
            )
            return r.choices[0].message.content
        except Exception as e:
            print(f"GPT-5 failed: {e}, falling back to Gemini")
        # Layer 3: Gemini
        try:
            model = genai.GenerativeModel("gemini-2.5-pro")
            r = model.generate_content(prompt)
            return r.text
        except Exception as e:
            print(f"All providers failed: {e}")
            return None

注意点：各社のAPI仕様は微妙に違うので、プロンプトの調整やレスポンス形式の正規化が必要です。実運用では、Portkey、OpenRouter、LiteLLMといったゲートウェイサービスを使うと、この層を自前実装せずに済みます。

プラクティス5：コスト監視を分単位で

従来のクラウド請求は「月末まで知らない」が標準でしたが、AIエージェントではこれが致命傷になります。プロンプトのバグやユーザーの悪意（プロンプトインジェクション含む）で、1日数百ドル飛ばす事故が起こり得るためです。

監視すべき3レベル

• サービス全体：1時間ごとの累積コスト
• ユーザーごと：1ユーザー1日のコスト
• セッションごと：1セッションのコスト（無限ループ検知）

それぞれに「ソフト警告」と「ハード停止」の2閾値を設けます。ソフト警告でSlack通知、ハード停止でリクエスト拒否、という運用です。

プロンプト/設定例5：セッション当たりコスト監視（Python擬似コード）

import redis
from datetime import datetime, timedelta

class CostGuard:
    def __init__(self, redis_client):
        self.redis = redis_client
        # 閾値（USD）
        self.session_soft = 1.0
        self.session_hard = 3.0
        self.user_daily_hard = 20.0

    def record(self, user_id: str, session_id: str, cost: float):
        # セッションコスト
        session_key = f"cost:session:{session_id}"
        new_session_cost = float(self.redis.incrbyfloat(session_key, cost))
        self.redis.expire(session_key, 3600)  # 1時間

        # ユーザー日次コスト
        today = datetime.utcnow().strftime("%Y%m%d")
        user_key = f"cost:user:{user_id}:{today}"
        new_user_cost = float(self.redis.incrbyfloat(user_key, cost))
        self.redis.expire(user_key, 86400 * 2)

        # 閾値判定
        if new_session_cost > self.session_hard:
            raise CostExceededError(
                f"Session {session_id} exceeded {self.session_hard} USD"
            )
        if new_user_cost > self.user_daily_hard:
            raise CostExceededError(
                f"User {user_id} exceeded daily limit"
            )
        if new_session_cost > self.session_soft:
            self.notify_slack(f"WARN: session {session_id} at {new_session_cost} USD")

class CostExceededError(Exception):
    pass

運用上のポイントは、コスト上限超過時にユーザーに丁寧に伝えることです。「サーバーエラー」と返すと混乱しますが、「現在のセッションが利用上限に達しました。新しいセッションを開始するか、管理者にご連絡ください」と返せば、ユーザーも対応できます。

プラクティス6：ポストモーテムを毎月実施

Google SRE Bookが提唱する「Blameless Postmortem（非難なきポストモーテム）」は、AIエージェントの運用でも極めて重要です。LLMは確率的に動くので、「人為的ミス」ではなく「構造的脆弱性」が原因の障害がほとんどです。

毎月のSREレビューで見る4項目

1. 実際に起きた障害：何が起きて、ユーザーにどう影響したか
2. ニアミス：障害寸前で止まったもの。次回は止まらない可能性がある
3. 品質劣化：成功率・レイテンシ・ユーザー満足度の悪化トレンド
4. コストスパイク：閾値超過や前月比異常増加

プロンプト/設定例6：ポストモーテムテンプレート

# インシデント・ポストモーテム

## サマリー
- インシデントID: INC-2026-0526-001
- 発生時刻: 2026-05-26 14:32 JST
- 復旧時刻: 2026-05-26 14:58 JST（26分）
- 影響範囲: 顧客サポートエージェント全機能停止
- 影響ユーザー数: 約120名（同時セッション数）

## 何が起きたか（事実のみ）
14:32にAnthropic APIから529エラー（overloaded）が連続発生。
セカンダリのGPT-5へのフォールバックは設定されていなかったため、
全リクエストが失敗。14:45にエンジニアが手動でGPT-5に切替実施。

## なぜ起きたか（5 Whys）
1. なぜ停止した？ → Claude APIが連続エラー
2. なぜフォールバックしなかった？ → コードに実装されていなかった
3. なぜ実装されていなかった？ → 初期開発時に「Claudeは安定している」前提だった
4. なぜ前提を疑わなかった？ → 過去6ヶ月間大きな障害がなかった
5. なぜ過去実績だけで判断した？ → SLOにフォールバック必須が明記されていなかった

## アクション（担当・期限明記）
- [ ] フォールバック実装（@yamada / 2026-06-02）
- [ ] SLOにフォールバック要件追記（@suzuki / 2026-05-30）
- [ ] 月次SREレビューで「単一依存」チェック項目追加（@suzuki / 2026-06-01）

## 学び
LLMプロバイダーは確率的に落ちる前提で設計すべき。
「安定している」は過去の話で、未来の保証にはならない。

ポストモーテムで重要なのは「誰が悪いか」ではなく「次に同じことが起きないために何を変えるか」です。Anthropic、OpenAI、Googleの3社それぞれの過去半年の稼働率を見ても、月に1〜2回は何らかのインシデントが起きています。これを前提にした設計が必要です。

プラクティス7：月次SREレポートで経営層を巻き込む

AIエージェントのSREは、エンジニアだけで完結させると経営判断が後手に回ります。月次レポートを作って経営層・事業部に共有し、「品質投資の優先度」を握る場を作ります。

レポートに含める5項目

• SLO達成状況（成功率・レイテンシ・コスト）
• エラーバジェット消費率
• 主要インシデント一覧と再発防止状況
• コスト推移（前月比、ユーザー単価）
• 次月の改善計画

プロンプト/設定例7：月次SREレポートのテンプレ

# AIエージェントSREレポート 2026年5月

## ハイライト
- SLO達成: 成功率96.2%（目標95%）、p95レイテンシ12.3秒（目標15秒）、コスト/req $0.42（目標$0.50）
- エラーバジェット消費: 月の72%消費（前月比+15ポイント）
- 主要インシデント: 1件（モデルAPIフォールバック未実装が原因、復旧26分）

## 数値サマリー
| 指標 | 5月実績 | 4月実績 | 目標 |
|------|--------|--------|------|
| 成功率 | 96.2% | 97.1% | 95% |
| p95レイテンシ | 12.3s | 11.8s | 15s |
| 1リクエスト当たりコスト | $0.42 | $0.38 | $0.50 |
| 月間総コスト | $8,400 | $7,200 | $10,000 |
| アクティブユーザー数 | 1,420 | 1,180 | - |

## 主要インシデント
- INC-2026-0526-001: Claude API障害、フォールバック未実装で26分停止
  → アクション: フォールバック実装完了（2026-06-02）

## 来月の改善計画
1. プロンプト変更時のA/Bテスト基盤整備
2. ユーザーごとコスト上限のUI上での可視化
3. Circuit Breaker導入（外部ツール3つに先行適用）

## 経営層への提案
- Q3にSREエンジニア1名増員を提案（現状1名で1,400ユーザーは限界）

このレポートを毎月続けると、経営層も「AIエージェントは確率的に壊れる」「品質投資が必要」という共通認識を持てます。インシデントが起きてから慌てて予算を取りに行くより、平時から数字を見せ続けるほうが、結果として安定運用に近づきます。

失敗パターン4選（よくある落とし穴）

失敗1：SLOを後付けで決める

本番リリース後にSLOを決めようとすると、過去のデータがないので「今の数値＝目標」になってしまい、改善の余地がなくなります。リリース前に「最低限これくらいは満たす」というラインを決めることが大事です。たとえ仮置きでも、運用しながら毎月見直すほうが遥かに健全です。

失敗2：モデルAPIの単一依存

Claude単独、GPT単独で運用すると、提供元が落ちた瞬間にサービス停止です。2025年以降、各社のステータスページを見ると月1〜2回は何らかのインシデントが起きています。フォールバック実装は必須と考えてください。

失敗3：無限ループ放置

「ツール呼び出し失敗→再試行→ツール呼び出し失敗」のループに陥ったエージェントが、1セッションでLLM呼び出し200回、コスト50ドルを消費した事例があります。1リクエスト当たりのLLM呼び出し回数上限は、最初から設定しておく必要があります。

失敗4：監視不在

「とりあえず本番に出してから監視を考える」は最悪のパターンです。本番で何かが壊れた時、トレースもログもなければ原因特定に何日もかかります。最低でもLangSmithかOpenTelemetryのどちらかは、リリース前に入れておくべきです。

想定シナリオ3つ（規模別）

シナリオA：SaaS開発10名チーム（B2Bツール内蔵エージェント）

たとえばCRMにエージェント機能を組み込んでいるSaaS企業。エンジニア10名、SRE専任なし、エージェント機能のMAU 2,000人規模。

このフェーズで最初にやるべきは「LangSmith導入＋SLO3指標の仮置き＋コスト上限設定」の3つだけです。本格的なSREチームを作るより、開発エンジニアが片手間でも見られる仕組みを作るのが現実解です。月次レビューはエンジニアリングマネージャーが30分主催すれば十分です。

シナリオB：受託開発30名チーム（クライアント向けエージェント納品）

クライアントごとに別のエージェントを納品し、運用も巻き取っているケース。納品数10件、各クライアントで月数万リクエスト。

このフェーズではマルチテナント管理が必須になります。クライアントごとにコスト・成功率・レイテンシをタグ付けし、Datadogのダッシュボードを分けます。SLOもクライアントごとに合意し、契約書のSLAに反映させる動きも始まります。SREロールを兼任する人を1人指名し、週次でレビューを回すのが現実的です。

シナリオC：自社プロダクト100名チーム（数十万ユーザー向けエージェント）

BtoCまたは大規模BtoBで、エージェント機能がプロダクトの中核を担うフェーズ。

ここまで来ると専任SREチームが2〜3名必要です。OpenTelemetry + Datadog/Grafana構成、PagerDutyによるオンコール、ポストモーテム文化の確立、四半期ごとの障害訓練（ゲームデイ）まで含めた本格運用になります。コスト管理も予算アラートをFinanceチームと共有し、経営層への月次レポートをCFOラインに送る運用に移行します。

SREツールスタックの選び方

規模別に推奨スタックを整理します。

規模	トレーシング	メトリクス	アラート	コスト管理
〜MAU 1万	LangSmith無料枠	LangSmith内蔵	Slack通知のみ	各社管理画面で月次
MAU 1〜10万	LangSmith有料	Datadog or Grafana	PagerDuty	カスタムRedis実装
MAU 10万〜	OpenTelemetry	Datadog APM	PagerDuty + 自動復旧	専用FinOpsツール

大事なのは「規模に合った投資」です。MAU 1,000人のサービスにDatadog Enterpriseを入れるとコストが見合いません。逆にMAU 50万のサービスでLangSmithだけだと、ダッシュボードの自由度が足りなくなります。

セキュリティ観点での追加考慮

SREは「サービスを止めない」だけでなく「事故を起こさない」も担当領域です。AIエージェント特有のセキュリティリスクとして、最低限以下を監視しましょう。

• プロンプトインジェクション：ユーザー入力に「previous instructions を無視せよ」等が含まれていないか
• 機密情報漏洩：エージェント出力に個人情報・APIキー・社内情報が含まれていないか（Output Guardrails）
• 権限境界：エージェントがユーザーの権限を超えてツールを呼んでいないか
• 監査ログ：誰がいつ何のツールを呼んだか、SOX対象の業務なら最低7年保持

これらは別記事で深掘りしますが、SLO設計の段階で「セキュリティインシデント0件」を非機能要件として明記しておくと、後から監査対応するときに楽です。

導入ロードマップ（90日プラン）

ゼロから始めるチーム向けに、90日でSRE基盤を整える順序を示します。

Day 1-30：基盤整備

• LangSmith or OpenTelemetry導入
• SLO3指標の仮決め
• コスト上限設定（セッション・ユーザー単位）
• Slack通知3本（成功率・コスト・LLM呼び出し回数）

Day 31-60：自動復旧

• モデルAPIフォールバック実装
• ツール呼び出しリトライ＋Circuit Breaker
• 初回ポストモーテム実施（過去のインシデントを掘り起こす）

Day 61-90：運用文化定着

• 月次SREレポート開始
• 経営層向け数値共有
• Q末で90日振り返り、次クォーター計画

このペースで進めると、3ヶ月後には「壊れても気付いて、自動で復旧して、人が再発防止策を立てる」基本サイクルが回り始めます。完璧を狙わず、まずは「測れる」「気付ける」状態を作ることが第一歩です。

関連記事・参考リンク

本記事の周辺トピックを掘り下げたい方は、以下の関連記事も参考にしてください。

• AIエージェントのアーキテクチャ設計：エージェントの構造そのものを設計する観点を整理
• AIエージェントのコスト最適化：トークン削減・キャッシュ・モデル選定の実践テクニック

外部の一次ソースとして以下を参照しました（参照日：2026-05-26）。

• OpenTelemetry公式ドキュメント：分散トレーシング業界標準の仕様と実装ガイド
• LangSmith公式ドキュメント：LLMアプリのトレーシング・評価・モニタリング
• Anthropic Claude Engineering Blog：プロダクション運用の知見・ベストプラクティス
• Google SRE Book：SREの原典。SLO・エラーバジェット・ポストモーテムの体系

まとめ：完璧より「測れる」を目指す

AIエージェントSREは、従来のSREに比べて「故障モードの多様性」と「確率的挙動」という新しい難しさがあります。一方で、原則は変わりません。SLOを決めて、計測して、自動復旧を組んで、振り返って改善する。この基本サイクルが回り始めれば、エージェントは「不安定で怖い」から「壊れても運用で吸収できる」に変わります。

本記事で紹介した7プラクティスと7つの設定例は、明日から手を付けられるものばかりです。まずはトレーシングとSLO仮置きの2つから始めてみてください。1ヶ月後には自社エージェントの実態が見え始め、改善の方向が定まるはずです。

---

著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。
X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。