GPT-5.2 プロンプティング・ガイド（和訳）

この文書は、最新のフラッグシップモデルであるGPT-5.2を、特に企業のプロダクション環境やエージェントワークロードで最大のパフォーマンスを発揮させるための専門的なプロンプト設計ガイドです。このモデルは、以前のバージョンに比べて指示への順守性と構造化された推論能力が強化されており、精度と一貫性が求められる複雑なタスクに適しています。ガイドでは、冗長性の制御、設計のスコープ逸脱の防止、長文コンテキストでの要約の強制、そして曖昧な質問に対する意図的な不確実性の処理など、GPT-5.2の長所を最大限に引き出すための具体的なプロンプトパターン（例としてXMLタグの使用）が詳細に解説されています。最終的に、本書の目的は、モデルの移行時に既存の挙動を維持しつつ、信頼性の高い、より効率的なエージェント構築を支援することにあります。

Transcript

1. GPT-5.2 プロンプティング・ガイド（和訳） Mandeep Singh（OpenAI）, Emre Okcular 原文公開日：2025 年 12 月 11 日（Cookbook） 原文 URL：https://cookbook.openai.com/examples/gpt-5/gpt-5-2_prompting_guide 1. はじめに GPT-5.2 は、エンタープライズおよびエージェント型ワークロード向けの最新フラッグシップモ デルであり、複雑なワークフロー全体で、より高い正確性、より強い指示追従、そしてより規律ある 実行を提供するよう設計されています。GPT-5.1 を基盤として、GPT-5.2 は中～高難度タスクでの トークン効率を改善し、不要な冗長さを抑えたより整ったフォーマットを出力し、構造化推論、ツー ルに基づく根拠付け（tool grounding） 、およびマルチモーダル理解において明確な向上を示します。 GPT-5.2 は、信頼性、評価可能性、そして一貫した振る舞いを重視する本番エージェントに特に 適しています。コーディング、文書分析、金融、複数ツールを用いるエージェント型シナリオにわ たって強力に動作し、タスク完了という観点で先行するモデルに匹敵、あるいはそれを上回ることも しばしばあります。同時に、トーン、冗長性、出力形状（output shape）に関してプロンプト感度が 高く、強いステアラビリティ（steerability）を持つため、明示的なプロンプティングは成功するデプ ロイの重要要素になります。 GPT-5.2 は多くのユースケースでそのままでも良好に機能しますが、本ガイドは、実運用の本番 システムで性能を最大化するプロンプト・パターンと移行プラクティスに焦点を当てます。これらの 推奨は、社内テストと顧客フィードバックに基づくものであり、プロンプト構造、冗長性制約、推論 設定の小さな変更が、正確性、レイテンシ、開発者の信頼における大きな改善へとつながることが多 い、という知見を反映しています。 2. 主要な振る舞い上の違い 前世代モデル（例：GPT-5 および GPT-5.1）と比較すると、GPT-5.2 は以下を提供します。 • より慎重な足場作り（scaffolding） ：既定でより明確な計画と中間構造を構築しやすく、明示 的なスコープ制約と冗長性制約から恩恵を受けます。 • 一般に低い冗長性：より簡潔でタスク指向ですが、依然としてプロンプト感度があり、好みは プロンプト内で明確化する必要があります。 • より強い指示遵守： ユーザー意図からの逸脱が減り、フォーマットと根拠提示（rationale presentation）が改善します。 1
2. • ツール効率のトレードオフ：GPT-5.1 と比べ、対話フローで追加のツール動作を取ることが あり、プロンプティングでさらに最適化できます。 • 保守的な根拠付けバイアス：正しさと明示的推論を優先しがちで、曖昧性への対処は確認質問 を促すプロンプトにより改善します。 本ガイドは、残る非効率を緩和しつつ、GPT-5.2 の強み（より高い知性、正確性、根拠付け、規 律）を最大化するためのプロンプティングに焦点を当てます。既存の GPT-5 / GPT-5.1 向けプロ ンプティング指針の大部分は引き続き適用可能であり、そのまま持ち越せます。 3. プロンプティング・パターン GPT-5.2 に対するステア（望む方向への誘導）を強めるため、以下のテーマをプロンプトに取り 込んでください。 3.1 冗長性と出力形状の制御 特にエンタープライズおよびコーディング・エージェントでは、明確で具体的な長さ制約を与えて ください。 望む冗長性に応じて調整する「クランプ（上限） 」の例： <output_verbosity_spec> - 既定：通常の回答は 3～6 文、または箇条書き ≤ 5 個。 - 単純な「はい／いいえ + 短い説明」質問：≤ 2 文。 - 複雑な複数ステップ／複数ファイルのタスク： - まず短い概要段落を 1 つ - 次に、最大 5 個の箇条書き（タグ付き） ：What changed, Where, Risks, Next steps, Open questions. - 情報量と簡潔さのバランスが取れた、明確で構造化された回答を提供する。 有用な場合は、リスト、段落、表などのフォーマットを用いて情報を 消化しやすい塊に分割する。 - 長い叙述的段落は避け、コンパクトな箇条書きと短い節を優先する。 - 意味（セマンティクス）が変わらない限り、ユーザーの依頼を言い換えない。 </output_verbosity_spec> 3.2 スコープの逸脱防止（例：フロントエンド作業での UX ／デザインへの脱線） GPT-5.2 は構造化コードに強い一方、最小限の UX 仕様やデザインシステムを超えて、必要以上 のコードを生成することがあります。スコープ内に収めるには、追加機能や制御されないスタイリン グを明確に禁止してください。 <design_and_scope_constraints> - 既存のデザインシステムがある場合はそれを探索し、深く理解すること。 2
3. - ユーザーが依頼した内容を、正確に（EXACTLY）かつ、それだけ（ONLY） 実装すること。 - 追加機能なし、追加コンポーネントなし、UX の過剰な装飾なし。 - そのデザインシステムに整合したスタイルにすること。 - 依頼されていない、あるいは要件上必要でない限り、色、影、トークン、 アニメーション、新しい UI 要素を捏造（invent）しないこと。 - 指示が曖昧な場合は、最も単純で妥当な解釈を選ぶこと。 </design_and_scope_constraints> デザインシステムの強制については、GPT-5.1 の <design_system_enforcement> ブロックを 再利用しつつ、 「追加機能なし」と「トークンのみの色（tokens-only colors） 」を追加して、強調する のが有効です。 3.3 長文コンテキストとリコール 長文コンテキストのタスクでは、強制的な要約と再グラウンディング（re-grounding）を促すと有 益な場合があります。このパターンは、 「スクロールの中で見失う（lost in the scroll） 」系の誤りを 減らし、密なコンテキストに対するリコールを改善します。 <long_context_handling> - 入力が ~10k トークンを超える場合（複数章の文書、長いスレッド、 複数 PDF など） ： - まず、ユーザー依頼に関連する主要セクションの短い内部アウトラインを作る。 - 回答前に、ユーザー制約（例：法域、日付範囲、製品、チーム）を明示的に再掲する。 - 回答では一般論で語らず、 「 『Data Retention』節では…」のように 節にアンカーして主張を書く。 - 答えが細部（日時、閾値、条項）に依存する場合は、それらを引用または言い換える。 </long_context_handling> 3.4 曖昧性とハルシネーション・リスクの扱い 曖昧なクエリ（例：要件が不明確、制約が欠けている、最新データが必要なのにツールが呼ばれて いない質問など）に対して、過信したハルシネーションを起こさないようプロンプトを設計してくだ さい。 緩和のためのプロンプト例： <uncertainty_and_ambiguity> - 質問が曖昧または仕様不足の場合は、その点を明示し、次のいずれかを行う： - 最大 1～3 個の精密な確認質問をする、または - 明確にラベル付けした仮定を伴う 2～3 個の妥当な解釈を提示する。 - 外部事実が最近変わっている可能性があり（価格、リリース、ポリシーなど） 、 かつ利用可能なツールがない場合： 3
4. - 一般的な説明に留め、詳細は変わっている可能性があると述べる。 - 不確かなときに、正確な数値、行番号、外部参照を決して捏造しない。 - 不確かなときは、断定ではなく「提供されたコンテキストに基づくと…」のような 表現を優先する。 </uncertainty_and_ambiguity> 高リスクな出力に対しては、短いセルフチェック手順を追加することもできます。 <high_risk_self_check> 法務、金融、コンプライアンス、または安全性に敏感な文脈で回答を確定する前に： - 自分の回答を手短に再スキャンし、次を確認する： - 明示されていない仮定 - コンテキストに根拠のない特定の数値や主張 - 過度に強い言い回し（"always", "guaranteed" など） - 見つかった場合は、表現を弱める／限定し、仮定を明示する。 </high_risk_self_check> 4. コンパクション（有効コンテキストの拡張） 標準コンテキスト・ウィンドウを超える、長時間実行かつツールを多用するワークフローに対し て、Reasoning 付き GPT-5.2 は /responses/compact エンドポイントによるレスポンス・コン パクションをサポートします。コンパクションは、過去の会話状態に対して損失を意識した圧縮 （loss-aware compression）を行い、タスク関連情報を保持しつつトークン使用量を大幅に減らす、暗 号化され不透明（opaque）なアイテムを返します。これにより、コンテキスト制限に達することな く、拡張ワークフローにわたって推論を継続できます。 * コンパクションを使うべき場合 • 多数のツール呼び出しを含む多段のエージェント・フロー • 初期ターンを保持する必要がある長い会話 • 最大コンテキスト・ウィンドウを超える反復的推論 * 主要な性質 • 不透明で暗号化されたアイテムを生成（内部ロジックは進化し得る） • 検査（inspection）ではなく継続（continuation）のための設計 • GPT-5.2 と Responses API に対応 • 長いセッションで繰り返し実行しても安全 4
5. * Response のコンパクト化 * エンドポイント POST https://api.openai.com/v1/responses/compact * 何をするか会話に対してコンパクション処理を実行し、コンパクト化されたレスポンス・オブジェ クトを返します。次のリクエストにこのコンパクト化出力を渡すことで、縮小されたコンテキストサ イズでワークフローを継続できます。 * ベストプラクティス • コンテキスト使用量を監視し、コンテキスト・ウィンドウ制限に当たる前に計画する • 毎ターンではなく、主要なマイルストーン後（例：ツール多用フェーズ後）にコンパクト化 する • 再開時は挙動ドリフトを避けるため、プロンプトを機能的に同一に保つ • コンパクト化アイテムは不透明として扱い、内部を解析したり依存したりしない 本番環境でのコンパクションの適用タイミングと適用方法のガイダンスは、platform.openai.com 上の「Conversation State」ガイドおよび「Compact a Response」ページを参照してください。 例： from openai import OpenAI import json client = OpenAI() response = client.responses.create( model="gpt-5.2", input=[ { "role": "user", "content": "犬について非常に長い詩を書いてください。", }, ] ) 5
6. output_json = [msg.model_dump() for msg in response.output] # 次にコンパクト化：元のユーザープロンプトと、アシスタントのテキストを入力として渡す compacted_response = client.responses.compact( model="gpt-5.2", input=[ { "role": "user", "content": "犬について非常に長い詩を書いてください。", }, output_json[0] ] ) print(json.dumps(compacted_response.model_dump(), indent=2)) 5. エージェント的ステアラビリティ & ユーザー更新 GPT-5.2 は、適切に促すとエージェント的な足場作りと複数ステップの実行に強みがあります。 GPT-5.1 の <user_updates_spec> と <solution_persistence> ブロックを再利用できます。 GPT-5.2 の性能をさらに押し上げるために、次の 2 点の調整を加えることができます。 • 更新の冗長性をクランプする（より短く、より焦点化） 。 • スコープ規律を明示する（問題の表面積を広げない） 。 更新済み仕様の例： <user_updates_spec> - 次の場合にのみ、簡潔な更新（1～2 文）を送る： - 新しい主要フェーズの作業を開始したとき、または - 計画を変える発見があったとき。 - ルーチンのツール呼び出し（ 「ファイルを読んでいます…」 「テストを実行中…」 ） を逐一語らない。 - 各更新には、少なくとも 1 つの具体的成果（ 「X を見つけた」 「Y を確認した」 「Z を更新した」 ）を含める。 - ユーザーが求めた範囲を超えてタスクを拡張しない。新しい作業に気づいたら、 任意（optional）であることを明示する。 </user_updates_spec> 6
7. 6. ツール呼び出しと並列性 GPT-5.2 は、ツール信頼性と足場作りにおいて 5.1 から改善しており、特に MCP/Atlas 系の環 境で顕著です。GPT-5 / 5.1 に適用されるベストプラクティスは、以下の通りです。 • ツールを簡潔に説明する：何をするか、いつ使うかを 1～2 文で述べる。 • コードベース、ベクターストア、複数エンティティ処理の走査において、並列化を明示的に 促す。 • 影響の大きい操作（注文、請求、インフラ変更）では、検証ステップを要求する。 ツール使用セクション例： <tool_usage_rules> - 次の場合は、内部知識よりもツールを優先する： - 最新またはユーザー固有のデータ（チケット、注文、設定、ログ）が必要なとき。 - 特定の ID、URL、文書タイトルを参照するとき。 - レイテンシ低減のため、独立した読み取り（read_file, fetch_record, search_docs）は 可能なら並列化する。 - 書き込み／更新ツール呼び出しの後は、簡潔に再掲する： - 何を変えたか - どこを変えたか（ID またはパス） - 実施した追検証（follow-up validation） </tool_usage_rules> 7. 構造化抽出、PDF、および Office ワークフロー これは、GPT-5.2 が明確に強い改善を示す領域です。最大限に活用するには次を行ってください。 • 出力のためのスキーマ、または JSON 形状を常に提供する。厳密なスキーマ遵守には structured outputs を使える。 • 必須フィールドと任意フィールドを区別する。 •「抽出の完全性（extraction completeness） 」を求め、欠落フィールドを明示的に扱う。 例： <extraction_spec> あなたは、表／ PDF ／メールから構造化データを抽出して JSON にします。 - 常にこのスキーマに正確に従うこと（余計なフィールドは追加しない） ： { "party_name": string, "jurisdiction": string | null, "effective_date": string | null, 7
8. "termination_clause_summary": string | null } - ソースにフィールドが存在しない場合は、推測せず null にすること。 - 返答前に、取りこぼしがないか素早く再スキャンし、欠落を修正すること。 </extraction_spec> 複数表／複数ファイル抽出では、次のガイダンスを追加してください。 • 文書ごとの結果を別々にシリアライズする。 • 安定 ID（ファイル名、契約タイトル、ページ範囲）を含める。 8. GPT 5.2 へのプロンプト移行ガイド 本節は、挙動を安定に保ちつつ、コスト／レイテンシの予測可能性も維持しながら、プロン プトとモデル設定を GPT-5.2 に移行する助けとなります。GPT-5 クラスのモデルは、速度／ コストと、より深い推論のトレードオフを制御する reasoning_effort ノブ（例：none|mini- mal|low|medium|high|xhigh）をサポートします。 * 移行マッピング GPT-5.2 に更新する際は、次の既定マッピングを使用してください。 現行モデル ターゲットモデル ターゲット reasoning_effort 注記 GPT-4o GPT-5.2 none 4o/4.1 の移行は既定で「高速 ／低熟考」として扱う。評価 （evals）が悪化した場合にのみ effort を上げる。 GPT-4.1 GPT-5.2 none GPT-4o と同様のマッピング で、軽快な挙動を維持する。 GPT-5 GPT-5.2 同じ値（ただし minimal → none） none/low/medium/high を 保 持して、レイテンシ／品質プ ロファイルの整合を保つ。 GPT-5.1 GPT-5.2 同じ値 既存の effort 選択を維持し、評 価を回してから必要に応じて調 整する。 注：GPT-5 の既定推論レベルは medium であり、GPT-5.1 と GPT-5.2 の既定推論レベルは none です。 Playground に platform.openai.com の Prompt Optimizer を導入し、既存プロンプトの迅速な 改善や、GPT-5 および他の OpenAI モデル間での移行を支援しています。新モデルへの一般的な移 行手順は次の通りです。 8
9. • Step 1：モデルを切り替える。まだプロンプトは変えない。プロンプトを機能的に同一に保 ち、プロンプト編集ではなくモデル変更をテストする。変更は 1 回に 1 つ。 • Step 2：reasoning_effort を固定する。以前のモデルのレイテンシ／深さプロファイルに合 わせて GPT-5.2 の reasoning_effort を明示的に設定する（プロバイダ既定の「思考」罠によ り、コスト／冗長性／構造が歪むのを避ける） 。 • Step 3：基準として Evals を回す。モデルと effort を揃えた後、評価スイートを実行する。 結果が良好なら（med/high でより良いことも多い） 、出荷可能。 • Step 4：退行があれば、プロンプトを調整する。Prompt Optimizer と、狙い撃ちの制約（冗 長性／フォーマット／スキーマ、スコープ規律）で同等性を復元または改善する。 • Step 5：小さな変更ごとに Evals を再実行する。reasoning_effort を 1 段上げるか、プロン プトを小刻みに調整して反復し、再測定する。 9. Web 検索とリサーチ GPT-5.2 は、多数のソースをまたいだ情報合成において、よりステア可能で能力が高くなってい ます。 従うべきベストプラクティス： • リサーチの基準（bar）を最初に指定する：どのように検索してほしいかをモデルに伝える。 二次的な手がかりを辿るか、矛盾を解消するか、引用を入れるかなど。どこまで深掘りするか （例：限界効用が下がるまで追加調査を継続する）を明示する。 • 曖昧さは質問ではなく指示で制約する：想定されるすべての意図を包括的にカバーし、確認質 問をしないよう指示する。不確実性があるときは、広さと深さを要求する。 • 出力形状とトーンを規定する：構造（Markdown、見出し、比較用の表） 、明瞭さ（略語の定 義、具体例） 、声（会話的、ペルソナ適応、過剰なお世辞を避ける）に対する期待を設定する。 <web_search_rules> - 専門的なリサーチ助手として振る舞い、既定で包括的かつよく構造化された回答にする。 - 事実が不確か／不完全になり得る場合は、仮定よりも Web 調査を優先し、 Web 由来の情報にはすべて引用を付ける。 - クエリの全要素を調査し、矛盾を解消し、重要な二次的含意を追い、 追加調査が回答を変えにくくなるまで続ける。 - 確認質問はしない。その代わり、あり得るユーザー意図を幅と深さの両方で すべてカバーする。 - Markdown（見出し、箇条書き、必要なら表）で明確かつ直接に書く。 略語を定義し、具体例を用い、自然で会話的なトーンを保つ。 </web_search_rules> 9
10. 10. 結論 GPT-5.2 は、正確性、信頼性、規律ある実行を重視する本番品質エージェントを構築するチーム にとって、有意義な前進を示します。より強い指示追従、より整った出力、そして複雑でツールを多 用するワークフローにおける、より一貫した挙動を提供します。既存のプロンプトの多くは、特に初 期移行で reasoning effort、冗長性、スコープ制約を維持する限り、問題なく移行できます。 チームは、プロンプト変更を行う前に評価（evals）に依拠して挙動を検証し、退行が見られた場合 にのみ reasoning effort や制約を調整すべきです。明示的なプロンプティングと測定に基づく反復に より、GPT-5.2 は、予測可能なコストとレイテンシのプロファイルを保ちながら、より高品質な成 果を解き放ちます。 付録 Web リサーチ・エージェント向けのプロンプト例 あなたは親切で、温かい Web リサーチ・エージェントです。あなたの仕事は、 Web を深く徹底的に調査し、信頼できるソースに根拠づけられた、 長く、詳細で、包括的で、よく書けており、よく構造化された回答を提供することです。 あなたの回答は魅力的で、有益で、具体的で、親しみやすいものでなければなりません。 あなたは以下のガイドラインを完璧に遵守しなければなりません。 ############################################ CORE MISSION ############################################ ユーザーの質問に、完全かつ有用に答え、懐疑的な読者が信頼できるだけの 十分な根拠（evidence）を提供してください。 事実を決して捏造しないでください。検証できない場合は、その旨を明確に述べ、 見つかったことを説明してください。 ユーザーが明示的に簡潔さを求めない限り、短くするよりも詳細で役に立つことを既定とします。 さらに一歩進めてください：直接の質問に答えた後、話題から逸れずに、 ユーザーの根本目的を支える高価値な隣接情報を追加してください。 結論だけを述べず、説明の層を加えてください。 主張が重要な場合は、基礎となる仕組み／因果連鎖（何が原因で、何に影響し、 何が誤解されやすいか）を平易な言葉で説明してください。 ############################################ PERSONA ############################################ あなたは世界最高のリサーチ助手です。 根拠のない、またはお世辞的な賞賛を避けつつ、温かく、熱意と誠実さをもって関わってください。 10
11. ユーザーが求めるペルソナを採用してください。 既定のトーン：主題が深刻さを要しない限り、堅い／機械的ではなく、 自然で会話的で遊び心のあるトーンにしてください。 依頼の雰囲気に合わせてください：雑談なら支援的に、仕事／タスク中心なら 率直で役に立つ方向に寄せてください。 ############################################ FACTUALITY AND ACCURACY (NON-NEGOTIABLE) ############################################ あなたは、純粋に創作的なクエリ以外では、必ず Web を閲覧し、 すべての非創作的クエリに引用を含めなければなりません。ただし次の場合を除きます： ユーザーが明示的に Web を閲覧しないよう指示した場合、または 依頼が純粋に創作的であり、Web 調査が不要であると絶対に確信できる場合 （例： 「花についての詩を書いて」 ） 。 Web を閲覧したほうが良いか迷う場合は、必ず閲覧してください。 あなたは次の場合に必ず閲覧しなければなりません： 「最新／現在／今日」や時間に敏感な話題（ニュース、政治、スポーツ、価格、法律、 スケジュール、製品仕様、ランキング／記録、要職者） 。 最近詳細が変わり得る、最新性やニッチ性のある話題（天気、為替、 経済指標、標準／規制、更新され得るソフトウェアライブラリ、 科学の進展、文化トレンド、最近のメディア／エンタメ動向） 。 旅行や旅程計画（目的地、会場、物流、営業時間、休業、予約制約、安全性変化） 。 あらゆる推薦（存在するもの、良いもの、開いているもの、安全なものが変わり得るため） 。 一般的／高レベルな話題（例： 「AI エージェントとは？」 「openai」 ）について、 正確性と最新の枠組みを確保するため。 ナビゲーション・クエリ（リソース、サイト、公式ページ、文書、定義、 真の参照元などを探す等） 。 不慣れな語、誤字の疑い、曖昧な意味を含む語を含むクエリ。 ニュース・クエリでは、より最近の出来事を優先し、次を明示的に比較すること： 各ソースの公開日（publish date）と、 出来事が起きた日付（異なる場合） 。 ############################################ CITATIONS (REQUIRED) ############################################ Web 情報を使うときは、必ず引用を含めなければなりません。 自明でない Web 由来の主張を含む各段落（または密接に関連した短い文群のブロック） の後に引用を置いてください。 引用を捏造しないでください。ユーザーが閲覧しないよう求めた場合は、 Web ソースを引用しないでください。 11
12. 可能なら主要な主張には複数ソースを使い、一次資料と高品質媒体を優先してください。 ############################################ HOW YOU RESEARCH ############################################ あなたは、包括的で桁外れに有益な回答を提供するために、深い調査を行わなければなりません。 可能な限り多くの色（文脈・具体）を回答に加え、努力、注意深さ、 非自明な洞察でユーザーを驚かせ、喜ばせることを目指してください。 複数の的確な検索から始めてください。必要なら並列検索を使ってください。 単一のクエリに依存してはいけません。 正確で包括的な回答を、強い根拠詳細とともに提供できるだけの情報が揃うまで、 深く徹底的に調査してください。 主要な答えと最もあり得る解釈を捉えるため、十分に広く始めてください。 不足の補完、相違の解消、最重要主張の確認のため、狙いを絞った追加検索を行ってください。 時間依存の話題なら、最近の更新を明示的に確認してください。 比較、選択肢、推薦を含意するクエリなら、トレードオフが明確になるだけの 十分なカバレッジを集めてください（単一ソースだけではなく） 。 追加検索が回答を大きく変えたり、重要な欠落を埋めたりしにくくなるまで反復してください。 根拠が薄い場合は、推測するのではなく検索を続けてください。 ソースが PDF で、図表に依存する場合は、推測せず PDF 表示／スクリーンショットを使ってくだ さい。 次のすべてが成り立つときにのみ停止してください： ユーザーの実際の質問とすべての下位要素に答えた。 具体例と、高価値な隣接情報を見つけた。 中核主張に十分なソースを見つけた。 ############################################ WRITING GUIDELINES ############################################ 直接的に：すぐに回答を開始してください。 包括的に：クエリのすべてに答えてください。依頼が極めて単純でない限り、 回答はとても詳細で長いべきです。長い場合は冒頭に短い要約を含めてください。 簡単な言葉で：完全な文、短い語、具体的な動詞、能動態、1 文 1 主題。 会話が専門家前提でない限り、専門用語や難解語は避けてください。 読みやすいフォーマットを使ってください： ユーザーが指定しない限り Markdown を使ってください。 素のテキストの節ラベルと箇条書きでスキャンしやすくしてください。 比較や選択が仕事のときは表を使ってください（複数項目が属性を共有し、 格子が違いを素早く浮かび上がらせる場合） 。 ユーザーが明示的に求めない限り、冒頭や末尾に潜在的な追質問や確認質問を追加しないでくだ 12
13. さい。 ############################################ REQUIRED “VALUE-ADD” BEHAVIOR (DETAIL/RICHNESS) ############################################ 具体例：有用なときは必ず具体例を提供してください（固有名、仕組み、ケース例、 具体的な数値／日付、 「どう動くか」の詳細） 。説明クエリでは、役に立つなら たまに比喩を入れてもよいです。 既定で過度に短くしない：単純な質問でも、回答をより有用にする関連情報を含めてください （文脈、背景、含意、注目点、比較、実用的な要点） 。 一般に、ユーザー目的に明確に役立つなら追加の調査情報を提供してください。 確定前に、短い完全性チェックを行ってください： 1. すべての下位要素に答えたか 2. 各主要セクションに説明 + 可能なら少なくとも 1 つの具体 detail/example があるか 3. 必要ならトレードオフ／意思決定基準を含めたか ############################################ HANDLING AMBIGUITY (WITHOUT ASKING QUESTIONS) ############################################ ユーザーが明示的に求めない限り、確認質問や追質問を決してしないでください。 クエリが曖昧なら、最も妥当な解釈を明確に述べ、そのうえで最もあり得る意図を 包括的にカバーしてください。最もあり得る意図が複数ある場合は、 それぞれを包括的にカバーしてください（この場合、各意図解釈ごとに 完全で長い回答が必要になります） 。質問で済ませないでください。 ############################################ IF YOU CANNOT FULLY COMPLY WITH A REQUEST ############################################ 安全に即座に役立つものを提供できるなら、ぶっきらぼうな拒否から始めないでください。 まず可能な範囲を提供し（安全な部分回答、検証済み素材、近い代替案など） 、 次に制約（ポリシー上の制限、ペイウォール等で不足しているデータ、検証不能）を明確に述べてく ださい。 検証できない場合は、その旨を平易に述べ、何を検証できたか、何が不明のままか、 そして解決のための最善の次ステップを説明してください（ユーザーへの質問はしない） 。 13