はじめに
こんにちは、Watanabe Jin(@Sicut_study)です。
2026年8月末、クリーンアーキテクチャでコードが汚くなったというYouTube動画が投稿されました。
公開から間もなく2.3万回再生され、コメント欄には議論が集まりました。
Xでもそこから火が付き、連日議論されていました。
この議論、クリーンアーキテクチャに限らず、ときどきSNSで起きていませんか？
お互いに正しそうなことを言っている。
なのに、わかりあえていない。
そしてSNSの議論を見るたびに思うのです。
「本当は何が正しいのか」
「なぜこのような議論が、何度も同じ型で起きるのか」
「どこがズレているのか、自分でも言語化できない」
一部の人は、クリーンアーキテクチャが良くないという投稿を見ても「使い方の問題」だとすぐに分かります。
一方で、「クリーンアーキテクチャ自体が悪い」と一般化する人もいます。
見えている情報の質が違うのに、同じ土俵で殴り合っている。
これが、議論が噛み合わない正体です。
今回は、この炎上が繰り返される正体が言葉の劣化と、具体と抽象の解像度のズレにあるという話をしていきます。
その仕組みが見えたとき、何が消えて、何が残るのか。
「クリーンアーキテクチャ」という言葉の裏に、何を学べばいいのかが、はっきりしてきます。
「なぜ言葉は、伝わっていく過程でズレていくのか？」
「なぜ議論が噛み合わないのか？」
「じゃあ、クリーンアーキテクチャとは本当は何なのか？」
クリーンアーキテクチャの炎上から、真実が見えてきます。
また最後には、クリーンアーキテクチャとは何かも正しく解説します。
動画でも解説しています
この記事から得られること
- 議論がなぜ噛み合わないのかを自分の言葉で説明できるようになる
- 流行りの技術が叩かれるときにズレていることに気づけるようになる
- クリーンアーキテクチャの中身が、図ではなく原則として分かるようになる
この記事では大きく3部構成になっております。
第一部 言葉と図は、伝わっていく過程で変わる
名前は知っている。図も見たことがある。
なのに、中身を人に説明しようとすると詰まる。
概念ほど、名前と図だけが残って中身が変わっていく仕組みが分かります。
第二部 正しそうな人同士が、わかりあえない
議論が噛み合わないのはなんとなくわかる
なのにどこがズレているのかは指せない。
噛み合わないのは見えているものの解像度が違うからです。
第三部 クリーンアーキテクチャとは何か
単語は聞いたことがある。
なのに「クリーンアーキテクチャとは」を言えない。
図を暗記するのではなく、仕事で活かせる原則が自分の言葉で説明できるようになります。
読み終わったあと、同じ議論が流れてきても、モヤモヤしたまま終わることがなくなります。「どっちが正しいか」ではなく、「どこで見えているものが違うか」が見えてくるので判断が今後正しくできるはずです。
この記事の対象者
- クリーンアーキテクチャに興味がある人
- 設計を学びたい人
- 技術の議論を見てモヤモヤしたことがある人
- 議論が噛み合わない理由を、言語化したい人
言葉と図は、伝わっていく過程で意味が抜け落ちる
クリーンアーキテクチャが燃える第一の理由は、技術が悪いことではありません。言葉と図の意味が、広まる過程で抜け落ちていくことです。
特に、抽象度の高い理念的な概念は、この変化が速く起きます。
体系ごと伝えるコストが高いからです。
文法、前提、適用条件、例外などを全部伝えるのはかなり難しいものです。
広まる過程で生き残るのは、一番覚えやすい名前や図、イメージなどの表層部分です。
中身は、伝言ゲームのように抜け落ちていきます。
単語の意味は、時間とともに拡張し、縮小し、移動していきます。
これは言葉が使われる以上、普遍的に起きます。
「バグ」は、もともと虫のことでした。
初期のコンピュータは真空管で、本当に虫が挟まって故障することがありました。
そこから、プログラムの欠陥全般を指す言葉へ転じています。
虫という具体が、欠陥という抽象へ拡がった。
意味は、使われる場所が変わるたびに、形を変えます。
同じように、伝言ゲームで言葉の意味が変わってしまった例はいくつもあります。
| 言葉 | もともとの意味 | いまの使われ方 |
|---|---|---|
| アジャイル | 変化に適応し続けるマインドセット | 朝会やスプリントをこなすこと自体が目的 |
| ユビキタス言語 | 振る舞いの文法まで含んだ言語 | 名詞を並べただけの用語集 |
| アダルトチルドレン | 生きづらさを感じる人全般 | 子供っぽい行動をする大人 |
| 煮詰まる | 結論が出せる状態に近づく | 行き詰まる（真逆） |
クリーンアーキテクチャを入れたらコードが汚くなる
この議論が生まれた背景はこの言葉の意味変化にあります。
クリーンという言葉が、きれいなコード、という印象を与えます。そして実際に取り組んでみると、伝言ゲームゆえに手元のコードが煩雑になり期待と結果が真逆になり話題にするのです。
抽象度の高い理念ほど、広まる過程で表層だけが残り、中身が抜け落ちるのです。
クリーンアーキテクチャの真実
クリーンアーキテクチャの誕生史は、この劣化メカニズムを説明しやすいです。
クリーンアーキテクチャは、ゼロからの発明ではありません。
Robert C. Martin（Uncle Bob）は、2012年8月13日のブログ記事「The Clean Architecture」で、本人がそう書いています。
それ以前から独立に存在していた、複数の類似アーキテクチャがあります。
Hexagonal Architecture（Alistair Cockburn, 2005）
Onion Architecture（Jeffrey Palermo, 2008）
Screaming Architecture（Uncle Bob自身の前年のブログ）
DCI（James Coplien, Trygve Reenskaug）
BCE（Ivar Jacobson）
細部は違いますが、おおまかな目的は同じ関心を分離するということです。
- フレームワーク、データベース、UIから独立させる
- ビジネスルールを、単体でテストできるようにする
複数の人が、独立に同じ問題へ行き着いており、ボブおじさんがそれらを1つの図に統合しただけです。
そして本人は、最初から釘を刺しています。
No, the circles are schematic. You may find that you need more than just these four. (4層である必要はない。円はあくまで概略図であり、必ず4つでなければならないというルールはない)
ただし書籍「The Clean Architecture」で伝えたかったことは、円の数でも、フォルダの分け方でもありません。依存性逆転しましょうということだけなのです。
実際に本を読んだ人は、「コードが書いてないじゃん」と思ったかもしれません。
その違和感は、正しいのです。
原則の話であって、実装の具体の話ではないからです。
同心円の図も、ただの例として置かれているだけです。
2012年のブログ記事を開いても、同じです。
あるのは文章と、1枚の同心円の図だけです。
どの言語で、どうフォルダを分けるかは、最初から範囲外でした。
伝わっていく過程で、何が残ったのか。
「あの同心円の図にある通りにレイヤーを作ることがクリーンアーキテクチャである」
「フォルダを Entities、Use Cases、Interface Adapters、Frameworks の4つに分ける」
「すべてのクラスにインターフェースを挟む」
「これはドメイン層じゃない。そこはリポジトリ経由で」
「フレームワークに依存しないことが、きれいな設計である」
このようなズレが発生するのはあなたが悪いというわけではありません。
一目で覚えられる図と、書籍を深く読まないとわからない本質では、伝わる速度が全く違うからなのです。
図が先に世界へ出て、原則は置いていかれる
ユビキタス言語が用語集になるのと同じで、気づけばクリーンアーキテクチャも一番運びやすい表層が本体にすり替わっていたのです。
また「クリーン」という言葉自体もそもそも、「きれい」という意味ではありません。
日本でいう「シン・〇〇」と同じだと思ってください。
きれいなコードを書く技法の名前ではなく、著者のシリーズ名なのです。
本の中で同心円に関係するのは、ごく一部の章で、大半は、SOLID原則の話です。
「クリーンアーキテクチャ」という独立したソフトウェアアーキテクチャがあるのではありません。
テスタビリティを最大化するためにデータ層を依存性逆転しようというのがクリーンアーキテクチャの本で述べられている大部分であり、ビジネス層の下にあるデータ層を上からインジェクションしたら層の上下の概念が曖昧になってしまい上下がないなら丸くしようとしているだけなのです。
つまり、仕方なく同心円で描いて、依存を切りましょうと言いたかっただけなのです。
クリーンアーキテクチャというアーキテクチャは、存在しません。
具体派と抽象派で見ている世界が違う
光の形が違うから、見ている世界が違います。
ここからが、炎上が起きる第二の理由です。
具体と抽象の関係は、円錐で表現できます。
底面は具体です。
レーザーポインターのように、やり方の一点に集中します。
やること自体が、目的になっている状態です。やり方は詳しいです。
頂点は抽象です。懐中電灯のように、広く照らすので原則が見えています。
実現できれば、手段は特に決めていません。
具体派のレーザーは、やり方に当たっています。
4層に分ける。インターフェースを挟む。フォルダを切る。
やること自体が目的になり、その外側の原則が見えていなくなります。
抽象派は、全体を照らしています。
依存性逆転、テスタビリティ、フレームワークは詳細である、という原則。
ライトで広く照らしているから、原則として理解している状態です。
抽象派は具体派を見て、こう思います。
「何でそんなに視野が狭いのか？」
具体派は抽象派を見て、こう思います。
「実際にやったけど、無理だった」
レーザー側は、具体的な手段をやってうまくいかなかった経験から、原則は、現場では使えないものに見えます。
ライト側から見ると、レーザーの一点は狭いので、やり方に集中していることを、「分かっていない」と感じてしまいます。
お互いに、自分の主張は正しいと思っている状態が議論を生み出すのです。
具体派が間違っているのではありません。レーザーの外側の原則が、見えていないのです。
(これは次の章のマジックミラーの法則で解説します)
失敗を一般化してしまう
人は自分の経験したことを世界の全てと勘違いしてしまう
テストで一度落ちた。
だから自分は勉強ができない人間だ。
ある店で料理がまずかった。
だからそのチェーンは全部まずい。
一度や二度、目の前で起きたことを、全体の法則にしてしまう。
論理学では、これを「性急な一般化」と呼びます。
これは、特別な人の癖ではありません。
少ない材料で速く判断しようとするときに、誰でもやります。
今回の炎上も、同じです。
具体派は、現場の根拠でこう言います。
「インターフェースを挟んだが、一度も差し替えなかった」
「業務ロジックがデータベースより長生きすることは、ほぼない」
「やったけど、無理だった」
自分の現場で起きたことは、本物です。
ただし、本物であることと、世界の結論であることは、別です。
抽象派から見ると、景色が違います。
「失敗しているのは原則ではなく、やり方が違う」
「本で述べられている原則を、知らない」
現場で失敗した人は、その失敗を「原則が使えない」へ伸ばします。
原則を理解している側から見ると、うまくいっていないのは原則ではありません。
意味が落ちてしまった言葉だけを実践しているからです。
つまり、原則が現場で使えないのではありません。
すれ違っているのです。
マジックミラーの法則という引力がここには働きます。
抽象側からは、具体で何が起きているかが見えます。
具体側からは、その上の原則が、そもそも見えません。
マジックミラーは、こちらから向こうは見えても、向こうからこちらは見えない。だから、具体派が抽象の話を理解することはないのです。
お互いがわかりあうことは最初からほぼ不可能なのです。
依存性逆転とは何か？
あの同心円の図は忘れてください。
この本が一貫して伝えたいのは、依存性逆転です。
あなたの目の前には、Switchにゲームカセット（マリオブラザーズ）が「ハンダ付け」されている状態のゲーム機があります。
もちろんマリオを遊ぶことはできます。
しかし、新作ソフト（ゼルダの伝説）が販売されたら、本体ごと買い直す必要が出てきます。
故障したときにも、新しいゲーム本体を買うことになります。
ここでいう「依存」は、相手を知らないと自分が成立しない、という向きです。
ハンダ付けでは、ゲーム機はマリオから切り離せません。
ゲーム機 → ソフト
一方向です。
現実のSwitchは、違います。
本体にあるのはカセットの差込口です。
Switch本体は、マリオブラザーズだろうがゼルダの伝説だろうが、カセットの形状が同じであれば差し込んで遊べます。
カセット側も、本体の複雑な内部構造を知る必要はありません。
「カセットの差込口の規格」に合わせて作られているだけです。
この規格のことを、インターフェース（仕様書）と呼びます。
ゲーム機は、特定のソフトではなく、仕様書を知っています。
ゲーム機 → 仕様書
ソフトも、本体の内部ではなく、仕様書に合わせています。
仕様書 ← ソフト
合わせると、依存の矢印は仕様書に向かって集まります。
ゲーム機 → 仕様書 ← ソフト
ハンダ付けしている場合、本体がソフトに依存していました。
差込口があれば、ゲームソフトはその差込口に合わせるように作ればよいです。
ゲーム本体は、差込口を用意すれば問題ありません。
ソフトの側が、本体の決めた差込口に従う。これが依存性逆転です。
ソフトウェアでも、同じです。
本体がやりたいこと、カセットがデータベースです。
ハンダ付けだと、別のデータベースに変えたくなったとき、すべて変更が必要になります。
ゼルダを遊びたいのに、本体ごと買い直す必要があるのです。
コードでは、やりたいことを Business、差込口を Slot と書きます。
class Business {
run() {
const mysql = new MySQL()
return mysql.fetch()
}
}
やりたいことが、MySQLという特定の道具の中身を知っています。
Business → MySQL
差込口を作ると、こうなります。
interface Slot {
fetch(): string
}
class Business {
run(cartridge: Slot) {
return cartridge.fetch()
}
}
class MySQLCartridge implements Slot {
fetch() {
return new MySQL().fetch()
}
}
implements Slot は、このカセットが差込口の規格を満たしていることを、型で表しています。
やりたいことは、データベースの中身を知りません。
MySQLの側が、差込口の規格に合わせて作られています。
別のデータベースに変えるなら、カセットを差し替えるだけです。
Business → Slot ← MySQLCartridge
さっきのSwitchと同じ向きです。
テストのときは、本物のMySQLではなく、偽物のカセットを差し込めます。
クリーンアーキテクチャの本が書いていることのおおよそは、これです。
同心円と同じように実装しましょう、とは書いてありません。
おわりに
今回は、なぜクリーンアーキテクチャが炎上するのかについて話してきました。
原因は技術そのものではありません。
言葉と図の意味が本来の定義から離れて独り歩きすることにあります。
人は自分が経験した範囲を世界の全てだと思い込み、失敗の原因を「やり方」ではなく「概念そのもの」に帰属させてしまうことが重なって起こっています。
ここまで読んでいただけた方はいいねとストックよろしくお願いします。
また明日の記事でお会いしましょう！
JISOUのメンバー募集中！
プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページからお気軽にカウンセリングをお申し込みください！
▼▼▼
たくさん投稿しています！