生成AIへの個人情報の流出を手前で止めるOSS「Thyris Safe Zone」とは

「社員が生成AIに顧客の名前や問い合わせ番号をそのまま貼り付けていないか、送る前に止める仕組みが欲しい」「自社のアプリから外部のAIを呼ぶようにしたが、何が外へ出ているのか誰も説明できない」——生成AIを業務に組み込み始めた企業で、情報システムやセキュリティを預かる人たちから相次いで上がる声です。こうした悩みは、社員に注意を促す研修や、利用規程の文面を整えるだけでは片づきません。ありがちな受け止め方は「AIの提供元が安全なら大丈夫」というものですが、本当の論点はそこではありません。本当は、自社の境界を越える前に、送る中身を誰がどの基準で確かめるのかという、送り出す側の設計の問題です。この記事では、その確かめ役を担うソフトウェアとして公開されている Thyris Safe Zone（略称 TSZ）について、何ができるのか、どこまでは守れないのか、そして運営元の実績が乏しいことを含めて導入前に何を確かめるべきかを、公開された一次情報をもとに整理します。導入や操作の手順は扱いません。

Thyris Safe Zoneとは何か。2026年10月時点で確かめられる事実

Thyris Safe Zone は、Thyris.AI という組織が公開しているソフトウェアです（拠点は公式サイトに明記がなく、確認できていません）。公式の説明によると、社内のデータと外部のシステムの間に置く「ゼロトラスト（何も無条件には信用しない）」の層として作られ、個人情報・秘密情報・社外秘のデータが意図せず外へ出ないよう、送る中身をその場で確かめ、伏せ字にし、必要なら送信を止めるとされています。

2026年10月23日時点で、配布元のリポジトリで確かめられる事実は次のとおりです。作成は2025年12月13日、ライセンスは Apache-2.0、スターは30、フォーク（派生）は11、本体の記録の積み重ねは127件で、最後の更新は2026年10月15日でした。リリースは2025年12月の最初の版から始まり、2026年4月に1.0、8月に2.0、9月に2.1が出ています。小さいながらも更新は続いていると言えます。

一方で、公開している組織のアカウントは2024年9月の作成で、公開リポジトリは2件、フォロワーは11にとどまります。採用実績を記録する文書に載っているのは、運営元である Thyris.AI 自身の本番利用1件だけでした。中身は意欲的でも、第三者が使い込んだ実績はまだ見えないというのが、現時点での正直な姿です。この点は後の「安全性の評価」で改めて扱います。

なお、この記事の記述は、リポジトリの説明書き・同梱の文書・リリースの記録・公式サイトを読んだ範囲に基づきます。ソフトウェアを手元で動かして確かめたものではありません。書かれている機能が、実際にその通りに動くかは別の問題として読んでください。

なぜ今、AIに送る前の「関所」が求められるのか

生成AIを業務で使う形は、社員が画面に文章を貼り付ける段階から、自社のアプリが裏側で外部のAIを呼び出す段階へと移りつつあります。後者になると、どの文章が、いつ、どのAIに送られたのかが人の目に入りにくくなります。問い合わせの記録や社内文書をまとめてAIに渡す処理では、担当者が一件ずつ中身を確かめることは現実的ではありません。

そこで考えられるのが、社内と外部のAIをつなぐ通り道に「関所」を置き、通る文章を機械的に確かめるやり方です。氏名、電話番号、カード番号、接続用の鍵といった、形の決まった情報なら、送る前に見つけて伏せ字にできます。TSZ はまさにこの関所を担う部品として作られており、公式の製品概要は、社外のAIや外部のAPIには、伏せ字にした後の内容だけを渡すことを推奨される使い方として挙げています。

背景には規制対応の要請もあります。製品概要は、欧州の一般データ保護規則（GDPR）、カード業界のデータ保護基準、米国の医療情報の規則といった枠組みへの対応を支える設計だと説明しています。ただし、構成と安全性の文書は、正式な認証を受けたことや、規則の各項目との対応づけを主張するものではないと断っています。「入れれば規制に対応できる」という読み方はできない、という点は押さえておくべきです。

