C#でignore（無視）する方法まとめ｜警告・例外・JSONプロパティ・ファイル除外まで解説

はじめに

C#で「ignore（無視）」したい場面は、実はひとつではありません。

たとえば、C#の開発中には次のような「無視したい」がよく出てきます。

• コンパイル警告を一時的に無視したい

• 特定の例外だけを握りつぶしたい

• JSONに出力したくないプロパティがある

• 使わない戻り値や引数を無視したい

• Gitでbinやobjフォルダを管理対象外にしたい

• AnalyzerやStyleCopの警告を抑制したい

• 一部のテストを実行対象から外したい

しかし、C#にはすべての場面で使える共通のignoreキーワードがあるわけではありません。目的によって、#pragma warning disable、[JsonIgnore]、_、.gitignore、.csproj、.editorconfig、[Ignore]など、使う方法が変わります。

この記事では、「c# ignore」で調べている人に向けて、C#で何かを無視したいときの代表的な方法を目的別に整理して解説します。

1. C#で「ignore（無視）」したい場面と検索意図

1-1. 「c# ignore」で調べる人が知りたいこと

「c# ignore」と検索する人の多くは、C#の文法そのものよりも、開発中に出てきた何かを「対象外にしたい」「警告を消したい」「処理しないようにしたい」という意図を持っています。

代表的には、次のような検索意図があります。

同じ「ignore」でも、何を無視したいかによって正しい方法は大きく変わります。

1-2. 警告・例外・JSON・ファイル除外で意味が変わる「ignore」

C#における「ignore」は、文脈によって意味が変わります。

たとえば、コンパイル警告をignoreしたい場合は、コードの一部に対して警告を無効化します。

C#
#pragma warning disable CS0168
try
{
    // 何らかの処理
}
catch (Exception ex)
{
    // exを使わない
}
#pragma warning restore CS0168

JSONのプロパティをignoreしたい場合は、属性を使ってシリアライズ対象から除外します。

C#
using System.Text.Json.Serialization;

public class User
{
    public string Name { get; set; } = "";

    [JsonIgnore]
    public string Password { get; set; } = "";
}

Gitでファイルをignoreしたい場合は、C#のコードではなく.gitignoreに書きます。

gitignore
bin/
obj/
.vs/
*.user

このように、「C#でignoreする」といっても、C#の構文、属性、設定ファイル、ビルド設定、Git設定など、複数のレイヤーがあります。

1-3. C#に共通の「ignore構文」はあるのか

C#には、JavaScriptやPythonのように「この値を完全に無視する」という共通のignoreキーワードはありません。

ただし、C#には「破棄」を表す_があります。

C#
_ = SomeMethod();

この書き方は「戻り値を意図的に使わない」ことを示すときに使えます。

また、out引数を無視したい場合にも使えます。

C#
int.TryParse("123", out _);

ただし、_は主に「値を使わない」ことを表すためのものであり、警告、例外、JSON、ファイル除外などをすべて処理できるわけではありません。

1-4. 目的別に使うべきignore方法の早見表

C#で何かをignoreしたい場合は、まず「何を無視したいのか」を明確にすることが重要です。

以降では、それぞれの方法を具体的に解説します。

2. C#でコンパイル警告をignore（無視）する方法

2-1. #pragma warning disableで特定の警告を無視する

C#でコンパイル警告を一時的に無視したい場合は、#pragma warning disableを使います。

C#
#pragma warning disable CS0168

try
{
    // 何らかの処理
}
catch (Exception ex)
{
    // exを使っていないため CS0168 が出る可能性がある
}

#pragma warning restore CS0168

CS0168は「変数が宣言されているが使用されていない」という警告です。

#pragma warning disableの後に警告番号を指定すると、その警告だけを無効化できます。

C#
#pragma warning disable CS0219
int count = 10;
#pragma warning restore CS0219

CS0219は「変数に値が割り当てられているが使用されていない」という警告です。

特定の理由があって警告を消したい場合は、警告番号を指定して範囲を限定するのが基本です。

2-2. #pragma warning restoreで警告の無効化範囲を戻す

#pragma warning disableを使ったら、できるだけ近い位置で#pragma warning restoreを使って元に戻します。

悪い例です。

C#
#pragma warning disable CS0168

public class Sample
{
    public void Method1()
    {
        try
        {
        }
        catch (Exception ex)
        {
        }
    }

    public void Method2()
    {
        int value = 10;
    }
}

このように、ファイルの途中で警告を無効化したままにすると、本来気づくべき警告まで隠れてしまう可能性があります。

良い例です。

C#
public class Sample
{
    public void Method1()
    {
#pragma warning disable CS0168
        try
        {
        }
        catch (Exception ex)
        {
        }
#pragma warning restore CS0168
    }
}

または、警告が出ない書き方に変えるほうがよい場合もあります。

C#
try
{
    // 何らかの処理
}
catch (Exception)
{
    // 例外変数を使わないなら変数名を書かない
}

この場合、exを宣言していないため、未使用変数の警告自体が発生しません。

2-3. CS0168・CS0219など警告番号を指定して無視する例

C#でよく見かける警告には、次のようなものがあります。

たとえば、非推奨APIを一時的に使う必要がある場合は、CS0618を無視できます。

C#
#pragma warning disable CS0618

OldMethod();

#pragma warning restore CS0618

ただし、非推奨APIの警告は、将来的な削除や互換性の問題を知らせていることがあります。警告を無視する前に、代替APIがないか確認するべきです。

