タイでAWS移行を進めるには？現地法人の課題と移行手順を解説

タイ拠点でオンプレミス環境や既存システムを運用する企業では、サーバーの老朽化、保守負担、拡張性の不足を背景に、アマゾンウェブサービス（AWS）への移行が選択肢になります。AWSアジアパシフィック（タイ）リージョンを利用すれば、タイ国内にAWS環境を構築できます。

移行にあたっては、現行システムの依存関係、拠点間ネットワーク、費用、期間、停止時間、PDPAやデータ保管要件を整理し、本番切り替え後の監視・運用まで設計します。

この記事では、タイでAWS移行を検討する背景、タイランドリージョンの確認事項、移行手順、費用・期間、日本本社と現地法人の役割分担、支援会社の選び方を解説します。

タイでAWS移行を検討する背景とメリット

タイ拠点のオンプレミス環境では、サーバーの老朽化、保守契約の更新、障害対応、機器の増設が継続的な負担になります。現地に十分なIT人材を確保できず、日本本社や外部ベンダーへ対応を依存している企業もあります。

AWSアジアパシフィック（タイ）リージョンの開設により、タイ国内へのデータ配置や、現地利用者からの応答速度を重視するシステムでも、AWSを移行先として選びやすくなりました。

AWSへ移行すると、物理機器の調達や保守を減らし、利用状況に応じてリソースを増減できます。バックアップ、監視、セキュリティもAWSのサービスを組み合わせて設計できるため、運用体制や事業継続性、インフラコストを見直すきっかけになります。

オンプレミス環境の保守・拡張に課題が生じている

オンプレミス環境では、サーバー、ストレージ、ネットワーク機器の保守期限を管理し、故障や性能不足に備えて更新計画を立てます。増設や交換のたびに、機器の選定、調達、設置、設定、動作確認も必要です。

タイでは、必要な機器や保守要員をすぐに確保できないことがあります。現地ベンダーとの調整や日本本社の承認に時間がかかり、増強が間に合わないケースもあります。構成や障害対応が特定の担当者に依存していれば、異動や退職も運用リスクになります。

AWSでは、物理機器を購入せずにコンピューティングやストレージを追加できます。保守期限に合わせたシステム全体の更改も不要になり、業務量や利用者数に応じて構成を調整できます。

現地の運用負担を抑え、事業継続性を高められる

現地のIT担当者が、社内システム、ネットワーク、端末管理、利用者対応を兼務していることもあります。サーバー障害や容量不足が発生すると、原因調査や機器交換に追われ、本来の業務へ影響が及びます。

AWSでは、稼働状況、ログ、バックアップ、セキュリティイベントを遠隔から確認できます。日本本社や運用支援会社が監視し、障害調査や復旧を支援する体制も構築できます。

複数のアベイラビリティーゾーンへの分散、バックアップ、復旧手順を組み合わせれば、機器故障や拠点側のトラブルにも備えられます。ただし、可用性、バックアップ先、復旧時間、連絡経路は別途設計が必要です。

AWS移行によってインフラコストを見直せる

オンプレミス環境では、将来の利用増加を見込み、必要量を上回るサーバーやストレージを購入することがあります。機器代に加え、保守、設置場所、電源、空調、バックアップ機器の費用も発生します。

AWSは、利用するリソースやデータ転送量に応じた料金体系です。必要な容量から開始し、利用状況に合わせて増減できるため、余剰設備を抱える必要がありません。長期利用向けの料金プランや、未使用リソースの停止・削除もコスト管理に有効です。

一方、現行構成をそのまま移すと、過剰なスペックや不要なリソースが残り、利用料が想定を上回ることがあります。移行前に現行コストと利用状況を調査し、構成、料金プラン、運用費まで比較します。

タイランドリージョンへ移行する際の確認ポイント

AWSアジアパシフィック（タイ）リージョンは、2025年1月に一般提供が開始されました。リージョンコードは「ap-southeast-7」で、3つのアベイラビリティーゾーンから構成されています。

移行先として採用する際は、レイテンシ、データ配置、利用できるAWSサービス、可用性を確認します。

タイ国内からのレイテンシを確認する

タイランドリージョンを利用すると、タイ国内の利用者や拠点からAWS環境までの物理的な距離を短くできます。

