jQueryとは何か、なぜ「忘れられた」と言われるのか

1分でわかるjQuery

jQueryは、ページ上のよくある操作――要素の選択、クリックへの反応、テキストの変更、表示/非表示、サーバーへのリクエスト送信――を簡単にする小さなJavaScriptライブラリです。

もし $("button").click(...) のようなコードを見たことがあるなら、それがjQueryです。$は「ページ上の何かを見つけてそれに何かをする」の省略形と考えれば良いでしょう。

この記事で扱うこと

このガイドは実用的で技術的すぎない説明を目指します：jQueryとは何か、なぜ人気になったのか、なぜ新しいプロジェクトで使われにくくなったのか、そして自分のサイトがまだjQueryを使っている場合にどう扱うべきか。

短い意見ではなく、具体的な例と現実的なアドバイスを含めるために意図的に内容を詳しくしています。

「忘れられた」と言うときの意味

人々がjQueryを「忘れられた」と言うとき、消えたという意味ではなく大抵次のようなことを指します：

• 新しいプロジェクトでは使われる頻度が減った。モダンブラウザがかつてjQueryが提供していた多くの機能をサポートするようになったからです。
• 古いサイト（と一部のプラグイン、テーマ、管理画面）ではまだ普通に使われている。動くし慣れているし、置き換えるには時間がかかるからです。

つまり話は「jQueryは死んだ」ではなく、フロントエンド作業のデフォルトツールから、継承したり必要に応じて選んだりするレガシー依存へ移行した、ということです。

jQueryが一躍注目された理由

jQuery以前は、フロントエンドの仕事は同じ面倒なコードを何度も書き、複数のブラウザでテストして挙動の差に対処することが多くありました。単純に「この要素を見つける」「クリックに反応する」「リクエストを送る」といったことが特殊ケースの山になることもありました。

jQuery以前のフロントエンドがどう感じられたか

初期のJavaScript開発は、機能を作るよりも環境と格闘する時間の方が長かったと言えます。あるブラウザで動くコードを書き、別のブラウザで動くように分岐を足す。チームは日常のUI変更に耐えるために内部の“ミニライブラリ”を持っていることが普通でした。

結果として、開発は遅くなりバグは増え、ほんの小さな変更で古いブラウザが壊れるのではと常に心配する必要がありました。

ブラウザ差とその重要性

ブラウザは重要な点で一致していませんでした。DOMの選択方法、イベント処理、要素のサイズ取得の仕方などが違いました。特にInternet ExplorerはイベントやXMLHTTPリクエストのAPIが異なり、標準的なコードがそのまま移植できないことがありました。

これが重要だったのは、ウェブサイトは単一のブラウザ向けに作られているわけではないからです。チェックアウトフォームやナビゲーション、モーダルが人気のブラウザで動かないとビジネスに直結する問題でした。

jQueryが日常的タスクのために埋めたギャップ

jQueryが注目されたのは、ブラウザ間の差異を滑らかにする一貫した、使いやすいAPIを提供したからです。

日常的なタスクが劇的に簡単になりました：

• CSS風のセレクタでDOM要素を選んで操作する
• クロスブラウザなイベント処理
• タイマーを自前で書かずにできるアニメーションやエフェクト
• 単一で予測可能なインターフェースを持つAjaxリクエスト

何より「少ないコードで多くをする」スタイルにより、チームはブラウザ固有の驚きに悩まされることなくより速くリリースできました。特に当時はモダンなDOM APIが今ほど強力で広くサポートされていなかったのです。

jQueryが助けたコアな作業

jQueryの強みは新しい概念を生み出したことではなく、日常的なブラウザ作業を一貫して簡単に感じさせたことです。古いフロントエンドコードを読むと、典型的にjQueryは次の4つの仕事に使われています。

1) DOM選択と走査（$関数の考え方）

$()はCSS風のセレクタで要素を“つかみ”、グループとして扱えるようにしました。

ブラウザの差や冗長なAPIに悩む代わりに、要素をまとめて選んだり、子要素を探したり、親へ移動するといった短くチェーン可能な呼び出しで作業できました。

2) イベント：クリック/submit/readyパターン

jQueryはユーザーアクションに応答するのを簡単にしました：

• ボタンやリンクのclick
• フォームのsubmit
• ページ読み込み時に実行するready

