prompt-repetition

プロンプトの繰り返し

このスキルを使う場面

• ユーザーが非推論モデルまたは軽量モデルを使用しており、重要な質問がプロンプトの後半にあると正確性が低下します。
• プロンプトの形式が、長文コンテキストからの検索、選択肢が先に提示される多肢選択問題、または位置に依存する検索です。
• プロンプトを2回または3回繰り返すかどうかについて、プロンプトエンジニアリングが役立つという曖昧な約束ではなく、明確な判断基準をユーザーが求めています。
• モデルを変更したり、検索インフラストラクチャを構築したりする前に、手軽な実験を行う必要があるワークフローです。
• リクエストに、モデルが質問を忘れた、最後の指示を見落とした、リストの25番目の項目を見つけられなかった、選択肢の長いリストに混乱した、またはより強力な推論モデルよりHaiku／Flash／miniモデルの性能が低いといった内容が含まれています。

次の場合は、このスキルを主なワークフローとして使用しないでください。

• 本当の問題がコンテキストの選択、検索設計、またはノイズの多いソース情報の詰め込みである → より広範なコンテキストエンジニアリングまたはRAGの作業を使用します。
• 本当の問題が推論の深さであり、推論能力のあるモデルを利用できる。
• プロンプトがツール中心／エージェント型／複数ステップであり、プロンプト全体を繰り返すとコストと混乱が増す可能性がある。
• ユーザーが常時適用される汎用ミドルウェアの方針を必要としている。このスキルは対象を絞って使用するものであり、一律に自動適用するものではありません。

基本的な考え方

プロンプトの繰り返しは、タスク形式に応じた介入策であり、普遍的なプロンプトの法則ではありません。

最も強い根拠があるのは、次のケースです。

1. 長文コンテキストからの検索 — 多くのコンテキストの後に質問が置かれ、モデルが後半の詳細を見落とします。
2. 選択肢が先に提示される多肢選択問題 — 質問より先に選択肢が表示されるか、構造上、実際の問いを見失いやすくなっています。
3. 位置に依存する検索 — 項目一覧、順序付きリスト、レコードの位置などで、モデルがインデックスのような詳細を見失います。

このスキルがうまく機能するには、次の3つの質問に明確に答える必要があります。

1. これは、繰り返しを試す価値があるタスク形式の1つですか？
2. コンテキストの上限を超えずに試せる、安全な繰り返し回数はいくつですか？
3. 繰り返しが適切でない場合、代わりに何をすべきですか？

手順

ステップ1：変更する前にプロンプトの形式を分類する

現在のプロンプトを、次のいずれかに分類します。

形式	よくある兆候	繰り返しとの相性	相性がよくない場合の代替策
長文コンテキストからの検索	「巨大なコンテキストの後にある質問をモデルが無視する」	良好	コンテキストを削減／選択する、検索を行う、質問を最後の方でもう一度述べる
選択肢が先に提示される多肢選択問題	「選択肢が先に提示され、モデルが誤った文字を選ぶ」	良好	質問と選択肢の順序を入れ替える、回答形式を簡潔にする
位置に依存する検索	「長いリストの25番目の項目を見落とす」	良好	リストを分割する、構造化された表を提示する、検索を使用する
ツール中心のエージェントプロンプト	「ツール、ポリシー、ステップが多数ある」	低い	ポリシーを簡潔にする、段階を分ける、より優れたオーケストレーションを使用する
推論中心のタスク	「段階的な統合や計画が必要」	低い	推論モデルを使用する、タスクを分解する、例を示す
RAG／検索アーキテクチャ	「検索された根拠にノイズが多い、または不完全」	低い	検索、ランキング、チャンク分割、コンテキストの組み立てを改善する

タスクが相性の低い行に当てはまる場合、主な回答としてプロンプトの繰り返しを勧めないでください。

ステップ 2：モデルとコストのガードレールを確認する

プロンプトを繰り返すと、入力トークンが増加します。テストした実行で、生成される出力の長さやレイテンシーに増加がなかったと論文で報告されていても同様です。

最低限、次の点を確認してください。

• モデルのクラス — 非推論型／軽量モデルですか。それとも、より強力な推論能力を備えたモデルですか？
• 現在のプロンプトの長さ — 2×または3×にしても、使用可能なコンテキスト予算に十分収まりますか？
• 運用上の予算 — このワークフローで入力コストの増加を許容できますか？
• 失敗の種類 — コンテキスト後半の見落としを解決しようとしていますか。それとも、実際には推論や検索の品質に関するタスクですか？

保守的なデフォルト：

• プロンプトがすでにコンテキスト上限に近い場合は、全文の繰り返しを推奨しないでください
• タスクに構造化された推論が必要な場合は、モデル選択の代わりに繰り返しを使わないでください
• 最後の質問／指示だけが重要な場合は、プロンプト全体を複製する前に、質問を言い換える方法を試してください

ステップ 3：効果がある最小限の介入を選ぶ

失敗の種類に合った、最もコストの低い介入を使ってください。

1. 質問だけを繰り返す

   • コンテキストが非常に長く、最後の依頼だけが見落とされている場合に最適です。
   • 最初に試す最も低コストな方法です。

2. プロンプト全体を2×で繰り返す

   • 軽量モデルでの長文コンテキスト検索や、選択肢が先に示されるMCQに対するデフォルトの実験です。
   • プロンプト全体の構造が重要な場合に適した初回の試みです。

