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

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

概要（プロセス実行層）

Runtime OS において、Execution Layer は「最終実行層」です。

ここで初めて、
Decision は現実世界へ作用します。

通常のOSにおいても、
最終的に重要なのは「実行」です。

OSは：

  • プロセスを起動し
  • スレッドを実行し
  • ファイルを書き換え
  • ネットワーク通信を行い
  • デバイスを制御する

ことで、
実際にコンピュータを動かしています。

つまりOSとは、
最終的には：

「計算結果を現実の動作へ変換するシステム」

なのです。

Runtime OS でも、
同じ構造があります。

ただし Runtime OS が実行する対象は：

  • CPU命令
  • メモリアクセス
  • ファイル操作

だけではありません。

Runtime OS が実行するのは：

  • Agent action
  • API execution
  • Workflow execution
  • Robot control
  • Database update
  • Human notification
  • Financial transaction
  • Social action

です。

つまり Runtime OS は：

「現実世界へ作用するOS」

なのです。

ここが、
従来のAIシステムと決定的に違います。

なぜ Execution Layer が重要なのか

生成AI単体では、
多くの場合「提案」で止まります。

例えば：

メール文を生成する
要約する
コードを書く
分析する

などです。

しかし Runtime OS の世界では、
AIは：

  • 実行する
  • 制御する
  • 更新する
  • 停止する
  • 通知する
  • 契約する
  • 操作する

ようになります。

つまり AI は：

「実行主体」

へ変化するのです。

ここで初めて：

  • 安全性
  • 権限
  • Boundary
  • Human approval
  • 責任
  • Traceability

が極めて重要になります。

なぜなら：

Runtime OS は、
現実世界を変更してしまう

からです。

通常OSとの対応

通常OS：

Process
Thread
File I/O
Device control
Network communication

Runtime OS：

Agent action
API execution
Workflow execution
Robot control
Database update
Human interaction
External world control

になります。

Runtime OS における Execution の意味

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

Execution は
「AI推論」ではない

という点です。

例えば：

AI:
「工場停止した方がよい」

はまだ推論です。

しかし：

stop_machine(machine_12)

を実行した瞬間、
現実世界が変化します。

つまり Execution Layer は：

「Decision を Reality に変換する層」

なのです。

Execution Layer が扱うもの

Execution Layer が扱う対象は非常に広いです。

1. Agent Action Execution

Agent自体の実行です。

例えば：

Risk Analysis Agent
Vision Agent
Policy Validation Agent
Escalation Agent

などを起動します。

ここでは：

  • start
  • stop
  • retry
  • timeout
  • rollback

を管理します。

2. API Execution

外部システムとの接続です。

例えば：

ERP API
CRM API
Bank API
IoT API
Cloud API
Slack API

です。

Runtime OS は、
APIを通じて現実世界へ作用します。

つまり API は：

「現実世界I/O」

なのです。

3. Database Update

DB更新も重要な Execution です。

例えば：

在庫更新
契約状態変更
診断履歴保存
ユーザー状態更新

などです。

DB更新は：

  • 不可逆性
  • 一貫性
  • 責任

を持つため、
Boundary制御が重要になります。

4. Workflow Execution

複数処理を協調実行します。

例えば：

異常検知
 ↓
追加診断
 ↓
Human approval
 ↓
停止実行
 ↓
通知送信
 ↓
監査ログ保存

です。

つまり Runtime OS は：

「意思決定Workflow実行系」

でもあります。

5. Robot / Physical Control

ここが非常に重要です。

Runtime OS は：

  • 工場
  • ロボット
  • 自動運転
  • IoT
  • ドローン
  • 医療機器

などとも接続されます。

つまり Runtime OS は：

「物理世界制御OS」

になり得ます。

ここでは：

  • リアルタイム性
  • 安全Boundary
  • Emergency stop
  • Human override

が極めて重要になります。

6. Human Interaction Execution

Execution対象は、
機械だけではありません。

例えば：

通知送信
承認依頼
アラート発報
担当者割当
会議招集

などです。

つまり Runtime OS は：

「組織実行OS」

でもあります。

7. Social Action Execution

さらに重要なのは、
Execution が社会的作用を持つことです。

例えば：

送金
契約変更
行政通知
価格変更
サービス停止

です。

つまり Runtime OS は：

「社会作用実行OS」

なのです。

ここが通常OSと本質的に違います。

Execution Layer に必要なもの

Execution Layer は、
単なるAPI呼び出しでは不十分です。

必要なのは：

permission validation
boundary confirmation
human approval check
rollback capability
trace recording
execution isolation
emergency stop
retry control

です。

実行前チェック

Execution前には：

Boundary OKか
Human approval済みか
Policy違反していないか
Escalation中ではないか
Conflictがないか

を確認します。

つまり：

Execution は、
必ず Kernel を経由する

