GPT-6 Astra公式ガイドの続き──OpenAI開発者ブログ「Rethinking skills and prompts」全文解説、skillとAGENTS.mdは足すより減らせ

2026年9月12日夕・日本時間時点の情報です。OpenAIは9月11日、開発者ブログ（OpenAI Developers）に**「Rethinking skills and prompts for GPT-6 Astra」**を公開した。9月3日の公式ガイド「Using GPT-6 Astra」が、Astraの癖5つと対処法11本を挙げたうえで「skillやAGENTS.mdなどモデルが読むファイルを監査せよ」と強く推奨していたのに対し、今回のブログはその監査の中身にあたる。skillの説明文、AGENTS.md、境界の言葉、完了の定義の4か所について、前のモデル向けに積み上げた指示をどう減らすかが、良い例と悪い例つきで書かれている。

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

前回のガイド全体（癖5つ・貼る文11本の原文・移行7項目）は前の記事（GPT-6 Astra公式ガイド「Using GPT-6 Astra」全体解説）に整理してある。本記事はその続きとして読める。

3行まとめ

1. ブログが見直しを求めるのはskill（説明文と中身）・AGENTS.md・境界の言葉・完了の定義の4か所。共通の理由は「前のモデル向けに足した指示を、Astraは真面目に読みすぎる」で、方向は足すより減らす。
2. skillの名前と説明文は使う前から全部コンテキストに載る。Codex公式ドキュメントによると、この一覧に使えるのは**コンテキストの2%（不明なら8,000字）**までで、超えるとCodexが説明文を短くし、さらに多いと一覧から外して警告する。
3. Astraは「最初の実装まで作ってレビューに戻ってくる」ことがあり、対処は始める前に完了を定義すること。「実装できたら止まれ」という指示は早止まりを呼ぶ、とブログは書く。

ブログの4節と、直し方の要点

締めは「この記事を元にAstra自身に監査させろ」で、手作業で全部見直す必要はない、と書かれている。

前回のガイドで足りなかったもの

前回の公式ガイド「Using GPT-6 Astra」は、Astraが「ファイルの指示に敏感」で、skillの曖昧な指示や矛盾で早期に止まることがある、と書き、対処としてskillやAGENTS.mdの監査を強く推奨していた。ただし、本記事が読んだ範囲では、どの行を消せばよいかの基準は載っていなかった（前の記事の「このページに書かれていないこと」で触れたとおり）。

今回のブログはその空白を埋める形で、冒頭で対象をこう定義する。

If you've been using agents like Codex for your projects over the last year, you've likely accumulated a lot of instructions as you worked to steer the models toward good outcomes. With each release, it's been worth revisiting those assumptions, but with GPT-6 Astra, it's more important than ever.

（この1年、Codexのようなエージェントをプロジェクトで使ってきたなら、モデルを良い結果に向けて操るために多くの指示を積み上げてきたはずだ。リリースのたびにその前提を見直す価値はあったが、GPT-6 Astraではこれまで以上に重要になる）

指示の形は3つ、skill・AGENTS.md・タスクのプロンプトである。

skillは足すほど選べなくなる

ブログによると、skillは「Markdownファイルとして保存されたプロンプト」で、資料やスクリプトを一緒に束ねられる。使いどころは特定の作業の流れか、特定のアプリを使うときの案内、と限定的に書かれている。

問題は数と説明文にある。

People now default to packaging a lot of skills into their projects, and each skill comes with a name and description that are loaded into the model's context so it knows when to use them. But many descriptions are far too long, and when you add too many skills, Codex starts shortening their descriptions to fit. The model ends up seeing less of each description, making it harder to know which skill to pick.

（今は皆、プロジェクトに多くのskillを詰めるのが既定になっている。skillごとの名前と説明文は、モデルがいつ使うかを知るためにコンテキストに読み込まれる。しかし多くの説明文は長すぎ、skillを足しすぎるとCodexは収めるために説明文を短くし始める。モデルが見える説明文は減り、どれを選ぶべきか分かりにくくなる）

この「短くする」の枠は、Codex公式ドキュメント「Build skills」に数字がある。

In Codex, the initial list also includes each skill's file path. To avoid crowding out the rest of the prompt, this list uses at most 2% of the model's context window, or 8,000 characters when the context window is unknown. If many skills are installed, Codex shortens skill descriptions first. For large skill sets, Codex may omit some skills from the initial list and show a warning.

（Codexでは、最初の一覧に各skillのファイルパスも含まれる。プロンプトの他の部分を押し出さないよう、この一覧はモデルのコンテキストウィンドウの最大2%、ウィンドウの大きさが不明な場合は8,000文字までを使う。多くのskillが入っていると、Codexはまず説明文を短くする。skillが非常に多い場合は、一部を最初の一覧から省いて警告を出すことがある）