ただし、応答速度はリージョンだけで決まりません。拠点側の回線、通信事業者の経路、VPNや専用線、アプリケーション処理、外部サービスとの接続も影響します。

移行前に、実際の利用拠点から画面表示、ファイル転送、データベース処理などを測定します。バンコク以外に工場や営業拠点がある場合は、各拠点からタイランドリージョンまでの通信経路、回線品質、帯域、障害時の代替経路も確認します。

日本本社やタイ国外から利用する場合は、それぞれの接続元でも許容できる性能を得られるか検証します。

データ配置とPDPAの要件を整理する

タイランドリージョンを利用すれば、対象データをタイ国内のAWSインフラストラクチャに保存できます。国内保管が契約、社内規程、業界要件に含まれる場合は、移行先を判断する材料になります。

ただし、タイ国内へ保存するだけでPDPAへの対応が完了するわけではありません。個人データの収集、利用、開示、保護、移転を踏まえ、データの種類、利用目的、アクセス権限、保存期間、委託先との責任分担を整理します。

日系企業では、業務データをタイ国内に保存しながら、日本本社が管理画面やログへアクセスする構成も考えられます。データ本体の保存先だけでなく、バックアップ、ログ転送、外部サービスとの連携、障害調査時のデータ共有まで確認します。

日本本社やタイ国外からデータへアクセスする場合は、その取り扱いが国境を越えたデータ移転に当たるか、法務・セキュリティ部門と確認します。

利用予定のAWSサービスに対応しているか確認する

AWSサービスの提供状況はリージョンごとに異なります。必要なサービスがタイランドリージョンで提供されていなければ、構成変更や代替サービスの検討が必要です。

データベース、監視、セキュリティ、バックアップ、分析、生成AIなどは、利用できる機能や提供時期が異なることがあります。サービス名だけでなく、エンジン、インスタンスタイプ、機能、バージョンまで確認します。

現行環境の製品や機能を一覧化し、AWS上の移行先と提供状況を対応させます。利用できない場合は、別サービスへの置き換え、別リージョンへの配置、移行対象からの除外を検討します。

可用性と災害対策の構成を検討する

複数のアベイラビリティーゾーンへシステムを分散すれば、単一のデータセンターや設備の障害に備えられます。

ただし、分散するだけで必要な可用性や復旧要件を満たせるとは限りません。システムの重要度に応じて、サーバーやデータベースの冗長化、バックアップ、障害検知、切り替え方法を設計します。

リージョン全体の停止まで想定する場合は、別リージョンへのバックアップや災害復旧環境も検討します。復旧時間目標、復旧時点目標、データ転送費、維持費を比較し、必要な範囲を決めます。

タイでAWS移行を進める手順

AWS移行は、次の5つの工程で進めます。

1. 現行環境と移行対象を調査する
2. 移行方式と移行計画を決める
3. AWS環境とネットワークを設計する
4. テスト移行と本番切り替えを行う
5. 移行後の運用担当者へ引き継ぐ

日本本社、現地法人、既存ベンダー、移行支援会社の担当範囲も、初期段階で整理します。

現行環境と移行対象を調査する

最初に、現行環境の構成と利用状況を把握します。

• サーバー、データベース、ストレージ
• ネットワーク構成と通信先
• システム間の依存関係
• データ量、通信量、稼働時間
• 障害履歴と保守期限
• OS、ミドルウェア、ライセンス
• 利用者とアクセス経路
• 停止可能な時間帯

認証基盤、外部サービス、ファイル連携、夜間バッチ、プリンター、工場設備など、業務を成立させる接続先も調査対象です。

調査結果をもとに、AWSへ移行するシステム、オンプレミスに残すシステム、廃止するシステムを分け、難易度と業務影響から優先順位を決めます。

この工程で決めること

• 移行・残置・廃止の対象
• システム間の依存関係
• 移行の優先順位

移行方式と移行計画を決める

システムごとに移行方式を選びます。

移行方式は、現行環境の課題、将来の拡張計画、利用できる人員、停止可能時間を踏まえて選びます。

移行計画には、対象システム、作業順序、担当者、テスト期間、本番切り替え日を定めます。システム間に依存関係がある場合は、段階的に進めるか、まとめて切り替えるかも判断します。

