AIでコードを書くときの秘密情報の流出をOSS「Nenya」はどう防ぐのか

「開発チームがAIにコードを書かせているが、設定ファイルの鍵まで一緒に送っていないか心配だ」「社外のAIに渡る前に、機密だけ自動で消してくれる仕組みはないのか」——AIによるコーディングを認め始めた企業で、情報システムやセキュリティの担当者が口にする悩みです。ここで考えるべきは、伏せる道具を置けば安心できるかどうかではありません。本当に問うべきなのは、伏せる仕組みが何を見つけられ、何を見逃すのかを、自社で把握できているかです。この記事では、AIのコーディング道具とAIの提供元の間に置く中継のOSS「Nenya」について、一次情報で確かめられる伏せ字の仕組み、標準で効く範囲と自分で有効にする範囲、開発者自身が認める限界、導入前に確かめることを整理します。導入や設定の手順は扱いません。

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

Nenya は、GitHub で公開されている中継のソフトウェアです。リポジトリの説明によると、Go という言語で書かれた軽量の「AIの中継（ゲートウェイ）」で、Cursor や OpenCode などの手元のコーディング道具と、Gemini や DeepSeek などのAIの提供元の間に入り、利用者の側からは透明に働く中間の層だとされています。ライセンスは Apache-2.0 で、OSI承認のライセンスです。

2026年10月27日に確かめた範囲では、リポジトリは2026年3月28日に作られ、スターは36、派生は0、主な系統のコミットは約845件です。最新の版は10月23日に出た 0.18.0 で、9月17日の 0.14.1 から約1か月半で五つの版が出ています。READMEによると、OpenAI か Anthropic の会話の形式に合わせた提供元であれば使え、そのうち23の提供元には専用の対応部品が用意されています。

README は Nenya の役割を、AIのコーディング道具は依頼のたびにソースコード、プロンプト、資格情報をクラウドの提供元へ送っている、Nenya はその間に立つ「門番」だ、と説明しています。日本語で書かれた紹介や第三者の評価は、確認した範囲では見当たりませんでした。海外でも、独立した検証の記事は見つかっていません。

なぜ今、AIの通り道に「関所」を置く発想が注目されるのか

AIのコーディング道具は、作業中のファイルや会話の履歴、道具が読み込んだ結果をまとめて提供元へ送ります。開発の現場では、設定ファイルや環境の変数に、クラウドの鍵やデータベースの合言葉がそのまま書かれていることが珍しくありません。使う人が気づかないうちに、社外のAIの提供元へ、会社の鍵がコードと一緒に送られるという経路ができてしまいます。

こうした中、自前の中継を通してAIの呼び出しを見える化する考え方が、海外の技術者の間で議論されています。韓国の技術ニュースサイトで紹介された記事とその反応では、どの道具がどのモデルをいつ呼んだかを記録できる、本物の提供元の鍵を各道具から隠せる、といった利点が挙げられる一方、中継が一か所の故障点になることや、会話に個人情報が含まれることへの懸念も出ています。

Nenya はこの流れの中で、とくに手元の端末から出る前に秘密を伏せることを前面に出したOSSです。複数の提供元を切り替える中継は多くありますが、Nenya は伏せ字を「常に動く最低限の守り」と位置づけ、そのうえに文章に紛れた指示への備えや出口の見張りを重ねる、という組み立てを説明しています。

仕組み1：送信前に秘密情報を伏せる三つの段

設計の文書によると、Nenya は届いた依頼を、決まった順に並んだいくつかの処理に通します。最初に動くのが伏せ字の処理で、依頼の中身全体から、秘密の値、認証のための符号、資格情報の形をした文字列を、あらかじめ決めた文字の型（正規表現）で探して伏せます。README はこれを「第0段」と呼び、AWS の鍵、GitHub の符号、合言葉などを、中身が端末を出る前に伏せると説明しています。この段は標準で常に動きます。

次の段は、でたらめさの度合い（エントロピー）が高い文字列を秘密の候補として伏せる処理です。型に当てはまらない、ランダムに見える長い文字列を拾うためのもので、こちらは有効にするかを選べます。その後に、質問との関わりが薄い部分を削る処理と、大きすぎる依頼を要約して縮める処理が続きます。要約は手元で動かすAIにも、外部の提供元にも任せられる、と文書にあります。

