第2冊『日本政治 Digital Twin 全実装コード大全』――28言語を全最適し、Political Realityを実際に構築する（第4回）（第Ⅲ部　Runtime 第3章　Government Runtime――政治・行政・財政のState Transitionを実装する）

第Ⅲ部　Runtime

――政治・行政・財政のState Transitionを実装する

第Ⅰ部では、日本国家をMachine-readableにするOntologyを定義した。

第Ⅱ部では、法令、選挙・国会、行政機関、地方自治体、予算・財政・契約、統計という一次資料をCanonical Japan Stateへ統合した。

ここまでで、

[
\boxed{
PoliticalReality
\rightarrow
Ontology
\rightarrow
Data
\rightarrow
CanonicalState
}
]

という経路は成立した。

しかし、国家はDatabaseではない。

選挙が行われる。

人がRoleへ就く。

国会が議決する。

法令が公布され、施行される。

行政組織が再編される。

予算が成立する。

Resourceが配分される。

Programが実行される。

地方自治体でServiceが提供される。

そして社会のRealityが変化する。

国家とは、Stateの集合であると同時に、Stateが継続的に変化するSystemである。

第Ⅲ部では、この変化そのものをCodeへ翻訳する。

その中心が、

[
\boxed{
Government\ Runtime
}
]

である。

⸻

Runtimeの最小単位はState Transitionである。

[
\boxed{
State_t
+
Event
\rightarrow
State_{t+1}
}
]

しかし、国家規模のRuntimeでは、Eventが存在するだけではStateを変更できない。

そのEventはSchema上有効か。

誰が行ったのか。

そのRoleは有効だったか。

そのAuthorityはScope内だったか。

必要なLegal Basisは存在するか。

Evidenceは十分か。

Temporal Conditionは成立しているか。

これらを検証する必要がある。

したがって、より正確には、

[
\boxed{
State_{t+1}

Transition(
State_t,
Event,
Authority,
Evidence,
Rules,
Time
)
}
]

となる。

Runtimeとは、単にEvent Handlerを動かすことではない。

Political Realityが「どの条件なら変化したとみなせるか」を実行可能なRuleとして実装することである。

⸻

ここで最も重要なのは、

[
\boxed{
Executable
\neq
Autonomous
}
]

という境界である。

Digital Twinが法令をMachine-readableにできても、法律を制定するAuthorityを持つわけではない。

予算をSimulationできても、予算を成立させることはできない。

AI Agentが政策Optionを生成できても、政治的Decisionを代替しない。

Runtimeは国家を自律制御するEngineではない。

現実の制度主体によって行われたDecisionとEventを、正確に検証し、Canonical Stateへ反映するExecution Layerである。

[
\boxed{
MachineCapability
\neq
InstitutionalAuthority
}
]

は第Ⅲ部全体を貫くInvariantとなる。

⸻

そのため、State TransitionにはHuman-authoritative Architectureを組み込む。

Observe
 ↓
Validate
 ↓
Analyze
 ↓
Simulate
 ↓
Propose
 ↓
Human / Institutional Decision
 ↓
Authorize
 ↓
Commit Event
 ↓
Update State
 ↓
Audit

AIが担えるのは、Observation、Retrieval、Analysis、Inference、Simulation、Proposalまでである。

Authoritative Stateを変更するTransitionには、制度上有効なAuthorityが必要になる。

[
\boxed{
MachineProposal
\neq
AuthorizedDecision
}
]

である。

⸻

第Ⅲ部では、まずPolitical State Machineを構築する。

Election。

Appointment。

Resignation。

Cabinet Formation。

Diet Session。

Political Decision。

これらをCanonical Eventとして処理し、

[
PoliticalState_t
\rightarrow
PoliticalState_{t+1}
]

を生成する。

次にLaw / Regulation Runtimeを実装する。

法案提出、議決、公布、施行、改正、廃止をTemporal Transitionとして処理し、

[
LegalState_t
\rightarrow
LegalState_{t+1}
]

を再現する。

そしてDiet / Cabinet Runtimeによって、Political DecisionとGovernment Executionの境界を接続する。

⸻

行政側では、Ministry Vertical Runtimeを構築する。

Institution
   ↓
GovernmentUnit
   ↓
Role
   ↓
Authority
   ↓
Program
   ↓
Execution

というVertical Chainを実行可能にする。

ただし、HierarchyだけでAuthorityを推論しない。

[
\boxed{
OrganizationHierarchy
\neq
AuthorityGraph
}
]

である。

Role、Legal Basis、Scope、Timeを検証して初めてActionを許可する。

⸻

Fiscal Runtimeでは、

[
\boxed{
Requested
\rightarrow
Authorized
\rightarrow
Allocated
\rightarrow
Committed
\rightarrow
Paid
}
]

というState Transitionを実装する。

Budgetが成立したことと、Moneyが実際に流れたことを分離する。

Contract、Grant、Transfer、ProcurementなどのFiscal Instrumentも、それぞれ異なるEventとして扱う。

これによってDigital Twin上のMoneyは、静的なAmountからResource Flowへ変わる。

⸻

Local Government Runtimeでは、47都道府県・全市区町村を中央政府の末端Processとして扱わない。

National GovernmentとLocal GovernmentはCanonical Graph上で接続されるが、それぞれのAuthority Boundaryを維持する。

[
\boxed{
IntegratedRuntime
\neq
CentralizedAuthority
}
]

である。

国から地方へのFunding。

制度上のDelegation。

共同Program。

Data Sharing。

地方独自のDecision。

これらを異なるRelationとEventとして処理する。

⸻

そして最後に、Political、Legal、Administrative、Fiscal、Local RuntimeをIntegrated Government Runtimeへ接続する。

Political Event
     ↓
Legal State
     ↓
Government Authority
     ↓
Policy / Program
     ↓
Fiscal State
     ↓
Administrative Execution
     ↓
Local Execution
     ↓
Observed Reality

ここで初めて、Digital Twinは「現在の国家を表示するSystem」から、「国家がどのように現在へ到達したかを再生できるSystem」へ変わる。

[
\boxed{
Snapshot
\rightarrow
Transition
\rightarrow
History
}
]

である。

⸻

Runtimeにはもう一つ重要な能力がある。

Replayである。

同じOntology Version。

同じSchema Version。

同じInitial State。

同じValidated Event Log。

を与えれば、同じStateへ到達できなければならない。

[
\boxed{
InitialState
+
EventLog
\rightarrow
ReproducibleState
}
]

このDeterminismが、監査、研究、Historical Reconstruction、Simulationの基礎になる。

AI Modelの出力が変化しても、Canonical Government Runtimeまで非決定的になってはならない。

したがって、

[
\boxed{
DeterministicCore
+
ProbabilisticIntelligence
}
]

という分離を維持する。

⸻

そしてRuntimeは、必ず失敗を前提に設計する。

不正なEvent。

Evidence不足。

期限切れRole。

Authority Scope外のAction。

Source Conflict。

Schema Version不整合。

Duplicate Event。

Out-of-order Event。

System Failure。

これらが発生したとき、誤ったStateをAuthoritativeとしてCommitしてはならない。

Candidate Event
     ↓
Validation
  ┌──┴──┐
PASS   FAIL
 ↓       ↓
Commit  Reject / Quarantine
 ↓
Audit

さらにCorrection、Rollback、RecoveryをEvent Historyとして残す。

[
\boxed{
Failure
\neq
SilentStateCorruption
}
]

である。

⸻

第Ⅲ部で構築するのは、国家を自動運転するSoftwareではない。

国家の変化を、

Meaning。

Authority。

Evidence。

Time。

History。

とともに実行可能にするRuntimeである。

第Ⅰ部のOntologyが「国家とは何か」を定義した。

第Ⅱ部のDataが「国家はいまどうなっているか」を観測した。

第Ⅲ部のRuntimeは、

[
\boxed{
How\ does\ JapanState\ change?
}
]

に答える。

その最小構造は、

[
\boxed{
CanonicalState
+
ValidatedEvent
+
ValidAuthority
+
Evidence
\rightarrow
NewCanonicalState
}
]

である。

ここから日本政治Digital Twinは、静的なGovernment Data Platformを離れ、時間の中で動き始める。

[
\boxed{
Ontology
\rightarrow
Data
\rightarrow
Runtime
}
]

国家は、StateからProcessへ移る。
第3章　Government Runtime

第1節　Political State Machine

政治は、人物、政党、議席、国会、内閣を並べただけでは記述できない。

選挙が行われる。

候補者が当選する。

任期が始まり、終わる。

国会が召集される。

議案が提出される。

審議される。

議決される。

内閣が組織される。

Roleが交代する。

これらのEventによってPolitical Stateは継続的に変化する。

したがってPolitical Digital TwinのRuntimeは、

[
\boxed{
PoliticalState_t
+
PoliticalEvent
\rightarrow
PoliticalState_{t+1}
}
]

というState Machineとして実装する。

1　Political Stateを定義する

Political Stateとは、ある時点における政治的構成のCanonical Snapshotである。

概念的には、

PoliticalState {
   persons
   roles
   elections
   political_bodies
   memberships
   sessions
   bills
   decisions
   authority_refs
   valid_at
}

から構成される。

重要なのは、PersonそのものをState Transitionさせるのではなく、PersonとRole、Political Body、Election等のRelationを変化させることである。

[
\boxed{
PersonIdentity
\neq
PoliticalState
}
]

である。

2　Event-drivenにする

Current Tableを直接編集する方式では、政治史を失う。

そこで、すべての政治変化をCanonical Eventとして記録する。

ELECTION_CALLED
CANDIDACY_REGISTERED
VOTE_HELD
ELECTED
TERM_STARTED
TERM_ENDED
ROLE_ASSIGNED
ROLE_ENDED
SESSION_CONVENED
SESSION_CLOSED
BILL_INTRODUCED
BILL_PASSED
BILL_REJECTED
BILL_WITHDRAWN
CABINET_FORMED
CABINET_RESIGNED

Current Political StateはEvent LogからMaterializeする。

[
\boxed{
PoliticalHistory

InitialState
+
PoliticalEventLog
}
]

となる。

3　Event Transition Ruleを固定する

Eventが届いたからといって、即座にStateを変更しない。

PoliticalEvent
     ↓
Schema Validation
     ↓
Identity Resolution
     ↓
Temporal Validation
     ↓
Authority / Procedure Validation
     ↓
Evidence Validation
     ↓
Transition Validation
     ↓
Commit

を通す。

概念的には、

def transition(state, event):
   validate_schema(event)
   validate_identity(event)
   validate_time(event)
   validate_procedure(event)
   validate_evidence(event)
   validate_transition(state, event)
   return apply_event(state, event)

となる。

[
\boxed{
EventExistence
\neq
ValidStateTransition
}
]

である。

4　Election State Machine

ElectionはPolitical Stateを大きく変化させる。

SCHEDULED
  ↓
CANDIDACY_OPEN
  ↓
VOTING
  ↓
COUNTING
  ↓
RESULT_CONFIRMED
  ↓
ROLE_TRANSITION

といったState Machineとして表現できる。

