NeMo Guardrailsは何を止める？｜社内AIの守りを足す線

「社内向けのAIチャットを作ったが、聞かれてもいない話題にまで答えてしまう」「指示文に『この話題には答えないこと』と書いているだけで、本当に止まっているのか誰にも分からない」——社内で生成AIのアプリを作り始めた情報システム部門や開発の担当から、こうした声が上がっています。作ってみて初めて、止める仕組みが空いていることに気づくのは珍しくありません。守りは指示文の一行で足りるものではありません。本当は、何を止めるかを決める人と、止めすぎ・止め漏れを見直す人が決まっていて、はじめて守りとして働きます。この記事では、NVIDIA が公開する NeMo Guardrails を例に、社内の生成AIアプリに守りを外付けの部品で足すかどうかと、足したあとの持ち場を整理します。

NeMo Guardrailsは何をする部品か

NeMo Guardrails は、大規模言語モデルを使ったアプリに、プログラムで「守り」を足すためのオープンソースの部品です。公式ドキュメントによれば、安全でない入力、扱う範囲から外れた入力、方針に反する入力やモデルの応答を、止める、書き換える、検証することができます。社内の問い合わせ窓口のAIや、社内文書を検索して答えるAIのような、自社で作るアプリの部品として使う想定です。

公式GitHubでは、守りを置ける場所を5つに分けています。利用者の入力を確かめる入力の守り、モデルへの問いかけ方や会話の流れを決める対話の守り、検索で取ってきた文書の断片を確かめる検索の守り、アプリが外部の道具を呼ぶときの入出力を確かめる実行の守り、そしてモデルの応答を確かめる出力の守りです。

守りの中身は、設定ファイルと Colang という専用の記法で書きます。Colang には 1.0 と 2.0 があり、2026年10月時点の公式GitHubでは 1.0 が既定とされています。つまり、この部品は画面で設定を選ぶ製品ではなく、開発の担当がアプリに組み込んで使う部品です。ここが、管理画面のある市販の製品と大きく違う点です。

誰が作っていて、国内でまだ知られていない理由

NeMo Guardrails は、半導体の大手 NVIDIA が公式GitHubで公開しています。ライセンスは Apache 2.0 で、商用のアプリにも組み込めます。2026年10月時点でスターの数は約7,300あり、リリースも続いています。最新は2026年9月16日の v0.24.1 で、その前の v0.24.0 は8月26日、v0.23.0 は7月1日と、ほぼ1〜2か月ごとに新しい版が出ています。

それでも、日本語でこの部品を解説した記事は2026年10月時点でほとんど見当たりません。確かめられる範囲で理由を挙げると、まず公式ドキュメントが英語だけであること、次に、画面のある製品ではなく Python で組み込む部品なので、読み手が開発者に限られることです。導入の判断をする情シスやAI推進の担当が、自分たちに関係のある話として読む入り口がまだ少ないのです。

もう一つは、版の番号がまだ 1.0 に届いていないことです。リリースノートを読むと、直近の版でも互換を壊す変更が入っています。たとえば v0.22.0 では、それまで必須だった LangChain を任意の部品に移し、v0.24.0 でも一部の書き方が取り除かれました。動きの速い部品であることは、導入の判断で必ず押さえておきたい点です。

市販の製品なら、提供元が互換や移行の案内を出してくれることが多いでしょう。オープンソースの部品では、版を上げたときに何が変わるかをリリースノートで読み、自社のアプリへの影響を確かめるのは使う側の仕事になります。英語のリリースノートを定期的に読める人が社内にいるかどうかも、導入の前に確かめておきたい条件です。

なお、NVIDIA は同じ部品をコンテナで動かす形でも提供しています。公式ドキュメントによれば、部品として自分の Python の環境で動かす形と、コンテナとしてまとめて動かす形があり、設定は両者の間で持ち運べます。どちらの形でも、守りの中身を決める仕事は導入する会社に残ります。

指示文で「答えるな」と書くだけでは当てにならない理由

社内AIの守りとして最初に思いつくのは、システムの指示文に「この話題には答えない」「社外の情報は出さない」と書く方法です。手軽で、多くのアプリがまずこの形で動いています。

ただ、指示文はモデルへのお願いです。モデルは指示文を読んだうえで応答を作りますが、会話が長くなったときや、質問の言い回しが想定と違うとき、指示文の優先度が下がって範囲の外に答えてしまうことがあります。守れているかどうかを、指示文の側からは確かめられないのが一番の問題です。

