Skip to content
Published on

2026年に避けるべきツールとトレンド — アンチ推薦のキュレーション、そして代替案

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

この記事は「使うな」という否定の文章ではない。良かった時代を認めたうえで、2026年時点でもう新規プロジェクトには勧めないツールと、その席を埋めるべきより良い選択肢を一対一でまとめたキュレーションだ。正解ではなく意見だが、根拠のある意見である。

プロローグ — なぜアンチ推薦が必要か

良いツールを紹介する記事は山ほどある。一方で 離れるべきツール を教えてくれる記事は少ない。理由は二つある。第一に、誰かの思い出と動いている成果物を批判するのは人気がない。第二に、ツールは真空に存在しないので「これは悪い」という断言はほぼ必ず部分的にしか正しくない。

それでも誰かはこの記事を書かなければいけない。2026 年の新人が検索して最初に出会うチュートリアルが 2018 年で止まっており、そのチュートリアルが推すツールの半分はもう保守されていないからだ。新規プロジェクトをそのまま始めれば、最初の週にビルドが壊れ、最初の月にセキュリティ勧告がたまり、最初の四半期に移行コストが請求される。

この記事の前提は単純だ。

  1. すべてのツールは、ある時点では正しかった。 批判はその時点を否定しない。
  2. 時間が経つとコストが逆転する。 「このツールがやってくれること」より「このツールが妨げていること」のほうが大きくなる。
  3. 代案のない批判は怠惰だ。 だから項目ごとに代替案を必ず併記する。
  4. 代替案も永遠ではない。 一年後にはこの記事の半分は書き直しが必要になる。

最後の前提が大事だ。絶対的な真理ではなく 「今、新規プロジェクトを始めるなら、どこから始めないか」 くらいの案内として読んでほしい。

1章 · 一目で分かるマトリクス — AVOID / INSTEAD

本文に入る前に、まず全体地図を広げる。

カテゴリAVOIDINSTEAD一行理由
フロントエンド初期化Create React AppVite / Next.js / TanStack StartCRA は 2023 年に公式に推奨外、2025 年に実質終了
日付処理Moment.jsdate-fns / Day.js / TemporalMoment チーム自身が「レガシー」と宣言
ユーティリティlodash 全インポート標準 ES / 関数別 / Bun ビルトインTree-shaking 損失、標準が追いついた
Node パッケージ管理Yarn 1pnpm / Bun / Yarn 4Yarn 1 はもう更新されない
バンドラ素の Webpack / Gulp 単体Vite / Rspack / Turbopack / Bunコールドスタートと HMR が一桁ミリ秒の時代
モノレポYarn Workspaces 単体pnpm + Turborepo / Nxキャッシュと影響分析が標準になった
Python ツール導入apt-get install pythonuv / pipx / miseシステム Python の汚染を避ける
Python 依存pip install -r requirements.txt 単体uv / Poetry / Hatchロックファイルと並列インストール
AI 評価Open LLM LeaderboardLMArena / Artificial Analysis2024 年 6 月にアーカイブ化
LLM 統合LangChain <v0.2 の深いインポート分割された langchain-* / LlamaIndex / 公式 SDK 直叩き深いパスそのものが変わった
プロンプト「あなたは専門家です」系の前置きシステムプロンプト + 仕様 + 評価モデルが賢くなって効用が消えた
観測AppDynamics / 重量級 APMOpenTelemetry + Grafana / Tempo標準仕様、ベンダーロックインを回避
ログ収集自前フォワーダ + 自前フォーマットOTel collector + 構造化 JSON標準は梃子になる
CITravis CI(OSS 無料時代終了)GitHub Actions / GitLab CI / BuildkiteTravis の OSS 無料枠が終わった
コンテナビルドDocker Hub 無認証 pull に依存自社ミラー / ECR / GHCR / キャッシュpull 制限がビルド SLA を壊す
シークレット.env をコミット、平文共有SOPS / Doppler / Vault / SealedSecrets事故原因第 1 位
エディタVS Code「とりあえず全部入れる」拡張機能ダイエットサプライチェーンと性能を同時に害する
協業「レビューなしで main 直 push」短い PR + 速いレビュー + マージキューレビューしない組織は学習が止まる

