LM Studioのコーディング向けシステムプロンプト設計：`temperature`・`context_length`・`stop`トークン徹底解説

top_p・top_k・repeat_penaltyのチューニングは完了しました。出力のループは止まり、意味不明なコードも減りました。それでもモデルがトピックから外れたり、以前のコードを忘れたり、意図した場所で止まらないことがある——。

それは別のパラメータ群の問題です。そしてこちらも同様に重要です。

本記事では、モデルが自分の役割をどう理解するか、何を記憶できるか、どこで出力を止めるかを制御する3つのパラメータを解説します：temperature・context_length・stopトークンです。

🌡️ `temperature`とは？

top_pやtop_kが候補トークンを絞り込むのに対し、temperatureはその候補の中からモデルがどれだけ自信を持って選ぶかを制御します。

集中と創造性の間を調整するダイヤルとして考えてください：

temperature = 0.0 → 完全に決定論的。モデルは常に最も確率の高いトークンを選択。同じプロンプト = 毎回同じ出力。
temperature = 0.2 → 少し緩める。2番目や3番目に確率の高いトークンを時々考慮。
temperature = 1.0 → 完全確率的。候補トークンすべてが同等に扱われ、出力が予測不能に。
temperature > 1.0 → 混沌の域。コードには絶対に使用しないこと。

👉 コーディング向け推奨値：`0.1〜0.3`

コードは創作文章ではありません。関数シグネチャ、ループ、SQLクエリには正解があり、モデルにはそれにコミットしてほしいのです。temperatureが高いと、あるときは正常なPythonを返し、次の実行では構文エラーのあるPythonを返す原因になります。

{
  "temperature": 0.2
}

やや高め（0.4〜0.6）が適切な場面： ボイラープレートの生成、ドキュメントコメント、READMEのセクションなど、表現の多少の変化が許容される場合。

コードには0.7以上は絶対NG。 存在しないライブラリ名の幻覚、崩れたインデント、見た目は妥当でも実行できないロジックが出現します。

📏 `context_length`とは？

context_length（一部のUIではn_ctx）は、モデルが一度に「見える」トークン数——つまりワーキングメモリ——を定義します。

これには以下がすべて含まれます：

システムプロンプト
会話履歴全体
貼り付けたドキュメントやコード
モデル自身のこれまでの出力

コンテキストウィンドウが満杯になると、モデルは冒頭部分を忘れ始めます。コーディングセッションでは、以前の関数定義、確立した変数名、システムプロンプトで説明したプロジェクトの制約を忘れることになります。

👉 タスク別推奨設定：

タスク	`context_length`
単一関数の補完	2,048
ファイルレベルのコードレビュー	4,096
マルチファイルリファクタリングセッション	8,192
大規模コードベースのQ&A	16,384〜32,768

{
  "n_ctx": 8192
}

RAMコスト： コンテキスト長はモデルが使用するRAMに直接影響します。8GBマシンで7Bモデルをn_ctx = 32768で動かすと、OOMエラーや著しい速度低下が発生する可能性があります。実用的な計算式：

コンテキスト用RAM ≈ Q4量子化モデルの場合 n_ctx × 2バイト

つまりn_ctx = 8192はコンテキスト保存だけで約16MB——十分管理可能です。n_ctx = 32768は約64MB。モデルの重み自体が大半を占め、コンテキストはその上に積み上がります。

品質の崖： コンテキストウィンドウの末端では、ほとんどのモデルは一貫性を失い始めます——技術的にはまだウィンドウ内にあっても、冒頭で言われたことを「忘れる」のです。信頼性の高いコーディング支援のために、実際のコンテンツを設定したcontext_lengthの70〜80%以内に収めてください。n_ctx = 8192を設定した場合、実用的な上限は6,000トークンと考えてください。

🛑 `stop`トークンとは？

stopトークンはモデルに伝えます：「出力にこの文字列が現れたら、即座に生成を止めよ」

