クラウド運用の経験を積んだエンジニアが、次のステップとして設計業務に進もうとする場面があります。Azureの資格制度であるAZ-104（Azure Administrator Associate、日々の運用管理を認定する資格）と、AZ-305（Azure Solutions Architect Expert、アーキテクチャ設計を認定する資格）は、しばしば「初級・上級」の関係として語られます。しかし実際には対象とする業務がまったく異なります。この違いを誤解したまま設計業務に移行すると、チームやプロジェクトに具体的な支障が出ます。
運用担当としてキャリアを積んできたエンジニア、あるいはチームの役割分担を見直したいマネージャーに向けて、この誤解がなぜ起きるのか、自分やチームがその落とし穴に該当していないかをどう確認するか、整理しました。
何が起きるか：運用スキルの延長で設計を任せてしまう
AZ-104の対象範囲は、リソースの構築・監視・インシデント対応・バックアップ運用など、既に決まった構成を安定稼働させる作業です。RBAC（Role-Based Access Control、ロールに基づくアクセス制御）の割り当てや、監視アラートの設定、パッチ適用の運用手順書作成などが該当します。
一方でAZ-305が扱うのは、ランディングゾーン（組織全体のサブスクリプション構成やガバナンスの基盤設計）、ハブスポーク型のネットワークアーキテクチャ、可用性ゾーンやDR（Disaster Recovery、災害復旧）戦略といった、システム全体の構造を決める意思決定です。
この違いを軽視すると、運用経験が豊富なエンジニアが「うまく動く構成」をそのまま設計として採用してしまう事象が起きます。たとえば、単一リージョンで安定稼働してきた実績を根拠に、コスト最適化を優先した設計を将来の拡張要件を検討せずに採用してしまうケースです。
影響範囲は決して小さくありません。ネットワークのセグメンテーション設計やIDの境界設計は、後から変更するコストが非常に高い領域です。運用中に「動いているから正しい」という判断基準で設計判断を下すと、数年後にスケールやセキュリティ要件が変わった際に、大規模な再設計を強いられます。
なぜ起きるか：タスク思考とトレードオフ思考の断絶
原因を段階的に分解すると、まず「タスクの実行」と「トレードオフの決定」という思考様式の違いが挙げられます。運用担当者は日々のタスクをこなすことで評価されます。障害復旧の速さ、インシデント件数の少なさが成功指標です。
一方で設計者は、速度と統制のバランス、コストと可用性のバランス、セキュリティと利便性のバランスといった、複数の非機能要件のトレードオフを扱います。「最良の選択肢」を選ぶのではなく、「制約条件の中で妥当な選択肢」を選び、その理由を記録する仕事です。
次に、責任範囲のスコープの違いがあります。運用担当は多くの場合、単一のサブスクリプションやプロジェクト単位で完結する作業を担当します。しかし設計者は、複数のサブスクリプション、複数の環境（開発・検証・本番）、成熟度の異なる複数チームを横断して一貫性を保つ責任を負います。
さらに評価軸のズレも原因の一つです。運用担当の成功は「同じ障害が起きても素早く直せること」で測られがちですが、設計者の成功は「同じ種類の障害がそもそも起きにくい構造を作ること」で測られます。この評価軸の違いを理解しないまま設計業務に移行すると、目先の安定運用を優先し、根本的な構造上のリスクを見逃す判断を繰り返してしまいます。
自分のプロジェクトが該当するか確認する方法
チームやプロジェクトがこの落とし穴に陥っていないか、具体的に確認する方法があります。
- 設計判断の記録があるか：アーキテクチャ上の意思決定を記録するADR（Architecture Decision Record、設計判断とその理由を残す文書）が存在するか確認します
- ネットワーク構成図に将来の拡張余地が明記されているか：ハブスポーク構成や可用性ゾーンの配置図に、拡張時の変更範囲が注記されているか見ます
- ガバナンスモデルが明文化されているか：管理グループやポリシーの割り当てルールが、担当者の記憶ではなくドキュメントとして存在するか確認します
- コスト設計とコスト削減が混同されていないか：「コストを下げる施策」と「コストが予測可能な構造」が区別されているか、設計書の記述を見直します
Azureポータル上で確認できる具体的な項目としては、Azure Policy（ポリシーベースのガバナンス機能）の割り当て状況や、Management Groups（サブスクリプションを束ねる管理階層）の構造を確認する方法があります。以下のコマンドで、現在のポリシー割り当て状況を一覧できます。
az policy assignment list --output table
az account management-group list --output tableこれらの出力に、単発のリソース単位のポリシーしか存在せず、組織全体を横断するガバナンス設計が見当たらない場合、運用視点の設定にとどまっている可能性があります。
対策の手順
落とし穴を避けるための対策を、段階を追って示します。
1. 役割の期待値を明文化する：チーム内で「運用担当が判断してよい範囲」と「設計者がレビューすべき範囲」を文書化します。RBAC割り当ての変更は運用範囲、ネットワークセグメンテーションの変更は設計レビュー必須、といった線引きです。
2. トレードオフを記録する文化を作る：新しいアーキテクチャ判断のたびに、選ばなかった選択肢とその理由を1〜2行でも残します。ADRのテンプレートを使い、コスト・可用性・セキュリティのどれを優先したかを明記します。
3. スコープを横断するレビューを設ける：単一サブスクリプション内で完結する変更であっても、複数環境への影響を確認するレビューフローを設けます。特にIDの境界設計やネットワーク接続パターンは、変更前に必ず設計担当者の確認を通します。
4. 評価指標を分離する：運用担当の評価指標（インシデント対応時間、稼働率）と、設計担当の評価指標（同種障害の再発率、再設計コストの低さ）を別々に設定します。同じ指標で両者を評価すると、設計判断が短期的な安定性に偏りがちです。
5. 資格取得を役割定義のきっかけにする：AZ-104を取得済みのメンバーが設計業務に進む際は、AZ-305のシラバスに含まれるランディングゾーン設計や可用性設計のトピックを、実際の担当領域と照らし合わせて確認します。資格勉強がそのまま設計スキルの証明にはならない点は認識しておく必要があります。
まとめ
運用と設計は、同じクラウド基盤を扱っていても評価軸も成果物も異なる仕事です。運用の実績をそのまま設計判断の根拠にすると、拡張性やセキュリティ境界の設計を軽視するリスクが生まれます。
次に取れる一歩として、まずaz policy assignment listやaz account management-group listでガバナンス設計の実態を確認してみてください。そのうえで、チーム内の設計判断がADRのような形で記録されているかを見直すと、落とし穴に該当しているかどうかの手がかりが得られます。
運用担当と設計担当の責任範囲を明文化し、トレードオフの記録を習慣化することが、後から発覚する技術的負債を減らす現実的な一歩になります。