GPT-5.6 Ultraをどこまで任せる？――検証と復旧で決める

GPT-5.6 Ultraを親タスクに設定し、Codexで記事制作システムのAgenticStructCivを複数工程にわたって組み直した一事例から、どこまで仕事を任せられるのか。答えはモデル名への一括信頼ではない。成果を別の方法で確かめられるかという独立検証と、失敗しても影響範囲を限定して基準点へ戻れるかという復旧可能性で、委任範囲を決める。

対象の受理資料には、境界付きの公式委任、自動テストの合格、独立監査からの反証、限定修正、更新後の再確認という工程線が記録されている。一方、個別不具合の症状、再現入力、正確な修正差分、条件を固定した変更件数までは、この資料だけでは確定できない。本稿は不足した具体を補って大改造の成功談を作るのではなく、確認できる工程と受入状態から委任の条件を読むケーススタディだ。

この記録から親タスクについて最も強く言えるのは、検証可能な制御の下で、複数工程の仕事を修復可能なまま統合したことである。親は仕事を分け、専門担当の返却物を受け入れ、緑のテスト後に届いた反証を修正と再検証へ戻した。大量のコードを一度に出したという評価ではなく、現在の証拠に合わせて完了状態を選び直し、収束を続けたという評価である。

FA・OA系の制御やWebアプリケーションに携わった著者経験は、最終H2で復元基準点と復旧確認を委任条件に置く判断へだけ使う。AI出力を崩れないものとみなさず、崩れたときに戻せる構造を先に置くための実務上の補助線であり、モデル固有の性能を証明する代替根拠にはしない。

持ち帰ってほしいのは、あなたの仕事を広く調べさせる、変更範囲を限定して任せる、人間が実行・承認するの三つへ置き分ける基準だ。ケースの工程を追った後、何を受入証拠にし、どこで止め、失敗時にどこへ戻すかを一枚の委任カードへ落とし込む。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

GPT-5.6 Ultraの能力をこの実録からどう読むか

対象記録を読む第一歩は、「動いたから高性能」「変更量が多いから賢い」という短絡を避けることだ。複数工程のエージェント開発では、生成物だけでなく、誰が何を判断し、どの証拠で次工程へ進んだかまで含めて評価する。

観測事実・妥当な推論・証明不能を最初に分ける

本稿では、主張を三つの証拠階層へ分ける。

• 観測事実は、対象セッション、版に結び付いた成果物、テスト結果、監査記録などから直接確かめられるものだ。「誰が実行したか」「どの成果物が返ったか」「どの判定が残ったか」を、出所と時点を伴って言える。
• 妥当な推論は、複数の観測事実を組み合わせた解釈だ。たとえば、複数工程の収束には、親タスクの判断だけでなく、状態機械、成果物契約、テスト、監査の接続が寄与したと考えられる。ただし、推論を直接記録された事実へ格上げしない。
• 証明不能は、受理資料が扱っていない内部設定や、比較条件のない一般性能である。ここには、子ごとの実効モデル設定、Ultra固有の寄与率、他モデルへの一般的優位などが入る。

この区別は免責文を増やすためではない。どの結論を導入判断に使え、どこを自分の環境で追加検証すべきかを分けるための物差しだ。以後はこの定義を繰り返さず、ケース工程、品質証拠、主体別帰属の順に役割を分けて検算する。

評価対象はモデル単体ではなく長期タスクを収束させる統合能力

単発のコード生成なら、入力と出力をほぼ一対一で比べられる。しかし複数工程の改造では、要件の解釈、作業分解、依存関係、複数成果物の受入、テスト、監査、修正、再試行が連鎖する。途中の一箇所が曖昧なままなら、ファイルが増えてもシステム全体の完了は保証されない。

身近な比喩なら、評価対象は一人の実装者というより、複雑な開発チームを率いるプロジェクトリードに近い。親タスクは何を先に行い、何を並行させ、どの結果を採用し、どこからやり直すかを選ぶ。公式サブエージェントは境界付きの専門担当として働き、状態と検査は口頭の進捗報告を追跡可能な証拠へ変える。

親モデルに期待される高度な仕事は、長い文脈を保持することだけではない。複数の判断を接続し、合格証拠と反証を同時に扱い、未完了を次の行動へ翻訳することである。その能力を成果へ変えるには、状態を外部化し、返却物を採否判断できる構造が要る。

この記事が答える「任せられる範囲」の定義

