Python 16：非同期：JS との一番大きな違い

JS の台所は最初から開いている。Python は自分で開ける

非同期の話は、イベントループという係がいるかどうか、で全部説明できます。

レストランの台所でたとえます。料理人は1人です。

この「煮える間に他の鍋を見る料理人」がイベントループです。「待っている仕事」を覚えておき、返事が来たものから順に続きを実行する係です。料理人は1人なので、同時に手を動かすのは1つだけです。でも、待つのは何件でも同時にできます。

ネットの問い合わせは、ほとんどが「向こうの返事を待つ時間」です。料理でいえば、煮込んでいる時間です。だから、1人の料理人でも待ち時間を重ねるだけで、3皿を約1皿分の時間で出せます。

JS のコードは、ブラウザでも Node.js でも、いつもこのイベントループの中で動いています。だから JS の人は、ループの存在を意識せずに await を書けました。

Python は違います。既定ではループがありません。Python のコードは上から1行ずつ、待つときはその場で止まって待ちます。非同期にしたいときは、自分でループを作って、その上で動かす必要があります。これが JS との一番大きな違いで、この章の全部がここから出てきます。

Python は既定で「同期」：1行ずつ、待つ間も止まって待つ

まず、ふつうの Python（同期のコード）で何が起きているかをはっきりさせます。

requests.get(URL) の行を実行すると、Python は問い合わせを送り、返事が届くまでその行で止まります。返事が来てから、やっと次の行に進みます。こうして処理が止まることをブロックすると言います。

図の帯の中身は、ほとんどが「ネットの向こうの返事を待つ時間」です。Python の側でやる仕事（頼みを送る、届いた JSON を読む）は、ほんの一瞬です。つまり、3秒のうちほとんどの時間、CPU は何もせずに待っているだけです。

実際に測ってみました。第13章の requests の fetch で3都市を順に取ると、本物の Open-Meteo 相手に約2秒でした（回線や混み具合で変わります）。1都市ずつの待ちが、そのまま足し算になっています。

これは悪いことではありません。

Python の既定が同期なのは、たいていのスクリプトにはこれで足りるからです。「待ちが積み重なって困る」ときに、はじめて非同期の道具を持ち出します。

JS：スクリプトの外側に、いつもイベントループがある

比べるために、JS（Node.js）の動き方を確認しておきます。

node main.js と打つと、図の番号の順に進みます。

図の左下のコードを実際に動かすと、console.log(p) は Promise { <pending> }（まだ結果が無い約束）と表示します。fetch の返事を待たずに先へ進んだ証拠です。返事は、ファイルを最後まで実行した後で、ループが受け取って処理してくれます。

JS では、ループはあなたのコードより先に存在していて、あなたのコードはその中で動くのです。だから JS の関数はいつでも「待つ仕事をループに預けて先へ進む」ことができ、await はどこでも使える前提で言語が作られています。ES モジュール（.mjs や "type": "module"）では、ファイルの一番外側でも await が書けます（top-level await）。

ブラウザも同じです。ページを開いた瞬間からループが回っていて、クリックやタイマーや通信の返事を順に処理しています。

Python：ループは、asyncio.run(…) の間だけ存在する

Python で python3 main.py と打つと、ファイルを上から1行ずつ実行して、最後の行が終わればそのまま終了します（第1章）。途中にループはありません。

非同期で動かしたいときは、標準ライブラリの asyncio を使い、図の下のように書きます。

import asyncio

async def main():
    ...   # ここでは await が使える

asyncio.run(main())

`asyncio.run(main())` の1行が、図の上の青い区間です。ここでやっていることは3つです。

公式ドキュメントにも「この関数は必ず新しいイベントループを作り、最後に閉じる」と書かれています。つまり Python のループは、`asyncio.run` の行を実行している間だけ存在するのです。その前後は、いつもの1行ずつの世界です。

await が async def の中でしか書けないのは、このためです。async def の関数はループの上で動く前提で作られますが、ファイルの一番外側はループの外なので、「待つ仕事を預ける先」がありません。だから SyntaxError: 'await' outside function になります。

asyncio は Python に最初から付いてくる標準ライブラリなので、pip install や uv add は要りません。asyncio.run は Python 3.7 から使えます。

