どうも、ボクシング好きの株式会社ナハトの中山瑛文です。
井上拓真選手 vs 那須川天心選手、今月 9/27 ですからね！ Amazon Prime で観ることができますので皆さんお見逃しなく！
というのは置いといてですね……
今回は 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』!
（Robert C. Martin 著、角征典・高木正弘 訳、KADOKAWA）を読んだアウトプットと、「この考え方、システム作りだけじゃなくてプロジェクトの設計にも使えるんじゃないか？」という考察を書いてみます。
後半は正直まだ実践していない思考実験なので、「それは違うんじゃない？」というツッコミ大歓迎です。
読もうと思ったきっかけ
2026 年に入って、コーディングはもうかなりの部分を AI に任せられるようになりました。そうなると「エンジニアとしての自分の存在価値って何だろう？」と考えるわけです。
技術とビジネスの 2 つの側面があったとき、技術だけ、言われたことだけをやるエンジニアは淘汰されていくだろうな と感じています。求められるのは、ビジネスを理解して、問題発見 と 問題解決 の両方ができるエンジニアだと思います。
AI は問題解決がめちゃくちゃ得意です。でも、個別のコンテクストを全部把握しているわけではないので、問題発見はまだ弱い。人間関係だったり、現場の人が感じている「不」やペインを理解するのは、まだ難しい。それを汲み取って仮説を立てる部分に、人間のエンジニアの価値があると思っています。
そう考えると、「どんなニーズがあって、どんな問題設定をするべきか」を自分で考えられないといけない。ビジネスサイドの理解を進めないといけない。
技術フレームワークやクラウドを学ぶのもいいけど、それはあくまで 手段 です。目的である売上・粗利につながるビジネス上の行動って何だろう？ それをシステム化する、IT で作る。この「目的ベース」で考える型が欲しくて、Clean Architecture やドメイン駆動設計（DDD）の考え方が一番近いんじゃないかと思い、本書を手に取りました。
Clean Architecture とは
一言でいうと、
ビジネスロジック（アプリの核心となる大切なルール）をデータベースや画面などの外部の技術から切り離し、変更やテストを簡単にするソフトウェアの設計方針
です。
最初に読んだときは概念的でよく分からなかったのですが、僕なりの解釈で言い直すと、
「Why（何を達成したいか＝ビジネスロジック）を中心に置いて、How（どう実現するか＝技術）は常に入れ替えられるように分離しておこう」
という話でした。
不変なものと可変なものを分ける
本書ではビジネスロジックのことを エンティティ や ユースケース と呼びます。たとえば「ユーザーに商品をレコメンドする」「レコメンドから購入につながったら成果として扱う」といった、売上に直結するルールや行動です。
一方、可変なものは、使うデータベース、使うプログラミング言語、Web フレームワーク、UI などです。これらは 目的が達成されるなら何でもいい。
ここで 1 つ注意したいのは、本書は「ビジネスルールは変わらない」と言っているわけではないことです。ビジネスルールも当然変わります（料金体系が変わる、キャンペーンが増える等）。本書が言っているのは、ビジネスルールは「DB を乗り換えたから」「フレームワークが古くなったから」という外部の技術的な理由では変わるべきではない ということです。変化の理由が違うものは、分けて置いておこう、という話ですね。
もし「採用したデータベースを変えないといけないから、ビジネスロジックやワークフローも書き換えないといけない」となったら本末転倒ですよね。技術や DB、UI はあくまで手段であって目的ではない。
本書には「データベースは詳細である」「Web は詳細である」「フレームワークは詳細である」という章が並んでいて、著者はかなり強い言葉で「それらは主役じゃない」と言い切っています。
「分ける」＝ 依存の方向をそろえる
「分ける」というのは、具体的には 依存関係の方向をそろえる ということです。
ドメイン、ビジネスロジックは、UI やデータベースのことを 知らなくていい状態 にする。逆に、UI やデータベース側はビジネスロジックのことを知っていていい。依存の矢印は常に 外側 → 内側 の一方向。本書ではこれを 依存性のルール（The Dependency Rule） と呼んでいて、この本の一番大事な一行だと思っています。
「でもビジネスロジックがデータを保存したいときは DB を呼ぶじゃないか」と思いますよね。そこで使うのが 依存性逆転（DIP） です。ビジネスロジック側が「こういう保存機能が欲しい」というインターフェースだけを定義し、DB 側がそのインターフェースを実装する。呼び出しの流れは内 → 外でも、ソースコード上の依存は外 → 内に保てる、というテクニックです。
核となるビジネスロジックを決めて依存の方向を守っておけば、どれだけ状況や技術が変わっても、外側を差し替えるだけで対応できる。これが Clean Architecture のうれしさです。
Clean Architecture のモデル（4 つの円）
本書の有名な図は、同心円が 4 つ重なったものです。内側ほど抽象的で変わりにくく、外側ほど具体的で変わりやすい。
図の出典: The Clean Architecture | The Clean Code Blog（Robert C. Martin, 2012）
参考: ソースコードで理解するクリーンアーキテクチャ | Sansan Builders Box
図の左側の矢印が 依存の方向（外側 → 内側のみ）、右下の小さい図が「コントローラー → ユースケース → プレゼンター」という処理の流れ（Flow of control）です。処理は内側を通って外側に戻ってくるのに、ソースコードの依存は内側にしか向かない、というのが前の節で書いた依存性逆転の話です。
本書の 4 つの円と、レイヤードアーキテクチャの 4 層
僕は最初、この構造を「プレゼンテーション層 / アプリケーション層 / ユースケース層 / ドメイン層 / インフラストラクチャ層」と 5 層で覚えていました。調べてみると、これは Eric Evans の DDD 本（第 4 章）で紹介されている レイヤードアーキテクチャ の 4 層、
- ユーザーインターフェース層（プレゼンテーション層）：ユーザーに情報を見せ、操作を受け取る
- アプリケーション層：業務の流れを調整する。薄く保ち、ビジネスルールは持たない
- ドメイン層：ビジネスの概念とルール。ソフトウェアの心臓部
- インフラストラクチャ層：永続化・通信など、上の層を支える技術的な仕組み
に、Clean Architecture 側の「ユースケース」が混ざった形でした。本書の 4 つの円と対応させると、こうなります。
| 本書（Clean Architecture） | DDD のレイヤードアーキテクチャ | 中身 |
|---|---|---|
| エンティティ | ドメイン層 | 企業全体のビジネスルール |
| ユースケース | アプリケーション層 | アプリ固有の業務の流れ |
| インターフェースアダプター | プレゼンテーション層（の内側） + インフラストラクチャ層（の内側） | コントローラー / プレゼンター / ゲートウェイ |
| フレームワークとドライバ | プレゼンテーション層（UI 本体） + インフラストラクチャ層（DB 本体など） | 道具そのもの |
つまり 「アプリケーション層」と「ユースケース層」は同じものの別名 で、「プレゼンテーション層」は本書だと外側 2 つの円にまたがっています。本書自身も「クリーンアーキテクチャは、これら（ヘキサゴナル・オニオン・DCI・BCE など）のアーキテクチャを 1 つにまとめる試み」と書いているので、名前が本によって違うのは想定どおりというわけです。
以下、本書の 4 つの円を内側から順に説明します。
1. エンティティ（≒ ドメイン層）
一番内側。企業全体に通用するビジネスルール を置く場所です。
「1 つのアプリケーション」に閉じない、その会社がやっている商売そのもののルールです。たとえば広告運用会社なら「成果（CV）とは何か」「クライアントへの請求はどう計算されるか」といった、どのシステムから見ても変わらない決まり。
ここは、外側で何が起きても影響を受けないことが求められます。DB が変わっても、画面が変わっても、社内ツールが入れ替わっても、この層のコードは触らない。
2. ユースケース（≒ アプリケーション層）
このアプリケーション固有の業務の流れ を書く場所です。「ユーザーがこう操作したら、エンティティをこう動かして、こういう結果を返す」というシナリオ。
エンティティが「ルール」なら、ユースケースは「ルールを使った手順」です。「レコメンド結果を表示する」「月次レポートを生成する」といった単位で、1 ユースケース = 1 つのやりたいこと、になります。
レイヤードアーキテクチャで「アプリケーション層は薄く保て、ビジネスルールを持たせるな」と言われるのも同じ話で、ルール（エンティティ）と手順（ユースケース）を混ぜない、ということです。
3. インターフェースアダプター（プレゼンター / コントローラー / ゲートウェイ）
内側の世界と外側の世界の「翻訳」をする層 です。
- コントローラー：外から来た入力（HTTP リクエスト、CLI の引数など）を、ユースケースが理解できる形に変換して渡す
- プレゼンター：ユースケースの出力を、画面や API レスポンスに都合のいい形（表示用の文字列、フォーマット済みの数値など）に変換する
- ゲートウェイ：ユースケースが要求する「保存して」「取ってきて」というインターフェースを、実際の DB や外部 API 向けに実装する
ポイントは、この層が ユースケースを守る緩衝材 になっていることです。画面のレイアウトが変わってもプレゼンターを直せばいいし、DB が変わってもゲートウェイを直せばいい。ユースケースとエンティティには波及しません。
レイヤードアーキテクチャの「プレゼンテーション層」は、このプレゼンター・コントローラーと、一番外側の UI 本体をまとめて指しています。
4. フレームワークとドライバ（≒ インフラストラクチャ層）
一番外側。Web フレームワーク、DB 本体、UI、外部サービス など、具体的な道具の置き場です。
本書のスタンスでは、ここには自分で書くコードはほとんどなく、あるのは「道具と、道具をつなぐ接着剤のコード」だけ。ここに大事なロジックが漏れ出していたら、それは設計が崩れているサインです。
おまけ：アーキテクチャは「叫ぶ」
個人的に一番好きだった章が「叫ぶアーキテクチャ（Screaming Architecture）」です。
家の設計図を見れば「これは家だ」と分かる。同じように、ソフトウェアのディレクトリ構成を見たときに叫んでいるべきなのは 「これは在庫管理システムだ」「これは広告成果計測システムだ」 というユースケースであって、「これは Rails だ」「これは Next.js だ」というフレームワーク名であってはいけない、という話です。
ここから考察：これ、プロジェクト設計にも使えないか？
ここまでが本書から学んだことです。ここからは、読みながらずっと頭にあった 「この構造、システム作りに限らずプロジェクト全般に使えるんじゃないか」 という思考を書いてみます。
繰り返しになりますが、実践はまだしていません。「こう考えると整理できそう」というレベルの提案です。
なぜそう思ったか
冒頭で書いたように、今エンジニアに求められているのは「問題発見」の側です。つまり 何を達成したいのか（Why）を、手段（How）に汚染されない形で定義する力。
これって、Clean Architecture が「エンティティとユースケースを外側から守れ」と言っているのと、構造が同じなんですよね。
プロジェクトの現場でよく起きる失敗は、
- 「とりあえず GA4 入れよう」「GTM でタグ整理しよう」「BigQuery でダッシュボード作ろう」と ツール（一番外側）から話が始まる
- 途中でツールを変えることになったら、プロジェクトの目的ごと見直しになる（依存の方向が逆）
- 経営向けの報告フォーマットが変わっただけで、現場のやることまで変わる（プレゼンターの変更がユースケースに波及）
……と、本書が「やってはいけない」と言っていることのプロジェクト版に見えます。プロジェクト計画書を開いたとき、叫んでいるのがツール名なのか、目的なのか。「叫ぶアーキテクチャ」はそのままプロジェクトにも当てはまると思いました。
4 つの円をプロジェクトに写像してみる
| 本書の円 | システムでの中身 | プロジェクトに写像すると（提案） |
|---|---|---|
| エンティティ（ドメイン層） | 企業全体のビジネスルール | プロジェクトの理想状態と、変えてはいけないルール。誰（エンティティ＝人・もの・こと）が、どんな状態になっていれば成功か。売上・粗利にどうつながるか |
| ユースケース（アプリケーション層） | アプリ固有の業務の流れ | 理想状態に至るための行動の流れ。「誰が」「何をすると」「何が変わるか」のシナリオと、その成功条件（KPI） |
| インターフェースアダプター | コントローラー / プレゼンター / ゲートウェイ | 翻訳の層。現場の声・要望をユースケースに変換する（コントローラー）。成果をステークホルダーごとの言葉に変換する（プレゼンター）。データや外部組織との接続口を決める（ゲートウェイ） |
| フレームワークとドライバ（インフラストラクチャ層） | Web / DB / 外部サービス | 道具と資源。使うツール、データ基盤、外部ベンダー、予算、人員体制 |
ドメイン層・ユースケース層に「理想状態」を書く
まずドメイン層に、プロジェクトの 理想状態 を書きます。登場するエンティティ（人・もの・こと）は誰で、理想的にはどんな行動をしていて、それがどう売上・粗利につながるのか。
たとえば「広告の成果を正しく測れるようにする」プロジェクトなら、
- エンティティ：広告運用者、クライアント、広告媒体、成果（CV）
- ルール：「成果として数えるのは、実際に売上につながった行動だけ」「クライアントへの報告数値と請求数値は一致していなければならない」
こういう、ツールが何であっても変わらない決まりがドメイン層です。
そしてユースケース層に、その理想状態に至るための行動の流れを書きます。
- 「運用者が媒体の管理画面と実売上を照合し、差分があれば原因を特定する」
- 「クライアントに月次で成果報告を出す」
ここに書かれていることが達成されればプロジェクトは成功、という ツボ をこの 2 層で定義してしまう。ここさえ押さえておけば、後ろの層はいくら入れ替えても大丈夫、という状態を作るのが狙いです。
インフラストラクチャ層に「資源」を置く
そのために必要な情報、データ基盤、ツール、外部ベンダー、予算、人員は一番外側です。
GTM を使うのか別のタグマネージャーか、BigQuery か RDB か、内製か外注か。これらは ドメイン・ユースケースが決まった後で 選ぶもので、しかも後から差し替えていい。ここから話を始めない、というのが一番大事な規律だと思います。
プレゼンター層をどう考えるか（提案）
システムでのプレゼンターは「同じ結果を、受け手に都合のいい形に変換する」役割でした。プロジェクトに写すと、同じ事実を、ステークホルダーごとに翻訳する層 になると思います。
- 経営向け：粗利・ROI・投資回収の言葉
- クライアント向け：成果報告・改善提案の言葉
- 現場向け：具体的な作業手順・チェックリストの言葉
大事なのは、報告フォーマットや会議体が変わっても、ドメインとユースケースには手を入れない こと。「役員会の資料フォーマットが変わったので現場の KPI を変える」は、プレゼンターの都合でユースケースを書き換える設計違反です。
同じ層の コントローラー にあたるのは、逆方向の翻訳です。現場から上がってくる要望・クレーム・数値を、そのまま受け取るのではなく「これはどのユースケースへの入力か」に変換する役割。ヒアリングや要件整理がここに当たります。
アプリケーション層をどう考えるか（提案）
上で整理したとおり、レイヤードアーキテクチャの「アプリケーション層」は本書の「ユースケース」と同じものなので、厳密には分ける必要はありません。ただプロジェクトの文脈であえて分けるなら、ユースケースを回すための仕組み と位置づけるのが自然かなと思っています。
- ユースケース層 = 何を達成するか（成果に直結する行動と成功条件）
- アプリケーション層 = どう回すか（定例、意思決定プロセス、優先順位づけ、進捗管理）
「どう回すか」はプロジェクトによって変えていい可変な部分ですが、ツールほど外側でもない。ユースケースにピタッと寄り添う運用ルール、というイメージです。
オフラインでも成立するはず
IT の文脈なので、アプリやシステムで考えることが多いですが、ここまでの話は 一行もコードを書かないプロジェクトにも当てはまる と思っています。
営業組織の改善、採用プロセスの見直し、社内の業務フロー整理。どれも「変えてはいけない目的」「そこに至る行動」「翻訳」「道具」の 4 層に分けられるし、「道具から話を始めない」「報告の都合で目的を変えない」という規律はそのまま効くはずです。
DDD が「ドメインエキスパートと共通の言葉を作る」ことを重視しているのも、結局は同じ話で、ドメインエキスパート（現場のプロ）はエンジニアじゃないので、この考え方は最初からオフライン寄りなんですよね。
この考え方が「間違い」だとしたら何が壊れるか
自分の提案なので、反証もしておきます。
1. 依存の方向を守らせる強制力がない
コードならコンパイラや Lint が「内側が外側を参照している」と怒ってくれます。プロジェクトにはそれがない。人は普通に「ツール都合で目的を曲げる」判断をするし、それを止めるのは構造ではなく人の規律になります。ここは正直、弱点です。
2. 「不変のドメイン」は最初から分かっているとは限らない
本書やDDD の前提は「ドメインは発見していくもの」です。プロジェクト開始時点で理想状態を完璧に定義できるなら、そもそもプロジェクトは難しくない。なので、「ドメイン層を最初に確定させる」というより、変更が来たときに「これはどの層への変更か？」を毎回問い直す 使い方のほうが現実的なのかもしれません。
3. 比喩は必ず漏れる
システムの層とプロジェクトの層は、あくまで比喩的に対応しているだけです。人間関係や政治のように、どの層にも属さないものがプロジェクトには大量にあります。「Clean Architecture で全部説明できる」と思った瞬間に破綻すると思うので、思考の整理ツールとして距離を保つのが正しい使い方かなと。
まとめ
- Clean Architecture の本質は 依存性のルール：変わりやすいもの（技術・道具）が、変わりにくいもの（ビジネスの目的とルール）に依存する。逆はダメ
- 本書の 4 つの円は、エンティティ / ユースケース / インターフェースアダプター / フレームワークとドライバ。DDD のレイヤードアーキテクチャ（プレゼンテーション / アプリケーション / ドメイン / インフラストラクチャ）とは呼び名が違うだけで、「アプリケーション層」＝「ユースケース」
- この構造はプロジェクト設計にも写せそう。ドメイン層・ユースケース層に「ここを押さえれば成功」というツボを書き、ツール・データ基盤・体制は一番外側に置く
- プレゼンター層は「ステークホルダーごとの翻訳」、コントローラーは「現場の声のユースケースへの変換」、アプリケーション層は「ユースケースを回す仕組み」と位置づける提案
- ただし強制力がない・ドメインは事後的に分かる・比喩は漏れる、という弱点はある。「変更が来たときにどの層の話か問い直す」ツールとして使うのが現実的そう
おわりに
AI がコードを書く時代に、人間のエンジニアに残る仕事は「何を作るべきか」を見つけて定義することだと思っています。Clean Architecture はコードの本ですが、読んでみると 「Why を How から守れ」 という、コードに限らない話をしている本でした。
ここに書いた考察は、まだ頭の中だけの話です。実際のプロジェクトで試してみて、うまくいったことも、いかなかったことも、また記事にしようと思います。
参考
- Robert C. Martin 著、角征典・高木正弘 訳『Clean Architecture 達人に学ぶソフトウェアの構造と設計』（KADOKAWA、2018）
- The Clean Architecture | The Clean Code Blog（同心円図の出典）
- ソースコードで理解するクリーンアーキテクチャ | Sansan Builders Box
- Eric Evans 著『エリック・エヴァンスのドメイン駆動設計』（翔泳社、2011）第 4 章「ドメインを隔離する」（レイヤードアーキテクチャ）