【徹底解説】exportとmodule.exportsの違いとは？ESMとCommonJSの世界をやさしく解説

---

exportとmodule.exportsの違いを中学生にもわかるように徹底解説

この記事では export と module.exports の違いを、中学生にも理解できるように、基礎から順番に説明します。いまさら難しい用語を覚えるよりも、なぜこのふたつの仕組みが別物として動くのかを知ることが大切です。エンジニアの世界では、コードを分けて保守しやすくするためにモジュールが使われます。モジュールとは、機能ごとにまとめた部品のようなものです。部品を箱から取り出して使うとき、どの箱から何を取り出すかを指示するのが export の役割です。一方、module.exports はその出口そのものを指します。ESM（export などの新しい仕組み）と CommonJS（module.exports の伝統的な形）は、互換性の問題を引き起こすことがあります。つまり、あなたが今学んでいる内容は、将来 Web ブラウザ、サーバーサイドの Node.js、あるいはスマホのアプリ開発にも関係してくる基本の技術です。これから出てくる用語の意味を、日常の言葉に置き換えながら、1歩ずつ理解していきましょう。
特に覚えておきたいのは、export は「外に公開する入口」を作るものであり、module.exports は「この出口から出て行く中身そのもの」を指すことが多いという点です。実務ではこの違いを意識するだけで、他の人にコードを渡すときの混乱を減らせます。ここから先は、具体的な使い方の違いへと入っていきます。

able> 項目export の特徴module.exports の特徴 意味ESM形式でのエクスポートCommonJS形式のエクスポート 使い方export default または export 名称module.exports に任意の値を代入 互換性ブラウザとサーバー両方で使われることが多い主に Node.js の伝統的な方法 動的・静的静的に解析されることが多い動的に扱えるが require と併用が必要になることがある ble>

セクション1: そもそもモジュールとは何か

モジュールとは、コードを機能ごとに分けて管理する箱のことと考えてください。例えば、計算をする機能、データを整える機能、ネットワークに関する機能などが別々の箱に入っています。箱を作る理由は、再利用性と保守性を高めるためです。ある機能を別ファイルに置くと、他の人がその機能を使うときに迷いにくくなります。export はその箱の中身を外部の人へ見えるようにする出口です。出口を作っておくと、使う人は箱の中身を直接触らず、必要な機能だけを取り出して使えます。module.exports はその出口そのものを指します。たとえば箱に入っているもの全体を丸ごと渡したい場合、この module.exports に詰め替えます。ここまでの考え方を整理すると、export と module.exports は「外に見せる入口」と「実際の中身」の結びつきを決める指示のようなものだと理解できるでしょう。重要なのは、どちらを使っても、最終的にはファイルを読み込む側がどう利用するかを決めている点です。長い目で見ると、ESM と CommonJS の両方を使えるように工夫する場面が増えます。

セクション2: export の使い方とデフォルト/名前付きエクスポート

export には主にデフォルトエクスポートと名前付きエクスポートの考え方があります。デフォルトエクスポートは、1つのファイルで中心になる機能を広く公開したいときに使います。名前付きエクスポートは、複数の機能を別々に公開して、呼び出す側が必要なものだけ選べるようにします。たとえば「計算」と「文字列処理」という2つの機能があるとき、export { calc, formatString } のように公開し、使う側は import { calc, formatString } from './utils' のように取り出します。これによって、コードの可読性と再利用性が高まります。もちろん、ESM としての export の扱いは、 Node.js の設定や環境依存の問題も影響します。例えば package.json に \"type\": \"module\" を追加するなどの設定が必要になることがあります。ここまでの内容を覚えておくと、将来他の人と協力するときにも、どの機能をどの名前でどこから取り出すのかが明確になり、誤解を避けられます。

セクション3: CommonJSと ES Modules の実務的な違いと互換性のコツ

実務では、一部の古いライブラリがまだ CommonJS の形式を使っていたり、ツールチェーンが ES Modules を想定していなかったりすることがあります。そのため、export と module.exports の使い分けだけでなく、互換性の取り方を知っておくことが重要です。例えば、CommonJS を使うファイルから ES Modules のコードを読み込むには、ランタイムの設定や require の挙動に注意が必要です。逆に、ES Modules のファイルから CommonJS の値を取り出す場合、default export と module.exports の取り扱いの差に気をつける必要があります。実務で最も頻繁に使うのは、バージョン間の差やビルドツールの設定、そしてモジュールの読み込み順序の管理です。ここで覚えておきたいのは、互換性を優先する場合は可能な限り統一的な方式を選ぶこと、という点です。もし混乱しているときは、ドキュメントで公式の推奨を確認し、実際に小さなサンプルを作って動かしてみるのが一番です。

ピックアップ解説

小ネタ話題：export という言葉を聞くと難しく感じるかもしれませんが、実はこの考え方はとても身近な場面にも当てはまります。例えば学校の部活動で、先生が新しい道具を“外へ出す窓口”として渡してくれる場面を思い浮かべてみてください。export はその窓口を作る作業、つまり「この道具を外部に公開します」という宣言です。デフォルト export は「このファイルの主役となる機能」を一つだけ公開するイメージ、名前付き export は複数の機能を個別に公開できる機能です。クラスの授業で一人ずつ役割が決まっているときはデフォルト、複数の人が協力して動くときは名前付きが便利です。こうした感覚で考えると、export や import の動きが自然に理解でき、コードの設計を友だちと話すときの“共通言語”になります。

---