【IT用語】ビジネスロジックとは？意味や具体例をわかりやすく解説！

システム開発やプログラミングの話で、「ビジネスロジック」という言葉を見かけることがあります。

「ビジネスロジックを分けて書く」「ここにはビジネスロジックを書かない」と言われても、具体的にどの処理を指しているのか、わかりにくいのではないでしょうか。

この記事では、この「ビジネスロジック」について、以下の内容を具体例とともにわかりやすく説明します。

• ビジネスロジックの意味
• プレゼンテーション層・ビジネスロジック層・データアクセス層の違い
• ビジネスロジックが指す処理の範囲
• ビジネスロジックにあたる処理の見分け方
• ビジネスロジックを分けて書く理由
• レイヤードアーキテクチャによる層の分け方との関係

ビジネスロジックとは？

ビジネスロジックとは、業務やサービスのルールに基づいて、計算・判断などを行う処理のことです。

簡単にいうと、「そのシステムで何を、どのようなルールで処理するか」を実現する部分です。広い意味では、ルールを使って目的を達成するための一連の処理の流れも含めます。

例えば、次のような処理があたります。

システムの例	ビジネスロジックの例
ネットショップ	購入金額から送料を計算する、在庫数から注文できるか判断する
予約システム	希望する時間帯に予約できるか判断する
勤怠管理システム	出勤・退勤時刻や休憩時間から勤務時間を計算する
ゲーム	プレイヤーの行動やゲームのルールから勝敗を判定する

プレゼンテーション層・ビジネスロジック層・データアクセス層の違い

プログラムの処理を役割ごとに分けてまとめたものを「層（レイヤー）」と呼びます。

ビジネスロジックの範囲をつかむには、プログラムを次の3つの層（レイヤー）に分けて考えるとわかりやすくなります。

層	主な役割	ネットショップでの例
プレゼンテーション層	利用者や外部のプログラムとのやり取りを担当する	注文内容を受け取る、計算結果を画面に表示する
ビジネスロジック層	業務やサービスのルールを適用し、必要な処理を進める	注文できるか判断する、送料を計算する
データアクセス層	データの読み書きを担当する	商品情報を取得する、注文内容を保存する

入力を受け取ったり結果を表示したりする部分が「プレゼンテーション層」、データを読み書きする部分が「データアクセス層」です。そのどちらにもあたらず、サービスのルールに従って計算・判断したり、処理を進めたりする部分が「ビジネスロジック層」です。

ではこれから、各層について詳しく説明します。

プレゼンテーション層：入力を受け取り、結果を伝える

プレゼンテーション層とは、利用者や外部のプログラムとのやり取りを担当する層です。

Web画面であれば、入力された注文内容を受け取ったり、処理結果を画面に表示したりします。

例えば、次のような処理です。

• 注文画面に入力された商品番号や数量を受け取る
• ビジネスロジック層に注文処理を依頼する
• 計算された送料を「500円」と表示する
• 注文できなかった理由を、エラーメッセージとして表示する

「500」という計算結果に「円」を付けることや、文字の色・配置を変えることは、見せ方に関する処理なので、プレゼンテーション層で行います。

また、プレゼンテーション層は、見た目のある画面だけを指すわけではありません。別のプログラムからの要求を受け付け、処理結果をデータとして返す窓口も、この役割に含まれます。

ビジネスロジック層：ルールに従って計算・判断する

ビジネスロジック層とは、業務やサービスのルールに従って、計算・判断や処理の進行を担当する層です。

例えば、「商品の合計金額が5,000円以上なら送料無料」というルールに従い、今回の注文の送料を計算します。

ほかにも、次のような処理があります。

• 在庫数と注文数を比べて、注文を受け付けられるか判断する
• クーポンの利用条件を確認し、割引額を計算する
• 注文の状態を確認し、キャンセルできるか判断する

この層で中心になるのは、「どのように表示するか」や「どのデータベースに保存するか」よりも、「そのサービスでは、どの条件で、どの結果になるべきか」という決まりです。

データアクセス層：データを読み書きする

データアクセス層とは、データベースやファイルなどに対する、データの取得・保存・更新・削除を担当する層です。

