サポートセンター

クラウドMacに問題が発生?まずはマニュアルで自己解決、無理なら私たちを呼んでください

接続できない、再インストールしたい、CIでエラーが出る——こうした問題の大半は、以下の手順に従えば5分以内に自己解決できます。人的サポートが必要な場合も、チケットとメールサポートは年中無休で対応。緊急障害は24時間365日体制で応答します。

チケットを発行(緊急時は優先対応) よくある質問を見る
4つのサポート窓口

緊急度に応じて、最速の窓口を選んでください

セルフヘルプドキュメントが最速、チケットは対応範囲が最も広く、メールは記録を残すのに適しています。ステータスページでまず「プラットフォーム側の問題かどうか」を確認できます。

ドキュメントセンター

このページには入門ガイド、再インストール、CI/CD、トラブルシューティングのマニュアルをまとめています。コマンドをコピーしてすぐに使えます。

このまま下にスクロール →

チケットシステム

コンソールにログインしてチケットを発行すると、お使いのマシン情報が自動的に関連付けられます。緊急障害の場合は優先対応を選択できます。

コンソールでチケットを発行 →

メールサポート

support@hirevps.com — スクリーンショットやログなど、記録が必要な問題の添付に適しています。

メールを送る →

ステータスページ

各ノードのリアルタイムの可用性が一目でわかります。障害報告の前に確認すれば、余計な手間を省けます。

リアルタイムステータスを見る →
クイックスタート

認証情報を受け取ってからの最初の10分間

契約完了から2分以内に、コンソールとメールにSSH/VNCの認証情報が届きます。以下の3ステップに従えば、10分以内にデスクトップに入って作業を始められます。

1. 初回SSHログイン

認証情報に記載されているホスト名は jp1-1024.hirevps.com のような形式です。標準搭載のターミナルからそのまま接続できます:

# replace host and user with your credentials
ssh omac@jp1-1024.hirevps.com
# first login: change your password
passwd

ログイン後はすぐにパスワードを変更し、コンソールでSSH公開鍵をアップロードしてパスワードログインを無効にすることをおすすめします。安全性が高まり、手間も減ります。

2. VNC/画面共有を有効にする

提供時には画面共有がデフォルトで有効になっています。手動でオフにした場合も、SSH接続後にコマンド1つで再度有効化できます:

# enable macOS remote management (screen sharing)
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
  -activate -configure -access -on -restart -agent

Macでは「画面共有」アプリを、Windows/Linuxでは任意のVNCクライアントを使用してください。接続先にホスト名、ポート番号に5900を指定します。

3. 開発環境セルフチェックリスト

  • 提供イメージにはHomebrew、Git、Xcode Command Line Toolsがプリインストールされています。ターミナルで xcodebuild -version と brew --version を実行してバージョンを確認してください。
  • CI/CD用途では、まず一度フルビルドを実行してベースラインを記録しておきましょう。コールドスタートとインクリメンタルビルドの所要時間を記録しておくと、後でパフォーマンス問題を調査する際の比較対象になります。
  • 証明書と鍵は専用のキーチェーンに保管し、ビルドスクリプト内で明示的にロック解除することをおすすめします。GUIセッションがロックされた状態での署名失敗を防げます。
  • 契約終了前に、コードとビルド成果物をリポジトリまたはオブジェクトストレージに同期してください——データ消去後は復元できません(データの範囲については利用規約をご確認ください)。
よくある操作

再インストール、バージョン変更、データ移行——すべてコンソールの数クリックで完了

これら3つの操作はすべてセルフサービスで完結し、チケット発行は不要です。再インストールとバージョン変更は無料・無制限で何度でも行えます。

macOSの再インストール

コンソール → お使いのインスタンス → 「システム再インストール」からバージョンを選択して確定するだけです。全体の所要時間は約15〜25分です(実際の環境により異なります)。

再インストールを実行するとSSD全体のデータが消去されます。事前に必ずコードをリモートリポジトリへプッシュし、ビルド成果物をコピーしてから確定してください。

OSバージョンの変更

現行の正式リリース版と1つ前のメジャーバージョン(Sequoia / Sonomaなど)から選択できます。一部のノードではベータ版イメージも提供していますので、詳細はコンソールのリストをご確認ください。

