目的・背景
これまでの運用検討を、次の方針変更と検証計画としてまとめる。
通常作業と進行は親Terra/xhighが担い、必要な工程だけLuna/max・Sol/high・Astra/high・通常Chatの6 Proへ渡す。Pro $200のChat枠を前提に、6 Proを例外的な補助ではなく、適合する分析・設計・比較・レビューの主要担当として積極的に選ぶ。
目的は品質を保った総利用負担の削減。子の消費だけを最小化するのではなく、子に十分な推論・検証をさせ、親の再調査・再指示・再実装・再確認を減らす。総トークン数、Codex利用枠、追加クレジット、Chatメッセージ数は別の指標として扱う。節約率や各モデルの同等性能は未実証。
対象はPro $200利用者向けの運用。契約・権限・親設定を全利用者に一律適用せず、既存のユーザー選択と上書きを尊重する。本Issueの作成は、実装済み・設定変更済み・自動委譲の許可取得済みを意味しない。
確認した基準版：8a7580f1c9361df19b92c21f4d387ed653289c6e。#8で追加された通常Chat優先検討を土台に、親の役割と固定effortを含めて整合させる。
1. 初期運用のモデル・effortを固定する
| 位置付け |
モデル |
effort／選択 |
役割 |
| 親・通常作業 |
Terra (gpt-5.6-terra) |
xhigh |
依頼整理、分類、通常の調査・実装・検証、進行、結果の取りまとめ |
| 定型工程の子 |
Luna (gpt-5.6-luna) |
max |
対象・手順・合格条件の明確な取得、抽出、照合、定型処理 |
| 複雑な工程の子 |
Sol (gpt-5.6-sol) |
high |
複雑な実装、原因調査、矛盾解消、重要レビュー |
| 高度な工程の子 |
Astra (gpt-6-astra) |
high |
難しい設計・前提の再検討、重大な不確実性、現物照会を伴う高度な仕事 |
| 別の実行経路 |
通常ChatのChatGPT 6 Pro |
UIで6 Proを選択 |
材料と確認済みツールで完結する、まとまった分析・設計・比較・文案・レビュー |
- Terra子は標準ルートから外す。 通常のTerra向け作業は親が直接完結する。大量の途中情報を親から分離する明確な必要がある場合のTerra/xhigh子は、将来の例外候補として残すが、初期比較では常用しない。互換性維持のため、モデル定義や既存overrideを機械的に削除しない。
- この運用は利用者がTerra/xhighを親に選んで開始する想定。プラグインが親の保存設定・実行中の設定を無断で変更しない。別の親で開始したタスクも壊さない。
- 今回はeffortを毎回細分化して選ぶ運用をやめ、担当モデルと委譲範囲の選択に集中する。子のeffortを下げる実験は別段階に分ける。
- 固定するのは推論設定であり、担当能力や合格条件ではない。範囲外になれば担当を見直す。Luna→Terra→Sol→Astraを順番に試すことは義務にせず、最初から適任へ直接渡す。
- 明示的にmodelとeffortを指定し、実環境での対応を確認する。利用不可なら別値に黙って置換しない。要求値と観測できた実行値を分ける。6 ProをCodexの
high・maxと同等とみなさない。公式サブエージェント仕様
2. 6 Proを積極的に選ぶ分類へ整理する
まとまった思考工程の担当を選ぶ際、通常Chatで完結できるなら、CodexのSol・Astraより先に6 Proを第一候補として評価する。 難問だけに限定せず、通常の分析・比較・文書業務も候補にする。上位能力を使うための分類と、その経路を実際に利用できるかの確認は分離する。
| 作業条件 |
第一候補／進め方 |
| 材料がそろった比較、要件整理、設計、反例検討、文案、限定レビュー |
通常Chat 6 Pro。Terra・Solで同じ分析を先に済ませない |
| 公開情報や承認済み接続先の調査・資料比較 |
Chat側に必要な取得機能・権限が実在し、出典・鮮度・範囲を回収できるなら6 Pro |
| 分析と実行を切り分けられる開発・運用改善 |
Codexで必要な証拠取得→6 Proで分析・設計→親Terraまたは適切な子で実装・検証 |
| 短い確認、少量の整形、通常の局所修正 |
親Terra/xhighで完結。受け渡しのための子やChatを作らない |
| 明確でまとまった定型工程 |
委譲負担が見合う場合にLuna/max。意味判断が増えたら親へ返す |
| 編集・テスト・新しいログ確認を繰り返す複雑な工程 |
Sol/high。難しい設計前提や高度な判断が支配的ならAstra/high |
| Chatへ渡せない材料、利用不能な必須ツール、準備や全面的な再作業が過大な工程 |
Codex内の適切な担当。除外理由を具体的に残す |
利用枠を使い切ることや6 Proの利用率を上げること自体は目標にしない。一方、「念のため温存」「最後に確認だけ」といった扱いで、適合する工程をCodex側で抱え込まない。
6 Proで完了した分析を、理由なくCodexのAstraで全面的に再分析しない。追加レビューは重大な影響、矛盾、根拠不足、前提変更などの具体的な必要性に限定する。
3. 親の役割・引継ぎ・直列委譲を整合させる
親は通常作業の担当であり、全専門判断の唯一の審判ではない
- Terraは分類前に難問をほぼ解き終えない。問題の分割や受入条件の設計自体が難しければ、その検討も適任へ渡す。
- 元の依頼、重要な制約、必要な原資料への参照を保持し、子が親の誤解や不適切な分割を指摘できるようにする。
- 子へは、承認済み範囲での取得・分析／実装・通常修正・検証・証拠整理を、まとまった完了単位として渡す。
- 引継ぎは目的、対象、根拠、未解決点、合格条件、承認範囲、返却条件に絞る。repo作業ではcwd・worktree・branch/HEAD・対象差分を特定する。全履歴fork、全ログ転送、不要な保存物は増やさない。
- 返却は結論、重要差分、検証結果、根拠、前提・反例・未解決点を中心にする。親は重要な条件と証拠を確認し、有効な結果を再利用する。
- 不要な手戻りは減らすが、設計変更、承認境界、重大な不確実性、証拠矛盾によるエスカレーションは維持する。権限不足や材料不足をeffort増加で解決したことにしない。
現行の起動条件との衝突を解消する
現行のpolicy_hierarchyとChat経路は、親にも独立した有用作業があることを要求している。これは、Terraが専門工程を渡し、その結果を待って次へ進む使い方を制限する。
並列分担と、能力を補う直列の専門担当への委譲を分けて設計する。 直列委譲では、追加価値・引継ぎ負担・必要な能力を条件にし、親を働かせるためだけの無用な調査やレビューを作らない。ただし、実行環境の上位指示・ツール仕様が禁止する場合は、それを優先する。別CLIや別タスクで制約を迂回しない。
同時に委譲する独立工程は原則1件とし、Chatも含めた負担を管理する。Chat経路はrootからのみ利用し、子の再委譲や深い階層を標準にしない。必要な待機とユーザーへの進捗連絡は維持し、頻繁な状態取得や同じ成果の先回り実装は避ける。
4. Pro $200の利用枠を前提にする
2026-09-15に公式ヘルプ本文を再確認した。
- 通常ChatのGPT-6 ProはPro $200で週200メッセージ。
- GPT-5.6 Sol Proは別に日170メッセージ。両Proモデル合計では日200メッセージの上限もある。Sol Proを新しい委譲先として追加する要求ではない。
- GPT-6 Proの週次上限到達後、Pro $200ではGPT-5.6 ThinkingのMediumへ自動切替される。
- 通常Chatの枠はWork・Codexの共有利用枠とは別。
出典：GPT-5.6 and GPT-6 Pro in ChatGPT — Usage limits、Managing usage with GPT-6 Astra in Work and Codex。
上記は確認日時点の仕様であり、永久固定のサービス保証にしない。固定の日次割当や「毎週月曜日リセット」を作らず、最新の公式情報と実アカウントの表示を使う。修正・追加確認も含めてメッセージ予算を考える。ルーティングで数えたメッセージだけでは他のChat利用を含む実残枠を確定できないため、不明は不明として扱う。
6 Proの選択・表示、上限通知、モデル変更を検出した場合の扱いを明確にする。回答が得られただけで6 Pro実行とみなさない。UI観測とバックエンドのモデルID証明は別で、取得できないIDを自己申告で補わない。上限・モデル不明・必須ツール欠如では当該経路を停止し、既存の承認に従って待機またはCodex内の適切な担当を選ぶ。Work、モデルAPI、有料の追加購入へ黙って切り替えない。
5. 自動委譲の許可確認は、利用枠と別の未解決事項
個人向け利用規約の「Using our Services / What you cannot do」には、自動・プログラム的なデータやOutputの抽出、および制限の迂回に関する禁止がある。
ブラウザーで通常Chatへ送信し、回答を自動回収する具体的運用について、週200回以内であることやBrowser機能が存在することだけで許可済みと判断しない。自動回収を含む積極運用の拡大前に、公式に認められる経路・運用条件を確認し、根拠を記録する。現時点で例外適用は確認できていない。
分類方針の整備と、自動経路の有効化・拡大は分離する。未確認の許可を既成事実化せず、確認できた範囲の通常利用・受け渡しに限定する。既存のopt-inを尊重し、契約が$200であることだけで経路を自動有効化しない。機密情報、接続先の権限、外部書込み・本番操作の承認も拡大しない。
6. 想定する変更対象
plugins/codex-task-routing/defaults/config.json：summary、intro、effort、classification、parent、hierarchy、escalation、handoff等を横断して整合。plugins/codex-task-routing/defaults/templates/：分類表・有効方針・引継ぎ例を更新し、「Astra親固定」「Terra子常用」「可変effort表」と新方針の矛盾を残さない。plugins/codex-task-routing/skills/task-routing/SKILL.mdとreferences/chatgpt.md：6 Proの積極選定、直列委譲、受入・停止条件を反映。- 関連する設定・観測のreference、
README.md、docs/validation.md、必要なスクリプトとtests/。設定スキーマ・overrideの互換性を確認する。
- 配布ファイルを変更する場合はmanifestの版とパッケージ整合を更新する。親設定、認証情報、フックの信頼記録を勝手に編集しない。
7. 受入条件
8. 効果の比較・観測
最初は子のeffortを上記に固定し、親の変更と6 Pro活用の効果を切り分ける。比較対象は、Astra親の現行構成、Terra親でChatを使わない構成、Terra親で6 Proを優先する構成。通常作業と難しい判断は分け、タスクの範囲・対象版・合格条件・検証環境をそろえる。
見る指標は、品質・重大な見落とし・人間の修正量、初回受入、不要な差し戻し、親子合計のCodex利用量、6 Proメッセージ数、材料準備・受渡し・検収・待機負担。Astraの割合が下がっただけでは節約としない。 子の消費を増やしただけでも割合は下がるため、同等の成果を得るまでの絶対量と総負担を比較する。
既存のroot task IDと限定観測を再利用し、親子の二重計上や累積値の重複を避ける。取得不能な使用量は理由付きnull、要求モデルと観測モデルは別に記録する。会話全履歴の走査や計測だけの追加実行を標準にしない。少数の初期サンプルは動作確認であり、安定した節約率の証明とは区別する。
公式のモデル用途・effortの参考：Models、Subagents。本Issueの固定effortは今回選んだ検証用の運用基準であり、公式の最適設定を主張するものではない。
目的・背景
これまでの運用検討を、次の方針変更と検証計画としてまとめる。
通常作業と進行は親Terra/xhighが担い、必要な工程だけLuna/max・Sol/high・Astra/high・通常Chatの6 Proへ渡す。Pro $200のChat枠を前提に、6 Proを例外的な補助ではなく、適合する分析・設計・比較・レビューの主要担当として積極的に選ぶ。
目的は品質を保った総利用負担の削減。子の消費だけを最小化するのではなく、子に十分な推論・検証をさせ、親の再調査・再指示・再実装・再確認を減らす。総トークン数、Codex利用枠、追加クレジット、Chatメッセージ数は別の指標として扱う。節約率や各モデルの同等性能は未実証。
対象はPro $200利用者向けの運用。契約・権限・親設定を全利用者に一律適用せず、既存のユーザー選択と上書きを尊重する。本Issueの作成は、実装済み・設定変更済み・自動委譲の許可取得済みを意味しない。
確認した基準版：
8a7580f1c9361df19b92c21f4d387ed653289c6e。#8で追加された通常Chat優先検討を土台に、親の役割と固定effortを含めて整合させる。1. 初期運用のモデル・effortを固定する
gpt-5.6-terra)xhighgpt-5.6-luna)maxgpt-5.6-sol)highgpt-6-astra)high6 Proを選択high・maxと同等とみなさない。公式サブエージェント仕様2. 6 Proを積極的に選ぶ分類へ整理する
まとまった思考工程の担当を選ぶ際、通常Chatで完結できるなら、CodexのSol・Astraより先に6 Proを第一候補として評価する。 難問だけに限定せず、通常の分析・比較・文書業務も候補にする。上位能力を使うための分類と、その経路を実際に利用できるかの確認は分離する。
利用枠を使い切ることや6 Proの利用率を上げること自体は目標にしない。一方、「念のため温存」「最後に確認だけ」といった扱いで、適合する工程をCodex側で抱え込まない。
6 Proで完了した分析を、理由なくCodexのAstraで全面的に再分析しない。追加レビューは重大な影響、矛盾、根拠不足、前提変更などの具体的な必要性に限定する。
3. 親の役割・引継ぎ・直列委譲を整合させる
親は通常作業の担当であり、全専門判断の唯一の審判ではない
現行の起動条件との衝突を解消する
現行の
policy_hierarchyとChat経路は、親にも独立した有用作業があることを要求している。これは、Terraが専門工程を渡し、その結果を待って次へ進む使い方を制限する。並列分担と、能力を補う直列の専門担当への委譲を分けて設計する。 直列委譲では、追加価値・引継ぎ負担・必要な能力を条件にし、親を働かせるためだけの無用な調査やレビューを作らない。ただし、実行環境の上位指示・ツール仕様が禁止する場合は、それを優先する。別CLIや別タスクで制約を迂回しない。
同時に委譲する独立工程は原則1件とし、Chatも含めた負担を管理する。Chat経路はrootからのみ利用し、子の再委譲や深い階層を標準にしない。必要な待機とユーザーへの進捗連絡は維持し、頻繁な状態取得や同じ成果の先回り実装は避ける。
4. Pro $200の利用枠を前提にする
2026-09-15に公式ヘルプ本文を再確認した。
出典：GPT-5.6 and GPT-6 Pro in ChatGPT — Usage limits、Managing usage with GPT-6 Astra in Work and Codex。
上記は確認日時点の仕様であり、永久固定のサービス保証にしない。固定の日次割当や「毎週月曜日リセット」を作らず、最新の公式情報と実アカウントの表示を使う。修正・追加確認も含めてメッセージ予算を考える。ルーティングで数えたメッセージだけでは他のChat利用を含む実残枠を確定できないため、不明は不明として扱う。
6 Proの選択・表示、上限通知、モデル変更を検出した場合の扱いを明確にする。回答が得られただけで6 Pro実行とみなさない。UI観測とバックエンドのモデルID証明は別で、取得できないIDを自己申告で補わない。上限・モデル不明・必須ツール欠如では当該経路を停止し、既存の承認に従って待機またはCodex内の適切な担当を選ぶ。Work、モデルAPI、有料の追加購入へ黙って切り替えない。
5. 自動委譲の許可確認は、利用枠と別の未解決事項
個人向け利用規約の「Using our Services / What you cannot do」には、自動・プログラム的なデータやOutputの抽出、および制限の迂回に関する禁止がある。
ブラウザーで通常Chatへ送信し、回答を自動回収する具体的運用について、週200回以内であることやBrowser機能が存在することだけで許可済みと判断しない。自動回収を含む積極運用の拡大前に、公式に認められる経路・運用条件を確認し、根拠を記録する。現時点で例外適用は確認できていない。
分類方針の整備と、自動経路の有効化・拡大は分離する。未確認の許可を既成事実化せず、確認できた範囲の通常利用・受け渡しに限定する。既存のopt-inを尊重し、契約が$200であることだけで経路を自動有効化しない。機密情報、接続先の権限、外部書込み・本番操作の承認も拡大しない。
6. 想定する変更対象
plugins/codex-task-routing/defaults/config.json：summary、intro、effort、classification、parent、hierarchy、escalation、handoff等を横断して整合。plugins/codex-task-routing/defaults/templates/：分類表・有効方針・引継ぎ例を更新し、「Astra親固定」「Terra子常用」「可変effort表」と新方針の矛盾を残さない。plugins/codex-task-routing/skills/task-routing/SKILL.mdとreferences/chatgpt.md：6 Proの積極選定、直列委譲、受入・停止条件を反映。README.md、docs/validation.md、必要なスクリプトとtests/。設定スキーマ・overrideの互換性を確認する。7. 受入条件
python -m unittest discover -s tests -vとpython scripts/check_package.pyを含む必要な検証を通し、未実施の実環境確認は明示する。8. 効果の比較・観測
最初は子のeffortを上記に固定し、親の変更と6 Pro活用の効果を切り分ける。比較対象は、Astra親の現行構成、Terra親でChatを使わない構成、Terra親で6 Proを優先する構成。通常作業と難しい判断は分け、タスクの範囲・対象版・合格条件・検証環境をそろえる。
見る指標は、品質・重大な見落とし・人間の修正量、初回受入、不要な差し戻し、親子合計のCodex利用量、6 Proメッセージ数、材料準備・受渡し・検収・待機負担。Astraの割合が下がっただけでは節約としない。 子の消費を増やしただけでも割合は下がるため、同等の成果を得るまでの絶対量と総負担を比較する。
既存のroot task IDと限定観測を再利用し、親子の二重計上や累積値の重複を避ける。取得不能な使用量は理由付き
null、要求モデルと観測モデルは別に記録する。会話全履歴の走査や計測だけの追加実行を標準にしない。少数の初期サンプルは動作確認であり、安定した節約率の証明とは区別する。公式のモデル用途・effortの参考：Models、Subagents。本Issueの固定effortは今回選んだ検証用の運用基準であり、公式の最適設定を主張するものではない。