知識はデータに過ぎないのか？

シリーズ：プログラマーの哲学的思索 #02/11 | 読了時間：25〜30分 | 概念：認識論（Epistemology）— データ、情報、知識、そして知恵

著者：Wina @ Code & Cogito

---

あの日、データベースが教えてくれたこと

ある午後、「簡単な」タスクを引き受けました。データベースから先月の売上トレンドを抽出してほしい、と。

データはすべて揃っていました。数百万件のトランザクションレコード、ミリ秒精度のタイムスタンプ、各レコードには商品ID、金額、ユーザータグが紐づいています。クエリを書き、集計を走らせ、グラフを描きました。折れ線グラフは右肩上がり。悪くない。

レポートをプロダクトマネージャーに渡しました。彼女は3秒間それを見つめ、こう聞きました。「これは、私たちが何か正しいことをした結果なの？それとも単なる季節要因？」

言葉に詰まりました。

データはありました。数字もありました。トレンドグラフすらありました。しかし理解がなかったのです。「何が起きたか」は分かっていても、「なぜ起きたか」が分からない。すべてのトランザクションの詳細を語れても、それらの詳細が組み合わさって何を意味するのかが言えない。

その日から、一見素朴な問いを考えるようになりました。データと知識の間には、一体何があるのか？

後になって分かったのですが、この問いは哲学者たちを2,500年にわたって悩ませてきたものでした。そして彼らの答えは、エンジニアリングに携わる私たちにとって、驚くほど実用的なものです。

---

背景：ビットから知恵までの距離

DIKWピラミッド：過小評価されたアーキテクチャ

情報科学には古典的な階層モデルがあります——DIKWピラミッド。Data（データ）、Information（情報）、Knowledge（知識）、Wisdom（知恵）。多くの人はスローガンとして読み流します。しかしエンジニアの目で注意深く見ると、そこに記述されているのは変換パイプラインです。

raw = b"01001000 01100101 01101100 01101100 01101111"
info = raw.decode("utf-8")          # "Hello" — フォーマットが付いた
knowledge = "英語の挨拶、初対面で使われる"  # コンテキストと意味が付いた
wisdom = "今この人にHelloと言うのは適切か"  # 判断と行動が付いた

各層の変換は自動的には起こりません。データから情報へはエンコーディングとフォーマットが必要です。情報から知識へはコンテキストと関連付けが必要です。知識から知恵へは経験と判断力が必要です。

エンジニアなら特に理解できるポイントがあります。各層の変換は不確実性を持ち込む。 データそのものは確定的です（あのビット列はあのビット列です）。しかし解釈を始めた瞬間、あなたは哲学の領域に足を踏み入れます。

哲学者のバージョン：JTBとその崩壊

哲学における「知識」の最も古典的な定義はJTB——Justified True Belief（正当化された真なる信念）と呼ばれます。「知識」と見なされるためには、3つの条件を同時に満たす必要があります。

1. あなたがそれを信じている（Belief）——システムにそのレコードがある
2. それが真である（True）——現実に対応している
3. 信じるに足る十分な理由がある（Justified）——たまたま当たったのではない

エンジニアの言葉に翻訳すると：

def is_knowledge(claim, evidence, reality):
    believed = claim in my_beliefs        # 信じているか？
    true = claim.matches(reality)         # 真か？
    justified = evidence.supports(claim)  # 正当な理由があるか？
    return believed and true and justified

すっきりして見えます。しかし1963年、ゲティア（Edmund Gettier）という哲学者がたった2ページの論文でこの定義を吹き飛ばしました。彼が示した反例の本質はこうです。十分な理由をもって、たまたま真である事柄を信じることができる。しかし、あなたの理由と、それが真である原因との間には何の関係もない。 正しい答えに到達したが、推論プロセスが間違っていたのです。

エンジニアはこの状況を嫌というほど見てきたはずです。テストはすべてグリーン、コードも確かに正しく動いている——しかしそれはロジックが正しいからではなく、2つのバグがたまたま相殺し合っていたから。あなたはプログラムが「正しい」と「知って」いたのでしょうか。

