真理は関数なのか？
シリーズ：プログラマーの哲学的思索 #01/11 | 読了時間：25〜30分 | 概念：認識論（Epistemology）— 真理の本質と判定
著者：Wina @ Code & Cogito
深夜のTrue
ある深夜のことでした。
画面に表示された一行のコードを見つめていました。
if user.age >= 18:
return True
キーボードの上で指が止まりました。ふと、あることに気づいたのです。
この True は、一体何を意味しているのか？
技術的な意味ではありません——ブール値を返すことは分かっています。もっと深いことを聞いているのです。何がある事柄を「真」たらしめるのか？
年齢が18以上なら成年。日本ではかつて20歳でしたが、2022年に18歳に引き下げられました。アメリカで酒を買うなら21歳です。「成年」という概念そのものの定義が国によって異なります。
あのシンプルな True の背後には、人類が2,500年にわたって考え続けてきた哲学の難問が隠されていました。
そして気づいたのです。プログラマーこそ、この問題を考えるのに最も適した人々かもしれない、と。
なぜなら、私たちは毎日こういうことをしているからです。曖昧な現実を、明確なブール値に圧縮する。
すべての if は一つの判定です。そしてすべての判定には暗黙の問いが伴います——あなたの判定基準はどこから来ているのか。それは信頼できるのか。どんな条件下で無効になるのか。
これは「プログラマーの哲学的思索」シリーズの第一回です。最も基本的なところから始めましょう。真理。
Let’s debug reality.
背景：Booleanの幻想
プログラムの世界のきれいな二分法
プログラムの中では、真偽はシンプルです。
x = 5
y = 3
print(x > y) # True
疑いようがありません。明快そのもの。True は True です。
しかし、このロジックを現実世界に押し広げると、事態は崩れ始めます。
def is_adult(age):
return age >= 18 # これは本当に「真理」なのか？
この関数が返す True と、5 > 3 の True は、同じ種類の「真」でしょうか。
違います。
5 > 3 は数学的真理です。宇宙のどこであれ、いつであれ成立します。
しかし age >= 18 は社会的に構成された判定です。特定の法律、特定の文化、特定の時代の下で成立します。パラメータを変えれば無効になります。
すべての True が同じ種類の「真」ではないのです。
この洞察を、哲学者たちは二千年以上かけてフレームワークとして整理してきました。
なぜプログラマーがこの問題を考えるのに適しているのか
あなたは毎日「真」の問題を扱っているからです。
- テストは「本当にパスした」のか、それとも「偽のパス」なのか？
- 要件定義書に書かれているのは「本当のニーズ」なのか、それとも「表面的なニーズ」なのか？
- AIが生成した答えが「真に見える」が「実は偽」——どう見分けるのか？
哲学者アリストテレスは二千年前にこう述べました。「存在するものを存在すると言い、存在しないものを存在しないと言うこと、これが真である。」シンプルに聞こえます。しかし、この文をコードに書き起こそうとすると、そこにどれほどの暗黙の前提があるかに気づくでしょう。
三つの真理論：プログラマーの直感による翻訳
哲学者たちは「何が真か」という問いを、三つの大きな理論に整理しました。それぞれが、あなたがエンジニアリングで馴染んでいるパターンに対応しています。
一、対応説：文は世界と一致しなければならない
核心的な考え：真理とは、文と現実の一致である。
あなたが心の中に持っている関数に最も近い形です。
def is_true_correspondence(statement, reality):
return statement.matches(reality)
直感的で、心地よく、そして最も危険です。
なぜなら、完全な reality を手に入れることは通常できないからです。APIが返す部分的なデータ、ユーザーが報告する断片的な説明、モニタリングシステムが捉えた不完全なログ。それがあなたの手にある「現実」です。
対応説の問題は論理的なものではなく、実務的なものです。reality パラメータが完全であることを確認する方法がない。
アリストテレスが対応説を提唱しました。二千年にわたって最も直感的な真理観であり続けました。人々が「では『現実』そのものはどう定義するのか？誰が現実が何かを教えてくれるのか？」と問い始めるまでは。
二、整合説：システム内で矛盾しないこと
核心的な考え：ある文が、あなたの信念体系全体と整合していれば、それは真である。
インテグレーションテストに似ています。モジュール群が一緒に動作でき、自己矛盾がないことを確かめる。
def is_true_coherence(statement, belief_system):
return belief_system.add(statement).no_contradiction()
整合説の強みは、「現実と照合する」必要がなく、システム内部の一貫性を確保すればよいことです。
しかし罠もここにあります。美しい閉じたシステムは完全に自己整合的でありながら、現実から乖離しうる。
設計は優美で論理は厳密だが、ユーザーのニーズとまったく合っていないソフトウェアアーキテクチャを思い浮かべてください。理論上は完璧に一貫し、実践では完全に失敗する。
ヘーゲルやブラッドリーといった哲学者が整合説を発展させました。真理は巨大な論理のネットワークであり、各部分が互いに支え合っていると彼らは考えました。
三、プラグマティズム：使えるなら真
核心的な考え：ある信念が実践で良い結果を生むなら、それは真である。
A/Bテストやオンラインメトリクスに似ています。
def is_true_pragmatic(statement, metrics):
return metrics.after_adopting(statement).improves()
プラグマティズムはエンジニアにとって非常に魅力的です。「動くものが正義」という発想は馴染み深いものでしょう。
しかし、気まずい問いに直面させられます。役に立つ嘘は「真」と言えるのか？
プラシーボ効果は実際に効きます。間違った地図がたまたま目的地に連れて行ってくれたら、それは「正しい」のでしょうか。
ウィリアム・ジェイムズとジョン・デューイがプラグマティズムを発展させました。彼らは哲学を象牙の塔から現実へ引き戻しました。「これは真か」と問うのではなく、「これを信じることの帰結は何か」と問え、と。
ユニットテストは真理を証明できるか？
ここに、プログラマーが特によく理解できるパラドックスがあります。
テストが全件グリーンになりました。100%パス。あなたのプログラムは「正しい」と言えるでしょうか。
言えません。
テストができるのは、「永遠に正しい」ことの証明ではなく、あなたが思いついた入力、あなたが設計したケース、あなたが考慮したエッジの範囲内で、反証されなかったということの確認です。
def truth_by_tests(claim, test_cases):
return all(case.verify(claim) for case in test_cases)
# test_cases は永遠に不完全
これは哲学者カール・ポパーの「反証主義」と驚くほど一致しています。ポパーは言いました。科学は検証の積み重ねで真理を打ち立てるのではなく、反証の試みを繰り返すことで真理に漸近していくのだ、と。ある理論が「真である」ことは永遠に証明できません。言えるのは「今のところ反証されていない」ということだけです。
カバレッジの哲学版
テストカバレッジが95%です。残りの5%は？
もっと重要なのは、カバーしているのは「あなたが想像できた世界」だということです。世界には常に、想像もしなかったエッジケース、予見できなかった分布のドリフト、自分が知らないことすら知らない盲点があります。
したがって、真理は「継続的なモニタリング＋継続的なキャリブレーション」に近いものであり、一度きりの宣言ではありません。
型システムの保証と限界
強い型システムは安心感を与えてくれます。int が突然 str に変わることはなく、None は明示的に処理され、不可能な状態が排除されます。
しかし保証されないことがあります。
- 要件理解が正しいかどうか
- 変数名が現実を反映しているかどうか
- 目的関数にバイアスがないかどうか
型システムは形式論理に似ています。ルール内での推論の一貫性は保証しますが、ルール自体が正しいことは保証しません。
これはまさに整合説の問題です。形式的に完璧でも、実質的には乖離しているかもしれません。
禅の伝統には「指月の喩え」があります。月を指す指は月そのものではない。型システムは指であり、現実は月です。指（形式的保証）に囚われて月（現実の正しさ）を見失ってはなりません。
証明不可能性：なぜ「全域的な正しさ」はしばしば得られないのか
エンジニアリング上、2つの厳しい現実を知っているはずです。
- 複雑なシステムの状態空間は大きすぎて、網羅できない
- すべての使用シナリオを列挙することは不可能
哲学にも同様のジレンマがあります。ある命題に根拠を提供しようとすると気づきます。
- 根拠そのものも検証が必要
- 検証にはさらに別の根拠が必要
- こうして無限後退に陥る
最終的に2つの選択肢に行き着きます。ある基礎前提は証明不要だと受け入れる（公理）か、確実性には常に限界があると認めるか。
これはゲーデルの不完全性定理の精神と一致しています。十分に複雑な形式体系には、その体系の内部で証明できない真なる命題が必ず存在します。
エンジニアの直感的バージョンはこうです：
私たちは常に「リスク許容可能」な境界線上で仕事をしている。「絶対的に正しい」天国にはいない。
現代への接続：AIハルシネーションと真偽のサプライチェーン
生成AI時代において、真理の問題はかつてないほど切迫しています。
ChatGPTが返す答えは、次のような性質を持ちえます。
- 一貫して見える（整合説をパス）——文は流暢で、論理的に筋が通り、自信に満ちている
- しかし現実に対応していない可能性がある（対応説で失敗）——存在しない論文を引用し、虚偽の事実を作り上げる
- 短期的には役立つ（プラグマティズムを部分的にパス）——タスクの遂行には役立つが、潜在的なリスクを埋め込む
これがAIハルシネーション（幻覚）の本質です。整合説とプラグマティズムのテストはパスしたが、対応説では完全に失敗している。
プログラマーとして、対処の直感はすでにお持ちのはずです。それは、すべてのインテグレーションテストをパスしたのに本番環境で爆発するシステムのようなもの。テストケースが、あの致命的なエッジケースをカバーしていなかっただけです。
真理にはサプライチェーン管理が必要
AI時代において、真理はもはや一度きりの判定ではなく、サプライチェーンのように管理する必要があります。
- ソース追跡（source of truth）——この情報はどこから来たのか？
- クロスバリデーション（multi-source validation）——独立した第二のソースはあるか？
- バージョン管理（truth versioning）——いつ、なぜ変わったのか？
- 継続的モニタリング（post-deploy maintenance）——デプロイ後もまだ真か？
あなたが毎日運用しているCI/CDパイプラインは、本質的に真理のメンテナンスシステムです。
省察と示唆：プログラマーの真理リテラシー
あなたが求めているのは「真」か、それとも「安心」か？
多くの場合、真理を追求していると思っていても、実は制御可能感を追い求めています。「このバグは直った」——あなたが欲しいのは宇宙的真理ではなく、「安心してリリースできる」という感覚です。
しかし世界はしばしば制御不能です。優れたエンジニアは一度きりの「正解」を追い求めるのではなく、不確実性の中で持続的に機能する判定プロセスを構築します。
真理は一本のパイプラインである
今日の議論をエンジニアリングモデルに凝縮すると、次のようになります。
- 命題を定義する——スコープを明確に。「何を判定しようとしているのか？」
- エビデンスを指定する——追跡可能なソースを。「根拠は何か？」
- 一貫性チェック——自己矛盾を避ける。「あなたが知っている他のことと矛盾しないか？」
- 反例の探索——失敗する状況を積極的に探す。「どんな条件下で間違うか？」
- 本番モニタリング——分布ドリフトに注意する。「まだ真か？」
- バージョンアップの修正——自分が間違いうることを認める。「アップデートが必要か？」
真理は関数の戻り値ではありません。むしろ継続的に実行されるパイプラインに近い——入力、処理、検証、モニタリング、更新が必要です。
4つの持ち帰りメンタルモデル
-
懐疑の精神を保つ——テストを書くように自分の信念をテストする。すべてを疑えということではなく、「確実性」に対して健全な警戒を持つこと。
-
多次元の検証を追求する——一つの信念は、対応説・整合説・プラグマティズムのうち少なくとも2つをパスして初めて信頼に値する。1つだけパスしたものには注意が必要。
-
不完全性を受け入れる——テストカバレッジが100%になることは永遠にない。信念体系も同様。それを受け入れた上で、フォールトトレランスの仕組みを構築する。
-
継続的リファクタリング——コードをリファクタリングするように、信念体系を定期的に検証しアップデートする。以前のものが「間違っていた」からではなく、世界が変わったから。
おわりに
冒頭のあの深夜に戻りましょう。
if user.age >= 18:
return True
これで分かりました。この True はただのブール値ではありません。特定の法律フレームワーク（対応説）、社会的コンセンサス（整合説）、実用上のニーズ（プラグマティズム）の下で成立する判定結果です。
フレームワークを変えれば、それは False に変わりうるのです。
プログラマーとして、あなたには固有のアドバンテージがあります。不確実性の中で仕事をすること、複雑さの中に構造を見出すこと、エラーから継続的に修正していくこと——これらにすでに慣れています。
これらはまさに、真理の追究に最も必要な能力です。
次に if something == True: と書くとき、一瞬だけ考えてみてください。
その True は、あなたが思っているよりずっと複雑です。
次回予告
知識はデータに過ぎないのか？
あなたのデータベースにはTBクラスのデータが格納されています。しかし、あなたは何を「知っている」のでしょうか。
- データ、情報、知識、理解、知恵——このピラミッドは本当に成り立つのか？
- スキーマ設計は世界観の定義なのか？
- なぜ二人の人が同じデータを見て、正反対の結論に達するのか？
- 知識に「バージョン管理」は必要か？
次回は、認識論をプログラマーが操作できる知識工学に分解します。
参考資料
- Aristotle. Metaphysics. （対応説の原典）
- Popper, Karl. The Logic of Scientific Discovery. Routledge, 1959. （反証主義）
- James, William. Pragmatism. Longmans, Green, and Co., 1907. （プラグマティズム）
- Godel, Kurt. “On Formally Undecidable Propositions.” Monatshefte fur Mathematik, 1931. （不完全性定理）
- Floridi, Luciano. The Philosophy of Information. Oxford University Press, 2011. （情報の哲学）
- 西谷啓治『宗教とは何か』1961年（空と真理の東洋的視座）
