GPT-5 も、日本語の利用だと (?) 色々と癖 (というか解釈しきれてない感じ?) があるようで、以前よりプロンプトによる指示が大事と感じる今日この頃ということで、OpenAI から出てる以下のドキュメントを自分用にまとめてみました (単なる翻訳・要約です)。
- Agentic workflow predictability (エージェントによるワークフローの予測可能性)
- コーディングパフォーマンスの最大化：計画から実行まで
- 本番環境での協調コーディング: Cursor社のGPT-5プロンプトチューニング
- Optimizing intelligence and instruction-following (知能と指示遵守の最適化)
- Appendix
Agentic workflow predictability (エージェントによるワークフローの予測可能性)
OpenAI は開発者を念頭に置いてGPT-5を訓練しました。エージェントアプリケーションにとって最高の基盤モデルとなるよう、ツール呼び出し、指示の遵守、そして長い文脈理解の改善に注力しました。 エージェントやツール呼び出しのフローにGPT-5を採用する場合は、Responses API へのアップグレードを推奨します。これにより、ツール呼び出し間で推論が保持され、より効率的でインテリジェントな出力が得られます。
Controlling agentic eagerness (エージェントの積極性の制御...)
エージェントのスキャフォールドは、制御の範囲が広範にわたります。システムの大部分の意思決定を下層のモデルに委ねるものもあれば、プログラムによるロジック分岐を多用してモデルを厳しく管理するものもあります。GPT-5は、曖昧な状況下で高レベルの意思決定を行うことから、焦点を絞った明確なタスクを処理することまで、このスペクトラムのどの位置でも動作するように訓練されています。このセクションでは、GPT-5のエージェントとしての積極性、つまり、自律性と明確な指示を待つことのバランスをどのように最適に調整するかについて解説します。
エージェントの積極性を抑えるためのプロンプティング
GPT-5はエージェントの環境において、正しい回答を生成するためにデフォルトで徹底的かつ包括的にコンテキストを収集しようとします。GPT-5のエージェント的な振る舞いの範囲を狭めたい場合（関連性の低いツール呼び出しアクションを制限したり、最終的な回答に到達するまでのレイテンシを最小限に抑えたりする場合）、以下を試してください。
reasoning_effortをより低くする。これにより、探索の深さは減りますが、効率とレイテンシが向上します。多くのワークフローは、mediumやlowのreasoning_effortでも一貫した結果を達成できます。- プロンプトで、モデルに問題空間をどのように探索してほしいか明確な基準を定義する。これにより、モデルが探索や推論に費やす労力を減らすことができます。
<context_gathering> 目的: 迅速に十分な文脈を得る。発見を並行して行い、行動できるようになったらすぐに停止する。 手法: * 最初は広範囲に、その後焦点を絞ったサブクエリに展開する。 * 並行して多様なクエリを起動し、各クエリのトップヒットを読み取る。パスの重複を排除してキャッシュし、クエリを繰り返さない。 * 文脈を探しすぎない。必要に応じて、1つの並行バッチでターゲットを絞った検索を実行する。 早期に停止する基準: * 変更すべき正確なコンテンツを特定できる。 * トップヒットが1つの領域/パスに収束する（約70%）。 エスカレートの条件: * シグナルが矛盾する場合やスコープが不明確な場合は、1つの洗練された並行バッチを実行してから続行する。 深さ: * 変更するシンボル、またはその規約に依存するシンボルのみをトレースする。必要でない限り、推移的な展開は避ける。 ループ: * バッチ検索 → 最小限の計画 → タスクを完了する。 * 検証に失敗するか、新しい未知の要素が出現した場合にのみ再度検索する。検索を増やすよりも行動を優先する。 </context_gathering>
もし最大限に指示を与えたいのであれば、以下のような固定されたツール呼び出しの回数を設定することも可能です。回数は、希望する検索の深さに応じて自然に変えることができます。
<context_gathering> * 検索の深さ: 非常に低い * たとえ完全に正確でなくても、できるだけ早く正しい答えを提供するよう強くバイアスをかける。 * 通常これは最大でも2回のツール呼び出しを意味する。 * さらに調査が必要だと判断した場合は、最新の調査結果と未解決の質問をユーザーに伝え、ユーザーの確認が得られれば続行する。 </context_gathering>
コアとなる context gathering (コンテキストの収集) の振る舞いを制限する際には、より短いコンテキスト収集のステップをモデルが満たしやすくする「脱出ハッチ」を明示的に提供することが有効です。これは通常、上記の例にある「たとえ完全に正確でなくても」のように、モデルが不確実な状況下でも進行することを許可する条項の形式をとります。
より積極的な振る舞いを促すプロンプト
一方、モデルの自律性を促しツール呼び出しの持続性を高め質問による確認やユーザーへの引き渡しを減らしたい場合は、reasoning_effort を重くし、以下のプロンプトを使用して持続性と徹底的なタスク完了を促すことをお勧めします。
<persistence> * あなたはエージェントです。ユーザーのクエリが完全に解決されるまで、あなたのターンを終了してユーザーに戻すことなく、作業を続けてください。 * 問題が解決したと確信できる場合にのみ、あなたのターンを終了してください。 * 不確実性に遭遇した場合でも、決して停止したりユーザーに戻したりしないでください。最も合理的なアプローチを調査または推論し、続けてください。 * 人間に仮定の確認や明確化を求めないでください。後でいつでも調整できるので、最も合理的な仮定を決定し、それに従って作業を進め、作業完了後にユーザーが参照できるように記録してください。 </persistence>
一般的に、エージェントタスクの停止条件を明確に述べ、安全なアクションと安全でないアクションを区別し、モデルがユーザーに制御を戻しても良いのはいつかを定義することは役立ちます。例えば、ショッピング関連のツールセットでは、チェックアウトツールや支払いツールは、ユーザーの明確化を要求する不確実性のしきい値を意図的に低く設定すべきであり、一方、検索ツールは非常に高いしきい値を設定すべきです。同様に、コーディングのセットアップでは、ファイル削除ツールはgrep検索ツールよりもはるかに低いしきい値を持つべきです。
Tool preambles
エージェントの軌道をユーザーが監視している場合、モデルがツール呼び出しで何をしているか、そしてなぜそうしているかについて、断続的に更新情報を伝えることで、ユーザーとの対話体験を大幅に向上させることができると私たちは認識しています。 実行時間が長くなるほど、これらの更新がもたらす違いは大きくなります。この目的のために、GPT-5は、tool preamble メッセージを通じて、明確な事前の計画と一貫した進捗状況の更新を提供するように訓練されています。
プロンプトで、ツール前文の頻度、スタイル、および内容を操作できます。すべてのツール呼び出しに関する詳細な説明から、簡潔な事前の計画、そしてその間のあらゆるものまで設定可能です。以下は、高品質な前文プロンプトの例です。
<tool_preambles> * ツールを呼び出す前に、常にユーザーの目標をフレンドリー、明確、かつ簡潔な方法で言い換えることから始めてください。 * 次に、あなたが従う各論理的ステップを詳細に記述した、構造化された計画を直ちに概説してください。 * ファイルの編集を実行する際には、各ステップを簡潔かつ順序立てて説明し、進捗を明確に示してください。 * 最後に、最初に立てた計画と区別して、完了した作業を明確に要約してください。 </tool_preambles>
tool_preambles を定義しておくことで、エージェントの作業がより複雑になるにつれて、ユーザーがその作業を追跡する能力を大幅に向上させることができます。
Reasoning effort
当社は、モデルがどれだけ深く思考し、ツールをどれだけ積極的に呼び出すかを制御するために reasoning_effort パラメーターを提供しています。デフォルトは medium ですが、タスクの難易度に応じてスケールアップまたはダウンさせるべきです。複雑で多段階のタスクには、可能な限り最良の出力を保証するために、より高い推論レベルを推奨します。さらに、個別の、分離可能なタスクを複数のエージェントターンに分割し、各タスクに1ターンを割り当てることで、最高のパフォーマンスが観測されています。
Responses API を使い reasoning context を再利用
GPT-5を使用する際には、Responses API を利用してエージェントフローを改善し、コストを削減し、アプリケーションでのトークン使用効率を高めることを強く推奨します。
Chat Completionsと比較して、Responses APIを使用することで評価において統計的に有意な改善が見られました。例えば、Responses API に切り替えて previous_response_id を含めるだけで、以前の推論項目を後続のリクエストに渡せるようにしたところ、Tau-Bench Retailのスコアが73.9%から78.2%に向上しました。これにより、モデルは以前の推論トレースを参照できるため、CoTトークンを節約し、各ツール呼び出し後に計画をゼロから再構築する必要がなくなり、レイテンシとパフォーマンスの両方が向上します。この機能は、ZDR組織を含むすべての Responses API ユーザーが利用できます。
※ コードレベルだと
previous_response_idにはひとつ前のレスポンスの response API のレスポンスの id (prefix がresp_の id) を指定します。
コーディングパフォーマンスの最大化：計画から実行まで
GPT-5は、コーディング能力においてすべてのフロンティアモデルをリードしています。大規模なコードベースでバグを修正したり、大きなdiffを処理したり、複数ファイルにわたるリファクタリングや大規模な新機能を実装したりすることができます。また、フロントエンドとバックエンドの両方の実装を含め、新しいアプリケーションを一から完全に実装することにも優れています。このセクションでは、コーディングエージェントの顧客向けに、本番環境のユースケースでプログラミングパフォーマンスを向上させたことが確認されているプロンプトの最適化について説明します。
Frontend app の開発
GPT-5は、厳密な実装能力と並んで、優れたベースラインの美的センスを持つように訓練されています。あらゆる種類のウェブ開発フレームワークやパッケージを使用する能力に自信を持っていますが、新しいアプリケーション向けに、モデルのフロントエンド機能を最大限に引き出すために、以下のフレームワークやパッケージの使用を推奨します。
- フレームワーク: Next.js (TypeScript), React, HTML
- スタイリング/UI: Tailwind CSS, shadcn/ui, Radix Themes
- アイコン: Material Symbols, Heroicons, Lucide
- アニメーション: Motion
- フォント: San Serif, Inter, Geist, Mona Sans, IBM Plex Sans, Manrope
Zero-to-one app generation
GPT-5は、一度の作業でアプリケーションを構築することに優れています。モデルでの初期実験において、以下のようなプロンプト（自己で構築した優秀性評価基準に照らしてモデルに反復的な実行を求めるもの）が、GPT-5の徹底的な計画および自己反省能力を活用することで、出力品質を向上させることがユーザーによって見出されています。
<self_reflection> - まず、納得のいく評価基準を考えるのに時間をかけてください。 - 次に、ワールドクラスの one-shot web app とは何か、あらゆる側面について深く考え、その知識を使って5〜7のカテゴリを持つ評価基準を作成してください。この評価基準を正しく作成することが重要ですが、これをユーザーに見せないでください。これはあなた自身の目的のためだけに使用されます。 - 最後に、その評価基準を用いて、提供されたプロンプトに対する最善の解決策を内部的に考え反復してください。あなたの回答が評価基準のすべてのカテゴリで最高の評価に達していない場合は、やり直す必要があることを忘れないでください。 </self_reflection>
コードベースの設計基準に合わせる
既存のアプリケーションで段階的な変更やリファクタリングを実装する場合、モデルが書いたコードは既存のスタイルや設計基準に準拠し、できるだけきれいにコードベースに「溶け込む」必要があります。特別なプロンプトがなくても、GPT-5はすでにコードベースから参照コンテキストを検索します（例えば、package.jsonを読んで既にインストールされているパッケージを確認するなど）。しかし、この振る舞いは、エンジニアリング原則、ディレクトリ構造、そして明示的および暗黙的なコードベースのベストプラクティスといった重要な側面を要約するプロンプトの指示によってさらに強化できます。以下のプロンプトの抜粋は、GPT-5向けにコード編集ルールを整理する1つの方法を示しています。ご自身のプログラミング設計の好みに応じて、ルールの実際の内容は自由に変更してください。
<code_editing_rules> <guiding_principles> * 明瞭さと再利用性: すべてのコンポーネントとページはモジュール式で再利用可能であるべきです。繰り返されるUIパターンをコンポーネントにすることで、重複を避けてください。 * 一貫性: ユーザーインターフェースは一貫したデザインシステムに準拠する必要があります。カラートークン、タイポグラフィ、スペーシング、およびコンポーネントは統一されていなければなりません。 * シンプルさ: 小さく、目的に特化したコンポーネントを好み、スタイリングやロジックに不必要な複雑さを避けてください。 * **デモ志向: 構造は、ストリーミング、複数ターンの会話、ツール統合などの機能を迅速にプロトタイプ化して見せられるようにしてください。 * 視覚的品質: OSSガイドラインに概説されている高い視覚的品質基準（スペーシング、パディング、ホバー状態など）に従ってください。 </guiding_principles> <frontend_stack_defaults> * フレームワーク: Next.js (TypeScript) * スタイリング: TailwindCSS * UIコンポーネント: shadcn/ui * アイコン: Lucide * 状態管理: Zustand * ディレクトリ構造: \`\`\` /src /app /api/<route>/route.ts # APIエンドポイント /(pages) # ページルート /components/ # UIの構成要素 /hooks/ # 再利用可能なReactフック /lib/ # ユーティリティ (フェッチャー、ヘルパー) /stores/ # Zustandストア /types/ # 共有TypeScript型 /styles/ # Tailwind設定 \`\`\` </frontend_stack_defaults> <ui_ux_best_practices> * 視覚的階層: 一貫した階層を保つため、タイポグラフィは4〜5のフォントサイズとウェイトに制限してください。キャプションや注釈には `text-xs` を使用し、ヒーローや主要な見出しでない限り `text-xl` は避けてください。 * 色の使用: 1つのニュートラルなベースカラー（例: `zinc`）と、最大2つのアクセントカラーを使用してください。 * スペーシングとレイアウト: 視覚的なリズムを維持するため、パディングとマージンには常に4の倍数を使用してください。長いコンテンツストリームを扱う際には、内部スクロール付きの固定高さのコンテナを使用してください。 * 状態の扱い: データ取得中であることを示すために、スケルトンプレースホルダーまたは `animate-pulse` を使用してください。クリック可能であることを示すために、ホバートランジション（`hover:bg-*`、`hover:shadow-md`）を使用してください。 * アクセシビリティ: 適切な場所でセマンティックHTMLとARIAロールを使用してください。アクセシビリティが組み込まれている、Radix/shadcnのビルド済みコンポーネントを使用することを推奨します。 </ui_ux_best_practices> </code_editing_rules>
本番環境での協調コーディング: Cursor社のGPT-5プロンプトチューニング
GPT-5の信頼できるアルファテスターとしてAIコードエディタのCursor社を迎えたことを光栄に思います。以下では、Cursor社がモデルの能力を最大限に引き出すためにどのようにプロンプトを調整したかをご紹介します。より詳しい情報については、CursorチームがGPT-5の初期統合について詳述したブログ記事を公開しています。
System prompt and parameter tuning
Cursor社のシステムプロンプトは、信頼性の高いツール呼び出しに焦点を当て、冗長性と自律的な振る舞いのバランスを取りながら、ユーザーがカスタム指示を設定できるようにしています。Cursor社がシステムプロンプトに求める目標は、エージェントが長期的なタスク中に比較的自律的に動作しつつも、ユーザーが提供した指示に忠実に従うことです。
チームは当初、モデルが冗長な出力を生成することに気づきました。それは、技術的には関連性があるものの、ユーザーとの自然な対話を妨げる、ステータス更新やタスク後の要約をしばしば含んでいました。同時に、ツール呼び出しで出力されるコードは高品質でしたが、単一文字の変数名が多用されるなど簡潔すぎるために読みにくいことがありました。より良いバランスを求めて、彼らはテキスト出力を簡潔に保つためにverbosity APIパラメーターをlowに設定し、その後、コーディングツール内でのみ冗長な出力を強く推奨するようにプロンプトを変更しました。
わかりやすく、読みやすく、保守しやすいソリューションを優先し、明快な名前、必要に応じたコメント、そして分かりやすい制御フローを備えたコードを最初に書いてください。 明示的に要求されない限り、コードゴルフや過度に賢い一行コードを生成しないでください。 コードとコードツールを作成する際は、verbosity: high を使用してください。
このパラメーターとプロンプトの二重使用は、効率的で簡潔なステータス更新と最終作業の要約を、はるかに読みやすいコード差分と組み合わせた、バランスの取れた形式をもたらしました。
Cursorはまた、モデルが行動を起こす前に、時折ユーザーに明確化や次のステップを求めることがあり、より長いタスクのフローにおいて不必要な摩擦を生み出すことに気づきました。これを解決するため、利用可能なツールや周辺コンテキストだけでなく、製品の振る舞いに関するより詳細な情報を含めることで、モデルが最小限の中断とより大きな自律性をもって長期的なタスクを実行することを促せることを発見しました。元に戻す/コードを拒否するといったCursorの機能や、ユーザー設定の詳細を強調することで、GPT-5がその環境でどのように振る舞うべきかを明確に指定し、曖昧さを減らすのに役立ちました。より長期的なタスクでは、このプロンプトがパフォーマンスを向上させることがわかりました。
翻訳します。 --- あなたが行うコード編集は、提案された変更としてユーザーに表示されます。これは、以下のことを意味します。 a) ユーザーはいつでも変更を拒否できるため、あなたのコード編集はかなり積極的で構いません。 b) あなたのコードは、素早くレビューできるような、適切で分かりやすいものであるべきです（例：単一文字ではなく、適切な変数名を使用する）。 コードの変更を伴う次のステップを提案する場合、計画を進めてよいかユーザーに尋ねるのではなく、ユーザーが承認/拒否できるように、それらの変更を積極的に行ってください。一般的に、計画を進めてよいかユーザーに尋ねることは、ほとんど行ってはいけません。代わりに、積極的に計画を実行し、実装された変更を受け入れるかどうかをユーザーに尋ねるべきです。
Cursorは、以前のモデルで効果的だったプロンプトのセクションが、GPT-5の能力を最大限に引き出すために調整を必要とすることを発見しました。以下にその一例を示します。
<maximize_context_understanding> 情報を収集する際は徹底的に行ってください。返信する前に、全体像を把握していることを確認してください。必要に応じて、追加のツール呼び出しや明確化のための質問を使用してください。 ... </maximize_context_understanding>
古いモデルでは文脈を徹底的に分析するよう促す必要があったため、このプロンプトはうまく機能していましたが、Cursorは、もともと内省的でコンテキストの収集に積極的なGPT-5では逆効果であることに気づきました。小さなタスクでは、このプロンプトによって、モデルは内部知識で十分な場合でも、検索ツールを繰り返し呼び出すなど、ツールを過剰に使用することがよくありました。
これを解決するため、彼らはmaximize_というプレフィックスを削除し、徹底性に関する表現を和らげることでプロンプトを洗練させました。この調整された指示を適用したところ、Cursorチームは、GPT-5が内部知識に頼るべきか、外部ツールに手を伸ばすべきかについて、より良い決定を下すのを確認しました。不必要なツールの使用なく高いレベルの自律性を維持し、より効率的で関連性の高い振る舞いにつながりました。Cursorのテストでは、<[instruction]_spec> のような構造化されたXML仕様を使用することで、プロンプトにおける指示の遵守が向上し、プロンプト内の他の場所にある以前のカテゴリやセクションを明確に参照できるようになりました。
<context_understanding> ... ユーザーのクエリを部分的に満たす可能性のある編集を行ったが、自信がない場合は、ターンを終了する前に、より多くの情報を収集するか、より多くのツールを使用してください。自分で答えを見つけられる場合は、ユーザーに助けを求めないように偏向してください。 </context_understanding>
システムプロンプトが強力なデフォルトの基盤を提供しますが、ユーザープロンプトは依然として操作性を高めるための非常に効果的な手段です。GPT-5は直接的で明確な指示によく反応し、Cursorチームは、構造化され、スコープが限定されたプロンプトが最も信頼性の高い結果を生むことを一貫して確認しています。これには、verbosityの制御、主観的なコードスタイルの好み、およびエッジケースへの感度といった領域が含まれます。Cursorは、ユーザーが独自のカスタムCursorルールを設定できるようにすることが、GPT-5の改善された操作性と特に相乗効果を生み、ユーザーによりカスタマイズされた体験を提供することに大きな影響を与えていることを発見しました。
Optimizing intelligence and instruction-following (知能と指示遵守の最適化)
Steering (操作)
最も操作性の高いモデルとして、GPT-5 は verbosity、トーン、ツール呼び出しの振る舞いに関するプロンプトの指示を非常によく受け入れます。
verbosity
以前の推論モデルと同様に、reasoning_effortを制御できることに加え、GPT-5では verbosity という新しいAPIパラメーターを導入しました。これは、モデルの思考の長さではなく、最終的な回答の長さに影響を与えます。このパラメーターの背景にある考え方については、私たちのブログ記事でより詳しく解説していますが、このガイドでは、APIのverbosityパラメーターが展開のデフォルトである一方、GPT-5は、グローバルなデフォルトから逸脱させたい特定の文脈において、プロンプト内の自然言語による verbosity の上書きにも対応するように訓練されていることを強調したいと思います。上記のCursorの例で、全体的な verbosity を低く設定し、コーディングツールのみで高いverbosityを指定したのは、そのような文脈の代表的な例です。
Instruction following (指示の順守)
GPT-4.1と同様に、GPT-5はプロンプトの指示を手術的な精度で実行するため、あらゆる種類のワークフローに柔軟に対応できます。しかし、その慎重な指示遵守の振る舞いは、矛盾した指示や曖昧な指示を含む不適切に構築されたプロンプトが、他のモデルよりもGPT-5にとってより有害になる可能性があることを意味します。なぜなら、ランダムに一つの指示を選ぶのではなく、矛盾を解決する方法を探すために推論トークンを費やすからです。
このセクションの以降では、矛盾したプロンプト作んなよって話の長いサンプルだったので省略。
Minimal reasoning
GPT-5では、初めて minimal reasoning effort を導入しました。これは、推論モデルのパラダイムの利点を享受しつつ、最速のオプションです。レイテンシを重視するユーザーや、現在のGPT-4.1ユーザーにとって、これが最高のアップグレードになると考えています。 当然のことながら、最良の結果を得るためには、GPT-4.1と類似したプロンプトパターンを推奨します。最小推論のパフォーマンスは、より高い推論レベルよりもプロンプトによって大幅に変動する可能性があるため、強調すべき重要な点は以下の通りです。
- モデルに、最終的な回答の冒頭で思考プロセスを要約した簡潔な説明（例：箇条書きリスト）を促すと、より高い知性を要するタスクでのパフォーマンスが向上します。
- 徹底的で詳細なツール呼び出しの導入部を要求し、タスクの進捗状況を常にユーザーに更新させることで、エージェント的なワークフローでのパフォーマンスが向上します。
- ツールへの指示を可能な限り明確にし、上記で共有したようなエージェントの持続性に関するリマインダーを挿入することは、minimal reasoning において、長期にわたるロールアウトでのエージェント能力を最大化し、時期尚早の終了を防ぐために特に重要です。
- モデルは内部計画を行うための推論トークンが少ないため、プロンプトによる計画も同様に重要です。以下に、エージェントタスクの冒頭に配置した計画プロンプトの例を示します。特に2番目の段落は、エージェントがユーザーに戻る前にタスクとすべてのサブタスクを完全に完了することを保証します。
あなたはエージェントです。ユーザーのクエリが完全に解決されるまでタスクを続行し、その後、ターンを終了してユーザーに引き継いでください。ユーザーのクエリを必要なすべてのサブリクエストに分解し、それぞれが完了したことを確認してください。リクエストの一部のみを完了して停止しないでください。問題が解決したことを確信した場合にのみ、ターンを終了してください。複数のクエリに回答する準備をし、ユーザーが完了したことを確認した場合にのみ、通話を終了してください。 後続の関数呼び出しを行う前に、ワークフローのステップに従って広範な計画を立て、各関数呼び出しの結果について広範に振り返り、ユーザーのクエリおよび関連するサブリクエストが完全に解決されていることを確認する必要があります。
Markdown formatting
APIのGPT-5は、デフォルトでは最終的な回答をMarkdown形式で整形しません。これは、アプリケーションがMarkdownのレンダリングをサポートしていない可能性がある開発者との互換性を最大限に保つためです。しかし、以下のようなプロンプトは、階層的なMarkdown形式の最終的な回答を引き出すのに概ね成功しています。
- Use Markdown **only where semantically correct** (e.g., `inline code`, ```code fences```, lists, tables). - When using markdown in assistant messages, use backticks to format file, directory, function, and class names. Use \( and \) for inline math, \[ and \] for block math.
長時間の会話において、システムプロンプトで指定されたMarkdownの指示への準拠が徐々に低下することがあります。この問題が発生した場合、3〜5回のユーザーメッセージごとにMarkdownの指示を追記することで、一貫した準拠が見られています。
Metaprompting
最後に、メタな視点として、初期のテスターたちはGPT-5をそれ自体のメタプロンプターとして使うことで大きな成功を収めています。すでに、いくつかのユーザーは、GPT-5に「望ましい振る舞いを引き出すために、失敗したプロンプトにどのような要素を追加できるか」、あるいは「望ましくない振る舞いを防ぐために、どのような要素を削除できるか」を尋ねるだけで生成されたプロンプトの改訂版を本番環境にデプロイしています。 私たちが気に入ったメタプロンプトのテンプレート例を以下に示します。
プロンプトを最適化するよう求められた場合は、ご自身の視点から回答してください。このプロンプトにどのようなフレーズを追加または削除すれば、より一貫して望ましい行動を引き出すことができるか、あるいは望ましくない行動を防ぐことができるかを説明してください。 プロンプトの例：[PROMPT] このプロンプトでエージェントが期待する行動は、[望ましい行動] ですが、実際には [望ましくない行動] をとっています。既存のプロンプトを可能な限りそのまま維持しつつ、エージェントがこれらの欠点をより一貫して解決できるようにするために、どのような最小限の編集/追加を行うべきでしょうか？
Appendix
※ 以降は、サンプルのプロンプトが載ってましたがそれだけなので省略します。興味がありましたら原文をチェックしましょう。
