2025-06-18 / 最終更新日時 : 2026-09-29 musashi 技術コラム

稼働中のシステムを別のAzureリージョンへ移す｜引き継がれない設定と、切り替えの順序設計

Azure Functions を別のリージョンへ作り直すと、タイマートリガーの状態は新しいアプリでリセットされます。旧いアプリを動かしたまま切り替えると、同じ定時処理が新旧の両方で走ります。

リージョンの移設は、作り直した新しい環境を動かすだけでは終わりません。作り直しで引き継がれない設定を先に洗い出し、新しい受け口を先に作る・止まる時間を1か所に寄せる・旧い環境を止めて切り戻しに備える、という切り替えの順序を決めてから始めることが大切です。

構成をテンプレートで管理していれば、同じ環境を別のリージョンに作ること自体は難しくありません。ここまでは Azure を運用している方の多くが押さえている前提だと思います。弊社はお客様専用の環境を Azure 上に構築・運用しており、稼働中のシステムのアプリの実行基盤を、海外のリージョンから国内のリージョンへ移設しました。この記事では、そのときの経験から、作り直しで引き継がれない設定と、切り替えの順序の組み立て方を解説します。

全体像：リージョンの移設は「作り直して切り替える」こと
リソースを別のリージョンへ移動する機能は無いのか
引き継がれない設定：作り直しで付いてこないもの
引き継がれない設定：移設先の枠（クォータ）
切り替えの順序：止めずにできる作業と、切り替えの時間帯にしかできない作業を分ける
切り替えの順序：イベントの受け口は「新しい購読を先に、旧い購読を後に」
切り替えの順序：止まる時間を1か所に寄せる
切り替えの順序：切り戻しの手順を先に書き、旧い環境は止めて残す
弊社の考え方
弊社の支援
よくあるご質問

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。

全体像：リージョンの移設は「作り直して切り替える」こと

リージョンを移す理由には、新しいリージョンの開設、特定のリージョンにしかない機能の利用、社内の方針やデータの所在に関する要件などがあります。弊社の場合は、お客様に「個人データは国内で処理している」と説明できる状態にするためでした。データの所在をどう説明するかは、ソブリンクラウドとはでも解説しています。

移設の対象は、アプリの実行基盤である Function App と、その周りの監視・実行用のストレージです。データを持つ層（データベースやファイルの保管先）は、はじめから国内のリージョンにありました。利用者が使う画面は Azure Static Web Apps で提供しており、ここは作り直さず、画面の裏でリンクしている Function App を新しいものへ張り替えました。

進め方は、次の2つの柱に分けて考えています。

柱	決めること	これが無いと起きること
引き継がれない設定	作り直したときに、何が付いてこないか。どこで作り直すか	新しい環境は動いているのに、特定の機能だけが動かない
切り替えの順序	何を事前に済ませ、何を切り替えの時間帯に行うか。どの順で行い、どう戻すか	イベントの取りこぼし、処理の二重実行、止まる時間の長期化

リソースを別のリージョンへ移動する機能は無いのか

リージョンの移設と聞いて最初に思うのは、「リソースグループやサブスクリプションの移動のように、リージョンも移動できないのか」という疑問だと思います。答えは、リソースの種類によって分かれます。

Azure には、リソースを別のリージョンへ移すための Azure Resource Mover があります。依存関係の洗い出しや、移動の試行と破棄もできます。ただし Microsoft Learn の一覧を見ると、Resource Mover で移せるのは仮想マシン・仮想ネットワーク・ネットワークセキュリティグループなどに限られます。App Service や Azure Functions、Static Web Apps、Event Grid のシステムトピックは、移設先に作り直す方法が案内されています。

サービスの例	Resource Mover	Learn が案内している方法
仮想マシン	対象	Resource Mover で移す
仮想ネットワーク・ネットワークセキュリティグループ	対象	Resource Mover で移す、または作り直す
App Service・Azure Functions	対象外	移設先に作り直し、コードを配置し直す
Static Web Apps	対象外	移設先に作り直し、配置先を切り替える
Event Grid のシステムトピック	対象外	テンプレートを書き出して移設先に作り直す
ストレージアカウント・Key Vault・Cosmos DB	対象外	作り直し、データは別途移す

Azure Functions について、Learn は「関数アプリをホストする Azure のリソースはリージョンに固有で、リージョンをまたいで移動できない。移設先に既存のリソースのコピーを作り、コードを配置し直す必要がある」と説明しています。PaaS を中心にした構成では、移設は「移動」ではなく「作り直して切り替える」作業になる、と考えておくのが実態に合います。

引き継がれない設定：作り直しで付いてこないもの

作り直すときに問題になるのは、テンプレートに書かれていないものや、リソースを作ると新しく生まれるものです。Learn の Functions と App Service の移設ガイドに挙がっている項目と、弊社の対応をまとめます。

