ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-04-24上級

Antigravity エージェントの SRE を始める — SLO とエラーバジェットで『AIは気まぐれ』を本番運用に落とし込む

AI エージェントは確率的に動く以上、SRE の考え方なしに本番運用はできません。SLI/SLO/エラーバジェットを Antigravity エージェントにどう適用するか、実装コードと運用判断基準まで踏み込んで解説します。

antigravity435sre2slo3error-budgetproduction59reliability5agents90

プレミアム記事

「AI エージェントって、本番に置いて大丈夫なんですか?」

Antigravity で作ったエージェントを会社の業務フローに組み込もうとした初日、SRE チームのリードからこう言われました。同じ入力でも違う出力が返ってくる確率的な挙動を、99.9% の可用性で動いている既存サービスと並べて語ろうとすると、どうしても噛み合わないのです。

この記事は、その日の会議で私が答えられなかった問いに対する、半年分の運用経験をまとめた答えです。結論から言うと、「AI は気まぐれ」を前提にしたまま、SRE の古典的な道具である SLI / SLO / エラーバジェット を適用すれば、エージェントは本番で十分に扱えます。ただし従来の Web サービスとは違う形で SLI を定義しなければならず、ここで多くのチームがつまずきます。

ここではAntigravity の エージェント評価フレームワーク と組み合わせながら、実運用で使えるコード付きで解説します。LangFuse を使ったエージェント可観測性ガイド の内容と重ねて読むと、計装から意思決定までの流れが見えてきます。

従来の SLI がなぜ AI エージェントで通じないのか

Google の SRE Book に出てくる SLI の典型例は「HTTP リクエストの成功率」「レイテンシ 200ms 以下の割合」です。しかし、Antigravity エージェントで「成功」を定義しようとすると、途端に壁にぶつかります。

例えば「このコードベースをリファクタリングしてください」というリクエストに対して、200 OK で返ってきたレスポンスが本当に成功なのかは、コードを実際に読むまで分かりません。HTTP ステータスだけを見ていると、意味不明な差分を 200 で返しているエージェントも「成功」にカウントされてしまいます。

私が最初に失敗したのは、まさにここでした。is_success = response.status == 200 という雑な SLI を定義して 2 週間運用した結果、メトリクスは完璧なのに、開発者からの苦情は毎日届くという乖離が起きました。

AI エージェントで SLI を定義するときの鉄則は次のとおりです。

  • 決定論的な成功条件と確率的な品質評価を分ける(どちらか片方では足りない)
  • ユーザーが実際に感じる価値の観点で測る(内部 API のステータスではなく、タスクが完了したか)
  • サンプリング評価を前提にする(全件を LLM-as-a-Judge に通すとコストが爆発する)

以降では、これを具体的にどう実装するかを見ていきます。

SLI を 3 層で定義する

私が現在運用している Antigravity エージェントの SLI は 3 層構造です。それぞれが違う信頼性の側面を測っています。

第 1 層: インフラ SLI(従来型)

ここは通常の Web サービスと同じです。

  • リクエスト成功率(HTTP 5xx を除いたレスポンス割合)
  • レイテンシ P95 / P99
  • タイムアウト率

これだけでは足りませんが、ここが壊れているとそもそも次のレイヤーの議論に進めないので、まず押さえます。

第 2 層: タスク完了 SLI(決定論的)

エージェントが「タスクを完了した」と主張していることを、コード側で確認できる範囲で検証します。

  • ツール呼び出しが成功したか(例: git commit が exit code 0 だったか)
  • 出力が指定した JSON スキーマに一致するか
  • 生成されたコードが TypeScript の型チェックを通るか
  • テストが実行可能で、パスしているか

これは LLM ではなく普通のプログラムで判定できるので、全件に対してリアルタイムで計装します。

第 3 層: 品質 SLI(確率的)

ここで初めて LLM-as-a-Judge が登場します。

  • 出力が要求仕様を満たしているか
  • コードのスタイルが規約に沿っているか
  • 回答がハルシネーションを含んでいないか

これは高価なので、全トラフィックの 5〜10% にサンプリングして評価するのが現実的です。

この 3 層の切り分けを飛ばして、いきなり LLM-as-a-Judge でぜんぶ測ろうとすると、コストが月 10 万円単位で膨らむうえに、評価の揺らぎで SLO が安定しません。私はこの罠に最初の 3 ヶ月でハマりました。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
『AI は気まぐれだから本番に置けない』で止まっていた設計判断を、数値化された信頼性目標に変えて前に進められる
LLM-as-a-Judge と決定論的チェックを組み合わせた SLI の計装コードを、自分のプロジェクトにそのまま持ち込める
エラーバジェットを残量で自動停止する仕組みまで実装でき、深夜のアラートに叩き起こされる前に予防できる
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

Agents & Manager2026-05-22
Antigravity Agent のフォールバック階層設計 — モデル劣化・API障害・コスト超過を 4 段で受け止める Resilience アーキテクチャ
AI エージェントの本番運用で起きる『モデル応答劣化・API障害・コスト超過』を 4 段階のフォールバック階層で受け止める設計を、6 アプリ並行運用の実装ログとともに整理しました。
Agents & Manager2026-05-11
AI エージェントのカナリアデプロイと自動ロールバック — Antigravity と Burn-Rate SLO で本番を守る
AI エージェントの新バージョンを Antigravity 上でカナリアデプロイし、Burn-Rate SLO で自動ロールバックする実装パターン。個人開発でも回せる軽量運用のコード例付きで詳しく書きました。
Agents & Manager2026-04-28
Antigravity Agent 本番障害対応 Runbook 設計 — 検知から復旧・再発防止までの実践フレームワーク
Antigravity Agent の本番障害に備える Runbook 設計の完全ガイド。検知・トリアージ・復旧・ポストモーテムまでを実装コード付きで体系化します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →