モダンJavaScript開発の初期において、Axiosはネイティブのfetch() APIと比較して便利な機能を提供するHTTPリクエストライブラリとして広く採用されてきました。しかし、2025年の現在、Webプラットフォームは大きく進化しています。多くのReactやフロントエンドデベロッパーの頭の中には、*本当にまだAxiosが必要なのだろうか？*という疑問があるでしょう。この記事では、Axiosの伝統的な利点、モダンなFetch APIが現在提供している機能（ストリーミング、タイムアウト、インターセプター、エラーハンドリングなど）、今日のAxios vs. fetchの比較、そしてKy、Got、SuperAgentなどの代替手段や新しいツールについて探っていきます。

最後に、Axiosがまだ使う価値がある場面と、ネイティブfetchや他のソリューションが適している場面について明確な見解を示します。

Axiosの概要：従来Fetchより優れていた点

Axiosは、ブラウザとNode.js両方で使えるPromiseベースのHTTPクライアントライブラリで、ネットワークリクエストを行う際の多くの難点を解消したことから人気を博しました。後に登場したネイティブのfetch()や生のXHRと比較して、Axiosが非常に便利だった理由は何でしょうか？主な特徴を挙げてみましょう：

組み込みのJSON変換： Axiosは自動的にレスポンスデータをJSON形式に変換してくれるため、response.dataから直接アクセスできます。一方、fetchではresponse.json()を手動で呼び出す必要があります。また、リクエスト送信時（例：POST）にも、JavaScriptオブジェクトを自動的にJSONに文字列化してくれますが、fetchでは自分で行う必要があります。
優れたデフォルトのエラーハンドリング： AxiosはHTTPエラーステータスコード（4xx/5xxなど）をエラーとして扱い、そのPromiseはrejectされるため、catchブロックで簡単に処理できます。対照的に、fetch()はネットワークエラー時のみrejectし、HTTPエラーではrejectしません。fetchではresponse.okを確認して、ステータスが悪い場合に手動でエラーをスローする必要があります。この違いにより、Axiosは一般的なエラーケースを処理するためのボイラープレートが少なくて済みます。
簡単なタイムアウト設定： Axiosではconfigでタイムアウトを指定でき、時間がかかりすぎるとリクエストを中止します。歴史的にfetchには組み込みのタイムアウトオプションがなく、AbortControllerを作成し、タイムアウトを追跡して手動で中止する必要がありました（より冗長で忘れやすい）。
リクエスト/レスポンスインターセプター： Axiosの目玉機能の一つがインターセプターシステムです。リクエスト送信前またはレスポンス受信後（ただし.thenの前）に実行される関数を登録でき、一箇所でヘッダーの変更、グローバルエラー処理、認証トークンの挿入、ロギングなどが可能です。このミドルウェアのような機能はネイティブfetchでは提供されていません。
Node & ブラウザの統一サポート： Axiosはブラウザ（内部でXHRを使用）とNode.js（Nodeの HTTPモジュールを使用）の両方で動作するよう設計されています。2023年以前は、Fetch APIはブラウザのみネイティブだったため、Axiosを使用することで両方の環境で同じコードパスを書くことができました（Node.jsがfetchを採用したことで、これがどう変わったかは後述します）。
便利なAPI： Axiosは簡略化されたメソッド（axios.get、axios.postなど）とデータを取得するための単一の関数呼び出しを提供します。多くの開発者は、その構文がより直感的でコードがすっきりしていると感じています。例えば、AxiosのGETリクエストは、結果データをresponse.dataで得られるワンライナーにできますが、fetchでは余分なステップが必要になることがあります。要するに、AxiosはXMLHttpRequestの低レベルな詳細を抽象化し、開発者により使いやすいAPIを提供しています。
その他の利点： Axiosには組み込みのリクエストキャンセル（キャンセルトークン経由、現在はAbortControllerに合わせています）、ブラウザでのXSRFトークン処理などの自動リクエストヘッダー、XHR経由でのアップロード/ダウンロードの進捗イベントが提供されています。また歴史的に重要だったのは：Axiosは古いブラウザでも動作し（IE11もサポート可能でした）、一方fetchはIEではポリフィルが必要でした。2025年においてIE11はとうに過去のものですが、これはかつて決定的な要因でした。

