安全に関するガイダンス

生成 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 を割り当て、特定の期間に送信できるユーザー クエリの量に上限を設けるなど）。もう 1 つの保護対策は、プロンプト インジェクションの可能性から保護することです。プロンプト インジェクションは、SQL インジェクションと同様に、悪意のあるユーザーがモデルの出力を操作する入力プロンプトを設計する方法です。たとえば、以前の例を無視するようにモデルに指示する入力プロンプトを送信します。意図的な不正使用について詳しくは、生成 AI の使用禁止に関するポリシーをご覧ください。

• リスクが本質的に低いものに機能を調整する。 範囲が狭いタスク（テキストの抜粋からキーワードを抽出するなど）や、人間の監督がより厳しく行われるタスク（人間がレビューするショート フォーム コンテンツを生成するなど）は、リスクが低いことがよくあります。たとえば、メールの返信を最初から作成するアプリを作成する代わりに、概要の拡張や言い換えの提案に限定する場合があります。

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

テストは堅牢で安全なアプリケーションを構築するうえで重要な要素ですが、テストの範囲、スコープ、戦略はさまざまです。たとえば、単なる俳句ジェネレータは、法律事務所が法的文書の要約や契約書の作成に使用するアプリケーションよりも、リスクが低いと考えられます。しかし、俳句ジェネレータはより多くのユーザーが使用する可能性があるため、敵対的な試みや意図しない有害な入力が発生する可能性が高くなります。実装コンテキストも重要です。たとえば、アクションを実行する前に人間の専門家がアウトプットを審査するアプリケーションは、そのような監督がない同一のアプリケーションよりも有害なアウトプットを生成する可能性が低いと見なされる場合があります。

リスクが比較的低いアプリケーションであっても、変更とテストを数回繰り返してからリリースする準備が整ったと確信することは珍しくありません。AI アプリケーションには、次の 2 種類のテストが特に役立ちます。

• 安全性ベンチマークでは、アプリケーションが使用される可能性のあるコンテキストで安全でなくなる可能性のある方法を反映した安全性指標を設計し、評価データセットを使用して、アプリケーションが指標に対してどの程度機能するかをテストします。テストの前に、安全性の指標の最小許容レベルについて検討しておくことをおすすめします。そうすることで、1）テスト結果を期待値と比較して評価できる、2）最も重要な指標を評価するテストに基づいて評価データセットを収集できる、というメリットがあります。

  高度なヒント

  • 「既製の」アプローチに過度に依存しないようにしてください。アプリケーションのコンテキストに完全に適合させるには、人間の評価者を使用して独自のテスト データセットを構築する必要がある可能性が高いためです。
  • 指標が複数ある場合は、変更によって一方の指標が改善され、他方の指標が低下した場合のトレードオフをどのように行うかを決定する必要があります。他のパフォーマンス エンジニアリングと同様に、平均パフォーマンスではなく、評価セット全体の最悪のケースのパフォーマンスに焦点を当てることをおすすめします。

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

  • 敵対的テストは、悪意のある入力または不注意による有害な入力が与えられた場合に、ML モデルがどのように動作するかを確認するために、ML モデルを体系的に評価するためのメソッドです。
    • 入力が明らかに安全でない、または有害な出力を生成するように設計されている場合（たとえば、特定の宗教についてヘイトスピーチを生成するようテキスト生成モデルに求める場合）、その入力は悪意があるとみなされます。
    • 入力自体は無害でも、有害な出力を生成する場合（たとえば、テキスト生成モデルに特定の民族の人を説明するように求めて、人種差別的な出力を受け取る場合など）は、不注意による有害な入力とみなされます。
  • 敵対的テストと標準評価の違いは、テストに使用されるデータの構成です。敵対的テストでは、モデルから問題のある出力を引き出す可能性が最も高いテストデータを選択します。つまり、安全性ポリシーに関連するまれな例や異常な例、エッジケースなど、考えられるすべての種類の危害についてモデルの動作を調査します。また、構造、意味、長さなど、文のさまざまな次元の多様性も含まれている必要があります。テスト データセットの構築時に考慮すべき事項の詳細については、公平性に関する Google の責任ある AI の取り組みをご覧ください。

    高度なヒント

    • 従来の「レッドチーム」に人を登録してアプリケーションを破壊しようとする方法ではなく、自動テストを使用します。自動テストでは、レッドチームは、テスト対象のモデルから有害な出力を引き出す入力テキストを見つける別の言語モデルです。

問題の有無をモニタリングする

テストと緩和をどれだけ行っても、完璧を保証することはできません。そのため、発生した問題をどのように特定して対処するかを事前に計画します。一般的なアプローチとしては、ユーザーがフィードバックを共有するためのモニタリング対象チャネル（高評価/低評価など）を設定することや、ユーザー調査を実施して、さまざまなユーザーから積極的にフィードバックを収集することなどがあります。特に、使用パターンが想定と異なる場合は、このアプローチが有効です。

次のステップ

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