自社AIの指示文の漏えいと乗っ取りへの耐性を点検するツール「ZeroLeaks」とは

「社内向けのAIの窓口に、細かな指示文を書き込んである。利用者に聞き出されたら困るのではないか」「外部の文書を読ませるようにしたら、文書に紛れた命令にAIが従ってしまわないか心配だ」——生成AIを業務の窓口に組み込み始めた企業の、情報システム担当者からよく聞く二つの不安です。指示文を隠し通す工夫に目が向きがちですが、守りの要点はそこではありません。本当は、指示文はいつか漏れる前提で、漏れても困らない作りにし、そのうえで実際の耐性を測ることです。この記事では、AIに与えた指示文の漏えいと、紛れ込んだ命令による乗っ取りへの耐性を点検するツール「ZeroLeaks」について、一次情報で確かめられる仕組み・結果の読み方・ライセンスの条件・使う前に決めることを整理します。導入や操作の手順は扱いません。

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

ZeroLeaks は、GitHub上で公開されている点検用のツールです。READMEによると、利用者が用意したAIへの指示文（システムプロンプト、つまりAIの振る舞いを決めるために事前に与える文章）を、利用者が選んだ言語モデルに読み込ませ、実際の攻め手と同じような働きかけを行って、どの程度持ちこたえたかを報告するものです。言語や部品の形は、命令を打ち込んで動かす道具と、TypeScriptから呼び出す部品の二つが用意されています。

公開の時期と規模も確かめておきます。リポジトリと、それを持つ組織のアカウントは、どちらも2026年1月20日に作られています。最初の版も同じ日に公開され、2026年9月26日に公開された版まで、合わせて10の版が並んでいます。2026年10月20日時点で、スターはおよそ740、複製（フォーク）は114です。組織のアカウントが公開しているリポジトリは3つで、運営する会社の名前や所在地は、確認した一次情報には書かれていません。

呼び方にも注意が要ります。READMEは自らを「ソースは公開しているが、オープンソースではない」と明記しています。中身を読める形で公開されてはいますが、OSI（オープンソースの定義を管理する団体）が承認したライセンスではありません。この記事では「ツール」と呼び、ライセンスの条件は後の見出しで詳しく扱います。

そもそもAIへの指示文が漏れると何が困るのか

社内の問い合わせ窓口や顧客向けの案内にAIを使うとき、多くの企業は「答えてよい範囲」「話し方」「参照してよい情報」などを指示文に書き込みます。この文章は、言わばそのAIの振る舞いの設計書です。設計書が外に出ると、どこに制限があるか、どう言えば制限の外へ誘導できるかを、相手に読み取られやすくなります。

さらに困るのは、指示文の中に本来入れてはいけない情報が書かれている場合です。社内の仕組みの名前、接続先、担当者の連絡先、ときには接続用の鍵まで書き込まれている例もあると指摘されています。OWASP（ウェブの安全性に関する国際的な非営利の団体）は、言語モデルを使う仕組みの主要な危険をまとめた一覧の2025年版で、指示文の漏えいを独立した項目として取り上げています。

そのうえでOWASPは、指示文そのものが漏れることより、指示文に秘密を置いたり、権限の判断を言語モデルに任せたりしている作りのほうが本当の危険だ、と整理しています。つまり ZeroLeaks のような点検は、指示文の守りの強さを測るためだけでなく、作りそのものの見直しの入口として使うのが筋です。

点検する二つの観点：聞き出しと、紛れ込んだ命令による乗っ取り

READMEによると、ZeroLeaks の点検は二つの観点に分かれています。一つ目は聞き出し（抜き出し）への耐性で、言葉巧みに働きかけられたときに、AIが自分に与えられた指示文を明かしてしまわないかを確かめます。

二つ目は紛れ込んだ命令への耐性です。読み込ませた文書や、道具の実行結果、管理者を装った発言などに隠された指示に、AIが従ってしまわないか。道具の悪用に同意してしまわないか。これを確かめます。外部の文書やウェブの情報をAIに読ませる使い方が増えるほど、こちらの観点の重みは増します。

