概要

AIプラットフォームのデフォルトのデプロイメントモデルはクラウドネイティブである：ハイパースケーラーのインフラ上でエラスティックスケーリングを備えたコンテナ化マイクロサービスだ。多くの企業にとって、このモデルは機能する。しかし規制産業 — 銀行、医療、防衛、エネルギー、政府 — にとっては機能しない。データ主権に関する規制、エアギャップ要件、リアルタイム意思決定システムのレイテンシ制約、サプライチェーンセキュリティの懸念が厳格な境界線を生み出す：AIガバナンスプラットフォームは、組織が物理的に管理するインフラ上で動作しなければならない。

本論文はMARIA OSアプライアンス・リファレンスアーキテクチャを提示する — MARIA OSを自己完結型のラックマウント可能なアプライアンスとして展開するための完全な仕様である。3つのハードウェアティア（評価用、本番用、エンタープライズ用）、3つのネットワークモード（エアギャップ、ハイブリッド、クラウド接続）、3つのデプロイメントトポロジー（単一ノード、HAクラスタ、マルチサイト連合）を定義する。このアーキテクチャは、デプロイメントモードに関係なく、MARIA OSのすべてのガバナンス保証 — 責任保存、フェイルクローズドデフォルト、不変の監査証跡 — を維持する。

ハードウェア部品表、ソフトウェアスタック構成、HSM統合によるセキュリティアーキテクチャ、監視・可観測性設計、エアギャップ環境でのアップグレード戦略、災害復旧手順、キャパシティプランニングモデル、およびオンプレミスとクラウドを比較するTCO分析フレームワークを提供する。

---

1. なぜオンプレミスAIガバナンスが重要なのか

1.1 ハードコンストレイントとしてのデータ主権

AIガバナンスシステムは、組織内で最も機密性の高いデータを処理する：意思決定の根拠、責任の割り当て、価値観の整合性、承認チェーン、エビデンスバンドル。このデータは、組織の判断が明示化されたものである。規制産業では、このデータは厳格な居住要件の対象となる：

• 金融サービス：意思決定の監査証跡は、SOX法、MiFID II、バーゼルIIIの要件に基づき、7年以上オンプレミスで保持する必要がある。国境を越えたデータ転送は追加の規制審査を引き起こす。

• 医療：患者に影響する意思決定は、HIPAA、GDPR第9条（特別カテゴリーデータ）、および各国の健康データ保護法の対象となる。意思決定パイプライン自体がFDA 21 CFR Part 11の下で医療機器コンポーネントとなる。

• 防衛・政府：機密およびCUI（管理対象非機密情報）の意思決定データは、NIST 800-171およびCMMCレベル3+の下でエアギャップ処理を必要とする。

• 重要インフラ：エネルギー、水道、交通システムは、リアルタイムガバナンスのために100ms未満の意思決定レイテンシを必要とし、クラウドへの往復呼び出しは非実用的である。

1.2 レイテンシの議論

意思決定パイプラインのレイテンシは、単なるパフォーマンスの問題ではなく、ガバナンスの問題である。責任ゲートがAIエージェントの提案するアクションに人間の承認が必要かどうかを評価する際、評価はアクションウィンドウが閉じる前に完了しなければならない。物理世界の意思決定（製造、ロボティクス、エネルギーグリッド）では、このウィンドウは50msまで狭くなることがある。

L_{\text{gate}} = L_{\text{eval}} + L_{\text{evidence}} + L_{\text{network}} \leq L_{\text{action_window}}

オンプレミスデプロイメントは$L_{\text{network}}$（通常クラウドまでの20-80ms）を排除し、エビデンス評価とゲートロジックにより多くの時間を確保する。100msのアクションウィンドウにおいて、50msのネットワークレイテンシを排除することで、ガバナンス評価に利用可能な計算時間が2倍になる。

1.3 サプライチェーンセキュリティ

AIガバナンスプラットフォームは、組織内のすべての自動化された意思決定にとって重要な依存関係である。クラウドデプロイメントはサプライチェーンリスクを導入する：ハイパースケーラーの障害、APIの廃止、価格変更、データセンターの可用性に影響する地政学的リスク。オンプレミスデプロイメントは、これらの変動リスクを、組織の直接管理下にある固定的で管理可能なインフラに変換する。