複数の警告をまとめて無視することもできます。

C#
#pragma warning disable CS0168, CS0219

int unusedValue = 10;

try
{
}
catch (Exception ex)
{
}

#pragma warning restore CS0168, CS0219

2-4. ファイル全体で警告を無視する方法

ファイル全体で特定の警告を無視したい場合は、ファイルの先頭に#pragma warning disableを書きます。

C#
#pragma warning disable CS1591

namespace MyApp.Models;

public class User
{
    public int Id { get; set; }

    public string Name { get; set; } = "";
}

この例では、XMLコメント不足の警告であるCS1591をファイル全体で無視しています。

ファイル全体で無視する方法は、次のようなケースで使われることがあります。

• 自動生成コード

• 外部ツールが生成するコード

• 一時的な移行中のコード

• XMLコメントを必須にしているが、一部のDTOだけ対象外にしたい場合

ただし、ファイル全体で警告を無視すると、意図しない警告も見逃しやすくなります。可能であれば、対象範囲を小さくするのが安全です。

2-5. プロジェクト全体で警告を無視する方法

プロジェクト全体で特定の警告を無視したい場合は、.csprojにNoWarnを設定します。

XML
<PropertyGroup>
  <NoWarn>$(NoWarn);CS1591</NoWarn>
</PropertyGroup>

複数の警告を無視する場合は、セミコロンで区切ります。

XML
<PropertyGroup>
  <NoWarn>$(NoWarn);CS1591;CS0168;CS0219</NoWarn>
</PropertyGroup>

$(NoWarn)を残しておくことで、既存の設定を維持しながら警告を追加できます。

特定のビルド構成だけで警告を無視したい場合は、条件を付けることもできます。

XML
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
  <NoWarn>$(NoWarn);CS1591</NoWarn>
</PropertyGroup>

ただし、プロジェクト全体で警告を無視すると、すべてのファイルに影響します。個別の警告を本当に全体で無視してよいかは慎重に判断しましょう。

2-6. .editorconfigで警告レベルを調整する方法

.editorconfigを使うと、C#コンパイラやAnalyzerの警告レベルをルールごとに調整できます。

たとえば、CA1822を無視したい場合は次のように書きます。

INI
dotnet_diagnostic.CA1822.severity = none

CS1591を無視したい場合は次のように書けます。

INI
dotnet_diagnostic.CS1591.severity = none

警告として表示したい場合はwarningにします。

INI
dotnet_diagnostic.CA1822.severity = warning

エラーとして扱いたい場合はerrorです。

INI
dotnet_diagnostic.CA1822.severity = error

主な設定値は次のとおりです。

.editorconfigはチームで共有しやすいため、個人のIDE設定で無視するよりも、プロジェクトとしてルールを統一しやすいのがメリットです。

2-7. 警告を無視してはいけないケース

警告はエラーではないため、ビルド自体は通ることがあります。しかし、警告を安易に無視すると、不具合の原因を見逃す可能性があります。

特に、次の警告は慎重に扱うべきです。

• null参照に関する警告

• 非同期処理の待機漏れ

• 到達不能コード

• 例外の握りつぶしに関する警告

• セキュリティ関連のAnalyzer警告

• 非推奨APIの使用警告

• 未使用変数がロジックミスを示している場合

たとえば、次のコードは一見問題なさそうですが、Taskを待機していません。

C#
public void Save()
{
    SaveAsync();
}

このような警告を無視すると、非同期処理が完了しない、例外が捕捉されない、処理順序が崩れるなどの問題につながります。

警告をignoreする前に、「警告を消す」のではなく「コードを直せないか」を先に検討しましょう。

3. C#で例外をignore（握りつぶす）する方法

3-1. try-catchで例外を捕捉して無視する基本形

C#で例外を無視するには、try-catchで例外を捕捉し、catch内で何もしない方法があります。

C#
try
{
    File.Delete("temp.txt");
}
catch
{
    // 例外を無視する
}

ただし、このような空のcatchは基本的に推奨されません。どんな例外が起きても無視してしまうため、重大な不具合に気づけなくなるからです。

最低限、無視してよい理由をコメントで残すべきです。

C#
try
{
    File.Delete("temp.txt");
}
catch
{
    // 一時ファイルの削除に失敗しても処理継続に影響しないため無視する
}

より安全なのは、無視してよい例外の種類を限定することです。

3-2. 特定の例外だけを無視する方法

例外をignoreする場合は、できるだけ特定の例外だけを捕捉します。

C#
try
{
    File.Delete("temp.txt");
}
catch (FileNotFoundException)
{
    // ファイルが存在しない場合は削除済みとみなして無視する
}

この例では、ファイルが存在しない場合だけを無視しています。

catch (Exception)のようにすべての例外を捕捉すると、権限エラー、パスの不正、ディスク障害など、本来対処すべき例外まで隠れてしまいます。

悪い例です。

C#
try
{
    File.Delete(path);
}
catch (Exception)
{
    // 何でも無視してしまう
}

良い例です。

C#
try
{
    File.Delete(path);
}
catch (FileNotFoundException)
{
    // すでに存在しない場合は問題ない
}
catch (DirectoryNotFoundException)
{
    // ディレクトリが存在しない場合も削除済みとみなす
}

例外を無視するなら、「その例外が起きてもアプリケーションとして問題ない」と説明できる範囲に限定しましょう。

3-3. catch whenで条件付きで例外を無視する

catch whenを使うと、条件に一致する場合だけ例外を捕捉できます。

