OpenShip DesktopとCLIの選び方

OpenShip DesktopとCLIの選び方は、個人開発ならDesktop、スクリプト化やCIならCLI、遠隔チームなら「Desktopで監視、CLIを常時接続の実行端で動かす」が基本です。今週は、まず手動デプロイをDesktopで確認し、同じ操作をCLIで再現できるかを試してください。

この判断は、MacでAI SaaSを開発している個人開発者、リリース手順を自動化したい工程チーム、そして共有の実行環境を探している遠隔チーム向けです。画面の見やすさだけでなく、処理の実行場所、認証情報、失敗時の記録まで確認します。

個人開発ではDesktopを入口にする

小規模な検証や一時的な公開では、OpenShip Desktopの方が操作を始めやすいです。公式資料では、Desktop AppはAPI、ダッシュボード、データベースをまとめたネイティブアプリとして動作し、ローカルのフォルダーからデプロイできます。デプロイ状況、ログ、サービス状態を画面で追いやすい点が利点です。(公式インストール資料)

一方、CLIは初回から手順をコマンドとして残せます。公式クイックスタートでは、openship initでプロジェクトを初期化し、openship deployでデプロイする流れが案内されています。次回も同じコマンドを実行できるため、手動操作を後から自動化しやすい構造です。(公式クイックスタート)

個人開発者は、次の条件ならDesktopを主入口にしてください。

初期設定を画面で確認したい
デプロイ頻度が低い
ログを見ながら環境変数やドメインを調整する
失敗したときに直前の状態へ画面から戻したい
まだ手順が固まっていない

ただし、Desktopのクリック手順をそのまま「自動化済み」と考えてはいけません。操作を再現できるコマンド、設定ファイル、利用した認証情報を別途記録しておくと、Macを変更したときや他のメンバーへ引き継ぐときに困りません。

頻繁な公開ではCLIを手順の中心にする

週に何度も公開する独立開発者は、Desktopだけで作業を続けると、同じ画面操作が負担になります。環境の切り替え、ブランチの確認、ログの保存、ロールバックの判断を毎回手作業で行うからです。

この段階では、安定した処理をCLIへ移します。例えば、次のように役割を分けます。

リポジトリと対象環境を確認する
CLIで初期化済みの設定を読み込む
CLIでデプロイを実行する
終了状態とログを保存する
Desktopでサービス状態とログを目視確認する

OpenShip公式サイトは、CLIからデプロイ、ログ確認、ドメイン管理、ロールバックを扱えると説明しています。また、DesktopとCLIは同じ基盤を別の入口から操作する位置付けです。(公式ダウンロードページ)

ここで重要なのは、Desktopを完全に捨てる必要はないことです。CLIを実行主体にし、Desktopを状態確認の画面として残すと、再現性と視認性を両立できます。

自動化ではCLIが優先される

CI接続に向くのはCLIか

OpenShip CLIは、CIによる自動公開に接続しやすい選択です。ターミナルから実行できるため、リポジトリの設定、環境変数、認証情報、終了状態をパイプライン側で管理できます。公式資料でも、CLIはスクリプトと自動化向けと説明されています。(公式ドキュメントの操作入口)

ただし、CIへ接続する前に次を確認してください。

対話入力なしで最後まで進むか
成功と失敗で終了コードが分かれるか
ログを保存できるか
本番用と検証用の認証情報を分けられるか
同じコミットから同じ設定で再実行できるか
ロールバック手順を別コマンドとして記録できるか

公式API資料では、認証にAPIキーを使い、デプロイの開始と状態取得をプログラムから実行できる形が示されています。CLIだけで不足する場合は、APIを組み合わせる設計も検討できます。(公式APIリファレンス)

Desktop終了後の処理

OpenShip Desktopを閉じると、デプロイは必ず中断されますか。

必ずとは言えません。確認すべきなのは、処理がMac上のDesktopプロセスで動いているのか、接続先のサーバーやクラウド側へ移った後なのかです。公式資料は、Desktopがローカルマシンで動く構成と、サーバーやクラウドへ接続する構成を説明していますが、すべてのデプロイについて「アプリ終了後も継続する」とは保証していません。(公式アーキテクチャ資料)