失敗時に旧環境へ戻せる時点と、継続・中止を判断する責任者も事前に決めます。

この工程で決めること

• システムごとの移行方式
• 移行順序とスケジュール
• 担当者と承認者
• 切り戻し条件

AWS環境とネットワークを設計する

移行計画に基づき、AWS上の基盤を設計します。

• AWSアカウントの構成
• VPC、サブネット、ルーティング
• IAMの権限
• タイ拠点や日本本社との接続
• ログの取得先
• 監視項目と通知先
• バックアップの頻度と保存期間
• 暗号化とセキュリティ設定

ネットワークでは、タイ拠点、日本本社、オンプレミスに残すシステム、外部サービスの接続方法を決めます。インターネットVPNや専用線を比較し、帯域、安定性、障害時の代替経路を確認します。

監視とバックアップは移行前に設定し、本番切り替えと同時に運用できる状態へ整えます。

この工程で決めること

AWSアカウントとネットワークの構成

• 権限管理
• 監視と通知
• バックアップと復旧方法

テスト移行と本番切り替えを行う

本番切り替え前に、テスト環境や一部のデータを使って移行手順を検証します。

• データ転送にかかる時間
• システムの起動手順
• 接続先の変更方法
• データの整合性
• 業務機能の動作
• 切り戻しに必要な時間

サーバーの起動だけでなく、ログイン、データ入力、検索、帳票出力、ファイル連携、バッチ処理など、実際の業務手順に沿って確認します。

本番では、データ更新の停止、最終データ移行、接続先の変更、動作確認を手順書に沿って進めます。タイ拠点と日本本社が対応できる時間帯を設定し、作業状況と判断結果を共有する連絡経路も用意します。

重大な不具合が見つかった場合は、事前に定めた条件に従って旧環境へ切り戻します。

この工程で決めること

• テスト項目と合格条件
• 本番切り替え手順
• 開始・完了の判定者
• 切り戻し基準
• 当日の連絡体制

移行後の運用担当者へ引き継ぐ

本番切り替え後は、移行プロジェクトから通常運用へ引き継ぎます。

• AWS環境の構成図
• アカウントと権限
• 監視項目と通知先
• バックアップと復旧手順
• 障害対応手順
• 変更管理の方法
• 問い合わせ先と連絡経路

移行直後は、性能不足、通信エラー、バッチ処理の失敗、想定外のAWS利用料が発生することがあります。一定期間は移行担当者と運用担当者が共同で稼働状況を確認し、必要に応じて設定を調整します。

タイ現地法人、日本本社、外部支援会社の間で、一次対応、原因調査、復旧判断、利用者への連絡、本社への報告を分担します。監視と障害対応が機能する状態を、運用開始の基準とします。

この工程で決めること

• 運用責任者
• 監視と障害対応の分担
• エスカレーション先
• 日本本社への報告方法
• 移行後の確認期間

タイでAWS移行を進める際の費用と期間

AWS移行の費用と期間は、サーバー台数だけでは決まりません。システム構成、データ量、移行方式、ネットワーク、停止可能時間、テスト範囲によって変わります。

見積もりでは、現行調査、AWS環境の設計・構築、移行、テスト、本番切り替え、移行後の運用までを対象にします。費用や期間だけを優先して調査・テストを削ると、本番切り替え時のリスクが高まります。

移行費用を左右する項目と目安を確認する

AWS移行の費用は、主に次の項目で構成されます。

• 現行環境の調査・アセスメント
• AWS環境の設計・構築
• サーバー、データベース、データの移行
• ネットワーク接続の構築
• テストと本番切り替え
• 移行後の監視・運用
• AWSの月額利用料

既存構成を大きく変えず、対象システムも少ない場合は、調査や設計の範囲を抑えられます。一方、複数システムの連携、データベース変更、アプリケーション改修、専用線の構築が必要な場合は、費用が増えます。

移行後は、Amazon EC2やAmazon RDSなどの利用料に加え、データ転送、バックアップ、ログ保管、監視、サポートの費用も発生します。

概算を依頼する際は、次の条件を支援会社へ伝えます。

• 移行対象のシステムと台数
• データ量と通信量
• 現行環境の構成
• 移行方式
• 停止可能時間
• テスト範囲
• 移行後の運用範囲

