生成AIへの送信から個人情報や紛れ込んだ命令を取り除くOSS「Tamga」の仕組みと導入前の注意点

「社内のAIの窓口に、顧客の問い合わせ文をそのまま渡している。氏名や口座番号が外部の生成AIに送られていないか不安だ」「AIエージェントにウェブを読ませ始めたが、ページに仕込まれた命令まで運ばれてしまわないか」——生成AIを自社の仕組みに組み込み始めた企業の、情報システム担当者から聞こえてくる二つの声です。生成AIの提供元を選び直せば済む問題に見えますが、そうではありません。本当は、自社の側で、何を外へ送ってよいかを決めて止める関所を持てているかが問われています。この記事では、その関所を自社のサーバーに置くためのOSS「Tamga」について、一次情報で確かめられる仕組み・見えない範囲・公開されている性能の数字の読み方・導入前に確かめる点を整理します。導入や設定の手順は扱いません。

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

Tamga は、GitHub上で公開されているOSSです。READMEは自らを「自分のサーバーで動かす、生成AIとの通信のための安全柵」と説明しています。社内のアプリ、検索で集めた文書を生成AIに渡す仕組み、AIエージェントが呼び出す生成AIの窓口（API、つまりプログラムから機能を呼び出す入口）の手前に置き、送られる文章を点検してから提供元へ転送します。

公開の時期と規模も確かめておきます。リポジトリが作られたのは2026年6月20日で、最後に更新されたのは10月18日です。2026年10月21日時点で、スターは44、複製（フォーク）は4、スターの伸びは1日あたり0.4前後です。作者は個人のアカウントで、アカウントの作成は2021年10月、公開しているリポジトリは19、フォロワーは20です。著作権表示には個人名があり、運営する会社の名前は確認できませんでした。

版については、READMEの表示は0.9.0ですが、本文では0.9.0はまだ正式に公開されていないと書かれています。公開済みの版（リリース）も、すぐに使える配布用のコンテナの形もまだありません。ライセンスはAGPL-3.0で、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。公式サイトは、有料版はなく、このリポジトリが唯一の版だとしています。

なぜ今、生成AIへ送る手前に関所が求められるのか

READMEは、Tamga が生まれた背景として、生成AIを呼び出すアプリは「渡されたものをそのまま送ってしまう」点を挙げています。問い合わせ対応のAIが顧客の身分証の番号を含む文章を送る。文書を検索して渡す仕組みが、口座番号や接続用の鍵を含む文書を拾ってしまう。どれも誰かが意図して漏らしたのではなく、仕組みが素直に動いた結果として起きます。

READMEは、従来の守りでは防ぎにくい理由も三つ挙げています。社内のネットワークで情報の持ち出しを見張る仕組みは、暗号化された通信の中身までは読めない。外部の事業者が提供する中継サービスで点検すると、点検のために自社の文章をその事業者に渡すことになる。生成AIの提供元の安全機能は、その提供元にしか効かず、自社の手元に記録が残らない、というものです。

もう一つの背景が、紛れ込んだ命令（プロンプトインジェクション。読ませた文章に仕込まれた指示にAIが従ってしまう攻撃）です。OWASP（ウェブの安全性に関する国際的な非営利の団体）は、言語モデルを使う仕組みの主要な危険の一覧で、これを最初の項目に挙げています。AIエージェントがウェブや文書を読む場面が増えるほど、外から来た文章がそのまま次の依頼に混ざる経路が増えます。Tamga はこの経路の途中に見張りを置く試みです。

仕組み1：自社のサーバーで動く中継役として、送信の途中に入る

Tamga は、アプリと生成AIの提供元の間に立つ中継役（リバースプロキシ。外へ向かう依頼をいったん受け取って転送する仕組み）です。READMEによると、OpenAI と Anthropic の窓口と同じ形で依頼を受け付けるため、アプリの側は送り先の住所を Tamga に向け直すだけで使える作りになっています。ほかの提供元向けの経路も用意されています。

この作りの利点は、点検が自社の機械の中で終わることです。公式サイトは、利用者の依頼が作者側のサーバーを通ることはないと説明しています。外部の中継サービスに点検を任せる場合と違い、点検のために社外へ文章を渡すことはありません。社外へ出るのは、点検を通った依頼だけです。

