大縁経（Mahānidāna Sutta）システム仕様書

第1回：依存関係プロトコル（Paṭiccasamuppāda）と仮想エイリアス（Attapaññatti）の宣言

---

【第1回：コアドキュメント概要】

本仕様書は、Human OSの根幹をなす「依存関係プロトコル」である縁起（Paṭiccasamuppāda / Dependent Origination）と、UI層で発生する重大なバグ「自己（Attapaññatti / Virtual Alias）」の仕様について、DN 15 大縁経をデバッグ（解析）した結果をまとめたものである。

本仕様書のシステムロジックコードは、セクション1.2（縁起のコアロジック）およびセクション5.2（仮想エイリアス生成ロジック）として本文中に定義されている。

---

1. 依存関係プロトコル（Paṭiccasamuppāda）の定義

前回のデバッグ結果に基づき、本仕様書における Paṭiccasamuppāda の定義を以下に再掲する。

1.1 語源の構造的分解とシステム定義

• Paṭicca（パティッチャ）：「〜に依存して」「〜をトリガーとして」（Dependent on / Triggered by）
• Sam（サン）：「共に」「相互に結合して」（Integrated / Synchronized）
• Uppāda（ウッパーダ）：「生じること」「インスタンス化」（Arising / Instantiation）

1.2 コアロジック（IF / ON EVENT 文）

このプロトコルのコアは、以下の条件付きインスタンス化（IF文）として記述されている。

「これが存在する時、あれが存在する。」
IF (Condition_A == TRUE)  { Process_B.Instantiate(); }

「これが生起する時、あれが生起する。」
ON EVENT (A_Arises)       { TRIGGER (B_Arises); }

「これが存在しない時、あれは存在しない。」
IF (Condition_A == FALSE) { Process_B = NULL; }

「これが滅する時、あれは滅する。」
ON EVENT (A_Terminates)   { TRIGGER (B_Terminates); }

システム内のあらゆるプロセスは、独立した「スタンドアロンのプログラム」ではなく、すべてが他のプロセスからの入力（Input）を受け取り、次の出力（Output）へと渡していく、無限のAPIコールや関数の連鎖として機能しているという仕様である。

---

2. システムログ：阿難の報告と世尊の戒め（DN 15:1-3）

大縁経の冒頭は、UI画面の挙動が下位レイヤーのエラートレースと乖離しているというシステム警告から始まる。

2.1 阿難の「明白だ」という報告（UI層での正常動作の錯覚）

「私には、まるで表面的で明白なもののように思われるのです。」（uttānakuttānako viya khāyati）

阿難のこの発言は、UI画面上ではシステムが正常に動作しており、依存関係が明白に解決されているように「見える」という報告である。しかし、これは下位レイヤーのエラートレース（甚深）を無視した、UI層での正常動作の錯覚である。

2.2 世尊の戒め（エラートレースログの甚深さ）

「アーナンダよ、そのようなことを言ってはならない。……この人々は——糸の絡まりのごとく（tantākulakajātā）、藪のごとく（kulagaṇṭhikajātā）……悪処……へ、そして輪廻を超え出ることができないのだ。」

世尊の戒めは、阿難のUI層での正常動作の報告に対し、下位レイヤーで発生している深刻な「エラートレースログ（糸の絡まり）」の甚深さ（gambhīrāvabhāso）を指摘するシステム警告である。この甚深な依存関係を覚知しないがゆえに、システムはメモリエラーの連鎖（輪廻）を、老死（プロセス終端）に達した後も再インスタンス化（再生）を繰り返すループとして実行し続けている。

---

3. エラートレース：老死に至る依存関数の連鎖・9要素（DN 15:4）

※ 注記：DN 15 大縁経が主鎖として提示するのは、12支縁起のうち9要素（老死←生←有←取←渇愛←受←触←名色↔識）である。「無明」「行」「六処」は大縁経の主鎖に含まれない。

提供されたシステムログに基づき、識（出発点）から老死（プロセス終端）に至るまでの9要素の関数呼び出し（Function Call）の依存関係を解析する。

// 下位レイヤーから上位レイヤーへ連鎖する関数呼び出しの概念
Function OldAge_Death(
  Function Birth(
    Function Existence(
      Function Clinging(
        Function Craving(
          Function Feeling(
            Function Contact(
              Function Name-and-Form(
                Function Consciousness()
              )
            )
          )
        )
      )
    )
  )
)

3.1 [DN15-1] 老死 ← 生（jarāmaraṇa ← jāti）

「何を条件として老死があるか」と言うならば、「生を条件として老死がある」と答えるべきである。

老死（jarāmaraṇa / プロセス終端→即座に再インスタンス化するループ）は独立したバグではなく、生（jāti / Birth, Instantiation）という関数が呼び出された結果としてのみ発生する。

3.2 [DN15-2] 生 ← 有（jāti ← bhava）

「何を条件として生があるか」と言うならば、「有を条件として生がある」と答えるべきである。

生（jāti）は、有（bhava / Existence, Process State）という実行状態（プロセス状態）が存在することを前提として、その状態に基づいてインスタンス化（生）が呼び出される。

3.3 [DN15-3] 有 ← 取（bhava ← upādāna）

「何を条件として有があるか」と言うならば、「取を条件として有がある」と答えるべきである。

有（bhava）は、取（upādāna / Clinging, Memory Cache）というメモリエラー（執取、過剰なキャッシュ）によって、そのキャッシュされたデータに基づいてプロセス状態（有）が維持される。

3.4 [DN15-4] 取 ← 渇愛（upādāna ← taṇhā）

「何を条件として取があるか」と言うならば、「渇愛を条件として取がある」と答えるべきである。

