Spring Bootの@Transactionalはどこに付ける？

2026年11月4日

AIによる要約

Spring Bootの@Transactionalは、基本的にRepositoryではなく、業務処理のまとまりを表すServiceメソッドに付けることが多いです。どこからどこまでを1つの更新単位にするかを決めるためのアノテーションであり、何となく付けるものではありません。

新人SE

@Transactionalって、Repositoryに付けておけばDB更新は安全になりますか？

ポンコツSE

Repository単体ではなく、業務処理のまとまりで考えます。複数の更新を1つの成功・失敗として扱いたいなら、Serviceに付けるのが基本です。

Spring BootでDB更新を扱うと、@Transactionalというアノテーションが出てきます。

初学者は、とりあえずRepositoryや更新メソッドに付ければよいと考えがちですが、現場では「どこからどこまでを1つのトランザクションにするか」がレビューで見られます。

この記事のポイント

@Transactionalは更新処理の境界を決める
基本は業務処理のまとまりであるServiceに付ける
ControllerやRepositoryに何となく付けない
例外時にどこまでロールバックしたいかを考える

実行用サンプル

先に handle=taken を登録し、新しいユーザーで同じハンドルを使ってプロフィール保存を失敗させます。Service のトランザクション有無だけを変えて、例外後のDB件数を比較します。 JDK 17とMaven 3.9系で mvn test を実行できます。ZIPにはソース全文・テスト・pom.xml・READMEを収録しています。

GitHubでコードを見るサンプルZIPを取得

@Transactionalは何をするものか

@Transactionalは、DB更新を1つのまとまりとして扱うためのアノテーションです。処理の途中で例外が起きた場合、途中までの更新をなかったことにする、という考え方につながります。

@Transactional
public void register(UserRegisterRequest request) {
    User user = userRepository.save(new User(request.getName()));
    profileRepository.save(new Profile(user.getId(), request.getBio()));
}

この例では、ユーザー登録とプロフィール登録を1つのまとまりとして扱いたいです。プロフィール登録で失敗した場合、ユーザーだけ登録されると中途半端な状態になります。

基本はServiceに付ける

最初はユーザー1件・プロフィール1件です。外側のトランザクションがなければ、プロフィール登録だけが失敗して2件・1件になります。Serviceの register() をSpringの管理するBeanから呼び出した場合は、ユーザー登録もロールバックされて1件・1件です。テスト自身には @Transactional を付けず、サービス呼び出しが終了した後に別のRepository呼び出しで数えます。

RegistrationServiceTest.java の全文

package info.syachiku.audit;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.dao.DataIntegrityViolationException;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

@SpringBootTest
class RegistrationServiceTest {
    @Autowired
    private RegistrationService service;
    @Autowired
    private RegisteredUserRepository users;
    @Autowired
    private UserProfileRepository profiles;

    @BeforeEach
    void occupiedHandle() {
        profiles.deleteAll();
        users.deleteAll();
        service.register("既存ユーザー", "taken");
    }

    @Test
    void 個々の保存でコミットされプロフィールだけ失敗する() {
        assertThrows(DataIntegrityViolationException.class,
                () -> service.registerWithoutTransaction("新規ユーザー", "taken"));

        assertEquals(2, users.count());
        assertEquals(1, profiles.count());
    }

    @Test
    void 一つのサービス境界ならユーザー保存もロールバックされる() {
        assertThrows(DataIntegrityViolationException.class,
                () -> service.register("新規ユーザー", "taken"));

        assertEquals(1, users.count());
        assertEquals(1, profiles.count());
    }
}

現場では、@TransactionalをServiceの更新メソッドに付けることが多いです。理由は、Serviceが業務処理のまとまりを表す場所だからです。

RegistrationService.java の全文

