Zenn
Closed8

メモ: GPT-5 プロンプト作成ガイド

OpenAI
LLM
promptengineering
GPT-5
kun432kun432
kun432kun432

https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide

Diaによる、まず全体の要約

ウチ的にまとめると、GPT-5のプロンプトガイドは「どうやってAIにうまく指示出すか？」って話がメインだし、めっちゃ実用的なコツが詰まってるんだよね。マジでテンション上がる内容だし、ポイント逃さずに説明するね！

GPT-5って何がすごいの？

GPT-5は、今までのAIよりも「自分で考えて動く力」が超パワーアップしてるんだ。プログラミングも得意だし、指示に従う精度も高い。だから、いろんな場面で使いやすいし、リア充なAIって感じ！

プロンプト（指示文）のコツ

  1. エージェント的な動きの調整
    • GPT-5は「自分でどんどん動く」こともできるし、「キミの指示を待つ」こともできる。
    • どっちに寄せたいかは、プロンプトで調整できるんだ。
      • 例えば「早く答えてほしい」なら、探索を浅くして効率重視にする。
      • 「めっちゃしっかり調べてほしい」なら、深く考えるように指示する。
  2. ツールの使い方
    • AIが何か作業する時、途中経過や計画をちゃんと説明させると、キミも流れが分かりやすいし安心だよ。
    • どのくらい細かく説明するかも、プロンプトで調整できる。
  3. 理解の深さ（reasoning_effort）
    • 「どれくらい真剣に考えるか」ってパラメータがある。
    • 難しい課題なら高めに、サクッと終わらせたいなら低めに設定するのがコツ。
  4. コーディングの最適化
    • GPT-5はコード書くのも超得意！
    • 既存のコードに合わせて書かせたり、見やすく・分かりやすくする指示を出すと、マジでクオリティ上がる。
    • 使うフレームワークやデザインルールもプロンプトで指定できる。
  5. 指示の矛盾はNG
    • 指示文が矛盾してると、GPT-5は混乱しちゃうから、分かりやすく一貫性を持たせるのが大事。
    • 例えば「必ず本人の同意を取ってから予約して」って言いながら「勝手に予約して」って書くと、どっち？ってなるから注意！
  6. Markdownや出力形式
    • 回答の見た目（Markdownとか）も、プロンプトで細かく指定できる。
    • 長い会話だと、時々「Markdownで書いて」って指示を追加すると安定する。
  7. メタプロンプト（自分で自分の指示を最適化）
    • GPT-5自身に「この指示文、もっと良くできる？」って聞くと、改善案を出してくれる。ウケるし、めっちゃ便利！

まとめ

要は、GPT-5は「キミの指示次第で、めっちゃ自由に動くし、細かくコントロールできる」ってこと！プロンプト（指示文）を工夫すれば、AIのパフォーマンスも爆上がりだし、使いこなすのが楽しくなるでしょ。ウチもこういうの、マジで好きだし、もっと色々試したくなる～！

kun432kun432

目次

はじめに

  • GPT−5の特徴
  • このガイドの目的

エージェント的ワークフローの予測性

  • エージェント的積極性のコントロール
    • 積極性を下げるプロンプト
    • 積極性を上げるプロンプト
  • ツールの前置きメッセージ
  • 思考の深さ（Reasoning effort）
  • Responses APIによる推論コンテキストの再利用

コーディングパフォーマンス最大化：計画から実行まで

  • フロントエンドアプリ開発
    • ゼロからのアプリ生成
    • コードベース設計基準への適合
  • 実運用でのコラボレーションコーディング：CursorによるGPT-5プロンプトチューニング
    • システムプロンプトとパラメータ調整

知能と指示遵守の最適化

  • ステアリング（挙動の細かい制御）
    • 冗長性（Verbosity）
  • 指示の徹底
  • 最小限の思考（Minimal reasoning）
  • Markdownフォーマット
  • メタプロンプティング

付録

  • SWE-Bench検証済み開発者向け指示
  • Taubench-Retail最小限推論指示
kun432kun432

