AI開発と実務活用のヒントを発信中

ChatGPTへの禁止事項は短く書く。否定文を増やしすぎないプロンプト設計

ChatGPTに作業を頼むとき、安全のために禁止事項をたくさん書きたくなることがあります。

「これはしないでください」 「あれも禁止です」 「この操作は絶対に避けてください」

気持ちは分かります。AIに勝手なことをされたくないので、先回りして止めたくなります。

ただ、禁止事項を長く強く書けば書くほど、安全になるとは限りません。自分もChatGPTで作業用プロンプトを整理していたとき、危ない操作を避けるつもりで禁止事項を多めに書いたら、Codex側で入力が弾かれました。

この記事では、その失敗をもとに、ChatGPTへ安全指示を書くときの考え方を整理します。結論は単純です。禁止リストを増やすより、望む行動、確認条件、止まる条件を書くほうが扱いやすいです

安全指示は「危険なことを全部書く」より、「どう進めるか」を書くほうが安定します。禁止事項は短くし、判断が必要な場面では確認フローに変換します。

目次

禁止事項を書き足したらCodexで止まった

最初に起きたことを書きます。

ChatGPTで、作業用のプロンプトを作っていました。目的は、AIに安全に作業してもらうことです。そこで、自分は「してほしくないこと」をかなり細かく書きました。

たとえば、削除、外部送信、認証情報、破壊的な操作のような話題です。もちろん、それらを実行させたいわけではありません。むしろ逆で、避けてほしいから書いていました。

ところが、そのプロンプトをCodexに渡したところ、入力が安全側で止まりました。こちらの意図は「やらないで」でも、入力の中には危ない操作名が並んでいたわけです。

tomo

安全にしたつもりの文章が、入力としては危ない話題の密度が高い文章に見える。このズレが今回の出発点です。

安全にしたつもりのプロンプトが危険に見えることがある

安全判定の内部仕様を外から断定することはできません。ここは推測で言い切らないほうがよいです。

ただ、入力を分類する仕組みでは、テキストに含まれる語句や文脈が判断材料になります。OpenAIのモデレーション機能も、テキストや画像に含まれる有害な内容を検出するための分類として説明されています。

つまり、「危険なことをしないで」と書いていても、その文章自体には危険な操作名が含まれます。否定しているかどうかだけでなく、入力全体として何の話題がどれくらい出ているかも見られうる、と考えたほうが実務では安全です。

「やるな」と書いても危険語は入力に残る

次のようなプロンプトを考えます。

Markdown
危険な操作は絶対にしないでください。
本番環境や秘密情報に関わる操作は禁止です。
削除や外部送信につながる作業も禁止です。

人間が読むと、これは安全のための注意に見えます。けれど、入力に含まれる語彙だけを見ると、危ない話題が何度も出ています。

ここで大事なのは、禁止文そのものが悪いわけではないことです。問題は、禁止文を増やしすぎると、プロンプト全体が「危険な話題の一覧」に近づいてしまうことです。

禁止のつもりでも、危険な操作名を大量に並べると、プロンプト全体の印象が変わります。

否定文は意図よりも語彙が目立つ

ChatGPTへの指示では、こちらの意図と、入力として見える文字列を分けて考える必要があります。

こちらの意図は「安全に進めたい」です。けれど、文字列としては「危険な操作名を何度も含む文章」になっていることがあります。安全判定に限らず、モデルの応答もこの影響を受けます。

禁止していても危険な操作名はプロンプトに含まれる

たとえば、次の2つは目的が近いです。

Markdown
危険な操作をしないでください。削除、外部送信、秘密情報の表示、本番環境の変更は禁止です。
Markdown
手元の環境や外部サービスに影響する操作が必要な場合は、実行前に対象、理由、影響範囲を説明して確認を取ってください。

前者は、禁止対象を並べています。後者は、AIに取ってほしい行動を書いています。

