LLMガードレールとは？使うだけの会社は自分で作る必要がある？

LLMガードレールとは、生成AIへの入力とAIの回答を検査し、有害な表現や個人情報、想定外の使い方を止めたり伏せたりする仕組みのことです。ChatGPTなどを契約して使うだけの会社であれば、ガードレールを自分で作る必要はなく、提供元が標準で持つ機能を確かめ、回答の扱いを社内ルールで決めれば足ります。ただし、標準の機能は提供元によって名前も既定値も違い、日本語での効き方にも差があります。何を確かめ、何を決めればよいかを、判断表とチェックリストにまとめました。

LLMガードレールとは｜入力と出力を検査して止める仕組み

LLMガードレールは、大規模言語モデル（LLM）と利用者のあいだに置く検査の仕組みを指す言葉になります。道路のガードレールが車の進み方を決めるのではなく、はみ出したときに道の外へ落ちないよう受け止めるのと同じで、AIの回答そのものを作るのではなく、決めた範囲を外れたやり取りを止める役割を持っています。IPAのサイトで公開された、中核人材育成プログラム受講者による「生成AIおよびAIエージェントを安全に活用するための手引書」（2026年7月）は、ガードレールを、AIシステムへの入力や出力を監視し、有害・不適切な出力の抑制や禁止用途への応答拒否といった制御をするための機能と説明しています（p.25の脚注）。

LLMとは、大量の文章から言葉のつながりを学んだAIのモデルで、ChatGPT・Claude・Geminiの中心にあるものです。検査をするのは、AIに質問が届く前と、AIの回答が利用者に届く前の2か所が基本となります。ガードレールが生成AIのリスク全体のどこを受け持つかは、生成AIのセキュリティ全体（7つのリスク）とあわせて読むと位置がつかみやすいでしょう。

入力→ガードレール→LLM→ガードレール→出力の流れ

1回のやり取りの中で、ガードレールは次の順に働きます。

1. 利用者が質問や資料を入力する
2. 入力側のガードレールが、禁止した話題・攻撃的な指示・個人情報などを検査し、問題があればLLMに渡さずに止める
3. LLMが回答を作る
4. 出力側のガードレールが、有害な表現・個人情報・決めた範囲を外れた内容を検査する
5. 問題がなければ利用者に回答を表示し、問題があれば止める・伏せ字にする・注意書きを付けるのいずれかで返す

前述の手引書（p.61）は、ガードレールをモデルとは独立した入出力の検閲・遮断機能と位置づけており、Google Cloudのドキュメントも、安全フィルタとコンテンツフィルタは有害な出力を防ぐ障壁として働く一方で、モデルの動作に直接影響するものではないと書いています。モデル自体の安全性の訓練とは別の層として、入口と出口を見張る形と考えると分かりやすいでしょう。

違反したときの動作（ブロック・マスキング・警告）

ガードレールが違反を見つけたときの動作は、大きく3つに分かれます。1つ目は止める動作で、Microsoft Foundryのコンテンツフィルターでは、フィルターに引っかかった入力はHTTP 400のエラーとなり、回答側で止まった場合は打ち切られたことを示す値（finish_reason が content_filter）が返されます。2つ目は伏せる動作です。Amazon Bedrock Guardrailsの機密情報フィルターは、個人を特定できる情報をブロックするか、マスク（伏せ字）にするかを選べるようになっています。

3つ目は止めずに記録や注意だけを残す動作で、Foundryには、判定結果（注釈）だけを返してコンテンツはブロックしない設定もあります。Bedrock Guardrailsでは、違反したときに利用者へ表示するメッセージも自分で決められます。社員が使う画面で止まったときに何と表示されるかは、使う会社にとっても大事な確認点になります。

なぜ必要か｜LLMは確率で言葉を選び、想定外の入力に弱い

ガードレールが必要になるのは、LLMが確率にもとづいて次の言葉を選ぶ仕組みで動いているからです。同じ質問でも毎回少しずつ違う答えが返ることがあり、どんな入力にどう答えるかを、作った会社でさえ事前にすべて確かめることは出来ません。Google Cloudのドキュメントにも、自社の生成AIモデルは安全性を重視して設計されているとしたうえで、露骨な表現を含むプロンプトでは有害な回答を生成する可能性があるという記載があります。前述の手引書（p.61）も、AIモデル自体の安全対策だけでは、すべての攻撃や不適切な出力を防ぐのは困難だとしています。