仕組み1：個人情報と秘密情報を見つけて伏せ字にする

TSZ の中心にあるのは、送られてくる文章を受け取り、中に含まれる慎重に扱うべき情報を見つける検出の仕組みです。公式の説明では、メールアドレス、電話番号、クレジットカード番号、接続用の鍵などを見つけ、それぞれに確からしさの点数と、なぜそう判断したかの説明を付けるとされています。

見つけた情報は、文脈を保ったまま伏せ字に置き換えられます。たとえばメールアドレスの部分を「メールアドレスがここにあった」と分かる目印に差し替える、という形です。こうすると、AIは文章の意味をつかんだまま処理でき、中身の値そのものは社外へ出ないという状態を作れます。伏せ字にするか、送信ごと止めるかは、確からしさの点数としきい値によって決まると、構成の文書は説明しています。

ここで注意したいのは、検出は「よく見かける形」に強く、「その会社だけの言い回し」には弱いという点です。社内の案件コードや、取引先ごとの呼び名、日本語の住所や氏名の書き方などは、最初から用意された規則で十分に拾えるとは限りません。日本語の文章でどこまで拾えるかは、一次情報では確かめられないため、自社の実データに近い試験用の文章で、見逃しと誤検出の両方を測ることが前提になります。

仕組み2：規則とAIの判定を組み合わせたガードレール

TSZ は、形の決まった情報を見つけるだけでなく、「ガードレール」と呼ぶ判定の仕組みも持っています。公式の説明によれば、判定の方法は大きく三つあります。正規表現（文字の並びの規則）と許可・拒否の一覧による決まった判定、データの形式が決められた型に合っているかの確認、そして生成AIに文章の意味を判断させる判定です。

AIによる判定では、有害な表現、金融や医療についての助言、ブランドを損なう内容、自社で定めた分野の規則などを見るとされています。判定の規則は、個人情報向け、カード業界と欧州の規則向け、AIの安全向けといったひな形の束として用意され、動かしたまま規則を差し替えられる仕組みもあると説明されています。

ここで見落としやすい点があります。意味の判定に生成AIを使うということは、確かめたい文章そのものを、判定役のAIに渡すことになるという点です。判定役に外部のAIを選べば、伏せ字にする前の文章がそちらへ渡る可能性があります。構成の文書では、判定役として外部のAIの窓口のほか、手元で動かすモデルにつなぐ選択肢も挙げられています。どのAIに判定させるかは、関所を置く目的そのものに関わる選択だと考えてください。

また、AIによる判定は確率的で、同じ文章でも結果がぶれることがあります。構成の文書によれば、判定の点数は一定時間（既定で24時間）の一時保存に回されるとされ、同じ問い合わせが続く場面では処理を軽くできる一方、判定の誤りもその間は引き継がれうることになります。

仕組み3：既存のAI呼び出しの手前に置く2つの置き方

TSZ を業務の流れにどう組み込むかについて、公式の文書は大きく二つの置き方を示しています。一つ目は、TSZ 自体がAIの呼び出し口の役を兼ねる形です。公式の説明では、広く使われている呼び出し方と同じ形の窓口を持ち、アプリが外部のAIを呼ぶ代わりに TSZ を呼ぶと、行きと帰りの両方でガードレールを掛けたうえで、背後の外部のAIへ取り次ぐとされています。

取り次ぎ先としては、OpenAI と同じ形の窓口（Azure 上のものや、手元で動かす Ollama を含む）と、Amazon の Bedrock が挙げられています。つまり、アプリ側の作り替えを小さく抑えたまま関所を挟めることが、この置き方の利点として示されています。

