危ない

プログラミングの世界には、「壊れている」と「まだ壊れていないが、いずれ壊れうる」を区別する文化があります。前者はエラーと呼ばれ、コンパイラはそこで作業を止める。後者は警告と呼ばれ、プログラムは一応動くけれども、画面には黄色い注意書きが残ります。使われていない変数、決して実行されない行、桁があふれるかもしれない計算。この二分法は、日本語の「壊れた」と「危ない」の区別にきれいに対応しています。危ないとは、損害がまだ発生していない状態の形容です。起きてしまえばもう危ないではなく、事故と呼ばれる。

計算機科学は、この「いずれ壊れうる」を厳密に定義しようと努力してきました。たとえばC言語には未定義動作という概念があります。規格が結果を保証しない操作——確保していないメモリを読むような操作——を含むプログラムは、たまたま動いているだけで、環境が変われば何が起きるか分かりません。Rustという言語は、そうした操作を unsafe というキーワードで囲った区画の中にしか書けないようにしました。危険な操作を禁止するのではなく、危険がどこにあるかを構文の上で明示させる。似た発想は他にもあって、値が空かもしれないことを型で区別する言語では、空の可能性を処理し忘れた箇所が実行前に指摘されます。危なさを型と区画で管理する設計です。曖昧な形容詞だったものが、ここでは言語仕様の一部になっている。

では、プログラムが危ないかどうかを完全に判定する機械は作れるのか。理論は冷たい答えを返します。プログラムの意味に関する自明でない性質は、一般には機械的に判定できないことが知られています。ライスの定理と呼ばれる結果です。つまり、あらゆる危なさを漏れなく正確に検出する検査器は、原理的に存在しない。そこで実務は割り切ります。疑わしいものはすべて警告する。誤報が増えても、見逃しよりはましだ——静的解析と呼ばれる検査ツールの多くは、この方針で作られていて、開発者は毎日いくらかの誤報と付き合いながら仕事をしています。ただし誤報には隠れた費用がある。警告が多すぎると、人は警告を読まなくなるのです。狼が来たと叫び続けた少年の寓話と同じ構造で、警報の信頼は誤報のたびに少しずつ目減りする。危なさの検出は、感度を上げれば解決という単純な問題ではありません。

この設計は、人間の直感とよく似ています。暗い夜道で感じる「危ない」の大半は誤報で、たいていは何も起きずに家に着く。それでも警報の閾値を低く保つことには合理性があります。見逃しの損害が誤報の煩わしさを大きく上回るからです。小説で人物の危機感覚を書くときも、この構造は使えます。当たる直感だけを書けば、人物は預言者になってしまう。外れる警報を何度か書いておいて、そのうちの一度だけを本物にする。読者もまた、外れた警報を一緒に経験してきたぶんだけ、本物が鳴った瞬間の温度差を体感できる。誤報を許す警報システムとして書かれた直感は、正確な直感よりも人間に見えます。