なぜJavaScriptのfetchはawaitを2回しないとレスポンスを取れないのか

JavaScriptの fetch を使ったことがある人なら、こんなコードを書いたことがあると思います。

1
const resp = await fetch("https://api.example.com/data");
2
const data = await resp.json();

await を2回書いているのが気になったことはありませんか？1回の await で一気にレスポンスボディまで取れたら楽なのに、と思ったことはないでしょうか。

とある休日の午前中、いつものようにYouTube上でライブコーディング動画を見ていました¹。そこで配信者の方が、fetchを使ってレスポンスボディを取得する際に2回目のawaitが必要であることに対して、「なんでfetchはこんなにめんどくさいんだろう」と言っていました。言われてみると、確かにめんどくさいような気もします。

この記事では、なぜ fetch がこのような設計になっているのかをいろいろな観点から掘り下げてみます。

fetch の使い方おさらい

まずはJavaScriptのfetchの基本的な使い方を確認してみます。

1
// 1回目の await: レスポンスヘッダが届くまで待つ
2
const resp = await fetch("https://api.example.com/users");
3

4
// この時点でヘッダにはアクセスできる
5
console.log(resp.status);
6
console.log(resp.headers.get("Content-Type"));
7

8
// 2回目の await: レスポンスボディを読み取る
9
const users = await resp.json();

fetch() が返す Promise は、レスポンスヘッダが届いた時点で解決されます。この時点ではまだボディは読み取れていません。ボディを読むには .json() や .text(), bytes() といったメソッドを呼ぶ必要があり、これらも Promise を返すので再度 await が必要になります。

もし await が1回で済む設計だったら

「1回の await でヘッダもボディも全部取れたら便利なのに」と思うこともあると思います。以下のようなイメージです。

1
// 仮想的なAPI: 1回のawaitでボディまで取得
2
const { headers, body } = await fetch("https://api.example.com/users");

この仮想的なAPIだとどのような問題が出てくるのかを考えてみます。

問題1: 巨大なレスポンスボディ

レスポンスボディが数GBあるファイルだったらどうでしょうか？

1回の await でボディまで取得する設計だと、全データがメモリに読み込まれるまで待つことになります。時間がかかるだけでなく、メモリを大量に消費してしまいます。

現在の設計なら、ヘッダを見てからボディをストリームとして少しずつ処理できます。

1
const resp = await fetch("https://example.com/huge-file.zip");
2

3
// Content-Length を確認してから処理を決められる
4
const size = resp.headers.get("Content-Length");
5
console.log(`file size = ${size} bytes`);
6

7
// ストリームとして少しずつ処理
8
const reader = resp.body.getReader();
9
while (true) {
10
  const { done, value } = await reader.read();
11
  if (done) break;
12
  // value (Uint8Array) を少しずつ処理
13
  // 例えば、ローカルファイルに書き込んでいくなど
14
}

問題2: 終わらないストリーミングレスポンス

レスポンスボディが永遠に終わらないケースもあります。

代表例が Server-Sent Events (SSE) です。SSE はサーバーからクライアントへリアルタイムにデータをプッシュする仕組みで、ChatGPT や Claude の API でストリーミングレスポンスを受け取るときにも使われています。

1
// SSE エンドポイントへのリクエスト
2
const resp = await fetch("https://api.example.com/events");
3

4
// ストリームとして読み取る
5
const reader = resp.body.getReader();
6
const decoder = new TextDecoder();
7

8
while (true) {
9
  const { done, value } = await reader.read();
10
  if (done) break;
11

12
  const chunk = decoder.decode(value, { stream: true });
13
  console.log("received chunk:", chunk);
14
  // data: {"message": "Hello"}
15
  // data: {"message": "World"}
16
  // ...（サーバーが送り続ける限り続く）
17
}

SSE のレスポンスは、サーバーが接続を閉じるか、クライアントが明示的に中断するまで終わりません。

もし1回の await でヘッダとボディを全部取得するようになっていたら、この await はかなり長い間完了しないことになってしまいます。

JavaScript エコシステムの HTTP クライアントライブラリ

さて、fetch は「2回 await」の設計になっていますが、npm にある他の HTTP クライアントライブラリはどのような設計になっているかも見てみます。

axios

axios では1回の await でレスポンスボディまで取得できます。

1
import axios from "axios";
2

3
const resp = await axios.get("https://api.example.com/users");
4
// resp.data にはすでにパース済みの JSON オブジェクトが入っている
5
console.log(resp.data);

fetch と違う設計ですね。

では大きなファイルのダウンロードやストリーミングにはどう対応するのかというと、responseType: "stream"を指定するとOKです。

1
import axios from "axios";
2
import fs from "node:fs";
3

4
const resp = await axios.get("https://example.com/large-file.zip", {
5
  responseType: "stream",
6
});
7
resp.data.pipe(fs.createWriteStream("large-file.zip"));

fetch が「2回 await」方式を採用したのに対して、axios は「基本は1回 await だけど、レスポンスボディをストリームとして扱いたい場合はオプションを指定する」という形になっていることが分かります。

