C# の async/await が分かる人が TypeScript で詰まる5つ — Task と Promise の違い

みなさんこんにちは！ヒロポンです！

C# の async/await はもう手に馴染んでる。Task<T> を返して、await して、try/catch で例外を拾う。業務で何年も書いてきたやつ。

で、ある日「来週からフロント、TypeScript でよろしく」が降ってくる。

開いてみると、async/await がある。お、C# と同じやん？？……と思って書くと、これが地味に違う。

Task と Promise、見た目はそっくり。なのに、開始タイミングも例外の消え方も並行の挙動も微妙にズレてる。

そのズレを知らずに書くと、本番で「例外が出てるはずなのに何も起きない」みたいな現象でハマります。

この記事は、C# の async/await を知ってる前提で、TypeScript の Promise で詰まる5箇所を「Task ↔ Promise の対応」で翻訳する。C# の感覚を捨てずに、ズレてる行だけ上書きするのが狙いです。

まず対応マップ: C# Task と TypeScript Promise

細かい話に入る前に、全体の対応をこんな感じで1枚に。

この表の各行を、コード付きで1つずつ見ていきます。

詰まり①: Promise は生成した瞬間に走り出す

C# だと、new Task(() => ...) で作った cold な Task は Start() するまで動きません。「作る」と「動かす」が分けられる。

TypeScript の Promise に、その分離はありません。new した瞬間に中身が走ります。

const p = new Promise<void>((resolve) => {
  console.log("もう走ってる"); // ← new した時点で出力される
  resolve();
});
console.log("Promise を作った後");

// 出力順: "もう走ってる" → "Promise を作った後"

誰も await していなくても、.then() を付けていなくても、中の処理は始まってる。MDN にも「executor は Promise が構築されると同時に同期的に呼ばれる」と明記されています。

「あとで実行したい」なら、Promise を関数で包んで遅延させます。

// これなら呼ぶまで走らない (cold の代用)
const lazy = () => fetch("/api/data");
// lazy() を呼んだ瞬間に初めて走る

C# の cold Task の感覚で「まだ走ってないはず」と思ってると、ここでズレます。

詰まり②: await を忘れると例外が消える

これがいちばん怖いやつ。

C# なら、Task を返すメソッドを await し忘れると、コンパイラが CS4014 の警告を出してくれます。気づける。

TypeScript は、await を忘れても警告が出ません。

しかも、中で投げた例外が同期の try/catch に引っかからずに消えます。これがタチ悪い。

async function risky(): Promise<void> {
  throw new Error("失敗した");
}

function caller() {
  risky(); // ← await を忘れた。例外はここで捕まらない
  console.log("ここは普通に通る");
}
// "失敗した" は Unhandled promise rejection になり、
// 同期の try/catch には一切引っかからない

await を付ければ、いつもの try/catch で拾えます。

async function caller() {
  try {
    await risky(); // await して初めて例外が同期フローに乗る
  } catch (e) {
    console.log("捕まえた:", (e as Error).message);
  }
}

「例外が出てるはずなのに何も起きない」の正体は、だいたいこの await 忘れ。C# の警告に守られてた身からすると、ここは無防備に感じます。

詰まり③: Promise.all は1つこけたら全体がこける

並行実行は、C# の Task.WhenAll に当たるのが Promise.all です。でも失敗時の挙動が違う。

Task.WhenAll は、全部のタスクが終わるのを待ってから、例外をまとめて投げる。

Promise.all は、1つでも reject した瞬間に即 reject（fail-fast）。残りの完了は待ちません。

try {
  await Promise.all([ok(), fail(), ok()]);
  // fail() が reject した瞬間にここを抜けて catch へ。
  // 残りの ok() の完了は待たない
} catch (e) {
  console.log("どれか1つこけた:", (e as Error).message);
}

「全部の結果（成功も失敗も）が欲しい」なら、Promise.allSettled を使う。これが感覚的には Task.WhenAll に近い。

const results = await Promise.allSettled([ok(), fail(), ok()]);
// results[i].status が 'fulfilled' か 'rejected'。全部の結末が取れる
for (const r of results) {
  console.log(r.status);
}

実行結果:

Task.WhenAll のつもりで Promise.all を使うと、「片方こけたら、もう片方の結果が取れない」で詰まります。

詰まり④: async 関数は常に Promise を返す

C# の async Task<int> と同じで、TypeScript の async function は戻り値を常に Promise で包みます。

async function getValue(): Promise<number> {
  return 42; // return 42 でも、呼び出し側が受け取るのは Promise<number>
}

const n = await getValue(); // await して初めて number になる

await を付け忘れると、n は number ではなく Promise<number> のまま。C# でも Task<int> を await せずに使うと型が合わないので、ここは地続きです。

注意は、C# の async void に当たる投げっぱなし（fire-and-forget）。

TS でも async function を await せず呼べます。ただしその場合、中の例外が②の通り消えます。

投げっぱなしにするなら、せめて .catch() を付けて例外だけは拾っておくのが安全です。

// 投げっぱなしにするなら .catch だけは付ける
doSomethingAsync().catch((e) => console.error("拾った:", e));

詰まり⑤: ConfigureAwait に当たるものは無い

C# でライブラリを書くとき、ConfigureAwait(false) を付けて UI スレッドのデッドロックを避ける、という定番作法がありますよね。

TypeScript（JavaScript）には、これに当たるものがありません。