確認の手順：まず短い検証用デプロイを実行し、Desktopを閉じた後に、接続先の状態、CLIの状態表示、ログの更新を別経路で確認してください。画面を閉じただけで継続性を判断するのは危険です。

遠隔チームでは実行端を分ける

遠隔チームがOpenShip CLIをインストールする場所は、個人のMacではなく、原則としてチームが管理できる常時接続の実行端です。

担当者のMacにCLIを置くと、次の問題が起きます。

Macを閉じる、スリープする、再起動する
Wi-Fi切断やログアウトで処理の状態確認ができない
個人のシェル設定に依存する
退職や担当変更で認証情報の回収が難しくなる
同じプロジェクトを複数人が別設定で操作する

対して、常時接続のMacやサーバー上にCLIを置けば、実行場所を固定できます。Desktopは各メンバーの観察入口にし、公開処理は共有実行端から行う形です。Macを遠隔開発端として使う場合の接続方式や夜間運用は、遠隔Macの運用判断も参考になります。

一台のクラウドMacでDesktopとCLIを同時に動かせますか。

同じMac上で両方を使う構成は可能ですが、同時に同じ環境へ公開する運用は避けてください。Desktopを監視専用、CLIを自動化専用に分け、作業フォルダー、認証情報、実行担当を整理します。手動公開とCI公開が重なると、どちらが本番状態を変更したのか追跡しにくくなります。

権限分離では画面より認証方式を見る

DesktopかCLIかは、権限モデルそのものではありません。画面が分かれていても、同じ管理者資格情報を全員で使えば、権限分離にはなりません。

安全性を優先するチームは、次の順番で決めてください。

閲覧だけのメンバーと公開担当を分ける
検証環境と本番環境の認証情報を分ける
CI用の資格情報を個人アカウントから分離する
退職や担当変更時にキーを無効化できる状態にする
操作ログを保存し、誰が公開したか確認できるようにする

公式の料金・機能資料では、チーム向けにロール、監査ログ、APIキーなどの管理機能が案内されています。ただし、実際の権限範囲は利用形態と設定に依存するため、導入前に必要な操作だけを許可できるか確認してください。(公式のチーム機能資料)

チーム段階ごとの選択表

利用状況	主な入口	実行端	運用上の注意
個人開発・一時的な公開	Desktop	手元のMac	CLIで再現手順を残す
公開頻度が高い個人開発	CLI	手元のMacまたは専用端末	Desktopはログ確認に使う
CI・一括公開	CLI	CIまたは常時接続端	終了状態、ログ、キーを管理する
遠隔チーム	Desktop＋CLI	共有の常時接続端	個人Macを唯一の実行端にしない
権限に厳しい案件	CLI中心	権限分離した専用端	監査記録とキー回収を優先する

次のチェックで、今週の構成を決められます。

[ ] 1人だけが手動で公開するならDesktopを主入口にする
[ ] 同じ公開を繰り返すならCLIへ移す
[ ] CIから実行するならCLIまたはAPIを使う
[ ] 担当者のMacが止まると困るなら常時接続端を用意する
[ ] 本番権限を全員に配らない
[ ] Desktop終了後の継続性を実際の構成で検証する
[ ] ロールバックを画面操作だけに依存しない

夜間バッチや複数の実行環境を検討している場合は、Macを使った夜間バッチの構成比較のように、担当者が不在でも処理を続けられるかを先に確認してください。

DesktopからCLIへ移すタイミングは、公開回数ではなく、失敗時の復旧コストで判断するのが安全です。設定差分を毎回探している、同じログを複数人が確認している、担当者のMacが止まるとリリースできない。このどれかが出た時点で、CLIを実行主体へ移す時期です。

個人のMacだけで運用する方法は、初期費用を抑えられる一方、スリープ、通信切断、個人権限への依存、担当変更時の引き継ぎが弱点になります。特に遠隔チームでCLIを共有するなら、HashvpsのクラウドMacを常時接続の実行端として使い、Desktopは確認用に残す構成の方が、作業場所と認証情報を分離しやすくなります。長期の固定負荷や物理ポートが必要な処理では自前のMacが適しますが、短期の検証、共同利用、CI用の実行端が必要なら、レンタルの方が切り替えや回収を行いやすいです。