AI時代の設計は、実装のためではなく会話のためにある

最初の問いは、コードを書くことではない

LLMで開発するとき、多くの人はまずこう考える。どうやって速く書かせるか。しかし本当に重要なのはそこではない。むしろ問いは逆で、どうすればAIが迷わず動ける設計に変えられるかだ。

この発想の転換は、意外なほど大きい。人間向けの設計は、可読性、保守性、責務分離といった言葉で語られてきた。だがAIが実装主体に近づくと、それらは単なる美徳ではなく、並列化のためのインフラになる。設計が曖昧だと、LLMは毎回判断をやり直す。設計が明確だと、判断が減り、生成が増える。つまり、優れた設計は「良いコード」を作るだけでなく、複数のAIが同時に働ける環境を作る。

ここで起きているのは、ソフトウェア開発の本質の再定義だ。これまで設計は、未来の人間のためのメモリ圧縮だった。今や設計は、AIに対する実行可能な契約になりつつある。

---

速くなるのは、AIが賢いからではなく、曖昧さを減らしたから

LLMを使うと、短時間で大量のコードが出てくる。この事実だけを見ると、進歩の正体はモデル性能の向上に見える。だが実際には、速度向上の多くはモデルが賢くなったことより、仕事の切り分けが上手くなったことから生まれる。

たとえば、家を建てるときに、設計図が雑で「この柱はどこへ置くのか」「配線はどこを通すのか」が毎回現場判断になると、職人が何人いても遅い。逆に図面が明快なら、壁工事、配線、内装を別々のチームが同時に進められる。AIコーディングも同じで、設計の明確さは並列性そのものだ。

ここで重要なのは、深いレイヤー分けを人間の都合だけで嫌うべきではないという点だ。人間にとっては面倒でも、AIにとっては実装量が増えること自体は苦ではない。むしろ、レイヤーごとに責務がはっきりしていれば、各層で何を置くかという判断がほぼ不要になる。判断が減ると、プロンプトは短くなり、コンテキストは安定し、変更の影響範囲も狭くなる。

AI時代の設計の価値は、美しさではなく、判断を減らすことにある。

この視点で見ると、DDDやクリーンアーキテクチャのようなパターンは古臭いどころか、むしろ新しい。なぜなら、それらは人間が読むための流儀であると同時に、LLMにとっての共通言語でもあるからだ。境界が明確な言葉は、そのままAIへの指示体系になる。用語が揃っていれば、説明は短くなり、推論は安定する。結果として、同じコードベースでも、AIはより大きな文脈を扱えるようになる。

これは単なる生産性の話ではない。設計は、知能の使い方を決める。曖昧な設計は、知能を解釈に浪費させる。明確な設計は、知能を生成に集中させる。

---

コンテキストウィンドウとは、メモリ容量ではなく作業半径である

LLMを使うとき、多くの人はコンテキストウィンドウを「どれだけ入るか」という量の問題として捉える。だが本質はもっと実務的だ。コンテキストは単なる入れ物ではなく、モデルが同時に気にできる作業半径である。

たとえば、リポジトリを作るときに「まず gh コマンドでリポジトリを作って」と言う一言は、単純に見えて実は重要だ。これは単なる初期操作ではなく、以後の作業における参照点の確定だ。リポジトリが決まれば、ブランチ運用、Issue、PR、CI、権限、ディレクトリ構成まで、すべての文脈がそこを基準に整理される。最初の一手が曖昧だと、その後の全作業に微妙なずれが蓄積する。

LLMでも同じだ。コンテキストウィンドウの理解が重要なのは、単に長文を入れるためではない。何を同じ窓の中に置くか、何を外に逃がすかを決めるためだ。例えば、次のような違いがある。

1. 仕様、境界、命名規則、既存のモジュール構造は、コンテキストに入れる価値が高い。
2. 変更の詳細履歴や雑多な議論は、むしろ外に置き、必要時だけ参照するほうがよい。
3. AIに全体を一度に覚えさせるより、設計された局所文脈を何度も与えるほうが安定する。

ここでの核心は、コンテキストを「記憶」と思うと失敗しやすいということだ。正しくは、コンテキストは現在の作業空間だ。人間でも、机の上に広げる書類は限られている。すべての資料を机上に置くと何も見えなくなる。だから本当に必要なのは、情報を詰め込むことではなく、情報を配置することだ。

この視点を取ると、ハーネスエンジニアリングの意味も変わる。優れたハーネスとは、AIにたくさん読ませる仕組みではない。AIが毎回迷わず、同じ前提で動けるように、文脈の入口と出口を設計する仕組みだ。

---

並列化の本質は、人数を増やすことではなく、判断を分解すること

