AIに送る個人情報を伏せて応答で元に戻す中継OSS「guardrails-llm-filter」とは

「社員が生成AIに顧客のメールアドレスや契約番号を貼り付けていないか心配だ」「開発者がうっかり鍵の値を含んだまま、外部のモデルに問い合わせを送ってしまうのではないか」——生成AIを業務の仕組みに組み込もうとしている情報システム部門で、よく交わされる会話です。対策として最初に思い浮かぶのは、送ってはいけない情報の一覧を作って社員に周知することでしょう。しかし本当に問うべきなのは、人の注意だけに頼らず、外に出る直前の通信で機械的に伏せる仕組みを持てるかという点です。この記事では、ロシアのクラウド事業者Cloud.ruが公開したOSS「guardrails-llm-filter」を取り上げ、何を伏せて何を伏せられないのか、障害時にどう動くのか、企業が導入前に決めておくべき点を整理します。導入や設定の手順は扱いません。

guardrails-llm-filterとは何か。2026年10月時点で確かめられる事実

guardrails-llm-filterは、GitHubで公開されているOSSです。リポジトリの説明は「利用者とモデルの提供元の間に置く、透過的な中継役。モデルへの問い合わせから機微な情報を取り除き、応答の中で元に戻す」というものです。READMEの冒頭には、個人情報と秘密の値をモデルの提供元に渡してはならないという一文が掲げられ、「モデルには仮の記号が見え、利用者には元の値が見える」と説明されています。READMEと文書はロシア語で書かれています。

公開元を確かめます。リポジトリは、ロシアのクラウド事業者であるCloud.ruの開発用の組織アカウントにあり、2026年7月13日に作られました。組織のアカウントは2023年9月に作られ、公開しているリポジトリは18件、アカウントの紹介欄には同社の公式サイトが載っています。ライセンスはApache 2.0です。このラインの精査を行った2026年10月19日時点で、スターは204、派生は34、最後の更新は9月7日でした。1日あたりのスターの伸びは約2.1件で、企業の組織が出したものが、ゆるやかに注目を集めている形と読めます。

版の状況も見ておきます。リリースの一覧では、7月13日の最初の公開から、7月14日、7月15日と続き、確認した時点の最新は7月26日の依存部品の更新でした。READMEの表示では版は0.1.2で、まだ初期の段階にある道具です。同じ仕組みを、通信の中継基盤であるEnvoyの拡張として包んだ姉妹版のリポジトリも、同じ組織から公開されています。

なぜクラウド事業者が社内の守りを公開したのか

ロシアの業界紙ComNewsは2026年7月20日、Cloud.ruがこの道具の元となるソースコードを公開したと報じました。記事によると、この道具は同社の生成AI基盤の一部として作られ、同社が提供する基盤モデルの利用サービスへの問い合わせを守るために、すでに社内や顧客向けの案件で使われているとされます。公開版は同社の基盤に縛られず、ほかの提供元のモデルにも使えると紹介されています。

同じ記事では、同社の経営者が「安全性への要求は、生成AIの導入を阻む大きな壁の一つであり続けている」と述べたと伝えられています。つまり、生成AIを使いたいが、社外のモデルに機微な情報を渡せないという悩みに応えるための道具という位置づけです。これは日本の企業にもそのまま当てはまる悩みでしょう。

READMEの比較の節は、この分野の多くの道具が「一度消したら戻さない」一方向の黒塗りであるか、アプリケーションの中に組み込む必要があると指摘しています。そのうえで、自らの役割を接続先を差し替えるだけで使える、行きと帰りの両方向の置き換えと説明しています。これは公開元自身による位置づけで、外部の第三者が確かめた評価ではない点に注意してください。

仕組み：利用者とモデルの間に立つ中継役

READMEによると、利用者の仕組みはモデルの提供元に直接つなぐ代わりに、この中継役につなぎます。中継役は問い合わせを受け取ると中身を調べ、見つけた機微な値を「メールの1番目」といった仮の記号に置き換えてから、提供元へ送ります。提供元から応答が返ってくると、仮の記号を元の値に戻してから利用者に返します。READMEは、モデルは機微な値を見ることがなく、利用者は仮の記号を見ることがないとまとめています。

対応している問い合わせの形式は、OpenAIの会話形式と応答形式、Anthropicのメッセージ形式です。どれも、答えを一度に返す形と、少しずつ流して返す形の両方に対応しているとされます。さらに、モデルが外部の道具を呼び出すときに渡す引数の中でも、元の値に戻すとしています。それ以外の宛先への通信は、手を加えずにそのまま中継されることも明記されています。