簡単なリクエストについて、AxiosとFetchを並べて比較してみましょう：

// Axiosを使用（自動JSON解析、非2xx状態でエラー）
axios.get('/api/data', { timeout: 5000 })
  .then(res => {
    console.log('Data:', res.data);
  })
  .catch(err => {
    console.error('Error or timeout:', err);
  });

// Fetchを使用（手動JSON解析、手動タイムアウト＆エラー処理）
try {
  const ctrl = new AbortController();
  const id = setTimeout(() => ctrl.abort(), 5000);  // 5秒タイムアウト
  const response = await fetch('/api/data', { signal: ctrl.signal });
  clearTimeout(id);
  if (!response.ok) {
    throw new Error(`HTTP Error ${response.status}`);  // ステータスが悪い場合は手動でスロー
  }
  const data = await response.json();
  console.log('Data:', data);
} catch (err) {
  console.error('Error or timeout:', err);
}

ご覧のように、Axiosは小さな呼び出しで多くの便利さを詰め込んでいますが、fetchではタイムアウトやステータスエラーなどを手動で処理する必要があります。これらの違いがAxiosの人気を後押ししました。

2025年のモダンなFetch API：何が変わったのか？

2025年に早送りすると、WebとJSランタイムは成長しました。ネイティブのFetch APIは普及し、新しい機能を獲得して、Axiosとの機能ギャップが狭まっています。現在のモダンなfetchが提供するものを見てみましょう：