もう1つの性質は、想定外の入力に弱い点でしょう。通常の業務ソフトは決められた入力欄に決められた形式の値しか受け付けませんが、LLMは自由な文章を受け取り、その文章に書かれた指示にも従おうとします。そのため、ロールプレイを装った依頼や、資料の中に紛れ込ませた命令文によって、本来は答えない内容を引き出される余地が残ります。モデルを賢くするだけでは埋まらないこの隙間を、入口と出口の検査で狭めるのがガードレールの役目になります。

会社の業務で考えると、この性質は2つの困りごとにつながります。社員が悪意なく入れた文章でも、AIが思わぬ表現で答えてしまうことがある点と、社外の誰かがAIを通じて社内の情報を引き出そうとする点です。前者は主に出力側、後者は主に入力側のガードレールが受け持ちます。どちらも起こる確率は低くても、起きたときに会社の信用へ響く種類の事故といえるでしょう。

ガードレールが止めるもの｜入力側・出力側と主なリスク

ガードレールが見張る対象は、入力側と出力側で分けて考えると整理しやすくなります。扱うリスクは、有害な表現、個人情報、攻撃的な指示、誤った内容、話題の逸脱の5つに大きく分かれます。

入力側のガードレール：AIに届く前に止める

入力側のガードレールは、利用者が送った文章をLLMに渡す前に検査する仕組みです。禁止語の一覧に当たるか、暴力や差別など有害なカテゴリに当たるか、システムの指示を無視させようとする攻撃的な文面かといった点を調べ、当てはまればLLMに届く前に止めます。AnthropicはClaude向けの公式ガイドで、Claude Haiku 4.5のような軽いモデルに利用者の入力を先に判定させる方法（Harmlessness screens）を紹介しています。本体のAIに届く前に止めれば、有害な回答が作られること自体を防げる点が入力側の利点となります。

出力側のガードレール：利用者に届く前に止める

出力側のガードレールは、LLMが作った回答を利用者に表示する前に検査します。入力に問題がなくても、回答に差別的な表現や暴力的な描写、個人を特定できる情報が混ざることがあるため、出口でもう一度確かめる必要があるわけです。Microsoft Foundryのコンテンツフィルターは、ヘイト・性的・暴力・自傷行為の4つのカテゴリを、安全・低・中・高の4段階の重大度で判定し、入力と出力の両方に当てる仕組みになっています。回答を少しずつ表示する方式（ストリーミング）では、止まるまでに表示された部分は利用者に届いている点にも注意が必要となります。

個人情報・機密情報の検出とマスキング

個人情報や機密情報の検出は、経営者や総務の方がまず気にされる部分でしょう。Amazon Bedrock Guardrailsの機密情報フィルターは、生年月日や住所などの個人情報を入力と回答の両方から見つけてブロックまたはマスクでき、自社独自の番号の形式は正規表現（文字の並びのパターン）で追加できます。Google Cloudでは、個人を特定できる情報をブロックする安全フィルタが、利用者の側では変更できない構成として組み込まれていると説明されています。

一方で、この種の検出には限界もあります。前述の手引書（p.76）は、ブロックリストに登録していない形式は見逃されること、言い換えや要約をされた機密情報はルールでの検知が難しいことを、対策後に残るリスクとして挙げています。マスキングがあるから個人情報を入れてもよい、という運用にはしないようにしましょう。

プロンプトインジェクション・ジェイルブレイク・システムプロンプトの漏洩

プロンプトインジェクションとは、AIへの入力に命令文を紛れ込ませて、本来の指示や安全上の制約を無視させる攻撃を指します。このうち、ロールプレイや言葉遊びを使って安全上の制約を外させようとするものをジェイルブレイク（脱獄）と呼ぶことが多く、Microsoftはこれを検出する機能をPrompt Shields（プロンプトシールド）として提供しています。AIに与えた内部の指示文（システムプロンプト）を聞き出される漏洩も、同じ系統の攻撃として扱われます。LLMアプリの主なリスクをまとめたOWASPの一覧（2025年版）でも、プロンプトインジェクションは1番目、システムプロンプトの漏洩は7番目に挙がっています。

