【ITニュース解説】Deleting the option instead of defaulting it off

システム開発では、ソフトウェアが持つ様々な機能や動作を設定するための「オプション」がよく用意される。これらのオプションは、ユーザーや他のプログラムが、ソフトウェアの振る舞いを細かく調整できるようにするために不可欠なものだ。多くの開発現場では、ある機能をデフォルト（初期設定）で「オフ」にしておくというアプローチが一般的とされている。これは、その機能が多くのユーザーにとって不要である場合や、セキュリティ上の懸念がある場合、あるいは特定の条件下でのみ有効にすべき場合などに採用される。例えば、インターネットに接続する際に使う「プロキシ」の設定や、サイトにログインするための「認証情報」といったオプションは、普段は使わないためデフォルトで無効になっていることが多い。必要な人だけが、後から設定を変更して使えるようにする、という考え方だ。

この「デフォルトでオフ」というアプローチは、システムの柔軟性を保ち、将来的な機能拡張にも対応しやすいという利点がある。しかし、今回紹介する記事では、この一般的なアプローチとは異なる、非常に興味深い設計判断が語られている。それは、「絶対に設定してはいけない、あるいは設定すべきではないオプションは、デフォルトでオフにするのではなく、そもそもそのオプションをシステムから完全に削除してしまう」というものだ。

なぜ、このような大胆な選択をするのだろうか。記事の筆者は、次のように指摘している。「設定オプションとして存在し続ける限り、いつか必ずそのオプションは使われてしまう」と。これは悪意のある行為に限った話ではない。半年後、一年後といった将来、開発チームの誰かが、一見するともっともらしい理由を提示してくる可能性がある。例えば、「特定の国からしかアクセスできないウェブページをチェックする必要がある」「一時的にアクセス制限がかかっているサイトを通過したい」「自社が所有するウェブサイトなのに、なぜかログインが必要になってしまった」といった状況だ。

このような状況で、もしシステムにプロキシや認証情報を設定するためのオプションが用意されていたらどうなるだろうか。そのオプションは適切なデータ型で定義されており、コード上は何の問題もないように見える。コードレビューも、たった一行の変更であれば見落とされやすい。そして、そのオプションを「デフォルトでオフ」にした際の、元の設計意図や議論の内容は、時間の経過とともに忘れ去られてしまう可能性が高いのだ。結果として、本来許容すべきではない外部へのアクセスや、意図しない情報漏洩につながるリスクを抱えてしまうことになる。

そこで、記事の筆者が採用したのは、非常にシンプルながらも強力な解決策だった。それは、プロキシや認証情報に関する設定フィールドを、プログラムの設計図である「インターフェース」（プログラムの部品同士がどのように情報をやり取りするかを定義した取り決め）から完全に削除してしまうことだ。具体的には、ウェブページのスクリーンショット取得やリンクチェックを行う「ヘッドレスブラウザワーカー」（画面表示のないブラウザ環境で動作するプログラム）を開発するにあたり、その設定情報を定義するContextOptionsというインターフェースから、proxy（プロキシ）とcredentials（認証情報）のフィールドを一切取り除いた。

この設計では、ContextOptionsが要求するのは、ウェブページの表示サイズ（viewport）、利用環境を示す情報（userAgent）、外部へのアクセス許可リスト（egressAllowlist）、そして処理のタイムアウト時間（timeoutMs）の４つの情報のみだ。これにより、「ドライバー実装」（実際にブラウザを動かす部分）は、インターフェースが求めていないプロキシや認証情報の機能を提供しようとすること自体ができなくなる。たとえ将来、開発者が「やっぱりプロキシ設定が必要だ」と考えたとしても、インターフェースにその項目がないため、新しいフィールドを追加するにはインターフェースそのものを変更しなければならない。しかも、記事のチームは、このインターフェースの正確な形状を検証するテストも用意しているため、安易な変更はテストの失敗という形で明確に通知される。これにより、オプションの追加が「うっかり」ではなく、「意図的で議論された決定」となるよう強制しているのだ。

