エンジニアリング問題の切り分け

まず障害レイヤーを特定し、再現可能な情報を添えて問い合わせる

ここでは、専用物理Macノードの接続、Xcodeビルド、CI/CD runner、ストレージ、ノードネットワーク、請求を扱います。まず基本確認を順番に行い、解決しない場合は注文、環境、マスキング済みログをまとめて送信し、確認の往復を減らします。

6種類
問題の入口
5か所
提供中のノードリージョン
7項目
問い合わせ必須情報
バッチ診断台 BUILD / CHECK
ログ待機中
接続 アドレス、ポート、認証情報
まず確認
環境 システム、Xcode、SDK
次にそろえる
ビルド 依存関係、署名、キャッシュ
再現
デリバリー アーカイブ、アップロード、成果物
確認
推奨順序 接続 → 環境 → ビルド → デリバリー
サポート入口の概要

症状に合った確認手順へ進む

ネットワーク、システムバージョン、ビルド設定を同時に変更しないでください。一度に1つの変数だけを変え、元のエラー文と発生時刻を残すことで、接続、環境、プロジェクトのどの層の問題か判断できます。

接続の問題

アドレスには到達するがセッションに入れない

まずノードのアドレス、ポート、ユーザー名、認証情報を確認し、次にローカルネットワークの制限、クライアントの暗号化設定、セッション状態を確認します。古い認証情報を繰り返し試さないでください。

接続チェックの手順を開く
Xcodeビルド

コンパイル、アーカイブ、アップロードに失敗する

失敗した段階を記録し、ディスク容量、XcodeとSDKのバージョン、依存関係のロックファイル、署名素材、完全なビルドログを確認します。最初に発生した実際のエラーを優先して残してください。

ビルド診断の手順を見る
CI/CD

Runnerがオフライン、またはジョブが割り当てられない

runnerのサービスプロセス、登録状態、ラベルの一致、作業ディレクトリの権限、同時実行数の上限を確認します。プラットフォーム上でオンラインでも、現在のジョブのラベルに必ず一致するとは限りません。

runner設定を確認する
ストレージ拡張

キャッシュとビルド成果物で容量が不足する

ソースコード、依存関係キャッシュ、DerivedData、アーカイブ、納品成果物の使用量を分けて確認します。必要なファイルを先に書き出し、ディレクトリ単位で整理してください。用途を確認できないデータを直接削除しないでください。

ストレージに関するよくある質問を見る
ノード移行

チームまたはリポジトリの所在地が変わった

現在のノード、リポジトリのホスティングリージョン、主な作業者の所在地、大容量ファイルの転送方向を記録してから移行を検討します。移行前にコードとビルド成果物の独立したコピーを必ず用意してください。

ノードとネットワークを比較する
請求の問題

注文、契約期間、支払い状態を確認したい

注文番号、選択した構成、請求期間、支払い方法、コンソール上の表示状態を準備します。送信するのは取引IDだけにし、カード情報全体や秘密鍵は送らないでください。

コンソールから請求の問い合わせを送る
初回利用の流れ

まずノードの基準環境を固定し、プロジェクトツールをインストールする

初めてノードに入ったら、まず接続とセキュリティを確認し、その後で開発環境を設定します。これにより、システムの問題とプロジェクト依存関係の問題を分けて、後から再現しやすくなります。

  1. 01

    コンソールから接続情報を取得する

    注文に対応するノード、サーバーアドレス、ポート、ユーザー名、仮の認証情報を確認します。接続情報は現在の承認済みメンバーだけが使用し、チャット履歴や公開ドキュメントで転送しないでください。

    完了条件:安定してセッションを確立し、注文に対応するノードに接続していることを確認できる。
  2. 02

    アカウントのセキュリティを設定する

    初回アクセス後に仮の認証情報を更新し、チームの権限ポリシーに沿ったシステムアカウントを作成します。管理者操作は、ツールのインストールやサービスの調整が必要なメンバーだけに許可してください。

    完了条件:仮の認証情報を使わず、日常用アカウントと管理用アカウントの用途を分けている。
  3. 03

    システムと開発環境の基準を記録する

    macOSのバージョン、チップ、空きディスク容量、Xcodeのバージョン、コマンドラインツールのパス、ターゲットSDKを記録します。チーム独自のビルド・運用手順書にこれらの情報を記載してください。

    完了条件:同じバージョン情報で、ローカルとクラウドのビルド差異を説明できる。
  4. 04

    依存関係とrunnerをインストールする

    プロジェクトのロックファイルに従って依存関係をインストールし、専用のキャッシュディレクトリを設定してからself-hosted runnerを登録します。初回ジョブは同時実行数を低く設定し、署名、アーカイブ、アップロードの経路を検証してください。

    完了条件:最小構成のビルドジョブを繰り返し実行でき、完全なログが残る。