確かめておきたいのは、型の一覧がどこまでそろっているかです。確認した文書には、どの種類の秘密をどの型で見つけるのかの全体の一覧は書かれていませんでした。伏せた箇所が何に置き換わるのか、応答で元に戻すのかも、確認した範囲では分かりませんでした。自社の鍵の形が対象に入っているかは、導入を検討する側が試験の環境で確かめる必要があります。

仕組み2：届いた文章の指示に従わせないための層

Nenya のもう一つの柱は、プロンプトインジェクションへの備えです。文書は、英国の開発者サイモン・ウィリソン氏の「致命的な三条件」の考え方を引いています。外から来た信用できない文章を読み、社内の情報に触れられ、外へ通信できる、という三つがそろったAIは、文章に紛れた指示だけで情報を持ち出されうる、という見方です。コーディングの中継はこの三つを全部満たすため、少なくとも一つを断つことを狙う、と書かれています。

具体的には、指示を上書きしようとする言い回しや役割の偽装、隠された文字などを、AIを使わない決まった規則で検知する層があります。道具が読み込んだ結果などを「これはデータであって指示ではない」と印を付けて囲み、AIに区別させる層もあります。判断に迷う検知は別のAIに見直させることもできますが、文書によると、見直しのAIができるのは誤検知を取り消すことだけで、止める判断はAIに頼らない作りです。

ただし、これらの層は標準では切ってあります。検知の層も、囲みの層も、使う人が有効にしたときだけ働きます。また、囲みの層はAIが印に従うことを前提にしたもので、決まった規則のように確実に止める守りではない、と文書自身が書いています。MCP（AIに外部の道具をつなぐ共通の仕組み）の道具を中継から呼ぶ場合だけは、引数の大きさや形、宛先を確かめる守りが標準で働きます。

仕組み3：出口で持ち出しを見張る

伏せ字が「入口」の守りだとすると、応答の側には「出口」の守りがあります。一つは、AIの応答に含まれるリンクや画像の宛先を決まりに照らし、記録する、取り除く、止めるのいずれかを行う ExfilGuard と呼ばれる仕組みです。文章に紛れた指示でAIに社内の情報をリンクの中に埋め込ませ、外へ送らせる手口に備えるものと説明されています。

もう一つは、依頼ごとに目印の文字列を仕込み、それが応答や道具の呼び出しの中に出てきたら持ち出しの兆しとみなす「仕掛け線」です。10月23日の 0.18.0 では、これらの出口の見張りと伏せ字の処理が、提供元ごとに違う応答の形のすべての部分を調べるように直された、と変更履歴にあります。裏を返せば、それ以前の版では見張りの及ばない部分があったということです。

この出口の守りも、標準では切ってあります。宛先の決まりは標準では記録だけで止めず、仕掛け線は有効にすると止める動きになる、と文書にあります。文書は仕掛け線について、目印をそのまま含む場合しか見つけられず、持ち出しがないことの証明にはならないと明記しています。出口の見張りは持ち出しを減らす工夫であって、なくすものではありません。

仕組み4：中継そのものが抱える鍵を守る作り

中継を置くと、そこに提供元の鍵と、道具が中継に入るための鍵が集まります。中継そのものが狙われる場所になるため、Nenya は鍵の扱いにも手を入れています。README と安全の方針の文書によると、鍵はディスクへの書き出しを防ぐ固定のメモリーに置き、起動後は読み取り専用に封じ、異常終了時のメモリーの書き出しも止めています。

動かし方の面でも、管理者ではない利用者の権限で動かすこと、使える仕組みを絞る仕組みや権限の引き上げを止める設定、読み取り専用のファイルの置き場を前提にしています。道具ごとの鍵に役割を割り当て、使えるモデルや窓口を絞ることもできます。0.18.0 では、見本のままの弱い鍵では起動しないように改められました。