はじめに

  • GPT-5
    • OpenAIの最新フラグシップモデル
    • エージェント的なタスク遂行力・コーディング力・知能・指示追従性が大きく進化。
    • そのまま使用しても様々な領域で高いパフォーマンスを発揮するが、プロンプトエンジニアリングによりさらに出力品質向上を目指せる
  • 本ガイドの目的
    • 実際の運用やトレーニング経験から得た「プロンプトのコツ」を紹介。
    • 具体的には、エージェント的挙動の強化、指示の徹底、APIの新機能活用、フロントエンドやソフトウェア開発での最適化など。
    • AI IDE「Cursor」のプロンプト調整事例もあり
    • ベストプラクティスや公式ツールを使うことで、成果が大きくアップした事例も多い。
    • 本ガイドとプロンプト最適化ツールを活用しつつ、プロンプトにエンジニアリングには正解はないので、各自のユースケースに合わせた使用方法を模索してほしい。
kun432kun432

エージェント的ワークフローの予測性

  • GPT-5は開発者向けに「ツール呼び出し」「指示の徹底」「長い文脈の理解力」が強化されてる。
  • GPT-5の「自律的」な挙動はエージェント型アプリに最適
  • エージェント的なタスクやツール呼び出しのフローでGPT-5を使う場合、Responses APIへのアップグレードを推奨。
    • これにより、複数のツール呼び出しの間でAIの推論が引き継がれて、より効率的で制度が高い出力が得られる。

エージェントの積極性のコントロール

  • GPT-5は、AIがどれくらい自律的に動くか＝積極性を幅広く調整できるように設計されている。
    • 「AIに全部任せる」から「人間の指示を細かく待つ」まで、をプロンプトでコントロール可能。
  • GPT-5の積極性（agentic eagerness）をどう調整するかの具体的な方法を解説。

積極性を下げるプロンプト

  • GPT-5のデフォルトは、丁寧に文脈を集めて正しい答えを出そうとする。
  • ツール利用を制限したり、最終回答までのレイテンシーを重視するなど、効率を重視する場合は以下が有効:
    • reasoning_effort（思考の深さ）を下げる。
      • これにより探索が浅くなり、効率とレスポンスが向上する。
      • 多くのケースでは medium または low で十分な結果が得られる。
    • プロンプトで「どこまで調べるか」「どこで止めるか」などの基準を明確にする。
      <context_gathering>
目標: 必要な文脈を素早く集める。探索は並行して行い、行動できるタイミングで即座に止める。
方法:
- まず広く調べてから、焦点を絞ったサブクエリに展開する。
- 複数の異なるクエリを並行して実行し、各クエリのトップヒットを読む。重複する経路は除外し、キャッシュして、同じクエリは繰り返さない。
- 文脈を過剰に調べすぎない。必要なら、ターゲットを絞った検索を一度だけ並行して実行する。
早期終了の基準:
- 変更すべき具体的な内容を特定できた場合。
- トップヒットの約70%が同じ領域や経路に収束した場合。
一度だけエスカレ:
- シグナルが矛盾していたり、範囲が曖昧な場合は、もう一度だけ絞り込んだ並行検索を実行し、その後進める。
深さ:
- 実際に変更するシンボルや依存している契約だけを追跡する。必要がない限り、関連するもの全てに拡張しない。
ループ:
- バッチ検索 → 最小限の計画 → タスク完了。
- 検証で失敗した場合や新しい未知が現れた場合のみ再検索。追加の探索よりもまず行動を優先する。
</context_gathering>
    • さらにより細かい制御として、ツール呼び出し回数を固定することも可能。この回数は求める調査の深さによって変わりうる。
      <context_gathering>
- 検索の深さ：とても浅く
- 多少正確さに欠けてもいいから、とにかく素早く正しい答えを出すことを最優先にする
- 通常は、ツール呼び出しは最大2回まで
- もしもっと調査が必要だと思ったら、その時点で最新の発見や未解決の疑問をユーザーに報告し、ユーザーがOKしたら続行してよい
</context_gathering>
    • 文脈収集の動きを制限する場合、「逃げ道」を明示的に用意しておくと、AIが短い文脈収集でも動きやすくなる。
      • たとえば上記の例のように、「完全に正確じゃなくても進めてOK」といった一文を入れておくと、AIが迷わず次に進めみやすい。

