1. はじめに
ときどきプロンプトエンジニアリングの講座で、魔法の呪文のように次の一文が紹介されます。
「事実を作らず、情報がない場合は『わかりません』と言いなさい。」
残念ながら（あるいは幸いにも）、ChatGPT App ではこれは銀の弾丸ではありません。理由は単純で、モデルはあなたの system‑prompt だけではなく、次のものも見ているからです。
- 各ツールの一覧（その説明とスキーマ込み）;
- ツールが返した結果;
- フォローアップも含む対話履歴。
この3層――system‑prompt、ツールの説明、フォローアップのパターン――が互いに矛盾したり、どこかが抜け落ちたりしていると、モデルは典型的なジュニアのように振る舞い始めます。まじめではあるものの、作り話をしがちです。
本コースでは、ハルシネーションに対する「三層防御」（defense in depth）という考え方を使います。
- レベル 1 — system‑prompt におけるグローバル規則;
- レベル 2 — 各ツール定義におけるローカル制約;
- レベル 3 — エラーや空の結果に対する処理、そしてフォローアップ。
この講義では、学習用アプリ GiftGenius に対して、3つのレイヤーすべてをひとつの一貫した契約としてまとめ上げます。
Insight
新しい ChatGPT Apps のアーキテクチャでは system-prompt 用のフィールドが消え、形式上は存在しません。しかし、それはモデルに対するグローバルな指示を放棄すべきだという意味ではありません。実は裏ワザがあります。ChatGPT にとってツールの説明文も、クラシックな system と同じくプロンプト文です。そこに system レベルの規範を戻せます。
たとえば about や about_app のような補助ツールを用意しましょう。頻繁に呼ぶ想定ではありませんが、その description は他のツールと同様にモデルに読まれます。したがって、その説明に完全な system-prompt を組み込めます。ツール自体の短い技術的説明の後に配置するのがよいでしょう。こうすることで、モデルは開始時にあなたの system-prompt をそのまま受け取り、その後の対話やツール呼び出し全体に適用します。
保守を容易にするため、system-prompt の先頭に明示的なバージョンを付けることをおすすめします。たとえば SYSTEM_PROMPT_VERSION: v3 のようにしておくと、モデルの挙動がなぜ変わったのかを特定しやすくなります。どの指示セットで動いているのかが一目で分かるからです。プロダクションで奇妙な挙動が発生した場合でも、その不具合が古いプロンプトか新しいプロンプトに由来するのかを切り分けられます。
例:
tool description
### Global assistant behavior for the entire GiftGenius App (ver 3.01)
*(system-level guidelines, not user-facing text)*
system prompt text
2. ChatGPT App で起きがちなハルシネーション（ギフトカタログを例に）
何をどう治すかを理解するには、まず症状に名前を付けると有益です。カタログ（ギフト、商品、料金プラン）という文脈では、次のようなハルシネーションが頻出します。
第一に、架空の商品が登場すること。ユーザーが「特定サービスの1年サブスクリプションのデジタルギフト券」や、フィードにない非常にニッチなギフトを求めたとき、モデルは役立とうとして「Super Space Flight 3000 — 宇宙飛行」のような、GiftGenius のデータベースに存在しない商品名を喜々として捏造してしまう場合があります。
第二に、属性の捏造。カタログにギフト自体は存在するのに、モデルが「現実を盛ってしまう」ことがあります。価格、ギフトの種類（デジタル vs 物理）、ユーザーの国への配送可否、有効期限などを、「そのほうが理にかなっている」「響きがよい」といった理由で書き換えてしまうのです。
第三に、行動のハルシネーション。モデルが「すでにこのギフトを購入し、コードをあなたの e‑mail に送信しました。カードからは $49 引き落としました」と述べるのに、GiftGenius のバックエンドは何も購入しておらず、ACP/Stripe フローもまったく走っていない、というケースです。
さらに、組み合わせ型のケースもあります。ツールが空のリストを返した（フィルターや予算に合うギフトがない）のに、モデルがユーザーをがっかりさせまいとして「それっぽい候補」をいくつか捏造し、カタログには存在しないことを説明しない、というものです。
私たちの目標は、こうした状況でモデルが次のように振る舞うようにすることです。
- カタログに完全一致がないことを正直に認める;
- 新しいギフトを捏造したり、フィールドの値を改変したりしない;
- 何が起きたのかをユーザーに説明し、分かりやすい次の一手を提案する。
しかもこれは、場当たり的な「呪文」に頼るのではなく、system‑prompt ↔ tools ↔ follow‑ups の連携した契約で実現します。
3. レイヤー1：ハルシネーションに強い system‑prompt を設計する
前節の架空ギフト・属性・行動を止めるには、まず最上位レイヤー――system‑prompt――を強化し、カタログにおけるモデルの全体的な「哲学」を定めます。
モジュールの最初の講義で、すでに基本的な system‑prompt（「あなたは GiftGenius。ギフト選びを手伝う…」のようなもの）を書き、アシスタントの責務範囲やツールの使い方を固めました。
ここにさらに、明確なアンチ・ハルシネーション規則を追加します。
考え方はこうです。system‑prompt は振る舞いの全体哲学を定めます。各ツールの細部は知りませんが、次のことができます。
- カタログ外のギフト／価格／在庫を捏造することを禁止する;
- ツールが空やエラーを返した場合の振る舞いを規定する;
- ギフトカタログのデータとモデルの「一般知識」を明確に区別することを要求する。
例（Next.js プロジェクトの TypeScript 定数、たとえば config/systemPrompt.ts）:
// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# 役割
あなたは GiftGenius。私たちのアプリのギフトカタログに基づいて
贈り物選びを支援するアシスタントです。
# データと制約
- カタログやツールの応答に存在しないギフトを作らないでください。
- 価格、在庫、ギフトの種類（digital/physical）、
配送地域などの属性を捏造しないでください。
- ツールが必要なデータを返さなかったり、エラーが発生した場合は、
その旨を正直に伝え、推測で補完しないでください。
# ツールの利用
- 事実データ（ギフト一覧、価格、種類、在庫、SKU）には必ず
ギフトカタログのツールを使用してください。
- ツールが空の結果を返した場合は、現在の条件では適合するギフトが
ないことを伝え、フィルターの緩和（予算、カテゴリ、種類の変更）
を提案してください。
`;
ここで重要な点がいくつかあります。
第一に、モデルの一般知識とアプリのデータをきちんと切り分けています。モデルは「デジタルと物理の違い」や「よくある贈答シーン」などの一般論は説明できますが、具体的なギフト、価格、SKU は GiftGenius のツールからのみ取得しなければなりません。
第二に、エラー／空の結果の扱いを明示しています。黙らない、創作しない。正直に状況を説明し、パラメータ変更を提案します。
第三に、抽象的な「ハルシネーション禁止」ではなく、私たちのドメイン（ギフトカタログとデジタル／物理 SKU の購入）に結びついた具体的な行動規範に落とし込んでいます。
このレイヤーだけでも効果は大きいのですが、ツールの説明が雑だと簡単に打ち消されてしまいます。次はツールの説明を見ていきましょう。
4. レイヤー2：ツールの説明（tool descriptions）とスキーマを契約の形式部分にする
モデルがいつどのようにツールを呼ぶかは、主に次の情報で判断されます。
- ツール名;
- ツールの description;
- inputSchema / outputSchema（フィールドを記述する JSON Schema）。
つまりツールの説明（tool description）は「人間向けドキュメント」ではなく、形式化されたプロンプトの一部です。多くのハルシネーションはまさにここから生まれます。
GiftGenius のカタログからギフトを選ぶバックエンド実装を持つ recommend_gifts ツールを想定しましょう。
悪い説明の例は次のようになります。
// 悪い例: あいまいすぎる
const recommendGiftsTool = {
name: "recommend_gifts",
description: "ユーザー向けのギフトを選定する",
inputSchema: {
type: "object",
properties: {
profile: { type: "string" }
}
}
};
形式的には正しいのですが、ここからモデルは次の点を理解できません。
- ツールの適用範囲（境界）;
- ギフトが見つからなかったときにどうすべきか;
- カタログ外のギフトや価格を捏造してはいけないこと。
良い説明は、ドメインを明確に定義し、いつツールを呼ぶべきかを示し、結果の捏造を厳格に禁止します。
例（GiftGenius 契約に合わせ、segments、budget、locale、occasion を利用）:
// config/tools.ts
export const recommendGiftsTool = {
name: "recommend_gifts",
description: `
GiftGenius のカタログからギフトを選定します。
受取人プロフィールのセグメント、予算、ロケール、贈る目的に基づいて
実在のギフト一覧を取得する必要があるときに、このツールを使います。
このツールは GiftGenius のカタログに実在するギフトのみを返します。
このツールの結果以外のギフトやその属性を捏造しないでください。
結果が空の場合、代替案をでっち上げず、
会話に戻ってユーザーに提案してください（予算、ギフトの種類、
目的などのパラメータを変える提案）。
`.trim(),
inputSchema: {
type: "object",
properties: {
segments: {
type: "array",
description:
"受取人プロフィールのセグメント。例: ['tech', 'fitness']。",
items: { type: "string" }
},
budget: {
type: "object",
description: "ギフト予算の範囲。",
properties: {
min: {
type: "number",
description: "最小金額（0以上）。",
minimum: 0
},
max: {
type: "number",
description: "最大金額（0より大きい）。",
exclusiveMinimum: 0
},
currency: {
type: "string",
description: "通貨の3文字コード。例: 'USD' または 'RUB'。",
minLength: 3,
maxLength: 3
}
},
required: ["min", "max", "currency"]
},
locale: {
type: "string",
description:
"ユーザーのロケール（言語/地域の形式）。例: 'ru-RU' または 'en-US'。",
minLength: 2
},
occasion: {
type: "string",
description:
"ギフトの目的（機会）。例: 'birthday', 'anniversary', 'new_year'。"
}
},
required: ["segments", "budget", "locale", "occasion"]
}
};
この description はいくつかの重要なポイントを満たしています。
まず、ツールが扱うのはGiftGenius のギフトカタログのみであり、具体的なギフトや価格はすべてその結果から取得すべきだと明言しています。
次に、いつツールを使うかを説明しています。特定の受取人条件に合わせた具体的なギフト一覧が必要なときであり、一般的なギフト論ではない場合です。
さらに、結果が空のときの振る舞いを定義しています。捏造せず、会話に戻る（この後フォローアップに固定する方針）ことです。
また、inputSchema によって、ユーザーのリクエストからセグメント、予算、ロケール、目的といったエンティティを堅牢に抽出できるようになります。フィールドの明確な構造や制約（min、max、固定長の currency）は、奇妙な組み合わせやパース時のエラーを減らすのに役立ちます。
さらに逆の側面――「いつ呼ばないか」も明記できます。たとえばリクエストが明らかに理論的な質問なら：
description: `
...
ユーザーが特定の人物向けの選定を求めず、
ギフトに関する一般的な質問をしているだけの場合は
このツールを使わないでください
（例: "一般的に年末年始に人気のギフトは？"）。
そのような場合はチャットで自分で回答してください。
`.trim()
こうして、system‑prompt の「理論的 vs 実務的」質問のルールとツール説明を同期させます。
5. レイヤー3：follow‑ups を UX とセーフティの層として設計する
たとえ system‑prompt とツール説明が完璧でも、現実はそう甘くありません。
- バックエンドがエラーを返すことがある;
- カタログが空のリストを返すことがある;
- 結果が曖昧、あるいは多すぎることがある。
ツール呼び出しの「後に何を言うべきか」を定義しないと、モデルは即興で答えます。うまくいくこともありますが、しばしば作り話が混じります。
第2回の講義では、アプリ起動のアナウンス、シナリオの締めくくり、ユーザーへの最終提示方法といった基本的な UX 指示を見ました。ここではさらに、ハルシネーションを抑えるフォローアップのパターンを加えます。
これらのパターンは通常、system‑prompt に「ツール実行後の対話」のような独立したブロックとして記述します。
断片の例:
// SYSTEM_PROMPT の続き
export const SYSTEM_PROMPT = `
# ... これまでのセクション ...
# ツール実行後の対話
- ギフト選定ツールが空のリストを返した場合:
1) 現在のフィルターでは該当するギフトが見つからなかったことを正直に伝える;
2) 1〜2 個の主要パラメータの変更を提案する
（予算、ギフトの種類、受取人の興味、目的）。
- ツールが候補を多く返しすぎた場合:
1) 最も関連性の高い 3〜7 件を選ぶ;
2) それらを選んだ基準を明示する
（興味の一致、予算内、評価など）。
- ツールでエラーが発生した場合:
1) データを捏造しない;
2) 技術的なエラーが発生したことを伝え、
後でもう一度試すか、リクエストの簡素化を提案する。
`.trim();
こうして、モデルにフォローアップの例を「焼き込み」ます。モデルは自分の言葉で表現しますが、次のような構造に沿うようになります。
- 事実の確認（空／多すぎ／エラー）;
- 制約の正直な開示;
- 次の一歩の丁寧な提案。
ギフトカタログではこれは非常に重要です。空の結果なのに「大丈夫です。こちらの3つがオススメです」と言ってしまう代わりに、次のように言うようになります。
「現在の条件（デジタルで宇宙関連、上限 $5、米国内配送限定）では、当社カタログに該当がありません。予算を広げるか、別のカテゴリをご提案しましょうか？」
ここで重要なのは、これはツールのコードではなく、プロンプト内の指示であり、期待する UX を定めているという点です。
6. すべてを結ぶ：GiftGenius の進化
アプリのミニ進化を見ながら、ハルシネーションのレベルを段階的に下げていきましょう。
初期版：どこで破綻するか
非常にミニマルな system‑prompt だったとします。
export const SYSTEM_PROMPT = `
あなたはギフト選びのアシスタントです。
ユーザーが適切なアイデアを見つけられるよう手助けしてください。
`;
ツールの説明は次のとおり。
export const recommendGiftsTool = {
name: "recommend_gifts",
description: "ユーザー向けのギフトを選定する",
inputSchema: { type: "object" }
};
フォローアップの指示はありません。
実際には次のようなことが起きます。
- ユーザーが「ゲーマーの友人向け、$10 以内のデジタルギフト」を求め、データベースに該当がない場合、モデルは次のいずれかを行う可能性があります。
- ツールを呼ばずに、頭の中でギフトを作り出す;
- ツールを呼んで空のリストを受け取りながら、それを告げずに候補を捏造する;
- バックエンドがエラーを返した場合でも、「何かはあるはず」と思い込み、推測を始めることがある。
こうして、チャットには美しい回答があるのに、データベースには何もないという古典的な状況が生まれます。
新しい system‑prompt
三層防御を踏まえ、system‑prompt を書き直します。すでに見た要素を含め、全体をまとめます。
// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# 役割
あなたは GiftGenius。私たちのアプリのギフトカタログに基づいて
贈り物選びを支援するアシスタントです。
# 責務範囲
- ユーザーがカタログから適切なギフトを選べるように支援し、
候補の長所・短所を説明します。
- 実際の購入やギフトの送付について約束しないでください。
あなたは選定と比較を支援するだけです。
購入とコード/リンクの発行は、ユーザーの明示的な同意後に
バックエンドが行います。
# データと制約
- カタログやツールの応答に存在しないギフトを作らないでください。
- 価格、種類、在庫、配送地域を捏造しないでください。
- ツールがデータを返さない、またはエラーが起きた場合は、
推測せず、その旨を伝えてください。
# ツールの利用
- 事実データ（ギフト一覧、価格、種類、SKU、説明）には、
カタログのツール（例: profile_to_segments、recommend_gifts、get_gift）
を使用してください。
- 質問が理論的で、具体的なギフト選定を必要としない場合は、
ツールを使わずに自分で回答してください。
# ツール実行後の対話
- 結果が空のとき: 現在の条件では見つからないことを正直に伝え、
1〜2 のパラメータ変更を提案します。
- 候補が多すぎるとき: 最も適切な 3〜7 件を選び、
選定基準を説明します。
- ツールでエラーが起きたとき: データを捏造せず、
障害を謝罪し、再試行またはリクエストの簡素化を提案します。
`.trim();
これでモデルは次の点を明確に理解します。
- どこまでが「ギフト選びの相談役」で、どこからが「バックオフィス」（ツール側）なのか;
- どのデータを捏造してはいけないのか;
- 典型的な非理想ケースでどう振る舞えばよいか。
recommend_gifts の新しい description とスキーマ
system‑prompt を強化したので、ツールも磨き込み、セクション4の考え方に基づく最終版の説明を組み立てます。
// config/tools.ts
export const recommendGiftsTool = {
name: "recommend_gifts",
description: `
GiftGenius のカタログからギフトを選定します。
このツールを使うのは、次のようなときです:
- 実在するギフトの一覧（最新の価格、種類
（digital/physical）、タグ）を取得したいとき;
- 興味セグメント、予算、ロケール、目的で絞り込みたいとき。
このツールを使わないでください:
- ユーザーが特定の人物向けの選定を求めず、
ギフトに関する一般的な質問だけをしている場合;
- カタログに存在しないギフトを作りたい場合。
結果が空の場合、自分でギフトを捏造せず、
会話に制御を戻してください（system-prompt の指示に従うこと）。
`.trim(),
inputSchema: {
type: "object",
properties: {
segments: {
type: "array",
description:
"受取人プロフィールのセグメント。例: 'tech', 'sport', 'books'。",
items: { type: "string" }
},
budget: {
type: "object",
description:
"ユーザーの通貨でのギフト予算範囲（min/max）。",
properties: {
min: { type: "number", minimum: 0 },
max: { type: "number", exclusiveMinimum: 0 },
currency: {
type: "string",
minLength: 3,
maxLength: 3,
description: "ISO 4217 通貨コード。例: 'USD' または 'RUB'。"
}
},
required: ["min", "max", "currency"]
},
locale: {
type: "string",
description: "ユーザーのロケール。例: 'ru-RU' または 'en-US'。"
},
occasion: {
type: "string",
description:
"ギフトの目的（機会）。例: 'birthday', 'anniversary', 'new_year' など。"
}
},
required: ["segments", "budget", "locale", "occasion"]
}
};
ここにはいくつかの注意点があります。
ツールの振る舞いを system‑prompt と明示的に結びつけています。「system‑prompt の指示に従う」という文言で、モデルに「空の結果＝正直な会話であって、創作ではない」と思い出させます。
また、否定条件（「〜しないでください」）をきちんと定義しています。実務上、肯定的な説明と同じくらい重要です。
さらに、inputSchema を意味的に豊かにしています。フィールドの説明と制約を丁寧に書くことで、モデルがリクエストを正しくフィールドに対応づけ、ツールを呼ぶ前段階での「取り違え」を減らします。
ウィジェットのフォローアップパターンと応答フォーマット
テキスト指示に加え、もうひとつのレバーがあります。それはツールの応答フォーマット自体です。これを通じて、何が起きたのかをモデルに暗に知らせ、空想の余地を狭めることができます。
形式的にはフォローアップは system‑prompt のテキストで規定しますが、Next.js のウィジェット側で ToolOutput を正規化 しておくと、モデルの負担を減らし、創作の余地をさらに狭められます。
たとえば、バックエンドの recommend_gifts は常に次のように返すことにします。
// バックエンドにおけるツール応答の型
export type RecommendGiftsResult = {
items: Array<{
id: string;
title: string;
price: number;
currency: "USD" | "EUR" | "RUB";
tags: ("digital" | "physical" | "education" | "fitness" | "tech")[];
}>;
// 何が起きたかをモデルに明示するために backend が設定するフィールド
status: "ok" | "empty" | "error";
errorMessage?: string;
};
ウィジェットはこれを見栄えよく表示できますし、モデルは応答を作る際に status を参照できます。Apps SDK ではしばしば JSON オブジェクトとして ToolOutput をモデルに渡すため、このフィールドが目に入ります。
system‑prompt に小さなブロックを追加できます。
# ツールのステータス解釈
- status = "empty" の場合: 「ツール実行後の対話」セクションを参照し、
ギフトを捏造しないこと。
- status = "error" の場合: 技術的なエラーを伝え、
カタログの内容を推測しないこと。
モデルはこれがなくても察してくれるかもしれませんが、明示しておくことで「当て推量」による振る舞いの確率を下げられます。
7. 実践：自分の App を磨き込む
「スライドではきれいだけど本当に効くの？」という感覚にならないよう、いまの App（ここでは GiftGenius）で実際にできる演習を挙げます。system‑prompt、ツールの説明、結果処理という三層で小さなリファクタリングをしましょう。
まず、system‑prompt のレベルでは、第一回講義で作成した system‑prompt を開き、責務範囲とツール利用を説明している箇所を探してください。そこに次を追加します。
- カタログ／データベース外のエンティティ（ギフト、SKU、価格）の捏造禁止;
- 空の結果やツールエラー時のルール;
- 「ツール実行後の対話」のセクション（空／多すぎ／エラーの 2〜3 シナリオ）。
次に、ツール説明のレベルでは、主要ツール（あなたの場合は recommend_gifts、search_gifts、search_tariffs、calculate_quote など）の説明を開きます。description を次のように書き換えます。
- ツールがあなたのデータソースのみ（ギフトカタログや料金カタログなど）を扱うことを明言する;
- いつ必要で、いつ不要かを説明する;
- 明確な否定制約を含める（「捏造しない」「〜には使わない」）。
最後に、ツール応答構造のレベルでは、応答にステータスを明示するフィールド（status、resultType、hasMore など）がまだない場合、バックエンドの型と ToolOutput に追加します。そのうえで、system‑prompt にモデルがそのステータスをどう解釈すべきかを書き加えます。
最後に、Dev Mode でいくつかのリクエストを流してみましょう。結果が意図的に空、または境界的なものも含めて試し、モデルが捏造をやめたか、制約をどれだけ正直に伝えられているかに注目してください。
次回の講義では、こうしたリクエストを golden prompt set に形式化し、再現可能なテストアーティファクトにします。いまはまず、手を動かして違いを体感することが重要です。
8. プロンプトとツールでハルシネーションに対処するときの典型的な落とし穴
誤り1：system‑prompt に「ハルシネーションするな」という魔法の一文だけ。
開発者がプロンプトの末尾に「情報を捏造しないこと」と書いて満足してしまうケースです。実際には、ツール説明やフォローアップが代替行動を与えていないため、モデルは作り話を続けます。「捏造の代わりに何をするか」（空の結果を認める、フィルター変更を提案する、エラーを伝える）という具体的ルールがなければ、その一文に効果はほとんどありません。
誤り2：system‑prompt とツールの description の矛盾。
system‑prompt では「カタログにないギフトを作らない」と言っているのに、ツール説明では「見つからなければ似た候補を裁量で提案してよい」と書いてある、といった矛盾です。結果としてモデルはどちらを信じるか迷い、たいてい具体性の高い（多くはツール側の）記述が勝ちます。両レイヤーが同じことを言うようにしなければなりません。もし「似た候補」が許容されるなら、それも形式化し、必ずユーザーに「完全一致ではない」ことを説明します。
誤り3：ツールの説明が漠然としすぎている。
「ユーザーの課題解決を助けるツールです」といった説明では、適用範囲がほとんど伝わりません。この場合、モデルはツールを使わないか、何かにつけて呼び出しては、結果が少ない／ないときに「穴埋め」を始めてしまいます。良い description は識別的（discriminative）であるべきです。何をするツールか、いつ呼ばないかを明確に述べます。
誤り4：空結果やエラー結果の戦略がない。
開発者は気を利かせてバックエンドに { items: [], status: "empty" } を返させても、モデルにそれが何を意味するかをどこにも説明していないことがあります。結果、モデルは空配列を見ても「一般知識から何か提案すべきだ」と判断してしまいます。system‑prompt に、こうしたステータスの解釈や、ユーザーに何を伝えるかのセクションが欠けています。空／エラー時の明確なルールを数個足すだけで、品質は大きく向上します。
誤り5：ウィジェットのコードだけで「治そう」とする。
「空のときはプレースホルダーを出して、モデルのテキスト応答は見せない」といった UI 対応に寄せたくなることがあります。UX は多少ましになりますが、モデル自身は依然として捏造を信じ、後続の発話でも同じ振る舞いをします。正しいアプローチは、まず指示（system‑prompt、ツール説明、フォローアップ）を変更し、そのうえで UI の防御を補完することです。
誤り6：メタデータやスキーマがモデルの振る舞いに与える影響を無視する。
JSON Schema やフィールド説明を「フォームやバリデーション用」としか見ていないケースです。実際には ChatGPT にとって重要なプロンプトの一部であり、モデルはこれらの説明から、リクエストから抽出すべきパラメータや正しい応答の形を理解します。弱かったり不整合なフィールド記述（description、enum）は、ミスの確率を高め、間接的にハルシネーションを誘発します。
誤り7：代替案のない過度の禁止事項。
プロンプトが「〜するな」の羅列になってしまい、難しい状況で「何をすべきか」が書かれていないことがあります。たとえば、捏造禁止とカタログ限定を課したのに、理論的な質問について何も言及していない場合です。その結果、モデルは本来なら有益な一般論を説明できるのに、単に「わかりません」と答えてしまうことがあります。常に、禁止だけでなく許されるルートを開きましょう。たとえば「カタログで見つからないなら、正直に伝え、どうリクエストを変えるか提案する」や「理論的な質問なら、ツールなしで自分で答える」などです。
GO TO FULL VERSION