理由は、JS が単一スレッドのイベントループで動いてるから。C# の SynchronizationContext（元のスレッドに戻る仕組み）がそもそも無いんですよね。

const res = await fetch("/api/data");
// await の後で「元のスレッドに戻る」という概念がない。
// だから ConfigureAwait のような指定も要らない

これは「JS の方が楽」という話じゃなくて、事情が違うだけ。

JS は単一スレッドなので、逆に CPU が重い処理を裏で並列に回したいときは、Worker という別の仕組みが要ります。C# のスレッドプール感覚はそのまま持ち込めない。一長一短です。

動かして確かめる

①と②は、実際に動かすとこんな感じで一発で腑に落ちます。tsx などで TypeScript を直接実行してみてください。

// check.ts — Promise の eager 実行と await 忘れを観察する
console.log("start");
new Promise<void>((resolve) => {
  console.log("executor 実行");
  resolve();
});
console.log("end");
// 出力: start → executor 実行 → end (executor が同期で走る)

npx tsx check.ts

実行結果:

executor 実行 が end より先に出れば、「Promise は生成即実行」が体感できます！！

俺の現場メモ

C# の Task 感覚のまま TS に入ると、まず②の await 忘れで一度は事故ります。

俺もやりました。例外が出てるはずのバッチが、エラーログに何も残さず静かに失敗してる。

え、なんで止まらへんの？？ってなって、原因にたどり着くまでにけっこう時間を食った。ログには何も出てないんだから、そりゃ探すよなって。

でも、ハマったのは結局この5箇所くらい。残りの9割は「Task ↔ Promise」の対応で地続きでした。

C# で非同期を書いてきた経験は、ちゃんと効きます。ゼロから覚え直すわけじゃない。

おすすめは、こんな感じで手元に対応マップ（上の表）を置いて、ズレてる行だけ意識すること。

await 忘れに警告が出ない、Promise.all は fail-fast。この2つだけ体に入れておけば、TS の非同期で大コケすることはほぼ無くなります。

まとめ

C# の async/await 経験者が TypeScript で詰まる5つ、整理するとこうです。

• ① Promise は new した瞬間に走る — cold Task は無い。遅延は関数で包む
• ② await 忘れは警告ナシで例外が消える — Unhandled rejection。C# の CS4014 に守られてない
• ③ Promise.all は fail-fast — 全部待ちたいなら allSettled（こっちが Task.WhenAll 感覚）
• ④ async は常に Promise を返す — 投げっぱなしは .catch() で例外だけ拾う
• ⑤ ConfigureAwait は無い — JS は単一スレッドで SynchronizationContext が無いだけ

Task の知識は捨てなくていい。ズレてる5箇所だけ上書きすれば、TypeScript の非同期もいい感じに書けます。

よくある質問

Q1. C# の Task と TS の Promise、根本的に何が一番違う？

開始タイミングと await 忘れの安全網です。

Promise は new した瞬間に走り（cold が無い）、await を忘れても C# のような警告が出ません。例外は Unhandled rejection に消えます。

並行系（Task.WhenAll ↔ Promise.all）の失敗挙動も違うので、その3点を押さえれば大半は地続きです。

Q2. Promise.all と Promise.allSettled、どっちを使えばいい？

「1つでも失敗したら全体を失敗にしたい」なら Promise.all（fail-fast）。「成功も失敗も全部の結果を集めたい」なら Promise.allSettled です。

C# の Task.WhenAll の「全部終わるまで待つ」感覚に近いのは allSettled の方です。

Q3. await を付け忘れても動くなら、付けなくていい時もある？

戻り値も例外も要らない「投げっぱなし」なら付けなくても動きます。ただしその場合は .catch() で例外だけは拾ってください。

付けないと例外が Unhandled rejection になり、原因不明の静かな失敗になります。基本は await を付けるのが安全です。

Q4. C# の CancellationToken に当たるものは TS にある？

標準の Promise にキャンセルは組み込まれていません。fetch などでは AbortController を使って中断します。

C# の CancellationToken ほど統一された仕組みではないので、ライブラリごとのキャンセル手段を確認する形になります。

関連記事

• TypeScript for C#: LINQ と配列メソッドの対応表 — 同じ「C# の知識で TS を読む」シリーズ。LINQ ↔ 配列メソッドの対応
• C# WinForms で BackgroundWorker から async/await へ — C# 側の async/await・Task の基礎をおさらいしたい人向け
• C# の文字列比較 == / Equals / StringComparison でハマる3箇所 — C# の「同じ」の判定。TS の === とセットで押さえると混乱しない
• C# の using ステートメント3パターン — リソース解放の作法。async と並んで「型に守られる」C# らしさの話
• 「客先常駐しかない」業務SEが技術+αで抜ける道 — C# の知識を土台に TS まで広げられる SE は、案件の選択肢がどう変わるか。橋渡しのキャリア論

以上！

「C# の感覚で TS 書いて await 忘れた」経験ある人いたら、どんどんシェア待ってるぜ！！

---

執筆者

バイブス父さん — 業務SE 7年（SIer 正社員2 / フリーランス5）。現職は SEO 直轄部の AI アドバイザー兼 PL、副業で中小 SIer の CTO。SIer の正社員からフリーランスに転じ、複数のエージェント経由で案件を回してきた経験ベースで「業務SE視点」の技術 + キャリア記事を書いています。

🐦 X: @hiro_progra0524（日々の現場メモ更新中）
📝 About Me で経歴詳細を見る