ガードレールはこうした入力を見つけて止める防御の1つですが、前述の手引書（p.61の脚注）が引くOWASPの説明では、確実な防御策が存在するかは不明とされており、止めきれない前提で考える必要があります。攻撃の仕組みと具体的な対策は、AIエージェントのセキュリティ対策の記事で詳しく扱っています。

RAG・外部データ経由の攻撃とエージェントの権限

RAG（社内文書などを検索して回答に使う仕組み）では、読み込んだ文書やメール、Webページの中に仕込まれた命令にAIが従ってしまう、間接的な攻撃が問題になります。Microsoftはこれをドキュメント攻撃と呼び、Prompt Shieldsの検出対象に含めています。また、AIにメール送信やファイル操作などの権限を持たせるAIエージェントでは、ガードレールより先に、権限を必要最小限に絞り、重要な操作の前に人が承認する設計が基本です。この2つは使い方の設計が中心の話になるため、詳しくはAIエージェントのセキュリティ対策をご覧ください。

ハルシネーション（誤情報）の検出はどこまで出来るか

ハルシネーションとは、AIがもっともらしい誤りを事実のように答える現象のことです。ガードレールの中には、回答が参照した資料に根拠を持つかを調べる機能もあり、Amazon Bedrock Guardrailsのコンテキストグラウンディングチェックは、資料に根拠のない回答や、質問と関係のない回答を見つける機能として説明されています。ただし、資料と照らし合わせる仕組みのため、資料を渡さない普通の質問の答えを事実確認するものではありません。この機能の日本語対応は後の節で触れますが、数字・固有名詞・法令の正しさは、今のところ人が元の資料で確かめる運用が欠かせないでしょう。

話題の制限とトーンの制御

特定の話題に答えさせない、決まった口調で答えさせる、といった制御もガードレールの役割に含まれます。Amazon Bedrock Guardrailsの拒否トピックは、アプリの目的に合わない話題を定義してブロックでき、単語フィルターでは競合他社の名前のような語を指定して止められます。開発者向けのOSSであるNVIDIA NeMo Guardrailsも、政治の話題に触れない、決めた会話の流れに沿わせる、特定の文体を使わせるといった制御を例に挙げています。こうした制御を使う会社が組むのは、自社で問い合わせ用のAIを作る場面が中心になるでしょう。

ChatGPTなどを契約して使うだけの会社は、ガードレールを自分で作る必要があるのか

社員がChatGPTやClaude、Geminiの画面を使うだけの会社であれば、ガードレールを自社で作る必要は基本的にありません。総務省・経済産業省のAI事業者ガイドライン（第1.2版、2026年3月31日）は、AIに関わる事業者をAI開発者・AI提供者・AI利用者の3つに分けており、本編p.5でAI利用者を、事業活動においてAIシステムやAIサービスを利用する事業者と定義しています。契約して使うだけの会社は、このAI利用者に当たります。同じガイドラインの第5部（p.40〜41）がAI利用者に求めているのは、提供者が定めた利用上の留意点を守って想定された範囲で使うこと、出力の精度とリスクの程度を理解したうえで使うこと、個人情報や機密情報を不適切に入力しないことなどです。仕組みを作る役割は開発者と提供者の側にあり、利用者の役割は、提供された仕組みを選び、確かめ、使い方のルールで補うことだと読むことが出来ます。

実際に、業務用のAIサービスには、ガードレールが最初から組み込まれている例があります。Microsoft Copilot（旧称 Microsoft 365 Copilot）の公式説明は、有害なコンテンツのブロック、保護された素材の検出、プロンプトインジェクション（脱獄攻撃）のブロックといった保護を挙げています。

使う会社は、ガードレールを自作するのではなく、契約するサービスを選ぶ段階でガードレールも選んでいることになります。

ただし、標準で入っているからといって、すべてが同じ強さで効くわけではありません。同じ説明の中で、Microsoftはプロンプトインジェクションを防ぐ分類器について、すべてのCopilotの場面で使えるとは限らないとも書いています。次の節で見るように、提供元によっては既定で自動ブロックがオフになっているものもあり、何が効いているかは契約前と導入後に確かめるほかありません。確かめる相手は、社員が使うサービスの提供元と、自社の管理画面の2つになります。

