AI時代のエンジニアは、アーキテクトの能力が必要なのではないか
はじめに
このドキュメントは、私個人の考えを整理するためのものであり、正確なエビデンスに基づいて書かれたものではありません。そのため、誤った内容が含まれているかもしれません。
また、LLMやMLについても専門家ではないため、見識に甘さがあるかもしれません。いちアプリケーションエンジニアの考えと認識いただければ幸いです。
現状のエンジニアリング観点からみたAI
2024年9月現在、生成AIのパフォーマンスは数ヶ月単位でアップデートを続けており、実践で使えるコード生成のクオリティに達しつつあります。
少なくとも、少しの手直しで使えるレベルには確実に到達しており、ゼロから書くよりもはるかに速く作業できるようになっています。
個人的にあまり書きたくないコード（単調なテストコードなど）は、もはやAIの仕事と言っても良いと感じています。
AIエージェント
AIエージェントの定義は多少の揺れがありますが、AWSによれば「合理的な判断を自律して行うソフトウェア」と説明されています。
一方、LangChainでは、LLMに何らかのツール（Web検索や言語処理など）を与えて動作するソフトウェアを指しています。現時点のAIエージェントは、自我を持ち自律的に行動するというよりも、人間がその行動パターンを設計し、LLMなどを用いて分岐や繰り返しを柔軟に行う、デザインパターンのような位置づけだと理解しています。
AIエージェントのデザインパターン(アーキテクチャ)の発展とプロダクトのアーキテクチャ
AIエージェントは一種のデザインパターンであり、この分野ではより高い精度や省エネルギーを実現するための論文が数多く発表されています。
例えば、アウトプットを自己反省（リフレクション）させることでクオリティが向上するなど、LLMの振る舞いや使用方法自体もまだ研究段階で発展途上です。
同様に、それらの理論や実装論をソフトウェアとしてどのように実現するか、ソフトウェアアーキテクチャについてもまだ発展途上だと思われます。
例えば、私の所属する会社では、LLMのプロダクト構築にLangChain社のLangGraphというグラフベースのソフトウェアを使用しています。これは、LLMエージェントの論文を柔軟に実現するための基盤エコシステムであり、このLangGraphを使ってどのようにプロダクトを構築するのが効率的かは、各チームごとに最適なアーキテクチャを考える必要があります。
そして、当然ながら、現時点ではLangGraphが唯一の実現方法ではなく、今後モデルやLLMのデザインパターンが変化すれば、エコシステムの形態も変わってくることは、この1年ほどの動向を見れば容易に予想できます。
人間の行動パターンを作るのは難しい
AIエージェントの開発は、現時点では人間の行動パターンをモデル化し、それをシステムに実装することと言えます。しかし、前述のとおりLLMエージェントというデザインパターンがまだ発展途上である現状では、この行動パターンのモデル化を難しい作業だと感じています。
想像以上に人間の行動パターンは複雑であり、例外も多いため、現在のLLMエージェントのパターンで実装すると、かなり複雑な実装になってしまうように思います。
例外ケースのような複雑な判断を、LLMがより自律的に処理できれば一気に楽になるのですが、現時点ではそこまで汎用的に動けないためです。
これは、LLMのモデルの発展と共に、「5歳の子どもが作業する場合の指示フロー」「20歳の知識のない成人が作業する場合の指示フロー」「5年以上専門性がある人が作業する場合の指示フロー」のように徐々に改善され、プロセスも少なく最適化されていき、最終的には超汎用の行動パターンで良くなるのかもしれません。
これからのエンジニアの仕事は、アーキテクチャやデザインパターンをアップデートする能力がより顕著になる
超汎用的なAIモデルが完成し、すべてそれらに任せられる時代が1年後なのか10年後なのかはわかりませんが、現時点では前述のとおり、LLMプロダクトの開発にはアーキテクチャやデザインパターンの構築作業がまだ必要です。
そして、LLMのモデルや実装理論(デザインパターン)がアップデートされる限り、プロダクトのアーキテクチャやパターンも柔軟に変化していく必要があります。
ある時点までLLMが進化するまでは、このようなアーキテクチャのアップデート作業がエンジニアのメインの業務になるのではないかとなんとなく考えています。
AIエージェントのアーキテクチャについては、これからも日々さまざまな研究が進むのは確実です。そしてその一部は、直接LLMモデルにも反映されていくと思われます。
（ChatGPTのo1などは、単純な学習モデルだけでなく、おそらくエージェントとしての振る舞いまで実装されたAIエージェントのモデルなのではないでしょうか？）
- AIエージェントモデル = LLMの学習モデル + エージェントアーキテクチャ
みたいなイメージです。
現在は色々と過渡期であるため、ソフトウェア開発側もエージェントアーキテクチャについて試行錯誤している段階です。ある意味ではRAG（Retrieval-Augmented Generation）などもその類のものです。本来的には、広義の検索（インターネット上の検索）などはモデル提供側で完璧な検索ができるなら、RAGは必要ありません。
一方、AIエージェントのツール部分についてはプロダクト側に依存するため、完全な汎用AIモデルはおそらくまだしばらくは完成しないように思います。
RAGについても、自社のクローズドなデータベースへのアクセス用途などでは、引き続き独自のツールとして実装する必要があります。
また、そもそものシステムの実現レベルのアーキテクチャは、各プロダクトの実装に委ねられています。Amazon Bedrockを使うのかLangChainを使うのかなどの実装アーキテクチャは、まだまだ模索中の段階に見えます。
- AIエージェントモデル = LLMの学習モデル + エージェントアーキテクチャ
- AIプロダクト = AIエージェントモデル + (独自のエージェントアーキテクチャ) + ソフトウェアアーキテクチャ
しばらくはこの「エージェントアーキテクチャ」と「ソフトウェアアーキテクチャ」をプロダクト開発側で考慮する必要がありますが、一部のエージェントアーキテクチャはモデルベンダー側でも取り入れられるはずなので、そのたびにソフトウェアアーキテクチャの変更も頻繁に発生しうる状況だと思われます。
今までは、アプリケーションエンジニアは効率的なデザインパターンやアーキテクチャを学び利用するだけで良かったですが、これからはプロダクトに合わせた柔軟なデザインパターンやアーキテクチャを自ら考えなければならない時代になっていると感じます。
ある意味では、エンジニアの役割は、コードを書くことからより抽象度の高いレベルへと移行しているのかもしれません。
そして我々アプリケーションエンジニアは、よりデータサイエンティストやドメインエキスパートと密に連携して、ビジネス要件やユーザーのニーズを人間の振る舞いとして、アーキテクチャやデザインパターンに落とし込む作業が重要になってくると感じています。
終わりに
なんとなく最近感じているエンジニアとしての自分の考えを、書いてみました。読んでいただきありがとうございます。
Discussion