ただし実装上のState名は、実際の法制度・Sourceで確認できるEventへ対応させる。

重要なのは、

[
\boxed{
Candidate
\neq
ElectedPerson
\neq
ActiveRoleHolder
}
]

という分離である。

当選結果が確定したことと、特定Roleの任期が開始したことを同一Eventにしない。

5　Role Transitionを独立させる

政治家の交代はPerson Nodeの上書きではない。

Person A
  │
OCCUPIES
  ▼
Role
  │
ROLE_ENDED
  ▼
Historical Occupancy
Person B
  │
ROLE_ASSIGNED
  ▼
Role

とする。

これによってRoleそのものの制度的Identityを維持しながら、OccupantをTemporalに変更できる。

[
\boxed{
RoleContinuity
\neq
PersonContinuity
}
]

である。

6　任期をTemporal Constraintにする

Roleには有効期間がある。

RoleOccupancy {
   person_ref
   role_ref
   valid_from
   valid_to
   assignment_event_ref
   termination_event_ref
}

したがって任意時点について、

occupant(role, t)

を求められる。

期限切れOccupancyをCurrent Authorityとして利用してはならない。

[
\boxed{
ExpiredRole
\Rightarrow
NoCurrentAuthority
}
]

をRuntimeで検証する。

7　Political BodyもStateを持つ

国会、各院、委員会等も固定Entityではあるが、その構成は変化する。

PoliticalBodyState {
   body_ref
   active_members[]
   active_roles[]
   session_ref
   valid_at
}

Member加入・離脱、委員会所属、役職変更をEventとして反映する。

ここでも、

[
\boxed{
Membership
\neq
Authority
}
]

である。

所属しているだけで、そのPolitical Bodyの全Authorityを個人が持つわけではない。

8　Session Runtimeを実装する

国会活動にはSessionというTemporal Contextがある。

SESSION_CONVENED
     ↓
ACTIVE_SESSION
     ↓
Meetings / Deliberations / Decisions
     ↓
SESSION_CLOSED

MeetingやBill EventをSessionへ接続することで、

「どの国会の、どの会期で、どのDecisionが行われたか」

を再現できる。

[
\boxed{
Decision
+
InstitutionalContext
+
Time
}
]

として政治的Eventを保存する。

9　Bill State Machineを分離する

BillはLegal Instrumentになる前のPolitical Entityである。

概念的には、

DRAFT / PREPARATION
     ↓
INTRODUCED
     ↓
DELIBERATING
     ↓
PASSED / REJECTED /
WITHDRAWN / EXPIRED

としてStateを遷移させる。

成立後のLegal Stateは次節のLaw / Regulation Runtimeへ渡す。

[
\boxed{
BillStateMachine
\neq
LegalStateMachine
}
]

である。

この境界によって政治過程と法的効力を混同しない。

10　DecisionをSpeechから分離する

Political Runtimeには大量のSpeech Dataが存在する。

しかし、

[
\boxed{
Speech
\neq
InstitutionalDecision
}
]

である。

発言はPolitical EventまたはEvidenceとして保存できるが、正式なDecisionを生成するには、そのPolitical Bodyに定められたProcedureを満たす必要がある。

したがって、

Meeting
 ↓
Proposal / Bill
 ↓
Procedure
 ↓
Vote / Resolution
 ↓
InstitutionalDecision

として処理する。

11　Collective Authorityを守る

国会や委員会などのDecisionは、個人Authorityだけでは説明できない。

PoliticalBody
     │
HAS_AUTHORITY
     ▼
CollectiveAction

とし、

Member AuthorityとCollective Body Authorityを分離する。

必要に応じて、

Quorum。

Voting Rule。

Required Majority。

Procedure。

などをConstraintとして検証する。

[
\boxed{
MemberAction
\neq
BodyDecision
}
]

である。

12　Cabinet StateをPolitical Stateへ接続する

内閣もTemporal Political Entityとして扱う。

CabinetState {
   cabinet_ref
   prime_minister_role_ref
   minister_role_refs[]
   formed_at
   ended_at
   evidence_refs[]
}

人が変わるたびに「政府」というEntityを上書きするのではなく、

Person。

Role。

Cabinet State。

Institution。

を分離する。

これによってHistorical Cabinet Stateを再構成できる。

13　Political EventからAuthority Stateを更新する

Role TransitionはAuthority Graphにも影響する。

ROLE_ASSIGNED
    ↓
Active Occupancy
    ↓
Role Authority Resolution
    ↓
Authority Available to Person

逆に、

ROLE_ENDED
    ↓
Occupancy Closed
    ↓
Person Authority Removed

となる。

ただしAuthorityそのものをPersonへコピーしない。

[
\boxed{
Person
+
ActiveRole
+
ValidAuthority
\rightarrow
PermittedPoliticalAction
}
]

としてRuntimeで解決する。

14　Duplicate Eventを防ぐ

同じElection ResultやRole Assignmentを複数Sourceから取得する可能性がある。

したがってEventにはIdempotencyを持たせる。

event_id
event_type
subject_ref
effective_at
source_event_ref

などから重複候補を判定する。

[
\boxed{
Replay
\neq
DuplicateExecution
}
]

である。

Event Logを再生しても、同じTransitionが二重適用されてはならない。

15　Arrival OrderとPolitical Timeを分離する

Sourceへの掲載順とReality上の発生順は一致しないことがある。

[
\boxed{
ArrivalOrder
\neq
RealityOrder
}
]

である。

したがって、

occurred_at
effective_at
published_at
retrieved_at
recorded_at

を区別する。

遅れて取得されたEventでも、Historical Stateの正しい位置へ配置できるようにする。

16　Correctionを新しいEventとして処理する

誤ったSourceやIdentity Resolutionが後で訂正された場合、過去Eventを黙って削除しない。

Original Event
     ↓
CORRECTION_EVENT
     ↓
Corrected State

とする。

これによって、

「当時Systemは何を認識していたか」

と、

「現在どのStateが正しいと判断されているか」

を両方保持できる。

17　Political RuntimeをReplay可能にする

Political State Machineの重要な能力がHistorical Replayである。

Initial Political State
       +
Political Event Log
       ↓
Replay(until=t)
       ↓
PoliticalState(t)

したがって、

[
\boxed{
PoliticalState(t)

Replay(PoliticalEvents_{\leq t})
}
]

となる。

これによって任意の日付について、議員、Role、Political Body、Session、Bill State等を再構成できる。

18　AIをTransition Authorityにしない

AIはPolitical Runtimeを支援できる。

新しい政治EventをSourceから抽出する。

Person Identity Candidateを提示する。

BillとPolicyのRelationを推論する。

異常なState Transitionを検出する。

しかし、

[
\boxed{
AIProposedEvent
\neq
CommittedPoliticalEvent
}
]

である。

AIが抽出したEventはCandidateとしてValidation Pipelineへ送る。

Canonical Political Stateを直接変更する権限は持たせない。

19　Political State Machineを完成させる

最終的なRuntimeは、

Official Evidence
     ↓
Political Event Candidate
     ↓
Identity Resolution
     ↓
Temporal Validation
     ↓
Procedure / Authority Validation
     ↓
Evidence Validation
     ↓
Canonical Event
     ↓
State Transition
     ↓
PoliticalState(t+1)
     ↓
Audit Log

となる。

その核心は、

[
\boxed{
PoliticalState_{t+1}

Transition(
PoliticalState_t,
ValidatedPoliticalEvent
)
}
]

である。

これによってDigital Twinは、「現在誰が議員か」を答えるDatabaseから、

誰が選ばれたのか。

いつRoleが始まったのか。

どのPolitical Bodyに属したのか。

どのSessionで何が審議されたのか。

どのDecisionが成立したのか。

そのDecisionによって何が次のStateへ渡されたのか。

を再生できるPolitical Runtimeへ変わる。

そして政治的Decisionの一部は、次にLegal Stateを変化させる。

法案が可決されたからといって、直ちに現行法になるわけではない。

公布。

施行。

改正。

廃止。

それぞれに異なるTemporal Stateが存在する。

次節では、

[
\boxed{
PoliticalDecision
\rightarrow
LegalEvent
\rightarrow
LegalStateTransition
}
]

を実装する。

Political State Machineから、Law / Regulation Runtimeへ。

国家の意思決定は、Ruleの変化へ進む。
第2節　Law / Regulation Runtime

Political State Machineによって、選挙、国会、議案、議決、内閣という政治的State Transitionを実装した。

しかし、Political DecisionとLegal Realityは同一ではない。

法案が提出された。

国会で可決された。

公布された。

施行された。

改正された。

廃止された。

これらは異なるEventであり、異なる時点でLegal Stateを変化させる。

したがってLaw / Regulation Runtimeの基本式は、

[
\boxed{
LegalState_t
+
ValidatedLegalEvent
\rightarrow
LegalState_{t+1}
}
]

となる。

目的は法令文を検索できるようにすることではない。

任意の時点について、

その時、日本ではどのRuleが有効だったのか。

を再構成できるExecutable Legal Stateをつくることである。

1　BillとLawを分離する

最初のInvariantは、

[
\boxed{
Bill
\neq
Law
}
]

である。

Political Runtime上のBillが所定の過程を経ても、Legal Runtimeでは別のIdentityとLifecycleを持つ。

Bill
↓
Political Decision
↓
Enactment Process
↓
Promulgation
↓
Legal Instrument
↓
Effective Legal State

Bill IdentityをそのままLaw Identityとして流用しない。

両者をRESULTS_IN等の明示的Relationで接続する。

2　Legal Instrumentを第一級Entityにする

Legal Runtimeでは、法的規範を単なるDocumentとして扱わない。

LegalInstrument {
   canonical_legal_id
   instrument_type
   official_title
   promulgation_ref
   effective_rules[]
   revision_refs[]
   legal_basis_refs[]
   evidence_refs[]
}

を中心に置く。

法律、政令、省令等は同じLegal Instrument Familyへ置きながら、instrument_typeとAuthorityを分離する。

[
\boxed{
LegalDocument
\neq
LegalEffect
}
]

である。

3　Legal LifecycleをEvent化する

法令の変化をCanonical Eventとして記録する。

LAW_ENACTED
LAW_PROMULGATED
LAW_EFFECTIVE
LAW_AMENDED
LAW_PARTIALLY_EFFECTIVE
LAW_SUSPENDED
LAW_REPEALED
REGULATION_ISSUED
REGULATION_PROMULGATED
REGULATION_EFFECTIVE
REGULATION_AMENDED
REGULATION_REPEALED

これによってCurrent Textの上書きではなく、

[
\boxed{
LegalHistory

InitialLegalState
+
LegalEventLog
}
]

として履歴を再生できる。

4　PromulgationとEffectを分離する

Legal Runtimeで特に重要なのが時間である。

[
\boxed{
PromulgatedAt
\neq
EffectiveAt
}
]

公布された法令が、その日に全面施行されるとは限らない。

したがって、

LegalTemporalState {
   enacted_at
   promulgated_at
   effective_from
   effective_to
   recorded_at
}

を分離する。

これによって「公布済みだが未施行」というStateを正確に表現できる。

5　段階施行を表現する

