インタラクティブなグラフィカルインターフェイス
- ネットワーク
- 往復遅延の中央値、ジッター、パケットロスを継続的に測定し、安定した有線ネットワークを優先します。
- 表示
- まず解像度と色品質を下げ、入力遅延も同時に改善するか確認します。
- セッション
- 重複するクライアントを閉じ、複数のグラフィカルセッションがエンコードリソースを奪い合っていないことを確認します。
実践的な診断手順
リモートMacに問題が発生したら、まず原因の層を特定
ノードの状態、接続情報、ローカルネットワーク、アクティブセッション、ディスク、タスクキューを順に確認します。各手順で確認条件、次の対応、提出すべき情報を示すため、「接続できない」「重い」だけで障害を説明せずに済みます。
問題の切り分け
症状に最も近い項目を選択
選択すると、該当する手順に直接移動します。複数の問題が同時に発生した場合は、まず「接続できない」を解決し、その後にパフォーマンス、ビルド、ディスクを確認してください。
症状がまだ選択されていません。
リモートデスクトップの確認
4つのチェック項目で接続条件を確認
各層の確認が完了してから次へ進んでください。ノードの状態が不明なままクライアント設定を繰り返し変更したり、複数のデバイスから同じセッションへ同時に接続したりしないでください。
-
01
ノードの状態を確認
コンソールにログインし、注文に対応する物理ノードの引き渡しが完了していること、ノード名と現在使用している接続情報が一致していることを確認します。状態が変化中の場合は、画面に表示された状態文を保存し、接続要求を連続して再送しないでください。
- 確認条件：正しい注文番号、ノード、接続先を確認できる。
- 異常時の情報：状態の原文、ページの時刻、ノード識別子を記録する。
-
02
接続情報を再取得
ホストアドレス、ユーザー名、一時認証情報が同じ注文に由来することを確認し、コピー時に前後の空白を含めないでください。認証情報を更新した直後は、古い接続ウィンドウを閉じ、新しい接続設定を作成します。
- 確認条件：クライアントに認証失敗や認証情報の形式エラーが表示されない。
- 禁止事項：パスワード、秘密鍵、リカバリコードを問い合わせ本文に貼り付けない。
-
03
クライアント側のネットワーク問題を切り分け
ルートを書き換えるローカルプロキシを一時的に無効にし、現在のネットワークと別の信頼できるネットワークでそれぞれテストします。名前解決、TCP接続の確立、連続プローブでのパケットロスを記録し、1回のping結果だけを残さないでください。
- 確認条件：連続プローブが安定し、ハンドシェイク中に接続がタイムアウトしない。
- 異常時の情報：ネットワーク種別、往復遅延の中央値、パケットロス率を記録する。
-
04
セッションの使用状況を確認
チームメンバーが同じグラフィカルセッションを同時に使用していないことを確認します。古いクライアントが異常終了した場合は、セッションが解放されるまで待ってから再接続します。接続情報が正しく、ネットワークに到達でき、古いセッションを復旧できない場合に限り、接続設定を再作成してください。
- 再作成が適切：クライアント設定の破損、解像度ネゴシエーションの継続的な失敗、古いセッション記録の無効化。
- 再作成が不適切：ノードに到達できない、注文情報が一致しない、ローカルネットワークでパケットロスが続く。
接続復旧後にもう一度確認：
macOSのグラフィカルインターフェイスを開き、切断と再接続を1回実行します。キーボードレイアウト、表示倍率、クリップボードの動作が想定どおりであることを確認してから、ビルドや推論タスクを再開してください。
ノード間の往復遅延の目安
5ノードの遅延プローブ中央値
以下は固定回線のプローブから各ノードへのICMP往復遅延の中央値です。経路比較用であり、特定ユーザーのネットワーク環境での実測値を示すものではありません。
プローブネットワーク
地域固定回線、単一出口
測定時間帯
UTC 14:00–16:00
サンプリング方法
各経路60回、中央値
数値の単位
ミリ秒 RTT
| 測定元 | シンガポール | 日本（東京） | 韓国（ソウル） | 香港 | 米国西部 |
|---|---|---|---|---|---|
| シンガポール | 8 ms | 72 ms | 83 ms | 36 ms | 171 ms |
| 日本（東京） | 70 ms | 7 ms | 31 ms | 48 ms | 104 ms |
| 韓国（ソウル） | 82 ms | 32 ms | 6 ms | 43 ms | 126 ms |
| 香港 | 35 ms | 47 ms | 42 ms | 6 ms | 148 ms |
| 米国西部 | 169 ms | 103 ms | 124 ms | 146 ms | 9 ms |
表の見方：リモートデスクトップは、安定した往復経路の影響を受けやすくなります。中央値が低くても断続的にパケットロスが発生する経路は、中央値がやや高くても安定した経路より体感が悪くなる場合があります。
前提条件：プローブはユーザーのローカルWi-Fi、プロキシ、企業ネットワークの出口を経由しません。通信事業者間の接続、時間帯による混雑、無線干渉、クライアントの負荷によって結果は変動します。この表は性能を保証するものではありません。
タスクの最適化
ワークロード別にネットワーク、ストレージ、キューを確認
ボトルネックがインタラクション、CPU、メモリ、ディスク、キュー待ちのどれにあるかを先に確認します。リモート画面のカクつきを、ノードの計算性能不足と直接判断しないでください。
コンパイル、テスト、アーカイブ
- 環境
- Xcodeのバージョン、プロジェクトのコミットID、ビルドコマンド、失敗した段階をすべて記録します。
- ストレージ
- ワークスペース、DerivedData、アーカイブ、テンポラリディレクトリの空き容量を確認します。
- ログ
- 最後の終了メッセージだけでなく、最初のエラーと前後のコンテキストを保存します。
並列パイプライン
- キュー
- 待ち時間がスケジューラー、依存関係のダウンロード、テスト実行、アーカイブのアップロードのどの段階で発生しているか確認します。
- 並列度
- 並列タスク数を段階的に減らし、全体のスループットと各タスクの所要時間の変化を比較します。
- 分離
- リポジトリごとにワークディレクトリ、キャッシュパス、ログを分け、タスク同士の上書きを防ぎます。
大規模モデルの実験
- メモリ
- モデルサイズ、量子化方式、コンテキスト長、実行時のピーク使用量を記録します。
- ディスク
- モデルファイルが完全で、キャッシュと出力ディレクトリが想定したボリューム上にあることを確認します。
- キュー
- バッチ、コンテキスト、並列度のうち一度に1つだけ変え、結果を保存します。
sw_vers
uname -m
df -h
vm_stat
system_profiler SPHardwareDataTypeログを提出する際は、システムバージョン、アーキテクチャ、ボリューム容量、メモリ状態を添付できます。ユーザー名、プロジェクトパスの機密名称、アクセス認証情報は削除してから提出してください。
ストレージと追加デバイス
まずボリュームを特定し、容量やマウントの問題に対処
基本SSD容量は選択した構成によって異なります。OAM M4 16は256GB、OAM M4 24は512GB、OAM M4P 64は2TBです。追加ストレージを基本システムボリュームと混同しないでください。
確認の順序
システムボリューム、追加ボリューム、外部接続
-
デバイスがシステムに認識されているか確認
システム情報とディスクユーティリティで、デバイス名、接続方式、総容量、パーティションの状態を確認します。デバイスがまったく表示されない場合は接続構成を記録し、初期化の繰り返しを中止してください。
-
ボリュームがマウントされているか確認
デバイスは存在するのにボリュームが表示されない場合は、ファイルシステム、ボリューム名、マウントポイント、ディスクユーティリティのエラーを記録します。データ用途が不明な状態で消去や再パーティションを実行しないでください。
-
書き込み先を確認
プロジェクト、モデル、ビルドキャッシュ、エクスポート先が実際にどのボリュームへ書き込まれているか確認します。ディスク容量不足は、キャッシュがシステムボリュームに残り、追加ボリュームがワークディレクトリに使われていないことが原因になりがちです。
-
障害スナップショットを収集
デバイス一覧、ボリューム容量、マウント状態、初回発生時刻、最後に正常だった操作、関連するエラーログを提出し、タスクやクライアントを再起動したかどうかも記載します。
+1TB SSD と +2TB SSD
追加SSDは、作業データ、ビルドキャッシュ、モデルファイル、メディア素材の拡張に使用します。認識後はマウントポイントとディレクトリ権限を確認してからデータを移行してください。
- 追加容量を機種の基本ストレージ仕様として記載しないでください。
- 移行前に、書き込み中のビルドまたは推論タスクを停止してください。
- 障害情報にはデバイス容量、ボリューム名、マウントパスを含めてください。
Thunderbolt 5のデイジーチェーン接続
まず物理的な接続順に各デバイスを確認し、次にシステム情報のリンクとデバイスツリーを照合します。複数のデバイスで異常がある場合は、範囲を絞るため1台ずつ接続をテストしてください。
- 接続台数、接続順、異常なデバイスの位置を記録します。
- デバイスが断続的に消える、読み取り専用になる、マウントに失敗するかを記録します。
- 書き込み中のデバイスを、確認なしに何度も抜き差ししないでください。
安全な取り扱い
問い合わせ本文には診断情報だけを記載し、秘密情報は含めない
問い合わせ本文、スクリーンショット、ログ、メールで、パスワード、秘密鍵、リカバリコード、完全なアクセストークン、未加工の設定ファイルを送信しないでください。サポート担当者は、これらがなくても診断を開始できます。
注文番号、ノード、エラー原文、機密情報を除いたログ、再現手順、発生時刻、クライアントバージョン、ネットワークテストの概要。
ユーザー名以外の認証秘密、認証ヘッダー、秘密鍵の内容、リカバリコード、完全な環境変数、スクリーンショットに写った機密パス。
まず秘密情報を含まない問い合わせを送信してください。サポート担当者から管理された提出手順の案内を受けた後、指定された範囲で必要な情報だけを提供します。
問い合わせの準備
診断を開始できる情報を1回で提出
情報は多ければよいわけではありません。対象を特定し、時系列を整理し、問題を再現し、影響範囲を判断できる情報をそろえることが目的です。
注文番号とノード
コンソールに表示される注文番号、機種、ノードを記載します。デバイスのニックネームだけを書かないでください。
発生時刻
タイムゾーン、初回発生時刻、直近の再現時刻、問題が継続しているかを明記します。
再現手順
正常な状態を起点に操作を順番に記載し、どの手順で想定外の結果が発生したかを示します。
エラーとログ
エラー原文と前後のコンテキストを貼り付け、ログがクライアント、ビルドツール、システムのどれから取得されたかを説明します。
スクリーンショットと影響範囲
スクリーンショットから機密情報を隠し、影響が単一タスク、単一ユーザー、チーム全体のどれに及ぶかを説明します。
実施済みの確認
ネットワーク、クライアント、再接続、容量、キューについて実施した操作を列挙し、診断の重複を避けます。
接続できない場合の問い合わせ概要の書き方
件名は「ノード + クライアント + 接続段階」とし、本文には注文番号、ノード、発生時刻、クライアントOS、エラー原文、ネットワークテスト結果、アクティブセッションの有無、実施済みの再接続手順を順番に記載することをおすすめします。
カクつきやビルド速度低下にはどのデータが必要ですか
リモートデスクトップの問題では、往復遅延の中央値、ジッター、パケットロス、解像度、クライアントのネットワーク種別を提供してください。ビルドの問題では、コマンド、コミットID、開始・終了時刻、最初のエラー、空きディスク容量、並列タスク数を提供します。
注文やアカウントの問題はどこから送信しますか
コンソールにログインして問い合わせると、問題を注文記録に関連付けられます。ログインできない場合は support@ownamac.com まで連絡し、業務用メールアドレス、注文識別子、問題の概要を記載してください。パスワードやリカバリコードは送信しないでください。
送信準備
ノード、時系列、再現手順を1件の問い合わせにまとめる
稼働中の障害は、注文とノードを関連付けられるよう、優先してコンソールから送信してください。ログインできない場合は support@ownamac.com を使用し、機密情報を除いた内容だけを送信します。