置き換えの対応表は、問い合わせが処理されている間だけ、中継役のメモリーの中に置かれます。問い合わせと応答を同じ処理の中で扱うため、通常は別の保存先が要らないという設計です。変更履歴によると、最初の版は通信の中継基盤の拡張として動く形でしたが、その後、単独で動く中継役に作り替えられ、元の形は姉妹版のリポジトリに移されています。見つけた値の扱いは置き換えだけで、問い合わせそのものを止めることはないとREADMEに書かれています。

何を見つけて隠すのか：約265の規則と検査の数字

READMEによると、組み込みの規則は約265件あり、大きく五つの種類に分かれます。ログインの情報、外部サービスの鍵、利用の許可を示す一時的な証明、IPアドレス、個人情報です。個人情報には、ロシアの個人番号や納税者番号、企業の登録番号、カード番号、国際銀行口座番号が含まれ、番号の末尾の検算まで確かめるとされています。秘密の値の型の一部は、鍵の漏れを探すOSSであるgitleaksの一覧をもとにしていると、権利表記の文書に書かれています。

見つけ方は、決まった文字の並びの型に当てはめる方式と検算の組み合わせです。READMEは、AIによる推定も外部への問い合わせも使わないため、処理にかかる時間はごくわずかだと説明しています。利用者が独自の規則を足すこともでき、管理の窓口から登録すると、再起動せずにすぐ効くとされています。独自の規則は既定で500件までです。

公開元は、公開の評価用データで測った結果も載せています。1,810件、13種類の個人情報を含むデータで、精度は99.9、再現率は87.2、両者をまとめたF1という指標は93.1でした。精度が高いということは、隠したものの大半が本当に隠すべき値だったという意味です。一方で再現率87.2は、隠すべき値のうち1割余りを拾えなかったことを示します。これは公開元自身の測定で、日本語の文章や日本の番号で測ったものではない点も押さえておきます。

応答で元に戻す仕組みと、流れてくる応答への対応

この道具が他と違うと公開元が強調するのは、帰り道の処理です。モデルの答えに含まれる仮の記号を、元の値に戻してから利用者に返します。たとえば顧客への返信の下書きをモデルに頼んだ場合、モデルは仮の記号のまま文章を作り、利用者の手元には本物のメールアドレスが入った文章が届く、という形です。利用者の側から見ると、伏せていることを意識せずに、普段どおりの答えを受け取れることになります。

答えを少しずつ流して返す形式では、仮の記号が途中で切れて届くことがあります。READMEによると、この道具は流れてくる断片を順に読み、仮の記号を一つずつ元に戻して返すとしています。変更履歴には、この部分の不具合の修正が多く並んでいます。応答の形式によって、途中の断片を早く出しすぎる問題や、道具の呼び出しの引数が正しい形式でなくなる問題などが直されたと記されています。両方向の置き換えは、作りとして手間のかかる部分だと読み取れます。

元に戻す処理が失敗した場合は、運用の文書によると、仮の記号が利用者にそのまま見える形になります。情報は漏れませんが、利用者には意味の通らない答えが届きます。また、複数の台数で動かす場合には、対応表を外部の保存先に一時的に置く仕組みがあり、その保存期間は既定で15分です。保存期間は、最も長く流れ続ける応答より長くしておく必要があるとREADMEは注意しています。

止めずに通すという設計：障害時は伏せずに送られる

この道具を評価するうえで最も重要なのが、障害時の動きです。READMEと文書は、設計の約束として二つを挙げています。一つは、判定は「置き換える」か「通す」かだけで、問い合わせを止めないこと。もう一つは、内部で異常が起きたときは、通信を壊すのではなく通す側に倒すことです。英語ではこれをフェイルオープン（障害時は開いたままにする方式）と呼びます。

運用の文書には、具体的な場面が並んでいます。問い合わせの中身の形式を読み取れなかった場合、置き換えの処理で異常が起きた場合、見張る対象に入っていない宛先への通信の場合、いずれも伏せないまま提供元へ送られるとされています。それぞれの件数は数として記録され、置き換えの失敗には最も重い段階の警報が用意されています。