---

スキーマは世界観である

どう格納するかが、どう考えるかを決める

これは本記事で最も重要な洞察の一つなので、じっくり展開させてください。

データベースのスキーマを設計するとき、一見すると純粋に技術的な判断をしています。しかしよく考えると、非常に哲学的なことをしているのです——世界が何で構成されているかを決定しているのです。

「人」をカラムに分解します。氏名、年齢、性別、役職、部署。これらのカラムが、あなたが「人」にとって最も重要だと考える属性です。「夢」「恐怖」「子供時代の記憶」は入れていません。存在しないからではなく、モデルのスコープ外だからです。

「関係」を外部キーとリレーションテーブルに分解します。友人、同僚、上司。しかし人間関係の微妙さ——敵でもあり味方でもある、かつては親密だったが今は疎遠、表面上は丁寧だが裏では競い合っている——これらはスキーマの中には存在しません。

スキーマはオントロジー（存在論）の宣言です。システムが「見える」ものを定義します。

そして見えないものについては、永遠に問いを立てることができません。

# スキーマが、あなたが問える質問を決定する
class Employee:
    name: str
    department: str
    salary: float
    # 問えること：誰の給料が一番高い？どの部署が最も多い？
    # 問えないこと：誰が最もクリエイティブか？誰が陰でチームを支えているか？

哲学では、これを「オントロジカル・コミットメント」（存在論的関与）と呼びます。あなたの言語とフレームワークが、何の存在を認めるかを決定します。SQLスキーマは一つのオントロジカル・コミットメントです。APIのレスポンスフォーマットも。あなたが追跡するメトリクスも。

禅では「一切唯心造」（いっさいゆいしんぞう）と言います。すべては心が造り出す。ここで言う「心」をスキーマと読み替えると、認識の枠組みが世界の見え方を決定するという洞察が、驚くほど鮮明になります。

知識の3つの隠れた次元

DIKWピラミッドの外に、エンジニアが見落としがちな知識の3つの次元があります。

第一に、知識にはコンテキストがある。 「水は100度で沸騰する」——海面上では正しいが、山の上では正しくない。あなたのフィーチャーフラグがテスト環境では完璧に動くのに、本番環境で問題を起こすのは、コンテキストが変わったからです。知識はそれが成立するコンテキストを離れると、「知識」から「あなたをミスリードしかねない情報」に退化します。

第二に、知識には時効がある。 「このAPIエンドポイントはJSONを返す」——次のバージョンでProtocol Buffersに変わるまでは。フレームワークのベストプラクティスに対するあなたの理解——コミュニティのコンセンサスが変わるまでは。知識には消費期限がありますが、私たちは信念にTTLをつけることが稀です。

第三に、知識には出自がある。 その情報をどこで知りましたか。自分で検証しましたか。同僚が教えてくれましたか。ドキュメントで読みましたか。AIが生成しましたか。各ソースは異なる程度の信頼性を帯びています。しかし日常業務では、信念の出自チェーンを追跡することは稀です。「みんな知っている」前提が間違いだったと判明するまでは。

---

知識のバージョン管理：信念にもGitが必要

なぜ知識システムにretractが必要なのか

コードにはGitがあります。ドキュメントにはバージョン管理があります。では、あなたの信念は？

考えてみてください。3年前にある記事を読んで、「マイクロサービスこそ正しいアーキテクチャの方向性だ」と学びました。この信念はあなたの知識システムに入りました。以来、すべてのアーキテクチャ決定にこの信念を持ち込んでいます。しかしこの信念をアップデートしに戻ったことは一度もない。マイクロサービスが引き起こす痛みを経験し、反対意見を読み、異なる成功パターンを目にした後でさえも。

成熟した知識システムは、3つのことができなければなりません。

