用語の意味
リクエスト経路上にあるどのチェックも、回答を返せずに失敗することがあります。依存先がタイムアウトする、シグナルが欠ける、キーを取得できない、といった場合です。Fail open は、そのチェックが存在しなかったものとしてリクエストを進めることを意味します。Fail closed は、より厳格な経路を取ることを意味します。つまり、拒否されるか、チャレンジされるか、既存のより強い制御に送られます。
どちらも一般論として正しいわけではありません。適切な選択は、そのルートが何をするか、そして誤った判断にどれだけのコストがあるかによって決まります。
アクターチェックで重要な理由
アクターチェックは、リクエストに文脈を加えます。やり取りが人間によるものか、AI 支援か、エージェント主導か、あるいは不明かを示します。その文脈が利用できない場合でも、アプリケーションは応答しなければなりません。よくある失敗パターンは 2 つです。
- 誤って fail closed になる場合。 タイムアウトやシグナル不足が不審とみなされ、障害中に実ユーザーがブロックされます。
- 重要な操作で誤って fail open になる場合。 結果が欠けているのに黙って人間として扱われ、想定よりも低い厳しさで高影響の操作が進みます。
どちらも、判断を暗黙のままにしていることから起こります。対処法は、ルートごとに明示的に決めることです。人間と AI エージェント向けのアプリケーションレベルのポリシー設計についての記事では、失敗時の挙動がルートごとのポリシーにどう組み込まれるかを示しています。
選び方
実用的には、ルートをリスク層ごとに分けるのがよいでしょう。
- 低影響（公開ページ、ドキュメント、読み取り専用のカタログルート）: fail open。アクター結果が欠けても、何も変えるべきではありません。
- 中程度の影響（サインアップ、フォーム送信、コストのかかる検索）: 通常はログを残して fail open にするか、標準的なレート制限のような軽い適応を適用します。
- 高影響（アカウント変更、データのエクスポート、元に戻せない操作）: 既存のより強い制御に対して fail closed にします。たとえば再認証や確認です。ここでのポイントはブロックすることではなく、通常ならともかく使うはずのチェックに戻すことです。
そのうえで、関連するケースにも同じ振る舞いを定義します。
- タイムアウト: チェックが時間内に応答しなかった。
- テレメトリ不足: 統合が動いていなかった、またはシグナルが存在しなかった。
- Unknown: チェックは実行されたが、証拠が判断を支えなかった。
- 古い証拠: 結果が以前のものであり、より機微な操作に再利用すべきではない。
よくある誤解
- 「fail closed のほうが安全だ」。それは正当なユーザーにコストを移します。低影響のルートでは、障害時に fail closed にすると、防ぎたいリスク以上の害を生むことがあります。
- 「Unknown は失敗だ」。Unknown は有効な結果です。専用の明示的な扱いが必要であり、それがタイムアウト時の扱いと一致するとは限りません。
- 「結果が欠けているなら人間だ」。証拠がないことからアクタークラスを推測してはいけません。
Proof of Actor での扱い
Proof of Actor は、タイムアウトや Unknown の結果に Human を割り当てることはありません。また、導入しても何もブロックしません。チームは 観測モード から始めます。各ルートとリスク層で fail open か fail closed かをどうするかは、アプリケーション所有者が決めることであり、Route を通じて自分たちのコードで適用します。これにより、強制の挙動を予測しやすく保ち、ポリシーを本番に出す前に結果を確認できます。
ルーティングの判断がどこに入るか を読むか、早期アクセスに申し込む かしてください。