Codexのタスク分担設計：引継ぎ・権限・結果の検収

Codexの分担設計は、独立して検収できる調査やレビューから試すと、親が統合すべき責任を明確にできます。引継ぎには対象ファイル、確認資料、返す証拠、未確認事項を含め、ツール権限はOWASP: Excessive Agencyの最小化の考え方も参考にします。分担した事実だけで品質や費用の改善を判断しません。

Codexで複数の仕事を進めるとき、分担先のモデルを先に決めるより、どの工程を切り出せるか、何を引き継ぐか、結果をどう検収するかを決める必要があります。この課題を扱うために、AcecoreはCodex Task Routingを公開しました。

親の仕事と専門工程を分ける

通常の調査・実装・検証は親が進めます。独立した専門工程に具体的な追加価値があるときだけ担当を切り出し、利用者が選んだ親のモデルや推論設定は変更しません。同じモデルへ仕事を渡すためだけの分担や、親の独立作業がない並列化を避ける方針です。

分担の単位は「記事を1本書く」では足りません。参照する一次資料、作業範囲、必要なツール、完了条件、確認できなかった場合の返却条件まで短く渡します。親は返ってきた結論だけでなく、重要な差分と根拠を確かめます。

方針の版と実行事実を分ける

プラグインは有効な方針とそのハッシュをタスク開始時に提示します。個別設定を上書きできても、親の設定や既存の上書きを勝手に変更しません。フック自身はモデルを呼ばず、ネットワーク通信も行いません。

設定に書かれたモデル名は、実際にそのモデルが動いた証拠にはなりません。接続先、実行環境、結果を別に確認し、利用量を測れなかった項目は欠測として残します。通常Chatを使う経路も任意であり、利用可能性や送信許可が不明なら実行しない設計です。

確認済みのことと、まだ測れていないこと

方針更新PRでは134件の単体テスト、Windows・Ubuntu・macOSのCI、隔離したCodexホームでの導入・フック・再導入・解除を確認しています。Windowsの診断と配布検査は先行PRで整えました。

これらは配布物と設定経路の検査です。実アカウントでの子モデル起動、利用量や品質の改善率、すべてのホストでの通常Chat経路まで実証したことは意味しません。導入条件と操作手順は公開READMEを参照してください。