24時間働けますか？自律的AIエージェントループ × 非同期フィードバックで、開発を止めない仕組みをつくる

はじめに

AIは24時間働ける。でも、結局ボトルネックは人間じゃないか？

AIは24時間働ける、人間は勝ちようがないという言説はよく聞く。実際、Claude Codeをはじめとするコーディングエージェントは、コードを書き、テストを回し、リファクタリングまでこなす。理論上は24時間365日、疲れ知らずで走り続けられる。

しかし現実はどうだろう。タスクを定義し、依頼し、様々なコマンド実行を承認し、PRをレビューし、フィードバックするのも、マージするのも人間。仕様の曖昧さを解消するのも人間。AIがどれだけ速くコードを吐き出しても、人間が「次に何をやるか」を指示し、「これでOK」と判断するまで、開発は先に進まない。エージェントが自律的に走り続けることはできても、それを止めるのは人間だ。

つまり、AIの生産性は人間の応答速度で頭打ちになる。せっかく24時間稼働できるエンジンを積んでいるのに、8時間しか運転されず、16時間は車庫に停められているのと同じだ。

本当の意味でAIネイティブな開発フローはなんだ

我々はチーム開発のこれまでのフローに固執しているが、考え方を変えればもっと生産性を上げられるのではないだろうか。一つの仮説を立てた。

「人間がリアルタイムに張り付かなくても、AIが自律的にタスクを起票し、着手し、完了まで走り続けるループを回せるのではないか。」

ポイントは3つ。
1.自律的なタスク起票

AIがGitHub issueやコードベースの状態を読み取り、「次にやるべきこと」を自ら判断してタスクを作成する。
人間はタスクではなくもっと根幹的な目的のみを伝え、コードベースとの差分を自動で判断してタスクを作成する。

2.自動着手と連続実行

起票したタスクにそのまま着手し、実装・テスト・PRの作成・CIの通過・マージまでを一気通貫で行う。1つ終わったら次のタスクへ。止まらない。

3.人間は非同期でフィードバック

人間は自分のペースでGitHub issueを起票するだけ。方向性の修正や新しい要望はissueとして投げておけば、エージェントが次のイテレーションで拾ってくれる。
PRやmergeはゲートキーパーとせず、後追いで間違っていることや改善点をフィードバックする。

実験的なプロジェクトでの実践

この仮説を、実験的なプロジェクト reown で実践した。（プロジェクトはまだまだ未完成です）

reownとは

reownは「AIエージェントがPRを大量に生成する時代」に対応するためのGitレビューツールだ。コンセプトは "Own your codebase again, even in the age of agent PR storm"。変更の影響範囲やリスクを自動で把握し、低リスクなPRは自動承認、エージェントのPRも同僚のPRも同じ画面で切り替えなくレビューできる、そんなツールを目指している。ちなみにRustで書かれているが、筆者はRustを2日くらいしか書いたことがない。

このreownの開発を自律エージェントループで回すという実験を行った。

自律ループの仕組み

最近のAIエージェント界隈ではcronによるheartbeatパターンが注目されている。定期的にエージェントを起こし、やるべきことがあれば実行し、なければ眠る。Claude Code自体も内部的にループを回して自律的にツールを呼び出す仕組みを持っている。

今回の実験では、このループをClaude Codeの外側にもう一層被せた。シェルスクリプト agent/loop.sh がClaude Codeを繰り返し呼び出していく。

また、Claude Codeはsandboxを有効化することで多くのBashツールを安全に承認不要で実行可能とし、一方でローカルの認証情報を必要とするghコマンドの操作はシェルから決定的に実行できるようにした。

具体的には、以下のようなループを回している。

issueの取得とトリアージ
- GitHub APIで agent ラベルのついたopen issueを取得する。新規issueが見つかると、ロードマップエージェント（Claude Codeの1回の呼び出し）がプロダクトビジョン（docs/INTENT.md）と照合し、優先度・対応方針を判断してissueにコメントとラベル（planned or needs-split）を付与する。
大きなissueの自動分割
- needs-split と判定されたissueは、分割エージェントが2〜4個のサブissueに分解し、親issueをcloseする。各サブissueは1回のエージェント実行（約30ターン）で完了可能なサイズに収まるよう設計されている。
タスクの選択と実装
- planned ラベルのついた最も古いissueを選び、doing に切り替える。feature branchを作成し、実装エージェントがコードの実装・テスト・コミットまでを行う。
品質チェックと自動修正
- cargo test と cargo clippy を実行し、失敗した場合は修正エージェントを呼び出してリトライする。working treeがcleanであること、ローカルとリモートが同期していることも自動で検証する。
PR作成・CI・マージ
- pushしてPRを作成し、CIの完了を待つ。CIが落ちた場合は修正エージェントが自動でfixを試み、最大5回までリトライする。CI通過後、squash mergeを実行し、issueを done でcloseする。
タスクがなければ自らissueを提案
- planned なissueがすべて消化されると、プロダクトビジョン（docs/INTENT.md）と現在のコードベース・既存issueを照合し、「ビジョンに書かれているがまだ実現されていないこと」を自動で検出して、2〜4件の新規issueを起票する。つまり、人間がissueを書かなくてもループが止まらない。
次のイテレーションへ
- mainに戻り、5秒のインターバルを置いてループの先頭に戻る。

