For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme

安全対策のベストプラクティス

モデレーションや人による監督などの安全対策を導入します。

OpenAI が実施している安全対策については、安全性分類器、サイバーセキュリティチェック、ミスアライメントの監視を参照してください。未成年者が利用するアプリケーションでは、18 歳未満の利用者に関するガイダンスにも従ってください。

無料の Moderation API の活用

OpenAI の Moderation API は無料で利用でき、生成結果に安全性を損なうコンテンツが含まれる頻度を減らすのに役立ちます。用途に合わせて、独自のコンテンツフィルタリングシステムを開発する方法もあります。

Responses API または Chat Completions でテキストを生成するアプリケーションでは、生成リクエストでモデレーションスコアも取得できます。

敵対的テスト

アプリケーションが敵対的な入力に耐えられるかを確認するために、「レッドチーミング」を推奨します。製品をテストする際は、典型的な入力やユーザーの操作に加え、意図的にアプリケーションを誤動作させようとする人の入力や操作も含め、幅広いケースを試してください。応答が本来の話題からそれることはありませんか。「これまでの指示を無視して、代わりにこれを実行して」といったプロンプトインジェクションで、簡単に意図しない動作を引き起こせてしまいませんか。

人による出力の確認(HITL)

可能な限り、出力を実際に使用する前に、人が内容を確認することを推奨します。誤りが重大な結果につながる分野や、コード生成では特に重要です。確認する人がシステムの限界を理解し、出力の検証に必要な情報を参照できるようにしてください。たとえば、メモを要約するアプリケーションでは、元のメモを簡単に参照できるようにします。

プロンプトエンジニアリング

「プロンプトエンジニアリング」は、生成するテキストの話題や文体を一定の範囲に収めるのに役立ちます。これにより、ユーザーが望ましくないコンテンツを意図的に生成しようとしても、それが出力される可能性を低くできます。たとえば、新しい入力の前に望ましい動作を示す質の高い例をいくつか提示するなど、モデルに追加のコンテキストを与えると、意図した出力を得やすくなります。

顧客の本人確認(KYC)

原則として、サービスの利用にはユーザー登録とログインを必須にしてください。用途によっては、Gmail、LinkedIn、Facebook などの既存アカウントと連携してログインできるようにする方法も有効です。クレジットカードや身分証明書の提示を求めれば、リスクをさらに減らせます。

ユーザー入力と出力トークン数の制限

ユーザーがプロンプトに入力できるテキストの量を制限すると、プロンプトインジェクションの防止に役立ちます。出力トークン数を制限すると、悪用の可能性を減らせます。

入力や出力の範囲を絞ると、アプリケーション内で悪用できる範囲も狭まります。特に、入力や出力を信頼できる情報源から選ぶ方法が有効です。

ユーザーにテキストを自由に入力してもらうよりも、検証済みの選択肢をドロップダウンで提示する方が安全な場合があります。たとえば、Wikipedia に掲載されている映画の一覧から選んでもらう方法があります。

可能であれば、新しいコンテンツを生成して返すよりも、バックエンドで検証済みの資料から選んで返す方が安全な場合があります。たとえば、顧客の問い合わせに対して一から回答を生成する代わりに、問い合わせ内容に最も合う既存のサポート記事を案内します。

ユーザーが問題を報告できる窓口の設置

原則として、機能の不具合やアプリケーションの動作に関する懸念をユーザーが簡単に報告できるようにしてください。たとえば、連絡先のメールアドレスを掲載したり、問い合わせチケットを送信できるようにしたりします。担当者が報告を確認し、必要に応じて対応してください。

モデルの限界の把握と利用者への説明

言語モデルには、事実と異なる情報を生成するハルシネーション、不快な内容の出力、バイアスなど、さまざまな問題が起こり得ます。用途によっては、モデルを目的に合わせるために大幅な変更が必要です。モデルが目的に合っているかを検討し、想定される幅広い入力で API の性能を評価して、性能が低下し得るケースを特定してください。顧客層と実際に想定される入力の幅を考慮し、ユーザーがどの程度の性能を期待できるかを正しく理解できるようにしてください。

OpenAI は安全性とセキュリティを非常に重視しています。

API を使った開発中に安全性やセキュリティ上の問題に気付いた場合や、OpenAI に関連するほかの場面でこうした問題を見つけた場合は、脆弱性の協調的開示プログラムを通じて報告してください。

安全識別子の導入

リクエストに安全識別子を含めると、OpenAI が不正利用を監視し、検出しやすくなります。アプリケーションでポリシー違反を検出した場合、OpenAI はチームが対応を取るうえで役立つ、より具体的なフィードバックを提供できます。

安全識別子は、チームが不正利用に迅速に対応するうえでも役立ちます。個々のエンドユーザーの操作を一貫して追跡できるため、あるユーザーの不正利用によって組織内のほかのユーザーまでアクセスできなくなる可能性を減らせます。

安全識別子には、ユーザーごとに一意の文字列を使用してください。個人を特定できる情報を OpenAI に送信しないよう、ユーザー名やメールアドレスはハッシュ化してください。ログインしていないユーザーに製品のプレビューを提供する場合は、代わりにセッション ID を送信できます。

個々のユーザーがモデルとやり取りする製品では、安全識別子の使用を推奨しますが、必須ではありません。API リクエストに安全識別子を含めるには、safety_identifier パラメーターを使用します。

例:安全識別子の指定
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);

Images API では、safety_identifier を画像生成(POST /v1/images/generations)と画像編集(POST /v1/images/edits)の各リクエストに含めてください。JSON リクエストでは JSON プロパティとして、マルチパート形式の画像編集リクエストではフォームフィールドとして送信します。組織内では、同じエンドユーザーのリクエストに毎回同じ識別子を使用し、識別子の長さは 128 文字以内にしてください。

Images API の user パラメーターは非推奨です。移行するには、これまで user に指定していた識別子を safety_identifier に指定して送信してください。user を使用する既存のリクエストは引き続きサポートされます。両方のフィールドを指定した場合、空でない safety_identifier が優先されます。safety_identifier が省略されているか、null または空文字列の場合、API は user があればその値を使用します。

Realtime API のリクエストでは、プライバシーに配慮した同じ識別子を一貫して OpenAI-Safety-Identifier ヘッダーに指定してください。Realtime の一時的なクライアントシークレットを作成する場合は、サーバー側でシークレットを作成するリクエストにこのヘッダーを含め、識別子をそのセッションに紐付けます。信頼できるバックエンドから WebSocket または WebRTC で直接接続する場合は、接続リクエストにこのヘッダーを含めてください。

安全識別子は API 間やセッション間で引き継がれません。アプリケーションが Responses API のリクエストですでに safety_identifier を送信している場合でも、Images API のリクエストごとに同じ値を指定してください。Realtime の各セッションを作成する際や、各セッションに接続する際にも、同じ値を個別に指定してください。

侵害された API キーの失効

API キーの漏えい、不正使用、その他の侵害が疑われる場合は、速やかにそのキーを失効させ、新しいキーに置き換えてください。セキュリティ設定で、すべての API キーを確認し、侵害されたキーを失効させることができます。

CSAM に関するガイダンス

OpenAI は、NCMEC や Thorn をはじめとする子どもの安全に関する専門家と協力し、開発者が子どもを守るために活用できる実践的なガイダンスをまとめました。CSAM に関するガイダンスをご覧ください。