class KnowledgeRepo:
    def commit(self, claim, evidence, confidence):
        """知識を新たに追加、エビデンスと信頼度を付与"""
        self.log.append({"claim": claim, "evidence": evidence,
                         "confidence": confidence, "status": "active"})

    def retract(self, claim, reason):
        """知識を撤回——削除ではなく、撤回済みとマーク"""
        self.log.append({"retract": claim, "reason": reason})

    def trace(self, claim):
        """知識の完全な履歴を追跡"""
        return [entry for entry in self.log if entry.get("claim") == claim]

更新：新しいエビデンスが来たら、マージできること。撤回：古い主張が間違っていたら、明示的にマークできること。こっそり削除するのではなく、なぜ変更したかの記録を残すこと。追跡：すべての結論がそのソースと推論プロセスまで辿れること。

これはインシデントのポストモーテムのロジックとまったく同じです。システムに問題が起きた後、ログを消して何もなかったふりはしません。追跡し、記録し、予防策をアップデートします。あなたの信念体系も、同じ厳密さに値するのです。

ナレッジグラフ：大きさではなく、クエリ可能性

ナレッジグラフはエンジニアリング界で話題ですが、多くの人が注目するのは「大きさ」です。哲学は異なる視点を与えてくれます。ナレッジグラフの価値はノードの多寡ではなく、推論可能性にあります。

良い知識構造は、既知から未知を導き出せなければなりません。

# 最小限の知識推論
facts = {
    ("海水密度", "影響される", "塩分濃度"),
    ("海水密度", "影響される", "温度"),
    ("塩分濃度", "推定可能", "電気伝導度から"),
}

def what_affects(subject):
    return {obj for (s, p, obj) in facts if s == subject and p == "影響される"}

# what_affects("海水密度") → {"塩分濃度", "温度"}

重要なのはコードの複雑さではなく、知識を機械がクエリし推論できるレベルまで構造化したことです。「自分の頭の中では分かっている」から「システムが活用できる」への決定的な飛躍です。

---

現代への接続：LLMは知識を持っているのか？

流暢さは知識ではない

AI時代における最も緊急の認識論的問いです。

ChatGPTに質問すると、流暢で、整理された、もっともらしい回答が返ってきます。それは物事を「知っている」のでしょうか。

JTBフレームワークで検証してみましょう。

• Belief：厳密に言えば、LLMは何も「信じて」いません。次のトークンの確率分布を計算しています。しかし行動面では、信念を持っているかのように振る舞います。
• Truth：回答が正しいこともあれば、精巧にパッケージされた誤りのこともあります。LLM自身はその区別をしません。
• Justification：最も致命的な弱点です。LLMは通常、検証可能なソースチェーンを示せません。その「理由」は統計パターンであり、推論プロセスではありません。

したがって、LLMの出力は——整合説のテストはパスし（前後一貫して見える）、対応説のテストはパスするとは限らない（事実に対応するとは限らない）。知識に「似て」いますが、知識の最も核心的な要素を欠いています。追跡可能な正当化です。

RAGの認識論的意義

RAG（Retrieval-Augmented Generation）がエンジニアリング実務でこれほど重要な理由がここにあります。単なる技術的最適化ではなく、認識論的なパッチなのです。

RAGがやっていることは、回答を生成する前に信頼できるナレッジベースを検索し、取得したソースを回答に添付すること。哲学の言葉に翻訳すると、「正当化のないbelief」を「ソース追跡可能なjustified belief」にアップグレードしているのです。

完璧ではありませんが、方向性は正しい。エンジニアがここでやっていることの本質は、認識論的な穴を塞ぐ作業です。

知識のサプライチェーン管理

AI時代において、知識はもはや一度きりの判定ではありません。サプライチェーンのように管理する必要があります。

• 出自追跡（provenance）——この主張はどこから来たのか？
• 信頼度マーキング（confidence scoring）——どの程度確かか？
• クロスバリデーション（multi-source validation）——独立した第二のソースはあるか？
• 時効管理（TTL）——いつ再検証が必要か？

