安全に関するガイダンス

生成 AI モデルは強力なツールですが、制限がないわけではありません。その汎用性と適用性により、不正確な出力、偏った出力、不適切な出力など、予期しない出力につながることがあります。このような出力が害を及ぼすリスクを軽減するには、後処理と厳格な手動評価が不可欠です。

Gemini API が提供するモデルは、さまざまな生成 AI と自然言語処理（NLP）アプリケーションに使用できます。これらの機能は、Gemini API または Google AI Studio ウェブアプリでのみ使用できます。Gemini API の使用には、生成 AI の使用禁止に関するポリシーと Gemini API 利用規約も適用されます。

大規模言語モデル（LLM）が便利な理由の一つは、さまざまな言語タスクに対応できるクリエイティブなツールであるということです。残念ながら、これは大規模言語モデルによって、不適切なテキスト、配慮に欠けたテキスト、事実と異なるテキストなど、予期しない出力が生成される可能性があることも意味します。さらに、これらのモデルの驚くべき汎用性により、生成される可能性のある望ましくない出力の種類を正確に予測することも困難になっています。Gemini API は Google の AI に関する原則を念頭に置いて設計されていますが、これらのモデルを責任を持って適用するかどうかは、デベロッパーの責任です。デベロッパーが安全で責任あるアプリを作成できるよう、Gemini API にはコンテンツ フィルタリングが組み込まれており、有害な 4 要素を考慮した調整可能な安全性設定も用意されています。詳細については、安全性設定ガイドをご覧ください。

このドキュメントでは、LLM の使用時に発生する可能性のある安全上のリスクを紹介し、新しい安全性の設計と開発に関する推奨事項を推奨することを目的としています。（法律や規制によって制限が課される場合もありますが、そのような考慮事項については、このガイドでは扱いません）。

LLM を使用してアプリケーションを構築する場合は、次の手順をおすすめします。

• アプリケーションの安全性リスクを理解する
• 安全性のリスクを軽減するための調整の検討
• ユースケースに適した安全性テストを実施する
• ユーザーからフィードバックを募り、使用状況をモニタリングする

調整フェーズとテストフェーズは、アプリケーションに適したパフォーマンスに達するまで繰り返す必要があります。

アプリケーションの安全性に関するリスクを理解する

この文脈において、安全性とは、有害な表現や固定観念を助長するコンテンツを生成するなど、LLM がユーザーに害を及ぼすことを回避する能力として定義されます。Gemini API で利用可能なモデルは、Google の AI に関する原則を念頭に置いて設計されており、その使用には生成 AI の使用禁止に関するポリシーが適用されます。この API には、有害な言葉やヘイトスピーチなどの一般的な言語モデルの問題に対処し、包括性と固定観念の回避に努めるのに役立つ組み込みの安全フィルタが用意されています。ただし、アプリケーションごとにユーザーに異なるリスクセットをもたらす可能性があります。したがって、アプリケーション オーナーは、ユーザーとアプリケーションが引き起こす可能性のある被害を把握し、アプリケーションが LLM を安全かつ責任を持って使用するようにする必要があります。

この評価の一環として、危害が発生する可能性を考慮し、その重大度と緩和策を判断する必要があります。たとえば、事実に基づくエッセイを生成するアプリでは、エンターテイメントのために架空のストーリーを生成するアプリよりも、誤った情報を避けるように注意する必要があります。潜在的な安全上のリスクを調べるには、エンドユーザーや、アプリケーションの結果の影響を受ける可能性がある他のユーザーを調査することをおすすめします。これには、アプリ領域の最先端研究の調査、類似アプリの使用状況の観察、ユーザー調査やアンケートの実施、潜在ユーザーとの非公式インタビューの実施など、さまざまな方法があります。

安全性のリスクを軽減するための調整を検討する

リスクについて理解したので、リスクを軽減する方法を決定できます。ソフトウェア プロジェクトのバグのトリアージと同様に、どのリスクに優先順位を付け、どの程度のリスクを回避できるかを判断することは、重要な決定です。優先度を決定したら、最適な緩和策の種類を考えることができます。多くの場合、単純な変更によって変化が生まれ、リスクが軽減されます。

たとえば、アプリケーションを設計する際は、次の点を考慮してください。

• アプリケーションのコンテキストで許容される範囲をより適切に反映するように、モデル出力をチューニングする。チューニングにより、モデルの出力がより予測可能で一貫性のあるものになるため、特定のリスクを軽減できます。
• より安全な出力を実現する入力方法を提供する。LLM に正確に入力することで、出力の品質が向上します。入力プロンプトを試して、ユースケースで最も安全に機能するプロンプトを見つけることで、それを容易にする UX を提供できるため、労力に見合っています。たとえば、ユーザーが入力プロンプトのプルダウン リストからのみ選択するように制限したり、アプリのコンテキストで安全に機能する説明フレーズを含むポップアップ候補を提示したりできます。

• 安全でない入力をブロックし、出力をフィルタリングしてからユーザーに表示する。単純な状況では、ブロックリストを使用して、プロンプトやレスポンスに含まれる安全でない単語やフレーズを特定してブロックできます。また、人間のレビュアーにそのようなコンテンツを手動で変更またはブロックするよう要求することもできます。

• トレーニング済みの分類器を使用し、潜在的な有害性や敵対的シグナルで各プロンプトにラベルを付ける。そして、検出された有害性の種類に応じて、リクエストの処理方法にさまざまな戦略を採用できます。たとえば、入力が本質的に明らかに敵対的または不適切である場合、ブロックされ、代わりに既定のレスポンスが出力されます。

  高度なヒント

  • シグナルによって出力が有害であると判断された場合、アプリケーションは次のオプションを使用できます。
    • エラー メッセージまたは既定の出力を提供します。
    • 安全な代替出力が生成された場合は、もう一度プロンプトを試してください。同じプロンプトでも異なる出力が生成される場合があります。