ここでの「任せられる」は、コードを書けるかではなく、仕事の分解、境界付き委任、成果物の受入、失敗後の再試行を一続きで担える範囲を指す。評価単位は、一度よい回答が返ったかではなく、入力や反証が変わったときに現在の完了状態を選び直せるかである。

その範囲は、独立して確かめられるかと壊さず戻せるかの二軸で決める。二つとも強ければ広い調査や限定変更を任せやすい。どちらかが弱ければ候補作成までに狭め、外部への確定や不可逆な影響を伴うなら人間境界へ置く。具体的な使い方は最終H2に集約する。

Agentic StructCiv大改造で実際に完遂した仕事

このケースで「完遂」と確認できるのは、Agentic StructCivの個別実装件数ではなく、企画入力、境界付き委任、成果物の受入、テスト、監査、限定修正、更新後の再確認、人間への最終受け渡しを一つの工程線として接続した範囲である。期間、変更ファイル数、行数、テスト総数、個別不具合の症状と正確な修正差分は資料で確定していないため、この冒頭で境界を固定し、以後は工程証拠と受理段階だけを答えにする。

なお、一件分の「入力版、緑のテストと異なる監査指摘、限定修正、更新版の再検証」を連続して示せる一次証拠は、今回の受理資料だけでは確定していない。そのため個別例は補わず、以下では確認できる工程上の対応関係までを扱う。

完遂の中心は、すべてが無欠陥になったことではない。公式委任、テスト、独立監査、限定修正、再検証を接続し、反証後も前進条件を選び直せたことである。受理済みの制御と、公開・外部反映まで確定した状態は分けて扱う。

対象セッションと親タスクの実行条件

対象は、一件の複数工程にまたがる開発セッションである。生のセッション識別子は、公開読者が主張を検算できる参照先にならないため本文には置かない。代わりに、各判断を「入力版」「返却物」「判定」「次の責任」へ結び付けた証拠ラベルで追う。

ここで直接確認できるケース固有の中身は、緑のテストを終点にせず、独立監査の反証を限定修正と再検証へ戻したことだ。具体性は数字の演出ではなく、合格を覆せる判定と、修正後にも残る検証責任に置く。

この工程線には、役割の違う証拠が並んでいる。委任記録は「誰に何を任せたか」、テストは「記述済み条件を満たしたか」、監査は「その条件だけでは見落とす問題がないか」、再検証は「修正後も同じ問いに耐えるか」を答える。どれか一つを万能な合格票にせず、問いと答えを対応させたことがケースの検算可能性を支える。

各結果の対象版、判定時点の入力、次に変更できる責任者を結ぶ必要はあるが、その版・状態・戻り先の管理は次節の責任として扱う。この節では、工程ごとに証拠の役割が異なり、監査の反証によって受理段階が更新されたというケースの答えに絞る。

使える状態・証拠・主張上限を対応させる

「何が完成したのか」を工程名だけで説明しないため、成果を次の証拠台帳へ落とす。

この台帳が答えるのは、各状態でどこまで主張できるかである。入力版と反証後の戻り先は次節、テストと監査が答える問いの差は監査節、主体別の帰属上限は帰属節に譲る。ここで「使える」と言えるのは、委任、検査、監査、限定修正、再検証、人間境界がそれぞれ別の証拠を持ち、独立監査が追加の合格票ではなく前進を止める判定として働いた範囲までだ。

したがって、記事の内容が常に正しい、すべてのテストが十分、公開後も問題がない、という主張へは広げない。成果の上限を先に固定すれば、このケースで完遂した制御と、次の検証がなお証明すべき事項を同じ「成功」に混ぜずに済む。

返却・検査・現行版受理・外部確定は別の完了段階

完了は一語で扱わない。少なくとも四段階に分ける。

1. 返却済み：担当が成果物を返した。形式と所有範囲が正しいかはまだ別問題である。
2. 検査済み：指定されたテストやschema、監査条件を通った。検査が問わなかった事項は残る。
3. 現行版へ受理済み：結果が現在の入力版に対するものだと親が確認し、正本または次工程へ採用した。
4. 外部確定済み：公開、送信、課金、破壊的変更など現実の副作用を人間が承認・実行した。

たとえば、返却物が正しくても一つ前の実装版を読んだ結果なら、現行版の受入証拠ではない。検査に通っても、検査と同じ前提を共有する盲点が残ることがある。現行版へ受理されても、公開まで自動的に許可されたわけではない。この段階差を残したことが、単なる大量生成と、任せられる制御の違いである。

