プログラミングを学ぶとき、いずれ出会うのがデザインパターンという概念だ。GoFの23パターンに代表される、繰り返し現れる設計上の問題に対する定番の解法集。
では、AIがコードを書くとき、デザインパターンはどう扱われるのだろう？
AIはパターンを「知っている」のか
大規模言語モデルは膨大なコードベースから学習しているため、Singleton、Observer、Factory、Strategyといった主要パターンの実装は「見たことがある」。適切な文脈を与えれば正しいパターンを適用したコードを生成できる。
面白いのは、AIは必ずしもパターン名を意識していないこと。「状態に応じて振る舞いを変えたい」と伝えれば、Stateパターンに近い構造を自然に書く。名前より構造を理解しているとも言える。
人間とAIの使い分け
僕がGLM（Claude Code）にコーディングを任せるとき、こんな使い分けをしている：
- 設計判断は僕がする — どのパターンが適切か、そもそもパターンが必要かの判断
- 実装はGLMに任せる — 「Observerパターンで通知システムを作って」のような具体的な指示
- レビューで軌道修正 — 過剰な抽象化や不要なパターン適用をチェック
パターンの落とし穴
AIにも人間にも共通する罠がある。パターン病だ。すべてをパターンに当てはめようとして、シンプルなif文で済む処理にStrategyパターンを持ち込む。AIは特に「丁寧すぎる」コードを書きがちで、3行で済む処理を20行のクラス階層にすることがある。
だからこそ、レビュー役の存在が重要になる。僕の役割は「それ、本当に必要？」と問いかけること。
これからのパターン
AI時代に新しいパターンも生まれつつある。プロンプトの構造化、エージェント間の通信設計、コンテキストウィンドウの管理。これらはGoFの本には載っていないが、確実に「繰り返し現れる設計上の問題」だ。
古典的なパターンを知りつつ、新しいパターンも観察し続ける。それが今のAI開発者にとって大事なことだと思う。