csharp namespaceとは?C#の名前空間の使い方・usingとの違い・よくあるエラーを初心者向けに解説

はじめに

C#を学び始めると、namespaceというキーワードをよく見かけます。たとえば、次のようなコードです。

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

namespaceは日本語で「名前空間」と呼ばれ、C#のクラスや型を整理するために使われます。

初心者のうちは、namespaceusingの違いが分かりにくかったり、「型または名前空間の名前が見つかりません」というエラーでつまずいたりしやすいです。

この記事では、csharp namespaceの基本から、書き方、usingとの違い、よくあるエラー、実践的な使い方までを初心者向けに解説します。

1. csharp namespaceとは?C#の名前空間の基本

1-1. namespaceは「クラスや型を整理するための名前のまとまり」

C#のnamespaceとは、クラスやインターフェース、構造体、列挙型などの型を整理するための名前のまとまりです。

たとえば、次のように書くことで、UserクラスをMyApp.Modelsという名前空間に所属させることができます。

C#
namespace MyApp.Models
{
public class User
{
public string Name { get; set; }
}
}

この場合、Userクラスの正式な名前は単にUserではなく、正確には次のようになります。

C#
MyApp.Models.User

このように、namespaceを使うと、クラスをグループ分けして管理できます。

1-2. 名前空間が必要になる理由

小さなプログラムであれば、クラスの数は少ないため、namespaceの必要性をあまり感じないかもしれません。

しかし、実際のアプリケーション開発では、クラスの数が数十、数百、場合によってはそれ以上になることがあります。

たとえば、次のような役割ごとにクラスを分けることがあります。

C#
MyApp.Models
MyApp.Services
MyApp.Controllers
MyApp.Repositories
MyApp.Utilities

namespaceを使わずにすべてのクラスを同じ場所に置くと、どのクラスが何の役割を持つのか分かりにくくなります。

namespaceを使うことで、コードの役割や責任範囲を整理しやすくなります。

1-3. namespaceで解決できる名前の衝突とは

namespaceは、クラス名の衝突を避けるためにも使われます。

たとえば、アプリケーション内に次の2つのUserクラスがあるとします。

C#
namespace MyApp.Models
{
public class User
{
}
}
C#
namespace MyApp.ViewModels
{
public class User
{
}
}

どちらもクラス名はUserですが、所属する名前空間が異なります。

そのため、正式には次のように区別できます。

C#
MyApp.Models.User
MyApp.ViewModels.User

このように、同じクラス名でもnamespaceが違えば別の型として扱われます。

1-4. C#におけるnamespace・class・methodの関係

C#では、一般的に次のような階層でコードを書きます。

C#
namespace MyApp.Services
{
public class UserService
{
public void CreateUser()
{
Console.WriteLine("ユーザーを作成しました");
}
}
}

この構造を整理すると、次のようになります。

namespace
└ class
└ method

namespaceはクラスをまとめる単位です。

classはデータや処理をまとめる単位です。

methodは実際の処理を書く単位です。

つまり、namespaceは処理そのものを書く場所というより、クラスや型を分類するための入れ物と考えると理解しやすいです。

2. C#のnamespaceの基本的な書き方

2-1. 従来のブロック形式のnamespace

C#で昔から使われている書き方は、波かっこ{ }で囲むブロック形式です。

C#
namespace MyApp.Models
{
public class User
{
public string Name { get; set; }
}
}

この書き方では、namespace MyApp.Modelsの中にUserクラスを定義しています。

複数のクラスを同じnamespaceに入れることもできます。

C#
namespace MyApp.Models
{
public class User
{
}

public class Product
{
}
}

2-2. C# 10以降で使えるファイルスコープnamespace

C# 10以降では、ファイルスコープnamespaceという書き方が使えます。

C#
namespace MyApp.Models;

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

従来の書き方と違い、namespaceのあとにセミコロン;を付けます。

この書き方をすると、そのファイル内のすべての型がMyApp.Models名前空間に所属します。

従来のブロック形式よりもインデントが浅くなり、コードがすっきりします。

C#
namespace MyApp.Services;

public class UserService
{
public void Execute()
{
Console.WriteLine("処理を実行しました");
}
}

最近のC#プロジェクトでは、ファイルスコープnamespaceがよく使われます。

2-3. namespaceの中にclassを書く基本例

