LLMに汎用的なプロンプト（Instructionファイル, Customizationファイル, etc.）を作らせると、毎回似た修正を繰り返しがちになる。これを避けるために プロンプト原則 を Skill にまとめた。原則そのものと、各項目の意図を順に解説していく。
- 参考にした論文・ベストプラクティス記事
プロンプト原則
シンプルを突き詰める。
---
name: prompt-principles
description: LLM 向けの prompt を作成・編集・レビューする際に従うべき原則
---
# Prompt Principles
- 過剰な指示を削り、効く指示だけを残す
- **Context Rot**: 入力トークンが増えるほど出力品質が下がる
- **Instruction-Density Decay**: 指示が多いほど遵守率が下がる
- **Do the simplest thing that works**: 同等に機能する指示の内、最もシンプルな指示を採る
## Include
- **Non-parametric knowledge**: 素のモデルが持たない知識・事実・情報
- 状況固有で、素のモデルの挙動から変える必要がある事項（例: 判断基準、前提、条件、方針、手順、範囲）
## Exclude
- **Parametric knowledge**: モデルが既知の知識・事実・情報
- モデルが容易に取得可能な情報
- 詳細すぎる・長すぎる記述
## How to Write
- **Right altitude**: 具体的すぎると柔軟性が失われ、抽象的すぎると挙動が安定しないため、それらを避ける適正な抽象度で指示する
- 挙動を導く判断基準・方針を与える
- 抽象的・自由度の高い指示では理由・背景を添える（自律的・柔軟な挙動を促す）
- 一貫性が求められる（例: 形式、構造、スタイル）、または指示で挙動を定めにくい場合、代表的な例を厳選して示す
- **Output contract**: 期待する回答の方向性がある場合、それを規定する要素を示し、解釈の幅を絞る（例: 条件、形式、構成、内容、範囲、量）
- **Positive framing**: 望む挙動を直接的に書く
- 達成を判定できない語（例: 丁寧に、適切に）に挙動を委ねない。判定性が必要なら基準を規定する
- 広く浸透し意味の定まった用語・呼称がある場合、それを優先採用して文章を圧縮する（例: 概念名、手法名、形式名、役割名、文体名、規格名）
- 英語表記が一般的である用語・概念は英語表記を優先する
- 文章は項目や役割に応じて分類し、節・箇条書き・表・ブロックなどで構造化する
なぜシンプルに書くのか
Prompt Principles
- 過剰な指示を削り、効く指示だけを残す
- Context Rot: 入力トークンが増えるほど出力品質が下がる
- Instruction-Density Decay: 指示が多いほど遵守率が下がる
- Do the simplest thing that works: 同等に機能する指示の内、最もシンプルな指示を採る
LLMを期待する挙動へ誘導し、指示を効果的に作用させるために、シンプルで無駄のない指示を書かせる。
LLMへの指示・トークン量は少ないほど性能が高くなりやすい。ここではその背景が詰め込まれた用語を与えることで、効率的にLLMへその考え方を叩き込んでいる。
用語採用の背景
- Context Rot: 界隈では有名かつ重要な用語なので、採用
- Instruction-Density Decay: 用語としては Curse of Instructions の方が正確だが、LLMへの作用を考慮して、意味がより伝わりやすい本用語を採用
- Do the simplest thing that works:
過剰な指示を削り、効く指示だけを残すと重複する部分があるが、カバー領域が異なる・重要なので強調する意味でも重複が許容される ので採用 - 不採用
- 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 し、そうでないエラーは伝播させる」→ 狙った範囲の例外に安定的に対応できる
出力を規定する
- Output contract: 期待する回答の方向性がある場合、それを規定する要素を示し、解釈の幅を絞る（例: 条件、形式、構成、内容、範囲、量）
自由な出力が望ましくないケースでは、ちゃんと明示的な出力指示をさせる。
肯定形で書く
- Positive framing: 望む挙動を直接的に書く
否定形より肯定形で書かせる。
否定形の方が効きが弱くなりやすい。
基準で挙動を定める
- 達成を判定できない語（例: 丁寧に、適切に）に挙動を委ねない。判定性が必要なら基準を規定する
事前に定義できる範囲内で条件は明示する。（無理に条件を付ける必要はない）
良い感じの雰囲気の語に期待してはいけない。
- ❌「適切な長さで要約する」
- ✅「200 字以内で要約する」
定着した用語で圧縮する
- 広く浸透し意味の定まった用語・呼称がある場合、それを優先採用して文章を圧縮する（例: 概念名、手法名、形式名、役割名、文体名、規格名）
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の意味で使われるのを防ぐ。↑↓はフローや方向の意味に使わせる）
-
まとめ
現状のベストプラクティスを良い感じに集約して、プロンプト作成用のプロンプトを作った。
今後モデルが進化していくと、ノウハウがまた変わっていくのだろうけど‥