この設計は、生成AIを使う業務を止めないことを優先した選択です。一方で、情報を出さないことを優先したい企業にとっては、道具が止まった瞬間に守りが外れることを意味します。どちらが正しいという話ではなく、自社がどちらを優先するのかを決め、警報が出たときに誰がどう動くかを決めておく必要があります。設定を誤って対象の宛先と形式の組み合わせを間違えた場合も、素通りの件数が増え続けるとされています。

試しに見るだけのモード・管理画面・記録

いきなり置き換えを始めるのではなく、試しに見るだけの使い方も用意されています。READMEによると、この状態では通信には手を加えず、もし置き換えていたら何が対象になったかを、数と記録として残します。管理の窓口から切り替えれば、入れ直さずに、本番の置き換えへ移れるとされています。報道では、この試しの使い方が導入前の確認に使えると紹介されています。

管理画面はプログラム本体に組み込まれていて、管理用の窓口で表示されます。概要、規則の一覧、文章を試しに流してみる画面、設定、記録の一覧、監視の画面があると説明されています。READMEは、管理画面は既定で有効であり、社内の閉じた環境の中だけで動かし、外部に公開してはならないと注意しています。動作の数は、監視の仕組みであるPrometheusとGrafanaに渡せます。

記録の機能は既定では無効です。有効にすると、置き換えた問い合わせごとに、当てはまった規則と種類、仮の記号が記録されます。保存期間は既定で24時間です。置き換えたあとの問い合わせや応答の文章を残す設定もあり、READMEはこれが利用者の書いた内容そのものであると注意しています。さらに、仮の記号の裏にある元の値まで残す設定もあり、その場合は見られる人を絞るよう明記されています。

似た手段と何が違うのか

生成AIに渡す情報を制御する方法は、ほかにもあります。READMEの比較の節は、2026年7月時点の各製品の公式資料をもとに比べたとしています。下の表はその内容と、この記事で確かめた事実をまとめたものです。他の製品についての記述は公開元の見方であり、優劣ではなく役割の違いとして読んでください。

見る点	guardrails-llm-filter	文脈で読み取る抽出（Presidio）	会話の制御（NeMo Guardrails）	汎用のAI中継基盤（LiteLLM、Portkey など）
主な目的	機微な値の置き換えと復元	自由な文章の中の個人情報の発見	会話の流れの制御や不正な指示への対抗	接続先の振り分け、鍵や予算の管理
見つけ方	決まった型と検算	文脈を読む推定を使える	伏せることが主目的ではないとされる	製品により異なる
応答で元に戻す	対応	利用者の組み込みしだい	主目的ではない	一部の製品は戻さない作りとされる
組み込み方	接続先の差し替え	アプリケーションに組み込む	アプリケーションに組み込む	中継基盤として置く
向いている場面	鍵や番号の機械的な伏せ字	氏名など文脈で決まる情報	対話の制御	複数のモデルをまとめて管理

READMEは、自由な文章の中の固有名詞を文脈で読み取りたい場合はPresidioを、複数のモデルをまとめて扱う中継基盤が欲しい場合はLiteLLMやPortkeyを、不正な指示への対抗にはNeMo Guardrailsを勧めています。公開元自身が、この道具は伏せ字に特化していて、すべてを担うものではないと認めている形です。氏名や社内の事情を書いた文章は、決まった型に当てはまらない限り伏せられないと考えられ、目的に応じて重ねて使うことが前提になります。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。guardrails-llm-filterの判定は「注意付き」です。解説記事として取り上げますが、導入を考えるなら先に知っておくべき点があるという判定です。

まず、問題が見つからなかった点です。運営はCloud.ruの開発用の組織アカウントで、2023年に作られ、紹介欄に同社の公式サイトが載っています。業界紙も同社による公開を報じています。ライセンスはApache 2.0で、商用も含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下には部品を組み立てるための定義の文書がありますが、利用者が自分で実行するもので、取り込んだだけで自動的に動く処理ではありません。スターの伸びも1日あたり約2.1件で、不自然な水増しの兆候は見られませんでした。

それでも注意付きとした根拠は三つあります。一つ目は、規則や設定を変える管理の窓口に認証がないと、セキュリティ方針の文書に明記されていることです。二つ目は、内部で異常が起きたときに、伏せずに提供元へ送る設計であることです。三つ目は、セキュリティ方針の文書に報告の窓口と受領までの目安（5営業日以内）は書かれている一方で、どの版を修正の対象とするかが書かれていないことです。どれも公開元自身の資料から確かめられる事実で、このラインの基準の「迷ったら注意付きに寄せる」に従いました。