主な提供元が標準で持つガードレール機能と設定場所

LLMを提供する主な事業者は、それぞれ名前の違うガードレール機能を用意しています。ここでは開発者向けの公式ドキュメントに書かれた機能の名前と、設定する場所、既定の動きを整理しました。社員がブラウザで使うChatGPTやClaudeの画面そのものの設定ではなく、各社のモデルを業務システムに組み込むときの機能である点にご注意ください。

※各社の機能名・仕様は2026年9月25日時点の公式ドキュメントの記載です。画面の名前や既定値は予告なく変わることがあります。

OpenAI：Moderation（無料で使える判定の仕組み）

OpenAIが開発者向けに提供するModeration（モデレーション）は、文章と画像が有害かどうかを判定する仕組みです。判定に使うモデルはomni-moderation-latestで、公式ガイドにはモデレーションのエンドポイント（呼び出し先）は無料で使えると明記されています。判定の対象は、嫌がらせ、ヘイト、違法行為の助長、自傷行為、性的な内容、暴力の6系統を細かく分けた13のカテゴリで、画像は一部のカテゴリだけが判定の対象になります。個人情報や社内の機密情報を見分けるカテゴリはないため、それらは別の方法で守る必要があるでしょう。また、OpenAIは判定用のモデルを今後も更新する予定で、スコア（判定の確からしさ）に基づく独自の基準は見直しが要る場合があると書いています。

Microsoft：Foundryのコンテンツフィルターとプロンプトシールド

Microsoft Foundry（旧称 Azure AI サービス）に置いたモデルには、埋め込み用のモデルや音声のWhisperなどを除き、既定の安全設定が適用されます。設定の場所は、Foundryのポータルでプロジェクトを開き、左側のメニューの［Guardrails + controls］から［コンテンツ フィルター］を選んだ画面で、ヘイト・性的・暴力・自傷行為の4つについて、どの重大度から止めるかをスライダーで変えられます。Azure OpenAIのモデルでは、回答側のフィルターを外すことや判定だけにすることは、Microsoftの審査で承認された利用者に限られています。加えて、先ほど触れたPrompt Shieldsを有効にすると、利用者の入力による攻撃と、文書やメールに隠された命令による攻撃の2種類を検出できます。不適切な表現を止める組み込みの一覧（ブロックリスト）や、自社で作った語の一覧を入力側・出力側に当てることも出来ます。なお、この説明はFoundryのクラシック版ポータル向けの記事で、新しいポータルには別の記事が案内されています。

AWS：Amazon Bedrock Guardrails

AWSのAmazon Bedrock Guardrailsは、6種類の保護を組み合わせて1つのガードレールを作る方式です。内容は、有害な内容とプロンプト攻撃を見つけるコンテンツフィルター、指定した話題を止める拒否トピック、指定した語を止める単語フィルター、個人情報をブロックまたは伏せ字にする機密情報フィルター、資料に根拠のない回答を見つけるコンテキストグラウンディングチェック、論理のルールに照らして回答を検証する自動推論チェックになります。違反したときに利用者へ返すメッセージを決められ、画面上のテスト用の窓で動きを試してから使える点も特徴でしょう。ApplyGuardrailというAPIを使えば、モデルを呼び出さずにガードレールの判定だけを使うことも出来ます。

Google Cloud：安全フィルタとコンテンツフィルタ

Google Cloudでは、Geminiのモデルの回答に主に2種類のフィルタがかかります。1つは利用者が変更できない安全フィルタで、児童への性的虐待のコンテンツと個人を特定できる情報をブロックします。もう1つは構成可能なコンテンツフィルタで、ヘイトスピーチ、嫌がらせ、性的に露骨な表現、危険なコンテンツの4つについて、止める基準を選べる仕組みです。注意したいのは既定値で、ドキュメントにはgemini-3.5-flash以降のモデルでは既定値がOFF（自動ブロックなし）と書かれており、Google Cloudコンソールの設定もオフが既定と説明されています。標準で入っている機能でも、既定のままでは有害な回答を自動で止めない場合があります。

