【比較】モジュールとライブラリの違い

開発で使われる「モジュール」と「ライブラリ」は関連性が高いですが、規模と役割に違いがあります。

概要

モジュールとライブラリは「再利用可能なコード」という点で似ていますが、粒度（スコープ）が違います。モジュールは「コードを機能単位に分割するための部品」で、JavaScript では概念的に多くの場合1つのファイルに対応します（MDN も「複雑なプロジェクトには JavaScript を別々のモジュールに分割し必要に応じて import する仕組みが要る」と説明）。一方ライブラリは、その部品を特定の目的のために束ねた再利用可能なコードの集合体で、開発者が「道具」として呼び出して使います（呼び出して制御が戻る＝ライブラリの性質。Martin Fowler のライブラリ定義に整合）。簡単に言えば、モジュールが集まってライブラリになるという包含関係です。

例えるなら：部品と道具箱

• モジュール … ネジ・ドライバーの先端ビットのような「単機能の部品」。1つでは小さな役割しか持たないが、組み合わせの最小単位。
• ライブラリ … それらの部品を「ある目的（例：HTTP 通信、データ分析）」のために整理して詰めた道具箱。開いて必要な道具を取り出して使う。

詳細比較

観点	モジュール (Module)	ライブラリ (Library)
単位	コードの「部品」	部品をまとめた「道具箱」
粒度	小さい（概念的に単一ファイルが基本）	大きい（複数モジュール／関数で構成）
目的	コードを機能単位に分割し見通しと再利用性を上げる	特定目的の汎用ツールセットを提供する
関係	ライブラリはモジュールの集まり	モジュールはライブラリの構成要素
使われ方	import/export で他から取り込む	開発者が呼び出して使う（制御は開発者側）
例	自作 utils.py、ES Module の math.js	Pandas / NumPy / Requests、jQuery / Lodash

モジュール (Module)

• 概要: 特定の機能や責務を持つコードの集まりで、JavaScript では概念的に多くの場合単一のファイルに対応します（MDN の ES Modules ガイドも各ファイルを1つのモジュールとして扱い、export/import で連携する例を示す）。なお shapes.js が複数の子モジュールを再エクスポートするように、モジュール構成は import/export を介して複数ファイルにまたがって階層化することもできます。
• 目的: コードを機能単位で分割し、再利用しやすくするために使います。プログラムの構造を整理し、見通しを良くする効果があります。
• 例:
  • Pythonで自作した utils.py というファイル。
  • JavaScriptの ES Module として作成された math.js ファイル。

ライブラリ (Library)

• 概要: 複数のモジュールや便利な関数をまとめた、再利用可能なコードの集合体です。
• 目的: 特定の目的（例: 画像処理、HTTP通信、数値計算）を達成するための、汎用的なツールセットとして提供されます。開発者はライブラリを利用することで、複雑な機能を自分で実装する手間を省けます。
• 特徴: アプリケーションの処理の流れ（主導権）は開発者側にあり、ライブラリは必要に応じて「道具」として呼び出して使います（呼び出すと仕事をして制御が開発者側に戻る。これがフレームワークとの違い）。
• 例:
  • Python: Pandas, NumPy (データ分析), Requests (HTTP通信)
  • JavaScript: jQuery (DOM操作), Lodash (ユーティリティ)

よくある誤解

• 誤解1：「モジュールとライブラリは同じ意味」 — 誤りです。両者は粒度が違います。モジュールは機能分割の最小単位の部品、ライブラリはそれらを特定目的に束ねた集合体で、モジュールはライブラリの構成要素という包含関係にあります。
• 誤解2：「1モジュール＝必ず1ファイルで、絶対に複数ファイルにまたがらない」 — 言い過ぎです。JavaScript では概念的に1ファイル＝1モジュールが基本ですが、MDN が示すように親モジュールが複数の子モジュールを再エクスポートして階層化でき、モジュール構成は import/export を介して複数ファイルにまたがれます。「概念単位は1ファイル相当」が正確な理解です。
• 誤解3：「ライブラリの方がモジュールより“高機能”で優れている」 — 比較の軸を取り違えています。両者は優劣ではなく粒度・役割の違いです。自作モジュールを束ねれば自分のライブラリにもなり、ライブラリの中身は結局モジュールの集まりです。
• 誤解4：「ライブラリとフレームワークは同義」 — 誤りです。ライブラリは開発者が呼び出して制御が戻る（主導権は開発者）。フレームワークは制御が反転し、フレームワークが開発者のコードを呼びます。モジュールはこの軸とは独立した「コード分割の単位」です。

実務での選び分け

• 自分のコードを整理・分割したい（見通し・再利用・テスト容易性） → モジュール化。責務ごとにファイルを分け export/import でつなぐ。
• 特定目的の汎用処理を自前実装せず済ませたい → 既存ライブラリを導入して呼び出す。
• 自作の汎用処理が増え、他プロジェクトでも使い回したい → 関連モジュールを束ねて自作ライブラリ／パッケージとして切り出す（モジュール→ライブラリへの自然な発展）。
• 判断軸：①「コードをどう分けるか」はモジュールの問題、②「既製の道具を借りるか」はライブラリの問題。レイヤーが違うので二者択一ではなく、ライブラリを使いつつ自分のコードはモジュール分割する、が通常。

ひとことまとめ

モジュールは機能分割の最小単位の部品（概念的に多くは1ファイル）、ライブラリはそれを特定目的に束ねた道具箱。モジュールが集まってライブラリになる、という粒度の違いです。

出典・参考

• MDN「JavaScript modules（ガイド）」（複雑なプロジェクトは JavaScript を別々のモジュールに分割し必要時に import する仕組みが必要。各ファイルを1モジュールとして export/import で連携し、親モジュールが子モジュールを再エクスポートして階層化できる）: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
• Martin Fowler「Inversion of Control」（ライブラリは呼び出せる関数の集合で、各呼び出しが仕事をして制御を呼び出し側に返す＝主導権は開発者側、というライブラリの性質の根拠）: https://martinfowler.com/bliki/InversionOfControl.html