どちらの観点も、試験の項目は公開されている評価用の問題集やOWASPの一覧などから集めたものだとされ、READMEでは振る舞いを見る試験が78と書かれています。この記事では、個々の働きかけの中身や言い回しは扱いません。防御の側が知っておくべきは、点検がどの観点を見ていて、どこを見ていないかのほうだからです。

複数の役割のAIが、攻め手・採点役・まとめ役を分担する仕組み

READMEによると、ZeroLeaks の中では役割の異なる六つのAIの担い手が動きます。作戦を立てる役、働きかける役、相手の返事を評価する役、働きかけを組み替える役、点検する役、全体を取りまとめる役です。相手の返事を読みながら途中で方針を変える、という人の検査担当者に近い動きを、複数のAIで分担させる設計だと読み取れます。

ここで押さえたいのは、攻め手も採点役も言語モデルであるという点です。READMEでは、攻め手・点検の対象・評価役・最終判定役にそれぞれ別の言語モデルを選べるとしています。最終判定は、まず規則に基づく簡易な確認を行い、そのあと判定役の言語モデルが「完全に従った」「一部従った」「断った」を見分ける、という二段構えだと説明されています。

この設計には利点と限界の両方があります。決まった合図の言葉が出たかどうかだけで判断するより、実際の振る舞いを見て判定できる点は利点です。一方で、判定役のAIも間違えうるため、結果はそのまま事実ではなく、人が確かめる材料として扱う必要があります。どのモデルを判定役に選ぶかで結果が変わる可能性も、推測として念頭に置いておくべきでしょう。

点検の対象は「指示文と言語モデル」だけ。アプリや道具は含まない

見落としやすいのが、点検の範囲です。READMEは、点検の対象は言語モデルと指示文の組み合わせだけであり、道具は実行されず、アプリの中身や記憶の仕組みも関わらない、と明記しています。

つまり、自社のAIの窓口が実際には社内の検索の仕組みや外部の道具につながっていても、ZeroLeaks の手元版が測るのは、その手前にある「指示文を読んだ言語モデルの受け答え」です。本番で道具がどう呼ばれるか、権限がどう効くかまでは測れません。この範囲を取り違えて「点検に合格したから本番も安全」と受け取るのは危険です。

逆に言えば、指示文を書き換えたときの影響を、本番の仕組みを動かさずに確かめられる点は手元版の使いどころです。指示文の改訂のたびに同じ観点で測り直し、前回との差を見る、という使い方なら、範囲の限界と折り合いをつけやすいはずです。

結果の読み方：判定の段階と「判定できない」という答え

READMEによると、点検の結果は全体の判定として「安全」「低」「中」「高」「重大」の段階と、「判定できない」の六つのどれかで示されます。あわせて0から100の点数（高いほど安全）、指示文がどの程度漏れたかの度合い、見つかった問題、改善の提案、点検できた項目・失敗した項目・飛ばした項目の内訳などが出力されます。

ここで評価したいのは、点検しきれなかった項目があるときに「安全」と言わない作りです。READMEは、相手のモデルや判定役が応答に失敗し、問題も見つからなかった場合は「判定できない」とし、点数も0にすると説明しています。途中で止まった点検が、何も見つからなかった点検と同じに見えてしまう事故を避ける考え方です。

ただし、点検の量には上限があります。READMEでは、紛れ込んだ命令の試験は既定で20項目に絞られ、時間の上限で打ち切られた場合は要約にその旨が書かれるとしています。「安全」と出ても、それは試した範囲での話です。点検の内訳を必ず読み、どこまで試したかを記録に残すことが、結果を正しく使う前提になります。

また、点検の結果を受けて自動で処理を止めたり進めたりできるよう、問題が見つかった場合と判定できなかった場合とで、終わり方の合図を分けているとも説明されています。判定できなかった場合を「合格」として扱わない運用を、組み込む側でも徹底することが大切です。

手元で動かす版と、運営元の有料サービスの違い

