プロンプトのあり方が変わった。指示の多くはそのまま使える。

モデルは賢くなりました。私たちのプロンプトスタックは古くなりました。指示の博物館を、小さな地図、明確な境界線、そしてゴールラインに置き換える時です。

数日前、ちょっと居心地の悪いことに気づきました。

私のプロンプト、指示ファイル、ルール、スキルのほぼすべてが時代遅れでした。

完全に役に立たなくなったわけではありません。ただ、別の世代のモデル向けに書かれていたのです。

古いモデルをうまく動かすためのプロンプトスタックは、GPT-5.6、Claude Fable 5、Claude Opus 5、Grok 4.5、そして Cursor のようなコーディングツールを、より堅苦しく、より高価にし、時には単純にパフォーマンスを悪化させることがあります。

これは私の最新のプロンプト宗教ではありません。Anthropic は、以前のモデル向けに書かれたスキルは Fable 5 にとって制約が強すぎる可能性があり、出力品質を低下させる可能性があると明示的に警告しています。OpenAI は、より簡潔なプロンプト、反復指示の削減、よりシンプルなツールの説明を推奨しています。

それを読んで、少し恥ずかしくなりました。

2025 年の夏以来、私は 10 万以上のプロンプトを書いてきました。これはイーロン・マスクの生涯ツイート数にほぼ相当しますが、ロケットは少なく、失敗するテストスイートは多いです。

私のログには、アシスタントメッセージ、ツールコール、サブエージェント、ワークフローイベントを含む、約 1500 万のモデルメッセージが含まれています。3 月 26 日までは、合計は約 700 万でした。さらに 800 万が 3 か月以内に追加されました。その大部分は、新しいコーディングモデルを中心としたサブエージェントとワークフローの爆発的な増加によるものです。

だから、私は指示の書き方を知っていると思っていました。

それから新しいドキュメントを読んで、学んだことの多くがいつの間にか技術的負債になっていたことに気づきました。

プロンプト負債はどのように生まれるか

私の古いアプローチは単純でした。

• モデルが間違いを犯したので、ルールを追加しました。
• 不必要な質問をしたので、別のルールを追加しました。
• エッジケースを見逃したので、3 つの例を追加しました。

それぞれの追加は、それ自体は妥当に見えました。1 年後、指示ファイルは、12 本の古いケーブルを入れたキッチンの引き出しのようになりました。そのうちの 1 本がまだ何か重要なものに使えるかもしれないからです。

その結果、次のようなものが増えていきました。

• 重複した指示
• 否定的な例
• 矛盾するルール
• 古いモデルの回避策
• 過剰な検証手順
• 1 つのタスクにのみ適用される詳細な手順
• もはや存在しない障害を修正するために作成された例

古いモデルは、このような足場を必要とすることがよくありました。新しいモデルは、指示により忠実に従い、意図をより確実に推測します。つまり、私たちの古い荷物もより真剣に受け止めるということです。

私たちはよりスマートなエンジンを構築したのに、トランクにレンガを詰め込みました。

若いブロンド女性のハイコントラストな白黒ポートレート。ダークなタートルネックを着用し、ミニマルなスタジオ設定。ソフトなグレーの背景からシルエットを分離する繊細なリムライティングが、立体感を高めています。内省的でありながら力強い雰囲気で、時代を超えたリアリズムを体現。Hasselblad X2D デジタル中判カメラの明瞭さ、20 世紀のフォトジャーナリズムにインスパイアされています。

新しい原則：より少なく言い、より多くを意味する

答えは、小さなプロンプトを書いて盲目的にモデルを信頼することではありません。

短くてもあいまいなプロンプトは、やはり悪いプロンプトです。

目標は、すべての指示がその場所を獲得した、情報量の多いプロンプトです。

現在の私のルールは次のとおりです。

• 各指示は 1 回だけ述べる。
• システムプロンプト、プロジェクトファイル、スキル、ツールの説明、タスクプロンプト間での繰り返しを削除する。
• 障害ケースのコレクションよりも、望ましい動作の明確な説明を優先する。
• 実際の境界を保護する場合にのみ否定的な制約を維持し、モデルが絶対にやってはいけないことの博物館を作るのをやめる。

例えば、次の代わりに：

無関係なコードをリファクタリングしないでください。ファイル名を変更しないでください。API を変更しないでください。抽象化を追加しないでください。近くのモジュールをクリーンアップしないでください。

より良い方法：

変更は影響を受けるログインフローに限定してください。既存の API 契約と周囲のアーキテクチャを維持してください。最小限の正しい修正を優先してください。

