クラウド設計ガイドラインがない組織で起きること — 環境のブレと車輪の再発明

「AWSはうまく使えているが、なんとなく環境がバラバラで、新しい案件のたびにゼロから議論している」——中堅以上の組織でよく聞く悩みです。原因はたいてい1つ、組織としてのクラウド設計ガイドラインがないこと。ガイドラインの不在が何を招き、それがあると何が変わるのかを整理します。

01ガイドラインがないと、環境は必ずブレる

ガイドラインがなければ、設計はその時々の担当者の判断に委ねられます。悪気なく、それぞれが「自分にとってのベスト」で作る。結果、命名規則がプロジェクトごとに違い、タグがバラバラで、ネットワークの切り方も各人各様、セキュリティ設定も濃淡がある——同じ会社のAWSなのに、案件ごとに別の国の言葉で書かれた環境が並ぶことになります。

ブレた環境の代償は後から効いてきます。担当者が変わると引き継げない、横断で棚卸しできない、コストの内訳がタグで追えない、監査で「なぜこの設定？」に答えられない。1つ1つは小さな不統一が、積もって運用不能を招きます。

02そして「車輪の再発明」が始まる

もっと根深いのが、車輪の再発明です。ガイドラインがないと、新しい案件のたびに「アカウントはどう分ける？」「命名どうする？」「セキュリティの基本設定は？」を、また一から議論する。前の案件で誰かが考え抜いた答えが、組織の資産として残らないから、毎回ゼロから同じ悩みを繰り返します。

03ガイドラインが定めるべきもの

• アカウント構造 — 本番／検証／ログ／セキュリティをどう分けるか（マルチアカウント統制）
• 命名規則とタグ設計 — リソース名・タグの付け方。コスト配賦と棚卸しの土台
• ネットワーク／CIDR設計 — アドレスの割当ルール。オンプレ・他VPCと重複しない設計（アドレスプラン）
• セキュリティ基線 — 全アカウント共通の必須設定（初期設定10項目）
• バックアップ・監視・運用の標準 — 世代管理、監視項目（監視10選）、通知設計

04「作って終わり」の文書にしない

ガイドラインでよくある失敗は、立派なドキュメントを作って、誰も見ない・守られないことです。生きたガイドラインにするには、次が要ります。

• 強制力を仕組みで持たせる — 文書で「こうしましょう」と書くだけでなく、IaCのテンプレートやガードレール（SCP、Config）で、逸脱を構造的に防ぐ
• 最小限から始める — 完璧な大全を目指して頓挫するより、命名・タグ・セキュリティ基線の3つだけでも先に決めて回す
• 育てる前提で作る — 現場の実態に合わない部分は改訂する。ガイドラインは一度作る石板ではなく、更新し続ける生き物

この「文書＋仕組み」の組み合わせは、マルチアカウントIaC統制の考え方そのものです。ガイドラインを紙で配るのではなく、テンプレートとして配れば、守ることが一番楽な状態を作れます。

05小さく始める組織ほど、早く作る価値がある

「うちはまだアカウントが少ないから、ガイドラインは要らない」——逆です。少ないうちに型を作るほうが、圧倒的に安い。アカウントもリソースも増えてから統一するのは、動いているものを作り直す苦行になります。最初の1〜2アカウントの作り方が、3年後の統制コストを決めます（検証環境の記事と同じ思想）。

—まとめ

組織としてのクラウド設計ガイドラインは、あってもなくても動く「あれば良いもの」ではありません。ないと環境が必ずブレ、案件ごとに車輪を再発明し、品質がばらつき、いずれ運用不能に近づく。命名・タグ・ネットワーク・セキュリティ基線を組織標準として定め、文書だけでなくIaCとガードレールで強制し、小さく始めて育てる。これは技術というより、組織の意思決定の問題です。そして意思決定を助け、それを実際に動く仕組みに落とすのが、私たちのような立場の仕事です。