また、ブラウザごとのイベントオブジェクトやバインディングの違いを吸収してくれた点も重要でした。

3) AJAXの基本（ページ更新なしでデータを読み込む）

fetch()が標準になる前は、$.ajax()や$.get()、$.post()がサーバーとやり取りしてページを再読み込みせずにデータを取得する代表的な手段でした。

これにより、ライブ検索や「もっと見る」ボタン、部分的なページ更新といった現在では当たり前に思えるパターンが単一の馴染みあるAPIで実現できました。

4) エフェクト/アニメーションと簡単なUIヘルパー

hide()、show()、fadeIn()、slideToggle()、animate() といった手早いUI演出が普及しました。メニューや通知、簡易的なトランジションに便利で、当時はCSSのサポートが今ほど信頼できなかったこともあります。

これらが合わさって、古いJavaScriptコードで$(が先頭に来るのをよく見かけた理由であり、jQueryが長くデフォルトツールだった背景です。

簡単な例：jQueryとモダンJavaScriptの比較

jQueryの評判は、特にブラウザ差が厳しかった頃に、一般的なUIタスクを非常に少ないコードで実現できた点にあります。並べてみるとわかりやすいでしょう。

要素を選んでクリックを処理する

jQuery

// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
  e.preventDefault();
  $('.status').text('Saved!');
});

モダン（バニラ）JavaScript

// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');

saveButton?.addEventListener('click', (e) => {
  e.preventDefault();
  if (status) status.textContent = 'Saved!';
});

可読性：行数の少なさ vs 明確なAPI

一見するとjQueryの方が“すっきり”しているように見えます：1つのチェーンで要素を選び、ハンドラを付けてテキストを更新しています。その簡潔さが大きなセールスポイントでした。

モダンJavaScriptはやや冗長になりがちですが、より明示的です：

• querySelectorやaddEventListenerは何が起きているかを明確に示します。\n- textContentは標準のDOMプロパティで、ライブラリのラッパーではありません。\n- オプショナルチェイニング（?.）やnullチェックで要素が存在しない場合の挙動がより明確になります。

どちらが「良い」か？

文脈次第です。既存のコードベースがjQueryで統一されているならjQueryの方が一貫して扱いやすく、素早く作業できます。一方で新しいコードを書く場合は、モダンなDOM APIは広くサポートされており、依存を減らせて今日のツールチェインやフレームワークと組み合わせやすいです。

ネイティブJavaScriptが追いついた

長年にわたり、jQueryの最大の利点は「予測可能性」でした。要素の選択、イベントの添付、Ajaxの呼び出しを一つの書き方で書けば多くの場所で動きました。

しかしブラウザは標準化・改善され、jQueryがまとめていた多くの便利さは今やJavaScript自体に組み込まれています。つまり基本だけのためにライブラリを追加する必要がなくなったケースが増えました。

DOM APIがより簡潔で一貫したものに

モダンDOMは多くのjQueryパターンをカバーします：

• document.querySelector() / document.querySelectorAll() は多くの $(...) を置き換えます。\n- element.classList.add() / .remove() / .toggle() はクラス操作を担当します。\n- element.addEventListener() はほとんどのイベントケースでjQueryのラッパーに取って代わりました。

jQuery固有のヘルパーを覚える代わりに、標準APIに依存できるようになりました。

ネットワークリクエストはfetchへ

かつて$.ajax()が多用されていましたが、fetch()は多くの日常的なリクエストをより少ない手続きで扱えるようになりました（特にJSONと組み合わせたとき）：

const res = await fetch('/api/items');
const data = await res.json();

エラーやタイムアウトは明示的に扱う必要がありますが、基本的な「プラグイン不要でリクエストを送る」考え方がネイティブになったのです。

Promise、async/await、モジュールによる構造化の向上

jQueryはコールバックや$.Deferredを通して非同期処理を多くの人に紹介しましたが、今日ではPromiseやasync/awaitが非同期フローを読みやすくし、ESモジュールはコードの構成を明確にします。

この組み合わせ（モダンDOM + fetch + 言語機能）は、チームがデフォルトでjQueryを選ぶ理由の多くを取り除きました。

フレームワークがUIの作り方を変えた

