【Spring Boot】Controllerは1つにすべき？用途ごとに分けるべき？
山崎講師こんにちは。ゆうせいです。
Spring Boot で RESTful API を開発するとき、「Controller クラスは 1 つにまとめるべき？」 それとも 「用途ごとに分けるべき？」 という疑問を持つことはありませんか？
結論から言うと、用途ごとに分けるのが一般的 ですが、小規模なプロジェクトでは 1 つにまとめることも可能です。
この記事では、それぞれのメリット・デメリットを解説し、どのようなケースで Controller を分けるべきか？ を考えていきます！
1. Controller の役割
Spring Boot における @RestController は、クライアントからのリクエストを受け取り、適切なレスポンスを返す役割 を持ちます。
基本的な構造は以下のようになります。
@RestController
@RequestMapping("/users")
public class UserController {
@GetMapping("/{id}")
public String getUser(@PathVariable Long id) {
return "User ID: " + id;
}
@PostMapping
public String createUser(@RequestBody String user) {
return "User created: " + user;
}
}
👉 この UserController は、ユーザー管理に関するリクエストを処理する役割を持っています。
2. Controller を1つにまとめる場合
2.1 小規模なプロジェクトでは OK
アプリが小規模（エンドポイントが少ない）な場合は、1つの Controller に全ての API を定義する ことも可能です。
@RestController
@RequestMapping("/api")
public class MainController {
// ユーザー関連
@GetMapping("/users/{id}")
public String getUser(@PathVariable Long id) {
return "User ID: " + id;
}
@PostMapping("/users")
public String createUser(@RequestBody String user) {
return "User created: " + user;
}
// 商品関連
@GetMapping("/products/{id}")
public String getProduct(@PathVariable Long id) {
return "Product ID: " + id;
}
@PostMapping("/products")
public String createProduct(@RequestBody String product) {
return "Product created: " + product;
}
}
✅ メリット
- コード量が少なく、管理しやすい（最初のうちはシンプル）
- ファイル数が少ないので、迷子になりにくい
❌ デメリット
- API が増えると コードが肥大化し、可読性が下がる
- 「どのエンドポイントが何の役割なのか」 が分かりにくくなる
- チーム開発では コンフリクト（競合）が発生しやすい
👉 結論：小規模なプロジェクトなら 1 つにまとめても OK！
3. Controller を用途ごとに分ける場合
3.1 一般的な Web API の構成
中規模以上のプロジェクトでは、「役割ごと」に Controller を分けるのが推奨 されます。
例えば、「ユーザー管理」「商品管理」「注文管理」 という3つの機能がある場合、それぞれ Controller を分けることで、可読性と保守性が向上します。
3.2 例：用途ごとに分けた Controller
@RestController
@RequestMapping("/users")
public class UserController {
@GetMapping("/{id}")
public String getUser(@PathVariable Long id) {
return "User ID: " + id;
}
@PostMapping
public String createUser(@RequestBody String user) {
return "User created: " + user;
}
}
@RestController
@RequestMapping("/products")
public class ProductController {
@GetMapping("/{id}")
public String getProduct(@PathVariable Long id) {
return "Product ID: " + id;
}
@PostMapping
public String createProduct(@RequestBody String product) {
return "Product created: " + product;
}
}
@RestController
@RequestMapping("/orders")
public class OrderController {
@GetMapping("/{id}")
public String getOrder(@PathVariable Long id) {
return "Order ID: " + id;
}
@PostMapping
public String createOrder(@RequestBody String order) {
return "Order created: " + order;
}
}
✅ メリット
- コードが整理され、可読性が向上
- 責務が明確になり、チーム開発がしやすい
- APIの増加に柔軟に対応可能
❌ デメリット
- ファイル数が増える（ただし、大規模開発ではむしろ整理しやすい）
- 各 Controller の共通処理をまとめる工夫が必要（
@RestControllerAdviceなど）
👉 結論：中〜大規模のプロジェクトでは「用途ごとに分ける」のがベスト！
4. どのように分けるべきか？
基本的には、「リソース単位」 で分けるのがベストプラクティスです。
| 機能 | Controller名 | エンドポイント |
|---|---|---|
| ユーザー管理 | UserController | /users |
| 商品管理 | ProductController | /products |
| 注文管理 | OrderController | /orders |
| 認証・ログイン | AuthController | /auth |
その他の考え方
- ドメイン単位（ECサイトなら
CartController,CheckoutControllerなど） - 管理画面用と分ける（
AdminUserController,AdminProductControllerなど）
5. まとめ
| 設計方針 | メリット | デメリット | 適用するプロジェクト |
|---|---|---|---|
| Controller を 1 つにする | コードが少なく、シンプル | 規模が大きくなると管理が困難 | 小規模（エンドポイントが少ない） |
| 用途ごとに分ける | 可読性・保守性が向上 | ファイル数が増える | 中〜大規模（API が多い） |
6. 実際の開発でのポイント
✅ プロジェクトの規模を考慮する（小規模なら 1 つでも OK、大規模なら分割が必須）
✅ 責務（リソース）ごとに分ける（UserController, ProductController など）
✅ 共通処理（エラーハンドリング, ロギング）は @RestControllerAdvice にまとめる
7. 結論
「Controller を 1 つにすべきか？」の答えは、プロジェクトの規模と用途による ですが、
基本的には「用途ごとに分ける」ほうが、可読性・保守性の面で優れています！
実際のプロジェクトでは、以下の方針を意識するとよいでしょう：
- まずは1つの Controller でシンプルに開発（プロトタイプ段階）
- APIが増えてきたら、リソースごとに適切に分割
- 共通処理を
@RestControllerAdvice,Service層へ整理してスッキリさせる
Spring Boot の API 設計は、「適切な責務分割」が重要 なので、状況に応じて適切な設計を選びましょう！🚀
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
- 代表取締役
-
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。