設定しない場合、モデルは論理的な終点を超えて生成を続けます——余分な説明を加えたり、続きのコードを考案したり、繰り返したりします。

{
  "stop": ["```", "# END", "\n\n\n"]
}

コードにとって特に重要な理由

コードブロック内に関数を書くよう依頼した場合、閉じるトリプルバッククォートで止まってほしいはずです。stopトークンがないと、多くの場合こうなります：

stopトークンなし：

```python
def calculate_tax(amount):
    return amount * 0.07

異なる税率を扱えるよう拡張することもできます：

def calculate_tax(amount, rate=0.07):
    ...

実は、もっと良いバージョンがあります…


**"stop": ["`"]あり：**

def calculate_tax(amount):
    return amount * 0.07


クリーン。完了。

### コーディングタスクに役立つstopトークン：

| ユースケース | stopの値 |
|---|---|
| コードブロック出力 | ` "`" ` |
| 単一関数、散文なし | "\ndef " （次の関数定義の前で停止）|
| 構造化JSON出力 | "}" + 手動カウント、またはスキーマ検証 |
| diff/patch出力 | "---" |
| 冗長な説明の防止 | "\n\n\n" （3つの空行）|

---

## ⚙️ LM Studioのコーディング向け完全推奨設定

前回のtop_p/top_k/repeat_penaltyの設定と組み合わせた完全版：

```json
{
  "temperature": 0.2,
  "top_k": 40,
  "top_p": 0.9,
  "repeat_penalty": 1.05,
  "n_ctx": 8192,
  "max_tokens": 2048,
  "stop": ["```", "\n\n\n"],
  "seed": -1
}

🧠 コード向けに実際に機能するシステムプロンプトの書き方

これら3つのパラメータは、適切に書かれたシステムプロンプトと組み合わせることで大幅に力を発揮します。システムプロンプトはコーディング会話が始まる前にモデルの役割と制約を設定します——context_lengthの一部を消費するため、簡潔に保ちましょう。

優れたコーディング用システムプロンプトの条件：

言語とスタイルを明確に指定：

You are a Python 3.11 backend developer. Use type hints on all functions.
Follow PEP 8. Prefer standard library over third-party packages unless necessary.

出力フォーマットの期待値を設定：

When writing code, output only the code block with no explanation before or after,
unless explicitly asked. Use triple backtick fences.

プロジェクトの制約を確立：

This project uses FastAPI 0.111, PostgreSQL 16, and Python 3.11.
No Django. No SQLAlchemy — use raw asyncpg for database queries.

Simplicoのバックエンド作業で実際に使用しているシステムプロンプト：

You are a senior backend engineer. Stack: FastAPI, Python 3.11, PostgreSQL with asyncpg, pgvector.
Always use async/await. Use type hints. Follow PEP 8.
Output code only — no explanations unless asked. Use triple backticks.
If the task is ambiguous, ask one clarifying question before writing code.
Do not hallucinate library names. If unsure about an API, say so.

このプロンプトは約80〜100トークン——8,192トークンのコンテキストのごく一部です。その投資効果は絶大で、スタックの間違いが減り、出力フォーマットがクリーンになり、モデルが仮定する前に確認するようになります。

日本語プロジェクト向け追加指示の例：

インボイス制度に関連する機能では、適格請求書発行事業者番号（登録番号）を
必ずバリデーションロジックに含めること。消費税は標準税率10%、
軽減税率8%の両方を考慮した実装とすること。

🧮 全パラメータの相互作用まとめ

パラメータ	制御対象	コード向け推奨値
`temperature`	選択への確信度	0.1〜0.3
`top_k`	考慮するトークン候補数	20〜50
`top_p`	含まれる確率マスの量	0.85〜0.9
`repeat_penalty`	直近トークンの繰り返し抑制	1.05〜1.1
`n_ctx`	一度に「見える」量	ほとんどのタスクで8,192
`stop`	生成を止めるポイント	`""` `+` "\n\n\n"`