AI Agent 勉強会【初参加歓迎】1.5時間でAIエージェントを導入レベルまでキャッチアップ！というAlmondo社主催の勉強会に参加してきました
私は地方出身の田舎育ちだったのでこういった勉強会に対面で参加できる機会はほとんどありませんでした。社会人として都会に来てからこういった勉強会に参加できるようになったのでなんの知識もないですが勇気を出して参加してみました。猛者たちが勢ぞろいでとても勉強になりました。
勉強会では3人の方が登壇していました。正直自分には半分くらいしか理解できませんでしたが、調べながらまとめてみました。
エージェントのコンテキスト管理手法
まず、一つ目は寺尾 拓さんの発表です。
内容
エージェントにおいていかにコンテキストが大切でああるか、そしてコンテキストの管理方法について解説していました。
エージェントに長いタスクを任せると使い物にならなくなるのはコンテキストウィンドウを消費してだんだん動かなくなる。100Kトークンを超えると多くのLLMモデルでパフォーマンスが低下するようです。20万字～25万字くらいらしいです。そして、Tokenによって課金されるためお金がかさみます。
中間削除
ReAct1~4があったとしたらそのうちの一つを削除します。
実装コストが安いですが、ハルシネーションを起こす確率がほかの手法より高いそうです。まずはここから始めるがよいといわれていましたが、うまくいくかは運しだいらしいです。不要な物を削除するのではなく、適当に消すらしいので重要な部分を削除してしまう可能性があるからです。
記憶を圧縮する
ReAct1~4があるとするとReAct1~4の要約することでコンテキストウィンドを節約する手法です。精度が下がりにくく、ノイズが削除されます。自分はこれを聞いたときにとても納得感がありましたが、悪い点としては要約を作る時間、正確な出典の明示が難しくなるみたいです。ついでに、疑問に思ったのですが要約を作るのもAIにやらせるということなんでしょうか？それなら、コンテキストウィンドは分けたら節約はできると思いますが、お金はかかりそうだなと思いました。実際はどうなんでしょうか。
外部記憶に格納する
ReAct1~4があるとしたら、各ReActの要約(memoに近い)ものはコンテキストウィンド内に保持して、具体的な内容は外部に記憶させておく手法です。そして、必要に応じてLLMが外部記憶から思い出すということです。やってることが完全に人間です。人間も覚えきれないし、一度に大量の情報を処理しきれないからメモを取ります。
これは、精度が下がりにくく、ノイズが除去されて、トレーサビリティが高いそうです。
悪い点としては、うまく使いこなすにはLLMチューニングが必要、「思い出す」ための追加推論コストがかかり、実装が難しいところだそうです。
コンテキスト管理の実践
ここで実際にあるモデルを取り上げてどんな手法がとられているのか実例を語られていました。AIエージェンの勉強をするときはこうしてどのモデルがどんな手法をとっているのか調べることがよいそうです。こちらに関してぜひ資料を読まれてください。
まとめ
大きく分けると、中間削除、記憶圧縮、外部記憶の3種類があり、様々なバリエーションがあるので銀の弾丸はないそうです。
実践AIエージェント導入記 – AIスタートアップの会社のリアルな活用事例
次に、2つ目は森本尊礼さんの発表です。
爆速要件定義
AI駆動開発では設計が大切である。PO・PdMとして仕様書を書きます。ここで、その仕様書をGithubで管理するためにGithubをNotion化します。novel-vscodeという拡張機能を使います。これを使ってGithubの仕様書を書いているのでエンジニアがそれを見て、バンバンプルリクエストを送ってくるそうです。かなりいかついですね。おかげで開発生産性は上がった故の課題としてレビュー、テストが大変だったそうです。ここも、LLMにレビューさせたりとかなり活用しているみたいでした。ただ、LLMの出力が正しかどうか判断することが難しかったそうです。
ADMで爆速PR TIME
ADMとはAI Droven Managementのことだそうです。人間が用意した情報をもとにLLMを動かして開発をすすることを指している？らしいです。ここら辺はメモを取りきれず、情報としてあやしいです。会議の元データやすべての社内のデータをGithubで管理してそれを使ってLLMが出力する。人間はLLMが使うための情報を集めるだけになると話されていて、私も最近NotebookLMを使うためにせっせこドキュメントにまとめていたので、なにか確信を突かれた気がしました。Markdownとの相性がAI良いそうなので最近はVsCodeを使ってMarkdownでメモを取っています。シンプルでドキュメントで取るよりもやりやすいです。
まとめ
AI駆動開発をするために社内情報を一元化してLLMに使わせるということで、これは大きな会社ほど実現が難しそうですが、絶大な効果を生みそうだと感じました。また、会社の資料などもGithubで管理されているそうなのでエンジニア以外の人たちもGithubを触るということ？なのか、なかなか大変そうだと感じました。
最後に、森本さんの前職は女装コンカフェだそうです。最初の自己紹介の時に言われていたのでその話が気になって内容に集中しきれませんでした。
自立型AIエージェントを活用したUI設計 ~ フロント自動化
最後に、北見 海貴さんの発表です。
UIデザイン生成ツールの難点
チャットごとにコードベースが独立してしまう。同じアプリを作るためには1つのチャットで場額作業しなくてはいけなくなるが、コンテキストウィンドの範囲を超えると精度が落ちてしまう。v0やLovableなどのUIデザイン生成ツールは何画面もあるようなシステム開発には不向き。
「コードでデザインを生成する」という体験を保ちつつ、Cursor上でUIデザインの構築・運用管理を子なう方法
課題
Cursorで好き放題に画面を量産すると、リポジトリがカオス化しがち
・同じようなコンポーネントが何個も生まれがち
・画面ごとにトンマナ・スタイル
よって、保守が難しくなる。
・同じようなコンポーネントが何個も生まれがち
→shadcn/uiを用いることで解決
・画面ごとにトンマナ・スタイル
→Storybookを用いることで解決
上記ライブラリを用いた「制約」を設けることで、AIによる生成結果をコントロール
shadcn/ui
Tailwind CSS × Radix UIのOSSコンポーネント集
npm依存ではなく、CLI経由でソースをリポジトリに生成してくれるので、コードが隠蔽されず生成AIとの相性〇
global.cssにてトークン一括管理を行うため、スタイリングの一括管理が容易に可能
Stroybook
コンポーネントや画面をブラウザで確認できるUIカタログツール
コンポーネントごとにユーザーが定義した状態の確認が可能
開発中のコンポーネントをブラウジング可能
UIデザイン・フロントエンド開発の流れ
1.Cursor上でshadcn/uiを使ってUIIデザイン/画面の実装を進める
2.Curosor上でデザインシステムを構築し、実装した画面に一括で適用
3.生成されたUIデザインの一貫性をStorybook上で確認
まとめ
私も実際にアプリ開発をしていたときチャットによってスタイルが変わって修正が必要になるので、自分でやったほうが早くないかと思う時がありました。それが、今ではこういった手法ではスピードを保ちつつ一貫性を保ちつつ保守性も高くなる手法があるということで驚きました。詳しくは、記事を書いているそうなので1度を通してみてください。
正直、当日聞いてるときは何を言ってるのかさっぱりわからんという感じでした。こうして記事にまとめる口実で復習することでやっとわかってきたということです。地方出身ということでこういった会にやっと参加できてとても強い刺激を受けました。これからもこういった会に足を運んでいきたいです。
学び
ここからは、自分がわからなかった単語とかをまとめていますので、あまり気になさらないでください。
コンテキストウィンドウ：AIが1度に理解・処理できる情報の範囲を意味しているようです。また、コンテキストウィンドはTokenという単位で計測されます。
次に、コンテキストウィンドウの範囲の中にはシステムプロンプト→入力→ReActの流れがあり、この「ReAct」が何を指しているのかわかりませんでした。これは推論（Reasoning）しながら、行動（Acting）することを「ReAct」と呼ぶみたいです。ようするに出力ととらえて大丈夫なんですかね？
トレーサビリティ：軽く調べてみた感じでは、あまり要領を得ることはできませんでした。
トンマナ：トーン（Tone）＆マナー（Manner） の略で、表現の一貫性や雰囲気を整えるためのルールや方向性を指します。
最後に
この勉強には先輩である@shinkaaaaiさんに 同期の@moyomoyomoyo と連れて行っていただく形で参加しました。最後のMeetupでは先輩についていくだけであんまり自ら行動することはできず自分のコミュニケーション力のなさに悲しくなりました。まずは、コミュニケーションの力をつけるところからです。
Views: 0