一律の相場ではなく、費用の内訳と前提条件が明示された見積もりを比較します。

移行期間を左右する要因を整理する

移行期間は、現行調査、設計、構築、テスト、本番切り替えに必要な時間を積み上げて算出します。

主な変動要因は次のとおりです。

• 移行対象のシステム数
• システム間の依存関係
• データ量と転送速度
• アプリケーション改修の有無
• ネットワーク回線の準備
• テスト環境の有無
• 社内承認やベンダー調整
• 停止可能な日時

リホストは比較的短期間で進めやすい一方、現行環境の情報不足や複数ベンダーとの調整があると、調査と計画に時間がかかります。リプラットフォームやリファクタリングでは、設計変更、改修、追加テストが必要になるため、期間も長くなります。

移行計画では、本番切り替え日だけを先に決めず、各工程の完了条件と承認者を設定します。タイ現地法人、日本本社、既存ベンダー、支援会社の確認期間もスケジュールに含めます。

停止時間と業務への影響を見積もる

本番切り替えでは、データ更新の停止、最終データ転送、接続先の変更、動作確認が発生します。その間、対象システムを利用できない場合があります。

停止時間を左右する主な条件は次のとおりです。

• 移行するデータ量
• 拠点回線の帯域
• 差分同期の可否
• システムの起動と確認にかかる時間
• DNSや接続先の切り替え方法
• 切り戻し手順

事前に大部分のデータを転送し、本番当日は差分だけを同期する方法や、システムを段階的に切り替える方法もあります。ただし、利用できる手法はシステム構成によって異なります。

利用部門とは、次の項目を確認します。

• 停止できる曜日と時間帯
• 停止中に利用できない業務
• 手作業で代替できる範囲
• 顧客や取引先への案内
• 切り戻しを判断する時刻
• 業務再開の確認方法

タイ拠点と日本本社が同じシステムを利用する場合は、双方の営業時間と時差も考慮し、業務影響と復旧判断まで本番切り替え計画へ反映します。

日本本社とタイ現地法人の役割分担

AWS移行では、日本本社、タイ現地法人、外部支援会社の責任範囲を分けます。本社側は方針、予算、セキュリティ基準を管理し、現地側は業務要件や利用者への影響を整理します。支援会社へ作業を依頼する場合も、意思決定まで委ねるのではなく、各段階の確認者と承認者を明確にします。

実際の分担は現地のIT体制や本社の管理方針によって異なります。移行前、移行当日、移行後の各段階で、誰が確認し、誰が判断するかを決めます。

日本本社が管理する範囲

日本本社は、全社方針や管理基準に関わる事項を担当します。

• AWS移行の目的と対象範囲
• 予算とスケジュール
• AWSアカウントの管理方針
• IAM権限と承認ルール
• セキュリティとログ管理の基準
• バックアップと災害対策の要件
• 委託先の選定と契約
• 障害やセキュリティ事故の報告基準

AWSアカウントや管理者権限を現地法人や支援会社だけに委ねると、本社側が構成や変更履歴を把握できなくなるおそれがあります。アカウントの所有者、管理者権限の付与先、請求情報の確認者を本社側でも管理します。

本番切り替えでは、移行の開始、継続、切り戻しを判断する責任者も定めます。事業部門や経営側の承認が必要な場合は、その経路も事前に決めます。

現地法人が担当する範囲

タイ現地法人は、現地の業務や利用環境を把握し、本社や支援会社へ共有します。

• 現行システムの利用状況
• 利用者、業務時間、繁忙期
• 停止可能な日時
• 現地回線やネットワーク機器
• 現地ベンダーや通信事業者との調整
• 業務テスト
• 利用者への停止・再開案内
• 移行後の問い合わせ受付

本社側がシステム構成を管理していても、表計算ファイルによる連携、共有フォルダ、プリンター、工場設備、現地ベンダーのサービスなど、実際の利用方法までは把握できていないことがあります。業務上必要な接続先は現地側で洗い出します。

テスト移行では、ログイン、データ入力、帳票出力、外部サービスとの連携など、通常業務を再現して確認します。

外部支援会社へ依頼する範囲

外部支援会社には、技術調査、設計、構築、移行、運用支援を依頼できます。

