AI時代のライブラリファースト開発について語る

Last updated at 2026-08-31Posted at 2026-08-31

本記事では、筆者が実践している「ライブラリファースト」という開発の考え方を紹介する。仕様にもっとも合った言語・ライブラリを選ぶことを、コーディングでもっとも重視する進め方だ。

AIの進歩で、コードそのものは無尽蔵に吐き出されるようになった。しかし「どの言語で書くか」「どのライブラリを使うか」という選択はまだ人間が判断する必要があると考えている。そしてこの選択は、AIが出力するコードの品質にも直結する。

この言語・ライブラリ・AIの関係は、住宅建築に例えるとわかりやすい。

言語は工務店、ライブラリは工法、アプリは家

建築	プログラミング
工務店	プログラミング言語（Python、JavaScript、Rust など）
工法	フレームワーク・ライブラリ（Django、React、Axum など）
家	作りたいアプリ
施主	あなた（人間）
仲介業者	AI

まず施主がどんな家を建てるか（仕様）を決め、それに最適な工務店（プログラミング言語）と工法（ライブラリ・フレームワーク）を選ぶ。AIは指示された工務店で建てる仲介業者だ。

言語もライブラリも、選択は結局コストの話だ。仕様に合ったものを選べば、コード量が減り、型でバグを事前に防げ、保守性も上がる。合わないものを選ぶと、同じものを作るのに余計なコードが増え、その分だけ品質を保つ手間も増える。

家を建てるとき工法選びを重視するように、コードを書くときも工法（フレームワーク・ライブラリ）の選択をもっとも重視する。これが冒頭で触れたライブラリファーストだ。

仕様に合った工法を選ぶと、AIの思考がそれに沿い、考える幅が狭まってコーディングに集中できる。コード量自体も減る。

コードが少なければ、人間のメンテナンスコストが減るだけでなく、AIが把握すべき文脈も減って出力がぶれにくくなる。結果としてアプリの品質が上がる。

AIはプロンプトなしだとありきたりな選択に落ち着く習性がある。さらに言語やライブラリを選ぶ判断軸は多種多様で、用途・パフォーマンス・コード量・保守性・コミュニティの規模・更新頻度など、状況によって優先順位も揺れる。

こうした多様な判断軸を踏まえ、仕様にもっとも合った選択をするのは、まだまだ人間が決めた方がいい。

作りたいもの	言語の候補
Webフロントエンド	JavaScript / TypeScript
Webバックエンド	JavaScript / TypeScript（Node.js）、Python
ターミナルで動くツール	Rust、Go
データ分析・機械学習	Python
ちょっとしたスクリプト	Python（uv）、シェルスクリプト

バックエンドはRust、フロントエンドはJavaScriptのように、役割ごとに別の言語を組み合わせることもある。どこをどの言語に振るかは、用途を理解している人間が決める。

ブラウザで動くWebアプリという家を建てたいとする。JavaScriptがブラウザと相性がよく、さらに型安全にして堅牢にしたいので工務店はその派生のTypeScript。コンポーネントベースでUIを構築したいので工法はReact、というふうになる。

データを集計・可視化するスクリプトという家を建てたいなら、工務店はPython、データ操作を少ないコードで表現したいので工法はpandasとmatplotlib、というふうになる。

Pythonは工法がもっとも豊富な工務店で、用途によって工法を変幻自在に使い分けられる。

ターミナルで画像表示できるツールという家を建てたいなら、速度とメモリ効率が要るので工務店はRust、ターミナルUIと画像描画を扱えるので工法はratatui、というふうになる。

依存ライブラリ込みで1ファイルとして配布できるスクリプトという家を建てたいなら、工務店はPython。工法はuvのshebang機能を使い、依存管理と実行を1ファイルに完結させる、というふうになる。

AI時代の役割分担はこう整理できる。

人間が判断する部分

AIに任せられる部分

土台の選択まで任せて誤ると、用途に合わない言語やライブラリの上で作ることになる。後からの乗り換えでメンテナンスコストが上がる。この土台選びを人間が重視し、仕様にもっとも合った言語・ライブラリを選ぶ。これがライブラリファーストの実践だ。