項目	作り直すと起きること	必要な対応
アプリの名前	Function App の名前は Azure 全体で一意なので、同じ名前と URL は使えない	新しい名前にし、URL を直接呼んでいる相手を洗い出す
関数のアクセスキー	新しいアプリでは新しいキーが作られる	キーで呼んでいる相手を新しいキーへ切り替える
タイマーの状態	新しいストレージを使うと、タイマートリガーの状態がリセットされる。新旧のアプリはそれぞれ独立して定時処理を動かす	新しいアプリでは切り替えまで定時処理を動かさず、切り替えで旧いアプリを止める
アプリ設定	値の多くは移せるが、接続先を移したものは値が変わる	書き出して移し、環境に固有の値は新しい値にする
Key Vault の参照	地域の境界をまたいで書き出せない	移設先で参照を作り直す
マネージド ID	システム割り当ては作り直しになる。ユーザー割り当ても別のリージョンへは移せない	接続先のサービスに、同じ権限を付け直す
監視	Application Insights と Log Analytics はリージョンのサービス	移設先に作り、接続文字列を新しいものにする
カスタムドメイン・証明書	App Service のマネージド証明書は書き出せない	移設先で事前にドメインを確認し、証明書を作り直す

アプリ設定は「移すもの」と「新しい値のままにするもの」に分ける

アプリ設定は、ポータルから JSON の形で書き出せます。ただし全部をそのまま上書きすると、新しい環境に固有の値まで旧い値に戻してしまいます。弊社では、業務の設定（データベースの名前や保管先のコンテナー名など）は旧い環境の値を移し、実行用のストレージへの接続や Application Insights の接続文字列など、実行基盤に固有の設定は新しい環境の値を残しました。どの設定がどちらに当たるかを、移す前に一覧で決めておくと取り違えを防げます。

マネージド ID の権限は、画面が開いても足りているとは限らない

システム割り当てのマネージド ID は、新しい Function App を作ると別の ID として生まれます。旧い ID に付けていたロールの割り当ては付いてこないため、接続先のサービスごとに付け直します。弊社の構成で必要だったのは、Azure OpenAI と、メールの送信に使うサービスへの2件でした。キーで接続しているサービスには、ロールの割り当ては要りません。権限が足りないと、画面は開くのに、その ID を使う機能だけが失敗します。切り替えの前に、ID を使う機能を実際に動かして確かめます。

引き継がれない設定：移設先の枠（クォータ）

もう1つ、引き継がれないものがあります。リソースを作れる数の枠（クォータ）です。Learn によると、クォータはサブスクリプションの範囲で設定され、サブスクリプションごとに既定の値があります。多くの枠はリージョンごとに管理されるため、移設元のリージョンで使えていたプランが、移設先のリージョンでも同じように作れるとは限りません。

弊社では、移設先のリージョンで App Service の Basic プランの枠が初期値で0になっており、プランを作れませんでした。ポータルから増加を申請して承認されるまで、移設の作業は止まりました。Learn は、増加の申請は Microsoft の審査を経ること、また割り当てられた枠は容量を予約・保証するものではないことを明記しています。移設の計画では、最初に移設先で必要なプランや SKU を作れるかを確かめ、申請が要るなら待ち時間を日程に含めておきます。なお、クォータの増加の申請自体に費用はかかりません。

切り替えの順序：止めずにできる作業と、切り替えの時間帯にしかできない作業を分ける

移設の作業の大半は、稼働中のシステムを止めずに進められます。新しい環境を作り、設定を移し、コードを配置して動くことを確かめるまでは、利用者から見て何も変わりません。切り替えの時間帯に行う作業を最小限に絞ることが、止まる時間と事故の両方を減らします。弊社の仕分けは次のとおりです。

作業	いつ行うか	理由
移設先の枠を確かめ、必要なら申請する	最初に	承認まで待ち時間があり、ほかの作業が進められない
プラン・Function App・監視・実行用のストレージを作る	事前	利用者から見えない
アプリ設定を移し、マネージド ID に権限を付ける	事前	新しいアプリはまだ使われていない
コードを配置し、関数の数と動作を確かめる	事前	切り替えの前に「動く」状態にしておく。定時処理の関数は、切り替えまで無効にするかアプリを停止しておく
検証環境で、切り替えまでの手順を一度通す	事前	いちばん不確かな手順を本番の前に確かめる
イベントの購読を切り替える	切り替えの時間帯	新旧が並ぶ間は、同じイベントが両方に届く
画面の裏の接続先を張り替える	切り替えの時間帯	張り替えの間は API が応答しない
旧いアプリを停止する	切り替えの時間帯	定時処理の二重実行を止める
配置パイプラインの宛先を新しいアプリにする	切り替えの直後	次の変更が旧いアプリへ配置されるのを防ぐ
旧い環境を撤去する	期限が来てから	切り戻しの手段を残しておく

