生成AIで、開発はどのように変わるのかを考える

最近考えていることを言語化しておく。

モジュールのインタフェース設計の重要性が増す

これまでもソフトウェア開発における実装コストは下がり続けていたが、生成AIはさらに実装コストを大きく低減させる。そのため既存の実装をゼロから作り直すことも現実的な選択肢になる。
既存の実装を作り直す場合には「どの範囲を置き換えるか」が重要な関心事となる。 そして「どの範囲を置き換えるか」を決めるのが、モジュールのインタフェース設計である。

作り変える際にはモジュール単位で作り直して品質を担保することになるが、インタフェースが適切に設計されていないと変更の影響範囲を閉じることができず、品質担保に要する工数の増大に繋がる。
生成AIの恩恵を受ける(作り変えるコストを下げる)には、今まで以上にインタフェース設計が重要になるだろう。

フロントエンド開発のボリュームが小さくなる

ここ最近はフロントエンド開発の重要性が高まっていたと感じる。 その背景には複数の要因があるが、主な理由は以下のように考えている。

  • UXやSoEなシステムの重要性が認知された
  • フロントエンドの技術の進化やSPAの台頭した
  • BaaSのようなサービスが現れ、バックエンドの一部が簡略化ができるようになった

しかし生成AIの登場により、フロントエンドには以下の影響が出てくる可能性がある。

  • boltのように、フロントエンドを容易に生成できるようになりつつある
  • エージェントのように、UIがチャットで完結できるアプリはSlackやTeamsのアプリとしての提供が進む可能性がある

すべてがチャットアプリになることは現実的ではないため、フロントエンドエンジニアの需要そのものがなくなることはないだろう。
しかし少人数でのフロントエンド開発や、フロントエンドとバックエンドの兼任は増えると予想する。
フロントエンド開発のみに特化するのはリスクが高いのではなかろうか。

APIとデータモデリングの重要性が高まる

これは前述の「インタフェース設計の重要性」や「フロントエンド開発」の話を踏まえると、必然的に起こる話だ。
APIとはまさにインタフェースなので、多様なフロントエンドに対応できるようなAPIを提供することや、フロントエンドへ依存しないような仕様がより重要になるだろう。

またAPIを通じてアクセスするデータモデルだが、ここは生成AIが登場しても大きく変わることはないだろう。
DDLやSQLを生成AIで作ることはできるが、一度利用し始めたデータモデルを変更することは容易ではない。
データモデルを変更するとなれば移行設計を行う必要があり、それはAPIにも影響を及ぼす。
つまり永く使うことのできるデータモデルが求められるのは、これからも変わらないだろう。

生成AIとの親和性が高いアーキテクチャ設計が重要になる

生成AIの恩恵を受けるためには、以下のように生成AIと親和性の高い構成をとることが重要となる。

  • テキスト化されていること
  • コンテキストを渡しやすい構成であること
  • コンテキスト長を抑えること

テキスト化とは、例えば設定項目はできるだけJSONやYAMLで記述することが挙げられる。
シーケンス図は画像データよりもMermaidで記述されていたほうがよいだろう。 最近の生成AIは画像データも処理できるようになりつつあるが、トークン量はテキストのほうが抑えられるし、誤認識の確率も抑制できる。

コンテキストを渡しやすい構成とは、例えばファイル構成だ。
生成AIにソースコードを渡そうと思ったら、できるだけ1ファイルにしたほうが渡しやすい。そのため、1つのモジュールは1つのファイルにまとまっていたほうがよいということになる。
これは今後、各ツールの生成AI対応が進めば改善される可能性はあるが、いずれにしてもファイル数が多くなるほど生成AIに渡しづらい構成であることには変わらないだろう。

コンテキスト長は今後LLMの進化とともに大きくなっていくであろうが、コストや処理時間には影響がある。
できるだけコンテキスト長を抑えられるような構成も重要になるだろう。

プログラミング言語やフレームワークの移行は比較的容易になる

これまではプログラミング言語のスイッチングコストが非常に大きかったが、今後は比較的容易になる。
LLMがもたらす本質は「同じ意味をいろんな表現に変換できること」であり、これはLLMが最も得意な領域だろう。

「バックエンドをJavaからPythonにしたい」「RubyからKotlinにしたい」といった場合でも、今までに比べれば圧倒的に早く書き直すことができる。
もちろんテストなどは必要になるので工数はかかるが、これまでに比べればかなり現実的な選択肢になるだろう。
(ただし全部を一度に置き換えることは難しいことが多いため、やはりインタフェース設計はここでも重要になってくる)

同様に、別のフレームワークへ乗り換えたい場合や、フレームワークのバージョンアップで破壊的な変更がある場合も、生成AIを用いれば容易になるはずだ。
新バージョンがリリースされて数か月もすれば学習済のLLMがリリースされ、生成AIで書き直すことができるだろう。

関連記事


  1. Ollamaを使ってMac上でLLMを実行してみた
  2. LLM活用法:コードを指定のプログラミング言語で書き換え
  3. GenUのRAGにおけるクエリ・応答生成の仕組みを調べてみた
  4. 主要な各LLMサービスの料金とその推移をまとめてみた
  5. 生成AIの現状を踏まえ、社内活用と未来を考えてみる
  6. Google検索とChatAIにみる、エンタープライズサーチとRAGの未来

comments powered by Disqus