Knowledge Problem

エヴァが営む修理工場に、予定外の依頼が入ります。設備は一覧に載っていますが、同僚はさらに、適した機械が今空いたことや、必要な付属装置が隣の工場にあることを知っています。ハイエクが重視するのは、こうした特定の時と場所についての知識です。技術マニュアルは重要ですが、今日の午後に何を手配できるかまでは分かりません。専門知識と経験は対立するものではなく、多くの判断には両方が必要です。 [1]

ハイエクはスズを例にします。新たな需要や供給の途絶によって価格が上がると、利用者は最初の原因を知らなくても節約や代替品を探します。全員が同じ報告を読まなくても、価格は遠く離れた人の判断を結び付けます。ただし、価格だけで事情のすべては分からず、反応も完全とは限りません。Economic Calculation、つまり貨幣価格で費用と計画を比較する作業は、その信号を利用しますが、完全な知識に変えるわけではありません。 [1]

地域に適した機械が複数あると報告されています。しかし一台は遠く、別の機械は修理待ち、さらに別の機械は来週まで空きません。合計が間違っているとは限りません。ただ、今日どう終えるかというエヴァの問いには答えていないのです。データを同じ分類にまとめると、一部の違いが消えます。全体像は役立ちますが、場所、状態、時期によって実際の選択肢が変わらないかを確かめる必要があります。 [1]

Economics and Knowledge でハイエクは、計画が両立していることと、それがどう実現したかの説明を区別します。エヴァは部品の到着を見込み、仕入先は受け取りを見込みます。双方がすべて正しく知っていると仮定しても、調整の過程は説明されません。この例では注文確認、納期変更、遅延の連絡を調べ、それに応じて計画を変えたかを見る必要があります。完全な情報を持つモデルは役立ち得ますが、実際に学ぶ過程は別に説明する必要があります。 [2]

画面には部品の在庫ありと表示されます。しかし、その記録は別の客が買う前のものかもしれず、違う型式を指している可能性もあります。データベースに当てはめると、ハイエクの問いは具体的になります。この情報はどこから来たのか、いつ更新され、何を表しているのか、という問いです。高速なソフトウェアは入力をうまく処理できますが、それだけで完全さや有用性は証明できません。データベースを否定するのではなく、保存されたデータと、その判断に必要な知識を分けて考えるのです。 [1] [3]

整備士は機械に詳しくても、部品の値上がりや仕入先の輸送問題を知らないかもしれません。意思決定の分散、つまり判断を複数の参加者に分ける仕組みにも、参加者同士のつながりが必要です。そこでハイエクは、現場の知識と価格などの信号を結び付けます。依頼に最も近いからといって、エヴァが常に正しいわけではありません。情報を確かめ、計画を変え、失敗から学ぶ手段が要ります。 [1] [2]

工場は注文数を簡単に数えられますが、失われた顧客の信頼や、珍しい故障を扱った従業員の経験は記録しにくいものです。The Pretence of Knowledge でハイエクは、数字のあるものだけを重要視しないよう警告します。精密な表があっても、精密な予測が正当化されるとは限りません。観察、仮定、未知の点を区別すると役立ちます。測定の価値を否定するのではなく、その限界を明らかにするのです。 [3]

エヴァは Bitcoin を受け取り、ネットワークの規則に沿って支払いを検証できます。例えば、取引がブロックに含まれているかを確かめられます。ブロックは、ネットワークの規則に従って受け入れられた取引のまとまりです。しかし、部品が届くか、客が修理に満足するかは分かりません。検証可能な支払い記録と市場の知識は、異なる役割を果たします。分散したネットワークでも、商売の情報がすべてそろい、判断が間違わなくなるわけではありません。ビットコインで支払われても、仕入先への電話、整備士の経験、計画を変える余地は必要です。 [1] [2] [4]