10並列でAIを回す、という言い方は派手に聞こえる。しかし本当の価値は、単に速さを10倍にすることではない。並列化の本質は、ひとつの巨大な判断を、独立した小さな判断に分解することにある。

人間の開発でも、並列化がうまくいくチームは、作業者が多いから強いのではない。依存関係が整理されていて、各人が何を決めればよいかが明確だから強い。逆に、仕様が曖昧なまま人数だけ増やしても、会議が増えるだけで進まない。AIでもまったく同じことが起きる。

ここで役立つのが、レイヤーという発想だ。UI、アプリケーション、ドメイン、インフラのように境界を切ると、各レイヤーで必要な文脈が違うことが明白になる。すると、あるAIはドメインルールだけを担当し、別のAIはAPI接続だけを担当し、さらに別のAIはテストだけを見る、という分業が可能になる。大事なのは、分業そのものではない。依存しすぎない分業が可能になることだ。

これは、AIに仕事を細かく切ると品質が落ちるという直感に反する。実際には逆で、切り方が悪いから品質が落ちる。意味のある境界で切れば、各AIは一貫した局所最適を出しやすい。境界がないまま全体を一気に書かせると、文脈が混ざり、命名が揺れ、修正のたびに別の部分が壊れる。

並列化とは、同時にたくさん考えさせる技術ではない。考えるべきことを分割して、考えなくてよいことを固定する技術である。

この定義は、AIだけでなく人間にも効く。会議を減らす最良の方法は、会議で決めることを減らすことだ。コードレビューを速くする最良の方法は、レビューで迷うことを減らすことだ。LLMコーディングで求められるのも同じで、モデルを大きくする前に、判断の総量を設計で削ることが先だ。

---

新しい設計能力とは、AIが読みやすい世界を作ること

ここまでを一言でまとめるなら、AI時代の設計能力は、人間に説明しやすい世界ではなく、AIが継続的に作業しやすい世界を作る能力だ。

この違いは微妙だが決定的だ。人間向けの設計は、ときに美しい抽象と優雅な命名を重視する。しかしAI向けの設計では、抽象の美しさより、誤解の余地の少なさが重要になる。たとえば、ある機能に対して「サービス」「マネージャ」「ユーティリティ」といった曖昧な箱を作るより、ドメインの意味で名前を切ったほうがよい。AIは曖昧な名詞に弱い。何を責務とし、何を持たないかが明確な言葉に強い。

ここに、設計の学習価値がある。DDDやクリーンアーキテクチャを学ぶ意味は、流行を追うことではない。AIとの対話の文法を身につけることにある。境界、集約、依存方向、ユースケース、インターフェース。これらは単なる教科書用語ではなく、モデルに作業の筋道を示す座標軸になる。

同時に、コンテキストウィンドウの理解も、単なる制限管理では終わらない。これは、会話の設計だ。何を最初に固定し、どの情報を常駐させ、どの情報を都度取りに行くか。良いシステムは、情報を全部持つのではなく、必要なときに必要な文脈だけを召喚できる。

この考え方が浸透すると、開発の評価軸も変わる。優れた開発者は、単に速く書ける人ではなく、AIが迷わず動ける骨格を作れる人になる。つまり、これからの設計とは、未来の自分のためのメモではなく、現在のAIのための道路整備なのだ。

---

Key Takeaways

1. 設計の価値は、AIの判断コストを下げることにある。曖昧さを減らすほど、生成は速く、修正は安全になる。
2. レイヤー分けは人間の好みではなく、並列化の前提条件。責務が明確なほど、複数のAIが同時に独立して働ける。
3. コンテキストウィンドウは容量ではなく作業空間。全部を入れるのではなく、必要な文脈を正しく配置する発想が重要。
4. DDDやクリーンアーキテクチャは、AIにとっての共通言語。用語が揃うと、説明の重複が減り、誤解も減る。
5. 最初の一手を固定することが、後続の並列性を生む。リポジトリ作成や構成の初期決定は、後のすべての作業を安定させる。

---

結論: これからの優秀な設計は、知識を保存するのではなく、知能を流す

AI時代において、設計はもはや静的な青写真ではない。設計とは、知能がどこで止まり、どこで流れ、どこで並列化されるかを決める配管図のようなものだ。良い配管は、圧力を保ったまま遠くまで水を運ぶ。悪い配管は、どこかで漏れ、渋滞し、全体を詰まらせる。

だから本当に問うべきなのは、「AIに何を書かせるか」ではない。AIが迷わず書けるように、私たちは何を固定し、何を分け、何を共通言語にするべきかだ。そこに答えられる人だけが、LLMを単なる高速な自動補完ではなく、真の開発パートナーに変えられる。

そしてそのとき、ソフトウェア設計は過去の遺産ではなくなる。むしろ、AIと人間が同じシステムを共同で構築するための、最も未来的な技術になる。