「指示を増やす」と「制約を設計する」は別の作業

依頼の説明を長く書くことと、制約を渡すことは、似ているようで別の作業です。

説明を増やす行為は「やってほしいこと」の解像度を上げる作業です。一方、制約を渡す行為は「やってはいけないこと」「必ず守る形式」「まだ決まっていない前提」という枠を先に置く作業です。前者だけをいくら積み重ねても、AIが自由に選べる範囲そのものは大きく変わりません。長い説明の中に、結局「これはしないでください」という一文がなければ、AIはその部分を自分の判断で埋めることになります。

検索で上位に出てくる解説の多くは、役割・出力形式・禁止事項・数値・文体といった項目を列挙する形で「制約条件の書き方」を紹介しています。項目そのものは有用ですが、列挙だけで終わると「なぜその項目が効くのか」「どの順番で置くべきか」「増やしすぎるとどうなるか」という構造が抜け落ちやすくなります。relmeaが実務で重視しているのは、この構造の部分です。制約は「AIが自由に選べる範囲を先に区切る作業」として独立に扱うことが、出力のばらつきを抑える出発点になります。

制約は3種類に分けて考える — 除外・形式・前提確認

実務で使う制約は、大きく3種類に分解できます。

  • 除外条件：してはいけないこと・使ってはいけない表現
  • 出力形式：どんな体裁・順序・分量で出すか
  • 前提確認：依頼者側もまだ決めきれていない条件を、AI側から聞き返してもらう仕組み

前の2つは「枠を狭める」制約、3つ目は「枠を狭める前に、足りない情報を埋める」制約です。この違いを意識せずに全部を同列に並べると、設計がぼやけます。

除外条件と出力形式は、プロンプトの先頭付近にまとめて書くようにしています。relmeaの運用では、後半に書かれた条件よりも先頭付近に書かれた条件のほうが安定して守られやすいと捉えており、その前提で制約の置き場所を決めています。これはモデルの内部動作を検証した結果というより、実務上そう扱ったほうが再現性が高いという運用上の判断です。

例：社外向けの一次回答メールを下書きさせる

以下の制約を守って、問い合わせへの一次回答メールを作成してください。

【除外条件】
- 「大変申し訳ございません」を含む謝罪の重複表現は使わない（謝罪は1回のみ）
- 解決策が確定していない段階で「必ず解決します」と断定しない
- 絵文字・感嘆符は使わない

【出力形式】
- 件名・本文・署名欄の3ブロックで出力する
- 本文は300字以内
- 箇条書きは使わず、地の文で書く

【前提】
問い合わせ内容：[ここに要約を入力]
現時点で確定している対応：[ここに入力]
未確定の事項：[ここに入力]

この形にしておくと、「謝罪が重複していないか」「断定していないか」「300字を超えていないか」という、あとから直しにくい崩れを先に防げます。逆に「もう少し柔らかい言い回しに」「一文だけ短く」といった調整は、出力を見てから追加で指示すれば十分です。先に防ぐべき崩れと、あとから直せる崩れを分けて考えることが、制約設計の実務的な出発点になります。

制約は多いほど良いわけではない — 粒度と数の設計

制約を思いつく限り書き並べたくなりますが、数を増やせば増やすほど安定するわけではありません。

制約同士が矛盾していると、AIはどちらか一方を優先し、もう一方を結果的に満たさない出力を返すことがあります。relmeaの運用では、これを「制約を黙って一つ落とす」現象として扱っており、明示的なエラーにならないぶん気づきにくい問題だと考えています。たとえば「300字以内」と「必須項目を5つすべて詳しく説明する」を同時に課すと、両立が難しく、どちらかが崩れる形で出力されることがあります。

粒度についても注意が必要です。「読みやすく書いてください」「簡潔にしてください」といった粒度の粗い制約は、基準が人によって異なるため、AIにとっても解釈の幅が広いままです。一方で「1文を40字以内にする」「箇条書きは1項目2行まで」のように基準を数値化した制約は、解釈の余地が小さくなります。粗い制約を細かい制約に置き換えることが、数を増やすことよりも効果的です。

数の目安として、1つの依頼につき本当に守ってほしい制約を3〜5個程度に絞るようにしています。それ以上になる場合は、次の順番で優先順位をつけます。

  • 最優先：あとから直しにくい崩れを防ぐ制約（除外条件・出力形式）
  • 次点：数値で基準を示せる制約（文字数・項目数など）
  • 任意：あとから追加指示で直せる調整（語調・言い回しの好み）