外付けの部品は、モデルとは別の場所で入力と出力を確かめます。条件に合わなければ、モデルに渡す前に止めたり、応答を利用者に返す前に差し替えたりします。守りの判定がモデルの外にあるので、止めた記録も残せます。何件止めたか、何を止めたかが残ることが、あとで見直すための材料になります。

指示文に入れてよい情報と入れてはいけない情報の線は「システムプロンプトは漏れる前提で書く」の記事で扱っています。外部の文書に紛れた指示にAIが乗っ取られる問題への備えは「AIが外部の指示に乗っ取られる原因と対策」の記事に譲り、ここでは社内AIの守りを足すかどうかに絞ります。

止められる守りの種類

公式ドキュメントでは、組み込みで使える守りとして、大きく4つの種類を挙げています。1つ目は内容の安全で、入力や応答が有害でないかを確かめます。判定には、モデル自身に確かめさせる方法、NVIDIA が公開する安全判定用のモデル、他社の判定のサービスなどを使えます。

2つ目は、モデルの決まりを外させようとする入力の検知です。3つ目は話題の制御で、アプリが扱う話題の範囲を決め、範囲の外の質問には答えないようにします。4つ目は個人情報の検知で、入力や応答に含まれる個人情報を見つけて、止めるか伏せ字にします。

判定用のモデルについては、公式ドキュメントで、Llama 3.1 をもとに作られた内容の安全の判定モデルをはじめ、話題の制御と、決まりを外させる入力の検知のためのモデルが紹介されています。部品の本体は無料でも、判定に使うモデルをどこで動かすかで、データの行き先と費用が変わります。この点はあとの節で詳しく扱います。

個人情報の検知についても、公式ドキュメントは、部品が単独ですべてを見つけるのではなく、外部の個人情報の検出の道具と組み合わせる形を案内しています。どの検出の道具を使うかで、日本語の氏名や住所をどこまで拾えるかは変わります。日本語の文書を扱うアプリでは、試作の段階で自社の文書に近い例を流し、拾えたものと拾えなかったものを数えてから採用を決めます。

工程1　守りの種類は、社内AIで困ることから逆算する

ここからは、部品を入れたあとに崩れないための運用を、工程の順に見ていきます。最初の工程は、どの守りを使うかを決めることです。4つの種類を全部入れたくなりますが、まずは社内AIで実際に困っていること、困りそうなことから逆算します。

たとえば、社内規程に答えるAIなら、困るのは規程と関係のない話題に答えることや、人事の個別の事情に踏み込むことです。顧客の資料を検索して答えるAIなら、困るのは見てよい人の範囲を超えた個人情報が応答に出ることです。困ることが違えば、必要な守りも違います。アプリごとに、困ることを3つ程度書き出してから、対応する守りを選びます。

困ることを書き出すときは、起きたときの影響の大きさも一緒に書いておきます。社員が少し戸惑う程度で済むのか、個人情報が見てはいけない人に届くのか、社外に誤った情報が出るのかで、守りに使ってよい費用と遅れの幅が変わるからです。影響の大きい困りごとから順に守りを当てると、限られた予算でも効く守りから足せます。

このとき、決めたことを文書に残します。アプリの名前、想定する利用者、扱う話題、扱わない話題、困ることと対応する守り、です。この文書が、あとで止めすぎや止め漏れを見直すときの基準になります。顧客向けのAIで答えさせない項目は「顧客向けAIに答えさせない項目一覧」の記事に整理しているので、社外に出すアプリではそちらも参照してください。

工程2　部品で足す守りと、足さない守りを分ける

次の工程は、選んだ守りを、部品で足すもの、指示文で持つもの、運用で持つものに分けることです。全部を部品で足すと、応答のたびに判定が増えて遅くなり、費用も増えます。逆に全部を指示文に任せると、守れているかを確かめられません。

守り	部品で足すか	考え方
扱わない話題の拒否	足す	範囲の外に答えると困るアプリでは、モデルの外で確かめて記録を残す
不適切な内容の遮断	足す	社員が使う窓口でも、出てはいけない内容は外側で止める
個人情報の検知と伏せ字	扱う文書による	個人情報を含む文書を検索するアプリでは足す。公開資料だけなら指示文と文書の選び方で持つ
口調や答え方の型	足さない	指示文で持つ。外れても実害が小さい
答えの正しさの最終確認	足さない	部品の確認は補助にとどめ、重要な回答は人が確かめる運用で持つ
外部の道具の呼び出し	道具による	書き込みや送信をする道具では足す。読むだけの道具は権限の設計で持つ

