カスタムドメイン/SSL、自動スケール、デプロイメントスロットを備えた運用Webアプリ用のApp Serviceプランが必要です。
Standard (S1) App Serviceプラン層以上を使用します。
理由: Standardは、カスタムドメインとSSL、自動スケール、デプロイメントスロットといったすべての主要な運用機能をサポートする最低限の層です。Basic層には自動スケールとスロットがありません。
CertLabProMicrosoft Azure Developer Associate
最終確認：2026年5月
AZ-204 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
カスタムドメイン/SSL、自動スケール、デプロイメントスロットを備えた運用Webアプリ用のApp Serviceプランが必要です。
Standard (S1) App Serviceプラン層以上を使用します。
理由: Standardは、カスタムドメインとSSL、自動スケール、デプロイメントスロットといったすべての主要な運用機能をサポートする最低限の層です。Basic層には自動スケールとスロットがありません。
App Serviceのゼロダウンタイムデプロイを実行し、運用設定（接続文字列など）を運用スロットに維持します。
デプロイメントスロットを使用します。運用環境固有の設定を「デプロイメントスロット設定」（スティッキー）としてマークします。スワップ操作を実行してデプロイします。
理由: スワップ操作は、トラフィックをリダイレクトする前にステージングスロットをウォームアップします。スティッキー設定はスワップ中にコードと一緒に移動しないため、ステージング設定が本番環境に適用されるのを防ぎます。
App ServiceがVPNやExpressRouteなしでオンプレミスリソース（例：SQL Server）に接続する必要があります。
App Service Hybrid Connectionsを使用します。オンプレミスにHybrid Connection Manager (HCM)をインストールします。
理由: Hybrid Connectionsは、受信ファイアウォールポート、VPN、またはVNet統合を必要とせずに、オンプレミスリソースへの安全なTCPトンネルを提供します。HCMがアウトバウンド接続を開始します。
ConsumptionプランのAzure Functionでコールドスタートが長く、レイテンシーが発生しています。
Functions Premiumプランに移行し、少なくとも1つのウォームアップ済みインスタンスを構成します。
理由: Premiumプランは、指定された数のインスタンスを常に準備状態に保つことで、コールドスタートを排除します。この目的のために、完全なDedicatedプランよりも費用対効果が高くなります。
ConsumptionプランのAzure Functionが、実行に10分以上かかるためタイムアウトしています。
そのFunctionをPremiumまたはDedicated (App Service)プランに移行します。
理由: Consumptionプランの最大タイムアウトは10分です。PremiumおよびDedicatedプランは、より長い実行時間（最大60分または無制限）をサポートします。
多数の独立したアイテムを並行して処理し、すべてが完了するまで待機してから先に進みます。
Durable FunctionsのFan-out/Fan-inパターンを実装します。オーケストレーターは複数のアクティビティ関数を同時に呼び出し、`Task.WhenAll`（または同等のもの）を使用して完了を待ちます。
理由: このパターンは並行実行のために設計されており、独立したタスクのシーケンシャル処理（Function Chaining）よりもはるかに効率的です。
長時間実行されるワークフローが、タイムアウトを伴う人間による承認などの外部イベントを待機する必要があります。
Durable Functions Human Interactionパターンを使用します。`waitForExternalEvent`と`createTimer`を組み合わせます。イベントが発生するかタイマーが期限切れになったときに処理を進めるために`Task.WhenAny`を使用します。
理由: このパターンにより、オーケストレーションはコンピューティングを消費することなく外部トリガーを無期限に待機し、タイムアウトも適切に処理できます。
コンテナ化されたアプリケーションが、トラフィックがないときにコストを最小限に抑えるために、ゼロインスタンスにスケールアウトする必要があります。
KEDAベースのスケールルール（例：HTTPリクエストまたはキューの長さ）を使用してAzure Container Appsを使用します。
理由: KEDAスケーラーを備えたContainer Appsは、アイドル時にゼロレプリカにスケールダウンし、オンデマンドでスケールアップできるため、イベント駆動型または断続的なワークロードに最適です。CPU/メモリのスケーリングではゼロにはスケールできません。
Azure Container Appsのバックエンドマイクロサービスは、同じ環境内の他のContainer Appsからのみアクセス可能である必要があり、パブリックインターネットからはアクセスできません。
バックエンドContainer Appでイングレスを有効にし、トラフィックの可視性を`internal`に設定します。
理由: 内部イングレスはContainer Apps環境へのアクセスを制限します。環境内の他のアプリは、内部FQDNを使用してサービスを検出し、呼び出すことができます。
オーケストレーションなしで、単純なタスク、テスト、またはバッチジョブのために単一のコンテナを実行する必要があります。
Azure Container Instances (ACI)を使用します。
理由: ACIは、基盤となるインフラストラクチャを管理することなく、単一のコンテナを実行する最も速く簡単な方法です。複数のコンテナアプリケーションをオーケストレーションするには、Container AppsまたはAKSを使用します。
ローカルのDockerfileからAzure Container Registry (ACR)にDockerイメージをビルドしてプッシュする必要がありますが、Dockerがローカルにインストールされていません。
`az acr build`コマンドを使用します。
理由: `az acr build`は、ビルドプロセスをクラウドのACR Tasksにオフロードします。ビルドコンテキストをAzureに送信し、イメージをビルドして、レジストリに直接保存します。
特定のプロパティ（例：`region`）で頻繁にフィルターされるクエリを持つCosmos DBコンテナを設計しています。
最も頻繁にクエリされ、カーディナリティの高いプロパティをパーティションキーとして選択します（例：`/region`）。
理由: `WHERE`句にパーティションキーを含むクエリは、単一の論理パーティションをターゲットとするため、コストのかかるクロスパーティションのファンアウトクエリを回避し、RU消費を最小限に抑えます。
グローバルに分散されたアプリケーションで、読み取りが常に最も最近コミットされた書き込みを返す必要があります。
Cosmos DBアカウントの整合性レベルをStrongに設定します。
理由: Strong整合性は線形化可能性を保証し、読み取りが常に最新であることを保証します。他のレベル（Session、Bounded Staleness、Eventual）は、整合性と引き換えに低レイテンシーと高可用性を提供します。
マテリアライズドビューを更新するために、Cosmos DBコンテナ内のすべての新規または更新されたドキュメントをリアルタイムで処理する必要があります。
変更フィードプロセッサを利用するCosmos DBトリガー付きAzure Functionを使用します。
理由: 変更フィードは、変更の永続的なログを提供します。変更フィードプロセッサを備えたCosmos DBトリガーは、複数のFunctionインスタンスにわたる状態管理と負荷分散を自動化します。
同じ論理パーティション内の複数のドキュメントに対してアトミック操作（例：2つ作成して1つ更新）を実行する必要があります。
Cosmos DB SDKの`TransactionalBatch` APIを使用します。すべての操作は同じパーティションキーをターゲットにする必要があります。
理由: TransactionalBatchは、バッチ内のすべての操作が単一のアトミック単位として成功または失敗することを保証し、部分的な更新を防ぎます。クライアント側のバッチ操作では、ストアドプロシージャよりも効率的です。
Cosmos DBのワークロードが予測不能で、トラフィックに大きなピークと谷があります。
データベースまたはコンテナで自動スケールプロビジョニングスループットを構成します。
理由: 自動スケールは、使用量に基づいてRU/sを自動的にスケーリングし、ピーク時のパフォーマンスと谷間のコスト削減を保証します。設定された最大RU/sの10%から100%の間でスケーリングします。
データは最初は頻繁にアクセスされ、その後アクセス頻度が低下し、最終的に長期保存のためにアーカイブされます。
Hot、Cool、Archiveのアクセス層を組み合わせて使用します。ライフサイクル管理ポリシーを使用して移行を自動化します。
理由: アクセス層をアクセスパターンに合わせることでコストを最適化します。Hotは頻繁なアクセス、Coolはまれなアクセス、Archiveは長期の低コストストレージ用です。ライフサイクルポリシーがこれを自動化します。
複数のプロセスが同時に同じBlobを変更するのを防ぎます。
Blobリースを実装します。プロセスは、Blobを変更する前に、排他書き込みロック（リース）を取得します。
理由: リースは悲観的同時実行制御を提供します。リースが取得されると、リリースされるか期限切れになるまで、他のクライアントはそのBlobに書き込むことができません。
Blob Storageに監査ログを保存し、固定された保持期間（例：7年間）中に変更または削除できないようにします。
Blobコンテナに時間ベースの保持ポリシーを構成します。無期限の保持には、法的ホールドを使用します。
理由: 不変ストレージポリシーはWORM（Write-Once, Read-Many）状態を強制し、これはコンプライアンスに不可欠です。一度ロックされると、時間ベースのポリシーは短縮できません。
キーと値の属性でBlobを分類し、すべてのBlobをリストすることなくストレージアカウント全体でクエリする必要があります。
Blobインデックスタグを使用します。
理由: インデックスタグはストレージサービスによってインデックス化され、サーバー側のフィルタークエリ（`Find Blobs by Tags`）で使用できます。メタデータはインデックス化されず、リスト後クライアント側でのみフィルターできます。
Single-Page Application (SPA)でユーザーを安全に認証し、バックエンドAPI用のトークンを取得します。
PKCE (Proof Key for Code Exchange) を使用したAuthorization Codeフローを使用します。
理由: これはパブリッククライアントに対する現在のセキュリティのベストプラクティスです。URLにトークンを公開するのを避け（非推奨のImplicitフローとは異なり）、クライアントシークレットを必要としません。
バックグラウンドサービスまたはデーモンが、サインインユーザーなしで保護されたAPI（Microsoft Graphなど）を呼び出す必要があります。
アプリケーション権限付きのClient Credentialsフローを使用します。
理由: このフローは、クライアントシークレットまたは証明書を使用してアプリケーション自体を認証します。アプリケーション権限は、管理者の同意を条件として、組織全体にアクセスを許可します。
ミドルティアのWeb APIが、元のサインインユーザーのIDを保持したままダウンストリームAPIを呼び出す必要があります。
On-Behalf-Of (OBO) フローを実装します。
理由: ミドルティアAPIは、ユーザーのアクセストークンをダウンストリームAPIにスコープされた新しいトークンと交換します。これにより、ユーザーのIDが安全に委任されます。
MSALを使用するアプリケーションが、ユーザープロンプトを最小限に抑えながら効率的にトークンを取得する必要があります。
常に最初に`AcquireTokenSilent()`を呼び出します。`MsalUiRequiredException`で失敗した場合は、`AcquireTokenInteractive()`などのインタラクティブなメソッドにフォールバックします。
理由: `AcquireTokenSilent()`は、キャッシュで有効なトークンをチェックするか、ユーザー操作なしで新しいトークンを取得するためにリフレッシュトークンを使用します。これは良好なユーザーエクスペリエンスのために不可欠です。
Azureリソース（例：App Service、Function）が、コードや設定に資格情報を保存せずに、別のAzureリソース（例：Key Vault、SQL Database）にアクセスする必要があります。
ソースリソースでマネージドID（システム割り当てまたはユーザー割り当て）を有効にし、ターゲットリソースに対してRBAC権限を付与します。
理由: マネージドIDは、リソースに対してMicrosoft Entra IDのIDを提供します。Azureが資格情報のライフサイクルを管理するため、開発者がシークレットを処理する必要がなくなります。
複数のAzureリソースが、他のサービスにアクセスするために同じIDと権限を共有する必要があります。
単一のユーザー割り当てマネージドIDを作成し、必要なすべてのリソースに割り当てます。
理由: ユーザー割り当てIDは、任意のリソースから独立したライフサイクルを持つため、再利用可能です。システム割り当てIDは単一のリソースに紐付けられ、そのリソースが削除されると削除されます。
Azure ADグループを使用して、個々のシークレットレベルで細分化された権限を持つKey Vaultシークレットへのアクセスを許可する必要があります。
Key VaultにAzure RBAC権限モデルを使用します。`Key Vault Secrets User`のようなロールをプリンシパルに割り当てます。
理由: RBACは、Vaultまたは個々のキー/シークレット/証明書スコープでのロール割り当てを可能にし、Vault内の特定の種類のすべてのオブジェクトに適用されるアクセス ポリシーよりもきめ細かい粒度を提供します。
アプリケーションが再起動せずにAzure App Configurationからの構成変更を反映する必要があります。
App Configurationプロバイダー/SDKを使用し、センチネルキーを監視して更新するように構成します。
理由: SDKはセンチネルキーの変更を定期的にチェックできます。アプリケーション設定を更新するときにセンチネルキーも更新すると、すべてのクライアントが構成を更新するきっかけになります。
特定のユーザーグループ（例：ベータテスター）と一般ユーザーの一定割合に対して新機能を有効にする必要があります。
Targetingフィルターを備えたAzure App Configurationの機能フラグを使用します。
理由: Targetingフィルターは複雑なロールアウトをサポートしており、特定の割合のユーザーとグループに基づいてオーディエンスを定義できるほか、その他のすべてのユーザーに対するデフォルトのロールアウト割合も定義できます。
クライアントに特定のBlobへのアクセスを許可するために、安全な短命のトークンを生成する必要があります。
ユーザー委任SASを作成します。
理由: ユーザー委任SASは、ストレージアカウントキーではなくMicrosoft Entra IDの資格情報で署名されます。これにより、アカウントキーの配布を避け、Entra IDポリシーを通じてアクセスを取り消せるため、より安全です。
マイクロサービスアプリケーションのパフォーマンス問題をトラブルシューティングするために、依存関係を視覚化し、どのダウンストリームサービスが高いレイテンシーの原因となっているかを特定します。
Application InsightsのApplication Map機能を使用します。
理由: Application Mapは、分散アプリケーションのトポロジービューを自動的に検出し表示し、各コンポーネントの健全性とパフォーマンスメトリック、およびそれらの間の呼び出しを示します。
単一のユーザーリクエストが複数のマイクロサービスを流れる際に追跡します。
Application InsightsのEnd-to-Endトランザクション詳細ビューを使用します。すべてのテレメトリは共有の`operation_Id`によって関連付けられます。
理由: Application Insights SDKはW3C Trace Contextヘッダーを自動的に伝播するため、単一の操作のすべてのテレメトリが同じ`operation_Id`と関連付けられ、統合されたビューが可能になります。
運用上の問題を診断します：断続的なパフォーマンス低下と断続的な例外。
パフォーマンス低下にはApplication Insights Profilerを使用します。例外にはSnapshot Debuggerを使用します。
理由: Profilerは、低速なリクエスト（「ホットパス」）のメソッドレベルのタイミングトレースをキャプチャします。Snapshot Debuggerは、例外がスローされた瞬間のコールスタックとローカル変数をキャプチャします。
高トラフィックアプリケーションからのApplication Insightsのデータ量とコストを削減しつつ、統計的に有効なデータを維持します。
アプリケーションのSDK構成で適応サンプリングを有効にします。
理由: 適応サンプリングは、目標のデータ量内に収まるようにサンプリングレートを自動的に調整し、高トラフィック時にはより積極的に、低トラフィック時には控えめにサンプリングすることで、重要なテレメトリを保持します。
複数の地理的な場所からWebアプリケーションエンドポイントの可用性を継続的に監視します。
Application Insightsで標準の可用性テスト（URLpingテスト）を構成します。
理由: 可用性テストは、世界中のAzureデータセンターからエンドポイントにリクエストを送信し、稼働時間と応答性のプロアクティブな監視を提供し、障害発生時にアラートをトリガーします。
パフォーマンスメトリック（例：平均応答時間）が、定義された期間に特定のしきい値を超えたときに発生するアラートを作成します。
Azure Monitorメトリックアラートルールを作成します。リソースとメトリックをターゲットにし、静的しきい値、集計タイプ、評価期間を構成します。アクショングループにリンクします。
理由: メトリックアラートは、低レイテンシーでステートフルな、ほぼリアルタイムのメトリックデータの監視を提供し、パフォーマンスベースのアラートに最適です。
呼び出し頻度（例：1分あたり100回）と、より長い期間（例：1ヶ月あたり10,000回）の合計呼び出し数でAPI使用量を制御します。
呼び出し頻度には`rate-limit`ポリシーを使用します。合計呼び出し量には`quota`ポリシーを使用します。
理由: `rate-limit`は短期間のバーストをスロットルし、HTTP 429を返します。`quota`は長期（例：請求期間）にわたる使用上限を強制し、超過するとHTTP 403を返します。
API ManagementでAPI応答をキャッシュしてバックエンドの負荷を軽減し、キャッシュキーがリクエストヘッダーによって変化するようにします。
インバウンドセクションで`<cache-lookup vary-by-header="..." />`ポリシーを、アウトバウンドセクションで`<cache-store duration="..." />`ポリシーを使用します。
理由: この2部構成のポリシーの組み合わせにより、応答キャッシュが有効になります。`cache-lookup`はキャッシュされたアイテムをチェックし、`cache-store`は応答を保存します。`vary-by`属性は、異なるリクエストバリエーションに対して一意のキャッシュエントリを保証します。
APIへの変更を管理します。破壊的な変更が必要な場合と、破壊的でない変更をテストする必要がある場合。
破壊的な変更にはバージョン（例：/v1、/v2）を使用します。破壊的でない変更や安全な段階的ロールアウトにはリビジョンを使用します。
理由: バージョン管理により、複数のAPIバージョンを同時に稼働させることができます。リビジョンを使用すると、APIをオフラインで変更、テストし、ダウンタイムなしで「現在の」リビジョンにすることができます。
Azureサービスでイベント（例：Blobが作成された、リソースグループが作成された）が発生したときに、複数の独立したダウンストリームサービスに通知します。
Azure Event Gridを使用します。Azureリソースのシステムトピックと、各ダウンストリームハンドラーのイベントサブスクリプションを作成します。
理由: Event Gridは、イベント発行者と購読者を分離するフルマネージドのプッシュベースのpub/subサービスであり、リアクティブなイベント駆動型アーキテクチャを可能にします。
多数のデバイスから、大量のテレメトリまたはイベントデータ（毎秒数百万イベント）をストリーミングで取り込みます。
Azure Event Hubsを使用します。
理由: Event Hubsは、高スループットの取り込みのために設計された、大規模にスケーラブルなデータストリーミングプラットフォームです。並列処理のためにパーティション化されたコンシューマーモデルを使用します。
同じソース（例：特定のIoTデバイス）からのイベントが、同じコンシューマーによって順序通りに処理されるようにします。
ソース識別子（例：デバイスID）に設定されたパーティションキーを使用してEvent Hubsにイベントを送信します。
理由: Event Hubsは、同じパーティションキーを持つすべてのメッセージを同じパーティションにルーティングします。パーティション内ではメッセージの順序が維持されます。
関連するメッセージのシーケンスを厳密なFirst-In, First-Out (FIFO)順序で処理します。
Azure Service Busセッションを使用します。すべての関連メッセージを同じ`SessionId`で送信します。
理由: セッションは、並行して順序付けられたメッセージストリームを提供します。セッション対応のレシーバーはセッションをロックし、メッセージが単一のコンシューマーによって順次処理されることを保証します。
単一のパブリッシャーがトピックにメッセージを送信しますが、複数のサブスクライバーはメッセージプロパティに基づいてメッセージのサブセットのみを必要とします。
複数のサブスクリプションを持つService Busトピックを使用します。各サブスクリプションにSQLフィルターまたはCorrelationフィルターを適用します。
理由: これはコンテンツベースのルーティングを備えた標準的な発行/購読パターンです。各サブスクリプションは、そのフィルタールールに一致する場合にメッセージのコピーを受け取ります。
メッセージが複数回の再試行後も正常に処理できず、後で検査するために脇に置いておく必要があります。
メッセージが最大配信カウントを超えるまで処理を失敗させます。自動的にDead-Letter Queue (DLQ)に移動されます。
理由: DLQは、ポイズンメッセージ用の組み込みのサブキューです。これにより、失敗したメッセージがメインキューをブロックするのを防ぎ、オフラインでの分析と再処理が可能になります。
エンタープライズコマンド、リアクティブイベント、または大容量テレメトリのメッセージングサービスを選択します。
コマンド（注文、トランザクション）にはService Bus。リアクティブイベント（Blob作成、リソース変更）にはEvent Grid。テレメトリ（IoTデータ、クリックストリーム）にはEvent Hubs。
理由: Service Busは、順序付け、トランザクション、デッドレター処理などの豊富な機能を提供します。Event Gridは、軽量でプッシュベースのイベントルーティング用です。Event Hubsは、高スループットのデータストリーミング用です。