必要があります。

Rollback / Compensation

通常OSの transaction rollback に近い概念も必要です。

例えば：

送金失敗
Workflow中断
API timeout
部分実行

が起きた場合：

  • rollback
  • compensation action
  • human intervention

が必要になります。

Execution Isolation

通常OSが process isolation を持つように、
Runtime OS も：

Agent isolation
Workflow isolation
Execution sandbox

を持つべきです。

例えば：

Financial workflow が
Medical workflow に影響しない

ようにします。

Human Override

Execution中でも、
人間は停止できる必要があります。

例えば：

Emergency stop
Pause workflow
Cancel execution
Force override

です。

これは Runtime OS における：

「Human interrupt」

です。

Execution の本質

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

Execution Layer は、
「推論」を扱っているのではない

という点です。

Execution Layer は：

「現実世界変更」

を扱っています。

つまり：

  • 責任
  • 危険
  • 法律
  • 安全
  • 社会影響

が必ず発生します。

ここが：

Runtime OS が単なるAIではない理由

です。

Runtime OS における位置

DTM 的には：

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

の：

Human Gate
↓
Reality Change

を担います。

つまり Execution Layer は：

「Decision を Reality に変換する層」

なのです。

Runtime OS における最大の違い

通常OS：

計算を実行する

Runtime OS：

社会的作用を実行する

です。

つまり Runtime OS は：

  • AI
  • 組織
  • 人間
  • 法律
  • 現実世界

を接続し、

「現実を変更するOS」

になるのです。

Execution Layer の設計原則

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

Execution Layer とは、Decision Runtime Kernel によって許可された Decision を、Agent action・API execution・Workflow・Robot control・Human interaction・社会的作用として現実世界へ反映し、その結果をTrace可能な形で管理する Runtime OS の実行層である。

これが、

Runtime OS における Execution Layer の本質

です。

以下のように設計すると、Execution Layer を Runtime OS の「現実世界実行層」として整理できます。

設計案

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

Approved Decision
  ↓
Execution Pre-check
  ↓
Execution Plan Builder
  ↓
Executor Router
  ↓
Execution Sandbox
  ↓
Action Executor
  ↓
Result Validator
  ↓
Rollback / Compensation Handler
  ↓
Execution Result
  ↓
Decision Trace

1. Execution Pre-check

まず、実行前に最終確認を行います。

ここでは、Decision Runtime Kernel から渡された Decision が本当に実行可能かを確認します。

確認項目は：

Boundary OKか
Human approval済みか
Policy違反がないか
権限が有効か
実行期限内か
競合Decisionがないか
Escalation中ではないか

です。

例：

{
  "decision_id": "dec_001",
  "precheck_result": "passed",
  "checks": {
    "boundary": "ok",
    "human_approval": "approved",
    "policy": "ok",
    "conflict": "none",
    "execution_window": "valid"
  }
}

ここで失敗した場合は、Execution を止めて Kernel に戻します。

2. Execution Plan Builder

次に、Decision を実行可能な手順に変換します。

例えば、Decision が：

machine_12 を停止する

だった場合、実行Planは：

1. 作業員に通知
2. 追加センサー確認
3. PLC APIへ停止要求
4. 停止状態確認
5. 管理者へ結果通知
6. Trace保存

になります。

つまり Execution Plan Builder は、

Decision を具体的な Action Sequence に変換する

役割を持ちます。

例：

{
  "execution_plan_id": "ep_001",
  "decision_id": "dec_001",
  "steps": [
    {
      "step_id": "s1",
      "action": "notify_operator",
      "executor": "notification_executor"
    },
    {
      "step_id": "s2",
      "action": "run_diagnostics",
      "executor": "diagnostic_agent"
    },
    {
      "step_id": "s3",
      "action": "stop_machine",
      "executor": "plc_executor"
    }
  ]
}

3. Executor Router

次に、各Actionを適切なExecutorへ振り分けます。

Executorの種類は例えば：

Agent Executor
API Executor
Workflow Executor
Database Executor
Robot / IoT Executor
Notification Executor
Human Task Executor
Financial Executor

です。

例：

send_slack_message → Notification Executor
update_inventory → Database Executor
stop_machine → Robot / IoT Executor
run_risk_analysis → Agent Executor

4. Execution Sandbox

Execution は必ず Sandbox 内で行います。

通常OSでプロセスを隔離するように、Runtime OS でも実行単位を隔離します。

隔離対象は：

Agent実行
API呼び出し
Workflow
DB更新
外部操作

です。

Sandboxでは：

許可されたActionだけ実行できる
許可されたResourceだけ触れる
Timeoutを設定する
Rate limitをかける
外部APIの失敗を閉じ込める
他Workflowへ影響させない

を制御します。

5. Action Executor

実際のActionを実行します。

例：