基本的な構成は次のようになります。

C#
namespace SampleApp;

public class Calculator
{
public int Add(int a, int b)
{
return a + b;
}
}

この場合、CalculatorクラスはSampleApp名前空間に属しています。

別のファイルから使う場合は、次のようにusingを書いて利用できます。

C#
using SampleApp;

var calculator = new Calculator();
int result = calculator.Add(3, 5);

Console.WriteLine(result);

出力結果は次のようになります。

8

2-4. namespaceを階層化して書く方法

C#のnamespaceは、ドット.を使って階層化できます。

C#
namespace MyApp.Services.Users;

public class UserService
{
}

このUserServiceクラスは、次の名前空間に所属しています。

C#
MyApp.Services.Users

階層化すると、機能ごとにコードを整理しやすくなります。

たとえば、次のように分けることができます。

C#
MyApp.Models
MyApp.Services
MyApp.Services.Users
MyApp.Services.Products
MyApp.Repositories
MyApp.Controllers

ただし、あまり深くしすぎると、かえって分かりにくくなるため注意が必要です。

2-5. namespace名の命名ルールとよく使われる付け方

namespace名には、一般的にプロジェクト名や会社名、機能名を組み合わせます。

例としては、次のような名前がよく使われます。

C#
MyApp
MyApp.Models
MyApp.Services
MyCompany.ProjectName.Core
MyCompany.ProjectName.Infrastructure

C#では、namespace名は大文字・小文字を区別します。

C#
MyApp.Services
myapp.services

この2つは別の名前空間として扱われます。

一般的には、各単語の先頭を大文字にするPascalCaseが使われます。

C#
namespace ShoppingApp.OrderServices;

避けたほうがよい例は次のような名前です。

C#
namespace test;
namespace aaa;
namespace MyNamespace;

意味が分かりにくい名前にすると、後からコードを読んだときに役割が分かりづらくなります。

3. namespaceとusingの違い

3-1. namespaceは定義するもの、usingは利用しやすくするもの

初心者が混乱しやすいポイントが、namespaceusingの違いです。

簡単に言うと、namespaceは型を定義するときに所属先を決めるものです。

一方、usingは別の名前空間にある型を短い名前で使えるようにするものです。

たとえば、次のクラスがあるとします。

C#
namespace MyApp.Models;

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

このUserクラスを別のファイルで使うとき、次のように書けます。

C#
using MyApp.Models;

var user = new User();

using MyApp.Models;を書くことで、MyApp.Models.Userを単にUserと書けるようになります。

3-2. usingを書かない場合の呼び出し方

usingを書かない場合でも、完全修飾名を使えばクラスを呼び出せます。

C#
var user = new MyApp.Models.User();

このように、namespaceを含めた正式な名前で書く方法を完全修飾名といいます。

usingを書いた場合は、次のように短く書けます。

C#
using MyApp.Models;

var user = new User();

つまり、usingは必須ではありません。

ただし、毎回完全修飾名を書くとコードが長くなるため、通常はusingを使います。

3-3. usingディレクティブの基本的な使い方

usingディレクティブは、ファイルの先頭に書くのが一般的です。

C#
using System;
using MyApp.Models;
using MyApp.Services;

namespace MyApp;

public class Program
{
public static void Main()
{
var user = new User();
var service = new UserService();

Console.WriteLine("処理を開始します");
}
}

using System;を書くと、Consoleなどの型を短い名前で使えるようになります。

usingを書かない場合は、次のように書く必要があります。

C#
System.Console.WriteLine("処理を開始します");

usingを使うことで、コードを簡潔に書けます。

3-4. using staticとの違い

using staticは、通常のusingとは少し違います。

通常のusingは、名前空間を省略して型名を書けるようにします。

C#
using System;

Console.WriteLine("Hello");

一方、using staticは、特定のクラスの静的メンバーをクラス名なしで使えるようにします。

C#
using static System.Console;

WriteLine("Hello");

通常はConsole.WriteLineと書くところを、WriteLineだけで呼び出せます。

ただし、使いすぎると「どのクラスのメソッドなのか」が分かりにくくなるため、初心者のうちは通常のusingを中心に理解するとよいです。

3-5. global usingとは何か

global usingは、プロジェクト全体で有効になるusingです。

通常のusingは、そのファイル内でのみ有効です。

