- 公開日
重要なルールを埋もれさせないためには、先に「何が保たれれば合格か」を決め、同じ意味の指示をまとめ、同時に満たせない指示の扱いを決めます。整理後は、同じ資料と判定基準で回答を比べ、必要な条件が消えていないか確かめます。指示の数が減ったことだけでは、守られやすくなったとは判断できません。
失敗するたびに注意書きを足していると、古い例外や別の用途の指示が残ることがあります。見直す対象は、文章の長さだけでなく、それぞれの指示がどの場面で何を求めているかです。ここでは、日常業務の依頼文を整理する手順と、変更で以前の条件が壊れていないかを確かめる方法を扱います。
削る前に、残す条件を決める
まず、いま使っている依頼文を保存し、作業の目的と失敗した場合の困りごとを確認します。たとえば告知文の下書きなら、日時を変えないこと、資料にない連絡先を作らないこと、許可なく送信しないことが候補になります。文体や文字数も必要ですが、これらと衝突した場合にどうするかを決めておきます。
整理の材料として、今のルールを一文ずつ書き出し、いつ、なぜ追加したかを添えます。追加した理由が分からないルールは、すぐに削らず確認対象にします。統合や削除をした条件も記録しておけば、後の確認で欠落が見つかったときに原因を追えます。
重要条件を「正しく」「安全に」とだけ書くと、整理の前後で同じ意味が残ったかを判定できません。「資料に記載のない問い合わせ先は未確認と表示する」のように、対象、条件、求める行動まで具体化します。条件の選択は業務担当者が行い、AIに依頼文を短くさせる場合も、その判断まで任せきりにはしません。
AnthropicのPrompt engineering overviewは、プロンプトを改善する前提として、成功基準とそれを実際に確かめる方法を挙げています［1］。以下の整理方法は、この考え方を告知文作成へ当てはめた提案です。特定の指示数を適正値とするものではありません。
重複と競合を、意味で分ける
重複は、同じ場面で同じ行動を求める指示が重なっている状態です。「メールを送らない」と「自動配信しない」がこの作業で同じ対象を指すなら、「下書きの作成まで。送信操作は行わない」にまとめられます。一方、「社外へ送らない」は社内送信を許すようにも読めるため、同じ意味として置き換えられません。
競合は、ある入力に対して、複数の指示を同時に満たせない状態です。「すべての欄を埋める」と「資料にない値を補わない」は、欠落のある資料で衝突します。この場合は一方を黙って削るより、「資料にない欄は未確認と記す」と、欠落時の扱いを決める方が、依頼の目的を追えます。
似て見えても、適用条件が違うルールは残します。「社外向けは製品名を正式表記にする」と「社内向けは承認された略称を使える」は、対象を明示すれば両立します。共通の指示と今回だけの条件を分けて置くと、別の作業から残った指示も見つけやすくなります。
Claudeの組織向け指示について、AnthropicのSet organization instructionsは、具体的で明確な指示、指示全体の整合性、変更後のテストを勧めています［2］。ただし、これは指示を減らすほど全モデルの遵守率が上がるという実験結果ではありません。削除の判断には、残したい意味と実際の回答の照合が必要です。
架空の告知文で、整理前後を比べる
社内ポータルの保守案内を作る架空例を考えます。元資料には、次の情報だけがあるとします。
- 作業：社内ポータルの定期保守
- 日時：2026年11月12日18時〜19時、日本時間
- 対象：全社員
- 影響：保守中はポータルを閲覧できない
問い合わせ先の記載はありません。業務担当者は「資料に忠実な下書きを作る」「不足は見える形で残す」「送信しない」を重要条件とし、120字以内という希望より優先すると決めたものとします。
整理前の依頼文は、次のようなものです。
資料から案内文を作ってください。
事実だけを書いてください。
推測しないでください。
日時・対象・影響・問い合わせ先を必ず入れ、空欄をなくしてください。
不足する項目は一般的な内容で補ってください。
120字以内にしてください。
重要事項は省かないでください。
メールを送らないでください。
自動配信しないでください。ここでは、事実に関する重複に加えて、欠落を補う指示との競合があります。また、文字数に収まらない場合の扱いも不明です。整理後は次のようにできます。
以下の資料だけを使い、社内向けの保守案内の下書きを作ってください。
日時・対象・影響・問い合わせ先を示し、記載がない項目は『未確認』としてください。
日時は、開始・終了の時刻とタイムゾーン（日本時間）まで資料どおりに残してください。
120字以内を目安にしますが、必要項目と未確認の表示を優先してください。
超える場合は、下書きの後に理由を添えてください。
作業は下書きの作成までとし、送信操作は行わないでください。期待する下書きの一例は、「全社員向け：社内ポータルの定期保守を2026年11月12日18時〜19時（日本時間）に行います。保守中は閲覧できません。問い合わせ先：未確認」です。これは説明用の期待出力であり、モデルで実行して得た結果ではありません。
変更したのは、重複のまとめ方、欠落時の行動、文字数と必要項目の優先関係です。元資料、下書きという目的、日時や影響の意味、送信しないという条件は変えていません。「問い合わせ先：情報システム部」と補えば、もっともらしくてもこの例では不合格です。未確認という表示は、現実に窓口が未決定という意味ではなく、提供資料で確認できないという意味です。
実務で使うときは資料と必要項目を差し替え、文字数の制限が単なる希望か、掲載先の厳格な上限かも確かめます。上限が必須なら、勝手に超過させず、短縮案の再作成や掲載方法の相談へ進む指示に変えます。
回帰確認では、以前守れていた条件も見る
回帰確認とは、変更によって、それまで満たしていた条件が壊れていないかを調べることです。整理前後の依頼文をそれぞれ新しい会話で使い、モデル、設定、資料、利用できるツール、判定基準を揃えて比較します。会話履歴を含む業務なら、比較に必要な履歴も同じにします。
確認用の資料には、項目が揃ったものだけでなく、問い合わせ先がないものや、文字数に収まりにくいものも入れます。OpenAIのEvaluation best practicesも、評価目的と基準を定めた比較、変更ごとの評価、通常例に加えた境界事例などの確認を勧めています［3］。
告知文の例では、次のように期待結果と確認方法を対応させます。
- 全項目がある資料：必要項目を原文と照合します。窓口があるのに未確認と出した場合も、抽出漏れとして直します。
- 問い合わせ先がない資料：未確認の表示があり、部署名や連絡先を創作していないかを見ます。埋めてしまった場合は、不足時の指示を見直します。
- 必要項目が長い資料：文字数の希望より必要な内容を優先し、超過理由が添えられているかを見ます。日時や影響を落とした場合は、整理後の版を採用せず修正します。
記録には依頼文の版、入力資料、設定、出力、条件ごとの判定を残します。原資料を入手できず判定できない項目は、合格に含めず未確認にします。同じ入力でも回答が変わることがあるため［3］、繰り返し試した回数も記録します。少数の例で問題がなかっただけで、今後の全回答が条件を守るとは扱いません。
比較で良くなったとしても、今回の変更には重複削除と競合解消の両方が含まれます。その結果を「指示数を減らした効果」とだけ説明することはできません。目的はその業務で必要な条件が保たれた版を選ぶことです。
送信禁止は、文章の外でも止める
下書き専用の処理なら、送信機能をAIに提供せず、接続先でも送信権限を与えない設計にします。これなら、AIが送信を提案してしまっても、その経路からは実行できません。OWASPのLLM06:2025 Excessive Agencyは、必要な機能と権限への限定、下流システムでの認可を対策として挙げています［4］。指示・システムでの強制・人間の承認をどう分担するかは、AIの送信をどう制御する？ 指示・システムの強制・人間承認の役割で詳しく説明しています。
確認するときは、外部へ届かない試験環境で、送信要求が拒否されることと、下書き作成は続けられることを分けて見ます。「送信しません」と回答したことだけでは、権限制限を確認したことにはなりません。別の汎用ツールから送信できるなら、その経路も見直します。
依頼文を整理しても、設定変更や試験には手間がかかります。単発の文章作成なら元資料との照合から始め、繰り返し使う依頼文は代表的な入力を保存して、修正のたびに確認します。残す条件、変更した箇所、試した結果が追える形にすれば、短くした際の抜けも、後から追加したルールの必要性も検討できます。
個人向けカスタム指示の矛盾と重複の減らし方は「個人向けカスタム指示を分解して、矛盾と重複を減らす」で解説しています。
固定ルールと動的コンテキストを分けて製品FAQを運用する方法は「固定ルールと動的コンテキストを分けて製品FAQを運用する」で解説しています。
基本から確認する：この記事の前提になる考え方は、「プロンプトの書き方ガイド（依頼文の基本6項目と例文）」にまとめています。