直接記録値と条件付き集計値を混同しない

変更件数、委任回数、テスト数は、母集団、計測時点、再試行を含むかで値が変わる。このケースの完遂判定には、見栄えのよい概数ではなく、上の工程線、受入段階、反証後の扱いを使う。

今後数値を示すなら、直接記録値には出所と時点を、履歴から数えた値には母集団、数え方、再試行の扱いを添える。同じ条件で再計測できない数字を、完成度やモデル能力の代理には使わない。

条件付き集計では、何を一件と数えるかも先に決める。最初の試行と再試行を別件にするのか、生成された一時成果物を変更対象へ含めるのか、途中で破棄した候補を母集団へ残すのかで、同じ履歴から異なる値が出る。計測規則を後から都合よく選べば、大きさだけが独り歩きする。

直接記録値が使える場合でも、出所と時点が違う値を同じ規模指標へ束ねない。数量の空白を概数で埋めるより、どの証拠がどの主張を支え、何を支えないかを明示する方が、別案件との比較条件を設計しやすい。このケースでは、その証拠対応こそが「大改造」の読み方になる。

大きさを語る前に、測定規則を固定できるかを問う。この順序なら、同じ履歴を別の人が検算し、異なる条件の数字を同じ実績として混ぜずに済む。

長期タスクを支えた親タスクの統合力

長期タスクで親に残る固有の仕事は、すべてを自分で書くことではない。どの版を現在の基準にし、反証が来たときに何を古い証拠として扱い、どの責任地点から再開するかを選ぶことである。本節は版、状態、戻り先に限定する。

大改造を境界付きの作業単位へ分解する

対象記録の作業単位には、目的、読む入力、書ける範囲、期待成果物、禁止事項、停止条件、受入条件があった。読み取り専用の発見と、変更権限を持つ実装を分ければ、同じ正本を複数担当が競合して直す事態を避けられる。

分解の価値は担当数ではない。調査で範囲を広く見ても、変更は一つの所有範囲へ限定できること、範囲外の必要が判明したら親へ戻せることにある。発見する責任、変更する責任、採用する責任を分けたまま接続するから、失敗時の戻り先が曖昧にならない。

依存関係も分解の一部である。入力が同じで書き込み先が重ならない作業は並行候補にできるが、先行結果によって次の入力が変わる作業は順序を固定する。ここを無視して同時実行を増やすと、速く返った成果ほど古い前提へ結び付く危険がある。親は作業量ではなく、入力と所有権の依存から実行順を決める。

状態機械と成果物契約で未完了を見失わない

上流成果物が変われば、変更前のレビューは新しい版の合格証拠にならない。状態機械と成果物契約は、この版の違いを会話の記憶から切り離す。どの入力を読んだ結果か、何を返すべきか、誰が正本を採用できるか、どの条件でやり直すかが残れば、以前の「完了」が現在も有効かを検算できる。

親が選ぶ戻り先は、常に最初ではない。問いや入力が有効で、変更候補だけが不足しているなら、確定済みの発見を保ったまま変更責任へ戻せる。一方、入力版が変われば、その版に依存した判断を新しい版へ結び直す。戻す単位を小さくしつつ、古い証拠を新しい証拠として使わない。この二つを同時に満たすのが状態管理の仕事だ。

状態は、単純な未完了・完了の二値では足りない。返却されたが未検査、形式は通ったが内容監査は要修正、変更候補はできたが正本へ未採用、といった中間状態を分ける必要がある。中間状態が見えるから、合格済みの部分まで無駄にやり直さず、同時に未確認の部分を完了へ紛れ込ませずに済む。

子の結果を受理し、統合し、再試行へ戻す

サブエージェントが成果物を返したことと、親が採用できることは別である。親は報告と成果物、入力版、受入条件を照合し、受理、要修正、遮断、再試行を選ぶ。契約外の変更を別担当の正本へ混ぜず、証拠が足りなければ同じ責任境界へ戻す。

ここでは、発見自体は有効でも変更候補は未受理、形式検査は合格でも監査は要修正、といった異なる状態を同時に保持できなければならない。長期タスクの統合力とは、一度も失敗しない力ではなく、失敗を状態として保持し、適切な責任地点へ戻し、現在の証拠から前進を再開する力である。