C#
using System;

一方、global usingを使うと、複数のファイルで共通して使う名前空間を一度だけ定義できます。

C#
global using System;
global using MyApp.Models;
global using MyApp.Services;

これにより、各ファイルに同じusingを何度も書かなくて済みます。

ASP.NET Coreなどのプロジェクトでは、テンプレートによって一部のusingが暗黙的に有効になっていることもあります。

4. namespaceの使い方をサンプルコードで解説

4-1. 同じnamespace内のクラスを呼び出す例

同じnamespace内にあるクラスは、usingを書かなくてもクラス名だけで呼び出せます。

C#
namespace MyApp.Services;

public class MessageService
{
public string GetMessage()
{
return "こんにちは";
}
}
C#
namespace MyApp.Services;

public class GreetingService
{
public void SayHello()
{
var messageService = new MessageService();
string message = messageService.GetMessage();

Console.WriteLine(message);
}
}

MessageServiceGreetingServiceはどちらもMyApp.Services名前空間に所属しています。

そのため、GreetingServiceの中でMessageServiceをそのまま呼び出せます。

4-2. 別namespaceのクラスをusingで呼び出す例

別のnamespaceにあるクラスを使う場合は、usingを使うと便利です。

まず、Userクラスを定義します。

C#
namespace MyApp.Models;

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

次に、別の名前空間にあるクラスから呼び出します。

C#
using MyApp.Models;

namespace MyApp.Services;

public class UserService
{
public void PrintUser()
{
var user = new User
{
Name = "Taro"
};

Console.WriteLine(user.Name);
}
}

UserServiceMyApp.Servicesにあります。

UserMyApp.Modelsにあります。

名前空間が違うため、using MyApp.Models;を書くことでUserを短い名前で使えるようにしています。

4-3. 完全修飾名でクラスを呼び出す例

usingを使わずに、完全修飾名で呼び出すこともできます。

C#
namespace MyApp.Services;

public class UserService
{
public void PrintUser()
{
var user = new MyApp.Models.User
{
Name = "Hanako"
};

Console.WriteLine(user.Name);
}
}

この書き方では、MyApp.Models.Userとフルネームで指定しています。

クラス名が重複していて、どちらを使うか明確にしたい場合にも完全修飾名は役立ちます。

4-4. 複数ファイルに同じnamespaceを定義する例

C#では、複数のファイルに同じnamespaceを書いても問題ありません。

たとえば、次の2つのファイルがあるとします。

C#
namespace MyApp.Models;

public class User
{
public string Name { get; set; }
}
C#
namespace MyApp.Models;

public class Product
{
public string ProductName { get; set; }
}

どちらもMyApp.Models名前空間に所属しています。

そのため、同じ名前空間内では次のように自然に扱えます。

C#
namespace MyApp.Models;

public class Order
{
public User Customer { get; set; }

public Product Item { get; set; }
}

namespaceはファイル単位で完全に分離されるものではなく、同じ名前空間であれば複数ファイルにまたがって定義できます。

4-5. namespaceを分けてコードを整理する実践例

実際のアプリケーションでは、役割ごとにnamespaceを分けると見通しがよくなります。

たとえば、ユーザー情報を扱うアプリケーションを考えます。

C#
namespace UserManagementApp.Models;

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

public string Name { get; set; }
}
C#
using UserManagementApp.Models;

namespace UserManagementApp.Repositories;

public class UserRepository
{
public User FindById(int id)
{
return new User
{
Id = id,
Name = "Sample User"
};
}
}
C#
using UserManagementApp.Models;
using UserManagementApp.Repositories;

namespace UserManagementApp.Services;

public class UserService
{
private readonly UserRepository _repository = new UserRepository();

public void ShowUser(int id)
{
User user = _repository.FindById(id);

Console.WriteLine($"ID: {user.Id}, Name: {user.Name}");
}
}

この例では、役割ごとに名前空間を分けています。

C#
UserManagementApp.Models
UserManagementApp.Repositories
UserManagementApp.Services

Modelsにはデータを表すクラス、Repositoriesにはデータ取得を担当するクラス、Servicesには処理の流れを担当するクラスを配置しています。

このように分けることで、クラスの役割が分かりやすくなります。

5. 初心者がつまずきやすいnamespaceのエラーと対処法

