壊さないための設計 / Designing Not to Break

日記まとめ（公開用）｜壊さないための設計

※ 2026年1月の日記（1/3〜1/11）をもとにした思考の要約。 ※ 技術メモというより、設計に対する立場表明に近い。

作ることから、壊さないことへ

ここしばらく考えていたのは、 「どう作るか」ではなく「どう壊さないか」だった。

作ること自体は、正直そこまで難しくない。 壊すことも、実は簡単だ。

難しいのは、

• 人が雑に触っても
• 近道をしても
• 後から変更されても

致命的に壊れない状態を保つこと。

関心は完全に「攻撃」から「防御」に移っている。

設計とは統治である

どんなアーキテクチャも、壊そうと思えば壊せる。 だから重要なのは「正解の型」を選ぶことではない。

必要なのは、

• 壊してはいけない部分を決めること
• 変更してよい場所を限定すること

設計とは、美しさや賢さの表現ではなく、 現場で事故を起こさないための統治だと思っている。

アーキテクチャは思想であり、配置である

Clean / Hex / Onion / DDD は、 どれか一つが正しいわけではない。

• Clean は思想
• Onion は説明モデル
• Hex は接続点の整理法

それぞれ役割が違うだけで、 目的は共通している。

変更に強くすること。壊れ方を制御すること。

要素を細かく分割することよりも、 責務をどこに「置くか」という配置のほうが重要だと感じている。

フロントエンドは世界が二つある

フロントエンドが難しいのは、 ロジックが薄いからではない。

扱っている世界が、

• データ → 処理 → データ（バックエンド）
• データ → 処理 → 表現（フロントエンド）

と根本的に違うからだ。

そのため、 バックエンド向けの層構造をそのまま当てはめると、 どこかで無理が出る。

思想は借りるが、構造は調整する。 それが現実的な落としどころだと思っている。

アダプタは包帯である

アダプタは恒久的な層ではない。

それは差分に対する一時的な包帯であり、 時間が経てば剥がされる前提の存在だ。

理想は持っていい。 ただし、今日やるのは今日の一畝（いちうね）だけ。

構造は固定せず、 常に手入れされるものとして扱う。

AIとの付き合い方

AI は便利だが、魔法ではない。

• AI は取り外し可能な部品
• 実装は任せられる
• 設計は任せられない

設計が言語化できていないと、 AI に書かせても、人が書いても、 結果は大きく変わらない。

必要なのはツールではなく、 説明できる設計だ。

形を忘れるために、形を使う

陰陽や荘子の話を読むと、 フレームワークに対する距離感が少し変わる。

形は必要だが、 形に囚われた瞬間に自由度は落ちる。

守るために縛る。 だが、縛り続けることが目的ではない。

結び

設計とは、 人が間違える前提で、 壊れ方を制御するための知恵だと思っている。

作れる人は多い。 壊さない人は、まだ少ない。

今はそちら側に立ちたい。

Diary Summary (Public) | Designing Not to Break

English version. Original thoughts written between Jan 3–11, 2026.

From Building to Not Breaking

Lately, what I have been thinking about is not how to build, but how not to break.

Building something is not particularly difficult. Breaking something is often even easier.

What is genuinely difficult is keeping a system in a state where it does not fail catastrophically:

• when people touch it carelessly,
• when shortcuts are taken,
• when changes are made later under time pressure.

My focus has clearly shifted from attack to defense.

Design as Governance

Any architecture can be broken if someone really wants to break it. Therefore, the goal of design is not to choose the “correct” architecture.

What matters is:

• deciding what must not be broken,
• and limiting where change is allowed.

Design is not about elegance or cleverness. It is about governance that prevents accidents in real-world practice.

Architecture as Thought and Placement

Clean, Hexagonal, Onion Architecture, and DDD are not competing answers.

They play different roles:

• Clean Architecture is a set of principles,
• Onion Architecture is an explanatory model,
• Hexagonal Architecture is a way to organize connections.

They share a single goal:

to control change and to control how systems fail.

Rather than endlessly splitting components, I find it more important to decide where responsibilities are placed.

Frontend: Two Different Worlds

Frontend development is not difficult because the logic is thin. It is difficult because it deals with a different kind of world.

• Backend systems: data → processing → data
• Frontend systems: data → processing → representation

Applying backend-oriented layering directly to frontend systems often leads to friction.

Borrow the ideas, but adapt the structure. That compromise feels more realistic in practice.

Adapters Are Bandages

Adapters are not permanent layers.

They are temporary bandages applied to differences that exist for now. They are meant to be removed when the system evolves.

It is fine to have a long-term ideal. But each day, you only cultivate today’s small field.

Structures should be maintained, not frozen.

Working with AI

AI is a powerful tool, but it is not magic.

• AI is a replaceable component,
• implementation can be delegated,
• design cannot.

If a design cannot be explained clearly, it will fail regardless of whether it is written by a human or by AI.

What matters is not the tool, but a design that can be articulated.

Using Forms to Eventually Forget Them

Reading Eastern philosophy changes how I relate to frameworks.

Forms are necessary. But once we cling to them too tightly, flexibility is lost.

We impose constraints in order to protect systems. But constraint itself should never become the goal.

Closing

Design, to me, is wisdom for controlling how systems fail, under the assumption that people will make mistakes.

Many people can build systems. Far fewer can keep them from breaking.

That is the side I choose to stand on.