一つの法令でも条項ごとに施行時期が異なる場合がある。

したがって、

[
\boxed{
LawEffective
\neq
AllProvisionsEffective
}
]

である。

LegalInstrument
     ↓
Provision
     ↓
EffectivePeriod

としてProvision LevelまでTemporal Stateを持てるようにする。

概念的には、

effective(provision, t) -> true | false

を問い合わせられる。

これにより、ある日付に実際に有効だった条文集合を生成できる。

6　RevisionをVersionとして保持する

改正時に法令本文を直接置換してはならない。

LegalInstrument
  ├── Version_1
  ├── Version_2
  └── Version_3

としてRevision Historyを保持する。

各Versionには、

LegalVersion {
   version_id
   legal_instrument_ref
   valid_from
   valid_to
   amendment_event_ref
   source_snapshot_ref
}

を持たせる。

したがって、

[
\boxed{
CurrentLaw

LatestEffectiveVersion(t)
}
]

としてCurrent Viewを生成する。

7　改正法と被改正法を接続する

改正は単なるText Differenceではない。

AmendingInstrument
     │
   AMENDS
     ▼
TargetInstrument
     ↓
TargetProvision

というLegal Relationを形成する。

さらに、

ADD
REPLACE
DELETE
RENUMBER
MOVE

などのChange Operationへ展開できる。

これによって、

[
\boxed{
Amendment

LegalEvent
+
Target
+
ChangeOperation
+
EffectiveTime
}
]

として機械処理できる。

8　法令HierarchyをAuthority Graphへ接続する

Legal Instrumentは孤立して存在しない。

Constitution
  ↓
Law
  ↓
Cabinet Order
  ↓
Ministerial Ordinance

のような法的構造を記述できるが、単純なTreeだけでAuthorityを決定してはならない。

重要なのは、

LegalInstrument
     │
AUTHORIZED_BY
     ▼
LegalBasis

というRelationである。

[
\boxed{
LowerLevelInstrument
\Rightarrow
RequiresValidLegalBasis
}
]

をRuntimeで検証する。

9　Issuer Authorityを検証する

Regulationを発するにはInstitutional Authorityが必要である。

Issuer
 +
ActiveRole / Institution
 +
LegalBasis
 +
AuthorityScope
 +
Time
     ↓
ValidLegalAction

とする。

つまり、

[
\boxed{
ValidLegalEvent

ValidIssuer
+
ValidAuthority
+
ValidProcedure
+
ValidEvidence
+
ValidTime
}
]

である。

Digital Twinは文書が公開されたという事実だけから、その法的効力を推測しない。

10　Legal ReferenceとLegal Dependencyを分ける

法令同士には多数の参照が存在する。

REFERS_TO
AMENDS
REPEALS
AUTHORIZED_BY
IMPLEMENTS
DEFINES
EXEMPTS_FROM

などを区別する。

[
\boxed{
TextReference
\neq
LegalDependency
}
]

である。

単に他法令名が本文に現れただけで、Authority Relationを生成してはならない。

11　RepealをDeletionにしない

廃止された法令もDigital Twinから削除しない。

ACTIVE
 ↓
REPEAL_EVENT
 ↓
REPEALED

とする。

[
\boxed{
Repealed
\neq
Deleted
}
]

である。

過去の行政行為や政策を理解するには、当時有効だった法令を保持しなければならない。

Historical Stateでは廃止済み法令も重要なAuthoritative Evidenceになる。

12　Effective Law Setを生成する

任意時点tについて、

[
\boxed{
EffectiveLawSet(t)

{
L
\mid
EffectiveFrom(L)\leq t < EffectiveTo(L)
}
}
]

を生成する。

Provision Levelまで扱うなら、

[
\boxed{
EffectiveProvisionSet(t)
}
]

を計算する。

これにより、

「2020年時点のRule」

「2026年時点のRule」

を同じCurrent Databaseから推測するのではなく、それぞれのHistorical Legal Stateとして再構成できる。

13　Legal StateとInstitutionを接続する

法令はGovernment ArchitectureへAuthorityを与える。

LegalInstrument
     ↓
ESTABLISHES / AUTHORIZES
     ↓
Institution
     ↓
GovernmentUnit
     ↓
Role
     ↓
Authority

これによって法令改正が組織・Authority Stateへ与える影響を追跡できる。

例えばInstitutionの設置・廃止・所掌変更がLegal Eventによって発生する場合、

Legal Event
   ↓
Authority Change
   ↓
Organization Event
   ↓
Government State Transition

へ渡す。

14　Legal StateとPolicyを接続する

PolicyとLawも同一ではない。

[
\boxed{
Policy
\neq
Law
}
]

である。

Policy
  │
IMPLEMENTED_THROUGH
  ▼
LegalInstrument

または、

LegalInstrument
  │
PROVIDES_BASIS_FOR
  ▼
Policy / Program

として接続する。

これにより、「政策方針が存在する」ことと「法的根拠が成立している」ことを区別できる。

15　政治から法へのBoundaryを固定する

前節のPolitical State Machineとの接続点は明確にする。

Political Runtime
     ↓
Institutional Decision
     ↓
Legal Transition Candidate
     ↓
Legal Procedure Validation
     ↓
Promulgation / Effect Event
     ↓
Legal Runtime

したがって、

[
\boxed{
PoliticalApproval
\neq
LegalEffect
}
]

である。

Political RuntimeはDecisionを生成する。

Legal Runtimeは、そのDecisionがどのLegal Eventを経てRuleとして有効になるかを処理する。

16　RuntimeをDeterministicにする

Legal Runtimeは同じInitial Stateと同じValidated Event Logから、同じLegal Stateを生成しなければならない。

InitialLegalState
     +
ValidatedLegalEvents
     ↓
Replay(until=t)
     ↓
LegalState(t)

したがって、

[
\boxed{
LegalState(t)

Replay(
LegalEvents_{\leq t}
)
}
]

である。

AIによる法令解釈が変化しても、Canonical Legal Stateまで変化してはならない。

17　InterpretationとLegal Stateを分離する

法令には解釈が必要な場合がある。

しかし、

[
\boxed{
LegalText
\neq
Interpretation
}
]

かつ、

[
\boxed{
Interpretation
\neq
AuthoritativeLegalState
}
]

である。

AIによるInterpretation。

研究者によるInterpretation。

行政上のInterpretation。

司法判断。

これらを同一State Classへ潰さない。

Canonical Legal StateはEvidenceに基づく法令・Version・Effect・Authorityを保持し、Interpretation Layerは別に接続する。

18　AIをLegal Authorityにしない

AIは、

法令構造のParse。

改正箇所の検出。

参照法令の抽出。

Version Comparison。

Legal Basis Candidateの探索。

矛盾候補の検出。

を支援できる。

しかし、

[
\boxed{
AIInterpretation
\neq
LegalAuthority
}
]

である。

AIが「この法令はこう解釈される」と生成した文章によってCanonical Legal Stateを変更してはならない。

Machine-generated RelationはINFERREDとしてValidation対象にする。

19　Law / Regulation Runtimeを完成させる

最終的なLegal Runtimeは、

Political Decision
     ↓
Legal Event Candidate
     ↓
Legal Identity Resolution
     ↓
Procedure Validation
     ↓
Issuer / Authority Validation
     ↓
Legal Basis Validation
     ↓
Temporal Validation
     ↓
Evidence Validation
     ↓
Canonical Legal Event
     ↓
Legal State Transition
     ↓
Effective Law / Provision Set
     ↓
Audit / Replay

となる。

その核心は、

[
\boxed{
LegalState_{t+1}

Transition(
LegalState_t,
ValidatedLegalEvent
)
}
]

である。

これによって日本政治Digital Twinは、法令を「現在読めるText」としてではなく、

いつ成立し、いつ公布され、いつ何が施行され、どのVersionが有効となり、どのInstitutionとAuthorityを成立させたのか

というTemporal Legal Realityとして実行できる。

Political State Machineが国家のDecisionを動かした。

Law / Regulation Runtimeは、そのDecisionをRuleへ変換した。

しかし、Ruleが成立しただけでは行政は動かない。

国会と内閣。

Political DecisionとExecutive Decision。

法的AuthorityとAdministrative Execution。

これらを接続して初めて、国家の意思はGovernment Actionへ移る。

次節では、

[
\boxed{
Diet
\rightarrow
Cabinet
\rightarrow
GovernmentExecution
}
]

をRuntimeとして接続する。

政治と法から、実際に行政を動かすExecution Boundaryへ。

日本政治Digital Twinは、Diet / Cabinet Runtimeへ進む。
第3節　Diet / Cabinet Runtime

Political State Machineは政治主体と意思決定の変化を記述し、Law / Regulation Runtimeはその一部をLegal Stateへ変換した。

しかし、日本国家のExecutionを動かすには、さらに一つの境界を実装しなければならない。

国会と内閣である。

国会は国権の最高機関であり、国の唯一の立法機関として法律、予算、条約承認などに関与する。一方、行政権は内閣に属し、内閣は行政各部を指揮監督する。

Digital Twinでは、この制度的分業を単純な、

Diet
↓
Cabinet
↓
Ministries

というCommand Treeへ圧縮してはならない。

必要なのは、

[
\boxed{
PoliticalDecision
\rightarrow
InstitutionalAuthority
\rightarrow
ExecutiveAction
}
]

の各境界を保持したRuntimeである。

1　Diet StateとCabinet Stateを分離する

まず、

[
\boxed{
DietState
\neq
CabinetState
}
]

とする。

GovernmentRuntime {
   diet_state
   cabinet_state
   legal_state
   executive_state
}

国会の構成が変わることと、内閣の構成が変わることは別のState Transitionである。

同じPolitical Realityへ属していても、それぞれ独立したIdentity、Event、Authority、Timeを持つ。

2　Diet RuntimeをCollective Decision Engineとして実装する

国会Runtimeの中心は、個々の議員ではなくPolitical BodyによるCollective Decisionである。

Diet
├── House of Representatives
├── House of Councillors
├── Committees
├── Sessions
├── Meetings
├── Bills
├── Motions
└── Decisions

したがって、

[
\boxed{
MemberAction
\neq
DietDecision
}
]

である。

個人の発言、質問、賛否と、国会として成立したDecisionを分離する。

3　Diet DecisionをState Transitionとして処理する

国会に関係するEventを、

SESSION_CONVENED
MEETING_OPENED
BILL_INTRODUCED
DELIBERATION_STARTED
COMMITTEE_DECISION_RECORDED
HOUSE_DECISION_RECORDED
BUDGET_DECISION_RECORDED
TREATY_DECISION_RECORDED
SESSION_CLOSED

などへCanonicalizeする。

ただし、Event名そのものが法的効果を保証するわけではない。

[
\boxed{
RecordedPoliticalEvent
+
ValidProcedure
\rightarrow
InstitutionalDecision
}
]

というValidationを通す。

4　ProcedureをExecutable Constraintにする

国会のDecisionは単純なBooleanではない。

PoliticalBody
     +
Session
     +
Agenda
     +
Procedure
     +
RequiredCondition
     +
RecordedResult
     ↓
