開発基礎 Study Note：モジュール・パッケージ・依存関係――コードの再利用と構造化のルール

AIにアプリづくりを頼むと、「必要なパッケージを追加します」「モジュールを読み込みます」「依存関係をインストールします」といった言葉が出てきます。

画面を作ってほしいだけなのに、なぜ別のものを追加するのでしょうか。実は、アプリは自分で書いたコードだけでできているとは限りません。誰かが作った部品を取り込み、それらを組み合わせて動かすことがよくあります。

今回は、その仕組みを理解するための3つの言葉、パッケージ・モジュール・依存関係を整理します。JavaScriptやTypeScriptを使ったWebアプリを例に、AIの作業を追えるところまで見ていきましょう。

1. 今回分かるようになること

この記事のゴールは、次の3つです。

• パッケージ・モジュール・依存関係の違いを、一文ずつで説明できる。
• コードをコピーしただけでは動かない理由が分かる。
• AIが部品を追加するとき、何を確認すればよいか分かる。

先に全体像を置くと、こうなります。

パッケージとモジュールは、同じ部品を違う側面から呼ぶこともあります。依存関係は、その部品同士をつなぐ「必要としている」という関係です。

2. パッケージは、取り込んで使える部品のまとまり

たとえば、アプリに日付を見やすく表示する機能を追加するとします。

「2026年10月12日」と表示するだけなら、自分でコードを書けるかもしれません。ただ、曜日を付ける、別の言語に対応する、日付同士を比較する、と機能が増えるほど、考えることも増えていきます。

そこで、日付を扱うための既存の部品を取り込んで使う方法があります。このように、再利用できるコードなどを配布・導入するためにまとめたものが、パッケージです。

料理でいえば、調味料セットを買ってくるイメージです。必要なものを全部自分で作らなくても、用意されたものを使って料理を組み立てられます。

npmの世界では、パッケージはpackage.jsonというファイルで説明されます。名前やバージョン、必要な別のパッケージなどを記載するファイルです。パッケージは公開されたものだけでなく、組織内で共有するものや、自分で作るものもあります。npm公式：パッケージとモジュール

なお、パッケージには画面で使う機能だけでなく、コードの変換やテストを助ける道具も含まれます。AIが「パッケージを追加します」と言ったら、「アプリの機能か、開発のための道具を取り込むのだな」と受け取ればよいでしょう。

3. モジュールは、コードを分けて使う単位

次に、モジュールです。

アプリのコードを全部1つのファイルに書くと、機能が増えたときに読みにくくなります。そこで、「日付の処理」「入力の確認」「画面の表示」のように役割を分け、必要なところから読み込んで使います。その単位がモジュールです。

たとえば、自分で作った日付の処理をdate-utils.jsというファイルに置いたとします。別のファイルから、その中の機能を読み込んで使えます。

import { formatDate } from './date-utils.js';

これは説明用の例です。「同じプロジェクトにあるdate-utils.jsから、formatDateという機能を読み込む」という意味になります。読み込まれる側では、その機能をexportで外に公開しておきます。MDN：JavaScriptモジュール

ここで覚えたいのは、モジュールは、外から買ってきた部品に限らないということです。自分で書いたコードも、役割を分けて読み込める形にすればモジュールになります。

料理のたとえを続けるなら、調味料セットがパッケージで、その中から使うソースなどがモジュールに近いイメージです。ただし、これは理解のためのたとえです。「パッケージは必ず複数のモジュールからできている」と決めつける必要はありません。

パッケージは配布・導入の単位、モジュールはコードを分けて利用する単位。この視点の違いを押さえておけば、会話の中で両方の言葉が出てきても追いやすくなります。

4. 依存関係は、「それが必要」というつながり

では、依存関係とは何でしょうか。

あるアプリが日付処理のパッケージAを使っているなら、そのアプリはAに依存しています。Aがなければ、Aを使う処理を実行できないからです。

さらに、Aの内部で別のパッケージBを使っている場合もあります。

アプリ → 日付処理のパッケージA → 補助機能のパッケージB

矢印は「右側の部品を必要とする」という意味です。AとBは、関係を説明するための架空の名前です。

アプリが直接必要とするAを「直接依存」、Aを通じて必要になるBを「間接依存」または「推移的依存」と呼びます。部品を1つ追加したつもりでも、その部品が必要とする別の部品まで入ることがあるわけです。

料理でも、レシピに「カレーのルー」が必要で、そのルーの製造には複数の材料が必要です。自分が選ぶ部品の裏側に、さらに必要なものがある。このつながりが依存関係です。

そのため、導入したパッケージの数が多く見えても、すべてを自分で選んだとは限りません。npmのような道具は、指定したパッケージと、それに必要なパッケージを導入します。npm公式：npm install

5. コードを読み込むことと、部品を導入することは別

ここが、AIコーディングで特に大切なところです。

コードにimportを書けば、外部のパッケージが自動的にダウンロードされるのでしょうか。

一般的なnpmを使う構成では、そうではありません。importは読み込む指定であり、必要なパッケージをプロジェクトに用意する作業は別にあります。

たとえば、AIが外部パッケージを使うコードを書いたのに、そのパッケージを導入していなければ、読み込み先が見つからずエラーになることがあります。

逆に、パッケージを導入しただけでも、その機能が勝手に画面へ追加されるわけではありません。必要な機能を読み込み、それを使うコードを書く必要があります。

