C#クラス名の命名規則を初心者向けに解説！基本ルール・悪い例・実務で使える付け方

はじめに

C#でプログラミングを学び始めると、変数やメソッド、クラスなど、さまざまな名前を自分で決める場面が出てきます。その中でも特に重要なのが、クラス名の命名規則です。

クラス名は、単なるラベルではありません。そのクラスが何を表しているのか、どのような役割を持っているのかを、コードを読む人に伝える大切な情報です。適切なクラス名を付けることで、自分だけでなくチームメンバーにとっても読みやすく、修正しやすいコードになります。

この記事では、C#のクラス名命名規則について、初心者にもわかりやすく解説します。基本ルール、良い例・悪い例、実務で使える名前の付け方まで順番に見ていきましょう。

1. C#のクラス名命名規則とは？初心者が最初に押さえる基本

1-1. クラス名はコードの役割を伝えるための名前

C#のクラス名は、そのクラスが何を表すのかを伝えるための名前です。

たとえば、顧客を表すクラスであれば Customer、商品を表すクラスであれば Product、注文処理を担当するクラスであれば OrderService のように名前を付けます。

C#
public class Customer
{
    public string Name { get; set; }
}

このように Customer というクラス名を見るだけで、「顧客に関する情報を扱うクラスなのだろう」と予想できます。

一方で、次のような名前では役割が伝わりません。

C#
public class Data
{
}

Data という名前だけでは、何のデータなのかがわかりません。顧客データなのか、商品データなのか、注文データなのかを判断できないため、コードを読む人に余計な負担をかけてしまいます。

1-2. C#ではクラス名にPascalCaseを使うのが基本

C#のクラス名では、PascalCaseを使うのが基本です。

PascalCaseとは、単語の先頭を大文字にしてつなげる書き方です。

C#
public class OrderService
{
}

public class ProductRepository
{
}

public class CustomerViewModel
{
}

OrderService のように、Order と Service のそれぞれの先頭を大文字にします。

C#では、クラス名、メソッド名、プロパティ名などにPascalCaseを使うのが一般的です。初心者のうちは、まず「クラス名は先頭大文字」と覚えておくとよいでしょう。

1-3. クラス名は名詞・名詞句で付ける

クラス名は、基本的に名詞または名詞句で付けます。

クラスは「もの」や「概念」を表すことが多いため、動詞ではなく名詞を使うのが自然です。

良い例は次のとおりです。

C#
public class Customer
{
}

public class Order
{
}

public class Invoice
{
}

public class UserAccount
{
}

一方で、次のような動詞のクラス名は不自然です。

C#
public class CreateOrder
{
}

public class CalculatePrice
{
}

CreateOrder や CalculatePrice は処理を表しているため、クラス名よりもメソッド名に向いています。

C#
public class OrderService
{
    public void CreateOrder()
    {
    }

    public decimal CalculatePrice()
    {
        return 0;
    }
}

このように、クラス名には「何を表すクラスか」、メソッド名には「何をする処理か」を表す名前を付けると、コードの役割が整理されます。

1-4. 命名規則を守ると可読性・保守性が上がる

命名規則を守る最大のメリットは、コードが読みやすくなることです。

C#では、クラス名がPascalCaseで書かれていると、コードを読む人は「これはクラス名だ」とすぐに判断できます。逆に、命名規則がバラバラだと、クラス名なのか変数名なのか、メソッド名なのかがわかりにくくなります。

たとえば、次のようなコードは読みづらくなります。

C#
public class order_service
{
}

public class productrepository
{
}

public class CUSTOMERDATA
{
}

同じプロジェクト内で書き方が統一されていないと、コード全体に一貫性がなくなります。

命名規則を守ることで、次のようなメリットがあります。

コードの役割が理解しやすくなる
クラスを探しやすくなる
修正時の影響範囲を把握しやすくなる
チーム開発で認識のズレが減る
将来の自分が読み返したときに理解しやすい

プログラムは書いて終わりではありません。あとから修正したり、機能追加したり、他の人が読むこともあります。そのため、C#のクラス名命名規則を守ることは、実務でも非常に重要です。

2. C#クラス名の基本ルール

2-1. 先頭は大文字にする

C#のクラス名は、先頭を大文字にします。