InstitutionalDecision

として処理する。

Runtimeは、どのBodyが、どのProcedureを経て、何を決定したかを保持する。

これにより「議論された」と「決定された」を混同しない。

[
\boxed{
Deliberated
\neq
Decided
}
]

である。

5　Diet Outputを型付きEventとして渡す

国会のDecisionは、その内容によって異なるRuntimeへ渡される。

Diet Decision
├── Legal → Legal Runtime
├── Fiscal → Budget Runtime
├── Treaty-related → Relevant Runtime
└── Political / Institutional → Political Runtime

つまり、Diet Runtime自体がすべてのStateを変更するわけではない。

[
\boxed{
Decision
\rightarrow
TypedTransitionCandidate
}
]

として次のDomain Runtimeへ渡す。

これによってDomain Boundaryを維持する。

6　CabinetをExecutive Political Bodyとして扱う

内閣も単なる「総理大臣＋大臣一覧」ではない。

Cabinet {
   cabinet_ref
   prime_minister_role_ref
   minister_role_refs[]
   collective_authority_refs[]
   formed_at
   valid_until
   evidence_refs[]
}

としてTemporal Stateを持つ。

PersonとRoleを分離し、

[
\boxed{
Person
\neq
MinisterRole
\neq
Cabinet
}
]

とする。

内閣の交代でもPerson IdentityやInstitution Identityを破壊しない。

7　Cabinet FormationをEvent Chainにする

内閣形成も一回のDatabase Updateではない。

Political Preconditions
     ↓
Prime Minister Role Transition
     ↓
Minister Role Assignments
     ↓
Cabinet Formation Event
     ↓
Active Cabinet State

としてEvent Chainを形成する。

退任時も、

CABINET_RESIGNATION_EVENT
     ↓
Role Transition
     ↓
Historical Cabinet State

へ移す。

これによってHistorical Replayが可能になる。

8　Cabinet DecisionとMinister Actionを分ける

行政側でもCollective AuthorityとIndividual Authorityを混同してはならない。

[
\boxed{
CabinetDecision
\neq
MinisterAction
}
]

である。

Cabinet
  │
COLLECTIVE_AUTHORITY
  ▼
Cabinet Action
Minister Role
  │
ROLE_AUTHORITY
  ▼
Ministerial Action

としてAuthority Graphを分離する。

どちらが必要なのかはAction TypeとLegal Basisによって決まる。

9　Cabinet RuntimeをLegal Stateへ接続する

内閣のActionにはLegal Runtimeへ接続されるものがある。

Cabinet Action
     ↓
Legal Basis Validation
     ↓
Legal Event Candidate
     ↓
Law / Regulation Runtime

重要なのは、

[
\boxed{
ExecutiveDecision
\neq
LegalEffect
}
]

である。

内閣側のDecisionが存在しても、必要な法的手続・公布・施行等を経なければLegal Stateを直接変更しない。

10　Cabinetから行政各部へExecutionを渡す

Cabinet RuntimeとMinistry Runtimeの境界では、

Cabinet State
     ↓
Authorized Executive Direction
     ↓
Responsible Institution
     ↓
Government Unit
     ↓
Program / Administrative Action

というExecution Chainを形成する。

しかし、

[
\boxed{
PoliticalDirection
\neq
CompletedExecution
}
]

である。

Directionが出されたことと、各行政機関でImplementationされたことを別Stateとして保持する。

11　Responsibility Resolutionを行う

Executive ActionにはResponsible InstitutionをResolutionする。

ExecutiveAction {
   action_id
   authority_ref
   legal_basis_refs[]
   responsible_institution_refs[]
   responsible_unit_refs[]
   effective_time
   evidence_refs[]
}

これによって、

「誰が決めたか」

と、

「誰が実行するか」

を分離する。

[
\boxed{
DecisionAuthority
\neq
ExecutionResponsibility
}
]

である。

12　複数府省庁へのExecutionを表現する

一つの政策が複数府省庁へまたがることもある。

Executive Decision
     ↓
Execution Plan
  ┌──┼──┐
  ↓  ↓  ↓
Inst A Inst B Inst C

このとき、一つの巨大なUnified Ministryへ統合しない。

各InstitutionのAuthorityを維持したままDependency Graphを形成する。

[
\boxed{
CrossMinistryDependency
\neq
CrossMinistryAuthority
}
]

である。

13　DietとCabinetの関係を双方向に保持する

国会と内閣は一方向Pipelineだけではない。

Diet
↓
Law / Budget / Institutional Decision
↓
Cabinet
↓
Government Execution
↓
Reporting / Accountability / New Proposal
↓
Diet

というLoopを形成する。

したがって、

[
\boxed{
Diet
\leftrightarrow
Cabinet
}
]

を複数のTyped RelationとEventによって表現する。

単純なCONTROLS Edge一つへ圧縮しない。

14　Decision Provenanceを保持する

行政Actionがどこから生じたかを遡れる必要がある。

AdministrativeAction
     ↓
ExecutiveDecision
     ↓
Political / Legal Basis
     ↓
Evidence
     ↓
SourceSnapshot

これによって、

「この行政Actionは何に基づいているか」

をMachine-readableに回答できる。

[
\boxed{
ExecutionWithoutProvenance
\neq
AuthoritativeExecution
}
]

である。

15　Runtime Commandと現実の権限を分離する

Software上のexecute()というFunctionが、国家権限を生み出してはならない。

RuntimeCommand
     ↓
Authority Validation
     ↓
Procedure Validation
     ↓
Evidence Validation
     ↓
State Transition

とする。

[
\boxed{
SoftwarePermission
\neq
InstitutionalAuthority
}
]

である。

System Administratorであっても、政治的・法的AuthorityがなければAuthoritative Political Stateを変更できない。

16　Historical Replayを可能にする

Diet / Cabinet RuntimeもEvent Logから再構成する。

[
\boxed{
DietCabinetState(t)

Replay(
ValidatedEvents_{\leq t}
)
}
]

とする。

これによって任意時点で、

国会の構成。

会期。

議案State。

内閣構成。

Role Occupancy。

Institutional Decisions。

Executive Actions。

を再現できる。

さらにKnownAtを指定すれば、その時点で利用可能だったEvidenceだけによるStateも再構成できる。

17　AIをGovernment Decision Makerにしない

AIはDiet / Cabinet Runtimeで、

議事録検索。

Decision Candidate抽出。

法的根拠探索。

関係府省庁候補のResolution。

Cross-Ministry Dependency分析。

Historical Comparison。

を支援できる。

しかし、

[
\boxed{
AIRecommendation
\neq
GovernmentDecision
}
]

である。

AI Agentが生成したActionはProposal Stateに留める。

Authoritative Transitionには、制度上有効なHuman / Institutional Decisionを要求する。

18　Diet / Cabinet Runtimeを統合する

最終的なExecution Flowは、

Political Reality
     ↓
Diet Event
     ↓
Procedure Validation
     ↓
Institutional Decision
     ↓
Legal / Fiscal Transition
     ↓
Cabinet State
     ↓
Executive Decision
     ↓
Authority / Legal Basis Validation
     ↓
Responsible Institution
     ↓
Administrative Execution Candidate
     ↓
Audit

となる。

その核心は、

[
\boxed{
Decision
+
Authority
+
Procedure
+
LegalBasis
+
Evidence
\rightarrow
ExecutableGovernmentAction
}
]

である。

ここで日本政治Digital Twinは、Political DecisionとGovernment Executionの境界を越える。

しかし、内閣がActionを決定しても、それを実際に処理するのは行政機関である。

省。

庁。

局。

部。

課。

室。

地方支分部局。

そして、それぞれに割り当てられたRole、Authority、Capability。

次節では、これらをVertical Runtimeとして実装する。

[
\boxed{
Institution
\rightarrow
GovernmentUnit
\rightarrow
Role
\rightarrow
Authority
\rightarrow
Action
}
]

Diet / Cabinet Runtimeから、Ministry Vertical Runtimeへ。

国家のDecisionは、行政組織の内部を通ってExecutionへ進む。
第4節　Ministry Vertical Runtime

Diet / Cabinet Runtimeによって、Political DecisionをExecutive Actionへ接続した。

しかし、内閣がDecisionしただけでは行政は実行されない。

実際のExecutionは、省庁、その内部部局、地方支分部局、施設等の組織構造と、そこに配置されたRole、Authority、Capabilityを通じて行われる。

したがってMinistry Vertical Runtimeの基本構造は、

[
\boxed{
Institution
\rightarrow
GovernmentUnit
\rightarrow
Role
\rightarrow
Authority
\rightarrow
Action
\rightarrow
StateTransition
}
]

となる。

ここで実装するのは、単なる電子組織図ではない。

「どの行政Actionを、どの組織単位が、どのAuthorityに基づいて実行できるのか」を検証しながらStateを動かすVertical Execution Runtimeである。

1　組織図とRuntimeを分離する

行政組織を、

Ministry
 ↓
Bureau
 ↓
Department
 ↓
Division
 ↓
Office

と記述するだけならOrganization Graphである。

Runtimeにはさらに、

GovernmentUnit
     ↓
Role
     ↓
Authority
     ↓
Capability
     ↓
Action
     ↓
Event

が必要になる。

したがって、

[
\boxed{
OrganizationStructure
\neq
ExecutionRuntime
}
]

である。

2　Government Unitを再帰構造にする

日本の行政組織は、すべてが同一階層ではない。

そこで特定の名称をCodeへ固定せず、

GovernmentUnit {
   canonical_unit_id
   institution_ref
   unit_type
   parent_unit_ref
   valid_time
   authority_refs[]
   capability_refs[]
}

というRecursive Modelを採用する。

[
\boxed{
GovernmentUnit
\rightarrow
GovernmentUnit
}
]

という自己参照構造によって、異なる府省庁の組織形態を同じRuntimeで扱える。

3　HierarchyとAuthorityを分離する

Ministry Vertical Runtimeで最も重要なInvariantの一つが、

[
\boxed{
PART_OF
\neq
HAS_AUTHORITY_OVER
}
]

である。

上位組織に属するからといって、すべてのActionについて直接Authorityを持つとは限らない。

したがって、

GovernmentUnit A
     │
   PART_OF
     ▼
GovernmentUnit B
Role
     │
HAS_AUTHORITY
     ▼
ActionScope

を別Graphとして保持する。

Organization TreeからAuthorityを自動推論しない。

4　RoleをExecution Pointにする

行政ActionはInstitutionという抽象Entityが直接行うのではなく、制度上定義されたRoleを通じて実行される。

Person
 │
OCCUPIES
 ▼
Role
 │
BELONGS_TO
 ▼
GovernmentUnit

Roleには、

RoleRuntime {
   role_ref
   unit_ref
   authority_refs[]
   valid_from
   valid_to
   delegation_refs[]
}

を持たせる。

[
\boxed{
Person
\neq
Role
\neq
Authority
}
]

という第Ⅰ部のOntologyが、ここでExecution Ruleになる。

5　AuthorityをAction Scopeとして実装する

Authorityは単なるadmin=trueではない。