---

2. アプライアンスフォームファクタの定義

MARIA OSアプライアンスは、事前構成・検証済みのハードウェア・ソフトウェアバンドルとしてラックマウント可能なユニットで提供される。3つのティアが異なるデプロイメント規模に対応する：

各ティアは検証済み構成である — ハードウェア、ファームウェア、OS、MARIA OSソフトウェアが一つのユニットとしてテストされている。これにより、DIYオンプレミスデプロイメントを悩ませるハードウェア・ソフトウェア互換性問題の組み合わせ爆発が排除される。

アプライアンスは、MARIA OSサプライチェーン検証システムによって暗号的に署名されたハードウェアマニフェストとともに出荷される。初回起動時、アプライアンスは自身のハードウェアをマニフェストと照合し、輸送中のコンポーネント交換や改竄を検出する。

---

3. ハードウェアリファレンス仕様

3.1 コンピュートアーキテクチャ

M-400 本番ティア — ハードウェア仕様

compute: cpu: model: "AMD EPYC 9454 (Genoa)" cores: 48 threads: 96 base_clock_ghz: 2.75 boost_clock_ghz: 3.8 tdp_watts: 290 quantity: 2 # Dual socket purpose: "Decision pipeline, governance engine, API serving"

gpu: model: "NVIDIA L40S" vram_gb: 48 quantity: 2 interconnect: "PCIe Gen5 x16" purpose: "Agent inference, value scanning, evidence embedding"

ram: type: "DDR5-4800 ECC RDIMM" capacity_gb: 512 channels: 12 purpose: "In-memory decision state, agent context windows"

storage: tier_1_hot: type: "NVMe U.2 PCIe Gen5" capacity_tb: 3.84 quantity: 4 raid: "RAID-10" effective_capacity_tb: 7.68 purpose: "Active decision state, agent runtime, governance DB"

tier_2_warm: type: "NVMe U.2 PCIe Gen4" capacity_tb: 7.68 quantity: 4 raid: "RAID-6" effective_capacity_tb: 15.36 purpose: "Decision audit logs, evidence bundles (90-day window)"

tier_3_cold: type: "SAS SSD" capacity_tb: 15.36 quantity: 4 raid: "RAID-6" effective_capacity_tb: 30.72 purpose: "Long-term audit archive, compliance retention"

networking: management: "1GbE BMC/IPMI dedicated" data: - "2x 25GbE SFP28 (cluster interconnect)" - "2x 10GbE RJ45 (application traffic)" storage_fabric: "1x 100GbE QSFP28 (optional, for external storage)"

security_hardware: tpm: "TPM 2.0 (firmware integrity)" hsm: "FIPS 140-3 Level 3 PCIe HSM module (key management)"

3.2 GPUサイジングの根拠

エージェント推論が主要なGPUワークロードである。各MARIA OSエージェントは、意思決定評価、エビデンス分析、価値スキャニングのために量子化された言語モデルを実行する。サイジングの公式：

G_{\text{required}} = \left\lceil \frac{N_{\text{agents}} \times M_{\text{model}} \times B_{\text{batch}}}{V_{\text{gpu}} \times U_{\text{target}}} \right\rceil

ここで$N_{\text{agents}}$は同時エージェント数、$M_{\text{model}}$はモデルメモリフットプリント（量子化された7Bモデルで通常4-8 GB）、$B_{\text{batch}}$はバッチオーバーヘッド係数（1.3倍）、$V_{\text{gpu}}$はGPUあたりのVRAM、$U_{\text{target}}$は目標使用率（0.85）。4ビット量子化7Bモデルで50エージェントを実行するM-400の場合：$G = \lceil (50 \times 4 \times 1.3) / (48 \times 0.85) \rceil = \lceil 6.37 \rceil = 2$ GPU。

---

4. ネットワークトポロジーとデプロイメントモード

4.1 3つのネットワークモード

アプライアンスは、デプロイメント時に選択可能な3つのネットワーク構成をサポートする：

エアギャップモード：外部ネットワーク接続なし。すべてのモデル、アップデート、構成は物理的に搬送される媒体（暗号化USBまたは光学メディア）を介してロードされる。ガバナンスエンジンは外部依存関係ゼロで動作する。モデルアップデートは、保管連鎖追跡付きの署名・暗号化メディアで提供される。