表は長いが意図がある。項目そのものではなく、ペアを覚えてほしい からだ。「Moment 使わない」ではなく「Moment の代わりに date-fns/Temporal」がワンセット。

2章 · フロントエンド — CRA、Moment、lodash 全インポート

2.1 Create React App

何が問題か。 Create React App は 2016 年に Facebook が公開した React 初期化ツールだ。一行コマンドで依存関係とビルド設定を抽象化し、学習導入のハードルを大きく下げた。しかし 2022 年以降ほぼメンテナンスが止まり、2023 年 3 月に React 公式ドキュメントが「新規アプリには非推奨」と明記、2025 年には React チーム自身が引退告知を出した。Webpack 4 ベースのビルドはコールドスタートが数十秒から数分、依存セキュリティ勧告が積み上がり、新しい React 機能との統合経路はもう CRA を通らない。

それでも使われる理由。 検索結果がそこへ連れて行く。2018-2022 年のチュートリアルが上位に居座り、社内資料も同じ年代で止まっている。新人はその道をそのまま辿る。

代わりに使うべきもの。

  • 単一ページアプリ: Vite + React。コールドスタート 1 秒以下、HMR は即座。
  • フルスタック/ルーティング/サーバーコンポーネント: Next.js。事実上の React メタフレームワーク。
  • ルーティング優先の SPA に近いフルスタック: TanStack Start。型安全なルーターとデータローディング。

良かった点。 CRA は「一コマンドで React を始める」という体験を最初に定義した。後続ツールの「使い始めやすさ」はすべてその遺産だ。

2.2 Moment.js

何が問題か。 Moment は一時 JavaScript 日付処理の標準だった。しかしミュータブルなオブジェクトモデル、肥大化したバンドル、ロケールデータ全部入り、tree-shaking 不適合 — これらすべてが現代フロントエンドの価値観と衝突する。決定的なのは Moment チーム自身が 2020 年 9 月に「レガシープロジェクト」と公式宣言した ことだ。新規コードには勧めないし、新機能追加もしないという発表である。

それでも使われる理由。 すでに全コードに埋め込まれている。そして代替が多すぎて決定麻痺になる。

代わりに使うべきもの。

  • date-fns: 関数型、tree-shake 可能、互換性が広い。フォーマット/計算中心ならデフォルト。
  • Day.js: Moment と API 互換志向。移行コスト最小。
  • Temporal: ECMAScript 標準化が進行中。ポリフィルで先取り可能。長期的にはここに収束する。
  • Luxon: Moment 開発者が作った後継。意見が強めの API。

良かった点。 Moment がなかったら、JavaScript の貧弱な Date API の上で 10 年間何をやっても悲惨だった。標準が追いつくまでの時間を稼いでくれたライブラリだ。

2.3 lodash 全インポート

何が問題か。 import _ from 'lodash' は全関数をバンドルに引き込む。2026 年の標準 ES は Array.prototype.at、structuredClone、Object.groupBy、Array.fromAsync、Promise.any、Promise.allSettled、String.prototype.replaceAll、optional chaining、nullish coalescing で lodash の半分を吸収済み。lodash 自体も 2021 年の 4.17.21 以降、事実上大きな更新がない。

それでも使われる理由。 古いコードと古い指の癖。_.get、_.pick、_.debounce は手に馴染んでいる。

代わりに使うべきもの。

  • 可能な限り標準 ES。_.map → .map、_.filter → .filter、_.find → .find。
  • 深いアクセスは optional chaining と nullish coalescing。
  • それでも lodash が必要なら lodash-es から個別に: import { debounce } from 'lodash-es'。
  • ランタイムが Bun ならビルトインを先に確認する。

良かった点。 lodash のドキュメントは長く JavaScript 標準ライブラリの事実上の参考書だった。標準が取り込んだ関数の模範解答集。

2.4 Gulp / Grunt / Bower