弊社では、本番の前に検証環境で同じ移設を一度行いました。いちばん不確かだったのは、画面の裏の接続先を別のリージョンの Function App へ張り替えられるかどうかでしたが、検証環境で成功を確かめてから本番に進めています。検証環境は、確かめた後にいったん元の構成へ戻しました。

切り替えの順序：イベントの受け口は「新しい購読を先に、旧い購読を後に」

弊社のシステムでは、ストレージにファイルが置かれると Event Grid がイベントを送り、Function App が処理を始めます。ストレージは移設の対象ではないため、変えるのはイベントの届け先（イベントの購読）だけです。

Learn によると、Event Grid の購読は、どのイベントをどこへ届けるかを決めるもので、関数でイベントを受けるにはイベントの発生元への購読が必要です。旧い購読を先に削除してから新しい購読を作ると、その間に置かれたファイルのイベントは、どの関数にも届きません。そこで弊社は、新しい Function App への購読を先に作り、届くことを確かめてから、旧い購読を削除しました。Learn の Event Grid の移設ガイドも、移設先に作って確かめてから移設元を削除する順序で書かれています。

この順序では、新旧の購読が並ぶ間、同じイベントが新旧の両方に届きます。1つのファイルが2回処理されるということです。ただし Learn は、Event Grid の配信は「少なくとも1回」であり、通常の運用でも同じイベントが重複して届くことがあると説明しています。つまり、処理を重複に強く作っておくことは、移設のためだけでなく、もともと必要な設計です。

ストレージのイベントには、置かれたファイルの版を表す eTag が含まれます。弊社の実装では、処理済みの記録とイベントの eTag を照合し、同じファイルの同じ版を2回処理しても結果が変わらないようにしています。このため、新旧が並ぶ短い時間の重複は無害でした。重複に弱い処理（外部への送信や課金など）がある場合は、先に処理側を直してから切り替えます。

切り替えの順序：止まる時間を1か所に寄せる

利用者から見て止まる時間を完全に無くすには、両方のリージョンでシステムを動かし、Front Door や Traffic Manager のような振り分けの仕組みで切り替える構成が要ります。Learn も、停止を最小にしたい場合の選択肢として、両方のリージョンで動かす構成を挙げています。弊社の構成はそこまで作っていなかったため、止まる時間をゼロにするのではなく、止まる時間を1か所に寄せて短くすることを目標にしました。

その1か所が、Static Web Apps にリンクしている Function App の張り替えです。Learn によると、1つの Static Web Apps にリンクできる Function App は1つだけです。新旧を同時にリンクしておくことはできないため、旧いアプリのリンクを外して新しいアプリをリンクする間は、画面から API を呼べません。弊社の実測では、この間は約44秒でした。画面の表示そのものは止まらず、API を使う操作だけがこの間失敗します。

ほかの作業はこの前後に並べ、止まる時間が重ならないようにしました。イベントの購読は新しい購読を先に作るため、止まる時間を生みません。旧いアプリの停止は張り替えの後に行い、張り替えるまでは旧いアプリが画面からの API に応答し続けるようにしました。なお、リンクを外しても、Function App の側に作られた認証の設定（ID プロバイダー）は自動では削除されません。Learn は、匿名の要求に誤って公開しないための仕様だと説明しています。旧いアプリは後で撤去するため、弊社ではそのまま残しました。

切り替えの順序：切り戻しの手順を先に書き、旧い環境は止めて残す

切り替えの時間帯に問題が出たとき、その場で戻し方を考えるのは危険です。弊社は、切り替えの手順と一緒に、切り戻しの手順を先に書いておきました。今回の構成での切り戻しは、①旧い Function App を起動する ②Static Web Apps のリンクを旧いアプリへ戻す ③旧いアプリへのイベントの購読を作り直す、の3つです。旧い購読は削除しているため、作り直せるよう、削除する前に購読の設定を書き出しておきます。

切り替えの後は、試験用のデータで、ファイルを置いてから処理の結果が出るまでを端から端まで確かめました。お客様のデータに影響しないよう、試験データは確認の後にすべて削除しています。配置の後に何を確かめるかの考え方は、Azure DevOps で本番環境へのデプロイを管理するで解説しています。

旧い環境は「削除」ではなく「停止」して、期限を決めて残す

Learn の移設ガイドは、移設が完了したら移設元のアプリとプランを削除するよう案内しています。弊社はこれに対して、旧い Function App を停止した状態で一定期間残し、切り戻しの手段にしています。削除してしまうと、戻すには作り直しからになるためです。停止しておけば、定時処理が新旧の両方で動くこともありません。

