クラウドMacの専用物理ノードに関する接続、ビルド、ネットワーク、ストレージ、請求の問題に対応します。エラーメッセージ、ツール名、請求項目を入力すると、最も関連性の高い対応手順を案内します。
対象を確認ノード、アカウント、注文、ビルドタスク
証拠を保存時刻、コマンド、エラー行、マスキング済みログ
範囲を絞るネットワーク、認証情報、ディスク、ツールチェーン
接続失敗が必ずしもネットワーク原因とは限らず、ビルド失敗が必ずしもXcode原因とも限りません。まずタスクに合う入口を選び、その問題を切り分ける証拠を確認してください。
ノードアドレス、ポート、クライアント側ネットワーク、ホスト検証、リモートMacデスクトップの設定を確認します。タイムアウト、画面が真っ黒になる、クリップボードの同期不良、入力遅延に適しています。
接続の確認手順を見るログイン用メールアドレス、インスタンスの所有先、仮認証情報が更新済みか、コマンドやディレクトリに必要なローカル権限を確認します。サポート情報にパスワードを記載しないでください。
権限の確認項目を見るXcodeのパス、SDK、Scheme、ワークスペース、依存関係キャッシュ、ディスク容量を確認し、xcodebuildの完全な終了コードと最初のエラー位置を保存します。
ビルド診断の方法を見るRuby環境、Bundler、laneの引数、環境変数、署名素材の問題を切り分けます。最後の1行だけでなく、失敗したステップ名を優先して記録してください。
自動化ログの確認ポイントを見る遅延、ジッター、パケットロス、対象ポートへの接続性を個別に測定します。1回のpingだけで回線を判断せず、ローカルネットワークと別の接続回線も比較してください。
ネットワーク測定の順序を見る基本プラン、利用期間、ノード、ストレージ拡張、Thunderbolt 5の並列接続項目を区別し、注文確認ページと請求書の各金額を照合します。
請求の確認方法を見る以下の6つのパスは同じページに表示されます。分類ボタンは移動と強調表示だけを行い、他の内容を隠しません。関連する問題を横断して確認できます。
まずコンソールでインスタンスが接続可能な状態か確認し、ノードアドレスとポートを一字ずつ照合します。続いてローカルからポート接続テストを実行してください。ポートに到達できない場合は、ローカルネットワークを一度切り替え、ノードの問題か接続回線の問題かを切り分けます。SSHの初回接続ではホストフィンガープリントを確認し、認証に失敗する場合はユーザー名、鍵のパス、ファイル権限を確認します。GUIセッション確立後に画面が真っ黒になる場合は、まず解像度と視覚効果を下げ、既存のセッションを切断して再接続してください。
失敗がコンソールへのログイン、ローカルログイン、または特定コマンドの権限確認のどこで発生したかを切り分けます。コンソールでは注文、インスタンス、請求、チケットを確認できます。ノード内のローカル権限は、現在のユーザー、ディレクトリ所有者、コマンドの要件によって決まります。 Permission deniedが表示された場合は、対象パス、実行したコマンド、現在のユーザーを記録し、プロジェクトディレクトリ全体の権限を繰り返し変更しないでください。仮認証情報で初回ログインした後は速やかに更新し、共有デバイスに接続情報を保存しないでください。
whoami、pwd およびディレクトリ権限情報で実行コンテキストを確認する。コマンドをプロジェクトのルートディレクトリで実行していることを確認し、 .xcodeproj と .xcworkspaceを区別します。続いてXcodeの選択パスと利用可能なSDKを出力し、Schemeが共有されているか、名前の大文字・小文字が一致しているかを確認します。依存関係の更新後に問題が発生した場合、最初にすべてのキャッシュを削除しないでください。初回の失敗ログを保存し、最初の明確なエラーを特定してから、DerivedDataを消去するか依存関係を再解析するか判断します。
プロジェクトの取り決めがシステムコマンドか bundle exec fastlaneのどちらかを確認し、Ruby、Bundler、Gemfile.lockの対応関係を確認します。ログの最後の行は単なる処理終了の通知であることが多く、実際の原因はそれより前に現れます。最初のエラーブロックから上方向にコンテキストを保存し、失敗したlane、action、引数の出所を明記してください。環境変数は名前と存在の有無だけを提出し、実際の値は提出しないでください。
リモート操作の快適さは、遅延、ジッター、パケットロス、利用可能な帯域幅に左右されます。まず普段利用する場所から、シンガポール、東京、ソウル、香港の各ノードを個別にテストし、中央値の遅延が低くジッターの小さい経路を選びます。テスト時はローカルネットワーク、時間帯、サンプル数を固定してください。無線ネットワークの結果が大きく変動する場合は、有線または別の接続回線で再測定します。GUIセッションでは解像度、色品質、視覚効果を下げ、コマンドや長時間タスクはSSHに振り分けることを優先します。
請求は注文確認ページを1行ずつ照合します。まずGPUMini M4 CoreまたはGPUMini M4 Plusを確認し、日、週、月、四半期から選択した期間、対象ノード、ストレージ拡張やThunderbolt 5並列接続の追加有無を確認してください。請求総額だけを比較しないでください。同じ総額でも、期間と追加項目の組み合わせが異なる場合があります。すべての金額は米ドル建てで、利用できる支払い方法はUSDT-TRC20、またはStripe経由のVisa、Mastercard、Amexです。実際に利用できる決済ゲートウェイは決済画面の表示に従います。
SSH、xcodebuild、Fastlaneの末尾には「タスクに失敗しました」とだけ表示されることがあります。判断に使える情報は通常、最初のエラー位置とその前後数行にあります。
$ ssh -v build@node.example
debug1: Connecting to node [port 22]
debug1: Server host key verified
Permission denied (publickey).
↑ よくある失敗箇所：ユーザー名、鍵のパス、鍵の権限
$ xcodebuild -workspace App.xcworkspace -scheme App build
Resolve Package Graph
xcodebuild: error: The workspace does not contain scheme "App".
↑ よくある失敗箇所：ワークスペースの選択、Schemeの共有設定
$ bundle exec fastlane build
[build] Running gym
Exit status: 65
↑ 上方向にある最初のxcodebuildエラーブロックを確認ユーザー名、対象ノード、ポート、ホスト検証の結果、完全なエラー行を提出してください。秘密鍵の内容をログやチケットに記載しないでください。
作業ディレクトリ、workspaceまたはproject、Scheme、destination、Xcodeのバージョン、終了コードを提出してください。
lane、action、依存関係のバージョン、最初のエラーブロックを提出してください。環境変数は名前と存在の有無だけを記載します。
各ステップを完了して結果を記録してから次へ進みます。複数の設定を一度に変更すると問題が一時的に解消しても、本当の原因を特定できません。
コンソールにログインしてインスタンス、ノードコード、現在の状態を確認し、正しい注文を表示していることを確認します。シンガポール、東京、ソウル、香港はいずれも通常利用できるノードですが、実際の利用可否はコンソールの最新表示に従います。
DNS解決、対象ポート、遅延、ジッター、パケットロスを確認し、別の接続回線でも再測定します。ポートに到達できない場合と認証に失敗する場合は別の問題であり、同じ方法で対処しないでください。
ユーザー名、鍵のパス、ファイル権限、ホストフィンガープリントを一字ずつ照合します。何度も失敗したからといって、すべての認証情報を無計画に交換したり、パスワードや秘密鍵をサポートチームに送ったりしないでください。
システムボリュームの空き容量、DerivedData、依存関係キャッシュ、アーカイブ生成物、一時ディレクトリを確認します。ディスク容量の逼迫は、ビルドの中断、書き出しの失敗、ツールの異常終了として現れることがあります。
最初の明確なエラーの前後にログのコンテキストを広げ、コマンド、ディレクトリ、ツールのバージョン、終了コード、再現手順を記録します。最後の1行だけでは通常、問題を特定できません。
GPUMiniの4つのノードは年間365日、通常どおり稼働しています。突発的なノードインシデントが発生した場合は、影響を受けたノード、開始時刻、現在の影響、対応状況、復旧結果を中心にステータス情報を更新します。個々のユーザーのネットワーク、認証情報、ディスク、プロジェクト設定の問題を、サービス全体のインシデントとして扱うことはありません。
ステータスを確認する際は、まずノードコードとインスタンスの状態を確認し、自分が観測した時間帯と比較してください。問題が続いている場合、「接続できない」だけを送らず、ローカルの接続地域、接続方法、完全なエラー、初回発生時刻、直近の再現時刻を添えてください。
サポートへの連絡が必要か判断するには：ノード、ネットワーク、認証情報、ディスク、ログを確認しても同じ問題を安定して再現できる場合、または注文と請求項目に明確な差異がある場合は、チケットを送信してください。一般的な問い合わせは support@gpumini.comまでメールでご連絡いただけます。
技術的な問題には、ノード、発生時刻、再現手順、マスキング済みログの4点が基本情報として必要です。請求に関する問題では、注文番号と確認対象の請求行も必要です。
チケットは現在のアカウントにある注文やインスタンスと紐付けられるため、ノードの状態、請求項目の確認、継続的な対応が必要な技術問題に適しています。
メールを送る前に、ワークロード、対象ノード、利用期間、同時ビルド数、メモリ、ストレージの要件を整理してください。技術的な問題でも、パスワードや秘密鍵は添付しないでください。
技術的な問題にはノード、時刻、再現手順、マスキング済みログを準備してください。注文、インスタンス、請求に関する問題は、まずコンソールチケットで関連付けて対応します。