7つのClaude Codeで一人開発　「完了は証拠で」と人が承認する5つの操作

AIの部品（モデル、ベクトルDB、エージェント、MCPなど）をつなぐ図を描くエディタ「DuctTape.io」の作者が、7つのClaude Codeのセッションをチームにして一人で製品を作る運用を、日本時間の10月8日から12日にかけてDEVに3本の記事で書いた。作者はオーストリアのグラーツを拠点とし、個人名は出していない。記事の中心は、エージェントのチームで実際に起きた失敗と、そこから決めた規則だ。完了の報告には証拠を求め、人が承認する操作は5種類に絞る。エージェントの数を増やす前に、何を信じ、どこで人が止めるかを決めておく、という筋になっている。

7つの役割と担当領域を分ける

作者は一人で7つのClaude Codeのエージェントと製品を作る方法を書いた記事（日本時間10月8日公開）で、7つのセッションを1台のサーバーで並行させていると説明した。セッションにはそれぞれ名前と役割、担当領域を決め、数日開いたままにして文脈を保つ。ただし7つ開いていても、実際に作業しているのは2〜3セッションほどだという。

担当領域の分け方ははっきりしている。Webアプリのコードを変えられるのは開発担当の1セッションだけで、カスタマーサクセス担当は読み取り専用だ。作者はAIエージェントのチームで起きる失敗をまとめた記事の前編（10月11日公開）でも、この「担当領域は1つに1人」を挙げている。ほかの担当は、その領域には提案をするところまでにとどめる。

要は、同じコードを2つのセッションが同時に書き換えない形を、役割の段階で先に決めているわけだ。読み取り専用の担当は気づいたことを開発担当への提案として渡すだけで、コードに手を入れるのはいつも1つのセッションだ。だから、誰の変更で何が変わったかを後から追いやすい。セッションを数日開いたままにするのも、担当ごとの文脈を毎回説明し直さずに済ませるためだ。

「完了」は証拠で確かめる

前編で作者が重く見ているのが、完了の報告の扱いだ。エージェントが「終わった」と言うだけでは完了と認めず、テスト結果、スクリーンショット、動くリンク、測った値などの証拠を添えさせる。作った側とは別のエージェントに検証させるのも有効だとしている。テストが通ったという一言ではなく、テストの結果そのものを見せる。画面が直ったという報告には、スクリーンショットか、その場で開けるリンクを付ける。速くなったと言うなら、測った値を出す。

人が承認する操作は、7つのエージェントを紹介した記事で5種類に絞っている。公開の投稿、リリースの公開、本番データの変更や削除、お金が絡む操作、秘密情報の扱いだ。前編でも、公開の投稿、お金、本番データの削除、秘密情報の4つを、人の承認が要る操作として挙げている。さらに、エージェント同士で「人が同意した」と伝え合うだけの話は、何を承認したかが書かれていなければ有効にしない、とも書いている。

つまり、エージェントの言葉をそのまま信じず、残った記録と証拠で判断する作りになっている。5種類の操作はどれも、間違えた時に取り消しにくいものだ。逆に言えば、それ以外の作業は人の承認を待たずに進められる。

小さく戻せる判断は人に回さない

人の承認を5種類に絞った理由は、失敗をまとめた記事の後編（10月12日公開）に出てくる。「迷ったら聞く」という決まりにしたところ、小さな質問が1日に20件ほど人に届いたという。そこで、小さく戻せる判断は調整役のエージェントが決めて記録する形に変えた。何を「小さい」とみなすかは文書にしておく。

だから、人が詰まって全体が止まることも、エージェントが勝手に大きな操作をすることも、両方を避けられる。境目を言葉で決めておくのが前提だ。調整役が決めた判断も記録に残るので、人は後からまとめて読み、違うと思えば戻せる。1日20件の質問に1件ずつ答えるより、記録を読む方が人の時間は少なくて済む。

文脈は文書に置き、資源の衝突に備える

長い会話の履歴をエージェントに持ち歩かせないのも、作者の決まりだ。仕様書、状態の文書、引き継ぎのメモを原本にして、文脈が切れたら文書を読み直して再開させる。ただし、ルールは足されるばかりで消されず、矛盾が出てくる。後編では、新しいルールを今あるルールと照らし合わせる役割を置くと書いている。文書を原本にしておけば、どのセッションの文脈が切れても、同じ文書から続きを始められる。その文書の中のルール同士がぶつからないように見張るのが、照合の役割というわけだ。

並列にしたことで、共有の資源（テストアカウント、ポート、DB）がぶつかる問題も起きた。7つのエージェントを紹介した記事によると、テストが不安定だった原因は2コア・8GBのサーバーの過負荷で、4コア・16GBに増やして直した。共有のアカウントに頼るテストが2つ見つかったので、今は1ワーカーに戻して流している。セッションを並べれば速くなるとは限らず、サーバーの大きさや、テストが共有する物まで見直す必要があったことになる。

7つのセッションを回す仕組みは、数よりも、完了を証拠で確かめることと、人が止める操作を先に決めることに支えられている。

編集部の見方

取り入れるかは別として、まず理解するなら、作者が「完了」の定義をエージェントの言葉ではなく証拠（テスト結果、スクリーンショット、動くリンク）に置き、作った側とは別のエージェントに確かめさせている所を見てみるといいかもしれない。Claude CodeやCodexに任せる作業が増えた時、自分の完了の基準がどこにあるかを書き出す手がかりになる。