ネットショップであれば、次のような処理があります。

• 商品番号を使って、データベースから商品の価格や在庫数を取得する
• 確定した注文内容をデータベースに保存する
• 変更後の在庫数をデータベースに保存する

ここでは、データをどこから取得し、どのような方法で保存するかを扱います。

例えば、データベースから「在庫数は3個」という情報を取得する処理は、データアクセス層で実装します。一方、取得した在庫数と注文数を比べて、「在庫が3個しかないのに5個の注文があるため、注文を受け付けられない」と判断する処理は、ビジネスロジック層で実装します。

このように、データを取得する部分はデータアクセス、取得した情報を使って注文の可否を判断する部分はビジネスロジックと整理できます。

ネットショップの注文処理で全体の流れを見てみよう

プレゼンテーション層・ビジネスロジック層・データアクセス層の違いを、実際の注文の流れに当てはめてみましょう。

ここでは、架空のネットショップに、次のルールがあるとします。

• 注文数が在庫数を超える場合は、注文できない
• 商品の合計金額が5,000円以上なら、送料は無料
• 商品の合計金額が5,000円未満なら、送料は500円

ここでは一例として、利用者が「1個1,500円の商品を2個」注文しようとしています。在庫は3個あるとします。

処理の流れを役割ごとに整理すると、次のようになります。

順番	行う処理	担当する層
1	注文された商品番号と数量を受け取る	プレゼンテーション層
2	商品の価格と在庫数をデータベースから取得する	データアクセス層
3	在庫3個に対して注文2個なので、注文可能と判断する	ビジネスロジック層
4	商品の合計金額を1,500円×2個＝3,000円と計算する	ビジネスロジック層
5	合計金額が5,000円未満なので、送料を500円と決める	ビジネスロジック層
6	商品代金と送料を足し、支払金額を3,500円と計算する	ビジネスロジック層
7	注文内容をデータベースに保存する	データアクセス層
8	注文完了と支払金額を画面に表示する	プレゼンテーション層

この表は、実行される処理を順番に並べたものです。実際には、ビジネスロジック層が必要なタイミングでデータアクセス層の取得・保存処理を呼び出し、全体を進める構成などが考えられます。

注目したいのは、「情報を受け取る」「ルールに従って判断する」「情報を保存する」という役割の違いです。

ビジネスロジックが指す処理の範囲

ビジネスロジックという言葉は、資料や開発チームによって、指す範囲が異なることがあります。

送料計算や注文可否の判定など「サービスのルールそのものを実現する処理」を指す場合もあれば、「それぞれの処理を呼び出して、注文全体を進める処理の流れ」まで含める場合もあります。

この違いを理解するために、ネットショップの注文処理を「サービスのルールそのものを実現する処理」と「それぞれの処理を呼び出して、注文全体を進める処理」に分けて考えてみましょう。

サービスのルールそのものを実現する処理

こちらは、サービスの決まりに従って、金額や受付可否などを決める処理です。

例えば、「商品の合計金額が5,000円以上なら送料無料、5,000円未満なら送料500円」というルールがあるとします。

送料を計算する処理は、商品の合計金額を受け取り、このルールに従って送料を決めます。

• 商品の合計金額が3,000円なら、送料は500円
• 商品の合計金額が5,000円なら、送料は0円

同じように、「注文数が在庫数を超えていないか」「発送済みの注文ではないか」を確認し、注文やキャンセルができるか判断する処理も、この役割にあたります。

こうした、業務やサービスのルールを実現する処理を「ドメインロジック」と呼ぶことがあります。

それぞれの処理を呼び出して、注文全体を進める処理

注文を完了するには、送料を計算するだけでは足りません。商品情報を取得し、注文できるか確認し、注文内容を保存する必要もあります。

そこで、必要な処理を順番に呼び出し、注文全体を進める処理を用意します。

例えば、次のように進めます。

1. 「商品の価格や在庫数を取得する処理」を呼び出す
2. 「注文できるか判断する処理」を呼び出す
3. 注文できない場合は、そこで中止する
4. 注文できる場合は、「送料や支払金額を計算する処理」を呼び出す
5. 「注文内容を保存する処理」を呼び出す