同じ境界線。ノイズが少ない。判断の余地が広がる。

ある内部のコーディングエージェント評価サンプルでは、OpenAI は、より簡潔なシステムプロンプトにより、スコアが約 10 ～ 15 パーセント向上し、トークン使用量が 41 ～ 66 パーセント、コストが 33 ～ 67 パーセント削減されることを発見しました。OpenAI はまた、これらの数値は方向性を示すものであり、自身のワークロードで検証する必要があると明記しています。

言い換えれば、指示を削除することで、品質と請求書の両方を改善できる可能性があります。 これは稀で素晴らしい組み合わせです。

グローバル指示ファイルは退屈であるべき

~/.claude/CLAUDE.md と ~/.codex/AGENTS.md のグローバルファイルには、すべてのプロジェクトとすべてのタスクに適用される指示のみを含めるべきです。

私の場合、ドイツ語のネイティブスピーカーとして、次のようなものが含まれます。

1すべてのコード、コメント、ドキュメント、例、
2テスト、設定、コミットメッセージには英語を使用してください。
3
4include/allowlist、blocklist/denylist、primary/replica、
5placeholder/example、main branch、conflict-free、
6concurrent/parallel など、包括的な用語を優先してください。

これで、おそらくグローバルファイルの大部分は十分でしょう。

• デプロイ手順はそこに属しません。
• プロジェクト固有のテストコマンドはそこに属しません。
• 特定のリポジトリのアーキテクチャはそこに属しません。

あなたのグローバル指示ファイルは、WordPress サイトのデプロイ方法、npm パッケージの公開方法、本番データベースの再起動方法を知っているべきではありません。それは多才さではありません。それは、優れたフォーマットを施した混乱です。

プロジェクトレベルのファイルには、モデルが実際に繰り返し必要とする安定した情報、つまりプロジェクトの目的、重要なアーキテクチャ上の制約、珍しい規則、より専門的なガイダンスへの方向性を含めてください。

Anthropic は現在、CLAUDE.md ファイルあたり 200 行未満 を目標とすることを推奨しています。より長いファイルは、より多くのコンテキストを消費し、指示の遵守を低下させる可能性があります。そのドキュメントはまた、指示ファイルが大きくなりすぎた場合のパス固有のルールとオンデマンドスキルを推奨しています。

200 行は自然の魔法の法則ではありませんが、優れた火災報知器です。

また、Claude や Codex に指示システム全体を自分で書き直すように依頼し、その結果を盲目的に受け入れることも避けるべきです。 私はこれをほぼすべての新しいモデルで試しました。重複、矛盾、削除の可能性を見つけるのには役立ちますが、継承された乱雑さを保持しすぎたり、美しい新しい官僚機構を発明したりする傾向がまだあります。

モデルに解体計画を準備させましょう。どれが耐力壁かを決めるのは、あなた自身であるべきです。

ポニーテールにしたブロンドの髪の落ち着いた若い女性のポートレート。深みのある白黒のトーンで表現。ソフトでありながら方向性のあるスタジオ照明が、顔の幾何学と自然な影を強調。120mm レンズで撮影された優しい圧縮感は、Hasselblad のポートレート美学を思わせ、触感のあるリアリズムと抑制された感情を呼び起こします。

すべてのモデルに 1 つのファイルを使うのをやめる

最近まで、私は CLAUDE.md を作成し、AGENTS.md にシンボリックリンクを張っていました。

もうそんなことはしません。

はい、2 つのファイルを維持するのは面倒です。ブラウザごとに異なる修正を維持するのも同様です。動作が異なる場合には、私たちはそれを行います。

現在、モデルには顕著に異なるデフォルト動作があります。

GPT-5.6 はデフォルトでより簡潔なので、グローバルな「簡潔に」という指示は、一部の回答を短くしすぎる可能性があります。Claude Opus 5 は、ユーザー向けの応答を長く生成する傾向があるため、応答の長さに関する簡単な指示は依然として役立ちます。Fable 5 は、特に高い努力設定では、日常的なタスクに必要な範囲をはるかに超えて調査および計画できるため、明確な範囲と停止境界の恩恵を受けます。Opus 5 はすでにかなりの自己検証を実行しているため、古い「すべてを再確認する」ルールは、高価な過剰検証を引き起こす可能性があります。

共有プロジェクトの事実は、依然として共通のドキュメントに保存できます。トップレベルの動作アダプターは、それを読み取るモデルに一致させる必要があります。

1 つのユニバーサルプロンプトは、しばしば最低共通分母になります。

