プロトタイプは、インラインの文字列から始まるかもしれません。プロンプトに担当者、レビュー、ロールバック、データ処理、複数の機能や言語、測定可能な挙動が必要になった時点で本番運用の負荷が現れます。それは公開前に起こることもあり、一律の時期はありません。
指示の一部だけを変えたくなり、顧客ティアごとに異なる振る舞いが必要になります。バージョンをA/Bテストし、問題発生時にはロールバックし、プロンプトが最後にいつ、なぜ変更されたかを把握する必要も生じます。
本番用プロンプトの設計では、これらの選択を明示します。プロンプト本文は、管理されたリリースと実行システムに含まれる一つの成果物です。
この記事では、三層の編集アーキテクチャで担当と変更頻度を説明し、提供元のAPIへの対応付けを示します。これは参照設計であり、普遍的なデータ形式ではありません。セキュリティ境界については、OWASPのプロンプトインジェクション指針に従ってください。指示とデータの分離はレビューと評価に役立ちますが、プロンプトテンプレートだけで認可や分離の境界を作ることはできません。
本番環境のプロンプトには、再利用可能なテンプレートとリクエストごとのデータという、二つの別個の成果物があります。テンプレートはコードのようにバージョン管理してください。レンダリング後のプロンプトとモデルの回答にユーザー、顧客、社内のデータが含まれる場合は、機密ログとして扱ってください。
APIに対応付ける三層の編集アーキテクチャ
この設計では、編集上の三つの関心事を分離します。
system層。 比較的安定した振る舞い、アイデンティティ、制約です。機能横断のAIの振る舞いに責任を持つチームが担当します。
developer層。 機能ごとの指示、ツール利用ポリシー、出力要件です。機能チームが担当します。
user・実行時層。 ユーザーの依頼に、承認済み顧客データ、会話履歴、検索した知識などの動的コンテキストを加えます。リクエストまたは会話ターンごとに構築します。
担当、安定したポリシー、機能指示、実行時データを混ぜると、変更のレビュー、評価、キャッシュ、ロールバックが難しくなります。管理しやすくなる場合に分離し、提供元またはアプリケーションが別の表現を使うなら、三つのAPI項目を無理に設けないでください。
指示の権限とデータの配置は関係しますが、同じではありません。信頼階層は、メッセージが衝突したときにどの指示が優先されるかを決めます。データ配置は、動的または信頼できない内容をアプリケーションのどこに置くかを決めます。検索したテキストをuserまたはcontextの項目に入れても、承認済み、正確、安全にはなりません。本人確認、テナントアクセス、データ最小化、ツール権限、出力検証はモデルの外で強制します。
分離が基礎になります。
┌─────────────────────────────────────┐
│ system層（比較的安定） │ アイデンティティ、振る舞い、ポリシー意図
├─────────────────────────────────────┤
│ developer prompt（機能ごと） │ 機能の指示、ツール、形式
├─────────────────────────────────────┤
│ user prompt（呼び出しごと） │ ユーザークエリ、コンテキスト、会話
└─────────────────────────────────────┘
モデルAPIごとに、この区別の表現方法は異なります。
- OpenAI：Responses APIでは、アプリケーション側の指示にトップレベルの
instructionsパラメーターまたはdeveloperメッセージを使い、ユーザー入力にはuserメッセージを使います。複数ターンのフローを管理する際は、前のレスポンスの指示が自動的に引き継がれると想定してはいけません。 - Anthropic：設計をClaudeのMessages API、system指示の仕組み、メッセージロール、ツール定義に対応付けます。対応するロール配置はモデルやプラットフォームで異なる場合があります。
- Gemini：
system_instructionとリクエスト内容、および選択したAPIの独立したツール設定に対応付けます。
提供元ごとのアダプターと統合テストを使います。API間でロール名をコピーし、優先順位、持続性、ツールの挙動が同じだと想定しないでください。
第1層：system prompt
この編集パターンでは、system層が機能横断の役割と振る舞いを定義します。機能指示より変更頻度を低くしつつ、変更時には必ずバージョン管理と評価を行います。
適切なsystem promptは次を扱います。
アイデンティティ。 AIが何者か。「あなたは［会社］のAIアシスタントで、［領域］を専門とします。」
語調とスタイル。 どのような話し方をするか。曖昧な形容ではなく、具体的な特性を指定します。
必要な振る舞いの制約。 モデルが拒否、エスカレーション、開示、形式化すべき内容です。セキュリティ、権限、不可逆アクションの制御は、この文章だけに依存せず、アプリケーションコードと下流システムで強制します。
振る舞いのパターン。 よくある状況への対処方法です。拒否、エスカレーション、不確実性を扱います。
安全性とコンプライアンス。 必須の開示、規制上の規則、コンテンツポリシーです。
含めるべきでないもの：
- 機能固有の指示（「営業メールではXを行う」）。
- 動的コンテキスト（「ユーザーの注文履歴は……」）。
- ツールの説明（別の場所に置きます）。
- 頻繁に変わる内容。
system promptの長さは、評価で必要と判明した振る舞いに合わせます。短いプロンプトで十分な場合もあれば、長くても重要なルールが欠ける場合があります。語数の範囲を目標にせず、指示の衝突、タスク品質、レイテンシー、tokenコストを測定してください。
有効なテンプレート：
あなたは[name]、[company / context]のAIアシスタントです。
## あなたの役割
[2-3 sentences on what you do]
## 語調とスタイル
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- [anti-pattern 1]を行わない
- [anti-pattern 2]を行わない
## 厳格な制約
- 決して[hard rule 1]を行わない
- 決して[hard rule 2]を行わない
- 常に[hard rule 3]を行う
## 不確実性への対処
- 事実を知らない場合：明確にそう伝える。
- ユーザーが範囲外のことを求めた場合：支援できる内容を提示する。
- リクエストが害を及ぼす可能性がある場合：拒否し、理由を説明する。
## 形式の要件
- 標準ではプレーンテキスト
- コードや構造化データの表示時はMarkdownを使用
- 簡潔にし、水増しのための文言を加えない
これが中核です。すべてのやり取りがここを通り、変更は意図的かつ低頻度に行います。
第2層：developer prompt
developer promptは機能固有であり、機能ごとに異なります。
要約機能のdeveloper prompt：
タスク：以下の文書を要約してください。
要件：
- 3～5個の箇条書き
- 各項目は一つの完全な文
- 印象ではなく、事実と具体的な主張に焦点を当てる
- 文書に数値が含まれる場合、最も重要なものを含める
- マーケティング表現や推測を含めない
- 重要な点が曖昧な場合、その旨を記す
形式：前置きなしの通常のMarkdown箇条書き。
コードレビュー機能のdeveloper prompt：
タスク：以下のコード差分をレビューしてください。
次を含むJSONオブジェクトを出力：
- summary：変更概要（1～2文）
- concerns：具体的な問題の配列（各要素：file、line、severity、description）
- suggestions：改善案の配列（各要素：file、line、suggestion）
- approved：boolean（マージを妨げる問題がなければtrue）
severityの値：
- "blocker"：マージ前に修正必須
- "warning"：対処すべきだがブロッキングではない
- "nit"：スタイル上の任意事項
重点項目：
- ロジックエラー
- セキュリティ問題
- 性能問題
- テストカバレッジの不足
- 不明瞭な命名または構造
対象外：
- 書式（フォーマッターが処理）
- 主観的なスタイルの好み
各機能が独自のdeveloper promptを持ち、個別に保存、バージョン管理、評価されます。
第3層：user prompt
user層は動的であり、通常は次を含みます。
ユーザーの実際のリクエスト。 「この文書を要約してください。」
システムが検索したコンテキスト。 RAGの文書、顧客履歴、会話履歴です。
呼び出しごとの変数。 ユーザー名、タイムゾーン、言語設定、アカウントティアです。
この層は、呼び出し時にプログラムで構築します。通常の構造は次のようになります。
{conversation_history_summary}
{retrieved_context}
ユーザーのリクエスト：{user_query}
追加コンテキスト：
- ユーザー名：{name}
- ユーザーのタイムゾーン：{timezone}
- ユーザーのティア：{tier}
具体的な構造は機能によって異なります。原則は、データをsystem promptやdeveloper promptではなく、ここに置くことです。
テンプレート化の規律
本番プロンプトはテンプレートから構築します。インラインで文字列を連結するのはプロトタイプ向けであり、拡張できません。
単純なテンプレートシステム：
from string import Template
SUMMARIZE_TEMPLATE = Template("""
$conversation_summary
Document to summarize:
$document
User's specific instructions: $user_instructions
""")
prompt = SUMMARIZE_TEMPLATE.substitute(
conversation_summary=summarize_conversation(history),
document=document_text,
user_instructions=user_query,
)
さらに高度な方法として、条件分岐とpartialを備えたテンプレートライブラリ（Jinja2、Handlebars）があります。
{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}
{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}
User's request: {{ user_query }}
テンプレート化は、変数を介したプロンプトインジェクションを防ぎ（必要に応じてユーザー入力をエスケープします）、条件付きロジックを可能にし、プロンプト構造を一貫させます。
管理された正式な記録元を選ぶ
本番プロンプトをバージョン管理されたリリース成果物として扱います。正式な記録元には、repository、自社所有のregistryまたはservice、編集UIを備えたmanaged productを選べます。一つの保存方法が全チームに合うと考えず、ガバナンスと運用要件に基づいて選びます。
コードで管理する場合、repository内のprompts/directoryにプロンプトごとのファイルを置く方法が、明確な出発点です。
prompts/
system/
main.txt
customer-support.txt
code-assistant.txt
features/
summarize.txt
classify-ticket.txt
generate-email.txt
templates/
base.j2
各ファイルに個別のcommit履歴とPRレビューを持たせ、本番配備では既知のコード版を参照できます。
これが重要な理由：
- 差分の可視性。 PRでプロンプトの正確な変更内容を確認できます。
- ロールバック。 変更が問題を起こしたときに元へ戻せます。
- 履歴。 「返金ポリシーをいつ変更したか」「なぜこの段落があるか」をgit blameで確認できます。
- ツール連携。 リンター、バリデーター、評価スイートをファイルベースのプロンプトと統合できます。
主な選択肢を明示的に比較します。
| 正式な記録元 | 適する場合 | 必要な制御 |
|---|---|---|
| repository | アプリケーションコードとともにリリースする、エンジニアリング所有のプロンプト | branch protection、code owner、秘匿化済みfixture、環境間の昇格、配備identity、既知commitへのrollback |
| 自社所有のregistryまたはservice | 実行時選択、独立したプロンプトリリース、複数製品またはlocale | role-based access control、不変版、承認記録、環境分離、認証済みclient、暗号化、監査event、export、テスト済みrollback |
| managed serviceまたは編集UI | 非エンジニアの共同作業または実験運用 | role-based access control、最小権限role、レビューワークフロー、版の出典、本番アクセス分離、データ処理レビュー、export、rollback |
inline stringは小規模なprototypeでは使えますが、発見と独立したリリースが難しくなります。編集UIも、権限、レビュー、出典、配備、rollbackの制御がワークフローのリスクに合えば適切です。チャット画面から貼り付けたプロンプトは、ほかの候補と同じレビュー、秘匿化、評価の経路に入れます。
本番の会話、顧客レコード、サポートチケット、社内文書、機密変数を含むレンダリング済みプロンプトをコミットしてはいけません。ソース管理には、再利用可能なテンプレート、fixture、サニタイズ済み評価例を保存します。実際のトレースは、保持期間、アクセス制御、マスキングを備えた可観測性ストアに保存します。
実行時registryとservice
A/Bテスト、ユーザーティア別の差異、ロケール固有のプロンプトなど、頻繁に変わるものには、ファイルベースのソース管理では時間がかかりすぎます。
パターンとして、メタデータ付きのプロンプトバージョンをデータベースまたはサービスに保存します。
prompt = prompt_service.get(
name="summarize",
version="v3",
locale="en",
user_tier="enterprise",
)
サービスが管理するもの：
- 各プロンプトの現行バージョンと履歴。
- 追加日時、追加者、理由のメタデータ。
- 各バージョンに紐づく評価スコア。
- ロールバック機能。
ツールにはPromptLayer、Helicone、社内システムがあります。多くのチームには、単純なDBスキーマを使った社内システムで十分です。
インターフェースが重要です。エンジニアだけでなく、製品やコンテンツの担当者もプロンプトを編集できるようにします。ただし、変更はレビューを経て、評価に合格してから本番反映します。
評価をゲートとする変更
すべてのプロンプト変更は、デプロイ前に評価を通します。本格的な本番システムでは必須です。
フロー：
- エンジニアまたは非エンジニアがプロンプト変更を作成する。
- 評価スイートに対して変更を実行する。
- 変更とともに評価結果をレビューする。
- 評価に合格した場合（リグレッションがなく、理想的には改善）、承認できる。
- 承認済み変更をデプロイする。
- デプロイ後の監視で評価が見逃した問題を検出する。
重要なプロンプトには代表的な評価群を維持し、信号が変更の判定に十分信頼できる場合は、安定して自動化できる確認をCIで実行します。合格基準を自動スコアに還元できない場合は、専門家または人のレビューを使います。テスト内容、しきい値、レビュー担当者、残る不確実性を記録してください。
このゲートは正しさを証明しません。リリース判断を検査可能にし、配備後の回帰を検出する基準を提供します。
実用的なリリースチェックリスト
プロンプトのバージョンを本番反映する前に、短いチェックリストを必須にします。
| 確認項目 | 要件 |
|---|---|
| 担当 | プロンプトに担当者とレビュアーが指定されている。 |
| 指示の層 | system、developer、user / コンテキストのデータが分離されている。 |
| スキーマ | 構造化出力にスキーマと失敗時の経路がある。 |
| インジェクション対策 | ユーザー提供コンテンツが明確に区切られ、指示として扱われない。 |
| 評価 | 候補プロンプトがリグレッションセットと安全性ケースに合格している。 |
| ログ | テンプレートバージョン、モデル、レイテンシー、コスト、マスキング済み入出力を観測できる。 |
| ロールバック | コードを大きく変更せず、直前の正常なバージョンへ戻せる。 |
この記事からリンクしている付属チェックリストを使えば、これらを反復可能なリリースレビューにできます。
本番環境でのA/Bテスト
オンライン実験に適したプロンプトでは、現在のバージョンと段階的に比較することで、オフライン評価以外の実環境のシグナルを得られます。実トラフィックを最初の安全性テストに使わず、データ収集だけを目的に、実質的に危険な処理へ利用者をさらさないでください。
次は例であり、既定の配分ではありません。
- トラフィックの95%で本番プロンプトv3を使う。
- 5%で新しい候補v4を使う。
- モデルへのアクセス、ツール権限、アクションの上限を、承認済みの本番境界より広げない。
- 対象となるトラフィックで、タスク成功率、安全性とポリシーのエラー、利用者の反応、下流指標、レビュー済み評価スコアを測定する。
- 開始前に最小サンプル、停止条件、担当者、1ステップのロールバックを定義する。
- 十分な根拠が得られたら、候補を拡大、修正、中止のいずれにするか決める。
配信方法には、自社管理のfeature flag、配備設定、承認済みのプロンプトregistry、独自ルーティングなどがあります。
注意点：
- A/Bテストで検出できるのは測定対象だけです。ユーザーフィードバックや下流のコンバージョン指標がなければ、得られる情報はわずかです。
- 統計的有意性には量が必要です。利用量の少ない機能では困難です。
- 同時実験は相互作用し、原因の特定を妨げる場合があります。重複を意図的に管理してください。
- 製品、対象者、法域に応じて、通知、同意、除外、レビューの義務を検討します。影響が大きい、または元に戻せない操作には、通常、トラフィック分割より強い承認と可逆性が必要です。
プロンプトの可観測性
すべての本番LLM呼び出しで、次を記録します。
- 使用したプロンプトテンプレート（名前、バージョン）。
- 置換した変数。許可リストにある名前を使い、必要に応じて値をマスキングする。
- ポリシーで許可される場合のみ、最終的なレンダリング済みプロンプト。それ以外はマスキング、サンプリング、ハッシュ化した表現を保存する。
- モデルの回答。機密性の高いワークフローではマスキングまたはサンプリングする。
- レイテンシー、トークン、コスト。
- 下流のシグナル（ユーザーフィードバック、成功指標）。
これは「なぜモデルはこのユーザーに奇妙な回答をしたのか」をデバッグするために必要なデータです。なければ推測するしかありません。
保存先はデータベーステーブルまたは可観測性ツールです。すべてを記録すれば、呼び出し量 × トークン数 × ストレージのコストが発生します。プライバシーリスクも現実的です。ワークフローごとに安全な保存項目を決め、標準ではシークレットと個人データをマスキングし、長期保持するコンプライアンス上の理由がなければ保持期間を短くします。一部のチームはサンプリングします。
実際の本番プロンプトと回答のサンプルを定期的（毎週）に読むレビューも行います。評価が見逃す問題を検出できます。
プロンプトのアンチパターン
避けるべきパターン：
アンチパターン1：担当者のいない多目的プロンプト。 関係のない機能、ポリシー、例、実行時の仮定を組み合わせた大規模なsystem promptは、レビュー、評価、rollbackが難しくなります。長さ自体ではなく、測定されていない複雑さが問題です。
対策：有用な場合は担当と変更境界に沿ってcomponentを分け、重複または古い指示を削除し、代表的な評価で新しい設計を比較します。
アンチパターン2：インラインの文字列連結。
prompt = "You are helpful. " + (
"The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...
壊れやすく読みにくいうえ、インジェクションを受けやすくなります。
対策：テンプレートシステムを使います。
アンチパターン3：一つのプロンプトを多数のユースケースに使う。
メール作成、コードレビュー、カスタマーサポート、調査に同じ「汎用アシスタント」プロンプトを使うことです。すべて異なるタスクであり、一つではどれにも最適化できません。
対策：共有system promptの上に、機能固有のdeveloper promptを置きます。
アンチパターン4：ハードコードされたプロンプト。
response = openai.chat.completions.create(
messages=[
{"role": "system", "content": "You are a helpful assistant..."},
{"role": "user", "content": query}
]
)
プロンプトがコード内に埋まり、デプロイなしでは編集できません。A/Bテストも独立したバージョン管理もできません。
対策：プロンプトファイルまたはサービスへ抽出します。
アンチパターン5：評価のカバレッジがない。
体系的にテストしていないプロンプトで機能をリリースし、品質を「感覚」で判断する状態です。ドリフトを検出できません。
対策：重要な振る舞いに、リスクに応じた評価範囲を追加します。失敗とエスカレーションのcaseも含めます。
アンチパターン6：system promptにデータを混ぜる。
あなたはJohnのアシスタントです。Johnは2023年に登録したプレミアム顧客で、Tallinnに住み、47件の未解決チケットがあります。
system promptが呼び出しごとに変わり、キャッシュが機能せず、混乱が生じます。
対策：動的データはsystem promptではなく、user / コンテキスト層に置きます。
アンチパターン7：途中に埋もれた指示。
ユーザーのリクエストを支援してください。丁寧に答えてください。出力はJSONにしてください。Markdownは使わないでください。ユーザーは価格について質問しているため、数値を引用する際は注意してください。出力は1～2文にしてください。それでは支援してください。
重要な指示が埋もれ、モデルが見落とす可能性があります。
対策：明確なセクションで構成し、重要な指示は先頭と末尾に置きます（新近性効果が役立ちます）。
一般的な機能に固有のパターン
機能固有のパターンをいくつか紹介します。
分類
タスク：以下のテキストを、次のカテゴリーのいずれかに分類してください。
- billing：支払い、返金、サブスクリプション
- technical：バグ、エラー、統合の問題
- account：ログイン、パスワード、プロフィール変更
- feature_request：新機能のリクエスト
- complaint：具体的に対処可能な問題を伴わない一般的な不満
JSONオブジェクトを出力：{"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}
分類するテキスト：
{text}
パターン：定義付きのカテゴリー列挙、構造化出力、確信度と理由のフィールドです。
抽出
タスク：以下の文書から構造化データを抽出してください。
スキーマ：
- vendor_name：請求書を発行した会社
- invoice_number：文書に印刷された番号
- date：ISO 8601形式
- line_items：{description, quantity, unit_price, total} の配列
- subtotal、tax、total：数値
ルール：
- フィールドが存在しない場合はnullを使用
- 数値は文字列ではなく数値型にする
- 曖昧な場合は "needs_review": trueとし、説明する
文書：
{document}
パターン：明示的なスキーマ、型の要件、欠損データの扱い、曖昧な場合のエスカレーションです。
スタイルを指定した生成
タスク：{audience} を対象に、{topic} についての {format} を書いてください。
スタイル：
- {Specific style trait 1}
- {Specific style trait 2}
- 避けるもの：{anti-pattern 1}、{anti-pattern 2}
制約：
- 長さ：{N}語
- 含めるもの：{required elements}
- 除外するもの：{forbidden elements}
語調の参考：
[Provide a sample of the desired voice]
出力：前置きや追記を付けず、{format} のみ。
パターン：具体的なスタイル特性、明示的な制約、参考サンプルによる語調の固定です。
エージェントループ
次のツールを利用できます：
{tool_descriptions}
各ターン：
1. 必要な作業を考える。
2. ツールが必要か判断し、必要なら呼び出す。
3. 結果を確認後、さらにツールが必要か、回答できるか判断する。
4. 十分な情報が得られたら、最終回答を生成する。
制約：
- リクエストごとに最大5回のツール呼び出し。
- 5回で完了できなければ、不足しているものを説明する。
- ツール名や引数を決して作り上げない。
- ツール結果に基づいて操作する前に検証する。
ユーザーのリクエスト：
{user_query}
パターン：段階的なツール利用手順、ツール予算、明示的な検証、範囲を限定した失敗時の処理です。
チームの側面
本番プロンプトには通常、複数の関係者が関わります。
- エンジニアはプロンプトをシステムへ組み込み、テンプレートを保守し、デプロイを管理します。
- 製品担当はプロンプトが達成すべきことを定義します。
- コンテンツ / マーケティング担当は語調とスタイルの指針を担当します。
- ドメイン専門家は、法律用語や医療用語など、特定のユースケースで何が正しいかを理解しています。
有効なパターンは、コードレビューと同様に、領域に応じた適切なレビュアーを置く「プロンプトレビュー」です。語調の変更はコンテンツ担当、ロジック変更はエンジニア、領域固有の内容は専門家がレビューします。
法律、医療、金融などの機密性の高いユースケースでは、正式なレビューと承認が必要になる場合があります。それに応じたプロセスを構築してください。
ステージゲート型のプロンプト成熟化計画
「プロンプトはコード内の文字列」という状態から「プロンプトは管理されたインフラ」という状態へ移行するチーム向けの計画です。
ステージ1：基盤。
- 振る舞いに実質的な影響を与えるプロンプトとプロンプト構築コードを洗い出す。
- 指示の権限モデル、実行時データ境界、担当者、提供元への対応付けを定義する。
- リリースワークフローに適した、管理された正式な記録元とテンプレート方法を選ぶ。
- 不要な機密内容を保持せず、配備版と結果を識別するプライバシーに配慮したtelemetryを設定する。
ステージ2：評価。
- リスクと処理量が最も高いプロンプトから評価スイートを構築する。
- 重要なプロンプト変更に代表的な評価を実行し、必要に応じて分野のレビューを行う。
- 安定した自動確認をCIに置き、自動化できない合格判断をレビュー記録に残す。
ステージ3：運用。
- 選択したrepository、registry、serviceでプロンプトのバージョン管理を実装する。
- 段階的な展開と停止の仕組みを追加し、対象となるワークフローに限ってA/Bテストを使う。
- ワークフローに必要な品質、安全性、ポリシー、待ち時間、費用、下流シグナルの監視を構築する。
- プロンプト変更のレビュープロセスを確立する。
この成果を日程だけで約束してはいけません。テストによって、プロンプトの洗い出しが完了し、重要な変更にバージョン管理とゲートが適用され、ロールバックが機能し、テレメトリーでデプロイ済みバージョンを識別でき、担当者がインシデント対応を演習できると確認できた場合にのみ、このステージ群を完了してください。
インフラとしてのプロンプト
本番プロンプトは文字列として保存される場合もありますが、組み立て、評価、リリース、アクセス、可観測性の制御に囲まれた、バージョン管理済みのシステムコンポーネントとして動作します。
指示階層は権限を定義しますが、実行時データやツール操作を保護しません。テンプレート化は組み立てミスを減らせますが、プロンプトインジェクションを防ぎません。管理された正式な記録元がバージョン履歴を提供します。リスクに応じた評価がリリース判断に情報を与え、telemetryが評価群の外でも意図した挙動が続くかを確認します。
必要な厳密さはリスクと範囲によりますが、省略する制御には理由の記録が必要です。公開上の主張では、実際に実装したバージョン管理、評価、展開、rollback、telemetryの根拠を示します。
評価と本番telemetryが、選択したモデル、プロンプト版、データ経路、ツール、ポリシーが合格基準内で動作すると示すまでは、制御可能性は仮説です。その根拠をリリースとともに保存し、版ごとに失敗を調べ、rollbackを利用可能に保ってください。
担当、権限、データ処理、評価、配備、rollback、根拠を明示できる、最小のアーキテクチャから始めます。