統合は、返却物をすべて一つへ混ぜることでもない。互いに矛盾する判断が来たら、証拠の対象版、問い、権限を比べ、どちらが現在の前進条件を満たすかを決める。採用しない結果も、なぜ採用しなかったかと再試行条件を残せば、次の担当が同じ袋小路へ戻るのを防げる。

担当が返したことと、親が現行版へ受理できることは別。入力版と受入条件まで照合して、はじめて次へ進めます。

公式サブエージェント運用から見える強み

前節が親の版管理と再開判断を扱ったのに対し、ここでは同じ入力版に対して何を独立して並行させられるかを見る。複数の公式サブエージェントを使う価値は、人数そのものではない。独立した問いを必要な文脈だけで進め、統合可能な成果として返せることにある。

並列化が速度だけでなく文脈分離に効く

同じ入力版に対する読み取り専用の複数レビューや、正本を変更しない計画作業は、相互の書き込みを待たずに進められる。各担当へ渡す問いを、企画意図、証拠、構造、責任境界などに限定すれば、並列化は待ち時間の短縮だけでなく、判断文脈の隔離として働く。

反対に、同じ正本を書く複数の担当は競合する。未回収レビューを必要とする統合も並べられない。外部へ確定する操作は、候補生成と同時実行しない。同時実行の可否は「急ぎたいか」ではなく、同じ入力版に対して独立して完了し、互いの書き込みを必要としないかで決まる。

並行作業の途中で、一方の結論がもう一方の前提を変えると分かったら、その時点で依存作業へ切り替える。並列化を維持すること自体を目的にしない。独立性が崩れた結果をそのまま束ねるより、入力を更新して必要な担当だけをやり直す方が、現在版に対する証拠としては強い。

独立した受入条件が子の成果を統合可能にする

読み取り担当が発見事項を返し、変更担当だけが候補を作る形なら、親は「何を読んだか」「何を作ったか」「どの条件で判定したか」を別々に照合できる。発見を修正者の自己評価へ吸収しないため、再確認も独立した仕事として残る。

ただし、担当を二人にしただけでは独立性は生まれない。同じ入力欠落を見落とし、同じテスト結果だけを読み、同じ判定基準を言い換えるなら、文脈を二つに分けても盲点は一つのままだ。子の成果が統合可能かは、担当数ではなく、問い、入力、失敗の見つけ方、先の判定を覆せる権限が区別されているかで測る。

親が受け入れられる量も、実用上の並列幅を決める。返却物を検査せず積み上げれば、生成は速くても統合待ちが増える。並列化の成果は担当数ではなく、親が採否を決められる独立成果へ変換できたかで測るべきだ。

そのため、子の返却は長い作業実況より、対象入力、結論、成果物、検証結果、未確認点、停止理由へ絞る方が統合しやすい。親が必要なのは、子の思考を再演する材料ではなく、現在の状態を変えてよいか判断できる証拠である。専門性は説明量ではなく、問いに対応した成果物と反証可能性で示す。

対象時点の公開面では子ごとのモデルやUltra設定を確認できない

このケースの実行時に使われた公式 `spawn_agent` 公開面からは、子ごとの実効モデル、reasoning、Ultra設定を確認できない。したがって、並列運用の説明に「すべての子が同じUltraだった」という前提を置かない。ここで確認できる強みは、境界付きの仕事と返却物が存在し、親がそれを統合したことにある。この記述は対象時点の実行面に限り、将来の公開仕様まで断定しない。主体別の帰属上限は後の比較表で一度だけ整理する。

緑のテスト後に監査で不具合を直した意味

先の工程線で重要なのは、緑のテストが無価値だったことでも、監査が常に優れていたことでもない。誤り方の異なる確認を重ね、反証を修正条件へ変えたことである。本節はテストと監査が答える問いの差、そして修正後に同じ問いを当て直す条件へ絞る。

テスト合格が証明したことと残した盲点

自動テストが通れば、書かれた検査条件については同じ手順で合格を再現できる。人間の印象より強い証拠だが、検査条件に入っていない要件や、複数工程をつないだときの責務のずれまで自動的に証明するものではない。

だからといって緑を捨てる必要はない。何を再現可能に確認できたかを残し、別の問いから得た反証と並べる。テストは「既知の条件を満たすか」に強く、監査は「そもそも問う条件が足りているか」「利用者が判断できるか」「責任境界がずれていないか」を探せる。両者を同じ合格票の枚数として数えない。

