TrueFoundryプロンプトレジストリの解説：本番環境の成果物としてのバージョン管理されたプロンプト

プロンプトは、メッセージ、変数、モデル設定、ガードレール、スキーマ、所有権、そしてリリースIDが一体となって初めて、運用上の意味を持ちます。

本番環境のプロンプトは、単なるメッセージテキストではありません

「プロンプト管理」という言葉は、単に文字列を保存するだけのように聞こえるかもしれません。しかし、本番アプリケーションにおいて実行される単位はもっと大きく、順序付けられたメッセージ、入力変数、モデルの選択、生成パラメータ、ガードレール、構造化出力スキーマ、キャッシュやログの設定、そしてメタデータが含まれます。これらの一部でも変更されれば、目に見える指示内容が変わらなくても、動作が変化する可能性があります。

TrueFoundryのプロンプトレジストリは、この実行単位をリポジトリ内のバージョン管理されたアーティファクトとしてモデル化しています。保存された各バージョンには、アプリケーションから参照可能な完全修飾名（FQN）が付与されます。編集して保存するたびに新しいバージョンが生成され、UI上で履歴や差分を確認できます。リポジトリへのアクセス権によって、誰がプロンプトを表示、編集、使用できるかを制御します。

これにより、チームは実際に呼び出される指示パッケージに対して安定したIDを割り当てることができます。ただし、これだけでそのバージョンが適切で安全であり、本番環境へのリリースが承認されていると保証されるわけではありません。それらは評価や組織のポリシーに基づくリリース判断が必要な事項です。

レジストリのオブジェクトは、目に見えるプロンプトテキストよりも意図的に広く定義されています。動作に影響を与える付随的な制御設定やスキーマはすべて、リリースIDおよびレビュー対象に含めるべきです。

リポジトリのスコープがセキュリティの境界となります

プロンプトの権限は、各プロンプトで個別に設定するのではなく、親リポジトリから継承されます。これにより管理が簡素化され、関連するアーティファクトを一つの所有権境界の下にまとめるようチームに促すことができます。また、これはリポジトリの設計が重要であることを意味します。広範な共有リポジトリを作成すると、意図せずして機密性の高い指示や利用権限が想定以上の人々に公開されてしまう可能性があります。

所有権、データの分類、デプロイ環境、または変更権限が異なる場合は、リポジトリを分離してください。誰がバージョンを作成し、なぜ変更され、どのアプリケーションがそれを使用しているかを記録しましょう。コミットメッセージは有用なコンテキストですが、承認や評価結果の代わりにはなりません。

バージョンIDはすべてのリクエストを通じて維持されるべきです

アプリケーションは、プロンプトバージョンのFQNとランタイム変数を指定することで、AI Gateway経由で保存されたプロンプトを呼び出すことができます。ゲートウェイはプロンプトをレンダリングし、モデルリクエストを実行します。あるいは、TrueFoundry SDKを使用してバージョンを取得し、アプリケーションがリクエストを送信する前にクライアントサイドでレンダリングすることも可能です。

どちらの方法でも、解決されたバージョンIDをリクエストのメタデータやトレースに保持する必要があります。そうしなければ、本番環境でインシデントが発生した際に、最終的なメッセージは確認できても、それを生成したアーティファクトが特定できなくなる恐れがあります。管理されたリリースには、番号付きのバージョンを固定（ピン留め）してください。アプリケーションコード内で「最新（latest）」という慣習をピン留めせずに使用することは、影響範囲の広い暗黙的なデプロイチャネルとして扱うべきです。

現在のSkillsドキュメントでは、スキルダウンロードにおける「latest」エイリアスの使用を明示的に禁止しています。プロンプト管理においても、FQNを通じて番号付きのプロンプトバージョンを使用するよう定めています。統合機能が便利な動的参照を提供している場合であっても、リリースシステムはトラフィックが流れる前に具体的なバージョンを解決し、記録しておくべきです。

サーバーサイドとクライアントサイドのレンダリングでは、信頼の境界が異なります

TrueFoundryでは、明示的なテストが必要となる2つの優先順位ルールを定めています。保存されたプロンプトにモデルが指定されていない場合、リクエスト側でモデルを指定する必要があります。バージョンとリクエストの両方でモデルが指定されている場合は、リクエスト側のモデルが優先されます。リクエストで提供されたメッセージは、プロンプトバージョンのメッセージに追加されます。これらの動作は有用ですが、構成上の注意点でもあります。つまり、バージョン単体では、実際に実行されるリクエストの内容を完全には記述していない可能性があるということです。