一方で、中継の運用で漏れやすい情報についての記載は限られています。設計の文書は、記録には担当の道具や提供元、モデル、試行の回数などの付帯の情報を残すとしていますが、依頼の本文そのものを記録に残すかどうかは、確認した文書からは分かりませんでした。応答の写しはメモリーの中の一時保存に置かれ、0.18.0 からは道具の鍵ごとに分けて扱われるとされています。

標準で効くもの、自分で有効にするもの

Nenya を評価するときにいちばん大事なのは、どの守りが最初から効いていて、どの守りは使う人が選ばないと働かないのかを分けて見ることです。下の表は、README と防御の文書の記載を筆者がまとめたものです。

守り	標準の状態（文書の記載）	防御の目で見た注意点
型による秘密の伏せ字	常に動く	対象の種類の全体の一覧は文書で確認できず。自社の鍵の形を試す必要がある
でたらめさによる伏せ字	選んで有効にする	誤って普通の文字列を伏せることもありうる。業務への影響を試す
指示の上書きなどの検知	切ってある	有効にしても、部分に分けて送られた指示はつなげて調べない
信用できない文章の囲み	切ってある	AIが印に従う前提の工夫で、確実に止める守りではない
応答の宛先の決まり	切ってある（有効にしても標準は記録のみ）	止める設定にするかは自社で決める
目印による仕掛け線	切ってある（有効にすると止める）	形を変えた持ち出しは見つけられない
中継から呼ぶ道具の引数の確認	道具をつないだときは働く	道具の側で直接呼ぶ処理は中継を通らない

表から分かるのは、常に動くのは型による伏せ字だけだという点です。そのほかの多くの守りは、運用する側が意図して有効にし、止めるのか記録だけにするのかを選ぶ必要があります。「Nenya を入れたから、プロンプトインジェクションにも持ち出しにも備えている」と報告するのは、設定を確かめるまでは早すぎます。

「伏せ字は最善努力」：開発者自身が書いている限界

Nenya の文書は、限界を率直に書いている点が特徴です。防御の文書には「秘密の伏せ字は最善努力」とあり、型やでたらめさに頼る方法は、新しい形の秘密を見逃すと明記されています。また、AIのコーディング道具が自分の側で直接呼ぶ道具は中継を通らないため、毒を仕込まれた結果に導かれた呼び出しは中継から見えない、とも書かれています。

さらに、守りの部品が壊れたときの動きにも注意が要ります。文書によると、伏せ字などの守りの部品は、壊れたときに中身を素通りさせず、エラーを返して止まる作りです。これは安全側の作りですが、文書自身が「止まることは、使えない時間が生まれることだ」と書いています。一方、依頼を縮める部品は、壊れたときに元の依頼をそのまま送る作りが標準です。

免責の文書は、Nenya を「危険を減らすためのもので、なくすものではない」と位置づけ、使う人が自らの責任で確かめるよう求めています。危険な命令を型で止める仕組みについても、別名の使い方や符号化、別の実行の経路などで回り込まれうると書いています。防御の文書の結びにある「過信した守りは、理解している守りより悪い」という一文は、この種の道具を使う企業にとっても大切な考え方です。

比べる表：ほかの漏えい対策との違い

AIへの情報の持ち出しを防ぐ手段は、Nenya のような中継だけではありません。会社がすでに持っている仕組みと並べると、Nenya の位置づけが見えやすくなります。下の表は一般的な作りをもとにした整理で、個別の製品の細かな仕様を比べたものではありません。

観点	Nenya のような中継	コードの保管場所の秘密の検査	社内の網の出口での情報漏えい対策
見る場所	AIへ送る直前の依頼と、AIからの応答	保管場所に登録されたコード	社外へ出る通信全般
強み	AIに渡る中身そのものを、送る前に伏せられる	登録前後に秘密の混入を見つけられる	AI以外の経路もまとめて見られる
弱み	中継を通らない通信は見えない。型にない秘密を見逃す	AIへの送信そのものは止められない	暗号化された通信の中身は見にくいことが多い
運用する人	開発の部門や情報システム部門	開発の部門	情報システム部門

