GPT-6 Astraのプロンプト整理｜残す指示と変更を戻す判断基準

どの指示を残し、どれを整理する？

GPT-6 Astraの指示は、同じ文章でも適用先が違えば必要性が変わるため、本記事では目的・適用条件・失う要件を照合して処置を選びます。

OpenAIは、長い指示への追従と、曖昧・競合する指示を見直す必要性を説明しています。「長文だから悪い」と置き換えず、同じ目的に複数の指示がぶつかっていないかを確認する読み方が適切です（2026年9月20日確認）。OpenAIのモデル向け指示ガイド

Skillsとは、再利用する手順や資料をまとめる仕組みです。AGENTS.mdとは、Codexへプロジェクトなどの作業指示を伝えるファイルです。今回の依頼文とは、その作業でほしい成果物や条件を伝える文章を指します。Skillsの公式説明／AGENTS.mdの公式説明

OpenAI Developersは、このガイドを紹介する投稿でも、スキルの適用条件・必要な指示の読み込み・完成状態の明確化を挙げています。このあとで期待できるメリットと注意点を確認し、判断表で記事制作の指示へ置き換えます。

メリットを得るために、どの指示をどう直す？

以下は公式情報を踏まえた筆者の判断基準です。修正例は説明用で、どの用途にもそのまま使える完成プロンプトではありません。「適用条件」は、その指示を使う作業・対象・時点を意味します。

表は横にスクロールできます。

判断の根拠：指示の見直しに関する公式ガイドと、目的・出力・境界を伝える公式説明。

注意目的が説明できない指示は、いったん保留します。長いという理由で消すと、普段は目立たない例外条件まで失うおそれがあります。今回確認した公式資料には、全用途に共通する最適な文字数や削減率は示されていません。

Skills・AGENTS.md・依頼文のどこを直す？

OpenAIは、Skillsの名称・説明と選択後に読む本文を分け、Codexでは開始時にAGENTS.mdから指示を組み立てる仕組みを説明しています。直す箇所は「いつ選ぶか」「何を共通で守るか」「今回どこまで完成させるか」で分けます（2026年9月20日確認）。Skillsの選択と読み込み／Codexの指示読み込み

公式文書では、単独Skillsはデスクトップアプリ・CLI・IDE拡張、プラグイン同梱SkillsはWeb・デスクトップ・モバイルのChat／Workにも対応すると説明されています。利用経路や画面を一括りにしないでください（2026年9月20日確認）。Skillsの対応環境

使う入口自体を整理したい場合は、ChatGPTの機能を目的から選び直す案内も参照できます。

まず、自分が編集できる置き場所を選ぶ

今回の作業だけを変えるなら、まず依頼欄の文章から試せます。SkillsやAGENTS.mdを使っていない人は、下の記事制作の依頼文の例へ進んでください。以下は指示を整理するための筆者の使い分けです。

表は横にスクロールできます。AGENTS.mdはCodex向け、SKILL.mdはスキルを扱える環境向けの例です。通常のチャットへファイル名だけを書いても、手元のファイルが自動で読み込まれるとは限りません。参照してほしい資料は添付するか、利用中の環境で参照できる場所を指定します。

Skillsは選択条件と手順本文を分けて直す

Skillsが対象外で選ばれる、または必要な仕事で選ばれない場合は、まずdescriptionの適用条件を確認します。descriptionは用途や選ぶ条件を伝える説明文です。一方、選ばれた後に必要資料へたどれない場合は、SKILL.mdの参照先・読む条件から確認する、というのが筆者の切り分け方です。

Skillsでは名称・説明が先に示され、選ばれたスキルのSKILL.md本文を読む段階へ進みます。SKILL.mdとは、そのスキルの手順を記すファイルです。この段階的な読み込みと、必要時に参照する資料の配置を区別します（2026年9月20日確認）。Skillsの段階的な読み込みの公式説明

Skillsで選択条件を確認し、手順本文と必要な参照を読む流れの概念図。

例：表記修正だけでも出典確認のスキルが選ばれるとき。説明文が「文章を書くときに必ず使う」なら、対象が広すぎないかを確認します。次の例は、記事の事実確認を担当するスキルを想定しています。

description: >-
  記事中の事実・数値・出典を追加・変更するとき、または
  既存の主張の検証を依頼されたときに使う。
  事実や意味を変えない表記修正だけには使わない。例をコピー

入れる場所：対象のSKILL.md冒頭にある、ハイフン3つで囲まれた設定部分のdescriptionを置き換えます。nameや手順本文は残し、同じdescriptionを二つ作らないようにします。これはスキル全体ではなく、説明欄だけの例です。

使った後の確認：「句読点だけを整える」という依頼と、「提供対象を公式情報で確認して追記する」という依頼で、適切に選ばれるかを分けて確かめます。descriptionの修正だけで、毎回の選択が保証されるわけではありません。選ばれない場合は、読み込み・有効化の状態も確認します。

