最近、Mac miniの役割が変わった。
ただの据え置きMacではなく、Codexの母艦になっている。
家に置いたMac miniでCodex Appを動かしておく。
長めの作業、複数threadの確認、AIチーム運用、日次の作業をそこへ寄せる。
外にいる時は、iPhoneやMacBook Proから見る。
必要なら、そこで判断だけ返す。
ここが大きい。
Codexを1回だけ使うなら、手元のMacで十分です。
でも、毎日使うようになると少し違う。
作業するMacが変わるたびに、thread、作業中の状態、ローカルファイル、認証、プラグイン、ブラウザ環境が分かれる。
その分だけ、確認が面倒になる。
だったら、Codexが働く場所を固定した方がいい。
この記事は、Mac miniを常時稼働のCodex hostにして、外出先からAIチームの仕事を確認するようになった記録です。
2026年6月29日時点の自分の環境での話として書いています。
Codexを使い倒すと、作業するMacを固定したくなる
最初は、MacBook Proだけでいいと思っていた。
持ち運べるし、画面も大きい。
外でも家でも同じMacを使えば、作業環境は揃う。
でも、Codex Appを毎日使うようになると、少し事情が変わった。
Codexにはthreadがある。
projectがある。
worktreeがある。
automationsがある。
skillsやpluginsもある。
さらに、ローカルのファイル、CLI、Git、ブラウザ、認証済みサービス、MCP、Computer Useの設定も関係する。
つまり、Codexの作業は「モデルに質問するだけ」では終わらない。
どのMacの、どのprojectで、どのthreadを動かしているかが効いてくる。
ここが地味に重い。
出先でMacBook Proを開いた時に、作業中のthreadが別Macにある。
ローカルファイルはGitHubへpushしていても、Codex Appの作業状態まではそのまま同期されない。
未commitの変更や実行中のterminalも、当然ながら別物になる。
だから、長く走らせる作業はMac miniに寄せることにした。
Mac miniを常時稼働のCodex母艦にした
自分の運用では、Mac miniを常設のCodex hostとして扱っている。
机の上に置いておく。
電源につないでおく。
Codex Appを起動しておく。
作業の主戦場はMac mini。
MacBook Proは、持ち運びと確認用。
iPhoneは、外出先から進捗を見て判断を返すための端末。
ざっくり分けると、こうなる。
| 端末 | 役割 |
|---|---|
| Mac mini | Codexの母艦。長い作業、複数thread、automations、ローカルツールを置く |
| MacBook Pro | 外出先や別席からの確認、軽い修正、必要時のリモート操作 |
| iPhone | ChatGPTアプリからCodex threadを見て、追加指示や判断を返す |
Mac miniを母艦にすると、Codexが使う環境を固定できる。
projectも同じ。
threadも同じ。
ローカルツールも同じ。
pluginsやskillsも同じ。
ここで言う母艦は、すごいサーバーという意味ではない。
「Codexが実際に作業するMacを決めておく」というだけです。
でも、これだけで運用はかなり変わる。
公式docsでも、mobileからconnected hostを操作できる
この話は、自分の工夫だけではない。
OpenAIのCodex Remote Connections docsでは、ChatGPT mobile appから、接続済みのMacまたはWindows上のCodex hostを操作できると説明されている。
できることも、かなり実運用向きです。
- host上のprojectで新しいthreadを始める
- 既存threadを続ける
- follow-up instructionを送る
- 質問に答える
- commandやactionを承認する
- 出力、diff、test result、terminal output、screenshotを確認する
- hostやthreadを切り替える
さらに重要なのは、remote accessで使われる環境です。
公式docsでは、remote accessはconnected host側のprojects、threads、files、認証情報、permissions、plugins、Computer Use、browser setup、local toolsを使うと説明されている。
つまり、iPhoneが作業しているわけではない。
iPhoneから送った指示を、接続済みのMac mini上のCodex環境で動かす。
ここがポイント。
外から見ている端末と、実際に作業するhostを分けられる。
iPhoneから見ると、判断だけ返せる
実際にiPhoneで見ると、体感としてはかなり違う。
Mac mini上で進んでいるCodex threadを、ChatGPTアプリから確認する。
作業報告を見る。
必要なら短く返す。
このスクショは、実際の画面を公開用にぼかしたものです。
local path、thread ID、commit情報、内部のthread名は出さないようにしています。
外出先でやることは、全部を操作することではない。
自分が返すのは、だいたいこのくらいでいい。
- OK
- その方向で進めて
- そこはやめて
- もう一度確認して
- 公開していい
- まだ止めて
これで仕事が進む。
人間が全部作業するのではなく、止めるか、進めるか、戻すかを決める。
Codexが作業し、人間が判断する。
この分担に寄せられるのが、Mac mini母艦運用の面白いところ。
AIチーム運用では、母艦があると受け渡しが楽になる
自分はこれまで、Codexを1人の万能アシスタントとしてではなく、役割ごとのthreadとして使う話を書いてきた。
Director。
Engineer。
Tester。
Document Owner。
Assistant Director。
もちろん、これは会社の組織そのものではない。
Codexのthreadや作業ログを、役割ごとに分けて扱うための運用です。
ただ、役割を分けると、次に問題になるのは場所です。
どのMacでDirector threadを動かしているのか。
どのhostにEngineerの作業が残っているのか。
Testerの検証結果はどこで見られるのか。
ここが散ると、結局人間が探すことになる。
Mac miniを母艦にしておくと、作業場所を寄せられる。
外にいる自分は、その母艦にぶら下がっているthreadを見る。
結果として、人間の役割は伝言係ではなくなる。
Engineerが作業する。
Testerが確認する。
Directorが判断する。
自分は必要な時だけ、外からGOか差し戻しを返す。
まだ全部が完全自動という話ではない。
むしろ、完全自動にしないための母艦です。
判断点を残しながら、作業の待ち時間を減らす。
そのために常時稼働hostを置く。
Codex Cloudとは別物として考える
ここは混ぜない方がいい。
CodexにはCloudの作業面もある。
一方で、今回の話はMac miniをconnected hostとして使う運用です。
Mac mini hostでは、Mac mini側のローカル環境が効く。
files、local tools、plugins、browser setup、Computer Use、permissionsがhost側にある。
CloudはCloudで便利です。
ただ、自分のローカル環境、ログイン済みのブラウザ、手元のツール、作り込んだskillsやdocsを使いたい場合は、常設Macをhostにする意味がある。
どちらが上という話ではない。
Cloudに投げる作業。
Mac mini hostで回す作業。
手元のMacBook Proで見る作業。
ここを分けると、Codexの使い方が少し整理される。
常時稼働hostに置くもの、置かないもの
Mac miniを母艦にするなら、何でも置けばいいわけではない。
置くものは、作業に必要なもの。
- Codex App
- よく使うproject
- Git環境
- 必要なCLI
- 使い回すdocs
- skills
- 必要なplugins
- ローカルで確認したいブラウザ環境
一方で、出しすぎない。
記事に出さないものも決めておく。
- IPアドレス
- 画面共有URL
- thread ID
- local pathの細部
- 認証情報の値や接続設定の詳細
- 未公開repo名
- ブラウザsessionの詳細
スクショを使う時も同じ。
画面の雰囲気は出していい。
でも、作業の中身やIDはぼかす。
Codexの記事は、実運用を書けるほど面白くなる。
ただ、そのまま出すと内部情報も混ざりやすい。
公開用には、実体験を残しつつ、識別できる情報を削る。
自分で試すなら、この順番がよさそう
自分の環境で試すなら、いきなり大きく作らない方がいい。
まずは、普段Codexを使っているMacをhostにする。
そのMacでCodex Appを起動しておく。
ChatGPT mobile appから見えるか確認する。
次に、長く動かす作業を1つだけ寄せる。
たとえば、次のような作業です。
- 記事の下調べ
- docsの整理
- 公開前チェック
- リライト候補の洗い出し
- テスト結果の確認
- 日次レポートの要約
外出先から返す判断も、最初は絞る。
OK / 修正 / 保留 / 次へ
この4つくらいでいい。
細かい作業をiPhoneで全部やろうとすると疲れる。
でも、判断だけなら返せる。
ここまでできたら、常時稼働hostを用意する意味が出てくる。
ただし、起きているMacが必要
常設hostには、現実的な注意点もある。
公式docsでも、mobile accessにはCodex App hostが起きていて、オンラインで、同じaccount / workspaceにサインインしている必要があると説明されている。
つまり、Mac miniが寝ていたら止まる。
Codex Appが落ちていたら止まる。
ネットワークが切れていたら止まる。
ここは、自動化の魔法ではない。
電源。
スリープ。
ネットワーク。
Codex Appの起動。
Gitの同期。
worktreeの扱い。
こういう普通の運用が効いてくる。
自分は、Codexの使用量だけでなく、ローカル環境も見るようになった。
以前書いたcodex doctorやログ容量の点検ともつながる話です。
AI作業が増えるほど、AIそのものより、AIが動く場所を整える必要が出てくる。
まとめ。持ち歩くのは作業環境ではなく、判断でいい
Mac miniをCodexの母艦にすると、仕事の置き場所が決まる。
長い作業は、常時稼働のhostに置く。
外出先では、iPhoneやMacBook Proから見る。
必要な時だけ判断を返す。
これで、AIチームの仕事はかなり回しやすくなる。
もちろん、まだ人間の確認は必要です。
むしろ、そこは残す。
全部を自動化したいわけではない。
自分が見なくてもいい待ち時間を減らし、見るべき判断だけ返せるようにする。
そのためのMac mini。
そのためのCodex Remote Connections。
そのための役割thread。
Codexを本気で使うなら、プロンプトだけでなく、hostも設計した方がいい。
あわせて読みたい本
AIチーム運用やAIエージェントの考え方を整理するなら、このあたりも読みやすい。
ポチップ
関連記事
- ひとり事業のAIチーム運用。メディア、集計、発信、リライトをつなぐ
- Codexのthread toolで、AIチームの役割スレッドをつなぐ
- 人間が伝言係をやめると、AI開発チームはかなり自動化できる
- AIに任せる仕事は、プロンプトではなくskillにした方がいい
- Codexを使い倒すなら、使用量だけでなくローカル環境も点検すべきって話