Nyxis(ニクシス)とは？AIアプリの情報漏洩を“数学で防ぐ”仕組みと限界を徹底解説

この記事では、AIに書かせたWebアプリで起きやすいアクセス権限の不備による情報漏洩を、数学的な証明で防ごうとするバックエンドフレームワーク「Nyxis(ニクシス)」を解説します。防げる漏洩の範囲、使い方、導入時にかかる費用を確認できます。

Walkersでは「AIを用いたシステム開発のノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAI開発×補助金支援を行っています。⇒サービス概要はこちら

Nyxis(ニクシス)とは？

Nyxis(ニクシス)とは、一般社団法人Nyx Foundationが2026年10月26日にGitHubで公開した、アクセス権限のチェックが正しく働くことを数学的な証明(形式証明)で保証するバックエンドフレームワークです。大部分が、数学の定理の証明にも使われるプログラミング言語「Lean」で書かれています。

アクセス権限のチェックとは、ログインした人が、どのデータを見たり変えたりしてよいかを確かめる仕組みです。本人かどうかを確かめるログインとは別で、たとえばURLの番号を書き換えるだけで他社の文書が見えてしまうのは、アクセス権限の不備による情報漏洩です。

こうした不備は、Webアプリを安全に作るための情報を公開している国際的な非営利団体OWASPがまとめた、APIで起こりやすい重大リスクの一覧でも、2023年版の1位です。

AIに作らせたアプリでも、この種の漏洩は実際に報告されています。2025年5月には、AIでアプリを作るサービス「Lovable」で作られたアプリを調べた研究者が、1,645件のうち170件(約1割)でデータベースの権限設定が不十分で、ログインしなくても氏名や電話番号、決済情報などを読み取れる状態だったと公表しました(CVE-2025-48757)。Lovable側は、アプリのデータを守る責任は各利用者にあるとして、この指摘に異議を唱えています。

画面や処理をAIに次々と作らせるほど、権限チェックの書き忘れや設定漏れが入り込む余地も増えます。Nyxisは、この心配を「書き忘れないよう気をつける」のではなく、仕組みと証明でなくそうとするフレームワークです。Nyxisでできることは、主に次のとおりです。

公式のREADMEでは、Nyxisで作ったバックエンドについて「どのようなHTTPリクエスト列が送られても、認証された主体の正当な権限を超えるデータの読み取り・変更・削除・権限付与は発生しない」ことが証明されると説明しています。権限の不備によって、見てはいけないデータを読まれたり書き換えられたりする漏洩を防ぐための保証です。ただしこれは、公式文書に書かれた仮定が成り立つことを前提とした保証です。

画面の部分はNyxisの外にあり、Next.jsなど普通のWebアプリからHTTPで呼び出します。Nyxisが受け持つのは、データの出し入れと、その権限の判定を行うサーバー側です。

記事執筆時点(2026年10月29日)の最新版はv0.1.1で、公式は「開発中」としています。実行にはPostgreSQL(Supabase)とSupabase Authが必要で、管理画面のようなものはなく、ターミナルでのビルド作業から始めます。

Nyxis 4つの特徴とは？

ここでは、公式のREADMEと保証範囲の文書をもとに、Nyxisの特徴を4つ紹介します。

【特徴①】「誰が何を見てよいか」をルールだけで決める

Nyxisで開発者が書いて承認するのは、Cedarのスキーマとポリシーだけです。「誰がどのデータを見てよいか」を、コードではなくルールとして一か所にまとめるのがNyxisの出発点で、Leanを書く必要はありません。

Cedarは、アプリの権限ルールを書くためのオープンソースの言語です。Nyxisでは権限のルールとデータの構造を一緒に定義でき、Cedarの「エンティティ」がデータベースのテーブル、「属性」がテーブルの列(項目)にあたります。

公式サンプルの掲示板では、次の3つをCedarで書いています。

権限のルールがアプリのコードから切り離されているので、レビューする人はスキーマとポリシーを読めば、どのデータが誰に見えるかを確認できます。処理のコードを1行ずつ追って、漏洩につながるチェック漏れを探す必要がなくなります。