Authority {
   authority_id
   role_ref
   action_type
   object_scope
   jurisdiction_scope
   legal_basis_refs[]
   valid_from
   valid_to
   constraints[]
}

として保持する。

Action実行時には、

[
\boxed{
ValidAuthority

Role
\times
Action
\times
Scope
\times
LegalBasis
\times
Time
}
]

を検証する。

これによって「権限がある」という曖昧な状態を、Machine-verifiableなConstraintへ変換する。

6　CapabilityとAuthorityを分ける

組織が技術的・人的に実行可能であることと、制度上実行してよいことも異なる。

[
\boxed{
Capability
\neq
Authority
}
]

である。

例えば、

GovernmentUnit
  │
HAS_CAPABILITY
  ▼
DataAnalysis
Role
  │
HAS_AUTHORITY
  ▼
OfficialPublication

のように分離する。

AI導入によってCapabilityが拡張されても、それだけでAuthorityは拡張されない。

これは次世代Government AIに不可欠な境界である。

7　Administrative ActionをCanonicalizeする

行政Runtimeで発生するActionをTyped Actionとして定義する。

REVIEW
APPROVE
REJECT
ISSUE
NOTIFY
REGISTER
ALLOCATE
INSPECT
REQUEST
REPORT
PUBLISH
TRANSFER
EXECUTE_PROGRAM

実際のDomainではさらに詳細なAction Typeへ展開する。

各Actionには、

AdministrativeAction {
   action_id
   action_type
   actor_role_ref
   unit_ref
   target_refs[]
   authority_ref
   legal_basis_refs[]
   occurred_at
   evidence_refs[]
}

を持たせる。

8　CommandとEventを分離する

Runtimeへ「これを実行したい」というRequestが届いても、まだRealityは変化していない。

Command
  ↓
Validation
  ↓
Execution
  ↓
Event
  ↓
State Transition

とする。

[
\boxed{
Command
\neq
Event
}
]

である。

CommandはIntent。

Eventは実際に成立したState Changeの記録である。

失敗したCommandから成功Eventを生成してはならない。

9　Vertical Validation Pipeline

Actionは次のPipelineを通す。

Command
 ↓
Actor Identity
 ↓
Active Role
 ↓
Government Unit
 ↓
Authority Scope
 ↓
Legal Basis
 ↓
Temporal Constraint
 ↓
Required Evidence
 ↓
Business Rule
 ↓
Execute
 ↓
Canonical Event

一つでも成立しなければAuthoritative StateへCommitしない。

概念的には、

def authorize(command, state):
   role = resolve_active_role(command.actor, state)
   authority = resolve_authority(role, command.action)
   validate_scope(authority, command.target)
   validate_legal_basis(authority)
   validate_time(authority)
   validate_evidence(command)
   return authority

となる。

10　Delegationを明示する

行政組織ではAuthorityの委任・代行等を考慮する必要がある。

Digital Twinでは元Authorityを直接書き換えず、

Original Authority
     ↓
Delegation Event
     ↓
Delegated Authority
     ↓
Delegate Role

として表現する。

重要なInvariantは、

[
\boxed{
DelegatedAuthority
\subseteq
OriginalAuthority
}
]

である。

委任によって元のAuthorityを超える権限を生成してはならない。

有効期間とScopeも保持する。

11　WorkflowをState Machineにする

行政業務は一つのFunction Callではなく、複数Roleを通過する場合がある。

DRAFT
 ↓
REVIEW
 ↓
APPROVAL
 ↓
EXECUTION
 ↓
PUBLICATION
 ↓
CLOSED

各Transitionについて、

TransitionRule {
   from_state
   to_state
   required_role
   required_authority
   required_evidence
   guard_conditions[]
}

を定義する。

これによってWorkflow自体をExecutable Policyへ変換できる。

12　Vertical RuntimeをProgramへ接続する

行政組織は組織のために存在するのではない。

政策・ProgramをExecutionする。

Policy
 ↓
Program
 ↓
Responsible Institution
 ↓
Government Unit
 ↓
Role
 ↓
Administrative Action
 ↓
Program State

したがって、

[
\boxed{
ProgramExecution

Institution
+
Capability
+
Authority
+
Resource
+
Action
}
]

として記述する。

「担当府省庁」というLabelだけでExecutionを済ませない。

13　VerticalとFiscalを接続する

Program ExecutionにはResourceが必要になる。

GovernmentUnit
     ↓
Program
     ↓
Fiscal Authorization
     ↓
Resource Allocation
     ↓
Execution

しかし、

[
\boxed{
AdministrativeAuthority
\neq
FiscalAuthority
}
]

である。

政策上の担当Authorityを持つRoleが、そのまますべての支出Authorityを持つとは限らない。

この境界は次節のBudget / Fiscal Runtimeで実装する。

14　Cross-Ministry Dependencyを外部Relationにする

Vertical Runtimeは一つの府省庁内部だけで閉じない。

Ministry A Runtime
     │
DEPENDS_ON
     ▼
Ministry B Runtime

を許容する。

ただし、

[
\boxed{
Dependency
\neq
Authority
}
]

である。

AがBのDataやActionを必要とすることと、AがBを指揮できることは別である。

Vertical Runtimeを維持したまま、後続のIntegrated Government Runtimeで横断接続する。

15　組織再編をRuntimeへ反映する

省庁、局、課等は時間とともに変化する。

UNIT_CREATED
UNIT_RENAMED
UNIT_MOVED
UNIT_SPLIT
UNIT_MERGED
UNIT_DISSOLVED
MANDATE_CHANGED

をOrganization Eventとして処理する。

再編後もHistorical Identityと旧Authorityを保持する。

[
\boxed{
CurrentOrganization
\neq
HistoricalOrganization
}
]

である。

過去の行政Actionを現在の組織構造へ誤って割り当てない。

16　AuditをVertical Chain全体に通す

すべてのAuthoritative Actionについて、

Who
↓
Which Role
↓
Which Unit
↓
Which Authority
↓
Which Legal Basis
↓
Which Action
↓
Which State Changed
↓
Which Evidence

を再構成できなければならない。

したがって、

[
\boxed{
AdministrativeAction
\rightarrow
Authority
\rightarrow
Evidence
}
]

のTraceを必須とする。

これは責任追跡だけでなく、System Debuggingにも必要である。

17　AI AgentをVertical Runtimeへ配置する

AI Agentは行政Verticalの各層を支援できる。

Source Retrieval
     ↓
Document Analysis
     ↓
Action Candidate
     ↓
Required Evidence Search
     ↓
Rule Check
     ↓
Human Review
     ↓
Authorized Execution

AIは大量の行政情報を横断し、次のAction Candidateを生成できる。

しかし、

[
\boxed{
AgentCapability
\neq
GovernmentAuthority
}
]

である。

AI AgentにはCanonical Authorityを付与せず、Proposal、Analysis、Retrieval、Validation Assistanceを基本Roleとする。

18　Ministry RuntimeをReplay可能にする

Administrative Event Logから任意時点のVertical Stateを再構成する。

[
\boxed{
MinistryState(t)

Replay(
AdministrativeEvents_{\leq t}
)
}
]

これによって、

その時どの組織が存在したか。

誰がどのRoleにいたか。

どのAuthorityが有効だったか。

どのProgramを担当していたか。

どのActionが実行されたか。

をHistorical Stateとして再現できる。

19　Vertical Runtimeを完成させる

最終的なMinistry Vertical Runtimeは、

Executive Decision
     ↓
Responsible Institution
     ↓
Government Unit
     ↓
Active Role
     ↓
Authority
     ↓
Legal Basis
     ↓
Capability
     ↓
Administrative Command
     ↓
Validation
     ↓
Execution
     ↓
Canonical Event
     ↓
Administrative State Transition
     ↓
Audit / Replay

となる。

その核心は、

[
\boxed{
AdministrativeState_{t+1}

Transition(
AdministrativeState_t,
Action,
Role,
Authority,
LegalBasis,
Evidence
)
}
]

である。

ここで日本政治Digital Twinは、省庁を組織名の一覧としてではなく、AuthorityとActionが流れるExecutable Verticalとして記述できるようになる。

しかし、行政Actionを実行するには、もう一つのConstraintがある。

Resourceである。

政策を担当していること。

実行Authorityを持っていること。

それだけではMoneyを動かすことはできない。

予算の要求。

成立。

配分。

Commitment。

契約。

支払。

決算。

これらにも独立したState Transitionが存在する。

次節では、

[
\boxed{
FiscalAuthorization
\rightarrow
ResourceFlow
\rightarrow
Execution
}
]

を実装する。

Ministry Vertical RuntimeからBudget / Fiscal Runtimeへ。

行政のAuthorityは、国家ResourceのExecutionへ接続される。
第5節　Budget / Fiscal Runtime

Ministry Vertical Runtimeによって、行政ActionをInstitution、Government Unit、Role、Authorityへ接続した。

しかし、行政上のAuthorityを持つことと、国家Resourceを支出できることは同一ではない。

政策が存在する。

担当組織が存在する。

Programが存在する。

それでもFiscal Authorizationがなければ、Moneyは動かない。

したがってBudget / Fiscal Runtimeでは、

[
\boxed{
Policy
\rightarrow
Budget
\rightarrow
Authorization
\rightarrow
Allocation
\rightarrow
Commitment
\rightarrow
Payment
\rightarrow
Execution
}
]

を独立したState Transitionとして実装する。

目的は政府支出を集計することではない。

どのAuthorityによって、どのResourceが、いつ、どのProgram・Organization・Territoryへ移動したのかを再生可能にすることである。

1　Fiscal Stateを定義する

Fiscal Runtimeの中心には、単一の「予算額」ではなく複数のStateを置く。

FiscalState {
   fiscal_year
   accounts
   fiscal_items
   programs
   authorizations
   allocations
   commitments
   contracts
   payments
   balances
   evidence_refs[]
}

最重要Invariantは、

[
\boxed{
Requested
\neq
Proposed
\neq
Authorized
\neq
Allocated
\neq
Committed
\neq
Paid
}
]

である。

「予算がある」と「実際に支出された」を同一視しない。

2　Budget LifecycleをState Machineにする

Budgetは静的Documentではない。

概念的には、

REQUESTED
   ↓
PROPOSED
   ↓
AUTHORIZED
   ↓
ALLOCATED
   ↓
EXECUTING
   ↓
CLOSED

というLifecycleを持つ。

途中で補正、配分変更、契約、支払等が発生すれば、それぞれをFiscal Eventとして記録する。

[
\boxed{
FiscalState_t
+
FiscalEvent
\rightarrow
FiscalState_{t+1}
}
]

である。

Current Amountを上書きするのではなく、ResourceがどのTransitionを通過したのかを保持する。

3　Political DecisionとFiscal Effectを分離する

国会による予算DecisionはFiscal Runtimeへの重要なInputである。

しかし、

[
\boxed{
BudgetDecision
\neq
Payment
}
]

である。

Diet Decision
    ↓
Fiscal Authorization Event
    ↓
Authorized Budget State
    ↓
Administrative Allocation
    ↓
Fiscal Execution

という境界を置く。

