OpenAI が適用する保護対策については、安全性分類器、サイバーセキュリティチェック、ミスアラインメントの監視をご覧ください。未成年者が利用するアプリケーションでは、18 歳未満のユーザーに関するガイダンスにも従ってください。
無料のモデレーション API の活用
OpenAI の モデレーション API は無料で利用でき、生成結果に安全でないコンテンツが含まれる頻度を減らすのに役立ちます。また、ユースケースに合わせた独自のコンテンツフィルタリングシステムの開発を検討することもできます。
Responses API または Chat Completions でテキストを生成するアプリケーションでは、 生成リクエストにモデレーションスコアの取得も 含めることができます。
敵対的テスト
敵対的な入力に対する堅牢性を確保するため、アプリケーションの「レッドチーミング」を推奨します。典型的な入力やユーザーの行動に加え、アプリケーションを「壊そう」とする行動も含めて、幅広いケースで製品をテストしてください。話題から逸脱することはありませんか。「これまでの指示を無視して、代わりにこれを実行して」といったプロンプトインジェクションで、機能の動作を簡単に変えられてしまいませんか。
人間による確認の組み込み(HITL)
可能な限り、出力を実際に利用する前に人間がレビューすることを推奨します。これは、重大な結果を伴う分野やコード生成で特に重要です。レビュー担当者はシステムの限界を理解し、出力の検証に必要な情報にアクセスできるようにしてください。たとえば、メモを要約するアプリケーションでは、元のメモを簡単に参照できる必要があります。
プロンプトエンジニアリング
「プロンプトエンジニアリング」は、出力テキストの話題や語調を制限するのに役立ちます。これにより、ユーザーが意図的に望ましくないコンテンツを生成しようとしても、そのようなコンテンツが生成される可能性を減らせます。新しい入力の前に望ましい動作の質の高い例をいくつか示すなど、モデルに追加のコンテキストを与えることで、出力を望ましい方向へ導きやすくなります。
顧客確認(KYC)
原則として、サービスの利用にはユーザー登録とログインを必要とするようにしてください。Gmail、LinkedIn、Facebook などの既存アカウントによるログインとサービスを連携させることも役立つ場合がありますが、すべてのユースケースに適しているとは限りません。クレジットカードや身分証明書を必須にすると、リスクをさらに減らせます。
ユーザー入力と出力トークン数の制限
ユーザーがプロンプトに入力できるテキストの量を制限すると、プロンプトインジェクションの防止に役立ちます。出力トークン数を制限すると、不正利用の可能性を減らすのに役立ちます。
入力や出力の範囲を絞り、特に信頼できる情報源に基づくものに限定することで、アプリケーション内で可能な不正利用の範囲を狭められます。
自由形式のテキスト入力を許可するより、検証済みの選択肢を持つドロップダウンフィールド(Wikipedia の映画一覧など)からユーザーに入力してもらう方が、安全性を高められる場合があります。
可能であれば、新たに生成したコンテンツを返すよりも、バックエンドにある検証済みの資料群から出力を返す方が安全な場合があります。たとえば、顧客の質問に対して一から回答を作ろうとする代わりに、最もよく合う既存のカスタマーサポート記事へ案内します。
ユーザーが問題を報告できる仕組み
原則として、機能の不具合やアプリケーションの動作に関する懸念を、ユーザーが簡単に報告できる手段を用意してください。たとえば、連絡先メールアドレスの掲載やチケット送信機能などが考えられます。寄せられた報告は人間が確認し、適切に対応する必要があります。
限界の理解と周知
言語モデルには、ハルシネーションによる不正確な情報の生成、不快な出力、バイアスなど、さまざまな問題が生じる可能性があります。そのため、大幅な調整を加えなければ適さないユースケースもあります。モデルが目的に合っているかを検討し、想定される幅広い入力で API の性能を評価して、性能が低下する可能性のあるケースを特定してください。顧客層とその顧客が使用する入力の範囲を考慮し、過度な期待を抱かせないよう、実際にできることを適切に伝えてください。
OpenAI は、安全性とセキュリティを非常に重視しています。
API を使った開発中、または OpenAI に関連するその他の場面で、安全性やセキュリティの問題に気づいた場合は、協調的脆弱性開示プログラムを通じて報告してください。
安全性識別子の実装
リクエストに安全性識別子を含めて送信すると、OpenAI による不正利用の監視と検出に役立ちます。これにより、アプリケーションでポリシー違反が検出された際に、OpenAI からチームに、対応につながるより具体的なフィードバックを提供できます。
安全性識別子は、チームが不正利用により迅速に対応するためにも役立ちます。個々のエンドユーザーまで一貫してアクティビティを追跡できるようになり、あるユーザーの不正利用によって組織の他のユーザーのアクセスまで妨げられる可能性を減らせます。
安全性識別子には、各ユーザーを一意に識別できる文字列を使用してください。個人を特定できる情報を OpenAI に送信しないよう、ユーザー名やメールアドレスをハッシュ化してください。ログインしていないユーザーに製品のプレビューを提供する場合は、代わりにセッション ID を送信できます。
個々のユーザーがモデルとやり取りする製品では、安全性識別子の使用を推奨しますが、
必須ではありません。次のように safety_identifier パラメータを使用して、
API リクエストに安全性識別子を含めてください。
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.chat.completions.create({
model: "gpt-6-astra",
messages: [{ role: "user", content: "This is a test" }],
max_completion_tokens: 5,
safety_identifier: "user_123456",
});
console.log(response.choices[0].message.content);Realtime API リクエストでは、同じ値を継続して使用する、プライバシーに配慮した識別子を、
OpenAI-Safety-Identifier ヘッダーで指定してください。短期間有効な Realtime クライアントシークレットを作成する際は、
そのシークレットを作成するサーバー側のリクエストにヘッダーを含め、
識別子をそのセッションに紐付けてください。信頼できるバックエンドから直接 WebSocket または WebRTC の接続リクエストを行う場合は、
その接続リクエストに
ヘッダーを含めてください。
安全性識別子は、API 間やセッション間で引き継がれません。
アプリケーションが Responses API リクエストで safety_identifier をすでに送信している場合でも、
各 Realtime セッションの作成時または接続時に、
同じ固定値を別途渡してください。
侵害された API キーの失効
API キーが漏洩、不正利用、またはその他の形で侵害されたと考えられる場合は、 速やかに失効させ、新しいキーに置き換えてください。セキュリティ設定 で、 すべての API キーを確認し、侵害されたキーを失効させてください。
CSAM に関するガイダンス
OpenAI は、NCMEC や Thorn をはじめとする子どもの安全に関する専門家と協力し、 子どもを保護するための実践的なガイダンスを開発者に提供しています。CSAM に関するガイダンスを ご覧ください。