1. A-Sheets（要件定義）：設計ポリシーと要件識別子（A-No）

サービスレベルおよび管理基準を「設計ポリシー」として定義する

A-Sheets の役割は、ビジネス要件を「A-No」という一意のポリシーID（要件識別子）へ変換し、構造化することです。

• リソースの種別定義: 「永続資産（Asset）：保護すべきデータ層」と「計算資源（Vessel）：再生成可能なインフラ層」を明確に分離して定義します。
• SLO（サービスレベル目標）の策定: 「目標復旧時間（RTO）30分以内」といった要件を、システムが継続的に計測・維持すべき具体的な指標（SLI）と目標（SLO）へ展開します。
  • 例：正常レスポンス（HTTP 20x）率、P95レイテンシ、DB接続成功率など
• 実装・運用とのトレーサビリティ: 本シートで定義された A-No は、Terraform のタグ、リソース名、および監視ポリシーの名称として一貫して使用され、実装・テストと完全に同期します。

2. B-Sheets（論理・構成設計）：アーキテクチャの具現化

「計算資源」と「データ資産」を分離し、IaCへ統合する

B-Sheets は、A-Sheets で策定された設計ポリシーを具体的なパラメータへ落とし込む「構成定義書」です。Google Cloud における VPC、サブネット、IAM、および Terraform のライフサイクル設定等を記述します。

• 計算資源（Vessel）のステートレス化: VM やコンテナを再生成可能なリソースとして扱い、障害時やアップデート時にいつでも安全に破棄・再構築できる構成を定義します。
• データの多層保護: 永続資産（DB等）に対して、IaC（Terraform）レベルの prevent_destroy 設定と、クラウドプロバイダー側の削除保護（Deletion Protection）を二重に定義します。
• 管理情報の整合性維持: 構成の正本となる Terraform State 自体も、改ざんや削除から保護すべき重要な資産として管理対象に含めます。

3. C-Sheets（検証・試験）：設計ポリシーの妥当性証明

「要件通りの保護と復旧」が機能することを実証する

従来の試験が主に「正常な疎通」を確認するものであったのに対し、NWMA における C-Sheets は、「定義した設計ポリシーが技術的に有効に機能していること」を客観的に実証します。

• 復旧プロトコルの動作検証: インフラリソースに対して意図的に障害（ノード停止等）を発生させ、A-Sheets で定義したポリシー（A-No）に基づき自動復旧フローが正しく起動するかを検証します。
  • 例：MIG（マネージドインスタンスグループ）のオートヒーリング、GKE の再スケジューリング動作の確認など
• 資産保護機能の有効性試験: 永続資産（Asset）に対する誤操作や不正な削除リクエストが、IaC およびクラウドプラットフォーム側のガード（削除保護設定）によって設計通りに遮断されるかを確認します。