4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Codeで「放置しても止まらない」長期駆動システムを作った

Posted at

概要

はじめに

ClaudeCode、色々質問してくるのめんどいなぁ
バグAの修正でバグB出さないでほしい
タスクリストで渡したらうまくやってくれないかなぁ→できた

思想

  • タスクリストに従って、上から順に正しく実行してくれる
  • 途中でタスクを挟んでもその順でやってくれる
  • コンパイルエラーなど、機械的に検出できるものは検知して直るまでやる
  • 間違った実装をしたら人間の指示が悪い

銀の弾丸?

not銀の弾丸

不労所得?

not不労所得

誰向け?

エンジニア向け
個人開発者、新規で猫の手も借りたいエンジニアなど

これは
 昼:タスクの作成、大きいタスクを手動実行
 夜:小さいタスクを自動実行
というシステムの構築が出来たよという紹介です

ゲームだからか、結局人の手で目視確認は必要だった
非エンジニアがこの仕組みでうまくいけてもハリボテになりそう

結果だけ

初期投資とClaudeCodeMaxプランでエンジニアの人数+1出来るよぐらいの話
寝てる間に15タスクぐらいこなしてた。それ以上はタスク考えるのが大変だったので未検証
PR見る感じ1タスク15-30分程度ぐらい。人間より早いかも。精度はまぁまぁ
仕様書駆動とテスト駆動開発の合いの子にあたりそう

ざっくりどういう仕組み?

本題。
メインループとカスタムサブエージェント、DBでタスク消化のループを実現したというだけの話
呼び方は「task-dispatchやって」だけで全部のタスクを消化するまで駆動し続ける

システム構成

「止まらない」を実現するために

タスクの質を改善する

基本的に、ClaudeCode(含めほとんどのAI)は楽をしたがります

  • テストを書いて実装、テストが通らなかったらテストの方を修正する
  • 実装してダメなら他の部分を巻き込んで一番楽な形に修正する
  • スキルを用意してるのに見ない。何度もやってダメならようやく読む
  • 前に直したバグを再発させる
  • KPI的なのを用意したらKPIにのみ適合するような修正をする

何度キレたことか

これを改善するには調査/立項と実装を分離する必要があった

そこで作ったのがタスクマネージャー(適当に作ったので後悔命名)

スクリーンショット 2025-12-31 001700.png

これ自体はタスクのjsonを可視化してちょっと編集できる程度のもの
調査/立項と実装を分ける場合、中間ファイルが必要だったのでこういったものを作成
API経由でタスク操作もできる
🤖Created By Claude Code

タスク作成スキルの追加

実質Planモードのスキルを追加した。タスクマネージャーのAPI使ってタスクを追加してくれる

ポイントはこの段階で基本的に全部読ませること(仕様書、コード)
あとテストケースを作成させること
プロダクトごとにdocsフォルダ作って、全部の仕様をmdに。これを全部読ませるようにしたら精度上がった

2-3タスクぐらいでセッション作り直して精度維持(近いタスク混ぜると前のタスクと混同するので回避)

このスキルの中で以下をやってタスク作成

  • docsを全部読む
  • タスクとテンプレートを全部読む
  • タスクのヒアリング
  • 実装を読んで編集箇所を列挙
  • 許可を出すまで方針決め
  • タスクの作成(適切なテンプレート選択、概要も埋める)
  • テストの作成

「タスクが失敗するなら人間が悪い」 の思想

タスク実行エージェントとタスクチェックエージェントの作成

基本的には単体で動作するようにという思想で実装
やることは基本的に一緒で、docsと既存コードを読ませて実装。
計画と一致しているか、不足していたら足す方向のみを許可し、やることの削除を許容しない

チェックの中身はプロダクト固有のものを多めに。
Unityのゲーム実装なのでビルドが成功するか、プレハブやシーン(見た目に関する部分)などをやってるかをチェック
別のセッションでダブルチェックして漏れてたら改善。また改善……

こうして世に言われる仕様書駆動とテスト駆動の合いの子が出来た。車輪の再発明かも

メインループの作成

メインループと実行&修正ループを作成
task-dispatchってスキルでtask-executeとtask-checkerってサブエージェントを回す
夜寝る前に「task-dispatchやって」で数時間駆動し続けて大量のPR完成

1. メインループ(Dispatch)

無限に次のタスクを処理する
タスクが終わるたびに一番上のタスクを取得するようにしてタスクの挿入とかできるようにしてる