5-1. 「型または名前空間の名前が見つかりません」エラー

C#でよく出るエラーのひとつが、次のようなものです。

型または名前空間の名前 'User' が見つかりません

英語環境では次のように表示されることもあります。

The type or namespace name 'User' could not be found

このエラーは、C#コンパイラが指定されたクラスや名前空間を見つけられないときに発生します。

主な原因は次のとおりです。

usingが不足している
namespace名が間違っている
クラス名が間違っている
プロジェクト参照が不足している
アクセス修飾子がpublicになっていない

たとえば、MyApp.Models.Userを使いたいのにusingを書いていない場合、次のように修正します。

C#
using MyApp.Models;

var user = new User();

または、完全修飾名で書きます。

C#
var user = new MyApp.Models.User();

5-2. usingを書いているのに認識されない原因

usingを書いているのにクラスが認識されない場合もあります。

C#
using MyApp.Models;

var user = new User();

このように書いているのにエラーが出る場合、次の点を確認しましょう。

まず、実際のnamespace名が合っているか確認します。

C#
namespace MyApp.Model;

このように単数形のModelになっている場合、using MyApp.Models;とは一致しません。

正しくは次のどちらかにそろえる必要があります。

C#
namespace MyApp.Models;

または

C#
using MyApp.Model;

次に、クラスがpublicになっているか確認します。

C#
namespace MyApp.Models;

class User
{
}

この場合、クラスは同じアセンブリ内からは使えますが、別プロジェクトから参照する場合は使えないことがあります。

別プロジェクトから使うクラスは、基本的にpublicを付けます。

C#
namespace MyApp.Models;

public class User
{
}

5-3. namespace名とフォルダ構成が違う場合の注意点

C#では、namespace名とフォルダ名が必ず一致していなければならないわけではありません。

たとえば、Modelsフォルダにあるファイルで、次のようなnamespaceを書くことも文法上は可能です。

C#
namespace MyApp.Entities;

public class User
{
}

ただし、フォルダ名とnamespace名が大きく違うと、コードを読む人が混乱しやすくなります。

一般的には、フォルダ構成とnamespaceはある程度そろえることが多いです。

たとえば、次のような構成です。

Models/User.cs
Services/UserService.cs
Repositories/UserRepository.cs

それぞれのnamespaceは次のようにします。

C#
namespace MyApp.Models;
namespace MyApp.Services;
namespace MyApp.Repositories;

必須ではありませんが、保守しやすいコードにするためには、フォルダと名前空間を対応させるのがおすすめです。

5-4. クラス名の重複で発生するあいまいな参照

同じクラス名が複数のnamespaceに存在する場合、あいまいな参照が発生することがあります。

C#
using MyApp.Models;
using MyApp.ViewModels;

var user = new User();

もしMyApp.Models.UserMyApp.ViewModels.Userの両方が存在すると、C#はどちらのUserを使えばよいか判断できません。

この場合は、完全修飾名で指定します。

C#
var modelUser = new MyApp.Models.User();
var viewModelUser = new MyApp.ViewModels.User();

または、usingエイリアスを使う方法もあります。

C#
using ModelUser = MyApp.Models.User;
using ViewModelUser = MyApp.ViewModels.User;

var modelUser = new ModelUser();
var viewModelUser = new ViewModelUser();

同じ名前のクラスが増えると混乱しやすいため、役割に応じて分かりやすいクラス名を付けることも大切です。

5-5. アセンブリ参照やプロジェクト参照が不足しているケース

namespaceusingが正しくても、別プロジェクトのクラスを使う場合はプロジェクト参照が必要です。

たとえば、次のような構成があるとします。

MyApp.Web
MyApp.Core

MyApp.WebからMyApp.Coreのクラスを使いたい場合、MyApp.WebMyApp.Coreを参照している必要があります。

参照がない状態で次のように書いても、クラスは見つかりません。

C#
using MyApp.Core.Models;

この場合は、Visual Studioや.NET CLIでプロジェクト参照を追加します。

.NET CLIでは次のようにします。

Bash
dotnet add MyApp.Web reference MyApp.Core

その後、必要に応じてusingを書きます。

C#
using MyApp.Core.Models;

usingはあくまで名前を短く書くためのものです。

参照されていないプロジェクトの型を、usingだけで使えるようにすることはできません。

