# ky vs Axios: どちらのHTTPクライアントを選ぶか

> ky vs Axios: 小さくモダンな fetch のwrapper vs 機能豊富なHTTPライブラリ。サイズ、API、retry、hook、CI/テストへの適合をモダンなアプリ向けに率直に比較。

Source: https://latchkey.dev/ja/learn/tool-comparisons/ky-vs-axios  
Updated: 2026-06-26

kyはretryとhookを備えた小さくモダンなfetchのwrapper、Axiosは幅広い互換性を持つ大きく機能豊富なHTTPライブラリです。

kyはネイティブの fetch API を小さくエレガントなパッケージで包み、retry、タイムアウト、hook、クリーンなメソッドAPIを追加しつつ、ESM-firstで軽量なままです。Axiosはより古く重いですが実戦で鍛えられており、interceptor、幅広い環境サポート、そして巨大なインストールベースを持ちます。kyはサイズとfetch上のモダンなエルゴノミクスで優れ、Axiosは成熟度、エコシステム、幅広い互換性で優れます。

## Comparison

|  | ky | Axios |
| --- | --- | --- |
| ベース | ネイティブfetchのwrapper | 独自のXHR/httpコア |
| Bundle size | 極小 | より大きい |
| Retry | 組み込み | plugin/configで対応 |
| 成熟度 | モダン、成長中 | 成熟、巨大なベース |
| 最適な用途 | 軽量なモダンfetchのエルゴノミクス | 幅広い互換性、機能 |

## ユースケースとエルゴノミクス

kyは、retryとhookを組み込んだ小さなfetchベースのクライアントが欲しいモダンなESMアプリに適しています。Axiosは、古い環境も含め、最大限の互換性、interceptor、広大なエコシステムを必要とするプロジェクトに適しています。kyは軽量でモダンな選択肢、Axiosは成熟して幅広く互換性のある選択肢です。

## テストとCI

どちらもMSWやnockでmockでき、kyのfetchベースはNodeのネイティブfetchと整合します。いずれもmanaged runnerで動作し、高速なrunnerはHTTP統合テストスイートを短縮します。

## Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

```Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## What actually changes when you switch

- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.

## 結論

retryとhookを備えた小さくモダンなfetchのwrapperが欲しいなら: ky。最大限の互換性、interceptor、巨大なエコシステムが欲しいなら: Axios。kyは軽さとモダンなfetchを、Axiosは成熟度と幅広さを優先します。

## FAQ

### ky vs Axios: Which HTTP Client?

ky wraps the native fetch API in a small, elegant package, adding retries, timeouts, hooks, and a clean method API while staying ESM-first and lightweight. Axios is older and heavier but battle-tested, with interceptors, wide environment support, and a huge install base.

### Use case and ergonomics?

ky suits modern ESM apps wanting a tiny fetch-based client with built-in retries and hooks. Axios suits projects needing maximum compatibility, interceptors, and a vast ecosystem, including older environments. ky is the lean modern choice; Axios is the mature, broadly compatible one.

### Testing and CI?

Both mock with MSW or nock; ky's fetch base aligns with native Node fetch. Either runs on managed runners, where faster runners shorten HTTP integration test suites.

### Which should I choose?

Want a tiny, modern fetch wrapper with retries and hooks: ky. Want maximum compatibility, interceptors, and a huge ecosystem: Axios. ky favors leanness and modern fetch; Axios favors maturity and breadth.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt