理由
昨今、クリーンアーキテクチャはアンチパターンだの、AIに任せておいた方がむしろ質のよいものが出来るだの、そんな意見が世間を席巻している。
一方、アーキテクトから見ればそれらの意見はスロップでしかないのは周知の通りだろう。
業務で作成したアプリケーションの寿命が短いことは往々にして無い。どれだけPoCだと前置きしてトライアルを頼もうと、いつの間にか本番運用されて瑕疵報告が自分に飛んでくるのが世の常だ。
絡まりあったアーキテクチャ、どこに何があるのか分からないスパゲッティコード。
確かにAIに頼めば調査して解決してくれるのは事実だが、トークンも時間も無料ではない。
簡単に解決できるのであればそれに越したことは無く。
保守性とは「長く使う可能性のあるアプリケーション」全般に求められるものというのは、
このAI駆動開発全盛の時代においてもむしろ説得力を強める言説である。
方法
さて、守らせる方法にはいろいろあるが、私が推しているのは「TDDの文脈」にアーキテクチャ検査を乗せることだ。いわゆる「Arch-Unit」、コーディングが定めた規約に従っているかを全ソースコードファイルを読み込んで機械的に検査する手法である。
最近のAIは強力な傾向付け学習によってTDDをネイティブに扱える。先にRed、実装してGreenといった動きも最近のAIはスムーズにやってくれるので、案外頼むだけで静的解析→Arch-Unitは出来てしまう。
例えばtsなら以下のようなAgent.mdで頼む。
（これは記憶から取り出した一例。もっと良い書き方があるはず）
# 規約
## アーキテクチャ
Functional Core / Imperative Shell（FCIS）を採用します。
全てのソースコードに対して一律に適用するため、src/arch-test/FCIS/ 配下に下記ファイルを作成してください。
// src/coreでexportされる全ての関数・定数等について、引数が__brand を持つ型付きprimitiveであること
// src/coreの関数内で取り出される値について、他の関数に型を破棄して受け渡されることが無いこと
boundary.test.ts
// shellがcoreに依存しないこと
layer.test.ts
// coreの内部の依存が有向に保たれていること
package.test.ts
// ディレクトリ間で用語・概念の重複が無いこと
claster.test.ts
...(他多数。上記は一例）
こうするとAIが書いた後に自律的にチェックするnpm run testで書き方が悪ければ落ちる。
そのフィードバックがコンテキスト・メモリの成長を促し、保守性を意識した開発に繋がっていくというわけだ。
手軽に試せると思うので、ぜひやってみてほしい。