{
  "action_id": "act_001",
  "action_type": "api_call",
  "target": "plc_api",
  "operation": "stop_machine",
  "parameters": {
    "machine_id": "machine_12"
  }
}

ここでは必ず：

idempotency key
timeout
retry policy
rollback policy
trace_id

を持たせるのが重要です。

特に外部API実行では、二重実行を避けるために idempotency key が必要です。

6. Result Validator

実行結果を検証します。

Execution Layer では、APIを呼んだだけでは不十分です。

重要なのは：

本当に現実世界が期待通りに変化したか

を確認することです。

例えば：

stop_machine API を呼んだ

だけではなく、

machine_12 の状態が stopped になったか

を確認します。

例：

{
  "execution_result": "success",
  "validation": {
    "expected_state": "stopped",
    "actual_state": "stopped",
    "validated": true
  }
}

7. Rollback / Compensation Handler

実行に失敗した場合や、一部だけ成功した場合に対応します。

通常OSやDBでは rollback がありますが、現実世界では完全な rollback ができない場合もあります。

そのため Runtime OS では：

rollback
compensation
manual recovery
escalation

を分けます。

例：

状況 対応
DB更新失敗 rollback
通知送信失敗 retry
送金済み compensation
工場停止済み manual recovery
ロボット異常 emergency stop

現実世界では「元に戻す」よりも、「補償処理」が重要になる場合があります。

8. Execution Result Writer

最後に、結果を記録します。

記録するものは：

実行したAction
実行者
対象Resource
開始時刻
終了時刻
結果
失敗理由
rollback有無
human override有無
trace_id

です。

これは Decision Trace に接続されます。

Execution Schema 案

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

{
  "execution_id": "exec_001",
  "decision_id": "dec_001",
  "trace_id": "trace_001",

  "execution_type": "robot_control",
  "target": "machine_12",
  "action": "stop_machine",

  "status": "running",

  "precheck_result": "passed",

  "executor": "plc_executor",

  "parameters": {
    "machine_id": "machine_12"
  },

  "permission_snapshot": {
    "boundary_result": "approved",
    "human_approval": "approved",
    "policy_result": "ok"
  },

  "idempotency_key": "exec_001_stop_machine_12",

  "timeout_sec": 30,
  "retry_policy": {
    "max_retries": 2,
    "backoff": "exponential"
  },

  "rollback_policy": {
    "type": "manual_recovery",
    "on_failure": "escalate"
  },

  "result": null,

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

実装モジュール構成案

execution/
  schemas.py
  precheck.py
  plan_builder.py
  executor_router.py
  sandbox.py
  executors/
    agent_executor.py
    api_executor.py
    db_executor.py
    workflow_executor.py
    notification_executor.py
    robot_executor.py
  result_validator.py
  compensation_handler.py
  trace_writer.py
  service.py

処理イメージ

def execute_decision(decision):
    precheck = run_execution_precheck(decision)

    if not precheck.passed:
        return {
            "status": "blocked",
            "reason": precheck.reason
        }

    plan = build_execution_plan(decision)

    results = []

    for step in plan.steps:
        executor = executor_router.resolve(step)

        sandbox = execution_sandbox.create(
            decision=decision,
            step=step
        )

        result = executor.run(
            step=step,
            sandbox=sandbox
        )

        validated = result_validator.validate(
            step=step,
            result=result
        )

        if not validated.success:
            compensation_handler.handle_failure(
                step=step,
                result=result
            )
            break

        results.append(validated)

    trace_writer.write_execution_result(
        decision=decision,
        results=results
    )

    return results

実行状態管理

Execution は状態管理が重要です。

created
prechecked
planned
running
waiting_external_response
completed
failed
rolled_back
compensated
cancelled
escalated
overridden

これにより、途中停止・再開・監査が可能になります。

MVPで最初に作るなら

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

1. Execution Pre-check
2. Executor Router
3. API Executor
4. Result Validator
5. Trace Writer

次の段階で：

Workflow Executor
Sandbox
Rollback / Compensation
Robot Executor
Human Override

を追加すると良いです。

設計原則

Execution Layer は、単なるAPI呼び出し層ではありません。

本質は、

Approved Decision
↓
Pre-check
↓
Action Plan
↓
Sandboxed Execution
↓
Reality Change
↓
Validation
↓
Trace

です。

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

Execution Layer は、Kernel によって許可された Decision を、実行前検証・Sandbox・Executor・結果検証・Rollback / Compensation・Trace を通じて、現実世界への安全な作用として実行する Runtime OS の最終実行層である。

この層によって、Runtime OS は「考えるAI」ではなく、「現実世界に安全に作用する意思決定OS」になります。

Related Research

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

Chinoba Research
Chinoba-lab Open Source
Books and Library

コメント

モバイルバージョンを終了
タイトルとURLをコピーしました