Platform 骨格の設計

最優先は platform-as-product としての software scope を定義することである。作るべきものは単なる内部基盤ではなく、複数の product / partner team が使う internal platform である。良い platform は self-service API、 portal、 project template、 golden path を通じて利用者の cognitive load を減らし、 security と governance を default 化する。 application API、 UI concept、 BI dashboard、 automation engine などは個別機能として見るのではなく、「platform の user experience と policy surface」として再編成して考えるべきである。

Tenant / Identity / Resource 階層

次に固定すべきは tenant / resource / identity の体系である。次のような階層を最初に決め、それぞれに ownership と policy 適用点を定義する。

/org → /account → /project → /site → /cluster → /node → /workload → /data domain

multi-account 環境では central policy と visibility を保つための単一 organization が security boundary になる。 identity は secure かつ compliant な public cloud architecture の foundation であり、 governance は別 layer ではなく automated guardrail と compliance audit を成立させる基盤である。

具体的に言えば、分散認証、計算資源 allocation、仮想化、暗号、秘密分散、通信暗号化、規制対応状況、 dashboard などの多くがこの階層の上に乗る。階層が後から変わると、 quota、 billing、 audit、 access control 全部の再設計が必要になり、 cost が高い。

Control Plane と Data Plane の分離

「AWS-like な digital infrastructure」を作るなら、 control plane と data plane の分離 は早期に明文化すべき最上位原則である。

• Control plane: administrative API、 policy 伝播、 lifecycle 管理を担う。可用性は重要だが、 latency は data plane より緩い。
• Data plane: 実際の work (inference、 storage I/O、 networking) を担う。 control plane 障害時にも既存 state を保って動き続けるのが望ましい。

edge を含む分散基盤では、この原則はさらに重要である。 local site は中央管理との接続喪失時にも survivability を持たねばならない。地理分散、 reserved capacity、 staggered maintenance window、 local control plane の扱いも、 software architecture 側で前提化しておく必要がある。

設計上のチェックポイント:

• control plane が落ちても、 既存の workload は継続実行できるか?
• 新規 workload の admission は中央が落ちても local で受けられるか?
• audit log は中央復旧後に reconcile できるか?
• policy update が中央切断中に反映できなくても、最後の policy state で safely fallback するか?

非機能要求を Measurement System に変える

非機能要求は 「願望」ではなく「measurement system」 に変えるべきである。 cloud architecture の主要 guidance は、非機能 focus area を security、 reliability、 performance、 cost、 operations、 sustainability の 6 pillar として整理している。

• Reliability は SLO / SLI で定義する。 100% を目指すのではなく error budget を使って release 判断に接続する
• Performance は p50 / p95 / p99 latency と throughput で測る (平均値だけでは隠れる failure mode が多い)
• Cost は workload 単位の attribution と amortization 期間で見る
• Delivery 側 は DORA 5 指標 (deployment frequency、 lead time for changes、 change failure rate、 time to restore、 reliability) で測る

こうして初めて「required quality」が主観ではなく operating system になる。「reliability is important」のような形容詞ベースの要件は実装に降りないが、「99.9% monthly availability、 error budget 43 分 / 月、 burn rate 4x で release freeze」は実装に降りる。

Security と AI 固有の論点

security と compliance は、後付けの review 項目ではなく build path の一部 に入れる。 threat modeling は分解、脅威特定と優先度付け、 mitigation、 review / validation の 4 段階。 zero trust は network perimeter ではなく user、 asset、 resource を保護対象 にする。 secure development practice は SDLC に統合され、 software supply chain には tamper 防止と integrity 向上の枠組みが必要である。

microservices を採るなら、 auth、 service discovery、 secure communication、 monitoring、 circuit breaker、 throttling まで含めて考え、 service mesh で abstraction するのが整っている。 telemetry は vendor-neutral な基盤 (OpenTelemetry が現実的な基準) を最初に決めておくのが後戻りを減らす。

AI 専用の論点では、 inference workload を CPU-centric な一般論で扱わないことが重要である。 GPU workload には device plugin と GPU-aware scheduling が必要で、 inference autoscaling は request count より適切な runtime metric (queue depth、 batch fill rate、 GPU memory pressure 等) を選んで cost と performance を合わせ込む必要がある。

MCP (Model Context Protocol) の扱い: 有望だが、現行 spec 自体が arbitrary data access と code execution の力を持つため、 user consent、 tool safety、 data privacy を強く要求している。 roadmap でも governance maturation と enterprise readiness はまだ主要課題として扱われており、現時点では MCP を platform core の trusted bus にするより、「adapter boundary」として局所採用するほうが安全である。 ecosystem としては重要だが、 core dependency にすると enterprise 要件で詰まる可能性がある。