知識マップ: C# async/await実務判断表 - Task.RunとConfigureAwait

記事「C# async/await実務判断表 - Task.RunとConfigureAwait」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事は、C#のasync/awaitで最初に見るべきなのは処理がI/O-boundかCPU-boundかの区別であり、I/O待ちはasync APIをそのままawaitし、CPU計算はUIならTask.Run、ASP.NET Coreのリクエスト処理では避けるべきだと整理します。ConfigureAwait(false)はSynchronizationContextを持たないASP.NET Coreよりも、UIやアプリ固有コンテキストに依存しない汎用ライブラリコードで有力になります。独立した複数のI/O処理はTask.WhenAllやTask.WhenAnyで束ね、件数が多ければParallel.ForEachAsyncやSemaphoreSlimで並列数を制限し、寿命を呼び出し元から切り離したい処理はfire-and-forgetではなくChannel<T>とBackgroundServiceで管理すべきだとしています。

flowchart LR
    accTitle: C# async/awaitの実務判断の知識マップ
    accDescr: I/O-boundかCPU-boundかの見極めがTask.RunやConfigureAwait(false)の使い分け、WhenAll・WhenAny・Channelなどの選択とどうつながるかを示す図です。
    io_bound_operation["I/O-bound処理"]
    cpu_bound_operation["CPU-bound処理"]
    taskrun_dotnet["Task.Run"]
    ui_thread_context["UIスレッドのコンテキスト"]
    asp_net_core_request_thread["ASP.NET Coreのリクエスト処理"]
    sync_over_async["同期待ちの混入(sync-over-async)"]
    threadpool_starvation["スレッドプール飢餓(starvation)"]
    synchronizationcontext["SynchronizationContext"]
    configureawait_false["ConfigureAwait(false)"]
    generic_library_code["汎用ライブラリコード"]
    cancellationtoken_dotnet["CancellationToken(.NET)"]
    async_void["async void"]
    event_handler_method["イベントハンドラメソッド"]
    regular_async_method["通常の非同期メソッド"]
    task_whenall["Task.WhenAll"]
    task_whenany["Task.WhenAny"]
    parallel_foreachasync["Parallel.ForEachAsync"]
    semaphoreslim["SemaphoreSlim"]
    channel_t["Channel<T>"]
    backpressure["backpressure"]
    backgroundservice["BackgroundService"]
    ihostedservice["IHostedService"]
    fire_and_forget["fire-and-forget"]
    decoupled_background_work["呼び出し元から寿命を切り離した背景処理"]
    periodictimer["PeriodicTimer"]
    iasyncenumerable["IAsyncEnumerable<T>"]
    await_using["await using"]
    valuetask["ValueTask"]
    taskrun_dotnet -->|"用いるのは非推奨"| io_bound_operation
    taskrun_dotnet -->|"推奨される対応"| cpu_bound_operation
    taskrun_dotnet -->|"推奨される対応"| ui_thread_context
    taskrun_dotnet -->|"用いるのは非推奨"| asp_net_core_request_thread
    sync_over_async -->|"原因になり得る"| threadpool_starvation
    ui_thread_context -->|"利用する"| synchronizationcontext
    configureawait_false -->|"推奨される対応"| generic_library_code
    configureawait_false -->|"用いるのは非推奨"| ui_thread_context
    io_bound_operation -.->|"利用する"| cancellationtoken_dotnet
    async_void -->|"推奨される対応"| event_handler_method
    async_void -->|"用いるのは非推奨"| regular_async_method
    task_whenall -->|"推奨される対応"| io_bound_operation
    task_whenany -.->|"利用する"| cancellationtoken_dotnet
    parallel_foreachasync -->|"推奨される対応"| io_bound_operation
    semaphoreslim -.->|"推奨される対応"| io_bound_operation
    channel_t -.->|"利用する"| backpressure
    backgroundservice -->|"推奨される対応"| channel_t
    backgroundservice -->|"実装を担う"| ihostedservice
    fire_and_forget -->|"用いるのは非推奨"| decoupled_background_work
    channel_t -->|"推奨される対応"| decoupled_background_work
    periodictimer -->|"利用する"| cancellationtoken_dotnet
    iasyncenumerable -->|"推奨される対応"| io_bound_operation
    await_using -.->|"前提とする"| io_bound_operation
    valuetask -->|"用いるのは非推奨"| regular_async_method
    event_handler_method -.->|"前提とする"| ui_thread_context
    ihostedservice -->|"推奨される対応"| asp_net_core_request_thread