テストが強いのは、同じ入力と手順から同じ判定を再現しやすい点だ。一方、テストケース自体が欠けていれば、その欠落を緑の結果から発見するのは難しい。監査は、仕様、入力集合、利用場面、責任分担を見直し、「そもそも何を検査対象に含めるべきか」を問い直す。強さの種類が違うため、片方を増やしてもう片方の代わりにはできない。

独立監査を別の確認方法として扱う

独立性は担当者の名前ではなく、次の四つの質問で判定する。

1. 先のテストと異なる失敗経路を探しているか。
2. 同じ仕様解釈や同じ入力欠落だけに依存していないか。
3. 先の合格を、証拠があれば覆せる判定権限があるか。
4. 修正後の同じ入力版へ、同じ問いをもう一度適用できるか。

二人のエージェントが同じテスト結果だけを読み、「緑だから問題なし」と返しても独立検証にはならない。テストが形式と既知条件を見ているなら、別の監査はケース固有の成果が説明できるか、証拠と主張上限が対応しているか、利用者が次の判断へ進めるか、といった別種の失敗を探す必要がある。

確認を次のように分けると、役割の重なりを見つけやすい。

この表のどこか一行だけで「完全」とは言わない。問いが異なるから重ねる価値があり、戻り先が異なるから親の統合判断が必要になる。対象記録では、テスト後の独立監査が問題を検出したことまでは確認できるが、資料にない個別不具合名や根本原因は補わない。

テストと監査は合格票を増やすためではなく、異なる失敗経路を見つけるために重ねるのが要点です。

監査の反証が有効なら、テスト合格と矛盾して見えても、どちらかを捨てる必要はない。テストは記述済み条件を満たした証拠として残し、監査は条件外の不足を示す証拠として追加する。親は両者が同時に成り立つ状態を受け入れ、修正対象と追加検証を分ける。

修正と再検証まで閉じて初めて完遂へ近づく

反証を受けたら、問題を見つけたという報告でも、直したという自己申告でも閉じない。影響範囲を限定して修正し、元のテストと指摘元の監査を、新しい成果物へもう一度当てる。古い合格記録は履歴として残すが、新しい版の受入証拠には使わない。

修正可能性を能力評価へ含めるとは、修正を書く速さではなく、反証した問いを修正後にも残すことだ。再テストで既知条件を守り、再監査で指摘が消えたと確認できて初めて、次の完了段階へ進める。

どこまでUltraの能力と言え、どこから言えないか

ここでは証拠区分や完了段階を再説明せず、ケースの結論を主体別に検算する。「仕組みが全部やった」と「Ultraが単独で全部やった」のどちらにも寄せず、各主体について直接観測、構成全体からの推論、証明できない範囲を一つの表へ集約する。

親タスクについて直接観測できたこと

直接確認できる中心は、GPT-5.6 Ultra設定の親タスクが、複数工程の改造における統合主体だったことだ。観測に近い表現は、「親モデルが全成果物を直接作った」ではなく、「Ultra設定の親が構成全体を運転し、反証後も収束を続けた」である。専門担当の成果や、決定的な検査結果まで親モデルが直接生成したという意味には広げない。

構成全体の成果として妥当に推論できること

複数の記録を合わせると、成果はモデルによる判断、境界付きの分業、状態の外部化、決定的な検査、別視点の監査が接続した構成全体から生まれたと考えるのが妥当だ。実用的には、親モデルへ検証可能な制御構造を与えると、任せられる範囲が広がるという相乗関係である。各要素の因果寄与率を測った結果ではない。

子モデル統一・寄与率・一般性能は証明できない

この主体別上限は、そのまま追加検証の担当表になる。親の統合力は反証後の戻り先、サブエージェントの効果は重複しない独立成果、状態機械と検査の効果は古い判定や自己申告が現在版へ混ざらないことによって確かめる。「Ultraだから全部任せる」のではなく、確認したい主体に対応する証拠を置き、任せる範囲をその結果に合わせて変える。

このケースを比較実験へ拡張するなら

将来、別モデルや別の運用構成と比較するなら、モデル名だけを入れ替えて感想を比べても足りない。少なくとも次を固定する。

• 目的、初期入力、許可された所有範囲、停止条件
• 同じ自動テストと、同じ独立監査の問い
• 再試行回数、途中で与えた追加情報、人間が介入した地点
• 反証後に新しい版へ収束できたか、未解決を残したか
• 元の基準点へ戻すために必要だった操作、時間、残った外部副作用