C#
try
{
    File.Delete(path);
}
catch (IOException ex) when (ex.Message.Contains("別のプロセス"))
{
    // 別プロセスが使用中の場合だけ無視する
}

ただし、例外メッセージに依存する条件は、環境や言語によって変わる可能性があるため注意が必要です。

より実用的な例として、キャンセル時の例外だけを無視するケースがあります。

C#
try
{
    await Task.Delay(5000, cancellationToken);
}
catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested)
{
    // 明示的なキャンセルなので無視する
}

このように、catch whenは「例外の種類だけでは判断できないが、条件付きで無視したい」場合に便利です。

3-4. 空のcatchが危険な理由

空のcatchは、C#で例外をignoreする最も簡単な方法ですが、最も危険な方法でもあります。

C#
try
{
    SaveData();
}
catch
{
}

このコードでは、SaveDataでどんな問題が起きても無視されます。

たとえば、次のような問題が起きても気づけません。

• ファイル保存に失敗している

• データベース接続に失敗している

• 権限不足で書き込めない

• null参照が発生している

• 想定外のバグが発生している

結果として、「画面上は成功したように見えるが、実際には保存されていない」といった不具合につながります。

空のcatchを書く場合は、少なくとも次の条件を満たすべきです。

• 無視してよい例外が明確である

• 無視してもデータ不整合が起きない

• ユーザー体験に影響しない

• ログ不要と判断できる理由がある

• コメントで意図が説明されている

基本的には、空のcatchよりもログを残す方法を検討しましょう。

3-5. ログを残して安全に例外を無視する方法

例外を完全に無視するのではなく、ログを残して処理を継続する方法が安全です。

C#
try
{
    File.Delete(path);
}
catch (IOException ex)
{
    logger.LogWarning(ex, "一時ファイルの削除に失敗しました: {Path}", path);
}

このコードでは、削除に失敗しても処理は継続しますが、ログには原因が残ります。

ユーザーに見せる必要はないが、開発者や運用担当者が後から確認したい場合に有効です。

ログレベルも使い分けましょう。

「無視する」といっても、運用上必要な情報まで消さないことが重要です。

3-6. 例外を無視するより戻り値で制御すべきケース

例外は、通常ではないエラー状態を表現するための仕組みです。通常の分岐として頻繁に発生するものは、例外を無視するより戻り値で制御したほうがよい場合があります。

たとえば、数値変換ではint.Parseよりint.TryParseを使うほうが安全です。

C#
if (int.TryParse(text, out var value))
{
    Console.WriteLine(value);
}
else
{
    Console.WriteLine("数値ではありません");
}

戻り値を使って成否を判断できるAPIがあるなら、例外を握りつぶすよりもそちらを優先しましょう。

ファイル存在チェックも同様です。

C#
if (File.Exists(path))
{
    File.Delete(path);
}

ただし、ファイル操作ではチェック後に別プロセスがファイルを変更する可能性があるため、最終的には例外処理も必要になることがあります。

C#
try
{
    File.Delete(path);
}
catch (FileNotFoundException)
{
    // チェック後に削除されていた場合は無視
}

「例外をignoreする」のではなく、「例外を使うべき場面か」を考えることが大切です。

4. C#でJSONプロパティをignoreする方法

4-1. System.Text.Jsonの[JsonIgnore]でプロパティを除外する

C#でJSONの特定プロパティを無視したい場合、System.Text.Jsonでは[JsonIgnore]属性を使います。

C#
using System.Text.Json;
using System.Text.Json.Serialization;

public class User
{
    public int Id { get; set; }

    public string Name { get; set; } = "";

    [JsonIgnore]
    public string Password { get; set; } = "";
}

このクラスをシリアライズすると、PasswordはJSONに出力されません。

C#
var user = new User
{
    Id = 1,
    Name = "Taro",
    Password = "secret"
};

string json = JsonSerializer.Serialize(user);

Console.WriteLine(json);

出力例です。

JSON
{"Id":1,"Name":"Taro"}

パスワード、トークン、内部管理用プロパティなど、外部に出したくない値に使います。

C#
public class ApiResponse
{
    public string Message { get; set; } = "";

    [JsonIgnore]
    public string InternalCode { get; set; } = "";
}

[JsonIgnore]は、APIレスポンスやログ出力で機密情報を除外したい場合にもよく使われます。

4-2. JsonIgnoreConditionでnullや既定値だけ無視する

System.Text.Jsonでは、JsonIgnoreConditionを使って条件付きでプロパティを無視できます。

nullの場合だけ無視する例です。

C#
using System.Text.Json.Serialization;

public class User
{
    public string Name { get; set; } = "";

    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    public string? Nickname { get; set; }
}

Nicknameがnullの場合、JSONには出力されません。

C#
var user = new User
{
    Name = "Taro",
    Nickname = null
};

出力例です。

JSON
{"Name":"Taro"}

既定値の場合だけ無視するには、WhenWritingDefaultを使います。

C#
public class Product
{
    public string Name { get; set; } = "";

    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingDefault)]
    public int Stock { get; set; }
}

intの既定値は0なので、Stockが0の場合はJSONに出力されません。

プロパティ単位ではなく、全体設定としてnullを無視したい場合は、JsonSerializerOptionsを使います。

C#
var options = new JsonSerializerOptions
{
    DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
};

string json = JsonSerializer.Serialize(user, options);

全体設定を使うと、対象オブジェクト内のすべてのnullプロパティに影響します。特定のプロパティだけ無視したい場合は、属性を使うほうが分かりやすいです。