3. プロンプト全体を3×で繰り返す

   • 明らかに位置に左右されるタスクや、インデックスの多いタスクに限ってください。
   • コストとコンテキストウィンドウに十分な余裕がある場合のみ使用してください。

入力トークンのオーバーヘッドをユーザーが負担できない場合は、プロンプトの再構成または検索に切り替えてください。

ステップ 4：明示的なオプトアウトルールを適用する

次のいずれかに該当する場合は、繰り返しを推奨しないでください。

• ユーザーがすでに優れた推論モデルを使用しており、失敗の原因が多段階推論にある
• プロンプトに多数のツール、ポリシー、アクション制約が含まれており、繰り返すと不必要に重複する
• 検索対象のセットが弱い、矛盾している、または無関係である
• コンテキストの予算にすでに余裕がなく、複製すると切り捨てやパフォーマンス低下のリスクがある
• 質問の位置を変える、コンテキストを減らす、または小さな例を追加することで、より簡潔に解決できる

ステップ 5：単なるテクニックではなく、判断を示す

良い回答には、次の内容を含めてください。

1. 適合性 — このケースで繰り返しが適切かどうか、その理由
2. 推奨する最小限の介入 — 質問だけを繰り返す、プロンプト全体を2×で繰り返す、プロンプト全体を3×で繰り返す、または繰り返しを使わない
3. 予算に関する注意点 — 入力トークン／コンテキストウィンドウへの影響
4. 代替案／別の方法への切り替え — 繰り返しが適切でない場合に代わりに行うこと

次の形式で回答してください。

「このタスクの性質から、プロンプトの繰り返しとの適合性は[高い／低い]です。まず[最小限の介入]を試してください。[トークン／コンテキストのリスク]に注意してください。うまくいかない場合は、[より適切な代替案]に切り替えてください。」

ステップ 6：評価の範囲を絞り、比較可能にする

繰り返しをテストする場合：

• 繰り返しの変更点を除き、同じプロンプトを使用する
• 予算に余裕がある場合に限り、ベースラインと2×、3×を比較する
• 成功は、スタイルや長さだけではなく、タスクの正確さで評価する
• 繰り返したプロンプトがコンテキストを圧迫する場合や、明らかに肥大化した場合は中止する

複数の変更が必要な場合、繰り返しはおそらく主要な解決策ではありません。

ステップ 7：別の課題に移ったら、適切な方法に切り替える

• コンテキストの選択／検索／チャンク化／情報源の品質 → より広範なコンテキストエンジニアリングまたはRAGの作業
• 推論を多く要する統合／計画 → より強力な推論モデル、またはタスクを分解するワークフロー
• プロンプトの例／出力形式の誘導 → フューショットまたはプロンプト構造の作業
• ツールのポリシー／アクション制約の混乱 → プロンプト全体を複製するのではなく、オーケストレーションを簡素化する

例

例 1：軽量モデルでの選択肢先行型の多肢選択問題

プロンプト：

Flash モデルで、選択肢が先に提示される長い多肢選択プロンプトを使っています。プロンプトを複製するべきでしょうか。それとも構成を変更するべきでしょうか？

望ましい回答の構成：

• 選択肢先行型の多肢選択問題に分類します
• 最初の限定的な実験として、質問の再提示か、プロンプト全体の 2 倍化を提案します
• トークンコストとのトレードオフに触れます
• プロンプトの順序変更も有効な構成上の代替策であると説明します

例 2：RAG の品質に関する不満

プロンプト：

RAG の回答の質が低いです。あらゆる場面でプロンプトの反復を追加するべきでしょうか？

望ましい回答の構成：

• このケースにはあまり適していないと伝えます
• 検索やコンテキストの品質を改善するほうが効果的だと説明します
• 一律に反復を追加するのではなく、コンテキストエンジニアリングや RAG の改善を提案します

例 3：位置に依存する在庫検索

プロンプト：

mini モデルが、長い在庫リストの 25 番目のスロットにある商品を見落とし続けます。

望ましい回答の構成：

• 位置に依存する検索に分類します
• 予算が許せば、2 倍、場合によっては 3 倍の反復を認めます
• コストが高すぎる場合の代替策として、構造化テーブルまたはチャンク分割に触れます

例 4：推論モデルに関する質問

プロンプト：

推論能力のあるモデルを利用できますが、コストが高くなります。プロンプトの反復で代用できますか？

望ましい回答の構成：

• いいえ、反復は推論能力の代わりにはならないと伝えます
• 反復は、推論を必要としない特定の失敗パターンに限定します
• 複数ステップの推論には、より高性能なモデルまたはタスクの分解を提案します

ベストプラクティス

1. プロンプトの反復は、既定のミドルウェアではなく、対象を絞った実験として扱います。
2. 失敗パターンに合った最小限の介入から始めます。
3. 入力トークンのコストとコンテキスト予算への圧迫について、必ず説明します。
4. 本当の問題がコンテキストの品質にある場合は、プロンプトの再構成または検索の改善を優先します。
5. 根拠の弱い主張は取り除き、このスキルが一般的なプロンプトの小技集にならないようにします。
6. 最終的な推奨は二択にします。ここでは反復を試すか、別の方法を提案するかです。

参考資料

• references/evidence-and-boundaries.md
• references/operator-checklist.md