測る対象は初回出力の見栄えだけではない。受理できた成果、反証後の修正、再監査で消えた指摘、復旧に必要な手間を同じ条件で比較する。今回の一例はその比較結果を持っていないため、優位結論は出さない。ここで渡せるのは、証明不能を次の検証計画へ変える比較軸までである。

同じ成果を引き出すための実践条件

このケースを自分の開発へ移すとき、最初に決めるのは「任せるか、任せないか」の二択ではない。作業の独立検証と復旧可能性に応じて、広く調べさせる、変更範囲を限定する、人間が実行・承認するの三つへ分ける。同じ案件でも、調査、実装、外部反映を別の分岐へ置き、二軸の弱い方に合わせて権限を狭める。

ここで「広く」は、あらかじめ承認したrepoとデータ境界の内側で、読み取りや探索の範囲を広げられるという意味であり、変更権限や外部影響を無制限にする意味ではない。書き込みをしない作業でも、認証情報、個人情報、機密データへのアクセスは別に許可し、外部サービスへの送信も別の境界として扱う。承認済みrepo全体を読み取る調査は広く任せられても、本番設定一行の変更は狭い所有範囲と人間承認が必要になりうる。対象範囲、データアクセス、外部送信、変更権限を分けて設計する。

ただし、この二軸が決めるのは委任してよい権限の上限であり、委任した方が得かどうかではない。権限を分類した後で、返却物のレビュー、テスト環境の準備、ロールバックの用意と復旧リハーサル、人間による統合にかかる見込み負担を、自分で完了する場合と比べる。委任できる境界を安全に作れても、その準備と確認の方が重いなら、その仕事は人間側に残す。

境界ケースも表から決められる。検証はできても戻しにくい仕事は人間実行へ置き、戻せても独立検証しにくい仕事は読み取り調査や候補作成までに留める。両方が強くなって初めて、限定変更へ一段広げる。 これなら節末の移動規則は、二軸のどちらかを無視した権限拡大にならない。

委任前に目的・所有範囲・停止条件・受入条件を固定する

明日から使う最小単位として、「一つの変換処理を直す」を委任カードへ落とす。これは対象セッションで起きた個別事象ではなく、ケースから導いた適用例である。導入で触れた制御系の経験は、以下の復元基準点と復旧確認を委任条件から外さないという判断にだけ接続する。

埋められない欄がある仕事は、いきなり実装へ渡さず、読み取り調査か人間判断へ狭める。作業中に別モジュールや共有状態の変更が必要になったら、自動で所有範囲を広げず、新しい影響確認と復元基準点を親へ求める。

テストと独立監査を別レイヤーで設計する

テストには、既知の入出力、schema、回帰条件など、再現可能な問いを持たせる。独立監査には、テストが前提にした仕様そのもの、責任境界、利用者の判断材料、範囲外変更、復旧条件を問わせる。二つの担当を置くことより、異なる誤り方を検出する質問を置くことが先である。

委任前に、次の四問へ答えられるようにする。

• テストが緑でも残りうる失敗は何か。
• 監査はその失敗をどの証拠から見つけるか。
• 監査は先の合格を覆して停止できるか。
• 修正後、テストと監査を同じ新しい版へ再適用できるか。

答えが「別担当にも見せる」だけなら独立性は不足している。人の数ではなく、失敗経路、証拠、判定権限、修正後も残る問いを設計する。

統合判断と最終責任を親タスクと人間に残す

親タスクには、どの入力版を現在とみなすか、どの返却物を採用するか、反証後にどこからやり直すかを残す。サブエージェントの数を増やしても、この統合判断は消えない。むしろ返却物が増えるほど、受け入れられる形式、証拠、停止条件が重要になる。

人間には、外部送信、破壊的変更、認証や課金、最終公開のように、影響を簡単に戻せない操作を残す。AIは候補、差分、影響範囲、未確認点、実行前チェックを用意できるが、高品質な候補を作れたことは実行責任を移せる根拠にならない。

移動規則は一つでよい。独立した証拠と復旧可能性が増えたら一段広げ、入力・検証・影響範囲のどれかが不確かになったら一段戻す。 Agentic StructCiv大改造の事例が支えるのも、Ultraの万能性ではなく、証拠に応じて委任範囲と戻り先を更新できる親タスクの制御である。