人間が読むと、どちらも安全を意識した指示です。ただ、AIに渡すプロンプトとしては後者のほうが次の行動が分かりやすいです。AIは「止まる」「説明する」「確認を取る」という動きに変換できます。

強い禁止文ほど危険な話題の密度が上がる

安全指示を書くときほど、語気が強くなりがちです。

Markdown
絶対に実行しないでください。
いかなる場合も禁止です。
少しでも該当する場合は拒否してください。

この書き方は、人間には強い注意として伝わります。ただ、AIにとっては「何をすればよいか」が増えているわけではありません。

さらに、強い否定文を重ねると、プロンプト全体が緊張した文章になります。すると、AIが必要以上に保守的に止まる、または何を許可してよいか分からず曖昧な返答をすることがあります。

禁止リストが長いとAIの動きも不安定になる

禁止事項の書きすぎは、安全判定だけの問題ではありません。ChatGPTの応答そのものも扱いにくくなります。

長い禁止リストは、人間が読んでも疲れます。AIにとっても、重要な指示、例外条件、作業のゴールが埋もれやすくなります。

重要なルールが長いリストに埋もれる

たとえば、次のようなプロンプトです。

Markdown
あなたは安全に作業してください。
Aは禁止です。
Bは禁止です。
Cは禁止です。
Dは禁止です。
Eは禁止です。
作業後は要点をまとめてください。

本当に大事なのは、最後の「作業後は要点をまとめてください」かもしれません。けれど、禁止事項が長いと、完了条件や出力形式が後ろに追いやられます。

OpenAIのプロンプト作成の基本でも、指示を具体的にし、望む出力や形式を明確にする考え方が紹介されています。安全指示も同じで、禁止だけではなく、完了条件や確認方法まで書いたほうが安定します。

「しないこと」だけでは次の行動が決まらない

「削除しないで」と言われたAIは、削除を避けることはできます。けれど、削除が必要そうに見える場面でどうすればよいかは、まだ決まっていません。

そこで、次の行動まで書きます。

Markdown
ファイル削除が必要に見える場合は、削除せず、対象ファイル名と理由を説明して確認を求めてください。

この書き方なら、AIは迷いにくくなります。禁止ではなく、分岐を書いているからです。

tomo

AIに安全に動いてほしいときは、「やめて」だけで終わらせず、「その場面ではこうして」と続けるのがコツです。

禁止ではなく望む行動を書く

ここからは、実際にどう書き換えるかを見ます。

安全指示を書くときは、危険な操作名をできるだけ増やさず、AIが取るべき行動に寄せます。完全に禁止語をゼロにする必要はありません。必要な語は使って構いません。ただし、一覧表のように並べすぎないほうがいいです。

悪いプロンプト例: 危険語を並べた禁止リスト

悪い例です。

Markdown
危険な操作は絶対にしないでください。
削除は禁止です。
上書きは禁止です。
外部送信は禁止です。
秘密情報に触れる操作は禁止です。
本番環境に影響する操作は禁止です。
破壊的なコマンドは禁止です。

言いたいことは分かります。ただ、この形だと禁止対象の列挙になっています。ChatGPTもCodexも、次に何をすればよいかを読み取りにくいです。

良いプロンプト例: 確認条件と停止条件を書く

同じ意図を、行動方針に変えます。

Markdown
作業は読み取りと提案を優先してください。
手元のファイル、設定、外部サービスに影響する操作が必要に見える場合は、実行せずに止まってください。
そのうえで、対象、理由、影響範囲、代替案を短く説明してください。
ユーザーが明示的に承認した場合だけ、次の操作へ進んでください。

こちらのほうが、AIの行動が決まります。

  • まず読む
  • 影響がある操作では止まる
  • 対象と理由を説明する
  • 承認があれば進む

禁止事項を何十個も並べるより、この流れのほうが実務では使いやすいです。

