タスク別に問題を特定

エラーの発生から実行可能な切り分け手順へ

VMMiniクラウドMacの専用物理ノードにおける初回接続、SSHキー、VNC、MLX推論サービス、CI、注文の問題を扱います。まず現象に応じて基本確認を行い、ログと発生時間を添えてサポートを依頼してください。

このページでパスワード、秘密鍵、リカバリーフレーズを求めることはありません。既存の注文に関する問題は、コンソールからサポート依頼を送ると注文とノードの記録を自動で関連付けられます。

サポート実行フロー まず特定、次に収集、最後に送信
明確な手順
03 トラブルシューティング段階
現象 接続、ビルド、ディスク、サービス、注文
証拠 時間、コマンド、終了コード、マスキング済みログ
対応 自己解決または注文に関連付けて依頼
ノード対象地域 シンガポール・日本(東京)・韓国(ソウル)・香港
クイック検索

エラー情報、ツール名、タスクの目的を入力

検索では、このページのガイド、障害の振り分け、用語解説が対象になります。注文番号、ホスト名、アドレスを含むエラーは、先に機密情報を隠してから入力してください。

接続とアクセス

提供情報を確認してから接続方法を判断

接続問題は、アドレス、ポート、鍵の権限、クライアントのキャッシュ、ローカルネットワーク経路が原因で発生します。ホストフィンガープリントを確認するまで検証を省略しないでください。

SSH:ホストフィンガープリントから確認

提供されたホストアドレス、SSHポート、ユーザー名、対応する公開鍵の秘密鍵ファイルを準備します。秘密鍵は管理された端末または鍵管理ツールにのみ保存し、サポート依頼に貼り付けないでください。

  1. 初回接続:コンソールに表示されたホストフィンガープリントとクライアントの警告を一つずつ照合します。
  2. 権限確認:秘密鍵ファイルが現在のユーザーだけに読み取り可能で、公開鍵の改行が壊れていないことを確認します。
  3. 切断の切り分け:ローカルネットワーク、DNSまたはアドレス、ポートへの到達性、ユーザー名と鍵の対応を順に確認します。
  4. 証拠の収集:時刻付きの詳細モード出力を保存し、アドレス、ユーザー名、鍵のパスに含まれる機密部分を削除します。
ssh -vvv -p <port> <user>@<host>

VNC:セッションと表示状態を確認

ノードアドレス、ポート、接続認証情報、利用可能なグラフィカルセッションが必要です。認証情報はパスワード管理ツールに保存し、スクリプトリポジトリやビルドログに記載しないでください。

  1. 初回ログイン:OSバージョン、ディスク容量、タイムゾーン、キーボードレイアウト、現在のネットワーク状態を確認します。
  2. ブラックスクリーン:まずグラフィカルセッションが実行中であることを確認し、次にクライアントの色深度と拡大縮小設定を確認します。
  3. 頻繁な切断:発生時刻、継続時間、ローカルネットワークの種類、同時にSSHでアクセスできるかを記録します。
  4. 画面の遅延:表示品質を下げて比較テストを行い、クライアントの一時的な遅延だけでノード障害と判断しないでください。

リモートデスクトップ:クライアントとノードを分けて検証

使用するクライアントが提供された接続方式に対応していることを確認し、アドレス、ポート、セッション認証情報を照合します。無効になった古い認証情報を繰り返し試さないでください。

  1. ローカル側:プロキシを無効にするかネットワークを切り替えて比較し、クライアントのバージョンとエラー原文を記録します。
  2. ノード側:SSHが使える場合は、グラフィカルサービスのプロセス、ディスク空き容量、システム負荷を確認します。
  3. 経路側:異なるネットワークで接続結果を比較し、問題が単一の経路だけで発生しているか確認します。
  4. サポート依頼:注文ID、ノード、発生時刻、機密情報を隠したスクリーンショットを提供し、接続パスワードは送らないでください。
MLX推論サポート

