並行作業と長時間の作業

複数のAIとセッションを並行して使うほど、成果を左右するのは「誰が責任を持つか」と「どこまでを触るか」の管理になります。並行そのものは目的ではないため、弊社では範囲が重ならない作業だけを並行しています。

責任を一箇所へ戻す

一つのメインセッションが、目的を握り、設計を判断し、委譲の範囲を決め、差分を評価して受け入れを判定します。独立して進められる調査、局所的な実装、読み取り専用レビューは別のAIへ任せられますが、同じファイルや同じ設計判断を複数のAIへ同時に頼むことはしません。

別モデルの出力は、多数決の票として扱いません。根拠となるコード、テスト、実動作を確認し、最終的な判断を一か所へ戻します。委譲を何段にも連鎖させず、どのセッションが差分と検証結果に責任を持つかを明確にします。

現在はClaude CodeからCodexを呼び出し、範囲の明確な実装、通常のコードレビュー、前提や設計を疑うレビューを任せることがあります。CodexやKimiをメインセッションとして直接使う場合も、リポジトリの指示と完了条件は変えません。

範囲で制御する

worktreeはファイルを隔離しますが、複数のセッションが同じ設計を別方向へ変更することまでは防げません。だから範囲の合意で制御します。

• 読み取り専用の調査は、いつでも並行してよい
• 書き込みの前に、担当Issue、ブランチ、対象パスを明確にする
• 一つのメインプロセスは、Issueを1件ずつ完了地点まで進め、後続Issueのworktreeを先に作らない
• 同じ機能、共通基盤、横断的な設計に触る作業は並行しない
• リポジトリ全体のリファクタリングは排他的に扱う
• 作業中に見つけた別件は、その場で直さず記録して後続の作業へ回す

長時間の作業

一つの開発や監査を数時間継続することがあります。終了は時間ではなく、完了条件と検証結果で判断します。長時間実行そのものを目的にせず、合意した範囲をcommit、Pull Request、mergeなど合意した完了地点まで進めます。

長時間の作業では、Issue、worktree、commit、Pull Request、.docsなど、再開後にも確認できる場所へ状態を残します。バックグラウンドの実装やレビューには識別子と進行状況を持たせ、終了結果を回収してから次の判断へ進みます。中断、会話履歴の圧縮、セッション再開の後は、会話の記憶だけに頼らず、現在の差分、ブランチ、テスト結果を確認します。