Anthropic：利用ポリシーと入力の事前選別

Anthropicは、Claudeは本来こうした攻撃に強いとしたうえで、開発者向けに守りを強める方法をまとめた公式ガイドを公開しています。ガイドに並ぶのは、軽いモデルでの事前判定に加えて、既知の攻撃パターンでの入力チェック、断り方を明示したシステムプロンプト、何度も制限を破ろうとする利用者への利用制限、回答の継続的な監視を組み合わせる方法です。利用者側に関わるのは、禁止される使い方や高リスクの用途での追加の対策を定めた利用ポリシー（Usage Policy、2025年9月15日発効）のほうでしょう。高リスクの用途については、後の節で社内ルールに落とし込みます。

こうして並べると、同じガードレールでも、提供元によって名前も、止める対象も、既定の強さも違うことが分かります。社員が部署ごとに別々のAIサービスを使っていると、誰がどのサービスをどの業務に使っているかを会社として把握しにくくなってしまいます。利用状況をつかみやすくするためにも、業務で使うAIの環境は会社で1つにまとめておく方が管理しやすいでしょう。

日本語でどこまで効くか｜提供元の公式な記載

ガードレールの精度は言語によって差があり、日本語で試験されているかは提供元の資料で確かめる必要があります。Microsoftの記載では、Azure AI Content Safetyの有害コンテンツの判定は、中国語・英語・フランス語・ドイツ語・スペイン語・イタリア語・日本語・ポルトガル語の8言語で訓練・試験されました。一方で、Prompt Shields、保護された素材の検出、根拠の検出などは英語だけで試験したとし、他の言語でも動くものの品質は言語によって異なる場合があるため、自分で試すよう求めています。

AWSの資料には、Amazon Bedrock Guardrailsの言語ごとの対応表があります。日本語が「最適化済みでサポート対象」とされているのは、標準の階層（standard tier）のコンテンツフィルターとプロンプト攻撃、同じく標準の階層の拒否トピック、機密情報フィルターになります。反対に、単語フィルターとコンテキストグラウンディングチェック、旧来の階層（classic tier）のコンテンツフィルターと拒否トピックの表には、英語・フランス語・スペイン語だけが載っています。サポートされていない言語ではガードレールは効果がないとの記載もあります。Bedrockで資料の根拠を確かめる機能は、日本語の回答には効かない前提で考えましょう。

OpenAIのModerationのガイドには、日本語での精度についての記載は見当たりませんでした。どの提供元でも、日本語の業務文書で実際に止まるかは、導入時に自社で試してみてください。試し方は、後半の確かめる手順の節にまとめています。

日本語で特に気をつけたいのは、敬語や遠回しな言い方で書かれた依頼です。英語だけで試験された機能では、こうした言い回しでの判定の精度は公式の資料からは分かりません。社内の実際の文書に近い文面で試すことが、提供元の資料だけでは分からない差を埋める近道となります。

LLMガードレールの限界｜完全には防げず、権限管理の代わりにもならない

ガードレールは被害を減らす仕組みであって、すべての問題を防ぐ仕組みではありません。前述の手引書（p.61）は、提供者に求めるガードレールやマスキングの機能について、これらも万全ではなく単独での完全な防御を保証しないと書いています。新しい言い回しの攻撃は次々に生まれており、登録された形に当てはまらない入力はすり抜ける可能性が残ります。

ガードレールは、誰が何を使えるかという認証や権限の管理の代わりにはなりません。見せてはいけない資料をAIが読める状態にしておけば、ガードレールが見逃した1回で情報は外に出てしまいます。アカウントの管理、閲覧権限の整理、ログの取得といった土台の上に、追加の層としてガードレールを重ねる順番が基本となります。

止めすぎと見逃しのトレードオフ

ガードレールの強さには、止めすぎと見逃しの綱引きがあります。基準を厳しくすると、医療や安全管理の業務で必要な言葉まで有害と判定され、仕事にならない場面が増えてしまいます。反対に緩めれば、本来止めたい回答が通る確率が上がります。Microsoft Foundryで重大度のしきい値を選べるようにしているのも、Google Cloudで止める基準を選ばせているのも、この調整を使う側に委ねるためでしょう。社内で止まりすぎる場面が続くと、社員が会社の外のAI（野良AI・シャドーAI）に流れる原因にもなりかねません。止まった件数と、止まって困った件数の両方を見て、強さを決めていきましょう。

