AIに「途中で止まるな」と指示しても止まる。公式も認めていた――GPT-6 Astraの不要な承認待ちとテストやりすぎ問題
1. それ、本当にOpenAI公式なの？から始まった
SNSで、GPT-6 Astraを自走させるためのOpenAI公式ガイドが紹介されていた。
内容は妙に具体的だった。文脈からユーザーの意図と作業範囲を推論して最後まで進める。読み取り、レビュー、可逆的な修正、すでに許可された作業では毎回承認を取り直さない。本当に承認が必要なら、レビュー可能な完成状態まで作って最後の一手だけ確認する。
さらに、SKILL.mdやAGENTS.mdのような指示ファイルに敏感で、矛盾があると止まりやすいこと、小さなコード変更でも必要以上に広いテストをしがちなことまで書かれているという。
いや、普段イラついている症状だけをそんな都合よく公式文書が列挙する？
OpenAI公式を直接見た。
あった。
しかもかなりそのままだった。
2. 公式が「不要な承認待ち」と名前まで付けていた
OpenAIのGPT-6 Astra向けモデルガイダンスには、Astraは以前のモデルより、追加情報で結果が大きく変わりそうなときに質問しやすい、と明記されている。
協力的と言えば協力的だ。
ただ、長い作業ではこうなる。
ユーザー「この問題、全部調べて直して」
AI「調査しました。修正してよいですか？」
ユーザー「止めるなって書いたやろ」
AI「承知しました。修正案を提示します。適用しますか？」
永久機関である。
しかも公式の移行クイックスタートには、「不要な承認待ち」（Unnecessary approval pauses）という項目まである。
こっちが勝手に神経質になっていたわけではない。メーカーが症状名を付けている。
病院に行ったら医者から「はい、それ確認しすぎですね」と一発で診断された感じで話が早い。
3. なぜ「止めるな」だけでは止まらなかったのか
ここが一番大事だった。
「途中で止まるな」は方向だけを示す。モデル側にはまだ「追加情報で結果が変わるなら質問した方が親切」という既定動作が残る。
そこで公式は、もっと行動単位で書けと勧めている。
指示と利用可能な既存文脈から意図と範囲を推論する。実行依頼なら「できます」「計画はこちら」で終わらない。時間やトークンを節約するために“まあ役立つ部分解”で止めない。読み取り、レビュー、可逆的修正、すでに許可された作業では再承認を求めない。
つまり、
「止めるな」は精神論。公式ガイドは停止禁止区間を描いた路線図。
そりゃ後者の方が効く。
4. 承認は「入場券」ではなく「最後の赤ボタン」にする
公式ガイドで実務的に一番強いのが、承認を最後に寄せる考え方だった。
たとえばサイトを直して公開する仕事で、公開だけ本当に確認が必要だとする。
なら、調査、修正、ビルド、必要なテスト、差分確認まで先にやる。最後に「ここまで完成。残りは公開だけ」という状態で聞けばいい。
逆に、
「調査していいですか？」
「直していいですか？」
「テストしていいですか？」
「もう一回テストしていいですか？」
と毎工程で止まると、仕事がスタンプラリーになる。
ユーザーは行政手続きを遊びたいわけではない。
5. そして公式は「テストやりすぎ」まで認めていた
さらに刺さったのが「テストと検証」（Testing and verification）の説明だ。
OpenAIは、Astraはコード変更を完了扱いにする前にかなり丁寧にテストする傾向があり、小さい変更では必要以上に広いテストになることがある、と説明している。
見覚えがありすぎる。
1行直す。
関係するテストをする。
通る。
「念のため」で別テストを追加する。
通る。
さらに実装を鏡写ししたような低価値テストを増やす。
通る。
そして本来の仕事がまだ終わっていない。
テストが品質保証ではなく趣味になっている。
公式の推奨も明快だ。低影響で可逆的な変更に、実装をそのままなぞるだけのテストを書かない。変更に合った必要なテストと必須チェックを行う。それが通ったら、新しい変更、失敗、未解決の懸念がない限り、テストを広げたり繰り返したりせず完成へ進む。
テストはゴールではない。出荷前検査である。
検品に合格したのに、検品表を増やすために製品を倉庫へ戻すな。
6. 「じゃあ最初からそう実装しろよ」はかなり自然な感想
公式がここまで分かっているなら、「最初から自走をデフォルトにしてくれ」という感想になる。
ただしOpenAI側にも理由はある。Astraは、タスク境界を尊重し、結果を変える重要な不明点では質問する方向にも強化されている。一般ユーザーに対して、曖昧な「サイト直しといて」から勝手に公開まで走るモデルはそれはそれで事故る。
問題は、ユーザーが「最後までやれ」「可逆作業は進めろ」と十分に許可しているケースでも、保守側へ倒れすぎることだ。
だから公式が後から「もっと自律実行させたいなら、このようにプロンプトしてください」とガイドしている。
安全側の初期値は理解できる。
でもパワーユーザーからすると、
「その自律実行設定、奥の説明書じゃなくてスイッチで寄こせ」
になる。
7. Codexは“全部入り”の自走ルールをそのまま維持する
Codexのように、リポジトリを読み、修正し、テストし、プルリクエストや公開準備まで長時間走る環境では、2行だけでは足りない。
そこでCodex側は、全セッションで使う自走プロンプトをそのまま維持することにした。
中身は、最新のOpenAI公式ガイドを毎回確認すること、現在の$CODEX_HOMEやconfig.toml、AGENTS.md、スキル定義を実読すること、グローバルなdeveloper_instructions等を正本候補にすること、既存設定を壊さず冪等に統合することから始まる。
さらに、意図と範囲の推論、計画だけで止まらない、既許可の可逆作業は進める、承認は最後、質問前に自力で解けるものを調べる、ユーザー指示とskillの競合を明示する、停止原因になったSKILL.mdを特定する、仮想的なリスクだけで承認フローを増やさない、破壊的・不可逆操作の正当な境界は残す、サブエージェントを必要に応じて並列化する、テストを必要十分にする、適用先を再取得して確認する、簡易動作確認をする、重複追加しない、というところまで持つ。
要するにCodex版は、
「走れ」ではなく「どこまで走っていいか、どこだけ赤信号か、止まったら原因ファイルまで出せ」を全部定義する。
ここは削らない。
8. ChatGPT側は逆に2ルールだけでよかった
一方、普段のChatGPTまで全部入りにする必要はなかった。
Markdownが多い？
別に困っていない。
表やリスト？
使いやすいなら使えばいい。
サブエージェントの細かな使い分け？
必要な場面でやればいい。
日常的に本当に困るのは二つだけだった。
依頼範囲が明確なのに途中確認で止まること。
必要十分な検証を超えてテストを増殖させること。
だからChatGPT上の恒常ルールは、この2点だけに絞った。
依頼の意図と範囲が十分明確なら、「続けますか？」「適用しますか？」で細切れに止まらず、上位の安全・権限境界に触れない範囲を完遂する。
テストは変更に必要十分な範囲で行い、必要なチェックが通ったら、新しい変更、失敗、未解決の懸念がない限り無意味に反復・増設しない。
困っていないところまで矯正すると、今度はルール自体がノイズになる。
9. これは「Astra節約法」より「停止ロス削減法」に近い
SNSでは、これらがAstraの利用量を節約する方法として紹介されていた。
方向としては分かるが、公式の位置づけは、Astraの挙動を用途に合わせて調整するプロンプト作成のベストプラクティスだ。「このプロンプトで使用量が何割減る」と保証しているわけではない。
むしろ自走させれば、一回のタスクで長く働く場合もある。
ただし、
確認 → 人間の返事待ち → 再開 → また確認
という停止ロスは減る。
つまり節約というより、
同じ計算資源を“許可待ち”ではなく“完成”に使う。
こっちの方が正確だ。
10. 結論：自走して、必要なだけ検査して、終わらせろ
最先端AIの運用ルールを掘った結果、最終的な要求はものすごく普通になった。
仕事の途中で毎回こっちを見るな。
検品が終わったなら出荷しろ。
Codexには道路交通法まで全部渡す。ChatGPTにはこの2枚の張り紙だけ貼る。
そして一番おもしろいのは、これがユーザーの勝手な“AI調教術”ではなく、かなりの部分までOpenAI公式ガイド自身が説明していることだ。
AIの未来を調べていたはずなのに、最後は工場長の朝礼になった。
公式情報
- OpenAI, “Model guidance — Using GPT-6 Astra / Prompting best practices”: https://developers.openai.com/api/docs/guides/latest-model
- OpenAI, “Unrolling the Codex agent loop”: https://openai.com/index/unrolling-the-codex-agent-loop/