2. 修正ループ(task-checker が NG のとき)

無限に回させたいが3回目で次のタスクへ。ただ現状そうなったことはない

なんでエージェントなの

スキルでいいじゃんと思ったけど、セッションが伸びないのが一番のメリット
起きても数十行程度のログしか残ってないので、タスク追加してそのまま次を呼べる
単体起動はしない想定でエージェントの行数削減

モデルの使い分けでコスト最適化

長時間動かすとコストがかかるため、役割に応じてモデルを選定

エージェント モデル 理由
task-dispatch Opus ループ制御だけだが最後のチェック用にOpus
task-execute Opus 実装は高性能が必要
task-checker Sonnet チェック処理は軽量
task-creator Opus 高性能にしたかった。ultrathinkも検討中
task-planner haiku API登録のみ

※task-plannerはWin日本語だからかAPI登録が文字コードなどで失敗しがちだったので分離。Unix系環境なら多分不要

戻り値の統一

エージェント間の連携は戻り値で制御

EXECUTE_RESULT: OK / FAILED
CHECK_RESULT: OK / NG

task-dispatchがこの戻り値を見て次のアクションを決定する
最初これがなくて「なんとなく終わった」で次に行ってしまって大変だった

ファイル構成

.claude/
├── agents/
│   ├── task-dispatch.md    # メインループ
│   ├── task-execute.md     # 実装担当
│   ├── task-checker.md     # チェック担当
│   └── task-planner.md     # API登録(task-creatorから呼ばれる)
└── commands/
    ├── task-dispatch.md    # /task-dispatch
    └── task-creator.md     # /task-creator(タスク作成の相談)

一番大きい部分、executeとcheckerの要約。
注意事項や必ずやってほしいことは両方に記載。それぞれのプロジェクトに合ったものにしてください

task-execute 役割: ルートタスク配下の全子タスクを実行してPR作成

フロー:

  1. タイトル名からタスク特定
  2. docs読んで調査
  3. 子タスクを深さ優先で実行(完了ごとにステータス更新)
  4. UI自己チェック(配置・参照・呼び出し確認)
  5. PR作成(通常モード or 修正モード)
  6. ルートタスクを完了に更新

重要ルール:

  • タスク完了時は即座にステータス更新 + OK確認
  • UIタスクはスクリプトだけでなくPrefab/Scene反映必須
  • 修正モード時は既存PRに追加コミット

戻り値: EXECUTE_RESULT: OK or FAILED

task-checker 役割: 完了タスクのビルド・テスト・UI反映を検証

※Unityの例

チェック項目:

# 内容
1 Unityビルド成功するか
2 EditMode/PlayModeテスト通るか
3 PR作成されてるか
4 仕様書のサンプルコードと実装一致してるか
5 新規スクリプトがScene/Prefabに配置されてるか(GUID検索)
6 SerializeFieldに参照設定されてるか
7 新メソッドが呼び出されてるか

問題発見時: 修正タスクを追加

戻り値: CHECK_RESULT: OK or NG

運用してみて

うまくいかなかったこと

  • タスクの粒度が大きすぎると失敗しがち(1機能1タスクが限界)
  • 複数ファイルにまたがる変更は混乱することがある
  • UIの配置忘れ(スクリプト書いたがシーンに置いてない)は結構あった → checkerで検出するようにした
  • ミス0は無理そう。マージ前に人間のチェックをするか、ミス前提である程度受け入れて後で修正のが必要そう
  • 見た目に関してはやはり弱め。昼は重めなスクリプトを修正させて、その裏でのプレハブやシーンを編集してる

個人開発特有の話

  • JenkinsでPRをチェックし続けて、ビルドしてexe形式で吐き出せたら自動でマージという形に(個人開発だから出来ること)
  • 並列動作するとちょっと面倒なので直列に(並列動作は可能だがトークン不足で途中で止まりそうで、実装に対するメリットが無かった)

業務で使用するために

  • 自動でPRマージはさすがに出来ないので、あさイチの仕事がPRチェックになりそう
  • 修正に関して、文脈を把握できないのである程度コメントに残させた方が良さそう(Aに対する修正でBというバグを出した、Bの修正でA発生がありうる)

感想

  • 普通に10万ぐらいで売れそうなシステムが出来て満足(8時間稼働のエンジニア換算)
  • タスク作成2時間で8時間分ぐらいの仕事してくれるので楽になった。投資効果は既に回収してる気がする
4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?