ky

READMEの先頭に

極楽要求（しなさい）²

と書いてあることで有名（？）なky はどうでしょうか。

1
import ky from "ky";
2

3
// ky では .json() を直接チェーンできる
4
const data = await ky.get("https://api.example.com/users").json();
5
console.log(data);

このように .json() や .text() を直接チェーンできるようになっていて、await は表面上1回だけで済むようになっています。

ストリーミングを扱いたい場合は fetch と同様にできます。

1
import ky from "ky";
2

3
const resp = await ky.get("https://example.com/large-file.zip");
4
const reader = resp.body.getReader();
5
// 以降は fetch と同じ

レスポンスボディだけに興味があるケース（多くのケースはこれ）に対して便利なAPIを提供しつつ、ストリーミングも自然に扱えるという意味で、個人的には良いAPIだなと感じます。

got

ky と同じ作者による、これまた人気のあるHTTPクライアントライブラリである got も見てみます。

Promise API と Stream API が用意されています。

1
import got from "got";
2

3
// Promise API: レスポンス全体をメモリに読み込む
4
const resp = await got("https://api.example.com/users");
5
console.log(resp.body); // レスポンスボディ文字列が出力される

1
import { pipeline } from "node:stream/promises";
2
import fs from "node:fs";
3
import got from "got";
4

5
// Stream API: チャンクごとに読み込む
6
await pipeline(
7
  got.stream("https://example.com/large-file.zip"),
8
  fs.createWriteStream("large-file.zip"),
9
);

axios とも ky とも少し違う感じですね。

他の言語の HTTP クライアントはどうしているか

ついでに、他言語のHTTPクライアントライブラリがどのようなAPIになっているのかも確認してみます。

Rust (reqwest)

Rust の reqwest も fetch と同じ要領で、ヘッダ取得までで1回 await、 ボディ取得で2回目の await が必要です。

1
// 1回目の await: レスポンスヘッダを取得
2
let resp = reqwest::get("https://api.example.com/data").await?;
3

4
// ヘッダにアクセス可能
5
println!("Status: {}", resp.status());
6

7
// 2回目の await: ボディを取得
8
let body = resp.text().await?;

かなり fetch に似ていますね。

Rustは await が後置なので、レスポンスボディだけに興味がある場合は、以下のようにスマートに書くこともできます。

1
let body = reqwest::get("https://api.example.com/data")
2
    .await?
3
    .text()
4
    .await?;

Python (aiohttp)

Python の aiohttp はおもしろくて、公式ドキュメントの The aiohttp Request Lifecycleというページでまさにこの問題について解説をしています。そこでは、Pythonで昔からとても人気のあるHTTPライブラリである requests との対比をすることで、aiohttpの特徴を際立たせています。コード例を引用しつつまとめてみます。

まず、aiohttpでは以下のように、fetch と同じく2回の await に分かれています。

1
async with aiohttp.ClientSession() as session:
2
    # 1回目のawait
3
    async with session.get('http://python.org') as resp:
4
        # 2回目のawait
5
        print(await resp.text())

一方で requests は次のようにシンプルです。

1
resp = requests.get('http://python.org')
2
print(resp.text)

この記事をここまで読んできたみなさんなら分かる通り、aiohttp は fetch と同じ思想で設計されています。公式ドキュメントでは次のように説明されています。

aiohttp loads only the headers when .get() is executed, letting you decide to pay the cost of loading the body afterward, in a second asynchronous operation.

つまり、.get() の時点ではヘッダだけを読み込み、その後ボディの読み込みコストを払うかどうかは開発者が後から決められるようになっているのです。非同期I/Oの利点を最大限に活かすために、ブロッキングのタイミングを明示的に分離しているわけですね。

Go (net/http)

Go は async/await の構文を持たないので少し違って見えますが、本質的には同じです。http.Client.Do() はレスポンスヘッダが届いた時点でリターンし、ボディは io.Reader として提供されます。

1
resp, err := http.Get("https://api.example.com/data")
2
if err != nil {
3
    log.Panic(err)
4
}
5
defer resp.Body.Close()
6

7
// この時点でヘッダにアクセス可能
8
fmt.Println("Status:", resp.Status)
9

10
// ボディは io.Reader として提供される
11
// io.ReadAll によってレスポンスボディが終わるまでまとめて読み取ることもできるし、
12
// bufio.Reader を使って1行ごとに読み進めていく、もできる
13
body, err := io.ReadAll(resp.Body)
14
if err != nil {
15
    log.Panic(err)
16
}

ところで5行目に defer resp.Body.Close() とあります。もしこれを忘れて、なおかつレスポンスボディを読み切らずに放置してしまうと、HTTPレスポンスを中途半端な状態で止めてしまうことになり、TCPコネクションを次のHTTPリクエストのために再利用することができなくなるなどの問題が発生します。

net/http のドキュメントにも「絶対にレスポンスボディをcloseしてね」と書かれているし、golangci-lintにもこれを検知するリントルール bodyclose があります。

