# AIエージェント開発の意思決定ポイント # プロンプト制御 vs コード/ポリシー制御 🛡️ 🎯 ポイント エージェントの振る舞いを制約する手段として、プロンプトで「お願い」するか、コードで「壁」を作るか。この違いは「確率的な遵守」と「決定論的な強制」の違いに直結します。 「個人情報を出力しないでください」とプロンプトに書いても、プロンプトインジェクションで上書きされたり、コンテキストの膨張で指示の効力が揺らいだりします。正規表現で検出してブロックする処理は、LLMの判断に関係なく確実に動作します。問題は「どの制約をコードに引き上げるか」の判断です。 📋 概要 プロンプト制御はLLMへのシステムプロンプトや指示文に制約を記述し、振る舞いを誘導する方式です。Few-shot例示、ネガティブ指示、ロール設定などが典型的な手法です。コード/ポリシー制御は制約を実行可能なコード（条件分岐、正規表現、スキーマ検証）またはポリシーエンジン（OPA/Rego、Cedar等）で実装し、LLMの入出力や操作を強制的に制御する方式です。 🔍 意思決定のポイント **failure_cost** と **accountability** の2つで判定します。 📊 **制約の種類ごとの判定**: コード/ポリシーで強制すべきもの: - 🔒 境界・法的制約（個人情報の出力禁止、金額上限、禁止操作） - 🔒 不可逆操作の制限（削除、送金、公開） - 🔒 出力形式の強制（JSONスキーマ、値域の検証） プロンプトで誘導すべきもの: - 💬 応答の品質・様式（口調、丁寧さ、専門用語の使用） - 💬 文脈依存の判断指針（どのような場合に何を優先するか） 💡 要点と詳細 🟢 **プロンプト制御の強み**は柔軟性と表現力です。自然言語で記述するため、微妙なニュアンスや文脈依存の振る舞いを指示できます。「法務向けでは正式な表現、エンジニア向けでは技術用語OK」のような条件付き様式が自然に表現でき、変更もデプロイなしにプロンプトを書き換えるだけです。弱点は信頼性の低さで、プロンプトインジェクション・コンテキスト膨張・モデル更新で制約が破れるリスクがあります。版管理・テスト・監査も困難です。 🟡 **コード/ポリシー制御の強み**は確定性と監査性です。制約はコードとして版管理され、ユニットテストで検証され、監査証跡として残ります。「この出力がなぜブロックされたか」はポリシーの版とルールIDで一意に特定できます。プロンプトインジェクションやモデル更新の影響を受けません。ポリシーエンジンを使えばルール変更もデプロイなしで反映可能です。弱点は表現力の限界で、「丁寧に応答する」のような質的な制約はコードで表現できません。 ⚖️ トレードオフ | 観点 | プロンプト制御 | コード/ポリシー制御 | |---|---|---| | 信頼性 | 確率的（破れるリスクあり） 🔴 | 決定論的 🟢 | | 表現力 | 高い（ニュアンス可） 🟢 | 低い（条件→判定に限定） | | 監査性 | プロンプト履歴の追跡が必要 | 版管理＋監査証跡 🟢 | | インジェクション耐性 | 脆弱 | 影響を受けない | | 変更速度 | プロンプト書換のみ | ポリシー更新 or デプロイ | | 開発コスト | 低い | インフラ＋スキルが必要 | 🛠️ ユースケース 🔵 **プロンプト制御が向くケース**: 応答トーン・様式の誘導、文脈依存の判断指針、制約違反の影響が軽微なケース。 🔴 **コード/ポリシー制御が向くケース**: 個人情報・金融データの出力制御、不可逆操作の制限、規制対象の処理、出力形式の厳密な検証。 📌 **デフォルト戦略**: 「境界（壊してはならない制約）はコード、誘導（望ましい振る舞い）はプロンプト」が定石です。迷ったら「この制約が破られたとき、どれだけ痛むか」を自問してください。痛みが大きいならコードで強制、小さいならプロンプトで誘導します。最も実用的な構成はポリシー強制＋プロンプト誘導の二層構造です。コード/ポリシーで境界を決定論的に強制しつつ、プロンプトでLLMの振る舞いを境界の内側で誘導します。プロンプトの誘導が失敗してもポリシーが最終防壁として機能します。 #AIエージェント# #ソフトウェアアーキテクチャ#