どの様な話？
AI（ChatGPT 5.4）に、
- 事前知識は 因果関係の外側に有りますか？
- それとも、後に因果関係の中に組み込むことが可能ですか？
と質問した所、
- 両方あります。
- ただし、最初はたいてい因果関係の外側にあると考えると分かりやすいです。
との回答でした。
また、
- 「事前知識をモデル化しても、全部は入りきりません。」というのは事故の原因では無いでしょうか？
- 事故を減らすにはなるべく中に入れた方が良いのでは無いでしょうか？
と質問した所、
-
事故を減らすという目的なら、事前知識は「なるべく中に入れる」方が基本的に望ましいです。
-
ただし、重要なのは、「全部を中に入れられないこと自体が問題ではあるが、無理に雑に入れることも別の事故原因になる」という点です。
との回答でした。
「プログラム自体を仕様とする」という禁忌の根本原因
- 「プログラム自体を仕様とする」のは無謀だ、というのは理解出来る
- ある程度の設計書は要る
- （私は支持しませんが）その設計書は最終的には捨てるべき
という言説は、現在、一般的だと思います。
プログラムのみを「モデル」だと、した場合、
- ベイズ統計学で言う、
- 事前知識を、
- 数学的抽象化している
すなわち、
- 「本質的でない細部を削ぎ落す」
もっとぶっちゃけて言うと、
- 何かを隠している
のだと思います。
プログラムのみを「モデル」だと、した場合、
たしかに、事前知識は、因果関係の外側に残ります。
なぜなら、
- プログラミングとは、それ自体、数学的抽象化の産物で、
- 世界の営みをモデル化するとき、
- 嫌でも（本意では無くても）ダメな、出来ない事を隠す
- 表現力が、一般的な世界の営みに対して低い
からだと思います。
プログラミングでの事前知識はそこまで複雑か？
- 一般的な世界の営みでの事前知識
に対して
- プログラミング分野の事前知識（設計書に相当）
は、
- かなり単純で、
- プログラムのみをモデルとするという禁忌さえ犯さなければ、
- 全部入り切る
のでは、と私は予想します。
- プログラムに加えて、
- そのプログラムの各手続き（関数も含めた、プログラムの部分）を結果とした際の、原因についての記述
- さらに、
その原因を結果とした際の、原因についての記述
も記録し、保守し続けさえすれば、
- 「事前知識をモデル化して、全部を入れてしまう。」
という理想が可能になると、私は強く信じます。
なぜなら、
- プログラミング事の事前知識（設計書に相当）
は、
- かなり単純で、
- プログラムのみをモデルとするという禁忌さえ犯さなければ、
- 全部入り切る
からです。
交絡因子の活用方法
正しいデータ分析でビジネスを加速する 因果推論入門 [電子書籍版]
和から株式会社川原祐哉 インプレス
という本を読んでいると、
5-2-2 層分けの考え方 で、
- 何を使ってグループを層に分ければよいのでしょうか？ その答えが交絡因子です。
と言うのです。（強調は私）
プログラムのみから見ると、
- プログラムの各手続き（関数も含めた、プログラムの部分）を結果とした際の、原因についての記述としての、
- 因果ダイアログは交絡因子
です。
- 因果ダイアログが固定なら、
- 層も固定で、テストも固定
だし、
- 因果ダイアログが、時間を経て変わった場合、
- 層も変わるし、テストも変わる
のでは無いでしょうか？
プログラムに加え、（常設の）因果ダイアログを交えると、
- 因果関係が全部入り切り、
- 良くなる
- テストが不変か、可変かの基準となる
という数学的具体化の方向性も有り得ると、私は思います。
結論
これからも「プログラミング分野ならではの、数学的具体化」の不当な欠落でプログラミングが嫌いになる人は存在し続けることでしょう。
