Codex GPT-6 Astra 移行設計ガイド - 高難度タスクだけに安全に使う

Codex に新しい強いモデルが入ると、最初にやりがちな失敗は「全部の仕事を最新モデルへ寄せる」ことです。出力はよく見えますが、軽い仕事のコストが増え、重い仕事のレビュー観点が曖昧になり、既存の prompt や automation が強いモデルの判断に引っ張られます。

OpenAI Docs では、2026年8月31日から9月4日の更新として GPT-6 Astra が Codex と ChatGPT Work で使えるようになったこと、さらに code、apps、research をまたぐ複雑な仕事に向くことが説明されています。この記事では、Astra の性能紹介ではなく、Codex で GPT-6 Astra をどの仕事へ上げ、どの仕事へ上げないかを決める移行設計に絞ります。

通常の Sol / Terra / Luna の使い分けは Codex model selection 設計ガイド、sandbox や approval と一緒に profile 化する話は Codex config / profile 設定ガイド、token や subagent の上限は AIエージェント予算ガードレール設計ガイド、Astra が出した差分を受け入れる判断は Codex レビュー完了ゲート設計ガイドに分けています。

今回の論点は、Astra を default にするかではなく、Astra へ上げる前後で何を再審査するかです。

先に結論: Astra は高難度 lane にだけ置く

私なら、Codex の Astra 移行を次の表から始めます。

仕事	Astra に上げる条件	先に決めること
複数 repo の設計変更	影響範囲が1つの差分に収まらない	owner、対象 repo、触らない領域
認可・課金・データ境界の修正	見落としの被害が大きい	threat model、rollback、review owner
調査から成果物作成までの一連作業	code、browser、docs、spreadsheet をまたぐ	入力 source、template、検証方法
失敗した automation の原因分析	同じ失敗が繰り返される	再実行上限、外部 write 禁止、証跡
大きな移行計画	既存設定や prompt まで直す必要がある	migration checklist、比較 baseline

逆に、CI log の要約、GSC query の分類、短い Markdown 修正、既存パターンに沿った小さな実装は、まず Terra / Luna のままで十分です。Astra は「すべてを賢くする default」ではなく、失敗したときの被害が大きい仕事を、より広い文脈で判断させる lane として扱います。

移行前に既存 prompt を棚卸しする

Astra は instruction following が強く、skill や AGENTS.md のようなファイルに含まれる指示の影響も受けやすいと OpenAI Docs で説明されています。これは利点ですが、古い prompt が雑なままだと、強いモデルほど雑な指示を忠実に実行します。

移行前に見るべきものは、モデル名だけではありません。

astra_prompt_audit:
  instructions:
    - AGENTS.md
    - skill files
    - automation prompts
    - saved task templates
  check:
    - owner and done condition are explicit
    - destructive actions require approval
    - external write actions are separated
    - verification command is named
    - final answer format is reviewable

特に、昔の automation prompt には「よしなに直す」「必要なら公開する」「全部確認する」のような広い表現が残りがちです。Astra へ上げる前に、許す変更範囲、止める条件、検証、報告形式を短く書き直します。

reasoning effort は一括で上げない

OpenAI Docs では、GPT-6 Astra は none reasoning effort をサポートしないこと、既存の none / minimal から移す場合は low から比較することが説明されています。つまり、Astra へ移すだけで reasoning 設計も変わります。

移行時は次のように扱います。

既存の仕事	移行直後	上げる条件
定型分類	Astra にしない	失敗が継続し、人間の再分類が多い
日常実装	Terra 継続	設計判断が必要になった
深い設計調査	Astra low / medium	source が多く、矛盾がある
セキュリティ判断	Astra medium / high	threat model と修正案を同時に見る
複数 tool workflow	Astra medium	tool 待ち、途中修正、検証が混ざる

high や extra high は、入力が整っているときに効きます。入力が曖昧なまま effort だけ上げると、長く考えた曖昧な計画が返ってきます。まず task packet を小さくします。

async tool calling は「待ち時間の短縮」ではなく pending work の管理

GPT-6 Astra の更新では、async tool calling が強調されています。これは、アプリ側で tool を非同期に走らせている間も、モデルが別の推論や独立した応答を進められる仕組みです。ただし、実際に tool を実行し、pending work を管理するのはアプリ側です。

Codex 運用へ落とすなら、次のような分け方にします。

async_tool_policy:
  allow:
    - read-only search
    - build status polling
    - long-running analysis job
  require_review:
    - external write
    - deploy
    - billing or permission change
  log:
    - call_id
    - requested_action
    - started_at
    - returned_at
    - stale_result_policy

非同期 tool は便利ですが、結果が遅れて返るぶん、古い情報をもとに次の判断を進める危険があります。Astra に「続けてよい」と言う前に、tool result の鮮度、失敗時の扱い、重複実行の idempotency を決めます。