なお、勧告がないことは安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。この道具は機微な値と外部サービスの鍵が通る場所に置くものなので、評価は導入する側でも重ねる必要があります。三つの注意点の中身は、次の節で詳しく見ます。

導入前に知っておきたい注意点

第一に、管理の窓口に認証がない点です。セキュリティ方針と運用の文書は、規則や設定を変える窓口、管理画面、記録の一覧に認証も対象ごとの権限の確認もないと明記し、社内の閉じた環境に置き、外部に公開しないよう求めています。変更履歴では、最初の版の管理の窓口には任意の認証の仕組みがあったと記されており、現在の資料との違いは導入前に確かめたい点です。

第二に、要求ごとに伏せる範囲を変える指定です。文書によると、要求に付ける特定の付随情報で、その要求だけ伏せる範囲を狭められます。広げることはできませんが、伏せないという指定もできます。このため運用の文書は、信頼できない利用者が直接届く場合は、前段の中継基盤でこの付随情報を取り除くよう求めています。取り除かなければ、利用者が自分の要求の伏せ字を外せることになります。

第三に、元の値の置き場所です。複数の台数で動かす場合、対応表は外部の保存先（RedisやPostgres）に一時的に置かれ、元の値がメモリーの外に出ます。暗号化の設定は任意です。記録に元の値を残す設定も同じ注意が要ります。第四に、規則の多くはロシアの番号を前提にしていて、日本のマイナンバーや電話番号に向けた規則の記載は、確認した範囲では見当たりませんでした。日本で使うなら独自の規則を足す前提で考える必要があります。

第五に、運営と資料の面です。READMEと文書はロシア語で、日本語で仕組みや注意点を整理した資料は確認した範囲では見つけられませんでした。変更履歴は0.1.0のあとの変更を未リリースとしてまとめており、リリースの一覧の版との対応が分かりにくい状態です。公開元がロシアの事業者であることを踏まえ、自社の調達の規程や取引先の確認の手続きに照らして判断する企業もあるでしょう。

悪用されうるリスク

guardrails-llm-filterは守りのための道具で、攻撃のための道具ではありません。それでも、置き方しだいで生まれうる危険はあります。最も大きいのは、「伏せ字の中継役を入れたから、何を送っても大丈夫」という安心が独り歩きすることです。決まった型に当てはまらない情報や、取りこぼした1割余りの値、障害時に素通りした通信は、そのまま提供元に届きます。

次に挙げるのは推測ですが、検討の材料になります。管理の窓口には認証がないため、社内の環境に入り込んだ者がいれば、規則を無効にしたり、試しに見るだけの状態に切り替えたりして、利用者に気づかれないまま伏せ字を外せる可能性があります。記録に元の値を残す設定にしていれば、記録の一覧そのものが機微な情報の集まりになります。

また、この中継役は外部サービスの鍵や利用者の問い合わせがすべて通る場所です。運用の文書は、詳しい動作記録の段階では要求の付随情報を書き出すため本番で使わないこと、提供元との接続で証明書の確認を省く設定は試験用に限ることを求めています。これらの注意を守らなければ、守りのための設備が、情報の集まる弱点になる筋書きは考えられます。なお、この道具が実際に悪用された事例は、2026年10月19日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、道具を入れることと、道具が見落とす範囲を決めることを同時に進めることです。伏せ字の中継役は守りの一枚であって、送ってはいけない情報の定義や、社員への周知に代わるものではありません。

企業が取るべき対策

一つ目は、生成AIへの通信の出口を一本にまとめることです。guardrails-llm-filterを使うかどうかにかかわらず、社内の仕組みがそれぞれ勝手に外部のモデルへつないでいる状態では、どんな見張りも効きません。外部のモデルにつながる道を、見張りのある出口だけに絞ることが、伏せ字の仕組みが意味を持つ前提です。

二つ目は、送ってはいけない情報の定義を言葉で残すことです。中継役の規則は、その定義を機械が読める形に移したものにすぎません。三つ目は、素通りと取りこぼしの監視です。運用の文書は、置き換えの失敗や、伏せた件数が前日の同じ時間帯の3倍に増えたときの警報の例を示しています。警報を受ける担当と、受けたあとの手順を決めておくことが大切です。

