GPT-6 Astra公式ガイド「Using GPT-6 Astra」全体解説──癖5つと対処法11本、公式が「強く推奨」したのはプロンプトを足すことではない

2026年9月6日昼・日本時間時点の情報です。OpenAIはGPT-6 Astraの公開に合わせて、開発者向けドキュメントに**「Using GPT-6 Astra」**（Model guidance）を置いた。APIのChangelogは9月3日の項で、このページを「機能、プロンプト、移行の指針」として案内している。ページは導入・What's new・Prompting best practices・Migration quickstartの4節で、この記事はその全体を、公式が挙げる癖5つと対処法11本の原文つきで整理する。

動画版も公開しています： https://youtu.be/MPiQY19RE6M

Astra本体の性能と価格は公開当日の記事（GPT-6 Astra公開──自社比較表では首位、独立指標では5位）、Proへの提供開始は続報（GPT-6 AstraがChatGPT Proに到着）に整理してある。

3行まとめ

1. 公式ガイドはAstraの癖を5つ挙げ、それぞれの対処法として貼る文を原文つきで11本出している。癖は「質問して止まる」「ファイルの指示に敏感」「書式と決まり文句が多い」「委任が少ない」「テストが多い」。
2. ページ全体で「強く推奨（strongly recommend）」と書かれているのは1か所で、内容はモデルが読めるskillやAGENTS.mdなどのファイルを監査すること。プロンプトを足す話ではない。
3. APIの新機能は4つ（非同期ツール呼び出し・途中の舵取り・会話途中の思考量変更・不整合の監視）、制限は2つ（思考量noneは不可・EUデータ所在ではFast不可）、移行のチェック項目は7つ。

ガイドの4節と、この記事が扱う範囲

What's newの4機能は、それぞれ別ページのガイド（Async tool calling／Mid-turn steering／Reasoning models／Misalignment monitoring）に飛ぶ。本記事はその4ページも読んで条件を補った。

公式は導入で何と言ったか

公式ドキュメントは、Astraを「コンピュータ操作、ブラウジング、ソフトウェア開発、科学、専門職の仕事で最高性能（state-of-the-art）」とし、複数の評価で「出力トークンが大幅に少ないため、トークン単価は上がっても1タスクあたりの推定APIコストは前のモデルより下がる」と書いている。

性格については「最も整合したモデル（most aligned model yet）」と表現し、こう続ける。

When instructions leave room for interpretation, it uses the context it has to fill in routine gaps and asks focused questions when the answer could change the outcome.

（指示に解釈の余地があるとき、持っている文脈で決まりきった穴を埋め、答えが結果を変えうる場合には絞った質問をする）

使う場所は1行で、Responses APIのリクエストでmodelをgpt-6-astraにする。GPT-5.6で使えた機能（コンピュータ操作、Structured Outputs、ストリーミング、Programmatic Tool Calling、マルチエージェント、プロンプトキャッシュ、思考の引き継ぎ、コンパクション、proモード）はそのまま使えると書かれている。

癖1 質問して止まる

公式の説明では、Astraは「より良い協力者になるよう設計」されており、追加の入力が結果を大きく変えうる場面でユーザーに質問する。その結果、ユーザーが妥当な仮定で進めてほしい場面でも止まることがある。長い作業で筋を保つ点はGPT-5.6 Solより上と書かれているが、前のモデルなら仮定して進めた所で聞き返しやすい。

対処法として、公式は3本の文を出している。

対処法1 自律的に進めさせる文（公式は「start with this prompt」としている）

You should infer the user's intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the user's intended task to completion.

When the user expresses intent to perform new work or fix an existing issue, persist until the user's intended goal is complete. Progress autonomously towards the user's goal (e.g. creating isolated worktrees / checkouts if needed, resolving merge conflicts, read-only actions, creating draft PRs etc.) unless they are clearly destructive or irreversible.

（ユーザーの意図と作業範囲を、指示とそれまでの会話の文脈から推定せよ。あなたの仕事は行動に寄せ、ユーザーが意図した作業を完了まで運ぶことだ。ユーザーが新しい作業や既存の問題の修正の意図を示したら、意図した目的が完了するまで粘れ。明らかに破壊的または不可逆なものを除き、ユーザーの目的に向かって自律的に進めよ。必要なら隔離したworktreeやcheckoutを作る、マージ衝突を解消する、読み取り専用の操作、下書きPRの作成など）

対処法2 「できますか」を実行指示として扱わせる文

When the user's prompt indicates a request for action, such as "can you...", "I want to...", "help me..." and similar expressions, treat these as instructions to do the work and take action. Do not stop at acknowledging capability (e.g. "Yes…"), proposing a plan, or offering to continue. Do not settle for a partial or "helpful enough" solution that does not fully satisfy the user's task to save time, effort or tokens. If a task requires sustained work, complete all the necessary work until the intended outcome is fulfilled.