どれか一つで足りる、という関係ではありません。秘密をそもそもコードに書かない運用が土台にあり、その上で保管場所の検査、中継での伏せ字、出口での対策を重ねる、と考えるのが現実的です。中継の伏せ字は、すり抜けた秘密を最後に拾う網の一つと位置づけるのがよいでしょう。

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

このラインでは、OSSを手元に取り込んだり動かしたりせず、公開されている情報だけで安全性を判定しています。Nenya の判定は「注意付き」です。根拠は次のとおりです。

まず、問題の報告は見つかっていません。2026年10月27日の時点で、リポジトリに公開されたセキュリティ勧告はありませんでした。ライセンスは Apache-2.0 で、OSI承認のものです。作者のアカウントは2011年に作られたもので、公開しているリポジトリは41、フォロワーは72です。脆弱性の報告の窓口を定めた方針の文書もあり、非公開の報告の仕組みを使うよう求め、48時間以内に受け付けを返し、5営業日以内に最初の評価をするとしています。

一方で、注意を付けた理由が二つあります。一つは、リポジトリの直下に導入用のスクリプトがあり、導入のときに管理者権限で動く処理があることです。もう一つは、スター36、派生0と、利用の実績や第三者の目がまだ小さいことです。個人のアカウントによる開発で、組織としての運営体制は確認できませんでした。なお、問題が見つからなかったことは安全の保証ではありません。導入するなら、自社でも確かめてください。

注意点の詳細：個人開発・導入スクリプト・配布物の確かめ方

導入用のスクリプトの説明を読むと、GitHub の公開の版から本体を取得し、改ざん確認用の値の一覧と照らして、合わなければ中止します。Sigstore という署名の確認の道具が入っていればその署名も確かめますが、入っていなければ警告を出して値の照合だけで進みます。確認の値は本体と同じ場所から取るため、署名の確認が動いたときのほうが確かさは高い、と考えられます。本体や常駐の設定をシステムの領域に書き込むため、管理者権限が要ります。

配布物の確かめ方については、比較的よく整えられています。確認の文書によると、公開の版は作成時に署名され、配布物の確認の値の一覧そのものにも署名があり、部品の一覧（SBOM）も付いています。ただし文書自身が、これらの確認は「公式の作成の流れで作られ、その後に書き換えられていない」ことを示すもので、ソースコードの中身の正しさを保証するものではないと書いています。

運営の面では、支援の対象は最新の主な系統だけで、古い版は支援しないと方針の文書にあります。版の間隔が短く、0.18.0 では内部の点検で見つかった最優先の問題12件に対応したと変更履歴にあります。活発に直されている一方で、古い版を使い続けると、直された問題を抱えたままになるということです。免責の文書には、AIの支援を受けて作られ、作者がすべての行を確かめたとも書かれています。

悪用されうるリスク

Nenya 自体は攻撃の道具ではありませんが、守りの道具であるがゆえの危険があります。ここに挙げるのは一般的な想定で、Nenya での具体的な事例に基づくものではありません。現時点で悪用の報告は確認していません。

一つ目は、中継そのものが狙われることです。中継には複数の提供元の鍵と、社内の開発者の依頼がすべて集まります。中継の設定を書き換えられたり、乗っ取られたりすると、伏せ字を切られたうえで、すべての依頼を読まれる場所が一か所にできてしまうことになります。設定の変更の記録と、中継を動かす機械の管理が欠かせません。

二つ目は、守りへの過信です。「中継を入れたので秘密は出ない」と考えると、型にない秘密や、文章で書かれた顧客の情報、設計の資料などが素通りしていることに気づけません。三つ目は、中継を通らない利用です。開発者が中継を経ずに提供元へ直接つなげば、伏せ字は働きません。中継を置くことと、中継を通ることを強制することは別の話です。

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

Nenya のような中継を検討するときは、機能の多さより先に、伏せる範囲、有効にする守り、通ることの強制の三点を確かめます。次の順で進めると、後からの食い違いを防げます。

企業が取るべき対策

一つ目は、秘密をコードや設定ファイルに書かない運用を先に固めることです。鍵の保管の仕組みを使い、AIのコーディング道具が読む場所に生の鍵を置かないことが、どの中継よりも確かな守りです。中継の伏せ字は、その運用からこぼれたものを拾う二段目の守りと位置づけます。