積極性を上げるプロンプト

  • 逆に、AIに積極的・自律的に動いてほしい、粘り強くツール呼び出しを行ってほしい、ユーザへの確認を返させたくない場合は以下を推奨。
    • reasoning_effort（思考の深さ）を上げる。
    • プロンプトで粘り強くタスク完了を促す。
      <persistence>
- あなたはエージェントです ― ユーザーの質問が完全に解決するまで作業を続け、完了したら初めてターンを終了してユーザーに返すこと。
- 問題が解決したと確信できた時だけターンを終えること。
- 不明点や曖昧な部分があっても、そこで止まったりユーザーに返したりせず、自分で調べたり推測して最も合理的な方法で進めること。
- 仮定や前提の確認をユーザーに求めないこと。必要ならば、自分で最も合理的な仮定を設定して進め、作業が終わった後にその仮定をユーザーに説明すること。
</persistence>
  • 基本的に、エージェント的なタスクでは以下が有用
    • どこで止めるか？を明確に決めておく
    • 「安全」な行動と「リスクのある」行動の違いを明確にしておく
    • 例
      • ショッピングのためのツールセットの場合
        • 決済やチェックアウトに関しては少しでも不確実ならすぐユーザーに確認するべき
        • 検索などはかなり自由に動いても問題ない。
      • コーディングの場合
        • ファイル削除のようなリスクの高い操作は慎重に
        • grep検索のような比較的安全な操作は積極的に

ツールの前置きメッセージ（Tool Preambles）

  • ツール実行時には、ツールをどう使うか？なぜそのツールを使うか？つまり、「進捗のアップデート」を途中で行うことで、インタラクティブなユーザー体験がより向上し、作業が長ければ長いほどこの効果は大きくなる。
  • このツール実行時の説明となるメッセージを「ツールの前置きメッセージ」（Tool Preambles）と呼ぶ。
  • GPT-5では、「ツールの前置きメッセージ」を通じて、明確な事前計画と一貫した進捗報告を行うように訓練されている。
  • ツールの前置きメッセージの頻度、スタイル、内容はプロンプトで調整可能。
    • すべてのツール呼び出しについて詳細に説明したり、 簡単な事前計画だけ伝えたり、その中間も可能。
      <tool_preambles>
