まずタスクを明確にし、レンタル期間を決める
MLX推論の検証は日単位、リリース期間のビルドキューは週単位、継続的インテグレーションの実行環境は月単位や四半期単位で必要になることがあります。タスクの長さに応じて期間を選べるため、短期的なピークのために使わないデバイスを長期間保有する必要はありません。
VMMiniについて
短期のMac計算リソースを、境界の明確な物理ノードとして提供
VMMiniはクラウドMac専用物理マシンを提供しています。各注文には1台のApple Silicon物理ノードが割り当てられ、MLX推論、Mac AIデプロイ、iOS/macOSビルド、リモート自動化に適しています。共有リソースを分割した仮想マシンではありません。
実際に販売しているVMMini M4構成と、シンガポール、日本（東京）、韓国（ソウル）、香港の4ノードのみを公開しています。構成、期間別料金、提供範囲は公開ページとコントロールパネルで一致しています。
VMMini
物理ノード
- カタログ構成
- M4 / 16GB / 256GB
- 稼働方式
- 専用物理マシン、仮想マシンではありません
- 課金期間
- 日、週、月、四半期単位
- 稼働目標
- 99.9%
このサービスだけを提供する理由
デバイスは長期運用の負担ではなく、タスクの期間に合わせて使うもの
短期の推論検証、リリース前のビルド集中、ビルド負荷のピークは数日から数週間で終わることが多い一方、自前で購入すると調達、設置、ネットワーク、リモートアクセス、システム更新、障害対応が長期的な作業になります。VMMiniはこうしたインフラ作業を、利用期間を選べるクラウドMacサービスにまとめています。
物理リソースの境界を注文前に明確にする
ノードを選ぶ前に、チップ、メモリ、ストレージ、期間別料金、追加オプションを確認できます。VMMini M4はM4、16GB RAM、256GB SSDで固定され、曖昧なプラン名で実際の仕様を隠すことはありません。
終了計画をデプロイ計画と同時に立てる
タスクの開始前に、成果物のエクスポート方法、ログの保存期間、キーの失効時期、データの消去方法を決めておく必要があります。クラウドMacを日単位や週単位で使う場合も、終了時に場当たり的な対応をせずに済みます。
製品原則
注文作成前に明確にすべき4つの事項
エンジニアリングチームがインフラサービスを判断するには、確認可能な情報が必要です。固定カタログでページ、コントロールパネル、サポート手順を統一し、曖昧な表現で事実を置き換えません。
構成を明記
販売中の構成はVMMini M4のみです。M4、16GB RAM、256GB SSDで、追加ストレージやThunderbolt 5の接続が必要な場合は追加オプションとして別途課金し、基本仕様には含めません。
ノードを網羅
カタログにはシンガポール、日本（東京）、韓国（ソウル）、香港の4ノードがあります。選択時は都市名だけでなく、チームの所在地、コードソースの位置、ユーザーまでのアクセス経路を考慮してください。
料金を統一
基本構成の料金は$20.5/日、$55.4/週、$102.6/月、$279.1/四半期です。ページ上の期間別料金は注文カタログと一致し、すべてUSDで表示・決済されます。
ステータスを確認可能に
カタログ内の機種とノードの組み合わせは通常予約できますが、実際の利用可否はコントロールパネルからリアルタイムで返される情報を基準とします。ノードの事象、注文記録、サポート対応は具体的な時刻と注文識別子に関連付けて確認できるようにします。
境界を明確にする：
共有計算リソースを専用物理ノードとして見せることはありません。ノードのハードウェア、外部ネットワーク経路、ユーザー自身のソフトウェアは異なる層であり、トラブルシューティングでは個別に検証する必要があります。
対象ユーザー
実際のmacOS実行環境を必要とするエンジニアリングタスクにリソースを提供
同じクラウドMacを使うチームでも、重視する点は異なります。ワークロードごとに入力、実行方法、持ち出す成果物を整理し、あらゆる要件を単なる「リモート開発」の一言にまとめません。
iOS / macOS開発
BUILD
ビルドのピーク負荷を個人のワークステーションから移す
開発者には通常、固定されたXcodeツールチェーン、安定した依存関係キャッシュ、追跡可能なアーカイブ成果物、再現可能な失敗ログが必要です。課題は単一のコンパイルではなく、リリース時に複数人がローカルデバイスを奪い合うこと、環境の差異、成果物の分散です。
- 入力
- コード、ロックファイル、ビルド構成、管理対象の認証情報
- 実行
- コマンドラインでのビルド、テスト、アーカイブ、ログ保存
- 成果物
- アーカイブファイル、テストレポート、シンボルファイル、ビルド記録
CI/CDチーム
QUEUE
self-hosted runnerのリソース所有権を明確にする
継続的インテグレーションチームが重視するのは、キューの処理量、プロジェクト分離、キャッシュの消去、実行環境の無効化、失敗時の再試行です。共有環境ではキャッシュ汚染や権限問題が複数プロジェクトに広がりやすい一方、専用物理ノードならマシン単位で実行基準を設定できます。
- 入力
- Runner登録情報、リポジトリ権限、タスクタグ
- 実行
- 作業ディレクトリの分離、同時実行数の制限、一時ファイルの消去
- 成果物
- パイプラインログ、テスト結果、パッケージ、検証情報
AI実験ユーザー
MLX
Apple Siliconで実験とサービスデプロイを再現する
MLX推論とMac AIデプロイでは、モデルファイル、メモリ使用量、サービスのリスニングアドレス、ヘルスチェック、ログ収集を確認する必要があります。よくある管理上の負担は、モデルキャッシュの肥大化、過剰なポート公開、実験終了後の消去計画不足です。
- 入力
- モデル、推論スクリプト、依存関係のバージョン、テストサンプル
- 実行
- ローカルリスニング、ヘルスチェック、リソース監視、バッチタスク
- 成果物
- レスポンス結果、パフォーマンスログ、モデル構成、再現手順
稼働目標
99.9%のサービス目標を、注文記録と時間枠で確認
すべてのノードは365日、年間を通じて正常に稼働し、定期的な停止スケジュールは設けていません。サービス目標はノードサービスの可用性を測定するものであり、外部ネットワーク経路、ユーザー自身のソフトウェアエラー、制御不能な事象を物理ノードの結論に含めません。
99.9%
サービス可用率目標
- 計算期間、可用状態の定義、申請手順はサービス利用規約に従います。
- 確認資料には注文識別子、ノード、発生時刻、接続テスト、匿名化済みログが含まれます。
- 補償は、サービス利用規約の可用率基準、除外事項、審査結果に基づいて決定されます。
90日間の観測期間
短いマス目1つが1暦日を表します
目標対象日
01–10
11–20
21–30
31–40
41–50
51–60
61–70
71–80
81–90
この図は計算構造と目標基準を示すもので、注文単位の事象記録に代わるものではありません。具体的なノードのステータスと関連時刻は、コントロールパネルの情報を基準とします。
ノード運用の境界
販売中の4ノード。3つの層を分けて判断する
ノードの都市は物理的な配置場所を示しますが、ユーザーごとのアクセス体験を単独で予測するものではありません。注文前に、ノードの可用性、実際のネットワーク経路、ワークロード自体の状態を3つの層に分けてテストしてください。
SGシンガポール
東南アジアのチームとワークロード向けです。チームの出口、コードソース、対象ユーザーのネットワークをそれぞれ先にテストするのに適しています。
シンガポールノードを選択JP日本（東京）
日本および東アジアからのアクセス経路向けです。オフィスネットワーク、自動化プラットフォーム、依存関係のダウンロード経路を同時に確認してください。
東京ノードを選択KR韓国（ソウル）
韓国および北東アジアのタスク向けです。継続的インテグレーションチームは、Runnerからコードソースまでの実際の経路を確認してください。
ソウルノードを選択HK香港
華南および東南アジアからのアクセス向けです。地域をまたぐチームは、各オフィスネットワークの接続結果を個別に収集してください。
香港ノードを選択| 層 | 最初に確認すること | 記録する内容 | 次に行うこと |
|---|---|---|---|
| ノードの可用性 | ホストが応答するか、システムが起動しているか、注文ステータスが正常か | 注文識別子、ノード、発生時刻、接続結果 | コントロールパネルでステータスを確認し、異常時は関連チケットを提出する |
| ネットワーク経路 | ローカル出口、通信事業者のルーティング、コードソース、対象サービスまでの経路 | 送信元ネットワーク、宛先アドレス、継続的なテスト結果、ルーティング情報 | 送信元ネットワークを変更して再テストし、単一経路の問題とノードの問題を切り分ける |
| ユーザーソフトウェア | プロセス、ポート、権限、依存関係、ディスク、タスクログ | 再現手順、バージョン、匿名化済みログ、直近の変更 | 直近の変更を先にロールバックし、その後タスク層ごとに復旧する |
セキュリティとアクセスの責任
専用ハードウェアでも権限管理を省略できるわけではない
物理ノードによりリソース共有の境界は小さくなりますが、コード、認証情報、サービスのポート、ログ、エクスポートデータは引き続きユーザーが管理します。セキュリティ対策はタスク開始時、実行中、終了時のすべてを対象にしてください。
最小権限でアクセスを分ける
タスクを実行する担当者と自動化プロセスに、必要な権限だけを付与します。プロジェクトの認証情報と個人のアクセス情報は分けて保管し、秘密鍵をリポジトリ、ビルドスクリプト、イメージレイヤーに直接書き込まないでください。
- 担当者、Runner、サービスプロセスの権限一覧を作成する
- ワークロードが実際に使用するポートだけを開放する
- アクセスを無効化する責任者と手順をあらかじめ決める
キーをローテーションし、安全にログを共有する
長期タスクでは、チームのルールに従ってアクセスキーをローテーションしてください。調査のためにログを使用する場合は、トークン、秘密鍵、環境変数の値、個人を特定できる情報を先に削除してから、サポート依頼に添付します。
- キーの作成、使用範囲、無効化状態を記録する
- ログの読み取り権限と保存期間を制限する
- 異常発生時は環境全体をコピーせず、タイムラインを保存する
成果物をエクスポートしてデータを消去する
注文終了前に、ビルド成果物、モデル構成、テスト結果、必要なログがすべてエクスポート済みであることを確認します。その後Runnerを無効化し、一時的な認証情報を削除し、モデルとビルドキャッシュを消去して、自動化タスクがこのノードを参照していないことを確認します。
- 成果物の完全性と検証情報を確認する
- プロジェクトへのアクセスとマシンの関連付けを無効化する
- 消去結果と未完了の項目を記録する
責任範囲：VMMiniは注文に対応する物理ノードサービスとコントロールパネルの記録を担当します。ユーザーは自身のコード、アクセス認証情報、ソフトウェア構成、開放ポート、ワークロードの内容、データのエクスポート計画を管理します。
透明性の高い更新方法
事実の変更元を確認でき、多言語ページでも一貫性を保つ
構成、料金、ノードカタログ、サービスステータス、ポリシーは購入と運用の判断に影響します。関連する変更は明確な経路で公開し、あるページだけが更新され、別の言語版やコントロールパネルに古い情報が残ることを防ぎます。
CATALOG製品カタログ
機種仕様、ノード範囲、期間別料金、追加オプションは、まず正式なカタログに登録し、その後プランページ、注文フロー、ヘルプコンテンツに反映します。カタログにない組み合わせを選択肢として表示することはありません。
プランカタログを確認GUIDE操作ガイド
接続手順、MLXサービスの確認、継続的インテグレーションのトラブルシューティング、データのエクスポート方法はヘルプセンターで案内します。操作が変わる場合は、対象シーンと再確認が必要な手順も同時に説明します。
ヘルプセンターを開くORDER注文記録
具体的な注文に関するノード、期間、支払い、事象、サポート記録はコントロールパネルで関連付けられます。既存注文の問題は、重複した説明を減らすため、まずコントロールパネルから送信してください。
コントロールパネルへPOLICYポリシーと規約
データ処理、サービス目標、利用上の責任、紛争処理などのルールは、プライバシーポリシーとサービス利用規約にそれぞれ定めます。ユーザーの権利または責任に影響する変更は、該当する本文を更新します。
多言語の一貫性チェック
機種仕様、4ノードのカタログ、料金、支払い方法、サービス目標、連絡手段は重要な事実です。更新時は同じ情報源から同期し、言語版によって製品の提供範囲を変えません。
次のステップ
実際のタスク、ノード、期間でデプロイを判断する
まずワークロードに必要な実行時間、コードソースの場所、ストレージ容量、終了計画を確認し、日、週、月、四半期単位での利用を選択してください。注文はすべてUSDで決済されます。