表のうち、答えの正しさを部品に任せないのは、事実の確認を自動で完全にはできないからです。部品の確認で拾える誤りもありますが、重要な回答の正しさを最後に請け負うのは人です。社内の規程や手続きを答えるAIなら、根拠の文書を示させ、利用者が原文に当たれるようにしておくのが現実的です。

この分け方は、アプリごとに違って構いません。同じ部品を全社のアプリで使う場合でも、どの守りを有効にするかはアプリの持ち主と一緒に決めます。守りを層として設計する考え方そのものは「AIのガードレールは禁止事項の一覧ではない」の記事で扱っています。

扱う話題の範囲は、誰が書くか

話題の制御は、社内AIで最もよく使われる守りの一つです。ここで迷うのが、扱う話題と扱わない話題を誰が書くかです。開発の担当が書くと、技術的には正しくても、業務の実態と合わない範囲になりがちです。

おすすめは、アプリの業務の持ち主、たとえば人事の規程を答えるAIなら人事の担当者が範囲の案を書き、開発の担当がそれを部品の設定に落とす分担です。範囲の中身は業務の持ち主、設定への落とし込みは開発、と持ち場を分けておくと、範囲を変えたいときに誰に頼めばよいかが明確になります。

範囲を書くときは、扱わない話題を並べるより、扱う話題をはっきり書くほうが管理しやすくなります。扱わない話題は無数にあり、書き切れないからです。扱う話題の外の質問には、決まった案内を返し、適切な窓口を示すようにしておくと、利用者が行き止まりになりません。

範囲は一度決めたら終わりではありません。規程の改定や組織の変更があれば、扱う話題も変わります。社内の問い合わせをAIで受ける段取りそのものは「社内の問い合わせをAIで受ける5工程」の記事で扱っているので、ここでは範囲を書く人と直す人を決めておく点だけを押さえます。業務の持ち主が範囲の見直しを申し出られる窓口を、開発の側に用意しておくと、変更が滞りません。

工程3　誤って止めた件を記録し、見直す

部品を入れると、必ず二種類の誤りが出ます。止めるべきでない質問を止めてしまう「止めすぎ」と、止めるべき質問や応答が通ってしまう「止め漏れ」です。どちらも、記録がなければ気づけません。

止めすぎは、利用者の不満として表に出やすい誤りです。ただし、不満の声だけで判定をゆるめると、止め漏れが増えます。止めた件の記録と、利用者からの申し出を突き合わせて、本当に止めすぎだったかを確かめてから設定を変えます。

止め漏れは、表に出にくい誤りです。問題のある応答が出ても、利用者が報告しなければ誰も知りません。そこで、応答の記録から一定の件数を抜き出し、人が読んで確かめる時間を定期的に取ります。全件を読むことはできないので、話題や部署で偏らないように抜き出すのがこつです。

利用者から申し出を受ける窓口も用意します。応答の画面に、おかしな答えや不当に止められた質問を報告できる入り口を置いておくと、止めすぎと止め漏れの両方の材料が集まります。申し出には、誰がいつまでに返事をするかも決めておくと、利用者が報告をやめてしまうのを防げます。

• 止めすぎの苦情が来るたびに、記録を見ずに判定をゆるめる
• 止めた件の記録を取っているが、誰も読まずに保存期間が過ぎる
• 設定を変えた日と理由を残さず、前後で何が変わったか分からなくなる

見直しの場で見る数字と、決める人

見直しは、月に一度など周期を決めて行います。見る数字は、止めた件数とその内訳、利用者からの申し出の件数、抜き出して読んだ応答のうち問題のあった件数、そして応答にかかった時間です。数字は傾向を見るためのもので、件数が多いか少ないかだけで良し悪しは決まりません。

見直しの場には、アプリの業務の持ち主、開発の担当、情シスかAI推進の担当が入ります。設定を変える判断は、業務の持ち主と情シスが一緒に決め、開発は変更を実装して記録する、と分担を決めておくと、判断と実装が混ざりません。

