Runtime OSにおけるHuman Gate Layerとは何か ― AI時代の人間承認と責任の仕組み

通常のOS（Operating System）が、CPU・メモリ・プロセスといった計算資源を安全に協調制御するための基盤であったように、Runtime OS は、知能・人間・ルール・組織・現実世界を安全に協調実行するための基盤として考えることができます。

従来OSが、

「CPU・メモリ・プロセスの協調制御」

を行っていたのに対し、

Runtime OS は、

「意思決定・エージェント・境界・責任・人間承認の協調制御」

を行う存在です。

この観点で見ると、Runtime OS の構造は、実は従来のOSアーキテクチャと非常に強い対応関係を持っています。デバイスドライバに相当するSignal Input Layer、CPU Schedulerに対応するDecision Scheduler、Kernelに対応するDecision Runtime Kernel、権限管理に対応するBoundary Layerなど、AI時代の意思決定システムは、OS的な構造として理解できるようになっていくのです。

ここではHuman Gate Layerについて詳しく検討します。

概要（syscall / interrupt 的役割）

Runtime OS において、Human Gate Layer は極めて本質的な存在です。

なぜなら、AI時代において本当に重要なのは、

「AIをどれだけ賢くするか」

だけではなく、

「人間がどこで最終権限を持つか」

だからです。

従来のコンピュータシステムでは、
最終制御権はOS Kernelにありました。

しかし Runtime OS では、
最終制御権は、

Human Authority

にあります。

ここが、
通常OSとRuntime OSの決定的な違いです。

通常OSにおける syscall / interrupt

通常OSでは、
アプリケーションは直接Kernelを操作できません。

例えば：

• ファイルアクセス
• ネットワーク通信
• デバイス操作
• メモリ確保

を行うには、

syscall

が必要です。

つまり：

User Mode
   ↓ syscall
Kernel Mode

という切替が発生します。

また異常時には：

• hardware interrupt
• exception
• fault
• kernel panic

などが発生し、
Kernelが制御を引き取ります。

つまり通常OSでは、

「危険な操作」
「特権操作」

は、
必ずKernelを経由する

ようになっています。

Runtime OS における Human Gate

Runtime OS でも、
同じ問題が発生します。

ただし Runtime OS が扱うのは：

• CPU
• メモリ
• デバイス

ではありません。

Runtime OS が扱うのは：

• 意思決定
• Agent execution
• 現実世界操作
• 人間への影響
• 法律
• 社会的責任

です。

つまり Runtime OS における syscall は：

AI
 ↓
Human Authority

なのです。

なぜ Human Gate が必要なのか

AIが提案するだけなら、
そこまで問題にならない場合があります。

しかしAIが：

• 送金する
• 契約変更する
• 医療判断する
• 工場停止する
• ロボットを制御する
• 行政判断する

ようになると、
問題は一気に変わります。

なぜなら：

「誰が責任を持つのか」

が発生するからです。

ここで重要なのは、

AIは推論できても、
責任主体にはなれない

という点です。

つまり：

• 法的責任
• 倫理責任
• 社会責任
• 組織責任

は、
最終的には人間が持つ必要があります。

そのため Runtime OS では：

Human Gate Layer

が必要になります。

Human Gate の本質

Human Gate は単なる：

• OKボタン
• 承認画面

ではありません。

本質は：

「AIの自律性を、人間権限へ接続する境界」

です。

つまり Human Gate は：

• AI execution
• Human authority
• Organizational responsibility
• Legal accountability

を接続する層になります。

Human Gate が扱うもの

Human Gate Layer が扱うのは：

approval
confirmation
override
shutdown
rejection
escalation
manual intervention
responsibility assignment

です。

1. Confirmation

最も軽い Human Gate です。

例えば：

このメールを送信しますか？

この通知を公開しますか？

などです。

ここでは：

• 人間確認
• 内容確認
• 誤操作防止

が目的です。

2. Approval

より重要な操作では、
承認が必要になります。

例えば：

Action	Approval
契約変更	必要
送金	必要
工場停止	必須
医療変更	必須

です。

ここでは：

• 誰が承認するか
• 何段階必要か
• どの権限が必要か

を管理します。

3. Override

人間は、
AI判断を覆せる必要があります。

例えば：

AI:
「工場停止推奨」

Human:
「停止しない」

です。

これは非常に重要です。

なぜなら Runtime OS において：

最終権限は Human Authority

だからです。

つまり Runtime OS は：

Human Overrideable

でなければなりません。

4. Shutdown

最終手段として、
人間はシステム停止できる必要があります。

例えば：

Emergency Stop
Kill Agent
Disable Automation
Freeze Execution

です。

これは通常OSでいう：

kernel panic
emergency halt
kill process

に近いです。

つまり Runtime OS では：

「人間による停止権」

が必要になります。

5. Escalation

Human Gate は、
Escalation の中心にもなります。

例えば：

AI Agent
 ↓
Supervisor Agent
 ↓
Human Operator
 ↓
Manager
 ↓
Emergency Committee

