リミットレスペンダントの紹介
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う企業家の山本とエンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。
はい、ということで、今回もよろしくお願いします。
はい、よろしくお願いします。
ちょっと今回話したい内容が、リミットレスペンダントっていうのをちょっと最近欲しいなって思ってるのがあるんですけれども、ちょっとその話ができたら嬉しいなと思ってます。
そこから発言して、APIとかMCPとかそういう話になったりとかするのかなっていう、脱線してね、なるのかなとかも思ってるんですけれども、ちょっとなんかどういうところがそれいいと思ってるのかみたいな話ができたらいいかなというふうに思ってますので、よろしくお願いします。
わかりました。リミットレスペンダント。
リミットレス。AIっていうページで見れるんですけれども、簡単に言うと、プラウドノートとかに近い。
プラウドノートっていうのは議事録を腕とかペンダントとかではめてたりとか、あとはスマホの裏側につけたりとかして、何か会議があったら、それの議事録を勝手に生成してくれて、その議事録に対してAIでアプリ上で質問できたりとかするような。
それは形状によっては通話の記録をしてくれるバージョンがあったりとか、自分のペンダント的につけて常駐型みたいな感じで起動しておくと、リアルの会議をちゃんとみんなの声収集してやってくれたりとかするみたいな。
最近多いよね。ボタンを押したら議事録を自動で取ってきてくれたりとか、それがオンラインのものだったり、たぶん現場でそのものを置いておくだけで聞いてくれるよとか収集してくれるよっていうのが増えてるよね。
他にもイヤホン型のやつがあったりとか、色々するんだけれども、このリミットレスペンダントっていうの結構いいなと思っていて。
よくあるっていうか、それも最近出てきてすごいいいなと思ってるんだけど、基本的には会議が始まるときにオンを押して、議事録生成とかに使うっていうのが基本ベース。
そんなイメージがあるよね。やるときにオンにするみたいなイメージは強いかな。
一応そこで得た文字起こしとかは、その特定のアプリ内でAIに聞けたりするっていうのが基本なんだけど。
このリミットレスは100時間くらい駆動するらしくて、バッテリーが。
ペンダントとして100時間ずっと?
ずっと。だから自分のライフログみたいな感じでずっと録り続けられるっていうのがまず一個特徴。
なのと、そこですべての会話をしっかりと取得して、すべての会話をさらに外部からAPIでデータとして取得できるって文字起こしされたものなんだ。
もちろんアプリ内、リミットレスペンダントのアプリ内で聞いたりとかもできるらしいんだけれども。
そうなんだ。100時間って聞くと結構すごいバッテリー持つね。
じゃあ、丸1日オンにして、もう全部の会話を取得し続ける。
できるんだ。すごいね。
それがすごい。議事録系のツールって、自分で明示的にオンにしないといけない。
それはスマホのボイスレコーダーとかもそうだし、やっぱりあの一個が結構心理障壁高いと思ってて。
忘れちゃうんだよね、あと。話してる時に、つけなきゃって言って、ごめんもう一回みたいな話をちょっと僕もよくやっちゃうんだよね。
しかもあれをすることによって、自分もそうだし、会話相手も取られてるっていう感覚が残り続けるから、取られてる前提の会話になっちゃうっていう課題があると思ってて。
まあ確かに自然な会話にはちょっとなりにくいかもしれないよね。
で、その点、リミットレスは常駐してるんで忘れるはず。
そうだね、確かに。ペンダントとして体にもうぶら下げておける。
なんかね、形状的にはペンダントって言ってるんだけども、もちろんペンダント的につけることもできるし、なんかあの胸ポケットにこうパサッと刺しとくこともできるしみたいな、割となんか使いやすい感じの形状。
なんかクリップみたいな挟み込む感じの形状になってるみたいな。
自分もだから、取られてることを完全に忘れて喋っちゃうからね。
そうそうそうそう、もうその前提としてやるっていうのも結構いいなと思っていて。
APIとMCPの重要性
で、あとさらにいいのが、先ほどもうちょっと少し話したAPIで外部から、自分で作ったプログラムとかそういうのからアクセスできるっていうのも結構デカい部分かなというふうに思ってます。
ちなみにMCPもあるみたいな。
あ、MCPとかでも取得できる。
そうそうそうそう、っていうのがあるみたいです。
でもベースはAIで取得した会話を整理してくれたりとか、そういうのもやってくれるんだよね。
そういうのもやってくれる。けど基本的にログで溜め込んだデータを、自分たちのサービスの中に閉じようってするサービスが多いと思うんですけど。
確かに。結局さ、僕TLDVとか使ってるんだけど、TLDVっていう議事録音、MeetとかZoomで録音してくれて、あとで要約文とか見れるんだけど、あれってTLDVの中でしか見れないことが基本だと思うよね。
で、そうすると取り回し悪いよね。例えばChatGPTとかクロードとかも会話ログっていうのを外から別に取り出すことがある。
たぶんできるはできるかもしれないけど、公約には別に公開されてないよね。
そうだね、苦労するね結構。たぶんできるんだろうけど公約に公開されてないからどうやって取るの?みたいな話になるよね。
みたいなね。っていうところを、LimitlessはサービスとしてちゃんとAPIとかを整備してる。
ちょっとAPIって何?っていうところの知らない人もいらっしゃるかなというふうに思っていて、逆にMCPだけ知ってるとかもあると思うんですけども、
APIって簡単に言うと、サービス側がこういうパラメータを渡して、こういうURLに対してリクエストを送れば、アクセスすれば、
所定の情報、決まった情報、例えば今日っていう日付と、あと自分のIDを設定パラメータとして渡して、
そのAPIにアクセスすれば、その指定した日の会話ログが返ってくるみたいな、そういうふうに規格化してくれて、
いわゆるプログラムで容易にアクセスできるようにしてくれてるっていうような、それはいろんなパターンがあるんですけども、
認証もそうだし、情報取得もそうだし、編集とかデリートとかいろいろあるんですけれども、
そういうふうなものをちゃんとサービス開発側が用意してくれているものを基本的にはAPIと言ってるっていう感じなのかな。
サービス側が開発してるっていうところは定義からちょっと外れるけど、
フリーが例えばAPIを提供してたら、フリー会計に対してプログラムからアクセスできるような口を用意してくれてるみたいな、
なんかそんなイメージ、もしわかりやすく他の補足説明があれば。
だいたいもう合ってると思うよ。フリーとかも結局、みんなは普段Chromeとかブラウザからしかアクセスできないから、
パソコンでポチポチ触りながら情報を入力したりするけど、そのAPIっていう決まったフォーマットのアクセスの仕方とかがあることによって、
プログラムで完全に処理できるっていうのがAPIの良いところだよね。
他にも例えば、SlackのAPIとかだと、Slackにボット的にあって、あれはAPIなのかな?
あれも一応APIの一種だね。
ボット的に、Slackのボットがたまにあって、あるメッセージをメンションつけて送ると決まったやつを返してくれるとか、
他にもいろいろ、保存ボタンを押したらこういうプログラムが動くようになるとか、そういういろんなSlackのギミックを用意してくれてるけど、
それも基本的にはAPI、WebhookとAPIが一緒なのかな?
そうだね、APIの中にWebhookっていうのが立ち位置としてあるイメージだと思うよ。
Webhookっていうのはどっちかっていうと、システムから何かイベントが起こりましたよっていうのを通知する向けのもので、
通知する先は、例えば僕たちは開発してるシステムのサーバーにここにアクセスしてねって登録しておくと、
Slack側が、「〇〇さんが今メッセージを投稿したから、登録されたシステムに通知しなきゃ。」って言って叩いてくれるのがWebhookの仕組み。
プライバシーとデータ管理
APIっちゃいいいAPI。
あとはNotionとかね、データベースをプログラムから、Notionに登録している情報をプログラムから、
例えば自動的に毎日更新されるみたいなプログラムを作ったとしたら、毎日毎日新しいタスクが生成されるみたいなことを用意にできるようにしてくれるような口を用意してくれてる。
それもAPIとして提供されてたらできるようになってるみたいな。
ただね、やっぱね、そのAPIを提供してくれないような、まあしないのが悪いってわけじゃないんだけど、やっぱりサービスの特性上、提供しないところも結構ある。
ブログサービスとかもAPI叩かれて、別のブログサービスとかにどんどん転載されたら困るからやりませんとか、
なんかそういうので結構クローズになっていることが多いかな。
そんなこんなでちゃんとAPIが提供されているというところと、100時間ずっと、実際にこう、ちゃんとまだ見てないけど、常に取得して100時間なのかどうかはちょっと分からないけど、
一応他のものより圧倒的に長いし、利用用途としては常にログを取り続けるっていうようなサービス思想っていうところがあって、
その情報を自分たちのサービス内に閉じないっていう思想は結構なんかいいなっていうふうに思っていて、ちょっと欲しいなっていうふうに思っています。
あれだよねきっと、APIであるからこそ、その自分が喋ってた内容を、多分きっと翻訳された内容だったりとか、
まあ多分、そのサービス側で例えばタスクを作ってくれたりとか、きっとすると思うんだけど、そういうのをAPIを実行して、取得して、
でなんか、Googleカレンダーに自動で登録するような仕組みを自分で作れたりとか、AIに今日の1日の発言で良かったところは何?悪かったところは何?っていうのを聞いたりとか、そういう可能性があるってことだよね。
で、なんかそこを例えば、自分が今まで作ってきたノートの文章をシステムプロンプトに組み込んでいて、
で、その上で自分の今日話した発言、得た情報の中で、今まで自分の書いてきたノートの構成に近いようなニュアンスのノートの文章を作るっていうのを、
マストラとかAIフレームワークの活用して、上手く毎日10時にアクセスする。で、今日の会話録音を全部見て、その上でノートの文章を作成してもらうみたいなことが可能になったりとかするっていう。
いいね、1日のナレッジが自動的にこうノートにまとまって、公開ができたらさらに自分の中に貯めておくってことも十分、
なんか振り返ることができると思うし。
っていうような、しかもGetAudioっていうAPIもあるから、オーディオファイルとして取ってくることもできるみたいな。
ちょっとしたポッドキャストとかできそうだね。
ああ、そういうのもできるかもしれないね。
そうだね。
そうそう、みたいなちょっといろんなものが用途として考えられるかなっていうふうに思っていて、これ結構なんかいいなっていうふうに思ってるっていうのは最近ですと。
欲しいなあ、僕も。なんか自分の発言とか、たまに俺あの時何て言ったっけって思っちゃう時あるからね。
はいはいはい、そういうのもね。
他のサービスでね、ちょっとサービスの名前忘れちゃったけど、自分のMac上の操作を全部ロギングしてくれて、さっきやったあれ何してたっけみたいな。
セキュリティ上どうなんだみたいなところあるけど、さっきのLimitlessもプライバシー上どうなんだみたいなところあるけれども、
そういうのを常時監視してくれる相棒がいるっていう。
でも確かにそう考えると今までって言われると、プライバシーとかセキュリティっていうところ、もちろん大事なんだけど、それが気にしすぎるがゆえに、ずっと録音しておくみたいな発想にはあんまりなかった。
そうそう、それをだからぶっ飛んだ発想よね、ある意味。
そうだよね。
勇気のあるサービスだと思っていて。
でもそうやって権限を全部預けちゃって、例えばそれこそAIもそうなんだけど、全部やってもらうぞって覚悟を持つと、一気に開けること、やれることが増えるよね。
増えるよね。確かにだから聞いててやっぱこのサービス結構面白いなって思うけどね。
そこが大前提としてこのサービスが信頼に足るセキュリティとかっていうのは一応あるはあると思うんですけれども、例えばデリートログみたいなAPIもあるらしくて、
だからリミットレスで取得した会話ログの情報は自分で信頼の受けられるデータベースサーバーとかそういうところに毎日格納して、格納し終えたらちゃんとデリートで削除していって、ここ上限は残さないようにするとか、例えばね。
確かにそういう使い方もできるよね。
ちょっとよりセンシティブに考えるなら、一応このサービスに乗っちゃうからっていうのはあるけど、ずっと保持しておくよりは、最近何だったっけ、AI彼女みたいな海外のサービスがあって、それの会話ログが全部漏洩したみたいな。
それはすごく嫌なんだ。
APIの利便性
漏洩するタイミングでそのサービス上にログが残ってないっていう状態を作るっていうのも意外と万が一に備えてるっていうのでは。
逆にこれができるのが一個良いところだよね、APIって解放されてるっていう。
やっぱなんかサービスに閉じてアプリケーション上で毎日ポチポチ削除するんだってやると、なかなかルーティンに乗らないとかっていう問題があると思うけど、ちゃんとプログラム化できる可能性がある。
余地を残してくれてるっていうのはすごくいいところなのかなっていう。
めっちゃ大事だね。僕もね、そのAPIの話でいうと、このレコード機能だけじゃなくて、フリーの会計とかも結局自分で請求書をポチポチ最初作ってたけど辛くなっちゃって、
APIがあるっていうのを知ったから、もう自動で請求書作れるような仕組み作ったりとか、
それこそもう勤怠のログ自体も、今はパソコンとかスマホでボタン一個押せば、何の仕事をしてるかっていうのが全部記録されるようになってて、
しかもそれがAPIで取得できるから、その働いた時間を全部クライアントごとに分離して、
自動で、操作はもう僕が働いてるか働いてないかっていうオンオフだけで、最後もう自動で働いてる時間を合わせて請求書を生成するっていうところまでできるようになってるから、
APIがあるとすごくありがたいっていう話だね。
そうやね。それに加えて画面を見てくれてたら、それによってオンオフ勝手にしてくれたりとかしちゃうからね。
これはA社のやつをやってるから、今Aがオンゼスみたいな。
そうだね、そういうのもできたらいいね。やっぱちょっとプライバシー気になるけど、やってほしいなと思っちゃう。
やっぱなんか最近思うのは本当に、作業を少なくするんじゃなくて、作業をいかになくすかっていうのがやっぱ重要なのかな。
そうだね。一個でもあるとなんとなく頭の中でボヤッと考えちゃうから、考えちゃうとか、やらなきゃなってなるから、
オクになっちゃうね。どんなにそれが楽な作業になったとしても、その瞬間はめっちゃ楽になったと思うけど、
結局作業残ってんじゃんみたいな。ゼロにしてくれるのが。
そうそうそうそう。いかにゼロにするかって結構大事で、そのためには割と今回紹介したリミットレスじゃないけど、
APIが提供されてるっていうのは結構大きくて、もちろんこれ今聞いてる方がいたら、
マヌスとか使ってAIにブラウザを操作してもらったらいいじゃんみたいな、思ってる人もいるかもしれないですけど、
それも、あとはどこまでの確率を求めるかっていう話かなと思っていて、
マヌスに全部のログイン情報とかも渡さないといけないとか、いろんなセキュリティ的な、
自分としてはちょっと気持ち悪いなって思わないっていうのは人それぞれあると思うけど、
と、あとプラスマヌスがちゃんとその操作を仕切ってくれるかどうかっていうのが、やっぱ担保できないみたいなのがあって、
だからできるだけプログラムに寄せといて、ラスト1マイルだけAI化するみたいなとかっていう、
このなんか攻め合いみたいなのが割とAI、駆動開発をする中でもそうだし、AI関連サービスを使うのでも作るのでもそうだけど、
そこの住み分けって結構大事。プログラムにしようとするとツーマッチになりすぎるんだけれども、AI化すると割と簡単だし、
しかもAIでも全然精度出せるんだったらそっち選んだ方がいいと思うし、あとはコストの問題とかね、いろいろあると思うけど、
そんな感じで、ある意味今後のサービス開発とかにおいて結構重要な示唆を与えてもらったなと思って、
そういう意味でもちょっとこう、こんな話してるのに購入はしてないんですけど、
買ってないんかいっていう話だよね。
ずっと欲しいなって思ってるっていう感じなので、ここから学びを得たんで、やっぱりAI時代、API化されてること、MCP化されてることっていうのがすごく重要なんだなっていうふうに。
まあそうだね、あとあれではね、結局APIで公開されてますってなっても、じゃあどうやってAIに使ってもらうかっていうのが結構重要で、
なんかそういう意味で、なんか多分これ聞いてる方があまり馴染みないかもしれないし、もうすでに知ってるかもしれない話だと思うけど、
やっぱりMCPっていうものが、AIにそのシステムを操作してもらうためにはめちゃくちゃ今重要だっていうのが、
まあ登場したのが、概念として出てきたのはちょうど去年の今頃かな、2024年の暮れとかだったかな。
なんか割と最近の概念なんだよね。
あ、そうなの?
MCP自体は、そう、アンソロピックが提唱した概念で、ちょっと今から調べる。
あー確かに、ちょうどだ。2024年11月って書いてる。
あ、そうだよね。だからすごく最近登場してきた。
あ、そうなんだ。もうなんかけど、MCPないとちょっと辛いよねって感じだよね。
もうMCPあって当然の世界に、まあAIの世界ではなってきてるよね。
うん、まあまあそうだね。
結局AIっていうのは、その時学習したことしか知らないから、しかもそれがさ、公開されてる情報しか知ってないから、
こういう情報を取得してって言っても、例えばフリーのAPIの、ね、取得してくださいなんて言ってもさ、
知らないから適当なAPIを自分でこう騒動で書いて、
まあハルシネーションの元にもなるしね。
そういうのを抑えるために、標準的な規格としてAIに、そのシステムにどうやってアクセスするかっていうのを教えてあげるっていう意味で、
まあアンソニックピックはMCPって概念を、ちょうど去年提唱したばっかりっていうところだったね。
ちょっとAPIとなんかMCPってどういう関係性なんて、ちょっと僕的にはよく、なんか、思うことが、思うっていうかなんか、
まあそうだね、例えばマストラでワークフロー作ってると、
別にツールとしてMCPも提供できるし、APIも提供できるんですよね。
で、そうした時に、なんかMCPである理由って何なんだろうとかっていうのをちょっとすごく、俺は結構感じることがたまにある。
ああ、なるほどね。まあでも確かに、なんかMCPとAPI、あんまり変わらないっちゃ変わらないし、
なんかみんなMCPって言ってるから、なんか新しい概念だからこそ難しそうに感じるんだけど、
なんか実はそんな難しくないよなって僕は思ってて、じゃあAPIとMCP何違うのって話だと、
まあさっきAPIの話、軽く説明したと思うんだけど、こういうURLだったり、こういうアクセスの仕方してくださいっていうルールがあって、
実際にそれでアクセスしたら情報が取れるっていうのがAPIだよね。
だけど、そのAPIってあくまで、こういう場所にこういうアクセスの仕方してくださいっていう情報があるから、
プログラムが事前に、もうプログラム事前に固定で書いてて、リクエストできるようなものなんだけど、
それはMCPとほとんど似てて、MCPはなんかもう、
実際に言うとあれか、AIが実際にそのAPI叩くためにはやっぱりその情報を最初に与えなきゃいけなくて、
それをもうMCP側でやっちゃおうっていうのがコンセプトで、
そのMCPっていうのを起動すると、そのAIがMCPを使おうとした時に、
まずどういう情報が取得できますかってリストだったり、
その情報を取得する時にどういう使い方をしますかっていうのもセットで教えてくれるようなものがMCPサーバーっていうものになってるんだよね。
あれか、ドキュメント、使用書付きAPIみたいな感じで、APIをあくまでもラップしてるみたいなイメージ。
そうそう、あくまでもAPIをラップしてて、説明書、もう本当にその通りだね。説明書付きのAPIみたいなイメージで。
けどなんかちょっとわかったかもしんないくて、なんか今の正直阿部ちゃんの話だけだと、
今後のサービス開発の示唆
ちょっとまだやっぱり、俺の視点から言うとAPIとMCPってそんなになんか有益性がない。別にドキュメントを与えたらいいじゃん。
そう、だからあんまり変わんないと思ってる。
と思って、けど今明確に気づいたのは、俺が必要ないなーとかって思ってたのは、あくまでもマストラとかでAIエージェントをプログラムで組み上げていくっていう前提になった時に必要ないなって思っただけであって、
例えば先ほど言ったみたいに、クロードのアプリの中に組み込みたいとか、こっちから組み込みが難しいところに対してMCPっていう共通のインターフェースがあることによって、
組み込みやすくなるっていうのがメリットなのかもしれない。だからマストラでの開発の時に必要ないと思うのはほぼ当たり前というか、なんかその通りみたいな。
だから結局AIにこういうやり方をやってくださいって指示できる環境だったら別に問題ないし、それこそ…
プログラムしてしとけるっていう前提だったんだよね。
前提だし、そう。
あとは、今クロードとかのチャット内でも、このAPIにアクセスしてくださいっていうのを細かく指示を書いてあげれば、もちろんやってくれるけど、毎回毎回それ指示するの大変じゃん。
間違うかもしれないし。っていうのを1個ラッピングしてあげて、説明書付きのサーバーとして用意してあげると。
まあ接続しておいて常駐させてあげる良さが、MCPの本質的な良さなのかな。
その、なんだろう、そんなプログラムとかを書かない人であっても、簡単にクロードのアプリに組み込めるっていうか、接続しとけるみたいな。
もう標準化して、誰でもどこでも組み込みやすくしようねっていうのが、プロトコルだしね。
MCPのPってプロトコル、比較。あくまでそういう標準化されたもの。
ここまでの税制条件が揃うと、よく比喩表現で、タイプCだよとかって言ってる人がいる、意味も理解できるね。
めちゃくちゃ混乱しかしない気がするんだけどね、MCPってAIにとってのUSBタイプCですみたいな。
あくまでも共通インターフェースとして提供しているっていうところの部分を切り取って、タイプCって言いたいんだろうね。
なぜあれタイプCって言ってるかっていうと、タイプCってあれさ、映像を転送するためだけにも使えるし、充電にも使えるし、映像じゃなくてデータっていうところもあるから、
あれって一本の行動の中に全部その規格が決まってるから、そういうことができるよね。
データのやり取りが、だからそれはタイプCの起源とか仕組みを知ってる人がようやく理解できる。ちょっとわかりづらいな。
誰もピンとこないよとか初めて聞いたときに思った。
俺だってあれだと思ったよ、口が全部一緒っていうぐらいで仕方ないけど。
口の形が一緒だからね。
そうそうそうそう。
それで言ったら他のUSB全部一緒じゃんみたいな。
確かに確かに確かに。
確かにHDMI的な役割もタイプCで果たせるしっていう、本当はいろんな口を差し替えないといけないのをタイプC一本でできるよねってなった革命を表現として使って。
MCPとして表現してて。
そういうことか。あの図を見て毎回わからねえなって思ってたわけですよ。
で、しかもマストラ自分で触ってさ、何の意味があるんだろうこれ。
だからどっちかというとマストラの開発をするのであれば、マストラを開発して出来上がったAIエージェントなりワークフローに簡単にMCPとして突っ込めるような仕組みを作ってようやくMCPの進化が発揮されるかもしれないね。
なるね。
あとは前回の話であったクラウドコードのプラグインじゃないけど、いろんな人がMCPサーバー用意してくれてるから簡単に使えるようになったっていうのももしかしたら良さではあるかもしれないけど。
そうだね。でも大きく技術革命っていうよりかは標準化したことによって全員が。
プログラム組めない人が使いやすいようにっていうところと、プログラムが組み込めないようなアプリとかに対しても共通インターフェースで接続しやすいようにしたみたいなのが。
そこが革命だよね。
やっぱ去年とかはまさにクラウドのチャットとかでいろいろやってたけど、毎回毎回情報入力しなきゃいけなかったから、MCP登場してすごく便利になった。
そう考えるとMCPって若干まだ未完成よね。だってさ、プログラムしない人にとって便利なツールだと思うよね。共通インターフェースでいろんなものに組み込みやすいっていう。
なのに、ちょっとこう、やらないといけないじゃん。コードで管理したりとか。
なんかちょっと、
指示書、MCPを自分でMCPを作ろうとしたら、多分その指示書とかは書かなきゃいけないし、どういうツールが、なんでしょう、そのMCPの中で使える、取得できる情報の一覧って何ですかとか、どうやって使えますかとか、やんなきゃいけないからね。
あとまあ一個課題、やっぱなんか使ってて思うのは、そのMCPで、その説明書付きって言ったけど、あの説明書付きって本当にただの説明書で、英語だったり日本語で、こういうリストが使えますよ、こういうふうに情報を取得してくださいね。
MCPの現状と課題
で、サーバーはこういうふうに、なんかレスポンスを返すので、AIはそれを理解して使って情報を整理してくださいねっていうだけなんよね。
だから結構使える、なんかその、AIってテキスト処理すると結構上手くなってるけど、たまに間違えるじゃん。
MCPを呼び出すのに失敗するっていうことは、結構あるよね。 だからそこがまだ、なんでしょう、MCPが完成されてないというか、課題がある部分なのかなと思うんだよね。
そういえばMCPといえば、クラウドクレアがさ、なんか新しい提言してたよね、型安全に呼び出せるMCPみたいなのかな、ちょっとあんまちゃんと覚えてないけど。
なんかMCPによりこう、MCPをより使いやすくするための、なんか新しい規格というか、を提唱してたよね、こないだ。まあ1ヶ月ぐらい前になるのかな。
あれってさ、まあマスター使ってても思うけど、正直今俺、リアクトルーターV7とか開発してるじゃん。
タイプスクリプトで。まあ俺は言われるがままにさ、型安全の方が安心だよ、いいよって言われて、俺はそれに従って片付けの言語をチョイスしてるというか、もう受動的にチョイスして、
まあ型付きの方がいいんだろうな、ちゃんと型指定してあげた方がいいんだろうなっていうので、俺はなんか1回目とかの話の時に言ったけど、より安全に進めたいっていうのがあるから、あの分かんないがゆえにね。だから言われる通り、型をしっかり全部つけてってやってるんだよね。
なんか結構ここの型がどんだけ重要なのかとか、今回のクラウドフレアのMCPでちゃんと型がついてできるみたいなとかの有用性。まあマストラも型安全にエージェントワークフロー組めるよねとかっていうのも、なんかあんまピンときてなくて正直。
型安全がどれだけ重要なのかみたいな。 そうそうそうそうそう。そこが理解できないとあれの革命さがわかんない気がしてて。
まあちょっと前提あるよね、多分クラウドフレアがどんな提唱をしたかって話をしなきゃいけないかなと思うけど。 あーそうだね。
だからあれはコードモードっていうのを考えましたっていう話。 MCPに対してはコードモードで実行するっていうやり方があるんじゃないのっていう話で、コードモードってじゃあ何って言ったら、
MCPを実行するときにコードを書かせればいいじゃんっていうのがクラウドフレアの主張。 今まではMCPって説明書付きでテキストで説明書と、
実際にリクエストするときもテキストでこういう情報を取得したいとかっていうの。 もちろんちょっとプログラマチックにJSONっていうデータ構造に当てはめてリクエストするときもあるんだけど。
イメージあるよね。今までMCPで単純に呼び出すのが電話をして呼び出すみたいな感じ。 だからある程度自由なところが、登録フォームみたいなのを自分で作って、
項目全部ガチッと決めた。登録フォームって決められたら項目しか送られないじゃん。 みたいな感じにしたらいいんじゃねっていうような提唱って感じかな。
そうそう、まさにそうかもしれない。MCP起動するとタイプスクリプト、型が付いているJavaScriptのことをタイプスクリプトって言うんだけど、タイプスクリプトのコードが提示されて、こういう形で呼び出してね、したらこういう型でデータ返しますよっていうのが。
だからサンプルコード付きMCPみたいな。 そう、そうなったイメージかな。で、AIはそれを解釈して、あくまでもコードを書いて実行するだけっていうのがAIの役回りになるのね。
で、なんでそれがいいのかってクラウドフレアが言ったかっていうと、さっきも言ったように、AIってテキストの処理かなりできるようになったけど、やっぱたまに間違える。
JSONでね、過去移行多かったりね、ペイント足りなかったりね。 けど、なんかもう、そもそもAIってGitHubのソースコードとか、もう膨大な数のコードの学習はもうすでにしてるから、コードを書くこと自体はすごく得意。
だったらコードを書かせてリクエストしてもらった方が良くないっていうところから来てて、そのコードモードっていうのが生まれたのね。
じゃあそのコードを書かせるために、だからコードサンプル付きのMCPってさっき言ったけど、そのサンプルを何でやるってやった時に出てきたのがタイプスクリプトだった。
なんでタイプスクリプトが良いのかっていうと、さっきそう言ってた型安全。 型安全っていうのは事前に型情報、その入力する時にはこういうフォーマットで入力してね、とか、処理してる間に取得できる情報もこういう型、なんでしょ、決まったフォーマットになってるよね。
数値じゃないとダメだよって、同じ位置でも数値の位置じゃないとダメだよって。 そうそうそう、同じ位置でも数値だったりさ、たまにはブーリアンとかストリングだったりとか、いろいろあるんだけど。
文字列とか審議値とかね、トゥルーフォルス、トゥルーフォルスもトゥルーフォルスが文字列なのか審議値なのか全然違うからね。
で、そこをカッチリ決めてるのがタイプスクリプト。 で、これやってあげると、今まではさっき言ったように、なんか文字列だと思ってたのが、数字で帰ってきた、でエラーが起きるっていうのを、なんかその防ぐことができる。
あーなるほど。 しかもAIに事前にそういうなんかフォーマットだよっていうのを型情報という形で伝えてあげることができる。
で、AIはコードを読み書きする、理解する能力には長けてるから、もうある程度そこを教えてあげれば間違いなく呼び出せる。
安定して呼び出せるし、しかもコードを実行するだけになるので、それってめっちゃ早くない?って。
今までだったら、なんでしょう、AIに文章を生成してもらって、それを呼び出してようやくAPIが叩かれてとか。
それってけど実行環境ってどうなんの?
AIと型安全の関係
実行環境はもうノードJSベースで、そのMCPサーバー上でノードJSが実行できるようにして、タイプスクリプトで実行するっていう。
これは考えを提唱したのか、そういう環境を含めて、何だろう、提唱というか用意しましたよっていう話なのかというと、考えを提唱したっていうこと?
一応ね、なんかサンプルのリポジトリとかも確か公開されてて、なんかその実際に叩けるものもあるみたい。
けどまぁ、あくまでも考えを提唱したって方が…
どっちかっていうとね、考えの方に重きが置いてあるかなって、俺はその記事を読んでて思ったかな。
確かに、エンジニアの僕からしてみれば、まあ当たり前じゃんみたいな。
そりゃそうだよねって思ってたけど、やっぱできてなかった、言語化できてなかったけど、整理してこういう形でやるといいですよねって提唱したのはやっぱ大きな意味があるなって。
なんか結構思ったのはあれかもね、何だろう、MCPを介して帰ってくるレスポンスの値の方が明確であるっていうのは結構俺はメリットあるなって思った。
そうだね。
それはワークフローとかを作る身として、AIワークフローを作るっていう時に、帰ってきた値が想定と、例えば分かりましたっていう文字が1個入ってたとか、分かりました、その後にJSON形式で帰ってきたとかってやられると、もう全部破綻するんじゃん。
それのないようにプロンプトで制御するしかなかったりとか、もちろん返す方を制御できるモデルっていうのもあったりするんだけど、パラメータで指定して、
LLMにリクエストしたら余計なこと言わないようにするみたいなのを設定できたりもするけれども、全部のモデルに対してそれができるわけじゃなかったと思っていて、今はちょっとわかんないけど、だからそういうので結構不具合があることがたまにあって、
それがちゃんと指定された方で送るし、指定された方で帰ってくるっていうのが結構重要だなって思った。
確かに。
そっちかもしれない。
AIだってわかりましたとかいかがでしょうかって指示しないのに勝手に行ってくるもんね。
で、もともとAPI的に使うからレスポンスはJSONで、もう決められたプログラム用のデータフォーマットで帰ってくるはずが、なんか別の言葉が入っちゃったみたいな。
それはなんかMCPとしてどっちかというと、LLMのAPIを叩くときとか、特に、俺が言ってるのはどっちかというとそっちかもしれないけど、確かに。
確かに、それをだから完全にもうコードで縛っちゃう。
で、しかもそれを読み取るときも型が決まってるから、AIが予知可能というか。
そうだね、どういうのが返ってくるかっていうのも予知可能だし、じゃあそれを受け取ってあとはプログラムで処理するときも、もう値が決まってるから、値の型が決まってるから、何でしょう、うっかりその別の本当は入っちゃいけないデータが入ってこなくなる。
確かに。いやガスでさ、ワークフロー組んだ時とかさ、結構大変だったよね。
確かに、あのね、Excelの、Excelのスプレッドシート上。
暗黙的に変わったりするじゃん。
そう、なんかね日付のつもりで入力してるはずがなんか、数値になってたり、あとは1分の2みたいな数量さ、例えば割とカジュアルにみんな書いちゃうんだけど、それスプレッドシートからして日付だよみたいな、8月2日だよみたいな。
そう、だからなんかそこが型エラーで落ちてくれるのかな。
多分実際に実行して、プログラムで処理するときに、MCPから返ってきた値が違ったらもう明確にそこで落ちるようになる。
そう、だからこれ日付じゃないよとか、これ数値じゃないよとかって言って返してくれるから、デパックもしやすくなるよね。
そうだね、呼び出すときも、例えばスプレッドシートから情報取得して、それをそのまま、なんでしょう、プログラム実行するときに入力値として与えたら、それ型違うよってエラーで落ちてくれるのがめちゃくちゃありがたい。
確かに確かに。なんか、なるほどね、確かにそう考えるといいのか。
いやなんか型安全ってだるい、だるいイメージもあって。
そうだね、あまり言語によって型がないってあるから、型がない言語で普段仕事をしてたり、プログラムを書いてる人にとっては、急にじゃあ型書いてやってくださいって言われると、結構めんどくさいってみんな口をそろえて言うんだよね。
でも、プロジェクトの規模が大きくなったり、扱うデータがいろんな複雑な構造、レイヤー構造とかを持つようになったりすると、
人間がいちいちその、この変更を加えてこのデータ構造が変わったら、別の場所に影響が起きるみたいなのを考えるのは結構大変になってくるんですよ。
けどその型っていう情報をまずテンプレートとして、プログラム全体で一個一個決めてあると、何か変わった時に、全体がもう、なんでしょう、型チェックをするプログラムは別にあるので、
この型変わったことによって、別のところで入力しようとした時に、エラー起きるよっていうのを全部検知してくれるようになるから、
まあ型があった方が、僕個人としてはすごく嬉しいかなって。
なんかそこが、ちょっと話変わるけど、
LSPっていうのかな、VS Codeとかに組み込まれる。
あれによって型安全であることのメリットが最大限享受できると思ってて、もちろんタイプチェックとかを実行してさ、
型安全じゃないやつっていうか、型エラーで落ちてくれるっていうのもあれだけど、多分よりいいのはそっちのLSPとかの補助、補完があって、
こそなし得るメリットなのかなって俺は思ってた。
LSPがあれから、ってことはLSPを使う上でめちゃくちゃいいってこと?
そうそうそう。
あ、そうだね、なんか型を。
そう、で、そうした時にAI駆動開発において、AIはLSPを別に十分に使えるわけではないじゃん。
そうだね、てか生のエージェント、AIエージェントは別にLSPの機能を持ってないからね。
そう、だし別にセレナとかLSPのやつあるけど、あれも別に型エラーを別に検知できるとかそういう機能はないわけで。
そうだね。
って時に俺はなんかあんまり、AIにしかコードを書かせないっていう前提の人間からすると、型安全ってどれくらい安全になるんだろうっていう。
もちろんタイプチェックを絶対回すし、CIで回した時にそういう型チェックとかで弾かれるから、実際に本番に行くまでにある意味フィルタリングされるから、あれなのかもしれないけど。
確かに。AIが書く上で別にLSP効いてるか効いてないが、AIは単純にテキスト置換でしかコードを書かないから、あんまり意味ないんじゃねっていう。
っていうのがすごく俺の中ではあった。
確かにな。でもどうなんだろう。
AIが解釈しやすいっていう立場だった時に、ちょっと理解できるかなって思った。
1個はそれだろうね。事前に定義されてるからAIが解釈しやすいっていうのはあると思う。
そばに型エラーめっちゃ出すからさ、こいつ本当に分かってんのかなって思う時もあるけどね。
全部のファイル見てくれるわけではないから、遠いところに定義されてる型情報を。
調査しやすいのか。
でもそれもなんでしょう。LSPをちゃんと使っていればだけど、コードジャンプもしっかり効くようになるんで。
それは人間的な話なんだよね。
型安全性の重要性
人間的なメリットのことで、片付け言語っていうのは進化していっているような気がしてて、そうした時に型安全であるメリットって。
でも1個あるのはやっぱり型って、例えば関数の引き数にこの型で受け取りますっていう、明記するわけじゃん。
それを本当にグレップ、検索かけてくれるから、型情報を調査できるっていうのは1個あるね。
LSP使った方が効率的でコンテキストの消費が少ないよっていうのはあると思うんだけど、
明確に1個あるとすればそこは、型があるからゆえに間違えにくい。
間違えるけどね、みたいなのさっき言ったけど。
そこは型エラーが出るから、そのエラーが起きて初めてAIが認識して直してくれる。
直す時も情報があるから取りに行けるっていう。
そういうサイクルが回せるようにはなりやすいけどね。
ただコーデックスとかだとね、めちゃくちゃコード内を分析する能力というか、
しらみつぶしに探してくれる能力がめちゃくちゃ高いって使ってて感じるから、
多分Rubyとか型がついてなくても割と特定してくれるなって感じは。
調査する時の材料の1個としては型情報っていうのは結構重要やもんな。
結局だからコンテキストの消費はできるだけ、何か効率よくしたい。
消費してほしくない。
そこで俺のもう1個の矛盾点があって、型情報をつけることによってコード量は多くなるじゃない、必然的に。
コンテキスト多くならないかっていうアレもあって、
いやそれって、もちろんこのAI駆動開発とかを本当の意味で推進してくれるのは、
今までエンジニアをやってきた人たちだと思ってて、
けど、無駄に過去に囚われてるような気もして。
なるほどね。
人間的やり方なんじゃないかって。
人間的やり方と、エンジニアサイドの人間的やり方と、
真のAI駆動開発の超効率っていうところを、
若干入り混じって考えてるのかなって俺は思ってて、すごい腑に落ちなかった。
確かに言われてみるとそんな気もする知的だけど、どうなんだろう。
俺はそういうふうに思ってた。真に効率的、コンテキスト効率もよく。
けど、もちろん安全にやるっていう前提に立った時に、
結局調査しやすいとか、人間も分かりやすいっていうのもセットだと思うから、
総合的に考えると確かに型安全であるっていうのは重要なんだけど、
タイプチェックでちゃんと通して全部エラー潰すっていうのもそうだし、
だけど、これは本質的にもっとAIが進化した先に必要な技術なのかどうなのかっていうのは、
すごい謎だなって思った。
そうなんだなぁ、なるほどね。
調査しやすくなるとか、コンテキストを自伝教養できる、
だから効率のことを考えちゃうと別になくてもいけるよねって話になるから、
無駄っていう考えは出てくるかもね。
コンテキスト効率が全てでもないからね、AI化の開発に関して。
デバッグしやすいとかね。
そこのメリットもあるから、やっぱあった方がいいんじゃないかなとは思っちゃうけど、
確かに大規模に型がない状態で開発することもあんまりないから、最近はね。
その比較ができていないっていうのがあるかもしれない。
一方であと、僕の考えとしては、必ずしも型をつけなければいけないとも思ってないから、
なんかそのプロジェクトの規模によりけり?
はいはい。
それはだからエンジニアのエゴだと思うんだけど、
なんかその、あんまり良い具合でやったらいいんじゃない?みたいな。
いわゆる適当って言うやつだよね。
エンジニアのエゴ。
ちょうど良い感じにやったらいいんじゃない?みたいなのが、
俺からすると、もうゼロ百なわけですよ。
やるかやらないか。
そう、やるかやらないかなわけですよ。
プロダクションとかで動く行動に関しては、絶対型がつけておいた方がいいって話。
俺の視点からすると。
ただ、やっぱりAIがあるがゆえに、ハキステの行動とかも結構あるじゃん。
ちょっとこういう作業してほしいとか。
そのくらいの規模だったら、あえて型なんてやってたら、むしろ型について考えなきゃいけない時間が増えるので、
やんなくていいって思ってる。
そっちかな。
だからそういう意味で分岐してるっていう。
なるほどね。
そこをちょっと言語化してもらわないと、僕は困りますよって話かもしれない。
すいませんでした。
そうそうそう、なんかね。
まあまあけど、とはいえレスポンスがちゃんと型で返ってきて、
予期しやすくなるっていうのは結構でかいってことね。
そう。だからまあクラウドフレアの主張っていうのは全うだし、
まあやっぱり今までのMCPっていうものが持つ課題をちゃんと解決する。
そんな盛り上がってなかったよね、これ。
そうなんだよね。
なんか、まあどうなんでしょう、盛り上がってないのかな。
あんま話題にならなかったな感はあったけどね。
実用で使ってる人が少ないとかもあるのかもしれない。
俺らとかはさ、実運用で開発とかさ、ワークフローとかを使おうとしてるじゃん。
試しでやる人からするとさ、この実運用上の安全性って別に、
今まだプロトタイプ段階というか、試し段階だよっていう時に別にそんなこと考える必要ないというか。
あんまね、なんかそのめちゃくちゃそのコードの実行品質を担保したいっていうのは、
まあなんか。
それこそプロダクション環境で動かす前提のコードをAI駆動で開発しようとしないと、なかなか。
かな、まあ。
あとインパクト少ないかもね。なんか多分、阿部ちゃんが一番初めに得た印象だと、
そのAIが失敗するからコードで書かせようっていう話じゃん。
けどAIが失敗するって言っても、何回かトライして成功しておるじゃない。
そう、だからまあ、意外とまあ今までのMCPでもいけちゃうから。
しかもだんだんね、ツールユーズの性能上がってきてるから失敗少なくなったしね。
そうそうそう。
そういう意味ではインパクトが少ないな、この挿入する。
あとまあ、MCPを作る障壁も若干上がっちゃうからね。
コードにしなきゃいけない、構造化しなきゃいけない。構造化するっていうのはなんか要は、
抽象的に考えて、こういう型っていうのを考えなきゃいけないから。
それはなんかだから、これもあるよね。さっきのタイプスクリプト、型がないのが方がいいよね、面倒くさいよねって言ってる人たちと、
型があった方が絶対いいよねって言ってる人たちがいる状況とまあ割と似てる感じで、
MCPは型がない、コードモードは型あるみたいな。
あれだな、なんか社内、多分ほとんどの会社が社内ツール利用だと思うよ、今。エージェントワークなのって。
その時において、別にそこまでの安全性を求めてないというか、っていう前提やし、
おそらくAIを使うって時点で、そこまでの安全性を求めないといけないことに使おうとしない気がする。
確かに。
今後、B2Bプロダクトに本気でMCP化していきたいとか、AIツール導入していく必要があるみたいになってきた時に、ようやく効いてくるのかもしれない。
確かに。あとはB2Bとかでもそうだし、自社のMCPを公開する時に、そのMCP失敗しすぎたら、品質のどうなんて思われるかもしれないから、
そこを担保するためのっていう話かもしれないね。
あと、誤った情報を返す。例えば、ほぼありえないけど、山本の情報を取得したかったのに、阿部の情報を取得しちゃったみたいな。
そんなことは起きないんだけど、そういうような、ちょっと思ったものと違う情報が返ってくるっていう可能性もあるよね。失敗してなくても。
確かに。
その辺を全部、それが型をつけて改善されるのかどうかはちょっと、はてなけど、たまに精度を上げられるっていうのがあるかもしれないね。
そうだね、だから。
コードにすることで精度を上げれるっていう方が近いか、型よりは。
そうだね。
プログラムの型があって欲しい人とあって欲しくない人の違いと似たような感じで、MCPも、コード、型があるなし、みたいな話なんかな。
けど、基本型がある方が、俺はいいと思ってんだけどね。
思ってんだ、結局。
システムにおいては。
ただ、そのメリットってAI駆動開発においてどんだけ効くんだろうっていうのが、エンジニアから言われてる、俺の周りのエンジニアから言われた情報としては過剰なのかなって思ってたって感じ。
MCPと実用性
前提として型をつけることは、なんか大事というか。
あと型をつけるのが大事っていうのは、これはもうどっちかっていうと人間的な話かもしれないけど、
物事を抽象化して、設計をちゃんとできていないと型ってやっぱりつけにくいっていうのはあるから、このシステムはしっかり設計されているのかっていう指標のためにも型は作っておく方がいい。
それはでもAI駆動開発をする時でも、結局人間のリアルの世界の情報をプログラムで処理するっていう意味では、
情報を構造化して処理しなきゃいけないから、やっぱり型ってあった方がいいのかなっていうのは、AI駆動開発になっても感じるかな。
まあそうだね。システム作りっていう観点でいうと、型がちゃんとついているっていうのは、俺も賛成なんだけど、賛成なのに一方で疑問点が払拭できずにずっといたっていうのを、
今日は少しは。
少し進展しました。
なんか理解が。
かなっていう感じ。
セレナとかがね、MCPでコードベースを詳細に調査してくれるセレナが、もっとLSPを活用してくれるようになったらいいんだけどね。
セレナ最近微妙だよね。
なんか言ってるよね、ずっと。
セレナって簡単に言うと、シンボルリンクって言うのかな。
シンボリックリンク。
シンボリックリンクか。シンボリックリンク。
シンボリックリンクじゃねえ。シンボリックリンクはあくまでファイル間の連携の話で、シンボル。
シンボルか。シンボルっていう関数の名前とかよね。
そう関数とか。
変数とか。そういうのの名前ベースで検索して、その関数の範囲内だけを見れたりとか、その関数のちょうど直後に挿入できたりとか、
帰還するとか、そういうのをできるツールを、LSP、VSコードとかだったらあるんよね、たぶん。
あとね、セマンティック検索って言って、意味的に近いものを引き出す。
関数名はあるんだけど、ちょっと似たような関数とかも引けるっていうのが、セリナの特徴かな。
そういうので結構有用というか、コンテキスト消費をできるだけ効率よくするっていう意味で、たぶん注目されてる。
そうだね。
それの付随機能として、メモリをちゃんと過去の記憶を貯めておくみたいなとかでできたりとか、そういうのもあると思うんだけど、
基本的にはLSPをAIに提供しようっていう思想のもとの作られたMCPだと思うんだけど、
シンボル置換がミスるんですよ。
てかあれ、セリナのバグなんじゃないかなって俺思ってるんだけど。
あれね、セリナでシンボル置換やったことが実はないか、気づいてないだけかもしれないけど。
シンボル置換やるとさ、例えば関数だとさ、括弧2つで閉じたりするじゃん。
ニョロニョロ括弧とさ、普通の括弧で閉じたりするじゃん、関数と。
あ、並括弧と普通の丸い括弧?
そうそうそうそう。
あれがね、余分に1個ずつ残ってたりするね。
それはシンプルに置換ミスってこと?
置換ミスってね。
それってけど、セリナのツールとしてのバグなんじゃないかなって俺思ってて。
そんな気がするね。
だから俺はセリナで置換を目撃したら、すぐさまそこを見て、片エラー出てるわと思って。
で、2つ消すっていう。
あ、消すんだ。
そこは俺が決して、もうわざわざ消してとか言っても、ちょっともうしゃーないから。
あ、そうなんだ。
そうなんですよ。ちょっとね、改善してほしいな。
括弧では出たことなかったんやけど、コーデックスになってからずっと使ってる期間が長いから、
括弧とコーデックスでそのバグが差があるかどうかはちょっとわかんないな。
少なくともコーデックスでは置換ミスってる。
なんかあれなのかな、MCPに書いてるツールの使い方が、コーデックスにとっては誤解を生む書き方になってて、
コーデックスは普通に使ってるんだけど、本当は多分、置換するときに括弧とか書かなくていいはずが、
書いちゃってるからセリナ側でも追加して二重、みたいな可能性がありそうだよね。
それはありそう。
なんでだろうね。
まあまあ、いずれにしても不満ですよ。
不満ですか?
セリナはやめようかなって思って。
ずっと言ってるよね。でもなんか、あんまりセリナからどれに乗り移るよって話で、
ないないない。
ないもんね、今。
まあなんかね、個人でLSPをちゃんとMCPで使えるようにしてるっていうのも最近出てきてるらしいし、
まあ試してもいいかなと思いつつ、まああいつが結構僕の中ではワークしてるから。
あとCypherだっけ?
CypherはけどLSPじゃなくて、どちらか記憶装置的な意味なんですよ。
まあ、ラグチックにちょっとできるみたいなイメージかな。
だからセリナのメモリーをもっと拡張したみたいな感じかな。
そっちか。だからLSPという側面ではほんまないのか。
どちらかというとラグ検索とかみたいな。
じゃあセリナを使うしかないかな、また。
はい。まあそういう感じですね。
あとまあこんな感じで、結構長いこと喋りましたね、今日は。
そうだね、今日長かったね。
まあこんな感じの、なんか他、まあいっか、もう今日はこれで終わりで、いいですね。
いいんじゃない?だいぶ一しきり喋ったんじゃない?
喋りましたね、はい。
じゃあこれで、はい、ありがとうございました。
またちょっと来週話しましょう。
はい、お願いします。
はい、お願いします。ありがとうございました。
ありがとうございました。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。
いかがでしたでしょうか。
リミットレスペンダントとAPIの重要性
今回の話題は、はじめはリミットレスペンダントについて話したんですけれども、
そこからAPIの話、MCPの話、
型つけるって結構有用なのかな、どんなのかなみたいな話とかに
ちょっといろいろ飛んでいきましたが、
お楽しみいただけましたでしょうか。
もしAI駆動開発、もしくはAIワークフロー作りとか、
そういったところでこんなことを話してほしいとか、
こういうトピックについて取り上げてほしいみたいなことがあれば、
ぜひコメントなどでお呼びいただければと思っております。
あと、ポッドキャスト気に入っていただいた方は、
いいね、フォロー、あと高評価、ぜひお願いします。
それではまた次回もお楽しみください。
じゃあねー。