裏を返せば、何が「正当な権限」かはルールが決めます。ルール自体が間違っていれば、Nyxisはそのとおりにデータを見せてしまうので、ルールの承認は人が責任を持って行う必要があります。

【特徴②】AIが書いた処理から他人のデータに直接届かない

Nyxisでは、利用者の操作(リクエスト)を受けて実際に動く処理のコード(ハンドラ)を、Claude CodeなどのAIエージェントに普通に書かせることを想定しています。そのハンドラができるのは、Nyxisの権限チェックを通して操作を頼むことだけです。

一般的なWebアプリでは、処理ごとに「この人はこのデータを触ってよいか」のチェックを書きます。AIが1か所でもチェックを書き忘れれば、そこから他人のデータが漏れてしまいます。

Nyxisのハンドラは、データベースやファイルに直接アクセスする手段を持ちません。どの処理も必ずNyxisの権限チェックを通るので、チェックを「書き忘れる」こと自体が起きない作りです。

さらに、操作する人はログイン情報から、操作の対象はデータベースの現在のデータから、現在時刻や新しいIDはNyxisが決めます。処理のコードがこれらを偽って、別人になりすましたり別のデータを指したりすることはできません。

【特徴③】権限の穴がないことをビルドのたびに証明する

Nyxisでは、プログラムを組み立てるコマンド(lake build)を実行するたびに、Leanが証明を自動で検査します。証明が通らなければビルドは成功しないので、壊れた状態のまま気づかずに進むことがありません。

ビルドでは、承認したスキーマとポリシーへの結び付け、アプリのコードの監査、証明の検査がまとめて行われます。中心となる定理(authorization_safety)は、仮定のもとで、ルールを超える読み取りや変更が起きないこと、つまりアクセス権限の不備による漏洩が起きないことを述べています。

テストとの違いは、確かめる範囲です。テストは用意したケースしか確かめられませんが、証明はモデル上のあらゆるリクエストの並びについて、性質が成り立つことを示します。

公式は、アクセス権限のレビューと監査は「スキーマとポリシーを読み、証明が通っていることを確かめれば済む」としています。AIがハンドラを何度書き直しても、ルールと証明が変わらなければ、確認すべき箇所は増えません。

【特徴④】防げる情報漏洩と防げない情報漏洩を明示している

Nyxisは、証明で防げる漏洩と、証明の外にあって防げない漏洩、その前提を保証範囲の文書(ASSUMPTIONS.ja.md)にまとめています。READMEでも、本番で使う前に必ず読むよう求めています。

押さえておきたいのは、Nyxisが防ぐのは「権限のない人がデータを見る・書き換える」タイプの漏洩に限られ、情報漏洩のすべてではないという点です。作者自身も、公開当日にこの点を訂正しています。

公開時のX投稿では「情報漏洩が起きないことを数学的に保証する」と紹介されましたが、Xでは「権限のチェックが正しいことと、情報漏洩が起きないことは別の話ではないか」という指摘が相次ぎました。作者は同日夜に「表現が強すぎました」と謝罪し、証明しているのは一定の仮定のもとで「認可不備による情報漏洩が起きないこと」(認可＝アクセス権限のチェック)だと訂正しています。

導入を考えるなら、自社で心配している漏洩がこの範囲に入るのかを先に切り分けておくことが大切です。

証明で防げるのは、アクセス権限の不備による次のような漏洩です。

一方、保証の外にあるものとして、文書には次のような項目が挙げられています。

たとえばLovableの事例では、アプリの画面を通さず、データベースを直接操作されて情報が見えてしまいました。Nyxisを使っていても、データベースを直接操作できる窓口を開けたままにすれば同じ問題が残ります。公式文書は、この窓口(Data API)を無効にするよう求めています。

