JavaScriptのAIコードレビュー回避手法、企業が取るべきセキュリティ対策

公開日：2026年11月3日文：クリスタルメソッド編集部監修：河合継（代表取締役）

JavaScriptコードのAIレビューを意図的に無効化する手法が発見された

2026年10月30日、セキュリティ研究者のveritasが人気Webサイト1万件のブラウザフィンガープリントスクリプトをスキャン中に、AIの安全フィルターを逆手に取った難読化手法を発見した（出典：Better Stack Community、Stork.AI）。問題のスクリプトはロシアのDDoS対策企業に関連するservicepipe.techのドメインに設置されていた。スクリプト本体の実際の機能はGPUやcanvasを使った標準的なユーザーデータ収集だったが、calculateDeadlyLethalSuicideAspirinDosageのような致死量・生物兵器を連想させる関数名が大量に埋め込まれており、不可視Unicodeを使ったバイオウェポン合成を含むジェイルブレイクプロンプトも隠されていた（出典：coinfomania.com、x.com）。

8つのAIモデルでテストした結果、GPT-6 Astra・Claude Opus 5.5・Fable 5.1はバイオセキュリティリスクとして解析を拒否・遮断した。DeepSeekやKimiなど一部のモデルは天安門広場への言及を含めても処理を継続した。コミュニティではこの関数名群が「Words of Power」と命名され、AIの安全拒否ゲートをマルウェア隠蔽に悪用する新手法として注目を集めた（出典：Stork.AI）。

AIの安全フィルターを逆手に取る手口で、実際にどんな被害が出ているかは、日本・世界の主な被害一覧で説明しています。

関連記事AIによる情報漏洩とは？漏れる原因・事例と対策

なぜこの手法はJavaScriptのAIコードレビューを突破できるのか

問題の本質は、大規模言語モデルが「コードの実際の挙動」ではなく「テキストの意味的な危険性」に反応する設計にある。LLMは有害なプロンプトや危険な語彙を含むテキストを処理しないよう訓練されている。攻撃者はこの性質を利用し、無害なコードの中に有害な文字列を「毒」として混入することで、AIに解析を放棄させた。

不可視Unicodeを使ったジェイルブレイクプロンプトの埋め込みも同じ原理の拡張だ。人間がソースコードを目視しても異常は見えない。しかしAIがトークンとして処理すると、有害なシーケンスを検知して処理を停止する。IPA（情報処理推進機構）のAIセキュリティ短信2026年6月号・8月号でも、AIシステムへの敵対的入力やプロンプトインジェクションがセキュリティ上の重要課題として取り上げられている（出典：ipa.go.jp AIセキュリティ短信2026年6月号、ipa.go.jp AIセキュリティ短信2026年8月号）。

企業がサードパーティ製JavaScriptをAIコードレビューだけで安全確認しようとすると、まさにこの盲点を突かれる。AIが「解析できません」と返すこと自体が、何かを隠している可能性のシグナルである——という逆転した読み方が、現場では求められるようになった。

図：致死量・毒を連想させる関数名と不可視Unicodeを埋め込んだJavaScriptがAIの安全フィルターを意図的に発動させ、実際の挙動を検査させないまま素通りさせる手法（上段）と、それをカバーする3つの補完的対策（下段）

次に読む：AIセキュリティ対策とは？企業が知るべきリスク

AIセキュリティ対策とは？企業が知るべきリスクと今すぐできる対策【2026年】

AIに頼れない場面を補う3つの対策：未然防止・早期検知・影響局所化

未然防止：静的AST解析とテキスト前処理でAIの盲点を回避する

AIコードレビューに頼る前に、構文ベースの静的解析ツールをパイプラインの前段に置くことが有効だ。ASTパーサー（抽象構文木解析）は関数名の意味ではなくコードの構造とデータフローを解析するため、関数名に何を書いてあっても動作は変わらない。Semgrep・ESLint・Acornなどのツールはサードパーティスクリプトの動的読み込みパターン、外部ドメインへの通信、ローカルストレージへの書き込みといった挙動指向の検査を、関数名の毒性とは無関係に実行できる。

不可視Unicode（零幅文字・方向制御文字など）の検出は、コードレビューの前段に専用スクリプトを挟むことで機械的に処理できる。JavaScriptのソースコードに\u200b・\u2060・\u202eといった制御文字が含まれている場合を正規表現で検出し、その行をフラグとして記録するだけでよい。人間が目視する前に問題箇所を絞り込める。

// 不可視Unicode制御文字の検出（Node.jsで実行）
const fs = require('fs');
const src = fs.readFileSync('./target.js', 'utf8');
const found = [...src.matchAll(/[\u200b\u200c\u200d\u2060\u2028\u2029\u202a-\u202e\ufeff]/g)];
if (found.length > 0) {
  console.warn(`要調査: 不可視Unicode文字が${found.length}箇所で検出されました`);
}

早期検知：「AI解析拒否」を要調査シグナルとして運用フローに組み込む

今回の発見が示した最も実務的な教訓は、AIが「このコードは解析できない」と返すこと自体をアラートとして扱う運用設計だ。通常のJavaScriptコードがバイオセキュリティリスクを理由に拒否されることはない。拒否が返ってきた場合は自動的に人間のレビュアーにエスカレーションするフローを設けると、意図的な難読化を見落とすリスクを下げられる。

また、GLM-5.3が今回の隠しメッセージを「ノイズ」と識別し、毒関連に見える変数名が実際には数値生成の数学関数であることを正確に分析したように（出典：Stork.AI）、モデルによって反応は大きく異なる。1つのモデルで拒否されたコードを別のモデルで解析し結果を突き合わせることで、誤検知と本物の難読化を区別しやすくなる。重要なサードパーティスクリプトの導入審査には、複数モデルの並列レビューを標準プロセスに含めることを検討したい。