jQueryは「マルチページサイト」の時代に育ちました：サーバーでHTMLをレンダリングし、ブラウザがページを読み込んだあとに振る舞いを追加する（クリックハンドラ、アニメーション、Ajax呼び出し）というモデルです。

モダンなフロントエンドフレームワークはそのモデルをひっくり返しました。多くのアプリはブラウザでUIの大部分を生成し、データと同期させ続けるようになりました。

シングルページアプリとコンポーネントベースのUI

React、Vue、Angularはコンポーネントという、小さく再利用可能でマークアップ・振る舞い・状態を持つ単位でUIを構築する考えを普及させました。

この場合、フレームワークが画面上のソース・オブ・トゥルース（真実）になり、状態変化に応じて部分的に再レンダリングします。

一方でjQueryは命令的にDOMを操作するスタイル（「この要素を見つけてテキストを変えて隠す」）を推奨します。これがフレームワークのレンダリングサイクルと衝突すると、手動で変えたDOMが再レンダリングで上書きされるか、矛盾の原因になりやすくなります。

ビルドツールとバンドラがコードの出し方を変えた

SPAが普及するにつれて、チームはWebpack、Rollup、Viteのようなビルドツールを採用し、必要なものだけをimportしてバンドルするようになりました。単にいくつかのscriptタグを落とす時代とは違います。

この変化は依存とバンドルサイズへの感度を高め、jQueryを“念のため”入れる考え方を弱めました。

コンポーネント型アプリでjQueryが違和感を生む理由

フレームワーク内でjQueryを使うことは可能ですが、しばしばテストや理解が難しい“特別な島”になりがちです。リファクタで壊れやすく、結果としてチームはフレームワークに適したパターンを優先するようになります。

バンドルサイズと保守の圧力

jQuery自体は「巨大」ではありませんが、そこに付きまとうプラグインや関連コードが積み重なることが問題です。多くのプロジェクトはjQueryを導入するとスライダーや日付ピッカー、モーダル、バリデーションなどのプラグインも一緒に取り込むため、結局ページに重複したユーティリティがいくつも入ることがあります。

ダウンロード量とブラウザの負荷

JavaScriptが増えると、ブラウザがフェッチ、パース、実行する仕事が増え、ページが反応可能になるまでの時間に影響します。モバイル、遅いネットワーク、古いハードウェアでは特に顕著です。

見えないコスト：スタイルの混在と心理的負担

長く運用されるサイトでは次のような“ハイブリッド”なコードベースが生まれがちです：jQueryで書かれた機能、フレームワークで作られた新しい部分、スニペット的なバニラJS。

この混在は混乱を招きます：

• 要素選択やDOM更新のやり方が複数ある\n- イベントモデルやライフサイクルの前提が異なる\n- 状態管理の考え方が競合する（DOMが状態なのか、コンポーネント状態なのか）

結果として小さな変更でもリスクが上がり、古いjQueryスクリプトが同じマークアップに手を入れてバグを生むことがあります。

保守の圧力は徐々に大きくなる

チームがjQueryから離れていくのは「動かなくなるから」ではなく、モダンプロジェクトがバンドルサイズの小ささやUI振る舞いの所有権の明確化を重視するようになったからです。大規模になればパフォーマンス調整、デバッグ、新人のオンボーディングが楽な方に収束していきます。

古いサイトでjQueryをまだ見る理由

jQueryは単に人気になっただけでなく「デフォルト」になりました。長年にわたり、ブラウザ間の違いを吸収してインタラクティブなページを確実に動かす最も簡単な手段だったため、テンプレートやスニペット、チュートリアル、コピペの結果として広く埋め込まれました。

一度そうなると、たとえサイトが1つの小さな機能しかjQueryに頼っていなくても、他のあらゆるコードがjQuery前提で作られているためライブラリ全体を読み込むことが普通になってしまいました。

古いプラグインやテーマに組み込まれている

jQueryが残る大きな理由は、その成功がサードパーティコードに「どこにでもある」状態を作ったからです。古いUIウィジェット、スライダー、ライトボックス、フォームバリデータ、テーマスクリプトはjQueryプラグインとして書かれていることが多く、依存するコンポーネントがあるとjQueryを外すのは単純な数行置換では済みません。

WordPressがそのまま継承している

