【JavaScript】use strictとは？メリットや使い方を初心者向けにわかりやすく解説

はじめに

JavaScriptでプログラミングを進めていると、コードの先頭や関数の冒頭に 'use strict'; と書かれていることがあります。
これはstrictモードと呼ばれる書き方で、記述ルールがより厳しくなる仕組みです。
自分が書いたコードのミスを見つけやすくしたり、実行時のエラーを早期に発見しやすくする効果があります。
とくに初心者の方にとっては誤りに気づきやすくなるメリットが大きいので、この仕組みを理解しておくと開発中に感じる不安やトラブルを減らせるでしょう。

ここでは、javascript use strict について、できるだけシンプルに解説します。
実際の開発現場でどんなシーンで活用しやすいのか、どのように書くのが良いのかなど、なるべく具体例を交えて紹介していきます。

この記事を読むとわかること

• use strictとは何か
• 厳格モードが持つメリットやデメリット
• プログラミングの実務に役立つ使い方
• エラーを見つけやすくする具体的な事例
• 通常モードとの違いを比較するコード例

use strictを使う目的とその背景

strictモードは、JavaScriptのコードをより厳密に解釈してくれます。
通常モードでは見逃していたようなエラーや潜在的なバグを、実行時にきちんと警告やエラーとして通知してくれるのが大きな特徴です。

たとえば、変数の宣言漏れや、同じ名前の引数を重複して定義してしまうといったミスがあった場合、strictモードであればエラーとしてすぐに気づけます。
これは大規模な開発現場だけでなく、初心者が学習を始めるときにも大いに役立ちます。
何が問題なのかすぐに分かるため、「なぜ動かないのか分からない…」といった時間のロスが減るでしょう。

一方で、「そもそもなぜ、JavaScriptではこうした厳格モードをわざわざ書かないといけないのか？」と疑問に思う方もいるのではないでしょうか。
それはJavaScriptが誕生してからの歴史的経緯があり、後方互換性を大切にしてきた背景があります。
レガシーコードに影響を与えずにモダンな書き方を取り入れるため、あえて 'use strict'; を記述して厳格モードに切り替える設計を取っています。

少し前までは、プロジェクトによってstrictモードを使うかどうかはバラバラでした。
しかし現在では、コーディング品質を高めるためにstrictモードを推奨する方針が一般的になっています。

strictモードと通常モードの違い

strictモードと通常モードの違いは、エラーチェックや変数の扱いが大きなポイントです。
ここでは、いくつかの主要な挙動を取り上げて比較します。

変数宣言漏れをエラーにする

通常モードでは、宣言していない変数に値を代入してしまっても暗黙的に変数が作られ、エラーになりません。
これが原因でグローバルオブジェクトへの意図しない代入が発生し、思わぬ不具合の引き金になることがあります。

コピー
// 通常モード
myValue = 10; 
console.log(myValue); // 10と表示されるが、本来は宣言していない変数なので危険

一方でstrictモードを有効にすると、明示的に宣言していない変数に代入するとエラーを出してくれます。

コピー
'use strict';
myValue = 10; // エラーになる
console.log(myValue);

このように、プログラミング初心者がやりがちな変数の宣言忘れをすぐに発見できるため、コード品質が高まりやすくなります。

重複する引数名を禁止

JavaScriptでは、通常モードの場合、関数の引数に同じ名前をうっかり書いてしまっても実行時にはエラーになりません。
しかしstrictモードではエラーとして扱われます。
同じ引数名があると可読性が下がり、値を混乱しやすいので、厳格モードの恩恵を強く感じる場面の一つです。

コピー
function sample(a, a) {
  return a;
}

console.log(sample(1, 2)); 
// 通常モードだとエラーにならず、結果は2
// strictモードだとエラーとなる

このように、予期せぬバグを生む書き方を根本的に防ぐのがstrictモードの狙いです。

use strictの基本的な書き方

strictモードを使うには、スクリプト全体か、あるいは関数ごとに指定します。
最もよく見かけるのは、ファイルの先頭に 'use strict'; を置く方法です。
これにより、そのファイル内で記述されるすべてのJavaScriptコードがstrictモードで解釈されます。

コピー
'use strict';

const x = 5;
function calc() {
  // この関数内もstrictモード
  return x * 2;
}

console.log(calc());

一方で、特定の関数の中だけstrictモードにしたい場合は、その関数の先頭に 'use strict'; を書きます。

コピー
function myFunc() {
  'use strict';
  // この関数だけstrictモード
  y = 10; // エラーになる
}

ただし、一般的にはファイル全体をstrictモードにするケースが多いです。
部分的にstrictを使うと、ほかの関数では通常モードのままになり、挙動に一貫性がなくなるため注意が必要です。

開発現場での活用シーン

strictモードはコード全体を安全にするために使われますが、そのメリットが特に大きく感じられるのは複数人でのプロジェクト開発や長期間メンテナンスが続くプロジェクトです。
たとえば、小さなスクリプトなら変数の宣言ミスをすぐ見つけられるかもしれませんが、数千行にもわたる大規模なコードベースでは簡単に見落としてしまいます。