ハイブリッドモード：データダイオードまたは一方向ゲートウェイを介したアウトバウンドのみの接続。テレメトリ、匿名化されたガバナンスメトリクス、アップデートリクエストが外部に流れ、アップデートパッケージは別の監査済みチャネルを通じて流入する。意思決定データは決してプレミスを離れない。

クラウド接続モード：MARIA OSクラウドサービスへの暗号化トンネルにより、モデルアップデート、テレメトリ集約、ピーク負荷時のオプションのクラウドバースト推論を実現。意思決定データはオンプレミスに残り、モデルウェイトと匿名化された運用メトリクスのみがトンネルを通過する。

// Network mode configuration — set at deployment, enforced by firewall rules interface ApplianceNetworkConfig { mode: "air-gapped" | "hybrid" | "cloud-connected";

// Air-gapped: all undefined // Hybrid: only outbound defined // Cloud-connected: both defined outbound?: { endpoint: string; protocol: "mTLS" | "WireGuard"; allowList: string[]; // Explicit IP allowlist dataDiode: boolean; // Hardware-enforced one-way for hybrid };

inbound?: { endpoint: string; protocol: "mTLS"; allowList: string[]; rateLimit: { requestsPerMinute: number }; };

// Always present — governs what data classes can leave the appliance dataClassification: { decisionData: "never-transmit"; auditLogs: "never-transmit"; evidenceBundles: "never-transmit"; operationalMetrics: "transmit-anonymized" | "never-transmit"; modelUpdateRequests: "transmit" | "never-transmit"; }; }

4.2 クラスタインターコネクト

HAおよびマルチノードデプロイメントでは、ノードはオンボードHSMによって発行された証明書を使用するmTLSで、専用の25GbEクラスタインターコネクトを介して通信する。クラスタプロトコルは、意思決定パイプラインの状態に対してRaftベースの合意形成を使用し、ノード遷移時に意思決定が失われたり重複したりしないことを保証する。

---

5. ソフトウェアスタックレイヤー

アプライアンスのソフトウェアスタックは5つのレイヤーで構成され、各レイヤーには明確な責任境界がある：

MARIA OS Appliance Software Stack

layers: L0_platform: os: "Ubuntu 24.04 LTS (hardened, CIS Level 2)" kernel: "6.8 LTS (custom: real-time patches, SELinux enforcing)" firmware: "Signed UEFI with Secure Boot chain" purpose: "Hardware abstraction, security foundation"

L1_container_runtime: runtime: "containerd 2.0" orchestration: "K3s (lightweight Kubernetes)" networking: "Cilium (eBPF-based, no iptables)" storage: "Longhorn (replicated block storage)" purpose: "Workload isolation, resource management"

L2_data_layer: primary_db: "PostgreSQL 17 (Patroni HA)" cache: "DragonflyDB (Redis-compatible, multi-threaded)" event_bus: "NATS JetStream (embedded, no external dependency)" object_store: "MinIO (S3-compatible, local storage)" purpose: "State persistence, event streaming, object storage"

L3_maria_core: decision_pipeline: "6-stage state machine with transition validation" governance_engine: "Responsibility gates, approval workflows" audit_system: "Immutable append-only log (hash-chained)" evidence_engine: "Evidence collection, verification, bundling" value_scanner: "Behavioral value extraction and gap analysis" coordinate_system: "G.U.P.Z.A hierarchical addressing" purpose: "Core governance logic, decision processing"

L4_agent_runtime: inference: "vLLM (GPU) / llama.cpp (CPU fallback)" model_store: "Local model registry (OCI-compatible)" agent_lifecycle: "Spawn, monitor, constrain, terminate" sandbox: "gVisor (agent code isolation)" purpose: "Agent execution, model serving, isolation"

各レイヤーは独立してアップグレード可能である。レイヤー境界はコンテナネームスペースとネットワークポリシーによって強制される — L4の侵害されたエージェントは、L3のガバナンスエンジンやL2のデータレイヤーにアクセスできない。

---

6. デプロイメントトポロジー

6.1 単一ノード（M-100、M-400）