WordPressはレガシーjQueryの大きな供給源です。多くのテーマとプラグイン（特に古いもの）はフロントエンドでjQueryを使っており、管理画面も歴史的にjQueryに依存していました。新しいバージョンでモダンなJSに移す動きがあっても、古い拡張のロングテールがjQueryを残す要因です。

レガシーシステムは安定を優先する

古いサイトは「動いているものを壊さない」ことを優先します。jQueryを残すのは安全な選択となることが多いです：

• サイトが安定しており収益に直結している\n- 時間が限られており回帰テストが高コスト\n- 長年の細かい修正が蓄積されていて誰も全部を監査したくない

つまり、jQueryは忘れられているというより、サイトの土台に組み込まれていることが多いのです。土台は簡単には取り替えられません。

jQueryがまだ有効なとき

jQueryは「悪い」ソフトウェアではありません。単に以前ほど必須ではなくなったというだけです。しかし、時間や互換性、安定性を優先する状況では、jQueryを維持したり少しだけ追加する方が実用的なことがあります。

レガシーブラウザをサポートする必要がある場合

古いブラウザ（特に古いIE）をサポートする要件があるなら、jQueryはDOM選択、イベント、Ajaxを簡単に扱える選択肢になり得ます。ネイティブAPIだけで揃えようとすると余分なポリフィルが必要になることがあるため、総コストで考えるとjQueryが筋通っていることもあります。

既存のjQueryコードベースに対するクイックフィックス

サイトが既にjQuery中心で作られているなら、小さなUIの変更は同じスタイルで行った方が速く安全です。アプローチを混ぜると保守性が下がり、イベントやDOM操作のやり方が分散してしまいます。

現実的なルール：画面を1〜2箇所触るだけでアプリが安定しているなら、jQueryでパッチするのは許容範囲。ただし新しい「システム」としてjQueryを拡大していくのは避けるべきです。

ビルドステップのない小さなサイト

マーケティングサイトや内部ツールのようにバンドラやトランスパイラがない場合、jQueryは「単一のscriptタグで済む」便利なヘルパーです。トグルメニューや簡単なフォーム挙動など数個のインタラクションだけが必要なら導入が手早く済みます。

古いプラグインに依存している場合

成熟したプラグイン（カレンダー、テーブル、ライトボックス）はjQuery上に構築されていることが多いです。ビジネスクリティカルで安定しているプラグインなら、jQueryを残す方が最低リスクという判断になることがあります。

プラグインを維持する前に、非jQueryの代替があるか、あるいはプラグインのアップグレードが大規模な書き換えを招くかを確認しましょう。

jQueryから安全に離脱する方法

jQueryを外すのは「構文を置き換える」よりも長年の前提を解きほぐす作業です。安全なアプローチは段階的に依存を減らすことです。

1) 実際に何を使っているか監査する

次の三つを確認してください：

• どのページがjQueryを読み込んでいるか？\n- どのプラグインがjQueryに依存しているか？（スライダー、日付ピッカー、バリデーション等）\n- コードベースで使われているjQueryの機能は何か？（DOM選択、イベント、Ajax、アニメーション）

この監査で不要な置き換えを避け、$.ajax()を静かに使っているような“隠れた”依存を見つけられます。

2) まず成果が出やすいものから置き換える

多くのチームは次の単純なパターンを先に置き換えて早い勝ちを得ます：

• セレクタ：$(".card") → document.querySelectorAll(".card")\n- クラス：.addClass() / .removeClass() → classList.add() / classList.remove()\n- イベント：.on("click", ...) → addEventListener("click", ...)

小さなPRで進めればレビューもしやすく、ロールバックも簡単です。

3) Ajax移行計画を立てる

$.ajax()を使っているなら、その呼び出しをfetch()（または小さなHTTPヘルパー）に一つずつ置き換えます。UIがすぐ壊れないようにレスポンス形は当面同じにしておくのが良いでしょう。

// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);

// Modern JS
fetch("/api/items")
  .then(r => r.json())
  .then(renderItems);

4) テストと段階的ロールアウトでリスクを下げる

jQueryを削除する前に、重要なユーザーフロー、フォーム送信、動的なUIのカバレッジを追加しましょう。軽量なチェック（CypressによるスモークテストやQAチェックリスト）でも回帰を早期に捕まえられます。可能なら機能フラグの背後で変更を出し、分析やエラー率が安定していることを確認してください。