（「できますか」「したい」「手伝って」のような、行動を求める言い方は、作業をして行動せよという指示として扱え。能力を認めるだけ（「はい…」）、計画を提示するだけ、続けることを申し出るだけで止まるな。時間・労力・トークンを節約するために、タスクを完全には満たさない部分的な、あるいは「十分役立つ」程度の解決で済ませるな。持続的な作業が必要なら、意図した結果が満たされるまで必要な作業を全て完了せよ）

対処法3 成果物を作ってから承認を求めさせる文（公式は「often leads to quicker task completion」としている）

Before asking the user clarifying questions, you should complete the work that is already authorized from context and necessary to make the proposed action concrete and reviewable. The user should be approving a concrete, reviewable result. For example, before deploying a change, writing to an external application, merging a PR or publishing a site, do all the required work first so that user approval is the final step. You don't need user permission for reversible tasks, read-only actions, reviews or fixes, or anything for which authorization is provided earlier in the session or strongly implied from the task instruction.

Do not introduce unsolicited warnings, disclaimers, approval flows, or safety/compliance checklists due to hypothetical risk.

（ユーザーに確認の質問をする前に、文脈からすでに許可されていて、提案する行動を具体的でレビュー可能にするために必要な作業を完了せよ。ユーザーは具体的でレビュー可能な結果を承認すべきだ。例えば、変更をデプロイする、外部アプリケーションに書き込む、PRをマージする、サイトを公開する前に、必要な作業を全て先に行い、ユーザーの承認が最後の1手になるようにせよ。元に戻せる作業、読み取り専用の操作、レビューや修正、セッションの前段で許可が出ているか作業指示から強く示唆されるものには、ユーザーの許可は要らない。仮定上のリスクを理由に、頼まれていない警告、免責、承認フロー、安全・コンプライアンスのチェックリストを持ち込むな）

公式は但し書きとして、Astraは既定で作業中に「止まらない質問（non-blocking questions）」も投げる、アプリに必要な自律度に合わせて上の文を調整せよ、と書いている。

癖2 ファイルの指示に敏感

公式はAstraを「長い指示に従う力が上がった」とし、同時に「文脈の中の情報に敏感になりうる」と書く。具体例は、skillファイルの曖昧な指示や矛盾した指示でモデルが立ち止まり、早い段階で作業を止めること。ページで唯一「強く推奨」と書かれているのがここで、原文はこうである。

It can be more sensitive to instructions contained in skills and other files, such as AGENTS.md. We strongly recommend auditing skills and other files accessible to your model for instructions that could influence its behavior.

（skillやAGENTS.mdのようなファイルに含まれる指示に、より敏感になりうる。モデルがアクセスできるskillやその他のファイルについて、挙動に影響しうる指示がないか監査することを強く推奨する）

貼る文は2本ある。

対処法1 ユーザー指示をskillより優先させる文

The user's instructions take precedence over guidelines provided in a skill. If explicit user instructions conflict with a skill's instructions, prioritize the user's instructions.

（ユーザーの指示は、skillが提供する指針より優先する。明示的なユーザー指示がskillの指示と衝突したら、ユーザーの指示を優先せよ）

対処法2 止まった原因のSKILL.mdを名指しで報告させる文

If a skill causes you to ask for permission or confirmation, pause, leave requested work unfinished, or diverge from the user's intent, name and link to the exact SKILL.md file you read, quote the relevant instruction, and briefly explain how it applies. Distinguish explicit skill requirements from your interpretation of guidelines.

（skillのせいで、許可や確認を求める、止まる、依頼された作業を未完のまま残す、ユーザーの意図から外れる、のいずれかが起きたら、読んだSKILL.mdファイルの名前とリンクを示し、該当する指示を引用し、それがどう当てはまるかを簡潔に説明せよ。skillの明示的な要求と、指針に対するあなたの解釈は区別せよ）

2本目について公式は、多くのskillやAGENTS.mdを読み込む環境で「黙って矛盾している指針を見つける」ために使え、と説明している。本記事が読んだPrompting best practices節に、どの行を消すべきかを示す手順表はなく、監査そのものは各自の作業として残る。

癖3 書式と決まり文句が多い

公式の説明では、Astraは読みやすくするためにリスト・表・Markdownを使いがちで、セッションをまたいで同じ言い回しを繰り返すことがある。貼る文は3本で、公式は「散文にする」「技術的な話向け」「決まり文句を減らす」の3用途に分けている。

対処法1 散文にする文

