AI時代の設計は、コードを書くことより『共通言語を設計すること』に近い

Jul 10, 2026

1 min read

2 views

88%

問いは変わった: 何を作るかではなく、何を説明しなくて済むか

ソフトウェア設計の価値は、長いあいだ「人間が読みやすいこと」に置かれてきた。だが今、もっと本質的な問いが立ち上がっている。AIにとって分かりやすい設計とは何か。これは単なる流行への適応ではない。むしろ、ソフトウェアを組み立てる中心が「実装」から「構造の言語化」へ移ったことを意味している。

ここで見えてくるのは、ある種の逆転である。人間にとっては面倒なレイヤー分けや責務分離が、AIにとってはむしろ歓迎される。曖昧さが少ないほど、モデルは迷わない。つまり、設計とはコード量を減らすためのものではなく、判断の回数を減らすためのものになりつつある。

この変化を理解する鍵は、見た目に派手な技術選定ではない。Emotionのような実装選択も、超並列LLMコーディングを支えるハーネス設計も、実は同じ問いの上に乗っている。どうすれば人間とAIが、同じアーキテクチャを前提に会話できるのか。そこにこそ、これからのプロダクト開発の核心がある。

UIの話に見えて、実は認知の話である

EmotionのようなCSS in JSの道具立てが支持される理由は、単に「書きやすいから」ではない。スタイルをコンポーネントの近くに置くことで、画面の振る舞いと見た目の関係が局所化される。すると、あるボタンの見た目を変えたいときに、広大なCSSファイルの中を探し回らなくて済む。変化の影響範囲が小さくなるのだ。

これは表面的にはフロントエンドの話に見えるが、実際には認知負荷の削減である。人間は、情報が散らばると理解を失う。逆に、意味のまとまりが一箇所にあると、頭の中でシミュレーションしやすくなる。Emotionが評価されるのは、見た目の管理を楽にするからではなく、変更の意味を近くに閉じ込めるからだ。

この性質は、AI時代になるとさらに重要になる。なぜなら、AIは巨大なコードベースを一気に読むことはできても、曖昧な慣習や暗黙の前提を人間以上にうまく推測できるとは限らないからだ。スタイル、状態、振る舞い、責務が明確にまとまっていれば、モデルは「ここを変えればいい」と局所的に判断できる。つまり、局所性は人間のための親切であると同時に、AIのための最適化でもある。

良い設計とは、賢い人間が頑張って理解するためのものではない。理解しなくても壊しにくい状態を作ることである。

ここで重要なのは、コンポーネント設計とUI実装は分離できないということだ。見た目をどう組むかは、後から足す装飾ではない。むしろ、アプリ全体の意味構造をどの粒度で切るかという、アーキテクチャの最前線なのだ。

LLMが得意なのは実装ではなく、分解された実装である

超並列でLLMにコーディングをさせるとき、最初に効くのは「もっと賢く書かせる」ことではない。迷わせない構造を先に作ることである。人間なら適当に補完できる境界も、AIにはただの曖昧さになる。だからこそ、レイヤーの役割、依存の向き、責務の境界を明確にすることが重要になる。

ここで、DDDやクリーンアーキテクチャの価値が再発見される。これらは単に古典的な設計理論ではない。今やそれらは、人間とAIが共有できるプロジェクトの文法として機能する。たとえば「ドメイン層にはUIの都合を混ぜない」「ユースケースは外部I/Oに依存しない」といった規約は、チーム内の思想ではなく、AIへの指示としても強い。

想像してみてほしい。もし大規模な改修を10個の並列タスクに分けるなら、境界が曖昧なコードベースでは、各タスクが互いに食い合う。誰かが型を変えれば、別の誰かの前提が壊れる。だが、最初からレイヤーが明確なら、各タスクは独立した部屋のように動ける。設計は作業の並列性を決めるインフラなのだ。

この視点は、LLMの性能を「生成能力」ではなく「分業能力」で測る考え方へ導く。単発で賢いコードを書くことより、複数のエージェントが衝突せずに進める構造の方が、実際の生産性に直結するからだ。AI時代のボトルネックは、書けるかどうかではない。分けられるかどうかである。

設計は美学からインターフェースへ変わる

ここで、二つの世界が一つに重なる。Emotionが示すのは、関心事を局所に寄せる設計の力。ハーネスエンジニアリングが示すのは、仕事を並列化できるように責務を切る力。両者に共通するのは、コードの内部美学ではなく、相互作用の設計が重要だという点である。

