DataGridView:非同期データ更新時のクロススレッドエラーの発生原因と解決方法(サンプルあり)
📋 目次(クリックで展開)
DataGridView に表示するデータをデータベースや Web API から取得する際、画面がフリーズするのを防ぐために async/await を使った非同期処理を導入することは一般的です。
しかし、バックグラウンドスレッドで取得した結果をそのまま DataGridView(またはバインドしている BindingList など)に追加しようとすると、「有効ではないスレッド間の操作: コントロールが作成されたスレッド以外のスレッドからコントロール ‘dataGridView1’ がアクセスされました。」というエラー(InvalidOperationException)が発生してアプリが強制終了してしまうことがあります。
UIの快適性を高めようとして非同期処理を取り入れた途端にこのエラーに阻まれ、コードの書き換えに苦慮する開発者は非常に多いです。
今回は、非同期処理中にクロススレッドエラーが発生する原因と、最新の .NET 8 / .NET 10 環境に適合したスマートな解決方法について解説します。
クロススレッドエラーが発生する根本原因
Windows Forms アプリケーションには「UIスレッド(メインスレッド)」と呼ばれる、画面の描画やボタンのクリックイベントなどを専門に処理するスレッドが1つだけ存在します。
Windows Forms のルールとして、「UIコントロールの操作(描画やデータの更新)は、そのコントロールを作成したUIスレッドから行わなければならない」という絶対原則があります。
async/await を使用して Task.Run などで重い処理を別スレッド(バックグラウンドスレッド)に逃がした場合、その別スレッドから直接 DataGridView やデータソースの BindingList をいじってしまうと、この原則に違反するため、.NET が危険を検知して InvalidOperationException をスローします。
非同期処理のメリットを活かしつつ画面を更新するには、バックグラウンドで取得したデータを「安全にUIスレッドへと持ち帰る」処理が必要になります。
解決方法:IProgress または Control.Invoke の利用
古い .NET Framework 時代の記事では、Control.InvokeRequired を判定して MethodInvoker をデリゲートで呼び出すといった、複雑で視認性の低いコードがよく紹介されていました。
現代の C#(.NET 8 / 10)では、より直感的で安全な以下の2つのアプローチのいずれかを使用して解決するのがベストプラクティスです。
IProgress<T>(Progressクラス)を使用する(推奨)- .NET 標準の進捗・データ通知機能です。自動的にUIスレッドへの同期(コンテキストの委譲)を行ってくれるため、非同期ロジックの中にUIのコードを混ぜずに済み、コードが綺麗に分離できます。
- ラムダ式を用いた
Form.Invoke(またはBeginInvoke)- 一時的にUIスレッドに処理を投げたい場合に、簡潔に記述できます。
実装コード
以下は、ボタンを押したあとに非同期(バックグラウンドスレッド)で重いデータ取得処理を行い、結果を安全に DataGridView に反映するサンプルです。ここでは推奨される Progress<T> を使用したパターンを示します。
Form1.cs(画面側の処理)
using System.ComponentModel;
namespace WinFormsAsyncSample;
public partial class Form1 : Form{ private BindingList<MemberModel> _members = new();
public Form1() { InitializeComponent(); dataGridView1.DataSource = _members; dataGridView1.AutoSizeColumnsMode = DataGridViewAutoSizeColumnsMode.Fill; }
// 「非同期でデータ読み込み」ボタンのクリックイベント private async void btnLoadAsync_Click(object sender, EventArgs e) { btnLoadAsync.Enabled = false; lblStatus.Text = "データ取得中...";
// 1. UIスレッド上で Progress インスタンスを作成(コールバックを定義) var progress = new Progress<MemberModel>(newMember => { // この中だけは自動的に「UIスレッド」で実行されるため安全です _members.Add(newMember); });
// 2. バックグラウンドスレッドで重い処理を実行(Progressを渡す) await Task.Run(() => FetchDataFromDatabaseAsync(progress));
lblStatus.Text = "読み込み完了"; btnLoadAsync.Enabled = true; }
// 擬似的にデータベースやAPIからデータを取得する重い処理(別スレッドで動作) private void FetchDataFromDatabaseAsync(IProgress<MemberModel> progress) { // ネットワーク通信や重いSQLクエリの代わり(2秒待機) Thread.Sleep(2000); var data1 = new MemberModel("M001", "山田 太郎", "開発部"); progress.Report(data1); // UIスレッドへデータを届ける
Thread.Sleep(1000); var data2 = new MemberModel("M002", "佐藤 花子", "営業部"); progress.Report(data2); // UIスレッドへデータを届ける }}💡 簡潔に書きたい場合の代替案(Invokeを使う場合):
Progress<T>を使わず、その場で一瞬だけ同期させたい場合は、以下のようにラムダ式を使ってシンプルに記述することも可能です。Task.Run(() => {var data = FetchData(); // 別スレッドでの処理this.Invoke(() => _members.Add(data)); // UIスレッドに処理を戻す});
注意点
クロススレッドエラーを無理やり消そうとして、インターネットで見かけた古いTipsを安易に取り入れてしまうと、アプリケーションの品質や安全性を大きく損なう原因になります。
CheckForIllegalCrossThreadCalls = false を使う(非推奨)
// やってはいけないコード例Control.CheckForIllegalCrossThreadCalls = false;フォームの初期化時などにこの一行を入れると、.NET によるクロススレッドの監視が無効化されるため、エラーは出なくなります。しかし、複数のスレッドから同時にUIコントロールのメモリが書き換えられる危険が生じ、「原因不明のフリーズ」、「突然アプリが落ちる」、「データが稀に破損する」といった、デバッグが極めて困難な深刻なバグを誘発します。実務の開発では絶対に使用しないでください。
BindingList への追加も「UI操作」に含まれる
「DataGridView自体を触っていないから大丈夫」と考え、バックグラウンドスレッド側で _members.Add(data) を実行してしまうミスも多いです。BindingList は、要素が追加された瞬間に DataGridView へ「描き直して」というイベントを通知します。結果として DataGridView を別スレッドから触ったことになり、エラーが発生します。データソースの操作であっても、UIに紐づいているものはUIスレッド上で行う必要があります。
サンプルアプリケーション
DataGridView_Threading_Data_Update.zip
※ サンプルアプリケーションは、.NET 9 をターゲットに作成しています。
まとめ
今回は、非同期処理(async/await)から DataGridView を更新する際に発生する、クロススレッドエラーの原因と解決方法について解説しました。
業務アプリケーションの規模が大きくなるほど、ユーザーを待たせないための非同期処理と、DataGridView による大量データ表示の組み合わせは避けて通れなくなります。
一見難解に思えるスレッドの問題も、「重いデータ取得は別スレッドに任せ、最後の画面反映(リストへの追加)だけを Progress<T> や Invoke でUIスレッドに戻してあげる」 という交通整理のルールさえ押さえれば、安全に実装することができます。
画面がフリーズしない、洗練された業務システム開発の参考になれば幸いです。
💬 コメント