良い例は次のとおりです。

C#
public class Customer
{
}

public class Product
{
}

public class Order
{
}

悪い例は次のとおりです。

C#
public class customer
{
}

public class product
{
}

public class order
{
}

customer のように先頭が小文字になっていると、C#の一般的な命名規則に合っていません。小文字始まりは、変数名や引数名で使われるcamelCaseと混同しやすくなります。

クラス名は型名として使われるため、先頭を大文字にして区別しやすくしましょう。

2-2. 複数単語は各単語の先頭を大文字にする

クラス名が複数の単語で構成される場合は、各単語の先頭を大文字にします。

C#
public class OrderService
{
}

public class ProductRepository
{
}

public class CustomerAddress
{
}

public class UserAccountSetting
{
}

これはPascalCaseの基本です。

悪い例は次のとおりです。

C#
public class orderservice
{
}

public class productrepository
{
}

public class customerAddress
{
}

orderservice のように単語の区切りがわからない名前は読みづらくなります。customerAddress のように先頭だけ小文字になっている名前も、クラス名としては不適切です。

クラス名は、ひと目で単語の区切りがわかるようにしましょう。

2-3. アンダースコアやハイフンは使わない

C#のクラス名では、基本的にアンダースコア _ は使いません。

C#
public class OrderService
{
}

次のような名前は避けます。

C#
public class order_service
{
}

public class Product_Repository
{
}

C#では、単語の区切りにアンダースコアを使うのではなく、PascalCaseで表現します。

また、ハイフン - はC#の識別子として使えません。

C#
public class Order-Service
{
}

このような名前は構文エラーになります。C#ではハイフンは引き算の演算子として扱われるため、クラス名には使用できません。

2-4. 数字から始めない

C#のクラス名は、数字から始めることはできません。

次のようなクラス名は使えません。

C#
public class 3DModel
{
}

数字を含めたい場合は、先頭を文字にします。

C#
public class Model3D
{
}

public class ThreeDimensionalModel
{
}

3DModel のように数字から始める名前はエラーになりますが、Model3D のように途中や末尾に数字を含めることはできます。

ただし、数字を使う場合は、その数字に明確な意味があるかを確認しましょう。意味のない Class1 や Data2 のような名前は避けるべきです。

2-5. 予約語は避ける

C#には、言語仕様で特別な意味を持つ予約語があります。

たとえば、次のような単語です。

C#
class
public
private
namespace
void
string
int
return

これらはC#の構文で使われるため、通常はクラス名として使うべきではありません。

たとえば、次のような名前は避けます。

C#
public class Class
{
}

public class Namespace
{
}

C#では、予約語と同じ名前をどうしても使いたい場合に @ を付けることもできます。

C#
public class @class
{
}

しかし、このような書き方は読みづらく、実務ではほとんど使いません。初心者のうちは、予約語と同じ名前は避けると考えておきましょう。

2-6. 省略形や意味の曖昧な名前は避ける

クラス名では、意味のわかりにくい省略形や曖昧な名前を避けましょう。

悪い例は次のとおりです。

C#
public class Cust
{
}

public class OrdSvc
{
}

public class Tmp
{
}

public class Info
{
}

Cust は Customer の省略かもしれませんが、初めて読む人にはわかりにくい可能性があります。OrdSvc も、慣れていない人には意味を推測しづらい名前です。

良い例は次のとおりです。

C#
public class Customer
{
}

public class OrderService
{
}

public class TemporaryFile
{
}

public class UserProfile
{
}

名前が少し長くなっても、意味が明確なほうが実務では扱いやすくなります。

ただし、HTML、URL、ID のように一般的に広く使われている略語は使われることがあります。その場合も、プロジェクト内で書き方を統一することが大切です。

3. C#クラス名の良い例と悪い例

3-1. 良い例：Customer、OrderService、ProductRepository

C#のクラス名として良い例を見てみましょう。

C#
public class Customer
{
}

Customer は顧客を表すクラス名です。短く、意味が明確で、PascalCaseにも従っています。

C#
public class OrderService
{
}

OrderService は注文に関する処理を担当するクラスだとわかります。Service という接尾辞によって、ビジネスロジックや処理を持つクラスであることが伝わります。

C#
public class ProductRepository
{
}