書き換えテンプレート: 「しないで」ではなく「こう進めて」

書き換えるときは、次の型を使えます。

Markdown
<危ない場面> が必要に見える場合は、すぐ実行せずに止まってください。
実行前に <対象>、<理由>、<影響範囲>、<代替案> を説明してください。
ユーザーが承認した場合だけ、次の作業へ進んでください。

たとえば、ファイル操作ならこうです。

Markdown
ファイルの作成、変更、削除が必要に見える場合は、実行前に対象ファイルと変更理由を説明してください。
削除や大きな置換は、ユーザーが承認した場合だけ実行してください。

外部サービスならこうです。

Markdown
外部サービスに書き込む操作が必要に見える場合は、実行せずに止まってください。
送信先、送信内容、取り消し可否を説明し、ユーザーの承認を待ってください。

禁止文をゼロにするのではなく、禁止文を確認フローに変える。このくらいの考え方が現実的です。

共通プロンプトに書くこと、書きすぎないこと

ChatGPTのカスタム指示や作業用プロンプトに入れるなら、毎回使う判断基準だけに絞ります。

長くしすぎると、毎回の作業に関係ない指示まで混ざります。すると、ChatGPTが過剰に止まったり、重要なゴールを見落としたりします。

書くべきこと: 目的、作業範囲、確認条件、完了条件

共通プロンプトに入れやすいのは、次のような項目です。

  • どんな役割で答えるか
  • どの範囲で作業するか
  • 判断に迷ったら何を確認するか
  • 何をもって完了とするか

たとえば、技術記事の下書きを頼むなら、こう書けます。

Markdown
技術ブログ向けに、簡潔で具体的な日本語で書いてください。
仕様や料金など変わりやすい情報は、断定せず確認が必要な点として扱ってください。
読者が次に取れる行動が分かる形で締めてください。

コーディング支援なら、こうです。

Markdown
まず目的と影響範囲を確認してください。
実装に入る前に、変更する予定のファイルと確認コマンドを示してください。
作業後は、変更点と確認結果を短く報告してください。

どちらも、危険な操作名を長く並べていません。それでも、AIの動きはかなり制御できます。

書きすぎないこと: 危険操作名の長い列挙

共通プロンプトに向かないのは、危険操作名の細かすぎる列挙です。

たとえば、考えられる危険操作を全部入れようとすると、プロンプトはすぐ長くなります。しかも、新しい作業のたびに関係ない禁止事項まで読み込まれます。

共通指示は短く保ち、個別の作業で必要な制約はその場で足すほうが扱いやすいです。

必要なら禁止ではなく承認フローにする

どうしても止めたい操作があるなら、単に「禁止」と書くより、承認フローにします。

Markdown
影響範囲が大きい操作は、提案までに留めてください。
実行が必要な場合は、操作内容を1つずつ分けて提示し、承認を待ってください。

この形なら、ChatGPTは「拒否する」だけではなく、「提案する」「分けて提示する」「承認を待つ」という行動を選べます。

安全性は、強い言葉だけでは上がりません。実務では、どこで止まり、何を説明し、誰が承認するかを決めたほうが安全に近づきます。

まとめ

ChatGPTへの安全指示は、長く強い禁止リストにすると、かえって扱いにくくなることがあります。

  • 「やるな」と書いても、危険な操作名は入力に残る
  • 禁止事項を並べすぎると、プロンプト全体で危険な話題の密度が上がる
  • 「しないこと」だけでは、AIの次の行動が決まらない
  • 共通プロンプトには、目的、作業範囲、確認条件、完了条件を書く
  • 危ない場面は、禁止ではなく承認フローに変換する

今回のCodexで止まった実例は、禁止事項の書き方を見直すきっかけになりました。安全にしたいなら、危険な単語を増やすより、AIが迷ったときの動きを決める。まずはそこからで十分です。

よかったらシェアしてね!
  • URLをコピーしました!
目次