概念間の関係(全26件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• Task.RunをI/O-bound処理に用いることは推奨されません。既にasyncなI/OをTask.Runで包むのは、I/O待ちを別スレッドへ投げ直しているだけで、整理しづらくなるわりに得がない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Task.RunはCPU-bound処理に対する本記事の推奨です。Task.Runが効くのは、CPU計算を今のスレッドから外したいときである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Task.RunはUIスレッドのコンテキストに対する本記事の推奨です。WinForms/WPFなどUIイベントハンドラで重い計算をそのまま回すと画面が止まるため、Task.RunでUIスレッドから計算を外すのが素直である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Task.RunをASP.NET Coreのリクエスト処理に用いることは推奨されません。ASP.NET Coreのリクエスト処理はもともとThreadPool上で動いているため、Task.Runを挟んで直後にawaitしても余計なスケジューリングが増えるだけになりやすく、基本的に避ける / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 同期待ちの混入(sync-over-async)はスレッドプール飢餓(starvation)の原因になることがあります。Task.ResultやWait()のような同期的な待ちがコード中に混入すると、スレッドを塞ぎ続け詰まりやすくなる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• UIスレッドのコンテキストはSynchronizationContextを利用します。UIスレッドの文脈は、継続をUIスレッドへ戻すための仕組みであるSynchronizationContextとして表される。ConfigureAwait(false)は、awaitが捕捉したこのSynchronizationContextやTaskSchedulerへ継続を戻さないことを指示する記法である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ConfigureAwait(false)は汎用ライブラリコードに対する本記事の推奨です。UIやアプリモデルに依存しない汎用ライブラリコードでは、ConfigureAwait(false)は有力な選択肢である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ConfigureAwait(false)をUIスレッドのコンテキストに用いることは推奨されません。await後にUI更新やアプリ側コンテキストに依存する処理をするなら、ConfigureAwait(false)は付けないほうが自然である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• I/O-bound処理はCancellationToken(.NET)を利用します。新たに設計するI/O待ちのasync APIでは、CancellationTokenを受けてそのまま下流へ渡す設計が基本である(CancellationTokenを持たない既存APIも存在する) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• async voidはイベントハンドラメソッドに対する本記事の推奨です。async voidはシグネチャ上voidが必要なイベントハンドラだけで使い、その中でtry/catchにより例外を握ってUI側へ返す / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• async voidを通常の非同期メソッドに用いることは推奨されません。async voidは呼び出し元がawaitできず完了を待てず例外処理が難しくテストもしづらいため、イベントハンドラ以外の通常のメソッドでは避けるべきである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Task.WhenAllはI/O-bound処理に対する本記事の推奨です。独立した複数のI/O待ち処理は、1件ずつawaitするより先に全部開始してTask.WhenAllでまとめて待つほうが素直である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Task.WhenAnyはCancellationToken(.NET)を利用します。Task.WhenAnyで勝者を選び残りを止めたい実装では、CancellationTokenSourceを使い、勝者が成功と分かってから残りのタスクをキャンセルする / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Parallel.ForEachAsyncはI/O-bound処理に対する本記事の推奨です。件数が多いI/O処理では、Task.WhenAllで全件同時に投げるより、Parallel.ForEachAsyncで同時実行数の上限を明示するほうが安定する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• SemaphoreSlimはI/O-bound処理に対する本記事の推奨です。外部APIへの同時呼び出し数をより自由に制御したい場合、SemaphoreSlimで並列数の上限を作る方法もある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Channel<T>はbackpressureを利用します。Channel<T>を境界付き(bounded)で作った場合、書き込み側を待たせて増えすぎを防ぐbackpressureが働く。unboundedで使う場合は働かない。backpressure自体はChannel<T>に限らず成り立つ考え方である / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• BackgroundServiceはChannel<T>に対する本記事の推奨です。Channelに積んだ仕事を順番に処理する専用コンシューマは、アプリの起動・停止に寿命を合わせられるBackgroundServiceに置くことが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• BackgroundServiceはIHostedServiceの実装を担います。BackgroundServiceはIHostedServiceを実装した抽象クラスで、ExecuteAsync(CancellationToken)を1つオーバーライドするだけで常駐ループを書ける / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• fire-and-forgetを呼び出し元から寿命を切り離した背景処理に用いることは推奨されません。Task.Runを投げっぱなしにするfire-and-forgetは、例外をどこで見るか・終了時に待つか・件数増加への対応が曖昧になりやすく、寿命を切り離したい処理には向かない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Channel<T>は呼び出し元から寿命を切り離した背景処理に対する本記事の推奨です。呼び出し元から寿命を切り離したい仕事は、Channelに積んで専用のコンシューマが順番に処理する形のほうが例外・停止・上限を管理しやすい / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• PeriodicTimerはCancellationToken(.NET)を利用します。PeriodicTimerのWaitForNextTickAsyncはCancellationTokenを受け取り、停止時に素直に使える / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• IAsyncEnumerable<T>はI/O-bound処理に対する本記事の推奨です。ページングされたAPIやストリーミング結果など、全件そろうまで待ちたくない逐次データにはIAsyncEnumerable<T>とawait foreachが向く / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• await usingはI/O-bound処理を前提とします。破棄時にフラッシュや通信終了などの非同期処理が必要な型(IAsyncDisposable)を扱うI/O処理では、usingではなくawait usingを使う(I/O以外のIAsyncDisposable型を扱う場合にも同様に当てはまる) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ValueTaskを通常の非同期メソッドに用いることは推奨されません。ValueTaskは基本的に1回だけawaitする前提で制約があるため、日常的なアプリコードではまずTask/Task<T>で十分とされ、ValueTaskは計測して必要性が見えてから選ぶ / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• イベントハンドラメソッドはUIスレッドのコンテキストを前提とします。async voidのイベントハンドラ(例: SaveButton_Click)はUIスレッドのコンテキストで動作し、await後に_statusLabel.Textのようなコントロール操作を直接行う / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• IHostedServiceはASP.NET Coreのリクエスト処理に対する本記事の推奨です。長い処理やリクエスト寿命から切り離したい処理は、ASP.NET Coreのリクエスト処理の中で抱え込まず、キューやHostedServiceに出すほうが筋がよい / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

I/O-bound処理

HTTP、DB、ファイル、ソケットなど、外部の完了待ちが中心の処理。待っている間にスレッドを他の仕事へ返せる。

CPU-bound処理

圧縮、画像処理、ハッシュ計算、重い変換など、CPU計算そのものが中心の処理。どのスレッドで動かすかや並列数の決め方が主題になる。

Task.Run

CPUを使う処理を.NETスレッドプールのワーカースレッドへ明示的にオフロードするためのAPI。I/OバウンドのTaskに使う必要はない。

同期待ちの混入(sync-over-async)

非同期処理の継続やワーカーの中で、同期I/OやTask.Result/Wait()のような同期的な待ちを行ってしまうアンチパターン。スレッドプール飢餓の主因になる。

UIスレッドのコンテキスト

WinForms/WPFなどデスクトップアプリで、UIの応答性を保つために画面更新や重い処理の実行場所として意識されるコンテキスト。

ConfigureAwait(false)

awaitの継続を、捕捉したSynchronizationContextやTaskSchedulerへ投げ返さないことを指示する.NETの記法。「必ずスレッドプールへ移る」保証ではない。

async void

戻り値を持たないasyncメソッド。呼び出し元がawaitできず、完了を待てず、例外処理が難しくテストもしづらい。

Task.WhenAll

複数のTaskを先に全部開始してから、まとめて完了を待つ.NETのAPI。独立した複数処理を直列awaitより効率よくまとめられる。

Task.WhenAny

複数のTaskのうち最初に完了したものを返す.NETのAPI。最初に完了したタスクを返すのであって、最初に成功したタスクを返すのではない。

Parallel.ForEachAsync

MaxDegreeOfParallelismで同時実行数の上限を指定しながら、非同期処理を並列に実行できる.NETのAPI。

SemaphoreSlim

WaitAsyncで非同期に入り、Releaseで抜ける.NETの同期プリミティブ。並列数の上限指定や、awaitをまたぐ排他制御に使う。

Channel<T>

producer/consumerの形をWriteAsync/ReadAsyncで書けるキュー。境界付き(bounded)にするとbackpressureが働く。

BackgroundService

IHostedServiceの書きやすい実装補助となる抽象クラスで、長く走る本体をExecuteAsyncに書ける。

fire-and-forget

呼び出し元が完了を待たない起動方法。例外をどこで見るか、終了時に待つか、件数増加への対応が曖昧になりやすい。

PeriodicTimer

WaitForNextTickAsyncをawaitして使う、一定間隔の非同期処理向けのタイマー型。1つのタイマーに対して同時に複数のWaitForNextTickAsyncを飛ばさない前提で使う。

IAsyncEnumerable<T>

全件そろうまで待たず、届いたものから順に非同期に列挙できる.NETのインターフェース。await foreachと組み合わせて使う。

await using

破棄時にフラッシュや通信終了などの非同期処理が必要な型(IAsyncDisposable)を、非同期に破棄するための構文。

ValueTask

構造体として実装された戻り値型。基本的に1回だけawaitする前提で制約があり、計測して必要性が見えてから選ぶべきとされる。

イベントハンドラメソッド

UIフレームワークがシグネチャ上voidを要求する、ボタンクリックなどのイベントに応答するメソッド。

IHostedService

.NETの汎用ホストが、起動時にStartAsync、停止時にStopAsyncを呼んでくれる仕組み。アプリの寿命に合わせて動く常駐処理の入口。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。