メッチャ長くなりそう。。。

ちょっと書くことをまとめていたら読み物として超絶長くなったため、何回かに分けて投稿します。
一応、各記事には全体のリンクも用意するので、順番に読んでいってもらえれば幸いです。

前セツ

この記事は複数のAIとチャットをした結果をまとめたものとなります。
どうも、AIファーストな思考な、え～すけさんですよ。

AIに実装を完全に任せてプロジェクトを進めていくうちに、

人間に読みやすい綺麗なフォルダ構成やコードを書く必要ってあるのかな？
人間が理解しやすいフォルダ構成やコードってAIにとってはどうなの？

という疑問が湧いてきたので、AIにアーキテクチャどうなの？って言うことを聞いてみた。

AIに聞いてみた

まずはストレートに聞いてみました。

🤔 え～すけさん
「AIだけで大規模システムを開発・保守するとしたら、今のアーキテクチャが最適なの？」

するとAIから返ってきた答えは、意外なものでした。

🤖 AI
「人間向けのベストプラクティスを、そのままAIに適用するのは最適ではないかもしれません。」

おや...？

「人間向け」と「AI向け」で違いなんてあるのか？

そう思って理由を聞いてみました。

🤔 え～すけさん
「どういうこと？」

🤖 AI
「人間はコードを書くコストが高いですが、AIはコードを書くコストはほぼゼロです。」

🤖 AI
「その代わり、AIにとって最もコストが高いのは、コードを理解するために大量のファイルを読むことです。」

言われてみれば確かに。

人間は同じコードを何度も書くのは面倒なので、

共通化する
Utilにまとめる
DRY（Don't Repeat Yourself）を意識する

という考え方になります。

でもAIは違います。

コードを書くこと自体は数秒で終わります。

その一方で、

共通Utilはどこ？
どのクラスを使えばいい？
他にも似たような実装はない？
修正したら他に影響しない？

といった確認のために、多くのファイルを読み込む必要があります。

つまり、AIにとっては**「書くコスト」よりも「読むコスト」の方が圧倒的に高い**ということになります。

ここで、さらに疑問が湧いてきました。

🤔 え～すけさん
「じゃあ、今まで正しいとされてきたDRYって、AI時代でも本当に正義なの？」

するとAIは少し考えたあと、こんな答えを返してきました。

🤖 AI
「人間だけで開発するならDRYは今でも非常に有効です。」

🤖 AI
「しかし、AIだけで開発・保守することを前提にすると、評価軸が変わる可能性があります。」

評価軸が変わる...？

ここから、「AIが読みやすい設計とは何か？」という、今まで考えたこともなかった話になっていきました。

Feature FirstはAIと相性が良い？

DRYの話を聞いて、次に気になったのはフォルダ構成です。

最近はFeature Firstが人気になってきていますが、AIから見ても良い構成なのでしょうか？

そこで聞いてみました。

🤔 え～すけさん
「じゃあ、フォルダ構成はどうなの？AIが開発するなら何がいいと思う？」

するとAIは迷わずこう答えました。

🤖 AI
「AIだけで開発するのであれば、Feature Firstは非常に相性が良いと思います。」

「ほう、やっぱりそうなのか。」

理由を聞いてみることにしました。

🤔 え～すけさん
「なんでFeature Firstがいいの？」

🤖 AI
「AIは、一度に大量のコードを理解することが苦手だからです。」

例えば、昔ながらのレイヤー構成だとこんな感じになります。

controllers/
services/
repositories/
entities/

注文機能を修正したいだけなのに、

Controller
Service
Repository
Entity

と、あちこちのフォルダを見に行かなければなりません。

対してFeature Firstなら、

features/

    order/

    user/

    inventory/

注文機能を修正したいなら、

features/order

だけ見れば済む可能性が高くなります。

確かにこれはAIだけではなく、人間にとっても分かりやすそうです。

AIは「全体」より「小さな塊」が好き

さらにAIはこんなことも言っていました。

🤖 AI
「AIは、大きな仕事を一度にこなすより、小さな仕事を数多く処理する方が得意です。」

例えば、

「注文機能を全部作って」

という依頼より、

注文一覧APIを作る
注文登録APIを作る
注文キャンセルAPIを作る

のように細かく分けた方が、AIは安定したコードを生成できます。

これって、人間でも同じですよね。

「システム全部作って」と言われるより、「この機能だけお願い」と言われた方が作業しやすいです。

でも、本当にFeatureだけでいいの？

ここで少し意地悪な質問をしてみました。

🤔 え～すけさん
「じゃあ、全部Featureごとに閉じ込めれば最強ってこと？」

するとAIは少し考えた後、こんな答えを返してきました。

🤖 AI
「いいえ。共有すべきものまでFeatureに閉じ込めるのは危険です。」

おや？

Feature First推しなのに、早くも否定が入りました。

どういうことなんでしょう？

AIが苦手なのは「変更影響が見えないこと」

例えば、こんなテーブルがあるとします。

users

id
name
email
birthday

これをFeatureごとに持つと、

features/

    order/
        UserEntity

    login/
        UserEntity

    profile/
        UserEntity

のようになります。

ここで、

users

+ icon_url

というカラム追加があったとします。

さて、修正が必要なのはどこでしょう？

order？
login？
profile？
全部？

AIは検索すれば見つけられるかもしれません。

でも、「どこまで影響があるのか」という判断は、人間でもAIでも難しくなります。

「変更理由」で分けるという考え方

そこでAIが提案してきたのが、少し面白い考え方でした。

🤖 AI
「責務だけではなく、『変更理由』でもモジュールを分けると良いかもしれません。」

最初は何を言っているのか分かりませんでした。

詳しく聞いてみます。

🤔 え～すけさん
「変更理由？」

🤖 AI
「同じ理由で変更されるものは近くに置き、違う理由で変更されるものは分ける、という考え方です。」

例えば、

注文画面
注文API
注文の業務ロジック

これらは「注文仕様が変わる」という同じ理由で一緒に修正されることが多いです。

逆に、

users

テーブルは、

注文
ログイン
会員管理

など複数の機能から利用されます。

つまり、

「DBスキーマ変更」という別の理由で修正されることが多いわけです。

そう考えると、

shared/

    database/

features/

    order/

    login/

    profile/

という構成の方が自然なのかもしれません。

この考え方、意外と納得できる

正直なところ、この回答を聞いて最初は

「いやいや、そんな都合よく分けられる？」

と思いました。

でも考えてみると、実際の保守でも

「この修正、どこまで影響するんだろう…」

と悩むことはよくあります。

もしAIが主体で開発・保守する時代になるなら、

「責務」だけではなく「変更理由」も設計の基準になる。

そんな時代が来るのかもしれません。

ここで、さらに別の疑問が湧いてきました。

🤔 え～すけさん
「じゃあ、共通Utilってどうなるの？」

今まで当たり前のように作ってきた DateUtil や StringUtil。

AIはこれらをどう考えているのでしょうか。

次は、その話を聞いてみることにしました。