基準環境の記録

保存を推奨する環境情報

  • macOSとXcodeの完全なバージョン番号
  • ターゲットSDKとコマンドラインツールのパス
  • 依存関係マネージャーとロックファイルのバージョン
  • Runner名、ラベル、作業ディレクトリ
  • キャッシュディレクトリと最大同時実行ジョブ数
初回検証

最小ジョブで経路を確認する

まず確実にビルドできるコミットを1つ取得し、依存関係のインストール、コンパイル、アーカイブだけを実行します。成功を確認してから、並列ジョブ、キャッシュの復元、デリバリー手順を追加してください。

接続前の準備を確認する
ビルド障害の診断

失敗の経路に沿って1つずつ切り分け、6つの変数を同時に変更しない

ビルドの問題は通常、容量、署名、バージョン、依存関係、ログ、同時実行の6層に分かれます。各層の確認後に同じコミットを再実行し、結果が変わったかを記録してください。

01

ディスク容量

システムボリュームの空き容量、DerivedData、依存関係キャッシュ、アーカイブディレクトリ、エクスポート成果物を分けて確認します。容量不足の場合は必要な成果物を先に保存し、ディレクトリ単位で整理してください。

容量
02

証明書とプロビジョニングプロファイル

プロジェクトで選択したチーム、証明書の有効状態、プロビジョニングプロファイルの対象、Bundle Identifierが一致していることを確認します。ログや問い合わせに署名用秘密鍵を添付しないでください。

署名
03

XcodeとSDKのバージョン

実際にビルドを実行したXcodeのパスを記録し、コマンドラインツールが別のバージョンを指していないこと、プロジェクトが必要とするターゲットSDKが存在することを確認します。

バージョン
04

依存関係キャッシュ

ロックファイルと照合して、キャッシュが古くなっていないか確認します。まずキャッシュを復元しないクリーンビルドを試し、成功したら依存関係キャッシュを1つずつ戻して不一致の原因を特定します。

依存関係
05

完全なビルドログ

実行コマンド、終了コード、最初に発生した実際のエラーを保存します。最後の画面だけでは前段の失敗を見落としやすいため、ジョブ開始から終了までのマスキング済みログを添付してください。

ログ
06

並列ジョブ数

同時実行数を1ジョブまで下げて再現し、メモリ、ディスク、ネットワークの使用量を確認します。単独では成功して並列実行で失敗する場合は、同時実行数を段階的に増やして安定する上限を探します。

同時実行

6層すべてを確認しても特定できない場合は、失敗したコミットの識別子、実行コマンド、環境バージョン、終了コード、マスキング済みログを送信してください。

ビルド問題の問い合わせを送る
CI/CDサポート

runnerを認識可能、復旧可能、監査可能にする

専用物理ノードはself-hosted runnerに適していますが、安定運用には明確な登録ポリシー、ラベル、サービス管理、キャッシュ範囲、権限制御が必要です。

A1

登録

各ノードに一意のrunner名を付け、所属リポジトリまたは組織、登録範囲、作業ディレクトリ、サービスアカウントを記録します。ノードを移行する際は、先に古い登録を取り消してください。

A2

ラベル

ラベルには、チップアーキテクチャ、Xcodeのメジャーバージョン、ノードリージョン、用途など、安定した事実を表します。一時的なプロジェクト名を、管理しにくいラベルの組み合わせにしないでください。

