Claude Codeを複業運営に使い始めてから、私はタスクの渡し方を一度大きく作り直した。結論から書くと、「投げたら数十分〜数時間は画面を見に戻れない」ことを前提に、確認や判断を挟まなくても止まらずに進むタスクだけを渡すようにした。子育て中はスマホを見る余裕すら数分単位でしか取れない。その制約に合わせてタスクの粒度と渡し方を変えたら、Claude Codeが「使えるツール」から「勝手に進んでいる同僚」に変わった。

目次

なぜ「対話しながら使う」が最初から破綻していたか

Claude Codeを触り始めた頃、私は普通に対話しながら使おうとした。指示を出して、返答を見て、追加で指示を出して……というやり取りを、開発でよくやるのと同じ感覚で繰り返す想定だった。

これが子育て中は成立しない。子が呼んでいる、離乳食を作る、寝かしつけに入る——画面から離れる理由は数分おきに発生する。Claude Codeが「これでいいですか」と聞いてきた瞬間に手が離せない状況になれば、そこでセッションは止まったまま放置される。戻ってきたときには何を聞かれていたか忘れていて、結局最初から指示を出し直す羽目になったことが何度もあった。

対話前提の使い方は、子育て中は「相手の返事を待てる」ことが暗黙の前提になっている。私の生活にはその前提が存在しない。

タスクを渡す前に自問する1つの質問

今は新しいタスクをClaude Codeに渡す前に、必ず1つだけ自問するようにしている。

「このタスクは、私が3時間画面を見なくても、途中で判断を仰がずに最後まで進むか」

この問いにYesと言えないタスクは、渡す前に分解する。たとえばstoreforgeの商品リサーチを丸投げしようとしたとき、「良さそうな商品を選んで」という指示では、Claude Codeが判断に迷った時点で止まる。そこで「候補を10件洗い出してCSVに条件付きで出力する」「除外基準(価格帯、競合数など)は先に数値で渡しておく」という形に分解し直した。判断が必要な箇所はすべて事前にルール化し、実行時に人間の判断を求めなくても良い状態まで持っていってからタスクとして渡す。

この自問を通すかどうかで、渡した後の展開が全く変わる。通したタスクは戻ってきたときに完了しているか、少なくとも次に何をすればいいかが明確な状態で止まっている。通さずに渡したタスクは、大抵「確認待ち」のまま何時間も止まっている。

「非同期タスク」に向く仕事、向かない仕事の切り分け

複業4事業でClaude Codeに渡すタスクを続けていくうちに、向き不向きがはっきりしてきた。

  • 向く: 完了条件が事前に定義できる作業(コードの実装、記事の初稿執筆、データの整形、リサーチの一次情報収集)。「終わったかどうか」を私が見なくても機械的に判定できるものは強い
  • 向く: 失敗しても取り返しがつく作業。draft状態で止める、PRを作るところまでで止める、といった「後で人間が最終確認する」構造にしておけば、途中経過を見られなくても事故らない
  • 向かない: 途中で方針転換が起きやすい作業。要件が曖昧なまま走らせると、見当違いの方向に数時間分の作業が進んでしまい、戻ってきたときのやり直しコストの方が大きい
  • 向かない: 公開・送信など後戻りできない操作を含む作業。ここは必ず人間の最終GOを挟む設計にしている(本ブログのWordPress公開も同様に、下書きまでは自動、公開は必ず私が手動で行う運用にしている)

この切り分けをする前は、「向かない」タイプのタスクまで渡してしまい、戻ってきたら見当違いの実装が積み上がっていて手戻りの方が大きかった、ということがあった。今はタスクを渡す前に、この4分類のどこに当たるかを考える癖がついている。

GitHub Issueを「非同期の申し送り帳」にする

もう1つ効いているのが、タスクの単位をGitHub Issueに固定したことだ。以前書いた通り、私は全プロジェクトのタスク管理をlifeリポジトリのissueに一元化している。Claude Codeへの指示もこの単位に揃えることで、「今何を渡していて、どこまで進んでいるか」を画面に張り付かなくても追える状態にした。

具体的には、Issueの本文に完了条件を箇条書きで書き、Claude Codeにはそのissue番号を渡して「このissueの内容を実装してPRを作って」と依頼する形にしている。作業中に判断が必要になった場合は、Claude Codeを止めるのではなく、issueにコメントを残してもらうルールにした。これにより、隙間時間にスマホでissueを開くだけで、「止まっているのか」「完了しているのか」「私の判断待ちなのか」が一目でわかる。3分あればissueを1つ確認して次の指示を書き込める。これが今の複業運営の実質的な司令塔になっている。

まとめ

  • 対話しながら使う前提のワークフローは、育児中の「即応答できない」制約と根本的に噛み合わなかった
  • 「3時間離れても判断待ちで止まらないか」を渡す前に自問し、通らないタスクは分解してから渡す
  • 完了条件が事前に定義できる作業・後戻りできる作業はClaude Codeに任せ、方針転換が起きやすい作業・後戻りできない操作は人間のGOを挟む設計にしている
  • GitHub Issueをタスクの単位に固定することで、隙間時間に進捗確認と次の指示出しだけで運用が回るようになった

次回は、この非同期運用を支えるIssue運用のルール、特に「Claude Codeにどこまで判断を委ねるか」の線引きをより具体的に書く。

Twitterでフォローしよう

おすすめの記事