Runtime OS の詳細検討 Signal Input Layerについて

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

🎥 The YouTube version is also available:

Runtime OSとは？ AIエージェント・マルチエージェント時代に必要な新しいAI基盤

Books :Runtime OS 実践ガイド: AI Agent • Human Gate • Decision Trace* 統合する実装アーキテクチャ

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

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

概要

通常のOSでは、まず外部世界から情報を受け取る必要があります。

例えば、

  • キーボード入力
  • マウス操作
  • ネットワーク通信
  • センサー情報
  • ディスクI/O

などです。

OSは、これらの入力を直接アプリケーションへ渡しているわけではありません。

その間には、

  • デバイスドライバ
  • I/O制御
  • 割り込み処理
  • 入力抽象化

といった仕組みが存在しています。

例えばキーボード一つを取っても、実際にはメーカーや通信方式は様々です。しかしOSは、その違いを吸収し、

「キー入力イベント」

として統一的に扱えるようにしています。

つまり通常OSにおけるI/O層とは、

現実世界の複雑な入力を、
コンピュータ内部で扱える形へ変換する層

なのです。

Runtime OS においても、
同じ問題が発生します。

ただし、AI時代になると、
入力される対象は従来より遥かに複雑になります。

例えば：

  • LLMの生成結果
  • センサーデータ
  • APIイベント
  • 人間の入力
  • 他エージェントからの通知
  • SNS投稿
  • ログ情報
  • 監視システムのアラート
  • IoT機器の状態変化
  • 業務システムの更新
  • 外部サービスのレスポンス

などです。

つまり Runtime OS は、
単なるコンピュータ内部ではなく、

AI・人間・組織・外部世界

から絶えずSignalを受け取り続けることになります。

ここで重要なのは、
これらの入力は単なる「データ」ではないという点です。

例えば：

温度: 98℃

という値だけでは、
それが危険なのかどうかは分かりません。

しかし Runtime OS にとって重要なのは：

  • 工場設備の異常か
  • 医療上の危険か
  • センサー故障か
  • 一時的ノイズか
  • 緊急停止が必要か

という「意味」です。

つまり Runtime OS の Input Layer は、

データを受け取る層ではなく、
意味を持つSignalを受け取る層

なのです。

さらに重要なのは、
Runtime OS における「デバイス」の概念そのものが変化することです。

従来OSでは、
デバイスとは：

  • キーボード
  • マウス
  • GPU
  • NIC
  • センサー

などのハードウェアでした。

しかし Runtime OS では：

  • AIエージェント
  • 人間
  • 外部API
  • IoT機器
  • ロボット
  • SNS
  • 業務システム
  • 組織そのもの

までが、「入力源」になります。

つまり：

Runtime OS におけるデバイスとは、
AI・人間・外部世界そのもの

なのです。

例えば製造業では：

  • 温度センサーが異常を検知する
  • AI検査Agentが欠陥候補を出す
  • 現場作業員が異常報告を送る
  • 品質管理システムが警告を出す
  • ERPが在庫異常を通知する

こうした複数のSignalが同時にRuntime OSへ流れ込みます。

Runtime OS は、それらを単なるログとして扱うのではなく、

  • 危険度
  • 信頼度
  • 優先度
  • 発生源
  • 文脈
  • 過去履歴

を含む「意味付きSignal」として扱います。

その上で初めて、

  • Decision Scheduler
  • Boundary Layer
  • Human Gate
  • Escalation

などの次の層へ渡されるのです。

つまり Signal Input Layer は、

Runtime OS における
「現実世界との接点」

であり、

AI・人間・社会・センサー・組織から流れ込む膨大なSignalを、
意思決定可能な形へ変換する入口なのです。

具体的な設計案

Signal Input Layer は、単なる「入力受付」ではなく、

外部世界から来るデータを、Runtime OS が判断可能な Signal に変換する入口

として設計します。

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

External Sources
  ↓
Input Adapter
  ↓
Signal Parser
  ↓
Signal Normalizer
  ↓
Context Enricher
  ↓
Trust / Risk Scorer
  ↓
Signal Queue
  ↓
Decision Scheduler

1. Input Adapter

まず、入力元ごとに Adapter を用意します。

例えば：

LLM Adapter
Sensor Adapter
API Adapter
Human Input Adapter
Agent Adapter
Log Adapter
SNS Adapter
Database Adapter

役割は、それぞれの形式の違いを吸収することです。