矛盾のチェックも実務では欠かせません。書き並べた制約を読み合わせ、「この2つを同時に満たせるか」を確認する一手間を入れると、あとから「どちらの制約も中途半端に守られた出力」を受け取るリスクを減らせます。

単発の指示でなく、エージェントの定義に制約を持たせる

ここまでの制約は、1回のチャットのプロンプトに書く前提で説明してきました。ですが、繰り返し使うタスクをAIエージェントに任せている場合、同じ制約を毎回のプロンプトに書き足すのは非効率です。

relmeaは複数のAIエージェントに業務を分担させて事業を運用しており、その中で徹底しているのが「同じ修正を2度受けない」という原則です。ある出力の崩れに気づいたとき、次の会話でその都度言い足すのではなく、そのエージェントの定義そのものを直します。定義に書き込んだ制約は、以降そのエージェントが担当するすべての依頼に自動的に適用されるため、一度直せばそのタスクでは再発しません。

単発のプロンプトに書く制約と、エージェント定義に書く制約は、寿命が違います。単発の制約はその会話が終われば消えます。定義に書いた制約は、次にそのエージェントを使うときも生き続けます。繰り返し発生する業務ほど、制約は「毎回書くもの」ではなく「一度書けば済むもの」として扱ったほうが合理的です。

例：文章生成エージェントの定義に恒久ルールを持たせる

# 文章生成エージェント定義（抜粋）

## 出力の恒久ルール
- 表組み（Markdownテーブル）は使わない。箇条書きで代替する
- 強調記号（太字など）は使わない。強調したい語は見出しか
  「」で表現する
- 断定表現（「必ず」「絶対に」）は根拠となる数値がない場合は
  使わない
- 数値を主張する場合は出典を明記する。出典不明なら
  「不明」と書く

## 変更履歴
- 2026-XX-XX: 表組み崩れの指摘を受け、恒久ルールに追加

この定義を持つエージェントに次から依頼するときは、毎回「表を使わないでください」と書き足す必要がなくなります。手直しのたびに定義側を更新していく運用を続けると、同じ種類の修正依頼は時間とともに減っていきます。これは、単発チャットでのプロンプト改善だけでは得られない効果です。

「制約で縛る」と「聞き返させる」を使い分ける

制約を積み増すことがいつでも正解とは限りません。依頼そのものに、依頼者自身もまだ決めきれていない前提が含まれている場合、制約を増やしても解決しないことがあります。制約は「決まっている条件を守らせる」ための仕組みであり、「決まっていない条件を埋める」ための仕組みではないからです。

前提が足りていない依頼に対しては、制約を書き込むのでなく、AI側から先に聞き返してもらう設計のほうが有効です。たとえば新しい業務フローの設計を相談する場面で、想定する利用者・成功の基準・避けたい条件のどれかが依頼者側でも未確定なことはよくあります。この場合、「本題に入る前に、確認したいことがあれば先に質問してください」という一文を添えるだけで、AIは足りない前提を先に尋ねる振る舞いに変わります。

使い分けの目安は次のとおりです。

  • 定型的に繰り返す業務で、条件がほぼ固定されている場合：制約設計で枠を決める
  • 都度条件が変わる相談ごとで、依頼者自身も条件を決めきれていない場合：先に聞き返させる設計にする

この2つは対立するものではなく、組み合わせて使うものです。繰り返し業務はエージェント定義に制約を持たせ、都度変わる相談ごとには前提確認の一文を添える。依頼の性質を見極めてから、どちらの設計を使うかを選ぶことが、無駄な往復を減らす近道になります。

制約設計はチェックリストでなく設計思想

AIの出力がブレる原因を「指示の書き方」だけで捉えると、いつまでも説明を足す作業から抜け出せません。除外条件・出力形式・前提確認という3種類の制約を切り分け、あとから直しにくい崩れから優先して枠を決める。そして、繰り返し使う業務については、その制約を単発のプロンプトでなくエージェントの定義に持たせ、同じ修正を2度受けない状態を作る。これが、relmeaが実務の中で磨いてきた制約設計の考え方です。

制約は数を競うチェックリストではありません。何を守らせ、何をAIの判断に委ね、何を人に聞き返させるか。その線引きを設計することが、出力の安定につながります。