普遍的な可用性（ブラウザ＆Node）： おそらく最大の変化は、fetchが現在どこでも利用可能になったことです。Node.js v18（2022年）以降、fetch()はNode.jsに組み込まれています。つまり、React app（CSR）やNext.jsアプリ（Node上のSSR）では、クライアントとサーバーの両方で同じFetch APIをポリフィルなしで使用できます。Deno、Bun、Cloudflare Workersなどの他のランタイムもfetchをネイティブにサポートしています。サーバーサイドのリクエストを処理するためのAxiosの歴史的な必要性は大幅に減少しました - fetchは現在環境を横断する標準APIです。
標準化されたアボート＆タイムアウト： fetchは常にAbortControllerによるリクエストキャンセルを許可していましたが、最近の追加によりタイムアウトがより簡単になりました。AbortSignal.timeout(ms)メソッド（AbortController仕様の一部）は、指定されたms後に自動的にアボートする信号を返します。最新のブラウザとNodeでは、fetch(url, { signal: AbortSignal.timeout(5000) })として5秒後にタイムアウトすることができます。これは実質的にAxiosのタイムアウトオプションを1行で複製します（内部では依然としてAbortControllerですが、現在はプラットフォームに便宜上組み込まれています）。つまり、2025年には、fetchでのキャンセルとタイムアウトは数年前よりも使いやすくなっています。
ストリーミングレスポンス＆リクエストボディ： Fetch APIはWHATWG Streamsスタンダードを使用してストリーミングをすぐに利用可能です。fetch()を呼び出すと、レスポンスボディ（サーバーがチャンク形式のエンコーディングをサポートしている場合）はストリームとして消費できます（response.bodyはブラウザではReadableStreamです）。これによりデータをチャンク単位で処理できます - 大きなダウンロードやストリーミングデータ（ビデオやサーバー送信イベントなど）に便利です。Node.jsの実装では、レスポンスはNodeストリームにもできます。対照的に、AxiosはブラウザではXHRを使用しており、読み取り可能なストリームを簡単に公開していません（進捗を追跡できますが、通常はレスポンス全体を一度に取得します）。サーバー側では、Axiosはレスポンスデータ用にNodeストリームを返すことができますが、フロントエンドではfetchのストリーミング能力が高度なユースケースにおいて優位性を持ちます。つまり、fetchはフロントエンドアプリで真のHTTPストリーミングを可能にします。これはパフォーマンスやリアルタイムデータ処理において便利です。
改善されたエラーハンドリングパターン： fetchはコアの動作を変更していませんが（デフォルトでHTTPエラーステータスをスローしない）、開発者たちはそれを中心にパターンを確立しており、小さなラッパーライブラリで補うことができます。2025年では、response.okチェックやユーティリティ関数を使用してエラーハンドリングを効率化することがあります。将来的にはバッドステータスでスローするようなfetchオプションについても話題になっていますが、それがなくても、async/awaitと if (!res.ok) throwの組み合わせが必要を満たします。さらに、標準化されたAbortErrorとTimeoutError（アボート信号から）をfetchでキャッチして区別することができ、きめ細かい制御が可能です。基本的に、開発者たちはfetchレスポンスを明示的に処理することに慣れてきており、新しいAbortSignalタイムアウトはリクエストが時間を超過した場合に特定のTimeoutErrorがスローされることを意味します。
インターセプター？ これはFetch APIがまだ組み込みの同等機能を提供していない領域です。fetchにはリクエスト/レスポンスインターセプターのネイティブな概念はありません。ただし、独自のラッパー関数を作成したりサービスワーカーを使用したりすることで、同様のパターンを実現できます。例えば、すべてのリクエストに対して前処理（認証トークン用）と後処理（エラーログ用）を呼び出す小さなfetchユーティリティを作成することができます。この隙間を埋めるためのライブラリもいくつか登場しています（すぐに説明します）。しかし標準では、fetchにはaxios.interceptors.use()のようなワンライン解決策がありません。とはいえ、最新のアプリアーキテクチャでは、グローバルな懸念事項を他の方法で処理することもできます（例：認証などにReactコンテキストやReduxミドルウェアを使用するなど）。要するに： Axiosのインターセプターに大きく依存してクロスカッティングな懸念を処理している場合、fetchではその動作を複製するためにカスタムセットアップが少し必要になります。
アップロードと進捗： Axiosで依然として簡単な機能の一つ：アップロード進捗の追跡です。Axiosはブラウザでは内部的にXHRを使用するため、onUploadProgressイベントをレポートできます - ファイルアップロード中に進捗バーを表示するのに便利です。現在のFetch APIはアップロード進捗を簡単にフックする手段を提供していません（ReadableStreamボディを持つ実験的なfetch()があり手動で追跡できますが、わかりにくいです）。アプリで大規模なアップロードに関する詳細な進捗が必要な場合は、Axiosや他のXHRベースのソリューションの方が好ましいかもしれません。ダウンロード進捗については、fetchはストリーミングでき、バイトを数えられますが、ストリームAPIを利用する必要があります。AxiosはXHRでonDownloadProgressを使用でき、進捗イベントを提供します。つまり、2025年においても、進捗イベントはAxiosの小さな利点として残っていますが、多くのアプリではこれはディールブレーカーではありません。

要約すると、モダンなFetch APIはプラットフォームサポートの面で追いつき、利便性（タイムアウトの簡素化など）と強力なストリーミング機能を追加しました。ネイティブに提供されていないもの（インターセプター、自動JSON、自動エラー）は、小さなヘルパーや代替アプローチで対処できることが多いです。これは疑問を投げかけます：fetchが少し手間をかけてこれらすべてを行うことができるならば、今ではAxiosとfetchはどのように比較されるのでしょうか？

Axios vs. Fetch：長所と短所

今日の能力を考慮して、Axios対fetchを直接比較してみましょう：

Axiosを使用する利点：