実装方式の違い（ルールベース・分類器・別のLLMによる判定）

ガードレールの判定方法は、大きく3つに分けられます。1つ目はルールベースで、禁止語の一覧や正規表現に当てはまるかを調べる方式です。速く、結果の理由も説明しやすい反面、登録していない言い回しは通してしまいます。2つ目は機械学習の分類器で、Microsoftのコンテンツフィルターのように、文章が有害なカテゴリに当たる確からしさを判定するモデルを使います。3つ目は別のLLMに判定させる方式で、Anthropicが紹介する軽いモデルでの事前判定がこれに当たるでしょう。判定の柔軟さは3つ目が高いものの、1回ごとに別のモデルを呼ぶぶん時間と費用がかかるため、複数を組み合わせる形がAnthropicのガイドなどで紹介されています。

判断表｜このリスクは誰が止めるか

ガードレールで止められる範囲と止められない範囲を、リスクごとに表にしました。列は、提供元のガードレール、会社で契約した環境の設定、社内ルールと人の確認の3つとし、それぞれが主に受け持つ部分を書いています。

※提供元のガードレールの欄は、この記事で取り上げたMicrosoft・AWS・Google Cloud・OpenAI・Anthropicの公式ドキュメントの記載（2026年9月25日時点）をもとにした目安です。実際に効く範囲は、契約するサービスと設定で変わります。

表から分かるとおり、提供元のガードレールがはっきり受け持てるのは有害な表現の判定まででしょう。個人情報や誤った内容はガードレールが途中まで拾っても、最後は人が止める部分として残り、社外への誤送信のように、そもそもガードレールの外で起きる事故も起こり得ます。先に触れた手引書の指摘のとおり、個人情報の検出は登録した形式に頼る部分が大きく、社内ルールの側で入れてよい情報を決めておく必要があります。表の右の列は、会社が自分で決めない限り誰も埋めてくれない部分となります。ここを埋めるのが、次の節のチェックリストと社内ルールの役割です。

使う会社が確かめること・決めること（チェックリスト）

チェックリストは、提供元に確かめる項目と、社内で決める項目の2つに分けました。AI事業者ガイドライン（第1.2版）の公開ページには、事業者向けのチェックリスト（別添7）とワークシートも掲載されているので、あわせて照らし合わせてみてください。

提供元・管理画面で確かめる項目

• 有害な入力と回答を止める仕組みがあるか提供元の説明に、入力と出力の両方を検査すると書かれているかを見ます。
• 既定で有効か、オフになっていないか自動ブロックが既定でオフのモデルもあります。システムに組み込む開発会社には、どの基準で動かしているかを尋ねます。
• 止める強さを管理者が変えられるか変えられる場合は、誰が変える権限を持つかも決めておきます。
• 日本語で試験されているか提供元の対応言語の資料に、日本語が載っているかを確かめます。載っていない機能は効かない前提で考えます。
• 止まったときに社員の画面に何が表示されるかエラーだけが出るのか、理由が表示されるのかで、社内の問い合わせの量が変わります。
• 止まった記録や利用ログを管理者が見られるか後から入力を確かめられるかどうかで、事故の調査にかかる時間が変わります。
• 提供元の利用ポリシーで禁止された用途に当たらないか利用ポリシーを一度読み、高リスクの用途に当たる業務がないかを確認します。

社内で決める項目

• AIに入れてよい情報と入れない情報個人情報保護委員会の注意喚起（2023年6月2日）は、個人情報を含むプロンプトを入れる場合に、利用目的の達成に必要な範囲内か、提供事業者が機械学習に利用しないか等を十分に確認するよう求めています。
• 回答を社外に出す前に誰が読むか顧客への文書、Webサイトの記事、提案書など、社外に出るものの種類ごとに確認する人を決めます。
• 数字・固有名詞・法令を元の資料で確かめるか確かめる範囲を決めないと、忙しい時期ほど確認が省かれがちになります。
• 顧客への自動返信にAIの回答を使うか使う場合は、AIが答えていることを相手に伝える方法も決めます。
• 止まりすぎたときの相談先業務に必要な表現が止められたときに、誰に相談し、誰が強さを見直すかを決めます。
• 制限を繰り返し破ろうとした社員への対応ログで見つかったときに、注意するのか、利用を止めるのかを先に決めておきます。

