JavaScriptVM 難読化

コードを保護する理由は数多くあります。たとえば、成果物を単純にコピー＆ペーストされるのを防ぐこと（HTML5 ゲームなどクライアントサイドのプロジェクトでは特に重要です）、コメントや空白を取り除いて読み込みを速くし理解を難しくすること、そしてまだ支払いを受けていない成果物を保護し、ソースコードを渡さずにクライアントへデモを見せられるようにすることなどが挙げられます。

VM（バーチャルマシン）難読化は、JavaScript コードを、埋め込まれたインタプリタ上で動作する独自のバイトコードに変換します。読み取り可能な JavaScript を出力する標準の難読化とは異なり、VM 難読化は元のコード構造を完全に隠します。静的解析ツールは、バーチャルマシン全体をリバースエンジニアリングしない限りロジックを理解できません。詳しくは VM 難読化ガイド をご覧ください。

はい。特定の関数やメソッドにのみ VM 難読化を適用するオプションを用意しています。対象の関数に専用のコメント（/* javascript-obfuscator:vm */）を付けるだけで、その関数だけが VM 難読化の対象になります。最も機密性の高いアルゴリズムだけを保護し、残りのコードは標準の難読化のままにするか手を加えないでおけるため、パフォーマンスへの影響を最小限に抑えられます。

いいえ。API キー、シークレット、認証情報をフロントエンドのコードに保存しては絶対にいけません。どれほど強力な難読化を施しても、フロントエンドの JavaScript に含まれるデータは、その気になった攻撃者に抽出されてしまいます。難読化はリバースエンジニアリングを難しくしますが、暗号化ではないため、機密情報の保護を難読化に頼るべきではありません。シークレットはバックエンドのサーバーに保存し、サーバー側で環境変数を使い、API 呼び出しをバックエンド経由にしてキーを隠すか、サーバーが発行する短命のトークンを使用してください。

100% 完全な難読化は存在しません。JavaScript は最終的に攻撃者が制御する環境（ブラウザまたは Node.js）で実行され、そこでは常に実行時のメモリ検査が可能だからです。これを完全に封じられる JavaScript 難読化はありません。できるのは、そこに到達するためのコストを引き上げることです。現時点で、VM 難読化されたコードに対応する自動難読化解除のオンラインサービスは存在しません。難読化のたびにコードは固有のバーチャルマシンを備えた独自のバイトコードへコンパイルされるため、汎用的なツールを作ることが不可能だからです。標準の難読化ははるかに解除しやすく、自動化ツールや整形ツールで部分的に元に戻せることも少なくありません。一方 VM 難読化を解除するには、バーチャルマシンを完全にリバースエンジニアリングし、バイトコードを復号・デコードし、その命令セットを理解して実行を追跡する必要があり、専念しても数週間かかる作業になります。VM セルフディフェンディングを使わない場合、強力な AI エージェント（Claude Opus 4.7 など）は、小規模なコードベースであればバイトコードを追跡して元のコードをおおよそ復元できます。VM セルフディフェンディングを有効にすると、フック対策、レルムをまたいだ整合性検証、バイトコードのネイティブ性チェックといった多層的な LLM 対策防御が、エージェントがバイトコードを理解するために使う動的な手法、すなわち計装、フック、サンドボックス実行を妨害します。ファイルの静的な読み取りは依然として可能ですが、そこから見えるのは意味を持たないバイトコードだけであり、それを解釈するランタイムを観察しようとするたびに整合性チェックに引っかかります。ファイルだけを手がかりにした AI による自動難読化解除は、現実的ではなくなります。コードをさらに強固にするには、機密性の高い関数を IIFE でラップして名前を完全に変換させ、バイトコードの暗号化などの強化オプションを有効にしてください。詳しくは VM がコードを変換する仕組み をご覧ください。

VM 難読化は複雑な技術であり、一部のエッジケースは完全にはサポートされていない場合があります。VM 難読化後にコードが壊れる場合は、vmTargetFunctionsMode: 'comment' を使って特定の関数だけを難読化し、原因を絞り込めます。問題のあるコードを特定して報告する手順については、トラブルシューティングガイドをご覧ください。

難読化ツールは、デバッグやリバースエンジニアリングを防ぐためのコードを新たに追加します。文字列は 16 進数に変換され、VM 難読化ではバーチャルマシンのインタプリタ全体がバイトコードとともに同梱されます。サイズについては過度に心配する必要はありません。難読化されたコードは GZIP で非常によく圧縮され、ほとんどのサーバーでは GZIP が既定で有効になっています。

どのような難読化でもパフォーマンスには多少の影響があります。標準の難読化のオーバーヘッドはごくわずかです。VM 難読化の影響はそれよりはるかに大きく、コードの内容に強く依存します。たとえば、再帰を多用するバイトコード化されたコードは体感できるほど遅くなります。平均すると、low プリセットで約 10 倍、セルフディフェンディングとデバッグ保護を含む LLM 対策プリセットで約 12 倍の負荷になります。パフォーマンスはコードの内容に大きく左右されます。たとえば、再帰を多用するバイトコード化されたコードは特に遅くなります。オプションを調整するか、機密性の高い部分にのみ VM 難読化を適用することで、バランスを細かく調整できます。最適化のヒントについてはベストプラクティスガイドをご覧ください。

いいえ、おすすめしません。場合によってはコードが壊れます（特にセルフディフェンディングを有効にしている場合）。ただし、難読化の前にコードを minifier に通すことは可能です。

4.4MB 未満のファイルの場合、ソースはすべてメモリ上で処理され、難読化された出力として直ちに返されます。それより大きなファイル（Team / Business プラン）の場合は、安全なストレージに一時的にアップロードし、難読化の完了後ただちに削除します。さらに念のため、5 分ごとにクリーンアップ処理が実行され、5 分より古いファイルはすべて削除されます。お客様のコードが保持されることはありません。

いいえ、難読化されたコードを元のコードに戻すことは不可能ですので、元のコードは安全に保管してください。

はい。難読化オプションでターゲットとして「Node」を選択すると、出力が Node.js 環境向けに最適化されます。

ES2015（ES6）に加えて、ES2022 以降の構文、プライベートクラスフィールド、async/await、オプショナルチェーンなど、最新の JavaScript 機能すべてに対応しています。TypeScript や JSX は、難読化の前に JavaScript へコンパイルしてください。有料プランでは HTML ファイルも難読化できます。保護したい <script> タグに data-javascript-obfuscator 属性を追加すると、HTML の構造を保ったまま各スクリプトが個別に難読化されます。なお、マークした各スクリプト内のコードは自己完結している必要があり（他のスクリプトを参照しないこと）、ES モジュールのスクリプトはスキップされます。

難読化された出力は、VM インタプリタやセルフディフェンディング層を含めて、エバーグリーンなデスクトップブラウザと iOS 16 以降（おおむね直近 3 年間）で積極的にサポートし、テストしています。それより古いブラウザについては、ES2015 のモジュールサポートを下限としてベストエフォートで動作します。それを下回る環境（Internet Explorer を含む）は対象外です。

VM 保護については料金プランをご覧ください。標準の難読化は無料のオンラインプレイグラウンドでお試しいただけます。ひととおりの流れははじめにガイドで解説しています。