古いJavaの作法をGoとかにも輸入しようとしてくる輩か絶えないのよな。はやくこの新しい構成が広まってほしい https://t.co/QPr8drk5x9
— 渋川よしき (@shibu_jp) November 26, 2025
Xで何気なくレスのポストを付けたら、思った以上に反応がありました。実用Go言語の初版を書いたときには著者陣では「package by featureだよね」、という話をして本にもパッケージ構成の対比を紹介してpackage by featureが良いよ、書いたりしていて、内々ではもう決着がついていた話題・・・・と扱いたいところですが、次々と現れる「Goの標準フォルダテンプレート」みたいなのがpackage by layerなものが多く、「またか」みたいに毎回思っていました。
ということでGeiminiにdeep researchで実際のところの状況はどうなのかを調べてみました。自分が書いた文章とGeminiが書いた文章はきちんと分けておきたいので、こちらのブログの原稿は手書きで書いた内容のみとしていて、Geminiが生成した方はGist側に別にアップしています。
3行まとめ
- package by layerはアプリの機能が増えると収拾がつかなくなってくる
- MVCのN層アーキテクチャ→クリーンアーキテクチャ→コードが太って大変なのでpackage by featureになったよ
- ウェブフロントエンドも同じような変化を遂げてきたよ
- シンプルさをさらに推し進める派もあるよ
4行になった
初回の生成
1度生成したあとに、完全作り直し＆リライトを1度お願いしました。最初はもうちょっとpackage by featureに対して誘導的な「最近はドメインごとに切るpackage by featureが主流になってきたように思いますが」というのが入っていたのですが、それはちょっとフェアな結果にはならないかなと思い別チャットで投げなおしました。2回目は後述しますが、初回に入っていた話がなかったとか内容がいまいちだったりして再調査をお願いしました。
Ruby on Railsなどはpackage by layerでcontrollersやmodelsといったフォルダを最初に切ります。最近はドメインごとに切るpackage by featureも見かけます。springのサンプルもそうなっていました。パッケージ分割の流行についてdeep researchしてもらえますか？
Goの説明がちょっといまいちに感じる。cmdは一般的なレイアウトとして公式でも押している。testdataがプロダクションビルド対象外になるためテストがバイナリに影響を与えないために使う。これはpackage by layer, package by featureとは関係ない話である。pkgというフォルダを作るのはgo.mod以前にはあったかもしれないが、現在主流とは言えない。もうちょっとリサーチしたうえで書き直してもらえないか？
C#の状況についても調べてください。また、ウェブフロントエンドもjQueryベースの状態から、backbone, react/vueの時代になって大きくトレンドは変わってきていると思う。またCSSもアトミックデザインなどがpacakge by layerとなるので、そのあたりも調査をして追加をお願いします。
会社のGeminiの思考モード(Geimini 3 Pro)でレポートを作ってもらいました。
自分では知らなかったRails周りのアップデートとか、C#の話が書いてあって勉強になりました(Railsの話は今見たら1度目の修正で消えてしまった)。とはいえ、Goの最初に出てきた文章がいまいちだったりして、自分が詳しい範囲ではちょっと違和感を感じたのは事実で、訂正してもらったりしたので、まあ鵜呑みにしてはいけないですね。指摘した結果、Russ Coxがgolang-standards/project-layoutに「標準じゃないぞ」とコメントしたという、実用Go言語でも紹介している知っている事例が出てきたので、修正後の文章はだいぶ良くなったと判断しました。
また、初回の生成ではアトミックデザインの話があったのに、2回目では出てこなかったので追加でフロントエンド周りを追加で入れるように依頼を出しました。その結果Tailwind CSSのユーティリティファーストの方にまで話が広がって、個人的に思っていた感覚と近いものが出てきた、という変化もありました。また、ちょっと前にXで話題になった、Next.jsのコロケーションの話とかも出てきたので、フロントエンド周りの話もだいぶ良い結果かなと判断しました。
逆方向もないの？と追加で聞いた
個人的に聞く前からpackage by featureであったのですが、いくらなんでも流れが思っていた通りで一方的すぎるな、と思って次の指示も足しました。こちらの修正は前の内容とあんまりマージしてくれなかったのでこちらも別にアップしておきます。
全体的にpackage by featureになっていっているという論調ですが、逆方向に変化したものがあれば事例を追加して書き換えてください
色々長いけど、ざっとまとめると、完全なpackage by layerへの揺り戻しはないけども、逆に完全にフラットにするといった内容もあるぞ、という感じですかね。
メタなお話
いろんな言語の状況を調べるのは大変なところをざっと調べてまとめてくれるのは面白いですね。一方で、このようなツールを使った上で人類のレベルを引き上げるのは単に生成されたのを読むだけじゃダメだな、というのを思いました。
AI時代の調査の議論は、プロンプトを全公開して、その結果を比較しあったりしてそのプロンプトを改良して・・・みたいなのを共同でやっていくスタイルが新規に発生するのではないか、という仮説の元でこのブログを書いてみました。プロンプトも公開しているのでぜひ皆さんも手元で実行してみたり、それに対して指摘したりして、もし僕が実行したのと違う結論や事例が出てきたらそういうのはX等で教えてもらえたらと思います。AI時代、出力されたテキストにはたぶんあまり意味はなくて、そのためのプロンプトさえ共有すれば良いのでは？となればかなり情報量は圧縮されますね。
ほぼ同じプロンプトでも、2回の実行で出てくる内容が削られていたりもあったので、たぶん、みんながみんな実行すると違う話がいろいろ出てくるんじゃないかと。2回に分けて依頼するのと、新しいプロンプトで1回のリクエストで全部投げなおすのもまた結果が変わりそうですしね。毎回Google Documentで16-17ページぐらいなのでテキストの量で切られたりする？
あと、今回は、僕が持っていた知識と比べることで「これでOK」という判断をしました。また、逆方向の事例がないかも追加で調査をしてもらったりしました。何をもって妥当な結果か、どのような状態になるまでDeep Researchを繰り返せば良いのか、どういう追加指示をするのか、というのはやはり人が判断したりすることになり、そこにアウトプットとしての個性は出てくるので完全にAIお任せにはならないな、という気持ちになりました。
より良いDeep Researchの使い方は今後も追求していきたいですね。