アジア太平洋の拠点選びガイド

4拠点、料金は共通

仮想マシンに分割しない専有物理Mac miniです。チームの所在地や成果物の転送先をもとに拠点を選び、実際のネットワークで接続を確認しましょう。同じ構成なら、拠点が異なっても料金は変わりません。

シンガポール・日本(東京)・韓国(ソウル)・香港 M4構成は2種類 日・週・月・四半期

料金はすべてUSDです。各拠点は年間365日稼働しています。注文時の在庫状況はコンソールでご確認ください。

拠点一覧

構成は共通、ワークフローに近い拠点を選択

4拠点すべてでGNU Core M4とGNU Studio M4をご利用いただけます。注文ごとに専有物理マシン1台を割り当て、CPU・メモリ・ストレージを他の利用者と共有しません。

SG 東南アジアとの連携

シンガポール

東南アジアの開発チームにおすすめです。セルフホスト型CIランナー、依存関係のキャッシュ、日々のビルドを同じ拠点にまとめることで、異なる地域間のデータ転送を減らせます。

  • GNU Core M4M4 · 16GB RAM · 256GB SSD
    在庫あり
  • GNU Studio M4M4 · 24GB RAM · 512GB SSD
    在庫あり

追加オプション+1TB SSD、+2TB SSD、Thunderbolt 5による並列接続(各マシン)。複数台の並列接続をご希望の場合は、事前に接続方法をご確認ください。

選定前に、チームのオフィスネットワークからの操作感と、コードリポジトリや成果物ストレージからの転送速度をご確認ください。

シンガポールでレンタル
JP 日本市場向けワークフロー

日本(東京)

日本のチームとの共同作業、日本語ローカライズ、日本市場向けビルドに適しています。Xcodeのコンパイル、シミュレーターでの回帰テスト、成果物のアーカイブを1台で実行できます。

  • GNU Core M4M4 · 16GB RAM · 256GB SSD
    在庫あり
  • GNU Studio M4M4 · 24GB RAM · 512GB SSD
    在庫あり

追加オプション+1TB SSD、+2TB SSD、Thunderbolt 5による並列接続(各マシン)。追加SSDはビルドキャッシュや素材の保存先として利用できます。

拠点の場所によってApp Storeの審査基準が変わることはありません。また、現地のネットワークや実機、実際のユーザー環境でのテストに代わるものではありません。

東京でレンタル
KR 韓国市場・ゲーム配信

韓国(ソウル)

韓国チームが関わるゲーム配信、クライアントのビルド、ローカライズの回帰テストに適しています。UnityやFlutterのプロジェクトを拠点でビルドし、チームのリリース工程へ戻せます。

  • GNU Core M4M4 · 16GB RAM · 256GB SSD
    在庫あり
  • GNU Studio M4M4 · 24GB RAM · 512GB SSD
    在庫あり

追加オプション+1TB SSD、+2TB SSD、Thunderbolt 5による並列接続(各マシン)。大規模なプロジェクトでは、素材・キャッシュ・出力先に必要な容量を事前に確認してください。

対話的なデバッグが中心なら、普段使うオフィスネットワークから接続をテストしましょう。地図上の距離だけで拠点を決めないでください。

ソウルでレンタル
HK 中華圏のチーム連携

香港

複数地域にまたがるチームのリモート開発や音声・動画の共同作業に適しています。大量のトランスコードはクラウド上で実行し、完成データをSFTPで転送すれば、長時間の画面接続を避けられます。

  • GNU Core M4M4 · 16GB RAM · 256GB SSD
    在庫あり
  • GNU Studio M4M4 · 24GB RAM · 512GB SSD
    在庫あり

追加オプション+1TB SSD、+2TB SSD、Thunderbolt 5による並列接続(各マシン)。素材が多い場合は、プロジェクトデータとシステムディスクを分けて管理しましょう。

通信事業者によって接続品質は異なる場合があります。オフィスの固定回線、自宅のネットワーク、モバイル回線でそれぞれ確認してください。

香港でレンタル

「在庫あり」は、通常注文できる状態を示します。実際の提供状況や追加オプションはコンソールでご確認ください。本ページでは、推定レイテンシや過去の測定データは掲載していません。

主な利用者を確認

拠点選びの目安。実際の回線テストも必要です

チーム内のすべてのタスクを同じ拠点に集約する必要はありません。手動操作では接続の操作感、自動ビルドではリポジトリや成果物の転送経路、市場適応ではテスト環境をそれぞれ確認しましょう。

