DTOの使い分けってどうするの？新人エンジニアのための「全部入りDTO」運用ガイド

2025年6月3日 2025年6月3日山崎講師

山崎講師

こんにちは。ゆうせいです。

今回は、新人エンジニアの方からよく聞かれる疑問にお答えします。

「すべてのフィールドを持ったDTOを作って、あとは表示側で取捨選択するってアリですか？」

実はこれ、現場でもかなりよくある運用方法なんです。ただ、メリットもあれば注意点もあります。

それでは一緒に、じっくり見ていきましょう！

DTOって何だっけ？

まずは前提の確認から始めましょう。

DTO（Data Transfer Object）とは、名前の通り「データを運ぶための入れ物」です。
たとえばWebアプリケーションでは、DBやサービス層から取得したデータを画面表示やAPIレスポンス用に整形するために使います。

例えるなら、DTOは「お弁当箱」です。
ご飯（顧客名）も、唐揚げ（車名）も、ブロッコリー（購入日）も、詰めて渡す感じですね。

すべてのフィールドを持ったDTOとは？

こんな形のDTOをイメージしてください

public class CarSaleFullDto {
    private int customerId;
    private String customerName;
    private String email;
    private String phone;

    private int carId;
    private String carName;
    private double price;
    private String color;

    private int saleId;
    private Date saleDate;
    private String paymentMethod;
    private boolean delivered;
}

これは「顧客・車・販売情報」すべてを一つに詰め込んだDTOです。
まさに全部入りですね。

表示側で必要な項目だけ使うスタイル

使い方としてはこんな感じです：

System.out.println("顧客名: " + dto.getCustomerName());
System.out.println("車名: " + dto.getCarName());
System.out.println("購入日: " + dto.getSaleDate());
// email や 支払い方法は表示しない

使う側が選ぶという運用ですね。

この方法のメリットとデメリット

メリット（いいところ）

メリット	説明
DTOが増えすぎない	画面やAPIごとにDTOを作らなくて済むので、クラス数が抑えられる
ロジック共通化がしやすい	Excel出力やログ出力など、共通処理に使いやすい
開発が早い	ひとまず全項目が揃っているので、個別にDTOを作る手間が省ける

たとえば、「とりあえず全部まとめて返しておいて、必要なものだけ使おう」というスタートアップ開発では、とても重宝されます。

デメリット（気をつけたいところ）

デメリット	説明
DTOが肥大化する	本来関係ない項目まで含まれていて読みづらい
意図がわからない	画面やAPIに「なんでこの項目あるの？」という疑問が出やすい
セキュリティリスク	表示してはいけない項目（例：メールアドレスなど）も含まれてしまう可能性
関心の分離（SoC）が崩れる	特定の処理のためだけの情報が混ざることで、役割が曖昧になる

これは「何でも入ってる便利なバッグ」みたいなもので、使い方次第でカオスになります。

解決策：使い分けよう！フルDTOと用途別DTO

では、どうすればバランスよく運用できるでしょうか？

内部処理用と表示用を分けて使うのがベストです！

推奨パターン

用途	DTOの種類	備考
DBアクセス・共通処理	フルDTO（全部入り）	CSV出力、ログ用など内部用途に最適
画面表示・APIレスポンス	軽量DTO（必要項目だけ）	関心の分離を守り、安全性も向上

マッピングの自動化でラクしよう！

「DTO分けるの面倒じゃないの？」と思うかもしれません。

そんなときは、マッピングライブラリを使いましょう！

代表例：MapStruct（Spring Bootで人気）

@Mapping(target = "carName", source = "carName")
CarSaleListItemDto toListItemDto(CarSaleFullDto fullDto);

フルDTOから必要な項目だけ詰め替えるのを、自動でやってくれます。
IDE補完も効くので、ミスも防げて安心です。

まとめ：DTOの使い分けはプロの第一歩！

「全部入りDTOを作って、表示側で取捨選択する」方法は、十分アリです。
ただし、本番運用にはリスクもあるので、次のように使い分けるのがおすすめです。

フルDTOは内部処理・共通処理で使う
表示やAPIレスポンスには用途別DTOを使う
MapStructなどのマッピングツールで手間を減らす

今後の学習の指針

DTO設計は、次のステップでより深く学べます。

関心の分離（SoC）の原則について学ぶ
MapStructやModelMapperの使い方を習得する
セキュリティ設計とDTOの関係を意識する
REST APIの設計原則に沿ってDTOを分けてみる

ぜひ、DTOの設計力を武器に「読みやすく、安全で拡張しやすいコード」を目指していきましょう！

何かあれば、また気軽に聞いてくださいね。

セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク

投稿者プロフィール

山崎講師代表取締役

セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。