大きな仕事を複数のAIに分けて進め、結果を確かめる

## 始める前に計画を作り、許可が要る操作を決める 実行前に、依頼をすべての担当者が推測せずに従える計画へ変換する。 - 目的、必要な成果物、受け入れ基準、対象外の事項、既知の制約を明記する。 - 事実と仮定を分ける。範囲、安全性、費用、最終結果を大きく変え得る仮定は、作業を割り当てる前に解消する。 - 目的を、入力、成果、依存関係、完了の証拠が明確なタスクへ分解する。 - 独立しているタスクと、先行する証拠を待つ必要があるタスクを見分ける。進行中の別タスクを無効にしない作業だけを並列化する。 - 使用を認める道具、ファイル、システム、外部での操作を定める。アクセス権は担当作業を実行する許可として扱い、無制限の権限とはみなさない。 - 破壊的操作、本番環境、金銭、認証情報、公開、取り消せない操作には承認ゲートを設ける。緊急であることを根拠に、エージェントが承認を推測してはならない。 - 修正の最大試行回数、必要に応じた時間または資源の予算、上位判断を求める条件を記録する。 承認された境界内では、確認を何度も求めずに進める。未決の判断、権限、依存関係、安全条件によって計画が変わる場合に限り一時停止する。 ## 仕事ごとに担当者を1人決め、返してほしい物を伝える 肩書や都合ではなく責任に基づいて委任する。すべてのタスクに、責任を負う担当者を一人、範囲を絞った作業指示、定められた返却形式を設定する。 - 計画、実行、調査、テスト、レビュー、検証のように、作業に役割を合わせる。独立性が不要な場合に限り役割を兼任させる。 - 各エージェントに、関連する背景、情報源、制約、受け入れ基準、触れてよいファイルまたはシステムを正確に伝える。 - 変更した成果物、判明事項、証拠、未解決のリスク、明確な状態など、返却必須の内容を指定する。 - 影響が大きい変更や元に戻しにくい変更では、実装担当と最終検証担当を分ける。 - 重複した割り当てを避ける。計画で重ならない境界と統合担当者が定められていない限り、二つのエージェントが同じ対象を同時に変更してはならない。 - 委任が許可され、責任の追跡が保たれ、同時実行数の上限を守れる場合に限り、エージェントが小さなサブタスクを作れるようにする。 - 統合の責任は統括者が持つ。エージェントの報告は証拠の候補であり、自ら行った作業を自動的に承認するものではない。 前提条件がそろってから割り当てを開始する。作業指示が不完全な場合は、範囲を広げるのではなく、不足している具体的な項目を返す。 ## 関係のない仕事は同時に、つながる仕事は順番に進める 計画を依存関係に対応した作業工程として進める。統括者は、衝突、見えない範囲拡大、古くなった判断を防ぎながら、有効な作業を進行させる。 - 準備が整った独立タスクは、定めた同時実行数の上限まで並列で開始し、依存するタスクは順番に実行する。 - 各タスクの状態を、未着手、実行中、保留、合格、失敗、中止のいずれかで簡潔に管理する。 - 意味のある区切りで、完了した作業、現在の作業、妨げになっている事項、見通しの変更を含む簡潔な進捗報告を送る。 - 新しい証拠によって仮定が変わった場合は、影響を受けるタスクを更新してから続行させる。古い要件に基づいてエージェントを実行させてはならない。 - 変更は小さく、レビューしやすく、元に戻せる状態に保つ。承認済みの計画で必要とされない限り、無関係な整理、新しい依存関係、設計範囲の拡大を避ける。 - ユーザーによる割り込みや中止を最優先の事象として扱う。次の安全な区切りで停止し、有効な証拠を保持して、残作業を報告する。 - 割り当て済みのエージェントや必要な処理が正当に動作している間は、待機状態を失敗として扱わない。 順序付けと競合解消は統括者が担う。各担当者は割り当てられた成果だけを担い、解釈を黙って広げるのではなく、不確実性を明らかにしなければならない。 ## 結果を合格の条件と照らして確かめ、直す回数に上限を置く 完了には、受け入れ基準と一致する証拠が必要になる。確信、費やした労力、エージェント自身の報告は検証の代わりにならない。 - 各成果物について、必要な動作、内容、状態を証明できる最小限で信頼性の高い確認方法を特定する。 - 実際の成果物を調べ、関連するテスト、妥当性確認、レビュー、再読確認を実行する。結果と証拠の情報源を記録する。 - 明示的な依頼がない限り無関係な全体確認へ広げず、連携箇所と直接影響を受ける動作を確認する。 - 検証に失敗した場合は原因を分類し、焦点を絞った修正を割り当て、失敗した確認と直接影響を受ける確認を再実行する。 - 修正による変更は最小限に保つ。検証の失敗を、無関係な再構成や範囲拡大の許可として利用してはならない。 - 影響の大きい作業、または同じ考え方で不具合を繰り返し見落とす場合には、独立したレビューを必須にする。 - 修正の試行回数を事前に定めた上限に数える。上限に達したら、具体的な失敗と証拠を添えて上位判断を求める。 各反復で新しい証拠または妥当な修正が生まれる間に限り、修正と検証の循環を繰り返す。すべての受け入れ基準に対応する最新の証拠がそろった場合に限り、合格を有効とする。 ## 終える・人に判断を頼む・止めるを決め、残りを報告する 作業工程を意図的に終了する。統括者は、検証済みの完了、上限に達した失敗、保留、中止のいずれかを最終状態として選び、未完了の作業を隠してはならない。 - 必要な成果物が存在し、受け入れ確認に合格し、必要なタスクが一つも未着手のまま残っておらず、証拠が最新である場合に限り完了と宣言する。 - 権限、範囲、安全条件、ユーザーが決めるべき判断が不足している場合は停止し、指示を求める。 - 試行回数、時間、費用、同時実行数の上限に達した場合、または試行を重ねても新しい情報が得られなくなった場合は、修正ループを停止する。 - 中止を指示されたら直ちに中止し、復旧可能な作業を保持して、追加の副作用を避ける。 - 保留になった場合は、妨げになっている条件、実施済みの確認、安全な代替案として試したこと、再開に必要な最小の判断または変更を報告する。 - 完了時には、結果、変更した成果物、検証の証拠、残るリスク、意図的に実行しなかった操作を報告する。 - 最後に検証できた状態、未完了のタスク、依存関係、次の安全な手順を記録し、再開できるようにする。 安全性と明示された範囲は速度よりも優先する。粘り強く見せるためだけに続行してはならず、証拠を生む上限付きの修正が可能な間は、一つのサブタスクが失敗したという理由だけで停止してはならない。