あなたが毎日運用しているCI/CDパイプラインは、本質的に知識メンテナンスシステムです。コード（信念）が新しい環境（現実）の中でまだ成立するかを継続的に検証しています。

---

省察と示唆：あなたはデータを集めているのか、理解を積み重ねているのか

データ不安症の処方箋

多くの人がデータを蓄積するのは、一種の安心感を蓄積するためです。「データさえ十分にあれば、判断を間違えない」と。

しかし実際には、データが増えるほど、自分が知らないことがより見えてきます。データが増えれば次元も増え、次元が増えれば矛盾も増え、矛盾が増えれば不確実性も増えます。

成熟した知識観は「私は知っている」ではなく、「自分がどこで不確かなのかを知っている」です。

道元禅師はこう説きました。「仏道をならふといふは、自己をならふなり。自己をならふといふは、自己をわするるなり。」知ることの本質は、既知の自信の積み上げではなく、知らないことへの開かれた態度なのかもしれません。

4つの持ち帰りメンタルモデル

1. 階層を区別する——次に「知っている」と言うとき、自分に問いかけてください。それはデータなのか、情報なのか、知識なのか、理解なのか。階層が異なれば、下せる意思決定の質も異なります。

2. スキーマを検査する——あなたの思考フレームワーク（追跡しているメトリクス、問うている質問、構築したモデル）が、見えるものを決定します。定期的に問いましょう。自分のスキーマに入っていない重要なものは何か？

3. 出自をマークする——重要な信念については、そのソースを追跡してみてください。自分で検証したのか、「みんなそう言っている」だけなのか。ソースの信頼性が、そのまま信念の信頼性を決定します。

4. TTLを設定する——核心的な信念に消費期限を設けましょう。定期的に問いかけます。この信念はまだ成立するか？世界は変わったか？新しいエビデンスはあるか？

---

おわりに

あの午後のデータベースの前に戻りましょう。

数百万件のデータがありました。しかし大切なことを学びました。データは自動的に知識にはならない。食材が自動的に料理にならないのと同じです。 その間には構造、コンテキスト、判断、経験——そして「自分はまだ十分に理解していない」と認める意志が必要です。

次にデータベースから数字の山を引き出し、レポートに書き込もうとするとき、一瞬だけ考えてみてください。

それはデータなのか、知識なのか。あなたは本当に何かを「知った」のか？

---

次回予告

我思う、ゆえに我あり.py

あなたのプログラムはリフレクション（reflection）ができ、自分自身をモニタリングでき、状態に応じて戦略を自動調整できます。それは「自己意識」を持っているのでしょうか。

• デカルトがすべてを疑った後に残ったものは何か？なぜそれはフォールバック機構に似ているのか？
• リフレクション（reflection）と再帰（recursion）——自己参照のエンジニアリング構造は意識を説明できるか？
• AIエージェントが計画し、修正し、「私は思う」と言うとき、私たちはこの人格投射にどう向き合うべきか？
• 意識の「ハードプロブレム」は何が難しいのか？なぜエンジニアリングの手法では永遠に解けないかもしれないのか？

次回は、デカルトの方法論的懐疑から出発し、inspect、self、そしてモニタリングシステムを使って意識の謎を解きほぐします。

---

参考資料

• Plato. Theaetetus. （知識の古典的定義：正当化された真なる信念）
• Gettier, Edmund. “Is Justified True Belief Knowledge?” Analysis, 1963. （JTB反例）
• Ackoff, Russell. “From Data to Wisdom.” Journal of Applied Systems Analysis, 1989. （DIKWピラミッド）
• Quine, W.V.O. “On What There Is.” Review of Metaphysics, 1948. （オントロジカル・コミットメント）
• Floridi, Luciano. The Philosophy of Information. Oxford University Press, 2011. （情報の哲学）
• Lewis, Patrick et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS, 2020. （RAG）
• 道元『正法眼蔵』（自己の探究と知の本質）

---

---