1. 「約束」をコード化するということ
TerraformやCloudFormationでインフラを定義する行為を、単なる「環境構築の自動化」だと捉えているなら、その認識を直ちに改める必要があります。
NWMA（次世代Web管理アーキテクチャ）において、HCL（HashiCorp Configuration Language）で記述されるのはリソースのスペックではありません。発注者との間に交わされる「責任の境界線」そのものです。
ここで言う「責任の境界線」とは、SLO/SLAとして完全に数値化され、違反時のペナルティが自動執行されることを前提とした境界です。コードの一行一行が、いかなる事態においてもその可用性を死守するという、プロフェッショナルとしての署名となります。
2. なぜ Cloud Spanner でなければならないのか
NWMAにおいて、データベースの選択は技術的好みではなく、「整合性への保険」という設計要件です。責任を負う契約を実現するためには、以下の3点を同時に満たすデータストアが不可欠です。
- 外部整合性（嘘をつかない）： 分散DBでありながら強整合性を提供し、データの不整合による「説明不能な事態」を排除する。
- マルチリージョン耐障害性： 単一リージョンの死に際しても、サービスを継続できる物理的構成を持つ。（マルチリージョン構成例：asia-northeast1 / us-central1 など）
- 運用主体の努力に依存しない一貫性： 職人芸的なチューニングや手動バックアップに頼らず、マネージドサービスとして一貫性が担保されている。
現時点で、この厳しい設計要件を同時に満たす選択肢は Cloud Spanner しか存在しません。Spannerを採用することは、ダウンタイムとデータ損失を「人間の努力」から「数学と物理」の領域へ移譲することを意味します。
3. 自動清算ロジック：データの透明性と改ざん検知
支払額に直結するメトリクス「State(S)」には、高い透明性と改ざん耐性が求められます。NWMAでは、以下の「ELTアプローチ」による自動執行をアーキテクチャに組み込みます。
- Extract & Load: [Cloud Monitoring] でSLA違反をリアルタイム検知。生のイベントデータを [Pub/Sub] 経由で [BigQuery] へ即時格納します。この際、データにはデジタル署名を付与し、改ざん不能な「生の証拠」として保護します。
- Transform: [Cloud Functions] が事前に合意された「契約数式」を適用。実行主体を分離し、すべての操作を [Cloud Audit Logs] に記録することで、計算結果の正当性を事後検証できる構造（監査証跡）を担保します。
これは冷酷さのためではありません。人間を不毛な「交渉」から守るために、判断をシステムに委譲するという高度な設計判断です。
4. 紛争を未然に防ぐ「契約のアーキテクチャ」
「未達＝自動減額」を実務で運用するには、技術の外側に法務的ガードレールが必要です。NWMAでは、以下の項目をあらかじめ契約コード（または合意文書）に変数として組み込みます。
- 観測窓（Window）の設定: 1分単位のスパイクではなく、5分平均や月間稼働率など、ビジネス価値に準じた計測期間の合意。
- 不可抗力の定義: Google Cloud 自体の広域障害や、大規模なサイバー攻撃時における免責条項の明文化。
- 裁定プロセス: 数式による決定に万が一の疑義が生じた際の、人間による最終的な確認手順。
これらは紛争が起きてから争うのではなく、すべて「事前の設計」として合意しておくべきものです。
5. まとめ：技術は「責任」のためにある
第1回で示したのは、ITインフラを「動けばいいもの」から「契約を物理的に履行する装置」へと昇華させるための基本設計です。
いきなり全額の自動清算を始める必要はありません。まずは「特定のSLO違反時の警告」や「少額のクレジット付与」といったPoC（概念実証）から開始してください。ログ設計と数値の相関を検証し、運用手順を固めた上で、本番の契約へと反映させる。
コードに責任を宿らせる。その覚悟がない限り、私たちはいつまでも「人月」という名の、責任不在の椅子取りゲームから抜け出すことはできません。設計で、不条理を殺す。実装は、ここから始まります。