機能が豊富で開発者フレンドリー： Axiosは依然として多くの機能をすぐに利用できます：自動JSONパーシング、組み込みエラーハンドリング、リクエストキャンセル、そして有名なインターセプターメカニズム。これらの機能によりボイラープレートが削減され、複雑なリクエストワークフロー（例：すべてのリクエストに認証を付加する、特定のエラーをグローバルに処理するなど）が、その配管を書かなくても簡素化されます。
一般的なタスクのコードが短い： 前述のように、Axiosの呼び出しはやや簡潔になる傾向があります。データを変換したり、各呼び出しでステータスを手動でチェックする必要はなく、内部で処理されます。これにより、特にAPIコールが多い大規模プロジェクトでは、コードの可読性と保守性が向上する可能性があります。
環境間の一貫性： Axiosはすべてのjavascript環境で同じように動作します。fetchが現在Nodeにも存在しますが、そこでは比較的新しく、古いNodeバージョンではまだポリフィルが必要かもしれません。Axiosはブラウザとノード間で同一の動作（同じデフォルトタイムアウト、エラーなど）に確信を持たせてくれます。また、ブラウザの特異性（古いHTTP機能やJSON処理の違いなど）も滑らかに処理します。
高度な設定と拡張性： Axiosは成熟したプラグインエコシステムとオプションを持っています（カスタムリクエスト/レスポンス変換器、デフォルト付きのaxiosインスタンス、テスト用のaxios-mock-adapterなど）。「事前設定された」HTTPクライアント（ベースURL、デフォルトヘッダー、ロギング用インターセプターなど）をセットアップする必要がある場合、Axiosはaxiosインスタンスを作成することで簡単に行えます。fetchでは、ラッパー関数を呼び出すかグローバルな状態に依存する必要があり、それほど整然としていません。
進捗イベント： 前述のように、アプリがブラウザでアップロード/ダウンロードの進捗をモニターする必要がある場合、Axios（内部でXHRを使用）には組み込みのフックがあります。Fetchは2025年にも直接的な同等機能がありません。そのため、大きなファイルをアップロードして進捗を表示するアプリでは、Axiosの方がシンプルかもしれません。

Fetchを使用する利点：

依存関係なし（バンドルサイズが小さい）： Fetchはブラウザ（およびNode）に組み込まれているため、使用してもバンドルに追加のキロバイトは発生しません。Axiosは、それほど大きくはないものの（ある分析によると約21.8 kB gzip圧縮）、依然として追加のライブラリです。パフォーマンスとJSの最小化が重要な時代において、ネイティブソリューションは魅力的です。「You Aren't Gonna Need It（必要になるまで作らない）」原則に従うなら、余分なライブラリを避けることは勝利です。
モダンな機能（ストリーミングなど）： fetchのストリームAPIは、Axiosでは扱いにくいユースケースを可能にします。500MBのダウンロードやリアルタイムデータ（イベントストリームやライブビデオなど）をストリーミングする必要がある場合、fetchが適しています。Axiosはデフォルトではそのほとんどをメモリにバッファリングしますが、fetchではチャンク単位で処理できます。これにより、大きなレスポンスのメモリ使用量も削減できます。
きめ細かい制御： Fetchは低レベルAPIであり、リクエストとレスポンスのすべての側面を完全に制御できます。Promiseチェーン（またはasync/awaitを使用）でリクエストのあらゆる側面を検査し、微調整できます。例えば、fetchのResponseを他のWeb API（キャッシュストレージや、再生用のクローン）に直接渡すことができます。Axiosはそれを抽象化し、通常は便利ですが、一部の高度なシナリオではfetchのプリミティブの柔軟性を好むかもしれません。
進化するWeb標準： Fetch APIはWebプラットフォームの一部として進化し続けています。AbortSignal.timeoutのような機能や、今後の標準はまずfetchに登場するでしょう。fetchを使用することで、プラットフォームの方向性に沿うことになります。時間が経つにつれて、より多くの提案（fetchアップロード進捗や組み込みリトライなど）が標準化される可能性があります。対照的に、Axiosはメンテナが追加すれば機能を実装しますが、それは余分なステップです（Axiosは最終的に1.0リリースに達し、積極的に保守されていますが、ブラウザが提供する機能の上に機能を実装します - プラットフォームが最終的に許可しないことはあまりできません）。
ほとんどのニーズに十分： おそらくfetchの最も強力な主張は、多くのプロジェクトにとって 「十分に良い」 ということです。単純なリクエスト（JSON データのGET/POST、レスポンスの処理）を行う場合、fetchは少しだけ多くのコードを必要とします。多くのフレームワークはfetchを統合するパターンを提供しています（例えば、Reactフックや、デフォルトで内部的にfetchを使用するSWR/TanStack Queryを使用するなど）。したがって、本当にAxiosの追加機能が必要でない場合は、fetchを使用することでスタックをリーンで標準的に保つことができます。

