慎重に書き出したい。本稿は流出資料の悪用やシステムの脱獄(ジェイルブレイク)に関する話ではございません。私はそのいずれにも関心がなく、本物の事業を運営している人間も同じであるべきだと考えております。私の関心は別のところにある――綿密に設計された本番運用のシステムプロンプトの構造が、現実世界で実際に機能するAIエージェントへの指示書(プレッシャー下、スケール時、しかも壊そうとする実ユーザーの存在下で)について何を教えてくれるか、その一点でございます。
Anthropicは、関連する内容の多くを自社で公開している――公式システムプロンプト・リリースノートを参照のこと――そしてSimon Willison氏は、これらプロンプトの構造とその含意について、最も優れた公開記録者であり続けております。流出プロンプトに価値があるのは、秘密を暴くからではございません。本気の本番スケールにおいて、自分が何をしているか本当に分かっているチームが、どのように強力なモデルへの指示書を書いているかを、生々しく示してくれるからでございます。そしてその書き方は、ほとんどの創業者やオペレーターがエージェントにプロンプトを渡すときの書き方とは、ほぼ似ても似つかない。
教訓1:構造そのものが指示です
本気の本番プロンプトを読んだとき、まず誰もが圧倒されるのは構造的足場の量でございます。見出し付きのセクション。番号付きのルール。明示的な役割定義。指示カテゴリーごとのXML風タグ。これは様式の問題ではございません。構造そのものが指示なのでございます。
モデルに長文の壁を投げつければ、モデルはプロンプトの各部分が何を意味し、互いにどう関係するのかを推論しなければなりません。一方、明示的な構造を与えれば――「このセクションは安全について、このセクションはツール使用について、このセクションは拒否について」――見出しを書き終えた時点で、プロンプトエンジニアリングの半分はすでに完了しております。
私の知る創業者の多くは、メールのようなプロンプトを書く。挨拶、段落、依頼、結びの言葉。それは、自社をよく知る優秀なインターンには通用する。しかし、敵対的条件下で大規模に動作するモデルには通用しない。
教訓2:ルールは事例に勝る。事例は抽象論に勝る。
本気の本番プロンプトには、極めて具体的なレイヤリングがございます。最上部にハードルール(「決してXをしない」)。中段に具体的事例。最下層にフォールバックとしての抽象原則。流出したClaude Codeのプロンプトは、ほぼこのパターンを完璧になぞっております。
ところが、ほとんどのオペレーターが書くプロンプトは正反対だ。「役に立ち、正確であれ」といった曖昧な抽象論から始まり、ハードルールも具体例も提示されない。モデルは精一杯対応するが、錨がない。ゆえに振る舞いは、予測も再現もデバッグもできない方向にドリフトしていく。
私が熟読の末に得た結論はこうだ。エージェントに与えるすべての指示には、正しいアウトプットが何であるかを示す具体例を最低一つ含めるべきでございます。その例を書けないなら、自分自身が要求内容を理解できていないということだ――そしてエージェントは確実に理解できません。
欲しいものの良いサンプルをエージェントに見せられないなら、エージェントはそれを生成できません。サンプルこそが仕様(spec)です。
教訓3:拒否動作はセーフティ問題ではなく、設計問題です
プロンプトの大部分は、モデルが何かを断るべきタイミングと方法に充てられております。「違法なこと」だけではございません。拒否すべき場面、押し返すべき場面、明確化を求めるべき場面、進めて構わない場面――これらの完全な分類学(タクソノミー)が存在する。そしてその分類学は、想定されたものではなく、設計されたものでございます。
自社向けにエージェント製品を構築しているなら、「拒否」動作は後付けの装飾ではございません。プロンプトの中で最も高レバレッジな部分でございます。なぜなら、エージェントが「もっと情報が必要です」と言うべき場面で「最善を尽くします」と答えるたびに――あるいは「やってみるべき場面」で「お手伝いできません」と答えるたびに――ユーザーの信頼を焼却し、ユーザーにエージェントを迂回することを学習させているからでございます。「言ったことをやる、やることを言う」――この信条はエージェントにも当てはまる。エージェントが「やること」と「やらないこと」の境界線を明確に引けないなら、やるべきでないことにイエスと答え、やるべきことにノーと答える。
ハッピーパスを設計する前に、拒否分類学を設計せよ。それが大人の動きだ。
教訓4:ツール使用の指示は、タスク指示よりも多くの語数を割く価値がある
そのプロンプトの中では、「いつ・どのようにツールを使うか」に関する指示が、「何のタスクを実行するか」の指示よりも遥かに長い。これは偶然ではございません。ツール使用こそが、現実世界でエージェントが失敗する場所だからでございます。間違ったツールの呼び出し。正しいツールに間違った引数を渡す呼び出し。間違った順序での呼び出し。先に明確化を求めるべき場面でツールを呼び出してしまうこと。
自社のエージェントが何らかのツール――データベース、API、ファイルシステム、検索インデックス――にアクセスできるなら、プロンプトエンジニアリングの少なくとも60%の時間をツール使用の指示に費やすべきでございます。人格設定でも、トーンでもございません。各ツールにいつ手を伸ばすべきか、そしてツールが言った通りに動作したかをどう検証するか――その機構そのものに費やすべきでございます。
教訓5:プロンプトは会話ではなく、ポリシーです
本物の本番プロンプトを読んで得られた、最も重要な思考の転換がこれでございます。システムプロンプトはメッセージではございません。ポリシーでございます。エージェントが従う「成文憲法」でございます。法務文書のように書かれるべきだ――精緻に、曖昧さなく、矛盾するルール間の優先順位を明示し、エッジケースを具体的な言語で記述すべきでございます。
ところが、多くの創業者が書くプロンプトは会話調でございます。新入社員に送るSlackメッセージのように読める。結果として生まれるエージェントは、5分のオンボーディングしか受けていない新入社員のように振る舞う。熱心。おおむね役立つ。時折、致命的。日によって一貫しない。
エージェントのシステムプロンプトを、弁護士が読むつもりで書き直してほしい。エージェントに弁護士のように喋らせたいからではございません。そう書くために必要な精度こそが、1,000人のユーザーが同時にエージェントを叩き続けたときに一貫した動作をさせるために、まさに必要なものだからでございます。
読了後にカン氏が実際に変えたこと
自分のツールに対するプロンプトの書き方について、実用的に変更したのは次の3点でございます。
- 新しいエージェントプロンプトは必ず構造アウトラインから書き始める――役割、ハードルール、ツール使用指示、事例、拒否分類学、エッジケース――内容を一文書き始める前に、まずそこを固める。
- 主要な指示一つにつき、最低3つの具体例を書くことを自分に強制する。書けないなら、その指示はまだ十分に定義されていないということだ。それは敗北ではなくシグナルでございます。
- プロンプトをバージョン管理されたポリシーとして扱う。すべての変更にはコミットメッセージを付ける。すべての変更は同じシナリオセットでテストする。深夜1時のカウボーイ編集は禁じる。
これらの習慣を身につけるのに、流出プロンプトを読む必要はない。しかし、もし本気の本番プロンプトを手にする機会があれば――虚心に、注意深く、一度読んでみてほしい。本稿を含むプロンプトエンジニアリング関連のいかなるブログ投稿よりも、AIエージェントへの指示の与え方について多くを教えてくれる。
挑戦はこうだ。今、自分の最重要エージェントを動かしているシステムプロンプトを開いてほしい。契約書を監査する弁護士の目で、一文ずつ読んでいただきたい。一文ごとに問うこと――このルールは具体的か、サンプルがあるか、矛盾が生じたとき優先順位は耐えうるか。この三つのうち一つでもノーがあれば、今週中に書き直すこと。動くエージェントと、火曜の午後に恥をかかせるエージェントとの差は、ほぼ常にモデルではなく、プロンプトの中にある。
以上を日々のオペレーションにどう組み込んでいるかについては、オペレーターのコックピットの内側にあるAIを併せてご覧いただきたい。