NWMA
2026年、ITの価格決定権を民主化する「NWMA」宣言
本ページは、NWMA(IT資産価値管理方式)の思想と実装が最初に交差する「起点」となるドキュメントです。
すべてのNWMAにおける要件定義・設計・SLAは、最終的にここで示す「自動執行」という形に収束します。これは単なる一つの技術例ではなく、システムの主権を取り戻すためのマニフェストです。
NWMAにおいて、SLAを自動執行しない設計は未完成です。
この記事はこんな方へお届けします
- はじめての方:
インターネットサービスのルールをあらかじめプログラム化し、人間の判断を挟まずに「価格や保証」を自動実行させる、人に優しい仕組みです。 - 技術者:
SLI/SLAをコード化し、メトリクスと課金APIを直結させることで、契約を実行可能な仕様書としてデプロイする設計指針です。
Section 1:NWMAにおけるSLA自動執行の位置づけ
NWMAにおいて、SLA(サービスレベル合意)は単なる「監視指標」や「努力目標」ではありません。それは、Aシートに記された「判断理由(意志)」を、技術的に強制するための命令です。
- Aシート(要件): なぜ守るのか(意志の資産化)
- Bシート(構造): どう守るのか(構造の正本)
- Cシート(検証): 守れているか(自律的な証明)
- IaC / Automation(執行): 守れなかったらどう清算するか(数学的な誠実さ)
SLAを自動執行しない設計では、最終的なコスト負担は必ず人間に転嫁されます。それは障害対応ではなく、責任の先送りに過ぎません。SLA自動執行が存在して初めて、NWMAの思想は現実の世界を統治し始めます。
Section 2:[実装例] Google Cloud による自動執行パイプライン
本ページでは、NWMAの最初の実装例として Google Cloud を採用しています。2026年現在、メトリクス検知(Cloud Monitoring)からイベント配信(Pub/Sub)、数式実行(Cloud Functions)、請求処理(Billing API)までを最も透過的に結合できる「再現性の高い検証場」として選択した結果です。
NWMAの思想はクラウド非依存(Cloud Agnostic)であり、IT資産管理、SLA自動化、クラウドガバナンスにおけるこのロジックは、AWS や Azure においても同様に展開されるべき「設計原則」です。