実際には、AxiosとFetchの両方が同じ基本的なタスク - APIからデータを取得すること - を達成できます。Axiosはリクエストごとに数行を節約し、いくつかの懸念事項を一元化するかもしれません。fetchはインポートとバイト数を節約するかもしれませんが、少し手作業が増えるコストがかかります。パフォーマンス面では、通常の使用ではほぼ同等です（Axiosは処理のためにわずかなオーバーヘッドがあり、fetchはネイティブですが、タイトなループ以外では違いは無視できます）。

注目すべき点：Node.js開発者はしばしばAxios対ネイティブモジュールについて議論していました。Node 18以降では、fetchが組み込まれているため、Nodeでfetchを使用することは効率的な利点があります（依存関係が1つ少なく、Nodeのネイティブ HTTPクライアント - undici - がその下にあり、非常に高速です）。Node上のFetchは非常に効率的で、場合によってはHTTP/2もサポートしています。Axios（2025年時点）はNode上ではデフォルトでHTTP/2をサポートしていませんが、Got（後述するNode HTTPライブラリ）とNode fetchはサポートしています。そのため、Nodeコンテキストでは、HTTP/2リクエストについてはfetchの方がパフォーマンス面で優位性がある場合があります。ブラウザの使用では、パフォーマンスの違いは最小限です - ネットワーク時間が支配的であり、Axios対fetchコード間の小さな処理の違いではありません。

Ky、Got、SuperAgentなど

AxiosとFetchだけが唯一の選択肢というわけではありません。あなたのニーズに応じて、人気を集めている他のHTTPクライアントライブラリやFetchラッパーもあります：

