ChatGPTから開発や運用を進めるために作ってきた「YAMATO」を、いったん分解して再構成しました。今回は、なぜ作り直したのか、どの役割を残して何を減らしたのか、その結果として何が変わったのかをまとめます。
僕は、自分の仕事をChatGPTから進めるために「YAMATO」という仕組みを作っています。
対象にしているのは、文章生成のようなAIらしい作業だけではありません。iPhoneアプリのコードを修正したり、Webサイトを更新したり、GitHubのIssueを確認したり、サーバーの状態を調べたりするところまで含めています。
さらに、複数のiPhoneアプリを運営しているので、App Store ConnectやTelemetryDeck、Google Search Consoleなどの数字もYAMATOへ集めています。
つまりYAMATOは、開発作業を進める仕組みと、仕事や事業の状態を確認する仕組みを組み合わせたものです。
作り始めた理由は単純でした。
ChatGPTと相談して「この機能を追加しよう」と決まっても、実際に作業を始める段階では自分でMacを開きます。そのあと、ターミナルからCodexを起動し、リポジトリを確認して、必要ならGitHubにもIssueを作らなければなりません。
相談はChatGPTで進むのに、実行へ移るところで毎回人間が橋渡しをしていました。
そこで、ChatGPTへ仕事を頼んだあと、そのまま実行まで進められる仕組みを作ろうと考えたのがYAMATOの始まりです。
ただ、作り続けていくうちに一つ問題が出てきました。
自動化するための仕組みが増えすぎて、今度はYAMATOそのものを管理する仕事が増えてきたのです。
そこで今回は、新しい機能を増やす前に構成を見直しました。
最近は「YAMATOを使って」と言わなくなった
今は、開発中のiPhoneアプリで直したいところがあれば、ChatGPTへそのまま頼んでいます。
たとえば、
「このボタンを直して、TestFlightまで進めて」
と伝えます。
以前は、そのあとにどの経路で作業を進めるのかまで自分で考えていました。
YAMATOへ仕事を渡すのか、Codexを使うのか、Macで直接実行するのか。さらに、GitHubのどこへ記録するのかも気にしていました。
現在は、そのあたりをほとんど指定していません。
ChatGPTが必要に応じてGitHubを確認し、Desktop Commander Remoteを使ってMacやWindows、Debianへ接続します。
大まかな流れは次の通りです。
僕
↓
ChatGPT
↓
GitHub
↓
Desktop Commander Remote
├─ Mac
├─ Windows
└─ Debian
YAMATOは、この実行経路の真ん中には置いていません。
仕事の状態や実行結果を集めたり、アプリ事業の数字を保存したりして、必要な情報をDashboardから確認できるようにしています。
最初に作っていたYAMATOと比べると、役割はかなり変わりました。
最初は「AIの会社」を作ろうとしていた
YAMATOを作り始めたころは、AIへ仕事を振るための組織を作ろうとしていました。
ChatGPTが方針を考えたあと、YAMATOが仕事を受け取ります。Runnerがジョブを開始し、実装はCodexやClaude Codeへ渡します。
定型処理については別のWorkerを用意し、仕事はGitHub Issueで管理する形にしました。
変更があればPRを作り、Dashboardを開けば、今どの仕事が動いているのか分かります。
この仕組みは実際にかなり動きました。
Issueを作ると処理が始まり、Codexがリポジトリを変更します。その後にテストを実行し、GitHubへpushするところまで自動で進められます。
僕がターミナルを開き、コマンドを一つずつ入力する場面は減りました。
ここまでは狙い通りでした。
ところが、実際の開発を流し始めると、別の部分で問題が出てきます。
コードは完成しているのに、仕事が終わらない
あるとき、YAMATOへ渡した仕事が途中で止まりました。
Codexによる実装は終わっています。テストにも通り、GitHubへのpushまで済んでいました。
ところが、YAMATO上では完了になりません。
原因を追ってみると、問題はコードを書く部分ではありませんでした。
publish後の処理やPRの照合、lock、checkpoint、recovery、作業ディレクトリ、環境変数など、仕事を管理するために用意した処理のどこかで止まっていました。
一度だけなら修正すれば済みます。
ただ、同じような問題が続くと、Runnerの状態を確認し、ログを読み、lockを調べ、必要なら復旧処理まで追うことになります。
AIへ仕事を任せるために作ったYAMATOを、僕自身が管理する時間が増えていました。
ここで、仕組みを増やす方向を一度やめました。
まず、誰が何を担当するのかを整理し直すことにしたのです。
Desktop Commander Remoteを使い始めて構成が変わった
見直すきっかけになったのが、Desktop Commander Remoteです。
これを使うと、ChatGPTからMacのファイルを確認したり、ターミナルを実行したりできます。Gitも扱えるため、リポジトリの状態確認から変更、pushまで進められます。
MacではXcodeを使ったビルドも可能です。
その後、Windowsにも接続しました。Debianにも同じ入口から入れるようにしています。
ここまで使えるようになると、YAMATOの中に独自の実行経路を持ち続ける意味が薄くなってきました。
Macを操作する仕組みをYAMATO側でも持つ必要があるのか。
Windows用に別のWorkerを用意する必要があるのか。
Debianへ仕事を送るために専用Queueを残す必要があるのか。
実際に3台を操作してみると、かなりの作業をDesktop Commander Remote経由で進められました。
そこで、コンピューターへ接続する役割は、こちらへ寄せることにしました。
役割を整理し直した
現在は、それぞれの役割を次のように分けています。
僕
└─ 目的を決める
└─ 最終判断をする
ChatGPT
├─ 状況を確認する
├─ 作業方針を考える
├─ 必要な仕事へ分ける
└─ 実行先を選ぶ
GitHub
├─ Issue
├─ Commit
├─ PR
└─ 実行結果
Desktop Commander Remote
├─ Mac
├─ Windows
└─ Debian
YAMATO
├─ 仕事の状態を集める
├─ 実行結果を保存する
├─ 計測データを集める
└─ Dashboardへ表示する
GitHubには仕事そのものを残します。
何を頼んだのかはIssueで確認でき、どこを変更したのかはCommitやPRで追えます。途中で使うAIが変わっても、作業するマシンが変わっても、仕事の履歴はGitHubに残ります。
一方で、MacやWindows、Debianを操作するときはDesktop Commander Remoteを使います。
YAMATOは、それらの情報を集めたり、あとから確認したりする側へ寄せました。
役割を整理すると、僕が普段見る場所も減りました。
僕が確認する場所も減った
以前は、一つの仕事を確認するために何か所も見ていました。
GitHub Issueを開き、Runnerの状態を確認します。処理が止まっていればログを読み、必要ならGitHub ActionsやMacのターミナルも確認します。
さらにYAMATO Dashboardも別にありました。
これでは、AIへ仕事を任せているつもりでも、自分で進行を追いかけています。
現在は、普段使う場所をかなり絞りました。
- 何かしてほしいときはChatGPTへ頼む
- 作業の進み具合や事業の数字はDashboardで確認する
- 詳しい履歴が必要なときだけGitHubを見る
その結果、Gitの状態や接続先まで毎回考える機会が減りました。
振り返ってみると、YAMATOを作る前に減らしたかったのは、コードを書く作業だけではなかったようです。
どのツールを使うのか、どのマシンで実行するのか、結果をどこへ残すのか。
こうした細かな判断も、それなりに手間になっていました。
Dashboardにはアプリ事業の数字も集めている
YAMATO Dashboardには、開発作業の状態だけを表示しているわけではありません。
僕は複数のiPhoneアプリを運営しているため、App Store ConnectやTelemetryDeck、Google Search Console、GA4なども確認しています。
以前は、それぞれのサービスを開いて数字を見ていました。
ただ、複数のアプリを運営していると、同じ確認作業を何度も繰り返すことになります。
そこで、計測データもYAMATOへ集めるようにしました。
各サービス
↓
Collector
↓
Store
↓
Analyzer
↓
Dashboard
Collectorでデータを取得し、Storeへ保存します。そのあとAnalyzerで過去の数字と比較し、Dashboardへ表示します。
現在はアプリごとに、ダウンロード数やDAU、継続状況、Trial、有料ユーザー、売上、検索流入などを確認できます。
ここでは、取得できなかった数字を「0」として扱わないようにしています。
たとえばAPIからデータを取得できなかった日に0件と保存すると、本当に利用者がいなかったのか、それとも取得処理が失敗したのか分からなくなるからです。
そのため、取れなかった数字は未取得として残します。
あとから推移を見る場合、この違いはかなり重要です。
数字を一か所へ集めるだけなら、表計算でもできます。
YAMATOでは、数字そのものに加えて、どこまで取得できているのか、どこに問題があるのかまで確認できるようにしています。
Mac、Windows、Debianは役割を分けたままにした
Desktop Commander Remoteから3台へ接続できるようになっても、それぞれの用途までは揃えていません。
iOSアプリの開発はMacが中心です。XcodeやTestFlightを使うため、ここはMacで作業する必要があります。
Debianには、Linuxで動かしたい処理や常時稼働させたいサービスを置きます。
Windowsにも、Windowsで使いたいアプリや確認作業があります。
以前は、これらをYAMATO側から同じWorkerとして扱うことも考えていました。
ただ、実際に使ってみると、そこまで同じ形にする必要はありませんでした。
ChatGPTから操作するときの入口だけ共通にしておけば、その先ではMac向けの仕事をMacへ、Linux向けの処理をDebianへ渡せます。
各マシンの違いを消すより、僕が接続方法を毎回考えなくて済む方が使いやすくなりました。
GitHubを仕事の基準にした
YAMATOを組み直してから、GitHubの役割は以前より大きくなっています。
AIを複数使うと、作業の状態がいくつもの場所へ残ります。
ChatGPTには会話があります。Codexには実行中の情報があり、Macの作業ディレクトリにも変更が残ります。
さらにYAMATO独自の状態まで増やすと、どこを見れば現在の仕事が分かるのか判断しにくくなります。
そこで、仕事についてはGitHubを基準にしました。
依頼はIssueへ残し、コードの変更はCommitとPRで確認します。作業が終わったら、その結果もGitHubへ記録します。
途中で使うAIやマシンが変わっても、GitHubをたどれば何をしたのか確認できます。
YAMATOでは、その情報を読み取ってDashboardへ出したり、事業データと一緒に確認したりします。
このルールを決めてから、仕組みを変更するときも迷いにくくなりました。
自動化する前に、経路を増やす必要があるか考える
YAMATOを作り始めたころは、任せられる仕事を増やすことばかり考えていました。
Runnerへ流せる仕事を増やし、Workerを追加し、途中で止まったときの復旧方法も用意しました。
現在は、何かを追加する前に、その経路が本当に必要なのかを確認しています。
その場で終わる作業なら、ChatGPTからDesktop Commander Remoteを通して対象のマシンへ入った方が早い場合があります。
一方で、長時間動かす仕事や定期的な監視であれば、専用の処理を用意した方が扱いやすくなります。
仕事内容が違うので、すべてを同じ経路へ流す必要はありません。
この考え方に変えてから、YAMATO自身が担当する範囲は狭くなりました。
その一方で、僕がChatGPTへ任せられる仕事は増えています。
変わったのは、僕がやる作業だった
最近は、iPhoneからChatGPTへ指示して、そのままアプリの修正を進めることがあります。
Macの前にいなくても、リポジトリを確認し、必要な変更を加えられます。状況によってはビルドし、TestFlightへ上げるところまで進めます。
Webサイトの修正やサーバー調査でも、同じように頼めます。
以前は、何を直すのかに加えて、どの経路で実行するのかまで細かく指定していました。
今は、何をどう変えたいのかを伝える方へ時間を使っています。
実装方法を確認する場面はありますし、最後の判断も必要です。
それでも、Gitの操作や接続先まで毎回考えることは減りました。
今回YAMATOを作り直して、最も大きく変わったのはこの部分です。
これからも、増やす前に減らせるところを探す
まだ手を入れたいところは残っています。
計測データの取得方法は改善中ですし、Dashboardへ追加したい情報もあります。長時間動く仕事や、途中で失敗した処理をどう復旧するかも詰めなければなりません。
ただ、これから機能を増やすときは、以前とは確認する順番が変わりました。
今は、次の3点を先に確認しています。
- その機能を追加すると、自分の操作は減るのか
- 同じ情報を別の場所にも持つことにならないか
- その仕組み自体を維持する作業が増えないか
この3点を先に確認します。
YAMATOの内部構造を毎回思い出さなくても、ChatGPTへ仕事を頼めば必要な処理が進み、確認したいときだけDashboardやGitHubを見る。
今は、そこまで操作を減らせる構成を目指しています。