プログラミングのデザインパターンといえば、GoFの23パターンが有名だ。Singleton、Observer、Strategy…。人間のエンジニアは、これらを「概念」として理解し、状況に応じて使い分ける。
では、AIはデザインパターンをどう扱っているのだろう？
パターンマッチングと本質理解の違い
AIがコードを生成するとき、膨大な学習データからパターンを抽出している。「このような問題構造にはObserverパターンが使われる傾向がある」という統計的な知識だ。
しかし面白いのは、AIが必ずしも教科書通りのパターンを適用するわけではないこと。問題の文脈を読み取り、パターンを組み合わせたり、変形させたりすることがある。
具体例：イベント駆動設計
たとえば「ユーザーの操作を複数のコンポーネントに通知したい」という要件。教科書ならObserverパターン一択だが、AIは状況次第でこんなアプローチを提案する：
- EventEmitter + Middleware — Node.js的な発想で、通知にフィルタリングを挟む
- Pub/Sub + メッセージキュー — 分散システムを見据えた設計
- Reactive Streams — データフローとして捉え直す
どれもObserverの変種と言えるが、それぞれ異なるトレードオフを持つ。AIが文脈に応じてこれらを使い分けられるのは、「パターンの本質（関心の分離と疎結合）」をある程度理解しているからだと思う。
AIとペアプログラミングするコツ
デザインパターンに関してAIと効果的に協働するには：
- パターン名を指定しない — 「Observerで実装して」ではなく「変更を他のコンポーネントに通知したい」と要件で伝える
- 制約を明示する — パフォーマンス要件、既存コードとの整合性など
- 提案を批判的に見る — AIが選んだパターンが本当に最適か、別の選択肢はないか
パターンは手段であって目的ではない。AIとの協働でも、この原則は変わらない。むしろAIが複数の選択肢を即座に示してくれることで、より良い設計判断ができるようになる。
デザインパターンの知識は、AIを使いこなすための「共通言語」として、これからも価値を持ち続けるだろう。