ただし、残す間も費用はかかります。Learn は、Premium プランや App Service プラン（専用）の関数アプリは、アプリが動いていなくても課金されると明記しています。無料以外の App Service プランは、アプリが1つも動いていなくても課金されます。旧い環境を残すなら、いつまで残すか、どうなったら撤去するかを切り替えの前に決めておきます。1つのプランに本番と検証環境のアプリが載っている場合は、両方の切り替えが終わるまでプランを削除できない点にも注意が要ります。

この記事の要点

全体像

App Service・Functions・Static Web Apps・Event Grid は、Resource Mover の対象外。移設は作り直して切り替える作業になる

引き継がれない設定

名前・アクセスキー・タイマーの状態・Key Vault の参照・マネージド ID の権限・監視・証明書は付いてこない
アプリ設定は、移すものと新しい値のままにするものを先に決める
移設先の枠は別。申請の待ち時間を日程に含める

切り替えの順序

止めずにできる作業を先に済ませ、検証環境で一度通す
イベントの購読は新しいものを先に作り、重複は処理側で無害にする
止まる時間は1か所（弊社は Static Web Apps の張り替え）に寄せる
切り戻しの手順を先に書き、旧い環境は停止して期限を決めて残す。残す間も費用はかかる

弊社の考え方

リージョンの移設は、頻繁に行う作業ではありません。そのため手順が組織に残りにくく、移設のたびに同じ落とし穴に落ちがちです。弊社は、移設を「一度きりの作業」ではなく、「環境をテンプレートから作り直せるか」を確かめる機会と考えています。作り直してみて付いてこなかったものは、普段の運用でも、障害からの復旧や環境の複製のときに同じように付いてきません。

今回の移設で、弊社はアプリ設定の仕分け、マネージド ID の権限、イベントの購読の定義を手順書に残し、次に同じ構成を作るときの一覧にしました。テンプレートで構成を管理するときの注意点は、Azureの構成をBicepで管理するときの落とし穴で解説しています。

弊社の支援

弊社は、お客様専用のAI基盤やアプリを Azure 上に構築し、運用まで支援しています。データの所在の要件に合わせたリージョンの選定から、閉域の構成、検証環境と本番環境の2面での運用までを一貫して設計しています。閉域の構成はAzure OpenAI・AI Searchを閉域で使うをご覧ください。

すでに稼働している環境を別のリージョンへ移したい場合も、現在の構成の棚卸し、作り直しで引き継がれない設定の洗い出し、切り替えと切り戻しの手順づくり、検証環境でのリハーサルまで、段階的に進める支援を行っています。

よくあるご質問

こちらをクリックして「よくある質問」を表示

Azure には、リソースのリージョンを変更する機能がありますか？

仮想マシンや仮想ネットワークなどは、Azure Resource Mover で別のリージョンへ移せます。一方、App Service・Azure Functions・Static Web Apps・Event Grid のシステムトピックなどは対象外で、移設先に作り直して切り替える方法が案内されています。

移設の間、システムはどのくらい止まりますか？

構成によって変わります。弊社の構成では、Static Web Apps にリンクしている Function App を張り替える間だけ API が応答せず、その時間は約44秒でした。止まる時間を無くすには、両方のリージョンで動かして振り分けの仕組みで切り替える構成が必要です。

Event Grid の購読は、どの順序で切り替えればよいですか？

新しい届け先への購読を先に作り、届くことを確かめてから旧い購読を削除することをお勧めします。逆の順序では、その間のイベントがどこにも届きません。新旧が並ぶ間は同じイベントが両方に届くため、処理を重複に強く作っておきます。

アプリ設定は、旧い環境からそのまま移せますか？

書き出して移すことはできますが、全部をそのまま上書きすると、実行用のストレージや監視の接続先など、新しい環境に固有の値まで旧い値に戻ります。移すものと新しい値のままにするものを先に決めておきます。Key Vault の参照は、移設先で作り直す必要があります。

移設先のリージョンで、同じプランを作れないことはありますか？

あります。弊社では、移設先のリージョンで App Service の Basic プランの枠が初期値で0になっており、増加の申請が必要でした。申請は審査を経るため、移設の計画の最初に確かめ、待ち時間を日程に含めておくことをお勧めします。

移設が終わったら、旧い環境はすぐに削除すべきですか？

Learn は移設の完了後に削除するよう案内しています。弊社は、切り戻しの手段として旧いアプリを停止した状態で一定期間残し、期限が来たら撤去しています。停止していてもプランの費用はかかるため、残す期限を切り替えの前に決めておきます。

稼働中の Azure 環境を別のリージョンへ移したい、データの所在の要件に合わせて構成を見直したい、というご相談を承っています。現在の構成と、許容できる停止の時間をお聞かせいただければ、引き継がれない設定の洗い出しから、切り替えと切り戻しの手順まで、進め方をご提案します。お問い合わせよりお気軽にご相談ください。