async def を呼んでも、中身は動かない

JS から来た人が次につまずくのが、ここです。図の左右は、同じ形の関数を Python と JS で書いて、実際に動かしたものです。

JS の async function は、呼んだ瞬間に動き始めます。最初の await に着くまでは、ふつうの関数と同じように走ります。だから fetchCity("東京") と呼んだだけで「東京: 取りに行く」が表示され、その後で Promise { <pending> } が返ってきます。

Python の async def は違います。呼んでも中身は1行も動きません。返ってくるのは コルーチン（coroutine）という物だけです。

>>> c = fetch("東京")
>>> c
<coroutine object fetch at 0x7f49ef3eaa80>

「取りに行く」は表示されていません。コルーチンは「この関数を、この引数で実行する」という予約券のようなもので、次のどちらかをされるまで眠っています。

await を付け忘れると、何も起きずに通り過ぎてしまいます。Python は最後に警告だけ出します。

RuntimeWarning: coroutine 'fetch' was never awaited

これはエラーではなく警告なので、プログラムは止まりません。「何も起きないし、エラーも出ない」という、気づきにくいバグになります。この警告を見たら、await の付け忘れを疑ってください。

ループの中 ①：asyncio.run が main() を並べる

ここからは、tenki の3都市を並べて取るコードを実行したとき、ループの中で何が起きるかを5段で追います。コードの全体は後で見せます。骨組みはこうです。

async def main():
    results = await asyncio.gather(
        fetch("東京"), fetch("大阪"), fetch("札幌"))

asyncio.run(main())

図の舞台は3つの場所です。

最初の段では、asyncio.run(main()) がループを作り、main() のコルーチンをタスクにして、左の列に並べました。

タスクは、ループが面倒を見る仕事の単位です。コルーチンを包んで、「動かす」「await で中断したら脇に置く」「返事が来たら再開する」を管理します。コルーチンが予約券なら、タスクはループの受付に出して番号札をもらった状態です。

ループの中 ②：main が動き、3つの仕事を並べる

ループは左の列の先頭から main() を取り出して、動かし始めます。中央の緑の札が main() になりました。

main() の最初の行は asyncio.gather(fetch("東京"), fetch("大阪"), fetch("札幌")) です。

fetch("東京") などを呼んだ時点では、前に見たとおり、コルーチン（予約券）ができるだけで、中身は動いていません。`asyncio.gather` は、受け取ったコルーチンをそれぞれタスクにしてループに預けます。図の左の列に、東京・大阪・札幌の3つの札が並びました。

この時点では、まだどれも動いていません。ループが動かしているのは、あくまで main() です。ループは1度に1つの仕事しか動かさないので、main() が手を離すまで、3つの札は列で順番を待ちます。

JS の Promise.all([fetchCity(…), …]) との違いもここに表れています。JS では fetchCity(…) を呼んだ時点で、それぞれ最初の await まで走り出しています（問い合わせはもう送られています）。Python では、ループに預けられて順番が来るまで、問い合わせすら送られていません。

ループの中 ③：await で手放すと、ループは次を動かす

main() の行は results = await asyncio.gather(…) でした。`await` は、「この結果が出るまで、わたしは脇で待つ。その間ループは他の仕事をしてよい」という意味です。

main() は、3つがそろうのを待つために、自分から手放しました。図では右の「待っている」に移っています。

手が空いたループは、左の列の先頭から次の仕事を取ります。東京の fetch です。中央の緑の札が「東京」になりました。

東京の fetch は、httpx で問い合わせを組み立てて送り、r = await client.get(URL, …) の行に来ます。ここでまた await です。返事が届くまで、東京も手放します。

ここが非同期の核心です。`await` は、ただ待つのではなく「ループに手を返す」場所です。同期のコードの requests.get は、返事が来るまでその場で止まり続けました。await client.get は、送ったらすぐにループへ手を返します。

ループは、1つのタスクを途中で無理やり止めることはありません。タスクが自分から await で手放したときだけ、次の仕事に切り替えます。だから、await の無い長い計算を書くと、その間ループは他の仕事を一切動かせません。

ループの中 ④：3つとも返事待ち。ループは見張るだけ

東京が手放すと、ループは大阪を動かします。大阪も問い合わせを送って await で手放し、次に札幌も同じように手放します。