ProductRepository は商品データの取得や保存を担当するクラスだと予想できます。Repository という名前によって、データアクセスに関係するクラスだと判断しやすくなります。

良いクラス名には、次のような特徴があります。

役割が具体的である
PascalCaseで書かれている
名詞または名詞句になっている
省略されすぎていない
プロジェクト内の命名ルールに合っている

名前を見ただけで「このクラスは何をするのか」がある程度わかることが重要です。

3-2. 悪い例：customer、order_service、Cls1、DataManager

次に、C#のクラス名として避けたい悪い例を見てみましょう。

C#
public class customer
{
}

customer は先頭が小文字になっています。C#のクラス名としてはPascalCaseに従っていないため、Customer にするべきです。

C#
public class order_service
{
}

order_service はアンダースコアを使っています。C#では、クラス名にアンダースコアを使うのではなく、OrderService のようにPascalCaseで書きます。

C#
public class Cls1
{
}

Cls1 は、何を表すクラスなのかがまったくわかりません。自動生成された名前をそのまま使っているように見え、実務では避けるべき名前です。

C#
public class DataManager
{
}

DataManager は一見すると問題なさそうに見えますが、実務では注意が必要です。Data も Manager も意味が広いため、何のデータをどのように管理するのかがわかりにくい名前です。

より具体的にするなら、次のようにします。

C#
public class CustomerRepository
{
}

public class OrderService
{
}

public class ProductInventory
{
}

曖昧な名前は、あとから責務が増えやすく、巨大なクラスになりやすいので注意しましょう。

3-3. 悪い名前が実務で問題になる理由

悪いクラス名は、実務でさまざまな問題を引き起こします。

まず、コードを読む時間が増えます。名前から役割がわからないため、クラスの中身を開いて確認しなければなりません。小さなプロジェクトならまだしも、クラス数が多いプロジェクトでは大きな負担になります。

次に、修正ミスが増えます。たとえば DataManager という名前のクラスが複数の処理を担当している場合、どこを修正すればよいのか判断しづらくなります。その結果、本来修正すべきではない箇所を変更してしまう可能性があります。

また、チーム開発では認識のズレが起きやすくなります。ある人は Manager をビジネスロジックのクラスだと考え、別の人はデータ管理のクラスだと考えるかもしれません。このような曖昧さは、設計の乱れにつながります。

悪いクラス名は、次のような問題につながります。

クラスの役割がわかりにくい
修正箇所を探すのに時間がかかる
同じようなクラスが増えやすい
責務が増えすぎて巨大クラスになりやすい
チーム内で認識がズレる

クラス名は小さな要素に見えますが、コード全体の品質に大きく影響します。

3-4. 初心者がやりがちな命名ミス

C#初心者がやりがちな命名ミスには、いくつかのパターンがあります。

まず多いのが、Class1 や Form1 のような自動生成名をそのまま使うケースです。

C#
public class Class1
{
}

学習用の小さなコードなら問題になることは少ないですが、実務やポートフォリオでは避けましょう。何のクラスなのかがわかる名前に変更することが大切です。

次に、名前を短くしすぎるケースです。

C#
public class Usr
{
}

public class Prd
{
}

短い名前は入力しやすいですが、意味が伝わりにくくなります。User、Product のように正式な単語を使いましょう。

また、何でも Manager や Helper にしてしまうのも初心者に多いミスです。

C#
public class UserManager
{
}

public class DataHelper
{
}

これらの名前は悪いとは限りませんが、意味が広いため注意が必要です。具体的な役割を表せるなら、より明確な名前にしましょう。

C#
public class UserRegistrationService
{
}

public class CsvFileReader
{
}

初心者のうちは、「短い名前」よりも「意味が伝わる名前」を優先するのがおすすめです。

4. 実務で使えるC#クラス名の付け方

4-1. クラスの責務がわかる名前にする

実務でクラス名を付けるときは、そのクラスの責務がわかる名前にすることが大切です。

責務とは、そのクラスが担当する役割のことです。

たとえば、顧客情報を表すクラスなら Customer、顧客を登録する処理なら CustomerRegistrationService、顧客データを保存・取得するなら CustomerRepository のように、役割に応じて名前を変えます。

C#
public class Customer
{
}

public class CustomerRegistrationService
{
}

