システム設計 3点セット
システム設計 3点セット
― なぜこの設計なのかを説明できる設計者になる ―
従来の「説明用ドキュメント」から、運用のための「構成定義」へ
かつて、設計者の主な役割は「設計の根拠を説明し、合意を得ること」に重点が置かれていました。しかし、2026年現在の NWMA（Net Worth Management Architecture） において、その役割は大きく進化しています。
設計者の真のミッションは、「定義したSLA（サービスレベル合意）を、システムが自律的に維持・管理できる構造を構築すること」にあります。
刷新された「システム設計 3点セット」は、Google Cloud をはじめとする現代のクラウドネイティブ環境に最適化された論理構造を構築するための、「システム構成の最高基準（Golden Standard）」として機能します。
⚠ ご利用前の確認事項
本テンプレートは、単なる「構築手順書（マニュアル）」ではありません。
設計判断の根拠を論理的に構造化し、デザインレビュー、保守・運用の引き継ぎ、およびステークホルダーへの説明品質を向上させるための、設計者・レビュアー向け「アーキテクチャ定義フレームワーク」です。
専門的な設計スキルを標準化する、3つのアーキテクチャ・アセット
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 およびクラウドプラットフォーム側のガード（削除保護設定）によって設計通りに遮断されるかを確認します。
【NWMA 2026版】更新のポイント
| 項目 | 旧バージョン（2025以前） | 新バージョン（NWMA 2026） |
| 主眼 | 関係者への説明・レビューの通過 | システムによる設計ポリシーの自動維持 |
| A-No の定義 | 設計判断の参照番号 | ポリシー・タグ・監視を紐付ける共通キー |
| リソースの定義 | 構築対象となる物理/論理リソース | 再生成可能な「計算資源」と保護すべき「永続資産」 |
| 検証の目的 | 正常動作（疎通・機能）の確認 | 耐障害性およびデータ保護機能の有効性実証 |
更新履歴（Changelog）
- 2026-02-16: 表現の標準化と専門用語の統合:
- ドキュメント全体のトーンをITエンジニアの実務に適したプロフェッショナルな表現へ刷新。
- 「聖域」を「永続資産（Asset）」、「器」を「計算資源（Vessel）」、「執行」を「設計ポリシーの自動維持・適用」へ、それぞれ工学的な定義に基づき改訂。
- 2026-01-11:
- 「NWMA 2026」仕様へアップデート。
- タイトルを「システム設計 3点セット」へ変更し、Google Cloud 環境における「ポリシーの自動維持」と「データ資産保護」の概念を統合。
- 2025-12-14:
- 「ネットワーク設計 3点セット」初版公開。
【DL専用エリア】
設計ポリシー（A-No）をインフラ構成へ反映する実務テンプレート一式
下記のフォームに必要事項をご記入ください。「送信」ボタンを押すと、ダウンロードリンクが表示されます。
※ご登録いただいたメールアドレスは、本資料の送付および関連情報の提供にのみ利用いたします。
過度な頻度の配信は行わず、メール内のリンクからいつでも配信停止の手続きが可能です。
SLOを自律的に維持し、永続資産を保護する
コメントを残す