5-6. 大文字・小文字の違いによるミス

C#は大文字・小文字を区別します。

そのため、次の2つは別の名前として扱われます。

C#
MyApp.Models
MyApp.models

クラス名も同様です。

C#
User
user

たとえば、次のようなコードはエラーになります。

C#
using MyApp.models;

var user = new User();

実際の名前空間がMyApp.Modelsであれば、正しくは次のように書きます。

C#
using MyApp.Models;

var user = new User();

エラーが出たときは、スペルだけでなく大文字・小文字も確認しましょう。

6. namespaceを使うときのベストプラクティス

6-1. プロジェクト名に合わせてnamespaceを設計する

namespaceは、基本的にプロジェクト名を起点にすると分かりやすくなります。

たとえば、プロジェクト名がTaskManagerなら、次のような名前空間にします。

C#
TaskManager.Models
TaskManager.Services
TaskManager.Repositories
TaskManager.Controllers

プロジェクト名を起点にすることで、他のライブラリやプロジェクトと名前が衝突しにくくなります。

会社やチームで開発している場合は、会社名や組織名を含めることもあります。

C#
ExampleCompany.TaskManager.Models

ただし、長すぎる名前空間は扱いづらいため、分かりやすさとのバランスが大切です。

6-2. 機能や役割ごとにnamespaceを分ける

namespaceは、クラスの役割ごとに分けると管理しやすくなります。

よくある分け方は次のとおりです。

C#
MyApp.Models
MyApp.Services
MyApp.Repositories
MyApp.Controllers
MyApp.ViewModels
MyApp.Helpers

たとえば、データを表すクラスはModels、ビジネスロジックはServices、データアクセスはRepositoriesに分けます。

C#
namespace MyApp.Models;
C#
namespace MyApp.Services;
C#
namespace MyApp.Repositories;

このように整理すると、クラスの場所や役割を推測しやすくなります。

6-3. 深すぎるnamespace階層を避ける

namespaceは階層化できますが、深すぎる階層は避けたほうがよいです。

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

C#
MyCompany.MyProduct.Application.Features.Users.Commands.CreateUser.Handlers

大規模な設計では必要になることもありますが、初心者や小規模なアプリケーションでは複雑になりすぎる可能性があります。

最初は次の程度でも十分です。

C#
MyApp.Models
MyApp.Services
MyApp.Repositories

名前空間は細かく分けすぎるよりも、コードを探しやすくすることを優先しましょう。

6-4. 不要なusingは削除する

使っていないusingが多いと、コードが読みづらくなります。

C#
using System;
using System.Collections.Generic;
using System.Linq;
using MyApp.Models;
using MyApp.Services;

この中で実際に使っていない名前空間があれば削除しましょう。

不要なusingを削除しても、プログラムの動作には影響しません。

むしろ、必要な依存関係が分かりやすくなります。

Visual StudioやVisual Studio Codeでは、不要なusingを自動で整理する機能があります。

6-5. ファイルスコープnamespaceを活用してコードを簡潔にする

C# 10以降を使っている場合は、ファイルスコープnamespaceを活用するとコードが見やすくなります。

従来の書き方は次のようになります。

C#
namespace MyApp.Services
{
public class UserService
{
public void Execute()
{
Console.WriteLine("実行しました");
}
}
}

ファイルスコープnamespaceを使うと、次のように書けます。

C#
namespace MyApp.Services;

public class UserService
{
public void Execute()
{
Console.WriteLine("実行しました");
}
}

インデントが1段減るため、特にクラスの中身が長い場合に読みやすくなります。

新しいC#プロジェクトでは、ファイルスコープnamespaceを標準的に使う場面も増えています。

7. namespaceに関するよくある質問

7-1. namespace名とフォルダ名は必ず一致させるべき?

必ず一致させる必要はありません。

C#の文法上、フォルダ名とnamespace名が違っていてもコンパイルできます。

ただし、実務ではフォルダ構成とnamespace名をそろえることが多いです。

たとえば、Servicesフォルダにあるクラスなら、次のようにします。

C#
namespace MyApp.Services;

フォルダ名とnamespace名をそろえると、コードの場所と役割が分かりやすくなります。

7-2. 1つのファイルに複数のnamespaceを書ける?

書けます。

ブロック形式であれば、1つのファイルに複数のnamespaceを書くことができます。