同じページは、短くされても合致するように「主な用途と引き金になる言葉を説明文の先頭に置く」ことを求めている。なお、この2%はドキュメントの記述どおりに引用するにとどめ、本記事ではAstraのコンテキスト長（105万トークン）に掛け算した数字は出さない。ドキュメントは2%をコンテキストウィンドウに対して、8,000を文字数で書いており、単位を揃えて計算できる記述ではないためである。

ブログはさらに、説明文どうしの矛盾や、使いどころの盛りすぎが、関係ないskillを読み込ませて役に立たない指示を混ぜる、と続ける。直し方の1つ目は説明文を短くすること。公式の図「Be clear about when it applies」に載る例を、そのまま引く。

前半は同じで、後半の「いつ使うか」だけが狭くなっている。ブログの注釈によると、悪い例は「マイグレーションを扱うときだけでいいのに、データベースに関わるものに触れるたびに使おうとさせる」。

丁寧に書いたskillほど邪魔になる

直し方の2つ目は段階的に見せること（progressive disclosure）で、理由はこう書かれている。

Reading a skill takes up context, bringing you closer to compaction and introducing guidance that may not apply to the task. For skills with multiple workflows, make the root document a minimal router that points to supporting docs and scripts.

（skillを読むこと自体がコンテキストを消費し、圧縮に近づき、そのタスクに当てはまらない案内を持ち込む。複数の作業の流れを持つskillでは、根っこの文書を、補助の文書とスクリプトを指す最小限の案内役にせよ）

3つ目は、手順を一字一句書いたskillの扱いである。

Third, many skills were written as elaborate itineraries or recipes. Models have gotten much better at understanding nuance and ambiguity, so overly specific guidance can now hinder results where it previously helped.

（多くのskillは、手の込んだ旅程表やレシピのように書かれてきた。モデルは含みや曖昧さをずっと理解できるようになったので、細かすぎる案内は、以前は助けになった所でも今は結果を妨げうる）

もう1つ、見落としやすい注意がある。リポジトリに置いたskillは他の貢献者のエージェントも読み、その人は別のモデルを使っているかもしれない。ブログは「SolやLunaに合う案内がGPT-6 Astraには縛りすぎになることがある」と書き、残す指示をどのモデルが使うかまで考えるよう求めている。

skillを作るときに使う$skill-creatorskillについても、「こうした失敗の多くを和らげるために、最近その案内を更新した」とある。更新の時期はブログに書かれていない。

AGENTS.mdの棚卸し

AGENTS.mdは、モデルがそのリポジトリで働くたびに適用される。だからこそ1行ずつ、まだ要るかを見直せ、というのがブログの立場で、悪い例が具体的である。

Requiring a stack of docs or a full repo map before every edit is excessive for a typo fix. GPT-6 Astra can work out what it needs to read without being pushed to review the whole project before every change.

（編集のたびに資料の山やリポジトリ全体の地図を要求するのは、タイポ修正には過剰だ。GPT-6 Astraは、変更のたびにプロジェクト全体を見直すよう押されなくても、何を読む必要があるかを自分で判断できる）

公式の図「Read what the task needs」の例はこうなっている。

注釈は、毎回読ませる指示は「コンテキストを燃やして作業を遅くする」が、場面に紐づけて資料を指すのは役に立つ、とし、資料そのものも更新しておくよう添えている。

テストの指示も対象になる。前のモデルはテストを走らせて確認するよう促す必要があったが、Astraは自分でやるので、同じ指示が不要なテストにつながる、と書かれている。前回のガイドが挙げた癖の5つ目「小さな変更でも広くテストする」の一因が、自分で書いた1行かもしれない、ということになる。

逆に足す側の例が1つある。Astraは丁寧な代わりに、どこまでやるかで慎重になることがあるので、安全と分かっている作業には先に許可を書いておく。ブログの例文はこうである。

The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.

（ローカルのテストは使い捨てのフィクスチャを使い、本番へのアクセスは無い。それらを走らせ、依頼した変更が原因の失敗を直し、影響を受けるテストを再実行せよ。各ステップで承認を求める必要はない）

禁止の言葉が真に受けられる

前のモデルが許可なしに何かをした経験があると、「まず聞け」と強い言葉で書いた人は多い。ブログはそれ自体は役に立ちうるとしたうえで、Astraについてこう書く。

That can be useful, but GPT-6 Astra, as our most aligned model, has much better judgment and will not perform tasks unless it knows it is safe – so you should treat it as such.

（それは役に立ちうるが、GPT-6 Astraは当社で最も整合したモデルとして、はるかに良い判断力を持ち、安全だと分かっていない作業は実行しない。だから、そういうものとして扱ってほしい）

「最も整合したモデル」「はるかに良い判断力」はOpenAI自身の評価であり、本記事はそれを検証していない。ブログの実務上の含意は次の1文にある。

