2023年ごろ、プロンプトエンジニアリングが錬金術のように感じられた時期がありました。正しい呪文 — 魔法のフレーズ、指示の完璧な並び順 — を見つけると、それまでどろどろの出力しか返さなかったモデルが、突然金塊を生み出す。COSTAR のようなフレームワークは、まさにこの世界で生まれました。Sheila Teo の COSTAR（Context、Objective、Style、Tone、Audience、Response）はシンガポール初の GPT-4 プロンプトエンジニアリング大会で優勝しましたが、それには理由があります。試行錯誤にしか見えなかったプロセスに、秩序をもたらしたのです。
3年経った今も、フレームワークは健在です。COSTAR は今でも最も広く教えられている構造のひとつです。ただし、それが機能する理由は静かに変わりました。まだパフォーマンスハックとして使っているなら、あなたはほぼ存在しなくなった問題を解いていることになります。
フレームワークが実際にやっていたこと
構造化プロンプトの当初の売り文句は「能力の解放」でした。初期のモデルは、何もかも明示してやる必要がありました。読者を宣言しなければ、汎用的な出力が返る。フォーマットを指定しなければ、散文の壁が返る。COSTAR の6つのスロットは、2023年型モデルが放っておくと外してくる6つの要素に、きれいに対応していたのです。
だから構造が「荷重を支えている」ように感じられました。「Audience」欄を落とすと、出力が目に見えて悪くなる。そこで人々はルールを内面化しました。構造が多いほど、出力は良くなる。当時の証拠を考えれば、妥当な結論です。
何が変わったか
2026年のフロンティアモデルは、その足場の大半を自分で推論します。有能なモデルに「ベンダーへの丁寧なお断りメールを書いて」と頼めば、こちらが何も指定しなくても、良識的なスタイル、適切なトーン、きれいなフォーマットをすでに選んでくれます。かつて手で埋めていたスロットは、いまやモデル自身の判断で埋まるのです。
これは COSTAR が間違いになったという話ではありません。有能なモデルの単純なタスクに対しては、一部が冗長になったという話です。モデルがどのみち「プロフェッショナル」を選ぶのなら、「Tone: professional」と宣言することの限界価値はほぼゼロまで下がっています。単純な依頼に対する厳格な6部構成の足場は、いまやほとんど儀式 — 出力を動かさない労力です。
面白いひねりがあります。これはモデル依存なのです。COSTAR-A に関する最近の論文によると、元のフレームワークは大規模モデルの明瞭さを今でも改善する一方、小規模でローカル最適化されたモデルでは一貫性が落ちる — 特に、制約された指示的な出力を必要とするタスクで顕著だそうです。8Bクラスのファインチューニング済みモデルを自前のハードウェアで動かしているなら、昔のルールはまだおおむね有効で、むしろ COSTAR 以上に指示的な構造が必要かもしれません。「フレームワークは時代遅れ」論は、実のところ「フロンティアモデルが賢くなった」論であり、小規模モデルの世界にはきれいに転移しないのです。
今も食い扶持を稼いでいる部分
生き残ったのはここです。そして、これこそが残す価値のある部分です。フレームワークとは、忘却に対するチェックリストである。
2026年に構造化プロンプトが雑なプロンプトに勝つ理由は、たいてい構造そのものではありません。スロットをひとつずつ辿ることで、いまでも本当に品質を動かす要素を供給せざるを得なくなるからです。そしてそれは3つの場所に集中しています。
- Context（コンテキスト） — 単独で最もレバレッジの高い入力。悪い出力の大半は、構造の欠落ではなくコンテキストの欠落に行き着きます。モデルは、伝えられていないことを推論できません。
- Objective（目的） — 曖昧な身振りではなく、具体的で明確なタスク。
- Response format（出力形式） — アウトプットの形。パース可能で予測可能な構造を強制することが、プロンプトをパイプラインで安全に走らせられるようにします。
Style、Tone、Audience も依然として重要ですが、選択的にです。顧客向けやブランドボイスの仕事 — 文章が大規模に特定の響きを持つ必要がある場面 — では居場所があります。コードレビューや技術分析では、ほぼノイズです。あなたの認証ハンドラをレビューしているモデルに、トーンの指示は要りません。
つまり正しいメンタルモデルは「毎回6つの箱をすべて埋める」ではありません。「箱を記憶の補助として使い、そのあと容赦なく刈り込む」です。あなたのタスクにとって荷重を支えている部分だけ残し、あとは落とす。
実際に使えるテンプレート
必須フォームではなく、実用チェックリストとしての COSTAR がこちらです。どれだけ「省略可」の印が付いているかに注目してください。
/* ============================================================
* TL;DR: COSTAR as a checklist, not an incantation.
* On capable 2026 models, Context + Objective + Response do
* most of the work. Style/Tone/Audience matter for prose at
* scale, less for code. Keep what's load-bearing, cut the rest.
* ============================================================ */
# CONTEXT — highest leverage; never skip
You are reviewing a Hono route handler in a TypeScript monorepo
on Cloudflare Workers + Supabase.
# OBJECTIVE — be specific and concrete
Find auth-bypass risks in this handler and list each one.
# STYLE — often inferable for technical work; drop if obvious
Terse, senior-engineer register.
# TONE — usually noise for code; matters for user-facing copy
(omit)
# AUDIENCE — shapes assumed knowledge and depth
A backend dev who already knows JWT and RLS.
# RESPONSE — high leverage; forces predictable, parseable output
Markdown list: finding -> severity -> one-line fix. No preamble.構造がいまでも圧勝する場所
チェックリストの規律が「任意」でなくなる場所がひとつあります。一度書いて何度も走らせるプロンプトです。システムプロンプト、自動化フロー、RAG パイプライン — 呼び出しごとに反復改善できない場所すべて。対話型チャットなら、雑な依頼を投げて、読み違えられたら直せばいい。パイプラインではそうはいきません。何千もの入力に対して一発で正しくなければならないとき、フレームワークが強制する網羅性は、儀式であることをやめて保険になります。
正直なまとめ
COSTAR とその親戚たちは、悪くなったのではありません。降格したのです — 呪文から規律へ。モデルが本来到達できない能力を解放することは、もうありません。いまでもやってくれるのは、完全なプロンプトを書かせることです。そして完全なプロンプトは、どの頭字語を経由したかにかかわらず、より良い出力を生みます。
フレームワークは、モデルに効く魔法のフレーズではなく、自分の思考のための足場として扱いましょう。目の前のタスクで重みを持つスロットだけ埋め、持たないものは切り、浮いた労力を、どんなフレームワークも代わりに供給できない唯一の入力に注ぐこと。つまり、モデルが知りようのないコンテキストです。