Ky: はFetchの上に構築された「小さくて洗練された」HTTPクライアントです。Kyはバッテリー内蔵のFetchと考えてください。より単純なAPIを提供し、非常に軽量（重い依存関係なし）でありながらFetchの痛点をいくつか修正しています。Kyは非2xx応答をエラーとして扱い（Axiosのようにエラー時にスローします）、組み込みの再試行ロジックがあり、タイムアウトをサポートし、リクエストとレスポンスのためのフック（インターセプターに似た）の概念も持っています。例えば、Kyではky.get(url).json()とするだけで、手動解析なしでJSONデータを一回で取得できます。また、デフォルトオプションでインスタンスを作成することも可能です。基本的に、KyはAxiosのような多くの便利な機能を提供しますが、Fetchの上に構築されており、はるかに小さなパッケージ（gzip圧縮で約4-5KB）です。トレードオフとしては、モダンな環境専用（IEサポートなしなど、現在では問題ない）であり、ユーザーベースが小さいことです。2025年時点で、Kyは約11,000のGitHubスターと週に約30万ダウンロードを持っています – Axiosと比べると控えめですが、軽量なAxios代替を求める人々のお気に入りです。
Got: はNode.js用の強力なHTTPクライアントです。ブラウザでは動作しません（Node専用）が、完全性のために：GotはしばしばNodeのrequest/axiosのより現代的な代替と見なされています。HTTP/2サポート、自動再試行、ペイロードの圧縮/解凍、グローバル処理のためのフックなどの機能に焦点を当てています。実際、Gotはパフォーマンス重視の設計と最小限のオーバーヘッドで知られており、最も高速な高レベルNode HTTPライブラリの一つです。組み込みの再試行や効率的なHTTP/2が必要なNodeスクリプトやSSRを書いている場合、Gotは素晴らしい選択肢です。2025年までにGotはNodeエコシステムでかなり人気があります（約13,000スター、月に約6,400万ダウンロード）。React開発者の場合、ブラウザでGotを使用することはありませんが、サーバーサイド（例えば、Next.jsのAPIルート）でネイティブのfetchよりもGotを好む場合に使用するかもしれません。
SuperAgent: SuperAgentは長い間存在しており（成熟したライブラリです）、Nodeとブラウザの両方でHTTPリクエストのための流暢でチェーン可能なAPIを提供します。例：request.post(url).set(headers).send(body).end(fn)。そのエレガントな構文とプラグインシステムで人気を集めました。SuperAgentは組み込みの再試行や進捗イベントなどの機能もサポートしています。より多くの低レベル制御とカスタマイズを提供します – リクエストのあらゆる部分を調整できます。2025年、SuperAgentはまだ一部で使用されており（週に約270万のnpmダウンロード、16,000スター）、多くの人がAxiosやfetchに移行しています。そのスタイルを好む場合や特定の機能が必要な場合は、有力な代替手段となりえます。例えば、SuperAgentはNodeでストリームとして機能でき（レスポンスをパイプできます）、堅牢なプラグインエコシステムを持っています。欠点は、（ブラウザで使用する場合）バンドルサイズがAxiosより大きく、アプローチが「古いスタイル」であることです。しかし、戦闘済みであり、多くの環境で「ただ動作する」ものです。
ofetch: 新しい参入者（Nuxtコミュニティから）はofetch（oh-my-fetch）です。基本的に、Axiosのような機能を提供するfetchラッパーです：自動的にJSONを解析し、HTTPエラーでスローし、timeoutオプションをサポートし、組み込みの再試行、ベースURL、クエリパラメータヘルパー、さらには独自のインターセプターのようなフック（onRequest、onResponseなど）もあります。Node、ブラウザ、Webワーカーで動作します。Nuxtを使用しているか、高度に設定可能なfetchラッパーが欲しい場合、ofetchは人気を集めています。概念的にはKy（小さく、fetchの上に構築）に似ていますが、APIが若干異なり、フレームワークとの統合に向いています（例えば、インターセプター付きのカスタムfetchインスタンスを作成するofetch.create()があります）。
Alova: 「より新しいライブラリ」の中で、Alova.jsについて聞くかもしれません。これは、Reactのような反応型フレームワークを対象とした「ワークフロー合理化リクエストライブラリ」として自らをマーケティングしています。Alovaは、データ取得をステート管理フック、キャッシング、その他のパターンと統合することで、やや異なっています（HTTPクライアントと軽量なReact Queryの組み合わせのようなもの）。広く採用されているわけではありませんが、これを宣伝する記事（例えば*「AxiosをやめてAlovaを使え」*など）を見かけたら、単にデータを取得するだけでなく、より高レベルの問題（キャッシング、反応的な更新）を解決しようとしていることを知っておいてください。興味深いプロジェクトですが、2025年時点ではAxiosの人気には程遠いです。

要約すると、エコシステムは豊かです。

fetchが単純すぎると感じるがAxiosの全重量を望まない多くの人は、中間地点としてKyまたはofetchに向かいます。高性能またはNode固有の機能が必要な人はGotを使用するかもしれません。そして古いプロジェクトはまだSuperAgentなどを使用しているかもしれません。良いニュースは、これらのライブラリはすべて非常に有能であるということです – 多くの場合、好みと特定の要件に帰着します。

結論：Axiosを使う価値はあるのか？