この進行役が、送料の計算式やキャンセル条件のすべてを直接持つ必要はありません。それぞれを担当する処理へ仕事を依頼し、結果に応じて次へ進めます。

こうした処理は、「アプリケーションロジック」や「ユースケースを実現する処理」と呼ばれます。

広い意味のビジネスロジックには、この処理の流れも含まれます。一方、資料によっては、ルールそのものを実現する部分だけをビジネスロジックと呼ぶ場合もあります。

「ビジネスロジックはここに書く」といった説明を読むときは、どちらの意味で使われているかを確認すると、混乱しにくくなります。

ビジネスロジックにあたる処理の見分け方

ビジネスロジックかどうかを判断するときは、「その処理は、何をするために必要なのか」を考えてみましょう。

例えば、同じ金額を扱う処理でも、「送料をいくらにするか決めること」と「送料を画面に表示すること」では、役割が異なります。

ここでは、判断に迷いやすい処理を具体例で見ていきます。

画面が変わっても必要な計算・判断かを考える

ネットショップに、次の送料ルールがあるとします。

「商品の合計金額が5,000円以上なら、送料を無料にする」

このルールは、Webサイトから注文しても、スマートフォンアプリから注文しても同じです。画面の見た目や操作方法が変わっても、送料を決める処理は必要になります。

このような、画面に依存しない、サービスのルールに基づく計算・判断は、ビジネスロジックにあたります。

一方、次のような処理は、結果の見せ方を決めるため、プレゼンテーションの役割です。

• 送料無料の場合に、「送料無料」という文字を赤色にする
• 注文できない場合に、画面の上部へエラーメッセージを表示する

「送料無料かどうかを決める処理」と「送料無料という結果をどう見せるか」は、分けて考えましょう。

データを取得することと、そのデータで判断することを分ける

会議室の予約システムで、希望する時間帯に予約できるか確認する場面を考えてみましょう。

この処理は、次のように分けられます。

処理	役割
希望する時間帯の予約情報をデータベースから取得する	データアクセス
同じ会議室に重複する予約があるため、予約できないと判断する	ビジネスロジック
予約できる場合に、新しい予約をデータベースへ保存する	データアクセス

「情報を取得・保存すること」と「その情報を使って予約の可否を判断すること」は、異なる役割です。

「予約情報を扱う処理だから、すべてデータアクセス」と考えず、読み書きする部分と、ルールに従って判断する部分を分けて見てみましょう。

入力チェックは「形式の確認」か「ルールの確認」かを考える

入力内容を確認する処理を「バリデーション」と呼びます。バリデーションにも、異なる役割があります。

例えば、注文数の入力欄に「abc」と入力されていたら、数量として扱えません。このように、入力された値を数値として扱えるか確認するのは、入力形式のチェックです。一般に、入力を受け付ける側で行います。

一方、数値として受け取れたからといって、その注文を受け付けてよいとは限りません。

例えば、次のようなルールを確認する必要があります。

• 注文数は1個以上であること
• 1人が購入できる数は5個までであること
• 注文数が在庫数を超えていないこと

これらは、そのサービスで注文を受け付けてよいかを判断するためのチェックなので、ビジネスロジックにあたります。

例えば、「1人5個まで」という制限は、Web画面から注文しても、別のプログラムから注文しても守る必要があります。

画面側でチェックすれば、利用者にその場で間違いを伝えられます。ただし、画面を経由せずに注文が届くこともあるため、注文を受け付ける処理でも、必要なルールを確認することが大切です。

同じ処理でも、そのシステムの目的によって役割が変わる

日時を「2026年10月23日」のような形式に変換する処理を考えてみましょう。

ネットショップの注文履歴で、日時を読みやすく表示するために変換するなら、プレゼンテーションの役割です。

一方、さまざまな日時の形式を変換するツールであれば、その変換処理自体が、利用者に提供する中心的な機能になります。この場合は、ビジネスロジックとして扱えます。

つまり、「日時の変換だからプレゼンテーション」のように、処理の名前だけで決まるわけではありません。