図の右に、4つの札が並びました。main() は gather の完了を、東京・大阪・札幌はそれぞれネットの返事を待っています。左の列は空で、中央で実行中の仕事もありません。

このときループは、「どれかの返事が届いたら教えて」と OS に頼んで、待機しています。CPU はほとんど使っていません。

ここで、3つの問い合わせはほぼ同時にネットへ出ています。東京の返事を待つ時間、大阪の返事を待つ時間、札幌の返事を待つ時間が、重なっているのです。1つ1秒かかっても、全部で約1秒で済むのはこのためです。

言葉を整理しておきます。

asyncio がやっているのは並行です。料理人は1人のままで、煮込み時間を重ねているだけです。JS のイベントループもまったく同じ仕組みです。

ループの中 ⑤：返事が来たものから続きを動かし、全部そろう

やがて返事が届き始めます。たとえば大阪の返事が先に届けば、大阪の札が左の列に戻り、ループは大阪の fetch の await の続きから動かします。r.json() で気温を取り出し、return して、大阪のタスクは終わります。

返事が届く順番は、頼んだ順とは限りません。どの順で届いても、届いたものから続きを動かします。

3つとも終わると、gather の結果がそろいます。待っていた main() が左の列に戻り、ループが再開させます。図は、東京・大阪・札幌が「終わった」に並び、main() が実行中になった状態です。

gather の戻り値は、渡した順の list です。返事が届いた順ではありません。だから results[0] はいつも東京です。

results = await asyncio.gather(…)   # [("東京", 18.6), ("大阪", 21.9), ("札幌", 14.6)]
for city, temp in results:
    print(city, temp)

main() の最後の行まで進んで終わると、asyncio.run はループを閉じて、次の行へ進みます。ここから先は、また1行ずつの同期の世界です。

5段を1枚の表にまとめます。

並べて待つ：asyncio.gather は Promise.all

ループの中の動きを、時間の帯で見直すと図のようになります。最初の図では右へずれて並んでいた3本の帯が、左へ寄って重なりました。3都市で約3秒だったものが、約1秒になります。

`asyncio.gather` は、JS の `Promise.all` に当たります。

Python 3.11 からは、もう1つの書き方 `asyncio.TaskGroup` も使えます。

async with asyncio.TaskGroup() as tg:
    t1 = tg.create_task(fetch("東京"))
    t2 = tg.create_task(fetch("大阪"))
print(t1.result(), t2.result())

async with のブロックを抜けるときに、中で作ったタスクが全部終わるまで待ってくれます。公式ドキュメントでは、gather より安全な方法として紹介されています。どれか1つが失敗したら、残りのタスクを取り消してくれるからです。gather は1つが失敗しても、残りは動き続けます。

実際に動かすと、TaskGroup で2都市を取っても約1秒でした。どちらを使っても、待ち時間が重なる仕組みは同じです。この本では、Promise.all と形が近い gather を使います。

await できるもの・できないもの

await の右には何でも置けるわけではありません。Python の公式ドキュメントは、await できる物（awaitable）を3種類に分けています。

最後の行を実際に試すと、こう言われます（Response は requests の戻り値の型です）。

TypeError: object Response can't be used in 'await' expression

requests.get(URL) は同期の関数なので、行を実行した時点で返事を待ち終わり、ふつうの Response の物を返しています。それを後から await しても意味がありません。

JS との対応はこうです。

JS では非同期のものはほぼ全部 Promise ですが、Python では「まだ走っていないコルーチン」と「もう走っているタスク」が別の物である点が違います。asyncio.create_task(コルーチン) と書くと、コルーチンをタスクにしてループに預け、すぐに動き始めてもらえます。JS の「呼んだら走り出す」に近い形です。

time.sleep と requests は、ループごと止める

非同期で一番多い失敗がこれです。async def の中で、同期の、止まる関数を呼んでしまうことです。

async def fetch(city):
    time.sleep(1)          # ループが止まる
    requests.get(URL)      # これも止まる

time.sleep(1) や requests.get(…) は、await の無いふつうの関数です。ループに手を返さず、その場で止まります。ループは1人の料理人なので、料理人自身が鍋の前で寝てしまうのと同じで、他のタスクは誰も動かせません。