public class CustomerRepository
{
}

同じ Customer に関係するクラスでも、責務が違えば名前も変わります。

悪い例は次のとおりです。

C#
public class CustomerManager
{
}

CustomerManager だけでは、顧客の登録をするのか、検索をするのか、更新をするのか、削除をするのかがわかりません。

より具体的にするなら、次のようにします。

C#
public class CustomerRegistrationService
{
}

public class CustomerSearchService
{
}

public class CustomerRepository
{
}

クラス名を考えるときは、「このクラスは何を担当しているのか」を一言で説明できるかを確認しましょう。

4-2. Service・Repository・Controllerなど役割を表す接尾辞を使う

C#の実務では、クラスの役割を表すために接尾辞を使うことがあります。

代表的な接尾辞には、次のようなものがあります。

Service は、業務処理やビジネスロジックを担当するクラスに使われます。

C#
public class OrderService
{
}

public class PaymentService
{
}

Repository は、データの取得や保存を担当するクラスに使われます。

C#
public class ProductRepository
{
}

public class CustomerRepository
{
}

Controller は、ASP.NET Coreなどでリクエストを受け取り、処理の流れを制御するクラスに使われます。

C#
public class ProductsController
{
}

public class OrdersController
{
}

Factory は、オブジェクトの生成を担当するクラスに使われます。

C#
public class CustomerFactory
{
}

Validator は、入力値やオブジェクトの検証を担当するクラスに使われます。

C#
public class OrderValidator
{
}

このような接尾辞を使うと、クラス名を見るだけで役割を推測しやすくなります。ただし、接尾辞を付ければよいというわけではありません。実際の責務と名前が一致していることが重要です。

4-3. Entity・Model・DTO・ViewModelの使い分け

C#のプロジェクトでは、Entity、Model、DTO、ViewModel といった名前をよく見かけます。これらは似ていますが、役割が異なります。

Entity は、データベースのテーブルや業務上の重要な概念を表すクラスに使われることが多いです。

C#
public class CustomerEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
}

ただし、プロジェクトによっては CustomerEntity ではなく、単に Customer とする場合もあります。チームの方針に合わせることが大切です。

Model は、アプリケーションで扱うデータ構造を表す広い名前です。

C#
public class ProductModel
{
    public string Name { get; set; }
    public decimal Price { get; set; }
}

ただし、Model は意味が広いため、何でも Model にすると役割が曖昧になります。

DTO は、Data Transfer Objectの略で、データの受け渡しに使うクラスです。

C#
public class CreateOrderDto
{
    public int CustomerId { get; set; }
    public List<int> ProductIds { get; set; }
}

APIのリクエストやレスポンスでよく使われます。

ViewModel は、画面表示に必要なデータをまとめるクラスです。

C#
public class CustomerDetailViewModel
{
    public string CustomerName { get; set; }
    public string Address { get; set; }
}

画面に表示するための情報を持たせる場合に使います。

それぞれの違いを簡単に整理すると、次のようになります。

Entity は業務上のデータやデータベースに近いクラス
Model はアプリケーション内のデータ構造を表す広い名前
DTO はデータの受け渡し専用のクラス
ViewModel は画面表示用のデータを持つクラス

これらの名前は便利ですが、プロジェクトによって意味が異なることもあります。必ずチーム内で使い方を統一しましょう。

4-4. ManagerやHelperを安易に使わない

Manager や Helper は便利そうに見える名前ですが、安易に使うとクラスの責務が曖昧になります。

たとえば、次のようなクラス名です。

C#
public class DataManager
{
}

public class CommonHelper
{
}

public class UserHelper
{
}

これらの名前は、何をするクラスなのかがはっきりしません。特に CommonHelper のような名前は、いろいろな処理が詰め込まれやすく、保守しにくいクラスになりがちです。

より具体的な名前にするなら、次のようにします。

C#
public class CsvFileReader
{
}

public class PasswordHasher
{
}

public class UserRegistrationService
{
}

CsvFileReader ならCSVファイルを読むクラス、PasswordHasher ならパスワードのハッシュ化を行うクラスだとわかります。

Manager や Helper を使ってはいけないわけではありません。ただし、名前を付ける前に「もっと具体的な名前にできないか」を考えることが大切です。

