山本　慎一郎

最近、生成AIを活用したゲームを作っています。
前から構想はあったんですが、技術習得も兼ねて、遊び半分で作っています。

で、せっかくなので、AIにコードを書かせてみようと。
VSCode と Claude を使ってやっています。
ここまでガッツリAIに書かせるのは初めてなのですが、やっぱスゴイですね。
格が違います。

感覚的には、若手のエンジニアと一緒にコーディングしてるような気分ですね。
若手がコーディングして、『これでいいですか？』って提案してきたのを、レビューして、OK出すかもっと改善する指示を出すか。
それを繰り返してるような感覚です。
ペアプログラミングにも近いかもしれませんね。

ただ、やっぱりアーキテクチャの部分は、まだエンジニアのサポートがいるかなという感触です。
現段階の生成AIは完全体ではないので、最適でないアーキテクチャを提案してくることが多々あります。
要するに、実現はできるけれど最適ではない、という構造ですね。

これがどんな問題を引き起こすかというと、『全体最適化を図れない』という点です。
システムアーキテクトの試験でも問われますが、アーキテクチャを考えるときには、必ず「全体最適」という点を考慮しなければなりません。
「部分最適」の集まりだと、全体を統合したときに、最適なアーキテクチャではなくなり、結果として資源効率性などが低下してしまうという懸念があります。
ここが、今の生成AIではまだ実現できない。
そのように感じました。

そうなると、じゃあエンジニアの仕事はそこだね、ということになるのですが、ここにもひとつ問題が。
どうやって「全体最適化」が施されたアーキテクチャを判断するのか、ということです。

今のAIアシストによるコーディングでは、修正を適用するかについて、こちらに最終決定を求めてきます。
ですので、部分最適に留まるような変更は、その時点で方針転換を指示できます。

ただそれを行うためには、『AIを利用しているエンジニアが、全体最適でないと気付けること』が必要になります。
ということは、『エンジニアは、全体最適化された構造を知っていなければならない』ということになります。
そのためには、『エンジニアは、全体最適化された構造を学ぶ必要がある』ということになります。
となると、『エンジニアは、どうやって全体最適化を学ぶのか』という命題にぶつかります。

ここで、これまでどうやってエンジニアが全体最適化を学んできたかを考えています。
一番多いパターンは、仕様書を読んで全体像を理解したり、実際にコーディングしてオブジェクト指向なりなんなりで経験を積むことだったのではないかと思います。
要するに、現場で学んでいくパターンですね。
座学で理論を学ぶこともあると思いますが、やはり実務で実践して身に着けてきたと思います。

ところが、生成AIによあるアシストのお陰で、コーディングはもはやエンジニアの仕事ではなくなってきました。
仕様や要件を伝えれば、生成AIがコーディングしてくれるのです。
こうなると、エンジニアは、全体最適化について学ぶ機会が激減してしまうのではないかと危惧しています。
つまり、生成AIの作る「部分最適」のコードに対して、指摘ができなくなるということです。

このような問題は、結果としてプログラムの質を低下させることにつながるのではないかとも思います。

先にも挙げたように、全体最適でないプログラムは、資源効率性などの面で劣る可能性があります。
そうすると、同じ処理をするのにも余計なリソース（CPUとかメモリとか）を消費するようになります。
そしてそれは、ランニングコストの上昇やCO2排出量の増加という形で、ビジネスに跳ね返ってきます。
結果として、適切でないプログラムによって、ビジネスに負担がかかるのです。

もちろんこれは、トレードオフの問題だったり、ケースバイケースでの判断が必要な点だとは思います。
ただ、何も考えず、漠然とAIドリブンな開発ばかりしていてはいけないのではないかと。
そのように思います。

他方、これからのエンジニアのあるべき姿についても検討が必要です。

これからのエンジニアは、コーディングについての極めて深い知識は重要ではなくなってきます。
それよりも、アーキテクチャだったりビジネスプロセスだったり、AIが苦手とする部分をサポートしていくのが仕事になると思います。

ただ、前述のとおり、そのためにはある程度の現場経験が必要だと思います。
AIドリブンが効率的だと分かっていつつも、それなりの経験値を手に入れるまでは、エンジニアも手を動かしてコーディングする。
仕様書も、すべてAIドリブンで書かせるのではなく、実際に手を動かして書いてみる。
そういった経験が、ある程度は必要なのではないかと思います。

生成AIは、文字通り革新的な、そして、破壊的な影響を社会にもたらしました。
冒頭にも述べた通り、単なるコーディングであれば、もはや人間が敵う相手ではありません。

ただ、AIも完全ではありません。
得意不得意はあります。
ですので、お互いの不得意とする部分を補い合っていく。
そういった関係が、人間とAIの間で必要になってくると思います。

エンジニアの中には、AIを避ける方も結構いらっしゃるのですが、そろそろ相棒として迎えてあげてもいいんじゃないでしょうか？

それでは、APIの利用料として2日で$100飛んだ、山本慎一郎でした。