手順本文に参考資料をすべて貼っている場合は、作業ごとの参照条件と資料の場所を残す形へ整理できます。

## 必要な資料を読む条件
- 事実・数値・出典を追加、変更、検証するときは、
  references/source-rules.md を読む。
- HTMLの構造や表示を変更するときは、
  references/html-rules.md を読む。
- 対象作業に複数の条件が当てはまる場合は、
  該当する資料をすべて参照する。例をコピー

入れる場所：この例はSKILL.mdの手順本文へ入れます。二つのファイル名は説明用です。実際に存在する資料名へ置き換え、SKILL.mdからたどれる位置に置いてください。すべての作業に必要な規約は、本文に残すか、必ず参照する条件を残します。

SKILL.mdの構成と選択の仕組みは公式のSkills作成ガイドで確認できます。上の文章・ファイル名・確認課題は筆者による説明例です。

別資料へ分ける場合も、本文から必要な資料へたどれることを確認します。作成や追加の操作まで必要なら、Skillsの作成・追加・呼び出しを確認する記事へ進めます。

AGENTS.mdは共通ルールと必要な参照を絞る

AGENTS.mdでは、共通で守るルールと、特定の変更時に読む資料を分けます。OpenAIのガイドは、編集のたびに一律ですべての資料を読む指定を見直す考え方を示しています。必要な資料まで省くという意味ではありません。AGENTS.mdの見直しに関する公式ガイド

説明用の例：「毎回デザイン資料をすべて読む」という指定なら、UIを変える作業と、文章だけを直す作業で必要性を分けます。ただし、すべての変更に適用する規約であれば参照条件を狭めません。配置や適用関係も直したい場合は、AGENTS.mdの配置場所と優先関係を確認する記事で補えます。

修正前の例：「誤字修正でも毎回すべての資料を読み、同じ確認を3回行い、各工程で返事を待つ」。この指定を、資料が必要な条件と依頼済みの作業範囲が分かる形へ置き換えます。

## 記事を編集するときの共通ルール
- 原稿で指定された出典・形式・必須条件を維持する。
- 事実・数値・出典を変更するときは、出典ルール.md を読む。
- HTMLや表示を変更するときは、デザインルール.md を読む。
- 変更に必要な確認を行い、今回の変更が原因の問題を修正する。
- 依頼された下書きの編集・確認・修正は、完成まで進める。
- 公開・外部送信は、別途依頼されるまで実行しない。例をコピー

入れる場所：Codexで作業している対象プロジェクトのAGENTS.mdへ、該当する編集ルールとして反映します。既存ファイル全体をこの例で上書きせず、矛盾する旧ルールを整理してください。資料名は、自分のプロジェクトで参照できる実際のファイル名に置き換えます。

使った後の確認：新しい実行・セッションで、適用された指示と参照先を確かめます。「表記だけの修正」では何を読み、「表示の変更」では何を追加で読むかを確認し、必要な規約まで抜けていたら条件を戻します。AGENTS.mdの読み込みと確認方法

今回の依頼文には成果物と止める地点を書く

今回の依頼文には、納品物・必要な確認・追加判断が必要になる地点を書きます。OpenAIは、目的や出力、境界を示すことに加え、完了まで任せたい工程を依頼に含める考え方を案内しています。目的と境界を伝える公式説明／完了条件に関する公式ガイド

記事制作への応用なら「本文とHTMLを作り、表示上の問題を直した完成版まで。公開は確認後」と分ける方法があります。これは筆者の説明例であり、指示すれば全工程が完了する保証ではありません。

確認の追加も、未解決の問題が何かを基準にします。公式のコーディング向け助言を記事制作へ応用する場合、出典確認や必要な表示確認を残し、同じ確認を目的なく繰り返す指示を見直す、というのが筆者の考え方です。必要な確認とテストの公式方針

記事制作の依頼文を、どう書き換えて使う？

初めて試すなら、ここにある「修正後の例」を依頼欄に入れる方法から始められます。SkillsやAGENTS.mdの編集は不要です。以下は筆者が作った記事編集の例で、実際に効果を測定したプロンプトではありません。

修正前の例

添付のHTML記事を、初心者が使い方を判断できる内容に直してください。
出典リンク・指定の形式・既存のデザインと機能は維持してください。
毎回すべての参考資料を読み、すべての項目を必ず3回確認してください。
各工程が終わるたびに私の返事を待ち、完成版まで仕上げてください。
公開はしないでください。

この例では、資料を読む条件が一律で、確認を繰り返す目的も不明です。また、各工程で待つ指定があるため、「完成版まで」という依頼でも途中で返答を待つことになります。出典・形式・デザインと機能・公開の境界を残し、参照する条件と完成までの範囲を具体化します。

添付のHTML記事を、初心者が使い方を判断できる完成版へ修正してください。

