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

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

AI エージェントは確率的に動く以上、SRE の考え方なしに本番運用はできません。SLI/SLO/エラーバジェットを Antigravity エージェントに適用する実装コードと、緩い SLO ではバーンレート 14.4 倍のアラートが発火しない数式上の落とし穴まで、運用判断の基準を書き残します。

antigravity464sreslo3error-budgetproduction59reliability6agents100

✦ プレミアム記事

ストアのレビュー返信の下書きをエージェントに任せはじめた頃のことです。ダッシュボードは何週間も緑のままなのに、朝に下書きを開くと、手直しが必要な日が続いていました。

HTTP の 200 は返っていて、エラー率もゼロに近いのです。それでも「使える下書き」の割合は、画面のどこにも出ていません。胃のあたりが重くなるあの感覚を、今でも覚えています。

最初にお伝えしたいのは、確率的に動くエージェントでも、SRE の古典的な道具である SLI / SLO / エラーバジェットで本番運用は組み立てられるということです。ただし、従来の Web サービスと同じ形で SLI を定義すると、緑の画面だけが残ります。ここから先では、定義の仕方、計装コード、そして私が数式を確かめていて気づいた「設定したのに鳴らないアラート」の落とし穴まで、順に書き残します。

評価の土台は AI モデル評価・テストフレームワーク と、計装側は LangFuse によるエージェント可観測性 とあわせて読んでいただくと、計装から意思決定までの流れが辿りやすくなります。

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

Google の SRE Book に出てくる SLI の典型は「HTTP リクエストの成功率」や「レイテンシが一定値以下の割合」です。ところがエージェントに「このコードベースをリファクタリングしてください」と頼んだとき、200 OK で返ってきた応答が成功かどうかは、差分を読むまで分かりません。

私が最初に書きかけたのは、is_success = response.status == 200 という雑な SLI でした。この定義だと、意味の通らない差分を返したエージェントも「成功」に数えられます。メトリクスは完璧、でも使う側の手間は減らない——この乖離こそが、最初の落とし穴です。

もう一つ、起こりやすい例を挙げます。完了の定義を「エージェントが submit_result ツールを呼んだこと」にすると、エージェントが空の引数で submit_result を呼ぶだけで SLI が満たされてしまいます。エージェントが悪いわけではありません。測りやすいものを目標にすると、最適化はその人工物に向かうのです。

エージェントの SLI を決めるときの線引きは、次の 3 つです。

  • 決定論的な成功条件と、確率的な品質評価を分ける——どちらか片方では足りません
  • 内部 API のステータスではなく、ユーザーが感じる価値(タスクが終わったか)で測ります
  • 全件を LLM-as-a-Judge に通すとコストがかさむため、サンプリング評価を前提にします

SLI の定義を後から変えると、アラートも運用手順も合意事項も、その上に積んだものをすべて組み直すことになります。コードを書く前に、定義だけで 1 週間かけても惜しくありません。

SLI を 3 層で定義する

私が組んでいるエージェントの SLI は 3 層です。それぞれが、信頼性の別の側面を測ります。

層何を測るか判定方法計測頻度
第 1 層 インフラリクエスト成功率、P95/P99 レイテンシ、タイムアウト率従来の Web 監視と同じ全件
第 2 層 タスク完了ツール呼び出しの成否、スキーマ一致、型チェック、テスト通過普通のプログラム(決定論的)全件
第 3 層 品質要求充足、規約遵守、ハルシネーションの有無LLM-as-a-Judge と人の目サンプリング(数%〜10%)

第 1 層だけでは足りませんが、ここが壊れていると次の層の議論に進めないため、まず押さえます。第 2 層は LLM を使わずにコードで判定できるので、全件をリアルタイムで計装します。第 3 層は費用がかさむため、別ジョブで回します。

この切り分けを飛ばして、いきなり全部を LLM-as-a-Judge で測ろうとすると、コストが膨らむうえに、評価の揺らぎで SLO が安定しません。私はこの順番を取り違えて、手戻りを経験しました。

✦

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

この記事の続きを読む

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

この記事で得られること
✦『AI は気まぐれだから本番に置けない』で止まっていた設計判断を、数値化された信頼性目標に変えて前に進められる
✦LLM-as-a-Judge と決定論的チェックを組み合わせた SLI の計装コードを、自分のプロジェクトにそのまま持ち込める
✦SLO の値から発火可能なバーンレートの上限を逆算でき、『設定したのに一度も鳴らないアラート』を事前に潰せる
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

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

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

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

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

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

関連記事

◈ Agents & Manager2026-05-11
AI エージェントのカナリアデプロイと自動ロールバック — Antigravity と Burn-Rate SLO で本番を守る
AI エージェントの新バージョンを Antigravity 上でカナリアデプロイし、Burn-Rate SLO で自動ロールバックする実装パターン。個人開発でも回せる軽量運用のコード例付きで詳しく書きました。
◈ Agents & Manager2026-04-28
Antigravity Agent 本番障害対応 Runbook 設計 — 検知から復旧・再発防止までの実践フレームワーク
ツールを200回呼び出して止まらなくなった深夜の障害経験から、Antigravity Agent 向け Runbook の設計を体系化しました。検知・トリアージ・復旧・ポストモーテムの4段階を、個人開発でも回せる軽量フォーマットと実装コード付きで解説します。
◈ Agents & Manager2026-05-27
Antigravity Agent の Record & Replay — 失敗を3分で再現する本番運用パターン
Antigravity の自律エージェントが本番で失敗した瞬間を、後からオフラインで決定的に再生する Record & Replay の設計と実装。実際に運用してきた経験から、ストレージ設計・PII マスク・ハーネスのコードまで具体的に解説します。