何が問題か。 Bower は 2017 年に「もう作業しない」と公式宣言し、npm/yarn への移行を勧めた。Gulp/Grunt はビルドパイプラインを明示的なコードにする価値があったが、バンドラが十分に賢くなった時点でその役目はほぼ消えた。2026 年に新規プロジェクトで Gulp/Grunt に出会うことはまずない。

代わりに使うべきもの。

  • バンドル/HMR: Vite、Rspack、Turbopack、Bun。
  • タスクランナー: package.json scripts + npm-run-all / concurrently / turbo run。

良かった点。 「ビルドもコード」という発想を広めた。思想は生き残り、ツールが変わっただけだ。

3章 · Node ツールチェーン — Yarn 1、Workspaces 単体、手書き Webpack

3.1 Yarn 1

何が問題か。 Yarn 1(クラシック)は 2017-2020 年の npm の欠点を埋めたヒーローだ。しかし Yarn 2 以降は Berry 系列に分離し、1.x はセキュリティ修正以外ほぼ凍結状態である。さらに大きな問題は node_modules のフラット化戦略が、意図しない依存解決を許してしまう点 — pnpm が解決した課題だ。

代わりに使うべきもの。

  • 一般的な単一プロジェクト: pnpm。ディスク効率と厳格な解決が標準になった。
  • モノレポ: pnpm workspaces + Turborepo または Nx。
  • 速度優先: Bun。インストールも実行も速く、互換性も広がりつつある。
  • Yarn 自体が好きなら Yarn 4(Berry、PnP または nodeModulesLinker)。ただし PnP の互換性問題は評価してから決める。

3.2 Yarn Workspaces 単体でモノレポを回す

何が問題か。 ワークスペース自体は良い。しかしビルドキャッシュ、影響分析、リモートキャッシュのないモノレポは早く崩壊する。「この PR は何をビルド/テストすべきか」を人間が決め始めたら終わりだ。

代わりに使うべきもの。

  • Turborepo: シンプルな設定とキャッシュ。JS/TS 中心。
  • Nx: より強力なグラフとプラグイン。多言語/大組織向け。
  • Bazel: 本当に大きな組織、多言語。学習コストを払える時のみ。

3.3 素の webpack.config.js を手で書く

何が問題か。 Webpack 自体が悪いのではなく、2026 年に「Webpack の設定を直接書いて、すべてのローダーとプラグインを手で面倒見る」作業はほぼ必ず損だ。Vite/Turbopack がほぼ全領域を奪い、残った部分も Rspack(Rust ベースの Webpack 互換)が急速に埋めている。

代わりに使うべきもの。

  • 新規: Vite(汎用)、Next.js 内蔵(メタフレームワーク)、Turbopack(Next.js と一緒)。
  • 既存の Webpack 資産をほぼそのまま持っていきたければ Rspack。設定互換を保ちながら速度だけ上げる。

良かった点。 Webpack は「フロントエンドビルド」という概念そのものを定義した。後続ツールのメンタルモデル(エントリ/ローダー/プラグイン)はほぼ Webpack の遺産である。

4章 · Python — システム Python、requirements.txt 単体、conda 乱用

4.1 apt-get install python や brew install python をツール用途で使う

何が問題か。 システム Python は OS の一部だ。そこに pip install を始めるとシステムツールが壊れ、一度壊れると復旧が難しい。仮想環境を必ず作るという規律は良いが、それを人間の手で守る時代は終わった。

代わりに使うべきもの。

  • uv(Astral): Rust ベースの高速 Python パッケージ/プロジェクト管理。依存解決とインストールが速く、ロックファイルを標準で扱う。2024-2025 年で事実上の新標準になった。
  • pipx: CLI 形式の Python ツール(black、httpie など)を隔離して導入。
  • mise または asdf: Python バージョン自体をプロジェクト単位で管理。pyenv より速く多言語にも親和的。

4.2 requirements.txt 単体 + pip freeze ワークフロー

何が問題か。 pip freeze > requirements.txt は環境のスナップショットであって依存仕様ではない。直接書いた依存と、それが連れてきた推移的依存が混在し、プラットフォーム差が無視される。結果として他のマシンで「自分の環境では動いた」が再発する。

