LLMに汎用的なプロンプト（Instructionファイル, Customizationファイル, etc.）を作らせる プロンプト原則 を Skill にまとめた。原則そのものと、各項目の意図を順に解説していく。
- 参考にした論文・ベストプラクティス記事
プロンプト原則
シンプルを突き詰める。
---
name: prompt-principles
description: LLMプロンプト原則。Customization file・Prompt の作成・編集・レビュー時に使用せよ
---
# Prompt Principles
**Prompt目的に対する効果がコストを上回るか** が指示記述のあらゆる基準となる
- 過剰な指示を削り、効く指示だけを残す
- **Context Rot**: 入力トークンが増えるほど出力品質が下がる
- **Instruction-Density Decay**: 指示が多いほど遵守率が下がる
- **Attention Budget**: ある指示を追加・強調すれば、他の指示が薄まる
- **Do the simplest thing that works**: 同等に機能する指示の内、最もシンプルな指示を採る
## Include
- **Non-parametric knowledge**: 素のモデルが持たない知識・事実・情報
- 状況固有で、素のモデルの挙動から変える必要がある事項（例: 判断基準、前提、条件、方針、手順、範囲）
## Exclude
- **Parametric knowledge**: モデルが既知の知識・事実・情報
- モデルが容易に取得可能な情報
- 詳細すぎる・長すぎる記述
## How to Write
- **Right altitude**: 具体的すぎると柔軟性が失われ、抽象的すぎると挙動が安定しないため、それらを避ける適正な抽象度で指示する
- 挙動を導く判断基準・方針を与える
- 抽象的・自由度の高い指示では理由・背景を添える（自律的・柔軟な挙動を促す）
- 一貫性が求められる（例: 形式、構造、スタイル）、または指示で挙動を定めにくい場合、代表的な例を厳選して示す
- 挙動を定めるなら判定可能な基準を示し、挙動に自由度を与えるなら抽象度の高い表現でモデルへ委ねる
- **Output contract**: 期待する回答の方向性がある場合、それを規定する要素を示し、解釈の幅を絞る（例: 条件、形式、構成、内容、範囲、量）
- **Positive framing**: 望む挙動を直接的に書く。ただし、素のモデルの挙動の抑止・禁止は明示する
- 広く浸透し意味の定まった用語・呼称がある場合、それを優先採用して文章を圧縮する（例: 概念名、手法名、規格名）
- 英語用語の直訳・造語は避け、英語のまま使う（学習が不十分な語は不安定な挙動を招く）
- 文章は項目や役割に応じて分類し、節・箇条書き・表・ブロックなどで構造化する
なぜシンプルに書くのか
Prompt Principles
Prompt目的に対する効果がコストを上回るか が指示記述のあらゆる基準となる
- 過剰な指示を削り、効く指示だけを残す
- Context Rot: 入力トークンが増えるほど出力品質が下がる
- Instruction-Density Decay: 指示が多いほど遵守率が下がる
- Attention Budget: ある指示を追加・強調すれば、他の指示が薄まる
- Do the simplest thing that works: 同等に機能する指示の内、最もシンプルな指示を採る
LLMを期待する挙動へ誘導して指示を効果的に作用させるために、シンプルで無駄のない指示を書かせる。
LLMへの指示・トークン量は少ないほど性能が高くなりやすい。ここではその背景が詰め込まれた用語を与えることで、効率的にLLMへその考え方を叩き込んでいる。
各用語の効果
- Context Rot: 冗長な・過剰な文章の抑制
- Instruction-Density Decay: 細かすぎる・説明的過ぎる指示の抑制
- Attention Budget: 強調（「必ず」「絶対」）の乱用・意図的な曖昧さ排除などの抑制
- Do the simplest thing that works: シンプルなpromptの促進
- 不採用語
- Lost in the middle (長い指示の先頭・末尾以外は遵守されにくい): そんな長いプロンプトは今回の作成対象ではないので
何を書き、何を削るか
Include
- Non-parametric knowledge: 素のモデルが持たない知識・事実・情報
- 状況固有で、素のモデルの挙動から変える必要がある事項（例: 判断基準、前提、条件、方針、手順、範囲）
Exclude
- Parametric knowledge: モデルが既知の知識・事実・情報
- モデルが容易に取得可能な情報
- 詳細すぎる・長すぎる記述
LLMの挙動を期待する方向へ変える指示を書かせ、過剰な指示は削らせる。
モデルが既に知っていること（Parametric knowledge）を書いても挙動は変わらず、トークンを増やして遵守率を下げるだけ。
How to Write — どう書くか
何を書くかを絞ったら、次はどう書くか。
適正な抽象度で指示する
- Right altitude: 具体的すぎると柔軟性が失われ、抽象的すぎると挙動が安定しないため、それらを避ける適正な抽象度で指示する
- 挙動を導く判断基準・方針を与える
- 抽象的・自由度の高い指示では理由・背景を添える（自律的・柔軟な挙動を促す）
- 一貫性が求められる（例: 形式、構造、スタイル）、または指示で挙動を定めにくい場合、代表的な例を厳選して示す
具体的すぎる指示はLLMの柔軟性を損なうし、抽象的すぎる指示は解釈の幅が広すぎて挙動が安定しない。その中間の抽象度で書かせる。
（例）
- ❌ 具体的すぎ:「
FooErrorとBarErrorは catch する」→ 具体例に引き摺られ、それ以外のエラーに対応できない - ❌ 抽象的すぎ:「エラーを適切に処理する」→ 基準が曖昧で、LLMの挙動が定まらない
- ✅ 丁度いい抽象度:「回復可能な例外のみ catch し、そうでないエラーは伝播させる」→ 狙った範囲の例外に安定的に対応できる
基準で挙動を定める
- 挙動を定めるなら判定可能な基準を示し、挙動に自由度を与えるなら抽象度の高い表現でモデルへ委ねる
LLMの挙動を制御する必要があるなら、事前に定義できる範囲内で条件は明示する。
ただし、柔軟な挙動を期待するときなどは、あえて広い意味の語を使わせる。
- ❌「適切な長さで要約する」
- ✅「200 字以内で要約する」
出力を規定する
- Output contract: 期待する回答の方向性がある場合、それを規定する要素を示し、解釈の幅を絞る（例: 条件、形式、構成、内容、範囲、量）
自由な出力が望ましくないケースでは、ちゃんと明示的な出力指示をさせる。
肯定形で書く
- Positive framing: 望む挙動を直接的に書く。ただし、素のモデルの挙動の抑止・禁止は明示する
基本的には否定形より肯定形で書かせる。
否定形の方が効きが弱くなりやすい。
定着した用語で圧縮する
- 広く浸透し意味の定まった用語・呼称がある場合、それを優先採用して文章を圧縮する（例: 概念名、手法名、規格名）
LLMがよく知ってる用語を積極的に使わせる。
十分に浸透した用語なら、その用語だけでかなり広く深いコンテキストを与えられる。
ただし、知名度が不十分だったり、多義性があったりする場合は、説明を併記することで確実にLLMを導く。（これに関してはプロンプトに記述してないけど‥）
- 例:
Context Rot: 入力が長くなるほど出力品質が下がる
文章を構造化する
- 文章は項目や役割に応じて分類し、節・箇条書き・表・ブロックなどで構造化する
構造的な文章を書かせる。
構造化することで無秩序になりにくく、メンテナンス性の高いプロンプトになりやすい。
言語
英語の方がトークン効率が良いので、理解を阻害しない範囲で英語を導入させる。
ただし、自分で常に改善・メンテしていくプロンプトなので、基本は日本語で書かせてる。
（メンテしてくつもりがないなら全部英語変換してOK）
多言語混在
- 日本語・英語文章の混在: switchingで性能が下がるケースがあるらしいから避けとく（将来的には不明）
- タイトルや単語だけ英語化: 特に問題なし
トークン効率（日本語/英語）
GPT-5系の公式トークナイザ（o200k_base）でのトークン分割の例を挙げとく。
（あくまで以下は一例。傾向としては日本語トークン数は1.5～2倍ぐらい）
- 日本語文:
モデル情報を中継していく- トークン数: 9
- 英語文:
Keep relaying model information- トークン数: 5
| # | トークン | 種別 |
|---|---|---|
| 1 | モデル | カタカナ |
| 2 | 情報 | 漢語熟語 |
| 3 | を | ひらがな |
| 4 | 中 | 漢字 |
| 5 | 継 (e7b6) |
バイト分割 |
| 6 | 継 (99) |
バイト分割 |
| 7 | して | ひらがな |
| 8 | い | ひらがな |
| 9 | く | ひらがな |
（実験中）記号による圧縮
プロンプトに以下の1文を追加して、トークン圧縮を図れる。
-
意味を維持できる場合、語句を同義の記号で置換して表現する（例: = ≠ ≥ ∴ ∵ → ✅ ❌ ▲▼）-
∴: 「すなわち」、「従って」 -
∵: 「なぜならば」 -
▲▼: UP/DOWN（↑↓がUP/DOWNの意味で使われるのを防ぐ。↑↓はフローや方向の意味に使わせる）
-
まとめ
現状のベストプラクティスを良い感じに集約して、プロンプト作成用のプロンプトを作った。
今後モデルが進化していくと、ノウハウがまた変わっていくのだろうけど‥