JavaScriptの fetch でも同じような問題は発生するのでしょうか？つまり、レスポンスボディを読み切らなかったり、明示的なclose処理を忘れたりすると、リソースリークが発生するのでしょうか？

fetch でレスポンスボディを消費しきらなかったらどうなるか？

Fetch 仕様上は GC に頼っても OK

Fetch 仕様の Garbage collection セクションでは、レスポンスボディを消費せずに放置しても、ガベージコレクションによってリソースが解放されることが許容されています。つまり、仕様上はボディを読み切らなくても問題ないことになっています。

Node.js (undici) では GC に頼るべきではない

しかし、Node.js の fetch の内部実装である undici のドキュメントには、Garbage collection というセクションがあり、次のような警告が書かれています。

Garbage collection in Node is less aggressive and deterministic (due to the lack of clear idle periods that browsers have through the rendering refresh rate) which means that leaving the release of connection resources to the garbage collector can lead to excessive connection usage, reduced performance (due to less connection re-use), and even stalls or deadlocks when running out of connections.

ブラウザには画面描画のリフレッシュレートがあり、その合間がガベージコレクションを実行するのにちょうどいいタイミングになります。しかし Node.js にはそのような「明確なアイドル期間」がないため、GCの実行タイミングが不定期で予測しづらくなります。その結果、レスポンスボディの消費を GC 任せにしてしまうと、コネクションが過剰に使われたり、再利用がうまくいかずパフォーマンスが低下したり、最悪の場合はコネクションが枯渇してデッドロックに陥る可能性があるということです。

そのため、「必ずレスポンスボディを消費するかキャンセルするように」と注意喚起されています。Goと同じですね。

Deno ではリソースリーク検知機能がある

Deno には Resource sanitizer という機能があり、テスト実行時にリソースリークを検知してくれます。もしレスポンスボディを消費もキャンセルもせずに放置すると、テストが失敗します。

1
import { assertEquals } from "jsr:@std/assert";
2

3
Deno.test("fetch without consuming body", async () => {
4
  const resp = await fetch("https://example.com");
5
  assertEquals(resp.status, 200);
6
  // ⚠️ レスポンスボディを消費し忘れている！
7
});

エラーメッセージで教えてくれているとおり、await resp.text() などしてレスポンスボディを消費しきるようにすれば、このエラーは出なくなります。

1
import { assertEquals } from "jsr:@std/assert";
2

3
Deno.test("fetch without consuming body", async () => {
4
  const resp = await fetch("https://example.com");
5
  assertEquals(resp.status, 200);
6
  // ✅ レスポンスボディを解放する
7
  await resp.body?.cancel();
8
});

Explicit Resource Managementとの統合は？

Goだと defer resp.Body.Close() というようにして、respを取得した直後に defer を使って Close の予約をすることができました。直後に置くことで忘れにくくなるというのはもちろん、例えばレスポンスボディを読む前に何かがエラーになってその関数を抜けないといけなくなった、みたいな「異常系」の場合でも、確実に Close が呼ばれるようにできるため、優れた方法です。

JavaScriptでもGoの defer みたいなこと、やりたいですよね？あります。Explicit Resource Management です。2026年1月現在、Chrome, Firefox, Node.js (v24以降)、Deno、Bunで利用可能です。Safariはダメです。

「解放し忘れると良くない」リソース代表として、ファイルディスクリプタがあります。以下のDenoの例では、Explicit Resource Managementを活用することで、確実に file.close() が呼ばれるようにしています。たとえ await file.stat() のところで例外が発生したとしてもです。

1
async function printStat() {
2
  // using がポイント
3
  using file = await Deno.open("foo.txt");
4
  const info = await file.stat();
5
  console.log(info);
6
}

これを踏まえて考えると、以下のように fetch の戻り値に対してExplicit Resource Managementの仕組みを使えたら嬉しいような気がします。これでレスポンスボディの消費し忘れを防げます。

1
// こうできたら理想（実際はできない 2026年1月時点）
2
await using resp = await fetch("https://example.com");

ただ、これに関してはまだ議論の初期段階で、具体的な話は進んでいないように見えます。今後の進展に期待です。

• Discussion: How should streams handle Explicit Resource Management · Issue #1307 · whatwg/streams
• ECMAScript Explicit Resource Management proposal integration with web APIs · Issue #8557 · whatwg/html

まとめ

HTTP ではヘッダが先に届き、ボディは後から（場合によっては永遠に）届き続けます。fetch の2回の await はこの性質をそのまま API に落とし込んだものである、ということでした。

一方で、「ほとんどのケースではボディを全部取得したいだけなのに、毎回2回 await するのは冗長だ」という気持ちもわかります。ky のように .json() をチェーンできるAPIは、よくあるユースケースに対してのシンプルな記法を用意しつつ、レスポンスヘッダとボディを別々に取り扱うというやり方に違和感なく統合されている感じがしました。

HTTPは奥が深いです。この記事で見てきたクライアント側だけではなく、サーバー側も、ライブラリのAPI設計などから透けて見える背後の事情を理解していくのが飽きない楽しさです。またHTTPやWebの仕様について気になることがあったら、掘り下げてみます。