2026年10月18日、掃除の記録アプリ「掃除！」を作り始めました。今回試したのは、iPhoneのChatGPTから自宅の開発環境を操作する方法です。
自宅の開発マシンはMac miniとWindowsの2台です。どちらにもDesktop Commander Remoteで接続できるため、外出先からソースコードの調査や修正を頼めるようになりました。iOSアプリのビルドは、Xcodeの入ったMac miniの担当です。
開発ソースの正本はGitHubに置いてあります。複数のPCで同じアプリを扱う以上、どのコードを基準にするか決めておかないと困るからです。
「掃除！」の開発で実際に何を頼んだのかも交えながら、今の使い方を紹介します。インストール手順よりも、普段どうやって作業を進めているかという話です。
iPhoneから自宅のMacとWindowsへ
iPhoneからの操作にはChatGPTを使っています。画面を直す際は、変更したい箇所をチャットで伝える形です。コードを確認する必要があれば、ChatGPTがDesktop Commander Remoteを使って接続先のPCを操作します。
Desktop Commander Remote経由なら、接続先のファイルやターミナルも操作可能です。Xcodeでのビルドも、私はこの経路で依頼しています。Windowsにも開発用のファイルやツールがあるので、作業に応じて接続先を選ぶわけです。
私が用意している環境は次のとおりです。
| 機器・サービス | 用途 |
|---|---|
| iPhone | ChatGPTへの指示、結果の確認、アプリの実機テスト |
| ChatGPT | 調査内容や修正方針の相談、Desktop Commander経由の操作 |
| Desktop Commander Remote | Mac mini・Windows・Debianへの接続とファイル・コマンド操作 |
| Mac mini | XcodeでのiOSアプリ開発、シミュレーター、ビルド、TestFlight関連の作業 |
| Windows | ソースコードの確認・編集、各種開発作業 |
| Debian | サーバーや定型処理の状態確認 |
| GitHub | ソースコードの正本、変更履歴、Issue管理 |
ここで大切なのは、iPhoneが操作の入口になっている点です。XcodeはMac mini上で動いており、Windowsの開発作業も接続先のWindowsが処理します。iPhoneにPC用の開発ツールを入れているわけではありません。
PCのデスクトップ画面をスマートフォンに映し、細かい文字を追う機会も減りました。ChatGPTへの依頼も「どのファイルを調べてほしいか」「この表示が気になる」といった話し方で済みます。その際に欲しいのは、実行されたコマンドと変更ファイルが分かる報告です。
MacとWindowsを使うので、GitHubを正本にした
複数のPCで開発していて困るのは、作業した場所によってコードの内容が変わってしまうことです。Windowsで変更したファイルがMacには届いていなければ、Xcodeでビルドしても期待した修正を確認できません。
そこで、開発ソースはGitHubのリポジトリを基準にしています。MacとWindowsの作業フォルダは、GitHubにあるコードを扱うための場所という位置付けです。
ただし、GitHubを正本に決めただけで自動的に内容がそろうわけではありません。あるPCで修正しても、その変更がコミットされていなければ別のPCからは見えないままです。GitHubへ反映済みの変更も、Mac側の作業フォルダが古ければビルドには入りません。
ChatGPTから「修正しました」と返ってきたら、変更したファイルと差分を確認するのが私のやり方です。未コミットの変更が残っていれば、その内容を確かめたうえで次の作業を頼みます。
Gitの状態を確認する際に使えるコマンドは、たとえば次のようなものです。
git status --short
git branch --show-current
git log -1 --oneline
git diff --stat
git status --shortでは未コミットの変更が分かります。git log -1 --onelineは、その作業フォルダがどのコミットにいるかを見るためのものです。実際の作業では、ブランチやリモートの状態も見ています。
作業の管理にはGitHubのIssueも使っています。変更内容と関連するIssueを結び付けておけば、あとから修正理由を追いやすいからです。ChatGPTとDesktop Commanderで操作できる範囲が広がった分、Gitの状態を確かめる習慣は以前より重要になりました。
「掃除！」では、画面を見ながら何度も直した
「掃除！」は、キッチンやトイレなど、掃除した場所と日時を記録するアプリです。画面には掃除場所を表すアイコンを並べています。
開発中、今日の画面にあった四隅の数字とマークが気になりました。実際に使う画面としては不要だと思い、ChatGPTへ削除を依頼しています。履歴画面に表示されていた「〜の掃除」という文言も外しました。
こうした修正は、文章だけで説明するより画面を見せた方が伝わりやすいと感じています。どこが気になるかスクリーンショットで示せば、対象となる部分を特定しやすくなるからです。ChatGPT側でコードを修正したあとは、シミュレーターや実機の表示を確認していました。
ふりかえり画面には日・週・月の集計も入れています。その途中で起きたのが、シェアカードの期間切り替えに関する不具合でした。日・週・月の選択部分をタップしても反応せず、週表示から変えられなくなったのです。
実機で触って、ようやくこの問題に気づいたんです。タップできない場所が分かる画面を添え、ChatGPTへ修正を頼みました。コードの変更報告だけを見ていたら、気付けなかった不具合だと思います。
「修正できた」と「使える」は別の確認
ChatGPTから修正完了の報告が返ってきたとき、私はまず何が変更されたかを見ます。そのあと気になるのが、ビルドや実機への反映です。
ソースコードに変更があっても、ビルドが失敗していればアプリは動かせません。ビルドに成功しても、実機で触って初めて分かる問題は残ります。「掃除！」のシェアカードがその例でした。
複数のPCを使っているため、確認する対象も増えます。たとえば、Windowsでの修正がGitHubへ反映されていても、Mac側で古いファイルを開いていたら意味がありません。ビルドに使うMac側の作業フォルダも、最新の変更が入っているか確認が必要です。
TestFlightでは、実際に配布されたビルド番号も確認します。ChatGPTから「ビルドできた」と返ってきても、それだけでTestFlightへのアップロードや実機へのインストールまで済んだとは判断しません。
開発を再開するときも同じです。前回の作業が途中で止まっていれば、GitHubへ反映していない変更がPCに残っているかもしれません。その状態のまま次の修正へ進むのは危険なので、まず現状を調べてもらうようにしています。
開発以外では、何を頼んでいるのか
Mac miniやWindowsへの接続は、普段のPC作業にも使っています。
Mac miniのログが気になれば、ChatGPTに対象のファイルや実行中の処理を調べてもらいます。Windowsで確認するのは、ファイルの所在やGitリポジトリの状態などです。Debianではサーバーや定型処理の稼働状況を見てもらうなど、PCごとに頼む内容が違います。
以前なら、PCを開いてターミナルやファイル管理画面から調べていた内容です。今はiPhoneから調査を頼めるため、外出先でも必要な情報に手が届きます。
ただし、操作できる範囲は接続先のPCの状態次第です。PCの電源が落ちていたり、必要な権限がなかったりすれば操作できません。OSの更新や再起動を伴う作業など、途中で接続が切れる処理にも注意が必要です。接続できないときは、まず原因の調査から始めることになります。
ファイル削除や既存コードの上書きには、特に慎重になっています。GitHubの正本があっても、未コミットの作業を失えば元に戻せない場合があるためです。
作業の現在地を知りたくてYAMATOも作った
MacとWindowsで複数の開発を進めていると、今どのIssueを扱っているのかが分かりにくくなりました。毎回GitHubと各PCを調べるのも手間です。
そこで、GitHubのIssueや作業記録をまとめて見るためにYAMATOダッシュボードを作っています。私がChatGPTで指示を出したあと、進行中の仕事や確認が必要な項目を把握するためのものです。
ただし、ダッシュボードの表示が最新とは限りません。表示と実際の状況が食い違ったら、確認先はGitHubと各PCのログです。YAMATOでは、作業の状態をひと目で把握できるようにしています。
iPhoneから作業するようになって
「掃除！」を作ってみて、iPhoneからの指示でも普段の開発をかなり進められると分かりました。Mac miniではXcodeを使い、Windowsでもコードを扱っています。その間にあるのがChatGPTとDesktop Commander Remoteです。
ただ、PCが増えるほどGitHubの状態を確かめる必要も出てきます。コードの修正報告だけで判断せず、動かしたいビルドが実際にどの変更を含んでいるかまで確認する。今のところ、この運用で開発を続けています。
外出先からMac miniのログを確認でき、Windowsでの開発も進められるようになりました。次に新しいアプリを作るときも、まずはこの環境を使うつもりです。