Theories of Mind as Languages of Thought for Thought about Thought
心の理論を思考に関する思考のための思考言語と見なす：ベイジアンネットワーク/因果文法モデルとプログラミングパターンモデルの利点を統合
https://osf.io/qhc6y/download
詳細：真のAGIのための再帰的推論確率的プログラミング言語：memoの実装、具現化されたゲーム
要旨
「心の理論」（theory of mind）とはどのようなものでしょうか？認知科学者として、私たちは研究する様々な心の理論をどのように形式化すべきでしょうか？本稿では、心の理論を一種のプログラミング言語、すなわち他の心に関する問題を定式化し、推論するために特化した言語と見なすことが価値があると主張します。プログラミング言語の理論と歴史からのアイデアを借りて、この視点が心の理論における概念を形式化し、複数の心の理論間の違いを正確に明確にし、私たちが時間とともに自身の心の理論をどのように発展させるかを推論するのにいかに役立つかを示します。
はじめに
私たちは心の理論をどのように捉えるべきでしょうか？影響力のある「理論理論」（Carey, 1985; Gopnik & Meltzoff, 1997）の観点では、私たちは心の理論を実際に理論として、科学理論に似たものと見なすべきです（Gopnik & Wellman, 1992）。しかし、ここで「理論」とは具体的に何を指すのでしょうか？与えられた心の理論 θ を正確で計算可能な方法でどのように表現するのでしょうか？さらに、θ は一体どのようなものでしょうか — そして、θ が属する可能性のある心の理論の空間 T をどのように形式化すべきでしょうか？
心の理論を表現できる正確な数学的言語は、3つの重要な価値を持っています。
第一に、そのような言語は、心の理論に関するアイデアや仮説を明確かつ曖昧さのない方法で述べることができます。
第二に、そのような言語は、これらのアイデアや仮説を実行可能な計算モデルとして体系的にインスタンス化することを可能にし、価値あるシミュレーションや分析を行うことができます — 例えば、Horschler et al. (2023) は、一連の実行可能なモデルを用いて非ヒト霊長類の心の理論を特徴付ける方法を最近示しました。
最後に、心の理論の体系的な計算基盤は、人間のような社会的知能を持つ現実世界のAIシステムを原則的な方法で設計するために使用することができます。
したがって、本稿の目的は、θ と T を形式化する方法を提供することです。私たちは、心の理論 θ をプログラミング言語（PL）と見なすべきだと提案します。この言語では、心が他者の心的推論を伴う問題を定式化し、解決することができます。したがって、心の理論の空間 T は、心的推論に使用できる潜在的なプログラミング言語の空間によって定義されます。
本稿はこの観点を4つの段階で展開します。
まず、心の理論を形式化しようとした先行研究の2つについて議論し、なぜ新しい解釈が価値あるのかを説明します。
次に、特定の心の理論を具現化したプログラミング言語の具体的な例を通して、私たちの観点を紹介します。この例を用いて、プログラミング言語の設計が心の理論における概念をどのように具体化するかを示します。
その後、具体的なものから一般的なものへと移行し、プログラミング言語の構文と意味論の変化に基づいて、異なる可能性のある心の理論間の違いを形式化する上で、私たちの観点がどのように役立つかを議論します。
最後に、プログラミング言語設計の歴史から洞察を得て、私たちの観点が理論変化のプロセスを理解する上でどのように洞察を提供するかを議論します。
心の理論の形式化の3つの試み
心の理論の形式化から私たちは何を期待するのでしょうか？私たちの見解では、心の理論の正式な記述は、少なくともその2つの重要な特徴を説明できるべきです。（1）心の理論が、その所有者が他者の心的状況を効率的に表現し、推論することを可能にする方法。（2）これらの理論の所有者が、新しい証拠に直面したときに、自身の理論を成長させ、修正し、あるいは完全に置き換える方法。
ベイジアンネットワークモデル 形式化の初期の試み（Gopnik et al., 2004; Gopnik & Wellman, 2012）は、心の理論を因果ベイジアンネットワーク（Pearl, 2000）として形式化することで、これらの要求に応えました。このモデルでは、エージェントの信念や欲望などの潜在的な概念は、ベイジアンネットワークのノードとして表現でき、エージェントの行動に向かう有向エッジを持ちます（図1）。予測や計画などのタスクは、効率的な確率的推論アルゴリズムによってサポートされます（Baker et al., 2008）。最終的に、理論自体も新しい証拠に直面して変化することができ、可能なベイジアンネットワークの空間に対する階層的推論を通じて実現されます（Goodman et al., 2006）。例えば、子供は最初は心の状態が図1(a)のようなネットワークでうまくモデル化できると非常に確信しているかもしれません。しかし時間が経つにつれて、彼女は図1(b)のような、知覚が制限された状況で心をより正確にモデル化できる、より簡潔ではないネットワークを好むようになるかもしれません。
このモデルは2つの課題に直面します。まず、考えられるすべての社会的状況についてベイジアンネットワークを記述することは、事実上不可能です。ある時点でのエージェントの信念や欲望は固定されたベイジアンネットワークで表現できるかもしれませんが、人間の心的状態に関する推論能力は無限で、生成性があり、再帰的です：私たちは他者の心的状態に関するエージェントの信念の信念について、行動に応じて動的に変化しながら、同様に容易に推論することができます。これは、固定されたベイジアンネットワークが心の理論の表現タスクには不十分であり、最初の要求（1）に課題を投げかけていることを示唆しています。第二に、このモデルは人がどのように理論を発展させるかを十分に説明していません。Goodman et al. (2006) のモデルは、2つの事前に設定されたベイジアンネットワーク間の推論を考慮していますが、これらの仮説自体の起源を説明しておらず、2番目の要求（2）に課題を投げかけています。
これらの課題に対処するため、Tenenbaum et al. (2007) は、直観的理論を固定されたベイジアンネットワークではなく、特定の状況に応じたベイジアンネットワークの集合を生成できる因果文法として形式化することを提案しました。因果文法は、ある領域内で無限の状況に対する推論をサポートし、文法によって生成される仮説に対する推論を通じて学習を実現します。しかし、「文法」の形式体系は、心の理論の豊かな全体像を表現するには依然として不十分です — 例えば、信念の再帰的な信念（Griffiths & Tenenbaum, 2007）を表現することはできません。
プログラミングパターンモデル 別の方法は、Church（Goodman et al., 2012）やWebPPL（Goodman & Stuhlmüller, 2014）のような汎用確率プログラミング言語（PPL）の発展に端を発しています。PPLでは、複雑な確率モデルをシンプルなプログラムで生成できます。例えば、ベイジアンネットワークにおける繰り返しノードは、ループによって自動的に生成できます。
このアイデアに基づき、Goodman et al. (2015) は心の理論を、汎用PPLにおける「プログラミングパターンツールボックス」と見なしました。例えば、このフレームワークでは、合理的で目標指向のエージェントの行動を表現することは、「推論としての計画」（planning-as-inference、Botvinick & Toussaint, 2012）というプログラミングパターンに対応します。ここでエージェントは、ある目標を達成するために、「どの行動がその目標達成につながったか」という結果を推論します。具体的には、WebPPLでは、次のようにコードを記述できます。
因果文法と同様に、これらのプログラミングパターンは、プログラマーが特定の状況に応じた確率モデルを柔軟に生成することを可能にします。しかし、これらのパターンは因果文法よりもはるかに強力です。例えば、「思考の思考」や再帰的な社会的推論を表現することは、ネストされた推論（nested inference）というパターンに対応します。これは、それ自体が再帰的に推論クエリを実行する確率モデル上で推論クエリを実行することです（Stuhlmüller & Goodman, 2014; Zhang & Amin, 2022）。
具体的には、観測された行動observed_actionに基づいてエージェントの目標を推論したい場合、つまり逆計画（Inverse Planning, Baker, Saxe, & Tenenbaum, 2009）を実行したい場合、次のように書くことができます。
因果文法と同様に、これらのプログラミングパターンはプログラマーが特定の状況に応じた確率モデルを柔軟に生成することを可能にします。しかし、これらのパターンは因果文法よりもはるかに強力です。例えば、「思考の思考」や再帰的な社会的推論を表現することは、ネストされた推論（nested inference）というパターンに対応します。これは、それ自体が再帰的に推論クエリを実行する確率モデル上で推論クエリを実行することです（Stuhlmüller & Goodman, 2014; Zhang et al. 未発表）。実際には、このツールボックスは目覚ましい成功を収め、社会認知における一連の複雑な心理現象を定量的にモデル化するために使用されてきました（Evans et al., 2017）。
では、私たちはついに要求（1）を解決したのでしょうか？確かに、人間の思考の無限性、生成性、再帰性を回復する上で進展がありました。しかし、プログラミングパターンは、以下の2つの理由から、心の理論の満足のいく形式化ではありません。
まず、本稿の後半で示すように、これらのプログラミングパターンを適用したモデルは簡単に書けますが、その挙動は私たちの直感に反する可能性があります — したがって、これらのパターンは典型的な心の理論における重要な側面を完全に捉えているわけではありません。次に、さらに重要なこととして、私たちは（2）理論変化の能力を失ってしまいました。心を考える際に推論できるような、形式化され「列挙可能」な「プログラミングパターン」構造は存在しないのです。
プログラミング言語モデル したがって、本稿では、ベイジアンネットワーク/因果文法モデルとプログラミングパターンモデルの利点を統合した新しい視点を提案します。私たちの見解では、心の理論は一連のプログラミングパターンというよりは、ひとつのプログラミング言語全体に似ています。ChurchやWebPPLと同様に、それは確率的プログラミング言語です。しかし、ChurchやWebPPLとは異なり、それは汎用的な確率的プログラミング言語ではなく、領域固有言語（domain-specific language、略してDSL）であり、心に関する推論の領域に特化しています。
プログラミング言語理論という分野では、長い間、各領域の理論を表現するためのDSLを設計するという伝統がありました（Bentley, 1986; Bernstein & Kjolstad, 2016; Iverson, 2007）。これには、古典力学理論（Sussman & Wisdom, 2015）、光線光学（Hanrahan & Lawson, 1990）、色知覚（Chen, Chang, & Zhu, 2024）など、科学分野のDSLも含まれます。
プログラマーが特定のプログラミングパターンを使用することに頼るのではなく、DSLの構文は、対象領域で問題を定式化するための概念的な語彙を直接提供し、その言語の意味論は、これらの問題がどのように解決されるかを決定します。したがって、「理論」は言語の設計に組み込まれています。
重要なのは、任意のプログラミング言語の構文と意味論は、数学的に形式化でき、さらには多くの可能な構文と意味論の集合（スキーマ）のメンバーとして機械的に処理できることです（Felleisen, Findler, & Flatt, 2009; Pierce, 2002）。したがって、理論の変化は、可能なプログラミング言語の空間上の学習プロセスとして形式的にモデル化できます。
ここで言うDSLとはどのようなものでしょうか？
これまで、DSLに関する議論は非常に抽象的でした。先に進む前に、「推論の推論」に特化した領域固有言語（DSL）の具体的な例、すなわち「memo」（mental modelsの略）という実際の言語（Chandra, Chen, Tenenbaum, & Ragan-Kelley, 2025）について簡単に紹介しましょう。memoは、社会認知の効率的な計算モデルを構築するための実用的なツールとして開発されました。
私たちの議論では、Goodman et al. (2015) が「確率化された思考言語仮説」を議論する際に実世界の言語Churchを例に挙げたのと同様に、memo（およびその後いくつかの仮説的バリアント）を問題の例示に用います。
まず、memoを簡単に見てみましょう。memoでは、モデルの核となるのはエージェントが選択を行うプロセスです。例えば、アリーがある日の仕事帰りにバーbで飲むことを選択したとします。彼は合理的なエージェントなので、職場に近いバーを選ぶ可能性が高いでしょう。memoでは、この選択行動をchooses式を使ってモデル化できます。これは、アリーがバーの集合Barsの中からバーbを選択し、その確率が職場からbまでの距離の減少関数に比例する（wpp、すなわち「with probability proportional to」）ことを表現します。
なぜDSLを使うのか？「少ない」が「多い」とはどういうことか？
chooses、observes、thinksといったmemoのステートメントは、汎用確率プログラミング言語（PPL）におけるサンプリング、コンディショニング、再帰的クエリに大まかに対応します。では、memoでこれらのモデルを記述することで、具体的にどのようなメリットが得られるのでしょうか？実際、私たちは、他の種類のプログラムを表現するのに適さないかもしれない専門言語を使用することで、表現能力を犠牲にしていないでしょうか？
数十年にわたるプログラミング言語分野の研究から得られた重要な教訓は、汎用性には代償が伴う、すなわち能力がもたらす負担があるということです。言語の表現力を高めることは、プログラマーが意図しないことを表現してしまう可能性を高め、結果としてプログラムの正確性を保証するためのプログラマーの負担を増大させます。したがって、プログラミング言語の先駆者であるHudak (1996) は、問題解決に理想的な抽象化とは、研究領域に「ぴったりと一致する」プログラミング言語である、「多すぎず、少なすぎず」と記しています。
ChurchとWebPPL自体が、この原則の具現化です。理論上、チューリング完全性の論理に基づけば、任意のWebPPLプログラムの確率計算は、通常の（非確率的な）プログラミング言語で手動で実装できます。実際、WebPPLプログラムはJavaScriptに自動翻訳されて実行されます（Goodman & Stuhlmüller, 2014）。WebPPLがJavaScriptと比較して加える価値は、確率計算が常に正しいことを保証することです—例えば、分布が常に正しく正規化されることを保証することによって。WebPPLは、ユーザーが正しい確率的推論のみを行うように制限することで、複雑な確率モデルを構築する能力を与えています。
同様に、memoがWebPPLと比較して持つ価値は、その制限性にあります。memoは、ユーザーがエージェントに関する正しい推論のみを行うように制限することで、複雑な心の理論モデルを構築する能力を与えています。
これを例で説明しましょう。Ali-ZoeのシナリオをWebPPLでどのように実装するかを考えてみましょう。Aliが近くのバーを選ぶ（例1）ことは、「推論としての計画」（planning-as-inference）パターンを適用することでモデル化できます（ここではconditionではなく、そのバリアントであるfactorを使って勾配のある確率的選択をモデル化します）。
このプログラムを実行すると、モデルが二人の遭遇確率を0%と誤って予測することがわかります。ああ、もちろんそうでしょう！なぜなら、私たちはzoe_b != ali_bという条件で推論しているため、推論結果が「彼らが遭遇する」という条件を満たすことはないからです。
一体何が問題だったのでしょうか？問題は、WebPPLが言語レベルで「エージェント」という概念をサポートしていないことです — 「ランダムな選択」という概念しかサポートしていません。Zoeのzoe_bの選択とAliのali_bの選択は、概念的に区別できません。したがって、「推論としての計画」というパターンを適用すると、WebPPLが生成する推論は、まるでZoeが自分が行くバーだけでなく、Aliが行くバーも選択できるかのように機能します — つまり、まるでZoeの「願望」がAliを「マインドコントロール」する力を与えているかのように機能します。Chandra、Chenら（2025）は、このようなバグを「行為者混同」（perpetration confusion）と呼んでいます。これは、どのエージェントがどのランダムな選択を制御しているかを混同する問題です。
経験豊富なプログラマーでも、実際にはこのようなバグに遭遇しやすいものです（Levine, 2018）。
この例が示しているのは、汎用確率プログラミング言語でプログラミングパターンを使用することで、心の理論に適合する多くの計算の「構成要素」が得られる一方で、これらの「構成要素」は、私たちの心の理論に反する計算を表現するためにも組み合わせられてしまう可能性があるということです — 例えば、あるエージェントが別のエージェントを「マインドコントロール」するような計算です。memoのようなDSLは、心理的推論に必要かつ十分な構造のみを提供することで、この問題を解決します。例えば、言語レベルでエージェントを推論するための構文と意味論を提供することで、「マインドコントロール」のような問題が設計段階から防止されます。
次のセクションでは、memoのようなDSLがその設計を通じて、どのように心の理論を具体的に体現しているかを検討します。
DSLはどのように心の理論を体現しているのか？
プログラミング言語は最終的に、その構文（syntax）と意味論（semantics）という2つの形式構造によって定義されます。本セクションでは、memoの構文と意味論が、心の理論における原則を具体的にどのように体現しているかを、2つのケーススタディを通じて議論します。
この過程で、memoの構文と意味論の変化を通じて、私たちが形式化したいと考える心の理論の異なるバージョンをどのように生成できるかを示します。心の理論の研究は、神経学的に正常な成人によって保持されている理論だけでなく、子供、高齢者、非ヒト霊長類によって保持されている心の理論も特徴付けることを目指しています。さらに、全能の存在（神など）や機械（Brink & Wellman, 2020）のような「非典型的な」心に対するこれらの心を持つ者の理論を特徴付けようとしています。同時に、世界におけるあるエージェントを観察したときに、個人がどの理論をそのエージェントに帰属させるかをどのように決定するかを理解することも目指しています（Burger & Jara-Ettinger, 2020; Gray, Young, & Waytz, 2012）。memoのようなDSLの様々なバリアントは、これらの理論の形式的な表現ツールとして機能します。
構文に関するケーススタディ：誤信念
memoでは、thinks文はエージェントの信念を表現するために使用されます。私たちはすでに、エージェントの真の信念や不確実性を表現するためにthinksをどのように使用できるかを見てきました。しかし、この構造はエージェントの誤信念を表現するためにも使用できます。例えば、「ゾーイはアリーが安いバーを選ぶと思っている」が、実際にはアリーが職場に近いバーを選んだという状況をモデル化するには、次のように書くことができます。
もちろん、このような表現の完全な汎用性は、実際には通常必要ありません。ほとんどの場合、memoのプログラマーは、あるエージェントが別のエージェントの決定を正しく知っていることを表現するだけで十分です。ゾーイがアリーの行き先を事前に知っていたとしましょう。例えば、彼がソーシャルメディアに投稿したからかもしれません。原則として、次のようにモデル化できます。ゾーイはアリーがバーを選んだと考えており（任意の分布に従う）、その後、彼女が実際にどこに行ったかを正しく観測したとします。
もちろん、このような表現の完全な汎用性は、実際には通常必要ありません。ほとんどの場合、memoのプログラマーは、あるエージェントが別のエージェントの決定を正しく知っていることを表現するだけで十分です。ゾーイがアリーの行き先を事前に知っていたとしましょう。例えば、彼がソーシャルメディアに投稿したからかもしれません。原則として、次のようにモデル化できます。ゾーイはアリーがバーを選んだと考えており（任意の分布に従う）、その後、彼女が実際にどこに行ったかを正しく観測したとします。
しかし、このような書き方は満足できるものではありません。冗長であり、実際には計算に使用されない「仮想的」な事前分布をthinks内で選択する必要があるからです。
このような状況が日常のモデリングで非常に頻繁に発生するため、memoはこれらの問題を解決するための効率的で軽量なショートカットを提供します：knowsステートメントです。
memoのknows文は、Phillipsら（2021）によって提案された「知識先行、信念後」（knowledge before belief）の概念と一致しています。多くの点で、knowsはthinks/observesよりも基本的なものです。その構文は、thinksが持つ複合的で再帰的な構造よりも単純であり（図2参照）、実際にはthinksやobservesよりも頻繁に使用され、memoコンパイラで実装に必要なコード行数も少なくなっています。
thinksとobservesという複雑なステートメントを削除し、より単純なknowsステートメントのみを保持した新しい「簡略版」memoを作成したとしましょう。その場合、何を失うのでしょうか？この「memo-junior」と呼べるプログラミング言語は、先の「クイックスタート」セクションの例1と例2のような様々なシナリオをモデル化するのに依然として使用できます。しかし、「memo-junior」は、エージェントが現実世界の真の状態とは異なる自身の信念を持つ状況を表現することができません。このようにして、memo-juniorを用いて、3歳児の心の理論に関する候補仮説を形式化し始めることができます。
意味論のケーススタディ：全知性
例3の以下の実装試行を考えてみましょう。
このモデルはmemoでエラーを引き起こします — 問題は、Zoeが自身の心理モデルでAliの選択bを知らないことです。ZoeがAliのbの何らかの関数に基づいてバーを選択することは意味がありません。実際、彼女はそもそもそのような関数を計算できるべきではありません！もしZoeがこのようにバーを選択できるとすれば、それは彼女がAliに対して何らかの「読心術」能力を持っていることを意味します。したがって、memoはこのような文を禁止しています。
しかし、ここで「禁止」とは形式的に何を意味するのでしょうか？この制限的なルールは、memoの形式意味論（Chandra, Amin, & Zhang, 2025）に見出すことができます。これは、chooses文がタイプ良好であるかどうかを導出するための前提条件です（図3参照）。あるエージェントaが、意思決定の確率分布を定義するためにある式eを使用する場合、aはeの値を理解している必要があります。
実際には、この前提条件はmemoコンパイラでチェックされ、chooses文に遭遇するたびに実行されます。チェックが失敗した場合、システムはプログラマーに、例3で示したように修正を促します。すなわち、必要に応じてknowsまたはthinks文を使用して、ZoeがAliのバー選択に関する心理モデルを明確に記述するように促します。
このように、memoの意味論における前提条件と後置条件は、「心の読み込み能力がない」という制限など、「エージェンシー」（agency）に関する基本的な原則を捉えています。memoの設計者は、意味論が具現化すべき原則を明確に列挙し、memoの意味論がどのようにこれらの原則を具体化しているかを詳細に説明しています（Chandra, Chen et al., 2025, セクション3.1参照）。しかし、これらの原則はmemoの設計者によって直感に基づいて選択されたものであり、異なる直感に合わせるために修正することも可能です。
例えば、上で議論した前提条件を緩和すれば、「全知のエージェント」の可能性を含む心の理論を形式化し始めることができます — これは、子供たちが親を記述する際によく示す心理理論の特徴です（Barrett, Richert, & Driesenga, 2001）。
理論—あるいはDSL—は時間とともにどう変化するのか？
GopnikとMeltzoff（1997）は、理論変化のダイナミクスを科学理論の変化（Kuhn, 1962; Lakatos, 1970）にたとえました。しかし、このプロセスをどのように形式的にモデル化するのでしょうか？心の理論をDSLと見なすこの視点は、理論構築をプログラミング言語設計と見なすことができることを示唆しています。本セクションでは、この比喩が理論変化の3つの視点をどのように支持するかを議論します。
合理的視点
Goodman et al. (2006) の、理論変化がベイジアンネットワーク空間上の階層的推論であるという見解に戻ると、私たちは今、理論変化が可能なプログラミング言語の構文と意味論の階層的推論によって駆動されると言えるでしょう。私たちは「有用性」、つまりより強力な表現効率と予測能力の方向へと理論を発展させます。結局のところ、現実世界のプログラミング言語も多くの場合、このように発展するのです。それは「象牙の塔」のような革新からではなく、実際の問題解決の中で示される実用性から生まれます（Meijer, 2007; Meyerovich & Rabkin, 2012; Stroustrup, 2020）。
この考えをどのように形式化するのでしょうか？Ellis et al. (2021) は、有用なパターンを特定し、それらを再利用可能な抽象化として形式化することでDSLを「成長」させるシステムについて記述しています。心の理論をDSLと見なすならば、私たちはそのようなシステムを用いて、心の理論の成長プロセスを同様の方法で形式化することを想像できるでしょう。
文化的視点
心の理論に用いられる自然言語の学習が、子供の誤信念を表現する能力の獲得に貢献するという大量の証拠があります（De Villiers & de Villiers, 2014; De Villiers & Pyers, 2002; Morgan & Kegl, 2006; Pyers, 2020; Pyers & Senghas, 2009; Schick, De Villiers, De Villiers, & Hoffmeister, 2007）。例えば、PyersとSenghas（2009）は、「メアリーは幽霊を見たと思った」という文には、真の主節（「メアリーは思った」）と偽の従属節（「彼女は幽霊を見た」）が含まれていると述べています。このような構文は、学習者に他者の誤信念を理解するために必要な論理的ツールを提供する可能性があります。
DSLの視点は、この仮説を形式化する方法を提供します。以前に議論したように、私たちは3歳児の心の理論を、複合的なthinks表現を欠く「memo-junior」としてモデル化できます。子供が他者の信念の文脈で「thinks」という言葉に触れるとき、これは子供にthinks固有の再帰的な構文構造を提供し、最終的にthinksの意味論を発明し、それによって誤信念を表現する能力を習得するのに役立つ可能性があります。
実用主義的視点
理論変化は混沌としたプロセスです。GopnikとMeltzoff（1997）は、新しい理論が慎重に検討されるが、古い理論はまだ完全に放棄されていない過渡期について述べています。実際、AmsterlawとWellman（2006）は、ある子供が一日の中で異なる課題において、2つまたは3つの異なる心の理論を使用する兆候を示す可能性があることを発見しました。
興味深いことに、プログラミング言語の設計も同様のパターンをたどります。プログラミング言語の発展自体もまた、混沌としたプロセスなのです（Steele Jr, 1998）。Pythonプログラミング言語を例に挙げましょう。2000年代初頭、Pythonユーザーは、テキスト（「文字列」）の抽象化に根本的な欠陥があることをますます明確に認識しました。この言語は、文字シーケンスとこれらの文字を表すバイトシーケンスを区別していませんでした。これにより、非ラテン文字のテキスト入力を処理することが困難になり、ますますグローバル化するプログラマーコミュニティにとって深刻な問題でした。
そのため、言語設計者は次の主要バージョンであるPython 3でこれらの抽象化を根本的に再設計し、2008年にリリースしました（van Rossum, 2008）。私たちはこの新バージョンを「パラダイムシフト」と見なすことができます。
しかし、科学におけるパラダイムシフトと同様に、この移行プロセスは一朝一夕にはいきませんでした（Coghlan, 2012）。旧バージョンのPython 2はその後12年間も広く使用され続け、2020年になってようやく正式に廃止されました。この間、多くのプログラマーが様々な理由でPython 3への移行をためらいました。既存のPython 2コードをPython 3に書き直したくない人もいれば、Python 2にしか存在しないライブラリに依存している人もいました。
そのため、長年にわたり、Python 2とPython 3のどちらを選ぶかは実用的な問題となりました。新しいプロジェクトを開始したり、本当にPython 3の機能が必要なプログラマーは通常新しいバージョンを選択し、大規模な既存のコードベースを維持しているプログラマーは可能な限りPython 2を使い続けました。中には、両方のバージョンと互換性のあるコードを慎重に記述するプログラマーも少なくありませんでした（Malloy & Power, 2019）。
子供が新しい心の理論を採用する過程でも、同様のダイナミクスが見られると予想されます。新しい理論がより説得力があるとしても、古くから検証されてきた理論を保持することは実用的な価値を持つ可能性があります — おそらく、古い理論としか互換性のないモデルや計算方法を利用し続けるためです。したがって、ある子供は、観察者にとって特定の心の理論のいずれとも完全に一致しないように見える行動パターンを示すかもしれません。
考察と今後の課題
本稿では、心の理論を、他者の心に関する問題を定式化し、推論するために使用できる、領域固有のプログラミング言語と見なすことが価値があると提案しました。memo確率プログラミング言語を例にとり、プログラミング言語がどのように心の理論をエンコードするか、プログラミング言語の異なるバリアントがどのように異なる心の理論をエンコードするか、そして「プログラミング言語」という比喩が心の理論の発展プロセスを理解するのにどのように役立つかを議論しました。
最後に、PL（プログラミング言語）理論が、さらに深い問いに答えるためのツールを提供してくれる可能性について考察します。
直観的理論の組み合わせ
現実世界の問題を解決するために、私たちの心の理論は、物理世界に関する直観的理論（Liu, Outa, & Akbiyik, 2024）など、他の領域の直観的理論と相互作用できる必要があります。複数の知識システムを横断する計算を実行するために、これらの直観的理論をどのように組み合わせるべきでしょうか？
直観的理論をDSL（ドメイン固有言語）と見なすならば、「DSLの組み合わせ」という観点からこの問題を考え始めることができます。実際、PLコミュニティでは、DSLがモジュール的に相互作用できるように設計する方法が長年研究されてきました（Felleisen et al., 2018参照）。
綿密に設計された「アプリケーションプログラミングインターフェース」（API）を持つDSLは、プログラマーが複数のDSLの利点を組み合わせて多言語プログラムを記述することを可能にします。例えば、ウェブサイトを作成するために、プログラマーはHTMLを使用してページの構造を定義し、CSSを使用してタイポグラフィスタイルを定義し、JavaScriptを使用してアニメーション効果を定義するかもしれません。HTML、CSS、JavaScriptは、ウェブデザインの異なる領域（構造、スタイル、スクリプト）に特化した非常に異なる3つの言語です。しかし、これら3つのDSLには綿密に設計されたAPIが備わっているため、プログラマーはそれらの間で相互作用可能なプログラムを簡単に記述できます。
私たちは、心理的推論のためのDSLと物理的推論のためのDSLも同様に適切なAPIを備えており、日常生活の社会物理的状況を推論するために組み合わせることができると想像できます（例示参照）。
直観的理論の比較
直感的に、成人の人間は3歳児や非ヒト霊長類よりも「豊かな」心の理論を持っています。しかし、「心の理論がどれほど豊かであるか」や「どれほど表現力があるか」という主張を、どのように形式化すればよいのでしょうか？理論の豊かさや表現力を定量化し、測定することはできるのでしょうか？
心の理論をDSLと見なすならば、プログラミング言語の分野における「表現力」（expressivity）に関する形式的定義、例えばFelleisen（1991）が提案した定義を適用して、そのDSLが表す心の理論の表現能力を形式化することを検討できます。
この定義をある心の理論の表現力を測る基準として使用することで、心の理論が進化と発展の過程でより高い表現力へと向かうという仮説を検証することができます。
心に関する定理
人々は具体的な状況を推論できるだけでなく、他者に関する普遍的な命題も推論できます。例えば、どのような状況でも、あるエージェントが変数xの値を忘れた場合、彼らは以前にxについて信念を持っていたに違いない、ということに私たちは同意するかもしれません。
これらの普遍的な直感はどこから来るのでしょうか？心の理論をDSLと見なすならば、プログラミング言語に関する一般的な定理の陳述と証明技術を適用して、これらの「心に関する定理」を形式化し、研究することができます。
例えば、Chandra、Amin、Zhang（2025）は、任意のmemoモデルにおいて、あるエージェントが変数xの値を知っている場合、そのエージェントはxについて確実である（すなわち、その視点から見てH(x) = 0である）という性質を形式化する方法を示しました。しかし、逆は成り立ちません。なぜなら、エージェントは誤った信念についても確信を持っている可能性があるからです。
したがって、私たちは第一原理から「心に関する定理」を導き出すことができます。それは、知識は確実性を意味するが、確実性は知識を意味しない、というものです。
memo：真のAGIのための再帰的推論確率的プログラミング言語：memoの実装、具現化されたゲーム
フレーム問題
他者の心に関する私たちの完全な理論は非常に広大であり、信念や欲望だけでなく、感情、記憶、注意、知覚など、多くの側面を含んでいます。具体的な状況に直面したとき、私たちは「フレーム問題」（McCarthy & Hayes, 1981）、つまり、関連する理論の部分だけを効率的に呼び出す方法をどのように解決するのでしょうか？
この点において、PLにおける「プログラムスライス」（program slicing、Weiser, 1984）の概念は価値があるかもしれません。「プログラム（またはプログラミング言語）のスライス」とは、無関係な部分を除去した後に残る関連するサブセットを指します。
豊かで汎用的な心の理論が、効率を高めるために不要な構文や意味論を削除して、特定の状況に特化した心の理論に「スライス」できると想像できます。
原文リンク：https://osf.io/qhc6y/download