4-5. 抽象クラス・基底クラスの命名例

抽象クラスや基底クラスにも、わかりやすい名前を付ける必要があります。

抽象クラスとは、共通処理や共通の性質を定義し、継承して使うことを前提としたクラスです。

C#では、抽象クラスに必ず特別な接頭辞を付ける必要はありません。ただし、役割が伝わる名前にすることが大切です。

C#
public abstract class Animal
{
    public abstract void Speak();
}

この場合、Animal は犬や猫などの共通概念を表しているため、自然な名前です。

基底クラスであることを明示したい場合は、Base を接尾辞として使うことがあります。

C#
public abstract class ControllerBase
{
}

public abstract class RepositoryBase
{
}

public abstract class EntityBase
{
}

ただし、何でも Base を付ければよいわけではありません。Base を付ける場合は、そのクラスが本当に共通の基底クラスとして使われるのかを確認しましょう。

良い例は次のとおりです。

C#
public abstract class PaymentProcessor
{
    public abstract void ProcessPayment();
}

この名前からは、支払い処理を行うクラスの共通基盤であることがわかります。

抽象クラスや基底クラスでは、継承先のクラスとの関係が自然に読める名前にすることが重要です。

4-6. 例外クラス・属性クラスの命名例

C#では、例外クラスや属性クラスにも一般的な命名パターンがあります。

例外クラスには、通常 Exception を付けます。

C#
public class CustomerNotFoundException : Exception
{
}

この名前を見ると、顧客が見つからなかった場合の例外であることがわかります。

他にも、次のような名前が考えられます。

C#
public class InvalidOrderStatusException : Exception
{
}

public class PaymentFailedException : Exception
{
}

例外クラスは、どのようなエラーを表しているのかが具体的にわかる名前にしましょう。

属性クラスには、通常 Attribute を付けます。

C#
public class RequiredLoginAttribute : Attribute
{
}

属性は、クラスやメソッドなどに追加情報を付けるために使われます。

C#
[RequiredLogin]
public class MyPageController
{
}

C#では、属性を使うときに Attribute を省略できます。そのため、クラス名は RequiredLoginAttribute でも、使用時は [RequiredLogin] と書けます。

例外クラスは Exception、属性クラスは Attribute を付けると覚えておくと、C#らしい命名になります。

5. C#の他の命名規則との違い

5-1. クラス名とメソッド名はPascalCase

C#では、クラス名とメソッド名はどちらもPascalCaseを使います。

C#
public class OrderService
{
    public void CreateOrder()
    {
    }

    public decimal CalculateTotalPrice()
    {
        return 0;
    }
}

OrderService がクラス名で、CreateOrder や CalculateTotalPrice がメソッド名です。どちらも各単語の先頭を大文字にしています。

ただし、クラス名は名詞または名詞句、メソッド名は動詞または動詞句にするのが基本です。

C#
public class CustomerRepository
{
    public Customer FindById(int id)
    {
        return new Customer();
    }
}

CustomerRepository はクラス名なので名詞句です。FindById はメソッド名なので動詞句です。

同じPascalCaseでも、名前が表す内容は異なる点に注意しましょう。

5-2. 変数名や引数名はcamelCase

C#では、ローカル変数やメソッドの引数にはcamelCaseを使うのが一般的です。

camelCaseとは、先頭の単語だけ小文字にし、2語目以降の先頭を大文字にする書き方です。

C#
public class OrderService
{
    public void CreateOrder(int customerId)
    {
        decimal totalPrice = 0;
    }
}

この例では、customerId が引数名、totalPrice がローカル変数名です。どちらも先頭が小文字になっています。

クラス名と比較すると、違いがわかりやすくなります。

C#
public class Customer
{
    public string customerName;
}

上の例では、Customer がクラス名でPascalCase、customerName がフィールド名でcamelCaseです。

ただし、フィールド名については _customerName のようにアンダースコアを付けるルールを採用するプロジェクトもあります。重要なのは、プロジェクト内で一貫性を持たせることです。

5-3. インターフェイス名はIを付ける

C#では、インターフェイス名の先頭に I を付けるのが一般的です。

C#
public interface ICustomerRepository
{
    Customer FindById(int id);
}

この場合、ICustomerRepository は顧客データの取得を表すインターフェイスです。

