Azure Static Web Appsから一時共有URLへ切り替えるタイミング

できること

Azure Static Web Appsのビルド成果物は`staticwebapp.config.json`の`outputLocation`で指定したフォルダに生成されます。このフォルダをzip圧縮して認証付き共有サービスにアップロードすることで、Azureのパイプラインには一切手を加えずにレビュー共有手段だけを切り替えられます。

切り替えを検討する初期段階では、相手がPCとスマホの両方で確認するかどうかを確認することが出発点です。Azure Static Web AppsのプレビューURLもモバイルで問題なく閲覧できますが、Microsoftアカウントが必要な場合にスマホでのサインインが摩擦になるケースがあります。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

できないこと

Azure Static Web Apps標準のプレビュー環境では、同一コンテンツを複数の取引先に対してそれぞれ別の認証でアクセス制御することができません。A社とB社に異なるパスワードでアクセスさせたい場合、Azure Static Web AppsのロールAPIで各社ごとにロールを設定する必要があり、設定の複雑さが急増します。

閲覧期限の自動付与もAzure Static Web Apps標準機能では提供されていません。PRのcloseでプレビュー環境は削除されますが、「1週間後に自動でアクセス不可にしたい」という期限設定はロジックアプリやAzure Functionsでの自動化が必要で、設定工数が発生します。

認証と期限の違い

「誰でも見てよい」場合のAzure Static Web AppsプレビューURLはURLの公開範囲がコントロールしにくく、Slackや社内wikiに貼られると想定外の人が閲覧するリスクがあります。認証付き共有サービスへの切り替えタイミングの一つは、「共有先を厳密に管理したくなった時点」です。

「短期レビューで期限を確実に守りたい」という要件が生まれた時点でも切り替えを検討すべきです。Azure側でPRを手動closeしてプレビューを削除する運用はヒューマンエラーが起きやすく、特に複数プロジェクトを並行管理するチームでは期限切れURLの放置が頻発します。認証付き共有サービスの期限機能は、このヒューマンエラーをシステム的に排除します。

• 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
• 特定の相手だけ: パスワードまたはメール認証を使う
• 会社内だけ: 会社ドメイン認証を検討する
• 短期レビュー: 期限を設定して古いURLを残さない

差し替え・レビュー運用

切り替え後の差し替え運用として、ビルドパイプラインの最終ステップにzip化とアップロードを追加する形が効率的です。Azure DevOpsのパイプラインでは`CmdLine@2`タスクを使ってビルド後のフォルダをzipにまとめ、cURLで共有サービスのAPIを呼ぶステップを追加するだけで自動化できます。

「最終版と途中版が混ざらない」ためには、ビルドのトリガーをmainブランチへのマージに限定し、featureブランチのビルドはAzure Static Web Appsのプレビューで確認、mainへのマージ後にだけ共有サービスにアップロードするというルールが有効です。社外承認者には常にmainブランチ相当のコンテンツだけが届くようになります。

• 確認してほしい観点を3つ以内に絞る
• 期限と返信先を明記する
• 修正後も同じURLで見られるか伝える
• 最終版と途中版が混ざらないようタイトルを付ける

向いているケース早見表

Azure Static Web Appsのまま続けるのが向いているのは、社内エンジニアのコードレビューとビジュアルレビューを同時に行い、全員がMicrosoftアカウントを持っているケースです。Entra IDとの連携による権限管理がシームレスで、追加のサービスを導入しなくても要件が満たせます。

認証付き共有URLへの切り替えが有効なのは、Microsoftエコシステム外の取引先に共有が必要になった時点、または「エンジニア以外のディレクターが自分でレビューURLを発行・管理したい」という要望が出た時点です。AzureポータルにアクセスせずにURLを発行・パスワード設定・期限設定が完結するサービスに切り替えることで、チームの分業が明確になります。