コンテンツにスキップ
非エンジニアのためのVibeCoding入門

ライブラリと依存関係のいろは

この章でわかること: AIがコードに加える「ライブラリ」とは何か、なぜ勝手に増えるのか、 そして「なぜか急にビルドが失敗する」の正体。仕組みの地図があれば、止まらずに対処できます。

ライブラリ = 出来合いの部品

Section titled “ライブラリ = 出来合いの部品”

前章のフレームワークが「作りかけの土台キット」だとすれば、 ライブラリは、そこに取り付ける個別の部品です。日付をきれいに整える部品、 グラフを描く部品、カレンダーを出す部品——世界中の開発者が「よくある処理」を あらかじめ作って公開してくれていて、それを借りて使うのがライブラリです。

自分で一から作らずに済むので、開発は一気に速くなります。裏を返すと、 あなたのプロトタイプは他人が作った部品の集まりでできている、ということです。

部品リストと、その実体

Section titled “部品リストと、その実体”

借りている部品は、プロジェクトの中に記録が残ります。用語は軽く知っておけば十分です。

名前正体例えると
package.json「どの部品を、どのバージョンで使うか」を書いた一覧表部品の発注リスト
node_modules実際にダウンロードされた部品の本体が詰まったフォルダ届いた部品の倉庫

package.json は数十行のリスト、node_modules は中身が膨大なので、 「リストを見れば何を借りているか分かる」とだけ覚えておけば大丈夫です。

AIが部品を足すのは、普通のこと

Section titled “AIが部品を足すのは、普通のこと”

「グラフを表示して」と頼むと、AIはグラフ用のライブラリを勝手に追加します。 これはサボりでも暴走でもなく、ごく普通の作り方です。人間の開発者も同じことをします。 なので、見覚えのない部品名が増えていても、それ自体は驚くことではありません。

なぜ更新で急に壊れるのか

Section titled “なぜ更新で急に壊れるのか”

一番つまずくのがここです。「昨日まで動いていたのに、更新したら真っ赤なエラーで ビルドが失敗する」。原因はたいてい次の3つのどれかです。

  • バージョンという「版」がある: 部品には 1.4.2 のような版番号が付いています。 数字が上がるほど新しい版です。
  • 破壊的変更(はかいてきへんこう): 新しい版で、部品の使い方そのものが 作り直されることがあります。蛇口のハンドルが急に別の向きに変わるようなもの。 古い使い方のままのコードは、当然かみ合わなくなります。
  • 部品どうしの相性: 部品Aが「部品Bの古い版じゃないと動かない」のに、 別の都合でBだけ新しくなる——こうした相性のズレでも全体が止まります。

迷ったら、増やさない

Section titled “迷ったら、増やさない”

部品は便利ですが、増えるほど「相性のズレ」や「更新で壊れる」余地も増えます。 プロトタイプ段階では、本当に必要な部品だけにとどめるのが結局いちばん速い、 という感覚を持っておくと安定します。判断に迷ったら、AIにこう聞いてみてください。

  • 「この機能、新しい部品を足さずに実現できない?」
  • 「この部品は有名で、今も更新が続いている?ダウンロード数は多い?」
  • 「代わりになる、もっと定番の部品はある?」

信頼できる部品を選ぶ(セキュリティの一言)

Section titled “信頼できる部品を選ぶ(セキュリティの一言)”

部品は「世界中の誰か」が公開したものです。中には、悪意を仕込んだ偽物や、 放置されて穴が空いたままのものも紛れ込みます。借りた部品の弱点が、そのまま あなたのアプリの弱点になる——これをサプライチェーンの問題と呼びます。

難しく考える必要はありません。「利用実績が多く、更新が続いている、素性のはっきりした 部品を選ぶ」。これだけで大半のリスクは避けられます。ここもAIに素性を確認させるのが近道です。

なぜ大事か

Section titled “なぜ大事か”

「ビルドが失敗した」の多くは、あなたのミスではなく借り物の部品の事情です。 その地図があれば、真っ赤なエラーの前で固まらず、「更新のせいかも」「相性かも」と あたりを付けてAIに頼めます。動くものを壊さない——プロトタイプを商談まで無事に 届けるうえで、これが効いてきます。全体像はWebアプリの全体像や フレームワークと Next.jsとあわせて押さえておくと安心です。

参考リンク(情報ソース)

Section titled “参考リンク(情報ソース)”