これによってPolitical Runtime、Diet / Cabinet Runtime、Fiscal Runtimeの責任範囲を分離できる。

4　Fiscal Authorizationを第一級Entityにする

Moneyを動かすにはFiscal Authorityが必要になる。

FiscalAuthorization {
   authorization_id
   fiscal_item_ref
   account_ref
   amount_limit
   authority_ref
   legal_basis_refs[]
   valid_from
   valid_to
   constraints[]
}

とする。

そして、

[
\boxed{
AdministrativeAuthority
\neq
FiscalAuthority
}
]

を維持する。

政策担当者だからといって、任意の金額を支出できるわけではない。

5　Allocationを独立Transitionにする

成立したBudgetが、どのProgram、Government Unit、Project等へ割り当てられるかを記述する。

FiscalAuthorization
     ↓
Allocation Event
     ↓
Program / Unit
     ↓
Available Resource

Allocationには、

Allocation {
   allocation_id
   source_fiscal_ref
   destination_ref
   amount
   effective_at
   authority_ref
   evidence_refs[]
}

を持たせる。

[
\boxed{
AuthorizedAmount
\neq
AllocatedAmount
}
]

である。

6　CommitmentをPaymentから分離する

支出義務が生じたことと、Moneyが実際に支払われたことも異なる。

[
\boxed{
Commitment
\neq
Payment
}
]

とする。

Available Resource
     ↓
Commitment
     ↓
Contract / Obligation
     ↓
Payment Event

これにより、Budget消化を単なるPayment履歴ではなく、Execution Processとして追跡できる。

7　ProcurementとContractを接続する

調達を伴う場合、

Program
 ↓
Procurement
 ↓
Award
 ↓
Contract
 ↓
Commitment
 ↓
Payment

というChainを形成する。

ただし、

[
\boxed{
Procurement
\neq
Contract
\neq
Payment
}
]

である。

調達開始。

契約成立。

契約変更。

履行。

支払。

を別Eventとして保持する。

8　Fiscal Instrumentを型付けする

国家Resourceは契約だけで移動するわけではない。

PROCUREMENT
GRANT
SUBSIDY
TRANSFER
CONTRIBUTION
INVESTMENT
LOAN
CONTRACT_PAYMENT

などのFiscal Instrumentを区別する。

したがって、

[
\boxed{
Funding
\neq
Procurement
\neq
Ownership
}
]

である。

Moneyが流れたという事実だけから、Governmentが相手Organizationを所有・支配していると推論してはならない。

9　PaymentをEventとして実装する

PaymentはFiscal Stateを実際に変化させる主要Eventである。

PaymentEvent {
   payment_id
   fiscal_source_ref
   instrument_type
   payer_ref
   recipient_ref
   amount
   currency
   occurred_at
   contract_ref
   program_ref
   evidence_refs[]
}

Payment EventがCommitされると、

Previous Balance
     ↓
Validated Payment
     ↓
New Balance

となる。

ただし、同一Paymentの重複取込を防ぐためIdempotencyを保証する。

10　Fiscal ConstraintをCodeで検証する

Runtimeは支出前に最低限、

Active Authorization?
Sufficient Available Amount?
Correct Fiscal Year?
Correct Account?
Correct Program?
Valid Authority?
Valid Recipient?
Required Evidence?
No Duplicate Transaction?

を検証する。

概念的には、

def validate_payment(state, command):
   authorization = resolve_fiscal_authorization(command)
   assert authorization.is_active(command.date)
   assert command.amount <= available_balance(authorization)
   assert within_scope(command, authorization)
   assert valid_authority(command.actor, authorization)
   assert evidence_complete(command)
   return True

となる。

[
\boxed{
TechnicallyExecutable
\neq
FiscallyAuthorized
}
]

である。

11　Budget BalanceをEventから導出する

残額を人間が直接入力する設計を中心にしない。

[
\boxed{
Balance

Authorized
+
Adjustments

Committed/Executed
}
]

という形で、定義したAccounting Ruleに従いEventから導出する。

重要なのは、どの金額概念を用いているかを明示することである。

available_balanceとcash_balanceとunspent_authorizationを混同しない。

12　補正・移動を上書きしない

Fiscal Stateは年度途中でも変化する。

BUDGET_SUPPLEMENTED
ALLOCATION_CHANGED
FUNDS_TRANSFERRED
COMMITMENT_CHANGED
CONTRACT_CHANGED
PAYMENT_CORRECTED

などをEventとして保持する。

[
\boxed{
Adjustment
\neq
Overwrite
}
]

である。

最終額だけを残すと、なぜResource Stateが変化したのかを説明できなくなる。

13　NationalからLocalへのResource Flowを接続する

前節までに構築したLocal Government GraphとFiscal Runtimeを接続する。

National Fiscal State
       ↓
Transfer / Grant / Subsidy
       ↓
Local Government
       ↓
Local Program
       ↓
Territory

これによって、

[
\boxed{
NationalResource
\rightarrow
LocalExecution
}
]

を追跡できる。

ただし、国からResourceが移転されたことと、地方のDecision Authorityが国へ移ったことは別である。

[
\boxed{
FiscalTransfer
\neq
AuthorityTransfer
}
]

である。

14　Program Executionへ接続する

Fiscal RuntimeはMoneyだけで閉じない。

Policy
 ↓
Program
 ↓
Fiscal Authorization
 ↓
Allocation
 ↓
Administrative Action
 ↓
Contract / Transfer
 ↓
Execution

としてMinistry Vertical Runtimeへ戻す。

これによって、

「政策がある」

から、

「Resourceを伴って実行された」

までを区別できる。

[
\boxed{
PolicyExistence
\neq
ProgramExecution
}
]

である。

15　ExecutionとOutcomeを分離する

Resourceが支出されたとしても、政策成果が生じたとは限らない。

Fiscal Execution
     ↓
Program Execution
     ↓
Territory / Population
     ↓
Observation

まではCanonical Runtimeで接続できる。

しかし、

[
\boxed{
Payment
\neq
Outcome
\neq
Impact
}
]

である。

OutcomeやImpactの評価は、Social Reality Dataと後続のGovernment Intelligence / Simulationによって扱う。

Fiscal Runtime自身が因果効果を生成しない。

16　Fiscal Provenanceを完全に保持する

一つのPaymentから上流へ、

Payment
 ↓
Contract / Fiscal Instrument
 ↓
Commitment
 ↓
Allocation
 ↓
Fiscal Authorization
 ↓
Budget Decision
 ↓
Legal / Political Basis
 ↓
Evidence

を遡れるようにする。

これによって、

[
\boxed{
WhereDidThisMoneyComeFrom?
}
]

をMachine-readableに回答できる。

同時に下流へ、

Payment
 ↓
Recipient
 ↓
Project / Service
 ↓
Territory

を辿ることで、

[
\boxed{
WhereDidThisMoneyGo?
}
]

にも答えられる。

17　Fiscal RuntimeをReplay可能にする

Fiscal Event Logから任意時点のStateを再構築する。

[
\boxed{
FiscalState(t)

Replay(
FiscalEvents_{\leq t}
)
}
]

とする。

これによって、

その時点で成立していた予算。

配分済みResource。

未執行額。

Commitment。

Contract。

Payment。

をHistorical Stateとして再現できる。

さらにKnownAtを指定すれば、後日修正されたDataを混入させず、当時利用可能だったFiscal Informationだけを再現できる。

18　AIをMoneyのAuthorityにしない

AIはFiscal Runtimeで大きな役割を持てる。

予算項目のMapping。

異常支出Candidateの検出。

ContractとProgramのRelation Resolution。

重複候補の発見。

Resource Flow分析。

将来執行率のSimulation。

を行える。

しかし、

[
\boxed{
AIRecommendation
\neq
FiscalAuthorization
}
]

である。

AI Agentが支出Candidateを生成しても、MoneyをAuthoritativeに動かすTransitionには制度上有効なAuthorityを要求する。

19　Budget / Fiscal Runtimeを完成させる

最終的なRuntimeは、

Political / Legal Decision
       ↓
Budget Authorization
       ↓
Fiscal Authority
       ↓
Allocation
       ↓
Program / Government Unit
       ↓
Commitment
       ↓
Procurement / Fiscal Instrument
       ↓
Contract / Recipient
       ↓
Payment
       ↓
Execution
       ↓
Territory
       ↓
Audit / Replay

となる。

その核心は、

[
\boxed{
FiscalState_{t+1}

Transition(
FiscalState_t,
FiscalEvent,
Authority,
Authorization,
Evidence
)
}
]

である。

これによってMoneyは、年度ごとの巨大な数字から、国家の内部を移動するTemporal Resource Flowへ変わる。

Political RuntimeがDecisionを生成した。

Legal RuntimeがRuleを成立させた。

Diet / Cabinet RuntimeがExecutive Actionへ接続した。

Ministry Vertical Runtimeが行政組織を動かした。

Budget / Fiscal Runtimeが、そのExecutionへResourceを与えた。

しかし、日本国家のExecutionは中央政府だけでは完結しない。

政策とResourceの多くは、都道府県、市区町村、地域のInstitutionを通じて具体的な生活空間へ到達する。

次節では、

[
\boxed{
NationalState
\leftrightarrow
LocalState
}
]

を、Authorityを中央へCollapseさせることなく接続する。

Budget / Fiscal RuntimeからLocal Government Runtimeへ。

国家Resourceは、地域のRealityへ進む。
第6節　Local Government Runtime

Budget / Fiscal Runtimeによって、国家ResourceをPolicy、Program、Allocation、Contract、Payment、Executionへ接続した。

しかし、日本国家のExecutionは中央政府だけでは完結しない。

都道府県。

市区町村。

首長。

議会。

行政組織。

地域ごとの予算と事業。

そして、それぞれのTerritoryで生活する人々と企業。

中央政府で成立した制度やResourceは、地方公共団体との関係を通じて具体的な地域Realityへ接続される。

したがってLocal Government Runtimeの目的は、地方を中央政府の末端Processとして組み込むことではない。

[
\boxed{
NationalState
\leftrightarrow
LocalState
}
]

を、それぞれのAuthority Boundaryを維持したまま実行可能にすることである。

1　Local Stateを独立したRuntimeにする

地方公共団体は単なるTerritory Nodeではない。

LocalState {
   local_government
   territory
   executive
   assembly
   government_units
   roles
   authorities
   legal_refs
   policies
   programs
   fiscal_state
   observations
   evidence_refs[]
}

として独立したStateを持つ。

したがって、

[
\boxed{
LocalGovernment
\neq
Territory
}
]

である。

行政主体と地理空間を分離したうえでGOVERNS Relationによって接続する。

2　中央―地方を単純なHierarchyにしない

Digital Twinでは、

National Government
      ↓
Prefecture
      ↓
Municipality

をそのままCommand Hierarchyとして解釈してはならない。

地理的包含。

制度上の関係。

Fiscal Transfer。

行政上のCoordination。

Data Sharing。

それぞれは異なるRelationである。

[
\boxed{
GeographicContainment
\neq
AdministrativeAuthority
}
]

である。

3　Local Authority Graphを独立させる

各地方公共団体について、