実際に、1秒の time.sleep をする async def を3つ gather で並べて測ると、3.0秒かかりました。async def と gather を使っているのに、時間の帯は図のように順番に並んだままです。しかも、エラーも警告も出ません。

JS では、こういう「止まる関数」はほとんどありません。ファイルも通信もタイマーも、最初から非同期の API しか無いか、同期版には Sync と名前に付いているからです。Python では、同期の関数のほうが標準で、非同期版は別に用意されています。何を呼ぶと止まるのかを、自分で意識する必要があります。

どうしても同期のライブラリしか無いときは、`asyncio.to_thread` で別のスレッドに逃がせます。

await asyncio.gather(*(asyncio.to_thread(fetch_sync, c) for c in CITIES))

1秒止まる同期の関数 fetch_sync（中で time.sleep(1) するもので試しました）でも、3つが約1秒で終わりました（asyncio.to_thread は Python 3.9 から）。スレッドについては、少し後で説明します。

httpx：await できる HTTP ライブラリ

requests は同期専用です。await できる版はありません。そこで非同期では、httpx というライブラリを使います。requests とほとんど同じ書き方ができるように作られていて、同期版（httpx.Client）と非同期版（httpx.AsyncClient）の両方を持っています。

tenki のフォルダで、第13章と同じように入れます。

$ uv add httpx

pyproject.toml の dependencies に httpx が書き足され、uv.lock が更新され、.venv の site-packages に httpx とその依存（httpcore、anyio など）が入ります。pip で入れるなら、venv を有効にして pip install httpx です（第11・12章）。

書き方を比べます。

`async with` は、第6章の with の非同期版です。with が __enter__ と __exit__ を呼んだように、async with は __aenter__ と __aexit__ を await しながら呼びます。ブロックを抜けるときに、開いた接続をきちんと閉じてくれます。

AsyncClient を1つ作って3都市で使い回しているのにも理由があります。同じ相手（api.open-meteo.com）への接続を使い回せるので、都市ごとに接続し直すより速くなります。

JS の fetch は最初から非同期でしたが、Python では「非同期で HTTP を使いたいなら、非同期に対応したライブラリを選ぶ」必要があります。これは HTTP に限りません。データベースのドライバなども、非同期版を別に選ぶことが多いです。

tenki に入れる：3都市を並べて取る

ここまでの内容で、tenki を書き直します。第13章の requests で1都市を取っていた処理を、httpx の非同期版にしたものです。URL は第13章と同じ Open-Meteo の住所で、都市ごとの緯度・経度は辞書 CITIES（{"東京": (35.68, 139.77), …}）にまとめました。

import asyncio
import httpx

async def fetch(client, city):
    lat, lon = CITIES[city]
    params = {"latitude": lat, "longitude": lon,
              "current": "temperature_2m"}
    r = await client.get(URL, params=params, timeout=10)
    return city, r.json()["current"]["temperature_2m"]

async def main():
    async with httpx.AsyncClient() as client:
        results = await asyncio.gather(
            *(fetch(client, c) for c in CITIES))
    for city, temp in results:
        print(city, temp)

asyncio.run(main())

*(fetch(client, c) for c in CITIES) は、都市ごとのコルーチンを作って、gather の引数として広げる書き方です（第5章の *args）。

速さの違いを、はっきり確かめるために、1回の問い合わせに必ず1秒かかる、手元の練習用サーバーを相手に測りました。

待ち時間が重なった分だけ、ほぼ3分の1になりました。都市が10個、100個と増えるほど、差は大きくなります（ただし相手のサーバーに一度に大量の問い合わせを送るのは迷惑になるので、実際には同時に送る数を絞ります）。

1つ注意があります。第14章で、[project.scripts] に tenki = "tenki.cli:main" と書きました。tenki コマンドは、この main をふつうの関数として呼ぶだけです。main が async def だと、呼ばれてもコルーチンが返るだけで、何も動きません（コルーチンの話そのままです）。

そこで、コマンドの入口の main は同期の関数のままにしておき、非同期の本体には別の名前を付けて、main の中で asyncio.run します。

async def fetch_all():
    ...   # 上の main の中身

def main():
    asyncio.run(fetch_all())

こうすれば pyproject.toml は変えずに、uv run tenki で3都市が並べて取れます。

