最近、AIに関する議論には必ずと言っていいほど「ルール」という言葉が登場します。
「ハルシネーション（もっともらしい嘘）を絶対に起こさない」「常に真実を述べる」「ユーザーの意図に従う」「安全でないことはしない」といった具合です。
膨大なシステムプロンプトにこれらを詰め込み、「ガードレール」と呼ぶ人もいれば、プロンプトは信頼できないため、すべてを外部から強制すべきだと主張する人もいます。
どちらの立場も、現場で直面している課題への反応ですが、実は全く異なるメカニズムについて話しています。つまり、「ルール」という言葉が多義的に使われすぎているのです。
実用的なAIシステムを理解するためには、**「プロンプト（人間がいかに意図を伝えるか）」と「ルール（システムがいかに制約やポリシーを強制するか）」**を切り分け、それぞれがどこに適しているのかを理解する必要があります。
1. プロンプトは「意図」を表現するためのもの
プロンプトの本質は、自然言語によるガイダンスです。やりたいことを説明し、コンテキストや例を示し、役割やトーンを設定します。するとモデルは、その指示に最も適合するトークンの羅列（回答）を生成します。
これは、以下のような一般的なタスクで非常にうまく機能します。
- 執筆や編集
- 要約
- ブレインストーミング
- 概念の説明
- 対話型アシスタント
これらの領域では、あいまいさは「バグ」ではなく「仕様」です。プロンプトは柔軟で許容度が高いため、多少のミスがあっても人間が修正（イテレーション）すれば問題ありません。
つまり、プロンプトは「決定論的な正しさ」ではなく、「有用性」のために最適化されているのです。
AIを「思考のパートナー」や「クリエイティブ・アシスタント」として使う場合、プロンプトは最適なツールです。そして、これが現在多くの人が日常的にAIに触れているモードです。
2. エンジニアが本来意味する「ルール」とは
エンジニアが「ルール」について語る時、通常はプロンプトの中に隠された日本語や英語の文章を指しているわけではありません。
彼らが意味するのはシステムレベルの制約です。つまり、テキストで何と書いてあろうと、「絶対に違反してはならないこと」を指します。
実務においては、これは**「エージェント・ルール（Agent Rules）」**と呼ばれることもあります。特定のタスクだけでなく、すべての動作に普遍的に適用されるAIの「憲法」のようなものです。毎回書き直す指示とは異なり、システム層に組み込まれ、常に強制されます。
例えば、真のルールとは以下のようなものです。
- 「すべてのコードは TypeScript でなければならない」
- 「生成された出力に API キーを含めてはならない」
- 「データベースへの書き込みには、明示的な人間の承認を必要とする」
これらはプロンプトに書かれた単なる「お願い」ではありません。リンター、バリデーター、承認ワークフロー、アクセス制御などを通じてシステムが強制するポリシーです。
ルールが意味をなすのは、AIがコードリポジトリ、CI/CDパイプライン、API、データベースといった**「実行可能なシステム」**と統合されている場合です。人間が読むだけのテキストを生成するならプロンプトで十分ですが、AIがコマンドを実行したり状態を変更したりする場合は、決定論的な制約が必要になります。
3. なぜプロンプトベースの「ルール」は限界があるのか
プロンプトにどれだけルールを書き並べても、それは所詮「自然言語」に過ぎません。
モデルは決定論的に「従う」のではなく、コンテキストに基づいてもろもろの条件を考慮しながら、最も確率の高い続きの言葉を生成しているだけです。コンテキストが長くなったり、悪意のある入力（アドバーサリアル・アタック）を受けたりすると、十分に訓練されたモデルであっても、初期の指示を誤解したり無視したりすることがあります。
つまり、プロンプトに50個の「〜してはいけない」を詰め込んでも、それは「多くの場合うまくいくガイダンス」にはなりますが、「保証」にはなりません。
ここで、**「スキル（Skills）」**のような構造化されたアプローチが重要になります。ルールを散文で羅列するのではなく、再利用可能な振る舞いのパターンを独立したモジュールとして定義する手法です。例えば、「コードレビュー・スキル」には以下が組み合わされます。
- プロンプトによるガイダンス（トーン、徹底度）
- スキーマの強制（構造化されたフィードバック形式）
- システムチェック（行番号の参照必須、修正案の提示必須）
このレイヤー化されたアプローチは、生のテキストルールよりも信頼性の高い「ソフトな境界線」を作ります。それでもまだ完璧な保証ではありませんが、ミスが実害（コード実行やデータ変更など）を伴うシステムでは、より高い信頼性が求められます。
4. すべての「ルール」が外部にあるわけではない
ここで重要なニュアンスがあります。一部のルールはモデル自体に組み込まれています。
最近のモデルは、RLHF（人間からのフィードバックによる強化学習）やセーフティ・ファインチューニング、あるいは「憲法AI（Constitutional AI）」と呼ばれる手法で訓練されています。これらはプロンプトや外部システムではなく、モデルレベルの挙動です。
例えば：
- 有害なコンテンツの生成を拒否する
- 機密性の高いクエリを慎重に扱う
- 学習から得られた安全性のヒューリスティックを適用する
これらの内部挙動は「ルール」のように感じられ、非常に有用ですが、本質的には依然として「確率的」なものです。システムレベルの強制力とは異なります。
訓練された安全なモデルが、特定の入力に対してハルシネーションを起こしたり、安全でない出力をしたりすることがあるのはそのためです。それはルールの失敗ではなく、確率論的推論の限界なのです。
5. 本当の境界線はどこにあるか
「プロンプトはチャット用、ルールはエージェント用」と言い換えることもできますが、より正確には以下のようになります。
-
プロンプト：エラーのコストが低い場合に適している
（プロンプトを打ち直したり、イテレーションを回したり、人間が修正できる場合） -
ルール：エラーのコストが高い場合に必要となる
（データ、システム、ユーザーの信頼に影響を与えるミスが許されない場合）
これは、チャットボット、医療アシスタント、コードジェネレーター、自律型エージェントなど、何を作るにしても当てはまる原則です。
ネット上でよく見かける「ルール」のリスト（憲法のようなプロンプトなど）は、実際には**「保証のふりをしたソフトな制約」**です。それらはプロンプトを豊かにしますが、挙動を強制するものではありません。
本物のルールとは、可能な限り外部にあり、永続的で、決定論的なものです。
メンタルモデル：AI制御の構造
- プロンプトレイヤーが「意図」を表現する
- モデルが「候補」を生成する
- 制約レイヤーが、システムで実際に「何が許可されるか」を強制する
実践例：エージェント・ルールとスキル
実際の自律型エージェントのシステムにおいて、制約や構造化されたポリシーがどのように機能するのか、特に自然言語のプロンプトを超えて「Agent Rules」や「Skills」がどのように形式化・強制されるのかに興味がある方は、こちらのガイドが参考になります。
Agent Rules、Workflows、Skills、Slash Commands：AIと効率的に働くための完全ガイド
この記事では、ルールを「整理されたテンプレート」や「ポリシー」として定義するための具体的なエンジニアリングパターンを解説しています。プロンプトに「ガイドラインに従ってください」と書くことと、それらをシステムレベルの構造としてエンコードすることの違いを理解できるはずです。
最後に
プロンプトとルールは、対立する手法ではありません。適切に設計されたAIシステムにおいては、互いを補完し合うレイヤーです。
- プロンプトは、人間が「何をしたいか」を表現するのを助ける
- ルールは、システムが「何をしてもよいか」を決定するのを助ける
AIの失敗の多くは、モデルが指示を無視したことではなく、「プロンプトを決定論的なポリシー強制手段として扱ってしまったこと」に起因します。
「意図（プロンプト）」と「強制（ルール）」を分離し、「スキル」のような構造化されたパターンでその間を橋渡しすることで、柔軟かつ安全なシステムを構築することができるのです。