5つのチェックポイントでモデルサービスを特定

まず実行環境とモデルファイルが完全であることを確認し、次にリッスンアドレス、ヘルスエンドポイント、ログを確認します。必要なポートだけを開き、接続元を制限してください。

01

環境を確認

macOSバージョン、Pythonバージョン、仮想環境のパス、MLX関連パッケージのバージョン、利用可能なディスク容量を記録します。タスクが共有環境の設定ではなく、VMMini M4、M4、16GB、256GB SSDの専用物理ノードで実行されていることを確認します。

02

モデルを準備

モデルファイルのパス、ファイル数、検証結果、必要容量を確認します。モデルとキャッシュは明確なディレクトリに置き、ダウンロード処理とサービスプロセスが同じ一時領域へ同時に書き込まないようにします。

03

リッスン状態を確認

まずローカルアドレスにバインドして検証し、実際のアクセス要件に応じてリッスン範囲を調整します。ポートが他のプロセスに使用されていないことを確認し、外部アクセスは必要なポートと接続元だけに限定します。

04

ヘルスチェックを実行

ノード上でヘルスエンドポイントを呼び出し、HTTPステータス、応答時間、レスポンス本文を記録します。ローカルでは正常で外部だけ失敗する場合は、モデルを再起動せず、ポート、アクセスルール、ネットワーク経路を確認します。

05

再現可能なログを収集

起動コマンドのマスキング済み版、標準出力、標準エラー、終了コード、モデル名、発生時刻を保存します。アクセス トークン、リクエスト本文、ユーザーデータが含まれる場合は、送信前に必ず削除します。

ローカルヘルスチェック

まずループバックアドレスでサービスを検証

実際のポートとヘルスパスをコマンドに置き換えます。ヘルスエンドポイントは軽量で安定し、完全な推論タスクを起動しないものにしてください。

curl --fail --show-error \
  --max-time 10 \
  http://127.0.0.1:<port>/health
CIサポート

runnerを取り消し可能・クリーンアップ可能・再現可能にする

self-hosted runnerは常駐プロセスだけではありません。登録、認証情報、キャッシュ、成果物、取り消し操作について、担当者と保持範囲を明確にする必要があります。

01

runnerを登録

専用のサービスアカウントと独立した作業ディレクトリを使用し、runner名、ラベル、所属プロジェクト、登録時刻を記録します。ラベルは実際の能力だけを表し、複数プロジェクトが同じ作業ディレクトリへ誤って割り当てられないようにします。

完了条件 キューからrunnerを識別でき、テストタスクが明確な終了コードを返す。
02

プロジェクト認証情報を分離

トークンをプロジェクトと環境ごとに分け、管理された鍵ストレージまたは実行時環境変数を優先します。長期認証情報をリポジトリ、runner設定のバックアップ、ダウンロード可能な成果物に保存しないでください。

完了条件 タスクログに秘密値が出力されず、1つのプロジェクトを取り消しても他のプロジェクトに影響しない。
03

ビルドキャッシュを管理

依存関係キャッシュ、DerivedData、一時ファイル、アーカイブに別々のディレクトリを設定します。ディスク容量が不足したら、まず増加元を確認してからプロジェクト単位で削除し、実行中のタスクが使用するディレクトリを直接削除しないでください。

完了条件 キャッシュパスを追跡でき、クリーンアップで最終成果物が削除されない。
04

ビルド成果物を保持

成果物にコミットバージョン、ビルド番号、ツールチェーンのバージョン、検証情報を記録します。タスク終了後、保持が必要なファイルをrunnerの作業ディレクトリから移動し、キャッシュのクリーンアップで削除されないようにします。

完了条件 失敗ログと成功した成果物を同じビルドに関連付けられる。
05

runnerを安全に取り消し

新しいタスクの受け付けを停止し、現在のジョブが終了するのを待ってから、プロジェクト側で登録トークンを取り消し、サービスを削除します。最後に、作業ディレクトリ、キャッシュ、認証情報が移行計画どおり処理されたことを確認します。