それでは、2025年においてもまだAxiosが必要ですか？ 答えはプロジェクトの要件と優先事項によって異なります：

Axiosを使用する場合... そのすぐに使える利便性に価値を置き、それらを使用するユースケースがある場合。大規模で複雑なアプリケーションでは、Axiosはインターセプターを通じてグローバルな懸念事項（認証トークンの添付、すべてのレスポンスのロギング、401エラー時の自動トークン更新など）を簡素化できます。もし古い環境をサポートする必要がある場合（現在ではかなり稀）や、アップロード進捗イベントが必要で良い代替手段が見つからない場合、Axiosは信頼できる選択肢です。また、チームがすでにAxiosに精通しており、うまく機能している場合は、それを取り除く緊急の理由はありません。Axiosの開発者体験 - より短く読みやすいリクエストコードと組み込みの安全装置 - により、バグが少なくなる可能性があります（例：fetchでnon-OKレスポンスの処理を忘れるなど）。その堅牢な機能セットと一貫性から、一部のガイドでは**「ほとんどの最新Webアプリケーションに推奨される選択肢」**として残っています。要するに、Axiosはまだ使用する価値があります。日常的なタスクで開発者の時間を節約する、実証済みの機能豊富なHTTPクライアントを求める場合に。
Fetch（または軽量ラッパー）を使用する場合... 標準により近く、依存関係を最小限に抑えたい場合。多くのReactアプリでは、特に現在では簡単にアボート、タイムアウト設定、ストリーミング処理ができるようになったネイティブのFetch APIで十分です。バンドルサイズとパフォーマンスが最優先の場合、Axiosを避けることで余分なライブラリを排除できます。また、よりシンプルなアプリや高度なリクエスト操作を必要としないアプリでは、fetchは物事をシンプルに保ちます。小さなヘルパーを組み込むか、Kyのような小さなライブラリを使用して反復的なタスク（JSONパーシングやエラースローなど）を処理することで - Axiosの全重量なしに改善されたDXを提供する良いミドルグラウンドを得られるかもしれません。基本的に、fetch()が少しの足場で必要の95%をカバーすると感じるなら、おそらくAxiosは必要ありません。
他の代替手段を検討する場合... ユースケースが専門的な場合。例えば、Node.js中心のサービスを構築していてHTTP/2と自動リトライが必要な場合は、Gotを検討してください。Axiosに似たAPIを持ちながらより小さいものを望むなら、Kyやofetchが優れた選択肢となります - Axiosの一部の特典（エラーのスロー、タイムアウト、フック）を完全なバンドル影響なしに提供します。そして、新しいパラダイム（tRPCやGraphQLなど）を探索している場合、データフェッチングはそれらのライブラリのクライアントによって大部分が処理される可能性があり、コード内でのfetch/Axiosの選択はあまり関連性がなくなります。

Axiosはかつてのようにフロントエンド開発において絶対的な必須品ではなくなりました - ネイティブのFetch APIが大幅にギャップを埋めています。fetch（いくつかのヘルパー付き）を使用して現代的なアプリを構築しても完全に問題ありません。しかし、Axiosは、その追加機能が複雑な要件を円滑にしたり開発者の時間を節約したりするシナリオでは、依然として「価値がある」といえます。多くの開発者が理由があって好む、実証済みの高レベルインターフェースを提供しています。

多くのチームにとって、これは好みの問題です：fetchに慣れていてミニマリズムを楽しんでいるなら、おそらくAxiosは必要ありません。便利さを求め、Axiosのパターンに慣れているなら、2025年に入ってもそれを使い続けることに問題はありません。あなたのコンテキストで長所と短所を検討してください：

小さなアプリ、モダンなスタック、最小限の依存関係？ - fetch（場合によってはKyと共に）は素晴らしい選択です。
大規模アプリ、多数のAPIコール、グローバルな処理が必要？ - Axiosは小さなコストを上回る生産性の利点を提供できます。