二つ目は、AIのコーディング道具の利用を規程で決めることです。どの道具を、どの提供元とつないで使ってよいのか、中継を必ず通すのか、社外に出してよい情報の区分は何かを、AIの利用規程に入れます。社内のAIへの通信は中継を必ず通す、という決まりと、それを網の側で確かめる仕組みをそろえて置くことが大切です。

三つ目は検知と運用です。中継の記録から、伏せ字が働いた回数や、出口の見張りが反応した件数を定期的に見て、どのチームで秘密が混ざりやすいかを把握します。四つ目は調達の確認で、運営の体制、支援の範囲、配布物の署名の確かめ方、更新の頻度、提供が止まったときの代わりの手段を確かめます。個人の開発のOSSを使う場合は、作者が更新をやめても自社で回せるかまで考えておきます。

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

Nenya の作りは、止める判断を決まった規則に任せ、AIには誤検知の見直しだけをさせる、というものです。この考え方は、企業がAIを使った守りを組むときにもそのまま当てはまります。AIに判断させない部分を、先にはっきりさせておく必要があります。次のような使い方は避けてください。

• 中継を入れたことを理由に、鍵が書かれた設定ファイルをAIに読ませてよいことにする
• 伏せ字が効くかを試さないまま、本番の開発チーム全体に広げる
• 持ち出しの見張りの判断を、見直しのAIの答えだけで止めたり通したりする
• 標準のまま使い、指示の検知や出口の見張りが切ってあることに気づかない
• 古い版を更新しないまま使い続ける

人が決めるべきなのは、AIに渡してよい情報の区分、有効にする守り、止めるか記録だけかの線引き、中継を通ることの強制の四つです。AIに任せてよいのは、迷う検知を見直し、なぜそう判断したかの根拠を添えて記録に残すところまでです。最終的に止めるか通すかの基準と、その結果の見直しは人が受け持ちます。

よくある質問：中継を置けば、社内のコードをAIに渡してよいのか

答えは「中継だけでは決められない」です。Nenya の伏せ字は、型に当てはまる秘密を送信前に消すもので、顧客の情報や設計の考え方、未発表の製品の話など、文章で書かれた機密は対象ではありません。そうした情報をAIに渡してよいかは、提供元との契約（学習に使わない、保存期間など）と、社内の情報の区分で決めることです。

OSSであることは、守りの中身を誰でも確かめられるという利点です。Nenya は限界を文書に率直に書いており、その点は評価できます。ただし、確かめられることと、自社で確かめたことは違います。「伏せる中継を入れたから安全」ではなく、何を伏せられて何を伏せられないかを試し、通ることを強制し、記録を見続けることが前提です。

• Nenya の機能・標準の状態・限界・配布物の確かめ方は、GitHub のリポジトリ（README・リリースの一覧・変更履歴・文書）を2026年10月27日に確かめた範囲に基づきます。版の更新で変わる可能性があります
• 伏せ字の対象の種類の全体の一覧、伏せた箇所の置き換え方、依頼の本文を記録に残すかどうかは、確認した一次情報の範囲では確かめられませんでした
• この記事はOSSを取り込んだり動かしたりせずに書いています。導入や設定の手順は扱いません

まとめ

Nenya は、AIのコーディング道具とAIの提供元の間に置き、送信前に鍵や合言葉などの秘密情報を伏せる中継のOSSです。ライセンスは Apache-2.0 で、型による伏せ字が常に動き、そのうえに文章に紛れた指示への備えや出口の見張りを重ねられる作りになっています。鍵の扱いや配布物の署名にも手が入っており、限界を文書に率直に書いている点も特徴です。

一方で、常に動くのは型による伏せ字だけで、多くの守りは自分で有効にする必要があること、開発者自身が伏せ字は最善努力と認めていること、個人の開発で実績がまだ小さく、導入用のスクリプトが管理者権限で動くことには注意が要ります。秘密を書かない運用を土台に、中継を通ることを強制し、伏せられる範囲を試験で確かめることが、Nenya との現実的な付き合い方です。

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