バージョン変更も再インストールと同じ処理のため、同様にディスクが消去されます。複数バージョンでの互換性テストを行う場合は、日単位で別インスタンスを新たに立ち上げ、テスト完了後に解約する方法をおすすめします。

スナップショットとデータ移行

再インストール前にはAPFSのローカルスナップショットで保険をかけられます。マシン間の移行には rsync の利用をおすすめします:

# create a local snapshot before risky changes
tmutil localsnapshot
# sync your workspace to the new machine
rsync -avz ~/work/ omac@new-host:~/work/

当社はお客様のマシン内のデータを読み取ったり、バックアップしたりすることはありません(プライバシーポリシー参照)。重要なデータは定期的にリモートリポジトリまたはオブジェクトストレージへ同期してください——ローカルスナップショットも再インストール後には消去されます。

CI/CD連携

このMacをビルドノードに

専有物理専用サーバー+root権限があれば、主要なCIツールへの連携は公式標準の手順そのまま。独自の改変は一切不要です。お使いのツールを選んでください:

セルフホストランナーの連携

リポジトリまたは組織のActions設定ページで「New self-hosted runner(macOS / ARM64)」を選択し、表示されるダウンロード・設定コマンドをクラウドMacのターミナルに貼り付けて実行してください:

# run these on your cloud Mac (values come from your Actions settings page)
./config.sh --url <your-repo-url> --token <runner-token> \
  --labels macos,arm64,hirevps
# install as a service so it survives reboots
./svc.sh install && ./svc.sh start

ワークフローの runs-on を [self-hosted, macos, arm64] に変更するだけです。M4物理専用サーバーでの xcodebuild 実行は、ホスト型ランナーよりも大幅に高速な場合が多いですが、実際の差はプロジェクトによって異なります。

トラブルシューティング

頻発する3つの問題、まずはリストで自己診断

チケットを発行する前に、対応するリストを2分ほどかけて確認してみてください——半数以上の障害報告はステップ2で解決しています。

マシンに接続できない(SSHタイムアウト / VNCが真っ黒な画面)
  1. ステータスページを開いて、お使いのノードが正常に稼働しているか確認してください——正常であれば、問題はお客様側にある可能性が高いです。
  2. ローカルで ping コマンドを実行してホスト名に到達できるか確認してください。スマートフォンのテザリングに切り替えて再度試すと、社内ネットワークやプロバイダによる22/5900番ポートのブロックを排除できます。
  3. コンソールでインスタンスの状態を確認してください:「稼働中」と表示されている場合は、まずコンソールの「リモート再起動」を試してください。起動処理で止まっている場合は3分ほど待って再度確認してください。
  4. SSHポートやファイアウォールルール(pfctl)を変更した記憶がないか確認してください——これは自分自身を締め出してしまう最も一般的な原因です。コンソールの「レスキューターミナル」を使えば、ネットワークを経由せずに直接システムに入って設定を元に戻せます。
  5. 上記をすべて試しても接続できない場合は、チケットで「接続不可」にチェックを入れて発行してください。P1として対応します。
ビルドが遅くなった(xcodebuildの所要時間が明らかに増加)
  1. まずタスク自体に変化がなかったか確認してください:依存関係の更新やXcodeのメジャーバージョンアップ後の初回ビルドでは、インデックスとキャッシュの再構築が発生するため、一度だけ遅くなるのは正常です。
  2. top -o cpu で暴走しているプロセスがないか確認してください。Spotlightの初回インデックス作成はCPUを占有します。mdutil -a -i off で無効化できます。
  3. DerivedDataがCIの実行ごとにクリアされていないか確認してください——キャッシュディレクトリを保持しておくと、インクリメンタルビルドの時間を大幅に短縮できることが多いです。
  4. df -h でディスクの空き容量を確認してください:SSDの使用率が90%を超えると書き込み性能が低下します。まずディスクを整理してから比較してください。
  5. お使いのマシンは専有物理専用サーバーのため、他ユーザーとのリソース競合はありません。上記の要因をすべて排除してもなお遅くなり続ける場合は、前後2回分のビルドログを添えてチケットを発行してください。ハードウェアレイヤーを調査します。
