モダンJavaScriptにおけるStrictモードを使用するメリット

2025年にJavaScriptを書いている場合、おそらく気づかないうちにすでにstrictモードを使用しています。ESモジュールとクラス本体は自動的にstrictモードを有効にします。では、なぜJavaScriptのstrictモードを理解することが重要なのでしょうか?

それは、レガシーコードがまだ存在するからです。バンドラーの設定が異なるからです。そして、特定のエラーが表示される理由(または表示されない理由)を知ることで、より優れたデバッガーになれるからです。

この記事では、ECMAScript strictモードが何をするのか、今日でも重要なメリットは何か、そして実際にそれについて考える必要があるのはいつかを説明します。

JavaScriptのStrictモードとは何か、なぜ存在するのか

JavaScriptのstrictモードは、ECMAScript 5(2009年)で導入された言語の制限付きバリアントです。スクリプトまたは関数の先頭に"use strict"を配置することで有効にします。

このディレクティブが存在する理由は、JavaScriptの初期設計に問題のある動作が含まれており、既存のウェブサイトを壊すことなく削除できなかったためです。Strictモードは、より安全なセマンティクスへのオプトイン方式を提供しました。

Strictモードでは、JavaScriptエンジンは:

• サイレント失敗に対してエラーをスローします(未宣言の変数への代入など)
• 混乱を招く構文を禁止します(with文など)
• コンテキストなしで呼び出された関数でのthisの動作を変更します
• 偶発的なグローバル変数の作成を防ぎます

これらの変更は、本番環境ではなく開発時にバグを表面化させることで、JavaScriptのエラー防止をサポートします。

Strictモードが自動的に適用される場所

多くの開発者が見落としていることがあります:JavaScript ESM strictモードは暗黙的です。ESモジュール(import/exportを含むファイル)を使用する場合、strictモードは常に有効です。オプトアウトはできません。

同じことが以下にも適用されます:

• クラス本体: class宣言内のすべてのコードはstrictモードで実行されます
• Node.jsのESモジュール: .mjs拡張子を持つファイル、またはpackage.jsonに"type": "module"があるファイル

コードベース全体がESモジュールとモダンなクラス構文を使用している場合、すでにstrictモードのメリットを得ています。明示的な"use strict"ディレクティブは冗長になります。

今日でも重要なメリット

Strictモードは多くの場合自動的に有効になりますが、その保護機能を理解することで、より良いコードを書き、より速くデバッグできるようになります。

早期のエラー検出

Strictモードは、サイレント失敗をスローされるエラーに変換します。未宣言の変数への代入は、偶発的なグローバル変数を作成する代わりにReferenceErrorをスローします。読み取り専用プロパティへの代入は、サイレントに失敗する代わりにTypeErrorをスローします。

これは、最小化された本番コードをデバッグする場合や、サードパーティライブラリを使用する場合に重要です。

より安全なthisのセマンティクス

非strictモードでは、コンテキストなしで関数を呼び出すと、thisはグローバルオブジェクトにバインドされます。Strictモードでは、thisはundefinedになります。これにより、偶発的なグローバルオブジェクトの変更を防ぎます—これは追跡が困難なバグの一般的な原因です。

分離されたeval()スコープ

Strictモードは、eval()が周囲のスコープに変数を導入することを防ぎます。eval()内で宣言された変数はeval()内に留まります。これにより、セキュリティリスクと予期しない副作用が軽減されます。

制限と一般的な落とし穴

Strictモードは万能薬ではありません。知っておく価値のあるいくつかの注意点があります:

関数レベルのstrictモードは特定のパラメータ構文と競合します。 デフォルトパラメータ、restパラメータ、または分割代入パラメータを持つ関数内で"use strict"を使用することはできません。エンジンはSyntaxErrorをスローします。

StrictモードとNon-strictモードのコードを混在させることは可能です。 スクリプトを連結したり、サードパーティのコードを読み込んだりする場合、アプリケーションの異なる部分が異なるモードで実行される可能性があります。これにより、微妙な動作の違いが生じる可能性があります。

ブラウザコンソールはデフォルトでstrictモードを使用しません。 DevToolsでコードスニペットをテストすると、実際のアプリケーションとは異なる結果が生じる可能性があります。

JavaScriptのStrictモード vs. ReactのStrictMode

これらはまったく異なるものです。JavaScriptのstrictモードは、パースとランタイムの動作に影響を与える言語レベルの機能です。Reactの<StrictMode>は、Reactコンポーネントの潜在的な問題を強調表示する開発ツールです—特定のライフサイクルメソッドを二重に呼び出し、非推奨のAPIを検出し、副作用について警告します。

混同しないでください。これらは異なる目的を果たし、異なるレイヤーで動作します。

Strictモードについて依然として気にかけるべき場合

2025年において、明示的な"use strict"が重要なのは、主に以下のシナリオです:

• レガシーコードベース: まだESモジュールに移行していない
• 非モジュールスクリプト: type="module"なしで<script>タグ経由で読み込まれる
• 古いランタイムをターゲットとするライブラリ: モジュールサポートが保証されていない場合
• 混在したモジュールシステム: CommonJSとESモジュールが共存する場合

古いコードを保守している場合や、幅広い互換性のためにライブラリを構築している場合、strictモードを理解することで、移行中の微妙なバグを回避できます。

まとめ

JavaScriptのstrictモードは、モダンな開発において新しいものでも任意のものでもありません—ESモジュールとクラスではデフォルトの動作です。明示的なディレクティブは、主にレガシースクリプトと非モジュール環境で重要です。

真の価値は、strictモードが何から保護するかを理解することにあります:サイレント失敗、偶発的なグローバル変数、安全でないthisバインディング。その知識により、"use strict"を自分で入力するかどうかに関係なく、デバッグが速くなり、コード品質についてより意図的になります。

よくある質問

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.