代わりに使うべきもの。

  • uv の pyproject.toml + uv.lock。明示依存とロックファイルが分離され、マルチプラットフォームのロックが可能。
  • Poetry: より意見の強い体験。ロックファイルを最初に普及させた。
  • Hatch: ビルドと環境管理を統合。PEP 標準に最も直球で従う。

4.3 conda を「すべて」に使う

何が問題か。 conda は科学計算スタック(GPU/ネイティブライブラリ)が複雑な時に真価を発揮する。しかし純粋な Python ウェブアプリや CLI を conda で回すと、依存解決が分単位になり、チャネル衝突や Anaconda の商用チャネル方針によるライセンスリスクが付いてくる。

代わりに使うべきもの。

  • 純 Python: uv または Poetry。
  • 科学/機械学習 + ネイティブ: mamba(高速 conda 互換)または pixi(Rust ベース、conda パッケージを使いつつロックファイルとタスク定義を統合)。pixi は 2024-2026 年で急速に採用を増やしている。

良かった点。 conda は「OS パッケージ管理なしに GPU スタックを回せるようにした」最初のツールだ。その価値は今も残っている。ただし汎用 Python ワークフローのデフォルトとしては不適切。

5章 · AI 評価と LLM 統合 — Open LLM Leaderboard、古い LangChain、古いプロンプトトリック

5.1 Open LLM Leaderboard

何が問題か。 Hugging Face の Open LLM Leaderboard は 2023-2024 年のオープンモデル評価の事実上の標準だった。しかし評価セット(MMLU、ARC、HellaSwag、TruthfulQA、Winogrande、GSM8K)が急速に飽和し、一部が訓練データに漏れて識別力が落ちた。公式に 2024 年 6 月に v2 に更新され、その後 v2 自体も 2025 年にアーカイブ状態へ移行した。 新しいスコアはもう算出されない。

代わりに使うべきもの。

  • LMArena(旧 Chatbot Arena): 人間のペアワイズ選好に基づく Elo ランキング。「どのモデルが優れているか」の最も信頼できる統合指標。
  • Artificial Analysis: 価格/レイテンシ/品質を一緒に見せる比較サイト。実務の意思決定に有用。
  • ドメイン評価: SWE-bench(ソフトウェア工学)、LiveCodeBench(コーディング、汚染対策)、MMLU-Pro(推論強化)、GPQA(大学院レベルの科学)。
  • 内部評価: 結局すべてのチームに自前のゴールデンセットが必要だ。上記は候補を絞る用にだけ使う。

5.2 LangChain <v0.2 時代の深いインポート

何が問題か。 2023-2024 年の LangChain コードは from langchain.something.deep.path import X のように、内部モジュールを深く直接取りに行くことが多かった。v0.2 以降パッケージが langchain、langchain-core、langchain-community、統合別の langchain-openai、langchain-anthropic、langgraph に分割され、その経路の大半が壊れた。

それでも使われる理由。 古いチュートリアルが検索上位にある。新人がそのコードをそのままコピー&ペーストする。そして v0.2+ への移行ガイドが長く先送りしやすい。

代わりに使うべきもの。

  • そのまま LangChain を使うなら、統合別パッケージを明示的にインポートし、エージェントグラフは langgraph で組む。
  • 単純な呼び出しなら LangChain を使わず、公式 SDK(Anthropic、OpenAI、Google)を直接叩く。抽象化のコストが価値を上回るケースが多い。
  • 検索/インデキシング中心なら LlamaIndex。表面が LangChain より一貫している。
  • マルチエージェントなら LangGraph、CrewAI、OpenAI Swarm を比較。ただし抽象が高いほどデバッグは難しい。

良かった点。 LangChain は「LLM をコードに繋ぐ」というパラダイムを最初に定義した。そのパラダイムが標準ベストプラクティスになる過程で、ライブラリ自体は何度も形を変えなければならなかった。結果として古いコードと新しいコードの距離が大きい。