LocalGovernment
├── Executive
├── Assembly
└── AdministrativeOrganization

を分離する。

さらに、

Person
 ↓
Role
 ↓
Authority
 ↓
LocalAction

を構築する。

中央政府と同じ、

[
\boxed{
Person
\neq
Role
\neq
Authority
}
]

というCanonical Ruleを利用することで、National / Localを一つのOntologyで扱える。

4　首長と議会を分離する

地方政治でも、

[
\boxed{
Executive
\neq
Assembly
}
]

である。

Governor / Mayor Role
       ↓
Executive Action
Local Assembly
       ↓
Collective Decision

としてAuthorityを分ける。

個々の議員によるActionと議会としてのDecisionも同一ではない。

[
\boxed{
AssemblyMemberAction
\neq
AssemblyDecision
}
]

である。

この構造によって地方政治をPerson ListではなくPolitical Runtimeとして実装できる。

5　Local Political EventをState Transitionへ変える

地方政治の変化もEvent-drivenにする。

LOCAL_ELECTION_HELD
LOCAL_ROLE_ASSIGNED
LOCAL_ROLE_ENDED
ASSEMBLY_SESSION_OPENED
LOCAL_DECISION_RECORDED
LOCAL_POLICY_ADOPTED
LOCAL_BUDGET_DECISION_RECORDED

等をCanonical Eventへ変換する。

したがって、

[
\boxed{
LocalPoliticalState_t
+
LocalPoliticalEvent
\rightarrow
LocalPoliticalState_{t+1}
}
]

となる。

PersonやCurrent Tableを直接上書きしない。

6　Local Administrative Verticalを実装する

地方行政組織にも中央省庁と同じVertical Runtimeを適用できる。

LocalGovernment
     ↓
GovernmentUnit
     ↓
Role
     ↓
Authority
     ↓
Capability
     ↓
AdministrativeAction

ただし、自治体ごとに組織名称や階層が異なるため、固定的な「部→課→係」をSchemaへ埋め込まない。

Recursive GovernmentUnit Modelを利用する。

[
\boxed{
CommonOntology
+
LocalStructure
}
]

によって多様性を保持する。

7　National Policyとの接続を型付けする

国と地方の関係を単一のEXECUTES Edgeへ圧縮しない。

COORDINATES_WITH
FUNDS
TRANSFERS_TO
DELEGATES
REGULATES
REPORTS_TO
SHARES_DATA_WITH
JOINTLY_OPERATES

などに分ける。

これによって、

[
\boxed{
Funding
\neq
Delegation
\neq
Coordination
\neq
Authority
}
]

を維持する。

Data Integrationによって制度上の境界を消さない。

8　National ProgramからLocal Programへ接続する

政策Executionは、

National Policy
     ↓
National Program
     ↓
National-Local Relation
     ↓
Local Program
     ↓
Local Administrative Action

として接続できる。

ここで重要なのは、National ProgramとLocal Programを同一Entityにしないことである。

[
\boxed{
NationalProgram
\neq
LocalProgram
}
]

とし、IMPLEMENTS、SUPPORTED_BY、RELATED_TOなどのTyped Relationで結ぶ。

これによって、国の制度と地域固有のImplementationを分離できる。

9　Fiscal FlowをLocal Stateへ受け渡す

前節のFiscal Runtimeから、

National Fiscal State
      ↓
Grant / Transfer / Subsidy
      ↓
Local Fiscal State
      ↓
Local Program
      ↓
Local Execution

へ接続する。

しかし、

[
\boxed{
ResourceTransfer
\neq
AuthorityTransfer
}
]

である。

Moneyが国から地方へ流れたからといって、その地方Actionを中央政府が直接実行したことにはならない。

10　Local Fiscal Stateを独立させる

地方側にも、

LocalFiscalState {
   fiscal_year
   budget
   authorizations
   allocations
   commitments
   contracts
   payments
   evidence_refs[]
}

を持たせる。

National Fiscal Stateと同様に、

[
\boxed{
Authorized
\neq
Allocated
\neq
Committed
\neq
Paid
}
]

を維持する。

これによってNational Resource FlowとLocal Resource Flowを接続しながら、会計上の境界を保持できる。

11　TerritoryをExecution Contextにする

Local RuntimeではActionをTerritoryへ接続できる。

LocalGovernment
     ↓
Program
     ↓
Project / Service
     ↓
Territory

これによって、

「どの自治体が実行したか」

と、

「どの地域を対象としたか」

を分離できる。

[
\boxed{
ExecutingGovernment
\neq
TargetTerritory
}
]

である。

複数自治体にまたがるProgramや広域Serviceもこの構造で表現できる。

12　自治体間連携をGraph化する

Local Realityは自治体単位で完全に閉じていない。

LocalGovernment A
     │
COOPERATES_WITH
     ▼
LocalGovernment B

のようなRelationを持つ。

共同事業、広域連携、共同Infrastructure等は、独立自治体をMergeせずにJoint Programとして表現する。

[
\boxed{
Cooperation
\neq
InstitutionalMerger
}
]

である。

13　行政区域の変更をRuntimeへ反映する

市町村合併、名称変更、境界変更等もEventとして処理する。

MUNICIPALITY_CREATED
MUNICIPALITY_MERGED
MUNICIPALITY_RENAMED
MUNICIPALITY_DISSOLVED
BOUNDARY_CHANGED

これによって、

[
\boxed{
LocalState(t)
}
]

をHistoricalに再構成できる。

現在の行政区域を過去の統計や政策へ遡及適用しない。

14　Territory VersionとObservationを同期する

Social Reality Dataを地域へ接続する場合、

Observation
   ↓
TerritoryVersion(t)

とする。

統計のReference Timeに対応するTerritory StateをResolutionする。

[
\boxed{
Observation(area,t)
\Rightarrow
TerritorySemantics(area,t)
}
]

である。

これによって市町村合併前後の時系列Dataを誤って同一地域として扱うことを防ぐ。

必要に応じてHistorical Crosswalkを利用する。

15　Local ExecutionからSocial Realityへ接続する

地方Runtimeは、Government ActionとObserved Realityが最も近接するLayerの一つである。

Local Policy
   ↓
Local Program
   ↓
Fiscal Resource
   ↓
Administrative Execution
   ↓
Territory
   ↓
Observation

これによってProgram実施前後の地域Stateを観測できる。

しかし、

[
\boxed{
Execution
\neq
Outcome
\neq
CausalImpact
}
]

である。

Canonical RuntimeはExecutionとObservationを接続するところまでを担い、因果推論はIntelligence / Simulation Layerへ渡す。

16　Resident Dataとの境界を固定する

地域Digital Twinは強力であるからこそ、Data Scopeを明確にしなければならない。

Public Japan Political Digital Twinでは、原則として公開された制度・行政・財政・統計Dataを中心にする。

[
\boxed{
LocalDataIntegration
\neq
ResidentSurveillance
}
]

である。

個人単位の行政Dataが必要なOperational Systemでは、明示されたLegal Basis、Purpose Limitation、Access Control、Audit等を別途要求する。

「技術的に接続可能だから接続する」という設計にはしない。

17　National / Local Eventを一つのTimelineへ接続する

中央と地方を統合すると、

National Event
    ↓
National State Transition
    ↓
National-Local Relation Event
    ↓
Local State Transition
    ↓
Local Execution
    ↓
Social Observation

というTimelineが形成される。

ただし、一つのEventがすべてのStateを直接変更するのではない。

DomainごとのRuntimeがそれぞれValidationし、Typed Eventを受け渡す。

これによって、

[
\boxed{
IntegratedTimeline
\neq
SingleAuthority
}
]

を実現する。

18　Local RuntimeをReplay可能にする

地方StateもEvent Logから再構成する。

[
\boxed{
LocalState(g,t)

Replay(
LocalEvents_{g,\leq t}
)
}
]

ここでgはLocal Government Identityである。

これによって任意の自治体・任意の時点について、

組織。

首長。

議会。

Role。

Authority。

Program。

Fiscal State。

Territory。

Execution。

を再現できる。

47都道府県・全市区町村を同じRuntime Contractで扱いながら、それぞれ独立したState Historyを保持する。

19　Local Government Runtimeを完成させる

最終的なLocal Runtimeは、

National State
     ↓
Policy / Legal / Fiscal Relation
     ↓
Local Government
     ↓
Local Political Decision
     ↓
Local Authority
     ↓
Local Administrative Vertical
     ↓
Local Fiscal State
     ↓
Program / Project / Service
     ↓
Territory
     ↓
Observed Social Reality
     ↓
Audit / Replay

となる。

その核心は、

[
\boxed{
LocalState_{t+1}

Transition(
LocalState_t,
ValidatedLocalEvent,
Authority,
Evidence
)
}
]

である。

ここで、日本政治Digital TwinのRuntimeは中央政府から地域まで到達した。

Political State Machine。

Law / Regulation Runtime。

Diet / Cabinet Runtime。

Ministry Vertical Runtime。

Budget / Fiscal Runtime。

Local Government Runtime。

それぞれは独立したAuthorityとState Machineを持ちながら、一つのPolitical Realityの中で相互に接続される。

次に必要なのは、これらを巨大な一枚岩のSystemへ潰すことではない。

[
\boxed{
IndependentRuntimes
+
TypedEvents
+
SharedCanonicalState
}
]

によって、一つのGovernment Runtimeとして協調させることである。

次節では、第Ⅲ部のすべてを統合する。

[
\boxed{
Political
+
Legal
+
Administrative
+
Fiscal
+
Local
\rightarrow
IntegratedGovernmentRuntime
}
]

中央と地方、政治と行政、RuleとMoney、DecisionとExecution。

それらをAuthority Boundaryを保持したまま接続したとき、日本政治Digital Twinは初めて、国家全体のState Transitionを再生できるRuntimeになる。
第7節　Integrated Government Runtime

ここまで、第Ⅲ部では日本国家を動かす複数のRuntimeを実装してきた。

Political State Machine。

Law / Regulation Runtime。

Diet / Cabinet Runtime。

Ministry Vertical Runtime。

Budget / Fiscal Runtime。

Local Government Runtime。

それぞれは異なるState、Event、Authority、Validation Ruleを持つ。

しかし、現実の国家では、それらは独立して動いているわけではない。

選挙が政治Stateを変える。

政治的Decisionが法令を変える。

法令がAuthorityを変える。

Authorityに基づいて行政が動く。

予算がResourceを与える。

地方公共団体が地域でExecutionする。

そして、その結果が社会のObservationとして現れる。

したがって第Ⅲ部の最後に必要なのは、

[
\boxed{
IndependentRuntimes
+
TypedEvents
+
SharedCanonicalState
\rightarrow
IntegratedGovernmentRuntime
}
]

である。

重要なのは、すべてを一つの巨大なState Machineへ統合することではない。

制度上分離されているものを分離したまま、一つのJapan Stateとして協調させる。

これがIntegrated Government Runtimeの設計原理である。

1　RuntimeをCollapseしない

最初のInvariantは、

[
\boxed{
Integration
\neq
Collapse
}
]

である。

Political RuntimeとLegal Runtimeは異なる。