構成は二段階です。READMEによると、中継役だけを動かす最小の構成と、記録用のデータベースや管理画面、報告書を作る分析の部品などを加えた全体の構成があります。最小の構成では点検と転送は行いますが、依頼の記録は残らず、再起動すると設定の一部も消えると明記されています。試しに動かす構成と、業務で使う構成を取り違えないことが大切です。

仕組み2：発言の役割ごとに読み分け、方針のファイルで扱いを決める

Tamga の特徴は、生成AIへの依頼を一つの文章としてではなく、発言ごとに、それが誰の言葉かを区別して読む点です。READMEによると、利用者の問いかけ、道具の実行結果、道具の説明、AIの振る舞いを決める指示文（システムプロンプト）を見分けます。

見つけた内容をどう扱うかは、方針を書いたファイルで決めます。扱いは、止める、伏せて送る、警告だけ出す、そのまま通す、の四つに加え、道具の実行結果に命令が紛れていた場合に、その結果だけを取り除いてAIエージェントの作業を続けさせる扱いがあります。規則ごとに、どの役割の発言に効かせるかも絞れます。方針は動かしたまま読み直され、書き方の誤りは厳しくはじく作りだとされています。

返ってきた答えの点検もできますが、READMEによると、同梱の方針では答えの点検は切ってあるとのことです。送る側だけを見ているのか、受け取る側も見ているのかで守れる範囲は変わります。導入する側が意図して決めるべき点です。また、依頼に付いた役割の目印を信用して例外を認める設定は、認証を行う別の中継の後ろでだけ使うよう注意書きがあります。

見つけるもの：個人情報・秘密の鍵・紛れ込んだ命令

READMEによると、Tamga が見つけるものは大きく三つです。一つ目は個人情報で、トルコの国民識別番号、クレジットカード番号（番号の検算と発行元の番号帯の確認つき）、国際銀行口座番号、メールアドレス、電話番号、トルコの納税者番号、公開されている住所としてのIPなどが挙げられています。トルコの口座番号と電話番号の形式には最初から対応していると書かれています。

二つ目は秘密の鍵で、主要なクラウドや開発の場、決済、チャットなどの各種の接続用の鍵や合言葉、暗号の秘密鍵、接続の設定に埋め込まれた認証情報が対象です。三つ目が紛れ込んだ命令で、指示の上書き、役割のすり替え、安全装置を外させる定番の言い回し、符号化して隠した内容、目に見えない文字に隠した文章などを、英語・トルコ語・ドイツ語で見つけるとされています。

見つけ方は、決まった語句の一覧を高速に照合する方式と、番号の検算、見た目の似た文字や幅のない文字による言い逃れを防ぐ文字の正規化を組み合わせたものだと説明されています。規則で止めなかった文章を、手元で動く小さな機械学習の判定器で見直す仕組みも選べます。日本の利用者が気をつけたいのは、日本の個人情報の形式や日本語の言い回しへの対応は、確認した一次情報には書かれていない点です。独自の項目を足す仕組みはありますが、何をどこまで見つけられるかは自社で確かめる必要があります。

記録と通知：何を残し、何を残さないか

全体の構成では、点検の判断が自社のデータベースに記録されます。READMEによると、依頼と答えの本文そのものは保存せず、依頼の付帯情報と、伏せた形の検知結果を既定で30日間残します。中継役だけの構成では、直近1000件を記憶の中に持つだけです。

記録の改ざんへの備えも書き分けられています。管理者の操作の記録には、前の記録とつなげて書き換えを見破れる仕組み（ハッシュの連鎖）がかかっていますが、依頼の判断の記録にはかかっていないと明記されています。監査の証跡として使うなら、この違いを踏まえて、別の仕組みへの転送や保管の方法を考える必要があります。

止めた・取り除いた・警告した依頼をきっかけに通知を出すこともでき、公式サイトは、セキュリティの監視の仕組みやチャット、呼び出し、課題管理の道具への連携を挙げています。ただし、READMEの開発状況の欄では、通知の送り先は端から端までの試験をしていない部品に入っています。管理画面は利用者の鍵を持たず、初回に管理者の鍵を求めてブラウザーに保存する作りなので、管理画面を開く端末の管理も守りの範囲に入ります。