If you stated boundaries previously because you wanted to prevent other models from going too far and you're now switching to GPT-6 Astra, consider updating that language: Astra could take it too seriously and may stop work where you'd actually be happy for it to continue.

（他のモデルの行きすぎを防ぐために境界を書いていて、いまGPT-6 Astraに切り替えるなら、その言葉を更新することを検討してほしい。Astraはそれを真に受けすぎて、本当は続けてほしい所で作業を止めることがある）

前回のガイドの癖1つ目「質問して止まる」を、自分の書いた禁止文が呼んでいる可能性がある、という読み方になる。

最初の実装でレビューに戻ってくる

粘り（Persistence）の節は、GPT-5.6 Solとの違いから始まる。

If you're used to GPT-5.6 Sol taking a request and continuing for long stretches, GPT-6 Astra can feel more tentative about when to stop. It may reach a first implementation and come back for your review while there's still work to do.

（GPT-5.6 Solが依頼を受けて長く走り続けるのに慣れているなら、GPT-6 Astraはいつ止まるかについて、より慎重に感じられることがある。最初の実装に到達し、まだ作業が残っているのにレビューのために戻ってくることがある）

対処は「始める前に完了を定義する」こと。実装を動かし、結果を見て、失敗を直すところまでが仕事なら、それを依頼の中に入れる。そして逆向きの指示への注意がある。

A requirement to stop for review after the first implementation will pull the model toward an earlier stopping point, so check whether that's a decision you actually need to make.

（最初の実装の後にレビューのため止まれという要求は、モデルをより早い停止点へ引き寄せる。だから、それが本当に自分が下す必要のある判断かを確かめてほしい）

探索を続けさせたいときも同じで、何を探索し、どこで止まるかを言う。前回のガイドにあった「成果物を作ってから承認を求めろ」の文は貼る文で、今回のブログは依頼の書き方の話である。両方を合わせて使う形になる。

締めは「Astra自身に監査させろ」

A new model is a good opportunity to clean your house, but you don't need to review everything manually: ask GPT-6 Astra to do an audit based on what was discussed in this article, then go build something you wouldn't have attempted before!

（新しいモデルは家を掃除するよい機会だが、すべてを手作業で見直す必要はない。この記事で論じた内容に基づいてGPT-6 Astraに監査を頼み、それから、これまで挑戦しなかったものを作りに行こう）

5日前に「公式ではない」と除外した題名だった

この記事を書いている筆者は、9月6日に前回のガイド解説を作ったとき、公式ベストプラクティスの所在を調べたメモに、Xで見かけた「Rethinking skills and prompts for GPT-6 Astra」という題名のポストを記録していた。当時は本文を取得しておらず、開発者ブログにも載っていなかったので「公式ではない」として扱わず、前回の記事と動画の出典11本には含めなかった。

その5日後、同じ題名がOpenAI Developersの公式ブログ記事（トピックはCodex、日付はSep 11, 2026）として公開された。前回の記事で「監査の基準表は載っていない」と書いた宿題に対する答えが、この形で出てきたことになる。9月6日時点の判断自体は、公式に載っていないものを公式扱いしないという規律どおりで、本記事もその線は変えていない。

この記事で確かめられなかった2点

• skill-creatorの更新の実体。ブログは「最近その案内を更新した」と書くが時期は無い。本記事が確認した範囲では、GitHubのopenai/skillsリポジトリにあるskills/.system/skill-creator/SKILL.mdの最終コミットは2026年2月9日で、ブログの「最近」とは合わない。別の配布経路（Codexに同梱される版など）で更新されている可能性があるが、本記事では特定できていない
• ChatGPTの会話画面への適用範囲。ブログはCodexのようなコーディングエージェントで使う人に向けて書かれている。skillはChatGPTにもあるが、AGENTS.mdはリポジトリで働くときの仕組みで、会話画面だけで使う人にそのまま当てはまる話ではない。前回の記事と同じ限定である

出典と時点

• ブログ本文の引用は、公開URLに.mdを付けて取得できるMarkdown原文から一字一句転記した。取得は2026年9月12日で、ページの表示日付は「Sep 11, 2026」、トピック分類は「Codex」
• 2つの図（skill説明文とAGENTS.mdの良い例・悪い例）は、ページ上ではinstruction-comparisonという比較図として描かれており、本記事は表に転記した。図の題名「Be clear about when it applies」「Read what the task needs」はページのキャプションによる
• skill一覧の上限（2%・8,000字）と、説明文の先頭に用途と引き金を置く指針は、Codex公式ドキュメント「Build skills」（learn.chatgpt.com、9月12日取得）による
• 前回のガイドの内容（癖5つ・強い推奨・手順表の不在）は「Using GPT-6 Astra」（9月6日取得版）と前の記事による
• 動画の台本と本記事は同じ出典2本から作っており、筆者の環境での試行結果は含めていない
• ブログや公式ドキュメントが更新された場合、本記事は該当箇所を追記します