async/awaitの脱糖とPromiseジョブキューの実行順序

await は「止まる」のではなく「抜ける」

async/await は同期コードのように読めますが、実体は Promise とジェネレータ的なステートマシンの組み合わせです。await で「処理が止まって待つ」というイメージは、実行順を読むときに誤解を生みます。正確には、await は その関数の実行を中断して呼び出し元へ制御を返し、待っている値が解決したら マイクロタスク（Promise ジョブ）として続きを再開します。この一文がすべての実行順の根拠です。前提として イベントループの内部構造 のタスク／マイクロタスクの区別を押さえておくと、本記事の順序はそのまま導けます。

async 関数は何に脱糖されるか

ECMAScript 仕様上、async 関数は内部的に 中断・再開できるステートマシンへ変換されます。各 await が「中断点」になり、関数のローカル状態（変数や次に進むべき位置）が保存されます。概念的には、ジェネレータ（yield で中断する関数）を Promise で自動的に駆動するドライバで包んだものに等しい、と理解すると正確です。

// 元のコード
async function f() {
  const a = await g();
  return a + 1;
}

// 概念的な脱糖（擬似コード：実際の生成物ではない）
function f() {
  return new Promise((resolve, reject) => {
    let state = 0, a;
    function step(value) {
      try {
        if (state === 0) {
          state = 1;
          // await g(): g() を Promise 化し、then で続きを予約して return（＝抜ける）
          Promise.resolve(g()).then(step, reject);
          return;
        }
        if (state === 1) {            // 再開点：a に解決値が入る
          a = value;
          resolve(a + 1);             // return a + 1 に相当
        }
      } catch (e) { reject(e); }
    }
    step();                           // 初回起動：最初の await まで同期実行
  });
}

ここで決定的に重要なのは、await g() の箇所で then を登録した直後に return してドライバ関数を抜けている点です。a + 1 の行は 別の呼び出し（再開）として後から走るのであって、その場で待つわけではありません。再開を予約する手段が Promise の then なので、続きは マイクロタスクキューに積まれます。

await の後続が「いつ」走るか

await の後続が 必ずマイクロタスクとして再開されることから、setTimeout などの macrotask より先に走ることが確定します。

async function f() {
  console.log('2: await の前（同期）');
  await null;                 // ここで中断 → 呼び出し元へ戻る
  console.log('4: await の後（マイクロタスク）');
}

console.log('1: 呼び出し前');
f();                          // f は await まで同期実行して return
setTimeout(() => console.log('6: setTimeout（macrotask）'), 0);
Promise.resolve().then(() => console.log('5: 外側の then'));
console.log('3: 同期の末尾');
// 出力順: 1 → 2 → 3 → 4 → 5 → 6

f() を呼ぶと 最初の await までは同期的に走り（2）、await null の時点で f の続き（4）が マイクロタスクとして登録され、関数を抜けて呼び出し元に制御が戻ります。続く同期コード（setTimeout 登録、then 登録、そして 3）が走り、現在のタスク（スクリプト）が終了。その直後にマイクロタスクが 登録順 に消化されます。f の続き（4）は外側の then（5）より先に登録されているため、4 → 5 の順で出ます。6（macrotask）は次の反復までお預けです。ここがつまずきやすい点で、「外側の then が先に書いてあるから先に走る」のではなく、await null が f() 呼び出しの時点ですでにマイクロタスクを積んでいるため f の続きが先になります。

await が消費する「ティック数」

await は 値が即解決でも最低1ティック遅延します。何ティック遅れるかは、await 対象が Promise か否か、また仕様改定の前後で変わります。

旧仕様では await p が「内部で Promise.resolve(p) を作り、それを待つ」ため 余分なティックを消費していました。2019年の仕様改定（Await の最適化）と V8 の対応で、await p は本来の Promise を直接待つ1ホップに短縮されました。一方で 自前の thenable を await すると、then の呼び出し自体がジョブ化されるため、なお余分なティックがかかります。Promise.resolve(既存Promise) は同一 Promise を返す（ラップしない）ため、ここで二重に包む心配は不要です。

エラーは reject、try/catch は then の第2引数

脱糖を見ると、await 中に投げられた例外がどう伝わるかも明確です。await p で p が reject すると、再開時に その中断点で例外として再スローされます。脱糖コードでは then(step, reject) の第2引数（onRejected）や step 内の try/catch がこれを担います。つまり async 関数内の try { await p } catch (e) {} は、p の拒否理由を同期例外のように捕捉できます。

async function h() {
  try {
    await Promise.reject(new Error('boom'));
    console.log('ここには来ない');
  } catch (e) {
    console.log('捕捉:', e.message);   // 捕捉: boom
  }
}

逆に、async 関数が投げた（または await した Promise が reject した）まま catch しなければ、関数が返す Promise が reject 状態になります。呼び出し側が .catch も await もしなければ、未処理拒否（unhandledrejection）になります。await を「同期的な throw/return」と読めるのは、この reject ↔ throw の対応が脱糖で保証されているからです。

なぜこの仕組みが必要か（直接 then との違い）

async/await は単なる構文糖ですが、人間がマイクロタスクの分割点を意識せずに逐次フローを書ける点に価値があります。手書きの then チェーンは、各 then が新しいマイクロタスクと新しいスコープを作り、変数の引き回しやエラーハンドリングが煩雑になります。async/await はステートマシン化によって 1つの関数スコープ内に中断点を埋め込むため、ローカル変数・try/catch・ループがそのまま使えます。実行順という観点では then と等価でありながら、可読性が大きく違うわけです。JavaScript エンジンが async 関数をどう最適化するかは JavaScriptエンジンの内部 のステートマシン生成と合わせて読むと、コストの実態がつかめます。

まとめ