4-3. Newtonsoft.Jsonの[JsonIgnore]でプロパティを除外する

C#では、Newtonsoft.Jsonを使っているプロジェクトも多くあります。Newtonsoft.Jsonでも[JsonIgnore]属性でプロパティを除外できます。

C#
using Newtonsoft.Json;

public class User
{
    public int Id { get; set; }

    public string Name { get; set; } = "";

    [JsonIgnore]
    public string Password { get; set; } = "";
}

シリアライズ例です。

C#
var user = new User
{
    Id = 1,
    Name = "Taro",
    Password = "secret"
};

string json = JsonConvert.SerializeObject(user);

Console.WriteLine(json);

出力例です。

JSON
{"Id":1,"Name":"Taro"}

注意点として、System.Text.Json.Serialization.JsonIgnoreAttributeとNewtonsoft.Json.JsonIgnoreAttributeは別物です。

System.Text.Jsonを使っているのに、間違ってNewtonsoft.Json側のJsonIgnoreを付けると、期待通りに無視されないことがあります。

C#
// System.Text.Jsonを使う場合
using System.Text.Json.Serialization;

// Newtonsoft.Jsonを使う場合
using Newtonsoft.Json;

プロジェクトでどちらのJSONライブラリを使っているかを確認しましょう。

4-4. 読み取り専用・書き込み専用プロパティを無視する方法

読み取り専用プロパティをJSONに含めたくない場合は、[JsonIgnore]を付けるのが分かりやすい方法です。

C#
using System.Text.Json.Serialization;

public class Order
{
    public int Quantity { get; set; }

    public int UnitPrice { get; set; }

    [JsonIgnore]
    public int TotalPrice => Quantity * UnitPrice;
}

この例では、TotalPriceは計算用のプロパティなのでJSONには出力しません。

System.Text.Jsonでは、オプションで読み取り専用プロパティをまとめて無視することもできます。

C#
var options = new JsonSerializerOptions
{
    IgnoreReadOnlyProperties = true
};

string json = JsonSerializer.Serialize(order, options);

ただし、この設定はすべての読み取り専用プロパティに影響するため、必要なプロパティまで消えてしまわないよう注意が必要です。

書き込み専用プロパティは、そもそもシリアライズ時に値を読み取れないため、JSON出力には向きません。APIの入力専用プロパティと出力専用プロパティを分けたい場合は、DTOを分ける設計も検討しましょう。

C#
public class CreateUserRequest
{
    public string Name { get; set; } = "";

    public string Password { get; set; } = "";
}

public class UserResponse
{
    public int Id { get; set; }

    public string Name { get; set; } = "";
}

入力用と出力用を分けると、JsonIgnoreに頼りすぎず、安全で分かりやすい設計になります。

4-5. シリアライズ時だけ無視したい場合の考え方

「JSONに出力するときだけ無視したいが、読み込み時には受け取りたい」というケースがあります。

たとえば、リクエストでは受け取るが、レスポンスでは返したくないパスワードなどです。

C#
public class UserDto
{
    public string Name { get; set; } = "";

    public string Password { get; set; } = "";
}

このような場合、同じDTOを入力と出力で使い回すと、Passwordをどう扱うかが曖昧になります。

安全な設計は、入力用DTOと出力用DTOを分けることです。

C#
public class CreateUserRequest
{
    public string Name { get; set; } = "";

    public string Password { get; set; } = "";
}

public class UserResponse
{
    public string Name { get; set; } = "";
}

この設計なら、レスポンスにPasswordが含まれる心配がありません。

一部のライブラリやバージョンでは、読み込み時・書き込み時の挙動を細かく制御できる機能があります。ただし、互換性やチーム内の分かりやすさを重視するなら、DTOを分ける方法が堅実です。

4-6. デシリアライズ時だけ無視したい場合の考え方

「JSONから読み込むときだけ無視したい」というケースもあります。

たとえば、クライアントから送られてきたIdを無視して、サーバー側で採番したい場合です。

JSON
{
  "id": 999,
  "name": "Taro"
}

このような入力をそのままエンティティに反映すると、意図しないID更新につながる可能性があります。

この場合も、入力用DTOを分ける方法が有効です。

C#
public class CreateUserRequest
{
    public string Name { get; set; } = "";
}

サーバー側では、Idをリクエストから受け取らずに生成します。

C#
var user = new User
{
    Id = GenerateId(),
    Name = request.Name
};

JsonIgnoreで無理に制御するよりも、受け取ってよい項目だけをDTOに定義するほうが安全です。

4-7. System.Text.JsonとNewtonsoft.Jsonの違い

C#でJSONプロパティをignoreするときは、使用しているJSONライブラリの違いに注意しましょう。

System.Text.Jsonの例です。

C#
using System.Text.Json;
using System.Text.Json.Serialization;

public class User
{
    public string Name { get; set; } = "";

    [JsonIgnore]
    public string Password { get; set; } = "";
}

Newtonsoft.Jsonの例です。

C#
using Newtonsoft.Json;

public class User
{
    public string Name { get; set; } = "";

    [JsonIgnore]
    public string Password { get; set; } = "";
}

どちらも属性名はJsonIgnoreですが、名前空間が異なります。期待通りに無視されない場合は、まずusingを確認しましょう。

5. C#で未使用変数・戻り値・引数をignoreする方法

5-1. _（破棄）を使って戻り値を無視する