影響局所化：サードパーティJavaScriptのサンドボックス化と読み込み制御

解析を通過した後の防御としては、サードパーティスクリプトの実行環境をサンドボックスで隔離することが基本だ。Content Security Policy（CSP）でスクリプトの読み込み元ドメインをホワイトリスト管理し、script-srcに許可ドメイン以外を含めない設定は、悪意ある第三者ドメインのスクリプトが混入した際の影響範囲を限定する。今回発見されたスクリプトはservicepipe.techに関連するドメインに設置されていたが、CSPが適切に設定されていれば読み込み自体をブロックできた可能性がある。

Tracebitは同様の「コンテキスト爆弾」の原理を防御用デコイ（ハニートークン）として応用しており、攻撃側だけでなく防御側もこの技術を活用できることを示している（出典：Better Stack Community）。

AIコードレビュー回避に対応する現場と、AIで解決できないことの限界

対策が必要な具体的な現場

影響を受けやすいのは、外部ベンダーのトラッキングスクリプト・チャットウィジェット・A/Bテストツールをタグマネージャー経由で複数導入しているEC・メディア・金融サービスの運用担当者だ。導入するサードパーティスクリプトの数が多く、個別のコードレビューにかけるリソースが限られているこれらの現場では、AIコードレビューをスクリーニングの自動化として使いたい需要は高いが、今回の手法はその前提を崩す。

自治体や公共機関のWebサイト担当者も同様だ。外部委託で制作・管理されるサイトに組み込まれるサードパーティスクリプトを、発注側が内容まで確認する体制は整っていないことが多い。IPAの信頼できるAI基盤の実証においても、AIに対する信頼性の前提を人が検証する仕組みの重要性が指摘されている（出典：ipa.go.jp 信頼できるAI基盤の実証）。

AIでは解決できないことと注意すべきリスク

最終的な判断は人間が行う必要がある。AIが拒否したコードが本物の脅威かどうか、静的解析でフラグの立ったコードが実際に悪意あるものかどうかの判断は、文脈と意図を理解できる人間のレビュアーが担う。AIはあくまで優先順位付けと作業量削減のツールだ。

誤検知のリスクも無視できない。致死量や毒を連想させる関数名を含む正規のコード（薬理計算・毒性評価システムなど）を誤ってフラグ立てする可能性はある。自動拒否ではなく「要確認フラグ」として人間にエスカレーションするフローが適切だ。

複数モデル並列レビューはAPIコストと処理時間の増加を伴う。全スクリプトに適用するよりも、新規導入スクリプト・ドメイン変更・バージョンアップ時など変化点に絞った適用がコスト効率上現実的だ。監視の強化は個人情報・プライバシーの問題とのトレードオフでもある。サードパーティスクリプトの全通信を記録・解析する体制は、エンドユーザーのデータを扱うことになるため、プライバシーポリシーと個人情報保護法の観点から設計する必要がある。

以下の比較表は、JavaScriptセキュリティ対策として組み合わせ可能な手法の特性を整理したものだ。

手法	AIフィルター回避への有効性	不可視Unicode検出	実装コスト	主な限界
AIコードレビュー（単体）	低（今回の手法で無効化可能）	低（フィルターが先に停止）	低	毒入り関数名で拒否誘発される
静的AST解析（Semgrep等）	高（関数名に依存しない）	中（別途ルール追加が必要）	中	ゼロデイパターンには対応しにくい
不可視Unicode検出スクリプト	高（前段でフラグ立て）	高	低	制御文字の正規表現メンテが必要
複数モデル並列レビュー	中（モデルにより差あり）	中	高（APIコスト増）	全モデルが拒否するケースもあり得る
CSP + ドメインホワイトリスト	高（読み込み自体をブロック）	対象外	中	許可済みドメインのスクリプト改ざんには無効

明日から試せる実務的な一歩

まず自社サービスのサードパーティスクリプトの一覧を作成し、読み込み元ドメインをリストアップする。次にESLintやSemgrepを使った簡易スキャンを実行し、外部ドメインへの通信・ローカルストレージ書き込み・eval使用箇所を洗い出す。不可視Unicode検出は上記のシンプルなスクリプトで対応できる。

AIコードレビューを使っている場合は、拒否・遮断が返ってきたスクリプトを「要エスカレーション」として別キューに入れるフローをCI/CDパイプラインに追加する。今回の事例のように、AIが拒否するかどうかがシグナルになるケースは今後増えるとみられる。静的解析・不可視Unicode検出・拒否シグナルの運用組み込みを組み合わせることで、AIコードレビュー単体では補えないJavaScriptのセキュリティ対策の盲点を現実的な工数で埋められる。

参考文献

x.com　https://x.com/i/trending/2116246506629898243
coinfomania.com　https://coinfomania.com/javascript-obfuscation-technique-raises-safety-concerns/
Stork.AI　https://www.stork.ai/blog/the-hidden-text-that-can-blind-ai
Better Stack Community　https://betterstack.com/community/guides/ai/ai-safety-filters/
ipa.go.jp（AIセキュリティ短信 2026年6月号）　https://www.ipa.go.jp/digital/ai/security/rcu1hd0000007gji-att/2026-1_0626.pdf
ipa.go.jp（AIセキュリティ短信 2026年8月号）　https://www.ipa.go.jp/digital/ai/security/rcu1hd0000007gji-att/2026-2_0907.pdf
ipa.go.jp（信頼できるAI基盤の実証）　https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2026/rcu1hd000001b13r-att/rcu1hd000001b1ev.pdf