Tamgaが見ないもの：チャットサイト・MCPの通信・素通りの通信

導入前に最も確かめたいのが、見えない範囲です。READMEは「Tamga が見るのは、Tamga に送られた依頼だけ」とはっきり書き、見えないものを並べています。第一に、ブラウザーでチャットサイトに打ち込んだり貼り付けたりした文章です。これはブラウザーからサイトへ直接送られ、中継役を通りません。

チャットサイト向けには、貼り付けや送信の時点で Tamga に判断を問い合わせる拡張機能が試作の段階で用意されています。ただし、READMEによると、試したのは2026年10月11日に三つのサイトで一度だけで、ほかのサイトでは試しておらず、拡張機能の配布の場にも出ていません。第二に、AIエージェントとMCP（AIと外部の道具をつなぐ共通の取り決め）の接続先との間の通信です。道具の返した内容は、エージェントが次の依頼に含めたときにだけ Tamga に届きます。

第三に、送り先を向け直していないアプリの通信です。READMEは、提供元の住所に直接送り続けるアプリは点検されず、Tamga はそうした通信を見つけることも止めることもしない、と書いています。画像・音声・文書の添付も、方針で読む設定にしない限り読まずに転送されます。つまり関所を置いても、関所を通らない道を塞ぐのは別の仕事です。社内の通信の出口の管理と組み合わせて初めて意味を持ちます。

公開されている性能の数字と、その読み方

READMEには、2026年10月3日に測ったとされる数字が載っています。点検にかかる時間は、中央値で0.2ミリ秒程度とされています。提供元の代わりに模擬の相手を置いた試験では、毎秒100件から1000件の依頼で、全体の応答の遅れは中央値で2ミリ秒前後と報告されています。同じ日の測り直しで値に幅があったこと、以前の環境では大きく遅れた例があったことも、READMEに書かれています。

見つける精度は、誤って止めない割合（適合率）と見逃さない割合（再現率）で示されています。規則だけの場合、調整に使った試験の文章では適合率1.000・再現率0.896、調整に使っていない文章ではどちらも1.000とされています。攻撃を想定した84の試験では78を見つけ、6を見逃したとあります。

ここで読み落としたくないのは、作者自身の注記です。READMEは、規則は調整用の文章の見逃しに合わせて書いたもので、調整に使っていない文章も同じ作者が書いたため、どちらの数字も実際の環境での性能より高く出ると認めています。機械学習の判定器が独立したデータでどれだけ働くかも測っていないと書かれています。数字は「作者の試験ではこうだった」という参考値として扱い、自社の文章で測り直すことが前提です。

比べる表：ほかの守り方との違い

生成AIへ送る内容を守る手段はいくつかあります。READMEの説明を手がかりに、Tamga のような自社運用の中継役と、ほかの守り方の違いを、防御の担当者に関係する観点に絞って並べます。表の中の「ほかの手段」の欄は一般的な傾向で、製品によって違います。

観点	自社運用の中継役（Tamga）	外部の事業者の中継サービス	生成AIの提供元の安全機能	社内ネットワークの持ち出し監視
点検する場所	自社のサーバー	事業者のサーバー	提供元のサーバー	社内の通信の出口
文章の中身を読めるか	読める（送られた依頼のみ）	読める	読める	暗号化された通信は読みにくい
点検のための社外送信	なし	あり	あり（送信そのもの）	なし
複数の提供元への効き目	向け直した提供元に効く	事業者が対応する範囲	その提供元だけ	提供元を問わない
自社の手元の記録	残せる（全体の構成）	事業者の仕様による	残りにくい	残せる
運用の手間	自社で運用・更新	契約と設定	少ない	既存の運用に乗る

どれか一つで足りるわけではありません。自社運用の中継役は中身を読めて社外送信もない一方、運用と更新の責任をすべて自社が負います。通信の出口の監視で抜け道を塞ぎ、中継役で中身を見るという組み合わせが、READMEの「見えない範囲」の説明とも整合します。

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

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Tamga の判定は「注意付き」です。根拠は次の三点です。