Section 3:実装理論 ―― A/B/Cシートによる「一本貫通」の責任設計
NWMAにおいて、コードは単なる構築の自動化手段ではありません。それは、要件から試験までが「一本の筋」で繋がっていることを証明する「責任の執行」そのものです。
意志を構造化する「三位一体」の管理
設計の主導権を確保するために、設計・構築・検証をバラバラのフェーズとせず、以下の3要素を同時並行で定義します。
- Aシート: 10年後の自分へ向けた判断基準のメッセージ。
- Bシート: Aシートの意志をコードへ変換した、構造の正本(Terraform / Ansible)。
- Cシート: 要件が満たされているかを自動証明する、デプロイの門番。
「試験できない要件」はデプロイさせない
NWMAの統治(ガバナンス)において、Cシート(試験)によって自動検証できない要件を Aシートに記述することは、設計の放棄を意味します。曖昧な言葉を捨て、プログラムが判定可能な構造化された言葉へと翻訳します。
Section 4:アーキテクチャの統治構造(IWMA / PWMA)
NWMA自身はインフラや設定を直接操作しません。 NWMAは「判断基準」を定義し、その執行を IWMA / PWMA に委譲する最上位の設計憲法です。
- IWMA(Infrastructure Worth Management Architecture) ── 基盤(器)の設計・境界・責任を定義する。Terraform等を用い、インフラの資産価値を確立します。
- PWMA(Platform Worth Management Architecture) ── OS・ミドルウェアの設定(状態)を管理し、自律的に執行する。Ansible等を用い、構成ドリフトを根絶します。
NWMAが「なぜ守るのか(意志)」を定義し、IWMAが「器」を整え、PWMAが「状態」を維持します。
Section 5:永続化の原則 ―― なぜ再デプロイでデータが消えないのか
NWMAにおける自動執行は、闇雲な破壊ではありません。システムを「器(インフラ)」「状態(プラットフォーム)」「資産(データ)」の3層に峻別し、ライフサイクルを隔離することで、安全な自己修復を実現します。
1. 執行対象の限定と順序
異常検知時の自動執行は、以下の順序で「低コスト・低破壊」な手段から実行されます。
- 第1執行:PWMA層の再同期 設定ファイルやプロセスを正本(Bシート)から再注入し、再起動します。
- 第2執行:IWMA層の再生成 OSレベルの汚染が疑われる場合、インスタンス等の「器」を破棄し、初期状態から再構築します。
- 最終通告:保守チームへの連絡 上記で解決しない場合のみ、人間にエスカレーションします。
2. データ層の独立(永続化の分離)
データベースやストレージなどの「資産(データ)」は、デプロイ境界の外側に配置します。IaC(Bシート)において削除保護(prevent_destroy)を定義し、器が何度作り直されても接続先のエンドポイントと資産は一瞬たりとも失われないよう設計します。
データ層は、SLA自動執行・再デプロイ・自己修復の対象外とする。これはNWMAにおける絶対条件である。
Section 6:FAQ ―― 判断コストを下げるためのよくある質問と回答
A1:設計の数式化に一定の工数はかかりますが、運用後の「調整・交渉コスト」がゼロになるため、中長期的なROI(投資対効果)は極めて高くなります。
A2:可能です。
既存の課金体系を維持しつつ、NWMAによる「自動割引・クレジット適用」をアドオンとして注入する形でスモールスタートできます。
A3:柔軟性という名の「曖昧さ」は排除されます。
ただし、リカバリ手順自体をプログラム化することで、人間が介在するよりも迅速な復旧が可能となります。
A4:理論上は可能ですが、モニタリングと請求APIの密結合度において、2026年現在は Google Cloud が最もこの設計に適しています。
A5:はい。
規模に関わらず「管理コストを構造的に殺す」ことができるため、少人数で高付加価値なサービスを運営する組織にこそ推奨されます。
結論:誠実さを「設計」に委ねるという選択
言葉を尽くす誠実さから、数式を実行する誠実さへ。 NWMAを採用することは、人間を「調整」という非生産的な作業から解放し、本来の創造的な活動へ回帰させることを意味します。
NWMAにおいて、SLAを自動執行しない設計は未完成です。
理由を書き、構造を定め、守れなければ機械が執行する。 それが、システムの価値を「負債」にせず、10年後も輝き続ける「資産」として維持する唯一の方法です。
次のステップへのガイド:
思想から実装へ: 最初期の記録 NWMAの思想が、いかにして Google Cloud 上の SLA自動執行という形へ結実したのか。その思考のプロセスと、初期の連載インデックスについては以下の記事に記録されています。
👉 【連載インデックス】設計の主権を奪還せよ ―― 思考・市場・実行基盤を統合する「NWMA」の地図(Zenn)
NWMAは単体で完結する理論ではなく、
IWMA(基盤)とPWMA(状態)を統治する最上位の判断基準として機能します。
Qiita 関連記事
Zenn 関連記事
- 対象読者(インフラ/SRE/アーキテクト)/ 要件定義+SLA/SLO が主題であること 要件定義・SLA/SLOを「判断資産」として残すための設計思想を、NWMAの視点で整理します。 Section […]
- 【重要:NWMA定義のアップデートについて】 本記事は、NWMA(IT資産価値管理方式)の思想が確立される過程で書かれた「実装視点からの記録」です。 現在、NWMAは単なる自動化の手法を超え、**IW […]
- 単一のクラウドに縛られず、インフラの「型」と「中身」を論理的に分離・統制するための実践的なアプローチを解説します。 1. 導入:既存運用の不条理を断つ ARIA LUNAの視点: 「手順書通りにコマン […]
2026年、ITの価格決定権を民主化する「NWMA」宣言
本ページは、NWMA(IT資産価値管理方式)の思想と実装が最初に交差する「起点」となるドキュメントです。
すべてのNWMAにおける要件定義・設計・SLAは、最終的にここで示す「自動執行」という形に収束します。これは単なる一つの技術例ではなく、システムの主権を取り戻すためのマニフェストです。
コメントを残す コメントをキャンセル