エージェントIDEのクォータ切れから作業を引き継ぐ手順
今回やったこと
エージェントIDEがクォータ切れで停止したとき、計画書だけを読んで進捗を推定せず、作業ツリー・エージェントの記録・実行経路を合わせて確認する引き継ぎ手順を整理する。ここで扱うのは記録された確認項目であり、特定IDEの一般的な障害率やクォータ仕様を説明するものではない。
実装ステータス
手順記録あり。確認対象と記録されている事象を紹介する。停止後に必ず復旧できるという保証や、素材にない原因の断定は加えない。
まず作業ツリーを確認する
停止したセッションの画面に表示された要約だけでは、実際に何が変更されたかは分からない。最初に未コミットの作業ツリーを確認し、変更されたファイルと差分を把握する。計画に書かれた内容と、実際にファイルへ反映された内容は別の情報だからだ。
次に、エージェントの brain ディレクトリに残る task.md、implementation_plan.md、walkthrough.md を読む。これらには依頼内容、予定、作業説明が分かれて記録される。計画書が完成形を示していても、実装済みとは限らない。作業ツリーの差分と照らし合わせ、完了・未完了を整理してから、引き継ぎ先が読めるリポジトリ内の docs へ作業内容を退避する。
| 確認するもの | 分かること | 単独では分からないこと |
|---|---|---|
| 未コミット差分 | 実際に変更されたファイル | 変更が正しく動くか |
task.md | 依頼された作業 | 実装が完了したか |
implementation_plan.md | 想定した手順 | 計画どおり進んだか |
walkthrough.md | 作業の説明 | 説明と現状が一致するか |
確認結果は、完了した作業、未完了の作業、再確認が必要な点に分けて記録する。IDEのセッション状態に依存したままだと、次の担当が同じ探索をやり直すことになる。リポジトリ内に退避すれば、別のセッションからも確認できる。
画面とCLIの実行経路を分けて確かめる
この手順の素材では、画面のダッシュボード確認に加え、python3 run_battle_sim.py --compare -n 200 を実行してCLI経路も検証するよう記録されている。画面上で見える状態と、コマンドラインから実行した結果は同じ確認ではない。どちらか一方だけで全体の状態を判断しないための確認項目だ。
また、素材には大きなBGMなどのバイナリが原因として挙がるHTTP 400と、pre-pushフックにある「300秒以内のgit fetch」制約が記録されている。これらは引き継ぎ時に調べる対象として扱う。HTTP 400がどの条件で起きるか、発生頻度がどの程度かは記録されていないので、一般化はできない。ログや対象ファイルを確認し、実際に該当したかを区別して書き残す。
引き継ぎメモを完了条件に含める
クォータ切れからの復旧を、IDEを再び開けることだけで終わらせると、作業の所在が分からないままになる。差分とエージェント記録の照合、実行経路の確認、docsへの退避までを一続きの引き継ぎとして扱う。次の担当が必要な情報をリポジトリ内で得られる状態が、作業再開の基準になる。
この手順が解決するのは、止まったセッションから作業状態を回収するための確認漏れである。IDE側のクォータを回復させたり、外部サービスの可用性を保証したりするものではない。確認できなかった項目は「未確認」として残し、推測で完了扱いにしないことが重要になる。
更新履歴
- 2026-09-27: 初稿を作成。