見直しの結果、設定を変えたときは、変えた日と理由と、変える前に止めていた件の例を残します。次の見直しで、変更の前と後の数字を比べるためです。変更の記録が積み重なると、どの守りがどの困りごとに効いているかが見えるようになり、守りを足すか外すかの判断が早くなります。

このとき、AIに記録の要約や傾向の下書きをさせるのは構いません。ただし、要約だけを見て判断せず、止めた件の実物をいくつか読んでから決めます。何を止めるかの方針を、AIの要約に決めさせないことが大切です。

止めた件の記録には、利用者が入力した質問の中身が残ります。記録を読める人を見直しの担当に限り、保存の期間を決めておかないと、守りのための記録が別の用途に使われかねません。記録を誰が読み、何日で消すかは、アプリの利用者に向けた説明にも書いておきます。

工程4　応答の遅れと費用の増え方

守りを足すと、応答が遅くなります。公式ドキュメントによれば、入力や応答をモデル自身に確かめさせる守りは、モデルを使った検証です。つまり、守りを一つ足すごとに、応答のたびのモデルの呼び出しが増えることになります。入力の守りと出力の守りを両方足せば、利用者の質問1回につき、本来の応答に加えて複数回の判定が走ります。

遅れを抑える方法として、公式ドキュメントは入力と出力の守りを並列で動かす設定を案内しています。外部のモデルや判定のサービスを呼ぶ守りが複数ある場合に向いていますが、入力を書き換える守りでは、処理の順番の食い違いで結果が変わることがあるため、順番どおりに動かすほうがよいとされています。v0.21.0 では、判定用のモデルの守りを並列で動かす仕組みも加わっています。

費用は、判定にどのモデルを使うかで増え方が変わります。本来の応答と同じ大きなモデルで判定すれば、呼び出しの回数に比例して費用が増えます。判定専用の小さなモデルを自社の環境で動かせば、呼び出しごとの費用は抑えられますが、そのモデルを動かす計算の環境を用意する必要があります。利用者が増えたとき、守りを足したときに、費用がどう増えるかを試算してから本番に入れます。

遅れの許容範囲も、利用者の側から決めておきます。社内の問い合わせのように数秒待てる用途と、会話の途中で即答が求められる用途では、足せる守りの数が違います。試作の段階で、守りを足す前と後の応答の時間を測り、利用者が待てる範囲に収まるかを確かめてから本番の設定を決めると、あとで守りを外す判断に追い込まれずに済みます。

判定用のモデルをどこで動かすか

守りの判定にモデルを使う以上、利用者の入力や応答の中身は、判定のモデルにも渡ります。判定のモデルを自社の環境で動かすのか、外部のサービスを呼ぶのかで、データの行き先が変わります。社内の文書や個人情報を扱うアプリでは、判定の側に送る中身の行き先も、本来のモデルと同じ基準で確かめる必要があります。

公式GitHubには、NVIDIA が評価用に用意しているモデルの呼び出し先について、本番の環境では使わず、評価と試験だけに使うよう明記されています。試作のときに使った呼び出し先を、そのまま本番に持ち込まないよう注意が要ります。

他社の判定のサービスを使う場合は、そのサービスの規約で、送った内容が保存されるか、学習に使われるかを確かめます。どこで判定するかを決めるのは、データの扱いを所管する情シスや法務の仕事です。開発の担当が試作の都合で選んだ呼び出し先が、そのまま残っていないかを、本番の前に一度確かめてください。

工程5　更新と所管を決める

NeMo Guardrails は1〜2か月ごとに新しい版が出ており、互換を壊す変更も含まれています。版を上げないまま使い続けると、不具合の修正や新しい守りを取り込めません。逆に、確かめずに版を上げると、昨日まで動いていた守りが動かなくなることがあります。

そこで、部品の版の管理を誰が持つかを決めます。開発の担当が版を上げる前に、試験の環境で守りが同じように働くかを確かめ、変更の内容を見直しの場に報告する、という流れが一つの形です。部品の更新の担当と、守りの中身の担当を分けて決めることで、どちらかが空く事態を防げます。

守りを書く記法の選び方も、所管の話に関わります。Colang には 1.0 と 2.0 があり、2026年10月時点では 1.0 が既定です。どちらで書いたかによって、版を上げたときに直す範囲が変わることがあります。どの記法で書いたかを台帳に残し、書き手が替わっても読み解けるようにしておきます。