順番としては、次のように考えられます。

1. 必要な機能と、使うパッケージを決める。
2. パッケージをプロジェクトに導入する。
3. コードから必要な機能を読み込む。
4. その機能を使い、動作を確認する。

AIがこの一連の作業をまとめて進めると、画面には完成したコードだけが見えることがあります。それでも、裏側では「部品を用意すること」と「部品を使うこと」の両方が必要です。

6. 依存関係は、どこに記録されるのか

npmを使うプロジェクトでは、次の3つをよく見かけます。

package.jsonには、アプリの実行に必要なものを記すdependenciesと、開発・テストなどに使うものを記すdevDependenciesという区分があります。開発用の道具でも、公開前のビルドで必要になる場合があります。npm公式：依存関係の指定

また、「この部品のこの範囲のバージョンを使いたい」という条件と、「実際にどのバージョンを取りそろえたか」という記録は違います。その再現を助けるのがロックファイルです。npm公式：package-lock.json

通常、アプリのコードと一緒にpackage.jsonやロックファイルをGitで管理し、導入済みの部品は必要な場所で取りそろえます。別のパソコンにソースコードだけを持っていっても、部品の準備が済んでいるとは限らないのです。

具体的にどう取りそろえるかは、次回の「パッケージマネージャー」で扱います。今回は、注文書・明細・部品の実体は別のもの、と分かれば十分です。

7. エラーが出たときは、何が足りないかを見る

アプリが動かないとき、必ずしも自分で書いた処理に誤りがあるとは限りません。必要な部品を読み込めていない場合もあります。

たとえば、次のようなメッセージです。

Module not found
Cannot find module

大まかには「読み込み先のモジュールが見つからない」という意味です。外部パッケージが未導入のこともあれば、自分で作ったファイルの場所や名前を間違えていることもあります。

「モジュールがない」と出たら、すぐに新しいパッケージを入れるのではなく、まず何を読み込もうとしているかを確認します。

• 外部のパッケージなら、必要なものが記録され、導入されているか。
• 自分のファイルなら、ファイルが存在し、指定した場所や大文字・小文字が合っているか。
• 部品は存在するなら、読み込む機能の名前や、使っているバージョンが合っているか。

また、部品同士が要求するバージョンの条件が合わず、導入時に止まることもあります。部品がそろっているだけでなく、組み合わせにも条件があるのです。

AIには、「最初に出たエラーと読み込み先を確認し、未導入・パスの誤り・バージョンの不整合のどれかを切り分けて」と頼むと、確認してほしいことを具体的に伝えられます。

8. AIが部品を追加するときに確認したいこと

パッケージを使うと、必要な機能を全部自作する負担が減ります。一方で、外部の部品をプロジェクトに取り込むことにもなります。

AIが「このパッケージを追加します」と言ったら、まず確認したいのは次の3つです。

1. 何の機能のために必要か。 追加する理由を一文で説明してもらう。
2. 既存の仕組みで対応できないか。 すでに入っている部品や、言語の標準機能で足りるかを確認する。
3. 追加後に何を確認したか。 目的の動作、必要なテスト、ビルドなど、変更に合った確認結果を見せてもらう。

業務で使う場合は、利用する部品のライセンスや保守状況、既知の問題も、組織のルールに沿って確認します。

更新するときも同じです。「新しいバージョンがあるから全部更新する」だけでは、ほかの部品との組み合わせが変わり、動作に影響することがあります。更新の目的と範囲を決め、確認できる単位で進めることが大切です。

全部の部品名を暗記する必要はありません。「何のために入り、何を必要とし、どこまで確認できているか」を追えることが、AIに任せるうえで役立ちます。

9. まとめと理解度確認

パッケージは、配布・導入できるようにまとめた部品の単位。モジュールは、コードを分けて読み込んで使う単位。依存関係は、あるコードや部品が別の部品を必要とするつながりです。

コードが手元にあることと、必要な部品がそろっていることは別です。アプリは、ソースコードと、そのコードが必要とする部品を合わせて動きます。

自分の言葉で説明してみる

1. パッケージとモジュールは、どのような視点の違いがありますか？
2. 自分で書いたファイルも、モジュールになれますか？
3. パッケージを1つ追加したのに、複数の部品が導入されるのはなぜですか？
4. 外部パッケージを使うimportを書けば、そのパッケージも自動で導入されますか？
5. 「Module not found」と出たら、必ず新しいパッケージを導入すれば解決しますか？

解答例

1. パッケージは配布・導入の単位、モジュールはコードを分けて読み込んで使う単位です。同じ部品を違う側面から呼ぶ場合もあります。
2. なれます。自分で書いたコードも、機能を分け、ほかのコードから読み込める形にすればモジュールになります。
3. 追加したパッケージが、内部で別のパッケージを必要とすることがあるからです。その先の部品も、間接依存として導入される場合があります。
4. 一般的なnpmを使う構成では、導入されません。部品をプロジェクトに用意することと、コードから読み込むことは別の作業です。
5. 必ずではありません。自分のファイルの場所や名前の誤りなどでも起こります。何を読み込もうとしているかを先に確認します。

参考資料

• npm公式：パッケージとモジュール
• MDN：JavaScriptモジュール
• npm公式：npm install
• npm公式：依存関係の指定
• npm公式：package-lock.json

資料確認日：2026年10月12日