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

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

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

antigravity346agentkit12self-healingproduction53observability11

プレミアム記事

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

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

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

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

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

私が運用している3つのエージェント(決済サポート、コードレビュー、SEO レポート)の障害ログを集計したところ、過去90日間で発生した1,247件のエラーは以下のように分類できました。

  • 外部 API のレート制限・タイムアウト: 671件(53.8%)
  • 依存サービスの瞬間的なダウン: 198件(15.9%)
  • LLM 側の不安定なレスポンス(JSON パース失敗・空応答等): 274件(22.0%)
  • コード起因の本物のバグ: 104件(8.3%)

つまり9割以上は「待てば直る」あるいは「別の手段に切り替えれば直る」性質のものでした。にもかかわらず、私のエージェントは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-29
Antigravity 長時間実行エージェントの監視設計 — watchdog と段階的リカバリ
AdMob 収益最適化を 8 週間バックグラウンドエージェントに任せて見えた、長時間タスクが静かに停止する 3 つの故障モード。watchdog タイマーと段階的リカバリの実装メモを残します。
Agents & Manager2026-05-27
Antigravity Agent の Record & Replay — 失敗を3分で再現する本番運用パターン
Antigravity の自律エージェントが本番で失敗した瞬間を、後からオフラインで決定的に再生する Record & Replay の設計と実装。Dolice Labs 4 サイトを並行運用してきた経験から、ストレージ設計・PII マスク・ハーネスのコードまで具体的に解説します。
Agents & Manager2026-05-20
Antigravity AIエージェントの『知識鮮度』を運用設計する — モデルカットオフ・コーパス老朽化・実世界時刻ずれを本番で扱う時間管理アーキテクチャ
Antigravity で動かす AI エージェントは、モデル側・RAG コーパス側・実世界側の三つの時間軸を別々に管理しないと、半年前のドキュメントを根拠に古い実装を提案してきます。Freshness Oracle と時間認識プロンプトで知識の鮮度を運用設計する実装パターンを、TypeScript の動くコードとともに整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →