【ITニュース解説】I proposed a shelf life for published claims. A reader showed me I was measuring the wrong variable.

技術に関する情報を発信したり、他者の情報を受け取ったりする際、その情報がどれくらい信頼できるのか、いつまで「最新」と見なせるのかは常に重要な問いである。ある技術情報を発信する人は、自身が公開するベンチマーク結果のような技術的な主張について、「いつまでその主張が有効であるか」という「棚卸し期限」を設けることを検討した。これは、例えば四半期ごとに再検証されない主張には「未検証」という印をつけるというものであった。このアイデアは、時間の経過を追うだけで自動的に管理できるため、実装が容易である点が魅力的だったのだ。

しかし、この提案に対し、読者の一人から重要な異論が提起された。読者は、主張のステータスを時間の経過によって決めることは適切ではないと指摘した。なぜなら、主張の内容を変えるのは時間の経過ではなく、「誰がその主張を覆そうと試みたか」という検証のプロセスだからである。筆者自身が測定しただけの段階では、それはまだ「主張」ではなく、他の人々が読み、検討するための「下書き」に過ぎない。その主張が本当に「確定済み（settled）」となるのは、筆者とは異なる動機を持つ第三者が、その主張を否定しようと試みて、しかし失敗した時である、と読者は論じた。これは時間の経過によるものではなく、その主張が受けた検証の質による「状態の変化」だというのだ。

この読者の指摘は、筆者自身の過去の経験にも裏付けられていた。筆者が過去に修正した四つの誤りのうち、三つは、実は公開したその時点で既に間違っていたものであった。つまり、これらの情報は最初から「新鮮」な状態ではなかった。時計による「棚卸し期限」を設けたとしても、公開から九十日後に「未検証」とマークされる頃には、とっくに誤った情報として存在し続けていたことになる。逆に、公開時に実際に正しかった唯一の主張は、時計による期限が来れば「未検証」の対象となってしまう。このように、時間に基づくアプローチでは、すでに誤っている情報がいつまでも「新鮮」に見えてしまう一方で、真に正しい情報が不当に古びてしまうという問題が生じる。読者はこの失敗モードを、「時間による期限設定は、しっかり検証された情報まで古びさせるが、一方で内容にバグがある情報が、ずっと正しいかのように見えてしまう」と表現した。筆者の四つの誤りは、時間の問題ではなく、作成者しか検証していないという「検証者の偏りの問題」であったのだ。

筆者は、この読者の指摘が正しいと認めた。自身が「棚卸し期限」という時間の概念に手を出したのは、それが唯一自動化可能な測定手段だったからだと振り返る。情報の記録には時間は含まれているが、「誰か違う視点を持つ人がこれを見たか」という情報は含まれていない。つまり、筆者は根本的な失敗の原因に対応するのではなく、単に自分が作れるメカニズムを提案してしまったのだ。これは、システム設計のレビューであれば即座に指摘されるような間違いであったと、筆者は認識した。

この診断がさらに重く響くのは、筆者が行った修正の発見元がどこにあったかという点である。四つの修正のうち二つは、実際にコードを実行した読者によって発見された。残りの一つは、そうした読者の行動が筆者に促した習慣、すなわち公開直前に草稿中の全ての数値を再測定するという習慣によって見つかったものだ。どの修正も、筆者が自分の仕事をより注意深く読み直した結果見つかったものではなかった。これは、時間による「棚卸し期限」が設定されたところで促されるはずの行動とは全く異なる。読者もまた、自身の経験として、ある再構築作業が「暫定的」から「確定済み」に移行したのは、自分が実行していない再分析が、自分のメモからではなく元のソースコードから再構築された後だったと述べている。これもまた、自分の仕事を注意深く読み直した結果ではなかったのだ。

では、「時間による期限」に代わるものは何だろうか。正直な答えとして、筆者にはまだ有効なメカニズムが見つかっていない。間違った理由で以前のメカニズムを考案したばかりの自分が、また新しいものを考案することには疑念を抱いている。もし新しいメカニズムが必要だとすれば、それは経過時間ではなく「異なる視点からの検証記録」という形をとるべきだろう。つまり、「作成者以外の誰が、何を試みて、何が起こったか」という情報である。これは、技術的には簡単に記録として追加できるが、小規模なブログで情報を「検証」しようと意欲を持つ第三者の確保は、筆者には制御できないため、実際には用意することが非常に困難な情報である。

この考察は、少しばかり受け入れがたい結論へとつながる。もし「確定済み」となるために外部からの「検証」が必要だとすれば、筆者が公開するほとんどの主張は決して「確定済み」にはならない。そのほとんどに付されるべき適切なラベルは、「永続的に暫定的」（permanently provisional）となるだろう。筆者はこの結論に抵抗を感じるが、その抵抗は「そう見えること」についてであり、「それが真実であるか」については抵抗がないことに気づく。

二つ目の疑問、「誤りを修正する際、元の情報をどう扱うべきか」については、読者の意見は明確であり、筆者も納得した。読者は、元のテキストを削除せず、日付入りの修正文を同じ文書内に残しておくべきだと主張する。修正された内容はどのようなもので、どのように発見されたのかを明記するのだ。元のテキストを削除して修正を埋め込むと、記事は読みやすくなるかもしれないが、その修正が持つ唯一の価値、すなわち「かつて何を信じ、なぜそう信じていたのか」という学びの記録が失われてしまう。きれいに修正され、過去の経緯が分からない情報は、事実が隠蔽された情報と同じである、というのだ。

筆者はこれまでも、発見者の名前を記しながら、おおよそ同じ方法で修正を行っていた。しかし、他の誰かからは「記事が読みにくくなる」と言われたこともあった。今では、「読みにくくなる」という観察は正しかったが、それは情報を正確に伝えるための、受け入れるべきトレードオフだったと筆者は考えている。

読者は、自身にはほとんど読者がいないため、その方法が大規模にテストされたわけではないと付け加えた。筆者にも同様に多くのフォロワーがいるわけではない。しかし、両者が独自にたどり着いた結論は、修正後の情報が元の情報よりも良くなっているというものであった。そして読者は、筆者が思いつかなかった理由を提示した。「何かを乗り越えて得られた主張こそが、正直に手渡せる唯一の種類である」というものだ。

筆者にはまだ解決できない疑問が残っている。一つ目は、「もし『確定済み』が、異なる動機を持つ誰かがあなたの主張を検証し失敗することを要求するなら、それをどのように記録すれば、単なる形式的なものではなく、真に価値ある情報となるだろうか」というものだ。二つ目は、「『永続的に暫定的』という状態は、実際には問題ないのだろうか」というもの。直感的には、「未確定」とマークされた主張ばかりのブログは、情報の正確性に自信がないように読めてしまう。しかし、この直感は完全に見た目だけのものかもしれない。もし、ほとんどの公開されている技術的な主張が、実際には作成者以外の人によって厳密に検証されていないのであれば、そう明言することこそが、情報の信頼性を高める第一歩となるのかもしれない。