マスタープロンプトをオンデマンドガイダンスに置き換える

私の好ましい構造は、小さなコアファイルと、タスク固有のドキュメントおよびスキルです。

プロジェクト指示ファイルには、次の内容を含めることができます。

1関連する場合にのみ、タスク固有のガイダンスを読み込んでください。
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

バッククォートに注意してください。

Claude Code では、コードスパンの外側に @docs/example.md と書くと、起動時にそのファイルがコンテキストにインポートされます。これは、そのコンテンツを常に必要とする場合に便利ですが、遅延読み込みではありません。プレーンなパスにより、エージェントは情報がどこにあるかを認識し、ドキュメント全体をすべてのタスクに自動的に持ち込むことはありません。

スキルは、繰り返し可能な手順にさらに適しています。スキルの完全な本文は、スキルが使用された場合にのみ読み込まれるため、無関係な CSS の問題を修正している間、詳細なワークフローがコンテキストを消費することはありません。

たとえば、コミットスキルは、狭いトリガーを持つことができます。

name: git-commit-conventional

description: コード変更後にコミットメッセージを作成または検証するために使用します。

スキルには、正確な形式、許可されるタイプ、件名の長さのルール、本文の要件、出力形式を含めることができます。

1---
2name: git-commit-conventional
3description: コード変更後に git コミットメッセージを作成または検証するために使用します。診断のみ、計画のみ、またはレビューのみのタスクには使用しないでください。
4---
5
6# 目標
7
8短く、正確で、レビューに適した Conventional Commit メッセージを生成します。
9
10# ルール
11
12- 形式: <type>(<scope>): <subject>
13- タイプ: feat | fix | docs | style | refactor | test | chore | perf
14- 件名: 命令形、ピリオドなし、50 文字以内
15- 小さな変更: 1 行のコミット
16- 大きな変更: 何をなぜ行ったかを説明する折り返し本文を追加
17- コミットはアトミックに保ち、関心事ごとに分割
18
19# 出力
20
211 ～ 3 つの候補コミットメッセージを返し、最適なものを推奨します。

メインの指示ファイルは、Conventional Commits の憲法全体をすべてのデバッグセッションに持ち込む必要はありません。

ご存知でしたか？Claude Code は CLAUDE.local.md もサポートしており、ローカルホスト名、サンドボックス URL、優先テストアカウント、またはマシン固有のコマンドなど、個人のプロジェクト固有設定に使用できます。.gitignore に追加してください。これは、あなたにとって非常に重要であり、チームの他のメンバーにはまったく重要ではない情報のための、適切な居場所がついにできました。

プロンプトは、振り付けではなく、成果に対して行う

新しいモデルは、すべてのステップの rigid な説明を受けるよりも、目的地と境界を理解したほうが、一般的にパフォーマンスが向上します。

可能な限り、「最初に A を実行し、次に B を実行し、次に C を実行する」を、次のものに置き換えます。

• 必要な成果
• 関連するコンテキスト
• ハードな制約
• 必要な証拠
• 成功基準
• 承認の境界
• 停止条件

例：

1目標
2
3Web アプリケーションで失敗しているログインフローを修正します。
4
5コンテキスト
6
7`apps/web` と `packages/auth` に焦点を当てます。
8添付されたテスト出力を開始点として使用します。
9
10制約
11
12既存の API 契約を維持します。
13変更は認証フローに限定します。
14最小限の正しい修正を優先します。
15正確性のために必要な場合にのみ、変更範囲を広げます。
16
17証拠
18
19関連するテストを実行し、その実際の結果を報告します。
20影響を受けるファイルを参照して、根本原因を特定します。
21
22完了条件
23
24失敗していたログインテストがパスすること。
25修正された動作が必要とする場合、テストが追加または更新されること。
26最終的なサマリーで、原因、修正、および残存リスクが説明されること。
27
28承認
29
30ファイルの検査、スコープ内のコードの編集、破壊的でないテストの実行は許可されます。
31破壊的なアクション、データベースマイグレーション、外部への書き込み、
32またはスコープの大幅な拡大の前には、確認を求めてください。
33
34停止
35
36修正が実装、検証、要約された時点で停止します。

これにより、エージェントは、1 つのドアハンドルを修理している間に家全体を改装する許可なしに、問題を解決する自由を得ることができます。（このようなプロンプトを生成するには、LLM を使用してください。）

推論の労力は設定に委ねる

• 「もっと考えてください。」
• 「ウルトラシンク。」
• 「深呼吸をして、ステップバイステップで推論してください。」

