JavaScriptは、その柔軟性ゆえに多くの開発者に愛されている言語ですが、一方で「意図しない動作」を許容してしまうという側面も持っています。
古くから存在する仕様の中には、現代のプログラミングにおいてはバグの原因となりやすい不適切な挙動も含まれています。
こうした問題を回避し、コードの安全性と実行速度を向上させるための仕組みがJavaScript Strict Mode（厳格モード）です。
Strict Modeを正しく理解し活用することは、単なるエラーチェック以上の意味を持ちます。
それは、将来のJavaScriptの仕様変更に耐えうる堅牢なコードを記述し、チーム開発における予測可能性を高めるための第一歩となります。
本記事では、Strict Modeの基礎から具体的な制約事項、そして現代のJavaScript開発における実践的な役割までを詳しく掘り下げていきます。
Strict Modeとは何か
Strict Modeは、ECMAScript 5（ES5）で導入された「JavaScriptの実行環境をより厳格なルールに変更する機能」です。
通常、JavaScriptは「Sloppy Mode（ずぼらなモード）」と呼ばれる状態で動作しており、多少の構文上のミスや曖昧な記述があっても、ブラウザが気を利かせて実行を継続しようとします。
しかし、この「親切な挙動」が、実際には見つけにくい論理的なバグを生む原因となります。
Strict Modeを有効にすることで、JavaScriptエンジンの解釈を明示的かつ厳格にし、サイレントに失敗していたエラーを例外（Exception）として報告させることができます。
なぜStrict Modeが必要なのか
現代の開発においてStrict Modeが必要とされる主な理由は、以下の3点に集約されます。
- エラーの早期発見： 実行時にエラーが発生しないものの、予期せぬ動作を招く記述を禁止し、開発段階でミスに気づきやすくします。
- 最適化の促進： コードの曖昧さを排除することで、JavaScriptエンジン（V8など）がより高度な最適化を行いやすくなり、実行速度の向上が期待できます。
- 将来の安全性： 将来のJavaScript（ECMAScript）で定義される可能性のあるキーワードの使用を制限し、言語の進化に伴う互換性の問題を未然に防ぎます。
Strict Modeを有効にする方法
Strict Modeを有効にするには、スクリプトや関数の冒頭に特定の文字列を記述するだけです。
スクリプト全体に適用する
ファイル全体の動作を厳格化したい場合は、ファイルの先頭に以下のディレクティブを記述します。
// スクリプト全体のStrict Modeを有効化
"use strict";
let message = "Hello, Strict Mode!";
console.log(message);Hello, Strict Mode!関数スコープに適用する
特定の関数内だけを厳格化することも可能です。
既存のライブラリとの兼ね合いで、ファイル全体をStrict Modeにできない場合に有効です。
function strictFunction() {
"use strict";
// この関数の中だけがStrict Modeになる
let innerVar = "Strict scope";
return innerVar;
}
function sloppyFunction() {
// ここはSloppy Modeのまま
nonDeclaredVar = "Allowed but dangerous";
return nonDeclaredVar;
}現代の開発環境におけるデフォルト設定
2026年現在のモダンな開発環境では、開発者が明示的に "use strict"; と書く機会は減っているかもしれません。
なぜなら、ES Modules（ESM）やClass構文を使用している場合、JavaScriptは自動的にStrict Modeで動作するからです。
| 構成要素 | デフォルトの動作 |
|---|---|
従来のスクリプト (<script>) | Sloppy Mode |
ESモジュール (import/export) | Strict Mode (強制) |
クラス定義 (class {}) | Strict Mode (強制) |
そのため、最新のフレームワーク（React, Vue, Next.jsなど）を利用しているプロジェクトでは、意識せずともStrict Modeの恩恵を受けていることがほとんどです。
Strict Modeによる主な変更点と制約
Strict Modeを有効にすると、具体的にどのような制限がかかるのでしょうか。
主要な変更点を解説します。
1. 未宣言の変数への代入禁止
Sloppy Modeでは、宣言していない変数に値を代入すると、自動的にグローバル変数として定義されてしまいます。
これは意図しないデータの書き換えやメモリリークの原因となります。
"use strict";
function setError() {
// var, let, const を忘れた場合
errorMessage = "An error occurred";
}
setError();出力結果（エラー）：
Uncaught ReferenceError: errorMessage is not definedStrict Modeでは、このように宣言のない変数への代入は即座にエラーとして処理されます。
これにより、単純なスペルミスなどで意図せずグローバル変数を汚染することを防げます。
2. 読み取り専用プロパティへの代入禁止
JavaScriptには、値を変更できないプロパティを持つオブジェクトが存在します。
Sloppy Modeではこれに値を代入しようとしても無視されるだけですが、Strict Modeではエラーがスローされます。
"use strict";
const obj = {};
Object.defineProperty(obj, "readOnlyProp", {
value: 42,
writable: false
});
// 読み取り専用プロパティを上書きしようとする
obj.readOnlyProp = 100;出力結果（エラー）：
Uncaught TypeError: Cannot assign to read only property 'readOnlyProp' of object '#<Object>'3. 削除不可能なプロパティの削除禁止
delete 演算子を用いて、削除できないプロパティ（Object.prototype など）を削除しようとした場合も、同様に厳格なチェックが行われます。
"use strict";
// 組み込みプロパティを削除しようとする
delete Object.prototype;出力結果（エラー）：
Uncaught TypeError: Cannot delete property 'prototype' of function Object() { [native code] }4. 引数名の重複禁止
関数の引数に同じ名前を複数回使用することは、論理的な混乱を招きます。
Strict Modeではこれを構文エラー（SyntaxError）として扱います。
"use strict";
// 引数名が重複している
function sum(a, a, b) {
return a + a + b;
}出力結果（エラー）：
Uncaught SyntaxError: Duplicate parameter name not allowed in this context5. 八進数リテラルの制限
古いJavaScriptの仕様では、0 から始まる数値（例: 010）を八進数として扱っていましたが、これが非常に紛らわしいため、Strict Modeでは禁止されています。
現代的な書き方である 0o10 のような形式を使用する必要があります。
"use strict";
// 以前の八進数表記
let num = 010;出力結果（エラー）：
Uncaught SyntaxError: Octal literals are not allowed in strict mode.this の振る舞いの変化
Strict Modeにおける最も重要な変更点の一つが、関数内における this の値の扱いです。
Sloppy Modeの場合
関数を単独で呼び出したとき、その中の this はデフォルトで「グローバルオブジェクト（ブラウザなら window）」を指します。
function showThis() {
console.log(this);
}
showThis();出力結果（Sloppy Mode）：
Window { ... }Strict Modeの場合
Strict Modeでは、関数呼び出し時の this が明示的に指定されていない場合、undefined になります。
"use strict";
function showThis() {
console.log(this);
}
showThis();出力結果（Strict Mode）：
undefinedこれにより、グローバルオブジェクトを意図せず操作してしまうリスクを完全に排除できます。
特に、コンストラクタ関数を new 演算子を付け忘れて呼び出した際、Sloppy Modeではグローバル変数にプロパティを書き込んでしまいますが、Strict Modeなら即座にエラーで止めてくれます。
eval と arguments の安全性向上
Strict Modeは、JavaScriptの「黒魔術」とも呼ばれる一部の機能についても、安全性を高めるための制約を設けています。
eval の独自スコープ
通常、eval() 内で宣言された変数は、呼び出し元のスコープに影響を与えます。
しかし、Strict Mode下の eval() は、独自のスコープを持つため、周囲の環境を汚染しません。
"use strict";
let x = 10;
eval("var x = 20; console.log('eval内:', x);");
console.log("eval外:", x);eval内: 20
eval外: 10arguments オブジェクトの独立
Sloppy Modeでは、関数の引数とその値を保持する arguments オブジェクトが連動（エイリアス）しています。
一方、Strict Modeではこれらが完全に切り離されます。
"use strict";
function test(a) {
a = 42;
return [a, arguments[0]];
}
console.log(test(10));[42, 10]このように、引数の値を変更しても arguments に反映されないため、コードの挙動を予測しやすくなります。
Strict Modeを採用するメリットの深掘り
ここまで具体的な制約を見てきましたが、これらを守ることで得られるメリットは多岐にわたります。
1. セキュリティの向上
グローバルオブジェクトへの意図しないアクセスを防ぐことは、セキュリティ上のリスク低減に繋がります。
悪意のあるスクリプトがグローバル変数を介して機密情報にアクセスする経路を狭めることができるためです。
2. JavaScriptエンジンの最適化
JavaScriptエンジンは、コードがどのように動作するかを推測してコンパイル（JITコンパイル）を行います。
Strict Modeのように「スコープが明確で、変数の挙動が固定されている」コードは、エンジンの推測コストを下げ、より高速な機械語への変換を可能にします。
3. デバッグコストの削減
「バグがあるのに動いてしまう」状態は、開発者にとって最も厄介です。
Strict Modeによって「問題がある場所で即座にクラッシュする」ようになることで、デバッグの時間は大幅に短縮されます。
現代のJavaScript開発における注意点
2026年という現在のコンテキストにおいて、Strict Modeと向き合う際に知っておくべきアドバイスをまとめます。
連結スクリプトの罠
複数のJavaScriptファイルを1つに結合して配信する場合、注意が必要です。
1つ目のファイルに "use strict"; が書かれており、2つ目のファイルがSloppy Modeを前提とした古いライブラリだった場合、結合後のファイル全体がStrict Modeで解釈され、2つ目のファイルでエラーが発生する可能性があります。
現在ではWebpackやViteなどのビルドツールがこのあたりを適切に処理してくれますが、ライブラリの読み込み順序や結合設定には気を配るべきです。
予約語の回避
将来のJavaScriptでキーワードとして採用される予定の単語（implements, interface, package, private, protected, public, static, yield など）を変数名に使うことは、Strict Modeでは固く禁じられています。
Linter（ESLint）との併用
Strict Modeは実行時のチェックですが、開発時にはESLintなどの静的解析ツールを併用するのがベストプラクティスです。
ESLintの設定で strict ルールを有効にすれば、コードを実行する前にエディタ上で厳格なチェックを行うことができます。
まとめ
JavaScript Strict Modeは、プログラミングの自由度を奪うものではなく、「不確実性」を排除して「品質」を担保するためのツールです。
本記事で解説した以下のポイントを振り返ってみましょう。
- グローバル変数の汚染を防ぎ、宣言漏れをエラーとして報告する。
- this の値を undefined にすることで、オブジェクト操作の安全性を高める。
- ESモジュールやクラスを使用している場合は、デフォルトで有効になっている。
- JavaScriptエンジンの最適化を助け、パフォーマンス向上に寄与する。
「動けば良い」という段階から、「保守しやすく、高速で、安全なコード」を書く段階へとステップアップするために、Strict Modeは欠かせない存在です。
特に大規模なアプリケーション開発やチームでの開発においては、Strict Modeを前提としたコーディング規約を徹底することが、長期的なプロジェクトの成功へと繋がります。
現代のモダンなJavaScript開発においては、もはやStrict Modeは「選択肢」ではなく、「標準的な作法」であると言っても過言ではありません。
もし、まだ古いプロジェクトでSloppy Modeのまま運用されているコードがあれば、少しずつStrict Modeへの移行を検討してみてはいかがでしょうか。
その一歩が、よりプロフェッショナルな開発環境への入り口となるはずです。