Runtime OS Architecture #05: Boundary Layer — AIを現実世界へ安全に接続する実行制御基盤

Knowledge Base Archive この記事は Chinoba Knowledge Base の技術アーカイブです。 Chinoba.orgを見る →

通常の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的な構造として理解できるようになっていくのです。

ここではBoundary / Permission Layerについて詳しく検討します。

概要（メモリ保護・権限管理に相当）

Runtime OS において、Boundary / Permission Layer は極めて重要な存在です。

なぜなら、AI時代に本当に危険なのは、

「AIが間違えること」

そのものではなく、

「AIが無制限に実行できてしまうこと」

だからです。

通常のOSでも、もし権限管理が存在しなければ、システムは成立しません。

例えば、すべてのプロセスが自由に：

  • 他プロセスのメモリを書き換えられる
  • root権限を取得できる
  • デバイスを直接制御できる
  • システムファイルを削除できる

ようになれば、OS全体はすぐに破綻します。

そのため通常OSには：

  • root権限
  • process isolation
  • sandbox
  • memory protection
  • capability control

といった「境界」が存在しています。

つまり通常OSにおける Permission Layer の本質は、

「何を実行可能にするかを制限すること」

です。

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

ただし Runtime OS が扱うのは、

  • CPU
  • メモリ
  • ファイル

ではありません。

Runtime OS が扱うのは：

  • 意思決定
  • Agent execution
  • 外部システム操作
  • Workflow
  • 人間への影響
  • 現実世界への作用

です。

つまり Runtime OS において Boundary が守るべきものは、

「現実世界への危険な影響」

なのです。

なぜ Boundary が必要なのか

生成AI単体なら、
多少間違っても大きな問題にならない場合があります。

しかし Agent 化が進むと状況は変わります。

AIは：

  • APIを操作し
  • DBを書き換え
  • 工場を制御し
  • 医療判断に関与し
  • 金融送金を行い
  • 社会システムと接続される

ようになります。

つまりAIは、

「現実世界を変更可能な存在」

になるのです。

ここで重要なのは、

AIは「推論」だけではなく、
「実行能力」を持ち始める

という点です。

その瞬間、
必要になるのが：

Boundary / Permission Layer

です。

Runtime OS における Boundary とは何か

Runtime OS の Boundary は、

「AIやAgentが、どこまで現実世界へ作用できるかを制御する境界」

です。

つまり Boundary Layer は：

  • 実行許可
  • 危険制御
  • 権限制御
  • 人間承認
  • 法規制適合
  • 安全制御

を管理します。

これは、

AI時代の Permission System

です。

通常OSとの対応

通常OS：

OS機能 役割
root権限 管理者制御
process isolation 他プロセス保護
sandbox 危険操作隔離
memory protection 暴走防止

Runtime OS：

Runtime機能 役割
Human authority 最終承認
Decision Boundary 実行制限
Agent isolation Agent暴走防止
Policy enforcement 法律・ルール適用
Execution permission 実行権限制御

になります。

Boundary Layer が管理するもの

Boundary Layer は、
単なるアクセス制御ではありません。

管理対象は：

実行可能範囲
自律許可レベル
危険度
人間影響
不可逆性
法規制
安全性
組織権限
責任範囲

です。

1. Agent Capability Control

まず、
各Agentが何を実行可能かを制御します。

例えば：

Agent Allowed Actions
Summary Agent 要約のみ
Monitoring Agent アラート送信のみ
Financial Agent 送金申請のみ
Medical Agent 提案のみ

です。

つまり：

Agentごとに「能力境界」を持つ

必要があります。

2. Autonomy Level

次に、
どこまで自律許可するかを制御します。

例えば：

Action Autonomy
メール下書き Full Auto
社内通知 Semi Auto
金融送金 Human Approval
工場停止 Multi-stage Approval

です。

重要なのは：

「AIが何をできるか」

ではなく、

「AIにどこまで自律実行を許可するか」

なのです。

3. Risk Boundary

Boundary Layer は、
危険度を評価します。

例えば：

Action Risk
ログ保存 Low
DB更新 Medium
医療変更 High
緊急停止 Critical

です。

ここで：

  • 人命影響
  • 金融影響
  • 法的影響
  • 不可逆性
  • 社会影響

を考慮します。

4. Human Approval Boundary

一定以上の危険操作は、
Human Gate を要求します。

例えば：

Action Human Required
メール返信 不要
契約変更 必要
医療診断変更 必須
工場停止 多段承認

です。

つまり Runtime OS は、

「AI単独実行禁止領域」

を持つ必要があります。

5. Legal / Compliance Boundary

Boundary は、
法律・規制も評価します。

例えば：

個人情報保護
医療法
金融規制
AML
GDPR
労働安全

です。

つまり Runtime OS は、

「法的境界」

も管理する必要があります。

6. Execution Isolation

