axios の連続 CVE を機に「脱 axios」を検討するチームが増えている。 ただし「fetch にすれば軽くなる」と短絡的に置換すると、retry / interceptor / progress 監視など axios で当然だった機能を自作することになり、結果的にコード量が増える。本記事では、axios の主要代替 5 つを 6 軸で比較し、用途別の推奨と移行コストの目安を整理する。
目次
- axios の代替候補 5 つの全体像
- 6 軸スコアカード比較表
- bundle size 実測値
- TypeScript 対応の差
- retry／interceptor／progress 機能比較
- 脆弱性履歴 2024-2026
- 用途別 推奨ライブラリ
- axios → 代替への移行コスト目安
- よくある質問（FAQ）
axios の代替候補 5 つの全体像
| ライブラリ | リリース | 主な特徴 | 主要採用例 |
|---|---|---|---|
| 標準 fetch | ブラウザ・Node.js 18+ 標準 | ゼロ依存、最小 | Next.js App Router 既定 |
| ky | 軽量で fetch ラッパー | retry／hook／TS 第一級 | Sindre Sorhus 系 OSS 採用 |
| got | Node.js 専用 | retry／pagination／HTTPS Agent 制御 | サーバ・CLI 系 |
| superagent | 古参（2011-） | プラグインエコシステム | 既存大規模システムの保守 |
| wretch | 軽量 fluent API | 直感的チェーン記法 | フロントエンド SPA |
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
6 軸スコアカード比較表
| ライブラリ | bundle | TS | retry | interceptor | 脆弱性 | エコシステム | 総合 |
|---|---|---|---|---|---|---|---|
| 標準 fetch | ◎ | ○ | ✕（自作） | ✕（自作） | ◎（CVE 0） | △ | 14/18 |
| ky | ◎ | ◎ | ◎ | ◎ | ◎ | ○ | 17/18 |
| got | △ | ◎ | ◎ | ◎ | ○ | ◎ | 16/18 |
| superagent | △ | △ | ○ | ○ | △ | ◎ | 12/18 |
| wretch | ◎ | ◎ | ○ | ○ | ◎ | ○ | 15/18 |
| axios（参考） | △ | ○ | ◎ | ◎ | ✕（CVE 多） | ◎ | 13/18 |
bundle size 実測値
| ライブラリ | min | min+gz | tree-shaken |
|---|---|---|---|
| 標準 fetch | 0 KB | 0 KB | 0 KB |
| ky | 11.2 KB | 4.0 KB | 3.2 KB |
| wretch | 8.5 KB | 3.2 KB | 2.7 KB |
| got | 88 KB | 27 KB | Node.js 専用 |
| superagent | 56 KB | 18 KB | 16 KB |
| axios | 35 KB | 13 KB | 11 KB |
TypeScript 対応の差
- ky: 第一級 TypeScript 対応。型推論が型ガード級に効く。
- got: 完全 TypeScript 化済み。レスポンス型ジェネリック対応。
- wretch: チェーンメソッドの型推論が秀逸。
- fetch: 標準型は緩い（
unknown多用）、ラッパー自作で型補強が前提。 - axios: 型は提供されるが Promise<AxiosResponse<T>> のネストで冗長。
- superagent: 型定義は外部、推論弱い。
retry／interceptor／progress 機能比較
| 機能 | fetch | ky | got | superagent | wretch | axios |
|---|---|---|---|---|---|---|
| retry | 自作 | 標準 | 標準 | プラグイン | 標準 | 標準 |
| interceptor (req/res) | 自作 | hook | hook | プラグイン | middlewares | interceptor |
| upload progress | △ | △ | ○ | ○ | △ | ◎ |
| download progress | △ | △ | ○ | ○ | △ | ◎ |
| cancel | AbortController | 標準 | 標準 | プラグイン | AbortController | CancelToken |
| timeout | AbortController | 標準 | 標準 | 標準 | 標準 | 標準 |
脆弱性履歴 2024-2026
| ライブラリ | 2024 | 2025 | 2026（4 月時点） | 累計 |
|---|---|---|---|---|
| 標準 fetch | 0 | 0 | 0 | 0 |
| ky | 0 | 1 (Low) | 0 | 1 |
| got | 1 (High) | 0 | 0 | 1 |
| superagent | 1 (Medium) | 1 (High) | 0 | 2 |
| wretch | 0 | 0 | 0 | 0 |
| axios | 2 | 2 | 2 | 6 |
用途別 推奨ライブラリ
| 用途 | 第一推奨 | 第二推奨 | 理由 |
|---|---|---|---|
| Next.js App Router (BFF) | 標準 fetch | ky | App Router の cache / revalidate と統合 |
| React SPA | ky | wretch | bundle 軽量＋retry 標準 |
| Node.js サーバ（API） | got | ky | HTTPS Agent 制御の柔軟性 |
| CLI ツール | got | ky | retry／progress の品質 |
| 既存 axios プロジェクト保守 | axios 最新版維持 | — | 移行コスト > 維持コスト |
| レガシー大規模 | superagent 維持 | — | プラグイン依存大、移行リスク高 |
axios → 代替への移行コスト目安
前提: axios 利用箇所 100 callsite、開発者 2 名
| 移行先 | 工数目安（人日） | 主作業 |
|---|---|---|
| 標準 fetch | 25-35 | retry／interceptor 自作、エラーハンドル統一 |
| ky | 15-20 | hook 移植、型再定義 |
| got | 10-15（Node.js のみ） | options 命名修正 |
| wretch | 18-25 | チェーン API への書換 |
| superagent | 30-40 | プラグイン運用学習込み |
よくある質問（FAQ）
Q. Next.js のサーバアクションでは何を使うべき？ A. App Router の標準 fetch が cache／revalidate と統合され最良。Pages Router 時代の axios は段階的に置換推奨。
Q. ky と wretch、どちらを選ぶ？ A. retry／hook を多用するなら ky、宣言的なチェーン記法を好むなら wretch。bundle size はほぼ同等。
Q. axios の interceptor 資産を捨てたくない場合は？
A. ky の hooks.beforeRequest / afterResponse で 90% は移植可能。残り 10%（CancelToken など）は AbortController に書換が必要。
参考資料
- bundlephobia.com 各ライブラリの bundle size
- npm trends による週次ダウンロード数
- NVD axios / ky / got / superagent CVE 検索結果
axios 脱却の段階的移行設計や retry／interceptor 移植支援は、GXO のフロントエンド最適化サービスで対応しています。中堅企業向けに 2-3 ヶ月の移行ロードマップ策定から実装まで支援可能です。
<!-- GXO_QUALITY_REWRITE_20260507_START -->GXO実務追記: サイバーセキュリティで発注前に確認すべきこと
この記事のテーマは、単なるトレンド紹介ではなく、自社で最初に塞ぐべきリスク、外部診断の範囲、初動体制を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。
まず決めるべき3つの論点
| 論点 | 確認する内容 | 未整理のまま進めた場合のリスク |
|---|---|---|
| 目的 | 売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか | 成果指標が曖昧になり、PoCや開発が終わっても投資判断できない |
| 範囲 | 対象部署、対象業務、対象データ、対象システムをどこまで含めるか | 見積もりが膨らむ、または重要な連携が後から漏れる |
| 体制 | 自社責任者、現場担当、ベンダー、保守運用者をどう置くか | 要件確認が遅れ、納期遅延や品質低下につながる |
費用・期間・体制の目安
| フェーズ | 期間目安 | 主な成果物 | GXOが見るポイント |
|---|---|---|---|
| 事前診断 | 1〜2週間 | 課題整理、現行確認、投資判断メモ | 目的と範囲が商談前に整理されているか |
| 要件定義 / 設計 | 3〜6週間 | 要件一覧、RFP、概算見積、ロードマップ | 見積比較できる粒度になっているか |
| PoC / MVP | 1〜3ヶ月 | 検証環境、効果測定、リスク評価 | 本番化判断に必要な数値が取れるか |
| 本番導入 | 3〜6ヶ月 | 本番環境、運用設計、教育、改善計画 | 導入後の運用責任と改善サイクルがあるか |
発注前チェックリスト
- 重要システムと個人情報の所在を棚卸ししたか
- VPN、管理画面、クラウド管理者の多要素認証を必須化したか
- バックアップの世代数、復旧時間、復旧訓練の実施日を確認したか
- 脆弱性診断の対象をWeb、API、クラウド、社内ネットワークに分けたか
- EDR/MDR/SOCの必要性を、監視できる人員と照らして判断したか
- インシデント時の連絡先、意思決定者、広報/法務/顧客対応を決めたか
参考にすべき一次情報・公的情報
上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。
GXOに相談するタイミング
次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。
- 見積もり依頼前に、要件やRFPの粒度を整えたい
- 既存ベンダーの提案が妥当か第三者視点で確認したい
- 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
- 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
- PoCや診断で終わらせず、本番導入と運用改善まで進めたい
<!-- GXO_QUALITY_REWRITE_20260507_END -->axios 代替ライブラリ 比較 2026｜fetch・ky・got・superagent・wretch を bundle size／TypeScript／脆弱性で評価を自社条件で診断したい方へ
GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。
※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。