2つのレンダリングパスはモデル実行という点では収束しますが、ミューテーション（変更）ポイントは異なります。テレメトリには、保存されたバージョン、ランタイム変数、追加されたメッセージ、および解決されたモデルを保持する必要があります。

変数にはプレースホルダーだけでなく、契約（コントラクト）が必要です

テンプレート変数を使用するとプロンプトを再利用できますが、同時に入力の境界も生じます。レンダリング前に、必須変数、型、許容値、長さ、エンコーディング、およびデータ分類を検証してください。システムレベルの命令に挿入された変数は、ユーザーメッセージに配置された同じ値とは異なるセキュリティ上の影響を与える可能性があります。

テンプレート機能をプロンプトインジェクション対策として扱わないでください。信頼できない値を区切り、その権限を最小限に抑え、適切な入力ガードレールを適用してください。構造化出力が必要な場合は、ダウンストリームのコードが期待するスキーマと照らし合わせて、返されたペイロードを検証してください。スキーマは形式を制限することはできますが、事実の正確性やビジネス上の承認を証明するものではありません。

設定はプロンプトリリースの一部です

プロンプトのバージョンには、選択されたモデルや、ガードレール、構造化出力、ログ記録、キャッシュ、メタデータなどの高度な設定を含めることができます。リリースのレビューでは、メッセージの差分だけでなく、マニフェスト全体を比較する必要があります。ガードレールを「強制」から「監査」に変更したり、仮想モデルのターゲットを切り替えたりすることは、文章を1つ編集するよりも大きな影響を及ぼす可能性があります。

環境固有の懸念事項は明示的に管理してください。本番環境のモデルルート、ログ記録ポリシー、データ保持設定は、開発環境とは異なる場合があります。1つのプロンプトバージョンを複数の環境で実行する必要がある場合は、不変のプロンプトコンテンツと環境ポリシーを分離し、両方の解決済みバージョンをテレメトリに記録してください。

レジストリは評価システムではありません

バージョン履歴は「何が変わったか」には答えますが、「品質が向上したか」には答えません。信頼できるリリースプロセスでは、各候補バージョンを評価データセット、タスクレベルのメトリクス、安全性チェック、レイテンシとコストの測定、必要に応じた人間によるレビュー、およびロールバックの判断と結びつける必要があります。

変数の境界、追加されたメッセージ、モデルのオーバーライド、ガードレールの結果、構造化出力の失敗などを検証できる代表的なケースを使用してください。候補となるバージョンを、同じモデルルートと評価設定の下で、現在デプロイされているバージョンと比較します。結果が確率的な場合は、一度の幸運な出力を報告するのではなく、分布や繰り返しサンプルの要約を報告してください。

リリースループは、バージョニングと評価を分離します。昇格はエビデンスに基づく決定であり、ロールバックはプロンプト、モデルルート、制御の組み合わせを既知の正常な状態に戻すものです。

ロールアウトとロールバックには具体的な識別子が必要です

安全なロールアウトとは、候補となるFQNを解決し、評価結果を記録し、デプロイメント参照を更新し、本番環境の結果を監視し、ロールバック用に以前のバージョンを保持するプロセスです。ランタイムは、要求されたプロンプト参照と解決されたバージョンの両方をログに記録する必要があります。リクエスト時のモデルオーバーライドが許可されている場合は、解決されたモデルターゲットもログに記録してください。

ロールバックとは、単に古いテキストを新しいバージョンにコピーすることではなく、既知の正常な組み合わせ全体を復元することを意味します。障害の原因がモデルターゲット、ガードレール、スキーマ、またはアプリケーションの構成ルールにある場合、プロンプト本体には問題がない可能性があります。

プロンプト構成には所有権ルールが必要です

多くのアプリケーションでは、レジストリプロンプトと、開発者の指示、取得したコンテキスト、会話履歴、ツール実行結果、ランタイムメッセージを組み合わせています。レジストリが制御するのはその一部のみです。どのレイヤーが動作指示を導入できるか、どのレイヤーが信頼できないエビデンスを運ぶか、どのコンポーネントがモデルやガードレールの設定を上書きできるかを定義してください。

有用なリクエストマニフェストには、プロンプトバージョンのFQN、アプリケーションリリース、レンダリングパス、変数名とダイジェスト、追加メッセージ数、解決されたモデル、仮想モデル設定、構造化出力スキーマバージョン、およびガードレールポリシーバージョンが記録されます。そのマニフェストにより、分散された構成プロセスが、すべてのログに機密値を保存することなく、検証可能な1つの実行IDへと変換されます。

キャッシュはリリース範囲を拡大させる可能性がある