• 現行環境とシステム依存関係の調査
• 移行方式と移行計画の策定
• AWSアカウントとネットワークの設計
• セキュリティ、監視、バックアップの設計
• AWS環境の構築
• サーバーやデータの移行
• テスト移行と本番切り替え
• 構成図や運用手順書の作成
• 移行後の監視と障害対応

移行目的、停止可能時間、業務要件、セキュリティ基準は自社側で判断します。支援会社には技術的な選択肢とリスクを提示してもらい、本社と現地法人が方針を決めます。

契約前には、対応範囲、本番切り替え時の役割、成果物、納品条件、移行後の運用範囲、障害時の責任分界を合意します。

タイのAWS移行支援会社を選ぶポイント

支援会社を選ぶ際は、AWS環境の構築力だけでなく、現行調査、本番切り替え、移行後の運用までの対応範囲を確認します。

タイ拠点の移行では、日本本社のセキュリティ・管理基準と、現地の業務要件やネットワーク環境を擦り合わせる必要があります。技術力や費用に加え、現地調整、本社への報告、成果物、責任分界まで比較します。

現行調査から移行後の運用まで対応できるか

AWS環境の設計・構築だけを依頼すると、現行システムの依存関係や、移行後の監視・障害対応が対象外になることがあります。

現行調査、移行方式の選定、ネットワーク設計、セキュリティ、監視、バックアップ、テスト移行、本番切り替え、切り戻しまで、どの工程を任せられるか確認します。

移行後の運用を別会社へ引き継ぐ場合は、構成図、設定情報、監視項目、バックアップ、障害対応手順が引き継がれる状態で納品されるかも確認が必要です。同じ会社へ運用まで依頼する場合も、移行作業と通常運用の責任範囲は分けて契約します。

タイ現地法人との調整を任せられるか

タイ拠点の移行では、現地の利用部門、IT担当者、通信事業者、既存ベンダーとの調整が発生します。日本側だけで計画すると、業務時間、回線状況、現地特有の利用方法が反映されないおそれがあります。

現地担当者へのヒアリング、機器・ネットワークの確認、停止日時やテスト日程の調整、本番切り替え時の進行管理まで対応できるかを確認します。

現地の通信事業者や既存ベンダーとの調整では、契約内容の確認、回線工事、機器設定、作業員の入館手続きなどが発生することがあります。日本語でプロジェクトを管理できても、タイ語や英語による現地調整を誰が担うかは別途確認が必要です。

あわせて、現地訪問の可否、対応言語、受付時間、担当拠点、再委託の有無も確認します。「タイ対応」や「日本語対応」だけでは、現地での作業や調整まで含まれるとは限りません。

日本本社への報告とガバナンスに対応できるか

日本本社がAWS環境を管理する場合は、構成、変更内容、障害、コストを継続的に把握できる体制が必要です。

日本語での進捗報告、構成図や設計書の提出、変更履歴の記録、障害報告、月次レポート、監査対応まで支援範囲に含まれるか確認します。

AWSアカウントや管理者権限を支援会社だけが保有する状態は避けます。アカウントの所有者、権限の付与先、設定情報、請求情報を自社でも管理し、契約終了後に引き継げる状態にします。

変更作業の承認者、緊急時に支援会社が実施できる範囲、事後報告でよい作業も事前に定めます。技術資格や移行実績だけでなく、日本本社の管理基準を現地運用へ反映できるかが選定基準になります。

タイのAWS移行・運用をサーバーワークスが支援

サーバーワークスは、オンプレミス環境からAWSへの移行に向けた現行調査、設計、構築、本番切り替えを支援しています。ネットワーク、セキュリティ、監視、バックアップまで含め、移行後の運用を前提としたAWS環境を設計します。

タイでのAWS活用については、現地対応と日本本社への報告を組み合わせた支援が可能です。移行対象や費用、期間、役割分担を整理できていない場合も、現行環境の確認から相談できます。

まとめ

タイでAWS移行を進める際は、現行環境の依存関係、ネットワーク、データ配置、停止時間、移行後の運用まで含めて計画します。

日本本社、タイ現地法人、支援会社の役割を分け、本番切り替えと切り戻しの判断基準も明確にしておく必要があります。

支援会社を選ぶ際は、AWS環境の構築だけでなく、現行調査、現地調整、本社報告、移行後の運用まで対応できるかを確認します。