です。

つまり Human Gate は：

「権限階層」

でもあります。

Human Gate は syscall に近い

通常OSでは：

User Process
 ↓ syscall
Kernel

です。

Runtime OS では：

AI Agent
 ↓ Human Gate
Human Authority

になります。

つまり Human Gate は、

「社会的 syscall」

なのです。

Human Gate は interrupt にも近い

異常時には、
Human Gate は interrupt 的役割も持ちます。

例えば：

Boundary violation
Risk escalation
Agent conflict
Unexpected behavior

が発生した場合：

AI execution
 ↓ interrupt
Human intervention

になります。

つまり Human Gate は：

「社会的 interrupt handler」

でもあります。

Human-in-the-Loop を超える

ここで重要なのは、

Human Gate は、
単なる Human-in-the-Loop ではない

という点です。

普通の Human-in-the-Loop は：

AI → 人間確認

程度です。

しかし Runtime OS の Human Gate は：

Authority
Responsibility
Override
Shutdown
Escalation
Governance

まで含みます。

つまり Human Gate は：

「Human-in-the-Kernel」

なのです。

Human Gate が必要な理由

もし Human Gate がなければ：

• AIが暴走しても止められない
• 責任主体が曖昧になる
• 法規制に対応できない
• 組織承認が存在しない
• 社会的受容性が失われる

ことになります。

つまり：

Human Gate は、
AIを社会へ接続するための根本条件

なのです。

Runtime OS における位置

DTM 的には：

Event
  ↓
Signal
  ↓
Decision
  ↓
Boundary
  ↓
Human Gate
  ↓
Execution
  ↓
Trace

の：

Boundary
↓
Execution

の間に存在します。

つまり Human Gate は：

「AI Decision を Human Responsibility に接続する層」

なのです。

Runtime OS における最大の違い

通常OSでは：

Kernel が最終制御権を持つ

でした。

Runtime OS では：

Human Authority が最終制御権を持つ

になります。

つまり Runtime OS は：

「人間をOS内部に組み込むOS」

なのです。

Human Gate Layer の設計原則

したがって、
Human Gate Layer は次のように定義できます。

Human Gate Layer とは、AIやAgentによるDecisionとExecutionの間に存在し、人間による承認・介入・override・shutdown・責任付与・Escalationを可能にする Runtime OS の権限制御層である。

これが、

Runtime OS における Human Gate の本質

です。

以下のように設計すると、Human Gate Layer を Runtime OS の「人間権限制御層」として実装しやすくなります。

設計案

基本構成は次のようにします。

Boundary Decision
  ↓
Human Gate Resolver
  ↓
Approval Request Builder
  ↓
Authority Resolver
  ↓
Human Task Queue
  ↓
Human Response Handler
  ↓
Override / Reject / Approve Processor
  ↓
Escalation Controller
  ↓
Execution Permission
  ↓
Decision Trace

1. Human Gate Resolver

まず、そのDecisionに人間関与が必要かを判断します。

判定基準は以下です。

risk_score
human_impact
legal_impact
financial_impact
safety_impact
reversibility
policy_requirement
boundary_result
confidence

例えば：

{
  "human_gate_required": true,
  "gate_type": "approval",
  "reason": [
    "critical_risk",
    "human_safety_impact",
    "low_reversibility"
  ]
}

Human Gate が不要な場合は、そのまま Execution Layer へ進みます。
必要な場合は、承認タスクを生成します。

2. Gate Type の分類

Human Gate は一種類ではありません。

最低限、次の5種類に分けると良いです。

confirmation
approval
override
shutdown
escalation

Gate Type	役割	例
confirmation	軽い確認	メール送信確認
approval	正式承認	送金・契約変更
override	AI判断の上書き	工場停止推奨を却下
shutdown	緊急停止	Agent停止、実行凍結
escalation	上位権限へ移譲	管理者・委員会へ移す

3. Approval Request Builder

人間に渡す承認リクエストを生成します。

重要なのは、人間が判断できる情報をまとめることです。

含めるべき情報は：

AIの提案
なぜその提案になったか
使用されたSignal
Risk score
Boundary result
Policy result
代替案
承認した場合の影響
拒否した場合の影響
推奨アクション
期限
責任者

例：

{
  "approval_request_id": "ap_001",
  "decision_id": "dec_001",
  "title": "工場ラインAの停止承認",
  "summary": "machine_12 の温度異常により停止が推奨されています。",
  "proposed_action": "stop_machine",
  "risk_score": 0.94,
  "boundary_result": "require_human_approval",
  "recommended_action": "approve_shutdown",
  "alternatives": [
    "追加診断を実行する",
    "作業員へ確認する",
    "一時監視を継続する"
  ],
  "deadline": "2026-05-26T10:05:00+09:00"
}

4. Authority Resolver

次に、誰が承認できるかを決めます。

通常OSで root 権限が必要な操作があるように、Runtime OS でも操作ごとに必要な権限レベルを定義します。

例：

operator
supervisor
manager
domain_expert
compliance_officer
emergency_authority

