OpenAIが提案した「指示の棚卸し」
Eric Provencher氏による公式ブログは、モデルの進歩に合わせて、過去の補助的な指示を再評価するよう促しています。論点は次のように整理できます。
- スキルの説明は短く、適用する場面を明確にする。説明が長すぎたり適用範囲が広すぎたりすると、必要なスキルを選びにくくなる。
- 詳細資料は必要なときに読む構成にする。細かい手順で過度に行動を縛ることも見直す。
- AGENTS.mdにある一律の資料読込や検証要求を点検し、自律的に進められる範囲と作業の完了条件を明確にする。
同記事は、Astraが最初の実装段階でレビューを求め、作業を早めに止める場合にも言及しています。一方、これらはOpenAIによる運用上の助言です。指示を削った際の改善率を示す比較実験は掲載されていません。
スキル、AGENTS.md、依頼文の役割を分ける
まず、三つの置き場所を区別しておくと、自分の環境を点検しやすくなります。
| 置き場所 | 担わせる役割 | 編集部による例 |
|---|---|---|
| スキル | 特定の仕事で繰り返し使う進め方 | 導入事例記事の制作、請求書データの整理 |
| AGENTS.md | プロジェクト内で継続して守る前提 | 使用言語、データの扱い、検証環境 |
| 今回の依頼文 | その仕事固有の目的と終点 | 対象画面、直したい症状、納品形式 |
スキルは、指示を記したSKILL.mdと、必要に応じて資料やスクリプトをまとめる仕組みです。公式のスキル作成ガイドでは、最初に名前と説明を読み、選択したスキルの本文を後から読む構造が説明されています。
同ガイドによると、Codexの初期スキル一覧には上限があり、数が増えると説明文が短縮される場合があります。短縮されるのは最初の一覧であり、選ばれたスキルの本文まで一律に短縮されるという意味ではありません。
一方、AGENTS.mdの公式ガイドは、個人共通の指示とプロジェクト内の指示を重ねる仕組みを説明しています。作業場所に近い階層の指示が、上位の指示を上書きする構成です。ルートにあるファイルだけを直しても、別の階層に古いルールが残る可能性があります。
たとえば「毎回、公開前に確認を求める」という常設ルールと、「今回は公開まで進める」という依頼の関係が曖昧なら、どこまで任せたのかが伝わりません。資料の量に加えて、指示同士がどう関係するかを揃える必要があります。
スキルの説明には「何の依頼で使うか」を書く
ここからは編集部による応用例です。企業の導入事例を制作するスキルを考えてみます。
適用範囲が曖昧な説明は、次のようなものです。
企業の情報発信を高品質に支援する。記事、広報、営業、顧客対応に関するあらゆる依頼で使う。
この説明では、短いメールの修正にも、導入事例の制作手順が持ち込まれかねません。次のように、成果物と依頼の場面を指定できます。
導入事例記事を制作する。取材素材から事例原稿を作る依頼、または事例原稿を全面編集する依頼で使う。
ここで大切なのは「短くする」という形式だけではありません。営業メールと事例記事は、必要な資料も、完成の判断も違います。その違いを説明文に反映します。
本文には、素材の確認、構成、執筆、校正といった判断の要点を置きます。業種別の用語集や顧客別の表記表が長くなるなら、別資料に分け、どの場合に読むのかを添えます。たとえば「製造業の事例では設備用語集を参照する」と書けば、別分野の記事で同じ資料を読む必要はありません。
資料を分けた後はリンク切れにも注意が必要です。入口だけを簡潔にしても、参照先へ到達できなければ仕事に使えません。
削ってよい指示と、残すべき制約を区別する
指示の棚卸しで避けたいのは、文字数を目標にして、必要な条件まで消してしまうことです。編集部では、各指示に対して「何を防ぐためにあるのか」を確認する方法を提案します。
| 指示の性質 | 点検すること | 見直し方の例 |
|---|---|---|
| プロジェクト固有の制約 | 今も対象の環境・契約に当てはまるか | 有効なら残し、理由を添える |
| 過去のモデルへの補助 | 現行モデルでも同じ失敗が起きるか | 小さい仕事で外して比較する |
| 特定の作業だけの手順 | どの依頼で必要になるか | 該当スキルや参照資料へ移す |
| 一度限りの要望 | 次の仕事にも適用すべきか | 常設せず、個別の依頼に置く |
たとえば「顧客データを検証用の外部サービスへ送らない」は、モデルの能力だけでは決まらないデータ管理上の条件です。「既存のデータ取得経路を使う」も、料金や負荷を抑える設計に由来するなら残す意味があります。
逆に、ある障害の調査で使った資料一式を、その後の誤字修正でも毎回読む必要があるかは再検討できます。事故の記録自体を消す必要はありません。履歴として保存し、同種の問題を扱うときに参照する形にできます。
AIへの文章上の指示と、実際に使える権限も別です。「本番へ反映しない」と書くことと、本番へ書き込めない環境を用意することは同じではありません。指示を整理しても、環境側の権限設定まで緩める理由にはなりません。
「完成」を成果物と確認方法で伝える
依頼文を改善する際には、対象、できあがり、確認方法、止まる条件を一組にすると使いやすくなります。以下は実在する案件ではなく、編集部が作成した例です。
たとえば「お問い合わせフォームを直して」だけでは、見た目を直すのか、送信機能まで確認するのかが曖昧です。
お問い合わせフォームで、必須項目が空のまま送信できる問題を修正してください。空欄では該当箇所にエラーが表示され、入力すると送信できる状態を完成とします。検証にはダミーデータとテスト用の送信先を使い、この変更で生じた不具合は修正してください。PCとスマートフォンで表示を確認し、確認結果を報告してください。本番への反映は今回の対象に含めません。
この依頼なら、完成の条件を画面上の動作で確認できます。ただし、テスト用の送信先が存在しないなら、存在するものとして作業を進めることはできません。不足する前提がある場合の扱いも、実際の環境に合わせて決めます。
記事制作なら、完了条件は別になります。「本文の納品」「CMSへの下書き保存」「公開ページの表示確認」では、仕事の終点が違います。執筆だけを依頼したつもりで公開されることも、公開まで頼んだつもりなのに下書きで止まることも、避けたいすれ違いです。
何を確認したら終わりなのかを先に揃えると、単に「最後まで頑張って」と促すより、結果を評価しやすくなります。
見直しの効果は、小さい仕事で確かめる
最初からすべてのスキルや常設ルールを書き換えると、結果が変わった理由を追いにくくなります。編集部の提案は、よく行う仕事を一つ選び、変更前後を比べる方法です。
- 現在の指示を保存し、対象の仕事と合格条件を決める。
- 適用範囲の広すぎる説明、重複したルール、古い参照先を確認する。
- 一度に見直す箇所を絞り、同じ条件の仕事で結果を比べる。
- 誤ったスキルの選択、不要な確認待ち、完成条件の未達、成果物の誤りを記録する。
速く終わっただけで改善と判定するのは早計です。必要な確認を省いていないかも見ます。また、一回の成功でいつも同じ結果になるとはいえません。少なくとも代表的な依頼と、例外を含む依頼の両方を試す余地があります。
モデルの性能や費用を選び直したい場合は、関連記事のGPT-6 AstraとClaude Fable 5.1の比較も参照してください。本稿が扱うのは、そのモデルを仕事に使う際の指示設計です。
よくある質問
AGENTS.mdは短いほどよいのですか？
文字数だけで判断する必要はありません。プロジェクト固有の前提を失わず、適用場面と参照先が明確になっているかを確認します。
スキルを減らせば必ず精度が上がりますか？
必ず上がるとはいえません。必要なスキルを削れば仕事に必要な情報も失われます。数だけでなく、説明の範囲、重複、実際の選択結果を点検します。
他のモデルと同じ指示を共有してもよいですか？
共有する場合は、利用するモデルそれぞれで確認するのが実務的です。あるモデルでうまく動いた指示を、別のモデルでも同じように動くとみなすことはできません。
まとめ
- 指示の見直しでは、文字数よりも「どの仕事で使うか」と「何のために残すか」を明確にする。
- スキル、常設ルール、個別の依頼を分けると、同じ指示を重ねたり、関係のない手順を持ち込んだりする問題を点検しやすい。
- 自律的に任せるには、成果物だけでなく確認方法と作業の終点を揃え、小さな仕事で変更の効果を確かめる。
出典・参考
- OpenAI：Rethinking skills and prompts for GPT-6 Astra（Eric Provencher、2026年9月11日）
- OpenAI：Build skills
- OpenAI：Custom instructions with AGENTS.md
公式資料は2026年9月20日に確認。本文中の業務例、指示文、点検表はTechCreate編集部による作成です。