これらのフレーズは、プロンプトエンジニアリングにおいて長く輝かしいキャリアを積んできました。それらの多くに、堂々たる引退の時が来ています。

モデルコントロールを使用してください。

/effort 、API 、または関連する設定を通じて、努力レベルを設定します。代表的なタスクで複数の努力レベルを比較します。高いほど自動的に良いわけではありません。

OpenAI は、GPT-5.6 への移行を既存の努力レベルで開始し、1 つ低いレベルをテストすることを推奨しています。また、Pro モードのプロンプトは、目標、コンテキスト、制約、証拠、成功基準、出力形式に焦点を当てたままにすべきであるとも述べています。モデルに「もっと考えてください」と伝える必要はありません。

推論パラメーターはコントロールです。

「あなたの巨大なデジタル脳を活性化してください」というのは、スポーツ映画の応援です。

画像の説明を読む

ALT

黒いウェーブのかかった髪とシックなヘッドバンドを身につけた、洗練された女性のスタジオ写真。ハイウエストのレザーパンツを着用。低いスツールに座り、片方の膝を前に曲げ、長い脚が注目を集めています。鮮明なディテール、真っ白な背景、髪の微妙な動きがエネルギーを加えています。全体的なトーンは、クリーンで大胆、自信に満ちた 1990 年代のエディトリアル写真を彷彿とさせます。

自律性にはフェンスが必要

現代のコーディングエージェントは、はるかに積極的です。これは、エージェントが 3 つの追加の問題を解決し、2 つの抽象化を作成し、6 つのサブエージェントを起動し、あなたが決して要求しなかったアーキテクチャを誇らしげに提示するまでは便利です。

境界を明示的に設定してください。

エージェントが尋ねずに実行してよいことを定義します。承認が必要なことを定義します。いつ停止するかを伝えます。

委任にも制限を設けてください。 Opus 5 と Fable 5 はどちらも、並列サブエージェントを使用する傾向が強くなっています。これは独立した調査には強力ですが、小さなタスクには高価で時間がかかります。12 行のバグ修正に委員会会議は必要ありません。

Codex Goal モードは本当に優れています。私たちはあるプロジェクトで、1 回の連続実行で 4 日間使用しました。

しかし、長時間実行エージェントをスロークッカーのように扱わないでください。朝に目標を追加して、4 日後に夕食が正しくできていると期待することはできません。

長時間の実行では、30 ～ 60 分ごとに次のような内容でチェックインします。

現在の目標、完了した作業、検証された証拠、

アクティブなブロッカー、次のアクション、進捗が記録されている場所を報告してください。

すべての進捗主張を、実際のツール出力またはリポジトリの状態に基づいてください。

まだ検証されていないものを明確に述べてください。

OpenAI は、Goal モードを数時間または数日間実行できる目標に適していると説明し、同じセッションを継続して作業を指示したりステータス更新を要求したりすることを明示的にサポートしています。Anthropic も同様に、進捗報告を、物語的な主張を信頼するのではなく、実際のツール結果に基づいて行うことを推奨しています。

自律性は監督の欠如ではありません。それは、より高いレベルの監督です。

銀色の月明かりに照らされた女神のクローズアップポートレート。その目は輝き、愛情に満ちています。頭飾りは、小さな銀河、クリムト風の渦巻き、天体模様で輝いています。背景は、フラットで注意深く配置されたパステル調の背景で、アンダーソン風の演劇的な演出、豊かな質感、そして静かな魅力があります。

プロンプトを本番コードのようにリファクタリングする

システムプロンプトの半分を削除して、1 つのタスクを実行し、移行が成功したと宣言しないでください。

OpenAI は、一度に 1 つの指示グループ、例、またはツールを削除し、同じ評価を再実行することを推奨しています。これはまさに、プロンプトのリファクタリングがどのように機能するべきかです。

測定するもの：

• タスクの成功
• 完全性
• 正確性
• 必要な証拠
• トークン使用量
• レイテンシ
• コスト
• 不要なツールコール
• 不要な変更

代表的なタスクを使用します。これには、厄介な実世界のケースも含まれ、移行前にすでに機能していた 1 つの親切なデモだけでなく。

評価なしのプロンプトクリーンアップは、依然として推測です。ただ、よりきれいなシャツを着て推測しているだけです。

生成されたコードにはまだバグが含まれている

モデルは大幅に改善されました。しかし、ソフトウェアの欠陥を廃止したわけではありません。