ZeroLeaks には、この記事で扱うリポジトリの版とは別に、運営元が提供する有料のサービスがあります。READMEは、両者は点検する対象そのものが違うと説明しています。手元の版は指示文と言語モデルを点検し、運営元のサービスは道具や記憶、接続用の情報を持って実際に動いているAIエージェントを点検するものです。

READMEによると、運営元のサービスでは指示文の聞き出しの点検は行っておらず、指示文だけを点検したい場合は手元の版を使う位置づけです。新しい働きかけの手法は運営元のサービスに先に入る、とも書かれています。主な違いを、READMEの比較表から防御側に関係する項目に絞って並べます。

観点	手元で動かす版（このリポジトリ）	運営元の有料サービス
点検の対象	指示文を読み込ませた言語モデル	動いているAIエージェント（道具・記憶・接続情報を含む）
点検の範囲	聞き出しと、紛れ込んだ命令への耐性	エージェントの境界、文脈に含まれる秘密、複数エージェントなど
費用	ライセンスの範囲で無料。言語モデルの利用料は自社負担	有料の契約（無料の契約はなく、試用期間あり）
試験の項目	公開されている試験の集まり	最新の手法（新しい手法はこちらに先に入る）
結果の保存	利用者が自分で保存する	報告を保存し、時間の経過で比べられる
問い合わせ	GitHubの課題の欄	上位の契約で優先の対応

社外のサービスに自社のAIエージェントをつなぐ場合は、そのサービスに何を見せることになるかを別途確かめる必要があります。運営元のサイトにも、運営する会社の名前や所在地は見当たりませんでした。この記事は手元の版を中心に扱います。

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

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

一つ目は、ライセンスがOSI承認ではない独自の条件であることです。使い方によっては条件に触れうるため、法務の確認が要ります。二つ目は、運営元の実績を外から確かめにくいことです。組織のアカウントはリポジトリと同じ2026年1月20日に作られ、公開リポジトリは3つ、運営する会社の名前は確認できませんでした。三つ目として、リポジトリにはセキュリティ上の問題の報告窓口を定めた方針の文書が置かれていません。

一方で、精査の範囲では、公開済みのセキュリティ勧告はなく、導入の際に自動で動く処理も見つかりませんでした。スターの伸びも1日あたり3前後で、不自然な急増は見られません。ただし、問題が見つからなかったことは安全の保証ではありません。点検のための道具であっても、使う前の確認は他の道具と同じように行うべきです。

ライセンスの条件：OSSではなく、2年後にApache-2.0へ移る

ZeroLeaks のライセンスは「FSL-1.1-Apache-2.0」です。FSLは「機能的ソースライセンス」と呼ばれる、ソースを公開しつつ一定期間は商用の競合利用を制限するライセンスで、公式サイトによると、各版は2年後にApache-2.0またはMITという緩やかなオープンソースのライセンスに移ります。OSIの承認ライセンスの一覧に、FSLは含まれていません。

ZeroLeaks のライセンス文書では、許される目的を「競合する利用以外のすべての目的」と定め、例として社内での利用、営利でない教育や研究などを挙げています。禁じられる競合する利用とは、このツールの代わりになる、または同じか大きく似た機能を持つ商用の製品やサービスとして、他者に提供することです。運営元の既存の製品やサービスの代わりになるものも含まれます。

Apache-2.0へ移る日は、ライセンス文書では各版の公開から2年後か、2028年1月21日のどちらか早いほうとされています。2026年1月に公開された最初の版でも、2026年9月に公開された版でも、遅くとも2028年1月21日には移る計算になります。自社内の点検に使う範囲では競合する利用に当たりにくいと読めますが、取引先向けの点検サービスに組み込むような場合は条件に触れる可能性があります。解釈は自社の法務に確かめてください。

ほかにも、再配布する際はライセンスの条件の写しかリンクを付けること、特許の侵害を主張した場合は特許の許諾が直ちに終わること、商標を使う権利は与えられないこと、無保証であることが定められています。

