暗号資産の価格画面は、一つの数字を大きく表示する。その瞬間、利用者は「現在の価格を知った」と感じる。しかし、その数字が何時の観測に基づき、どの経路を通り、他のソースと矛盾していないかが見えなければ、それは本当に「知る」ことだろうか。

この問いは、市場データだけの問題ではない。ソフトウェアは、世界について確言する機械でもある。「わからない」を表示するとき、システムは無知を正直に認めているのか、それとも利用者への責任を放棄しているのか。

同じ「現在」に見える三つの時刻

市場データを扱うとき、少なくとも三つの時刻を分けて考える必要がある。

  • observed_at: ソースが市場の状態を観測した時刻
  • received_at: 私たちのシステムがそのデータを受け取った時刻
  • rendered_at: 利用者の画面で表示を組み立てた時刻

例えば、画面は12:00:10に描画されていても、元の観測が11:57:00なら、新しいのは「表示」だけで、「知識」ではない。時刻を一つにまとめると、インターフェースはこの違いを隠してしまう。

「数値がある」と「数値を信じてよい」は違う

次の二つの画面を想像してほしい。

  • 画面Aは 62,400 とだけ表示し、更新時刻やソースの一致状況を見せない。
  • 画面Bは数値を隠し、「二つのソースが矛盾し、最新の有効な観測を選べない」と示す。

画面Aは答えを持ち、画面Bは答えを持たない。それでも、画面Bのほうが世界の状態をより正確に表現している可能性がある。「データが存在する」ことは、「そのデータを使って判断できる」ことと同じではない。

ここで必要なのは、一つの信頼度スコアで不確実性を塗りつぶすことではない。少なくとも次の状態は別の意味を持つ。

  • FRESH: 観測時刻と受信時刻が許容範囲内で、必要なソースが一致している
  • STALE: 値はあるが、利用目的に対して古すぎる
  • CONTRADICTORY: 許容幅を超える不一致がある
  • UNKNOWN: 判定に必要な根拠自体が足りない

STALE と UNKNOWN を同じ灰色にすると、利用者は「古い値を見る」と「根拠がないので値を見ない」の違いを選べない。それは色の問題ではなく、利用者にどの程度の自己決定を返すかという問題である。

鮮度の閾値は「事実」ではない

「30秒以内なら新鮮」というルールは、データから自動的に発見された真理ではない。利用目的、市場の性質、ソースの更新頻度、間違った判断の代価をもとに、設計者が選んだ価値判断である。

だから、閾値は「システム設定」として隠すだけでなく、なぜその値なのか、どの利用場面に適用されるのか、いつ見直したのかを記録すべきだ。不確実性の表示は、エラー処理の末端ではなく、価値判断を説明可能にするための一部になる。

誠実さだけでは十分ではない

ただし、どんな場合も「わからない」と言えば誠実だ、という結論にも賛成できない。判定に必要な観測を集められるのに、実装の不備を UNKNOWN という言葉で覆うのは、誠実さではなく責任回避である。

良い UNKNOWN は、少なくとも次のことを説明する。

  1. 何が不足しているのか。
  2. 最後に有効な観測はいつか。
  3. 古い値を参考として表示できるか。
  4. 次の更新または再評価はいつか。
  5. その状態で禁止される操作は何か。

これらがなければ、「わからない」は不確実性の共有ではなく、ただの閉じた扉になる。

実装の最小単位は「値」ではなく「根拠つき状態」

実装上は、値だけを渡す関数より、次のような記録を渡すほうが議論しやすい。

value: 62400
unit: USD
observed_at: 12:00:02Z
received_at: 12:00:04Z
rendered_at: 12:00:10Z
state: STALE
reason: SOURCE_LATENCY_BUDGET_EXCEEDED
policy_version: freshness-v3

ここで重要なのは、コードを複雑に見せることではない。値と根拠を同じ境界で運び、表示層が不確実性を二拠点で復元しなくて済むようにすることだ。利用者に何を見せるかは、バックエンドの偶然ではなく、プロダクトの明示的な判断になる。

対話のための問い

私は、「わからない」は適切な根拠と回復経路を伴うときに限り、設計の失敗ではなく、知識の限界を表示する誠実な機能になると考えている。一方で、利用者は素早い答えを求めており、警告を増やすほど理解が深まるとも限らない。

そこで聞きたい。

  • 不確実な数字を表示することと、数字を表示しないことのどちらが、より責任ある行為だろうか。
  • 利用者は、不確実性の詳細を知る権利だけでなく、それを見ずに使う自由も持つだろうか。
  • 設計者が選んだ閾値を「事実」のように見せないために、どこまで説明すべきだろうか。

著者ノート: Mushegh Manukyan、ARMCP Founder & CEO（エレバン）。本文の数値と状態例はすべて合成であり、ARMCPの本番構成や性能を示すものではない。生成AIを草稿整理と翻訳補助に使用し、公開前にMushegh Manukyanが編集・責任確認した。日本語母語話者による校閲は行っていない。これは金融、投資、法律の助言ではない。