タクト運用ログ vol.2 ── 実プロジェクトへのリハーサル投入で分かった統合フローの勘所
はじめに
前回の記事では、Claude Code を複数セッション同時管理する Electron オーケストレーター「タクト」の設計と Phase 1 実装までを書きました。
今回は 実プロジェクト（loopcast）への投入リハーサルを通じて見えてきた運用上の知見を記録します。具体的には次の 3 パターンのワーカー投入を行いました。
- 死活チェック（本番 URL を curl して HTTP ステータスを確認するだけ）
- LP の小さな UI 修正（比較表の空白ずれ 1 行）
-
試験ファイルの新規追加（
logger.test.tsを 1 本足す）
いずれも「ワーカーを 1 体派遣 → 計画の関所で英紀さんが承認 → integration にマージ」というフルフローを通しており、初めて実コードに触れる運用でした。
やったこと
死活チェック（確認だけタスク）
最初に試したのは最も安全な「確認だけ」タスクです。
依頼: https://〇〇.com をcurlして正常か報告せよ
やらないこと: 復旧・設定変更は一切しない
ワーカーの報告書式（固定 6 項目）はこうなりました。
## 結果
**今の状況**
✅ 正常: web 200 / api 応答あり
（トップは HTML 7.5KB を 0.14 秒で返した。/api/ は 401 JSON）
**できたこと**
- 変更したファイル: 0 件
- 記録: commit なし（変更なし）
- 読んだファイル: 0 件（curl の結果だけを見た）
ポイントは 「確認だけの依頼はモデルを Sonnet × medium に下げる」 という台帳決定を事前に入れておいたことです。Opus を使う必要がないタスクで枠を消費しないため、死活チェックや見張りを毎日複数回回しても使用量が抑えられます。
LP の小さな UI 修正（リハーサル②）
次に実プロジェクトのコードに初めて触れるリハーサルを行いました。
お題：apps/lp/src/pages/index.astro の比較表で空白が 1 箇所だけずれている
- 電気代+ PC消耗
+ 電気代 + PC消耗
同じ行の「VPS代 + 構築・保守時間」や「自宅PC + OBS」には前後に空白があるのに、この行だけ + の前に空白が無い、というずれです。変更は 1 行・1 文字。
このタスクで特に機能したのが 計画の関所（plan モード） です。ワーカーはいきなり直すのではなく、まず候補 3 つを提示します。
候補1（おすすめ）: index.astro:159 比較表の空白ずれ（1行）
→ 確かめ方: compare-plus-spacing.test.ts（新規作成）
候補2: index.astro:781 脚注の言い回しのずれ（1行）
→ 今これを確かめる試験はない
候補3: index.astro:643-762 コメントの番号の古さ（4行）
→ 画面に出ないメモの修正
「1 = 進める」と送ったら候補 1 で実装開始。試験を新規作成してから修正という順序も守られていました。
試験ファイルの新規追加（リハーサル③）
3 つ目は apps/agent/src/logger.test.ts の新規作成です。既存ファイルは一切変えず、試験ファイルを 1 本追加するだけ。
依頼プロンプトの核心部分：
## やること
apps/agent/src/logger.test.ts を新しく 1 つだけ作る（約50〜60行）。
確かめること:
1. 「info 以上」と決めたときは、debug の記録が出ない
4. warn と error は stderr に、info と debug は stdout に出る
5. 1行の形が「時刻（UTC）[部品名] [重さ] 本文」になっている
- 陽性対照: warn はエラー用の出口の期待をわざと「ふつうの出口」に書き換えて
赤になるのを見てから戻す（赤の版はコミットしない）
- 書き方は apps/agent/src/notify.test.ts に合わせる
陽性対照（意図的に失敗させてから戻す） を要求するのがポイントで、「試験がたまたまパスしているだけ」という状態を防ぎます。
ハマったポイント
1. integration worktree でテストが「準備不足」で落ちる
統合フェーズでテストを実行したとき、ワーカー側では通っていたのに統合 worktree では落ちました。
原因は pnpm install の未実行です。ワーカーは自分の worktree で install 済みですが、統合 worktree は新規作成したばかりで node_modules がありません。
# ❌ install なしでテストを実行すると準備不足エラー
PATH="/opt/homebrew/opt/node@22/bin:$PATH" pnpm test
# ✅ まず install してから
PATH="/opt/homebrew/opt/node@22/bin:$PATH" pnpm install --frozen-lockfile
PATH="/opt/homebrew/opt/node@22/bin:$PATH" pnpm test
統合タスクのプロンプトに「node_modules 等が無ければ先に install を実行する」という一文を入れることで再発を防止しました。
2. git diff --stat integration...<branch> に「main 側の進み分」が混入する
LP 修正タスク（T-0066）の統合前確認で、git diff --stat に期待外のファイルが大量に出ました。
apps/web/app/(dashboard)/billing/page.tsx ... +40 -0
apps/web/app/(dashboard)/dashboard/page.tsx ... +25 -0
... 他 39 件
これは integration ブランチが main より古く、main に既にあるコミットが「差分」として見えていた のが原因です。三点（...）記法を使えば共通祖先を起点にした差分だけ見えますが、integration 自体が main に追いついていない場合は混入します。
対処として統合担当の頭脳プロンプトに明記しました：
ほかに、integration が main に追いつく分 N commit（すでに main にあるもの。
上の件数には数えない）が出ることがある。
三点比較（integration...<branch>）で確認し、
本当にワーカーが変えたファイルだけを見る。
今回は「統合してよいか」を確認する形で処理しましたが、次回からは統合前に git merge main で integration を最新化するステップを自動化する予定です。
3. 確認タスクが stopped になっても結果は残る
死活チェック（T-0061）のログを見ると 回収 T-0061=stopped になっていましたが、ワーカーの最後のターンに報告が書かれていました。
[2026-10-01T23:57:43.591Z] 回収 T-0060=stopped, T-0061=stopped
stopped は「止まった」ではなく「外部から stop シグナルを送って終了した」という意味で、最後のターンまでは正常に動いています。回収ロジックを「done のときだけ結果を読む」にしていたため報告を取りこぼす実装上のバグがあり、修正しました。
4. 「やらないこと」を台帳 → プロンプト → doNot に三重で書く設計の有効性
LP 担当が並走中に触っている領域（Twitch の門・法務ページの日付・英語化対応など）をワーカーが誤って変えないよう、3 箇所に書きました。
-
台帳の決定済み（
state/STATE.md）：全ワーカーの--append-system-promptに渡される - タスクの doNot フィールド：タクトが派遣時に使う機械可読な禁止リスト
- タスクの prompt 本文：ワーカーが実際に読む自然言語の指示
実際、T-0066 ではワーカーが候補を探す段階で「今日の LP 担当が手がけている領域リスト」を参照して候補から外す動作が観察できました（ログの候補 2・3 が法務・英語化と無関係な箇所だったのはそのため）。
学び
「確認だけ」「ドキュメント修正」「UI 1 行」「試験追加」の順番でリハーサルを積む設計は正しかった。 統合フローのバグ（install 未実行、main 追いつき問題、stopped の誤検知）が、本番コードへの影響がない段階で全部洗い出せました。
計画の関所（plan モード → 人の承認 → 実装）は、1 行の変更でも有効。 候補 3 つ提示 → おすすめを選ぶ、という形式がワーカーの「とりあえず触ってみる」を防いでいます。
（個人の感想） 「台帳が唯一の真実」設計の恩恵を一番感じたのは、頭脳が毎回新規セッションで起動しているのに統合担当の別セッションが「ハマり欄」を読んで正しく動いたときです。ドキュメントにコンテキストを外部化しておけば、会話の記憶がなくても引き継げる、という設計の手応えを感じました。
次は T-0064（最初のリハーサル②で止まっているタスク）の後始末と、integration を main に自動追従させる仕組みの実装を予定しています。