例えば、LLMの出力、センサー値、APIイベント、人間のコメントは形式が全く違います。
それらをそのまま扱うのではなく、まず Adapter が受け取り、Runtime OS 内部で扱える形式へ渡します。

2. Signal Parser

次に、受け取ったデータを解析します。

例えば：

{
  "raw_input": "temperature=98",
  "source": "sensor_01",
  "input_type": "temperature_reading"
}

この段階では、まだ単なる入力に近い状態です。

ここで、

  • 入力元
  • 入力種類
  • 時刻
  • 値
  • 単位
  • 発生場所
  • 関連ID

などを抽出します。

3. Signal Normalizer

次に、すべての入力を共通の Signal Schema に変換します。

例えば：

{
  "signal_id": "sig_001",
  "source": "temperature_sensor_01",
  "source_type": "sensor",
  "signal_type": "temperature_anomaly",
  "value": 98,
  "unit": "celsius",
  "confidence": 0.91,
  "timestamp": "2026-05-26T10:00:00+09:00"
}

重要なのは、ここで形式を統一することです。

Runtime OS 内部では、LLM出力も、センサーデータも、人間入力も、すべて Signal として扱います。

4. Context Enricher

Signal は単体では意味が弱いので、文脈を付与します。

例えば「温度98℃」だけでは判断できません。

そこで、

  • どの設備か
  • 通常温度は何度か
  • 過去にも発生したか
  • 現在の工程は何か
  • 周辺センサーも異常か
  • 人間からの報告はあるか
  • 過去のDecision Traceと一致するか

を追加します。

例：

{
  "context": {
    "asset_id": "machine_12",
    "location": "factory_line_A",
    "normal_range": "40-70",
    "recent_history": "similar anomaly occurred twice in last 24h",
    "related_signals": ["sig_0007", "sig_0008"]
  }
}

ここが非常に重要です。

Runtime OS は「データ」ではなく、
文脈付きSignal を扱うべきです。

5. Trust / Risk Scorer

次に、そのSignalの信頼度と危険度を評価します。

例えば：

{
  "trust_score": 0.86,
  "risk_score": 0.74,
  "urgency": "high",
  "requires_human_review": true
}

ここで見るべき指標は：

  • source trust：入力元は信頼できるか
  • confidence：検出精度は高いか
  • risk：放置した場合の危険度
  • urgency：今すぐ処理すべきか
  • reversibility：後から取り消せるか
  • human impact：人間への影響があるか
  • legal / safety impact：法規制や安全基準に関係するか

です。

6. Signal Queue

評価済みSignalは、すぐにDecisionへ渡すのではなく、Queueに入れます。

Critical Queue
High Priority Queue
Normal Queue
Low Priority Queue
Audit Queue

こうすることで、Decision Scheduler が優先順位をつけられます。

例えば：

  • 人命リスク → Critical
  • 工場停止リスク → High
  • 通常ログ → Normal
  • 参考情報 → Low
  • 監査用記録 → Audit

のように分けます。

7. Signal Schema の基本形

Runtime OS では、最初に共通スキーマを決めるのが重要です。

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

{
  "signal_id": "sig_001",
  "source": "camera_agent",
  "source_type": "ai_agent",
  "signal_type": "risk_detection",
  "payload": {},
  "confidence": 0.82,
  "risk_score": 0.67,
  "urgency": "medium",
  "context": {},
  "requires_human_review": false,
  "timestamp": "2026-05-26T10:00:00+09:00",
  "trace_id": "trace_001"
}

8. MVPとして最初に作るなら

最初から複雑にしすぎず、まずはこの5つで十分です。

1. Input Adapter
2. Signal Normalizer
3. Context Enricher
4. Risk / Trust Scorer
5. Signal Queue

最初の実装イメージは：

FastAPI
  ↓
Pydantic Signal Schema
  ↓
PostgreSQL / Redis
  ↓
Risk Scoring Service
  ↓
Decision Scheduler

で良いと思います。

設計の核心

Signal Input Layer の本質は、

入力を受けることではなく、入力を「意思決定可能なSignal」に変換すること

です。

したがって設計原則は次の一文にできます。

Runtime OS の Signal Input Layer は、AI・人間・外部世界から来る多様な入力を、文脈・信頼度・危険度・優先度を持つ共通Signalへ変換し、Decision Schedulerへ渡す層である。

この定義で設計すると、DTMの
Event → Signal → Decision → Boundary → Human → Log
にもきれいにつながります。

Related Research

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

Chinoba Research
Chinoba-lab Open Source
Books and Library

コメント

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