もう一つの例は、非公開の組織名が存在するかを推測できる問題です。外部の開発者が公式サンプルで確かめ、Xで指摘しました。見る権限のない組織と同じ名前で新しい組織を作ろうとしたとき、すでにその名前が使われていれば「すでにあります」というエラーになり、使われていなければ作成できます。この違いだけで、中身は見えなくても非公開の組織名の存在を推測できてしまいます。公式文書も、こうしたエラーがデータの存在を伝えるおそれを認めています。

そもそも情報漏洩の原因は、アクセス権限の不備だけではありません。東京商工リサーチの調査では、2025年に上場企業とその子会社が公表した個人情報の漏えい・紛失事故180件のうち、「ウイルス感染・不正アクセス」が116件、「誤表示・誤送信」が37件、「紛失・誤廃棄」が18件でした。ランサムウェアなどのウイルス感染や、誤送信・紛失による漏洩はNyxisの対象外で、別の対策が必要です。

公開直後から、外部の開発者による修正の提案も出ています。たとえば、ログインした人向けの応答が途中の共有キャッシュに残り、ほかの人に渡るおそれがある問題(PR #1)や、所属を追加する操作が自分自身を許可してしまう問題(PR #3)です。対応状況は変わるため、導入前にリンク先を確認してください。証明があることと、実際の構成で漏洩が起きないことは分けて確認する必要があります。

Nyxisにかかる費用

NyxisはMITライセンスのオープンソースとして公開されており、無料で利用できます。MITライセンスは商用利用や改変、再配布を認めるライセンスで、著作権表示とライセンス文を残すことが条件です。

記事執筆時点では、Nyxisの有料プランや、法人向けの商用サポート・稼働保証(SLA)は公式に案内されていません。困ったときの窓口は、GitHubのissueやプルリクエストが中心になります。

ただし、Nyxisを動かすにはPostgreSQL(Supabase)とSupabase Authが必要で、本番で使う場合はSupabaseの利用料金やサーバー代が別にかかります。開発中の版であることを踏まえると、費用面では、ライセンス料よりも導入と検証にかかる手間を見込んでおくことが大切です。

Nyxisの使い方

ここでは、Nyxisを手元で動かし、自分のアプリに組み込むまでの流れを紹介します。詳しい手順は、公式の日本語READMEと依存の準備、ローカルSupabaseの準備の各文書にまとまっています。STEP1〜4はターミナルでの環境構築なので、開発の担当者が進める作業です。

よくある質問

Nyxisを使えば情報漏洩は起きなくなりますか？

いいえ。作者は公開時のX投稿で「情報漏洩が起きないことを数学的に保証する」と紹介しましたが、同日夜に表現が強すぎたと訂正しています(詳しくは【特徴④】で解説しています)。Nyxisが証明しているのは、一定の仮定のもとでアクセス権限の不備による情報漏洩が起きないことです。SupabaseのData APIなどNyxisを通らない経路や鍵の流出、誤送信や端末の紛失による漏洩は防げません。

Nyxisは無料で使えますか？

Nyxis本体はMITライセンスのオープンソースで、無料で利用でき、商用利用もできます。ただし、動かすために必要なSupabaseの利用料金やサーバー代は別にかかります。

今あるアプリにNyxisを後から入れて、情報漏洩対策にできますか？

部品として後から足す使い方は想定されていません。Nyxisはバックエンドそのものを作るフレームワークなので、権限のルールをCedarで書き、データを扱う処理をNyxisの上で作り直すことになります。

---

Nyxisを検討する第一歩は、自社アプリで漏れてはいけないデータと、それを見てよい人を表に書き出すことです。

証明が通ることと漏洩を防げることの間には、裏口になる経路の遮断や鍵の管理、未解決の修正の確認という作業があります。

自社のAI開発をどこから始めるか迷う場合は、問い合わせ不要でその場で結果が出る無料診断で、相談したい課題を絞り込めます。

Walkersでは成果が実証されたノウハウをもとに、事業を成功に導くためのAI開発×補助金支援を行っています。新規事業・システム開発でお悩みがある方はお気軽にご相談下さい。

AI開発×補助金支援サービスの概要はこちら＞＞

Walkersに無料で相談する＞＞