点検の通信はどこへ流れるのか

READMEによると、手元の版は利用者の機械で動き、利用者自身の鍵で言語モデルの提供元に接続します。既定の接続先は複数の言語モデルを取り次ぐ中継サービスの OpenRouter で、OpenAI に直接つなぐことや、同じ形式で受け付ける別の接続先を指定することもできるとされています。

ここで見落とせないのは、点検する指示文そのものが、選んだ言語モデルの提供元へ送られるという点です。指示文に社内の事情が書かれているなら、それを社外のどの事業者に送ってよいのかを、点検の前に決めておく必要があります。中継サービスを通す場合は、中継の事業者と、その先のモデルの提供元の両方の扱いを確かめることになります。

一方、READMEには、手元の版から ZeroLeaks の運営元へ何かが送られるかどうかについての記載は見当たりませんでした。送られないと確かめられたわけではなく、確認できる情報がないという状態です。機密度の高い指示文を扱う場合は、通信の行き先を自社で確かめるか、機密を含まない写しで点検する、といった慎重な扱いが無難です。

悪用されうるリスクと、点検の道具の二面性

指示文の聞き出しや紛れ込んだ命令を自動で試す道具は、立場を変えれば、他社のAIの弱いところを探す道具にもなりうるという二面性を持ちます。READMEには、よく使われる防御の仕組みの種類を見分け、それに合わせて働きかけを選ぶ機能があるとも書かれています。

ただし、ZeroLeaks の手元の版は、利用者が持っている指示文を自分の選んだモデルに読み込ませて測る作りであり、他社が運用しているAIの窓口を直接試す作りとしては説明されていません。攻め手が同じ種類の手法を、他社の窓口に向けて使う可能性は否定できませんが、それはこの道具に固有の危険というより、同じ種類の手法がすでに公開の研究として出回っているという現実の表れと見るのが妥当でしょう。

守る側が受け取るべき示唆は、自社のAIの窓口も外から試されうる前提に立つことです。社外向けの窓口ほど、指示文が聞き出される前提で、漏れても困らない作りにしておく必要があります。なお、許可のない他者の仕組みを試す行為は、法律上の問題になりうることを社内でも共有しておくべきです。

漏れる前提で作る：OWASPが示す設計の考え方

点検の結果を受けて何を直すのか。その指針として、OWASPの指示文の漏えいの項目が参考になります。OWASPは、指示文を秘密として扱わず、守りの仕組みとしても使わないよう求めています。

具体的には、接続用の鍵や社内の仕組みの名前、権限の構造などの機微な情報を指示文から外し、モデルが直接触れない別の仕組みに置くこと。AIの振る舞いの厳しい制御を指示文だけに頼らないこと。出力を独立した仕組みで点検すること。そして、権限の分離や認可の判断を言語モデルに任せないことが挙げられています。

この考え方に立つと、ZeroLeaks の結果は「指示文をもっと固く書けば合格する」という方向ではなく、「漏れたら困る情報が指示文に入っていないか」「指示文だけで止めようとしている操作はないか」を洗い出す材料として使うのが筋です。点検で漏えいが見つかったら、まず指示文の中身を減らすことから考えると、手戻りが少なくなります。

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

ZeroLeaks を社内の点検に使うかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

ZeroLeaks を使うかどうかにかかわらず、AIの窓口を持つ企業が取るべき対策は共通しています。第一に、指示文に秘密を書かないことです。接続用の鍵、社内の仕組みの名前、担当者の連絡先などは指示文から外し、AIが直接触れない仕組みで扱います。

第二に、権限の判断をAIの外に置くことです。誰に何を見せてよいか、どの操作を許すかは、指示文での「〜してはいけない」に頼らず、仕組みの側で確実に止めます。第三に、外部の文書やウェブの情報を読ませる窓口では、紛れ込んだ命令を前提に、AIが取れる行動の幅をあらかじめ狭めておきます。