リファクタ中に余裕を持たせるためにスナップショットやロールバックをサポートするツールを使うチームもあります。たとえば、レガシーなフロントエンドをモダナイズする際に、Koder.aiのようなプロトタイピングツールで代替を作ってスナップショット/ロールバックしつつ繰り返す、といったワークフローが使われます。

全体計画の整理が必要であれば、/blog/jquery-vs-vanilla-js の比較をリファレンスとして使えます。

よくある移行時の落とし穴

jQueryからの移行は構文の置換より長年の前提を解く作業です。遅延の原因となる罠と回避法をまとめます。

一度に全部書き換えようとする

全体を書き換えるのは一見綺麗ですが、長いブランチや多くの回帰を生み、未完成のまま出荷圧力が高まることが多いです。安全なやり方は段階的に：機能やページ単位で置き換え、振る舞いは同じに保ち、触った部分にテストを追加することです。

同じUI領域でjQueryとコンポーネントフレームワークを混ぜる

React/Vue/Svelte等を導入している最中にjQueryが同じDOMノードを直接操作していると、フレームワークの再レンダリングがjQueryの変更を上書きしたり、逆にjQueryがフレームワークの管理する領域を壊したりします。

ルールとしては境界を明確にします：

• レガシーコンテナ内ではjQueryを保ち、別の場所にフレームワークをマウントする、または
• そのウィジェット全体をユニットとして移行してから新しい振る舞いを追加する

イベント委譲の差異

古いコードはしばしば次のような委譲に依存します：

$(document).on('click', '.btn', handler)

ネイティブDOMでも同様のことはできますが、マッチングやthis、event.targetの期待が変わることがあります。置き換え時に注意する点：

• どの要素を「クリックされたボタン」と見なすべきか（closest()が必要なことが多い）\n- 以前はイベントに名前空間を付けて管理していたか（jQuery特有の機能）\n

エフェクトを置き換えたときのアクセシビリティ低下

jQuery UIのエフェクトやカスタムアニメーションは、時に偶然アクセシビリティの問題を隠していたり、逆に問題を引き起こしていたりします。フェードやスライド、トグルを置き換える際は次を確認してください：

• フォーカス管理（開閉後のキーボードフォーカス）\n- aria-expandedなどのARIA状態属性\n- prefers-reduced-motionの配慮

これらを早めに検証することで移行が速く、信頼できるものになります。

まとめと次の一手

jQueryは悪くありません。ブラウザが異なっていた時代の現実的な問題を解決しました。変わったのは、新規プロジェクトでは普通は必要ないことが多くなったという点です。

jQueryが衰退した理由

いくつかの要因が、jQueryを「デフォルト」から「レガシー依存」へと押し下げました：

• モダンDOM APIの改善: 要素選択、クラス操作、イベント処理が標準で簡単になった。\n- ブラウザの一貫性向上: 互換性レイヤーの価値が減った。\n- フレームワークの期待の変化: React/Vue/Angularはコンポーネントと状態駆動のレンダリングを重視し、直接的なDOM操作は相対的に重要度が下がった。\n- パフォーマンスと保守の圧力: チームはバンドルサイズや不明瞭なコードを減らすことを重視するようになった。

実務的な次の一手

古いサイトを保守しているなら、jQueryは小さな修正や安定したプラグイン、ページ全体を再構築する余地がない場合には合理的なツールです。新しい機能を作るならまずはネイティブJavaScriptを検討し、明確に時間を節約する場合だけjQueryを残しましょう。

学習を続けるための参考：

• DOMの基本と一般的パターン：/blog/vanilla-js-dom-basics\n- 旧来のAjaxパターンをモダンなリクエストに置き換える方法：/blog/fetch-api-beginners

より速くモダナイズする方法を評価するなら、段階的にプロトタイプを作れるツールやワークフローを検討してください。Koder.aiのようなツールは、チャットで欲しい振る舞いを説明するとReactベースのUIや必要ならGo/PostgreSQLのバックエンドまで生成し、準備ができたらソースコードをエクスポートして既存のコードベースに統合できます。

ツールやサポートオプションを比較したい場合は /pricing を参照してください。

$(document).on('click', '.btn', handler)