完了条件 管理側からタスクが割り当てられず、ノード上に再利用可能な登録認証情報が残っていない。
用語ミニ辞典

8つの用語の意味を統一

トラブルシューティングでは用語を統一し、ノード、ソフトウェア、ネットワーク、請求の問題を混同しないようにします。

物理ノード
注文に実際に割り当てられるMac Mini M4ホストです。クラウドMacのハードウェアノードであり、仮想マシンインスタンスではありません。
専用
注文は物理マシン全体のプロセッサ、メモリ、ローカルストレージを使用し、他のレンタル注文と同じ計算リソースを共有しません。
VNC
macOSのグラフィカルインターフェースへアクセスするリモート表示方式です。切り分けでは、グラフィカルセッション、クライアント、ネットワーク経路を分けて確認します。
self-hosted runner
チームが登録・管理するCI実行環境で、タスクの取得、ビルドの実行、ログと成果物の返送を担います。
MLX
Apple Silicon向けの機械学習ツール群で、モデル準備、推論実験、サービス化の検証に利用できます。
ビルドキャッシュ
再ダウンロードや再コンパイルを減らすために保持するデータで、依存関係キャッシュ、DerivedData、ツールが生成した中間ファイルが含まれます。
ノード
物理ホストが所在するサービス地域です。現在の一覧には、シンガポール、日本(東京)、韓国(ソウル)、香港の4ノードが含まれます。
請求サイクル
注文で選択する利用期間で、日、週、月、四半期単位で作成できます。期間、開始時刻、終了時刻はコンソールの注文記録に従います。
障害振り分けツリー

現象から次の手順を選び、複数の設定を同時に変更しない

一度に変更する条件は1つだけにして結果を記録します。複数の設定を一度にリセットすると障害の境界が失われ、サポートチームも再現できません。

NET ノードに接続できない タイムアウト、接続拒否、フィンガープリントの変更、認証情報の不一致
まず確認

注文が有効か、アドレスとポートが現在のノードに対応しているか、ローカルネットワークから対象ポートへ到達できるか、ユーザー名と鍵が一致するかを確認します。

情報を収集

発生時刻、クライアントバージョン、エラー原文、マスキング済みの詳細接続出力、ネットワーク切り替え後の比較結果。

サポート依頼のタイミング

2つの独立したネットワークから接続できない場合、またはホストフィンガープリントがコンソールの記録と一致しない場合は、試行を止めて依頼してください。

BLD ビルド失敗 依存関係の解決、コンパイル、署名手順、runnerジョブの異常
まず確認

コミット、ロックファイル、ツールチェーンのバージョン、環境変数、runnerラベル、作業ディレクトリが直近の成功ビルドと一致するか確認します。

情報を収集

完全な終了コード、失敗段階の前後のログ、ビルドコマンド、ツールバージョン、キャッシュ削除後の比較結果。

サポート依頼のタイミング

同じコミットと設定がクリーンな作業ディレクトリでも安定して失敗し、ログがノードのシステムまたはディスク異常を示す場合に依頼します。

DSK ディスク容量不足 モデル、ビルドキャッシュ、ログ、アーカイブが増え続けている
まず確認

ディレクトリごとの使用量を集計し、モデル、依存関係キャッシュ、DerivedData、ログ、一時ファイル、移動が必要な最終成果物を区別します。

情報を収集

ファイルシステムの空き容量、最大使用ディレクトリ、増加開始時刻、実行中のタスク、直近のクリーンアップ記録。

サポート依頼のタイミング

ファイルシステムのレポートとディレクトリ集計が大きく異なる場合、または削除可能な内容を削除しても空き容量が増えない場合に依頼します。

SRV サービスが応答しない プロセスは存在するが、ヘルスエンドポイントがタイムアウトするか外部からアクセスできない
まず確認