昔のアーキテクチャ議論は、ともすると「どれだけきれいか」に寄りがちだった。だが今問うべきなのは、美しさそのものではなく、どれだけ誤解されにくいかである。たとえば、状態管理が散在していると、人間は「この値はどこで変わるのか」を追跡するだけで疲れる。AIならなおさら、変更候補が増えるほど推論の分岐が増え、ミスの確率が上がる。

このとき有効なのは、機能を「画面」「ドメイン」「インフラ」のような層に分けるだけでは足りない。より重要なのは、各層が何を知らなくてよいかを定義することだ。知らなくてよい情報が多いほど、その層は安定する。安定した層は、AIにとっても人間にとっても扱いやすい。

例えば、注文画面のボタンの色を変えたいだけなのに、決済ロジックや在庫更新の関数まで一緒に触らないといけないなら、その設計は失敗している。逆に、見た目の変更はUI層だけ、ビジネス規則はユースケース層だけ、永続化はリポジトリだけで完結するなら、変更は局所化される。優れた設計とは、変化がどこまで波及するかを予測可能にする設計である。

AIに優しいコードとは、AIだけが読めるコードではない。変更の意味が、層をまたいで拡散しないコードである。

この観点から見ると、設計とは抽象化の芸術ではなく、摩擦管理の技術だと言える。人間は曖昧さに慣れていても、並列に動くAIは曖昧さで事故を起こしやすい。だからこそ、曖昧さを減らす設計が、これからの現場では最も実利的になる。

これからの開発者に必要なのは、実装力より翻訳力である

では、私たちは何を学び直すべきか。答えは意外なほどシンプルだ。設計を、AIと人間が共有できる言語として扱うことである。これは抽象論ではない。日々の実務で、次のような変化を生む。

まず、機能追加のたびに「これはどの層の責任か」を先に決める。次に、UIの関心事はコンポーネントの近くに置き、状態の流れはできるだけ見える形にする。そして、ユースケースは外部実装から切り離す。こうした作法は、古い教条ではなく、AIにとってのナビゲーションシステムになる。

さらに重要なのは、設計書を増やすことではない。むしろ、コードそのものが設計書として読めるように整えることだ。関数名、ファイル構成、依存関係、境界の切り方が明快であれば、AIは探索コストを大きく下げられる。人間が読むドキュメントと、AIが読む構造は一致しなくてもよい。だが、両者が同じ地図を見ている状態は目指せる。

ここで開発者の役割も変わる。これから重要なのは、細部を一から書く職人であること以上に、適切な分解を与える編集者であることだ。AIは実装を速くするが、構造の欠如を自動で救済してはくれない。だから、速さを得るほど設計の質が問われる。

Key Takeaways

局所性を最優先にする
UI、状態、ドメイン、I/O の関心事をできるだけ近くに置き、変更の波及範囲を小さくする。
レイヤーは人間の整理術ではなく、AIの作業単位として設計する
「どこに何があるか」が明確だと、並列作業やLLMの部分修正が安全になる。
設計の基準を美しさから予測可能性へ移す
いい設計とは、変更したときに何が壊れるかを先に見積もれる設計。
コードを共通言語として整える
DDDやクリーンアーキテクチャのような用語は、人間だけでなくAIに対しても強い指示になる。
「書く力」より「分ける力」を鍛える
AI時代の生産性は、実装速度より、責務をどれだけ明確に切れるかで決まる。

結論: これからの設計は、機械に読ませるための人間の知恵である

AIがコードを書く時代には、設計はもはや人間だけのための芸術ではない。むしろ、人間とAIが同じ前提で動けるようにするための翻訳装置になる。Emotionのような局所化の思想も、DDDやクリーンアーキテクチャのような境界設計も、突き詰めれば同じ目的を持っている。変更を扱いやすくし、判断を減らし、理解を共有可能にすることだ。

だから、未来の開発者は「何を実装したか」だけでなく、「どんな会話がしやすい構造を作ったか」で評価されるようになる。コードベースは、単なる成果物ではない。人間とAIの協働を可能にする、思考のインターフェースである。

そしてそのとき、最も価値のある設計とは、もっとも賢い設計ではない。もっとも説明しなくて済む設計である。