項目の多くは、生成AIの社内ガイドラインにそのまま書き込める内容です。セキュリティ全体の点検には、生成AIのセキュリティチェックリストもあわせて使ってみてください。

税務・法律・医療などの回答は専門家が確認する

Anthropicの利用ポリシーは、法律、医療、保険、金融、雇用・住宅などを高リスクの用途とし、個人や消費者に向けた助言や判断にAIを使う場合、その分野の有資格者が公開や確定の前に内容を確認すること（Human-in-the-loop）を求めています。あわせて、AIの出力を個人や消費者に直接見せる場合には、AIを使っている旨を少なくとも各セッションの最初に伝える義務もあります。税務は一覧に名指しされていませんが、法令の解釈を含む回答である以上、会計事務所や経理部門でも同じ考え方で扱うのが安全でしょう。AIが作った税務の回答を顧客に送る前に、資格を持つ担当者が読む手順を社内ルールに入れてみてください。

社内ルールの文例（出力の扱い）

出力の扱いに絞った社内ルールの文例を載せます。自社の業務に合わせて言葉を直し、そのままガイドラインに加えることが出来ます。

1. AIの回答を社外（顧客・取引先・Webサイト）に出す前に、担当者が全文を読んで確認する。
2. 回答に含まれる数字・固有名詞・日付・法令は、元の資料で確かめてから使う。
3. 税務・法律・労務・医療に関わる回答を顧客に示す場合は、資格を持つ担当者が確認し、AIを使って作成したことを伝える。
4. 顧客からの問い合わせに、AIの回答をそのまま自動で返信する使い方はしない。
5. 個人情報・顧客の機密情報は、会社が認めた環境で、業務に必要な範囲に限って入力する。
6. AIに回答を断られた内容を、言い回しを変えて繰り返し聞き出そうとしない。

6つ目は、断られたことを抜け道探しの合図にしないための一文です。Anthropicのガイドも、何度も制限を回避しようとする利用者には利用の制限を検討するよう書いており、社内でも同じ線を引いておくと運用がぶれにくくなります。

効いているかを確かめる手順｜ログ・監視・レッドチーム

ガードレールは入れて終わりではなく、効いているかを定期的に確かめる必要があります。攻撃者の目線でわざと弱点を探す方法をレッドチーミングと呼び、AIセーフティ・インスティテュートの「AIセーフティに関するレッドチーミング手法ガイド」（第1.10版、2025年3月31日）は、その目的を、弱点や対策の不備を見つけて修正し、堅牢にすることと説明しています。本格的な手法は開発する会社向けですが、使う会社でも考え方は取り入れられます。開発者でなくても出来る確かめ方を、4つの手順にまとめました。

1. 年に数回、管理者が明らかに不適切な依頼（暴力的な表現を求める文など）を入れ、止まるか、何が表示されるかを記録する
2. 架空の氏名・住所・電話番号を含む文を入れ、伏せ字になるか、そのまま通るかを見る（実在する人の情報は使わない）
3. 社内で止まりすぎた例と、止まらずに困った例を集め、強さの設定や社内ルールの見直しに使う
4. 利用ログで、業務外の使い方や、同じ社員による繰り返しの回避の試みがないかを見る

Anthropicのガイドも、回答を定期的に分析し、その結果で入力チェックや指示文を直していく継続的な監視を勧めています。試した攻撃が止まったからといって、安心しきるのは早いでしょう。同じレッドチーミング手法ガイドは、実行した攻撃が成功しなかったことをもって、すべての攻撃が成功しないことを保証するものではないと注意しています。確かめた結果は記録に残し、提供元がモデルや判定の仕組みを更新したら試し直しましょう。OpenAIも、判定用のモデルを今後も更新していく予定だと書いています。

自社でAIを組み込む場合の選択肢と関連する基準