第四に、指示文の変更を点検の機会にすることです。指示文を改訂したら、同じ観点で測り直し、前回の結果と比べます。ZeroLeaks のような道具はこの繰り返しに向いています。第五に、社内のAI利用の規程に、指示文の管理者・改訂の記録・点検の頻度・点検で使ってよい外部の事業者を書き込んでおきます。点検を一度で終わらせず、仕組みと規程の両方に組み込むことが、守りを続けるための要点です。

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

ZeroLeaks は、攻め手も採点役もAIが担う道具です。それ自体は効率のよい設計ですが、点検の結果を最終的な判断としてAIに委ねてはいけません。AIに任せてよいのは、多くの働きかけを試して、怪しい応答を拾い上げるところまでです。

人が決めるのは、何を点検の対象にするか、どの結果を問題とみなすか、何を直すか、どこまで試したら十分とするかです。判定には根拠となるやり取りの記録が付くので、判定役のAIが根拠として挙げたやり取りを、人が実際に読んで確かめることを手順に入れます。避けたい使い方を挙げます。

• 点数が高かったことだけを理由に、本番の窓口を安全と判断する
• 「判定できない」を問題なしとみなし、点検を通過させる
• 機密を含む指示文を、送り先の事業者を確かめないまま点検にかける
• ライセンスを確かめずに、取引先向けの点検サービスに組み込む
• 点検で漏えいが見つかったとき、指示文に「明かすな」と書き足すだけで済ませる

最後の例は特に起きやすい失敗です。漏えいへの答えは、指示文を固くすることではなく、漏れても困らない中身にすることです。この順序を人が決めておくことが、点検を意味のあるものにします。

よくある質問：点検で「安全」と出れば、AIの窓口は安心してよいのか

答えは「試した範囲では持ちこたえた、という意味にとどまる」です。手元の版が測るのは指示文と言語モデルの組み合わせで、道具の呼び出しや権限の効き方は含みません。試験の数にも上限があり、判定役のAIが間違える可能性もあります。また、言語モデルの提供元がモデルを更新すれば、同じ指示文でも結果が変わる可能性があります。

では点検に意味がないのかというと、そうではありません。指示文がどの程度聞き出されやすいか、紛れ込んだ命令にどの観点で弱いかを、繰り返し同じ物差しで測れることは、指示文の改訂や作りの見直しの手がかりになります。「安全の証明」ではなく「弱いところを見つける道具」として位置づけるのが現実的です。

もう一つ、「運営元の有料サービスを使えば、もっと確実なのか」という問いもありそうです。点検する対象と範囲が違うため、比べる前に、自社が測りたいのが指示文なのか、動いているエージェント全体なのかを決めることが先です。運営元のサービスについては、確認できた一次情報が限られます。

• ZeroLeaks の機能・点検の範囲・結果の形式・ライセンスの条件は、GitHubのリポジトリ（README・ライセンス文書・リリースの一覧・セキュリティの欄）、運営元のサイト、FSLの公式サイト、OSIのライセンスの一覧、OWASPの項目を2026年10月20日に確かめた範囲に基づきます。版の更新で内容は変わる可能性があります
• 手元の版から運営元へ送られる情報の有無、運営する会社の名前と所在地、判定役のAIの精度は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、点検で使われる働きかけの具体は扱いません

まとめ

ZeroLeaks は、AIに与えた指示文が聞き出されないか、紛れ込んだ命令に従ってしまわないかを、利用者自身の鍵と環境で点検するツールです。役割の異なる複数のAIが攻め手と採点役を分担し、点検しきれなかった場合は「安全」と言わずに「判定できない」と返す作りになっています。

一方で、ライセンスはOSI承認ではないFSLで、競合する商用の利用が禁じられ、各版は公開から2年後か2028年1月21日の早いほうでApache-2.0に移ります。運営元の実績は外から確かめにくく、点検の対象は指示文と言語モデルに限られ、判定にはAIの誤りが混じりえます。指示文に秘密を書かない作りを先に整え、ライセンスと送り先を確かめたうえで、結果を人が読んで改善につなげることが、ZeroLeaks との現実的な付き合い方です。

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