Shiori Demo

Appearance

ブラックボックスな「AI検閲」と、Sunabaのホワイトボックスな物理隔離設計 ​

1. 概要 ​

LLM APIプロバイダ（AnthropicやOpenAI等）が裏側で動的にアップデートするセーフティフィルターは、外部の利用者から見て中身が一切見えない「完全なブラックボックス（仕様非公開）」である。 このブラックボックスなガードレールは、昨日まで動いていた正当な開発コードを「ある日突然、告知なしにサイバー脅威とみなして遮断する」という、AI駆動開発の持続可能性を脅かす主権喪失リスクをもたらす。 本稿では、このクラウド検閲によるデッドロックの構造と、自社製サンドボックス sunaba が実装する「頭脳（モデル）は検閲せず、腕力（実行環境）を物理的に縛るホワイトボックス隔離設計」の優位性について論じる。

2. インシデントの分析：ブラックボックス検閲がもたらす「主権の喪失」 ​

クラウドモデルのセーフガードに依存するAI開発ツールは、以下の3つの「ブラックボックス問題」を本質的に抱えている。

2.1. 告知なき地雷原のアップデート ​

プロバイダは、自社の安全基準（モデレーションポリシー）をしきい値レベルで常時更新している。 「明日から RTSP や proxy のコード生成をブロックする」といった告知は一切行われないため、利用者はある日突然、原因不明のエラーによってエージェントの動作を停止させられる。開発環境の安定性が、他社の非公開ポリシーによって人質に取られている状態である。

2.2. デバッグ不能な「Security through Obscurity」 ​

フィルター回避（Jailbreak）を防ぐ目的から、APIが返すエラーメッセージは Opus's safeguards flagged this message 等の抽象的な表現に限定される。 「プロンプトや生成コードのどのトークンがポリシーのどの条項に触れたのか」の詳細は隠蔽されるため、開発者は「なぜ自分の書いたコードが拒絶されたのか」をデバッグすることが論理的に不可能になり、手探りでプロンプトを書き換える不毛な試行錯誤を強いられる。

2.3. ローカルPCの開発主権のねじれ ​

開発者は、自分のローカルマシンで、自分がライセンスを持つコードを開発している。それにもかかわらず、「そのコードを書き換えて良いか否か」の最終決定権（検閲ゲート）が、クラウドの彼方にある他社サーバーに100%握られている。これは、開発者から自身の開発プロセスに対する「主権」を奪い去る、極めて歪な所有権の構造である。

3. sunaba による「ホワイトボックスな物理隔離」による主権の奪還 ​

このクラウドによる不条理な検閲から開発の主権を取り戻す唯一の解が、sunaba（コードサンドボックス実行エンジン）が提示する 「頭脳（モデル）には制限をかけず、腕力（実行環境）を物理的に縛る」 というアプローチである。

sunaba は、AIの思考や生成コードの内容をブラックボックスに推測してブロックすることはしない。その代わり、src/sunaba/security.py にて、インフラのルールがソースコードとして明示的かつ静的に定義された「ホワイトボックスな物理的防壁」を構築している。

3.1. ルールベースの静的バリデーション（security.py） ​

  • build_secure_run_kwargs() において、ホストに害を及ぼす危険性のあるDockerオプション（privileged モードの無条件拒否、未認可ディレクトリのマウント制限等）を、Pythonの静的ロジックとして明文化している。
  • 開発者は「何が許され、何が禁止されているか」のルールを100%把握し、コントロール下に置くことができる。

3.2. モデルフリーな「実行レイヤーでの構造的隔離」 ​

  • AIがどれほど危険なコード（例：ソケット通信、RTSPリレー、あるいは意図的な無限ループ）を書こうとも、それを実行するコンテナ自体を以下の機能で物理的に無害化する。
    1. 特権の完全剥奪（Unprivileged Container）
    2. 書き込み範囲の限定（ReadOnlyマウント ＆ 一時書き込み領域の隔離）
    3. Egress Proxy による安全な外部通信コントロール
  • インフラが物理的に安全を保証しているため、プロバイダ側で「サイバー攻撃トピックだ」と過剰に検閲してエージェントを殺す必要性がそもそも存在しない。検閲フリーなローカルLLM等へ切り替えても、システムの安全性は1ミリも揺るがない。

4. 結論 ​

他社のブラックボックスな「安全フィルター」にエージェントの命運を委ねる設計は、AIネイティブ開発における最大の単一障害点（SPOF）である。 sunaba が証明した 「ホワイトボックスなインフラ制限による物理隔離（security.py）」 は、AIの『思考（コードの内容）』を制限することなく、安全に『実行』させることで開発の主権を完全に開発者側に取り戻す、最も安定的で自由な次世代のAI駆動開発インフラであるといえる。

5. 参考文献 / 一次情報 ​

Shiori pointer-RAG automation experiment.

Copyright © 2026 masuda-masuo