要旨
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+ に基づくエアギャップ処理が必要です。
- 重要なインフラストラクチャ: エネルギー、水道、交通システムでは、リアルタイム ガバナンスのために 100 ミリ秒未満の意思決定遅延が必要であり、往復のクラウド呼び出しは非現実的です。
1.2 レイテンシーの議論
意思決定パイプラインの遅延は、単なるパフォーマンスの問題ではなく、ガバナンスの問題でもあります。責任ゲートが AI エージェントの提案されたアクションに人間の承認が必要かどうかを評価する必要がある場合、評価はアクション ウィンドウが閉じる前に完了する必要があります。物理世界の決定 (製造、ロボット工学、エネルギー グリッド) の場合、このウィンドウは 50 ミリ秒まで狭くなる可能性があります。
L_{\text{gate}} = L_{\text{eval}} + L_{\text{evidence}} + L_{\text{network}} \leq L_{\text{action\_window}}オンプレミス展開により $L_{\text{network}}$ (通常、クラウドまで 20 ～ 80 ミリ秒) が削減され、証拠評価とゲート ロジックにより多くの予算が残されます。 100 ミリ秒のアクション ウィンドウの場合、50 ミリ秒のネットワーク遅延を排除すると、ガバナンス評価に利用できるコンピューティング時間が 2 倍になります。
1.3 サプライチェーンのセキュリティ
AI ガバナンス プラットフォームは、組織内のあらゆる自動化された意思決定にとって重要な依存関係です。クラウド導入では、ハイパースケーラーの停止、API の廃止、価格変更、データセンターの可用性に影響を与える地政学的リスクなど、サプライ チェーンのリスクが生じます。オンプレミス展開では、これらの変動リスクを、組織の直接制御下にある固定された管理可能なインフラストラクチャに変換します。
2. アプライアンスのフォームファクターの定義
MARIA OS アプライアンスは、ラックマウント可能なユニットとして提供される、事前構成され検証されたハードウェアとソフトウェアのバンドルです。 3 つの層は、さまざまな導入規模に対応します。
| Tier | Model | Form Factor | Agent Capacity | Use Case |
| --- | --- | --- | --- | --- |
| Evaluation | M-100 | 2U rackmount | 1-10 agents | PoC, development, testing |
| Production | M-400 | 4U rackmount | 10-100 agents | Single-site production |
| Enterprise | M-900 | 8U rackmount (2x4U) | 100-500 agents | Multi-site federation primary |各層は 検証済みの構成 であり、ハードウェア、ファームウェア、OS、および MARIA OS ソフトウェアが 1 つのユニットとして一緒にテストされます。これにより、DIY オンプレミス展開を悩ませる、ハードウェアとソフトウェアの互換性の問題の組み合わせによる急増が解消されます。
アプライアンスには、MARIA OS サプライ チェーン検証システムによって暗号化署名された ハードウェア マニフェストが同梱されています。最初の起動時に、アプライアンスはマニフェストと照合して自身のハードウェアを検証し、配送中のコンポーネントの置き換えや改ざんを検出します。
3. ハードウェアリファレンス仕様
3.1 コンピューティングアーキテクチャ
# M-400 Production Tier — Hardware Specification
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.3x)、$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;
};
}クラスターは、フェイルオーバー中の意思決定損失ゼロを保証します。実行中の決定は、新しいリーダーの先行書き込みログから再生されます。同期レプリカの最大データ損失ウィンドウ (RPO) は 0 です。
6.3 マルチサイトフェデレーション (M-900)
複数の地理的場所にまたがるエンタープライズ展開では、フェデレーテッド トポロジが使用されます。各サイトは完全なローカル自律性を備えた独立した HA クラスターを実行します。フェデレーション レイヤーは、ガバナンス ポリシー、エージェント定義、集約された監査概要をサイト間で同期しますが、生の意思決定データが元のサイトから流出することはありません。
\text{Federation\_Consistency} = \frac{|P_{\text{local}} \cap P_{\text{global}}|}{|P_{\text{global}}|} \geq 0.999フェデレーション サイト間のポリシーの一貫性は、どのサイトでもポリシー更新後 30 秒以内に収束するゴシップ ベースのプロトコルを通じて 99.9% 以上に維持されます。
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すべてのサービス間通信には相互 TLS 認証が必要で、明示的に許可されたパスに制限されます。デフォルトのポリシーは deny-all です。サービスは通信を明示的に許可する必要があります。これにより、エージェントのランタイムが侵害された場合でも、ガバナンス エンジンやデータベースに直接アクセスできなくなります。
7.3 エージェントのサンドボックス化
各エージェントは、すべてのシステム コールをインターセプトする gVisor サンドボックス内で実行されます。エージェントは、ホスト ファイル システム、ネットワーク (管理されたプロキシ経由を除く)、またはその他のエージェント プロセスにアクセスできません。エージェントごとにリソース制限 (CPU、メモリ、GPU 時間) が適用され、不正な動作をするエージェントによるサービス拒否が防止されます。
8. 監視と可観測性
アプライアンスには、外部依存関係を必要としない自己完結型の可観測性スタックが含まれています。
| Layer | Tool | Purpose | Retention |
| --- | --- | --- | --- |
| Metrics | VictoriaMetrics | Time-series metrics (system + governance KPIs) | 90 days on-box |
| Logs | Loki | Structured log aggregation | 90 days hot, 1 year warm |
| Traces | Tempo | Distributed tracing (decision pipeline) | 30 days |
| Dashboards | Grafana | Visualization and alerting | N/A |
| Alerts | Alertmanager | Alert routing (email, webhook, PagerDuty) | N/A |ガバナンス固有のメトリクスは、可観測性スタックの第一級市民です。
- maria_decions_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. 適用: Blue-Green デプロイメントは、トラフィックを更新されたスタックにスワップします。以前のバージョンは引き続き即時にロールバックできます。
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 \time \lfloor V_{\text{gpu}} / M_{\text{model}} \rfloor$ を超える場合、$(k+1)$ 番目のモデル インスタンスを追加する必要があります。
- ストレージ: 決定ボリュームと線形です。各決定により、約 12 KB の監査データ (決定記録 + 証拠参照 + 移行ログ) が生成されます。 1 日あたり 1,000 件の意思決定が行われると、これは年間約 4.3 GB の監査データに蓄積されます。
- RAM: サブリニア。エージェント コンテキスト ウィンドウは、共通の埋め込みキャッシュを共有します。キャッシュ共有により、メモリは $O(N^{0.7})$ として拡張されます。
11.2 サイズ表
| Agents | Decisions/Day | Tier | GPU | CPU Cores | RAM (GB) | Hot Storage (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. クラウドとオンプレミス: 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 分/年) を達成します。
For deployments exceeding 50 agents with regulatory compliance requirements, the on-premise appliance reaches TCO parity with cloud deployment at approximately 18 months. By month 36, the cumulative cost advantage reaches 37%, primarily driven by eliminated egress fees and compliance overhead.12.3 意思決定主権プレミアム
オンプレミス展開はコストを超えて、クラウドに直接相当するものがない意思決定主権プレミアムを提供します。これは、意思決定データ、責任の割り当て、またはガバナンス評価が組織の物理的および法的管理の外にあるインフラストラクチャを通過したことがないという数学的保証です。データ侵害が存続に関わる業界（防衛請負業者、重要インフラ運営者、生命に関わる意思決定を扱う医療システムなど）にとって、この保証は機能ではありません。それは要件です。
結論
MARIA OS アプライアンス リファレンス アーキテクチャは、オンプレミス AI ガバナンスが妥協ではなく、規制対象企業の長期コストを削減しながらガバナンスの保証を強化する設計上の選択であることを示しています。このアーキテクチャは、責任の保存、フェールクローズされたデフォルト、不変の監査証跡、段階的な自律性など、あらゆる MARIA OS の不変条件を、自己完結型で検証済みのアップグレード可能なフォーム ファクターで保持します。
重要な洞察は、ガバナンスの地域性がガバナンスを強化するということです。意思決定パイプライン、ガバナンス エンジン、および監査システムが組織の直接の物理的制御下のインフラストラクチャ上で実行されると、攻撃対象領域が縮小し、レイテンシ バジェットが拡大し、法規制への準拠が継続的な検証の問題から 1 回限りの検証イベントに簡素化されます。
MARIA OS アプライアンスは、判断が製品であり、責任がアーキテクチャである組織に、その両方を具体的、監査可能、主権的なものにするためのインフラストラクチャを提供します。