最もシンプルなトポロジー：すべてのソフトウェアレイヤーが単一のアプライアンス上で動作する。評価、開発、およびエージェント数が控えめな（50未満）本番デプロイメントに適している。単一ノードはデータベース、ガバナンスエンジン、エージェントランタイムを含むフルスタックを実行する。バックアップは外部NASまたはリムーバブルメディアへのスケジュールされたスナップショットで処理される。

6.2 HAクラスタ（3ノードM-400）

高可用性を必要とする本番デプロイメントでは、Raft合意形成を備えた3ノードクラスタを使用する：

// HA Cluster Configuration interface HAClusterConfig { nodes: 3 | 5; // Odd number for Raft quorum topology: { leader: { role: "primary"; services: ["decision-pipeline", "governance-engine", "api-gateway"]; }; followers: { role: "standby"; services: ["decision-pipeline-replica", "read-api", "agent-runtime"]; replicationLag: { maxMs: 50 }; }; };

failover: { detectionMethod: "heartbeat + decision-pipeline-health"; detectionTimeoutMs: 2000; promotionTimeMs: 4200; // Measured p99 inFlightDecisionRecovery: "replay-from-wal"; };

database: { ha: "patroni"; syncReplicas: 1; // At least 1 sync replica asyncReplicas: 1; // Remaining nodes async walShipping: true; }; }

クラスタはフェイルオーバー時の意思決定ゼロロスを保証する：インフライトの意思決定は新しいリーダー上のWAL（先行書き込みログ）からリプレイされる。同期レプリカの最大データ損失ウィンドウ（RPO）は0である。

6.3 マルチサイト連合（M-900）

複数の地理的拠点にまたがるエンタープライズデプロイメントは、連合トポロジーを使用する。各サイトは完全なローカル自律性を持つ独立したHAクラスタを実行する。連合レイヤーはガバナンスポリシー、エージェント定義、集約された監査サマリーをサイト間で同期する — ただし、生の意思決定データは発生元のサイトを離れることはない。

\text{Federation_Consistency} = \frac{|P_{\text{local}} \cap P_{\text{global}}|}{|P_{\text{global}}|} \geq 0.999

連合サイト間のポリシー整合性は、ゴシップベースのプロトコルにより99.9%以上で維持され、任意のサイトでのポリシー更新から30秒以内に収束する。

---

7. セキュリティアーキテクチャ

7.1 ハードウェアセキュリティモジュール（HSM）統合

アプライアンスにはFIPS 140-3レベル3認証のHSMモジュールが含まれており、すべての暗号操作を管理する：

• 意思決定署名：すべての意思決定遷移は、HSM内に排他的に保持されるキーで署名される。これにより改竄検知可能なチェーンが作成される — 意思決定監査証跡への変更は署名チェーンを無効化する。

• 監査ログの整合性：不変の監査ログはHSM保持キーによるハッシュチェーンを使用する。検証にはHSMが必要であり、オフラインでのログ改竄を検出可能にする。

• mTLS証明書発行：すべてのサービス間およびノード間の証明書は、HSMに裏打ちされたPKIによって発行される。秘密鍵がHSM境界外に存在することはない。

• 保存時暗号化：すべてのストレージティアはHSMから導出されたキーによるAES-256-XTSを使用する。キーローテーションはサービス中断なしに毎月実施される。

7.2 ゼロトラストネットワーキング

Zero-trust network policy (Cilium)

apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: governance-engine-policy spec: endpointSelector: matchLabels: app: governance-engine ingress: - fromEndpoints: - matchLabels: app: decision-pipeline - matchLabels: app: api-gateway toPorts: - ports: - port: "8443" protocol: TCP rules: http: - method: POST path: "/api/v1/gates/.*" egress: - toEndpoints: - matchLabels: app: postgresql toPorts: - ports: - port: "5432" protocol: TCP - toEndpoints: - matchLabels: app: audit-log toPorts: - ports: - port: "8444" protocol: TCP

すべてのサービス間通信はmTLS認証を必要とし、明示的に許可されたパスに制限される。デフォルトポリシーはdeny-allである — サービスは通信を明示的に許可されなければならない。これにより、エージェントランタイムが侵害された場合でも、ガバナンスエンジンやデータベースに直接アクセスすることはできない。

7.3 エージェントサンドボックス

各エージェントは、すべてのシステムコールをインターセプトするgVisorサンドボックス内で実行される。エージェントはホストファイルシステム、ネットワーク（管理されたプロキシを介した場合を除く）、または他のエージェントプロセスにアクセスできない。リソース制限（CPU、メモリ、GPU時間）はエージェントごとに適用され、不正なエージェントによるサービス拒否を防止する。

---

8. 監視と可観測性

アプライアンスには、外部依存関係を必要としない自己完結型の可観測性スタックが含まれる：

ガバナンス固有のメトリクスは可観測性スタックにおいてファーストクラスの市民である：

• maria_decisions_total — ステージと結果別の意思決定カウンター

• maria_gate_latency_seconds — 責任ゲート評価時間のヒストグラム

• maria_responsibility_conservation_ratio — 意思決定合成全体の責任保存を測定するゲージ

• maria_audit_chain_integrity — ブーリアンゲージ（1 = 正常、0 = チェーン破損検出）

• maria_agent_sandbox_violations_total — エージェントごとのブロックされたシステムコールのカウンター

アラートルールは重要なガバナンス不変条件違反に対して事前構成されて出荷される。監査チェーンの整合性障害は、パイプラインの自動一時停止を伴うP1アラートを即座にトリガーする。

---

9. アップグレードとパッチ戦略

9.1 エアギャップ環境でのアップデートプロセス

エアギャップデプロイメントでは、アップデートは暗号的に署名されたメディアで提供される：

1. ビルド：MARIA OS CI/CDがOSパッチ、コンテナイメージ、データベースマイグレーションを含む署名済みアップデートバンドルを生成する。

2. 転送：バンドルは保管連鎖マニフェスト付きの暗号化リムーバブルメディアに書き込まれる。

3. 検証：アプライアンス上で、アップデートエージェントがHSM保持のMARIA OSルート証明書に対してバンドル署名を検証する。

4. ステージング：コンテナイメージがローカルレジストリにロードされる。データベースマイグレーションが現在のスキーマに対して検証される。

5. 適用：ブルーグリーンデプロイメントがトラフィックを更新されたスタックに切り替える。以前のバージョンは即時ロールバックのために利用可能なまま残る。

6. 検証：アップデート後のヘルスチェックが11のガバナンス不変条件すべてを検証する。いずれかのチェックが失敗した場合、60秒以内に自動ロールバックが実行される。

9.2 ローリングアップグレード（HAクラスタ）

HAデプロイメントでは、アップグレードは一度に1ノードずつ適用される。クラスタはプロセス全体を通じてクォーラムを維持する。各ノードのアップグレードは、次のノードに進む前にステージング-適用-検証サイクルに従う。3ノードデプロイメントの合計クラスタアップグレード時間：ゼロダウンタイムで約45分。

T_{\text{upgrade}} = N_{\text{nodes}} \times (T_{\text{drain}} + T_{\text{apply}} + T_{\text{validate}}) = 3 \times (3 + 8 + 4) = 45 \text{ min}

---

10. 災害復旧とバックアップ

10.1 バックアップアーキテクチャ

バックアップ戦略は、エアギャップ環境に適応した3-2-1モデルに従う：

• 3コピー：プライマリ（ライブ）、オンボックススナップショット、外部バックアップ

• 2種類のメディア：NVMe（ライブ + スナップショット）、リムーバブル暗号化SSD（外部）

• 1つのオフサイト：非エアギャップデプロイメントの場合、地理的に離れた場所への暗号化バックアップ

// Disaster Recovery Configuration interface DRConfig { backup: { database: { method: "pg_basebackup + WAL archiving"; frequency: "continuous WAL + daily base backup"; retention: { days: 30, walRetention: "7 days" }; encryption: "AES-256-GCM (HSM-managed key)"; };

auditLogs: {
  method: "immutable snapshot";
  frequency: "hourly";
  retention: { years: 7 };  // Regulatory minimum
  integrityVerification: "hash-chain validation on restore";
};

agentState: {
  method: "checkpoint + replay";
  frequency: "every 100 decisions or 5 minutes";
  retention: { days: 7 };
};

};

recovery: { rto: { singleNode: "4 hours", haCluster: "15 minutes" }; rpo: { singleNode: "1 hour", haCluster: "0 (sync replication)" }; procedure: "automated with manual approval gate"; testFrequency: "quarterly"; }; }