5.3 「あなたは○○の専門家です」系の古いプロンプトトリック

何が問題か。 2022-2023 年には「あなたはシニアエンジニアです、ステップバイステップで考えてください、深呼吸して」みたいな前置きが本当に効果を出した。モデルが RLHF で整列され、ツール使用も学習されるにつれ、そうした一般的な激励の限界効用はほぼ消えた。2025 年以降の主要ベンダーのプロンプトガイドはむしろ 仕様的で具体的 であることを勧める。

代わりに使うべきもの。

  • システムプロンプトに 役割/制約/禁止事項/フォーマット を明示。「専門家」ではなく「監査可能な SQL を書け、コメント禁止、単一トランザクション」。
  • 評価データセットと一緒にプロンプトを変える。印象ではなくスコアで確認。
  • 長すぎるシステムプロンプトはキャッシュヒット率とコンテキストコストを害する。短く、固く。
  • チェーンが必要なら「ステップバイステップで考えて」ではなく、明示的なステップと出力スキーマ(JSON Schema 等)。

良かった点。 昔のトリックがすべて無意味だったわけではない。「ステップバイステップで考えて」は一時期本物の効果があり、その発見が推論強化の出発点になった。ツールが進化するにつれてトリックは吸収されただけだ。

6章 · 観測とインフラ — 重量級 APM、自前フォワーダ、Docker Hub 依存

6.1 AppDynamics / 重量級 APM を小さなアプリに導入

何が問題か。 AppDynamics、Dynatrace のようなフルスタック APM は大規模モノリスを持つエンタープライズには価値がある。しかし 5 人チームに 10 個のマイクロサービスがある状況では、ライセンス費用と運用負担が価値を圧倒する。そしてベンダーロックイン。

代わりに使うべきもの。

  • 標準は OpenTelemetry(OTel)。メトリクス/ログ/トレースを一つの標準で。
  • メトリクス: Prometheus + Grafana。
  • トレース: Tempo または Jaeger。
  • ログ: Loki またはクラウドネイティブ系。
  • 一括ホスティング: Grafana Cloud または Honeycomb。ホスティング費用は別途評価。
  • マネージドの統合製品が本当に必要なら Datadog、New Relic も候補。ただし「OTel 互換性」を基準に比較。

6.2 自前ログフォワーダ、自前フォーマット、自前パイプライン

何が問題か。 「うちだけのログ形式」は最初の 6 か月は速く、その後の 6 年は遅い。新ツールを繋ぐたびアダプタを自前で書き、検索/保存/保持ポリシーまで全部自前実装になる。

代わりに使うべきもの。

  • 形式: 構造化 JSON。キーは OTel semantic conventions ガイドに従う。
  • フォワーダ: OpenTelemetry Collector または Vector(Datadog のオープンソース)。
  • 保存: マネージドか ClickHouse/OpenSearch。自前は最後の選択肢。

6.3 Docker Hub 無認証 pull にビルド SLA を縛り付ける

何が問題か。 Docker Hub は 2020 年以降、無認証/無料アカウントの pull に時間あたり制限を設けている。CI でその制限に当たるとビルド全体が偽の失敗をする。さらにベースイメージの完全性も別途検証なしで信頼することになる。

代わりに使うべきもの。

  • 社内イメージミラー: Harbor、JFrog Artifactory、またはクラウドレジストリ(ECR、GHCR、Artifact Registry)。
  • ベースイメージはミラーを通し、SBOM と署名(cosign)を検証。
  • マルチアーキ(amd64/arm64)はビルド時に明示。

7章 · DevOps / CI — Travis OSS、手書き Bash、main 直 push

7.1 Travis CI に OSS ビルドを縛り付ける

何が問題か。 Travis CI は OSS CI の黄金期を作った道具だ。しかし 2020 年以降の無料方針変更で、多くの OSS プロジェクトが事実上使えなくなった。新規 OSS を Travis 上で始める理由はもうほぼない。

