先に要点
- Spring Boot は、Java で業務システムや API を作るときに、最初の設定・依存関係・運用の土台を整えやすいフレームワークです。「動くもの」と「本番で運用できる形」を両立しやすいのが、業務系で選ばれる本当の理由です。
- 採用するかどうかの分かれ目は「複雑な SQL とトランザクションをどこまで扱うか」「保守する人材が Java を読めるか」「10年使うか」です。軽い試作や個人開発なら別の選択肢の方が速いこともあります。
- DB アクセスは ORM の Spring Data JPA(Hibernate)と、SQL を自分で書く MyBatis の二択で詰まりやすいです。JPA は N+1 問題、MyBatis は実行計画の管理が論点になります。
- Actuator の
/actuator/healthなどは本番で野放しにすると情報漏えいにつながります。公開する エンドポイント の絞り込み・管理ポートの分離・認証の3点で守ります。
「Spring Boot は名前を聞くけれど、結局なにが便利で、なぜ業務システムでよく出てくるのか分からない」と感じる人は多いです。
初心者から見ると、「Java は固そう」「設定が多そう」「企業システム向けで近寄りにくい」という印象もあると思います。
ただ、Spring Boot がよく使われる理由は、単に「大企業っぽいから」ではありません。
認証、権限、DB 連携、外部システム連携、監視、長期運用のしやすさまで含めて、業務システムで困りやすい点をかなり整理しやすいからです。
この記事では、基本だけでなく、実際の案件で Spring Boot を採用/不採用に分けた判断、JPA と MyBatis で詰まりやすい点、Actuator を本番でどう公開制御するかまで、設定キーと数値を添えて踏み込みます。
フレームワーク全体の比較から見たいなら、代表的なフレームワーク7選｜Laravel・Django・Rails・Spring Boot・Next.js・Nuxt・FastAPIの向いている用途を比較 も先に読むと全体像がつかみやすいです。
Spring Bootとは？
Spring Boot は、Java でバックエンドや業務システムを作るときによく使われるフレームワークです。
Spring の公式サイトでも、Spring Boot は「Spring を使って本番環境向けのアプリを素早く作れるようにする」ものとして紹介されています。
ここで大事なのは、Spring Boot が「Java の難しいところを全部消す魔法」ではないことです。
そうではなく、業務アプリで毎回必要になりやすい設定や部品の組み合わせを、最初からかなり整えやすくする道具だと考えると分かりやすいです。
公式ドキュメントでは、必要な依存関係をまとめた starter、設定を減らしやすい auto-configuration、本番運用向け機能の Actuator などが大きな柱として出てきます。
たとえば spring-boot-starter-web を1行入れるだけで、組み込み サーバー(デフォルトは Tomcat)、JSON 変換(Jackson)、REST API 用のアノテーション群がまとめて入ります。バージョン整合は親 BOM(Bill of Materials)が握っているので、ライブラリ同士のバージョン地獄に落ちにくいのが効きます。
業務案件で採用/不採用が分かれる本当の境目
「Spring Boot は業務システムで強い」とよく言われますが、すべての案件で正解になるわけではありません。実務では次の3点で判断が分かれます。
複数テーブルにまたがる集計、行ロック、複数更新を1つの トランザクション でまとめたい基幹系。@Transactional による宣言的トランザクションと、後述する JPA / MyBatis の使い分けが効きます。
不採用に傾く: 軽い試作・小規模
JVM の起動に数秒、メモリも数百MB単位を見ておく必要があり、1画面の社内ツールや個人開発では Laravel や Django の方が立ち上がりが速いことが多いです。
不採用に傾く: フロント体験が主役
UI の作り込みやリアルタイム性が中心なら、Next.js や Nuxt を主役に、Spring Boot は API 専任に回す構成の方が素直なこともあります。
実務的な目安として、登録・参照系の画面が数十本あり、夜間バッチや帳票、外部 API 連携、監査ログが絡む規模になると Spring Boot の整理しやすさが効いてきます。逆に、テーブルが数本でCRUDが中心の小さな社内ツールなら、わざわざ Java を選ばずに済む場面も多い、という温度感です。
JPA(Hibernate)とMyBatis、どこで詰まるか
業務システムで最初に大きく分かれるのが DB アクセスの方式です。Spring Boot では ORM の Spring Data JPA(内部実装は Hibernate)と、SQL を自分で書く MyBatis のどちらかを選ぶことが多く、ここの選択を誤ると後半で痛い目を見ます。
| 観点 | Spring Data JPA(Hibernate) | MyBatis |
|---|---|---|
| 書き方 | エンティティとリポジトリ。SQL を書かずに findByXxx で取得 |
SQL を XML やアノテーションに自分で書く |
| 得意 | 単純CRUD、コード量削減、DB 差異の吸収 | 複雑な集計、結合の多い検索、実行計画の制御 |
| 詰まりやすい点 | N+1 問題、発行SQLが見えにくい、複雑検索が苦しい | SQL が増えると保守が重い、DB 依存が強くなる |
| 向く案件 | 登録・参照が中心の業務アプリ | 帳票・分析・大量データの集計系 |
JPAで一番踏むのは N+1 問題
JPA で典型的に詰まるのが N+1 問題です。失敗の形で示します。
現象: 注文(Order)を10件取得して、各注文の明細(OrderItem)を画面に出すだけのコードで、ログに SELECT が11回出る。1件のときは速いのに、本番のデータ量で一覧画面が数秒固まる。
原因: 親(Order)を取る1回の SQL のあと、明細を遅延ロード(LAZY)で参照した瞬間に、子ごとに追加 SQL が走る。10件なら 1+10=11 回。これが N+1 です。一覧件数が増えるほど線形に悪化します。
確認手順: まず発行SQLを見えるようにします。開発環境で application.properties に次を入れ、ログのクエリ回数を数えるのが最短です。
回避: 取得方法は3通りで使い分けます。
- fetch join: JPQL に
JOIN FETCH o.itemsと書き、親子を1回の SQL で取る。最も素直。ただし複数のコレクションを同時に fetch join するとデカルト積で行が膨らむ(明細10×支払5で50行)ため、同時 fetch は原則1コレクションまで。 - @EntityGraph: リポジトリのメソッドに
@EntityGraph(attributePaths = {"items"})を付け、宣言的に一括取得を指定する。JPQL を書かずに済むので Spring Data のメソッド命名と相性がよい。 - バッチ取得:
spring.jpa.properties.hibernate.default_batch_fetch_size=100を設定すると、子の遅延ロードをIN (...)でまとめて取り、N回が数回に圧縮される。複数コレクションを持つ画面で、デカルト積を避けつつ効くのが利点です。
MyBatisは「複雑SQLと実行計画」を握りたいときに効く
逆に、5テーブルを結合して条件で集計するような検索や、月次の帳票SQLは、JPA で組み立てるより MyBatis で SQL を直接書いた方が読みやすく、実行計画も管理しやすいです。PostgreSQL なら EXPLAIN ANALYZE、MySQL なら EXPLAIN で実行計画を確認し、インデックスが効いているかを SQL 単位で詰められます。JPA は生成 SQL が見えにくく、ここの最適化がしづらいのが弱点です。
実務では「登録・参照系の大半は JPA、重い検索・帳票だけ MyBatis」という併用構成もよく取られます。最初に全部 JPA で組んでから一部だけ MyBatis に逃がす、という順番が現実的です。
MavenやGradleはどう関係するのか
Spring Boot を触ると、すぐ Maven や Gradle が出てきます。
これは Spring Boot の一部というより、Spring Boot アプリを組み立てるためのビルドツールです。
| 要素 | 役割 |
|---|---|
| Spring Boot | アプリ全体を作りやすくするフレームワーク |
| Maven / Gradle | 依存関係管理、テスト、ビルドをまとめる道具 |
| Spring Initializr | 最初のひな形を公式に作るサービス |
| Actuator | 監視や状態確認をしやすくする運用向け機能 |
Maven は pom.xml に XML で依存関係を書く方式で、情報量が多く安定。Gradle は build.gradle(または Kotlin DSL)に短く書け、ビルドキャッシュで再ビルドが速い、という違いです。どちらも実行は ./mvnw spring-boot:run / ./gradlew bootRun のように同梱のラッパー(wrapper)で行えるので、JDK 以外をマシンに入れずに済みます。
どんな業務システムに向いている？
Spring Boot が向いているのは、「画面をすばやく作ること」だけでなく、「裏側の処理や保守も大きい」システムです。たとえば、こんな場面で名前が出やすいです。
- 社内の申請・承認システム
- 会員情報、契約情報、請求情報などを扱う基幹系の業務アプリ
- 外部 API や他システム連携が多いバックエンド
- 長く保守する前提の企業向け Web システム
- 夜間バッチや監査ログが重要なシステム
逆に、「とにかく軽く試作したい」「個人で小さく始めたい」「まずフロントの体験が主役」という場面では、Laravel、Django、Next.js、Nuxt など別の候補の方が入りやすいこともあります。
Actuatorを本番でどう公開制御するか
Actuator は 監視 や状態確認に便利ですが、設定を理解しないまま本番に出すと事故のもとです。ここは「公開範囲」「ポート」「認証」の3点で管理します。
まず公開範囲。デフォルトは health だけ
Spring Boot 3.x では、HTTP 経由で公開されるのはデフォルトで /actuator/health だけです(/actuator/info は有効でも既定では公開されません。両方を公開していたのは 2.x の挙動です)。逆に言うと、安易に「全部出す」設定にすると危険なものまで露出します。よくあるアンチパターンが次です。
現象: 監視のために management.endpoints.web.exposure.include=* を本番に入れてしまう。
原因: ワイルドカードは /actuator/env(環境変数や設定値)、/actuator/heapdump、/actuator/mappings なども一緒に公開する。env には DB のホスト名や場合によっては資格情報の断片が見えることがある。
回避: 必要なものだけを明示列挙します。
management.endpoints.web.exposure.include=health,info,prometheusのように、出すものだけ書くhealthの詳細(DB やディスクの内訳)はmanagement.endpoint.health.show-details=when-authorizedで認証済みのときだけ見せる(デフォルトはnever)
ポートを分離する
アプリ本体と管理エンドポイントを別ポートに分けると、ファイアウォールや ロードバランサー の設定で「管理ポートは社内からのみ」と切り分けやすくなります。
| 設定キー | 値の例 | 意味 |
|---|---|---|
server.port |
8080 | 業務アプリ本体。外部公開する |
management.server.port |
9090 | Actuator 専用。外部に出さず社内/監視からのみ許可 |
management.endpoints.web.base-path |
/manage | 既定の /actuator をずらして推測されにくくする(補助) |
これで /actuator/health は 9090 番でだけ応答し、利用者がアクセスする 8080 番には出ない、という分離ができます。
認証をかける
ポートを分けても、社内ネットワーク内から誰でも触れる状態は避けたいことが多いです。Spring Boot 3.x では Actuator のセキュリティは通常の Spring Security のルールと統合されているため、spring-boot-starter-security を入れ、/actuator/**(または分離した管理パス)に対して認証や特定ロールを要求する設定を1か所に書けます。ヘルスチェック用の /actuator/health だけは ロードバランサー から無認証で叩けるように個別許可する、という組み合わせが定番です。
最初の始め方
最初の入り方としては、次の流れがかなり無難です。
ここで大事なのは、最初から全部入りにしないことです。
業務システム向けの強みがあるフレームワークですが、学び始めから重くすると逆に見通しが悪くなります。特に N+1 や Actuator の公開制御は、最初の段階で発行SQLや公開エンドポイントを「目に見える」状態にしておくと、後から事故になりにくいです。
Spring Bootに関するよくある質問
Q. Spring と Spring Boot の違いは何ですか？
A. Spring は Java 向けの大きなフレームワーク群、Spring Boot はその上で「設定を最小化して動かせるようにまとめた起動キット」です。実務では Spring Boot 経由で Spring を使う形が標準です。
Q. JPA と MyBatis はどちらを選ぶべきですか？
A. 登録・参照が中心なら JPA、複雑な集計や帳票SQLを握りたいなら MyBatis が向きます。実務では「大半は JPA、重い検索だけ MyBatis」という併用も多いです。判断基準は「自分で SQL と実行計画を管理したいか」です。
Q. N+1 問題はどう見つけて直しますか？
A. まず spring.jpa.show-sql=true と logging.level.org.hibernate.SQL=DEBUG で発行SQLを可視化し、1リクエストのSELECT回数を数えます。親1件+子N件で増えていれば N+1 です。直し方は fetch join、@EntityGraph、default_batch_fetch_size の3択です。
Q. fetch join と EntityGraph はどう使い分けますか？
A. JPQL を書いて明示的に取りたいなら JOIN FETCH、リポジトリのメソッド命名を活かしたまま宣言的に取りたいなら @EntityGraph です。ただし複数コレクションを同時に fetch するとデカルト積で行が膨らむため、同時 fetch は1コレクションまでにし、残りはバッチ取得に逃がします。
Q. Actuator を本番で公開して大丈夫ですか？
A. 公開範囲を絞れば問題ありません。management.endpoints.web.exposure.include で必要なものだけ列挙し、env や heapdump を不用意に出さないこと、management.server.port でポートを分けること、Spring Security で認証をかけること、の3点が基本です。
Q. health エンドポイントの中身はどこまで見せられますか？
A. management.endpoint.health.show-details で制御します。デフォルトは never(UP/DOWN のみ)、when-authorized にすると認証済みユーザーにだけ DB やディスクの内訳を見せられます。ロードバランサー のヘルスチェックには UP/DOWN だけで十分なことが多いです。
Q. Maven と Gradle はどちらを使うべきですか？
A. 既存プロジェクトに合わせるのが原則です。新規なら、設定が短くビルドキャッシュで速い Gradle、情報が豊富で安定の Maven、というバランスで選ばれます。どちらもラッパー経由で実行でき、JDK 以外の追加インストールは不要です。
Q. Spring Boot アプリの本番デプロイはどうしますか？
A. jar を直接実行する、Docker イメージ化して Kubernetes や ECS、Cloud Run で動かす、専用アプリサーバーに乗せる、の3パターンが多いです。最近はコンテナ化が主流で、その場合も Actuator の管理ポート分離はコンテナのネットワーク設定と合わせて設計します。
まとめ
Spring Boot は、Java で業務システムや企業向けバックエンドを作るときに、設定、依存関係、運用の見通しを整えやすいフレームワークです。だからこそ、認証、DB、外部連携、監視、長期保守まで考える現場でよく使われます。
ただし採用は万能ではありません。複雑なSQLとトランザクション、保守人材、運用年数で判断が分かれ、DB アクセスは JPA の N+1 と MyBatis の実行計画管理という具体的な論点が待っています。Actuator も「公開範囲・ポート・認証」を押さえれば本番で安全に使えます。最初は Spring Initializr、ビルドツール1つ、小さな API 1本、という順で見るとかなり整理しやすいです。
Spring Boot だけでなく他の候補とも比べたいなら、代表的なフレームワーク7選｜Laravel・Django・Rails・Spring Boot・Next.js・Nuxt・FastAPIの向いている用途を比較 もあわせて読むと判断しやすくなります。
Java 自体が業務で強い理由から整理したい場合は、Javaが業務システムで強い理由は？長期運用・保守・人材面を実務目線で解説 もつながりやすいです。
参考リンク
- Spring: Spring Boot
- Spring Boot Reference: Developing with Spring Boot
- Spring Boot Reference: Build Systems
- Spring Boot Reference: Auto-configuration
- Spring Boot Reference: Production-ready Features (Actuator)
- Spring Boot Reference: Actuator Endpoints
- Spring Boot Reference: Monitoring and Management Over HTTP
- Spring Initializr: start.spring.io