どこで await できるか

await を書ける場所をまとめます。ルールは1つだけで、「そこでループが回っているか」です。

python -m asyncio と打つと、最初からループが回っている REPL が起動します（Python 3.8 から）。ちょっと試すのに便利です。

$ python3 -m asyncio
>>> await asyncio.sleep(1)

逆に、もうループが回っている所で `asyncio.run` を呼ぶと、エラーになります。asyncio.run は「新しいループを作る」関数ですが、1つのスレッドで同時に回せるループは1つだけだからです。

RuntimeError: asyncio.run() cannot be called from a running event loop

実際に async def の中から asyncio.run を呼んで確かめると、このメッセージが出ました。Jupyter ノートブックで asyncio.run(main()) と書いて同じエラーになるのも、同じ理由です。ループの中にいるなら、asyncio.run は要りません。await main() と書けば済みます。

スレッド・プロセスとの使い分けと、GIL の一言

「同時に進める」道具は、asyncio のほかにスレッドとプロセスがあります。ここでは使い分けの入口だけ押さえます。

スレッドは、1つのプログラムの中で、同時に動ける流れを複数持つ仕組みです。asyncio のように await で手放さなくても、OS が勝手に切り替えてくれます。だから requests のような止まる関数でも並べられます。

ここで出てくるのが GIL（Global Interpreter Lock）です。ふつうの Python（CPython）は、Python のコードを同時に実行できるスレッドを1本に限る鍵を持っています。スレッドを4本作っても、Python の計算を同時に進められるのは1本だけです。

ただし、ネットの返事やファイルを待っている間は、鍵を手放します。だから、待ちの多い仕事ならスレッドでも速くなります（前に見た asyncio.to_thread の例が約1秒になったのはこのためです）。逆に、計算そのものが重い仕事は、スレッドでは速くなりません。その場合は、鍵ごと別々のプロセス（別の Python）を立てて、CPU の芯を複数使います。

Python 3.13 では、この鍵を外した実験的な版（free-threaded ビルド）が用意されました。3.14 で正式にサポートされましたが、既定の版ではなく、別に入れる必要があります。ふだん使う Python には、まだ GIL があると考えてください。

迷ったら、まずこう考えれば十分です。待つのが多いなら asyncio、止まるライブラリしか無いならスレッド、計算が重いならプロセス。

FastAPI では、ループはフレームワークが回してくれる

次の第17章では、tenki を FastAPI の Web API にします。そこでは、asyncio.run を自分で書きません。

図の番号の順に、役割を見ます。

つまり、Web サーバーを起動した時点で、JS と同じ「最初からループがある世界」になります。あなたは async def weather(city: str): のような関数を書いて FastAPI に渡すだけで、ループの上で呼んでもらえます。ループの中なので、ここで asyncio.run を書くと、前に見た RuntimeError になります。

1つの要求で天気の返事を待っている間に、同じループが別の人からの要求を受け付けます。これが、1つのプロセスで何人もの相手をできる理由です。

逆に、async def の中で requests や time.sleep のような止まる関数を呼ぶと、ループごと止まり、他の全員が待たされます。第17章の「よくある間違い」でも、この話がもう一度出てきます。

「あなたが呼ぶ」のではなく「フレームワークが、あなたの関数を呼ぶ」という関係は、第10章で見たフレームワークの定義そのものです。ループを回すことも、フレームワーク側の仕事に含まれている、というわけです。

よくある間違いと、そのときのメッセージ

非同期のつまずきは、ほとんどが「await の忘れ」と「止まる関数を async def の中で呼ぶ」の2つに集まります。どれも、この章の中で実際に出したメッセージです。

一番怖いのは4つ目です。エラーも警告も出ず、ただ遅いだけなので、気づかないまま使い続けてしまいます。「async def の中で呼んでいる関数は、await 付きで呼んでいるか」を見直す癖をつけましょう。await の付いていない関数呼び出しで、時間がかかりそうなもの（通信・ファイル・sleep）があれば、それがループを止めています。

1つ目と5つ目は、JS の感覚のままだと起きやすい間違いです。JS では async 関数を呼べば走り出すので、await を忘れても処理自体は行われます。Python では、await を忘れると処理そのものが行われません。