10.2 不変監査ログの復旧

監査ログは最も重要なデータ資産である。アプライアンスの完全な損失シナリオにおいても、監査ログは復旧可能かつ検証可能でなければならない。ハッシュチェーン構造により、任意のバックアップからの整合性検証が可能になる — 単一のエントリが変更された場合、チェーンはその時点で破断し、正確な変更箇所が特定可能となる。

---

11. キャパシティプランニングモデル

11.1 リソーススケーリングの公式

MARIA OSアプライアンスのキャパシティプランニングは、3つの主要次元に基づく予測可能なモデルに従う：

R_{\text{total}} = \sum_{i=1}^{N} \left( R_{\text{agent}i} + R{\text{pipeline}} + R_{\text{governance}} + R_{\text{audit}} \right)

各リソースクラスは異なるスケーリング特性を持つ：

• CPU：エージェント数に対して線形。各エージェントはオーケストレーションロジックに約0.5 vCPUを消費する。ガバナンスエンジンは4 vCPUの固定オーバーヘッドを追加する。

• GPU VRAM：ステップ関数。各モデルインスタンスはバッチ推論を介して複数のエージェントにサービスを提供する。$(k+1)$番目のモデルインスタンスの追加が必要になるのは、エージェント数が$k \times \lfloor V_{\text{gpu}} / M_{\text{model}} \rfloor$を超えた場合である。

