はじめに
これまでの記事で、Harness、Loop Engineering、Evaluation、Context Engineering、Tool Engineering、Memory、Observabilityと、AIエージェントを支える要素を一つずつ見てきました。
今回はRecovery、つまりAIエージェントが失敗したときにどう復旧するかについて掘り下げます。AIは必ず間違えます。それを前提にした上で、失敗をどう扱うかを設計しておくことが、Recovery Engineeringの本質です。
1. Recovery Engineeringとは何か
Recovery Engineeringとは、AIエージェントが失敗したときに、安全かつ的確に復旧できる仕組みを設計することです。
失敗をゼロにすることを目指すのではなく、失敗が起きることを前提として、そこからどう立ち直るかに焦点を当てます。これはこの連載を通して何度も触れてきた考え方ですが、今回はこの復旧そのものを主役として扱います。
2. なぜ「失敗しない設計」ではなく「失敗から戻る設計」なのか
AIエージェントに「絶対に間違えないように」という制約を積み重ねていくと、プロンプトやルールがどんどん複雑になっていきます。それでも、あらゆる失敗を事前に防ぐことは現実的に難しいです。
コード生成であればテストの失敗、API連携であれば通信エラー、ファイル操作であれば権限エラーなど、失敗の種類は多岐にわたります。すべてを事前に予測してルール化するのは、ほぼ不可能です。
そこで発想を変え、失敗は起きるものとして扱い、起きたときにどう対処するかを設計しておく。これがRecovery Engineeringの基本姿勢です。
3. 失敗の種類を整理する
Recoveryを設計する前に、どんな失敗が起こり得るのかを整理しておくと、対応方針も立てやすくなります。
一つは、一時的な失敗です。ネットワークの瞬断や、外部サービスの一時的な不調など、時間をおいて再試行すれば解決する可能性が高いものです。
もう一つは、恒久的な失敗です。存在しないファイルを参照しようとした、権限が足りない、といった、単純な再試行では解決しないものです。
さらに、部分的な失敗もあります。タスク全体は完了したが、一部の処理だけがうまくいかなかった、というケースです。
これらを区別せずに一律の対処をしてしまうと、無駄なリトライを繰り返したり、逆に本来なら回復できたはずの失敗を諦めてしまったりします。
4. リトライという基本戦略
もっとも基本的なRecoveryの手段はリトライです。一時的な失敗であれば、同じ操作をもう一度試すだけで解決することが少なくありません。
ただし、無条件にリトライを繰り返すと、根本的な問題を放置したまま同じ失敗を繰り返すだけになってしまいます。リトライの回数に上限を設ける、リトライの間隔を徐々に広げる、といった工夫が必要です。
また、リトライしても解決しない失敗については、次の手段に切り替える判断が求められます。
5. フォールバックという考え方
リトライで解決しない場合の次の手段として、フォールバックがあります。
別のツールを試す、別のアプローチを取る、より単純な方法に切り替える、といった選択肢です。例えば、あるAPIが利用できない場合に別の手段でデータを取得する、特定のライブラリが使えない場合に代替の実装に切り替える、といったイメージです。
フォールバックを用意しておくことで、単一の手段に依存しすぎず、失敗があってもタスク全体を止めずに進められる可能性が高まります。
6. Human Escalationという最後の手段
リトライやフォールバックでも解決できない失敗については、人間に判断を委ねる、Human Escalationという選択肢があります。
すべてをAIだけで解決しようとすると、無理に間違った対応を選んでしまうリスクがあります。判断が難しい状況や、重大な影響を及ぼしかねない状況では、AIが「これ以上は自分で判断せず、人間に確認を求める」という選択ができることも、健全なRecoveryの一部です。
どこまでをAIの裁量に任せ、どこから人間の確認を挟むか。この境界線をあらかじめ決めておくことが、安全なエージェント設計につながります。
7. Rollbackという安全装置
コードの変更やファイルの操作など、状態を書き換える系の作業では、Rollback、つまり以前の状態に戻せる仕組みが重要になります。
Gitのようなバージョン管理があれば、AIが誤った変更を加えても、以前のコミットに戻すことができます。データベースの操作であれば、トランザクションを使って、途中で失敗した場合に変更を取り消せるようにしておく、といった工夫も同様です。
Rollbackの仕組みがあると、AIに大きな裁量を与えても、最悪の事態を避けやすくなります。これは以前の記事で扱ったHarnessの話とも重なる部分です。
8. 失敗を例外ではなく通常状態として扱う
Recovery Engineeringの根っこにある考え方は、失敗を例外的な出来事として扱うのではなく、通常起こり得る状態の一つとして設計に組み込む、という姿勢です。
失敗を例外として扱うと、それが起きたときにシステム全体が止まってしまったり、想定外のエラーとして扱われてしまったりします。一方で、失敗を通常のフローの一部として組み込んでおけば、
失敗する → 検出する → 原因を分析する → 修正する → 再実行する
という流れが、特別なことではなく、いつも通りの動きとして処理されるようになります。
9. RecoveryとObservabilityの関係
Recoveryを適切に機能させるには、前回取り上げたObservabilityが欠かせません。何が失敗したのか、どこで失敗したのかが記録されていなければ、どのRecovery手段を選べばいいのか判断できないからです。
一時的な失敗なのか、恒久的な失敗なのか、部分的な失敗なのか。この判断も、実行結果やログといったObservabilityの情報があってはじめて可能になります。
RecoveryとObservabilityは別々のテーマとして扱われがちですが、実際には強く結びついた関係にあります。
10. まとめ
Recovery Engineeringは、AIエージェントが失敗しないようにすることではなく、失敗したときに安全かつ的確に立ち直れるようにすることを目指す設計です。
リトライ、フォールバック、Human Escalation、Rollback。これらの手段を組み合わせ、失敗の種類に応じて適切に切り替えられるようにしておくことで、AIエージェントは失敗を恐れずに大きな仕事に挑めるようになります。
失敗を例外ではなく通常の状態として扱うこと。これがRecovery Engineeringの根本にある発想であり、AIエージェントに裁量を持たせるための土台にもなっています。
次回は、人間とAIの関わり方そのもの、Human-in-the-loopからAgent-in-the-loopへの変化について掘り下げていきます。
関連記事
- AIエージェントで本当に重要なのはLLMではない？Harness EngineeringとLoop Engineeringから考える次世代AI開発（全体像）
- Harness Engineeringとは何か？AIエージェントの性能を決める「実行環境」の設計
- Loop Engineeringとは何か？AIエージェントを「失敗から改善するシステム」に変える方法
- AIエージェントの評価（Evaluation）設計入門
- Context Engineeringとは何か？AIエージェントに「何を見せるか」を設計する
- AIエージェントのTool Engineering入門
- AIエージェントにおけるMemory設計
- AIエージェントのObservability設計
- Human-in-the-loopとは何か（次回予定）
Tags
AI AIエージェント Recovery LLM AgenticAI