また、複数のエンジニアが共同で作業している場合、「誰かが一部の変数をグローバルにしてしまい、意図せず別のファイルから参照されてバグが発生した」というような事態が起きがちです。
strictモードであれば、こういったミスがエラーとして即座に指摘されるため、原因を特定しやすくなります。
結果として、開発効率を保ちながら品質を高めることにつながります。

さらに、チームの中にプログラミング初心者がいる場合も、strictモードを有効にすることでルールを守っていないコードに気づきやすくなります。
レビュー担当者の負担も減り、「コーディングルールが守られているかを自動的にチェックできる」というメリットもあります。

エラーを早期に発見する具体例

ここでは、通常モードなら見逃されがちなミスがstrictモードでエラーになる例をもう少し詳しく見ていきましょう。

誤った代入先

意図せず、定数や読み取り専用のプロパティに値を代入してしまった場合、通常モードでは警告なく黙って無視されてしまうことがあります。
strictモードでは、これをしっかりとエラーとして扱います。

コピー
'use strict';

// 読み取り専用のプロパティの例
Object.defineProperty(window, 'myProp', {
  value: 100,
  writable: false
});

myProp = 200; // strictモードでエラー

現場の開発では、ライブラリやフレームワークが提供する定義済みの定数を誤って上書きしてしまうケースがあるかもしれません。
strictモードはそんな失敗をすぐに教えてくれます。

thisの値に関する扱い

通常モードで関数を呼び出したとき、this が undefined になるはずの場面で window (ブラウザの場合) やグローバルオブジェクトを指してしまうことがあります。
これもバグを生みやすい原因ですが、strictモードなら undefined を返す仕様になり、不要なグローバル汚染を防ぎます。

コピー
function showThis() {
  console.log(this);
}

// 通常モードだとwindowが表示されることがある
// strictモードだとundefined
showThis();

thisの扱いに関しては、オブジェクト指向的にJavaScriptを使う場合にとても重要です。
意図しないthisの参照ミスを防ぐためにも、strictモードは大きく貢献します。

メリットとデメリット

strictモードには多くのメリットがありますが、一部で注意点もあります。
ここでは代表的なメリット・デメリットを整理します。

メリット

エラーを早期に発見できる

変数宣言漏れや定数の上書きなどのミスが即エラーになるため、原因特定が楽になります。

保守性が高まる

チーム開発でのヒューマンエラーを抑え、後からコードを読む人にも優しい状態にします。

グローバルスコープ汚染を防ぐ

無意識にグローバル変数を作ってしまう危険が少なくなります。

厳格な書き方の習慣がつく

最初からstrictモードに慣れておくと、書き方そのものが整然としやすくなります。

デメリット

古いコードとの混在

過去に書かれたコードがたくさんあるプロジェクトで、部分的にstrictモードを導入すると挙動が混ざって混乱する可能性があります。

一部の柔軟性を失う

そもそもゆるい記述が許されていたために動いていたコードがエラーとなり、修正が必要な場合があります。

初心者の方にとっては、strictモードのデメリットよりもメリットの方が大きいと言えるでしょう。
多少手間がかかったとしても、バグの早期発見につながる点は魅力的です。

実際の開発ワークフローでの使い方

では、具体的にどのような流れでstrictモードを使うのかを考えてみましょう。
多くのプロジェクトでは、最初に新しいファイルを作るときに 'use strict'; を書くというルールを決めます。
チームメンバーが新たにファイルを作成するときは、その冒頭に 'use strict'; を加えるだけなので、運用もシンプルです。

そして、既存のファイルにも徐々にstrictモードを導入したい場合は、まずはテストコードやユニットテストをしっかり整備しておくことが大切です。
strictモードを導入してエラーが出た場合、ユニットテストの結果でどこがエラーを起こしたかがすぐにわかるからです。
このようにして、ひとつずつstrictモードに切り替えていくと、大きな混乱を防ぎながら移行できます。

エラーを活かすためのポイント

strictモードにしただけで安心してしまうと、「エラーが出ているのに放置される」状況になりかねません。
エラーメッセージを見ても、初心者の方は最初戸惑うかもしれませんが、これをしっかりと確認して原因を特定する習慣をつけることが大切です。

コードレビューやリンターの活用

チーム開発の場合、コードレビューを通じてstrictモードのエラーがどのように発生しているか確認しやすくなります。
また、ESLintなどのツールを設定すると、strictモードが有効な前提でルールを厳しくしてくれることもあります。

こういったツールを導入しておけば、strictモードでエラーが起きそうな記述を事前に検知して、エディタ上で警告を表示してくれます。
結果として、コンソールでエラーを確認する前にバグに気づけるため、開発スピードも落ちにくいでしょう。

根本原因を理解する

strictモードで発生したエラーの原因を理解せずに、ただ対処療法的に修正してしまうと、同じミスを別の箇所で繰り返す可能性があります。
エラーメッセージには何が書いてあるのか、なぜ通常モードだと通っていた記述がstrictモードでエラーになるのかを意識的に学ぶ姿勢が大切です。
この「なぜ？」を掘り下げる経験が、JavaScriptの言語仕様を深く理解するきっかけになります。