二つ目は、すでに使っている通信の中継装置に TSZ を後付けする形です。2026年9月の版で、Envoy Gateway という中継装置に、要求と応答の中身の確認だけを担う役として TSZ を取り付ける方式が加わりました。公式の説明では、通信の振り分け・認証・利用量の制限などは中継装置に残し、TSZ は中身の確認だけを受け持つという分担です。既存の通信の仕組みを大きく動かさずに済むため、すでに中継装置を運用している組織には現実的な選択肢になりえます。

どちらの置き方でも、構成の文書は、本番では「確認の途中で問題が起きたら通さない」設定を既定にし、処理の失敗を安全とみなすことは決してないと説明しています。関所が止まれば業務の通信も止まる、という引き換えがあることは、導入前に関係者で共有しておくべき点です。

記録と運用画面：何が残り、何が残らないか

関所を置く以上、何が止められ、何が通ったのかを後からたどれることが重要です。構成の文書によると、TSZ は設定や検出の規則、許可・拒否の一覧、そして検出の出来事をデータベース（PostgreSQL）に保存し、判定の結果を素早く返すための一時保存に Redis を使います。確認の要求ごとに、要求の番号、検出の件数と内訳、処理にかかった時間を記録し、必要ならログを集めて分析する仕組み（SIEM）へ送れるとされています。

記録の中身については、意図して絞り込む方針が示されています。中継装置に取り付ける方式では、送られた指示の文章、AIの返答、見つけた値、資格情報、判定の出力などを、ログや計測値に書き出さないことが明記されています。関所の記録そのものが個人情報のたまり場になる、という本末転倒を避ける設計と読めます。

一方、閲覧用の運用画面は、説明書きによれば読むだけの初期版で、現時点では開発用の動かし方にしか対応していません。要求の件数や最近の出来事は、裏側の本体を再起動すると消える、記憶上だけの保持と明記されています。監査や事後の調査に使う記録は、運用画面ではなく、別に用意したログの保管先で持つ前提で考える必要があります。

想定される使いどころ

公式の製品概要が挙げる使い方を、企業の場面に置き換えると、いくつかの典型が見えてきます。一つは、問い合わせ対応や社内文書の要約など、自社のアプリが裏側で外部のAIを呼ぶ処理の手前に置く使い方です。顧客の連絡先やカード番号が混じりやすい文章を、伏せ字にしてから外部のAIに渡せます。

二つ目は、社内の文書を検索してAIに答えさせる仕組み（RAG）での使い方です。リリースの記録には、安全な検索連携の作例や、情報の持ち出しを試す演習用の作例が加わったとあります。社内文書の中に紛れ込んだ鍵や個人情報が、AIの回答を通じて外へ出る経路を狭める用途が想定されます。

三つ目は、AIの出力の側を確かめる使い方です。答えの形式が決まった型に合っているかの確認や、有害な表現・専門的な助言の混入を見る判定は、AIの返答を社外の顧客にそのまま見せる業務で役立つ可能性があります。ただし、どの使い方でも、関所は「最後の砦」ではなく「何重かの守りの一枚」と位置づけるのが妥当です。利用規程、権限の絞り込み、送る情報そのものを減らす設計と組み合わせて初めて意味を持ちます。

類似の手段との違いを表で比べる

生成AIへの情報の持ち出しを抑える手段は、TSZ のような自社で動かす関所だけではありません。よく検討される手段と並べると、TSZ の位置づけが見えやすくなります。下の表は一般的な整理で、個別の製品の性能を比べたものではありません。

手段	守れる範囲	主な負担	向く組織
利用規程と研修だけ	社員の意識に左右される	小さいが、守られたかを確かめられない	利用がまだ限られる段階
アプリごとに自前の検出を作り込む	作り込んだ部分だけ	アプリが増えるたびに作り直し	AIを使うアプリが少ない組織
TSZ のような自社で動かす関所	関所を通る文章（守れない形式あり）	運用・更新・規則の調整を自社で担う	運用の体制があり、通り道を一本化できる組織
提供元が運営する有償の関所サービス	契約と製品の対応範囲次第	費用と、確かめる文章を外部に預けること	運用を外に任せたい組織