package info.syachiku.audit;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class RegistrationService {
    private final RegisteredUserRepository users;
    private final UserProfileRepository profiles;

    RegistrationService(RegisteredUserRepository users, UserProfileRepository profiles) {
        this.users = users;
        this.profiles = profiles;
    }

    public void registerWithoutTransaction(String name, String handle) {
        saveUserAndProfile(name, handle);
    }

    @Transactional
    public void register(String name, String handle) {
        saveUserAndProfile(name, handle);
    }

    private void saveUserAndProfile(String name, String handle) {
        RegisteredUser user = users.save(new RegisteredUser(name));
        profiles.save(new UserProfile(user.getId(), handle));
    }
}

このあとに示すController・Repository・自己呼び出しの断片は、境界を考えるための別の例です。配布例で実際に検証するのは、上の RegistrationService です。

Repositoryに付ければよいわけではない

RepositoryはDBアクセスの部品です。1回の保存や検索だけを見ればRepositoryでもよさそうに見えますが、業務処理はRepository呼び出し1回で終わらないことがあります。

public void register(UserRegisterRequest request) {
    userRepository.save(user);
    profileRepository.save(profile);
    pointRepository.save(firstLoginPoint);
}

この3つの保存を1つの成功・失敗として扱いたいなら、個々のRepositoryではなく、この処理全体を囲むServiceに@Transactionalを付ける方が自然です。

Controllerに付けるのは避ける

Controllerに@Transactionalを付けると、HTTPリクエスト全体をトランザクションとして扱う形になります。画面/APIの入口とDB更新の境界が混ざり、責務が分かりにくくなります。

@PostMapping("/users")
@Transactional
public ResponseEntity<Void> register(@RequestBody UserRegisterRequest request) {
    userService.register(request);
    return ResponseEntity.ok().build();
}

この書き方は、Controllerがトランザクション境界まで持ってしまっています。通常はService側へ移した方がレビューで通りやすいです。

readOnlyを使う場面

検索だけの処理では、@Transactional(readOnly = true)を使う現場もあります。読み取り専用であることを明示し、更新処理との区別を付けるためです。

@Transactional(readOnly = true)
public UserDetailResponse findDetail(Long userId) {
    User user = userRepository.findById(userId)
            .orElseThrow(() -> new UserNotFoundException(userId));
    return UserDetailResponse.from(user);
}

ただし、すべての検索に必ず付けるかどうかはプロジェクト方針によります。既存コードの書き方に合わせましょう。

ロールバックされる例外を意識する

トランザクションでは、例外が起きたときにロールバックするかどうかも重要です。Springでは、基本的に実行時例外が起きるとロールバックされる、と理解しておくとよいです。

@Transactional
public void cancel(Long orderId) {
    Order order = orderRepository.findById(orderId)
            .orElseThrow(() -> new OrderNotFoundException(orderId));

    order.cancel();

    if (order.isInvalidState()) {
        throw new CannotCancelOrderException(orderId);
    }
}

新人のうちは、例外を握りつぶすコードに注意します。例外をcatchして何もしないと、失敗したのに正常終了した扱いになり、意図したロールバックにならないことがあります。

@Transactional
public void importCsv(File file) {
    try {
        importService.importFile(file);
    } catch (Exception e) {
        log.error("CSV取込に失敗しました", e);
    }
}

この例では、例外をcatchして外へ出していません。仕様として続行するなら別ですが、失敗時にロールバックしたい処理なら危険です。

同じクラス内の呼び出しに注意

少し現場寄りの注意点として、同じクラス内で@Transactional付きメソッドを呼ぶと、期待通り効かないことがあります。Springの仕組み上、プロキシ経由で呼ばれることが前提になるためです。

public void registerAll(List<UserRequest> requests) {
    for (UserRequest request : requests) {
        registerOne(request);
    }
}

@Transactional
public void registerOne(UserRequest request) {
    userRepository.save(new User(request.getName()));
}

新人のうちは深追いしすぎなくてよいですが、@Transactionalを付けたのに効かないときの典型パターンとして覚えておくと役立ちます。

現場レビューではどう見られるか

// レビューコメント例
// ユーザー登録とプロフィール登録が別々の更新になっています。
// 片方だけ成功するとデータ不整合になるため、
// Serviceのregisterメソッドに@Transactionalを付けて1つの更新単位にしてください。