問い合わせ用のチャットボットなど、自社のサービスにLLMを組み込む場合、会社はAI利用者だけでなくAI提供者の立場も兼ねることになります。この場合は、提供元のガードレールを有効にしたうえで、自社の用途に合わせた設定を足す作業が発生します。開発を外部に頼む場合も、次の3点を発注する側が知っておくと話が早いでしょう。

開発する会社が使うOSSツール（NeMo Guardrails・Llama Guard・Guardrails AI）

OSS（無償で公開されたソフトウェア）のガードレールには、代表的な例として次の3つがあります。

• NVIDIA NeMo Guardrailsは、会話型のLLMアプリにプログラムでガードレールを加えるためのOSSで、話題の制限や会話の流れの固定、文体の指定などを扱います。
• MetaのLlama Guardは入力と出力の有害さを判定するモデル群で、同じくMetaのPrompt Guardは、プロンプトインジェクションやジェイルブレイクを見つけるための道具として公開されています。
• Guardrails AIは、入力と出力を検査するガード（Input/Output Guards）をアプリに組み込むPythonのフレームワークで、検査項目（validators）を集めたGuardrails Hubから必要なものを選んで使います。

いずれも開発者が組み込む前提の部品で、使う会社が自分で入れて動かすものではありません。クラウドの標準機能で足りるか、OSSを足すかは、開発会社と相談して決めましょう。

OWASP Top 10 for LLM Applicationsとの対応

Webアプリの安全性の指針で知られるOWASPは、LLMアプリの主なリスク10項目を2025年版として公開しています。ガードレールと関わりが深いのは、プロンプトインジェクション（LLM01）、機密情報の開示（LLM02）、不適切な出力の扱い（LLM05）、システムプロンプトの漏洩（LLM07）、誤情報（LLM09）あたりになります。過剰な権限（LLM06）やサプライチェーン（LLM03）、際限のない消費（LLM10）は、権限の設計や契約・利用量の管理で対処する項目で、ガードレールの守備範囲の外にあります。発注先の開発会社に、10項目のどれをどの仕組みで押さえるかを表にしてもらうと、抜けが見つけやすくなります。

規制・ガバナンスとの関係（AI事業者ガイドライン・EU AI Act・NIST AI RMF）

国内では、先に触れたAI事業者ガイドライン（第1.2版）が、法的な拘束力のない指針（ソフトロー）として、開発者・提供者・利用者それぞれの取り組みを示すものです。海外では、EUのAI法（AI Act）が2024年8月1日に発効し、一部の例外を除いて2026年8月2日から適用され（高リスクAIの規定は2027年12月以降に延期）、チャットボットなどでAIとやり取りしていることを人に知らせる透明性のルールも同じ8月から効力を持つと欧州委員会は説明しています。米国のNIST（国立標準技術研究所）が2023年1月26日に公表したAIリスクマネジメントフレームワーク（AI RMF）は任意で使う枠組みで、2024年7月26日には生成AI向けの追補（NIST-AI-600-1）も公表されました。EUで事業をしていない国内の中小企業にとって、これらがすぐに義務になるわけではありませんが、顧客や取引先からAIの使い方を問われたときの説明の土台にはなります。まずは国内のガイドラインに沿って、使う側の取り組みを文書にしておくことから始めましょう。

よくある質問

まとめ

LLMガードレールとは、生成AIへの入力と回答を検査し、有害な表現や個人情報、想定外の使い方を止める仕組みです。ChatGPTなどを契約して使うだけの会社は、AI事業者ガイドラインでいうAI利用者に当たり、ガードレールを自分で作る必要はありません。やることは、提供元の標準機能が有効か、日本語で試験されているか、止まったときに何が表示され記録されるかを確かめることと、回答を誰が確認するかを社内ルールで決めることの2つになります。ガードレールは完全ではなく、権限管理や人の確認の代わりにはならないため、判断表の右の列を自社で埋めておきましょう。

生成AIのリスク全体は生成AIのセキュリティ｜7つのリスクと会社で安全に使う仕組みで、社内ルールの作り方は生成AIの社内ガイドラインの作り方で扱っています。法人のAI活用に関する他の記事はAI活用コラム一覧をご覧ください。