表から分かるのは、TSZ の強みが「確かめる処理も記録も自社の中に置ける」点にあることです。その代わり、規則の調整、更新への追随、関所が止まったときの対応を自社で引き受けます。この負担を担える体制があるかどうかが、TSZ を選ぶかどうかの分かれ目になります。

商用版はあるのか。オープンコアかどうかの確認

中心部分を無償で公開し、一部の機能を有償にする「オープンコア」の形かどうかも確かめました。2026年10月23日時点で、リポジトリの説明書き、公式の文書サイト、製品概要、今後の計画の文書のいずれにも、有償版の機能の区分や料金の記載は見当たりません。公開されている本体、運用画面、Go と Python 向けの部品、コマンドで操作する道具は、いずれも同じ Apache-2.0 の下に置かれています。

気になる点が二つあります。一つは、同梱の文書のうち詳しい窓口の説明書だけが「エンタープライズ向け」と名付けられていることです。これが将来の有償版を意味するのか、単に企業向けの読み物という意味なのかは、公開情報からは判断できないため、未確認として扱います。もう一つは、運営元の公式サイトが、TSZ のほかに複数の業務向け製品と、個別の開発や本番運用の支援をうたっている点です。製品概要も、企業向けの評価や設計の相談に応じると書いています。

このため現時点の整理としては、TSZ 本体は Apache-2.0 のOSSで、有償の支援は別に相談する形と読むのが妥当です。ただし、運営元の事業の形は今後変わりうるため、導入を検討する時点で、ライセンスと提供の条件をあらためて確かめてください。

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

このラインでは、OSSを入手したり動かしたりせず、公開された事実だけで安全性を判定しています。TSZ の判定は「注意付き」です。根拠にした事実を、良い材料と気になる材料に分けて示します。

良い材料としては、ライセンスがOSI承認の Apache-2.0 であること、2026年10月23日時点で公開されたセキュリティ勧告がないこと、脆弱性の報告窓口と手順を定めた方針の文書があること、そして最終更新が2026年10月15日で保守が続いていることが挙げられます。セキュリティの方針では、公開の場で脆弱性を報告せず、専用の窓口へ連絡するよう求め、修正は最新の版と直近のリリースに対して行うとしています。

気になる材料は、運営体制の実績です。公開している組織は公開リポジトリ2件・フォロワー11、リポジトリのスターも30と小さく、採用実績の記録は運営元自身の1件だけでした。個人情報の流れの真ん中に置く部品としては、第三者による検証の厚みが足りないというのが「注意付き」とした理由です。なお、リポジトリの直下には組み立て用の定義ファイルがありますが、入手しただけで自動的に処理が動く仕組みは確認していません。

念のため付け加えると、ここで問題が見つからなかったことは、安全の保証ではありません。勧告がないのは、利用者が少なく調べられていないだけ、という可能性もあります。判定は公開情報に基づく目安であり、導入する組織が自ら確かめる手順の代わりにはなりません。

注意点の詳細：運営体制・文書の食い違い・ライセンスの経緯

注意点をもう少し掘り下げます。まず、文書どうしの食い違いです。セキュリティ強化の計画をまとめた文書は、TSZ には認証・権限・利用量の制限・通信の暗号化といった運用上の守りが欠けている、と書き、試験用の設定ファイルに既定の認証情報が残っており、今後取り除く予定だとしています。一方、構成と安全性の文書では、認証の仕組みや権限の区分、要求の大きさの制限などがすでにあるように説明されています。

どちらが現在の実態かは、公開情報だけでは断定できません。計画の文書が古いまま残っている可能性もあれば、機能はあっても既定では無効になっている可能性もあります。今後の計画の文書は、中継装置向けの安全強化の版を2026年10月25日に予定していると書いており、まさに今、守りの部分が作り込まれている途中と読めます。導入を検討するなら、その版の内容と、既定の認証情報が本当に取り除かれたかを確かめるべきです。