レビューでは、アノテーションが付いているかだけでなく、更新単位が業務的に正しいかを見られます。

レビュー前のセルフチェック

@Transactionalの確認リスト

どこからどこまでを1つの更新単位にしたいか説明できるか
ControllerではなくServiceに付けているか
複数Repository更新が途中で失敗したときの状態を考えたか
例外を握りつぶしてロールバックを妨げていないか
既存プロジェクトの@Transactional方針に合わせているか

この記事とあわせて読みたい

まとめ

@Transactionalは、何となくDB更新に付けるものではありません。業務処理のまとまりを考え、基本はServiceの更新メソッドに付けます。途中で失敗したときにどこまで戻したいかを説明できるようにしておきましょう。

-設計・テスト・レビュー
-Spring, トランザクション

設計・テスト・レビュー

2026/11/4

SpringのServiceが肥大化したらどこで分ける？計算・保存・通知の分割例

SpringのService分割を、注文処理のBefore／Afterで比較。計算と通知を分けても、在庫・保存・監査の順番を保ちます。SpringとH2で正常・失敗時のDBを検証し、全文コードと実行用ZIPを提供します。

設計・テスト・レビュー

2026/11/4

システム移行のDNS切り替え｜新旧の併存と切り戻しを3アプリで考える

このページに書いてあること 3つのWebアプリを刷新する例で、DNSを一度に切り替える方式と、アプリごとに切り替える方式を比べます。接続先の切り替えと、旧系を停止できる条件は分けて考えます。前提注文・在庫・請求の3アプリがあり、新旧アプリは同じDBを使います。既存のURLを保ち、DNSの参照先を変更する構成です。切替前に、DNSレコードのTTL、クライアントやリゾルバーのキャッシュ、新旧アプリが共通DBを読み書きできる期間を確認します。先にTTLを短くしても、既に旧TTLでキャッシュされた回答はその ...

設計・テスト・レビュー

2026/11/5

Javaのequalsをオーバーライドする注意点

AIによる要約Javaでequalsをオーバーライドするときは、単にIDEで生成すればよいわけではありません。何を同じとみなすのか、hashCodeと揃っているか、変更される値を比較に使っていないかを確認する必要があります。 equalsは、オブジェクト同士を「同じものとして扱うか」を決めるメソッドです。現場では、ID、コード値、注文番号など、業務上の同一性を表すクラスでよく話題になります。この記事のポイント equalsは同一判定のルールを表すオーバーライドするならhashCodeもセットで考える ...

設計・テスト・レビュー

2026/11/4

Javaの現在日時をテストで固定する方法｜Clock.fixedで期限判定を確認する

「昨日まで通った期限判定テストが、今日になったら落ちた」。期限を固定して期待結果だけ書き、判定の中でLocalDate.now()を呼んでいると起こる失敗です。テストのたびに予定日を書き換える運用では、期限当日と翌日の境界を保証できません。ここで取る方針は、現在日時を業務ロジックの入力として扱い、Clockを渡すことです。題材は「締切日当日まで申請でき、翌日からできない」という架空の申請機能。画面表示やDB保存ではなく、期限判定を毎日同じ条件で確かめます。実行サンプル締切日の当日・翌日と、同じ瞬間を ...

設計・テスト・レビュー

2026/11/5

Javaのログレベルはどう使い分ける？INFO・WARN・ERRORの現場ルール

AIによる要約ログレベルはメッセージの重要そうな雰囲気ではなく、運用時にどう扱うかで決めます。INFOは正常な業務・処理の主要イベント、WARNは処理を継続できるが確認が必要な状態、ERRORは要求やジョブが失敗し対応が必要な状態です。DEBUG・TRACEは調査用の詳細に使います。例外は最終的に扱う境界で一度だけ記録し、logger.error("...", e)のようにThrowableを渡します。パスワードや個人情報はどのレベルにも出しません。 Javaの現場ではSLF4JとLogbackなどを使い ...

Spring BootのDTO変換はどこでやるべきか

Spring BootのServiceに業務ロジックを書く理由