通常OSが process isolation を持つように、
Runtime OS も Agent isolation を持つべきです。

例えば：

Financial Agent は工場制御できない
Medical Agent は送金できない
Monitoring Agent はDB削除できない

などです。

つまり：

「Agent隔離」

が必要になります。

7. Boundary Escalation

Boundaryを超える場合は、
Escalation を発生させます。

例えば：

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

です。

これは通常OSの：

interrupt
privilege escalation
kernel panic

に近いです。

Boundary の本質

ここで極めて重要なのは、

Boundary は単なる「制限」ではない

という点です。

Boundary の本質は：

「AIを現実世界へ安全接続すること」

です。

つまり Boundary があるからこそ：

  • AIは実行可能になる
  • Agentは社会へ接続できる
  • 自律性を許可できる
  • 危険を制御できる
  • 責任を明確化できる

のです。

Runtime OS における Boundary の位置

DTM的には：

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

の、

Decision
↓
Execution

の間に存在します。

つまり Boundary は、

「推論」と「現実実行」の間にある安全層

なのです。

Runtime OS における最大の違い

通常OSでは：

プロセス暴走を防ぐ

ことが目的でした。

Runtime OSでは：

意思決定暴走を防ぐ

ことが目的になります。

つまり Runtime OS の Boundary は、

「意思決定保護機構」

なのです。

Boundary Layer の設計原則

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

Boundary / Permission Layer とは、Agent・Decision・Execution が、どこまで現実世界へ作用可能かを制御し、Human authority・Policy・Risk・Legal constraints を用いて、自律実行可能範囲を制限する Runtime OS の安全制御層である。

これが、

Runtime OS における Boundary の本質

です。

設計案

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

Decision Request
  ↓
Capability Checker
  ↓
Risk Evaluator
  ↓
Policy / Legal Checker
  ↓
Autonomy Level Resolver
  ↓
Human Gate Resolver
  ↓
Execution Permission Engine
  ↓
Boundary Decision

1. Capability Checker

まず、そのAgentがそのActionを実行してよいかを確認します。

通常OSでいう：

このプロセスはこのファイルを読めるか
このユーザーはroot権限を持つか
このアプリはネットワークへアクセスできるか

に相当します。

Runtime OSでは：

このAgentは送金できるか
このAgentはDB更新できるか
このAgentは工場停止できるか
このAgentは医療判断に関与できるか

を確認します。

例：

{
  "agent_id": "summary_agent",
  "requested_action": "send_payment",
  "capability_result": "deny",
  "reason": "summary_agent_has_no_financial_permission"
}

ここで重要なのは、Agentごとに明確な Capability Profile を持たせることです。

2. Capability Profile

Agentごとの権限を定義します。

例：

{
  "agent_id": "monitoring_agent",
  "allowed_actions": [
    "read_logs",
    "detect_anomaly",
    "send_alert"
  ],
  "denied_actions": [
    "delete_database",
    "transfer_money",
    "stop_machine"
  ],
  "allowed_resources": [
    "logs",
    "sensor_streams"
  ],
  "max_autonomy_level": "semi_auto"
}

この Profile によって、

Agentが何をできるか
何をできないか
どこまで自律実行できるか

を制御します。

3. Risk Evaluator

次に、そのAction自体の危険度を評価します。

評価軸は以下です。

human_impact
financial_impact
legal_impact
safety_impact
privacy_impact
reversibility
external_world_impact

例：

{
  "risk_score": 0.91,
  "risk_level": "critical",
  "risk_factors": [
    "human_safety",
    "irreversible_action",
    "physical_world_control"
  ]
}

重要なのは、Agentの権限があっても、Actionのリスクが高ければ自動実行させないことです。

4. Policy / Legal Checker

次に、法律・社内ルール・安全基準に照らして確認します。

対象は：

safety_policy
privacy_policy
financial_policy
medical_policy
factory_operation_policy
human_approval_policy

です。

例：

{
  "policy_result": "requires_human_approval",
  "matched_policies": [
    "factory_shutdown_policy",
    "human_safety_policy"
  ],
  "reason": "machine_shutdown_requires_manager_approval"
}

この層によって、AIの判断を組織ルールや法規制に接続します。

5. Autonomy Level Resolver

次に、どこまで自律実行を許可するかを決めます。

おすすめは5段階です。

L0: Observe Only
L1: Recommend
L2: Draft / Prepare
L3: Execute with Human Approval
L4: Execute Automatically

例：

Level 意味 例
L0 観測のみ ログ監視
L1 提案のみ 異常検知提案
L2 下書き作成 メール下書き
L3 承認後実行 契約変更、送金
L4 自動実行 低リスク通知

工場停止や医療判断変更は、基本的に L3 以上にはしない方が安全です。
つまり「自動実行禁止領域」として管理します。

6. Human Gate Resolver