代わりに使うべきもの。

  • 最も普遍的: GitHub Actions。OSS の無制限分は十分にゆるい。
  • 最も強力なキャッシング/並列: Buildkite(セルフホストエージェント)、CircleCI。
  • GitLab を使うなら GitLab CI。
  • モノレポ: Turborepo/Nx キャッシュ + 上のどの CI でも。

7.2 手で書いた Bash パイプラインをビルドの中核に置く

何が問題か。 Bash は強力でどこでも動く。しかし 100 行を超えるビルドスクリプトはほぼ必ず誤った抽象化に到達する。一人辞めるとその人だけが知っていた環境変数が消える。

代わりに使うべきもの。

  • 単純なコマンド束: package.json scripts、mise tasks、just。
  • ビルドグラフ: Turborepo、Nx、Bazel。
  • 「スクリプトが長くなった」その時点でツールに移行する。200 行の Bash は警告サインだ。

7.3 「main に直接 push」文化

何が問題か。 ツールではなくプロセスのアンチパターンだ。小さなチームが速く動こうとする意図は理解できるが、レビューなしのマージは学習が止まった組織の最初のサインである。事故はその後ちょうどよく到着する。

代わりに使うべきもの。

  • 短い PR(およそ 400 行の変更以下)を標準に。
  • マージキュー(Mergify、GitHub Merge Queue) — メインの破損防止。
  • 自動マージルール — レビュー通過 + CI グリーンで自動マージ。
  • CODEOWNERS と 1 レビュアールール — 真の責任者にルーティング。

8章 · 一般的なプロセスアンチパターン — VS Code 拡張肥大、.env コミット、「全部書き直そう」

8.1 VS Code 拡張肥大

何が問題か。 VS Code は豊富な拡張エコシステムが強みだ。しかしその強みがデフォルトになると — 「便利そうだからとりあえずインストール」— 二つが同時に崩れる。性能(起動時間、メモリ、言語サーバー衝突)と サプライチェーンセキュリティ(悪意ある拡張、タイポスクワッティング)。

代わりに使うべきもの。

  • 拡張ダイエット。四半期ごとに使っていない拡張を外す。
  • 信頼できる発行元のみ(Microsoft、公式言語チーム、知名度のある企業)。出所が曖昧な拡張はインストール前に検討。
  • ワークスペース別の推奨拡張リスト(extensions.json)。
  • 作業に応じてエディタを分ける。重い IDE は本当にそのときだけ。

良かった点。 VS Code の拡張モデルはエディタエコシステムを永遠に変えた。問題はモデルではなく無節制だ。

8.2 .env をコミット、平文でシークレットを共有、Slack DM にトークン

何が問題か。 セキュリティ事故の単一原因第 1 位。一度コミットされたシークレットは永遠だ — 履歴書き換えでも取りこぼすケースは多い。

代わりに使うべきもの。

  • ローカル: direnv + .envrc.local(絶対コミットしない)+ 1Password CLI / op read。
  • チーム: SOPS + age/KMS キー、Doppler、1Password Secrets Automation。
  • インフラ: Vault、クラウドのシークレットマネージャ(AWS Secrets Manager、GCP Secret Manager)、SealedSecrets(Kubernetes)。
  • 事故対応: git-secrets、gitleaks、trufflehog を pre-commit と CI の両方に。

8.3 「古いから全部書き直そう」大規模リライト

何が問題か。 この記事のすべての提言を一四半期で全部適用しようとする欲。大規模リライトは最も高い負債返済方法であり、その間に新しい負債が積み上がる。

代わりに使うべきもの。

  • ストラングラー・フィグ パターン: 新コードが古いコードを少しずつ包んで置き換える。
  • モジュール単位の移行、一度に一つ。
  • 四半期ごとに「古いツールを 1 個置き換える」目標。1 年で 4 個。
  • 移行ごとに「前後比較指標」(ビルド時間、バンドルサイズ、セキュリティ勧告数)を記録。今日の決定が明日の決定の材料になる。

9章 · グレーゾーン — 死んでいないがデフォルトにはしないツール

この節は「絶対使うな」ではない。新規プロジェクトのデフォルトとしては勧めないが、文脈によっては合理的 なツール群だ。

