1．アカウントやサブスクリプションの構成が整理されていない

　サウバー氏は、サブスクリプションが整理されておらず、リソースグループにも明確な構造がないAzure環境を見ることがあるという。1つのサブスクリプションにさまざまなWebアプリケーションがまとめてひも付いている「全部入りサブスクリプション」も見かけるという。

　全部入りサブスクリプションについてサウバー氏は、「最低限、開発環境と本番環境単位でサブスクリプションを分けるべきだ」と提言する。さらに、大企業であれば「チームと環境」単位で、リソースグループは必ず「アプリケーションと環境単位で作成すべきだ」と薦めている。

　具体的には、あるアプリケーションに必要なデータベース、Webサーバなどのリソースは、必ず同一のリソースグループにまとめるとよい。同氏によると、Microsoftは2025年「Service Groups」を公開した。これはタグを進化させたようなもので、「本番アプリ群」や「GDPR対象アプリ群」などを論理的にまとめることができる。

2．リソースの命名規則がバラバラ

　2つ目は命名規則だ。サウバー氏は、「Azureのリソースの名前付けに自信がある人は、実はあまり多くない。多くの環境では、リソース名がバラバラだ」と指摘する。

　対策は極めてシンプルで、命名規則を決めることに尽きる。Microsoftは推奨される命名規則を公開しており、リソース種別の略称、アプリケーション名、環境名、インスタンス番号を組み合わせる形が基本だ。Azureには「Azure Naming Tool」という専用ツールもある。重要なのは、どのルールを選ぶかではなく、「全チームが一貫したルールを使うこと」だ。この点もAzure Policyを使えば、技術的に強制できる。

3．タグの設計が不十分

　タグはリソースのメタデータであり、「本番環境の月額コストはいくらか」「このリソースの責任者は誰か」といった問いに答えるための重要な手掛かりとなる。しかし、タグが統一されていない企業は少なくないとサウバー氏は指摘する。

　そこで、環境名、オーナー、事業部など、必要なタグを標準化することが重要だ。タグの内容自体は組織ごとに自由に決めてよいが、「付けるかどうか」を人に委ねてはいけない。

4．Azure Policyを使っていない

　「命名規則やタグのルール、暗号化プロトコル「TLS」（Transport Layer Security）の要件などをドキュメントにまとめても、それが守られるかどうかは別問題だ」とサウバー氏は指摘する。そこでサウバー氏は、リソースを組織のポリシーに沿って管理するための仕組みであるAzure Policyの利用を薦める。Azure Policyを使えば、リソース作成の拒否、監査、設定の強制といった制御が可能になる。ただし、Infrastructure as Code（IaC）を採用している場合、自動修正（Modify）はコードとの差分を生む可能性があるため注意が必要だ。

5．認証プロセスに課題がある

　サウバー氏によると、ユーザー名、パスワード、クライアントシークレット（アプリケーションがMicrosoft Entra IDにアクセスするための認証情報）を使ってリソースにアクセスしている企業が見受けられる。これは、情報漏えいや管理コストの温床になりやすい。

　AzureのManaged Identity（Managed ID）を使えば、クライアントシークレットを使わない認証が可能になり、IDの管理はAzure側に委ねられる。パスワードもクライアントシークレットも不要になり、接続文字列にはURLだけが残る。結果として、認証は完全にパスワードレスになる。

6．DefaultAzureCredentialを理解せずに使っている

　一方で注意が必要なのが、DefaultAzureCredential（Azure SDKを使用してアプリケーションを開発する際に、環境に合わせて自動で認証方法を切り替えるライブラリ）の使い方だ。DefaultAzureCredentialは便利な仕組みだが、内部で複数の認証方式を順番に試すため、状況によっては接続に数秒かかることがある。本番環境では、明示的に認証方式を指定する設計が望ましい。

7．TLS 1.2以上を必須にしていない

　Azureの各種サービスは、セキュリティ強化のためTLS 1.2以上を使用することを要件としている。可能であればTLS 1.3の採用も検討すべきだとサウバー氏は指摘する。

8．CI/CDでクライアントシークレットを使った認証を続けている

　CI/CD（継続的インテグレーション/継続的デリバリー）では、クライアントシークレットに依存しないフェデレーションIDの活用が推奨される。有効期限を数分～1時間程度と短く設定された短命トークンによる認証が可能となり、GitHub Actionsなどと組み合わせることで、より安全なデプロイパイプラインを構築できる。

9．コストアラートを設定していない

　サウバー氏によると、Azureにはデフォルトで「使い過ぎを止める仕組み」は存在しない。そのため「Azure Budgets」や「Cost Alerts」などの機能を使い、閾値アラートや異常検知を設定することが重要だ。ただし、あくまで「監視」を目的としており、リソースを自動停止するものではない点には注意したい。

10．オンデマンド課金のまま長期利用している

　長期間稼働が前提のリソースをオンデマンド課金で使い続けるのは、意図せず高いコストを払い続ける行為に等しい。サウバー氏は、「本来削減できる20～70％のコストを取り逃している」と指摘する。年単位のリソースの利用を約束することで利用料金の割引を受けるAzure ReservationsやAzureの節約プランを利用できるAzure Savings Plan for Computeを活用すれば、20～70％程度のコスト削減が見込めるという。サウバー氏は、「特にAzure Savings Plan for Computeは柔軟性が高く、多くの組織で検討に値する」と強調する。

おわりに

　これら10の失敗は、Azureの機能不足が原因ではない。多くは、初期設計の曖昧さと、標準を強制する仕組みの欠如から生まれている。1つでも思い当たる点があれば、そこが改善の出発点になる。Azure環境は、放置すれば自然に複雑化する。だからこそ、意識的に「失敗を避ける設計」を取り入れることが、長期的な安定運用への近道となる。