例：

{
  "required_authority": "plant_manager",
  "candidate_approvers": [
    "user_102",
    "user_204"
  ],
  "multi_stage": true,
  "required_approvals": [
    "safety_supervisor",
    "plant_manager"
  ]
}

ここで重要なのは、

誰でも承認できるわけではない

ということです。

5. Human Task Queue

承認依頼は Human Task Queue に入れます。

Queue は用途別に分けると良いです。

confirmation_queue
approval_queue
critical_approval_queue
override_queue
shutdown_queue
escalation_queue

こうすると、人間側の未処理タスクを管理できます。

特に重要なのは：

pending
approved
rejected
overridden
expired
escalated
cancelled

の状態管理です。

6. Human Response Handler

人間の応答を受け取ります。

応答は最低限、次を扱います。

approve
reject
request_more_info
override
shutdown
escalate

例：

{
  "approval_request_id": "ap_001",
  "responder_id": "user_204",
  "response": "reject",
  "comment": "現場確認がまだ取れていないため停止しない。",
  "responded_at": "2026-05-26T10:03:00+09:00"
}

重要なのは、コメントや理由も必ず Trace に残すことです。

7. Override / Reject / Approve Processor

人間の応答に応じて Decision 状態を更新します。

approve → execution_allowed
reject → execution_blocked
override → human_decision_replaces_ai_decision
shutdown → freeze_execution
request_more_info → return_to_agent_or_context_layer
escalate → escalation_controller

ここで、Human Authority が AI Decision より上位にあることを明確にします。

8. Escalation Controller

期限内に応答がない場合や、判断が分かれた場合は Escalation します。

条件例：

approval_timeout
risk_score >= 0.9
conflicting_human_responses
policy_required_escalation
boundary_violation
emergency_signal

Escalation path の例：

operator
  ↓
supervisor
  ↓
manager
  ↓
emergency_committee
  ↓
shutdown_authority

Human Gate Schema 案

最小構成はこれで良いです。

{
  "human_gate_id": "hg_001",
  "decision_id": "dec_001",
  "trace_id": "trace_001",

  "gate_type": "approval",
  "status": "pending",

  "required_authority": "plant_manager",
  "candidate_approvers": [
    "user_102",
    "user_204"
  ],

  "risk_score": 0.94,
  "reason": [
    "critical_risk",
    "human_safety_impact",
    "low_reversibility"
  ],

  "proposed_action": "stop_machine",
  "allowed_responses": [
    "approve",
    "reject",
    "request_more_info",
    "escalate"
  ],

  "deadline": "2026-05-26T10:05:00+09:00",

  "response": null,
  "responder_id": null,
  "comment": null,

  "on_approve": "allow_execution",
  "on_reject": "block_execution",
  "on_timeout": "escalate",

  "created_at": "2026-05-26T10:00:00+09:00",
  "updated_at": "2026-05-26T10:00:00+09:00"
}

実装モジュール構成案

human_gate/
  schemas.py
  gate_resolver.py
  approval_request_builder.py
  authority_resolver.py
  task_queue.py
  response_handler.py
  escalation_controller.py
  service.py

処理イメージ

def resolve_human_gate(decision, boundary_result, context):
    gate = gate_resolver.resolve(decision, boundary_result, context)

    if not gate.required:
        return {
            "human_gate_required": False,
            "next": "execution_layer"
        }

    approval_request = approval_request_builder.build(
        decision=decision,
        boundary_result=boundary_result,
        context=context
    )

    authority = authority_resolver.resolve(
        action=decision.proposed_action,
        risk_score=decision.risk_score,
        context=context
    )

    task = task_queue.create(
        approval_request=approval_request,
        authority=authority
    )

    trace_writer.write_human_gate_created(task)

    return task

MVPで最初に作るなら

最初はこの4つで十分です。

1. Gate Resolver
2. Approval Request Builder
3. Human Task Queue
4. Response Handler

その後に、

Authority Resolver
Escalation Controller
Multi-stage Approval
Override / Shutdown

を追加するとよいです。

UI設計のポイント

Human Gate はUIが非常に重要です。

承認画面には最低限、以下を表示します。

AIの提案
理由
Risk level
Boundary result
承認が必要な理由
実行した場合の影響
拒否した場合の影響
代替案
Approve / Reject / Escalate

単なる「OK / Cancel」では不十分です。
人間が責任を持って判断できる情報を提示する必要があります。

設計原則

Human Gate Layer は、単なる承認ボタンではありません。

本質は、

AI Decision
↓
Human Authority
↓
Responsibility
↓
Execution Permission
↓
Trace

をつなぐことです。

つまり設計原則はこうです。

Human Gate Layer は、AIやAgentのDecisionを、人間の承認・拒否・介入・override・shutdown・責任付与へ接続し、その結果をExecution PermissionとDecision Traceへ反映する Runtime OS の人間権限制御層である。

この層があることで、Runtime OS は単なる自律実行システムではなく、社会的責任を持つ意思決定システムになります。