jQueryの$.ajaxは何をラップしているのか

jQueryの`$.ajax()`は結局「XMLHttpRequestの操作代行」です

jQueryの`$.ajax()`は魔法ではありません。
中身でやっていることは、ブラウザが持っている通信APIであるXMLHttpRequest（XHR）の生成・設定・送信・イベント管理を、人間が書きやすい形に整理して提供しているだけです。

つまり、

• jQuery.ajax → 新しい通信機能

ではなく

• jQuery.ajax → XMLHttpRequestの操作ラッパー

です。

これを理解すると、なぜ昔のJavaScriptが難しかったのか、そしてなぜjQueryが爆発的に普及したのかが一気に見えてきます。

そもそもXMLHttpRequestとは何か

XMLHttpRequest（XHR）は、ページを再読み込みせずにサーバと通信するためのブラウザ標準APIです。
いわゆる「Ajax通信」を実現している本体そのものです。

名前にXMLと入っていますが、XML専用ではありません。
JSONでもHTMLでもテキストでも取得できます。

典型的なXHRコードは次のようになります。

var xhr = new XMLHttpRequest();

xhr.open('GET', '/api/user', true);

xhr.onreadystatechange = function () {
  if (xhr.readyState === 4 && xhr.status === 200) {
    console.log(xhr.responseText);
  }
};

xhr.send();

一見すると単純そうに見えますが、実際に使うと問題だらけでした。

当時の開発者が苦しんだポイント**

• readyStateを監視する必要がある
• status判定が必要
• エラー時の処理を自分で書く必要
• タイムアウト処理が手作業
• POST時のヘッダ設定が必要
• JSONパースを自分で行う必要
• ブラウザごとに挙動が違う

つまり「通信するだけ」で大量のボイラープレートコードが必要でした。

jQuery.ajaxがやっている本当の仕事

jQueryの`$.ajax()`は、この面倒な部分をすべて引き受けています。

実際の対応関係を見ると分かりやすいです。

jQuery.ajaxのオプション	内部で行われる処理
url	xhr.openのURL設定
type	GET/POSTのメソッド指定
data	クエリ文字列の組み立て
headers	setRequestHeaderの設定
timeout	タイマー管理
success	onreadystatechange成功分岐
error	失敗時ハンドリング
dataType: 'json'	JSON.parse自動実行

つまり`$.ajax()`は単なる便利関数ではなく、通信処理フレームワークです。

実際のコード比較を見てみます。

XMLHttpRequest**

var xhr = new XMLHttpRequest();
xhr.open("POST", "/api/login", true);
xhr.setRequestHeader("Content-Type", "application/json");

xhr.onreadystatechange = function() {
  if (xhr.readyState === 4) {
    if (xhr.status === 200) {
      var data = JSON.parse(xhr.responseText);
      console.log(data);
    } else {
      console.error("error");
    }
  }
};

xhr.send(JSON.stringify({id:"user", pass:"1234"}));

jQuery.ajax**

$.ajax({
  url: "/api/login",
  type: "POST",
  contentType: "application/json",
  data: JSON.stringify({id:"user", pass:"1234"}),
  dataType: "json",
  success: function(data){
    console.log(data);
  },
  error: function(){
    console.error("error");
  }
});

機能は同じです。
書く量と理解コストがまったく違います。

これがjQueryの価値でした。

「ラップしている」とは具体的に何をしているのか

jQueryは内部で以下を自動化しています。

1. XMLHttpRequest生成**

ブラウザ差異（IEのActiveX）を吸収

2. 状態管理**

readyStateの監視を抽象化

3. レスポンス変換**

text → JSON → script → html を自動変換

4. エラーハンドリング**

通信失敗・タイムアウト・HTTPエラーを分類

5. コールバック管理**

success / error / complete を整理

特に重要なのが「ブラウザ差異の吸収」です。

当時は同じコードでも

• IE6では動かない
• Safariでは例外
• Firefoxではヘッダエラー

という状況が普通に起きていました。
jQueryはこの差異を内部で分岐していました。

開発者は「通信したい」とだけ書けばよかったのです。

なぜjQuery.ajaxが革命だったのか

現在の`fetch`と違い、当時はPromiseもありませんでした。
非同期処理はイベント駆動で、しかもブラウザごとに挙動が違いました。

つまり

• 非同期が難しい
• 通信が難しい
• 互換性が難しい

この3つを同時に解決したのが`$.ajax()`です。

単なる記述量削減ではありません。
「Webアプリケーションが現実的に作れるようになった」レベルの変化でした。

Gmail、Google Maps、Twitterなどの「ページ遷移しないUI」が普及した背景には、Ajax通信の実用化があります。
そして現場の実装を支えたのがjQuery.ajaxでした。

注意点：jQuery.ajaxは万能ではない

便利ですが、誤解されがちな点があります。

jQuery.ajaxは通信を簡単にするだけで、セキュリティを保証するものではありません。

例えば次は危険です。

$.ajax({
  url: "/api/user?id=" + userInput
});

これはサーバ側の脆弱性をそのまま突きます。
また、CSRF対策も自動では行いません。

つまり

• 通信は簡単になる
• 安全になるわけではない

ここは重要です。

ではなぜ現在はfetchが使われるのか

理由は単純で、ブラウザ自体が進化したからです。

• Promise標準化
• CORS標準化
• JSONが前提になった
• ブラウザ差異がほぼ消えた

これにより「ラッパーの必要性」が減りました。
現在のfetchは、jQuery.ajaxが担っていた役割をブラウザが持つようになった姿です。

まとめ

jQueryの`$.ajax()`は新しい通信技術ではありません。
XMLHttpRequestという難解な低レベルAPIを、人間が使える形に翻訳したインターフェースです。

Web開発の歴史を少し誇張して言えば、
Ajaxを発明したのはブラウザですが、
Ajaxを普及させたのはjQueryです。

そして現在の`fetch`は、その思想がブラウザに取り込まれた結果と言えます。

jQueryが古く見えるのは、役目を終えたからです。
役に立たなかったからではありません。