A3

サービスの常時稼働

runnerを管理対象サービスとして実行し、起動方法とログの場所を記録します。システム再起動後にサービスが自動復旧することを確認し、最小ジョブを1つテストしてください。

A4

キャッシュディレクトリ

依存関係、DerivedData、アーカイブを別々のディレクトリで管理し、削除のしきい値を設定します。キャッシュは高速化のためのものであり、プロジェクトの唯一のコピーや長期保管用リポジトリにしないでください。

A5

最小権限

日常のビルドアカウントには、ジョブに必要なディレクトリとコマンドの権限だけを付与します。ツールのインストール、システム設定の変更、サービス管理時のみ管理者権限を使用してください。

Runnerがオフラインのときの確認順序

サービスプロセス → 登録の有効性 → ラベルの一致 → 作業ディレクトリの権限 → 外部接続 → プラットフォームのジョブキュー。

runnerの問い合わせを送る
用語集

まず用語を統一してから問題を説明する

問い合わせで用語を統一すると、物理ノード、リモートセッション、runner、ビルドキャッシュを同じ障害対象として混同せずに済みます。

物理ノード
macOS、Xcode、ビルドジョブを実際に実行するApple Silicon Macデバイス。ノードはハードウェアの提供単位であり、共有仮想リソースではありません。
専用
1つの注文に対応するノードリソースをその顧客が使用し、CPU、メモリ、ローカルストレージが他の顧客のジョブと混在することはありません。
非仮想マシン
システムは物理Mac上で直接実行され、1台のデバイスを複数の仮想インスタンスに分割するものではありません。ハードウェア仕様は注文構成に直接対応します。
VNC
macOSのグラフィカルインターフェースをリモートで表示・操作する接続方式。アドレス、ポート、アカウント、暗号化オプションは接続情報に従って入力します。
Self-hosted runner
チームがCI/CDプラットフォームに登録し、専用ノード上でジョブを実行するrunner。ツールのバージョン、キャッシュ、同時実行ポリシーを管理できます。
ビルドキャッシュ
重複するダウンロードやコンパイルを減らすための再生成可能なデータ。依存関係キャッシュやDerivedDataが含まれます。破損時に安全に再構築できる状態にしてください。
署名証明書
ビルドとデリバリーに使用する機密性の高い署名素材。診断時は証明書名、状態、エラーだけを説明し、問い合わせに秘密鍵をアップロードしないでください。
ノードリージョン
物理ノードが所在するリージョン。選択時は開発者の所在地、コードリポジトリの場所、納品先、大容量ファイルの転送方向を併せて検討します。
ノードとネットワークの診断

1回の遅延だけでなく、ワークフロー全体を見てリージョンを選ぶ

VMArmでは、シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部の5つのノードリージョンを提供しています。リモート操作、リポジトリ取得、依存関係のダウンロード、成果物のアップロード方向を総合的に比較してください。

SG

シンガポール

東南アジアのチームや、主要サービスが東南アジアにあるリポジトリ・デリバリーチェーンに適しています。

JP

日本(東京)

日本および東アジアのチームに適しており、リモートデスクトップ操作とリージョン内のビルドリソースへのアクセスを両立できます。

KR

韓国(ソウル)

韓国および北東アジア方面の開発メンバー、依存関係ミラー、デリバリーフローに適しています。

HK

香港

華南および東南アジアの協業チームに適しています。選択前に、リポジトリとリモートセッションの経路を同時にテストしてください。

US-W

米国西部

北米西海岸のチームや、主要リポジトリ、依存関係ソース、デリバリーシステムが北米にあるプロジェクトに適しています。

