Claude Codeでの作業の煩わしさを出発点に設計されたあるコーディングエージェントは、開発者とコードを書くエージェントの間にレビュー役のエージェントを置きます。レビュー役は、応答のたびに人間の新しいプロンプトを待つことなく、計画、実装、チェックへとタスクを進め続けられます。セッションの保持と作業の実行はサーバーが担うため、タスクを続けるためにローカルのターミナルが正常に動き続ける必要はありません。ある機能開発の実行例から、このワークフローの動きと、人間の判断がなお必要な場面が見えてきます。
音声による依頼からコーディングタスクへ
ワークフローの起点はカンバンボード、つまりカードを段階ごとに移動させるタスクボードです。列はbacklog、plan、in progress、blocked、doneに固定されています。この限定的な構成は意図的なもので、独自のステータスや自動化を開発者が細かく設定できるようにする代わりに、コーディングエージェントがタスクをたどる道筋を予測しやすくしています。
ある実行例では、音声による依頼から、/resumeのセッション一覧にGitの状態を色付きの点で示すカード26が作成されました。赤は未プッシュ、黄は未マージ、緑はマージ済みを表します。音声アシスタントは依頼を書き起こすだけでなく、ユーザーストーリー、要件、テスト基準を備えたカードを作成し、確認用に開きました。auto planとauto buildを有効にしてカードを計画の列へ移すと、コードの調査と計画の作成が始まりました。これらのスイッチは、カードが次の段階へ進んだときに計画と実装を自動で始めるかどうかを決めるものです。
▲ 音声によるタスクとセッションの状態
同じ音声操作で、ボードを開いたり過去の作業をたどったりすることもできました。別の検索では、16時間前のASCIIアイコンに関するやり取りを求めると、該当するセッションとそのターミナル上の文脈が表示されました。音声を書き起こし以外に使う具体例といえますが、あらゆるセッションで検索がどこまで確実に機能するかを示すものではありません。
レビューのループとサーバーの関係
このシステムが改善を目指すターン制のワークフローでは、開発者がエージェントの応答を読んで評価し、次のプロンプトを書きます。ここでは、開発者が最初にタスクの要件を定めます。続いてレビュー役のエージェントがコーディングエージェントの進捗を確認し、要件を満たさない計画を却下したうえで、完了条件を満たすまで作業を促します。判断の分かれるトレードオフは、エージェント同士で黙って決着させるのではなく、開発者に差し戻すこともできます。
ターミナルでの操作はコマンドラインインターフェース（CLI）が担いますが、セッションとチャット履歴は中央のサーバーに保存されます。この設計により、あるターミナルで始めたタスクを別のマシンやTelegramから再開できます。/resumeの画面にはセッションとそのGitの状態が一覧表示され、開発者はTabキーで並行するセッションを切り替えられます。
各コーディングセッションは専用のDockerコンテナ（独自のツールと依存関係を備えた隔離環境）で動き、別々のGitブランチ（コード変更の並行した流れ）を使います。ファイルの読み取り、編集、コマンドの実行は、開発者のローカルの作業ツリーを直接操作するのではなく、サーバー側の作業スペースで行われます。環境を標準化することで、クライアント端末ごとに使えるユーティリティが異なる問題を減らす狙いがあります。また、複数のエージェントが同じローカルファイルを同時に編集することなく、別々のタスクを進められます。
ターミナルのクラッシュが分離を試した
カードPHA-26の作業中、Reactベースのターミナルインターフェースが「Maximum update depth exceeded」エラーでクラッシュしました。CLIには実際の不具合がありましたが、コーディングタスクはサーバー上で動き続けました。インターフェースを開き直すと、進行中のセッションに再びアクセスできました。
▲ ターミナルのクラッシュ後も続く作業
この出来事は、アーキテクチャを限定的ながら有効に試すものになりました。今回のインターフェースのクラッシュは、今回のバックグラウンドの作業を止めませんでした。あらゆるサーバー障害や中断が無害だと示すものではありません。それでも、長時間動くコーディングの処理をターミナルの表示から切り離すことが、日常の開発でなぜ重要になり得るのかは示しています。
その後、この機能のタスクでは337件のテストが実行されました。そのうち334件が成功し、3件が失敗しましたが、失敗した3件は以前からあったベースラインの失敗と判定されました。この結果は、実行を単に成功か失敗かで語るより多くを伝えています。依頼された変更は検証まで到達しましたが、報告されたテストはすべてが成功したわけではありませんでした。
コードを書いた後に起きたこと
完成したカードが完了へと移ると、Gitの自動同期処理が引き継ぎました。システムは上流の変更を取り込み、タスクのブランチを統合して、結果をプッシュしました。GitHubのコミット5cca2faには、5つのファイルにわたるステータス表示の変更が記録されていました。その後の/resume画面には、マージ状態と色付きの点を伴うセッション履歴が表示され、改善対象だったワークフローの中でこの機能を確認できるようになりました。
統合処理は、エージェントの作業中に上流で加えられた変更を考慮するよう設計されています。コンフリクトを解消できない場合は、マージを完了扱いにせず、タスクをblockedにして人間の介入を求めます。今回の機能開発で示されたのは同期が完了した例であり、並行するブランチのコンフリクトを常に自動で解消できるということではありません。
レビュー役とコーディングエージェントの2つのエージェントは、6つの判断原則も共有しています。変更前に既存のコードを調べること、自作する前に確立された手法を探すこと、複雑さを加えるなら理由を示すこと、仮定をテストで確かめること、依頼された範囲にとどまること、エンドユーザーの体験を考えることが求められます。これらの原則は互いに逆の方向へ働くことがあります。たとえば、よりシンプルな実装では依頼されたインターフェースの動きを実現できない場合があり、設計上、こうした未解決の選択は開発者に届くようになっています。
このワークフローから得られること
ここで最も明確に示された改善点は、作業の連続性です。タスクは音声による依頼からカード、計画、コードのチェック、Gitのコミットへと進み、その途中でローカルのターミナルのクラッシュも乗り越えました。その代わりに、細かなカスタマイズではなく、決められたボードとワークフローに従うことになります。テストの失敗、起こり得るマージのコンフリクト、人間の承認の必要性も、引き続きプロセスの一部です。
同様のコーディングワークフローを組むなら、まずタスクごとに要件とテスト基準を定めましょう。長時間の実行はターミナルのインターフェースから切り離し、並行するブランチは隔離し、完了したタスクを受け入れる前にテスト結果とマージ状態を確認します。継続的に進めることが役立つ場面では自動の計画と実装を使いつつ、曖昧な点や止まった統合を人が解決できる明確な道筋を残しておくことが大切です。