完全一致キャッシュやセマンティックキャッシュを利用すれば、モデル推論を繰り返さずに結果を返すことができます。これによりコストとレイテンシを改善できますが、キャッシュキーと無効化ポリシーには、回答やその認可に影響を与えるあらゆる入力を反映させる必要があります。プロンプトのバージョン変更、モデルルートの変更、ガードレールの変更、テナント境界、あるいは重要な変数の変更などが発生した場合、異なるキャッシュエントリが必要になることがあります。

新しいプロンプトバージョンを公開しても、古いバージョンで生成された応答が自動的に削除されるとは限りません。アプリケーションやゲートウェイがどのようにキャッシュエントリを識別しているかを確認し、解決済みのプロンプトバージョンをキャッシュの可観測性に含めてください。機密性の高いタスクでは、キャッシュヒットの判断からアクセス制御を除外するか、認証されたスコープをキーに含めることで、あるユーザーの結果が別のユーザーに渡らないようにしてください。

作成、承認、デプロイを分離する

リポジトリの編集権限は、誰が新しいバージョンを作成できるかを決定するものであり、誰が本番環境での使用を承認したり、アプリケーションの固定参照を変更したりできるかを決定するものではありません。成熟したチームでは、影響の大きいプロンプトに対してこれらの役割を分離しています。デプロイ記録には、承認者、評価レポート、対象となるコンシューマー、開始時刻、ロールバック先を明記する必要があります。

緊急の編集であってもトレーサビリティは不可欠です。迅速な対応が必要な場合でも、レビューを簡略化しつつ、具体的なバージョンを作成し、差分を保持し、影響を受けるトラフィックを絞り込み、事後評価を行う必要があります。バージョン管理されていない文字列を本番環境で直接編集することは、レジストリを導入する意義を損なう行為です。

自動化すべき失敗テスト

• 必須変数を省略し、モデル実行前に呼び出しが失敗することを確認する。
• 信頼できない区切り文字や命令のようなコンテンツを、すべての変数位置に入力してみる。
• バージョンにリクエストモデルが保存されている場合に、別のリクエストモデルを指定し、優先順位が正しく検証・記録されるかを確認する。
• 実行時のメッセージを追加し、保存されたメッセージに対する順序が正しいかを確認する。
• ガードレール、スキーマ、ログ、キャッシュ設定のみを変更し、リリースの差分にそれが反映されることを確認する。
• リポジトリへのアクセス権を取り消し、影響を受けるユーザーやサービスがそのアーティファクトを消費できなくなったことを確認する。
• 記録されたFQNを使用してロールバックし、解決されたリクエストが既知の正常なリリースと一致することを確認する。

Prompt Registryがスタック全体で果たす役割

Prompt Registryは、アーティファクトの識別、バージョン管理、リポジトリアクセス、再利用可能な呼び出し機能を提供します。AI Gatewayは、モデルルーティング、予算管理、ガードレール、ログポリシー、テレメトリを適用するためのリクエストパスを提供します。TrueForgeはエージェントランタイムの一部として命令を消費できますが、永続的なセッション動作やツール実行はプロンプトのバージョン管理とは切り離されています。

この分離により、レジストリが曖昧な「AIコントロールプレーン」になることを防ぎます。レジストリは特定のアーティファクトを管理し、ゲートウェイはルーティングされた推論制御を管理し、アプリケーションはビジネス入力と結果の検証を管理します。そして、評価システムがその組み合わせがリリース基準を満たしているかを判断します。

運用のルール

Prompt Registryを使用して、モデルへの命令を識別可能、レビュー可能、かつ再現可能な状態に保ってください。具体的なバージョンを固定し、変数を検証し、構成とオーバーライドを記録し、プロモーションの前にマニフェスト全体を評価してください。

TrueFoundryの最大の強みは、レジストリがプロンプトを「正しく」することではありません。チームが規律あるリリースプロセスを構築するための安定した基盤を提供し、実際にどのオブジェクトが本番環境に到達したかを把握できるだけの十分なランタイム制御を提供できる点にあります。

参考文献

1. TrueFoundry — プロンプト管理。
2. TrueFoundry — ガードレール概要。
3. TrueFoundry — AIゲートウェイ概要。

編集上の開示 この記事は、2026年9月19日時点における、引用された公開資料に対するTrueFoundryのエンジニアリング上の解釈を反映したものです。製品機能の範囲はリンク先のドキュメントに準拠します。例やデフォルト設定はあくまで説明を目的としたものであり、法的助言、監査意見、独立したベンチマーク、あるいはセキュリティ、安全性、コンプライアンスを保証するものではありません。

‍