ノードとネットワークの異常を記録する方法
確認対象 測定方法 記録する内容 判断のポイント
リモートセッション 業務時間帯とオフピーク時間帯に接続と操作性をそれぞれテストする ローカルネットワーク、ノード、クライアントバージョン、発生時刻 継続的な異常か、特定時間帯の変動か
コードリポジトリ 同じリポジトリと同じコミットで、クローン、取得、サブモジュールをテストする リポジトリのリージョン、所要時間、失敗コマンド、終了コード 接続確立が遅いのか、大容量ファイルの転送が遅いのか
依存関係のダウンロード キャッシュを無効にして依存関係の完全な解決を1回実行する 依存関係ソース、パッケージマネージャーのバージョン、失敗したパッケージ、再試行回数 特定の依存関係ソースだけの異常か、帯域幅全体の異常か
成果物のアップロード 同じサイズのマスキング済みテストファイルで転送を比較する ファイルサイズ、対象リージョン、開始・終了時刻 上り回線、対象サービス、ファイルサイズの影響
問い合わせに必要な情報

診断に必要なコンテキストを一度にそろえる

問い合わせの目的は問題の存在を証明することではなく、同じ注文、同じノード、同じ時刻、同じ失敗手順を特定できるようにすることです。

診断情報シート 7 REQUIRED FIELDS
01 注文番号

対応する構成、請求期間、納品記録を確認するために使用します。

02 ノードリージョン

シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部のいずれかを明記します。

03 発生時刻

タイムゾーンを含む時刻を示し、問題が再現するかどうかも説明します。

04 システムバージョン

メジャーバージョン名だけでなく、macOSの完全なバージョンを記載します。

05 Xcodeバージョン

実際にコマンドラインツールが指しているバージョンとパスも記載します。

06 再現手順

正常な状態から開始し、実際のクリックまたはコマンドの順序に沿って段階的に説明します。

07 マスキング済みログ

エラーのコンテキストと終了コードを残し、トークン、秘密鍵、その他の機密情報を削除します。

既存の注文

コンソールから問い合わせる

ログイン後に対象の注文を選択して問題を送信します。注文とノードのコンテキストがそろうため、接続、ビルド、移行、請求の問題に適しています。

コンソールへ移動
購入前の相談

ワークロードと規模を先に伝える

まだ注文していない場合は、用途、希望構成、同時ビルド数、希望リージョン、利用開始予定時期をお知らせください。

お問い合わせ方法を見る

送信前にアクセストークン、署名用秘密鍵、支払い情報全体などの機密情報を削除してください。データの取り扱いを確認する場合は、プライバシーポリシーをお読みください。

サポート範囲と対応フロー

問題の確認から問い合わせ完了まで、各ステップで結果を提示

対応順序は影響範囲と再現性によって決まります。サポートではノードの納品、接続、環境、注文の問題を扱います。プロジェクトのビジネスロジックはプロジェクト管理者が確認してください。

  1. 01

    問題の優先度判定

    接続不能、ビルド全体の停止、一部ジョブの異常、一般的な相談のいずれかで影響範囲を判断し、実行可能な代替経路があるか確認します。

  2. 02

    受付確認

    注文番号、ノード、時刻、環境、ログを受け取ったことを確認します。必要情報が不足している場合は、補足が必要な項目を明示します。

  3. 03

    診断の更新

    現在確認している層、除外済みの項目、次の検証手順、ユーザーに実行してもらうテストを説明し、情報が増えない手順の繰り返しを避けます。

  4. 04

    完了条件

    問題が復旧し、根本原因と回避方法を説明できた場合、またはプロジェクト設定の問題と確認し実行可能な確認方法を提示した場合、問い合わせは完了手続きに進みます。

サポート対象

  • 注文とノードの納品状態の確認
  • VNCアドレス、ポート、セッション接続の診断
  • ノードのシステム、ディスク、ネットワーク、権限の基本診断
  • Runnerサービスの状態と一般設定の確認
  • 請求期間と支払い状態の説明

プロジェクトチームとの共同確認が必要

  • 業務コードのロジックとサードパーティSDKの動作
  • プロジェクト固有のスクリプトと内部依存関係ソース
  • チームが独自に定めた署名・リリース手順
  • リポジトリ権限、ブランチ戦略、ジョブのトリガー条件
  • ビルド成果物の業務上の受け入れ基準
次のステップ

次のビルドを専用物理Macノードで実行する

VMArm M4 CoreまたはVMArm M4 Plusを選び、シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部からノードを選択してください。実際の利用可能状況はコンソールのリアルタイム表示に従います。