外出先のMacBook ProでMac miniの開発をそのまま続けられる
普段、自宅ではMac miniを使ってソフトウェア開発をしている。複数のプロジェクトを管理しながら、Claude CodeやCodexに実装やレビューを任せ、Dockerで開発用のサービスを動かす。そんな環境で以前から気になっていたのが、「外出先のMacBook Proでも、Mac miniで進めていた作業をそのまま続けられないだろうか」ということだ。
もちろん、GitHubを使えばソースコードは共有できる。しかし、最近のAIを活用した開発では、ソースコードだけを共有できても十分ではない。AIエージェントとの会話、動作中のターミナル、Git worktree、Dockerで動いているデータベース。できればこれらを一切移動せず、作業している場所だけを変えたい。
その希望を叶えてくれるのが、OrcaのRemote Orca Servers（リモート Orca サーバー）という機能だ。結論から言うと、Mac miniの開発環境をそのままに、MacBook Proから同じワークスペースへ戻って作業を継続できる。本記事では、その構成、従来の開発との違い、似た機能との違いを順に整理する。
Mac miniを開発拠点にする構成
[画像挿入：Mac miniとMacBook Proの役割分担が分かる構成図]
構成はシンプルだ。Mac mini側がOrca、Claude Code / Codex、Git / Git worktree、Docker / PostgreSQL、開発中のプロジェクト、AIの実行セッションをすべて保持する。MacBook Pro側はOrcaでリモート操作し、コードの確認・編集、AIエージェントへの指示、Webアプリの動作確認を担うクライアントになる。両者はTailscale経由で接続する。
Orcaは、Claude CodeやCodexなどのAIコーディングエージェントを管理できる開発環境だ。Git worktreeによる作業の分離、エージェントの実行、ターミナル、コード編集、ブラウザなどを統合している。Remote Orca Serversは、そのOrcaが、別のコンピューターで実行中のOrcaへ接続するための機能である。
ここが重要だ。MacBook Proに開発環境をコピーするのではなく、Mac miniにある開発環境をそのまま使う。しかも、一般的なリモートデスクトップのようにMac miniのデスクトップ全体を画面転送する仕組みとも違う。MacBook Pro側のOrcaから、Mac mini側のOrcaが管理しているプロジェクトやエージェントセッションへ接続する。離れた場所にある開発環境を、手元のOrcaで操作できるわけだ。
ソースコードだけでなく作業中の状態まで共有できる
従来のGitを中心とした開発では、端末を切り替えるために、コミットしてpushし、別の端末でpullすることが多かった。ところが、AIエージェントを使った開発では事情が違う。
Claude Codeがコードを調査している途中だったり、Codexにレビューを依頼していたり、複数のworktreeで並行作業していたりする。こうした作業は、単純にソースコードを同期するだけでは引き継げない。
Remote Orca Serversでは、Mac mini側がプロジェクト、worktree、ターミナル、タブ、AIエージェントのセッションを保持する。そのため、MacBook Proから接続し直しても、サーバー側の既存ワークスペースに戻れる。「別のマシンで開発を再開する」というより、「同じ開発環境を別の場所から操作する」という感覚に近い。この違いは大きい。
DockerやデータベースもMac miniに置いたままでいい
もう一つ大きな利点は、MacBook Pro側にプロジェクトの開発環境を丸ごと構築する必要がないことだ。
例えば、Next.js、Payload CMS、PostgreSQLを組み合わせたWebアプリなら、Node.js、各種ライブラリ、環境変数、データベースなどが必要になる。Dockerを利用する場合は、コンテナ、イメージ、ボリュームの管理もある。こうした環境をMac miniとMacBook Proの両方で整備するのはそれなりに手間がかかるうえ、片方だけライブラリのバージョンが違うといった問題も発生しやすい。
Remote Orca Serversなら、開発処理をMac miniに集約できる。MacBook ProはMac mini上のプロジェクトへ接続するので、そこにあるDockerやデータベースをそのまま利用できる。特に複数のプロジェクトを抱えている場合、この環境管理の負担軽減は魅力的だ。
MacBook ProがスリープしてもAIエージェントは動き続ける
これはAIを使った開発ならではのメリットだと思う。例えば、外出先でClaude Codeに大きな作業を依頼する。その後、MacBook Proを閉じて移動することになっても、処理はMac mini側で実行されている。
Mac miniが起動しており、Orcaの実行環境が維持されていれば、クライアントであるMacBook Proが切断されてもエージェントは作業を継続できる。再接続すれば、サーバー側に保持されたワークスペースへ戻れる。
もちろん、Mac mini自身が停止した場合まで作業が継続するわけではない。それでも、ノートPCを常時開いておく必要がないことは、外出先での開発にとって大きな利点になる。
SSH Targetsとの違いは管理する主体
[画像挿入：SSH TargetsとRemote Orca Serversの違いが分かる比較図]
Orcaには「SSH Targets」という似た機能もある。こちらはMacBook Pro側のOrcaが開発環境を管理し、特定のworktreeやエージェントをSSH接続先で実行する仕組みだ。一方、Remote Orca Serversでは、Mac mini側がOrcaの実行環境そのものを管理する。どちらもリモート実行に対応するが、管理する主体が異なる。
違いを整理すると、次のようになる。SSH Targetsは管理主体が手元のOrcaで、既存のOrca環境全体の共有は主目的ではない。Remote Orca Serversは管理主体がリモートのOrcaで、既存環境全体の共有と、複数クライアントからの利用に対応する。どちらもリモートでのAI実行には対応している。
どちらが優れているというより、用途の違いだ。今回のように、普段使っているMac miniのOrcaを外出先からそのまま利用したいなら、Remote Orca Serversが適している。
設定はGUIで完結する
今回はMac miniとMacBook Proの両方にOrcaとTailscaleをインストールする方法を選んだ。Mac mini側で接続用のアクセスリンクを発行し、MacBook Pro側でそのリンクを登録する。基本的にはGUI上で設定が完結する。
詳しい手順は、本シリーズの「番外編：Remote Orca Servers完全設定ガイド」で画面の流れに沿って紹介する。
まとめ：開発環境にどこからでもアクセスする
Remote Orca Serversの魅力は、単にリモートのMacを操作できることではない。開発環境を一か所に集約し、どの端末からでも同じ作業の流れに戻れることだ。
これからAIエージェントが長時間、自律的に開発を進める機会はさらに増えていくだろう。そうなると、開発に必要なのは必ずしも高性能なノートPCではなくなる。安定して稼働する開発マシンと、そこへアクセスできる端末があればよい。
自宅のMac miniで開発を始め、外出先のMacBook Proで続きを確認し、帰宅後は再びMac miniから作業する。端末を切り替えても、開発環境は切り替わらない。「開発環境を持ち歩く」から「開発環境にどこからでもアクセスする」への転換を実現してくれる機能だ。次回は、Claude CodeやCodexのAIセッションをどのように引き継げるのか、具体的な開発シーンを通して紹介する。