C#では、戻り値を意図的に無視したい場合に_を使えます。

C#
_ = DoSomething();

これは「戻り値は使わないが、メソッドの実行自体は必要」という意図を示す書き方です。

たとえば、戻り値として成功・失敗を返すが、呼び出し側では不要な場合があります。

C#
_ = int.TryParse("123", out var number);

ただし、この例では戻り値を無視しているため、変換に成功したかどうかを確認していません。通常は次のように書くほうが自然です。

C#
if (int.TryParse("123", out var number))
{
    Console.WriteLine(number);
}

_で戻り値を無視するのは、戻り値を使わないことが明確で、かつ問題ない場合に限定しましょう。

5-2. タプルの一部だけを無視する方法

C#では、タプルの一部だけを使い、不要な値を_で無視できます。

C#
(string name, int age, string email) = GetUser();

Console.WriteLine(name);

もしageが不要なら、次のように書けます。

C#
var (name, _, email) = GetUser();

Console.WriteLine(name);
Console.WriteLine(email);

メソッド例です。

C#
static (string Name, int Age, string Email) GetUser()
{
    return ("Taro", 30, "taro@example.com");
}

複数の値のうち、一部だけを使いたい場合に便利です。

C#
var (_, statusCode, _) = GetResponseInfo();

Console.WriteLine(statusCode);

ただし、_が多すぎると何を無視しているのか分かりにくくなります。必要に応じて、戻り値の設計自体を見直しましょう。

5-3. out引数をout _で無視する方法

out引数の値が不要な場合は、out _を使って無視できます。

C#
bool isNumber = int.TryParse("123", out _);

このコードでは、変換後の数値は不要で、「数値として変換できるか」だけを確認しています。

実用例です。

C#
if (int.TryParse(input, out _))
{
    Console.WriteLine("数値です");
}
else
{
    Console.WriteLine("数値ではありません");
}

日付判定にも使えます。

C#
if (DateTime.TryParse(input, out _))
{
    Console.WriteLine("日付です");
}

out _を使うと、不要な一時変数を作らずに済みます。

悪い例です。

C#
int value;
if (int.TryParse(input, out value))
{
    Console.WriteLine("数値です");
}

valueを使わないなら、out _のほうが意図が明確です。

C#
if (int.TryParse(input, out _))
{
    Console.WriteLine("数値です");
}

5-4. ラムダ式の未使用引数を分かりやすく扱う方法

ラムダ式では、イベント引数やコールバック引数を使わないことがあります。

C#
button.Click += (sender, e) =>
{
    Console.WriteLine("クリックされました");
};

senderやeを使わない場合、_を使って「未使用」を表すことがあります。

C#
button.Click += (_, _) =>
{
    Console.WriteLine("クリックされました");
};

ただし、C#のバージョンや文脈によって、_が破棄として扱われる場合と通常の変数名として扱われる場合があります。特に、ひとつだけ_を使う場合は、単なる変数名として見えることもあります。

読みやすさを重視するなら、次のように意図が分かる名前を使うのも選択肢です。

C#
button.Click += (unusedSender, unusedArgs) =>
{
    Console.WriteLine("クリックされました");
};

チーム開発では、ラムダの未使用引数を_にするのか、unused付きの名前にするのか、コーディング規約で統一しておくとよいでしょう。

5-5. 未使用変数の警告を出さない書き方

未使用変数の警告を消すために#pragmaを使う前に、警告が出ない書き方にできないか確認しましょう。

たとえば、例外変数を使わないなら、変数名を書かないようにします。

C#
try
{
    DoSomething();
}
catch (InvalidOperationException)
{
    // 例外の種類だけ分かればよい
}

戻り値を使わないなら、代入しないか、意図的に破棄します。

C#
DoSomething();

戻り値を明示的に無視する意図を示したい場合は、次のようにします。

C#
_ = DoSomething();

out引数を使わないなら、out _を使います。

C#
int.TryParse(input, out _);

タプルの不要な値は_で破棄します。

C#
var (name, _, _) = GetUser();

未使用変数の警告は、単なるノイズではなく、ロジックミスを教えてくれている場合もあります。警告をignoreする前に、本当にその変数が不要なのか確認しましょう。

5-6. _を使うときの注意点

_は便利ですが、使いすぎるとコードの意味が分かりにくくなります。

たとえば、次のコードは何を無視しているのか分かりづらいです。

C#
var (_, _, _, result, _) = GetComplexData();

このような場合は、戻り値の型を見直すか、必要な値だけを返すメソッドを用意したほうが読みやすくなります。

C#
var result = GetResultOnly();

また、_は常に万能なignore構文ではありません。次のような用途には使えません。

• コンパイル警告全体を無視する

• JSONプロパティを除外する

• Git管理からファイルを除外する

• テストをスキップする

• Analyzerルールを無効化する

_はあくまで「使わない値を受け取らない、または使わないことを示す」ための書き方です。

6. C#プロジェクトでファイルやフォルダをignoreする方法

6-1. .gitignoreでGit管理から除外する

C#プロジェクトでファイルやフォルダをGit管理から除外したい場合は、.gitignoreを使います。

代表的な設定例です。

gitignore
# Build results
bin/
obj/

# Visual Studio
.vs/
*.user
*.suo

# Rider
.idea/

# VS Code
.vscode/

# NuGet
*.nupkg
packages/

# Test results
TestResults/
coverage/

.gitignoreは、Gitに「このファイルやフォルダは追跡しない」と伝えるための設定ファイルです。

