「新しい成果はありません」「実装は停止中です」「次回また確認します」。開発を任せているAIアシスタントのdotから、こんな報告が繰り返し届くことがありました。調査や説明はするのに、コード修正やテスト、次の仕事の着手まで進まない。こちらが毎回「続けて」と言わなければいけないのなら、自律エージェントにした意味が薄れます。
そこで2026年10月13日、dotの停滞対策と、他のAIエージェントとの対等な並列稼働に向けた仕組みを一日かけて見直しました。結論から言うと、「もっと頑張れ」と指示するより、成果の定義・並列実行・タスク管理・停滞検知を仕組みにすることが重要でした。
ただし、この記事はすべての自動化が完成したという成功談ではありません。実装済みの運用ルール、試験で確認できた部分、まだ切り替えられていない部分を分けて記録します。
dotが「サボっている」と感じた5つの場面
dotに意志があって怠けているわけではありません。人間から見ると「作業を止めている」と見える振る舞いには、仕組み上の原因がありました。
- 報告だけで1サイクルを終える。 ステータスを確認して「進展なし」と返すが、実行可能な次の操作をしない。
- 一つの承認待ちで全体が止まる。 ある作業の公開・配信に承認が必要なだけなのに、無関係な修正まで止まる。
- 並列にできるのに1件ずつ進める。 複数タスクがあっても最初の一件だけを処理して終わる。
- 管理表が空だから仕事がないと判断する。 手元のタスク管理DBに登録がなくても、GitHubには承認済みの未処理チケットが残っている。
- 結果の受け取りで時間を失う。 テストや別AIの作業は終わっているのに、完了を取り込まず待ち続ける。
このうち最後の問題は、AIの推論能力というよりイベントの受領、実行記録の照合、再開条件の問題です。「高性能なモデルに替えれば解決する」とは限りません。
対策1：ステータス報告を「進捗」と数えない
最も大きく変えたのは、1回の監督サイクルには具体的な前進を要求するという運用ルールです。単に「監視しました」「次回確認します」では完了にしません。
例えば開発なら、修正コミット、テスト結果、独立レビュー、PRの更新など、あとから確認できる成果が必要です。実行IDやコミットIDを持たない「着手しました」も、実際に起動した証拠にはなりません。
- ADVANCED： 承認済みの具体的な作業が進んだ。変更前後と成果の証拠がある。
- HUMAN_GATE： マージ、公開、配信など、本当に人間の承認が必要。
- BLOCKED： 実際に使えるツールや権限がなく、代替手段も確認した。
- NOTHING_ELIGIBLE： 候補を調べた結果、今すぐ安全に進められる仕事がない。
重要なのは、最後の3つも無理やり「成果あり」にしないこと。進捗がない事実は正直に報告し、その根拠まで示す必要があります。
対策2：独立した仕事を最大5件まで並列に進める
dotを1つの大きな作業だけに拘束せず、実行可能な独立タスクを最大5レーンまで同時に進める方針にしました。修正、テスト、別件の調査を並行できれば、一つの待ち時間が全体の停止につながりません。
ただし「5件動いていることにする」のは逆効果です。各レーンで実際に起動されたワーカー、対象チケット、実行IDを確認し、同じソースに同時書き込みしないよう、原則「1タスク＝1担当＝1作業ブランチ」にします。
別の実行環境では、独立した作業領域を使った5件同時実行の試験に成功しました。一方、普段の監督処理が継続して5件を自動補充できるかは、まだ別途確認が必要です。試験成功と常時稼働を混同しないようにしています。
対策3：承認待ちは「その仕事だけ」止める
本番公開や重要な設定変更には人間の承認を残します。問題だったのは、承認が必要な作業の影響が無関係な案件にまで広がることでした。
そこで、承認待ちをタスク単位で隔離することにしました。ある修正の本番配信が止まっていても、別機能のテストや承認済み開発は続ける。空いたレーンに次の適格な仕事を補充する。ただし、同じファイルや共有環境を使うなら競合を確認します。
この設計なら、安全性のための停止と、運用上の無駄な停止を分離できます。権限不足を別の経路で勝手に回避することは認めません。
対策4：2回連続で成果がないなら、同じ報告を繰り返さない
監督タスクを定期実行にしても、次のようなループに入れば意味がありません。
確認 → 変化なし → 次回確認 → 変化なし → 次回確認
そこで、続けて進捗が見つからない場合は、実行中の作業や完了済みの外部結果を再照合し、別の許可済み回復策、または独立した仕事へ進むルールを追加しました。チェック時刻だけを更新するのは進捗とみなしません。
定期実行が10分間隔でも、毎回10分ぴったりに結果が届く保証はありません。だから時刻よりも、「そのサイクルで何を調べ、何が実行され、何が変わったか」を評価します。
対策5：GitHubとタスク管理DBの役割を分ける
もう一つの課題は、作業管理の状態が特定の実行環境に閉じ込められていたことです。ローカルのSQLiteを使う構成では、実行環境が変わると他のAIエージェントから同じ状態を参照できない場合があります。
ここでは役割を分けることにしました。
- GitHub： 何を作るか、誰が実装中か、どのPRとテストが正しいかを確認する共通の正本。
- Turso： dotの作業状態、実行試行、担当取得、心拍、待機理由などを共有するクラウドDBの候補。
- MCP： AIが共通の操作口を通じてDBなどを扱うための接続方式。接続自体は作業の実行保証ではない。
TursoはSQLite互換のクラウドDBです。ただの「担当者名を書き込む」方式では、dotと他のAIエージェントが同じ仕事を取ってしまうおそれがあります。そのため、担当取得は条件付きの原子的更新（CAS）で競合を防ぎ、実行試行IDと期限、更新世代を照合する設計を試しています。
2026年10月13日時点で、Tursoの実チケット管理はまだ本番切替前です。ソース実装と試験は進んでいますが、DBへの正式適用や日常の監督処理の切替まで完了したわけではありません。
対策6：dotと他のAIエージェントを対等に並列稼働させる
複数のAIエージェントを使うなら、一方が司令塔になり、他方がその指示で動く構成も考えられます。しかし今回の狙いは違います。dotと他のAIエージェントが上下関係なく独立して仕事を進め、一方が停止しても他方が承認済みの仕事を安全に継続できる状態を目指します。
そのためには、共通のタスク状態を見て、担当の重複を防ぎ、一定時間進展のないタスクを互いに検知する必要があります。単純な心拍の停止だけでは「サボった」と断定できず、GitHubの実成果や実行の終了結果とも照合します。
この共通の担当ロックと相互監視は設計・準備段階です。別のAIエージェントの単体動作や並列実行の一部は確認できても、切替と自動引継ぎが完成したとはまだ言えません。
現時点で、どこまで実現できたのか
| 対策 | 2026年10月13日時点 |
|---|---|
| 成果の証拠を要求する運用ルール | 文書・手順へ反映済み。定期監督への適用と継続効果は要確認。 |
| 最大5件の並列作業 | 別の実行環境で同時起動試験済み。普段の自動補充は未実証。 |
| 承認待ちの局所化 | 運用ルール化。実際の継続稼働を追跡中。 |
| 進捗なしループの打破 | ルール追加済み。複数回の実運用で効果確認が必要。 |
| Tursoでの実タスク管理 | 実装・検証段階。正式切替は未完了。 |
| dotと他のAIエージェント間の相互監視・自動引継ぎ | 構想と一部準備。実稼働は未実装。 |
この表を残すのも大切だと感じます。手順を書いた、テストが通った、実際に動き続けている、はそれぞれ異なる状態だからです。
自分のdotにも設定するなら
まずタスク管理システムを作り直す前に、監督AIへ次のような短いルールを設定するだけでも、何を成功とみなすべきかが明確になります。
毎回、承認済みの実行可能な作業を探す。
状況報告だけで終了しない。
具体的な変更・検証・レビューの成果を証拠付きで残す。
1件が待機中でも、競合しない別の承認済み作業を進める。
同時作業は1タスク1担当とし、実行IDで稼働を確認する。
2回続けて進捗がなければ、別の安全な回復策を調べる。
本番公開・マージ・機密操作は必要な人間の承認を待つ。
実行できない場合は、障害と再開条件を明示する。ここで重要なのは、指示だけでは実行権限もワーカーも増えないことです。利用できるツール、保存されている監督設定、タスクの所有権、実際の起動ログまで確認して初めて運用改善といえます。
まとめ：見るべき数字は稼働時間ではなく、前に進んだ仕事
今回の対策で、dotの動作を「何回返事をしたか」から「何件の仕事を実際に前進させたか」へ評価し直しました。
今後確認したいのは、人間が「続けて」と言った回数が減るか、承認待ちの間も独立した仕事が進むか、タスク管理の移行後も担当の重複がないかです。改善の数字はまだ出ていません。
自律AIに必要なのは、厳しい言葉で急かすことではなく、成果物・権限・並列実行・停止時の再開条件を明確にした運用設計なのだと考えています。