ServiceDock
2026年8月17日 更新
約4分で読めます
AIに守ってほしい決まりごとがあるとき、会話の最初に伝えるか、毎回送る指示として置くかで扱いが分かれます。後者がシステムプロンプトです。
履歴の削られ方を積み上げたところ、会話の中で伝えた決まりごとは9往復目に消えました。しかも消えたことは動作からしか分かりません。
履歴の削られ方を積み上げました。会話の中の決まりごとは9往復目に消え、毎回送る側は20往復で1,200トークンを使います。
システムプロンプトに置くかどうかで何が変わるのかを、往復ごとに積み上げました。題材は「金額は税込で答える」といった3つの決まりごとです。
断っておくと、これはモデルを動かした実測ではありません。履歴が上限で削られる条件を置いて追った計算です。置いた値はコードに書いてあります。
const RULE_TOK = 60;
const PER_TURN = 900;
const LIMIT = 8000;
// A: 会話の1往復目で決まりごとを伝える。履歴が削られると一緒に消える
function inConversation(turn) {
const fit = Math.floor(LIMIT / PER_TURN); // 履歴に入る往復数
const oldest = Math.max(1, turn - fit + 1); // 残っている最古の往復
return { alive: oldest <= 1, sent: RULE_TOK, oldest };
}
// B: 毎回送る指示に置く。履歴とは別枠なので削られない
function inSystem(turn) {
return { alive: true, sent: RULE_TOK * turn, oldest: 1 };
}
往復 会話の中で伝える 毎回送る指示に置く 1回 効いている 効いている 5回 効いている 効いている 9回 消えた 効いている 10回 消えた 効いている 15回 消えた 効いている 20回 消えた 効いている 会話の中で伝えた決まりごとが消えるのは 9往復目 20往復ぶんで、決まりごとの送信に使うトークン量 会話の中で伝える: 60 tok（1回だけ。ただし途中で消える） 毎回送る指示に置く: 1200 tok（毎回送るぶん） 差: 1140 tok
8往復目までは差がありません。差が出るのは履歴が上限に当たってからで、そこで会話の中の決まりごとだけが消えます。
この消え方が厄介です。エラーは出ません。税抜きの金額が返ってきて初めて、決まりごとが効いていないと気づきます。
しかも気づくのは、決まりごとを外れた出力が実際に出たときだけです。外れなかった往復では、消えていても分かりません。
毎回送る側は20往復で1,200トークンを使います。会話の中で伝える方式との差は1,140トークンです。安いのは会話方式ですが、途中で消えます。
履歴に置いた決まりごとは、上限に当たった時点で静かに消える。
System prompts should be extremely clear and use simple, direct language that presents ideas at the right altitude for the agent.原文Anthropic Engineering「Effective context engineering for AI agents」 この内容の有効期限2027-02-17
毎回まとめて送られる指示です。役割、守ってほしい決まりごと、返してほしい形式を置きます。
システムプロンプトは、会話の内容とは別に、毎回まとめて送られる指示です。会話が何往復進んでも、同じものが毎回送られます。
4番目に注意してください。今日の依頼をここに書くと、明日も同じ依頼が送られ続けます。
Anthropicは、プロンプト設計の主眼が効果的なプロンプト、とりわけシステムプロンプトをどう書くかにあるとしています。ここに何を書くかが、動作の土台になるという整理です。
同じ文書では、システムプロンプトは明確で、単純で直接的な言葉を使い、相手にとってちょうどよい粒度で示すべきだとも述べられています。細かすぎても抽象的すぎても効きません。
違いは1点で、削られるかどうかです。会話の中身は履歴の一部なので、上限に当たれば古い順に消えます。システムプロンプトは別枠なので残ります。
運用していて気づいたのは、書いたまま誰も検証していない指示が溜まることでした。消しても動作が変わらない行は、毎回送られているだけで何もしていません。編集部では、1行ずつ外して動作が変わるかを確かめるようにしています。
As the term implies, the primary focus of prompt engineering is how to write effective prompts, particularly system prompts.原文Anthropic Engineering「Effective context engineering for AI agents」 この内容の有効期限2027-02-17
期待する動作を過不足なく示せる最小限です。増やすほど毎回の送信量が増え、指示どうしの優先順位も曖昧になります。
システムプロンプトの分量は、足りないと動作が安定せず、多すぎると効かなくなるという両側から挟まれます。
Anthropicは基準を明確に示しています。構成の仕方に関わらず、期待する動作を完全に示せる最小限の情報を目指すべきだ、という書き方です。
つまり短ければよいのでも、詳しければよいのでもありません。動作が決まる分だけ書いて、そこで止めるという基準になります。
指示が増えると、内容が衝突しはじめます。「簡潔に答える」と「根拠を必ず示す」を同時に書くと、どちらを優先するかは書かれていません。
対処は2つあります。衝突する指示を減らすか、優先順位を明示することです。前者のほうが確実に効きます。
書いた指示が実際に効いているかは、外して動作が変わるかを見れば分かります。変わらないなら、毎回送っているだけの行です。
20往復で1,200トークンという前の節の数字は、決まりごと3つぶんです。指示が10倍になれば、その分だけ毎回の送信量に乗り続けます。文脈全体の設計はコンテキスト設計の記事で扱っています。
足りなくても多すぎても効かない。動作が決まる分だけ書く。
Regardless of how you decide to structure your system prompt, you should be striving for the minimal set of information that fully outlines your expected behavior.原文Anthropic Engineering「Effective context engineering for AI agents」 この内容の有効期限2027-02-17
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る