• ストレージ：意思決定量に対して線形。各意思決定は約12 KBの監査データを生成する（意思決定レコード + エビデンス参照 + 遷移ログ）。1日1,000件の意思決定で、年間約4.3 GBの監査データが蓄積される。

• RAM：サブリニア。エージェントのコンテキストウィンドウは共通の埋め込みキャッシュを共有する。メモリはキャッシュ共有により$O(N^{0.7})$でスケーリングする。

11.2 サイジングテーブル

---

12. クラウド vs. オンプレミス：TCO分析フレームワーク

12.1 コスト構成要素

公正なTCO比較は、両方のデプロイメントモデルにおけるすべてのコスト構成要素を考慮しなければならない：

// TCO Analysis Framework interface TCOModel { onPremise: { capex: { hardware: number; // Appliance purchase price installation: number; // Rack, power, cooling setup networkInfrastructure: number; }; opex: { power: number; // kWh * rate * PUE cooling: number; // Included in PUE rackSpace: number; // Colocation or owned DC staffing: number; // 0.25 FTE per appliance (estimated) maintenance: number; // Hardware warranty + support contract softwareLicense: number; // MARIA OS on-premise license upgrades: number; // Hardware refresh (5-year cycle) }; };

cloud: { capex: { migration: number; // Initial setup and data migration }; opex: { compute: number; // GPU instances (reserved or on-demand) storage: number; // Block + object storage networking: number; // Egress charges softwareLicense: number; // MARIA OS cloud license (SaaS) staffing: number; // 0.1 FTE for cloud management complianceOverhead: number; // Additional controls for cloud compliance }; }; }

// Break-even formula // T_breakeven = CAPEX_onprem / (OPEX_cloud_monthly - OPEX_onprem_monthly) // Typical: 14-22 months for 50+ agent deployments

12.2 規制産業における隠れたクラウドコスト

規制産業における隠れたコストを考慮すると、TCO比較は大きく変化する：

• コンプライアンスオーバーヘッド：規制産業におけるクラウドデプロイメントは追加の制御（暗号化キー管理、アクセスログ、データ居住検証）を必要とし、基本的なクラウドコストに15-30%を追加する。

• エグレス料金：規制当局のレビューのためにエクスポートする必要がある意思決定監査データにはエグレス料金が発生する。大規模では月額10,000ドル以上になることがある。

• ベンダーロックインリスク：クラウドネイティブアーキテクチャは、6-18ヶ月のエンジニアリング工数と推定されるスイッチングコストを生み出す。

• 可用性保証：クラウドSLAは通常99.9%（年間8.7時間のダウンタイム）を保証する。MARIA OS HAクラスタは直接管理下で99.99%（年間52分）を達成する。

規制コンプライアンス要件を持つ50エージェントを超えるデプロイメントでは、オンプレミスアプライアンスは約18ヶ月でクラウドデプロイメントとのTCOパリティに達する。36ヶ月目までに、累積コスト優位性は37%に達し、これは主にエグレス料金とコンプライアンスオーバーヘッドの排除によるものである。

12.3 意思決定主権プレミアム

コストを超えて、オンプレミスデプロイメントはクラウドに直接的な等価物を持たない意思決定主権プレミアムを提供する：意思決定データ、責任の割り当て、ガバナンス評価のいずれもが、組織の物理的・法的管理外のインフラを通過したことがないという数学的保証である。データ侵害が存在的な結果をもたらす産業 — 防衛請負業者、重要インフラ運営者、生命に影響する意思決定を扱う医療システム — にとって、この保証は機能ではない。要件である。

---

関連記事: Planet 100 Agent Population Dynamics: Emergent Role Specialization in Large-Scale Multi-Agent Governance Systems

関連記事: Communication Topology and Information Cascading in Planet 100: Bottleneck Detection and Bandwidth Optimization in 100+ Agent Clusters

関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law

関連記事: Organizational Learning Dynamics Under Meta-Insight: A Differential Equations Model for System-Wide Intelligence Growth

関連記事: Metacognition in Agentic Companies: Why AI Systems Must Know What They Don't Know

関連記事: Self-Modifying Agent Systems: Architecture for Agents That Rewrite Their Own Tools, Commands, and Workflows

関連記事: AI Office Operating Model: Design Principles for a Virtual Office Where 10 Teams Work as a Unified Organizational OS

関連記事: Collective Calibration Dynamics: How Agent Teams Achieve Shared Epistemic Accuracy in MARIA OS

関連記事: Civilization Simulation as a Governance Laboratory: Emergent Institutional Evolution in Constrained Multi-Nation Systems

関連記事: Recursive Self-Improvement Under Governance Constraints: Governed Recursion via Contraction Mapping and Lyapunov Stability

関連記事: Sentence-Level Streaming VUI Architecture: From Cognitive Theory to Production Implementation in MARIA OS

関連記事: Action Router Intelligence Theory: Why Routing Must Control Actions, Not Classify Words

関連記事: Voice-Driven Agentic Avatars: A Recursive Self-Improvement Framework for Autonomous Intellectual Task Delegation

関連記事: Voice-Driven Agentic Avatars: Foundational Theory for High-Cognition Task Delegation with Recursive Improvement

関連記事: Voice User Interface設計の認知科学的基盤: マルチモーダル対話における注意資源配分モデル

関連記事: Action Router × Gate Engine Composition: Formal Theory of Responsibility-Aware Routing

関連記事: Gated Meeting Intelligence: Fail-Closed Privacy Architecture for AI-Powered Meeting Transcription

関連記事: Real-Time Meeting Session Orchestration: State Machine Design for Multi-Component Bot Systems

関連記事: AI Governance IP Strategy: A Three-Layer Model for Protecting Structural Ethics in Autonomous Systems

関連記事: Multi-Agent Societal Co-Evolution Model: Network Trust Dynamics and Phase Transitions in AI-Augmented Organizations

関連記事: Self-Extending Agent Architecture: Capability Gap Detection, Tool Synthesis, and Autonomous Evolution Under Governance Constraints

関連記事: Robot Judgment OS Lab: Designing Responsibility-Bounded Physical-World AI with Multi-Universe Gates

関連記事: CEO Clone: From Judgment Extraction to Autonomous Governance Engine

関連記事: Industrial Loop Stability: Mathematical Foundations for Self-Monitoring Capital-Physical-Ethical Control Systems

関連記事: CEO Cloneが「育つ」仕組み ── 使うほど社長に近づく理由

関連記事: CEO Cloneを社内ツールに接続する方法 ── Slack・LINE・メール連携

関連記事: CEO Clone判断エンジン：エンジニアが知るべき活用法

関連記事: Company Intelligence: なぜMARIA OSはAIツールではなく、会社の知能をつくるOSなのか

関連記事: Decision Civilization Infrastructure: From Ethics-as-Architecture to the Universal Responsibility Operating System

関連記事: The Brain as a Recursive Self-Improving System

関連記事: MARIA VITAL：Agent組織のための生命維持システム — Heartbeat監視から再帰的自己改善まで

関連記事: Tool Genesis Under Governance: How to Safely Turn Generated Code into New Commands

関連記事: Anomaly Detection for Agentic System Safety and Deviation Control

関連記事: Institutional Design for Agentic Societies: Meta-Governance Theory and AI Constitutional Frameworks

関連記事: Agent Tool Compiler: From Natural Language Intent to Executable Tool Code via Compilation Pipeline

関連記事: Audit Universe Runtime: Agent Design for Executing Audit Procedures as Runtime Operations

関連記事: Evolution as Safe Mutation Governance

関連記事: CEO Clone OS：社長インタビューから、統治された経営判断OSへ

関連記事: 動的ハーネスと位相空間制御：virtual-talentからMARIA OSへ

関連記事: Governance Load Testing: Where Does Governance Break in the 1000-Agent Era?

関連記事: Agentic Ethics Lab: Designing a Corporate Research Institute for Structural Ethics in AI Governance

関連記事: CEO Cloneのセキュリティ対策 ── 社長のデータを守る仕組み

関連記事: Investment Decision Lab: Designing Agentic R&D Teams for Multi-Universe Capital Allocation

関連記事: Doctor Architecture: Anomaly Detection as Enterprise Metacognition in MARIA OS

関連記事: Responsibility Propagation in Dense Agent Networks: Decision Flow Analysis in Planet 100's 111-Agent Ecosystem

関連記事: 申込から5分で使える「CEO Clone Light」の始め方 — 面談不要・すべてオンラインで完結

関連記事: Audit Universe Runtime：監査手続をランタイム・オペレーションとして実行するAgentアーキテクチャ

関連記事: Meta-Insight Under Distribution Shift: Change-Point Governance Loops for Enterprise Agentic Systems

関連記事: MARIA OS Appliance Reference Architecture: Standard Configuration for On-Premise AI Governance Infrastructure

関連記事: LINE・Slack・Discordで「判断OS」に相談できるようにする方法

関連記事: Knowledge Graph Construction from Decision Audit Trails: Entity Resolution and Temporal Edge Weighting for Governance Traceability

関連記事: LOGOS and the AI Tribunal: Decision Patterns, Sustainability Optimization, and Constitutional Amendment Dynamics in Civilization's National AI Systems

関連記事: Agent Capability OS — Command Registry・Tool Registry・Capability Graphで能力を管理するOS設計

関連記事: Repeated Games and the Cofounder Problem: Why Startup Cooperation Depends on Shared Time Horizons

関連記事: The Complete Action Router: From Theory to Implementation to Scaling in MARIA OS

関連記事: Memory Stratification for AI Governance: A Rate-Distortion Framework for Retention Decisions

関連記事: The Algorithm Stack for Agentic Organizations: 10 Essential Algorithms Mapped to a 7-Layer Architecture

関連記事: Capability Gap Detection — Agentが自分の能力不足を認識するメタ認知アーキテクチャ

関連記事: 経営判断をAIに任せる前に知るべき「メタ認知」の重要性：自律型AIの未来と3つの課題

関連記事: MARIA OS 評価ハーネス：Agentの品質を測定するための標準テストインフラストラクチャ

結論

MARIA OSアプライアンス・リファレンスアーキテクチャは、オンプレミスAIガバナンスが妥協ではなく、規制企業の長期的なコストを削減しながらガバナンス保証を強化する設計上の選択であることを示している。このアーキテクチャは、MARIA OSのすべての不変条件 — 責任保存、フェイルクローズドデフォルト、不変の監査証跡、段階的自律性 — を、自己完結型で検証済みのアップグレード可能なフォームファクタで維持する。

重要な洞察は、ガバナンスの局所性がガバナンスを強化するということである。意思決定パイプライン、ガバナンスエンジン、監査システムが組織の直接的な物理管理下にあるインフラ上で動作する場合、攻撃対象領域は縮小し、レイテンシ予算は拡大し、規制コンプライアンスは継続的な検証問題から一回限りの検証イベントへと簡素化される。

判断が製品であり責任がアーキテクチャである組織にとって、MARIA OSアプライアンスはその両方を具体的、監査可能、かつ主権的にするためのインフラを提供する。