一つ目は、作者の実績が外から確かめにくいことです。スターは44と小さく、個人のアカウントによる開発で、運営する会社は確認できませんでした。READMEも作者一人の保守だと明記しています。二つ目は、ライセンスがAGPL-3.0であることです。OSI承認のOSSですが、改変して通信網越しに提供する場合の条件があり、使い方によって法務の確認が要ります。三つ目に、公開済みのセキュリティ勧告はありませんが、正式な版が出ていない段階で、勧告が出るほど外部の目に触れていないとも読めます。

一方で、精査の範囲では、スターの不自然な急増はなく、パッケージを入れただけで自動で動く処理も見つかりませんでした。リポジトリ直下には作業をまとめたファイルがありますが、これは人が呼び出す種類のものです。脆弱性の報告窓口を定めた方針の文書も置かれています。ただし、問題が見つからなかったことは安全の保証ではありません。守りのための道具であっても、自社の手順で中身と配布元を確かめる必要があります。

一人で保守する開発段階のOSSという注意点

READMEの開発状況の欄は、Tamga を「1.0より前で、一人が保守している」と説明しています。そのうえで、端から端まで試験した部分と、リポジトリにはあるが試験していない部分を分けて書いています。この正直な書き分けは評価できますが、裏返せば未検証の部品が多いということでもあります。

READMEによると、試験済みとされるのは、中心の点検、方針のファイル、主要な提供元の経路、記録用のデータベースなどです。一方、一部の提供元への経路、通知の送り先、配置用の定義、各言語の部品、報告書を作る分析の部品、端末間の相互認証などは、リポジトリにはあるが端から端までの試験をしていないとされています。社内の一括ログインの仕組みとの連携が限られる、独自の権限の役割を作れない、といった既知の制約も挙げられています。

脆弱性の報告の方針は文書で示されています。それによると、報告の受け付けの返事は48時間以内、確認された重大な問題は14日以内の修正を目標としていますが、保証された水準ではなく目標であり、専任のセキュリティ担当はいないと書かれています。修正は最新の開発版に入り、古い版にはさかのぼって入れない方針です。業務の通信の要所に置く部品として、この体制で足りるかを自社で判断する必要があります。

AGPL-3.0というライセンスで確かめること

AGPL-3.0は、OSI承認のOSSのライセンスで、利用・改変・再配布が認められています。社内で改変せずに使う範囲では、多くの場合大きな負担にはなりにくいと考えられます。ただし、このライセンスには、改変したものを通信網越しに利用者へ提供する場合、その利用者にソースを示す義務があります。

Tamga は通信の中継役なので、社内で手を入れた版を、取引先や子会社など社外の利用者にも使わせる形にすると、この条件に当たる可能性があります。自社の独自の検知規則や連携の部品をどこまで本体に組み込むかによって、公開の範囲が変わることも考えられます。どの使い方が条件に当たるかの解釈は、自社の法務に確かめてください。

公式サイトとREADMEは、有料版はなく、何も有料版のために取っておいていないと説明しています。商用の別ライセンスの案内は、確認した一次情報には見当たりませんでした。将来、運営の形やライセンスが変わる可能性もあるため、採用する場合は、採用した時点のライセンス文書を記録に残しておくのが無難です。

悪用されうるリスクと、中継役そのものが狙われる危険

Tamga は守りのための道具で、攻撃のための機能は説明されていません。ただ、検知の規則が公開されているOSSである以上、攻め手も同じ規則を読み、引っかからない言い回しを探せるという点は意識しておくべきです。READMEも、語句に基づく照合には限界があることを既知の制約に挙げています。

もう一つ見落とせないのが、中継役そのものの重みです。生成AIへのすべての依頼が通る場所には、接続用の鍵や業務の文章が集まります。中継役が乗っ取られたり設定を書き換えられたりすれば、点検を素通りさせる、記録を残さない、といったことも起こりうると推測されます。管理者の鍵や管理画面、記録用のデータベースの守りは、守りの道具だからこそ、ほかの重要な仕組みと同じ水準で扱う必要があります。