【維持する条件】
出典リンク・指定の形式・既存のデザインと機能を維持してください。

【参照する資料】
記事本文と今回の修正依頼を基準にしてください。
事実や数値を追加・変更する部分は、関連する公式情報を確認してください。
表示やHTMLを変える場合は、添付のデザインルールも参照してください。

【完成条件】
必要な説明と具体例を加え、出典との対応と変更箇所のHTML・表示を確認してください。
見つかった問題を修正し、貼り替えられる記事全文を提出してください。
確認できない項目は、未確認であることと理由を添えてください。

【進めてよい範囲】
依頼した下書きの編集・確認・修正は、通常の工程ごとに返事を待たず進めてください。
結論や作業範囲を左右する不明点がある場合は、その点を確認してください。
WordPressへの公開・外部送信は行わないでください。例をコピー

この例は、短い文章にすることより、残す条件と実行する範囲が伝わることを優先しています。専門記事なら読者像や必須の確認項目など、自分の制作で必要な条件を追加してください。

1. 編集する記事全文を添付する。HTML記事ならCSSとJavaScriptも含め、どの部分を直したいかを伝えます。デザインルールを使う場合は、それも添付します。
2. 例をコピーし、自分の依頼へ合わせる。「初心者」を実際の読者へ置き換え、必要な具体例や納品形式を指定します。デザイン資料がない場合は、その参照指定を「添付記事の配色・幅・文字サイズを基準にする」などに置き換えます。
3. 完成版と残した条件を照合する。出典・形式・表示・機能が保たれたか、未確認項目が明記されているかを確認します。残す条件が欠けた場合は、追加指示で修正するか、元の指示へ戻します。

注意既存の「各工程で必ず待つ」指示も確認してください。今回の進め方を変えるなら、その旧ルールがどこにあるかを確認し、今回適用する範囲を明確にします。組織や環境が定める権限・承認の制約は、依頼文を書き換えるだけでは変更できません。

指示を直す前後の効果を比較したい場合は、下の手順で変更対象以外の条件をそろえます。この例のように複数箇所を一度に変えた場合、結果の違いを一つの修正だけの効果とは判断できません。

変更した指示を採用する基準は？

GPT-6 Astraの指示変更は、筆者の判断基準では変更前後の条件をそろえ、必要な要件が残ったかと、比較そのものが成立するかを分けて採否を決めます。出力と境界を明示する公式説明

変更前の文面と今回の条件を保存する

最初に元の指示と、今回そろえて確認する条件を保存します。モデルや資料も同時に変えると、結果の違いを指示の変更だけに結び付けにくくなるためです。

1. 変更前の文面と、その置き場所を残す。
2. 使うモデル・入力資料・成果物の完成条件を記録する。
3. 判断表から一つの変更を選び、残す要件を確認する。

一つの変更を同じ条件で照合する

変更前後で、変更対象以外の条件をそろえます。使用モデル・入力資料・適用中の指示・完成条件を記録し、成果物だけを見て短縮の影響と決めないでください。意図した一箇所以外も変わった場合は、比較を保留します。

説明用の例：記事の構成が整っていても、残すはずの出典が欠けたなら、その変更は採用しません。下の図はこの仮の場面を描いたもので、Astraで観測した不具合ではありません。

必須条件が欠けた変更を採用せず、保存した指示へ戻して見直す説明例。

欠けた要件を直すか、保存した版へ戻す

変更後に必須条件が欠けた整理案は採用しません。変更前には満たしていたなら、変更箇所を修正するか保存版へ戻します。変更前にも同じ欠落があるなら、元に戻すだけで解決したとは扱わず、元の指示・資料・実行条件の不足を点検します。

変更後に必要条件を満たし、変更対象以外の条件もそろえて確認できた場合は、その用途での採用候補です。一度の結果だけで効果を一般化しません。変更前の結果がない、条件をそろえられない、必要な確認を実行できない場合は、比較と採用判断を保留します。

整理後も困るとき、何を確認する？（FAQ）

GPT-6 Astraの作業停止は、指示の量だけで原因を特定できないため、本記事では指示の反映状況・競合・実行権限を分けて確認する方針です。指示を削り続ける前に、次の疑問を切り分けてください。

まとめ｜次に見直す指示はどう選ぶ？

まずは元の文面を保存し、判断表から見直す箇所を一つ選びます。書き方が分からない場合は、依頼欄に貼る修正例を自分の作業へ合わせてください。Skillsを使う人はdescription、Codexの共通ルールを直す人はAGENTS.mdというように、適用先を分けます。

同じ条件の重複が見つからなければ、無理に削る必要はありません。指示を短くすることを目標にせず、目的を説明できる状態に整えてから採否を決めます。

使用モデル、Skills・AGENTS.md・依頼テンプレート、または成果物の完成条件を変えたときは、指示の必要性と適用先をこの判断表で再確認してください。