Onyxのランタイム保護がTrueFoundry AI Gatewayで利用可能に:あらゆるLLM呼び出しにポリシーガードレールを適用
.png)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
チームがLLMのトラフィックをAIゲートウェイ経由でルーティングしている場合、すべてのプロンプトとレスポンスがリスクの発生源となり得ます。TrueFoundry AI Gatewayは、OpenAI互換の単一APIの背後で1,000以上のLLMへの統合アクセスを提供します。このゲートウェイのカスタムガードレールとしてOnyxが利用可能になったことで、TrueFoundryのユーザーはアプリケーションコードを変更することなく、ランタイム保護を追加できるようになりました。
ランタイム保護は、各アプリケーション内ではなく、強制ポイント(エンフォースメントポイント)で実施されるべきものです。Onyxは、境界を通過するすべてのプロンプトとレスポンスに対して同一のチェックを実行します。これにより、モデルやユーザーが出力結果を目にする前に、プロンプトインジェクション対策、ジェイルブレイク検知、データ流出チェック、コンテンツポリシーの評価といったOnyxの保護機能がアプリケーションに適用されます。
設定は構成のみで完了します。デプロイが必要なラッパーや、変更が必要なアプリケーションコードはありません。
前提条件
- HTTP 200でverdict: falseを適切に処理する、少なくとも1つのモデルプロバイダーが構成されたTrueFoundry AI Gateway。
- Onyx AI Guardポリシーおよびそのガードトークン。強制したい入力(Input)または出力(Output)方向をスキャンするブロックルールが少なくとも1つ設定されていること。
- TrueFoundryゲートウェイからOnyxテナントホストへのアウトバウンドHTTPS通信。
- TrueFoundryダッシュボードでガードレールグループを追加および適用する権限。
統合の手順
Onyxは、ゲートウェイのカスタムガードレール契約に直接対応するTrueFoundryネイティブの評価エンドポイントを公開しています。TrueFoundryがOnyxを呼び出し、Onyxが判定結果を返すため、間にラッパーやアダプターを介す必要はありません。
ステップ1:ガードトークンの取得とURLの構築
AI GuardポリシーURLに含まれるガードトークンは、評価対象のポリシーを識別するものであり、呼び出し時の認証情報として機能します。これはAPIキーやMCPゲートウェイ・トークンとは異なります。Onyxの「Policies」から「Runtime Policies」、「AI Guard」タブの順に進み、ポリシーのAI Guard URLを開いて、ガードトークンとテナントのホスト名をコピーしてください。
ガードレールURLを構築します:
https://<routing-id>.ai-guard.onyx.security/guard/evaluate/v1/<guard-token>/truefoundry
必ずご自身のテナントホストを使用してください。https://ai-guard.onyx.security のままではテナントにルーティングされず、404エラーが返されます。
ステップ2:カスタムガードレールの設定を登録する
TrueFoundryダッシュボードで「AI Gateway」、「Guardrails」、「New Guardrails Group」の順に進みます。タイプに「Custom」を選択し、名前を「onyx-security」とします。2つの設定(方向ごとに1つずつ)を追加し、両方とも同じOnyx URLを指定します。
入力設定(input config)では、名前を「onyx-input」、操作を「Validate」、ターゲットを「Request」に設定します。ステップ1で構築したガードレールURLを貼り付け、「Auth Data」は「None」のまま、「Config」を「{}」に設定し、強制戦略として「Enforce But Ignore On Error」を選択します。
出力設定(output config)では、名前を「onyx-output」、操作を「Validate」、ターゲットを「Response」に設定します。同じガードレールURLを使用し、「Auth Data」は「None」、「Config」は「{}」に設定し、強制戦略として「Enforce But Ignore On Error」を選択します。
これら2つの設定の違いは、名前とターゲットのみです。「Auth Data」は空のままにしてください。URLパス内のガードトークンが認証の役割を果たすため、Bearerトークンは不要です。
ステップ3:ガードレールをトラフィックに適用する
モデルのガードレール設定でグループをモデルに紐付けるか、ゲートウェイの「ポリシー」から「ガードレール」を介して適用します。あるいは、モデルを変更せずにテストできるよう、リクエストごとにヘッダーで指定することも可能です:
{
"llm_input_guardrails": ["onyx-security/onyx-input"],
"llm_output_guardrails": ["onyx-security/onyx-output"]
}
問題のないプロンプトを送信すると、そのままモデルに渡されます。Onyxのルールに抵触するプロンプトを送信すると、ゲートウェイがそれをブロックし、モデルの回答の代わりにポリシーで設定したメッセージをHTTP 400エラー(error.type: guardrail_checks_failed)として返します。レスポンスのガード機能を使用する場合は "stream": false に設定してください。出力ガードレールはストリーミングレスポンスには適用されません。
実現できること
入出力のバリデーション 入力ガードレールはモデルの実行前にプロンプトを検査し、出力ガードレールはストリーミング以外のリクエストにおいて、レスポンスがユーザーに届く前に検査を行います。Onyxは、ポリシーの「入力方向」および「出力方向」のルールに基づいてそれぞれを評価します。
ポリシー主導のブロッキング ブロック時にはOnyxで設定したメッセージが表示されるため、呼び出し元には一般的なエラーではなく、意図した通りの文言が伝わります。強制力の変更はOnyxコンソール上のポリシー編集のみで完結し、TrueFoundry側での変更は不要です。
すべてのアプリケーションで単一のポリシーを適用 チェックはゲートウェイで実行されるため、そこを経由するすべてのチームとアプリに同じガードレールが継承されます。アプリケーションごとの統合を維持する必要はなく、新しいサービスをリリースする際もガードレールの適用漏れが発生しません。
一元化された可観測性 ガードレールの判定結果は、リクエストの他の情報とともにトレースされます。ゲートウェイはOpenTelemetryに準拠しているため、レイテンシやコストの監視に使用している既存のスタックで、どのリクエストがなぜブロックされたのかを確認できます。
よくある質問
AIゲートウェイにおけるLLMガードレールとは何ですか?
ガードレールとは、プロンプトやレスポンスがモデルやユーザーに到達する前にゲートウェイが実行するチェック機能です。TrueFoundry AIゲートウェイでは、これらを構成可能なポリシーとして実行するため、プロンプトインジェクション、ジェイルブレイク、データ漏洩などを各アプリケーションではなく中央で一括してブロックできます。
Onyxガードレールを追加するために何かをデプロイする必要がありますか?
いいえ。TrueFoundryはOnyxのevaluateエンドポイントを直接呼び出します。OnyxのURLを指定するガードレール設定を2つ登録するだけで、ホストするためのラッパーやアダプターは不要です。
Onyxのガードレールは、プロンプトとレスポンスの両方に適用されますか?
はい。この統合では、リクエスト用とレスポンス用にそれぞれ1つずつ、計2つのレールを登録します。出力時にフレーズがブロックされるかどうかは、Onyxのポリシーに「出力方向」のルールが設定されているかによって決まります。入力と出力はOnyxで個別に設定され、出力のガードには非ストリーミングリクエストが必要です。
ガードレールを追加するために、アプリケーションコードを変更する必要がありますか?
いいえ。ガードレールはゲートウェイで実行されます。モデルにアタッチするか、リクエストにヘッダーを渡すだけで、アプリケーションコードを変更することなくそのまま利用できます。
なぜリクエストでバリデーションエラーが返されるのですか?
/truefoundryエンドポイントには、リクエスト内にcontext.user.subjectSlugが必要です。通常のトラフィックではゲートウェイがこれを付与しますが、テストのためにエンドポイントを直接呼び出す場合は、subjectSlugを含めてください。そうしないと、Onyxは「リクエストを検証できませんでした」というブロック判定を返します。
TrueFoundry AI Gatewayを自分のVPC内で実行できますか?
はい。TrueFoundryはVPCデプロイ、オンプレミス、エアギャップ環境、マルチクラウド構成をサポートしており、データがドメイン外に出ることはありません。
既存のオブザーバビリティスタックと統合できますか?
はい。ゲートウェイはOpenTelemetryに準拠しており、Grafana、Datadog、Prometheusと連携可能です。プロンプトからモデルに至るまでの各リクエストを、ガードレールの判定結果を含めてトレースできます。
OnyxとTrueFoundryはこの統合において協力関係にあります。導入をご希望の場合は、TrueFoundryまたはOnyxの担当者までお問い合わせください。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.














%20(28).webp)



.webp)
.webp)
.png)

.png)
.png)
.png)
.png)
.png)
.webp)
.webp)