さらに、外部へのアクセス許可リストであるegressAllowlist（出力許可リスト）についても、特別な配慮がされている。このリストは必須項目とされ、呼び出し元のプログラムが自由に設定できるものではなく、ワーカーが自身の責任範囲として所有するポリシーに基づいて自動的に生成される。つまり、個々のタスクが勝手にアクセス範囲を広げることはできないようになっている。

この許可リストは、単に「どのウェブサイトにアクセスするか」というナビゲーション（ページの移動）だけでなく、そのページが読み込むすべての「サブソース」（埋め込みの画像、スクリプト、CSSファイルなど）にも適用される点が重要だ。もしナビゲーションだけが許可されて、サブソースはチェックされないとしたらどうなるだろう。自社のウェブページに他社の分析スクリプトが埋め込まれていた場合、ワーカーはそのスクリプトを読み込むために、許可リストにない第三者のサーバーにリクエストを送ってしまうことになる。これでは許可リストの意味が薄れてしまう。そのため、記事のワーカーは、許可されていないURLへのリクエストは、ページの作成前だけでなく、ページ内のあらゆるリソースに対しても厳しく拒否し、ブロックされたことを通知するように設計されているのだ。

このような設計は、確かに非常に厳格だ。ワーカーは、どんなウェブサイトにもログインできないし、認証が必要なページをレンダリングすることもできない。また、自社ドメイン以外のリンクをたどることも許されない。その結果、便利に思えるいくつかの機能は、共有のインターフェースを明示的に、かつ大々的に変更しなければ実現できなくなった。これが「コスト」であり、「トレードオフ」だ。開発チームは、そういった機能性を一部犠牲にしてでも、「ワーカーが絶対にやってはいけないこと」を確実に防ぐことの方が、失われる機能よりも価値があると判断したのだ。

では、このような極端とも言える設計アプローチは、どのような状況で適用すべきなのだろうか。もちろん、すべてのオプションを削除すべきではない。ほとんどのオプションは、柔軟性を保つために「デフォルトでオフ」のまま残しておくべきである。この記事が提唱する「オプション削除」というパターンがそのコストに見合うのは、以下の３つの条件がすべて当てはまる場合だと記事は述べている。

一つ目は、もしその機能が有効になってしまった場合、単なるプログラムの「バグ」（意図しない挙動）として扱われるだけでなく、「利用規約違反」（サービス提供者との契約破棄）、「プライバシー問題」（個人情報保護の侵害）、「セキュリティインシデント」（不正アクセスや情報漏洩）といった、より深刻で取り返しのつかない事態に発展する可能性がある場合だ。例えば、ユーザーの同意なしにその情報を外部サーバーに送信してしまうような機能がこれに当たる。

二つ目は、その機能を有効にすべきだという「圧力」が、後になって、しかも締め切りが迫っているような状況で、この設計判断の議論に参加していなかった人から来る可能性が高い場合だ。時間的制約や情報の欠如が、安易な有効化を招き、リスクを生む危険性がある。

三つ目は、その機能が悪用されたり、意図せず有効化されたりした場合の「影響範囲（ブラスト・ラディウス）」が、開発者自身だけでなく、「他の多くの人々」（顧客、パートナー企業、社会全体など）に及ぶ場合だ。顧客のデータ漏洩や、システム全体の信用失墜など、広範囲な被害が想定されるケースだ。

これら３つの条件がすべて揃うときこそ、その設定フィールドは「デフォルトでオフ」にするのではなく、インターフェースから完全に削除するべきだ、というのがこの記事の結論だ。これは、単なる技術的な設計判断に留まらず、将来のリスク、倫理、そして組織のガバナンスまでを見据えた、深い洞察に基づいた選択と言えるだろう。