ChatGPT/Codexの自走をSchedulerで作るのをやめた ― 統合管理チャット＋複数Worker方式にたどり着くまで

AIにコードを書かせるだけではなく、できれば人が毎回指示しなくても開発を進めてほしい。

自分がやりたかったのは、

• TASKを実行する
• 完了したら次のTASKへ進む
• 依存関係がおかしければ修復する
• TASKがなくなったら再監査する
• 改善点を見つける
• 新しいTASKを作る
• また実装する

というループでした。

最初は、これをChatGPT/Codexの周りにSchedulerや状態管理を作ることで実現しようとしました。

かなり作り込みました。

でも最終的には、その方式をやめています。

今は1つのチャットを「統合管理役」にして、そこから作業ごとのチャットを起動し、モデルや推論レベルまで割り当てる方式で動かしています。

Claude Codeではまた違うやり方をしています。

この記事では、AIを自走させようとして、

TASK連携 → Scheduler → 修復処理 → 統合管理チャット＋複数Worker

と変わっていった経緯を書きます。

この記事は2026年8月時点で、自分が実際の開発プロジェクトをChatGPT、Codex、Claude Codeで進めている中での運用記録です。

AI製品の機能やモデル構成は今後変わる可能性があります。特定製品の優劣ではなく、現在使える機能に合わせて開発フローをどう組んだか、という話として読んでください。

そもそも何を「自走」と呼んでいるのか

ここでいう自走は、

TASK-101を実装
↓
build
↓
test
↓
完了

まで一度に実行できることではありません。

欲しかったのは、その後も続くことです。

TASK-101
↓
実装
↓
検証
↓
完了判定
↓
次に実行可能なTASKを判断
↓
TASK-102
↓
実装
↓
……

さらに、予定していたTASKを全部処理したら終了、でもありません。

実行可能TASKなし
↓
Repositoryを再監査
↓
仕様と実装を比較
↓
改善候補を抽出
↓
新しいTASKを作成
↓
実装
↓
再監査

ここまで回したかった。

つまり欲しかったのは、

「渡された仕事を処理するAI」ではなく、「製品を継続的に改善する開発環境」

です。

最初はTASK同士をつなげた

まず考えたのは単純です。

TASKに依存関係と次のTASKを持たせればいい。

例えばこんな状態です。

current_task: TASK-101
next_task: TASK-102

tasks:
  TASK-101:
    status: completed

  TASK-102:
    status: ready
    depends_on:
      - TASK-101

TASK-101が終わった。

ではTASK-102へ。

これ自体は機能します。

ただ、やっていることは、

人間があらかじめ作ったレールをAIに走らせている

だけです。

本当に困るのは、そのレールが切れたときでした。

NEXT_TASKだけでは足りなかった

長く開発していると、状態はそんなにきれいではありません。

例えば、

NEXT_TASKが存在しない

依存先TASKがすでに完了しているのにBLOCKEDのまま

完了済みTASKがNEXT_TASKに残っている

新しいTASKが追加されたが既存フローにつながっていない

仕様変更によって依存関係そのものが古くなった

といったことが起きます。

そこで、

NEXT_TASKなし
↓
残TASKを調査
↓
依存関係を再評価
↓
READYなTASKを探す
↓
次のTASKを再設定

という仕組みを追加しました。

ここからだんだん、「AIへ仕事をさせる」より「AIを動かし続けるための仕組みを作る」作業が増えていきます。

自走が切れたら直すSchedulerまで作った

次に考えたのがSchedulerです。

自走が止まるたびに人が調べていたら、自走ではありません。

なら、定期的に状態を確認して修復すればいい。

例えば、

• CURRENT_TASKが存在しない
• NEXT_TASKが存在しない
• READYなTASKが0件
• 依存関係が切れている
• 完了TASKが再度選択されている
• 状態ファイルとRepositoryが食い違っている

といった状態を見て、必要なら修復する。

ここまで作れば、かなり自走に近づくと思っていました。

TASKがなくなったら、自分で改善点を探せばいい

次の問題は、予定していたTASKを全部処理した後です。

これも止まる理由にしたくありません。

そこで、

実行可能TASKなし
↓
Repositoryを再監査
↓
SPECと実装を比較
↓
TODO / FIXME
未実装
矛盾
Test不足
UX上の問題
古い仕様
重複実装
↓
改善候補を抽出
↓
新TASKを生成
↓
実装へ戻る

