コードはAIが書ける時代に、設計力はどう鍛えるか - CleanArch Masterという形にした理由¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
生成 AI によってコードを書くハードルが下がった時代に、差が出るのは「どう分けるか」「責務をどこに置くか」という設計力だ、という記事。
Clean Architecture は図や記事を読むだけでは実装に落としにくいため、GitHub Pull Request と AI レビューで手を動かしながら学ぶ CleanArch Master という教材の設計意図が説明されている。
教育工学の観点として、ill-structured problem、Bloom のタキソノミー、形成的フィードバック、scaffolding が使われている。
本文¶
記事の出発点は、生成 AI によってコード生成そのもののハードルが下がったこと。 API や UI は AI と一緒に作れるようになったが、責務分離、依存関係の向き、ドメイン知識の置き場所、ユースケース境界の判断は依然として難しい。
Clean Architecture も、同心円の図を見ると理解した気になりやすい。 しかし実装すると、UseCase に何を置くのか、Domain に何を持たせるのか、Repository と QueryService をどう分けるのか、Infrastructure の都合をどこで止めるのかが急に難しくなる。
筆者は、この「分かった」と「書ける」の間を埋めるため、Clean Architecture を手を動かして学ぶ CleanArch Master を作っている。
設計は正解が一つに定まりにくい¶
記事では Herbert Simon と Jonassen の議論を引きながら、設計課題は ill-structured problem になりやすいと説明する。
well-structured な問題は、ゴール、制約、評価基準が明確で、正解が比較的決まりやすい。 たとえば、入力に対して期待した出力を返す関数を書く課題はこの性質に近い。
一方、ill-structured な問題は、何を良い解とするかが文脈に依存する。 設計はまさにそうで、責務の切り方、境界の置き方、データの持たせ方に唯一の正解がない。
「本を貸し出す」機能でも、判断点は複数ある。
- どこまでをドメインルールとしてエンティティに持たせるか。
- UseCase はどこまでオーケストレーションするか。
- Repository と QueryService をどう分けるか。
- トランザクション境界をどこに置くか。
このような判断では、答えそのものよりも、なぜその設計にしたのかを説明できることが重要になる。
記憶や理解だけでは設計力に届かない¶
記事では Bloom のタキソノミーを使って、設計学習の段差を説明している。
Clean Architecture を学ぶとき、最初はレイヤー名や依存関係ルールを覚える。 次に、サンプルコードを見て、責務分離の意図を理解する。 しかし、実務で必要なのは、要件を読んで自分で構造を決め、実装し、その妥当性を評価する段階。
これは「記憶」「理解」だけでなく、「応用」「分析」「評価」「創造」にまたがる。
レイヤー名を知っていても、実装では UseCase にロジックを寄せすぎたり、Infrastructure の都合が Domain に逆流したりする。 つまり、知識として知っていることと、設計判断として書けることの間には大きな溝がある。
答えを教えるより問いを設計する¶
CleanArch Master では、完成形コードをただ見せる教材にはしない方針が取られている。 完成形だけを見ると、学習者は理解した気分になれるが、自分で責務を切る経験が得られない。
そこで、課題では答えそのものよりも、判断が必要になる制約を前面に出す。 実装にはある程度の自由度を残しつつ、設計上の論点が自然に立ち上がるようにする。
目標は、正解コードをなぞることではなく、学習者が自分で分け方を考え、その理由を説明できるようになること。
これは Clean Architecture の考え方とも合う。 Clean Architecture は、フォルダを層に分けることが目的ではない。 外側の都合からビジネスルールを守り、依存関係を内側へ向けるための設計である。 その意図を理解しないと、ただのディレクトリ分割で終わる。
フィードバックは速く具体的である必要がある¶
設計学習では、フィードバックの質が重要になる。 Hattie と Timperley、Nicol と Macfarlane-Dick、Shute などの研究を参照し、形成的フィードバックは timely で specific であるほど機能しやすいと説明される。
設計レビューで必要なのは、抽象的な感想ではない。
- 何が良かったのか。
- どこが原則から外れているのか。
- 次に何を直せばいいのか。
この3つが、判断の記憶が新しいうちに返ってくる必要がある。 時間が空きすぎると、なぜその実装にしたのかという文脈が薄れ、学習として回収しにくくなる。
人間メンターだけで速く具体的なレビューを常時返すのはコストが高い。 そのため CleanArch Master では、GitHub の Pull Request を提出すると AI レビューが返る形にしている。
レビューの評価軸は、Clean Architecture 原則が 50%、レッスン固有要件が 50%。 スコア、要約、良かった点、違反箇所、改善提案を返し、違反にはファイルパスや行番号も付ける。
AI レビューは人間レビューを完全に置き換えるものではない。 それでも、提出したらすぐ返り、次の修正へ進めるフィードバックループを作れることに価値がある。
最初は支え、少しずつ外す¶
教育工学の scaffolding、つまり足場かけの考え方も教材設計に使われている。 学習者が一人ではまだ難しい課題に取り組めるよう支援し、理解度が上がるにつれて支援を減らしていく。
無料パートでは TODO アプリを題材に、基本構造を図解する。
- エンティティ層
- ユースケース層
- インターフェース層
- フレームワーク層
- 依存関係の向き
最初から複雑な業務ドメインに入らず、まず構造の見取り図を作る。
有料パートでは図書館管理システムを題材に、より複雑なユースケースに進む。
- ドメイン層の基礎
GetBookユースケースBorrowBookユースケースReturnBookユースケースListBooksユースケースExtendLoanユースケース
読み取り、複雑な書き込み、トランザクション、状態遷移、ページネーションなどの論点が段階的に出る。 最初は命名や構造のガイドを使い、後半では学習者自身が判断しないと進めない課題へ移る。
向いている人¶
対象は完全なプログラミング初学者よりも、実務初級から中級へ進みたい人に近い。
- API 実装経験はあるが設計に自信がない人。
- Clean Architecture を読んだが実装に落とせていない人。
- GitHub や Pull Request ベースの学習に抵抗がない人。
- AI 時代にコード生成だけでなく設計力を伸ばしたい人。
逆に、GitHub の基本操作や PR の流れが分からない段階では、前提が少し重い。
読み替え¶
この記事は、AI 時代の学習設計として読める。 AI がコードを書けるなら、人間は設計をどう学ぶのか。 答えは「設計の正解を暗記する」ではなく、制約つきの課題に向き合い、自分で判断し、その判断に速く具体的なレビューを受けること。
これは Clean Architecture だけでなく、DDD、API 設計、DB 設計、テスト設計にも通じる。 実装結果だけではなく、判断理由を言語化し、レビューされる経験が設計力を作る。
要点¶
- 生成 AI 時代は、コードを書く力より設計判断の力が差になりやすい。
- 設計課題は ill-structured で、正解が一つに決まりにくい。
- Clean Architecture は図を理解するだけでは不十分で、責務分離を実装で判断する必要がある。
- 設計学習には「記憶」「理解」だけでなく「応用」「評価」「創造」が必要。
- 完成形コードを見せるより、判断が必要になる問いを設計する方が学習につながる。
- フィードバックは速く具体的で、次の修正に直結する必要がある。
- AI レビューは人間レビューの代替ではないが、学習ループを短くする道具になる。