自分のファイルから、世界のコードへ
F-07で見たimportとexportは、あくまで自分が書いたファイル同士のつながりでした。しかし現実のアプリでは、日付の計算やファイルの読み込みといった機能を、一から自分で書くことはほとんどありません。すでに世界の誰かが書いて公開してくれたコードを、部品として借りてくるのが普通です。その借り先と仕組みが、この講義で学ぶnpmです。
このスライドのポイント
- F-07: importとexportは「自分が書いたファイル同士」のつながり
- 現実のアプリでは、日付計算やファイル読み込みを一から自作しないことが多い
- すでに世界の誰かが書いて公開したコードを、部品として借りてくる
- その借り先と仕組みが、この講義で学ぶnpm
3つの用語を定義する
用語を3つ定義します。パッケージとは、配布用にまとめられた他人のコードのことです。たとえば日付を扱うパッケージや、表計算ファイルを読むパッケージがあります。npmとは、そうしたパッケージを登録し、取得し、更新するための仕組みと道具で、Node.jsに付属しています。依存関係とは、自分のプロジェクトがどのパッケージに頼っているかという関係のことです。そしてパッケージ自身もまた別のパッケージに頼っていて、その関係は連鎖していきます。
このスライドのポイント
- パッケージ＝配布用にまとめられた他人のコード（例: 日付を扱うパッケージ、表計算ファイルを読むパッケージ）
- npm＝パッケージを登録・取得・更新するための仕組みと道具（Node.jsに付属）
- 依存関係＝自分のプロジェクトがどのパッケージに頼っているかの関係
- パッケージ自身も別のパッケージに頼り、連鎖していく
なぜ知る必要があるか
この仕組みを知らないと、AIが「◯◯を入れましょう」と提案したときに、その意味がわかりません。入れるとは、そのコードを自分のプロジェクトへ取り込むことです。さらに、取り込んだパッケージが別のパッケージを芋づる式に連れてくるため、自分では選んでいない大量の他人のコードが混ざります。その連鎖の中に不具合や悪意あるコードが潜むリスク、詳細はカテゴリQで扱いますが、それを想像できないまま安易に取り込んでしまいます。
このスライドのポイント
- AIの「◯◯を入れましょう」の意味がわからない（入れる＝プロジェクトへの取り込み）
- 取り込んだパッケージが別のパッケージを芋づる式に連れてくる
- 自分で選んでいない大量の他人のコードが混ざる
- その連鎖に不具合や悪意あるコードが潜むリスク（詳細はカテゴリQ）を想像できない
依存はピラミッド状に広がる
取り込みの構造を図で整理します。いちばん上に自分のアプリがあります。その下に、自分で選んで入れた直接依存のパッケージが数個並びます。さらにその下には、それらのパッケージが必要とする間接依存が芋づる式に広がり、数百に及ぶこともあります。つまり、目に見えて入れたのは一個でも、その下には見えない大量の依存がぶら下がっているのです。
このスライドのポイント
- いちばん上: 自分のアプリ
- その下: 自分で選んで入れた直接依存（数個）
- さらに下: それらが必要とする間接依存が芋づる式に広がる（数百に及ぶことも）
- 目に見えて入れたのは1個でも、その下に見えない大量の依存がぶら下がる
便利さとリスクはセットで入る
具体例で考えます。日付の処理を一から自分で書くのは、うるう年や時差まで含めるととても大変です。パッケージを使えば、たった一行の取り込みで済みます。これが便利さです。ただし、そのパッケージがある日更新されなくなったり、問題を含んでいたりするリスクも、便利さと一緒に取り込んでいます。借りる相手を信用する、という判断が常について回ります。
このスライドのポイント
- 日付処理を一から自作するのは大変（うるう年・時差なども）
- パッケージなら1行の取り込みで済む＝便利さ
- そのパッケージが更新されなくなる・問題を含むリスクも一緒に取り込む
- 借りる相手を信用する、という判断が常につく
技術サンプル: 依存の連鎖
サンプルは依存の広がりを表した図です。自分のアプリの下に、自分で入れた日付パッケージがぶら下がり、そのさらに下に、勝手についてくる文字整形パッケージなどの間接依存が続きます。読み方の要点は二つです。依存は連鎖するということ、そして便利さと、他人のコードを信じるリスクは必ずセットだということです。AIへの質問例としては、このパッケージを追加する理由と、追加せず自作した場合の手間を比較してください、と尋ねます。
このスライドのポイント
- 種別: diagram
- 目的: 「1個入れる」とその下の連鎖ごと取り込むことを可視化する
- サンプル本体:
混同しやすい概念
混同しやすいのは、F-07で学んだ自分のモジュールと、この講義のパッケージです。どちらもimportで取り込むため、コードの見た目はよく似ています。しかし、自分のモジュールはプロジェクトの中で自分が書いたものであるのに対し、パッケージは外部から取得した他人のコードです。出どころが違えば、責任の持ち方も変わります。
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIがパッケージの追加を提案してきたら、そのまま受け入れず、本当に必要か、広く使われているか、最終更新はいつかを確認させてください。安易な追加は依存を増やし、A-09で学んだ中リスクの変更にあたります。質問例としては、この機能はパッケージを追加せずに実現できますか、と一度立ち止まって聞くのが有効です。
このスライドのポイント
- AIがパッケージ追加を提案したら、そのまま受け入れない
- 確認させること: 本当に必要か／広く使われているか／最終更新はいつか
- 安易な追加は依存を増やす＝A-09の中リスク変更にあたる
- 質問例: 「この機能はパッケージを追加せずに実現できますか」
まとめと次回
最後に一問一答です。パッケージが依存するパッケージも一緒に取り込まれることを、何と呼ぶでしょうか。（間）答えは、依存関係の連鎖、つまり間接依存です。三十秒でまとめます。npmは他人のコードを部品として取り込む仕組みで、一個入れるとその下の依存ごと取り込まれます。便利さとリスクは常にセットで、追加は慎重に判断します。次回は、その依存を記録しておく台帳、package.jsonへ進みます。関連資料は「環境変数・APIキー管理入門」と「AI開発ツール比較表」です。
このスライドのポイント
- 一問一答: 「パッケージが依存するパッケージも取り込まれることを何と呼ぶ？」→依存関係（の連鎖・間接依存）
- 30秒まとめ: npmは他人のコードを部品として取り込む仕組み／1個入れると下の依存ごと入る／便利さとリスクはセット
- 次回: 依存を記録する台帳、package.jsonへ
- 関連資料: 「環境変数・APIキー管理入門」「AI開発ツール比較表」