次に、ライセンスの経緯です。2026年8月のリリースの記録には「ライセンスの変更」とあり、変更の記録を見ると、それまでは Apache-2.0 に独自の採用条件を足した独自のライセンスで、変更後に Apache-2.0 そのものになっていました。現在の条件は利用者にとって分かりやすくなっていますが、以前の版を入手して使っている場合は、旧条件が付いている可能性がある点に注意が必要です。

最後に、配り方です。説明書きでは、Python 向けの部品を公開の配布所ではなく、リポジトリの最新の状態から直接取り込む形で案内しています。これは、版を固定しないと、ある日突然中身が変わったものを取り込みうる、ということです。社内で使うなら、確かめた版を固定し、変更を人が見てから更新する運用が前提になります。

守れる範囲の限界：ストリーミング・画像・ツール呼び出し

TSZ の文書で評価できるのは、守れない範囲を正直に書いている点です。構成と安全性の文書は、中継装置に取り付ける方式について、保証できるのはまとめて受け渡される通信だけで、少しずつ流れてくる応答（ストリーミング）の形式は対象外だとしています。生成AIの返答を逐次表示する画面では、この形式がよく使われます。

ほかにも、画像・音声・ファイルとして送られる中身は確認しないこと、AIエージェントが外部の道具を呼ぶ通信の一部の形式は確認の対象外であることが明記されています。さらに、道具の呼び出しを確かめても、その道具を使ってよいかの許可や、信頼できる接続先かの判断はしないとも書かれています。つまり TSZ は中身の確認役であって、AIエージェントの権限を管理する仕組みではありません。

この限界は、企業の実際の使い方と照らすと重い意味を持ちます。社員が資料のファイルごとAIに渡す、画面の写しを貼る、といった使い方は珍しくありません。文章の関所だけを置いて「AIへの持ち出し対策は済んだ」と考えるのは危ういと言えます。どの通り道が関所を通り、どの通り道が通らないのかを、導入前に図にして洗い出しておく必要があります。

悪用されうるリスクと、ガードレール自体が狙われる可能性

TSZ は守りのための部品で、それ自体が攻撃に使われる種類のものではありません。ただし、守りの部品だからこそ生じるリスクがあります。一つ目は、関所があらゆる機密の文章が集まる場所になることです。伏せ字にする前の文章は、必ず関所を通ります。関所の設定が甘かったり、管理用の窓口が外から触れる状態だったりすれば、狙う側にとって格好の的になる可能性があります。

二つ目は、規則のすり抜けです。決まった形を探す検出は、書き方を少し崩した情報や、分割して送られた情報を見逃すことがあります。AIによる判定も、言い回しを工夫した文章にだまされる余地があると一般に指摘されています。関所があることを前提に、すり抜ける書き方を探す動きは起こりうると考えておくべきです。これは TSZ に限らず、この種の仕組み全般に言える推測です。

三つ目は、規則そのものの書き換えです。TSZ は動かしたまま規則を差し替えられる仕組みを持つとされます。便利な反面、管理用の権限が奪われれば、検出の規則を緩めたり、許可の一覧に特定の値を足したりして、関所を素通りにできてしまうおそれがあります。規則を変えられる人を絞り、変更の記録を残すことが、関所の信頼性を支えます。

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

ここまでの整理を踏まえ、TSZ に限らず、生成AIの手前に関所を置く部品を検討するときの確かめ方を、順を追って示します。いずれも、本番の通信につなぐ前に終えておくべき確認です。

企業が取るべき対策

TSZ を入れるかどうかにかかわらず、生成AIへの情報の持ち出しに備えて企業が取るべき対策を整理します。第一に、AIに送ってよい情報の区分を社内規程で先に決めることです。関所の規則は、この区分を機械に落とし込んだものにすぎません。区分がないまま関所を置いても、何を止めるべきかが決まりません。