Legal RuntimeとAdministrative Runtimeも異なる。

National RuntimeとLocal Runtimeも異なる。

したがって、

Political Runtime
Legal Runtime
Cabinet Runtime
Administrative Runtime
Fiscal Runtime
Local Runtime

を独立Moduleとして維持する。

統合するのはAuthorityではなく、State ContractとEvent Flowである。

2　Shared Canonical Stateを中心に置く

各Runtimeが独自の「日本」を持ってはならない。

                 Canonical Japan State
                 /    /    |    \    \
                /    /     |     \    \
         Political Legal  Admin  Fiscal Local
          Runtime Runtime Runtime Runtime Runtime

すべてが同じCanonical Identity、Ontology、Evidence、Temporal Modelを参照する。

[
\boxed{
OneCanonicalReality
\rightarrow
MultipleDomainRuntimes
}
]

である。

これによって同一Person、Institution、Program、Territory等がRuntimeごとに別Entityになることを防ぐ。

3　Runtime間をTyped Eventで接続する

Domain Runtime同士をDatabaseの直接書換えで接続しない。

Political Runtime
     ↓
PoliticalDecisionEvent
     ↓
Legal Runtime
     ↓
LegalEffectEvent
     ↓
Administrative Runtime

のようにTyped Eventを介する。

Fiscal側なら、

Diet / Cabinet Runtime
     ↓
FiscalAuthorizationEvent
     ↓
Fiscal Runtime
     ↓
AllocationEvent
     ↓
Administrative Runtime

となる。

[
\boxed{
RuntimeA
\rightarrow
TypedEvent
\rightarrow
RuntimeB
}
]

をIntegrationの基本形とする。

4　Event Contractを固定する

Runtime間Eventには共通Contractを持たせる。

GovernmentEvent {
   event_id
   event_type
   source_runtime
   subject_refs[]
   authority_refs[]
   legal_basis_refs[]
   occurred_at
   effective_at
   evidence_refs[]
   causation_id
   correlation_id
   schema_version
}

これによってEventがどこから生まれ、何を根拠とし、どのTransition Chainに属するかを追跡できる。

5　Causation Chainを保持する

一つの行政Actionの上流には複数のEventが存在する。

Political Decision
     ↓
Legal Event
     ↓
Authority Change
     ↓
Fiscal Authorization
     ↓
Administrative Action
     ↓
Local Execution

各Eventにcausation_idを持たせれば、

[
\boxed{
Action
\rightarrow
WhyDidThisHappen?
}
]

を遡ることができる。

ただし、ここでのCausationはSystem上のEvent Dependencyであり、社会科学上の因果効果とは区別する。

[
\boxed{
RuntimeCausation
\neq
SocialCausation
}
]

である。

6　Correlation IDで一つの政策Executionを束ねる

複数Runtimeにまたがる一連のProcessには共通Correlation IDを付与できる。

Policy Process P-001
Political Event       ┐
Legal Event           │
Budget Event          ├── correlation_id = P-001
Administrative Event  │
Local Event           ┘

これによって、分散したEventを一つのGovernment Processとして追跡できる。

StateをMergeしなくてもProcessを統合できる。

7　Authority Validationを各Runtimeに残す

Eventが別Runtimeから届いたからといって、自動承認しない。

Incoming Event
     ↓
Schema Validation
     ↓
Identity Validation
     ↓
Authority Validation
     ↓
Legal / Domain Rules
     ↓
Evidence Validation
     ↓
Local Transition

とする。

[
\boxed{
TrustedRuntime
\neq
AutomaticAuthority
}
]

である。

各Runtimeが自身のInstitutional Boundaryを守る。

8　Distributed Transactionを国家Authorityにしない

Softwareでは複数Serviceを一つのTransactionとして処理したくなる。

しかし国家制度では、異なるDecisionが異なる時点で成立する。

したがって、

[
\boxed{
TechnicalAtomicity
\neq
InstitutionalAtomicity
}
]

である。

政治Decision、法的効力、予算成立、行政Executionを一つのDatabase Transactionへ閉じ込めない。

代わりにEvent-drivenなProcessとして進行させる。

9　SagaとしてGovernment Processを実装する

長時間にわたるGovernment ProcessはSaga型として表現できる。

Political Decision
     ↓
Legal Transition
     ↓
Fiscal Transition
     ↓
Administrative Transition
     ↓
Local Transition
     ↓
Completed / Suspended / Failed

各段階は独立してCommitされる。

後続Transitionが成立しなかった場合、過去の正当な政治Decisionまで技術的Rollbackで消してはならない。

[
\boxed{
Compensation
\neq
HistoricalDeletion
}
]

である。

10　State Projectionを生成する

各RuntimeのStateを統合して、Current Japan StateをProjectionする。

PoliticalState
     +
LegalState
     +
AdministrativeState
     +
FiscalState
     +
LocalState
     ↓
JapanStateProjection(t)

したがって、

[
\boxed{
JapanState(t)

P(t)+L(t)+A(t)+F(t)+G(t)
}
]

と概念化できる。

ただしこれは物理的に一つの巨大Tableへ格納するという意味ではない。

Logical Stateとして統合する。

11　Cross-domain Invariantを検証する

統合Runtimeだからこそ検出できる矛盾がある。

例えば、

存在しないInstitutionにCurrent Roleが付いていないか。

失効したAuthorityによるActionがないか。

未施行法令を根拠にExecutionしていないか。

Budget AuthorizationなしにFiscal Eventが進んでいないか。

廃止自治体へCurrent Programが割り当てられていないか。

これらをCross-domain Validatorで確認する。

Canonical Japan State
     ↓
Cross-domain Rules
     ↓
VALID / WARNING / INVALID

とする。

12　ConsistencyとTruthを区別する

Cross-domain Validationを通過したからといって、それがRealityの絶対的Truthであるとは限らない。

[
\boxed{
InternallyConsistent
\neq
AbsolutelyTrue
}
]

である。

Systemが保証するのは、

Schema。

Evidence。

Authority。

Time。

Domain Rule。

間の整合性である。

Realityについて新しいEvidenceが得られれば、Correction EventによってStateを更新する。

13　Replayで国家の時間を再構築する

Integrated Runtimeの大きな能力は、複数Domainを同期してReplayできることである。

Initial Japan State
      +
Validated Government Event Log
      ↓
Replay(until=t)
      ↓
JapanState(t)

これによって、

ある時点の国会。

内閣。

法令。

行政組織。

Authority。

予算。

地方自治体。

Program。

を一つのTemporal Stateとして再構成できる。

[
\boxed{
JapanState(t)

Replay(
GovernmentEvents_{\leq t}
)
}
]

である。

14　RealityAtとKnownAtをRuntimeへ持ち込む

第Ⅱ部で定義した二重時間をRuntimeにも適用する。

[
\boxed{
JapanState(t,k)
}
]

tはReality Time。

kはKnowledge Cutoffである。

これによって、

「現在判明しているEvidenceで2020年を再構成する」

場合と、

「2020年当時に利用可能だった情報だけで2020年を再現する」

場合を分離できる。

後者は将来、Historical Decision Simulationに不可欠になる。

15　Failureを局所化する

一つのRuntimeのFailureで国家全体のStateを破壊しない。

Runtime A ─ ACTIVE
Runtime B ─ DEGRADED
Runtime C ─ QUARANTINED
Runtime D ─ ACTIVE

といったHealth Stateを持たせる。

不正EventはQuarantineし、最後に検証済みのCanonical Stateを維持する。

[
\boxed{
PartialFailure
\neq
GlobalStateCorruption
}
]

である。

16　CorrectionとRecoveryをEvent化する

誤ったEventがCommitされた場合も、Historyを消去しない。

Original Event
     ↓
Correction / Reversal Event
     ↓
New Canonical State

とする。

必要ならService側のTechnical Rollbackを行っても、Canonical Historical Recordは保持する。

[
\boxed{
Recovery
\neq
Erasure
}
]

である。

17　Human-authoritative Boundaryを統合する

Integrated Runtimeでも最終原則は変わらない。

AI / System
   ↓
Observe
Analyze
Validate
Simulate
Propose
   ↓
Human / Institutional Authority
   ↓
Authorize
   ↓
Government Runtime
   ↓
Canonical State Transition

AIが複数府省庁を横断して最適解を発見したとしても、

[
\boxed{
Optimization
\neq
Authorization
}
]

である。

国家のInstitutional AuthorityをOptimization Engineへ移譲しない。

18　Government Runtimeを一つのLoopへする

すべてを統合すると、

Political State
     ↓
Decision
     ↓
Legal State
     ↓
Authority
     ↓
Fiscal State
     ↓
Administrative Execution
     ↓
Local Execution
     ↓
Social Reality
     ↓
Observation
     ↓
New Political / Administrative Input

というLoopが形成される。

[
\boxed{
Decision
\rightarrow
Rule
\rightarrow
Resource
\rightarrow
Execution
\rightarrow
Reality
\rightarrow
Observation
}
]

そしてObservationは次のDecisionへ戻る。

これは閉じた自動制御Loopではない。

人間、制度、政治、社会が介在するHuman-authoritative Open Loopである。

19　Integrated Government Runtimeを完成させる

第Ⅲ部全体を最小化すると、

[
\boxed{
GovernmentRuntime

CanonicalState
+
DomainRuntimes
+
TypedEvents
+
Authority
+
Evidence
+
Time
+
Audit
}
]

となる。

さらにState Transitionとして書けば、

[
\boxed{
JapanState_{t+1}

Transition(
JapanState_t,
ValidatedEvents,
Authorities,
Evidence,
Rules
)
}
]

である。

ここで重要なのは、日本政治Digital Twinが日本国家そのものになることではない。

[
\boxed{
DigitalTwin
\neq
StateSovereignty
}
]

である。

Digital Twinは、国家を観測し、構造化し、変化を再生し、分析し、SimulationするExecution Architectureである。

Authoritative Decisionは、現実の制度主体に残る。

第Ⅰ部では、

[
Ontology
]

によって国家の意味を定義した。

第Ⅱ部では、

[
Data
]

によって一次資料からCanonical Japan Stateを構築した。

第Ⅲ部では、

[
Runtime
]

によって、そのStateを時間の中で動かした。

したがって、ここまでの生成軸は、

[
\boxed{
Ontology
\rightarrow
Data
\rightarrow
Runtime
}
]

となる。

しかし、まだ実装上の大きな問題が残っている。

この国家規模のRuntimeを、どのProgramming Languageで構築するのか。

Intelligence。

Critical Backend。

Memory。

Interface。

Distributed Runtime。

Infrastructure。

Formal Verification。

それぞれに最適な言語は異なる。

すべてを一言語で書く必要もなければ、28言語を均等に使う必要もない。

必要なのは、

[
\boxed{
RightLanguage
\rightarrow
RightLayer
\rightarrow
OneCanonicalReality
}
]

である。

次の第Ⅳ部では、日本政治Digital Twinを実際に構築する28-Language Architectureへ進む。

国家のState Transitionは、ここからPolyglot Systemとして物理的なSoftware Architectureを獲得する。

愛と敬意を込めてmandala