久しぶりに、Railsについて「設定より規約だなぁ」という発言を目にして、「規約よりアノテーションがいいし、AIに不利」みたいなツッコミをしたわけです。
ということで、どのようにAIに不利かまとめてみます。
一応、いまのRailsについてはAIがかなり学習しているので、Opusなどではかなり的確に扱えているようです。 なので「AIに扱えるようにならない」という意味ではないです。
規約ベースのフレームワークとは
ここでは例えばmodelフォルダの下にUserという名前のクラスを作るとusersというテーブルへのマッピングになる、というような規約の話です。
アノテーションベースであれば、Userというクラスに@Tableというアノテーションを付けるとuserというテーブルへのマッピングになります。ただ、ここでUserというクラスがuserというテーブルに対応するというところは規約ベースになっています。明示的に書くなら@Table("user")とします。
どのへんで不利？
コードを書くときであれば、システムプロンプトにルールが書いてあれば割と従ってくれます。またプロンプトにルールが必要なことは、AIに未知のフレームワークであれば規約ベースでもアノテーションベースでも同じです。
問題は読むときやリファクタリングです。
書くときであれば、恐らくテーブルマッピングクラスを書くときにはテーブルに関するルールへのアテンションが強まるはずで、それに従って続きのコードを書いていくので、ルールに従いやすいはずです。
一方で読むときには、どのルールにアテンションを強めればいいか自明ではなく、広くルールへのアテンションが向くことになるので、個別のルールへのアテンションは弱くなります。
@Tableと書いてあればデータベースまわりのルールへのアテンションが強くなりますね。
まあ、RailsでもテーブルへのマッピングクラスはActiveRecordを継承するのでその記述からデータベースまわりのルールへのアテンションが強くなるはずですね。なので、テーブルへのマッピングに関してはRailsも名前などの規約だけでなく< ApplicationRecordという記述も併用されてるということになります。
一方でフィールドに関してはクラスには何も書かなかったりするので、マイグレーション用のクラスを見にいく必要があります。そうすると、フィールドの情報が直接クラスに書かれている場合に比べて、離れたところにフィールド情報が置かれることになりますね。そうするとアテンションもちょっと弱まります。
いまのLLMは、注目すべきところに集中してアテンションが向くほうが性能があがります。注目すべきところが広範囲になるとアテンションが発散して性能が低くなります。つまり、 規約ベースだとアテンションが弱くなりがちで不利 ではないか、ということです。
もちろん確定するためにはちゃんと検証する必要がありますが、そういう傾向になるんじゃないかと思います。
Opus使っておけばいい？
まあ、多少アテンションが弱まろうが、そもそものモデル性能が高ければ問題ないですね。Opus使いましょう！
というふうに一概に言えるものでもないように思います。全員ふんだんにOpus使えるような予算の確保ってなかなか難しそう。
企業であれば、効果が出る最低限の課金を行いたいと考えるはずです。なので、できる限り安いモデル、なんならオープンウェイトのモデルを手元で、という風になっていきます。
これは規約ベースのフレームワークだからどうこうというより、AI処理に不利な仕組みを使うとき一般の話ですが、AI処理に不利な仕組みをAIで扱おうとすると、より高い性能が必要になります。 他はSonnetでまかなえるのにOpusが必要、とか、手元で動かすにしても他は8Bでできる処理が14B必要とか。 そうすると 経済的に不利 って話になりますね。
まとめ
まあ、実際にはRailsはAIが十分学習しているし、AIにとっての扱いやすさは規約や設定の部分だけで決まるわけではないので、傾向があるというだけの話ですね。
ただ、「設定より規約」って、いまやほとんど絶滅している、設定ファイルでクラスの役割を記述するフレームワークと比較していて、あまり意味がないように思います。
Railsガイドにも、「他のプログラミング言語やフレームワークでアプリケーションを作成すると、設定のためのコードを大量に書く必要が生じがち」という記述がありますが、いまやそんな言語やフレームワークはないんでは。
比較するならアノテーションベースで、その場に明示的に記述する仕組みです。
いまのAIは、必要な情報が必要な場所の近くに明示的に書かれているほうがパフォーマンスが出ます。アノテーションで必要な場所に明示的に書くほうが、AIにとって負担がないと思います。