第二に、AIへの通り道を一本にまとめることです。部署ごとに別々の経路で外部のAIを呼んでいると、関所を置いても抜け道が残ります。社内のアプリが外部のAIを呼ぶときは、決められた中継を通すことを原則にすると、確認と記録が一か所で済みます。第三に、関所の記録を、ほかのセキュリティの記録と合わせて定期的に見ることです。止められた件数が急に増えた部署や、同じ種類の情報が繰り返し送られている業務は、仕組みより先に業務の流れを見直すべき合図かもしれません。

第四に、調達の段階での確認です。TSZ のように運営元の実績が乏しいOSSを、個人情報の流れの中心に置く場合は、保守が止まったときの引き継ぎ先、脆弱性が見つかったときの連絡の受け方、ライセンスの条件の変化を、導入前に決めておきます。小さな運営元のOSSを使うこと自体が悪いのではなく、止まったときの備えなしに頼り切ることが危ういのです。

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

TSZ の判定には生成AIも使われます。だからこそ、AIに判断させる部分と、人が決める部分の線を引いておく必要があります。AIに任せてよいのは、決められた基準の中で、大量の文章を速く仕分ける作業です。一方、何を機密とみなすか、どこまで止めるか、例外を誰が認めるかは、AIに判断させず人が決める領域です。

AIに判定させる場合も、結果だけでなく、なぜそう判定したのかの根拠を書かせることが大切です。TSZ の検出は、確からしさの点数と判断の説明を返すとされています。この根拠を人が見られる形で残しておけば、誤って止めた件や見逃した件を後から確かめ、規則を直せます。そして、人が確認する範囲を先に決めておきます。たとえば止められた件のうち、例外として通すものは必ず人が承認する、といった形です。

• 関所を置いたことで安心し、ファイルや画像など関所を通らない通り道を放置する
• 意味の判定を外部のAIに任せ、伏せ字にする前の文章をそのまま判定役に渡している
• AIの判定結果を根拠を見ずにうのみにし、止めすぎや見逃しを確かめない
• 規則の変更や例外の許可を、承認や記録なしで誰でもできる状態にしておく
• 運営元の実績を確かめず、版も固定しないまま、最新の状態を本番に取り込み続ける

• Thyris Safe Zone の機能・構成・守れる範囲の限界・ライセンスの経緯・運営元の状況は、配布元のリポジトリ、同梱の文書、リリースの記録、公式サイトを2026年10月23日に確かめた範囲に基づきます。ソフトウェアを動かして確かめたものではありません
• スター数・フォーク数・組織の公開リポジトリ数・フォロワー数は2026年10月23日時点の値で、変わることがあります。2026年10月25日に予定されている安全強化の版の内容は、この記事の時点では確認していません
• 日本語の個人情報をどこまで検出できるかは、一次情報では確かめられませんでした。導入を検討する場合は、自社の試験用の文章で測ってください

まとめ

Thyris Safe Zone は、生成AIや外部のAPIへ送る文章から個人情報や秘密情報を見つけ、伏せ字にしたり送信を止めたりする、Apache-2.0 のOSSです。AIの呼び出し口を兼ねる置き方と、既存の中継装置に後付けする置き方があり、確かめる処理と記録を自社の中に置けることが強みです。現時点で有償版の区分は確認できず、本体は無償で公開されています。

一方で、運営元は公開リポジトリ2件・フォロワー11と実績が乏しく、採用実績も自社のみで、セキュリティ強化の計画の文書と構成の文書には食い違いも見られます。ストリーミングの応答、画像やファイル、AIエージェントの道具の許可など、守れない範囲も文書に明記されています。関所は守りの一枚であって、全部ではありません。

企業がまず決めるべきは、道具の選定より先に、AIに送ってよい情報の区分と、AIへの通り道、そして止める基準と例外を誰が認めるかです。そのうえで TSZ を試すなら、判定役のAIの置き場所、日本語での検出の精度、既定の認証情報の有無、版の固定を確かめてから本番につないでください。AIに判定を任せる部分があっても、基準と例外は人が決める——この線を保つことが、関所を本当に役立てる条件です。

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