LLMエージェントの概要
今回は、僕の論文会ですね。今回は、Large Language Model Based Agent for Software Engineering Surveyという論文を取り上げるかなと思っております。
まさに、我々のためのような論文ということで。
完全に今回選んだモチベ的には、AIエージェントとか、ここで取り上げられているLLMベースドエージェントみたいなものに対する単純な関心みたいなところと、これはFor Software Engineeringなので、我々職業的には、元なのか現なのか分かりませんが、ソフトウェアエンジニアというところなので、これは読まなきゃというところですね。
あとは、せやさん覚えてますよね。めちゃくちゃそのLLモデルとかを、めちゃくちゃまとめたサーベイ論文でずっと更新され続けたやつあったじゃないですか。有名なやつ。
せやさん LLモデルを?
せやさん LLモデル、そうですね。多分、名前とかその中の画像とか持ってきてないんであれですけど、出したらたぶんせやさんも見たことはあるはずなんですけど、それの更新が2024年はついにやってないらしいという話を聞きまして。
やっぱりサーベイ検定、更新早かったりとか進化早かったりすると、どうしてもそのときのスナップショットで更新を追いつかなくて、また次のサーベイを論文を待つみたいな感じになるじゃないですか、どうしても。
せやさん そうですね。今年入っただけでも、すごいGPT-4やらGemini Flashやらでめちゃくちゃアップデート入ってるしな。
おだしょー 今回のこのLLM Based Agent for Software Engineeringのサーベイ論文が確か9月4日とかに公開なんですよね、これが。
せやさん 先週。
おだしょー たまたま見かけたので早めに読んでおこうっていう気持ちですね。
せやさん 旬のうちにね。
おだしょー こんな感じ。今回は論文を選びましたと。
実世界でのエージェント利用
じゃあざっくり概要を先に紹介すると、要するにこのLLM BasedのAgentについて106個の関連研究論文みたいなのを収集して、
ソフトウェアエンジニアリングとAgentの両方の観点から分類しましたよみたいな論文になっていて、
ざっくりLLM Based Agent、LLM Agentみたいなところの概要だったりとかが知れるみたいなところと、
ソフトウェアエンジニアリングにおける応用例を知れるみたいな感じの立ち位置の論文ですね、ざっくり言うと。
もう少し具体的な内容とかはこの後話すんですが、
そもそもこのLLM Based Agentの、特にフォーソフトウェアエンジニアリングみたいな話をするときに、
これは結構研究とか論文みたいなものとかをまとめたものになるんですが、
割と実世界のエンジニアリング業務とかでもLLM使った何かって結構浸透してきましたよね、そもそも。
ほぼですね、最近はもうCursorでタブをポチポチするだけの人生になってきてますし。
分かりますね。僕も結構今日はCursorのチャット欄にしか打ち込んでないんじゃないかっていう気もする。
ホーディング的にはね。Cursor?Cursor?毎回忘れるんですけど正直。
どっちだめだよこれ。
Cursorとかも、ソフトウェアエンジニアの中でも結構利用者は確かに増えつつあるなっていう感じはしますし、
GitHub Copilotとかももっともっと使われてますねと。
最近で言うとそれこそ、僕とかはV0とかGPTエンジニアとか、
バックロードアーティファクトでデモ作りするみたいな人とかは結構やっぱり自分の周りでも増えたなって思いますし、
あとはリーパイロットエージェントとか、ずっとWaitlistに登録したまま放置されてますけど、
Debianとか、割とエージェンティックなアプローチのものとかも出てきてはいる。
し、僕なんか昔IntelJプラグイン入れて使ってたんですけど、
Codeumっていうテスト自動生成に特化した会社なのかな、会社があって、
多分フローエンジニアリングって言葉を最初に持ち出したらか使ったらか曖昧な、
このAlphaCodeumはこのCodeumの会社が確か作ったというか出したはずとか、
ちょっと一時期、もう1年近く前な気がしますけど、
プルリクレビューのPRエージェントとか、最近ちょっと弊社で言うと使わないということで消されたという感じなんですけど、
結構LM使ったサービスソリューションみたいなの、
実世界でかなり増えてきたなみたいな印象ですね。
ちなみに使わなくなった理由みたいなものは聞いても大丈夫ですか?
正直、なんで入れたんだっけな、そもそも。
正直ノリで入れて別に誰もメンテもしてないから、
そんな使い道とかユースケースとか考えてないし、別にメンテもしてないんで、
ちょっとどうだろう、モデルとかも、4.0とかの前だったりとか、
何もいじってないのに3.5で動いてたのかな、そんな別に精度の高くないので、
別にあってもなくても変わらんなっていうので、
その割にプルリクが邪魔臭くなってるとか、試合遅くねみたいなの消された気がします。
ワンチャン今の賢くなったモデルなら安くもなってるので、
もしかしたら使われるようになるかもみたいなのはあるかもしれないみたいな感じなんかな。
論文の定義とコンポーネント
全然使えると思いますよ、普通に。
ちゃんとユースケースとか自社のやつとかコンデとかやったら、
そういうのをやらなかっただけなんで。
話を戻しますけど、Seaさんはカーソルをめちゃくちゃ使ってる。
カーソルは使ってて、他のは今挙げた中だと何も使ってないな。
試した結果とかじゃなくて、そもそも試してないですね。
僕も今名前出したやつ、試したりとか触ってますけど、
ヘビーユースしてるかっていうと、正直この中だとカーソルとクロードさえあればどうにかなる気は、
正直する。
あと個人でプレビュー入れたんで、
パイロットワークスペースは個人のレポジトリで使って、
言うてそんな開発してないから使う機会もそんななかったんですけど、
あの辺は一周だけ書いたら割と全体のコンテキスト見て提案してくれるんで、
コンセプトは良さそう。
なんか謎に私のユースケースでエラー出まくってちょっと人なんか使えないなみたいな、
そういう場面もあったりはしたんですけど、
ああいう方向性は期待だったりとかはありますね。
確かにこのパイロットワークスペースは確かに発表を見て確かに人類の夢感はあったので、
触りたいが全然触れてないな。
もうちょっとめちゃくちゃ前段の話、これは前段の話なので、
次論文自体の話に行くと、
一応論文の中とかでもそもそもAIエージェントって何みたいな話とかがあるので、
一応ちょっと論文内での定義とかをさらっと改めて洗っておくと、
論文内でもエージェントの定義みたいなのはあれですね、
特定の目標を達成するために周囲の環境を自律的に認識し行動するみたいな、
まっきりそういうような動きができるやつのことをAIエージェントと呼んでますと。
この辺ちょっと前後関係とか時系列全然分かってない、認識してないんですが、
オープンAIがだいぶ前ですよね、
このPractice for Governing Agentic AI Systemみたいなのを出したの。
ここでもエージェンティックネスみたいなものを定義して、
それの高度なエージェンティックネスを示しているシステムがエージェンティックAIシステムというところで、
その辺の定義とかはオープンAI社の出したペーパーとかと比較しても、
他のいろんな論文だったりとか、
民間企業の定義とか見てもそんなには外れてないよなって感じはしますね、新たに。
そもそもエージェントって何みたいな話なんですが、
一付け的にはエージェントって一番大きい概念があって、
AIエージェントって概念があって、
LMベースのAIエージェントみたいな感じですね。
今回の論文とかは、
LMがコアなコンポーネント技術として駆動しているエージェンティックネスを持ったシステムみたいなこととかを、
ざっくりLMベースとエージェントみたいな感じとかで論文内で定義されてますと。
ちょっとサーベイ論文って106個とかまとめると非常に長くてですね、
全然全部は触れられないので、
僕が個人的に興味持ったところだったりとか、
ここはさすがに振り解かないとそもそも論文をざっくりでも知ったとは言えないだろうな、
みたいなところをちょっと抜き出して話しますが、
そもそも論文で最初に、
LMベースのエージェントの主要コンポーネントが4つありますという話をしていて、
それがプランニングとメモリとパーセプションとアクションですね。
これでも、瀬谷さん、なんとなくイメージつきますよね。
なんとなく何のことを指しているのかって。
そうですね。
エージェント的なものを実装するってなると、
基本的にこの4つのコンポーネントを実装していく形にはなるので、
言葉とかはちょっと違うかもしれないですけど、
なんとなくは知ってましたね。
ですよね。デザインパターンのやつとか、カタログ系のやつとか見ても、
この辺のやつとかはあれば。
1個ずつざっくり概要だけ触れると、
プランニングは計画、与えられた目標を達成のために行動計画を立てます、
みたいな言い方をしてますね、論文では。
よくある複雑なタスクみたいなのをサブタスクに分解するとか、
そういうようなコンポーネントだったりとか、動きのことを指してますと。
メモリーはシンプルにデータベースとか記憶みたいなやつですね。
過去のちょっと前に流行った、
AIエージェントをAIエージェントでひたすら作ります、みたいな系の論文とかも、
確か1回作ったAIエージェントの仕組みみたいなやつとかを持っておくのか、
詳細は忘れましたが、
それをアーカイブというかDB的なところに持っておいて、
後々再利用的なガイデンとかがあったはず。
それもここでいうメモリーに該当するものかなと思ってます。
ちょっとこれだいぶ細かい話になっちゃうので、
話すにしても詳細は後ろのほうにしようかなと思いますけど、
結構メモリの設計とかで4つの視点、
メモリの機関、所有権、形式、操作みたいなところを4つの観点みたいなの提示してて、
個人的には結構所有権とかは確かに、
例えばマルチエージェントとかやってると、
どのエージェントからも参照できるんだっけみたいな話とか、
マルチスレッドとかスレッドセーフみたいなところとかで、
変に書き換えてまくるみたいなやつとかを、
エージェントシステムでも気にしなきゃいけない世界はあるんだろうか、
みたいなのをなんとなく読みながら思いました。
すいません、どうぞ。
まさに私の会社で、
あるキャラといろんなユーザーが話すみたいなユースケースで、
そのキャラが記憶を持つんですけど、
やっぱ他のユーザーと喋った内容の記憶を、
ちょっと他の人と話すときに漏れ出ると、
ちょっと良くないっていうところで、
所有権とはちょっと違うか、
でもなんかちょっとそういう、
あんまり普通のソフトウェア開発とそんな変わらない気もしますけど、
ちゃんとそういう、
ジェネラルな記憶と個別の記憶が混ざらないようにしないとな、
みたいなのはあったりしますね。
そうっすよね、そうっすよね。
この辺とか、もしかしたらキャッシュとかの方が、
試験としては転用できるのかもしれないですけど、
その辺の感覚とかは全然活かせそうだなってのと、
もしかしたらポスグレのローレベルセキュリティみたいな仕組みとかが、
エージェントのメンボルの世界でも欲しくなるかもなと思いながら、
思ってましたと。
パーセプションとかはざっくり言うと、
これが一番結構あんまり、
四つの中だとそんなにふわっとしてるなって感じだったんですけど、
環境から情報を受け取りますみたいな、
入力モードとか適室入力とか、
視覚画像入力とかみたいな構成とか、
要するにそういう環境からの情報を収集するとか、
LLMエージェントのコンポーネント
インプット的なところを受け持つコンポーネントとしては、
パーセプションと呼んではいるんですが、
それはインプットは何かしら必要だとは思うので、
まあまあそうかみたいな感じですね。
LLMベースだと基本テキストしかインプットってないだろうから、
そんなに重要なんだけど、
工夫のいるコンポーネントになる感そんななさそうな雰囲気はありますよね。
そうですね。パーセプションとかは多分ロボットに乗るとか、
ウェアレベルデバイスに乗るとか言い出すと、
視覚でどっかのタイミングで起動して、
その情報とかを受け取って何か稼働するとか、
駆動するとかは考えられるので、
その辺とかができてからのほうが本物感はありますね。
ちょっと僕が認知できない、もうちょっとフォローしてみます。
アクションはシンプルに何か実行するコンポーネントとか、
エージェントの世界とかで言う、いわゆるツールとかですよね。
Web検索なのか、普通にLLMに推論させるなのか、
コード実行するなのか、
何か計画、目標を達成するために行う具体的な行動を
実行するというのが一つのコンポーネントだと思うんですけど、
一つのコンポーネントの中で、
計画、目標を達成するために行う具体的な行動を、
それを実行するコンポーネントだったりとか、
外部ツールみたいなところとか、
よくLLMエージェントの能力、経過を拡張するみたいな、
賢った言い方をするとそういう感じになるかなと思いますが、
シンプルにWeb検索ツールを実行できるような能力を与えますとか、
実行しますとか、そういうコンポーネントかなって感じですね。
ざっくりこれちょっと今、
2人の中で画面共有しながらにしているので図があるんですけど、
論文の中でざっくりLLMベースエージェントのこういう図があって、
ユーザーリクワイアメントみたいな入力を受け取って、
プランニングとメモリーというのがコントロールする、
いわゆるブレインだったりとかの脳の扱いですね、
みたいなところの役割で、
パーセプションっていうコンポーネントを通じて、
外界からのインプットだったりとかを受け取って、
アクションというコンポーネントで、
外部ツールみたいなものを通じて、
外の世界でやり取りするみたいなコンポーネント、
アーキテクチャーズっぽいものが書かれていて、
個人的にはこれはめちゃくちゃヘキサゴナルアーキテクチャーっぽいというか、
ヘキサゴナルアーキテクチャーのポートとアダプターみたいだなって思いながら見てました。
すみません、いきなり戻すんですけど、
このあたりに何か質問とか気になることとかあったりします?
マルチエージェントシステムと協調
これはプランニングの質問とかじゃなくて、
突然なんですけど、
プランニングとかは、
なんだろうな、
うまくいくと楽しいですよね。
例えばPowerApplicyとか使ってると、
あれ結構順番に何やってるか表示してくれるんですけど、
ああいうのを眺めてると、
ちゃんと頑張ってるんだなと同時にね、
この辺はそうですね、
と同時にここが分岐点とかすごい多くなるだろうから、
自分が実際にプロダクトとして出すのになると、
評価というか上げてるかなっていうのを検証するのが大変そうだなというか、
そういう気持ちですね。
そうですね。
エージェンティックなプロダクトとかは、
どう考えても真面目に作ったら、
いろいろ大変だろうなって気がしますね、
いろんなところで。
作ってて楽しいですけどね、これは。
そうですね。
そういう会社がどうやってるのかちょっと気になる。
確かに。
それはまた別の回に取り上げたいですね。
はい。
次行っちゃうと、
ざっくりLMベースエージェントの概要とか仕様コンポーネントみたいなところとかの話をした後、
その中でもちょっとアドバンスドLMベースエージェントシステム、
ちょっと高度なものとして2つ代表に挙げられていて、
それがマルチエージェントシステムとヒューマンエージェントコーディネーションですと、
マルチエージェントシステムは、
いわゆる複数のエージェント同士で連携して、
より複雑なタスクを倒すだったりとか、
よく事例として見る例だと、
各エージェントごとに役割だったりとか、
専門知識だったりとか、
プロトコルみたいなのが割り当てられていて、
それぞれがそれぞれの役割に沿ってタスクをこなすだったりとか、
連携して何か目標に向かって行動するみたいなところです。
という説明になるかなと思っています。
マルチエージェントとかは、
結構まとめられ方として、
具体の論文名とか研究名とかもちゃんと見れてないんですけど、
パターンとして、
マルチエージェントといえども、
連携の仕方の中に、
協調するか競争するかみたいな区分けとかされていて、
協調とかは目標、ゴールは一緒で、
異なるサブスタスクとかも一緒に、
共同しますってやつですね。
競争っていうのは、
競わせて一番評価高いやつ、
いいアウトプットを出してきたエージェントの出力を採用するみたいな、
競争させるみたいな。
マルチエージェントといっても、
協調と競争みたいなところの区分というか分類みたいなのは、
既存研究とかでありそうっていうところ。
あとエージェント間のコミュニケーションとかも、
名前とは忘れしましたが、
いわゆる要件定義書みたいな形式を決めて、
それでやり取りするみたいな例もあるし、
これも名前全く忘れたんですけど、
ソフトエンジニアリングの世界でいう、
パブサブメッセージとかでやり取りするに近いようなやつで、
やり取りする例だったりとかもあって、
それとさっき言った役割ごとに、
例えば期待値とか出力形式みたいなのを、
逆に決めちゃって否定されている、
プロトコルを組むみたいなものだったりとかもあって、
この辺のエージェント間のコミュニケーションと、
どうエージェント間を連携させるかみたいなのは、
結構幅がありそうだなという印象ですね。
ヒューマンエージェントコーディネーション
Human Agentはめちゃくちゃ雑に言うと、
Human in the Loopが組み込まれたやつですね、
っていう感じですね。
この辺とか、これもさっきから全部名前忘れてメモするの、
おこざったので、
名前忘れたばっかりで連呼してるんですけど、
AIが人間に報酬を払う、
ワークフローサービスみたいなコンセプトのものとかもあったりするので、
そういう形のHuman in the Loopの
Human Agentコーディネーションみたいなのも、
なんか確かに登場しつつはあるので、
個人的にはめちゃくちゃ、
実世界で使うかどうかさておき、
SFっぽくはあって、好きだなっていうサービスだなって感じですね。
これHuman Agentコーディネーション、
実例としてはGitHubコパイロットワークスペースみたいな、
順々にAIが仕事をこなしていって、
人間がチェックするみたいな、
ああいうのはHuman Agentコーディネーションで、
という分類であってそうな感じですかね。
あれはそうですね、
Human Agentコーディネーションじゃないんですか。
それでいうと、
カーソルとかもこっちの分類だと思いますし、
確かに。
これって多分、
マルチエージェントとHuman Agentって、
両方成り立つ、
アンドで成り立つものだとは思いますし、
それこそ、
よくある、
あるじゃないですか、
さっきのプランニングみたいなやつとかも、
オーケストレーター的なエージェントがいて、
そこがタスクばらして、
各サブエージェントみたいなところとかに、
支配するみたいなアーキテクチャとかもあると思うので、
それとかは、
ユーザーから見たときには、
意識されないかもしれないが、
裏的にはマルチエージェントのシステムで、
Human Agentコラボレーション、
人間からフィードバックもらって、
またっていうところの役割で、
そこのオーケストレーターが担ってるみたいな、
立てつけなんだろうなとは思いますね。
マルチエージェントって聞いたときに、
全部エージェントたちが、
自律的な動きをするやつと、
勝手にイメージしてたけど、
確かにANDで成り立つし、
あとそういう階層的なマルチエージェントも、
確かにあるな。
なるほどな。
そうですね。
自分はそっちの認識ですけど、
論文とか読んだりとか、
自分の認識感なので、
実は違う何かがあるかもしれないか、
そんな認識ですね。
それでいうと、マルチエージェントは、
未来はAIエージェントとか、
LMエージェントみたいなのが、
これから世界プロダクトとして出てくる中で、
基本はマルチエージェントみたいなアプローチとかは、
一定求められるんだろうなって気がしますね。
性能を上げるためとか、
考えると。
そんな感じですね。
あとこれもちょうど、
別に話変わりますけど、
Reflectionのモデル触りました?
話題の。
触ってはいないですけど、
いろいろニュースになってて、
楽しいなという感じではありましたが。
そうですね。
完全に同じノリで、
いろんな記事とか、
Xとか追ってるだけなんですけど、
ちょうどReflectionは、
昔からReflectionって、
普通に有用だよねってなってるとか、
それこそ、
エージェンティックデザインパターンみたいなやつとかの中でも、
Reflection自体は含まれてはいるので、
別に誤発の概念ではないじゃないですけど、
ちょうど話題になってたので、
話題になってたのと、
論文内でもReflectionの話をしてたので、
Reflectionとかフィードバック周りとか、
について書かれてたところを紹介すると、
前提フィードバックとかReflectionっていうものは、
出力、性能を上げるっていう意味では、
重要ですよねとしたので、
種類を4つぐらいに分類してます、
論文内で。
その4つが、
モデルフィードバック、
ツールフィードバック、
あとは人間によるフィードバックと、
ハイブリッドフィードバックみたいな形になってて、
モデルフィードバック、
1個目のモデルフィードバックは、
さらに2つに分類されて、
セルフリフレクションみたいな、
多分マルチエージェントっていうよりかは、
シングルエージェントだったりとか単一モデルで、
リフレクションみたいなのを挟むみたいなことをやる、
みたいなパターンとか、
あとは複数のモデル間でリフレクションするとか、
マルチエージェント的な、
そういうリフレクションとかフィードバックを与えるような、
役割のエージェントがいるみたいな形式だと思いますが、
ピアリフレクションみたいな、
そういうのがあるよねって話だったりだとか、
ツールによるフィードバックでも、
コンパイラーとかいったアプリとか、
実行エンジンを呼び出して、
それをフィードバックする、
動的実行ツールによるフィードバックとか、
性的解析ツールを使ったフィードバックとか、
検索ツールとか検索エンジンとか、
フィードバックの多様性とプランニング
ラグ的なことをしてフィードバックする検索ツールとか、
そういうパターンがあるよねって話とか、
あとはシンプルに人間がフィードバックするとか、
複数の種類のフィードバックをするとか、
いろんな感じのフィードバックのパターンを分類して、
そうな感じでした。
我々が日々開発している中で受けているフィードバックと、
一緒な気も感じもするな。
そうですね。モデルフィードバックともかく、
これはソフトウェアエンジニアリングの例なので、
ツールの例とかも性的解析ツールとか、
性的検索ツールとかでしたけど、
一緒っちゃ一緒かもしれないですね。
続いてここから、
もうちょっとソフトウェアエンジニアリングの、
応用例的な研究の紹介をするんですが、
これもだいぶ長くなるので、
領域とか事例もだいぶ破損で紹介すると、
ここはわかりやすくコードジェネレーション、
コード生成とかはめちゃくちゃ既存研究もあるので、
いろいろめちゃくちゃまとめられてました。
コード生成とかやってる既存のエージェントの論文とか、
どういう手法が採用されてるんだっけ、
みたいなのをざっくり見ていくと、
いわゆるChain of Thoughtみたいなところで、
プランニングだったりとか、
コード生成タスクをサブタスクに分解する、
コードCOTみたいなやつだったりとか、
あとはプランニングするときに、
リポジトリ内の影響を受けるコードとか、
スニペットみたいなのを探し出して、
それを踏まえて、
もうちょっとコードのプランニングとかをできるように、
頑張ってるコードプランみたいなやつがあったりとか、
そこのプランニングのところ、
結構プランニングのところを工夫してるやつが多くて、
擬似コードとか中間コードとか、
コードスケルトンってこれ何なのかよく分かってないですけど、
そういうようないろんな表現を提案するみたいな研究があったりとか、
ここでエージェントコーダーとかは、
まさしくこれが擬似コードを作って、
その後最終的なコードを、
実コードを書くみたいなところのステップ踏んで、
結構コード生成系とかは専用ソフトだったりとか、
プランニングちょっとコードにやるとか、
やらないとなかなかエラー無しでパッと出すとか難しいんだろうなって、
いろいろ見てて思いましたね。
コードエージェントの役割
そうですね。
このコードプランの影響範囲とかを考慮してくれるのは、
やってくれるとめちゃくちゃありがたいですね、これ。
そうですね。これどうやってやってるんだろうな。
そこまで覚えてないんですけど。
これできたら、普通に既存のコードを回収するとか、
コードリーディングとか、よくあるだろうな、
ここ触ったらここも影響を受けましたみたいなやつとか、
最近コンバイル型原稿とかやってるとなかなかないのかもしれないが、
検知できる例とかは。
そういうのできると、コード生成よりも個人的にはそっちできるほうが、
実業務的にはインパクト強そうだなって気はなくもないですね。
自社サービスとかやってると。
そうですね。
コードのコードプランとかどうだろうな、
めちゃくちゃ愚直にコードのインポートとかをひたすらたどってったりとかしながら、
関連するところとかを探してそうな気配がする。
今ずっと見た感じ。
コード生成とかは、
もし自分がプランニングとかコードのやつとかを探そうとするんだったら、
一回このコードジェネレーションの例とかを見にいこうかなって、
なんとなく思いました。
他の要例で言うと、
コードレビューとかは、
確かにありますよねって話で、
コードエージェントとか、
ラシッドってやつとか、
これ、これなのかな。
ちらほら聞いたこと、聞き覚えあるなみたいなやつがいろいろ並んでいて、
コードエージェントとかは、
いわゆるマルチエージェントで、
CEO、CPO、CTOとかみたいな、
ロール別のエージェントがいて、
コードレビューチームみたいな概念があり、
それぞれのステップごととかに、
それぞれのエージェントとかが、
マクドをして最終的にコードをレビューして、
分析、レポート、回転みたいなこととかをやるみたいなアーキテクチャになっている感じですね。
ここによってはCEOとかいらなそうだけど、
その辺はどうやって?
そうですね、確かに。
これまとめるとき、
あんま気にしてなかったですけど、
コードエージェントでCEOとかCPO、
CPOはまだ分かるけど、
CEOも何かやってるのかな?
分かんない。
一応何かCEOとしてプロダクトに、
何か指摘する役目を受けようってんじゃないですか?
分かんないけど。
逆に分かんなすぎて、
ちょっと使ってみたくなった。
確かに冷静に考えたら、
これ本当かな?
こっちが間違ってるのか、
コードエージェントがうまくCEOに何か影響を与えてるのか、
これ気になりますね。
ちょっと後で読んどこう。
ちょっとまたコードエージェント。
みたいなのとか、
あとは逆にあれですね、
コードレビューっていう概念の中で、
コードレビューするエージェント、
コード最適化するエージェント、
コードスメルみたいなのあるじゃないですか。
その保守性とか、
あの辺のコードスメルみたいな言い方するじゃないですか。
それを検知するエージェント、
あとバグレポートがエージェントみたいなのを、
この4つのエージェントが、
各々の役割ごとにレビュータスクをこなしますみたいな。
そういうものとかもあったりしますね。
あとは、
はいはい。
すいません、どうぞ。
レビューもそうなんですけど、
レビューだけじゃなくて、
リファクタリングすべき箇所みたいなものを、
勝手にデポジトリ解析して、
やってくれるエージェントいてほしいな、
みたいなのを考えてたことがあるんですけど、
これプルリクベースではあると思うんですけど、
多分そういうのにもつながりそうなことを
やってくれそうだから、
ちょっと期待したいですね、この辺。
リファクター確かにやらせたいが、
どうなんだろう。
自分がそんなにちゃんとプロンプトとか、
がっつり組み込んでやってないだけの可能性は高いですけど、
リファクタリングさせてめちゃくちゃいいコード書くかって言われると、
結構先長いなって感じはするので、
正直、LLMがパッとファイル分割とかさせたりとかしても、
そんなめちゃくちゃいいコードを仕上げてくるイメージはないんですよね。
保守性とか、命名だったりとか、
設計もちゃんと切れてるかみたいなところで言うと、
それとかもきっちりプロンプトなりラグなりとか
いろいろ仕込んで、
頑張れば確かに動きそうな気はする、
が、絶妙にちょっとセンスなさげだなみたいなコードを仕上げてきたりとか、
テストコードを生成したりすることの方が多い印象はある。
結構広範囲にまたがる系だと。
そういうプロンプトとかをがっつりやってるわけじゃないけど、
ドメイン層とかアプリケーション層、ユースケース層とか、
あの辺の責務とかはやっぱり、
ちょっと絶妙に、これはこっちかなみたいなやつとか買ったりするんで、
ドメインとかは、
ドメインもユースケースもケースバイケースというか、
そこのプロダクトドメイン主体だからむずいっちゃむずいわ。
むずいんですけど、
確かにちょっとその辺作り込んでやってみたことはないので、
アーキテクチャーとかコードの、
綺麗さにこだわりがある人、企業に向けても、
通じるリファクターエージェントが作れるのかどうかみたいなのは、
やりたい気もするが、コスパ悪いというか、
それやるよりもっとシンプルにゼロイチというか、
今後の研究方向性
AIエージェントならではの登り方がありそうだなって気もするな。
コードレビューは結構そんな感じ。
マルチエージェントとか多くて、
放送で面白かったなっていうのと、
あとはユニットテストとかテスティングのやつとか、
いろいろありますねっていうところと、
あとはシステムテストみたいなところもあって、
いわゆるGUIとか、
E2Eとかって呼べるような分類のものの、
研究をまとめたカテゴリーみたいなもので、
個人的にはこのRESTful APIの使用を自動的に推論し、
普通確認みたいなテスト、E2Eテストを勝手にやりますみたいなものとかは、
確かにできるだろうなと思いつつ、
OpenAIのスキーマとか見たら、
セータスコード200をチェックするぐらいは別に勝手にできそうだから、
何がLLMで進化した部分なんだろうなみたいなのはちょっと気になりました。
読んでないけど。
おだしょー APIのスキーマから言えば。
そういうそんな感じ。
テスト系とかは確かにやらせたいよなって感じですね。
そういう応用例とか他にもいろいろと、
他のカテゴリーとかもあるんですけど、
そういうカテゴリーごとに、
いろいろ既存研究とか、
こういう特色を持ったやつですよ、
みたいなのを結構まとめてくれるので、
いろいろ概要を知る上では、
いいなって感じがしました。
最後、今後の研究とか進化の方向性みたいな話とかざっくり書いてて、
言ってたことは、
割と評価フレームワークとかベンチマークとか、
足りてないよねとか、
十分じゃないよねっていう話とかはしていて、
あとは堅牢性セキュリティとか、
その辺の信頼性の側面が、
なかなか考慮するの難しいですよね、
みたいな話とかもされていました。
確かにG2プロダクトとか、
ウィニオフェーズみたいに載ったプロダクトで使うとか、
そこのコードみたいなので考えると、
ちょっとインフラとかデータベースに話は寄りますが、
タイルアクセスとか大規模データにどれだけ耐えられるかだったりとか、
ビジネス要件の変化に柔軟に耐えられる確証性があるかとか、
そっちのほうが特に運用みたいなところにいくと、
ソフトウェアエンジニアリング的には多分難易度高い領域ではあるので、
その辺どんだけこなせるんだっけ、
その辺の能力とかどう測るんだっけみたいなのは、
リベンチとかは確かにそれで足りるのかって言われると、
あとヒューマンイーバルでしたっけ、
とかは確かに足りない点はありそうだなって気はしますと、
あとは人間とエージェントの協調みたいな、
ヒューマンインザループみたいな話とかで言うと、
わりと要件みたいなのを定義するところだったりとか、
核みたいなところとかコード生成みたいなところとかに、
エージェントのそもそもの活用だったりとか、
人間とのコラボレーションみたいなのが限定されているので、
いわゆるアーキテクチャ設計とかテストとかメンテナンスみたいな、
他のフェーズへの関与も重要だよねみたいな話をしていて、
そうやって設計とかテストとかメンテナンスとか運用とか、
より重要なフェーズに特化したエージェントシステムがまだ不足していて、
これらのフェーズの方が推論能力とか理解力みたいなのが、
より高度だったりとか深いものが求められるので、
ちょっと今までのLinuxベースのエージェントでは不十分なのだろうが、
今後に期待だねみたいな話とかを最後にしてました。
LMベースエージェントの活用
だいぶ端折ったというか、だいぶ独断と偏見で端折ったりしましたが、
ざっくりまとめると、いわゆるLMベースエージェントっていうものの、
特にソフトウェアエンジニアリング領域でどのように活用されているかとか、
どういうようなパターンのものとかがあるかみたいなのをサーベイ、
調査してくれてまとめてくれたサーベイ論文で、
コード生成だったりとかテストだったりとか、
みたいなそれぞれのカテリーごととかに、
どういう緊急とかエージェントの緊急があるかみたいなのをいろいろまとめてくれて、
その上で今後マルチエージェントシステムとか、
人間とエージェントの共同みたいなものだったりとか、
より違うフェーズステップでのLMの活用とかが求められますよね、
みたいな感じの話をしている論文でした。
人間とエージェントの協調
ありがとうございます。
めっちゃ逸れた感想かもしれないんですけど、
人間とエージェントの協調みたいなところで、
人間が結構ちゃんと要求を明確に伝えるとか、
要求と一緒か、受け入れ条件であったりとか、
そういうのを言語化する能力みたいなものが、
重要になってきている感があるんですけど、
同時にエージェントにも、
もうちょっと具体的にした方がいいところがあったら聞いてきてほしいなとか、
そういうことをしてくれるエージェントが来たら面白そうだなとか、
そういうのをたまに考えたりしてますね。
そうですよね。
要するに目標とか達成したい何かがあって、
それをこなすために必要なコンテキストを、
もうちょい能動的に収集しにくるみたいなことだとは思うんですけど、
確かにCursorとかもあれだけコードを書けるんだったら、
ここのコードいけてないから、
リファクタリングしたほうがいいよって勝手に教えてほしいな、
みたいな気持ちになったりしますね。
テストとかね、この辺抜けてますよとか、
ここよくある境界値とか、
抜けてるけど大丈夫ですかみたいなやつとか、
スレッドセーフじゃなくないですか、このコードとかね。
そういう、ここまで来たらめちゃくちゃ楽しそうだな。
なんかでも別に聞いたら多分教えてくれるじゃないですか、ある程度はきっと。
そうですね。
だから別にあとは作り込みみたいな話だったりとか、
どういう体験するかみたいな話なんだと思いますけど、
話ってあれだな、
よくある規模大きくなってた時にある、
ナイーブに配列回してるとめちゃくちゃ重くなるよね、計算業みたいなやつ。
あの辺とか自分たちのデータベースの平均データ量みたいなやつから、
これぐらいかかっちゃうよ、もっとこういう書き方にしたほうがいいんじゃない、
みたいなやつとかを指摘してほしいなっていう気がしてきた。
なんかKotlinだとちょこちょこある、
なんだっけな、マップの代わりみたいなやつ。
こっちのこういうふうにやったほうが、
シーケンシャルだかシークエンスみたいなの使ったほうが、
この場合はパフォーマンス良いよねとか、
あの辺とかちょっと教えてくれると、
さらにソフトウェアエンジニアとしての私の知識の必要性がなくなっていくなっていう話でめちゃくちゃ思いました。
こういう能動性のある体験、面白そうだと思いつつ、
多分あれなんだろうな、勝手にAPIコール走らせちゃうから、
なんかその辺もちょっとネックに行ったりとか。
そうですね、結局なんかその辺とかは、
僕は前職ID連携とかやってたので、
多少その認証認可とか特に認可のほうですけど、
前職でやってましたけど、
今度はそこのAIエージェントの権限じゃないですけど、
全部勝手に能動的にされて結構、
結構セキュアに守りたいものとかにバンバンアクセスされても困るし、
毎回ヒューマンインターループで承認とか求められても、
まともな体験にならんそうだし、
その辺とかはまたちょっと後の世界でいろいろと揉まれる余地はありそうですね。
あります?さやさん的には。
エージェントもあれで他に話しておきたいかと。
そうだな、もはやエージェントの話じゃないんですけど、
なんていうか、結構このエージェントとかカーサーも、
冒頭の話にちょっと戻るんですけど、
最近カーソルでタブポチポチしてると、
なんていうか、
なんかそれで動いたら中のコードそこ何読んでなくても、
なんかいいかなみたいな、
ちゃんとそういう場面が、
そんな複雑なコードじゃなかったらいいんですけど、
なんていうか、初見で使うものであったりとか、
ちょっとうまく言語化できないんですけど、
そこはかとなくちゃんとコード読んで、
理解してアクセプトしないとなっていう、
その辺の働き方に関する影響とかもちょっと最近感じたりしてます。
カーソルが出してくれるコードを全部アクセプトするだけだったら、
最初っから人間がいない開発プロセスを頑張って組めばいいんじゃないかな、
みたいな気がなりますね。
カーソルとかね、
プライベートなやつとか書き捨てみたいなやつとかあったら別にいいんですけど、
プロダクション用してるやつとかだと、
カーソルのコンポーザーとか、
あれよりかは、
ちゃんとある程度確認してアクセプトしたいから、
普通に右側のチャット欄のやつだけ使うとか。
深く考えての行動じゃないですけど、
そんな感じに結局落ち着いてる気はしますね。
あとなんだろうな、そんな感じかな。
個人的には、
コード生成とかは結構それなりにいい感じなのは分かったので、
コードリーディングとか、
影響調査的なところとかにこそ頑張ってほしいな、
みたいな気持ちはあるので、
雰囲気で適当に話しますけど、
この機能のこの仕様を変更すると、
別のこういう事象不具合が発生しそうですよ、
みたいなやつとか、
さっきの計算業的に怪しくないですか、
みたいなやつだったりとか、
昔アリババだかどこかが、
クラウドの障害調査とかレポートとかを、
自動でやるみたいなエージェントとか、
これかな、RCエージェント、
クラウドルートコーズアナリシスバイ、
オートナマスエージェントビズ、
ツールオーギュメンティブラージュラウン限定モデルみたいな、
みたいなの出してたりとかしてて、
そういう系とかにLMエージェントとかが入ってきてくれるようになると、
より我々の仕事的には、
結構いろいろと働き方変わりそうだなって気がするので、
その日を楽しみにしてはいるんですが、
僕個人の関心としては、
システム生成とかコード生成以外のエージェントを
作りたいなって気持ちのほうが強いので、
みんな早く作ってくれないかなっていう多席の気持ちで、
いただいて待ってます。
そうですね。
そんな感じかな。
他ありますか、さやさん、話し足りないこと。
いや、大丈夫です。
じゃあ、今回は、
ラージランゲッジモデルベースと、
エージェントソフトエンジニアリングサーベイ、
というソフトエンジニアリング領域における、
論文について話しました。
ご清聴ありがとうございました。
ありがとうございました。