主なワークフローから拠点を選ぶ
主な用途おすすめの拠点選定のポイント契約前の確認事項
東南アジア向けサービスシンガポール開発メンバー、コードサービス、成果物の受取先が東南アジアに集中している場合は、まずテスト拠点としてお試しください。チームが普段使うネットワークから接続し、依存関係のダウンロードと成果物のアップロード経路を確認してください。
日本のApp Store審査準備・ローカライズテスト日本(東京)日本のチームとの連携やビルド環境の一元管理に便利です。拠点の場所が審査結果を保証するものではありません。言語、タイムゾーン、シミュレーター、実機でのテスト要件を確認し、ビルド環境と市場向けネットワーク環境を分けて考えてください。
韓国市場・ゲーム配信韓国(ソウル)韓国メンバーが参加するビルド、アセット処理、ローカライズの回帰テストに適しています。大容量プロジェクトの同期と、クライアントから実際のサービスへ接続する際のネットワーク環境を確認してください。
複数地域にまたがるチーム連携香港複数地域のメンバーが共同で使うビルド・トランスコード拠点の候補として適しています。各地域の利用者がそれぞれテストしてください。一人の結果だけでチーム全体の接続品質を判断しないようにしましょう。
接続テスト

普段使う回線をテストしてから、長期利用する拠点を決める

リモート画面共有では映像と入力操作を継続的にやり取りするため、往復遅延、ジッター、パケットロスの影響を受けやすくなります。SSHでビルドを実行する場合は常時映像を送る必要はありませんが、依存関係や成果物の転送速度は実際の帯域に左右されます。

画面共有:操作の応答性を確認

長期利用する予定のネットワークから、まずコンソールの速度テストで候補拠点を確認してください。マシンの利用開始後は、実際のクライアントで入力やウィンドウの移動、エディターのスクロールを試しましょう。

映像は鮮明でも時々止まる場合、回線のジッターが原因かもしれません。転送が継続的に遅い場合は、ローカルの上り・下り速度やバックグラウンドの同期処理も確認してください。解像度を下げると映像データ量を減らせますが、回線の往復遅延は解消されません。

自動ビルド:一連の転送経路を確認

マシンまでの接続だけをテストしても十分ではありません。CIの実行にはリポジトリの取得、依存関係のダウンロード、キャッシュの読み込み、成果物のアップロードが含まれます。各サービスの設置場所によって、実際の待ち時間は変わります。

クリーンビルドとキャッシュを利用したビルドをそれぞれ1回記録し、ダウンロード、コンパイル、アップロードの各段階を確認してください。コンパイルが安定していてアップロードが遅い場合は、マシンのメモリを原因と決めつけず、まず成果物の転送経路を調べましょう。

  1. 01

    普段使うネットワークでテスト

    一時的なテザリングではなく、普段のオフィスや自宅のネットワークからコンソールの速度テストを実行してください。複数人が利用する場合は、主な利用者がそれぞれ確認しましょう。

  2. 02

    普段使う時間帯に確認

    実際の業務時間帯に繰り返しテストし、遅延の変動や接続の安定性を確認してください。1回の結果はその時点の回線状態を示すもので、利用期間全体を保証するものではありません。

  3. 03

    結果をまとめて問い合わせ

    問題が見つかった場合は、拠点、テスト日時とタイムゾーン、クライアントの種類、発生した現象を記録してください。注文済みの場合はコンソールにログインしてチケットを送信してください。メールでパスワードや秘密鍵を送らないでください。

複数拠点での運用

各マシンの役割を明確にする

拠点ごとのインスタンスは独立したマシンで、ディスク、ビルドキャッシュ、プロジェクトファイルは自動共有されません。複数台を導入する前に、命名規則や環境設定、データの転送方法を決めておくと、「どのマシンに成果物があるか」を後から探す手間を減らせます。

01 / 命名

拠点と用途がわかる名前に

「拠点コード-プロジェクト-用途-連番」の命名規則をチームで決めます。たとえば jp-mobile-build-01のようにします。自社のインスタンス管理表にはコンソールのインスタンスID、担当者、用途も記録し、IPアドレスだけでマシンを見分けないようにしましょう。

これは運用管理の推奨事項であり、ホスト名の初期設定ではありません。拠点や用途を変更した際は、CIランナーのラベルと社内記録も更新してください。

02 / 環境

ツールチェーンを統一し、認証情報を分離

macOS、Xcode、依存ツール、ビルドスクリプトのバージョンをプロジェクトの記録に残してください。まず1台で検証し、同じ手順で他の拠点にも設定すると、手作業による環境差を防げます。

アクセスキーはマシンごとに設定し、タスクに応じてリポジトリや成果物ディレクトリへの権限を付与してください。署名用データ、パスワード、秘密鍵をコードリポジトリに登録しないでください。

03 / データ

成果物を転送し、更新は1台ずつ確認

ビルド後は、成果物やログ、必要な設定のバックアップをチーム管理のストレージに転送してください。追加SSDはそのマシン内のストレージ拡張用であり、拠点間の共有ディスクやバックアップサービスではありません。

コンソールで各マシンの契約期間と有効期限を確認してください。拠点を変更する場合は、新しいインスタンスへの移行として扱います。返却前に必要なデータをエクスポートしてください。返却後はシステムディスクと追加SSDのデータが消去されます。

拠点を選び、構成と利用期間を確認

4拠点共通の料金です。軽めのビルドには16GB構成、複数のシミュレーターや推論タスクには24GB構成をご検討ください。素材やキャッシュが多い場合は、追加SSDも別途ご計画ください。