【ITニュース解説】Fail closed: if a command doesn't say staging, treat it as production

ソフトウェア開発では、私たちが作ったプログラムが実際に動く「本番環境」と、リリース前のテストを行う「ステージング環境」という二つの重要な場所がある。本番環境は、ユーザーが直接利用する、まさに稼働中のシステムだ。ここに誤った変更を加えてしまうと、多くのユーザーに影響を与え、ビジネスに大きな損害をもたらす可能性がある。一方、ステージング環境は、本番環境とほぼ同じ構成を持つテスト環境で、新しい機能や修正をリリースする前に最終確認を行う場所だ。

これらの環境に対して、システム操作の指示、つまり「コマンド」を実行する場面は頻繁に発生する。この際、あるコマンドがどちらの環境に向けたものなのかを正しく判断することは非常に重要となる。しかし、この判断を自動化するコードを書くとき、システムは二種類の「間違った答え」を出す可能性がある。これは、コマンドの種類が明確でない「未知のケース」をどう扱うかによって結果が変わってくるためだ。

一つ目の誤りは、未知のコマンドを「ステージング環境向けの安全な操作」と判断してしまうケースだ。もしシステムが「このコマンドはステージング環境用だろう」と安易に仮定してしまったら、実際には本番環境に影響を与える可能性のある危険なコマンドだったとしても、システムは警告を発することなく、そのまま実行してしまうかもしれない。このような事態が発生すると、ユーザーに影響が及ぶ重大なシステム障害、いわゆる「インシデント」につながる可能性が高い。本番環境で予期せぬデプロイ（システム更新）が実行されたり、重要なデータが削除されたりといった事故が起こるのだ。

二つ目の誤りは、未知のコマンドを「本番環境向けの危険な操作」と判断してしまうケースだ。この場合、システムは「このコマンドは本番環境に影響を与えるかもしれない」と考え、たとえ実際には無害なコマンドであったとしても、念のための確認メッセージ（プロンプト）を表示したり、追加の認証を求めたりする。これは、ユーザーにとっては少し手間が増えるだけで、煩わしく感じるかもしれない。

この二つの間違いを比較すると、どちらがより深刻かは明らかだ。一つ目の間違いは、システムの安定性や信頼性を損なう重大な事故を引き起こす可能性がある。一方、二つ目の間違いは、一時的な不便さをもたらすだけで、システム自体には実害がない。このため、システム設計においては、未知のケースを扱う際に「安全側に倒す」という原則が非常に重要になる。これを「フェイルクローズド（Fail closed）」と呼ぶ。システムが判断に迷った場合は、安全な状態、つまり「閉じている」状態に移行し、危険な操作が勝手に実行されることを防ぐという考え方だ。

記事で紹介されている「Styx」というツールは、まさにこのフェイルクローズドの原則を採用している。Styxでは、コマンドが「ステージング」または「本番」のどちらであるかを明示的に指定しない限り、そのコマンドは自動的に「本番環境向けの操作」と見なされる。そして、本番環境に対する書き込み、デプロイ、データの削除といった危険な操作を実行する際には、さらにTouch IDやWindows Hello、システムパスワードといった追加の認証が求められるようになっている。これは、たとえ誤って危険なコマンドを実行しようとしたとしても、意図しない事故を防ぐための二重の安全策と言える。

このフェイルクローズドの原則を効果的に適用し、システムをより安全にするためには、三つの重要なポイントがある。

一つ目のポイントは、プロンプトが頻繁に表示されることによる煩わしさを解消する方法だ。システムが未知のコマンドを本番環境向けと見なし、安全のために毎回確認を求めてくると、無害なコマンドを実行するたびに確認が必要となり、作業効率が低下する可能性がある。しかし、この問題を解決するためにシステムのデフォルト設定を緩めるのは危険だ。そうではなく、無害なコマンドであっても、それがどの環境に向けたものなのか（例えば「staging」環境向けであること）をコマンド実行時に明示的に指定させるようにする。これにより、システムはそのコマンドが安全なステージング環境向けであると正しく認識し、余計な確認を求めることなくスムーズに実行できるようになる。これは、システムが勝手に判断するのではなく、人間が意図を明確に伝えることで、安全性を保ちつつ作業効率も向上させるアプローチだ。

二つ目のポイントは、未知のケースに対するテストを最初に書くことだ。ソフトウェア開発では、さまざまな入力パターンを想定してテストを書くが、開発者が忘れがちなのが、システムが分類できない「未知の入力」に対するテストだ。この未知の入力が与えられたときに、システムが必ず「危険なバケット」、つまり本番環境への操作として処理されることを保証するテストケースを、開発の早い段階で作成しておくべきだ。これにより、予期せぬコマンドが入力されても、常に安全側に倒れる設計になっていることを確認できる。

三つ目のポイントは、フェイルクローズドの限界を正直に認識することだ。ここで述べたようなコマンドを分類するシステム（分類器）は、あくまでそのシステムを経由して実行されるコマンドしか監視できない。例えば、システムの一部がコマンドラインインターフェース（CLI）を直接呼び出したり、ハードディスクに保存された認証トークンを使ってソフトウェア開発キット（SDK）経由で操作を実行したりする場合、それらの操作はこの分類器の監視下にないため、フェイルクローズドの原則が適用されない可能性がある。つまり、フェイルクローズドは、あくまでデフォルトの安全策であり、あらゆる操作を完全に隔離して実行する「サンドボックス」のような絶対的な安全環境ではないということだ。システムの設計者は、この限界を理解し、分類器の範囲外の操作については、別途適切なセキュリティ対策を講じる必要がある。

このように、システム開発において、特に本番環境に影響を与える可能性のある操作については、常に「フェイルクローズド」の原則を念頭に置くべきだ。未知のコマンドや予期せぬ状況が発生した際に、システムがどちらに倒れるべきか。安全側に倒れる設計をすることで、一時的な不便さよりも、重大なシステム障害を防ぎ、ユーザーに安心してサービスを提供できるようになるのだ。これは、システムエンジニアが学ぶべき、非常に重要な設計思想の一つと言える。