Summary
この文書の要点
- Solが要件、設計、API・データ契約、IAM・migration・cutover判断と最終統合を一貫して所有します。
- Lunaはread-only調査、Sparkは確定済み契約内の限定実装、Terraはread-onlyの独立レビューに責務を絞ります。
- 並列writeは完全に非重複のファイルを原則とし、同一生成物、DB、Terraform state、workflow、lockfile、端末全体の重い処理は排他します。
- 速度はモデル数ではなく、task packet、barrier、単一write owner、失敗時の停止条件、層別検証が揃った時に得られます。
一つの実行役へ集めると、判断と確認が同じ文脈に偏ります
一つのCodexセッションが要件整理、既存コード調査、実装、テスト、レビューをすべて抱えると、途中ログや探索結果が判断文脈を圧迫します。さらに、自分で選んだ設計を自分で検証するため、想定した正常系を確認する一方で、反証や失敗経路が薄くなりやすくなります。
そこで有効なのが、処理量ではなく責務と権限で分ける4モデル分業です。主担当は意思決定を保持し、調査、限定実装、独立レビューを別の文脈へ出します。各結果は要約と証拠に整えて戻し、主担当が同じ契約へ統合します。
ただし、4名を同時に起動すること自体を目的にしてはいけません。共有ファイルや共有状態へ同時に書けば、待ち時間より競合解消の方が大きくなります。安全性と速度の両立を図れるのは、読み取りと書き込みの境界、合流前のbarrier、検証責任が明確な場合です。
- 文脈分離: 探索ログやテスト出力を主担当へ流し込みすぎず、結論と根拠だけを返す。
- 権限分離: read-onlyの役とwriteを持つ役を明示し、全員へ同じ権限を渡さない。
- 判断分離: 実装した役とは別の役が、前提を疑い、negative pathを確認する。
- 統合責任: 最後の設計変更、差分採否、migration、cutoverは一人の主担当へ戻す。
4モデルは能力の序列ではなく、変更権限の境界で定義します
この文書では、Sol、Luna、Spark、Terraを人間の担当者名ではなく、4つのモデル役割を識別する呼称として使います。公開時点のCodex公式manualがGPT-5.6の推奨モデルとして示すのはSol、Terra、Lunaの3つで、Sparkはこの推奨3モデルには含まれません。本稿ではSparkを高速な限定実装ロールの呼称として扱い、実際のモデルIDは契約プランとクライアント版で利用可能なモデルを確認して割り当てます。
Solは主担当です。要件と非目的を整理し、アーキテクチャ、API・データ・エラー・テスト契約を決めます。IAM、migration、後方互換、cutover、rollbackのように局所実装だけでは決められない事項と、最終diffの統合判断もSolが所有します。
Lunaはread-onlyの探索担当です。既存の入口から永続化、外部連携、テストまでの経路と影響範囲を調べ、ファイル、symbol、呼び出し関係、既存テスト、未確認箇所を証拠付きで返します。修正案を先回りして書かず、調査時点のbase SHAも結果へ添えます。
Sparkは限定実装担当です。Solが確定した対象ファイル、symbol、入力、出力、エラー、テスト契約の範囲だけを変更します。契約の不足や対象外ファイルへの波及を見つけた場合は、自己判断で範囲を広げず、停止してSolへ返します。
Terraはread-onlyの独立レビュー担当です。SolやSparkの説明を正しい前提として追認せず、反例、境界値、権限不足、retry、timeout、部分失敗、rollback不能条件を探します。baseline監査と最終diff reviewを分け、未実施項目は問題なしではなく未検証として返します。
- Sol — 入力: 要求と制約。成果物: 契約、分割、統合判断。禁止: 不明点を暗黙に実装へ渡すこと。
- Luna — 入力: 調査質問とbase SHA。成果物: 経路、影響範囲、証拠、未確認。禁止: repositoryへのwrite。
- Spark — 入力: 確定済みtask packet。成果物: 限定diffと対象テスト結果。禁止: 契約や許可範囲の独断変更。
- Terra — 入力: baselineまたは最終diff。成果物: 反証、失敗経路、検証不足。禁止: 修正を混ぜることと、説明だけで合格にすること。
実装前にtask packetを固定し、曖昧さを並列化しません
並列実行へ進む前に、Solはtask packetを作ります。最低限、base SHA、目的、非目的、許可するwrite set、対象symbol、正常系と異常系の入出力、エラー表現、既存互換、必要テスト、禁止領域、停止条件を含めます。これがSparkの実装境界であり、Terraのレビュー基準でもあります。
API契約はrequestとresponseだけでは不十分です。validation、認証と認可、error code、retry可否、idempotency、timeout、観測に必要なlogやmetricまで決めます。データ契約ではnullability、既定値、一意性、更新順序、旧versionとの共存期間を扱います。
Lunaの調査で契約前提が崩れた場合は、Sparkを急いで動かさず、Solがtask packetを更新します。逆に、Sparkが未定義の分岐を見つけた場合も変更範囲を広げず、契約差分として返します。曖昧さの発見を失敗ではなく、設計へ戻すbarrierとして扱います。
- 基準点: base SHAと比較対象branchを記録する。
- 範囲: allowed files、allowed symbols、禁止領域、生成物の扱いを列挙する。
- 契約: 入出力、validation、権限、error、retry、timeout、互換性、観測を定義する。
- 完了条件: 実行するテスト、期待結果、レビュー観点、停止条件を先に書く。
三つの並列区間をbarrierでつなぎます
第一の並列区間は、Solの要件・契約整理とLunaの既存経路調査です。Solは変更後に必要な振る舞いを定義し、Lunaは現在の実装がどこを通るかを調べます。両者の結果を合わせ、Solが対象と契約を確定するまで実装へ進みません。
第二の並列区間は、Sparkの限定実装とTerraのbaseline・テスト観点監査です。TerraはSparkの差分を見る前に、既存テストが何を保証し、どの失敗経路が欠けているかを独立に整理します。これにより、実装内容へ引きずられないテスト観点を残せます。
第三の並列区間は、Terraの最終diff reviewとSolの静的検証です。Terraは正しいbaseとの差分を反証し、Solはformat、lint、typecheck、依存方向、生成物、設定整合を確認します。結果が揃った後に、Solが統合、migration、cutoverの可否を決めます。
subagentのtimeout、中断、tool失敗、一部結果だけの返却は成功に数えません。結果が来なかった観点は未検証として明示し、再実行するか、直列へ戻すかをSolが決めます。
- 区間1: Solの契約整理 + Lunaのread-only調査 → Solが契約確定。
- 区間2: Sparkの限定実装 + Terraのbaseline・テスト観点監査。
- 区間3: Terraの最終diff review + Solの静的検証 → Solが統合判断。
- 各区間の合流では、base、成果物、未確認、契約変更の有無を照合する。
write並列は完全に非重複のファイルを原則にします
並列writeを許可するのは、変更対象が完全に非重複で、生成や整形を含む間接writeも交差しない場合だけです。同一ファイルの別symbolでも、import列、formatter、code generation、共通型の変更が同じ行へ触れるため、原則はファイル単位のsingle ownerにします。symbol単位で分ける場合は、共有領域へ触れないことをSolが先に確認します。
同一生成物、DB、Terraform state、workflow、lockfileは排他対象です。package manifestを別々に変えて一つのlockfileを生成する、複数migrationを同じDBへ同時適用する、同じTerraform stateへplanとapplyを重ねる、といった操作はファイルが別でも安全ではありません。
端末全体で共有する重いqueueも競合します。全workspace build、E2E、Docker image build、coverage、依存installのようにCPU、memory、port、cacheを広く使う処理は、machine-wide heavy queueへ入れて直列化します。worktreeを分けても外部DB、Docker daemon、port、cache、remote workflowの共有は自動では分離されません。
- 並列可能: 独立した通常ファイルで、import、formatter、generator、共通型が交差しない変更。
- 単一owner: 同一ファイル、同一生成物、snapshot、package manifestとlockfile、workflow。
- 外部lock: DB migration、Terraform state、共有bucket、共有queue、共通preview環境。
- 端末queue: install、全体build、E2E、Docker build、coverageなどの重い処理。
.codex/config.tomlで役割を宣言し、指示と権限を二重化します
project設定は、信頼済みprojectでだけ読み込まれる.codex/config.tomlへ置きます。主担当をSolとし、同時に開くsubagentはLuna、Spark、Terraの3つまでにします。各役割は.codex/agents配下の独立したTOMLへ分け、name、description、developer_instructionsを必ず持たせます。
次の例では、主セッションをSolにし、LunaとTerraをread-only、Sparkだけをworkspace-writeにしています。LunaとTerraは公開時点のモデルIDを示しますが、Sparkのagent fileではmodelを固定していません。Sparkを起動する時に利用環境で確認した高速モデルを明示するか、確認済みのモデルIDだけをagent fileへ追加します。設定へAPI key、token、account ID、内部URLなどの秘密や固有情報は書きません。
sandbox_modeは重要な防御層ですが、それだけを強制境界とは考えません。親turnのlive permission overrideがspawn時に再適用される場合があるため、developer_instructions、task packet、tool権限、最終diff検査を併用します。また、read-only役がテストを実行するとDB、snapshot、cache、build成果物、portを変更することがあるため、副作用のないflagか分離環境を指定します。
- Sol: 主セッションで要件、契約、IAM、migration、cutover、最終統合を所有する。
- Luna: read-onlyで既存実装を調べ、base SHAと証拠を返す。
- Spark: workspace-writeでもallowed write setと停止条件で範囲を制限する。
- Terra: read-onlyでbaselineと最終diffを別々に監査する。
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
[agents]
enabled = true
max_concurrent_threads_per_session = 3
[agents.luna_explorer]
description = "既存経路と影響範囲を証拠付きで調べるread-only担当"
config_file = "./agents/luna-explorer.toml"
[agents.spark_worker]
description = "確定済み契約の範囲だけを変更する限定実装担当"
config_file = "./agents/spark-worker.toml"
[agents.terra_reviewer]
description = "反証と失敗経路を独立に監査するread-only担当"
config_file = "./agents/terra-reviewer.toml"name = "luna_explorer"
description = "既存経路と影響範囲を証拠付きで調べるread-only担当"
model = "gpt-5.6-luna"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
ファイルを変更しない。base SHAを記録し、入口、呼出経路、永続化、外部連携、既存テストを追跡する。
ファイルとsymbolを根拠として返し、未確認項目を明記する。
"""name = "spark_worker"
description = "確定済み契約の範囲だけを変更する限定実装担当"
model_reasoning_effort = "low"
sandbox_mode = "workspace-write"
developer_instructions = """
task packetに列挙されたファイル、symbol、入出力、error、test契約だけを実装する。
範囲外への波及や契約不足を見つけたら変更を広げず、Solへ返す。
"""name = "terra_reviewer"
description = "反証と失敗経路を独立に監査するread-only担当"
model = "gpt-5.6-terra"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
ファイルを変更しない。説明を追認せず、正しいbaseとの差分から反例、境界値、権限、失敗経路を探す。
未実施の検証を合格にせず、再現手順と不足テストを返す。
"""検証はbaseline、差分、契約、失敗経路の層に分けます
Terraは実装前のbaselineで、既存テストが通ることだけでなく、何を検証していないかを記録します。Sparkの実装後は対象テストを実行し、Solはformat、lint、typecheck、静的解析、依存方向を確認します。最終段階でTerraがbaseからのdiffを見直し、契約外変更と失敗経路を監査します。
API・データ契約では、正常系に加えてvalidation error、認証なし、権限不足、重複request、timeout、retry、部分成功、旧versionからのrequestを検証します。IAMはallowだけでなくdenyと最小権限を確認し、観測用logへ秘密や個人情報が出ないことも見ます。
read-onlyレビューでも、実行コマンドが副作用を持つ場合があります。テストDBは専用namespaceにし、snapshot updateを無効化し、cacheとbuild出力を分け、portを割り当てます。Terraがbaselineを取るために共有DBを書き換える構成は、権限上read-onlyでも運用上はread-onlyではありません。
- baseline: 既存の成功、既知の失敗、未検証、実行環境を記録する。
- diff: allowed write set、削除、rename、generated file、lockfile、秘密混入を確認する。
- 静的検証: format、lint、typecheck、依存方向、設定整合を確認する。
- 契約検証: 正常系、validation、認証・認可、retry、idempotency、timeout、互換性。
- 運用検証: health、log、metric、rollback、停止条件を確認する。
IAM、migration、cutoverは局所実装から切り離します
IAM変更は、Sparkが設定断片を編集できる場合でも、権限境界の判断をSolから移しません。必要な主体、resource、action、条件を整理し、最小権限と明示的なdeny、既存権限への影響、監査logを確認します。Terraは過剰権限と、正当な経路が拒否される反例の両方を見ます。
DB migrationでは、expandとcontractを分け、旧versionと新versionが同時に動ける期間を設けます。lock時間、backfill、再実行性、途中失敗、backupとrestore、rollback不能な変更をtask packetへ入れます。同じDBへ複数agentがmigrationを適用せず、専用環境でdry-runしてからSolが順序を決めます。
cutoverはコードが緑になっただけで実行しません。対象version、移行済みデータ、health、error rate、queue滞留、互換性、戻し先を確認します。停止条件を先に決め、異常時は追加修正をその場で重ねず、切り戻して原因を分離します。
- IAM: allow、deny、最小権限、既存主体への影響、監査log。
- migration: expand/contract、同時稼働、lock、backfill、再実行、restore。
- cutover: 対象version、health、error、queue、互換性、停止条件、戻し先。
- 最終判断: 断片を実装したモデルではなくSolが一貫して所有する。
速く見えても止めるべき兆候があります
Lunaの調査baseとSparkの実装baseがずれた場合、影響範囲の証拠は古くなっています。小さな差分に見えても再調査するか、変更された経路をSolが読み直します。古い調査結果をそのまま使うことは、並列化で得た時間を手戻りへ変えます。
Sparkが許可外ファイルを必要とする、Terraが契約自体の欠落を見つける、共有生成物やlockfileが変わる、テストが共有DBを更新する場合もbarrierへ戻します。差分を完成させるために境界を緩めると、限定実装と独立レビューの意味が失われます。
reviewerが実装者の説明を要約するだけになった場合も停止対象です。Terraにはbase、task packet、diff、テスト結果を渡しますが、実装意図を正解として固定しません。反証が出なかったことと、反証を試していないことを区別します。
- 調査baseがstaleになった。
- allowed write setの外へ変更が波及した。
- 共有state、生成物、lockfile、workflowへ同時writeが必要になった。
- read-only検証が共有DBやsnapshotへ副作用を出す。
- agentの中断やtimeoutを問題なしとして扱いそうになった。
4モデル分業が向かない変更もあります
誤字修正や一つの純粋関数の変更では、task packet作成とbarrierの費用が実装時間を上回ります。影響範囲が狭く、独立レビューの価値が小さい変更は、Solが直列に実装して通常の検証を行う方が簡潔です。
共有schema、同一Terraform state、一つのworkflow、同一lockfileを中心にした変更も、writeを安全に分割しにくい領域です。read-only調査とレビューだけを並列にし、writeは一人へ戻す方が安全です。parallelismを保つために不自然なファイル分割を増やすと、長期的な保守性を損ないます。
subagentはtoken、待ち合わせ、要約、再確認の費用を増やします。また、異なる名前を付けても同じ前提、同じ入力、同じ評価基準だけを共有すれば、独立性は見かけだけになります。役割ごとに問い、権限、完了条件を変え、必要な場面だけ使います。
- 小変更: 直列実行の方が調整費用を抑えられる。
- 共有write中心: 調査とレビューだけを並列化し、実装はsingle ownerにする。
- 高い不確実性: 先にSolとLunaで不確実性を減らし、実装を急がない。
- モデル可用性: role contractを維持し、利用できるモデルへ差し替える。
運用では速さだけでなく、競合と見逃しを測ります
運用開始時は、小さくても複数経路に影響する変更を選びます。まずSolとLuna、次にSparkとTerraを動かし、barrierで何が止まったかを記録します。全役割を常時起動するのではなく、調査量、変更境界、失敗時の影響から並列化する区間を選びます。
計測するのはlead timeだけではありません。write競合件数、契約差し戻し、stale調査、レビュー後の手戻り、未検証の持ち越し、障害で見逃した経路を記録します。速度が上がっても競合と見逃しが増えるなら、write分割を狭めるか、barrierを前へ戻します。
担当移管の条件も決めます。Lunaが設計判断を必要としたらSolへ、Sparkが契約外を見つけたらSolへ、Terraが重大な反例を見つけたら実装を止めてSolへ戻します。役割間で直接修正を回し続けず、設計の変更点を主担当へ集約します。
- 計測: lead time、並列待ち時間、write競合、差し戻し、手戻り、見逃し。
- 直列へ戻す条件: shared write、契約未確定、調査stale、環境分離不足。
- 再調査trigger: base更新、共通型変更、route変更、migration追加、テスト前提変更。
- 監査記録: task packet、base、agent結果、未検証、検証command、統合判断。
安全性はモデル数ではなく、契約と単一write ownerで作ります
4モデル分業の中心は、Sol、Luna、Spark、Terraという名称ではありません。要件と統合判断、既存経路の証拠、限定されたwrite、独立した反証を、混ぜずに受け渡せることが重要です。
並列化するのは、同時に進めても互いの前提を壊さない仕事です。共有stateや同一生成物へ触れる処理は排他し、調査とレビューを先に並列化します。writeを増やす時も、完全に非重複のファイルから始めます。
実務で持ち帰る判断軸は、task packetを固定できるか、権限を分けられるか、正しいbaseで独立検証できるか、最終判断を一人へ戻せるかの四つです。この条件が揃う範囲でだけ4モデルを使えば、安全性を損なわずに待ち時間を減らす運用を組み立てられます。