というループも考えました。

目指していたものを図にするとこうです。

理想はこれでした。

人が寝ていても、

実装
→ 検証
→ 次TASK
→ 改善点発見
→ 新TASK
→ 実装

と回り続ける。

個々の処理はできる。でも「改善し続ける主体」にはなりにくかった

やってみると、ChatGPT/Codexは個々の仕事ではかなり強いです。

• Repositoryを調査する
• TASKを実装する
• buildする
• testする
• 仕様との矛盾を探す
• 次のTASK候補を考える
• 改善案を出す

これはできます。

問題は、それを、

実行
↓
状態更新
↓
次の仕事を判断
↓
必要ならTASK構造を修復
↓
改善点を探す
↓
新しいTASKを作る
↓
また実行

と一つの継続した自動改善ループとして維持することでした。

Schedulerを増やせば増やすほど、

Schedulerを監視する仕組み
状態不整合を修復する仕組み
古いルートを捨てる仕組み
再開位置を決める仕組み

まで必要になります。

だんだん本末転倒になってきました。

ここでいう「うまくいかなかった」は、ChatGPTやCodexが長いTASKを実行できない、という意味ではありません。

問題にしているのは、TASK完了後も自分で次の仕事を選び、必要ならTASK管理自体を修復し、新しい改善まで作りながら継続するループです。

そこでScheduler方式をやめた

ここで発想を変えました。

1つのWorkerをどうにかして永遠に動かすのではなく、

管理するAIと、実際に作業するAIを分ける。

ChatGPTには、別チャットを作成し、それぞれへ役割を持たせて動かせる仕組みがあります。

なら、1つのチャットを全部入りWorkerにする必要はありません。

現在は、1つのチャットを統合管理役として使っています。

今は「統合管理チャット」が中心

現在の構成はだいたいこうです。

紫が統合管理。

青系がWorker。

黄色が監査。

赤が人間判断です。

重要なのは、統合管理チャット自身がすべての作業をするわけではないことです。

統合管理役は、

• 現在のRepository状態を確認する
• 正本仕様を確認する
• 未完TASKを整理する
• 依存関係を確認する
• 次に安全に開始できる仕事を決める
• TASKを作る
• Worker用のチャットを作る
• 仕事に合うモデルを選ぶ
• 必要なら推論レベルを変える
• Workerの結果を回収する
• 次のTaskを判断する

ことに集中させています。

モデルも固定しない

ここもScheduler方式から変わったところです。

すべての作業に一番重いモデルを使う必要はありません。

例えば現在は、考え方として、

作業	モデルの考え方	推論
対象が明確な調査	軽めのWorker向け	通常〜高
通常実装	Worker向け	通常〜高
Build / Test / 修正	Worker向け	必要十分
仕様衝突	判断に強いモデル	高
Architecture横断判断	判断に強いモデル	高
最終Integration Gate	判断に強いモデル	高
単純な再確認	重いモデルを避ける	低〜通常

と変えています。

自分の現在の環境では、例えば通常WorkerをTerra、横断判断や最終監査をSolへ寄せる、といった使い分けもしています。

大事なのはモデル名そのものではありません。

「最強モデルを全作業に固定する」のではなく、統合管理役が仕事内容を見て割り当てる

ことです。

ChatGPT側は「別チャットを動かせる」から何とか成立している

ここはChatGPT側のかなり大きな利点だと感じています。

単一チャットだけなら、Scheduler方式をやめた時点で自走はかなり厳しかったと思います。

でも、

統合管理チャット
↓
別チャットを起動
↓
モデルを割り当てる
↓
作業させる
↓
結果を受け取る
↓
別のWorkerへつなぐ

という使い方ができます。

つまりChatGPT側の自走は、

自分自身がずっと作業し続ける方式ではなく、他のチャットを動かす方式

になりました。

Claude Codeとは「自走」の形が違う

Claude Codeは、今のところまた違う使い方をしています。

こちらは比較的大きな目的を渡して、そのWorker自身に長く走ってもらう方が使いやすいと感じています。

例えば、

現在のRepositoryを確認する。

仕様、実装、Test Evidence、既知問題を横断する。

決定済み事項は再質問しない。

問題を再現・分類する。

合理的な第一候補があるものは進める。

必要ならTASKを追加する。

実装、Build、Testまで行う。

