「分からない」とき、どこを止めるべきか

判断できないときに確定処理を止める設計を、fail-closedと呼びます。本人確認が不明なのに機密情報を見せない、重複か不明なのに顧客を統合しない。こうした境界では合理的です。

しかし一つの外部依存が落ちたことで、無関係な読取や受付事実まで失う必要はありません。処理を、受付、判定、確定、通知へ分けると、止めるべき部分と継続できる部分が見えます。

問い合わせ基盤では、外部判定が不明なときの動作を、無条件成功と全面停止の二択にしません。受け付ける量を制限し、後で追える状態にし、危険な後続処理へ自動で進めない、といった限定的な縮退を設計します。

限定する軸には、時間、件数、送信元、使える機能、後続の権限があります。何を許すかだけでなく、いつ通常運転へ戻し、保留分をどう再確認するかまで決めます。

受付を止めれば、電話や別のメールへ連絡が移り、記録が分散します。社内では復旧確認、問い合わせ対応、再入力が増えます。「安全に失敗した」処理が、別の危険な手作業を生むことがあります。

一方で、誤った権限や削除を通した損失は、後から回収できません。可用性の数値だけでなく、止めたときに人がどの迂回路を使うかまで観察します。

各処理について、正しい成功、明確な失敗、判断不能を書きます。次に、誤成功と停止の影響、戻せるか、後で再判定できるか、誰が保留を解くかを決めます。

「安全のため止める」は結論ではありません。何を守るために、どの責任だけを止め、何を限定して続けるのか。その説明ができて初めて、障害時の動作が設計になります。

外部の確認が一時的にできないとき、全部を止めれば誤った成功は減らせます。しかし、正当な利用者を止める、入力を失わせる、現場が別の経路へ戻る、といった損失が出ます。反対に何でも通せば、後から戻せない誤りや不正な処理を作るかもしれません。

そこで処理を分けます。結果を確定して外部へ影響を出す操作は、情報が足りないなら止める。下書きを保存する、受付の事実を失わない、後で再確認できる状態に置く、といった操作は、限定して続けられることがあります。これはfail-openかfail-closedかの標語ではなく、責任の違う処理へ異なる挙動を選ぶ話です。

不明とエラーも同じではありません。明確に拒否されたのか、応答が失われたのか、まだ確認していないのかを混ぜると、復旧の選択を誤ります。利用者へ何を表示し、内部で何を保留し、誰がいつ再確認するかまで決めて初めて、安全性と可用性を両立できます。