【C#】using varの使い方とメリット。スコープによる挙動の違いを実例で解説

2026年3月10日2026年5月5日

構文・制御フロー

C#において、ファイル操作やデータベース接続、ネットワーク通信といった外部リソースを扱う際、最も重要な責務の一つが「リソースの確実な解放」です。

C# 8.0で導入されたusing宣言 (using declaration)は、従来のusingステートメントをより簡潔に、そして読みやすく記述するために設計されました。

特にusing varという形式は、現代的なC#開発において標準的なスタイルとなりつつあります。

しかし、簡潔さの裏には「スコープによる解放タイミングの変化」という重要な仕様が含まれており、これを正しく理解していないと思わぬバグやパフォーマンス低下を招く恐れがあります。

本記事では、プロフェッショナルな視点からusing varの基本概念、メリット、そして実戦で役立つスコープ管理のテクニックを詳しく解説します。

目次 [ close ]

C#におけるリソース管理とusingの進化

C#の世界では、メモリ管理はガベージコレクタ (GC) が自動で行いますが、ファイルハンドルやデータベース接続などのアンマネージリソースは、プログラム側で明示的に解放する必要があります。

これらを実現するのがIDisposableインターフェースであり、そのDisposeメソッドを確実に呼び出すための仕組みがusingです。

従来のusingステートメントの問題点

C# 7.0以前では、リソースを扱うために波括弧 { } を伴うusingステートメントが必須でした。

複数のリソースを扱う場合、コードが右へ右へと深くなる「ピラミッド型」のインデントが発生し、可読性が著しく低下するという課題がありました。

// 従来の書き方 (usingステートメント)
void LegacyProcess()
{
    using (var stream = new FileStream("test.txt", FileMode.Open))
    {
        using (var reader = new StreamReader(stream))
        {
            var content = reader.ReadToEnd();
            Console.WriteLine(content);
        } // ここでreaderがDisposeされる
    } // ここでstreamがDisposeされる
}

using宣言 (using var) の登場

C# 8.0から導入されたusing宣言は、変数の宣言の前にusingキーワードを置くだけで、その変数が属するスコープを抜ける際に自動的にDisposeを呼び出す仕組みです。

varと組み合わせることで、型推論を活かした極めてクリーンな記述が可能になります。

// C# 8.0以降 (using宣言)
void ModernProcess()
{
    using var stream = new FileStream("test.txt", FileMode.Open);
    using var reader = new StreamReader(stream);
    
    var content = reader.ReadToEnd();
    Console.WriteLine(content);
    
    // メソッドの終了時にreaderとstreamが逆順でDisposeされる
}

using varを利用する3つの大きなメリット

using varを採用することで、開発効率とコードの品質は大きく向上します。

主なメリットを3つの観点から整理しましょう。

1. ネストの解消による可読性の向上

最も分かりやすい恩恵は、インデントの削減です。

従来の方式では、3つのリソースを扱うだけでインデントが3段階深くなっていました。

using varを使えば、フラットな構造を保ったまま複数のリソースを定義できるため、ビジネスロジックそのものに集中しやすくなります。

2. 変数の有効範囲（スコープ）の明確化

using varで宣言された変数は、その宣言が含まれるブロックの終わりまで有効です。

これは「メソッド全体で使うリソース」であることを暗黙的に示すため、コードの意図が伝わりやすくなります。

また、従来のusingステートメントのように「波括弧を閉じるのを忘れる」といった構文上のミスも物理的に発生しません。

3. 型推論 var との親和性

C#では、右辺から型が明らかな場合、varを用いるのが一般的です。

using varはこの慣習に自然に適合します。

「using 型名変数名 = …」と書くよりも記述量が減り、型名の変更があった際のリファクタリングも容易になります。

実例で学ぶ：スコープによる挙動の違い

using varを使いこなす上で最も重要なのが、「Disposeが呼ばれるタイミング」の理解です。

従来のusingステートメントは波括弧を抜けた直後でしたが、using varは「その変数が定義されたブロックの末尾」で解放されます。

メソッド全体での利用

最も一般的なケースです。

メソッドの開始付近でリソースを確保し、終了時に解放します。

using System;
using System.IO;

public class ResourceDemo
{
    public void WriteLog(string message)
    {
        // メソッド内でusing宣言を使用
        using var writer = new StreamWriter("log.txt", append: true);
        writer.WriteLine($"{DateTime.Now}: {message}");
        
        Console.WriteLine("ログを書き込みました。");
        // writer.Dispose() はここで自動的に呼び出される
    }
}