C#のコード内で設定するものではなく、リポジトリのルートディレクトリに配置することが多いです。

6-2. Visual Studio向けの.gitignoreに含めるべき項目

Visual Studioを使うC#プロジェクトでは、次のようなファイルやフォルダを.gitignoreに含めることが多いです。

gitignore
.vs/
bin/
obj/
*.user
*.rsuser
*.suo
*.userosscache
*.sln.docstates
TestResults/

それぞれの意味は次のとおりです。

これらは通常、他の開発者と共有する必要がありません。むしろ共有すると、環境差分や不要な変更が増える原因になります。

6-3. bin・obj・.vsフォルダを除外する理由

C#プロジェクトでは、bin、obj、.vsをignoreするのが一般的です。

binフォルダには、ビルド後のDLLやEXEなどが出力されます。

bin/
  Debug/
    net8.0/
      MyApp.dll
      MyApp.exe

objフォルダには、ビルド途中の中間ファイルが入ります。

obj/
  Debug/
    net8.0/
      MyApp.AssemblyInfo.cs
      project.assets.json

.vsフォルダには、Visual Studioのローカル設定やキャッシュが入ります。

.vs/

これらはビルドやIDEの操作で自動生成されるため、Gitで管理する必要はありません。

もしbinやobjをGit管理してしまうと、次のような問題が起きやすくなります。

• 差分が大量に出る

• 他の開発者の環境と競合する

• リポジトリサイズが大きくなる

• ビルド成果物が古いまま残る

• 不要なコンフリクトが発生する

C#プロジェクトでは、ソースコードや設定ファイルを管理し、ビルド成果物は管理しないのが基本です。

6-4. .csprojで特定ファイルをビルド対象から除外する

Git管理から除外するのではなく、「ファイルはリポジトリに残すが、C#のビルド対象から外したい」場合は、.csprojを編集します。

SDKスタイルのC#プロジェクトでは、通常、プロジェクト内の.csファイルが自動的にビルド対象になります。

特定のC#ファイルを除外したい場合は、Compile Removeを使います。

XML
<ItemGroup>
  <Compile Remove="Experimental\OldCode.cs" />
</ItemGroup>

フォルダごと除外したい場合は、ワイルドカードを使えます。

XML
<ItemGroup>
  <Compile Remove="Experimental\**\*.cs" />
</ItemGroup>

これは「Git管理から外す」のではなく、「C#コンパイラのコンパイル対象から外す」設定です。

.gitignoreとは目的が違うので注意しましょう。

6-5. Compile RemoveでC#ファイルを除外する方法

Compile Removeは、C#ファイルをコンパイル対象から除外するために使います。

例です。

XML
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Remove="Legacy\LegacyService.cs" />
  </ItemGroup>

</Project>

複数ファイルを除外することもできます。

XML
<ItemGroup>
  <Compile Remove="Legacy\LegacyService.cs" />
  <Compile Remove="Samples\SampleCode.cs" />
</ItemGroup>

フォルダごと除外する場合です。

XML
<ItemGroup>
  <Compile Remove="Generated\Old\**\*.cs" />
</ItemGroup>

ただし、自動生成コードを除外する場合は、本当にビルドに不要か確認しましょう。生成コードに依存している場合、除外するとコンパイルエラーになります。

6-6. Content RemoveやNone Removeでリソースを除外する方法

C#プロジェクトでは、.csファイル以外にも、JSON、XML、画像、設定ファイルなどが含まれることがあります。

これらをビルドや発行対象から除外したい場合は、Content RemoveやNone Removeを使います。

XML
<ItemGroup>
  <Content Remove="sample-data\**\*" />
</ItemGroup>

Noneとして扱われているファイルを除外する場合です。

XML
<ItemGroup>
  <None Remove="docs\internal-note.txt" />
</ItemGroup>

特定のファイルを出力ディレクトリにコピーしないようにする場合は、CopyToOutputDirectoryを調整します。

XML
<ItemGroup>
  <None Update="appsettings.Local.json">
    <CopyToOutputDirectory>Never</CopyToOutputDirectory>
  </None>
</ItemGroup>

appsettings.Local.jsonのようなローカル設定ファイルは、.gitignoreでGit管理から除外することも多いです。

gitignore
appsettings.Local.json

「Gitから除外したい」のか、「ビルド対象から除外したい」のか、「出力対象から除外したい」のかを分けて考えることが重要です。

6-7. Gitの追跡済みファイルを後からignoreする方法

.gitignoreに書いたのにファイルが除外されない場合、そのファイルはすでにGitで追跡されている可能性があります。

.gitignoreは、まだ追跡されていないファイルに対して有効です。すでに追跡済みのファイルは、.gitignoreに追加しても自動では除外されません。

追跡を外すには、git rm --cachedを使います。

Bash
git rm --cached appsettings.Local.json

フォルダごと追跡を外す場合です。

Bash
git rm -r --cached bin
git rm -r --cached obj

その後、コミットします。

Bash
git add .gitignore
git commit -m "Ignore generated files"

ファイル自体はローカルに残し、Gitの追跡だけを外すのが--cachedのポイントです。

7. C#でコード解析・整形ルールをignoreする方法

7-1. .editorconfigでコード解析ルールを無視する

C#では、Roslyn Analyzerやコードスタイルの警告を.editorconfigで制御できます。

たとえば、IDE0051を無視する場合です。

INI
dotnet_diagnostic.IDE0051.severity = none

CA1822を無視する場合です。

