⚠️ この記事は開発者向けです。 Gemini API で作ったアプリの応答を、どの程度ブロックするか調整する話です。 自分が使うときのプライバシー設定（学習に使わせない等）をお探しの方は、Geminiを安全に使う をご覧ください。対象も操作する場所も違います。
Gemini API でアプリを作るとき、「不適切な応答が返ってきたら困る」「逆に、まじめな質問まで弾かれて使いにくい」という悩みが出てきます。この調整を担うのが Gemini safety settings（安全性設定） です。この記事では、まず安全性設定が何をする設定なのかを整理し、用途別の方針と運用の注意点までやさしく解説します。なお、これはGeminiアプリを使う側のプライバシーの話とは別物で、API開発者が応答の安全性を調整する話です。
結論：応答のブロックの強さを用途に合わせて調整する設定
先に要点だけ言うと、安全性設定（safety settings）でできるのは次のことです。
- 有害カテゴリごとに、応答をどの程度ブロックするかを段階で指定する: ヘイトや嫌がらせといった種類ごとに、強くブロックするか緩めるかを選べる
- アプリの用途に合わせて、厳しさを調整する: 子ども向けなら厳しく、専門用途で誤ブロックを減らしたいなら緩め、といった調整ができる
つまり、安全性設定は「APIの応答の安全性のつまみ」です。何でも自由に出させる設定ではなく、カテゴリ別にブロックの強さを変えるための仕組みだと捉えるとわかりやすいです。
注意したいのは、すべてを自由に調整できるわけではない点です。一部の安全フィルタは常時動作で、開発者が無効化できない場合があります。詳しくは後述します。
安全性設定の考え方
なぜ安全性設定が必要なのか
生成AIは、入力次第で望ましくない応答を作ってしまうことがあります。アプリとして公開する以上、そうした応答がそのままユーザーに届くのは避けたいところです。
一方で、ブロックを一律に強くしすぎると、本来は問題のない質問まで弾かれてしまう（過剰ブロック）という別の問題が起きます。たとえば医療や法律、防犯、セキュリティといった話題は、まじめな相談でも単語だけ見ると引っかかりやすいことがあります。
この「危険な応答は止めたい／まじめな利用は通したい」というバランスを、アプリの用途に合わせて取るための仕組みが安全性設定です。
ブロックは「カテゴリ × 強さ」で考える
安全性設定の基本構造はシンプルです。
- カテゴリ: 有害な内容を種類で分けたもの（ヘイト、嫌がらせ、性的な内容、危険な行為など）
- 強さ（しきい値）: そのカテゴリをどの程度の確からしさでブロックするか。強くブロックする〜ほとんどブロックしない、を段階で指定する
安全性設定のイメージ（カテゴリごとに強さを指定）:
ヘイト : 強めにブロック
嫌がらせ : 強めにブロック
性的な内容 : 強めにブロック
危険な行為 : ふつう
^^^^ カテゴリごとに別々の強さを設定できる具体的なカテゴリ名の正確な表記・しきい値の識別子（enum）・既定値・対応モデルによる差は更新が速い部分です。本記事では概念にとどめ、実際の値は公式の安全性設定ドキュメントで最新をご確認ください。
調整できない保護もある
ここが特に大事な点です。安全性設定で調整できるのは一部のカテゴリで、子どもの安全に関わるような中核的な保護は常時動作で、開発者が緩めたり無効化したりできない場合があります。
「全部オフにすれば何でも出せる」わけではない、と理解しておくと安全です。どこまで調整できるかは公式ドキュメントが一次情報なので、設計の前に必ず確認してください。
設定の方針（用途別）
しきい値は「強ければ良い・弱ければ良い」というものではなく、アプリの用途とユーザー層から逆算するのが基本です。目安を表にすると次のようになります。
| アプリの用途・ユーザー層 | 方針の目安 |
|---|---|
| 子ども向け・教育・公共性が高い | 厳しめ（強くブロック寄り） |
| 不特定多数の一般ユーザーが使う | 標準〜やや厳しめ |
| 社内の限定ツール・専門用途 | 用途に応じて調整（誤ブロックを減らす方向もあり） |
| 防犯・医療・法律など堅い話題を扱う | 過剰ブロックに注意しつつ、緩めるなら検証を厚く |
ポイントは2つです。
- まず標準で試し、困ったら調整する: いきなり極端な設定にせず、標準的な強さで動かして、過剰ブロックや漏れが出たカテゴリだけを見直す
- 緩めたぶんは自分で担保する: しきい値を緩めるほど、不適切な応答が通る可能性は上がります。そのぶんの安全確認（出力チェックや人手レビュー）を厚くする前提で緩める
設定を緩める判断は「楽をするため」ではなく「過剰ブロックを正すため」に使うのが健全です。緩めること自体が目的になると、リスクだけが増えます。
運用の注意（検証・責任・最新は公式）
安全性設定は強力ですが、これ一つに頼り切るのは危険です。次の点を必ず押さえてください。
- ユーザー入力は必ず検証する: APIに渡す前に、入力の長さ・内容・形式をアプリ側でチェックする。安全性設定は「出力側」の対策であり、「入力側」の検証は別途必要です
- 出力もそのまま信用しない: ブロックされなかった応答が必ず安全とは限りません。用途によっては、出力を表示する前にアプリ側でも確認する設計にします
- ログと人手レビューを用意する: どんな入力で何がブロックされたか／されなかったかを記録し、定期的に見直すと、設定の過不足に気づけます
- 年齢・用途への配慮: 子ども向けや公共性の高いサービスでは、年齢確認や利用規約など、安全性設定の外側の仕組みも組み合わせます
- 最終的な責任は開発者側にある: 安全性設定はGoogleが用意した道具ですが、どう設定し、どう公開するかを決めるのはアプリの提供者です。最終責任は開発者にあるという前提で設計します
関連して、役割や禁止事項をモデルに固定するsystem instruction設計や、プロンプトインジェクション対策も合わせて検討すると、より堅くなります。安全性設定だけを最後の砦にしないのがコツです。
一次体験：標準で試してから、カテゴリ単位で調整する
実際に堅い話題（防犯・セキュリティ系）を扱うアプリで試すと、最初から極端な設定にしないほうがうまくいきました。まず標準的な強さで動かし、過剰ブロックが起きたカテゴリだけを少し緩めるという進め方です。
このとき効いたのが、ブロックの記録を残しておくことでした。「どんな入力で・どのカテゴリが弾かれたか」が見えると、緩めるべきカテゴリと、むしろ厳しくすべきカテゴリが切り分けられます。やみくもに全カテゴリを緩めると、過剰ブロックは消える代わりに別のリスクが増える、と体感しました。カテゴリ単位で、根拠を持って動かすのが安全だと感じています。
まとめ
- Gemini safety settings（安全性設定）は、有害カテゴリごとに応答をどの程度ブロックするかを開発者が調整する仕組み
- 構造は「カテゴリ × ブロックの強さ（しきい値）」。アプリの用途とユーザー層から逆算して決める
- 一部のフィルタは常時動作で調整できない場合がある（子どもの安全など）。全部はオフにできない前提で考える
- 方針は「まず標準で試す → 過剰ブロックや漏れが出たカテゴリだけ調整 → 緩めたぶんは検証を厚く」
- 安全性設定は一つの層にすぎない。入力検証・出力確認・ログ・人手レビュー・年齢/用途配慮を組み合わせ、最終責任は開発者が負う
- 具体的なカテゴリ名・しきい値の識別子・既定値・対応モデル差は更新が速いため、必ず公式の安全性設定ドキュメントで最新を確認する
API開発の全体像から押さえたい方はGemini API入門（AI Studio）から、ユーザー側のデータの扱いが気になる方はGeminiを安全に使う（プライバシー）をあわせてご覧ください。応答の挙動を固めたい場合はsystem instruction設計も役立ちます。