四つ目は、中継役そのものの守りです。管理の窓口に届く経路、記録の保存先、外部の保存先の鍵の扱いを決めます。五つ目は、調達のときの確認です。初期の版であること、修正の対象の版が書かれていないこと、資料がロシア語であること、公開元の所在を踏まえ、社内で使える段階かどうかを文書で判断します。

AIに任せる範囲と、人が決める範囲

guardrails-llm-filterは、生成AIを安心して業務に使うための道具です。見つけ方にAIの推定を使わないため、同じ入力には同じ結果が出ます。しかしそれは、型に書かれていないものは見つけないという意味でもあります。だからこそ、AIに判断させない部分を先に決める必要があります。

具体的には、何を送ってはいけない情報とするか、どの規則を足すか、障害時に素通りを許すか、記録に何を残すか。この四つは道具にもAIにも委ねず、人が決めて記録に残します。生成AIに規則の案を作らせる場合も、なぜその型で拾えるのかという根拠を書かせ、試しに見るだけの期間の結果と照らして人が確認します。人が確認する範囲を先に決めておけば、規則が増えても管理が追いつきます。やってはいけない向き合い方を挙げます。

• 中継役を入れたことを理由に、送ってはいけない情報の周知や社内の決まりをやめる
• 障害時は伏せずに送られる設計であることを知らないまま、警報の受け手を決めない
• 管理の窓口と管理画面を、社外や広い社内の網から届く場所に置く
• 要求ごとに伏せる範囲を変える指定を、前段で取り除かずに受け付ける
• 記録に元の値を残す設定を有効にし、見られる人を絞らない
• ロシアの番号向けの組み込み規則だけで、日本の番号も守れていると思い込む

裏を返せば、人が決める範囲ははっきりしています。何を伏せ、何を見落としうると認め、止まったときにどうし、誰が中継役を守るか。この四つが決まっていないまま中継役を置いても、守りの厚みは増えません。

よくある質問：伏せ字の中継役があれば機密を生成AIに送ってよいのか

答えは「それだけでは足りない」です。guardrails-llm-filterが伏せるのは、組み込みの規則と独自の規則に当てはまった値だけです。公開元自身の測定でも、隠すべき値のうち1割余りは拾えていません。自由な文章で書かれた機密や、文脈でしか分からない情報は守備範囲の外と考えるべきです。

では入れる意味がないのかというと、そうではありません。鍵の値やカード番号のように形が決まった情報は、人の注意よりも確実に、しかもごくわずかな時間で伏せられます。応答で元に戻せるため、利用者の使い勝手を落とさずに済む点も、現場に受け入れられやすい理由になります。うっかりの多くは形の決まった値で起きるため、そこを機械に任せられる意味は小さくありません。

もう一つ、「障害時に素通りするなら、かえって危ないのではないか」という問いもありそうです。素通りの件数は数として残り、警報も用意されています。問題は、警報を見る人がいるかどうかです。業務を止めないことと情報を出さないことのどちらを優先するかを先に決め、その判断に合う置き方を選ぶのが妥当でしょう。

• guardrails-llm-filterの機能・版・設計・制限は、GitHubのリポジトリとその中の文書（README、セキュリティ方針、変更履歴、運用の文書）、リリースの一覧、勧告の一覧、業界紙の報道を2026年10月19日に確かめた範囲に基づきます。初期の版のため内容は変わる可能性があります
• 検出の数値は公開元自身の測定です。日本語の文章や日本の番号での精度、管理の窓口の認証の扱いの変遷は、確認した一次情報の範囲では十分に確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

guardrails-llm-filterは、社内の仕組みと生成AIの間に置き、問い合わせの中の個人情報や鍵の値を仮の記号に置き換えて送り、応答では元の値に戻すOSSです。約265の決まった型と検算で値を見つけ、AIの推定は使いません。ロシアのクラウド事業者Cloud.ruが社内で使ってきたものを2026年7月にApache 2.0で公開しており、GitHub上にセキュリティ勧告は登録されていません。

一方で、障害時は伏せずに送る設計であること、管理の窓口に認証がないこと、規則の多くがロシアの番号を前提にしていることは、公開元自身の資料に書かれています。何を伏せるか、何を見落としうるか、止まったときにどうするか、中継役を誰が守るかは、道具ではなく人が決める範囲です。送ってはいけない情報の定義と、見落としへの備えを先に決めたうえで使うことが、生成AIを業務に組み込む時代のguardrails-llm-filterとの付き合い方です。

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