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

Antigravity Self-Healing エージェントの設計実装 — 障害検知・自己診断・自動復旧のプロダクションパターン

Antigravity でエージェントを本番運用する際に避けて通れない『障害検知→自己診断→自動復旧』の3層設計。AgentKit 2.0 を使った具体的なラッパー実装と、私が深夜に呼び出された経験から得た落とし穴を共有します。

antigravity470agentkit13self-healingproduction59observability17

✦ プレミアム記事

午前3時14分。Slack の通知音で目が覚めました。「決済処理のサポートエージェントが応答していません。チケットが27件溜まっています」。

寝ぼけ眼でラップトップを開くと、Antigravity の Manager Surface に並んだログには「tool_call_failed: stripe.list_invoices」が延々と続いていました。原因は Stripe API の一時的なレート制限。エージェントは1度の失敗で諦め、以降のチケットすべてに同じエラーを返していたのです。

この夜、私は「障害が起きたときに自分で立ち直れるエージェントを作らないと、自分の睡眠が削られ続ける」と痛感しました。本記事は、その夜から半年かけて整えた Self-Healing エージェントの設計図 をそのまま共有するものです。Antigravity の AgentKit 2.0 で動く具体的なコードと、本番投入で踏み抜いた罠を交えてお話しします。

なぜ「自己修復するエージェント」が必要なのか

エージェントを本番運用してみると、教科書には書かれていない事実に気付きます。失敗の大部分はコードのバグではなく、外部依存の一時的な不調だということです。

決済サポート、コードレビュー、SEO レポートの3つのエージェントを動かしながら、障害ログを次の四つに仕分けてみました。正確な件数は記録しておりませんので割合は載せませんが、仕分けた結果の傾向ははっきりしていました。

分類ログに出る例基本の対応
外部 API のレート制限・タイムアウト429、deadline exceeded待つ(バックオフ)
依存サービスの一時的なダウン5xx、接続拒否切り替える(フェイルオーバー)
LLM 側の不安定な応答JSON パース失敗、空応答再生成する、検証を足す
コード起因のバグ型の不一致、想定外の None直す(リトライは禁物)

大半は上の三行、つまり「待てば直る」か「別の手段に切り替えれば直る」ものでした。にもかかわらず、私のエージェントは1度失敗すると黙り込んでいたのです。ご自身のログも、まず四つに仕分けてみてください。リトライで救える失敗と救えない失敗の線引きが、それだけで見えてきます。

ここで重要なのは「リトライを足せば解決する」と短絡しないことです。素朴なリトライは雪崩を引き起こします。 Stripe API がレート制限を返している最中に5回リトライすれば、ペナルティが伸びるだけ。本物のバグに対してリトライすれば、同じエラーログが100倍に膨らむだけです。

必要なのは「何が起きているかを自分で診断し、状況に応じた復旧戦略を選べるエージェント」です。これを私は Self-Healing エージェントと呼んでいます。

Self-Healing 設計の3層モデル — 検知・診断・復旧の責任分離

私が辿り着いた設計は、責任を3つのレイヤーに分けるものです。1つの巨大な try-except で全部を抱え込むのではなく、それぞれのレイヤーが明確な仕事を持ちます。

  • レイヤー1: 検知(Detection) — 「いま正常か、異常か」を判定します。ヘルスシグナル収集とアラート発火を担当
  • レイヤー2: 診断(Diagnosis) — 「どんな種類の異常か」を分類します。エラーの種類と影響範囲を判定し、復旧戦略を選びます
  • レイヤー3: 復旧(Recovery) — 「具体的にどう立ち直るか」を実行します。リトライ、フォールバック、デグレード、サーキットブレーカーなど

この分離が効くのは、各レイヤーを独立してテスト・改善できるからです。たとえば検知ロジックを変えるだけで「サイレント障害(エラーログが出ていないのに結果が間違っている状態)」を捕まえられるようになります。診断レイヤーを足すだけで、新しいエラーパターンに対する戦略を後から追加できます。

なぜこの分離が重要なのかというと、復旧コードは本番中に最も触れたくないコードだからです。深夜に「とりあえずリトライ回数を増やそう」とコードを書き換えると、別の障害を呼び込みます。検知と診断を別レイヤーに切り出しておけば、復旧ロジックを安定させたまま、新しい障害パターンを上のレイヤーで吸収できます。

✦

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

この記事の続きを読む

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

この記事で得られること
✦本番のエージェントが黙って失敗し続ける問題を、3層の異常検知パイプラインで早く見つけ、ユーザーへの影響を小さく抑えられるようになります
✦ヘルスチェック・自己診断・自動復旧の3段階フェイルセーフを Antigravity AgentKit 2.0 で実装するコードパターンを今日から自分のプロダクトに移植できます
✦復旧履歴をトレースに記録して継続的に改善するフィードバックループを構築し、『夜中に呼び出される運用』から抜け出すための判断軸を持てるようになります
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

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

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

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

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

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

関連記事

◈ Agents & Manager2026-05-27
Antigravity Agent の Record & Replay — 失敗を3分で再現する本番運用パターン
Antigravity の自律エージェントが本番で失敗した瞬間を、後からオフラインで決定的に再生する Record & Replay の設計と実装。実際に運用してきた経験から、ストレージ設計・PII マスク・ハーネスのコードまで具体的に解説します。
◈ Agents & Manager2026-04-28
Antigravityで運用するAIエージェントのプロンプトをバージョン管理してA/Bテストする実践設計
なんとなく良くなった気がするというプロンプト改善から卒業するため、プロンプトレジストリによるバージョン管理と A/B テストの分配ロジックを設計します。評価メトリクスと統計判定、チャンピオン昇格とロールバックの自動化まで実装コードで示します。
◈ Agents & Manager2026-05-12
Antigravity エージェントの判断を追跡する — 意思決定ログと説明可能性の実装設計
AIエージェントが「なぜその判断をしたか」を記録・分析する意思決定ログの設計を、動作するPythonコード例とともに解説します。本番環境での予期しない動作を根本から追跡し、品質改善サイクルを実装します。