プロセスの状態、リッスンアドレス、ポート使用状況、ローカルヘルスチェック、利用可能メモリ、直近の標準エラー出力を確認します。

情報を収集

起動コマンドのマスキング済み版、プロセス終了コード、ローカルと外部のリクエスト結果、応答時間、サービスログの時間帯。

サポート依頼のタイミング

ローカルリクエストも失敗し、サービスログがシステムレベルの異常を示す場合、または複数サービスが同時に応答しなくなった場合に依頼します。

ORD コンソールの注文異常 注文状態、期間、ノード、請求記録が想定と異なる
まず確認

注文ID、選択したVMMini M4構成、ノード、請求サイクル、追加項目、支払い記録が同じ注文に属するか確認します。

情報を収集

注文ID、画面に表示された状態、発生時刻、操作手順、マスキング済みスクリーンショット。完全な支払い情報は送信しないでください。

サポート依頼のタイミング

更新して再ログインしても記録が一致しない場合、または注文操作を続行できない場合は、コンソールから関連付けた依頼を送信します。

サービス稼働方針

ノードは365日稼働し、イベントは注文記録で確認

VMMiniのノードは365日、通常稼働するよう設計されています。注文ごとの可用性とイベント記録は、コンソールのリアルタイム情報と関連記録に基づきます。

4ノードの稼働範囲 一覧のノードはいずれもVMMini M4の注文に利用できます。実際の利用可能状況はコンソールにリアルタイムで表示されます。
注文イベントを確認

シンガポール

東南アジアのチームやワークロードで、まずこの経路をテストできます。

日本(東京)

日本または東アジアのコードソースとの実測比較に適しています。

韓国(ソウル)

北東アジアからのアクセス経路の接続テストに適しています。

香港

華南および東南アジア経路の実測比較に利用できます。

サービスイベントかどうかの判断: まず2つの独立したネットワークで接続を再試行し、次にノード上のサービスとユーザーソフトウェアの状態を確認します。外部ネットワーク経路、ユーザー設定、単一プロセスの失敗を、物理ノードの利用不能と直接みなさないでください。
サポート依頼を送信

すぐに調査へ進める依頼に含める情報

既存の注文は、ノード、期間、イベント記録を関連付けられるコンソールのサポート依頼を優先してください。ログインできない場合は、support@vmmini.comでサービスチームに連絡できます。

依頼情報チェックリスト

6つの必須情報

アカウントキーは含めない
  1. 01
    注文ID

    コンソールの注文IDを提示し、スクリーンショットにある別の個人情報で代用しないでください。

  2. 02
    関連ノード

    シンガポール、日本(東京)、韓国(ソウル)、香港のいずれかと、対応するホストを明記します。

  3. 03
    発生時刻

    タイムゾーン、初回発生時刻、最後に再現した時刻、継続中かどうかを記載します。

  4. 04
    再現手順

    操作順にコマンド、入力条件、期待結果、実際の結果を列挙します。

  5. 05
    エラー原文

    終了コードと重要なコンテキストを残し、「使用できない」「ビルド失敗」だけで済ませないでください。

  6. 06
    マスキング済みログ

    パスワード、秘密鍵、アクセストークン、ユーザーデータ、不要な完全アドレスを削除してから添付します。

注文がない、またはログインできない場合

次のアドレスへメールを送信: support@vmmini.com件名に問題の種類を記載してください。メールにはノード、時刻、再現手順、マスキング済みログも含めてください。

連絡先を確認

送信してはいけない情報

パスワード、秘密鍵、アクセストークン、リカバリーフレーズ、完全な支払い情報、マスキングしていないユーザーデータ、問題に関係のないコードリポジトリの内容。

データプライバシーを読む
証拠をサポート依頼に添付

既存の注文なら、ノード記録に直接関連付けて調査を続行

注文ID、ノード、発生時刻、再現手順、マスキング済みログを準備します。コンソールのサポート依頼は技術・注文の問題に利用できます。購入前の問い合わせも、専用サポートメールで受け付けています。