Viveコーディング時代の背景
こんにちは、三田です。
こんにちは、はくたけです。
ゆるテクは、緩く技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、というわけで、本日から新しいオープニングになりましたね。
ちょっと慣れないですね。
そうですね、1回目なので、ちょっと慣れないんですが、今後はしばらくこれでやっていきたいなと思ってます。
はい。
前回が確か、年末年始何してたっけみたいなお話でしたよね。
そうです。
とかをワイワイ2人でやってたんですけど、今日は久々に面白い記事があったので、それを引っ張ってきましたというので、その記事紹介を2人でできたらなって思ってます。
あれですね、ゆるテクの数少ないテクの部分ですね。
本日はなんですけれども、後ほどこのエピソードにはURLついてるんでそちらから見ていただければと思うんですが、
最近見かけた記事で、Viveコーディング時代の3層アーキテクチャ、こういうのやったらどうみたいなアーキテクチャを提案する記事があったので、それ持ってきました。
3層、なんかレイヤードアーキテクチャの何かしらの新しいレイヤーを定義する系の話かな。
そうですね。なんで結構やっぱこう、昨今歌われるのってAIが、AIエージェントがめちゃめちゃコーディングしてくれるから、保守性とかあんま考えずに作り直していった方がもはやいいやろうみたいな話ってやっぱ聞くじゃないですか。
はい、よく聞きます。
それに対して、どういうところはちゃんと人が考えて書いて、普遍なものになって、どういうところを基本AIが作り直す前提で捨てるぐらいの気持ちで書いた方がいいか、みたいなのをこの記事で説明というか提案してましたね。
今年はまだ読んでないんですが、記事を開くと、なんかヒーローイメージというかこの最初のファーストビューに、この4章原マトリックスみたいなやつがなんか。
そうそう。
これはまずどこから行けばいいかな。
そうですね。僕の方で事前にちょっと読んだんで、簡単に背景だけ共有すると、さっき話した通りAIで作り直した方がいいよねみたいな文脈が背景にあるんですけど、もうちょっと丁寧に行くと、従来のソフトウェア開発って基本的に1回作って、それを長期間メンテナンスしていくよねみたいな話が書かれてましたと。
なので基本前提としては長期間メンテナンスする前提なので、いわゆる補修性とか、あと品質面の部分に対して結構設計時に時間をかけたりするじゃないですか、僕らって。
そうですね。
こういうふうに共通化しておくと、後々変更するとき楽になるとか、そういったところをめちゃめちゃ考えて、当初設計してましたと。
それはなぜかっていうと、何度も述べてるようにメンテナンスするから、じゃあメンテナンスするときの書き直しのコストをなるべく減らしたいからみたいなのが従来僕らが開発していく中での前提にあった考え方。
ここ最近そこがやっぱりAIエージェントの登場によって変わってきたよねっていうふうに表現されていて、どこが変わってきたかっていうと、要は書き直しが大変だった部分が結構短時間で書き直してくれるよねみたいなところになってきたので、
じゃあここを長期的にメンテナンスしやすいのを見据えるよりも、とにかく目の前の成果をなるべく早く出すためにコードのきれいさとかを一旦置いておいて、バシバシAIで作らせたほうがいいんじゃねみたいなことを書いてます。
それだけ聞いてまず最初に浮かぶのが、とはいえ積み上げた品質の同等のアプリケーションを一発で一気に再生成できるとは思えないんですが、という考えがまず浮かぶんですが。
僕も読み終わってなおそう思ってるし、あんまそういうところに対しては言及されてないんで、もうそれは本当に人の捉え方それぞれだったりするし、どうこれを解釈してどう使っていくかって話なのかなとも思ってます。
僕も博多さんがおっしゃる通り、全てをぶっ壊して作り直すっていうのはあんまり正直現実的じゃないなって思っていて、この記事も割とそういうことはそこに対して同じようなことを書いてました。
それを踏まえた上でどういうふうにレイヤー分けしてAIにガッツリ任せるところとそうじゃないところを分けていくかみたいなことを提案してるって感じですね。
3層アーキテクチャの提案
そのために3層に分けるという話なんですね。
です。
じゃあその3層ってどういうものがあるかっていうと、この記事の表現をそのまま引用すると、なんだっけ、コアって呼ばれるところ、コア層とザコアってやつとザコネクタってやつとザディスポーザブルレイヤーっていう3つ。
ディスポーザブルね。
そういうレイヤーの名前なんだって思った。
なるほどね。
その3つに分けて構築していくといいんじゃないかみたいな話が書かれてて、ザコアっていうのがコアっていう名前の通りなんですけど、結構普遍的なところは普遍的でここだけは長期的に運用するの視野に入れて考えなきゃいけないところっていうふうに書かれていて、
それが例を挙げるとビジネスロジックであったりとか、データモデルであったりとか、あとは多分そのプロダクト、そのサービス特有の重要なアルゴリズムとかみたいなところは基本的に壊れないとか壊しちゃいけない部分だったりするから、ここに対しては従来通り丁寧に設計しましょうって書いてました。
なるほどね。
そうだよねって思って。
そうですね。でも、これを今自分が聞いていても思うし、これを聞いていらっしゃる皆さんも自分の今保守しているアプリケーションを想像してみてほしいんですけど、そのアプリケーションでいうザコアの部分どこやねんって多分難しいと思いますけどね。
本当僕もそう思うし、正直既存システムでこれ当てはめるの相当むずいなって思ってて。
そうですね。
そんな多分綺麗にコアと使い捨てられる場所を分離できてるところはいいんでしょうけど、割と入り乱れるじゃないですか。
そうですね。
ってなってくると、言いたいことは分かるんだが、やるとすれば新規システムを構築するときにその感覚というか概念ちょっと入れた上でどう共通化して分けていくかぐらいかなってすげえ思いました。
そうですね。
っていう感想がまずコア層を読んだときにはすごい思ったっていうのと、
その次がコネクタ層、契約とかだったかな、中で書いてる部分を要約すると。
契約って何やねんっていうと、いわゆるオープンAPIとかGRPCとかそういうインターフェースの部分は基本変更されないというか変更しないので、ここも重要ですよと。
そうですね。
これは別にAIに限った話じゃなくて、よくシステム設計していく中で結構バックエンドとかフロントエンドとの共通理解を作るっていう部分でも結構インターフェースって早めに定義したりするんで、まあまあまあって感じですよね。
そうですね。バックエンドの人もマイクロサービスシーズとかやってる人はまあまあまあ。
そんな勝手に変えたら困るやろうみたいな話なんで。
で、いうところが2つ目に来ていて、ここもちゃんと考えて設計して基本あんま変えないですっていう話がされてて、最後多分もうそれ以外って話なんでしょうけど、
それ以外の部分は基本使い捨てそうとして、要はAIに任せてちょっと内部の実装が汚かったとしても、そこを綺麗にするんじゃなくてもう一回作り直しちゃいいじゃんみたいな使い方をしていくといいよみたいな提案ですね。
なるほどね。UIもここに入っちゃうのか。
僕がそんなにフロントエンド開発にすごく明るいわけじゃないので、ここの記事で言ってる例としてUIコンポーネントとか、あとはデータパーサー系とか、あとはシステム間を連携するスクリプトとかがそこの使い捨てそうに当てはまってるんですけど、でもUIもそうなんだって感じはありますよね。
そうですね。アプリケーションというかシステムをデータ中心に考えるとUIはすごい一番外側とかになっちゃうんでしょうけど、この文脈で言う簡単に使い捨てて再生成すればいいじゃんに該当するかというとちょっと微妙な感じはしますけどね。難しそう。
使い捨てレイヤーの役割
あくまで一例というかパターンとして紹介してるだけなので、必ずしもUIイコール使い捨てのものなんですって話でもないかなと思うんで、この記事だとそう書かれてるってぐらいの解釈ではありましたと。
っていうところで、詰まるところインターフェースで定義された内容、インプットとアウトプットが担保されてればその中間過程のパーサーとかは割と結果が正解してれば中身は何だっていいみたいな話なんだろうなって僕は雑に解釈してますね。
なるほどね。この話を今していて、この話どっかで聞いたなーみたいな思ってて今ちょっと探してたんですけど、しんばらさんという方がいらっしゃいまして、その方がですね、提唱されていたパターンがありまして。
コアレイヤー。
記事を探していたんですけど、2018年に書かれていて、いろんなカンファレンスとかでも発表されてたことを覚えてるんですけど、独立したコアレイヤーパターンというのが、その時、しんばらさんという方が提唱されていたパターンがあって、目的、モチベーションは違うけども、形としては同じになりそう。
なるほど。今、僕も博多家さんに記事共有していただいて、流し見してるんですけど、まさにここで書いてる内容で、僕も一個感想でも書いてるんですけど、これ結局のところ、じゃあこういうことをやろうってなったときに、DDDとかのモデリング部分をしっかり理解してやらないことにはうまくできる気がしないなって思ってて。
結局、コアをどこまでとするかとか、インターフェース部分の、さっきの例で言うと、コネクターズの部分とかの契約をちゃんと固めておかなきゃいけないし、難しいですよね。ちゃんとモデリングしてないと失敗するところ。
そうなんですよね。最初の冒頭で、一回作って長期メンテナンスするってなったときに、設計とかに時間かけるよねって話あったけど、結局ここの設計に時間をかけることは変わらないんだろうなってちょっと思っていて。
それがおそらく、今までだと保守性とかにもフォーカスを当てていたんだが、でもどうだろうな、DDDも僕は結構保守性にもフォーカスを当ててる考えだと思ってるから、そんな劇的に変わるのかなみたいな感覚になってきましたね、話してて。
そうですね、あんまり全てをちゃんとメンテしなくてもよくなるんじゃないぐらいの意味合いかもしれないですね。
確かにそうですね。
ディスポーザブルレイヤーっていうのが一番外側にあってもいいんじゃないぐらいの提案かもしれない。
確かに。これ、僕最後読んで思ったのは、ディスポーザブルレイヤーって何があるかなって思ったんですよ。
自分が身近で開発してる中で。あんまり思いつかなくて。
これだって思うのあります?はくたけさん。
何でしょうね。あんまり長期メンテする前提かはちょっとわかんないけど、簡単なクラッドだけするようなアプリケーションを考えると、
データベースからデータ引っ張ってきて表示する部分の処理とかはテンプレだし、どうなってもいいというか、
簡単に壊して作り直しができそうだから、そういう部分は該当するかな。
なるほどな。そうか。結構あれですよね。こういう記事を読むまで僕はどっちかというと、最初のプロトタイピングとかの部分、
壊して作り直すっていう、壊す前提で作るみたいな使い方を主目的としてというかメインで考えてたんですけど、
割とこの記事の考え方でいくと、壊すんだがそのプロダクト自体は長期的に運用していくものみたいな時のデザインな感じしますよね。
そうですね。具体的に言ってもパッと確かに思いつかないんだよな。
パッと思いつかないから、うーんって思うが、これから自分が新しく設計するとか手を加えるってなった時は、
ちょっとだけ使い捨てる層は意識してパッケージ設計であったりとかはしようかなとはちょっとだけ思いましたね。
この説明を見るとグルーコードって書いてあるから、決まった部分があってその間をどう繋ぐかみたいなところはAIが生成する前提なんだろうな。
ああ、そういうことか。
そうですね。ウェブだと決まりきった処理の間かな。メール送信とかファイル読み書きとか。
はいはい。
HTTP通信とか。
メイン層のところと繋ぎ込むためだけの実装って感じか。
グルーコードでイメージするのはそういうやつですけど。
そうですよね。確かにね。
それでイメージすると確かに分かりやすいというか、逆にもうちょっと任せられるんじゃねとか思ってしまうが。
なんかそれだとそんなに任せられる量が多くなくて。
うんうん。
ねえ。うんうんって感じするな。
ってなりますな。
ただある意味そこに対して、そこに対しても今すごくAIで作った後頑張って超レビューしてるとか、
手直ししてるっていうフェーズがあるならば、その考えをもとにそんなにそこ頑張らなくていいよねにできるとちょっと幸せになるんですかね。
そうですね。
はい。というわけで今日はちょっとViveコーディング時代のアーキテクチャ提案記事をちょっと紹介させてもらいましたっていう感じです。
はい。面白かったです。
はい。良かったです。
はい。ありがとうございます。
はい。
そうですね。ちょうどキリもいいんで、そういった話を今日はしたところで、
ユルテクでは感想や話してほしいことなども募集をしています。
Xでハッシュユルテクをつけて投稿するか、Mixi2のコミュニティまでお願いします。
今日はありがとうございました。
ありがとうございました。