Default to using clear, concise paragraphs, each developing one main idea. Use lists only when the information is genuinely parallel, sequential, or easier to compare, and avoid nested lists unless the hierarchy cannot be expressed clearly in prose. Use plain, simple language: familiar words, concrete examples, and precise verbs. Prefer active voice and direct statements.

Make sure to state the main point clearly and early, then develop it with the explanation and detail the reader needs. Let each sentence build on what came before. Develop the points that matter and provide enough support to be useful.

（既定では、1段落に1つの主要な考えを展開する、明快で簡潔な段落を使え。リストは、情報が本当に並列・順序的・比較しやすい場合にだけ使い、階層を散文で明確に表せない場合を除いて入れ子のリストは避けよ。平易で簡単な言葉を使え。なじみのある単語、具体例、正確な動詞。能動態と直接的な文を好め。要点を明確に早く述べ、読者に必要な説明と詳細で展開せよ。各文を前の文の上に積み上げよ。重要な点を展開し、役立つだけの裏付けを示せ）

対処法2 技術的な話向けの文

Use plain language over jargon, and reference technical details only to the degree that it helps illustrate an idea or your work to the user. Communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the level of background knowledge assumed from the user's prompt and context.

（専門用語より平易な言葉を使い、技術的な詳細は、考えや作業をユーザーに示すのに役立つ程度にだけ参照せよ。複雑な概念を明快で一貫した形で伝え、ユーザーのプロンプトと文脈から想定される背景知識の水準に合わせて書き方を調整せよ）

対処法3 決まり文句（slop）を減らす文

Avoid using slop words or phrases like "Bottom Line:" in conclusions, "delve," "foster," "leverage," "it's worth noting," "importantly," "Question? Answer." or "This isn't about X. It's about Y.", "genuinely" or hyphenated compound descriptions and adjectives. Do not use concluding summary statements such as "In short:..", "The simplest mental model is:...".

State the intended action directly. Avoid adding what you won't do, what will remain unchanged, or how you'll separate or categorize results. Do not use contrastive framing such as "X, not Y" or "X—not Y" that introduces an unprompted alternative that the user didn't ask about. Avoid invented compound labels like "exact-head checks" and "editorial-row layouts", vague qualifiers, and canned transitions; use plain verbs and prepositions to state the actual relationship directly.

（結論の「Bottom Line:」、「delve」「foster」「leverage」「it's worth noting」「importantly」「Question? Answer.」「This isn't about X. It's about Y.」「genuinely」、ハイフンで連結した複合的な描写や形容のような決まり文句を避けよ。「In short:..」「The simplest mental model is:...」のような締めの要約文は使うな。意図した行動を直接述べよ。やらないこと、変わらないこと、結果をどう分けるか・分類するかを付け足すな。ユーザーが尋ねていない代替を持ち込む「X, not Y」「X—not Y」のような対比の枠組みを使うな。「exact-head checks」「editorial-row layouts」のような造語の複合ラベル、曖昧な修飾語、定型のつなぎを避け、平易な動詞と前置詞で実際の関係を直接述べよ）

3本目で公式が名指しした語は、結論の「Bottom Line:」、delve、foster、leverage、it's worth noting、importantly、「This isn't about X. It's about Y.」、genuinely、それに「In short:」「The simplest mental model is:」で始まる締めの文である。

癖4 委任が少ない

公式によれば、Astraは仕事を分けて並列で動くサブエージェントに委任できるよう訓練されているが、ワークフローによっては期待より委任が少ない。いつ・どれだけ委任するかを指定せよ、として2本の文がある。

対処法1 並列化できるなら委任させる文

If at any point you can parallelize work by delegating tasks to another agent (no matter if you are the root or subagent), you should do so using collaboration tools if it could save time or improve quality.

（いつでも、別のエージェントにタスクを委任して作業を並列化できるなら、自分がルートでもサブエージェントでも、時間の節約か品質の向上になる限り、協働ツールを使ってそうせよ）

対処法2 エージェント間のメッセージを読める形にする文

Messages that you send to other agents and your final answer may be read by a human, so ensure they are legible. Always put proper spaces between words and/or numbers.

（他のエージェントに送るメッセージと最終回答は人が読む可能性があるので、読める形にせよ。単語や数字の間には必ず適切な空白を入れよ）

公式は「委任の量は指示によく応える」とし、自分のハーネスとマルチエージェントの実装に合わせて調整するよう書いている。

癖5 テストが多い

コーディングでは、Astraは完了と判断する前のテストが徹底的で、小さな作業では必要以上に広くテストすることがある、と公式は書く。貼る文は1本である。

対処法 テストの範囲を校正する文

