機能と存在の分離【生命編】：システムに「命」を吹き込むのは誰か？
※ この記事はnote.comの自作コンテンツの転載です。
機能と存在の分離【生命編】：システムに「命」を吹き込むのは誰か？
本記事は「機能と存在の分離」をテーマにした3部作の完結編（第3回）です。
まだお読みでない方は、ぜひ第1回・第2回からご覧ください。
1. 「自律」という言葉の罠
「自律的な存在（オブジェクト）」を設計しようとするとき、私たちはつい「それは自ら状況を判断し、能動的に動くべきだ（アクティブ）」と考えてしまいがちです。しかし、ここに大きな混同が潜んでいます。
私たちが「アクティブかパッシブか」を論じるとき、それは往々にして「スレッドを自ら持つか」「ポーリングを行うか」といった、実装上の都合に引きずられていることが多いのです。
2. 「存在（Being）」としての自律
ドメイン分析レベルでの状態遷移は、決して「実装の手順」ではありません。それは、その存在が世界の中で保ち続けるべき 「論理的な可動域」 の記述です。
- 例： 「『契約済み』の状態でなければ『出荷』は発生しない」というルール。
これは、外部から「出荷せよ」と命じられるか（パッシブ）、自分が機を熟したと判断するか（アクティブ）に関わらず成立する「世界の理（Being）」です。
この意味において、オブジェクトは 「論理的に自律」 しています。何者にもその理を書き換えることはできないからです。
3. 命（エネルギー）を吹き込む「機能（Doing）」
では、その「理」に沿って実際に世界を動かすエネルギーはどこから来るのでしょうか。それが「機能（Doing）」の役割です。
-
実装上のアクティブ: 状況を監視し、トリガーを引く「ループ」や「イベントハンドラ」。
-
実装上のパッシブ: 外部からのメッセージを待つ「レセプター」。
これらはすべて、安定した「存在（Being）」という回路に、実行時という名の「電流」を流すための接続方式に過ぎません。
4. 創造の瞬間：ファクトリーによる初期配置
「存在（Being）」が論理的に自律しているためには、生まれた瞬間から世界（関係性）と整合している必要があります。ここで 「初期配置（Initial Configuration）」 と 「ファクトリー（Factory）」 が決定的な役割を果たします。
-
天地創造（Setup）:
ファクトリーは、システムという「世界」の物理法則と初期状態を定義する「創造主」です。どのセンサーがどのコントローラーに繋がるか、初期値はいくつか。これらを決定し、完全な状態でオブジェクトを産み落とします。 -
不変の出生:
自律的なオブジェクトは、後から「設定」されるのを待つのではなく、コンストラクタ（ファクトリー）によって 「生まれた瞬間から完全な状態」 として生成されるべきです。
「機能（Doing）」が時間を進めるエネルギーなら、ファクトリーは時間が動き出す前の「空間構築」を担います。この 「構築（Creation）」と「実行（Runtime）」の分離 こそが、堅牢なライフサイクルを生みます。
5. 結論：存在に「駆動権」を持たせない
「自律している」ことと、「能動的に動く（駆動権を持つ）」ことは違います。ここを混同しないことが、設計の最終的な鍵です。
-
自律（Autonomy）とは「拒否権」を持つこと:
外部から何を言われても、自分の内部整合性（Being）に反することは「できない」と断る力です。これは静的な強さです。
状態遷移で言えば、「イベントが来るまでその状態に留まり続ける（待てる）」のが自律です。 -
駆動権（Drive）とは「時間を進める力」を持つこと:
「いつ動くか」「次に何をするか」を自分で決めて、スレッドを回す力です。これは動的な責任です。
状態遷移で言えば、イベント待ちのない 「自動遷移（フローチャート）」 が連続している状態は、オブジェクトが駆動権を持ちすぎている兆候です。
システムを堅牢にするには、オブジェクトに 「自律（拒否権）」は与えつつ、「駆動権（Drive）」は持たせないのが理想です。
「駆動権」はシステム全体を俯瞰する「機能（Doing）」や「ランタイム」に預け、個々のオブジェクトはあくまで「聞かれたら答える」「叩かれたら響く」という高潔な受動性を貫く。これこそが、変更に強く、予測可能な「生命的なシステム」の正体です。
※補足：目的（Goal）と駆動権（Drive）の違い
「目的地に向かって進む車（Cities: Skylinesのような）」は、一見すると自ら駆動しているように見えます。しかし、それがゲームループ（Doing）によって update() された時だけ位置を計算しているのであれば、それは「駆動権」ではなく高度な「自律（計算ロジック）」です。
もしオブジェクトが勝手に時間を進めていたら、システム側でフレームレート（時間の速度）を変えたり、一時停止したりすることが不可能になってしまいます。彼らは「どこへ行くか（Goal）」は知っていますが、「いつ時間を進めるか（Drive）」という権限は持っていないからです。この 「時間の主導権」 を誰が握っているかが、自律と駆動を見分けるリトマス試験紙になります。
6. 哲学的総括：DoingはBeingの「メタ階層」
この関係性は、「DoingはBeingのメタレベル（上位階層）にある」 と言い換えることもできます。ここで、「指揮者と演奏者（オーケストラ）」 の関係を想像すると、その役割分担が鮮明になります。
- Being（演奏者）： 楽器を奏でる技術と譜面（Logic/Space）を持っています。しかし、自分勝手なタイミングでは音を出しません。
- Doing（指揮者）： 全体のテンポ（Time）を支配し、「今、この音を」と指示を出すメタ存在です。
「指揮者を見ない演奏者」 こそが、まさに 「意志（駆動権）を持ってしまったオブジェクト」 の姿です。彼らは自分の内部時計で勝手に演奏を始め、全体のハーモニー（整合性）を破壊してしまいます。
技術的な実例：交差点の信号機
もし交差点の各信号機が、それぞれ勝手に sleep(3000) しながら時間をカウントしていたらどうなるでしょうか？ 微細なズレが蓄積し、いつか「全方向が青」になる瞬間が訪れて大事故になります。
- Being（信号機）： 「赤の次は青」という順序（State）だけを知っている。
- Doing（制御機）： 「今、切り替える」というタイミング（Time）を一括管理する。
「時間（タイミング）」を個々のオブジェクトから取り上げ、メタ階層（Doing）で一元管理する。これが、システム全体の整合性と安全性を保証する唯一の方法です。
「指揮者がいなくても楽譜通りに完璧に演奏できる演奏者」 と、「正確なテンポでオーケストラ全体を導く指揮者」。この両者が揃って初めて、美しい音楽が奏でられます。
これをシステムに置き換えるなら、私たちが目指すべきは、「自律的な論理を持つオブジェクト（Being）」 を定義し、それを 「全体を統率する機能（Doing）」 によって導くことです。この2つが揃ったとき、システムは初めて「生命」を宿します。
Discussion