実装例：strictモードと通常モードの挙動比較

ここでは、同じ関数をstrictモードと通常モードで実行してみる簡単な例を挙げます。

コピー
// 通常モードの関数
function normalMode() {
  sampleVar = 50; // 変数を宣言せずに代入している
  console.log("normalMode:", sampleVar);
}

// strictモードの関数
function strictMode() {
  'use strict';
  anotherVar = 100; // 変数を宣言していない
  console.log("strictMode:", anotherVar);
}

normalMode();  // エラーにならず、"normalMode: 50"と表示
strictMode();  // エラーを出す

実行環境によっては少し挙動が異なる場合もありますが、基本的には通常モードで「変数宣言がない状態」でも通ってしまうコードが、strictモードではエラーとして止まります。
こうした挙動の違いを理解しておくと、コードの書き方が段階的に洗練されるでしょう。

よくある疑問やトラブルシューティング

初心者の方からよく聞かれる疑問や、実際に遭遇しやすいトラブルをまとめてみます。

「use strictを書いたら動かなくなった」

最も多いのがこれです。
strictモードを導入すると、今まで許されていた書き方がエラーになるため、「急に動かなくなった」と驚くかもしれません。
しかし、これはコードに潜んでいた問題を正しく指摘している証拠です。
まずはエラーメッセージを確認し、何が原因かを一つひとつ潰していきましょう。

「部分的にstrictモードにするとエラーが出るところがある」

ファイル全体をstrictにするのではなく、特定の関数だけstrictにする書き方を選んだ場合、予想外の場所でエラーになることがあります。
たとえば、外部のライブラリや他ファイルとのやり取りが複雑だと、両モードが混ざることで問題が顕在化するケースがあります。
この場合は、なるべくファイル単位でstrictモードを有効にする方法に切り替えた方が良いでしょう。

「モジュールファイルなら自動でstrictにならない？」

モジュールとして読み込んだJavaScriptファイル（<script type="module"> など）は、基本的にstrictモードが適用される仕様になっています。
そのため、モジュールを使う形で開発している場合は改めて 'use strict'; を書かなくても、ほぼ同様の効果が得られます。
ただし環境によっては、明示的に書いておくことで混乱を避けられる場合もあるので、プロジェクトのポリシーに従うと良いでしょう。

スクリプト全体か関数単位か？選択する基準

strictモードは、スクリプト全体に適用するか、関数単位に適用するかを選べます。
結論から言えば、スクリプト全体に適用するのがほとんどのケースで推奨されます。
理由としては、次のような点が挙げられます。

1. 可読性が高まる

コードのどこからどこまでがstrictモードかを把握するために、関数単位よりもファイル単位の方が単純です。

2. 一貫したルールが保てる

部分的に通常モードが混じると、エラーが出るところと出ないところが入り交じり、混乱しやすくなります。

3. チームメンバーに周知しやすい

「新たに追加するファイルは冒頭に 'use strict'; を付けてください」といった運用ルールが定めやすいです。

ただし、レガシーコードを一気にstrictモードにするのが難しい場合は、一部の機能だけ関数単位でstrictを適用することもあります。
この場合は後から全体に広げやすいように、プロジェクト全体の方針を明確にしておくことが大切です。

テストコード作成時の注意点

strictモードを導入したら、テストコードの書き方にも少し気を配る必要があります。
テスト自体もstrictモードで動かす方が、実際の本番コードと同じ条件でチェックができるからです。
もしテストファイルがstrictモードでないのに、本番コードはstrictモードだった場合、テストでは問題なく通るのに、本番環境ではエラーになるというギャップが生じるかもしれません。

そこで、テスト環境でも 'use strict'; を明示的に書いておくか、あるいはテストランナーの設定でstrictモードが有効になるようにしておきます。
こうしておけば、本番と同じ条件でテストを実行できるため、テストがより信頼性の高いものになります。

まとめ

JavaScriptで 'use strict'; を使うことで、コードを厳格なモードで動かせます。
これにより、変数の宣言漏れや無意識なグローバル汚染、重複した引数の定義といったバグのもとになる書き方を早期にエラーとして発見できます。
特にプログラミング初心者にとっては、このエラー表示が重要な気づきのきっかけとなり、学習効率を高めるでしょう。

ファイルの冒頭に 'use strict'; と書くだけで、あとは通常通りJavaScriptを書けばOKです。
チーム開発や長期間の保守が見込まれるプロジェクトであれば、最初からstrictモードを徹底する運用が多く選択されています。
一方で、既存のコードベースに適用する際は、テストコードを整備しながら徐々に適用すると混乱を減らせます。

ぜひこの機会に、javascript use strict の仕組みを理解して、実際に試してみてください。
エラーが発生したときはなぜそれがエラーになるのかを一つずつ確認し、JavaScriptの言語仕様を着実に学んでいくと、開発でのトラブルがぐっと減るはずです。