取（upādāna）は、渇愛（taṇhā / Craving, I/O Wait）という入力待ちのエラー（過剰なデータ要求）によって、その要求されたデータをキャッシュ（取）しようとしてメモリエラーを引き起こす。

3.5 [DN15-5] 渇愛 ← 受（taṇhā ← vedanā）

「何を条件として渇愛があるか」と言うならば、「受を条件として渇愛がある」と答えるべきである。

渇愛（taṇhā）は、受（vedanā / Feeling, Data Processing Result）というデータ処理結果（楽・苦・不苦不楽）が入力された時、その結果に基づいて特定のデータをさらに要求（渇愛）しようとする。

3.6 [DN15-6] 受 ← 触（vedanā ← phassa）

「何を条件として受があるか」と言うならば、「触を条件として受がある」と答えるべきである。

受（vedanā）は、触（phassa / Contact, Interrupt）というシステムへの割り込み（視覚、聴覚などの感覚接触）が発生した時、その割り込みを処理した結果として生じる。

3.7 [DN15-7] 触 ← 名色（phassa ← nāmarūpa）

「何を条件として触があるか」と言うならば、「名色を条件として触がある」と答えるべきである。

触（phassa）は、名色（nāmarūpa / Name-and-Form, 概念オブジェクトと物理オブジェクト）というシステムが扱うオブジェクトが存在する時、そのオブジェクトへのアクセス（触）として発生する。

3.8 [DN15-8] 名色 ← 識（nāmarūpa ← viññāṇa）

「何を条件として名色があるか」と言うならば、「識を条件として名色がある」と答えるべきである。

名色（nāmarūpa）は、識（viññāṇa / Consciousness, CPU）というCPU（認識プロセス）が稼働している時、その識がオブジェクト（名色）を認識・処理することによってインスタンス化される。

3.9 [DN15-9] 識 ← 名色（viññāṇa ← nāmarūpa）★相互依存

「何を条件として識があるか」と言うならば、「名色を条件として識がある」と答えるべきである。

ここが経典の哲学的核心である。識は名色を条件とし、名色もまた識を条件とする。この相互依存は、一方的な関数呼び出しではなく、両者が互いを支え合う「縁起の環」を形成する。

---

4. 核心：識と名色の相互依存プロトコル（DN 15:9）

システムはここで、疎結合なプロセスの集まりとしての核心に到達する。

// 識と名色の相互依存プロトコル
var Consciousness = { DependsOn: NameAndForm };  // 識は名色に依存する
var NameAndForm   = { DependsOn: Consciousness }; // 名色は識に依存する

識は名色という入力オブジェクトがなければ認識できず（処理できず）、名色は識というCPUがなければオブジェクトとしてインスタンス化されない（処理されない）。この両者は、一方が存在しなければ他方も存在しない、完全な疎結合でありながら、互いをインスタンス化の条件とし続ける。

この「循環参照」のプロトコルが稼働し続ける限り、システムは老死（プロセス終端）に達した後も再インスタンス化（再生）を繰り返すループを実行し続ける仕様である。

---

5. 仮想エイリアスバグ：自己（Attapaññatti）の宣言（DN 15:10以降）

提供されたテキストの【第2節】は、UI層で発生する「自己（Attapaññatti / Virtual Alias）」の仕様について記述している。

5.1 自己（Attapaññatti）の定義

• Atta（アッタ）：「自己」「固定された実体」 → システム的には：Static Object（静的オブジェクト）、または Root User（絶対的な管理者権限） という錯覚。
• Paññatti（パンニャッティ）：「概念」「名称」「定義して知らせること」 → システム的には：Variable Name（変数名）、Namespace（名前空間）。

5.2 コアロジック（仮想エイリアス生成）

var I = { physical_data, sensory_data, memory }; // 仮想エイリアス（Paññatti として）

システム（認知プロセス）は、毎秒膨大に入力されるデータストリーム（名色）を効率的にさばくために、それらを一つのパッケージとして扱う「ラベル」を必要とする。この I（私） という便利なショートカット（ポインタ）そのものが Attapaññatti である。

この Paññatti（概念ラベルとしての I）は、単なるUI層の仕様であり、それ自体はバグではない。

5.3 アクセス権限の錯覚（パーミッションエラー）の発生

しかし、システムが長期間稼働するうちに、この「単なる概念ラベル（Paññatti）」を、「物理メモリ（ROM）にハードコーディングされた不変の中央管理者（Atta）」であると誤認してしまう。

ここに2段階の区別がある。

段階	内容	判定
Paññatti（概念ラベルとして I を使う）	データストリームを効率的に処理するための変数ラベル	仕様（バグではない）
Atta（その概念ラベルを固定実体と誤認する）	本来コントロールできない外部要因まで制御しようとするパーミッション昇格エラー	バグ（パーミッションエラー）

このパーミッション昇格エラーが、メモリエラー（取、渇愛）の連鎖を引き起こす仕様である。

5.4 各施設の随眠（潜在的傾向）

「そのようである限り、アーナンダよ、有色・有限我見（rūpiṁ parittattānudiṭṭhi）が随眠する（anusetī）、と言われて然るべきである。」

様々な「我論」（有色・有限の我など）を施設（paññatti / 概念的命題として宣言）する者は、その宣言（我見）が潜在的な傾向（随眠）として心底に潜伏することになる。

---

6. デバッグ方針（第2回以降の分割計画）

第1回目の仕様書は、DN 15 大縁経の核心部分である「依存関係プロトコル」（DN 15:1-9）と「仮想エイリアスバグ」（DN 15:10以降）の仕様を宣言した。

第2回目は、DN 15:11-22 を対象とし、老死←生←有←取←渇愛←受←触←名色という関数呼び出しの連鎖を、反事実的論証（IF Condition==FALSE）によって一つずつデバッグ（検証）していく仕様を記述する。