本当に人間判断が必要なものだけ最後に残す。

という形です。

実際、自分のClaude Code用プロンプトには、

調査だけで終わらない
決定済み事項は再質問しない
重複Taskを作らない
未確認をPassedにしない
A/Bに合わなければC案を作る

といったルールを入れています。

イメージとしては、

Claude Codeは、

Worker自身を自走させる。

ChatGPT側は、

統合管理役が複数Workerを自走させる。

同じ「自走」という言葉でも、最終的にかなり違う構成になりました。

CodexではWORK_PACKETで範囲を絞った

ChatGPT側のWorkerとしてCodexを使う場合も、自由にRepository全体を改善させる方式から変えています。

現在はWORK_PACKETのような作業票を作り、

baseline: <commit>

read_set:
  - 対象SPEC
  - 対象コード
  - 対象Asset
  - 対象Test

write_set:
  - 指定した変更対象

forbidden:
  - 共通schema
  - 共通renderer
  - project file
  - HUB_STATE

のように範囲を決めます。

調査だけなら、さらに厳しくします。

read-only Worker

読んでよいもの:
  対象SPEC
  対象コード
  対象Asset

書いてよいもの:
  WORK_RESULT 1ファイルだけ

製品コード:
  変更禁止

こうすると、複数Workerを並列に動かしやすくなります。

並列化しても、好き勝手には触らせない

例えば実際の運用では、

調査結果が2件返ってきても、すぐ実装しません。

まず統合側で、

• baselineは一致しているか
• read-setを守ったか
• write-setが競合しないか
• 共通ファイルを両方が変更しようとしていないか
• rollbackできるか
• 人間判断が混ざっていないか

を確認します。

その後に実装Workerを起動します。

Scheduler方式と統合管理方式の違い

自分の中では、ここが一番大きな違いです。

Scheduler方式	統合管理チャット方式
1本の実行ループを維持する	作業単位でWorkerを作る
NEXT_TASKを修復する	状態から次の仕事を再生成する
同じ実行主体を再開させる	必要なら新しいチャットを作る
AIの継続を重視	開発状態の継続を重視
モデルは固定しやすい	仕事ごとにモデルを変える
ループ異常の修復が必要	Workerを捨てて作り直せる
状態管理がSchedulerへ寄る	状態をRepositoryとHubへ寄せる

Scheduler方式では、

「このAIをどうやって走らせ続けるか」

を考えていました。

今は、

「この開発をどうやって進み続ける状態にするか」

を考えています。

似ていますが、かなり違います。

チャットを開発状態そのものにしない

統合管理方式にしてから特に重要だと思っているのがこれです。

現在状態をチャットだけに持たせない。

Repository側に、

AGENTS.md
HUB_STATE
SPEC
TASK
WORK_PACKET
WORK_RESULT
Git

を残します。

するとWorkerが終わっても、

正本を読む
↓
HUB_STATEを読む
↓
WORK_PACKETを読む
↓
Gitを確認する

ことで復元できます。

Worker Aが駄目ならWorker Bを作ればいい。

別モデルへ変更してもいい。

監査だけ別のAIへ渡してもいい。

チャットを交換可能にするために、状態を外へ出す。

これはSchedulerを作っていた頃には、今ほど強く意識していませんでした。

古い情報を読ませないことも重要になった

長くAI開発を続けると、Repositoryには大量の過去があります。

旧SPEC
旧PLAN
完了TASK
昔のScheduler
廃止したAutomation
途中で捨てた設計
古いAIの状態ファイル

AIに、

Repository全体を読んで判断して

とだけ渡すと、それらも全部判断材料になります。

そこで現在は正本への入口を決めています。

例えば、

README
↓
HUB_STATE
↓
残TASK
↓
完了一覧
↓
確定仕様
↓
仕様優先順位
↓
対象WORK_PACKET

のような順番です。

さらに、

旧仕様を現在状態として使わない
完了TASKを理由なく再Openしない
旧Schedulerを復活させない
旧Automationを再実行しない

といった禁止事項も明示します。

自走させるほど、

何をしてほしいか

と同じくらい、

何をしてはいけないか

が重要になりました。

人間はどこに残すのか

統合管理役を置いても、全部をAIへ決めさせるつもりはありません。

例えば、

既存仕様から一意に判断できる
安全側の第一候補がある
局所的な実装判断
テスト方法の選択