• 各ユーザーに一意の ID を割り当て、一定期間に送信できるユーザークエリの量を制限するなど、意図的な不正使用に対する安全保護対策を講じる。もう一つの安全保護対策は プロンプト インジェクションからの保護ですプロンプト インジェクションは、SQL インジェクションと同様に、悪意のあるユーザーがモデルの出力を操作する入力プロンプトを設計するための方法です。たとえば、以前の例を無視するようにモデルに指示する入力プロンプトを送信する場合などです。意図的な不正使用の詳細については、生成 AI の使用禁止に関するポリシーをご覧ください。

• 本質的にリスクの低いものに機能を調整する。多くの場合、範囲が狭いタスク（テキストの一節からのキーワードの抽出など）や、人間による監視が大きいタスク（人間がレビューする短編コンテンツの生成など）は、リスクが低くなります。たとえば、メールの返信を一から作成するアプリケーションを作成する代わりに、概要の展開や別の言い回しの提案に限定できます。

ユースケースに適した安全性テストを実施する

テストは堅牢で安全なアプリケーションを構築するための重要な要素ですが、テストの範囲、スコープ、戦略はさまざまです。たとえば、法律事務所が法的文書の要約や契約書草案の作成に使用するアプリケーションのように、娯楽用の俳句生成ツールはそれほど深刻ではありません。ただし、俳句ジェネレータは幅広いユーザーが使用できるため、敵対的な試みや、意図しない有害な入力の可能性が高まる可能性があります。実装のコンテキストも重要です。たとえば、なんらかの措置を行う前に人間の専門家が出力を確認するアプリケーションは、そのような監視を行わない同一のアプリケーションよりも、有害な出力を生成する可能性が低いと見なされる可能性があります。

リスクが比較的低いアプリであっても、リリースの準備ができていると判断する前に、変更とテストを何度か繰り返すことは珍しくありません。AI アプリケーションでは、次の 2 種類のテストが特に有用です。

• 安全性ベンチマークでは、アプリケーションがどのように使用される可能性があるかという観点から、アプリケーションがどのように安全でないかを反映した安全性指標を設計し、評価データセットを使用して、指標に対するアプリケーションの性能をテストします。テストの前に、安全性指標の最小許容レベルについて検討することをおすすめします。これにより、1）これらの想定に照らしてテスト結果を評価でき、2）最も重視する指標を評価するテストに基づいて評価データセットを収集できます。

  高度なヒント

  • 「既製」のアプローチに過度に依存することに注意してください。アプリケーションのコンテキストに完全に適合するには、人間の評価者を使用して独自のテスト データセットを構築する必要があります。
  • 指標が複数ある場合は、ある指標の改善が別の指標には悪影響を及ぼす場合に、それをどのようにトレードオフするかを決定する必要があります。他のパフォーマンス エンジニアリングと同様に、平均的なパフォーマンスではなく、評価セット全体の最悪のケースのパフォーマンスに注目することをおすすめします。

• 敵対的テストでは、事前にアプリの破損を試みます。目標は、弱点を特定して、必要に応じて修正策を講じることです。敵対的テストは、アプリケーションの専門知識を持つ評価者によって多大な時間と労力がかかる可能性があります。しかし、多く行うほど、問題（特に、まれにしか発生しない問題や、繰り返し実行した後にのみ発生する問題）を発見できる可能性が高くなります。

  • 敵対的テストは、悪意のある、または意図せずに有害な入力が与えられた場合にモデルがどのように動作するかを学習する目的で、ML モデルを体系的に評価する方法です。
    • 安全でない、または有害な出力を生成するように入力が明確に設計されている場合（たとえば、特定の宗教についての差別的な暴言を生成するようにテキスト生成モデルにリクエストする場合など）、入力が悪意のあるものである可能性があります。
    • 入力自体が無害であっても、有害な出力（たとえば、特定の民族の人物についてテキスト生成モデルに質問し、人種差別的な出力を受ける場合など）を生成すると、入力が誤って有害となります。
  • 敵対的テストと標準評価の違いは、テストに使用されるデータの構成です。敵対的テストでは、モデルから問題のある出力を引き出す可能性が最も高いテストデータを選択します。つまり、まれな例や珍しい例、安全ポリシーに関連するエッジケースなど、起こり得るあらゆる有害性についてモデルの動作をプローブすることを意味します。また、構造、意味、長さなど、文のさまざまな次元に多様性を含める必要があります。テスト データセットを構築する際の考慮事項の詳細については、公平性に関する Google の責任ある AI への取り組みをご覧ください。

    高度なヒント

    • 「レッドチーム」のメンバーを募ってアプリケーションを壊す従来の方法ではなく、自動テストを使用します。自動テストにおける「レッドチーム」は、テスト対象のモデルから有害な出力を引き出す入力テキストを検出するもう 1 つの言語モデルです。

問題をモニタリングする

どれだけテストして軽減しても、完璧が保証されるわけではありません。発生する問題を特定して対処する方法を事前に計画してください。一般的なアプローチとしては、ユーザーがフィードバックを共有するためのモニタリング対象チャネル（高評価/低評価など）を設定することや、ユーザー調査を実施して多様なユーザーからフィードバックを積極的に求めることが挙げられます。これは、使用パターンが予想と異なる場合に特に有益です。

次のステップ

• Gemini API で利用できる調整可能な安全性設定については、安全性設定ガイドをご覧ください。
• 最初のプロンプトの作成を開始するには、プロンプトの概要をご覧ください。