所管が決まっていない部品は、作った担当が異動した時点で誰も触れなくなります。守りの設定は、扱う話題や社内の規程が変わるたびに直す必要があるものです。アプリの台帳に、守りの中身の持ち主と、部品の更新の担当を一行ずつ書いておくことをおすすめします。

この部品が担わないこと

NeMo Guardrails は、自社で作った生成AIアプリの入力と出力の間に置く部品です。社員が社外の生成AIのサービスに直接入力する場面は、この部品の外にあります。社員の持ち出しを入力の手前で止める話は、同じ便の Harmonic Security の記事で扱っています。

また、守りを足しても、AIの応答の責任がなくなるわけではありません。止め漏れはゼロにはならず、守りは事故を減らす仕組みであって、事故が起きないことの保証ではないと、利用者と経営に説明しておく必要があります。重要な判断に使う応答は人が確かめる、という運用の線は、部品を入れても残ります。

アプリが外部の道具を呼んで、書き込みや送信をする場合も同じです。部品の実行の守りで呼び出しの入出力を確かめることはできますが、そもそもどの道具をどの権限で呼ばせるかは、アプリの設計と権限の管理で決めることです。取り消せない操作の前に人の承認を挟む線は、部品とは別に引いておきます。

さらに、部品を足さなくてよいアプリもあります。公開済みの資料だけを答える小さなアプリで、利用者も限られているなら、指示文と文書の選び方、利用者への注意書きで足りることもあります。守りを足すかどうかは、困ることの大きさと、遅れや費用とのつり合いで決めます。

試作から本番に移す前に確かめること

部品を試作に組み込むのは、開発の担当なら難しくありません。問題が出やすいのは、試作のまま本番に移るときです。試作では守りが動いていることを確かめれば十分でも、本番では、止めた記録の置き場、判定のモデルの行き先、版の管理の担当まで決まっている必要があります。

• アプリごとに、困ることと対応する守りを書いた文書があるか
• 扱う話題の範囲を、業務の持ち主が確認したか
• 判定のモデルを動かす場所と、入力が渡る先を情シスと法務が確かめたか
• 評価用の呼び出し先が、本番の設定に残っていないか
• 止めた件の記録の保存場所と期間、読む担当が決まっているか
• 守りを足す前と後で、応答の時間と費用を測ったか
• 部品の版を上げる担当と、試験の手順が決まっているか

7項目のうち空いている項目があれば、本番に移す前に埋めます。とくに判定のモデルの行き先は、試作の担当だけで決めてしまいやすい項目です。社内の文書や個人情報を扱うアプリでは、この1項目のために本番を遅らせる価値があります。

導入の段取り

最後に、社内AIに NeMo Guardrails を足すときの段取りを、5つの工程にまとめます。それぞれの工程で、部品に任せることと人が決めることを分けておきます。

この順番で進めると、部品を入れる前に、何のために守りを足すのかが言葉になります。守りの判定は部品に任せ、何を止めるかの方針と見直しは人が持つ。この線を最初に引いておくことが、守りを形だけで終わらせない一番の近道です。

まとめ

NeMo Guardrails は、NVIDIA が公開するオープンソースの部品で、社内の生成AIアプリの入力と出力の間に置き、扱わない話題の拒否、不適切な内容の遮断、個人情報の検知などの守りを外付けで足せます。2026年10月時点で最新は v0.24.1、ライセンスは Apache 2.0 で、更新は速く、互換を壊す変更も続いています。指示文だけの守りと違い、モデルの外で判定して記録を残せる点が強みですが、守りを足すほど応答は遅くなり、判定のモデルの分だけ費用とデータの行き先が増えます。守りの判定は部品に任せても、何を止めるか、止めすぎと止め漏れをどう見直すか、部品を誰が更新するかは人が決めることです。まずは自社のAIアプリで困ることを3つ書き出し、どれを部品で守るべきかを考えるところから始めてみてください。

• 部品の機能・版・ライセンスは、NeMo Guardrails の公式GitHub、リリースノート、公式ドキュメントを2026年10月15日に確かめた範囲に基づきます。版は頻繁に更新されるため、導入前に最新の原文を確かめてください
• 守りを足しても止め漏れはゼロになりません。社外に出すアプリや重要な判断に使うアプリでは、人が応答を確かめる運用を残してください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。