00:07
michiru_da
マヂカル.fmは関西人のプロダクトマネージャーみちるだと関西人(?)のソフトAI事業のオパミューンが週2で配信する雑談ポッドキャストです。
お願いします。
うぱ / upamune
お願いします。
AIエージェントの概要
michiru_da
今日のテーマは、現場で活用するためのAIエージェント実践入門を読んでいるよ後半。
前回も、かの有名なAIエージェント本、緑と青の表紙のやつをみちるだが3章半ぐらい読んだよって話をしてまして、
1章と2章が非エンジニアでも結構わかりやすいAIエージェントの概要説明というところになっておりましたので、
ちょっと内容をサマライズしつつ、気になったところをおっぱさんに聞く回をやっていました。
45分ぐらい喋ったんですけど、1章ぐらいしか終わらなかったので、残りの2章は今から喋ろう。
なんでちょっとAIエージェントとは何ぞ、みたいな人とかはちょっと前回から言ってください。
1章はかなり騒論な感じだったんですけど、1章のところでも話したツールを呼ぶみたいな、
かなり具体でAIエージェントを使っていくためにしておいた方がいいこと、みたいなのが2章にはいっぱい書いてあります。
2章にもAIエージェントの内部構成みたいな図があって、真ん中にLLMがいて、
メモリー、自己修正、計画、プロフィール、行動地格、みたいなものとLLMがつながっていて、
その周りの外部の環境、APIとかいろんなデータとかブラウザとかとやり取りしながらタスクを進めるよ、
みたいなことが図で書いてあります。
この章は順番にプロフィールとは何ですか、みたいなこととかを説明してくれていて、
プロフィールはLLMにセッティングする役割みたいなやつですね。
あなたはベテランのケリー担当者です、みたいなこととかを言うと、
ケリーの人が気になる、気にするようなコートとかを注意しながら動いてくれるみたいな、
明るい計画で振る舞ってください、みたいなことで明るい応答をしてくれるみたいな感じです。
自分もそういうのがあるとか、あなたはこういう役割ですっていうのを設定することでアウトプットの精度が上がるみたいなのは聞いたことがあったんですけど、
このプロフィールの部分もエージェント的に、メモリを参照してどんどんプロフィールのところも更新するような、
思考や知識を参照するエージェントワークフロー型のプロフィールを使ったエージェントも増えているよ、みたいな話があって、
それはへーってなりました。
メモリーの重要性
michiru_da
たぶん別に経理担当者ぐらいとかだったらそんなに困らないんですけど、
うぱ / upamune
なんかその実在の歴史の人物になりきってくださいとかだと、どんどん汚染されちゃったりするのかな。
michiru_da
なので、たぶん同じ役割を維持し続けるためには、
たぶんそのメモリとかを使って、ちゃんとキャラクターとか設定したパルソナの背景を新しく更新し続ける方がいいですよ、みたいな話が書いてあって、なるほどと思いました。
ここはそっかって感じですかね。
うぱ / upamune
まあ確かに、めっちゃ長い会話してたら忘れて、忘れて全然違う人として振る舞ってる。
michiru_da
自分が何者か忘れちゃう。
うぱ / upamune
悲しい。
michiru_da
悲しい。
うぱ / upamune
メモリーいきなり出てきた気がするんだけど。
michiru_da
確かに。そうね、メモリーも未知数だわからないことの1個であるんだよな。
うぱ / upamune
メモリーめっちゃ大事ですよね、たぶん。メモリーの章あります。
michiru_da
メモリーとは何だ。
メモリーはLLMにインプットする情報を別で保持しとくやつみたいなイメージですね。
LLM、コンテキスト帳みたいな、何トークンまでしか入れれないよ、みたいなことがあると思うんですけど、
LLMに一度にインプットできる情報量って限られているので、
限られているし、たぶん長いコンテキストを渡しても全部読み取ってくれたら限らないみたいなことがあるので、
例えばエージェントが過去にやったアクションとか、
行ってきた応答とかをメモリーっていうものに別に置いておいて、
それを適宜参照させることでタスクの成功率とかが上がるみたいな感じのやつ。
うぱ / upamune
今ってChatGPTとかも話し続けるともう無理みたいになるんですかね。
michiru_da
確かにもういっぱいだよみたいな。
うぱ / upamune
なるんですかね。
そもそも普通の人からしたら話せる長さに制限あるんだみたいな、コンテキスト帳。
そうなんですよね。結構短いんですよ。
michiru_da
そうなんだ。GPTが話せなくなるのはコンテキスト帳がいっぱいになるからなんですね。
うぱ / upamune
ChatGPTがどうハンドリングしてるのか知らないですけど、いろんな手法がありますね。
michiru_da
なんかそのChatGPT最初に出たときって、
同じ話は同じチャット上でしておくと過去に話してないのに引き継いでくれるよみたいなのがあったけど、
最近ってもうそのどのスレか関係なく自分の会話ってめっちゃ引き継がれてるじゃないですか。
あるいはそのメモリがめっちゃデカなったみたいな。横断してメモリを持ってるみたいな。
うぱ / upamune
そうですね。ChatGPTでメモリを持ってるっていう感じですね。
michiru_da
なるほど。
なんかこれ理論上わかるんですけど、メモリとコンテキストの使い分けって何みたいな。
メモリも結局コンテキストな気がするんですけど、
LLMに明示的にインプットするやつとメモリに置いとくやつがあると思うんですけど、どういう違い?
うぱ / upamune
それはなんかあるじゃないですか。プロンプトっていつも乗るじゃないですか。
そうなんでコンテキストを圧迫するんですよね。
例えばメモリにみちるださんが前に私の好きな朝食はリンゴヨーグルト覚えといてって言ったときに、
毎回別の会話するときにみちるだの好きな朝食はリンゴヨーグルトって載ってたら無駄すぎません?
なんでみちるださんが朝食の話とか私の好きな朝食をAmazonで頼んどいてとか言ったときに、
みちるだの好きな朝食、メモリから検索して朝食リンゴヨーグルトじゃんってなったほうがいいですよね。
michiru_da
なるほど。じゃあいつも参照するものじゃないんだメモリは。
うぱ / upamune
メモリはツールとかと同じで、欲しくなったらとか。
michiru_da
へー、なるほど。それもLLMが自律的に判断もするし、こっちから指定もできる感じ?
そうなんだ。メモリに何を保存するかって指定が必要なんですか?
うぱ / upamune
これメモリのレイヤーをどう設計するか次第だから。
michiru_da
レイヤーって難しい言葉ですよね。
うぱ / upamune
ただの層、層です。
michiru_da
でもなんかシステム用語でレイヤーってあるじゃないですか。
うぱ / upamune
そう。ミルフィーユみたいになってるってことですね。
michiru_da
今のはもう汎用的な層の意味のレイヤー。
うぱ / upamune
そうです。それをどう設計するかなんですよね。
例えば、ユーザー単位で分けるのか。
ユーザー単位で分けないと、別に分けなくてもいいときもあると思うんですよ。
ある会社の知識として活用したいみたいな場合と、ある人の単位でやりたいみたいな。
それで時間の概念もありますよね。
毎年出てるような映画で、明日には記憶なくなっちゃうみたいな。
ああいうのも一日単位のメモリだったら、そういうのも実現できるっていうことですね。
michiru_da
なるほど。今日の記憶だけ使えるみたいな。
うぱ / upamune
そうです。前に話した、うちの会社のラグのボットは、メモリのキーにSlackのスレッドの親のタイムスタンプ入れてるんで、Slackの同じスレの中だけのメモリを持っています。
なので、Slackのスレで話したことは覚えてるみたいな。
michiru_da
それ以外は知らない。
そのAIボットを呼び出すときに参照してるメモリは、Slackのスレッドの中身だけっていう。
うぱ / upamune
それを逆にSlackのユーザーIDとかをキーにしたら、別にそのスレッド単位じゃなくても、いろんなところで君はそこであれを聞いてきたね、みたいなのもできる。
michiru_da
確かにそれもどこで区切るかが工夫のしがいがありますね。
うぱ / upamune
そうです。
michiru_da
一旦ちっちゃめの方が安心なのかな。
うぱ / upamune
そうですね。メモリなんか最初からいるのかなっていう気がする。
そうなんだ。
michiru_da
要件次第。
より精度を上げるためにって感じなのか。
メモリもそのコンテキスト帳みたいなMAXがありますか?
うぱ / upamune
ないと思います。
michiru_da
そうなの?
うぱ / upamune
ないと思いますっていうか、これメモリレイヤーは多分どうやって実現するかみたいなのって書かれてました?
AIの実務での活用
michiru_da
先の方に行ったらあるかもしれない。
ここはね結構意味合いしか。何を入れるかとかは書いてあるんですけど。
うぱ / upamune
メモリの保存形式。
michiru_da
これね分かんなかったな。
メモリに保存する形式がテキスト形式とパラメトリック形式があります。
うぱ / upamune
ここではラグの話とかFAQ回答だったらラグをメモリとして使うっていう話。
一番上の01はメモリDBに保存するみたいな話なんで、
そのデータベースって無限に入るんで。
michiru_da
じゃあこれがメモリの保存場所だよっていうのは指定するんだ。
うぱ / upamune
はい、それがないと動かないです。
michiru_da
場所だけ指定すれば勝手に何かをメモリに保存してくれるんですか?
うぱ / upamune
いや、そんな魔法のツールじゃなくてただのツールコールの一種だと思ってるんだけど。
michiru_da
そうなんだ。じゃあメモリにこういうの保存してねっていうのはやっぱり指示しないといけないのか。
それもプログラムなのか。
この本読んでて意外とAIが吉野にやってくれる箇所って少ながちなんだなっていうのも直感と違うところでした。
その前半の決定論的な箇所が多い方がいいよっていうのもそうなんですけど。
うぱ / upamune
そうです。というか業務で使うものはいかにAIを自由にさせないかっていう。
自由にさせすぎるとなんか実感に1回しかちゃんと動かないAIになるんで。
michiru_da
もうレールを敷きまくる。
こっち行かないよって。
そうそうそう。
それでもAI使った方がいいんですか?
うぱ / upamune
もちろん。
michiru_da
そうなんだ。
うぱ / upamune
いわゆる入力がガチっと決まってないと扱えないものが多かったんで。
それは例えばPDFファイルとか投げ込まれたり、これをこの中から金額と取引先とか画像を投げられるとか、
人の入力とか様々な入力に耐えられてその形式も別にどうでもいいみたいな。
michiru_da
入力をフォーマットにしなくて良くなるみたいなのはめっちゃ楽ですからね。
うぱ / upamune
そうですね。なのでメモリもめっちゃ特別なものというよりは、
そのAIが何かを覚えておくために利用するもの。
そのいつ利用してほしいとか何を保存してほしいかは言っといたりする必要があるっていう感じですね。
michiru_da
なるほど。
このメモリをAIが操作するみたいな箇所もあるんですけど、
メモリは書き込み読み取り管理の3つがあって、
書き込むときには要約をして書き込むのが重要だよとか、
逆にメモリから何かを読み取っていくときには、
いい感じに検索をして正しい情報をゲットして、
それを読み込むのが大事だよみたいなことがあるんですけど、
これメモリの読み取りって実質ラグってなったんですけど、
全然違う概念ですか?
うぱ / upamune
メモリの読み取りはラグなときもあります。
さっきの例の話ですね。
普通に、ラグじゃない普通にMySQLとかのデータベースの可能性もあるし、
後ろがラグな場合もあるし、
michiru_da
はたまたただの普通のファイルのテキストファイルの場合もある。
AIエージェントのメモリ
うぱ / upamune
例えば、みちるだの好きなものをとにかく書き溜めたテキストファイルとかあったとしたら、
それがメモリになってる。
michiru_da
メモリって何だろう?毎回参照しなければメモリ?
拾おうと思って?
うぱ / upamune
そうですよ。
とにかく永久保存できるもの。
そのAIジェントの活動が終わっても保存されているもの。
michiru_da
それを後から使うとかもできるんだ。
うぱ / upamune
だからAIジェントを呼び出されたら、永久保存されているものを読みに行って、
逆に何か新しいものを覚えたらそこに書き込みに行く。
なのでそのAIジェントが活動を終了しても次にそれを参照できる。
AIジェントが違ったらプロンプトっていうかコンテキストが独立してるんで、
そいつらの中でも共通認識としてメモリを使えるってことですね。
michiru_da
同じメモリを別のAIジェントで使い回すこともできるよっていう。
このメモリっていう独立した概念で存在するのが何の違いなんだって最初なりましたね。
うぱ / upamune
でもNAとNとかもそうですね。
michiru_da
メモリってありますよね。
デイビーアイコンみたいな。
うぱ / upamune
そうですね。
michiru_da
あれ最初私メモリなしで使ってて、毎回全て忘れてて、あれってなりました最初。
うぱ / upamune
でもうちのラグボットも最近までメモリなかったですね。
別に今でも別に外してもみんな違いもよくわかんないと思います。
michiru_da
そうなんだ。
一応本だとメモリ使う方が22%精度が出るので、とりあえず使った方がいいよみたいな感じだったんですけど。
時と場合によるという感じなのか。
うぱ / upamune
よるし、また戻ってくるけどその人は設計力士ですよね。
ゴミをめっちゃ保存しちゃって引っ張ってくるときもゴミだらけだったら、ただコンテキスト圧迫して結果に何も寄与しないゴミデータだけが押し寄せてくるみたいな感じだったら意味ないんで。
なるほど。
なんでまずなんだろうな。メモリなしで始めてみて。
なんかメモリが必要じゃねって別のAI人の実行でも覚えてほしい何かとかあるんだったら使えばって感じかな。
なるほど。
もうメモリだけのスタートアップとかありますからね。
michiru_da
すごいね。成り立ってるんだ。
うぱ / upamune
ん?
michiru_da
成り立ってるんだ。
うぱ / upamune
何立ってる?
michiru_da
いや、成り立ってるんだ。
成り立ってる。
うぱ / upamune
メムゼロとかゼップとか。
michiru_da
メモリって何を入れることが多いんですか?
うぱ / upamune
本だと行動履歴とか対話履歴みたいな。
うん。とかじゃないですかね。ヒストリーとか。
その人の何だろう。チャットGP的なやつだったら覚えてとか言ったら多分覚えてくれるんですよね。
michiru_da
チャットGPって。分かんないけど。
対話記録は残しておいた方がいいよっていう。
ただ、さっきのゴミをいっぱい保存すると意味ないよっていうのと一緒で、
過去の経験をそのまま記録し、情報を圧迫せずにプロンプトに組み込むと、ロングコンテキスト問題に繋がります。
これはめっちゃでかいプロンプトとかを書かれると、
LLMは最初と最後しか読めないみたいな。中の内容が抜け落ちちゃうよっていう問題があるので、
いかに過去の経験をメモリに入れるとしても、要約して短いプロンプトにするかみたいな。
それがポイントですよっていうのが書いてありました。
これはめっちゃ私やりそうだなと思って、やりそうってコメントをしてます。
うぱ / upamune
そうっすね。でもメモリのことはもう一旦忘れてんじゃん。
michiru_da
そうなんだ。時間を使っちゃった。メモリで。
計画の重要性
michiru_da
なんかそういうものもあんのね。
あとなんかこの本で意外とそのページを使って解説されていたのが、計画のところなんですよね。
そのLLMを構成する要素で、さっき説明したプロフィールとかメモリとか、実際に行動するところみたいなのに加えて、計画っていうものがありますと。
私の感想として、こんな章を削くほど大事なんだ。
LLMに計画してって言うだけではないのかっていう感想が書いてありますね。
でもこの本だとそのタスクの計画と実行計画みたいな、2種類ありますよっていうのが書いてあるんですけど、
エアーエージェントに合理的に最速で問題を解決してほしいという期待があるときには、できるだけ少ないステップで目標を達成するための計画立てというものが非常に重要ですというところが書いてあります。
で、タスク計画はそうだ。とにかく小さいステップに作業を分けろみたいなのが書いてありましたね。
あと、実際の達成したいゴールの手前にサブゴールみたいな、中間ポイントを置いて、
たぶんLLMが実際タスクとかをやっていった後に、ちゃんとその中間ポイントに達してるかみたいなのとかを設定すると早めに間違いに気づいて修正できるから、それもいいよみたいなのが書いてありましたね。
めっちゃ人間だなと思いました。
うぱ / upamune
そうですね。これも計画指定だとLLMの能力にだいぶ左右されちゃう。
michiru_da
そうなんだ。
うぱ / upamune
バカLLMだったら変な計画になったりとか。
あと、ジェミニのディープリサーチとかもまず聞いてきますよね。
michiru_da
そうですね。
計画これいいですか?
3つぐらいで質問してくる。
うぱ / upamune
質問をして解答したら、じゃあこの計画で進めます。いいですか?みたいな感じで選べますけど。
結構それないとあれですよね。長い時間走った後で、いやこれ全然違うやつやんけみたいな。
michiru_da
悲しい。
うぱ / upamune
そう。めちゃめちゃじゃなくてマチルダやないかいみたいなのが計画時点でわかってれば。
で、タスクの切り出しとかも、なんだろうな。ここではどういう単位で計画してほしいみたいなのが書いてればいいんじゃないかなっていう。
この小さいステップに作業を分けるっていうのも多分人によっても認識が違うし、LLMによっても違いますよね、例えば。
michiru_da
そうなんだ。
効率的なタスク分割
うぱ / upamune
ここだとマインクラフトの例がありますけど、材料準備、アイテム作りとか、その流度これも小さいのかみたいな話もあるし。
michiru_da
結構デカそうだ。
うぱ / upamune
そう。なんでそれで計画作ってみて、A案と5回に1回ぐらい失敗するから、もっと材料準備のやつは細かく何が必要なのかっていう材料を計画に書くように指示した方がいいのではとか、そういうのでいい感じになってくる。
michiru_da
親父さんも何か気を付けてることとかもありますか。
うぱ / upamune
むずいな。でも私は何か1回シュッてやらしてみて、なんだろう、違うこういう順番でやってほしいんじゃないんだよなっていうのは、その場でフィールドワークして、そいつにプロンプトに書き直してもらう。
それでもう1回最初からやるみたいな。
michiru_da
なんかその最近あんま見ないけど、そのクロードコード7時間ずっと走らせてましたみたいな人いるじゃないですか。
それってもうタスク計画がめっちゃ精度高いみたいな。
うぱ / upamune
いや、あれはもう何なんすかね。分かんないっす。
michiru_da
とりあえず実行してるだけみたいな感じなのかな。
うぱ / upamune
でもSDD、スペックドリブンデベロップメント、スペック駆動開発。
michiru_da
仕様駆動開発。
うぱ / upamune
そうそう、あれは結構もう恒例の極地っていう感じではあります。
私も開発するとき最近はもうSDDなんですけど、もう1300行ぐらいのまずデザインドキュメントを書いて。
michiru_da
へー、そんな細かいんだ。
うぱ / upamune
で、それにフィードバックして。
で、フィードバックしたら最後にその計画、実装する前にその計画と実際のコード群の計画との差分を擦り合わせるっていうクロードコードが勝手に。
で、こういう違いがあったけどどうしようかねみたいな聞いてきて。
これはこっちでこれはこっちみたいな。
そんな感じでしたらもう誰が何回クロードコードを実行しても大体同じ実装が出てくるみたいな感じだから、
それとかまで詳細にかけたらその7時間走らせるみたいなのもいけるという感じですね。
michiru_da
なるほど。
その選択、そうか小さいステップに分けるみたいなのも結局ゴールをめっちゃ詳しくインプットしてあげるみたいなことなのか。
うぱ / upamune
計画もね一番ざっくりな計画ってこの機能を実装しろっていうやつだけど、
これとこれとこれの関数を実装して繋いだらいけるよっていう一個ブレイクダウンしたものと、
この関数をさらにこういう実装にした方がいいよみたいな話もあるから、
タスク分解をどこにするかっていうのは小さい方がいいんだけど小さすぎたら本当にさっき最初に話したような、
まずこのファイルを読み込みますみたいな、これを探しますみたいな小さすぎるやつになっちゃうから、
その時のモデルの能力という感じですね。
michiru_da
なるほど。モデルの能力めちゃ結果を左右するんです。
うぱ / upamune
そうですよ。
だから、例えばGPT-5ってコーデックスってコードを書くCLIツールがあるんですけど、
コードを書くときはGPT-5コーデックスっていうコード書く専用のモデルになるんですよ。
michiru_da
そうなんだ。
うぱ / upamune
コードに関してより精度というか上がってるモデルなんですよね。
michiru_da
いい感じなんですか?
うぱ / upamune
いい感じです。クローズコードとかより全然。
michiru_da
うぱさんもそちら側に。
うぱ / upamune
遅いんですよね。
michiru_da
そうなんだ。何が?コーデックスが?
コーデックスが。
そうなんだ。コーデックスまだ触ったことないよ。
うぱ / upamune
遅いです。けど本当にねコーデックスはお得ですよ。
michiru_da
どういうこと?
うぱ / upamune
だってコーデックスって普通の人っていうか、そのGPTの旧チームプラン、ビジネスプランだったら月30ドルなんですよね。
30ドルでコーデックスのCLI使えます。
michiru_da
コード書くやつ。
うぱ / upamune
でももちろんVSコードとかカーソルにインストールできる拡張機能も使えますと。
デビューみたいなコーデックスクラウドっていうSlackとかウェブ画面で指示したらコード書いてくれるやつも使えます。
あとはプロリクエストのレビュー機能もコーデックスによる使えます。
さらにGPTっていうチャット機能も付いてくる。
それで30ドル。
michiru_da
高機能ですね。
そうそう。
全部使ってますか?
もちろん。
そうなんだ。
うぱ / upamune
コーデックスクラウドはめっちゃ調査させてる。
michiru_da
気になった時にやって?
うぱ / upamune
そうそう。問題とか起きた時にSlackでアットメンションして、これってこういうことなのか、こういうことなのかね、そしたら調査しますみたいな。
michiru_da
そうなんだ。
うぱ / upamune
で、iPhoneのライブアクティビティでこの問題を調査中みたいなのが出てくるんで、グッドです。
SlackのSlackじゃない、ChatGPTのiOSアプリからもコーデックス使えるんで、そっからもブチブチってできたりするんで。
michiru_da
確かに万博行ってる時にうぱさんにコーデックスデコーディングできるよってお勧めされたな、そういえば。
うぱ / upamune
でしょ?やってないな。
そうじゃんって言ってたね。
michiru_da
私たちとやる前に、仕様を考えてから作らせようと思ったんで、仕様を書いてたら万博終わりました。
うぱ / upamune
ちょっと脱線しちゃったけど。
michiru_da
なるほどね。
うぱ / upamune
計画第一っていう話ですね。
LLMの行動計画の難しさ
michiru_da
計画第一なのに、LLMに行動計画が立てられるのかっていうショーがあって、そこで衝撃の。
実は行動計画のような実行可能な手順を組み立てるのは、LLMにとっては難しいという研究結果が報告されていますっていう。
苦手なんだみたいな。
うぱ / upamune
ワンショットでいいの出てきたことなんかないですね。
michiru_da
そうなんだ。
なんかその、ちょっとさっき、今回か前回か忘れたけど、カーソルのプランモード、計画モードできましたよとか、
クラウドコードをまず計画してくれるのがいいってみんな言ってたけど、
これは別にその精度というかは、とりあえずそういうアクションやってくれる体験がいいみたいなことだったのか。
うぱ / upamune
いや、作ってきた計画へのフィードバック前提ですね。
計画立ててフィードバックなしでコーディングするんだったら、計画別にこっちに見せてくれなくてもいいんで、
プランモードって、実際に何かのファイルをいじりに行ったりしないっていう計画専用モードで対話しながら計画することで、
さっきのジェメギのディープリサーチみたいな、マチルダのこと調べたいんじゃないねんっていうみたいな悲劇を、
例えば1時間走らせてから気づくことがなくなるっていうことですね。
michiru_da
なるほど。
LLMは苦手だけど頑張ってるんだ。
うぱ / upamune
一応頑張ってくれます。
やっぱなんか、ゼロから書くのめっちゃだるいし、
あと、口で言えばそれを直してくれるのがめっちゃ楽ですね。
michiru_da
まあないよりはいいし、っていう感じなのか。
うぱ / upamune
こうしてみたいな感じだったら、ちゃんとした計画になるんで。
まあけどね、普通のこういうプランドットMDみたいなのを書こうみたいなのがちょっと前はあったんですけど、
やっぱそれでもね、ちょっと詳細すぎないから、やっぱ実行するときに解釈の幅が出るんですよね。
michiru_da
はいはいはい。
うぱ / upamune
なんで実行したらツンみたいな感じに。
michiru_da
わかりますね。
うぱ / upamune
それがSDDで本当にだいぶマシになりました。
そうなんだ。
本当になんかVIVEコーダーみたいな人にはSDDめっちゃ向いてないけど、
michiru_da
前からそのプランMDみたいなの書いて、精密に計画して実行したいよっていう人にはSDDマジでおすすめですね。
なんか自分もそのLLMにPRDっていうか、使用書みたいなの書かせるみたいなのあるんですけど、
なんかいい感じに指示しないと、本当にお前それでわかってんのかみたいな、
バリ抽象的な使用書みたいなやつが出てくるんで、
フェードバック前提みたいなのは間違いないなって感じですね。
うぱ / upamune
そうですね。
michiru_da
で、なんでこの本でもそのLLMで行動計画、
特になんか1個実行した後のその次の状況をあらかじめ予測して、次の手を考えるやつ。
なんか本の中だとなんかABCのブロックが積まれてて、
このBとCの順番を入れ替えるにはどういう風にブロックを動かしたらいいかみたいな、
そういう問題が書いてあったんですけど、そういうのはやっぱり苦手なので、
そいつを精度良く出すには、
ChadGBDのO1プレビューみたいな、
その推論モデルっていうのがここで必要になってきますよっていうので、
これもへーっていう感じでした。
時間かかるけど、普通のモデルよりはできるやつが推論モデルですよっていう感じでしたね。
シングルエージェントとマルチエージェント
michiru_da
これがブック、ブロックワールド問題。
うぱ / upamune
うーん、なるほど。
O1プレビューって今どこら辺の立ち位置、てかもういないか。
michiru_da
なんかO1プロも過去のモデルだよみたいな。
なんだっけ、O3プロみたいなやつが今は最強のやつみたいな。
うぱ / upamune
主に?
michiru_da
さすがにプロプラン開薬しちゃったからな。
うぱ / upamune
あ、のみちるだもん。
O1が3月に出て、6月にO3プロが出て、
で、10月にGPT-5か。
いやー、時間の流れは早いですね。
michiru_da
早いですねー。
うぱ / upamune
え、すごいな。O1、O3、GPT-5プロ、リリースされたの全部25年なんだ。
michiru_da
3月、6月、10月。
すごいね。
うぱ / upamune
O1プロ高すぎー。
michiru_da
あったなー。
ブログ書いてもらうのとかめっちゃいい感じだった気がするな。
うぱ / upamune
O1マジでやばいな。
なんかGPT-5は入力価格が、インプットが1.25ドルなんですけど、
O1プロは150ドルですね。
michiru_da
高っ。使えないな。さすがに。
うぱ / upamune
普通に破産するレベル、これは。
michiru_da
やばいね。
あとは、もうちょい高度な話みたいな感じで、
シングルエージェントとマルチエージェント、
シングルエージェントワークフローっていう謎のやつも紹介されていました。
そうですね。シングルエージェントの方は、
その主体になるLLMのシステムの数が1個に限定されますと。
なので、1人で作業をする場合を想定して、
タスクを解くことを、さっきの行動とか計画とか自己修正みたいな、
機能単位に分けたやつがシングルエージェントらしいです。
一応、マルチエージェントみたいなやつも教えてくれたんですけど、
これは壮大だったな。
2体以上のエージェントが連携するワークフローですっていう感じで。
これは、人間社会をシミュレーションしたりとか、
本当に業務プロセスの流れに沿って協調をしていくエージェントを作りたい時には、
これを使いましょうみたいな。
これも結構理論上相関みたいな感じでした。
でもさっきのうぱさんの決定論的な実装が多い方が、
2Bだと安心だよねっていうので言うと、
うぱ / upamune
マルチエージェントワークフローとか、なかなか使う機会も限られるのかなという。
逆にマルチエージェントかなって思いました。
michiru_da
そうなんだ。
うぱ / upamune
めっちゃある業務に特化させたエージェントをめっちゃ作る。
それで、ジェネラルなチャットエージェントみたいなやつが、
michiru_da
これは経費生産エージェントにお任せ。
うぱ / upamune
そうしないと、紙エージェントが生まれないと、
michiru_da
全てのツールを。
全部を網羅すること?
うぱ / upamune
そうそう。
これはたびたび話に出てる、ラグのBotでもやろうとしてて、
あいつってできることは質問にラグを使って答えるなんですけど、
その足として、めっちゃ質問が載ってるExcelとか渡したら全部回答してくれるみたいなのがあるんですけど、
そいつもAIエージェントとして実装されてるんですよね。
なので、ラグのBotが聞かれたら、シートにこれ書いといてって言われたら、
自分で頑張るんじゃなくて、そいつに投げちゃう。
そのAIエージェントを別のAIエージェント呼び出して、そいつにやろピコって言って、そいつが書いてくれるみたいな。
そのエージェント同士の協調みたいな。
michiru_da
確かに言い口は一個で、裏側は別の人がやってくれたらいいから。
うぱ / upamune
ではいいですね。
会社とかもそうですよね。
michiru_da
そうですね。窓口の人と、実務やる人別みたいな。
うぱ / upamune
そうそう。で、実務の人は詳しい人とかがいるとか。
michiru_da
あとそういう意味で言うと、AIワークフローとエージェントの区別が絶妙に難しい。
AIワークフローとエージェントの区別
うぱ / upamune
これは分けてるんですか?
michiru_da
一応分けて書いてましたね。
エージェントワークフローと混同しやすい用語としてAIワークフローというものがあります。
AIワークフローとは、LADMとツールが事前に定義されたコードバスを通じて調整されるシステム。
なので自律的にツールを選ぶとかあんまりないってことなのか。
それが違いなのかな。
なのでエージェントにおける計画やメモリー、自己修正などにとらわれない点が特徴とのことです。
うぱ / upamune
AIワークフローの中の一つのコンポーネントとしてAIエージェントが使われることもあるんじゃないかと思うんですけど。
それをまさにやってるのがNAとNだし、決定的な動作の中にエージェントノードがいるみたいな。
それはAIワークフロー、全体で見るとAIワークフローだけど、その中にエージェントいるよみたいな感じなのかな。
確かにそれもありそうですね。
michiru_da
そうですね。
AI機能を作りたいってなった時に、
いやそうか。
でも今のエージェントが間にいるワークフローみたいなのが結局多くなるみたいな感じなのかな。
AIワークフローで実装する中、エージェントにしなければいけないのかが結構それも難しいなって思いました。
自分は結構限定されたユースケースからまず検討を始めちゃうから、
それだったらワークフローでもいいなみたいに思う場合が多いかもしれないなという想像をします。
うぱ / upamune
それでいいんじゃないですか。
別のAIエージェントがそのAIワークフローを呼び出すみたいなこともできるから。
michiru_da
すごい相互作用的ですね。
うぱ / upamune
そのワークフローが決定論的であればあるほど嬉しい。
AIエージェントから見たら一つのただのツールコールでしかないから、あるワークフローを起動するっていう。
それはいいんじゃない。
michiru_da
いいそうです。
どんな感じかな。
うぱ / upamune
ワークフローからAIエージェントへどうやってやっていくかみたいなやつは、またアンソロピックエンジニアリングブログだけど、
効果的なエージェントの構築っていうやつでもうパターンがあるんですよね。
michiru_da
とりあえずそれを読むのがいいのか。
うぱ / upamune
プロンプトチェインギングパターンとかルーティングパターンとかパラレルパターンとかオーケストレーターワーカー型とかがあって、
michiru_da
それ聞いたことある。
うぱ / upamune
これは他のAIのSDK、AISDKって呼ばれるエージェントを実装するためのライブラリとかでも同じ概念がドキュメントで説明されてて、
michiru_da
このワークフローを構築するんだったらこういう感じでコード書けばいいよみたいな感じで書かれてるんで、それを理解しておくといいかなっていう感じですね。
うぱ / upamune
なるほど。
michiru_da
この本を読む前は、とりあえずその総論を読んで、1個か2個自分で実装も本の通りにやってみて、
その上で自分が今業務で使いたい一定複雑なAIワークフローなのか、あるいはエージェントなのかみたいなやつがあるんで、
それを作ればいいかってなったんですけど。
そうですね。ちょっと前半でも述べた通り、本を読んだからといって、じゃあどうすればいいかはちょっとやっぱ分からなそうであるっていうのがNowっていう感じですね。
うぱ / upamune
難しいよ。
難しい。
そうですね。すぐ使える知識って難しいですよね。
michiru_da
結局誰かのコピーするとかが短期的にはわかりやすかったりするんですけど。
これも前半で言いましたけど、結局多分自分で手を動かして、これは使えないなとか、これでも意外と使えるなっていうのが、
手触り感がないとどうにもという感じなので、やっていくということだけなんでしょうね。
うぱ / upamune
だいぶ手触り感のあるコードをみちるださんは社休してて、オープンAIのAPIをSDKを使って読んでAIエージェントを作り上げていくっていうのを書いてて、
AIエージェントの活用法
うぱ / upamune
さっきから簡単に言ってるツールコールとかも、自分でツールコールを検知したら関数を読んでその結果を返してあげるみたいなのをやらなきゃいけなくて。
みちるださんが発狂してましたね。これマジでみんなこれやってんの?みたいな。やってないよって。
やってないんかい。
だからその手触り感をね。
michiru_da
そうですね、本当にプリミティブなコードを書いてます。
うぱ / upamune
そういうことをやった後にAISDKとか触ったら目玉が飛び出てありがたさで前が見えなくなるっていうことですね。
最初からリッチすぎるやつを触ってると何が何なのかよくわかんない。
michiru_da
そうですね、ちっちぇいやつでいいんだよな。
うぱ / upamune
書籍にもすごいLLMを使わずにエージェントループをわかりやすく説明するっていうコードがあったんですけど、みちるださんはなんだこれ。
michiru_da
本当にコードを実行しても特に何の便利でもないアウトプットが出てくるやつで、
これって何のためのやつなんだっていうのをまたキレながらうぱさんに聞いてました。
うぱ / upamune
確かに。
michiru_da
だから別にLLMを使わずにその構造だけ書いてるんだよって言って、そっかって。
やっぱね、その第3章以降はエンジニア向けになってるんで、その辺の意図の解説とかさすがにないっていう感じなので、
ちょっとこの辺は一人で進めるのはやっぱ結構辛いなという感じですね。
うぱ / upamune
あとエンジニアじゃない人にとっては環境構築がむずいかも。
前までね、なんかGoogleコラボみたいなやつでできたんですけど、
4章からDockerを使いますみたいな感じになってきたから、さすがに無理かみたいな感じになって、
道主もローカルに移行。
michiru_da
移行しましたね。
でも昨日なんかエラスティックサーチの、なんか昨日に一応失敗して1時間ぐらい。
うぱ / upamune
プンスカしてた。
michiru_da
1時間半ぐらいちょっとそれで解けましたね。
大変な仕事ですよ、エンジニアの人は。
これを毎日。
うぱ / upamune
そうだよ。
道主さんもなんか焦げたら聞いてくれればいいのに、なんかずっとチャットアンジェリビティと対話してるの。
michiru_da
なんかあれもどんぐらいで切り上げたいかわかんないですね。
うぱ / upamune
聞いて出てきた答えを実行してみてダメだったらもう。
michiru_da
切れた方がいいかも。
うぱ / upamune
じゃあちょっと今後はそうさせていただきます。
じゃあこの本はまだ読み進めていけそう。
michiru_da
そうですね、なんか使うとこの今やりかけのヘルプデスク支援エージェントの作るやつはやろうかなと思ってます。
うぱ / upamune
しかもなんかあれですね、なんか自分が自分というかやってるところと近いというか。
michiru_da
結構ユースケースもわかりそうだし、自分が作りたいものにも転用しやすそうなので良さそう。
あとあれですね、多分発祥以降とかが本当に現場業務で使う上でのそのエージェントの評価問題とか、
あと多分実プロダクトに入れる時の UX みたいな話とかも一番最後の第8章以降で書いてありそうなので、
うぱ / upamune
ちょっとそこはそこでまた読もうかなと思います。
イベントのお知らせ
michiru_da
はい、ちょっとそれも面白かったらまたやるかも。
はい、すごい前編後編合わせて90分の対策になりました。
でもそれぐらい読みごたえのある良い本ということだったので、はい、機会でした。
そんな感じで。
あとちょっとここまで聞いてくれた方が何人いるかわからないんですが、
12月6日にマヂカル.fm公開収録イベントをやらせていただきます。
お前らのAIエージェントの理解間違ってるから教えてやるぜの人も来てください。
確かにエンジニアの人は来てるガチな気がするから、
まあ確かにうぱさんとAIエンジニアと話したいよって人も来てください。
AIエンジニアとAAPだからな。
12月6日東中野夕方です。
何人かでもお申し込みいただいた方いて、
全部で20名ぐらいの割とこじんまりとしたところなので、
ぜひちょっと迷っている方はお早めに。
うぱ / upamune
本当にもう全然来てください。
そこなんかもう余裕で埋まりますみたいな感じじゃないんで。
michiru_da
そう、なんか私行っていいのかなみたいな。
うぱ / upamune
本当にもう何その正月の集まりより少ないぐらいの。
michiru_da
そうです本当に。
それでみんな遠慮して結局全然人来ないとか本当にあり得るんで。
うぱ / upamune
確かに。
michiru_da
ちょっとでも行きたい気持ちがある方はぜひ今すぐお申し込みください。
うぱ / upamune
確かに。
確かにそのこういう知らない人いるの嫌だなっていう。
大丈夫かな。
みちるださんがいるんで。
michiru_da
はい。
うぱ / upamune
もう気配り、気配りチルダね。
michiru_da
任せてください。
うぱ / upamune
はい。
michiru_da
はい。
12月6日皆さんお申し込みお待ちしてます。
はい。
感想、質問、フィードバックはxのハッシュタグマヂカル.fm全部小文字または概要欄のお便りフォームまでお寄せください。
Spotifyのベルマークを押すと更新通知が届きますのでそちらもお願いします。
ありがとうございます。
うぱ / upamune
ありがとうございました。