そのシステムの中で、見せ方を整えるための処理なのか、サービスの機能やルールを実現するための処理なのかに注目して、役割を考えましょう。

ビジネスロジックを分けて書く理由

ビジネスロジックを入力・表示やデータの読み書きから分けるのは、同じルールを複数の場所で使いやすくし、変更や動作確認をしやすくするためです。

例えば、Webサイトとスマートフォンアプリの両方から注文できるネットショップを考えてみましょう。

それぞれに送料の計算処理を書くと、送料無料の条件を「5,000円以上」から「6,000円以上」へ変更するとき、両方を修正する必要があります。片方を修正し忘れると、同じ注文内容でも、Webサイトとアプリで送料が異なってしまいます。

そこで、共通の送料計算処理を用意し、Webサイトとスマートフォンアプリの両方から呼び出すようにします。送料のルールを共通の処理にまとめることで、同じ計算を何度も書かずに済み、条件を変更するときの修正漏れも減らせます。

また、送料計算を画面やデータベースから分けておくと、計算が正しいかどうかも確認しやすくなります。

例えば、送料計算の処理に商品の合計金額を渡し、次の結果が返るかを確認できます。

• 4,999円を渡すと、送料500円が返る
• 5,000円を渡すと、送料0円が返る

このような形なら、画面で注文を入力したり、データベースから商品情報を取得したりしなくても、送料計算だけを確認できます。

層の分け方は設計によって異なる

この記事では、ビジネスロジックを理解するために、次の3つの層に分けて説明しました。

層	主な役割
プレゼンテーション層	利用者や外部のプログラムとのやり取りを担当する
ビジネスロジック層	業務やサービスのルールを適用し、必要な処理を進める
データアクセス層	商品情報を取得する、注文内容を保存する

このように、役割ごとに層を分けてプログラムを整理する考え方を、レイヤードアーキテクチャと呼びます。ただし、層の数や名前、各層が担当する範囲は、設計によって異なります。

例えば、DDD（ドメイン駆動設計）を取り入れたレイヤードアーキテクチャでは、次の4つに分ける構成があります。DDDは、業務の概念やルールを中心にソフトウェアを設計する考え方です。

層	主な役割
コントローラー層 （プレゼンテーション層）	入力を受け取り、内部の処理へ渡して、結果を返す
ユースケース層 （アプリケーション層）	必要な処理を組み合わせて、注文や登録などを進める
ドメイン層	業務やサービスのルールを表現する
インフラストラクチャ層	データベースや外部システムなどとの技術的なやり取りを担当する

この記事の3つの層との違いで注目したいのは、ビジネスロジック層で説明した役割を、ユースケース層とドメイン層に分けている点です。

例えば、送料の条件や注文できるかの判断はドメイン層が担当します。一方、商品情報を取得し、注文可否の判定や送料計算を依頼し、注文を保存するという流れは、ユースケース層が担当します。

また、データアクセスの具体的な実装は、インフラストラクチャ層が担当します。ただし、この層は外部システムとの通信なども扱うため、データアクセス層と範囲が完全に同じではありません。

資料によっては、ユースケース層は「ビジネスロジックを持たない」と説明されることもあります。この場合は、業務ルールそのものはドメイン層に任せ、ユースケース層は処理の進行を担当するという区別として読むと理解しやすくなります。

本記事のまとめ

この記事では「ビジネスロジック」について、以下の内容を説明しました。

• ビジネスロジックとは、業務やサービスのルールに基づく計算・判断などを行う処理のことである。
• プレゼンテーション層は入出力、ビジネスロジック層はルールの適用や処理の進行、データアクセス層はデータの読み書きを担当する。
• 広い意味のビジネスロジックには、ルールそのものを実現する処理と、それらを組み合わせる処理の流れが含まれる。
• 何がビジネスロジックかを見分けるには、処理の名前や書かれた場所だけでなく、何のための処理かに注目する。
• レイヤードアーキテクチャの層の分け方は1通りではなく、業務ルールと処理の進行を別の層に分ける設計もある。

お読みいただきありがとうございました。