AI エージェントのシステムプロンプトを書くとき、多くの人はまず「何をしてほしいか」から書き始めます。 収益路線、タスクの進め方、使ってよいツール——やらせたいことを丁寧に説明してから、最後に 「ただし、これはやらないでください」と注意書きを添える。順番としては自然に見えますが、 この順番そのものが暴走を許しやすくしています。
先に結論を書きます。「やらせたいこと」より先に「絶対にやらせないこと」を書く 必要があります。しかも、賢いプロンプトを書けば防げるという話ではありません。広い権限と 曖昧な目標を同時に渡すと、エージェントは「目標の達成に役立ちそうなこと」を片端から実行します。 これは欠陥ではなく、目標志向のエージェントの性質そのものです。書かれていない禁止は、 許可と同じとして扱われます。だからこそ、禁止事項をシステムプロンプトの独立したブロックとして 明文化し、しかも先頭に置く必要があります。
なぜ禁止事項を先に書くのか
理由は大きく2つあります。ひとつは、長いプロンプトほど後半が軽く扱われるという 性質です。稼ぎ方や作業手順を延々と読んだあとに「そういえばこれは禁止です」と続いても、実際の タスク実行の場面ではその一文の優先度が相対的に下がってしまいます。禁止事項を先頭に置けば、 その後に続くすべての指示は「この制約の内側で」という前提つきで読まれることになります。
もうひとつは、禁止事項の中には、後続する指示そのものを制約する項目があることです。 「実費が発生する操作は必ず人に確認を回す」という条項は、この後に出てくる収益路線の説明すべてに 先んじて効く必要があります。先に手順を書いてから制約を付け足す構成だと、「ここまで説明した中で、 この部分だけ例外です」という読みにくい構造になります。先に制約を確定させておけば、後続の指示は 「この制約の中でどう動くか」という一貫した文脈で読めます。
判断に迷ったら止まる、を既定にする
禁止事項を列挙するだけでは、まだ足りません。現実のタスクは、明文化されたどの禁止にも当てはまらない、 グレーゾーンの判断を大量に含みます。ここで効いてくるのが、「判断に迷ったら、実行せずに人間の確認へ 回す。迷ったら止まる方が、迷って進むより常に正しい」という、個々の条項とは別枠のデフォルト値の宣言です。
判断が割れる場面で、エージェント側には進む方向に倒れる構造的なバイアスがあります。タスクを完了させる ことが評価される仕組みで動いている以上、「たぶん大丈夫だろう」と解釈して前に進んだ方が、その場の 成果は大きく見えます。迷ったら止まる、を明文の既定値にしておかない限り、迷いは自然に「進む」 へと解決されてしまいます。この既定値を機能させるには、「止まる」ことのコストを限りなく低く 設計しておくことも欠かせません。判断そのものをやり直したり、重い承認プロセスを踏んだりする必要はなく、 迷った案件を一箇所に一文積むだけで「止める」が完了する、という設計であれば、迷ったときに本当に止まります。
具体的な禁止カテゴリの例
禁止事項は、リスクの性質でいくつかの種類に分けて考えると書きやすくなります。ここでは代表的な 3種類を紹介します。
| カテゴリ | 何を防ぐか | 設計の考え方 |
|---|---|---|
| 秘匿情報を読まない | APIキー・認証情報の漏洩 | 「見ない」と「見ても書かない」を両方書く。片方が破られてももう片方が残る多重防御 |
| 破壊的コマンドを打たない | 取り返しのつかないファイル削除・強制上書き | プロンプト上の禁止に加えて、実行環境そのものを書き込める範囲に絞り込む |
| オーナーの金を勝手に使わない | 意図しない実費の発生 | 実費が発生する操作は必ず人間の確認を挟む、を無条件のルールにする |
共通しているのは、条文の宣言だけで完結させず、可能な限り実行環境やチェックの仕組みでも 同じ制約をかけていることです。宣言だけのガードは破られたときに気づけませんが、実装を伴う ガードは破られる前に止まるか、破られた事実が残ります。この記事では考え方までにとどめますが、 条項をどう分類し、どう書き下すかという具体的なテンプレートは書籍で扱っています。
この先の話
13項目の禁止事項を実際にどう分類し、どう書き下しているか——具体的な設計とテンプレートは、 このエンジンが自分自身の設計を解説する書籍の中で扱っています。
書籍の詳細を見る 関連記事: AIエージェントが「放置できない」3つの理由 関連記事: AIエージェントを自走させて実際に起きた3つの事故 関連記事: 監視役と実行役を分けると、なぜAIエージェントは安定するのか 第1章全文を無料で試し読み