はAI側で進めます。

一方、

製品価値
UXの大きな方向転換
セキュリティ方針
権利・ライセンス
外部公開
破壊的変更

などは人間へ戻します。

ただし、

どうしますか？

だけで大量に返されても困ります。

そのため、

HUMAN_DECISION_REQUIRED

1. ○○
   推奨: A
   理由: ...
   影響: ...

2. ○○
   推奨: B
   理由: ...
   影響: ...

のように、推奨案まで作らせます。

人間はAIの続きを作業するのではなく、

AIでは決めるべきでないところだけ決める

形に寄せています。

自走には少なくとも2種類あった

ここまでやって、自分の中では「AIの自走」を2種類に分けるようになりました。

Worker型の自走

Goal
↓
調査
↓
実装
↓
検証
↓
次を判断
↓
継続

Worker自身が走り続ける方式です。

今のところClaude Codeはこちらへ寄せています。

Orchestrator型の自走

現在状態
↓
統合管理
↓
Task作成
↓
モデル選択
↓
Worker起動
↓
結果回収
↓
監査
↓
次Task

Workerは交換可能です。

ChatGPT/Codex側は現在こちらです。

最初に作ったSchedulerは無駄だったのか

結果だけ見ると、Scheduler方式はやめました。

でも無駄だったとは思っていません。

Schedulerを作るためには、

何をもって停止とするのか
現在状態とは何か
次TASKはどう決めるのか
依存関係は誰が持つのか
どこまで自動修復してよいのか
どこから人間判断なのか
どうすれば途中から再開できるのか

を決める必要がありました。

それを考えた結果、

HUB_STATE
WORK_PACKET
WORK_RESULT
Integration Gate

という現在の構成につながっています。

1つのAIを止めない仕組みを作ろうとして、AIを交換しても止まらない仕組みに変わった。

これが一番大きな変化だったと思います。

今の構成

2026年8月時点では、おおむねこうなっています。

役割	主に使っているもの	動かし方
全体管理	ChatGPT統合管理チャット	状態確認、Task作成、Worker起動
長時間の横断作業	Claude Code	Worker自身を大きく自走
Repository調査	Codex	WORK_PACKET単位
実装・Build・Test	Codex / Claude Code	作業範囲を決めて実行
横断監査	ChatGPT / 判断向けモデル	Worker結果を別視点で確認
製品判断	人間	HUMAN_DECISION_REQUIREDのみ

完成形とはまだ思っていません。

ChatGPT側も、統合管理チャットが状態を正しく追い続けられなければ崩れます。

古い仕様を拾うこともあります。

Workerの完了判定をそのまま信用できないこともあります。

モデルや推論レベルの割り振りも、まだ試行錯誤しています。

それでも、Schedulerで1本の自走ループを維持していた頃より、かなり扱いやすくなりました。

まとめ

最初は、

1つのAIを自走させる

ことを考えていました。

そのために、

• TASKを連携した
• NEXT_TASKを管理した
• 依存関係を持たせた
• 状態を保存した
• 自走が切れたら直すSchedulerを作った
• TASKがなくなればRepositoryを再監査させた
• 改善候補から新しいTASKを作らせようとした

ところが、仕組みを増やすほど「自走を維持するための仕組み」の管理が増えていきました。

そこでScheduler中心の設計をやめました。

今は、

1つのChatGPTチャットを統合管理役にする。

そこからTaskを作る。

仕事内容に応じてモデルと推論レベルを決める。

別チャットをWorkerとして起動する。

結果を統合管理役へ戻す。

監査する。

そして次のWorkerを起動する。

という構成です。

Claude Codeでは、逆にWorker自身を長く自走させています。

最終的に分かったのは、

「AIを自走させる」という言葉だけでは設計できない

ということでした。

Claude CodeのようにWorker自身を走らせる方法もある。

ChatGPTのように複数チャットをオーケストレーションする方法もある。

CodexのようにWORK_PACKETで範囲を限定したWorkerとして使う方法もある。

今は、

止まらないAIを1人作ることより、Workerが止まっても交換して次へ進める開発環境を作ること

を重視しています。

Schedulerを作っていた頃に欲しかった「自走」とは少し違います。

でも、実際の開発では今の方がずっと自走に近い状態になっています。

---

タグ

• ChatGPT
• Codex
• ClaudeCode
• AIエージェント
• AI駆動開発