mid-turn steering は便利だが、監査ログに残す

Astra では、作業中に追加の指示を送り、完了済みの作業を保ったまま continuation へ反映する mid-turn steering が扱いやすくなっています。これは長い Codex task ではかなり有用です。途中で「その依存は触らない」「PR本文を短く」「先にbuildを見て」と軌道修正できます。

ただし、運用では次の3つを残します。

最初の goal
途中で追加された steering
最終差分がどちらの指示に従ったか

これがないと、レビュー担当は「なぜ最初の計画と違う差分になったのか」を会話履歴から探すことになります。Astra は途中変更に強いからこそ、変更された要求を decision log に近い粒度で残すべきです。

subagent delegation は明示的に設計する

OpenAI Docs では、GPT-6 Astra は subagent に作業を分けられる一方、期待より委譲が少ない場合は「いつ、どの程度、subagent を使うか」を prompt で指定することが推奨されています。ここは Codex の運用設計でそのまま効きます。

大きな migration や監査では、Astra に次のように渡します。

Use Astra for coordination.

Delegate only these independent checks:
- dependency impact check
- security boundary check
- migration docs check

Each subagent must return:
- finding
- evidence
- risk
- recommended action
- confidence

Do not let subagents edit files.

委譲は「速くするため」だけに使いません。main task の context を汚さず、調査結果を同じ形で戻すために使います。書き込み可能な subagent を増やす場合は、Astra ではなく git worktree、review owner、差分統合の手順を先に決めます。

configuration_update は cache と運用再現性を壊さないために使う

API 側では、会話途中で reasoning effort を変えるときに configuration_update input item を使い、request-level の reasoning は固定して prompt prefix の caching を保つ考え方が説明されています。Codex の日常利用でも、同じ発想が使えます。

悪い移行は、失敗するたびに task 全体を別 model / effort で最初から投げ直すことです。source 読み込み、状況説明、制約の再投入が増え、どこから結果が変わったのかも分かりにくくなります。

良い移行は、最初に baseline を残します。

run_baseline:
  model: gpt-5.6-terra
  effort: medium
  result: failed at migration impact analysis
  reason_to_escalate: cross-repo auth and billing boundary
  next_model: gpt-6-astra
  next_effort: medium
  preserved_context:
    - goal
    - source list
    - forbidden files
    - verification commands

モデルを上げるときは、結果だけでなく「なぜ上げたか」を残します。これを残さないと、次回からすべての類似作業が Astra に吸い寄せられます。

検証予算を先に決める

Astra は coding task で検証を丁寧に行いやすいと説明されています。これはよい性質ですが、小さな差分で広すぎるテストを回すと、時間と token を使いすぎます。

私なら、Astra lane には検証予算を必ず入れます。

verification_budget:
  required:
    - typecheck
    - focused test for changed behavior
    - build if public artifact changes
  optional:
    - broader regression tests
    - browser verification
  stop:
    - same failure appears twice
    - test requires production credentials
    - unrelated flaky test blocks completion

強いモデルほど「念のため」を増やせます。しかし、業務では「何を確認したら受け入れるか」を先に決めた方が、完了判断が安定します。Astra に任せるなら、検証を増やす権限ではなく、検証を選ぶ基準を渡します。

Codex での最小移行 runbook

実務では、次の順で十分です。

既存の Terra / Sol / Luna lane を残す
Astra 候補を高難度 task だけに絞る
AGENTS.md、skills、automation prompt を棚卸しする
none / minimal reasoning 前提の task を low から再確認する
async tool と mid-turn steering を使う task は pending work のログを残す
subagent を使う task は返却形式と編集可否を固定する
初回3件は人間が差分、検証、コスト、停止判断を見る

この runbook で見たいのは、「Astra の方が賢いか」ではありません。どの task なら Astra の強さが実務上のリスク低減につながり、どの task では過剰なのかです。

よくある失敗

1. Astra を default model にする

最新モデルを default にすると、短期的には満足度が上がります。ただ、軽い分類、短い修正、定型レポートまで重くなり、どの仕事で Astra が本当に必要だったか分からなくなります。default は既存 lane に残し、Astra は escalation として使います。

2. 古い automation prompt をそのまま使う

「毎朝確認して必要なら直す」のような広い prompt は、強いモデルほど広く解釈されます。Astra に上げる前に、read-only、draft-only、write allowed、external action forbidden の境界を書きます。

3. tool 待ちを会話の外へ出さない

async tool calling を使うなら、pending work の call_id、期限、重複実行時の扱いを保存します。これがないと、Astra が賢くても、外側の harness が古い結果を混ぜます。

4. subagent の統合責任を決めない

subagent が3つの良い報告を返しても、採用基準がなければ最終判断は荒れます。Astra を coordinator にするなら、採用する finding、捨てる finding、追加調査へ戻す finding の基準まで渡します。