必ず

「ここには値が入っているはずだ」と考えて書いた一行が、数か月後、例外のログとして返ってくることがあります。プログラムの中でその一行は assert と呼ばれます。実行時に条件を確かめ、成り立たなければそこで停止する。停止したということは、書き手の見込みが誤っていたということです。コードは書き手より正直で、しかも遅れて正直になる。この遅れが、私にはずっと引っかかっていました。書いた時点では確信があったはずなのに、確信の根拠のほうは一行のどこにも記録されていない。残っているのは断定の形だけです。

計算機の側には、断定の強さを区別する仕組みが一応あります。型検査を通れば、ある種の誤りは実行される前に排除されている——反例が存在しないことが機械的に確かめられた状態です。一方、assert が通ったというのは、その一回の実行で反例に出会わなかったという事実にすぎません。前者は全称の主張で、後者は標本の報告です。根拠の階層がまるで違うのに、ソースコードの見た目はどちらも短い一行で、区別は読む側の知識に委ねられている。日本語の副詞も似た状態にあります。確信の強さを盛る語は豊富にあるのに、その確信がどこから来たのかを示す語はほとんどない。証拠の種類を語形に義務づける言語もあると聞きますが、この語に関しては、由来は文の外に置かれたままです。もっとも、隣の類義語と同じ働きをしているわけではありません。「きっと」が話し手の確信の度合いを言うのに対し、こちらが言うのは例外がないことのほうで、量化に近い。だから部分否定の側へ回る「必ずしも」という形を持ち、「きっとしも」という形は作れない。全称に届いている語だからこそ、反例が一つ出れば丸ごと落ちます。

ここで立ち止まります。表示しないのは欠陥なのでしょうか。「明日は必ず持ってきてください」という文を考えると、これは事実の主張ではありません。要求です。守るべきは聞き手であって、話し手は検査する側に回る。設計手法の用語を借りれば、事前条件に近い——呼び出す側が満たすべき約束で、破られたときの責任も呼び出す側にある。同じ副詞が、事実の予測にも、自分への誓約にも、相手への要求にも使われる。三つを分けているのは語形ではなく、誰が守る側に立つかという配置だけです。由来を表示しないのは怠慢ではなく、配置のほうに情報を持たせる設計なのだと考えると、話が反転します。

この配置は、書かれた文の中では主語の人称に現れます。三人称なら予測、一人称なら誓約、二人称なら命令。そして予測は外れることがあり、誓約は破られることがあり、命令は無視されることがある——外れ方の種類が違う。予測が外れても誰も責められませんが、誓約が破られると人物の輪郭のほうが変わります。同じ語が同じ強さで発せられているのに、失敗したときに崩れるものが違う。物語が動くのは、崩れるものが人のほうにある場合だけです。

だから、この副詞を地の文に置くと危険が生じます。語り手が保証してしまうからです。語り手の断定は読者にとって型検査に近く、反例をあらかじめ排除してしまう。同じ語を登場人物の口に置けば、それは実行時にしか確かめられない条件になり、破られる余地が残る。約束の言葉として書かれた一語が、後の場面で静かに落ちる。落ちたときにログが残るように、その約束は誰かに聞かれた場所で交わされていなければなりません。