実装クラスは、次のように命名できます。

C#
public class CustomerRepository : ICustomerRepository
{
    public Customer FindById(int id)
    {
        return new Customer();
    }
}

インターフェイス名に I を付けることで、コードを見たときにインターフェイスであることがすぐにわかります。

他の例も見てみましょう。

C#
public interface ILogger
{
}

public interface IEmailSender
{
}

public interface IPaymentService
{
}

I の後ろもPascalCaseで書きます。iLogger や IemailSender のような名前にはしません。

5-4. 名前空間とクラス名の関係

C#では、名前空間を使ってクラスを整理します。

名前空間は、クラスの住所のようなものです。同じ名前のクラスがあっても、名前空間が違えば区別できます。

C#
namespace MyApp.Services
{
    public class OrderService
    {
    }
}

この場合、OrderService は MyApp.Services という名前空間に属しています。

名前空間とクラス名は、役割が自然につながるようにすると読みやすくなります。

C#
namespace MyApp.Repositories
{
    public class ProductRepository
    {
    }
}

Repositories という名前空間に ProductRepository があるため、データアクセス関連のクラスだとわかります。

一方で、次のような構成はわかりにくくなります。

C#
namespace MyApp.Utilities
{
    public class ProductRepository
    {
    }
}

Utilities という名前空間に ProductRepository があると、なぜそこにあるのか疑問が生まれます。

クラス名だけでなく、名前空間との組み合わせでも意味が伝わるようにしましょう。

5-5. ファイル名とクラス名は基本的にそろえる

C#では、ファイル名とクラス名を基本的にそろえるのが一般的です。

たとえば、Customer クラスであれば、ファイル名は Customer.cs にします。

C#
public class Customer
{
}

ファイル名は次のようにします。

Customer.cs

OrderService クラスなら、ファイル名は OrderService.cs です。

OrderService.cs

ファイル名とクラス名をそろえると、クラスを探しやすくなります。Visual Studioやエディタでも管理しやすくなり、プロジェクト内の見通しがよくなります。

1つのファイルに複数のクラスを書くこともできますが、基本的には1ファイル1クラスにするとわかりやすいです。特に初心者のうちは、ファイル名とクラス名を一致させる習慣を付けるとよいでしょう。

6. クラス名を決めるときの考え方とチェックリスト

6-1. そのクラスが何を表すかを一言で説明する

クラス名を決めるときは、まず「このクラスは何を表すのか」を一言で説明してみましょう。

たとえば、次のように考えます。

顧客を表すクラスなら Customer
注文を表すクラスなら Order
商品情報を取得・保存するクラスなら ProductRepository
メール送信を担当するクラスなら EmailSender
注文の合計金額を計算するクラスなら OrderPriceCalculator

一言で説明できない場合、そのクラスは複数の責務を持ちすぎている可能性があります。

たとえば、次のようなクラス名を考えたとします。

C#
public class OrderManager
{
}

このクラスが、注文作成、在庫確認、支払い処理、メール送信まで担当しているなら、責務が多すぎます。

その場合は、次のように分けることを検討します。

C#
public class OrderService
{
}

public class InventoryChecker
{
}

public class PaymentService
{
}

public class OrderConfirmationEmailSender
{
}

クラス名を考えることは、設計を見直すきっかけにもなります。

6-2. 1クラス1責務になっているか確認する

良いクラス名を付けるためには、クラスの責務が1つにまとまっていることが重要です。

1つのクラスが多くのことを担当していると、名前も曖昧になります。

たとえば、次のようなクラスです。

C#
public class UserManager
{
    public void RegisterUser() { }
    public void SendEmail() { }
    public void ExportCsv() { }
    public void ValidatePassword() { }
}

このクラスは、ユーザー登録、メール送信、CSV出力、パスワード検証など、複数の責務を持っています。そのため、UserManager という曖昧な名前になっています。

責務ごとに分けると、名前も明確になります。

C#
public class UserRegistrationService
{
}

public class EmailSender
{
}

public class UserCsvExporter
{
}

public class PasswordValidator
{
}

クラス名が決めにくいと感じたら、そのクラスが複数の役割を持ちすぎていないか確認しましょう。

6-3. 名前が長すぎないか確認する