ツールデフォルトにしない理由それでも使う文脈
Jenkinsセルフホスト運用負担、UI/プラグイン負債大きな社内、強い隔離/オンプレ要件
VagrantDocker/Devcontainer がほぼ吸収特定 VM 環境の再現が本当に必要
MongoDB デフォルトトランザクション/スキーマ/レポート弱点非定型 + 高スループット + スキーマ進化が速いドメイン
jQueryDOM API と fetch がほぼ吸収古いシステム維持 / 非常に単純なページ
Bootstrap 5 デフォルトトークン/ユーティリティ優先の時代と齟齬速い社内ツール、デザインシステムなし
Selenium新規は Playwright/Cypress が標準古いグリッド資産、非標準ブラウザ
Nginx 手動設定Caddy/Envoy がより現代的なデフォルト精密チューニング、大きな既存資産

グレーゾーンは正直な看板だ。「デフォルトではないが理由があれば使え」というサイン。ツールの価値は文脈に縛られているという事実を忘れないでほしい。

10章 · 良かったものたちへの短い献辞

この記事は批判だが墓碑銘ではない。少し立ち止まって認めよう。

  • CRA は React を初めて触る人の不安を一行コマンドに変えた。後続ツールのデフォルト親和性はすべて CRA の遺産だ。
  • Moment.js は 10 年間、貧弱な JS Date API の隙間を埋めた。標準が追いつく時間を稼いでくれたライブラリだ。
  • lodash は JavaScript 標準ライブラリの事実上の参考書だった。標準が吸収した関数半分の模範解答。
  • Webpack はフロントエンドビルドという概念を定義した。あのメンタルモデルなしには Vite もない。
  • Jenkins は CI 文化を普及させた。
  • Travis CI は OSS の CI 無料時代を開いた。
  • LangChain は LLM をコードに繋ぐパラダイムを定義し、自分自身を何度も変えながらその道を切り拓いた。
  • AppDynamics はフルスタック APM というカテゴリそのものを作った。

批判の対は感謝だ。今手にしているより良いツールたちは、これらが敷いた道の上に立っている。

エピローグ — 一四半期チェックリストと次の記事

この四半期に一つだけやるなら

新規プロジェクトなら、上のマトリクスのデフォルトをそのまま選ぶ。既存プロジェクトなら、最も頻繁にビルドされるパイプラインの最も遅い段 を一つだけ置き換える。週に 100 回回る処理を 30 分速くすれば、四半期で 50 時間が戻ってくる。

導入前の 6 質問チェックリスト

  1. このツールは 保守されているか? 最後のリリース日、Issue 解決比率を見る。
  2. このツールの 公式の推奨ステータス は何か? "deprecated" のような単語を探す。
  3. 代替と移行経路 はあるか? ロックされた状態で始めない。
  4. バンドル/実行コスト は価値に見合うか? 標準が吸収した機能のために依存を増やさない。
  5. サプライチェーン脅威 はどう扱うか? 拡張/プラグイン/ノードはすべて第三者コードだ。
  6. 離脱コスト はいくらか? 6 か月後に後悔しても抜け出せるか?

アンチパターン要約

  • 検索結果の一番上で止まる — 2018-2022 年の記事が一番上の分野が半分ある。
  • 「チームが慣れているから」— 慣れは資産だが新人には負債。
  • 「スター 1 万個あるから」— スターは関心であって採用ではない。
  • 「明日から全部書き直そう」— 大規模リライトは最も高い負債返済。
  • 代案なしの批判 — この記事のすべての項目がペアを持つ理由。

次の記事予告

次の記事ではこの記事が頻繁に触れた 移行そのもの を深掘りする。CRA → Vite、Moment → date-fns/Temporal、Yarn 1 → pnpm、requirements.txt → uv を実コードと共に一歩ずつ動かすガイドだ。何を壊し、何を先送りし、何を自動化するか — 「移行する決定」を「移行した結果」に変える実戦編。

ツールの寿命を認めることは敗北ではない。次の段階へ進む最初の決定だ。

参考 / References

Discuss on Twitter • View on GitHub