概要
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つのティアが異なるデプロイメント規模に対応する：
| ティア | モデル | フォームファクタ | エージェント容量 | ユースケース |
| --- | --- | --- | --- | --- |
| 評価用 | M-100 | 2Uラックマウント | 1-10エージェント | PoC、開発、テスト |
| 本番用 | M-400 | 4Uラックマウント | 10-100エージェント | 単一サイト本番環境 |
| エンタープライズ | M-900 | 8Uラックマウント (2x4U) | 100-500エージェント | マルチサイト連合プライマリ |各ティアは検証済み構成である — ハードウェア、ファームウェア、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. 監視と可観測性
アプライアンスには、外部依存関係を必要としない自己完結型の可観測性スタックが含まれる：
| レイヤー | ツール | 目的 | 保持期間 |
| --- | --- | --- | --- |
| メトリクス | VictoriaMetrics | 時系列メトリクス（システム + ガバナンスKPI） | ボックス上で90日 |
| ログ | Loki | 構造化ログ集約 | ホット90日、ウォーム1年 |
| トレース | Tempo | 分散トレーシング（意思決定パイプライン） | 30日 |
| ダッシュボード | Grafana | 可視化とアラート | N/A |
| アラート | Alertmanager | アラートルーティング（メール、Webhook、PagerDuty） | N/A |ガバナンス固有のメトリクスは可観測性スタックにおいてファーストクラスの市民である：
- 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 サイジングテーブル
| エージェント数 | 意思決定/日 | ティア | GPU | CPUコア数 | RAM (GB) | ホットストレージ (TB) |
| --- | --- | --- | --- | --- | --- | --- |
| 5 | 500 | M-100 | 1x L40S | 32 | 128 | 1.92 |
| 25 | 2,500 | M-400 | 2x L40S | 96 | 256 | 3.84 |
| 50 | 5,000 | M-400 | 2x L40S | 96 | 512 | 7.68 |
| 100 | 10,000 | M-900 | 4x L40S | 192 | 1024 | 15.36 |
| 250 | 25,000 | M-900 (cluster) | 8x L40S | 384 | 2048 | 30.72 |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 deployments12.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 意思決定主権プレミアム
コストを超えて、オンプレミスデプロイメントはクラウドに直接的な等価物を持たない意思決定主権プレミアムを提供する：意思決定データ、責任の割り当て、ガバナンス評価のいずれもが、組織の物理的・法的管理外のインフラを通過したことがないという数学的保証である。データ侵害が存在的な結果をもたらす産業 — 防衛請負業者、重要インフラ運営者、生命に影響する意思決定を扱う医療システム — にとって、この保証は機能ではない。要件である。
結論は
MARIA OSアプライアンス・リファレンスアーキテクチャは、オンプレミスAIガバナンスが妥協ではなく、規制企業の長期的なコストを削減しながらガバナンス保証を強化する設計上の選択であることを示している。このアーキテクチャは、MARIA OSのすべての不変条件 — 責任保存、フェイルクローズドデフォルト、不変の監査証跡、段階的自律性 — を、自己完結型で検証済みのアップグレード可能なフォームファクタで維持する。
重要な洞察は、ガバナンスの局所性がガバナンスを強化するということである。意思決定パイプライン、ガバナンスエンジン、監査システムが組織の直接的な物理管理下にあるインフラ上で動作する場合、攻撃対象領域は縮小し、レイテンシ予算は拡大し、規制コンプライアンスは継続的な検証問題から一回限りの検証イベントへと簡素化される。
判断が製品であり責任がアーキテクチャである組織にとって、MARIA OSアプライアンスはその両方を具体的、監査可能、かつ主権的にするためのインフラを提供する。