さらに、関所があることで安心し、関所を通らない利用を見落とす危険もあります。チャットサイトへの貼り付けや、向け直していないアプリの通信は見えません。「導入したから送信は安全」と受け取られることが、最も起きやすい失敗だと考えられます。社内への説明でも、見えない範囲を必ず添えるべきです。

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

Tamga を自社の守りに組み込むかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

Tamga を使うかどうかにかかわらず、生成AIを業務の仕組みに組み込む企業が取るべき対策は共通しています。第一に、生成AIへの通信の出口を一つに絞ることです。どのアプリがどの提供元に直接つながっているかを把握し、関所を置くなら、そこを通らない通信を通信の出口の管理で塞ぎます。

第二に、そもそも送らない設計を先に考えることです。顧客の識別番号や接続用の鍵が生成AIに届く前に、元の仕組みの側で取り除けるなら、それが最も確実です。検知の仕組みは、取り除き漏れを拾う二段目の守りと位置づけます。第三に、外部の文章を読むAIエージェントには、紛れ込んだ命令を前提に、取れる行動の幅をあらかじめ狭めておきます。

第四に、チャットサイトの利用は、技術の関所とは別に、社内の規程と教育で扱います。第五に、社内のAI利用の規程に、送ってよい情報の区分、止めたときの連絡先、例外を認める人、記録の確認の頻度を書き込んでおきます。関所の設定を規程と結びつけておくことで、担当者が替わっても判断の基準が残ります。

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

Tamga の中心は決まった規則による照合ですが、選べる機械学習の判定器や、報告書を作る分析の部品にはAIによる判定も含まれます。どちらにしても、何を止め、何を通すかの最終的な判断をAIや自動の仕組みに委ねてはいけません。任せてよいのは、怪しい依頼を拾い上げ、根拠となる検知の内容を記録に残すところまでです。

人が決めるのは、どの情報を外へ出してよいか、どの業務に例外を認めるか、止めたときに誰がどう判断するか、記録をどの頻度で誰が読むかです。検知の記録には何に反応したかが残るので、止めた根拠と通した根拠を、人が実際に読んで確かめることを手順に入れます。人が確認する範囲は、導入する前に決めておきます。避けたい使い方を挙げます。

• 作者の公開した精度の数字だけを根拠に、日本語の文章でも同じように守れると判断する
• 関所を置いたことを理由に、チャットサイトへの貼り付けや直接の通信の管理をやめる
• 止められた依頼を、理由を確かめずに例外として通す運用にする
• 答えの点検が切ってあることを確かめないまま、受け取る側も守れていると説明する
• 管理者の鍵や記録用のデータベースを、ほかの重要な仕組みより緩く扱う

止める仕組みは、止めた後の判断が伴って初めて機能します。自動で止めることと、人が理由を確かめることを組み合わせるのが、関所を形だけにしないための要点です。

• Tamga の機能・見えない範囲・性能の数字・開発の状況は、GitHubのリポジトリ（README・脆弱性の報告の方針・ライセンス文書）と公式サイトを2026年10月21日に確かめた範囲に基づきます。正式な版が出る前の段階で、内容は変わる可能性があります
• 日本の個人情報の形式や日本語の言い回しへの対応、機械学習の判定器の独立したデータでの精度は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、検知を逃れる言い回しの具体は扱いません

まとめ

Tamga は、社内のアプリやAIエージェントと生成AIの提供元の間に自社で置く中継役のOSSです。発言の役割を見分けて読み、個人情報・秘密の鍵・紛れ込んだ命令を見つけたら、方針に従って止める・伏せる・警告する・取り除くを選びます。点検は自社の機械の中で終わり、記録も自社のデータベースに残せます。

一方で、正式な版はまだなく、作者一人が保守する開発段階で、試験していない部品も多くあります。公開された精度の数字は作者自身が高めに出ると認めており、日本の個人情報への対応は確かめられていません。チャットサイトへの入力や関所を通らない通信は見えません。送らない設計と通信の出口の管理を先に整え、自社の文章で検知を確かめ、止めた理由を人が読むことが、Tamga との現実的な付き合い方です。

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