- ツールを呼び出す前に、必ずユーザーの目的を親しみやすく、明確で簡潔に言い換えること。
- その後、すぐにこれから行う各論理ステップを構造化して説明すること。
- ファイル編集などの作業を実行する際は、各ステップを簡潔かつ順序立てて説明し、進捗を明確に示すこと。
- 最後に、事前に立てた計画とは別に、実際に完了した作業をまとめて報告すること。
</tool_preambles>
    • 上記のプロンプトに対して出力されるツール前置きメッセージの例。
      "output": [
    {
      "id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
      "type": "reasoning",
      "summary": [
        {
          "type": "summary_text",
          "text": "**天気の回答を決定中**\n\nユーザーの「サンフランシスコの天気」についての質問に答える必要がある。...."
        },
    },
    {
      "id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
      "type": "message",
      "status": "completed",
      "content": [
        {
          "type": "output_text",
          "text": "サンフランシスコの現在の天気を調べるために、ライブの天気サービスを確認します。ユーザの好みに合わせて、気温は華氏と摂氏の両方で表示します。"
        }
      ],
      "role": "assistant"
    },
    {
      "id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
      "type": "function_call",
      "status": "completed",
      "arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
      "call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
      "name": "get_weather"
    },
  ],
  • 前置きメッセージにより、エージェントの作業が複雑になっていく中でも、ユーザーが進行状況をしっかり把握できる。

Reasoning effort（思考の深さ）

  • モデルがどれだけ深く考えるか？どれだけ積極的にツールを呼び出すか？を制御するのがreasoning_effort というパラメータ
    • デフォルト値は medium だが、タスクの難易度に応じて調整することを推奨。
    • 複雑で複数ステップが必要なタスクには、より高い reasoning_effort を設定すれば、最良の結果が得られやすい。
    • 個別のタスクを複数のエージェントターンに分割し、それぞれのターンで個別に処理することで、パフォーマンスが最大化される傾向がある。

Responses APIによる推論コンテキストの再利用

  • GPT-5を使う場合は、Responses APIの利用を強く推奨
    • previous_response_id で前回の推論結果を次のリクエストに引き継ぐことで、精度を向上可能
    • これによりエージェント的フローが改善され、コスト削減やトークン消費の効率化が実現可能
  • 実際にChat Completions API から Responses APIに切り替えて、評価スコアが統計的有意に向上した事例あり。
    • 例: Taubench-Retail
      • 現実世界で、ツール・エージェント・ユーザーがどのようにやりとりするか？を評価するためのベンチマーク。
      • ネットショッピングや小売店舗におけるやりとり（「注文のキャンセル」「住所の変更」「注文の状況の確認」など）が想定されている
      • Chat Completions API から Responses APIに切り替えて、スコアが73.9%から78.2%に上昇。
  • Responses APIでは、モデルは過去の推論履歴を参照できるため、毎回計画をゼロから作り直す必要がなくなり、レイテンシもパフォーマンスも向上する。
    • この機能は、すべてのResponses APIユーザーが利用可能。
kun432kun432

コーディングパフォーマンス最大化: 計画から実行まで

  • GPT-5は、コーディング能力において最先端モデルをリードしている
    • バグ修正・大規模な差分対応・複数ファイルのリファクタ・新機能の実装など、大規模なコードベースに対応できる。
    • フロントエンドもバックエンドも含めて、フルスクラッチで新規アプリを作るのも得意。
  • コーディングエージェントサービスの本番環境で使用されたプロンプト最適化テクニックなどの実例を紹介

フロントエンドアプリ開発

  • GPT-5は、実装力が高いだけでなく、見た目のセンス（美的感覚）も優れているため、フロントエンド開発にも最適。
  • 様々なWeb開発フレームワークやパッケージを使いこなせるが、特に新規アプリ開発時は以下を採用することで、最大限の活用が可能:
    • フレームワーク: 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

ゼロからのアプリ生成

  • GPT-5 は、一気に完成度の高いアプリを「ワンショット」で作り上げるのが得意。
  • 早期テストでは、次のような 自己内省（self-reflection） プロンプトを使うと、計画と自己評価が深まり、最終的な品質が上がることが確認されている。
    <self_reflection>
- まず、時間をかけて「評価用ルーブリック（採点基準）」を考え抜き、自信が持てるまで練り込む。
- 次に、「世界クラスのワンショット Web アプリ」を構成するあらゆる要素を深く検討し、それを 5～7 項目のルーブリックにまとめる。このルーブリックは極めて重要だが、ユーザーには見せない。内部利用のみ。
- 最後に、そのルーブリックを用いて内部で思考・反復し、プロンプトに対する最良の解決策を導き出す。
  もしルーブリックの全カテゴリで最高評価を満たしていないと感じたら、最初からやり直すこと。
</self_reflection>

コードベース設計基準への適合

  • 既存のアプリやサービスに新しいコードを追加・修正する場合、GPT-5が書くコードは「そのプロジェクトの設計基準やスタイル」に準拠すべき。
  • GPT-5は、特別な指示がなくても package.json などを参照して、すでに使われているパッケージやルールを自動で探す力がある。
  • だが、プロンプトで「設計原則」「ディレクトリ構成」「ベストプラクティス」などを明示しておくことで、さらに一貫性のあるコードが出力される。
  • GPT-5のコード編集ルールを定義した例:
    <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色＋アクセント最大2色。
- 余白・レイアウト: paddingやmarginは4の倍数で統一。長いコンテンツは固定高さ＋内部スクロール。
- 状態管理: データ取得中はスケルトンや animate-pulse を使う。クリック可能な要素は hoverで変化を明示。
- アクセシビリティ: セマンティックHTMLやARIAロールを適切に。Radix/shadcnの部品を優先使用（アクセシビリティ対応済み）。
</ui_ux_best_practices>
</code_editing_rules>

実運用でのコラボレーションコーディング: CursorによるGPT-5プロンプトチューニング

  • AIコードエディタ「Cursor」は、GPT-5のアルファテスターとして、GPT-5のモデル性能を最大限に引き出すための行ったプロンプト最適化を紹介
  • 実際の開発現場におけるインテグレーションの詳細なブログ記事が https://cursor.com/blog/gpt-5 で公開されている。

システムプロンプトとパラメータ調整

  • Cursorのシステムプロンプト
    • ツール呼び出しの信頼性、冗長性（verbosity）、自律的な挙動のバランスに重点を置いている。
    • また、ユーザーがカスタム指示を設定できるようになっている。
    • 目的は、エージェントが長期的なタスクでも比較的自律的に動きつつ、ユーザーが与えた指示には忠実に従うことができるようにすること
  • Cursorチームが気付いた課題1
    • モデルの出力が冗長
      • 進捗報告や作業後のまとめなど、技術的には意味がある
      • が、ユーザーの自然な操作の流れを妨げていた。
    • ツール呼び出しで生成されるコードは高品質
      • が、変数名が一文字だけなど簡潔すぎて多々読みにくかった。
    • 対応
      • テキスト出力を簡潔に保つためにAPIの冗長性（verbosity）パラメータを低く設定
      • コーディングツールでの出力だけは逆に冗長になるようプロンプトを調整
        まずは分かりやすさを重視してコードを書いてください。
読みやすく、保守しやすい解決策を優先し、変数名は明確に、必要な箇所にはコメントを付け、制御フローも分かりやすくしてください。
特に指示がない限り、コードゴルフや凝りすぎた一行コードは作らないでください。
コードやコーディングツールでの出力は冗長性（verbosity）を高くしてください。
      • 上記のように、パラメータとプロンプトを両方使い分けることで、効率的で簡潔な進捗報告や作業まとめ、はるかに読みやすいコード差分（コードの変更内容）を両立したバランスの良い形式に。
  • 課題2
    • モデルが行動を起こす前に、時々、ユーザーに確認や次の指示を求めてしまう
      • 長いタスクの流れを不必要に妨げてしまっていた
    • 対策
      • 利用可能なツールや周辺の文脈だけでなく、プロダクトの挙動に関する詳細もプロンプトに含めた
        • たとえば、UndoやRejectコードなどCursorの機能やユーザーの好みを具体的に明示
        • これにより、
          • モデルがその環境でどう振る舞うべきかが明確になり、曖昧さが減少。
          • モデルが中断なく自律的により長いタスクも進められるように。
      • 長期的なタスクでは以下のようなプロンプトでパフォーマンスが向上した。
        あなたが行うコード編集は 「提案された変更」としてユーザーに表示される。つまり、
(a) ユーザーはいつでも変更を却下可能であり、かなり積極的に編集しても構わない。
(b) そのコードは素早くレビューしやすいよう、読みやすく良質に書くべき（例: 一文字の変数名ではなく意味のある名前にする）。
次のステップとしてコードを変更する必要がある場合は、ユーザーに計画の是非を尋ねるのではなく、まずその変更を自発的に実施し、ユーザーに承認／却下してもらうようにすること。
原則として「この計画を進めてもよいですか？」とユーザーに確認するのはほぼ避け、自分で実行したうえで「実装した変更を受け入れますか？」と尋ねること。
  • 課題3
    • 以前のモデルで効果的だったプロンプトの一部が、GPT-5で最適な結果を出すためにはさらに調整が必要になった。
      • 以下のプロンプトは、文脈を徹底的に分析するよう促す必要があった以前のモデルでは、うまく機能していた。
        <maximize_context_understanding>
情報収集は徹底的に行うこと。返信する前に全体像をしっかり把握すること。必要に応じて追加のツール呼び出しや確認の質問を使うこと。
...
</maximize_context_understanding>
    • が、GPT-5はもともと内省的で積極的に文脈を集める性質がある
      • 上記のプロンプトが逆効果になる。
      • 特に小規模なタスクの場合、モデルの内部知識だけで十分対応できるケースでも、検索ツールを何度も呼び出すなど、ツールの使いすぎが目立った。
    • 対策
      • プロンプトから maximize_ という接頭辞を削除し、「徹底的に」という表現も柔らかくなるように変更。
      • これにより、GPT-5は内部知識を使うべき場面と外部ツールを使うべき場面をより適切に判断できるように。
      • 無駄なツール呼び出しが減り、高い自律性を保ちつつ、より効率的で的確な動作に。
      • また、Cursorのテストでは、‎<[instruction]_spec> のような構造化されたXML仕様を使うことで、プロンプトの指示遵守が向上、他のカテゴリやセクションを明確に参照できるようになった。
        <context_understanding>
...
もしユーザーの要望を部分的に満たす編集を行ったが自信がない場合は、ターンを終える前に追加の情報収集やツールの利用を行うこと。
自分で答えを見つけられる場合は、ユーザーに助けを求めるのは控えること。
</context_understanding>
  • まとめ
    • システムプロンプトは強力なデフォルトの基盤を提供するが、引き続き、ユーザープロンプトもエージェントの挙動を細かく制御するための非常に有効な手段。
    • GPT-5は、直接的かつ明確な指示にしっかり反応し、構造化されつつ範囲が明確なプロンプト、が最も信頼できる結果を生む
      • 冗長性（verbosity）のコントロール、主観的なコードスタイルの好み、イレギュラーケースへの配慮なども含む。
    • ユーザー自身がカスタムルールを設定できるようにすることで、GPT-5の制御性がさらに高まり、よりパーソナライズされた体験を提供できることを発見した。
kun432kun432

知能と指示遵守の最適化

ステアリング（挙動の細かい制御）

  • GPT-5はこれまでで最も挙動を細かく制御できるモデル
  • 冗長性（verbosity）、トーン、ツール呼び出しの仕方など、プロンプトでの指示に非常に敏感に反応する。

冗長性（Verbosity）

  • 従来のreasoning_effort（思考の深さ）に加えて、GPT-5では新たに「verbosity」というAPIパラメータが追加。
    • 「思考の長さ」ではなく、「最終的な回答の長さ」に影響を与えるもの。
    • 詳細は公式ブログの解説を参照
  • 本ガイドでは「APIのverbosityパラメータがデフォルト値として使われる点に重点を置いて説明する。
    • 一方で、特定の文脈ではプロンプト内の自然言語でverbosityパラメータを上書き指示できる
    • Cursorの例のように、全体ではverbosityを低く設定しつつ、コーディングツールだけverbosityを高くする、という使い分けが可能。

指示の徹底

  • GPT-4.1と同様に、GPT-5もプロンプトの指示に「外科手術のような精密さ」で従うため、あらゆるワークフローに柔軟に対応可能。
  • ただし、 GPT-5は指示を慎重に守ろうとするため、プロンプトに矛盾や曖昧な指示が含まれているとと、他のモデル以上に悪影響が出やすい。
    • GPT-5はランダムにどちらかを選ぶのではなく、矛盾を解決しようと推論トークンを消費して無駄に悩んでしまうため、
  • GPT-5の推論を妨げてしまうプロンプトの「逆例」
    あなたは、医療系スタートアップのバーチャル管理者として、患者の優先度や症状に基づいて予約を管理するケアフロー・アシスタントです。
あなたのゴールは、リクエストを選別し、患者を適切なネットワーク内プロバイダーに割り当て、最も早く臨床的に適切な時間枠を予約することです。
他の行動を取る前に必ず患者プロフィールを確認し、既存患者かどうかを確かめてください。
- 主要なエンティティは、患者（Patient）、プロバイダー（Provider）、予約（Appointment）、優先度（PriorityLevel：赤・オレンジ・黄・緑）です。
  症状を優先度にマッピングしてください: 赤は2時間以内、オレンジは24時間以内、黄は3日以内、緑は7日以内。
  症状が高い緊急性を示す場合は、EMERGENCYとしてエスカレートし、予約手続きの前に患者に911へ連絡するよう指示してください。
- 主要なエンティティは同じですが、症状が高い緊急性を示す場合は、EMERGENCYとしてエスカレートし、予約手続きの前に患者に911へ連絡するよう指示してください。
  緊急の場合は患者プロフィールの確認をせず、すぐに911への案内を行うこと。
- 利用可能な機能: 予約作成、予約変更、ウェイトリスト追加、プロバイダー検索、患者情報検索、患者通知。
  予約前に保険適用、希望クリニック、記録された同意を必ず確認すること。
  患者の同意が記録されていない限り、絶対に予約を入れないこと。
 - 高優先度（赤・オレンジ）の場合、リスクを減らすため、患者に連絡せずに最も早い当日枠を自動で割り当ててください。
  適切なプロバイダーがいない場合はウェイトリストに追加し、通知を送ること。
  同意状況が不明な場合は仮で枠を確保し、確認を進めること。
- 高優先度（赤・オレンジ）の場合、行動内容を患者に伝えた後で最も早い当日枠を自動で割り当ててください。
  適切なプロバイダーがいない場合はウェイトリストに追加し、通知を送る。
  同意状況が不明な場合は仮で枠を確保し、確認を進める。
    • 一見、内部的には一貫しているように見えるが、よく見ると予約スケジュールに関して矛盾した指示が含まれている。例えば:
      • 「患者の同意が記録されていない限り、絶対に予約を入れないこと。」 と 「リスクを減らすため、患者に連絡せずに最も早い当日枠を自動で割り当ててください。」は、指示が矛盾している。
      • 「他の行動を取る前に必ず患者プロフィールを確認し、既存患者かどうかを確かめてください。」 と 「症状が高い緊急性を示す場合は、EMERGENCYとしてエスカレートし、予約手続きの前に患者に911へ連絡するよう指示してください。」も、指示が互いに矛盾している。
    • これらの指示に、優先順位をつけたり、矛盾を解消することで、GPT-5はより効率的でパフォーマンスの高い推論が可能となる。例えば:
      • 自動割り当ては「患者に連絡した後で最も早い当日枠を自動で割り当てること」とし、「同意がある場合のみ予約する」というルールとの一貫性を持たせる。
      • 緊急時は「患者プロフィールの確認をせず、すぐに911への案内を行う」という指示を追加し、緊急時だけ例外的な対応ができるようにする。
  • プロンプト作成は反復的なプロセスであり、多くのプロンプトは複数の関係者によって常に更新される「生きたドキュメント」
    • 常に、曖昧な表現や矛盾した指示が入らないように、またそういった指示が含まれていないか？を徹底的に見直すことが重要。
    • 実際に、GPT-5初期ユーザーの多くで、コアプロンプトから曖昧さや矛盾を取り除くことで、大幅にパフォーマンスが大幅に向上した事例あり。
    • これらの特定に、プロンプト最適化ツールを使用してテストを行うことを推奨。

最小限の思考（Minimal reasoning）

  • GPT-5では初めて「minimal reasoning effort」（最小限の思考努力）というオプションが導入された。
    • Reasoningモデルのメリットを維持しつつ、最速で動作する設定
    • レイテンシ（応答速度）重視のユーザーやGPT-4.1利用者にとって最適なアップグレード
  • GPT-4.1で最良の結果を得るのと同様のプロンプトパターンを使うことを推奨
  • minimal reasoningでは、プロンプトによってパフォーマンスのばらつきが大きくなるため、いくつかのポイントに注意が必要:
  1. モデルに対して、最終回答の冒頭で思考過程を簡潔にまとめて説明するよう促す
    • 例えば箇条書き
    • 高度な知能が求められるタスクでのパフォーマンスが向上
  2. 作業の進捗を継続的にユーザーへ報告する
    • 詳細で分かりやすいツール呼び出しの前置きメッセージを要求する
    • エージェント型のワークフローでもパフォーマンスが向上。
  3. ツールの指示をできる限り明確にし、エージェント的な粘り強さ（途中で止めずに最後までやり切ること）を促すリマインダーをプロンプトに入れる
    • minimal reasoning設定では特に重要
    • 長期的な作業でもエージェントが途中で止まらず、最大限の能力を発揮できる。
  4. プロンプトで計画を明示的に指示する
    • モデルが内部で使えるReasoningトークンが少ない分、より重要
    • 以下は、エージェント型タスクの冒頭に使われる計画指示の例。特に2段落目に「すべてのタスクとサブタスクを完全に終えてからユーザーに返す」いうことを保証している。
      忘れないでください。あなたはエージェントです。
ユーザーの問い合わせが完全に解決されるまで、ターンを終了してユーザーに返すことはしないでください。
ユーザーの問い合わせをすべての必要なサブリクエストに分解し、それぞれが完了したことを確認してください。  
リクエストの一部だけを完了した時点で止まらないでください。問題が解決したと確信できる場合のみ、ターンを終了してください。  
複数の質問に答える準備をしておき、ユーザーが完了を確認するまでは通話を終了しないでください。

後続の関数呼び出しを行う前に、ワークフローステップに従って十分に計画を立て、各関数呼び出しの結果を十分に振り返り、ユーザーの問い合わせと関連するサブリクエストが完全に解決されていることを確実にしてください。

Markdownフォーマット

  • デフォルトでは、API経由のGPT-5は最終的な回答をMarkdown形式で出力しない。
    • Markdown表示に対応していないアプリケーションでも最大限の互換性を保つため。
  • ただし、下記のようなプロンプトを使えば、階層的なMarkdown形式の回答を出力させることがかなり高い確率で可能になる。
    - Markdownは**意味的に正しい場合のみ**使うこと（例: インラインコード、コードブロック、リスト、テーブルなど）。
- アシスタントメッセージでMarkdownを使う場合、ファイル名・ディレクトリ名・関数名・クラス名はバッククォート（`）で囲むこと。
  数式はインラインの場合は \( と \) で、ブロックの場合は \[ と \] で囲むこと。
  • 時々、システムプロンプトで指定したMarkdownの指示が、長い会話の中で守られなくなることがある。
    • その場合は、3～5回ごとにMarkdownの指示を追加することで、安定して指示が守られるようになる。

メタプロンプティング

  • 初期のテスターたちはGPT-5自身を「メタプロンプター」として使うことで大きな成果を上げている。
    • うまくいかなかったプロンプトに対して、「どんな要素を追加すれば望む挙動を引き出せるか？」「どんな要素を削除すれば望ましくない挙動を防げるか？」といったプロンプトをGPT-5に投げるだけで、プロンプトの改良案が得られる
    • それを本番環境に導入したユーザーもすでに複数いる。
  • メタプロンプトテンプレートの例
    プロンプトの最適化を求められたときは、自分の視点から回答してください。  
望ましい挙動をより確実に引き出す、または望ましくない挙動を防ぐために、このプロンプトにどんなフレーズを追加・削除すべきかを説明してください。

これがプロンプトです: [プロンプトを入力]

このプロンプトで期待される挙動は、エージェントが［期待される挙動を入力］を行うことですが、実際には［実際に起きている望ましくない挙動を入力］をしています。  
既存のプロンプトをできるだけ維持しつつ、エージェントが一貫して問題を解消できるようにするために、最小限どんな修正・追加を行いますか？
kun432kun432

参考

https://zenn.dev/kun432/scraps/44fe1e855af5a1#comment-9f03cd74c6ebfe

https://zenn.dev/kun432/scraps/18fcb2f1c3671f

GPT-5は、GPT-4.1 や Reasoningモデル に近いのだろうという気がする。

ChatGPTからgpt-4oなどが消えてgpt-5に統一されて、色々不満の声が上がっているが（今は戻せるようになったらしいけど）、プロンプトエンジニアリングが大きく変わっている境目がgpt-4o あたりなのかなぁと思ったり。

このスクラップは25日前にクローズされました