任意のブロック内での利用

メソッドの途中でリソースを解放したい場合は、意図的に波括弧 { } で囲むことでスコープを限定できます。

public void ProcessData()
{
    Console.WriteLine("処理を開始します。");

    {
        // このブロック内だけで有効なリソース
        using var tempFile = new FileStream("temp.dat", FileMode.Create);
        // ... 何らかの書き込み処理 ...
        
        // tempFile.Dispose() はこの「閉じ括弧」で呼ばれる
    }

    // ここでは既にファイルは解放されているため、削除や移動が可能
    File.Delete("temp.dat");
    Console.WriteLine("一時ファイルを削除しました。");
}

using var 使用時の注意点とアンチパターン

非常に便利なusing varですが、注意を怠ると予期せぬ不具合を引き起こすことがあります。

1. リソース解放の遅延による副作用

using varはブロックの末尾までリソースを保持し続けます。

例えば、大きなファイルを読み込んだ後に重い計算処理を行う場合、using varを使うと、計算中もファイルがロックされたままになります。

不適切な例：

void LongRunningTask()
{
    using var stream = new FileStream("data.bin", FileMode.Open);
    var data = Load(stream);

    // streamは開いたまま
    DoHeavyCalculation(data); // ここで数分かかる場合、その間ファイルはロックされる
    
} // ここでやっと解放

このような場合は、従来のusingステートメントを使用するか、前述のように波括弧でスコープを明示的に区切るべきです。

2. nullチェックとの兼ね合い

using varに渡すオブジェクトが null の場合、Dispose は呼び出されず、例外も発生しません。

これは従来のusingと同様の挙動ですが、varを使っていると「その変数がnullになり得るかどうか」という視点が抜け落ちがちです。

ファクトリメソッドなどからリソースを取得する場合は注意が必要です。

3. 非同期リソース解放 (await using)

I/O操作など、解放処理自体を非同期で行いたい場合はawait using varを使用します。

これはIAsyncDisposableを実装しているクラスに対して有効です。

public async Task SaveAsync(Stream data)
{
    // 非同期Disposeをサポートするリソースの宣言
    await using var connection = new MyDbConnection();
    await connection.OpenAsync();
    
    // ... 処理 ...
    
    // 非同期でDisposeAsyncが呼ばれる
}

応用編：複数のリソースをスマートに扱う

実務では、一つのメソッド内で複数のリソースを組み合わせることが多々あります。

using varを使うことで、それらの依存関係をフラットに記述できます。

public void CopyAndEncrypt(string sourcePath, string destPath)
{
    // 複数のリソースを並べて記述
    using var sourceStream = new FileStream(sourcePath, FileMode.Open);
    using var destStream = new FileStream(destPath, FileMode.Create);
    using var encryptor = CreateMyEncryptor();

    // 読み込みと書き込みのパイプライン処理
    sourceStream.CopyTo(destStream);
    
    // 解放は宣言の逆順（encryptor -> destStream -> sourceStream）で行われる
}

このように、スタック構造でリソースが管理されるため、依存関係があるオブジェクト同士でも安全に解放順序が保証されます。

パフォーマンスとコンパイル後の姿

using varは「シンタックスシュガー（糖衣構文）」です。

コンパイラはこれを、従来のtry-finallyブロックに変換します。

そのため、実行時のパフォーマンスにおいて従来のusingと差が出ることはありません。

内部的なコード変換イメージ

あなたが書いたコード：

using var resource = new MyResource();
resource.DoSomething();

コンパイラが生成するコード（概念）：

MyResource resource = new MyResource();
try
{
    resource.DoSomething();
}
finally
{
    if (resource != null)
    {
        ((IDisposable)resource).Dispose();
    }
}

この仕組みがあるからこそ、途中で例外が発生したとしても、確実にfinally節でリソースが解放されるという安心感が得られるのです。

using var を使うべきか、using ステートメントを使うべきか

どちらを使うべきか迷った際のガイドラインを提示します。

状況	推奨される記述	理由
メソッドの最後までリソースを使う	`using var`	最も簡潔で読みやすいため。
リソースを早期に解放したい	`using (...) { }`	スコープを視覚的に限定できるため。
複数のリソースを順次生成する	`using var`	ネストが深くならず、ロジックが見やすいため。
古いC#バージョンとの互換性が必要	`using (...) { }`	C# 8.0未満の環境では`using var`はコンパイルエラーになるため。