クラス名は具体的であるべきですが、長すぎる名前にも注意が必要です。

たとえば、次のような名前は少し長すぎます。

C#
public class CustomerOrderPaymentHistoryCsvExportService
{
}

意味は伝わりますが、読むのも書くのも大変です。長すぎる名前になった場合は、クラスの責務が多すぎる可能性があります。

分割できるなら、次のように整理します。

C#
public class PaymentHistoryExporter
{
}

public class CustomerOrderHistoryService
{
}

ただし、短ければよいわけではありません。

C#
public class Exporter
{
}

Exporter だけでは、何を出力するのかがわかりません。

クラス名は、短すぎても長すぎても問題です。目安としては、名前を見て役割がわかり、かつ無理なく読める長さにすることを意識しましょう。

6-4. チームやプロジェクトの命名ルールに合わせる

実務では、C#の一般的な命名規則だけでなく、チームやプロジェクト独自のルールに合わせることも大切です。

たとえば、あるプロジェクトでは次のようなルールがあるかもしれません。

データベースに対応するクラスには Entity を付ける
APIのリクエストクラスには Request を付ける
APIのレスポンスクラスには Response を付ける
画面用のクラスには ViewModel を付ける
サービスクラスには必ず Service を付ける

このようなルールがある場合は、自分だけ違う命名をしないようにしましょう。

たとえば、既存のコードで次のような命名が使われているとします。

C#
public class CreateCustomerRequest
{
}

public class CreateCustomerResponse
{
}

このプロジェクトで注文作成用のクラスを追加するなら、次のようにそろえるのが自然です。

C#
public class CreateOrderRequest
{
}

public class CreateOrderResponse
{
}

命名規則は、コード全体の一貫性を保つためのものです。自分にとってわかりやすい名前だけでなく、チーム全体にとって理解しやすい名前を選びましょう。

6-5. リファクタリングしやすい名前にする

クラス名は、一度決めたら絶対に変えられないものではありません。開発が進むにつれて、より適切な名前が見つかることもあります。

最初は OrderService という名前で作ったクラスが、実際には注文の価格計算だけを担当しているとわかった場合は、次のように変更したほうがよいかもしれません。

C#
public class OrderPriceCalculator
{
}

このように、クラスの責務に合わせて名前を見直すことをリファクタリングといいます。

Visual Studioなどの開発環境では、クラス名の変更を安全に行う機能があります。名前を変えると、参照している箇所もまとめて更新できます。

リファクタリングしやすい名前にするためには、次の点を意識しましょう。

役割と名前を一致させる
曖昧な名前を避ける
責務が変わったら名前も見直す
チーム内で変更理由を共有する

クラス名は、コードの設計を表す重要な要素です。設計が変わったら、名前も適切に変えていきましょう。

7. C#クラス名の命名規則に関するよくある質問

7-1. クラス名に日本語を使ってもいい？

C#では、技術的にはクラス名に日本語を使うこともできます。

C#
public class 顧客
{
}

ただし、実務では基本的に英語のクラス名を使うことをおすすめします。

理由は、C#のライブラリやフレームワーク、ドキュメントの多くが英語で書かれているためです。また、チーム開発や将来的な保守を考えると、英語のほうが一般的で扱いやすいです。

日本語のクラス名は、環境によって表示や検索で扱いづらくなる場合もあります。

そのため、次のように英語で命名するのが一般的です。

C#
public class Customer
{
}

public class Order
{
}

public class Product
{
}

学習用のコードで日本語を使うことはできますが、実務や公開するコードでは英語を使うのが無難です。

7-2. 略語は大文字のままでいい？

略語の書き方は、プロジェクトのルールに合わせることが大切です。

たとえば、ID、URL、HTML、XML のような略語はよく使われます。

C#では、略語を含むクラス名でもPascalCaseとして読みやすくすることが重要です。

C#
public class CustomerId
{
}

public class UrlBuilder
{
}

public class HtmlParser
{
}

一方で、すべてを大文字にすると読みにくくなることがあります。

C#
public class CustomerID
{
}

public class URLBuilder
{
}

public class HTMLParser
{
}

どちらの書き方が採用されるかは、チームやプロジェクトによって異なります。最近のC#コードでは、Id、Url、Html のように通常の単語として扱う書き方もよく使われます。