INI
dotnet_diagnostic.CA1822.severity = none

カテゴリ単位で調整することもできます。

INI
dotnet_analyzer_diagnostic.category-Style.severity = none

ただし、カテゴリ単位で無視すると広範囲に影響します。基本的には、個別の診断IDごとに設定するほうが安全です。

.editorconfigの例です。

INI
root = true

[*.cs]
dotnet_diagnostic.CA1822.severity = none
dotnet_diagnostic.IDE0051.severity = suggestion
dotnet_diagnostic.CS1591.severity = none

.editorconfigはリポジトリに含められるため、チーム全体で同じルールを共有しやすいです。

7-2. StyleCopやRoslyn Analyzerの警告を無視する

StyleCopやRoslyn Analyzerの警告も、基本的には.editorconfigで抑制できます。

たとえば、StyleCopのSA1600を無視する場合です。

INI
dotnet_diagnostic.SA1600.severity = none

SA1600は、要素にドキュメントコメントが必要というルールでよく見かけます。

複数のStyleCopルールを調整する例です。

INI
[*.cs]
dotnet_diagnostic.SA1600.severity = none
dotnet_diagnostic.SA1633.severity = none
dotnet_diagnostic.SA1200.severity = warning

Roslyn Analyzerの警告も同様です。

INI
dotnet_diagnostic.CA1303.severity = none
dotnet_diagnostic.CA1848.severity = suggestion

Analyzer警告を無視する場合は、次の点を確認しましょう。

• ルールIDが正しいか

• .editorconfigの対象範囲が合っているか

• プロジェクトにAnalyzerが導入されているか

• IDEやビルドで同じ設定が使われているか

• ルールを無視する理由が明確か

警告を消すためだけにすべてnoneにするのではなく、チームの品質基準に合わせて調整することが大切です。

7-3. SuppressMessage属性で特定の解析警告を抑制する

特定のコードだけAnalyzer警告を抑制したい場合は、SuppressMessage属性を使えます。

C#
using System.Diagnostics.CodeAnalysis;

public class Sample
{
    [SuppressMessage(
        "Performance",
        "CA1822:Mark members as static",
        Justification = "DIコンテナからインスタンスメソッドとして呼び出すため")]
    public void Execute()
    {
        Console.WriteLine("実行");
    }
}

SuppressMessageでは、なぜ抑制するのかをJustificationに書けます。

警告を無視する理由をコード上に残せるため、後から見た人にも意図が伝わりやすくなります。

ただし、属性が多すぎるとコードが読みにくくなるため、広範囲のルール管理には.editorconfigを使うほうが適している場合もあります。

7-4. GlobalSuppressions.csでプロジェクト単位に抑制する

Analyzer警告をプロジェクト単位で抑制したい場合は、GlobalSuppressions.csを使うことがあります。

例です。

C#
using System.Diagnostics.CodeAnalysis;

[assembly: SuppressMessage(
    "Style",
    "IDE0051:Remove unused private members",
    Justification = "リフレクションで使用されるため",
    Scope = "member",
    Target = "~M:MyApp.Sample.HiddenMethod")]

GlobalSuppressions.csは、Visual Studioのクイックアクションから自動生成されることもあります。

特定メンバーや型に対して警告を抑制できるため、コード本体を汚さずに抑制設定をまとめられます。

使い分けの目安です。

7-5. ReSharperやRiderの警告を無視する方法

ReSharperやRiderを使っている場合、JetBrains独自の解析警告が表示されることがあります。

特定行で無視したい場合は、コメントで抑制できます。

C#
// ReSharper disable once UnusedMember.Local
private void MethodUsedByReflection()
{
}

ファイル内でまとめて無効化する例です。

C#
// ReSharper disable UnusedMember.Global

public class ReflectionTarget
{
    public void Execute()
    {
    }
}

// ReSharper restore UnusedMember.Global

ただし、ReSharperやRiderの設定はIDE依存です。チーム全員が同じIDEを使っていない場合は、.editorconfigやAnalyzer設定で管理できないか検討しましょう。

IDE固有のignore設定に頼りすぎると、Visual Studioでは警告が出ないがRiderでは出る、またはその逆が起きることがあります。

7-6. チーム開発でignoreルールを統一するポイント

チーム開発では、各メンバーが個別に警告をignoreすると、品質基準がバラバラになります。

ignoreルールを統一するには、次の方針が有効です。

• .editorconfigをリポジトリに含める

• .gitignoreをプロジェクト共通で管理する

• .csprojのNoWarnをレビュー対象にする

• SuppressMessageには理由を書く

• IDE固有の設定に依存しすぎない

• CIでビルド・テスト・Analyzerを実行する

• 警告をエラー扱いするルールを明確にする

たとえば、CIで警告をエラー扱いしている場合、ローカルだけで警告をignoreしてもビルドが失敗することがあります。

XML
<PropertyGroup>
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>

一部の警告だけエラー扱いから外す場合は、WarningsNotAsErrorsを使うこともあります。

XML
<PropertyGroup>
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  <WarningsNotAsErrors>CS1591</WarningsNotAsErrors>
</PropertyGroup>

個人の都合で警告を消すのではなく、プロジェクトとしてどの警告を許容するかを決めることが重要です。

8. C#でテスト・カバレッジ対象をignoreする方法

8-1. テスト実行から特定のテストを除外する方法

C#のテストで特定のテストを一時的に無視したい場合は、使用しているテストフレームワークに応じた属性を使います。

代表的な方法は次のとおりです。