Do not write tests for reversible, low-impact changes that mirror the implementation. If you do choose to verify your work with tests, make sure that the tests are meaningful and necessary to verify implementation.

Run tests appropriate to the change and complete required checks. Once those pass, broaden or repeat testing only when new changes, failures, or unresolved concerns justify it; otherwise, continue toward completing the task.

（実装をなぞるだけの、元に戻せる低影響の変更にはテストを書くな。テストで検証すると決めたなら、実装の検証に意味があり必要なテストにせよ。変更に見合ったテストを走らせ、必要なチェックを完了せよ。それが通ったら、新しい変更、失敗、未解決の懸念が正当化する場合にだけテストを広げるか繰り返せ。そうでなければタスクの完了に向かえ）

癖5つと対処法11本の一覧

APIで新しくなった4つと、制限2つ

制限は2つ。思考量noneは使えず（Reasoning modelsページではHTTP 400が返ると明記）、EUデータ所在ではFastモードが使えない。

移行チェックリスト7項目

Codexを使っている場合、公式はopenai-docs skillに次の1行を頼めば、ガイドの推奨変更を当てられると書いている。

$openai-docs migrate this project to GPT-6 Astra

手動の場合はmodelをgpt-6-astraにした上で、次の7項目である。

モデルページの数字も添えておく。文脈は1,050,000トークン、最大出力は128,000トークン、知識は2026年4月30日まで。価格は入力$10・出力$50（100万トークンあたり）で、公開当日の記事に整理したとおりClaude Fable 5.1と同額である。

何から手をつけるか（筆者の順番）

ここからは公式の記述ではなく、筆者の判断である。

1. ファイルの監査。AGENTS.mdとskillを読み直し、矛盾した行や曖昧な行を洗い、「ユーザーの指示が優先」の1文を足す。公式が唯一強く推奨した所から始める
2. 癖1の3本。特に「成果物を作ってから承認を求める」文。公式が「完了が早くなることが多い」と書いた文である
3. 文体は用途で1本。散文がよければ1本目、技術文書なら2本目、決まり文句が気になるなら3本目
4. 委任とテストは環境次第。サブエージェントを使う環境か、コードを書かせるかで要否が決まる
5. APIの7項目は手順どおり

筆者の手元で起きたこと

この記事を書いている筆者は、9月4日にCodex用のAGENTS.mdを全面的に書き直したばかりで、翌5日にChatGPT Proへ切り替えてCodexのモデル欄に「GPT-6 Astra」が出た。公式ガイドの「監査を強く推奨」は、書き直したばかりのそのファイルをもう一度読み直せ、という宿題としてそのまま自分に返ってきた。

もう1つ。動画の概要欄に11本の原文をそのまま貼ろうとしたところ、11本だけで4,935文字あり、YouTubeの概要欄の上限5,000文字に収まらなかった。概要欄は公式ページへのリンクにし、原文は本記事に全文を載せた。貼るときは、この記事の英文をそのまま使い、自分の環境に合わせて削ってほしい。

このページに書かれていないこと

• ChatGPTの画面で使うときの話。本記事が確認したこのページは、APIとCodexのようにAstraを組み込む側に向けた内容で、チャット画面での振る舞いには触れていない。「聞いて止まる」「書式が多い」が画面でも起きるかは、本記事では確かめていない
• 監査の手順。「skillやAGENTS.mdを監査せよ」と「ユーザー指示の優先を明示せよ」までで、どの行を消すかの基準表は本記事が読んだ範囲には無い。名指しさせる文（癖2の対処法2）が、公式が示した唯一の道具である
• 11本の効果の数字。ページには各文の効果を示す数値は載っていない。「完了が早くなることが多い」「委任の量は指示によく応える」のような定性的な記述までである
• Codex CLIのバージョン要件。ヘルプセンターに記載があるとの検索結果はあったが、当該ページは本記事の取得環境から開けず（HTTP 403）、本記事には書いていない

出典と時点

• 本文の引用は「Using GPT-6 Astra」のMarkdown原文（developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md）から一字一句転記した。取得は2026年9月6日で、サーバーの最終更新は9月5日16:33（UTC）だった
• 新機能の条件は、Async tool calling／Mid-turn steering／Reasoning models／Misalignment monitoring／Prompt cachingの各ページ（いずれも9月6日取得）による
• モデルページの数字（文脈・出力上限・知識期限・価格・キャッシュ書き込みの倍率）は9月6日時点の記載
• 公開日の9月3日はAPI Changelogの日付による
• 筆者環境の記述はChatGPT Pro・macOSのCodexで、画面事実である。他の環境での表示を保証するものではない
• 公式ページが更新された場合、本記事は該当箇所を追記します