Codexに「壊してよいDB」を渡す——IssueごとにworktreeとDocker実行環境を分離する

GitHub Copilotなどのエージェント型開発ツールにコード実装を委任するとき、「実装に失敗して、データベースを壊してしまう恐れ」が足枷になる。共有の開発DBを使っていれば、AIが試行錯誤するたびに他のメンバーの作業が巻き添えを食う。そこで登場するのがGit worktreeとDocker実行環境の分離戦略だ。Issue単位で、ブランチ、worktree、Docker・DB実行環境を1対1対応させる。つまり「このIssueの中なら、DBを何度壊してもよい」と明確に境界を引く。エージェント型AIへ仕事を任せる前に、失敗の影響が局限された作業環境を先に用意する。

この運用の工夫がある。最初の段階では「Git側だけ分離する」でいい。次に「実行環境も分離する」。最後に「安全な削除操作を自動化する」。必要になった機能を段階的に追加する。ただし、削除時の注意は深い。Issue固有のDocker資源だけを削除し、main側のDB資源が残ることを保証する必要がある。そのため、「名前の一致だけでは削除しない」という原則を立てている。Issue番号、ブランチ、worktreeのパス、実行環境の識別情報を多重に照合して、所有関係を確認できた資源だけを対象にする。fail-closedの判定、つまり「確認できなければ削除しない」という安全設計だ。

中小企業がAIエージェントを現場に入れるなら、この視点が重要だ。AIに「絶対に壊すな」と要求するより先に、「このスコープなら壊しても影響が止まる」という環境設計を完成させることだ。制度や手順で安全を確保するのではなく、環境の物理的な分離で安全を実現する。こうすれば、AIは遠慮なく試験と検証を繰り返せるから、実装の品質が上がる。AIに仕事を委任する仕事の大半は、その前提条件（環境・権限・失敗の許容範囲）を設計することなのだ。