テストのignoreは、失敗するテストを隠すためではなく、外部環境依存や一時的な不具合など、明確な理由がある場合に限定しましょう。

8-2. xUnitのSkipでテストを一時的に無視する

xUnitでは、[Fact]や[Theory]にSkipを指定してテストをスキップできます。

C#
using Xunit;

public class UserServiceTests
{
    [Fact(Skip = "外部APIの仕様変更対応中のため一時的にスキップ")]
    public void CreateUser_ShouldReturnUserId()
    {
        // テストコード
    }
}

Theoryでも同様です。

C#
[Theory(Skip = "テストデータを見直し中")]
[InlineData(1)]
[InlineData(2)]
public void Calculate_ShouldReturnExpectedValue(int value)
{
    // テストコード
}

Skipには理由を書けるため、なぜignoreされているのかが分かりやすくなります。

一時的にスキップしたテストは、放置されないようにIssue番号や期限を書いておくとよいです。

C#
[Fact(Skip = "TODO #1234: 外部APIモック対応後に有効化する")]
public void ExternalApiTest()
{
}

8-3. NUnitのIgnoreでテストを無視する

NUnitでは、[Ignore]属性を使ってテストを無視できます。

C#
using NUnit.Framework;

public class UserServiceTests
{
    [Test]
    [Ignore("外部サービスの検証環境が停止中のため")]
    public void CreateUser_ShouldReturnUserId()
    {
        // テストコード
    }
}

テストクラス全体を無視することもできます。

C#
[TestFixture]
[Ignore("仕様変更によりテスト全体を見直し中")]
public class LegacyServiceTests
{
    [Test]
    public void Test1()
    {
    }

    [Test]
    public void Test2()
    {
    }
}

NUnitのIgnoreも理由を書けるため、必ずコメントを残しましょう。

8-4. MSTestのIgnoreでテストを無視する

MSTestでは、[Ignore]属性でテストを無視できます。

C#
using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class UserServiceTests
{
    [TestMethod]
    [Ignore]
    public void CreateUser_ShouldReturnUserId()
    {
        // テストコード
    }
}

テストクラス全体を無視することもできます。

C#
[TestClass]
[Ignore]
public class LegacyServiceTests
{
    [TestMethod]
    public void Test1()
    {
    }
}

MSTestでIgnoreを使う場合も、理由をコメントで残しておくとよいです。

C#
[TestMethod]
[Ignore] // TODO: #1234 外部APIモック作成後に有効化する
public void ExternalApiTest()
{
}

テストをignoreしたまま放置すると、品質低下につながります。CI上でスキップテスト数を確認する運用も有効です。

8-5. コードカバレッジから除外する方法

C#で特定のクラスやメソッドをコードカバレッジ対象から除外したい場合は、ExcludeFromCodeCoverage属性を使います。

C#
using System.Diagnostics.CodeAnalysis;

[ExcludeFromCodeCoverage]
public class GeneratedCode
{
    public void Execute()
    {
        // 自動生成コード
    }
}

メソッド単位でも指定できます。

C#
public class Sample
{
    [ExcludeFromCodeCoverage]
    public void DebugOnlyMethod()
    {
    }
}

カバレッジから除外する対象の例です。

• 自動生成コード

• 単純なDTO

• 外部ライブラリ連携の薄いラッパー

• 起動コード

• テストしにくい環境依存コード

ただし、カバレッジを良く見せるためだけに除外するのは避けるべきです。カバレッジ対象から外す理由が明確であることが重要です。

8-6. テストをignoreする際の注意点

テストのignoreは便利ですが、使い方を間違えると失敗しているテストを隠すだけになります。

注意点は次のとおりです。

• 理由を書く

• Issue番号を書く

• 期限を決める

• CIでスキップ数を確認する

• 長期間放置しない

• 失敗するからという理由だけでignoreしない

• 本当に不要なテストなら削除も検討する

悪い例です。

C#
[Fact(Skip = "失敗するため")]
public void ImportantTest()
{
}

良い例です。

C#
[Fact(Skip = "TODO #1234: 外部決済APIのモック実装後に再有効化する")]
public void Payment_ShouldBeCompleted()
{
}

テストをignoreする目的は、品質チェックから逃げることではありません。管理された一時的な除外として使うべきです。

9. よくあるエラー別：C#のignore設定が効かない原因

9-1. #pragma warning disableが効かない原因

#pragma warning disableを書いたのに警告が消えない場合、次の原因が考えられます。

まず、警告番号が間違っている可能性があります。

C#
#pragma warning disable CS1234

実際に出ている警告番号を確認し、正しいIDを指定しましょう。

次に、抑制したい警告がC#コンパイラ警告ではなく、AnalyzerやIDEの警告である場合があります。この場合は、.editorconfigやSuppressMessageが必要です。

INI
dotnet_diagnostic.CA1822.severity = none

また、#pragma warning disableの範囲外で警告が出ている可能性もあります。

C#
#pragma warning disable CS0219
int value = 10;
#pragma warning restore CS0219

int other = 20; // ここでは警告が出る

#pragmaは書いた位置から有効になるため、対象コードを正しく囲む必要があります。

9-2. [JsonIgnore]を付けてもJSONに出力される原因

[JsonIgnore]を付けたのにJSONに出力される場合、よくある原因は名前空間の間違いです。

System.Text.Jsonを使っている場合です。

C#
using System.Text.Json.Serialization;

Newtonsoft.Jsonを使っている場合です。

C#
using Newtonsoft.Json;