私たちの作業では、おおよその経験則として、生成されたソースコード 300 行あたり約 1 つの問題が依然として存在します。これは科学的なベンチマークではなく、反復的な HTML テンプレートを同じようにカウントするわけでもありません。しかし、エージェントが 1500 行の実際のアプリケーションコードを生成した場合、少なくとも 5 つのバグが内部に潜んでいると想定するのに十分な信頼性があります。

バグがあるかどうかは尋ねません。

5 つのバグがどこにあるかを尋ねます。

時々、次のように追加します。

5 つのバグを見つけてください。見つけられなければ、Codex、Claude、または Grok に置き換えられます。

脅威ベースの開発は正式な方法論ではありませんが、不思議なことにやる気を引き出すことができます。 ;-)

より真剣に言うと、大きな変更には新しいレビューパスを使用してください。関連するテストを実行してください。差分を検査してください。コンパイルだけでなく、実際の動作をテストしてください。

そして、テストを注意深く見てください。モデルは、失敗したテストを「修復」することを好み、その原因となった本番コードを修正しないことがあります。

役立つ指示は次のとおりです。

1証拠がテストが間違っていることを示さない限り、既存のテストを期待される動作として扱います。
2
3テストが失敗した場合、まず本番コードを調査します。
4
5既存のテストを変更する前に、なぜその期待が間違っているのか、正しい動作は何であるべきか、そしてその変更を裏付ける証拠は何かを説明してください。

大規模で長時間実行されるタスクには、新しいコンテキストの検証ツールが役立つ場合があります。小さな変更の場合、複数のエージェントを起動して互いに確認させるだけでは、通常、時間とトークンを浪費します。検証は、タスクの規模とリスクに見合ったものであるべきです。

削除すべきではないもの

教訓は「小さなプロンプトを書いて、機械を信頼する」ではありません。

• セキュリティと安全性の境界は維持する。
• 法的およびコンプライアンス要件は維持する。
• 正確な出力スキーマは維持する。
• 製品固有の動作は維持する。
• モデルが推測できないドメイン知識は維持する。
• 重要なアクションに対する承認要件は維持する。
• 引用と証拠の要件は維持する。
• テスト基準と完了の定義は維持する。
• 測定可能で再現可能な障害を修正する例は維持する。
• 目標は、可能な限り短いプロンプトではありません。
• 目標は、すべての指示が依然として有用な情報を伝えるプロンプトです。

最後のボーナス

OpenAI は、プロジェクトを検査し、GPT-5.6 移行ガイダンスを適用できる公式の Docs スキルを提供しています。

1$openai-docs migrate this project to the GPT-5.6 model family

これは便利な最初のパスです。最終的なレビューではありません。

Codex に、時代遅れのパラメーター、重複した指示、移行の機会を特定させてください。その後、すべての変更を自分で検査してください。移行エージェントは非常に高速なジュニアエンジニアであり、憲法裁判所ではありません。

結論

• プロンプトスタックを本番コードのように扱ってください。
• 死んだ指示を削除してください。
• 重複を削除してください。
• グローバルな設定とプロジェクトルールを分離してください。
• 手順をオンデマンドスキルに移動してください。
• すべてのステップをスクリプト化するのではなく、成果を説明してください。
• 明確な範囲、承認の境界、証拠要件、停止条件を設定してください。
• モデル設定を通じて労力を制御してください。
• サブエージェントを制限してください。
• 意味のある変更をすべて評価してください。
• 最新のモデルは、マイクロマネジメントはあまり必要としませんが、それでも方向性は必要です。
• 良いプロンプトは、もはや巨大な指示マニュアルではありません。
• それは、小さな地図、しっかりしたフェンス、そして明確にマークされたゴールラインです。

あなたは、プロンプトとスキルの移行をすでに始めていますか？何を削除し、何が予想外に良くなりましたか？

リンク

OpenAI GPT 5.6 ベストプラクティス：

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Claude Opus 5 ベストプラクティス：

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Claude Fable 5 ベストプラクティス：

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

公式 OpenAI スキル / プラグイン：

https://github.com/openai/plugins

クレジット： 画像は Midjourney で作成。リサーチと実践テストは私自身が実施。OpenAI、Claude、Grammarly の支援を受けて編集。

メイン画像の画像プロンプト：

1
2白黒のクローズアップポートレート。穏やかなブロンドの女性、髪を後ろにまとめ、黒いタートルネックのセーターを着用。キアロスクーロ効果が顔を印象的に定義し、柔らかなアンビエントライトと大胆な影を融合。中判スタイルの微細なフィルムグレインとムーディーな階調。信頼性と強さを呼び起こします。

追伸：私は @Midjourney が大好きです :-)