F-12: Fail-fast vs 縮退継続¶

この相反は何か¶

AI エージェントがエラーや異常に遭遇したとき、「即座に処理を中断して明示的にエラーを返すか（fail-fast）、それとも品質や機能を落としながらも処理を継続するか（縮退継続）」という二択が F-12 の相反です。

この選択が排他的になる理由は、エラー発生時の振る舞いが「停止する」か「続行する」かの二値であるためです。中間はありません。もちろん、エラーの種類ごとに異なる方針を適用する（あるエラーは fail-fast、別のエラーは縮退）ことは可能ですが、個々のエラー発生時点では必ずどちらかを選ぶことになります。

AI エージェント特有の考慮点として、エージェントの出力は「部分的に正しいが部分的に誤っている」状態が頻繁に発生します。従来のソフトウェアでは処理結果が正しいか間違いかの二値に近いですが、LLM ベースのシステムでは「10 項目中 8 項目は正しいが 2 項目は不正確」といったグレーゾーンが日常的に生じます。このとき部分結果を返すことが有益か危険かが、この相反の核心です。

選択肢A：Fail-fast¶

Fail-fast とは、エラーや品質基準の未達を検知した時点で即座に処理を中断し、明示的なエラーレスポンスを返す方式です。部分的な結果は破棄されるか、エラーであることを明示したうえで返却されます。

Fail-fast の最大の強みは安全性の確保です。不完全な結果が「正常な結果」として下流に流れることを防ぎます。特に [failure_cost] が高い領域---金融取引、医療判断、法的文書生成---では、部分的に誤った結果が正しいものとして扱われることの損害は、処理が中断されて再試行が必要になるコストを大幅に上回ります。

また、エラーの早期検出と迅速な対応が可能になります。問題が発生した時点で即座にアラートが上がるため、根本原因の調査と修正が迅速に行えます。縮退継続では問題が隠蔽され、後から発覚したときには影響範囲が広がっている可能性があります。

一方、ユーザー体験への影響があります。長時間の処理が最終段階で中断されると、それまでの処理時間と消費トークンが無駄になります。特に対話型のシステムでは、エラーメッセージだけを返されるユーザーの不満は大きくなります。

選択肢B：縮退継続（Graceful Degradation）¶

縮退継続とは、エラーや品質劣化を検知しても処理を完全には中断せず、品質や機能を落としながらも何らかの結果を返す方式です。取得できたデータの範囲で回答する、精度の低いフォールバックモデルに切り替える、一部の機能を無効にして残りを提供する、といった戦略を取ります。

縮退継続の最大の強みは可用性の維持です。エージェントが完全に停止するより、部分的でも結果を返す方がユーザーにとって有用な場合が多くあります。たとえば、10 件のドキュメントを要約するタスクで 2 件の取得に失敗した場合、8 件分の要約を返す方が、エラーメッセージだけを返すよりも有用です。

また、リトライによるコスト増加を抑制できます。Fail-fast で処理全体を再実行すると、成功していた部分のトークンも再消費します。縮退継続では成功した部分を活かして失敗した部分だけを補完するため、再処理のコストが抑えられます。

ただし、致命的なリスクがあります。部分的な結果が「完全な結果」と区別できない場合、下流のシステムやユーザーが不完全な情報に基づいて意思決定を行ってしまいます。特に、どの部分が欠落・劣化しているかが明示されない縮退は、偽りの安心感（false confidence）を生み出し、fail-fast よりも危険な結果を招くことがあります。

選定基準¶

この相反の選定は [failure_cost] と [latency_budget] の二つの駆動変数で決まります。

Fail-fast を選ぶべき条件：

[failure_cost] が高い場合。部分的に誤った結果が下流に流れたときの損害が大きいなら、処理を止める方が安全です。金融取引、医療判断、法的助言などの領域です。
部分結果と完全結果の区別がつきにくい場合。縮退で返された結果が「完全な結果」と誤解されるリスクがあるなら、fail-fast の方が安全です。
[accountability] が高い場合。「なぜこの不完全な結果を返したのか」の説明が求められる環境では、明示的なエラーの方が管理しやすいです。

縮退継続を選ぶべき条件：

[failure_cost] が低い場合。部分的な結果でもないよりはましであり、誤りが許容される領域です。
[latency_budget] が長く、部分結果をユーザーに提示しながら残りを処理できる場合。対話型アシスタントでは「現時点で分かっていること」を先に返し、追加情報を後から提供できます。
部分結果の品質劣化が明示的にユーザーに伝達できる場合。「3 件中 1 件のソースが取得できませんでした」のように、何が欠けているかが明確に伝えられるなら、縮退は有用です。

デフォルトとハイブリッド¶

デフォルト：部分結果が危険なら fail-fast、部分結果が有用なら縮退継続です。判断に迷ったら、「この部分結果に基づいてユーザーが行動した場合、取り返しのつかない損害が生じうるか」を自問します。答えが Yes なら fail-fast です。

ハイブリッド：段階的縮退ラダー（degradation ladder）が一般的な折衷案です。エラーの深刻度に応じて複数段階の縮退レベルを定義します。

レベル1（軽微）：一部データ欠損 → 欠損を明示して残りを返す
レベル2（中程度）：主要モデル障害 → フォールバックモデルに切り替え、品質低下を明示
レベル3（重大）：核心データの欠損や整合性エラー → fail-fast

この構成は A6 Adaptive Timeout & Budget-Bounded Retry パターンのエラー分類と組み合わせて運用します。

判断を誤ったときの症状¶

Fail-fast を選んだが縮退継続が適切だった場合の症状：

エラー率（5xx レスポンス率）が高く、実際にはユーザーに有用な部分結果を返せるケースが大半を占めています。
エラー発生後の全量リトライにより、トークンコストが想定を大幅に超えています。
ユーザーから「途中まで良かったのに最後でエラーになった」「何も返ってこないより一部でも見せてほしい」という不満が寄せられます。
可用性 SLA を維持できておらず、大半は部分的な機能提供で十分対応可能です。

縮退継続を選んだが fail-fast が適切だった場合の症状：

部分結果に基づいた意思決定でインシデントが発生しています。「全件出ていると思っていたが、実は半分しか含まれていなかった」「フォールバックモデルの精度が低いまま本番で使われていた」などです。
縮退レベルの管理が複雑化し、どの程度の劣化が許容されるかの基準が曖昧になっています。
下流システムが「正常レスポンス」と「縮退レスポンス」を区別できておらず、不完全なデータでバッチ処理が走っています。
モニタリングで問題が検知されにくく、長期間にわたって縮退状態が続いていたことに後から気づきます。