重要なのは、同じプロジェクト内で CustomerId と CustomerID が混在しないようにすることです。

7-3. 複数形のクラス名は使ってもいい？

クラス名は、基本的には単数形を使います。

C#
public class Customer
{
}

public class Product
{
}

public class Order
{
}

クラスは1つの概念や1つの種類を表すため、単数形のほうが自然です。

一方で、コレクションや一覧を表すクラスでは複数形を使う場合もあります。

C#
public class CustomersController
{
}

public class OrderItems
{
}

ASP.NET Coreのコントローラーでは、リソースの集合を扱う意味で CustomersController や ProductsController のように複数形が使われることがあります。

ただし、通常のエンティティやモデルでは、単数形を使うのが基本です。

C#
public class Customers
{
}

このような名前は、顧客1人を表すのか、顧客の一覧を表すのかが曖昧になります。

迷った場合は、まず単数形を選びましょう。複数形にする場合は、「複数のものを表している」と明確に説明できるときに使うのがよいです。

7-4. クラス名とメソッド名が似ていても問題ない？

クラス名とメソッド名が似ていても、役割が明確であれば問題ありません。

たとえば、次のようなコードは自然です。

C#
public class OrderService
{
    public void CreateOrder()
    {
    }
}

OrderService は注文に関する処理を担当するクラスで、CreateOrder は注文を作成するメソッドです。名前は似ていますが、クラスとメソッドの役割が違うため問題ありません。

ただし、クラス名とメソッド名がほとんど同じで、意味の違いがわからない場合は注意が必要です。

C#
public class CreateOrder
{
    public void Create()
    {
    }
}

この場合、CreateOrder は動詞的な名前になっており、クラス名としてはやや不自然です。

より自然にするなら、次のようにします。

C#
public class OrderService
{
    public void CreateOrder()
    {
    }
}

クラス名は名詞・名詞句、メソッド名は動詞・動詞句にすることで、役割の違いがわかりやすくなります。

7-5. Visual Studioで命名規則をチェックできる？

Visual Studioでは、C#の命名規則をチェックしやすくする機能があります。

たとえば、コード分析や.editorconfigを使うことで、命名ルールをプロジェクト内で統一できます。

.editorconfig では、クラス名はPascalCaseにする、インターフェイス名は I で始める、フィールド名は特定の形式にする、といったルールを設定できます。

たとえば、チーム開発では次のような方針を決めることがあります。

クラス名はPascalCase
インターフェイス名はI + PascalCase
ローカル変数はcamelCase
privateフィールドはアンダースコア + camelCase

Visual Studioの警告や提案を活用すると、命名規則のミスに気づきやすくなります。

ただし、ツールに任せるだけではなく、なぜその名前にするのかを理解することも大切です。命名規則は、コードを読みやすくするためのルールだからです。

まとめ

C#のクラス名命名規則では、PascalCaseを使い、名詞または名詞句で名前を付けるのが基本です。クラス名は、そのクラスが何を表しているのか、どのような責務を持っているのかを伝える重要な情報です。

クラス名を付けるときは、先頭を大文字にし、複数単語の場合は各単語の先頭を大文字にします。アンダースコアやハイフンは使わず、数字から始まる名前や予約語、意味の曖昧な省略形は避けましょう。

良いクラス名には、Customer、OrderService、ProductRepository のように、役割が明確で読みやすいという特徴があります。一方で、customer、order_service、Cls1、DataManager のような名前は、C#の命名規則に合わなかったり、意味が曖昧だったりするため注意が必要です。

実務では、Service、Repository、Controller、DTO、ViewModel、Exception、Attribute など、役割を表す接尾辞を適切に使うと、クラスの目的が伝わりやすくなります。ただし、Manager や Helper のような曖昧な名前は安易に使わず、より具体的な名前にできないかを考えましょう。

クラス名を決めるときは、「このクラスは何を表すのか」「1クラス1責務になっているか」「名前が長すぎないか」「プロジェクトのルールに合っているか」を確認することが大切です。

C#のクラス名命名規則を身につけると、コードの可読性や保守性が大きく向上します。初心者のうちから正しい命名を意識して、読みやすく実務でも通用するC#コードを書けるようになりましょう。