要するに、人間が agent ラベル付きのissueを1つ書くだけで、そこから先のトリアージ・分割・実装・テスト・PR・CI・マージ・クローズまでがすべて自動で回る。issueが尽きても、ビジョンと実態のギャップから次にやるべきことを自ら見つけ出す。人間はループの外から非同期にissueを投げ込むだけでいいし、投げ込まなくてもループは止まらない。

実際に自律して働いてくれたか？

2026年2月23日〜24日にかけて、実際にループを起動して走らせた記録がある。断続的に約8時間稼働させた結果を整理する。

合計イテレーション: 70回以上
マージされたPR: 48本
トリアージされたissue: 40件以上（優先度判断・方針コメント付き）
自動分割されたissue: 7件 → 合計23個のサブissueに展開
エージェント自身が提案したissue: INTENTとの差分から7件を自動起票
人間の能動的な作業時間: issueの起票に費やした30分程度

作業内容も多岐にわたった。依存ライブラリの追加、GitHub API連携、TUIからTauri GUIへの完全移行（プロジェクト構築→Tauriコマンド実装→TUIコード削除→ネイティブバイナリパッケージング）、フロントエンドスタック全体の構築（Vite + React + TypeScript、Tailwind CSS、Headless UI、react-i18next、共通コンポーネント群）、バックエンドの改善（async化、ページネーション、エラー型の構造化、リファクタリング）、ドキュメント整備、これらがすべて人間の介在なしに完了した。

issueを書いてラベルを貼り、あとは寝る。朝起きてGitHubを開いたら、プロダクトがTUIからネイティブGUIアプリに生まれ変わっていた。

人間が起票したissueがすべて消化されると、 docs/INTENT.md と現在のコードベースを照合し、「ビジョンに書かれているがまだ実現されていない機能」を検出して新規issueを自動起票した。起票されたissueはそのままトリアージ・実装・マージまで進んだ。人間がissueを書かなくても、ループは自走し続けた。

また面白いところは、エージェントが自分自身のワークフローの問題を修正していったことだ。

「CIのチェックが早すぎて毎回初回失敗になる」「イテレーション間隔を短くしたい」「progress.txtが無限に肥大化する」「CI待ちにタイムアウトがない」

これらの課題は人間がissueとして起票したが、修正を実装したのはエージェント自身だ。ループがループ自体を改善するというメタな展開が自然に発生した。

このアイデアを活用して我々の働き方は変えられるか

本番サービスでの実践の想定

AIネイティブな開発フローのイメージが湧いた。しかし本番環境を持つプロダクトで、AIが勝手にmergeするわけにはいかない。今回のreownの実験は、「レビューなしmerge」が許容されるサンドボックス的なプロジェクトだからこそ成立した。

では、このアプローチを本番プロジェクトに適用するにはどうすればよいか。いくつかの段階が考えられる。

ステージ1：PRストック
- エージェントは自律的にタスクを起票し実装するが、PRを作成するところまでで止める。mergeは人間が判断する。朝会のたびにレビュー可能なPRが溜まっている状態をつくる。人間のレビュー帯域がボトルネックになるが、従来より遥かに多くの改善がパイプラインに乗る。
ステージ2：リスクベース自動マージ
- まさにreownが目指していることだ。変更の影響範囲とリスクを自動で分類し、低リスクな変更（ドキュメント修正、テスト追加、lint修正、依存アップデート）はCIが通れば自動マージ。人間のレビューは中〜高リスクの変更に集中する。
ステージ3：AIレビュアーの導入
- 別のAIエージェントがレビュアーとして機能し、コード品質・セキュリティ・設計方針との整合性をチェックする。人間のレビューは、AIレビューを通過したもの、かつ高リスクと判定されたものだけに限定できる。
ステージ4：人間は「方針決定」に集中
- 日々のコーディングやレビューから解放された人間は、プロダクトの方向性、アーキテクチャの大方針、ユーザーフィードバックの解釈といった、より高次の意思決定に時間を使う。AIへのインプットは「何を作るか」「なぜ作るか」というレベルになり、「どう作るか」はAIに委ねる。reownでの実験で言えば、docs/INTENT.md（プロダクトビジョン）を書き、GitHub issueで方向性をフィードバックするだけで、実装はエージェントが走り続ける世界がすでに部分的に実現できている。