Risk や Policy に応じて、人間承認を要求します。

例：

{
  "human_gate_required": true,
  "approval_level": "plant_manager",
  "approval_reason": "critical_safety_action",
  "timeout_sec": 300,
  "on_timeout": "escalate"
}

ここで決めるのは：

承認が必要か
誰が承認するか
何段階承認か
タイムアウト時どうするか
拒否されたらどうするか

です。

7. Execution Permission Engine

最後に、実行許可を返します。

返す結果は、最初はこの5種類で十分です。

allow
allow_with_constraints
require_human_approval
escalate
deny

例：

{
  "permission_result": "require_human_approval",
  "allowed_actions": [
    "notify_operator",
    "prepare_shutdown_request"
  ],
  "blocked_actions": [
    "auto_shutdown_machine"
  ],
  "constraints": [
    "manager_approval_required",
    "record_decision_trace"
  ]
}

これにより、AIが勝手に実行できる操作と、必ず人間承認が必要な操作を明確に分けられます。

Boundary Policy Schema 案

Boundary ルールは、JSONまたはYAMLで管理すると扱いやすいです。

boundary_id: factory_shutdown_boundary
domain: manufacturing
action: stop_machine
risk_level: critical

conditions:
  - safety_impact: true
  - physical_world_impact: true
  - reversibility: low

permission:
  result: require_human_approval
  approval_level: plant_manager
  multi_stage: true

allowed_pre_actions:
  - notify_operator
  - prepare_shutdown_request
  - run_additional_diagnostics

blocked_actions:
  - auto_shutdown_machine

trace_required: true
escalation:
  on_timeout: emergency_control
  on_conflict: supervisor_review

Boundary Decision Schema 案

Kernel に返す結果は、次のような形が良いです。

{
  "boundary_decision_id": "bd_001",
  "decision_id": "dec_001",
  "agent_id": "risk_agent",
  "requested_action": "stop_machine",

  "permission_result": "require_human_approval",

  "risk_score": 0.94,
  "risk_level": "critical",

  "capability_result": "allowed",
  "policy_result": "requires_human_approval",

  "autonomy_level": "L3_execute_with_human_approval",

  "human_gate": {
    "required": true,
    "approval_level": "plant_manager",
    "multi_stage": true
  },

  "allowed_actions": [
    "notify_operator",
    "prepare_shutdown_request",
    "run_additional_diagnostics"
  ],

  "blocked_actions": [
    "auto_shutdown_machine"
  ],

  "matched_boundaries": [
    "factory_shutdown_boundary",
    "human_safety_boundary"
  ],

  "reason": [
    "physical_world_control",
    "human_safety_impact",
    "low_reversibility"
  ],

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

実装モジュール構成案

boundary/
  schemas.py
  capability_checker.py
  risk_evaluator.py
  policy_checker.py
  autonomy_resolver.py
  human_gate_resolver.py
  permission_engine.py
  boundary_registry.py
  service.py

処理イメージ

def evaluate_boundary(decision, agent, action, context):
    capability = capability_checker.check(agent, action)
    risk = risk_evaluator.evaluate(action, context)
    policy = policy_checker.evaluate(decision, action, context)
    autonomy = autonomy_resolver.resolve(agent, action, risk, policy)
    human_gate = human_gate_resolver.resolve(risk, policy, autonomy)

    permission = permission_engine.decide(
        capability=capability,
        risk=risk,
        policy=policy,
        autonomy=autonomy,
        human_gate=human_gate
    )

    return permission

MVPで最初に作るなら

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

1. Capability Checker
2. Risk Evaluator
3. Human Gate Resolver
4. Permission Engine

Policy / Legal Checker は最初は簡易ルールでよく、後から拡張すればよいです。

最小ルール例

def decide_permission(action, risk_score, human_impact, reversibility):
    if action in ["medical_change", "factory_shutdown"]:
        return "require_human_approval"

    if risk_score >= 0.9:
        return "escalate"

    if human_impact and reversibility == "low":
        return "require_human_approval"

    if risk_score < 0.3:
        return "allow"

    return "allow_with_constraints"

設計原則

Boundary / Permission Layer は、単なる禁止機構ではありません。

本質は、

AIの実行能力
↓
現実世界への影響
↓
Policy / Risk / Human Authority
↓
許可・制限・承認・拒否

を判断することです。

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

Boundary / Permission Layer は、Agent や Decision が現実世界へ作用する前に、Capability・Risk・Policy・Human Authority・Legal constraints を評価し、自動実行・制限付き実行・人間承認・Escalation・拒否を決定する Runtime OS の安全制御層である。

この層があることで、AIは初めて「社会に接続可能な実行システム」になります。

Related Research

この記事は Chinoba Knowledge Base の一部です。

Chinoba Research
Chinoba-lab Open Source
Books and Library

コメント

タイトルとURLをコピーしました