ディスクがいっぱいになった(No space left on device)
  1. まず容量を大きく占めているものを探しましょう:du -sh ~/Library/Developer/* ——XcodeのDerivedData、古いシミュレータのランタイム、Archivesが最も多くの容量を占めることが多いです。
  2. 安全に削除できるもの:rm -rf ~/Library/Developer/Xcode/DerivedData。使用していないシミュレータランタイムの削除には xcrun simctl runtime delete を使用してください。
  3. APFSのローカルスナップショットも容量を消費します:tmutil listlocalsnapshots / で確認し、tmutil deletelocalsnapshots で古いスナップショットを削除してください。
  4. CI用マシンでは、パイプラインに定期的なクリーンアップ処理を組み込んでおくことをおすすめします。容量が満杯になってから対処するのではなく、事前に対策しておきましょう。
  5. クリーンアップしてもなお容量が不足する場合は、アップグレードのタイミングです——SSDのアップグレードは差額のみのお支払いで済みます。データ移行方法は上記のマニュアルをご参照いただくか、プランページで大容量のプランを直接選択してください。
SLAと対応時間

明文化された対応保証

チケットは影響範囲に応じて3段階に分類されます。分類はチケット発行時にお客様が選択し、当社が確認・承認します。実現可能な内容のみをお約束しています。

チケットの分類と対応時間の対照表
レベル 典型的なケース 初回応答 対応時間帯
P1(緊急) マシンに接続できない、ハードウェア障害、ノード利用不可 30分以内 24時間365日
P2(機能低下) パフォーマンス異常、再インストールが途中で停止、ネットワークの断続的な不安定化 4時間以内 24時間365日
P3(通常) 利用に関するお問い合わせ、請求に関する質問、設定に関するご相談 12時間以内 平日

可用性と補償のルール

  • 単一インスタンスの月間可用性保証は99.9%です。すべてのノードは年間365日連続稼働し、計画停止時間は設けていません。
  • 実測の可用性が保証値を0.1%下回るごとに、当月の利用料金の5%相当のクーポンを補償として発行します。月間の補償上限は当該インスタンスの当月利用料金の100%です。
  • 補償の申請はコンソールから行えます。障害発生時間帯を添えて申請すれば、当社が監視データと照合して算出し、7営業日以内にお客様のアカウントへ反映されます。
  • 不可抗力、またはお客様自身の操作(システムファイルの誤削除、ネットワーク設定の誤変更など)による利用不可は補償対象外です——ただし、その場合も復旧のサポートは行います。

最速で対応してもらうためのチケット発行方法

  • コンソールにログインしてチケットを発行してください。システムが自動的にマシン番号とノード情報を添付するため、メールでのやり取りより手間が省けます。
  • 「いつ・何をしたか・どのようなエラーが出たか」を明確に記載し、スクリーンショットではなく完全なエラーテキストを貼り付けてください。原因特定の時間を大幅に短縮できます。
  • P1の問題は、チケット内で直接「緊急」にチェックを入れてください。メールでの連絡は避けてください——メールはP3の対応時間で処理されます。
  • 補償条項の詳細は利用規約をご確認ください。規約の記載内容が最終的な基準となります。
年間365日稼働・計画停止なし

サービスステータスとお知らせを1ページで確認

東京、シンガポール、ソウル、香港、米国西部の5拠点のリアルタイム可用性、履歴データ、イベント告知はすべてステータスページで公開しています。サービスに影響を及ぼす事象が発生した場合も、進捗は同じページで継続的に更新されます。障害報告の前にまずこちらを確認すれば、「プラットフォーム側の問題」か「お客様側の問題」かを即座に見分けられます。

リアルタイムステータスページを開く コンソールでイベント通知を購読
  • JP 東京リアルタイムの可用性と履歴グラフはステータスページをご覧ください
  • SG シンガポールリアルタイムの可用性と履歴グラフはステータスページをご覧ください
  • US-W 米国西部リアルタイムの可用性と履歴グラフはステータスページをご覧ください

マニュアルに該当する解決策が見つかりませんか?

コンソールにログインしてチケットを発行し、エラーの原文を貼り付けてください。あとは私たちにお任せください。

コンソールでチケットを発行