C#
namespace MyApp.Models
{
public class User
{
}
}

namespace MyApp.Services
{
public class UserService
{
}
}

ただし、1つのファイルに複数の名前空間を書くと、ファイルの役割が分かりにくくなることがあります。

基本的には、1ファイルに1つの主要なクラス、1つのnamespaceという形が分かりやすいです。

なお、ファイルスコープnamespaceは1ファイルに1つだけ書けます。

C#
namespace MyApp.Models;

ファイルスコープnamespaceを使う場合、そのファイル全体がその名前空間に属します。

7-3. 同じnamespaceを複数ファイルに書いてもよい?

問題ありません。

むしろ、C#では同じnamespaceを複数ファイルに書くことが一般的です。

たとえば、MyApp.Modelsに複数のクラスを配置する場合、次のようになります。

C#
namespace MyApp.Models;

public class User
{
}
C#
namespace MyApp.Models;

public class Product
{
}
C#
namespace MyApp.Models;

public class Order
{
}

これらはすべて同じMyApp.Models名前空間に所属します。

7-4. namespaceを省略してもC#は動く?

小さなコードであれば、namespaceを省略しても動く場合があります。

C#
public class Program
{
public static void Main()
{
Console.WriteLine("Hello");
}
}

ただし、実際のアプリケーションではnamespaceを使うのが一般的です。

namespaceを使わないと、クラス名の衝突が起きやすくなり、コードの整理もしにくくなります。

学習用の短いサンプルでは省略しても構いませんが、実務や中規模以上の開発ではnamespaceを使うようにしましょう。

7-5. usingをたくさん書くのは悪いこと?

必要なusingであれば問題ありません。

ただし、使っていないusingが大量に残っていると、コードが読みづらくなります。

たとえば、次のように必要な名前空間だけを書くのが理想です。

C#
using MyApp.Models;
using MyApp.Services;

不要なusingは削除しておくと、コードの依存関係が分かりやすくなります。

また、よく使うusingglobal usingにまとめることもできます。

C#
global using System;
global using MyApp.Models;

ただし、何でもglobal usingにすると、どこから型が来ているのか分かりにくくなることがあります。

7-6. Javaのpackageとの違いは?

C#のnamespaceは、Javaのpackageに似ています。

どちらもクラスを整理し、名前の衝突を避けるために使われます。

ただし、C#のnamespaceはフォルダ構成と必ず一致する必要はありません。

Javaでは、一般的にpackage名とディレクトリ構造を一致させます。

一方、C#ではフォルダ名とnamespace名が違っていても文法上は問題ありません。

ただし、C#でも実務ではフォルダ構成とnamespaceをそろえることが多いです。

また、Javaではimportを使って他のパッケージのクラスを読み込みますが、C#ではusingを使います。

Java
import java.util.List;
C#
using System.Collections.Generic;

考え方は似ていますが、言語仕様や慣習には違いがあります。

まとめ

csharp namespaceは、C#でクラスや型を整理するために欠かせない仕組みです。

namespaceを使うことで、クラスを役割ごとに分類でき、名前の衝突も避けやすくなります。

基本的な考え方は、namespaceは型を定義するときの所属先、usingは別の名前空間にある型を使いやすくするためのものです。

たとえば、次のようにnamespaceでクラスを定義します。

C#
namespace MyApp.Models;

public class User
{
}

そして、別の場所から使うときはusingを書きます。

C#
using MyApp.Models;

var user = new User();

usingを書かない場合でも、完全修飾名を使えば呼び出せます。

C#
var user = new MyApp.Models.User();

初心者が特につまずきやすいのは、usingの不足、名前空間名の間違い、大文字・小文字のミス、プロジェクト参照の不足です。

エラーが出たときは、次の点を確認しましょう。

namespace名は正しいか
usingは書かれているか
クラス名のスペルは合っているか
大文字・小文字は一致しているか
クラスはpublicになっているか
必要なプロジェクト参照は追加されているか

C# 10以降では、ファイルスコープnamespaceを使うことでコードをより簡潔に書けます。

C#
namespace MyApp.Services;

public class UserService
{
}

namespaceは、C#のコードを整理し、保守しやすくするための基本機能です。

最初は難しく感じるかもしれませんが、「クラスを分類するための名前のまとまり」と考えると理解しやすくなります。