カーサーの新機能紹介
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う企業家の山本とエンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあ本日もよろしくお願いします。
よろしくお願いします。
じゃあ、あれですかね、Devinのドキュメントのやつが、ちょっととりあえずとっかかりの部分はできたみたいなところなんで、
はい、なんかそのあたりの話を聞けたらと思ってます。で、ただちょっとそれだけだったら、多分なんか時間的に短すぎると思うので、
なんか阿部ちゃん最近ね、Cursorの新しい機能を試したりとかしてたと思うから、なんかそのあたりの話とか聞けたらなっていうふうに思ってますので、よろしくお願いします。
一応ちょっと補足として、前々回ぐらいにドキュメントを自動更新していくみたいな仕組みをGitHub Actionsで作ったんですけれども、
プルリクエスト作成されて、そのプルリクエストの差分を見て、今回はドキュメントの更新が必要なのかどうなのかっていうのをAIが判断して、
そのままドキュメントを更新していく、必要に応じてみたいな感じの仕組みを作ったんですけど、
そもそもDevynのDeepWikiうまく使ったらいけるんじゃねみたいな話になって、で、ちょっとそこから阿部ちゃんに見てもらってたみたいなのが経緯にあるので、
ちょっと前提のところは2回前ぐらいのドキュメントを自動更新していく仕組みみたいなタイトルのやつを見ていただいたらと思います。
じゃあ早速話しますかね、成果の報告を。
もともとGitHub Actionsでやってたプルリクエストに応じてDevynが起動して、
ドキュメントの差分が必要かどうか判断して、必要なら修正してプルリクに反映してくれるってやつは、
結局Devyn動かすからお金かかっちゃうような話で、
この間話してるときに、今言ってたように内部のWikiをそのまま引っ張ってくればいいんじゃないかっていうことになったんで、
ちょっと試してみたんですけど、まずなんかやり方いくつかあるかなと思って調べてて、
まずDevynのAPIを叩いてそのまま取得できるのかなと思って、最初ドキュメントを探したりしてたんですけど、
基本的に公開されているAPIっていうのがセッションの立ち上げだったり管理がメインになっていて、
あんまりDeepWikiに対して何かできるっていうようなAPIがありませんでした。
そのAPIっていうのは起動っていうのはDevynを呼び出すとかそういう動いてもらったらダメなの?みたいな。
そうそう、だから今までの、今僕らが元々使ってたGitHub ActionsでDevynにドキュメント更新してっていうのも、
実はそのAPIを内部で使っていて、それでなんかセッション立ち上げて、プロンプトでこういう変更を加えたから、
ドキュメントのアップデートしてっていうのを元々はやってたんだよね。
だけどまぁ、内部のそのドキュメント自体を取ってくるのはできないので、
次に目をつけたのがMCPなんですよ。
はいはいはい。
で、MCPはDevyn WikiのMCPがまぁ提供されているようでして、
で、それしかもなんか2つ用途別々にあって、
なんか一つ目は、ほら、ネットでさ、Devyn Wikiで調べると、
リアクトとかいろんな主要なフレームワークのWikiをDevynが作ったものを入れたりするんだけど、
そっち向けのMCPと、
ディープウィキやったっけ?ディープウィキやんな、確か。
そうだね、名前としてはディープウィキかな。
あとは、僕らが今管理しているプライベートリポジトリとか、
そのDevynのアプリケーションにそのまま接続したリポジトリに関するディープウィキが見れるMCP、
この2つあって、でまぁ当然その内部の、
僕たちのリポジトリ専用のMCPを使って情報の取得をしようと、
いろいろデバッグとかして見てたんだけど、
これでできるのは英語のドキュメントを全部取得することは確かにできるんだけど、
最近ほら多言語化できるようになって日本語でドキュメント生成になったんだけど、
そっちの情報は取得できなかったんですよ。
どうしてもまぁ英語のみっていう制約があるみたいで、今のところはね。
じゃあ逆にそれができたらそれでMCP経由で取るってこともできたんだけど、
今はできてないみたいな感じのか。
そうだね、だからMCPとかAPI経由では難しいんだなっていうような状況になって、
とはいえドキュメントそのままそっくり引っ張っていきたいなってなった時に、
クニックの策ですけども、クローディング的な形でDevynのサイトにアクセスして、
自分たちのそのページにアクセスするようにトークンを入れて、
ページを表示させてその情報を取得するみたいな形で持って、
引っ張ってくるっていうワークフローをGitHubで組み上げるっていうような形にはなりましたね。
なるほど、けど実際としてはもう本当にそのまままるっと、
だからAIに考えさせるとかそういうのじゃないっていうことだよな、多分。
そうだね。
もちろんそのDevynウィキの方はもちろんDevynが生成しているものなんだけど、
あくまでもそれを引っ張ってきているだけみたいな状態にしている。
ビジュアルエディターの機能
そうそう、あくまでも引っ張ってきて、それをリポジトリに毎朝9時に引っ張ってきたものを変更があればプロリクエストを投げて、
マージしていくみたいな感じに今は運用し始めたっていうような。
それはプログラムでやってるの?
全部ね、そうプログラム、JavaScriptをGitHub Actions上で実行して情報の取得だったりをしています。
差分があったらGitHub Actions上でその判定を入れるようにしていて、
その判定が下ったらプロリクはGitHub Actionsのワークフローの中でそのまま送るようにしているっていう形だよね。
なるほど、GitHub Actionsのことが俺はあんまりちょっと理解できてないんやけど、
そういう毎日何時みたいなこともできるんや、タイマー的な。
そうそうそう、クールオンみたいなのがジョブっていうのかな、設定できて、
本当にクールオンと同じような設定の仕方ができるので、
例えば1ヶ月に1回も、1週間に1回とかもできるし、毎年とかそういうレベルでも制御ができるので、
結構まあ便利っちゃ便利。今までね、あまりこれ使いどころないなと思ってたんだけど。
あんまないよね。
そうだね。
だってまあ普通に考えて、今回プロリク投げるとかっていう前提があるからGitHub Actionsでやる意味が出たけど、
そのスケジュール機能的なやったら別にガスで回したらいいやんとか、
そういう他の何かありそうやもんね。
ありそうありそう、GitHubのだからなんでしょう、
GitHub Actionsでやってもらいたいことって僕らが何かアクションした時に、
例えばレビューしてほしいとか、
イベント駆動機能のものが多かったから今まで全く使わなかったけど、
確かにこういうデータをフェッチしてもらいたいみたいな、
いうタイミングでは結構効くのかなっていう。
でもそれで考えるとあれかな、今まで気にしたことなかったけど、
GitHub上に公開されてる、これは個人のリポジトリなんですけど、
日本の住所、Kenallっていう住所データを自動で引っ張ってきて、
API化するプロジェクトがあるんですよ。
あれとかもそういえば、言われてみれば1日に1回とかで、
確かKenallにデータ取得しに行って、
そのデータをGitHub Actions上で整理して、
データベースなのか何かに突っ込んで配信するみたいなことをやっていて、
そういう形で何でしょう。
僕らはいつもクラウドフレアのワークフローだったり、
それこそAWSとかいろんな実行環境を使って定期実行っていうのを用意してたけど、
意外と小さなものだったらGitHub Actions上でまたなっちゃう。
そういうことか。
システムで提供する範疇も含めてGitHub Actionsに押し込めるみたいなこともできるよねってことか。
できるね。
繋がったような気がするけど、まあそうだね。
確かに確かに。なるほど。
まあ、MCPでできたらそっちのほうが健全ではあるから。
どうなんだろう。
まあけど、MCPで取ってくるってことはAIが判断するってことになるから、
今のほうがバクッと取ってくるっていう方針のほうがいいような気はするけどね。
そうだね。まあ1回のリクエストで取ってきてるから、そこまで悪質なことはないかなとは思うし。
まあまあそうだよね。
そうそうそう。だからどうなんだろうね。
まあなんかクローリングいい悪いみたいな論はあるけど、あくまで内部利用っていうところもあるから、
一旦それで運用を始めてみようかなっていうので、とりあえず。
本当にね、1日に1回ルーリックとか眺めてると、大きな機能変更あったら、
それこそ2万行レベルでドキュメント更新されてたりするから、結構すごいな。
中身見てると、本当に新しい機能について詳細に書かれてる。
はいはいはい。
あとドキュメント生成がデビンチームのチューニングに預けられてる状態っていうのが個人的にいいなって。
そうだよね。
完全に僕らが更新してくださいって指示与えないでもいいし、
その中身についてどう考えることもなく、とにかくデビンチームが作り上げた、
チューニングされたドキュメント生成っていうのが提供されるので、
結構おすすめじゃないとは思うかなって思ってるけど。
そうやね。だしちょっと気に食わないところだったら、デビン側でプロンプトでチューニングはしていけるっていう。
結構ベースいいし、カスタマイズ性もあるみたいな感じで、いいよね。
それをリポジトリに反映するので、
AIにはそのウィキの情報をメモリ的に見てもらって、
現時点の仕様っていうのを把握してもらって進めるのが結構いいんじゃないかなと思ってるんだけど。
ただこれもちょうど今週反映したばかりなので、そこまできっちり運用に載せてられないから、
またちょっと経過観察的に良かったかどうかっていうのは報告できたらいいなと思ってるけどね。
なるほどですね。あと最近カーサーかな。カーサー最近アブちゃんなんか新しい機能使ってたよね。
そう、カーサーでビジュアルエディターだっけな。何ていう名前なんだろうね。
あ、そうだね。ビジュアルエディターっていう機能がカーサーに搭載されました。
これはなかなか良いですよ。今までカーサーでブラウザーを見たり確認すること自体はできてたんですけど、
あくまで内部でブラウザーを起動してプレイライトだったり、そういうMCP経由で情報を取得するのとあまり変わらず、
表示されている画面の中身をAIが認識できるっていうところで留まってたんですけど、
そこから一歩、二歩進んでフィグマのエディターみたいな機能がさらにブラウザに対して追加されたっていうような変化が起きました。
これ何が良いかっていうと、今開発しているサイトの見た目を表示して、そこにそのままカーソルを当ててクリックとかすると、
そこの表示のオブジェクトの情報みたいなのがビジュアルエディターっていうフィグマみたいな操作画面に全部反映されていて、
文字列の中央揃えを変更するとか、あとはカードのリストの並び順とかをドラッグ&ドロップで移動したりとか、
そういうのもインタラクティブにできて、かつその下内容がAIにそのまま反映されるので、UIの変更とか改善っていうのが、
マウスでポチポチクリックしているだけで簡単にできるようになったっていうのが新しい機能になっています。
使用方法の確認
どこにあるの?
これね、アジェントエディターみたいなのとエディターとあるじゃん、モード的には。どっちでできるんだろう?
どっちっていうことはないんだよね。これは、そもそも起動するためのボタンが用意されているわけじゃなくて、
ブラウザを開いてくださいってチャットで頼むと、
あ、そういうこと?
そうそう、経由で。
わめちゃんが楽しそうに使っててさ、俺、これどう、何なんだろうって思ってたよね。
そういうこと?ブラウザを開いてください?
そうそう、ブラウザを開いてくださいとか、ローカルホスト何千で開いてくださいみたいな指示を出したらようやく起動されるっていう。
あ、そういうことか。で、ブラウザが起動して、そこの中はユーザーが、俺側が一応操作できるしってことか。
だから別にローカルホストで開いてって言わなくても、ブラウザ開いてって立ち上がったやつに、自分でそこの検索窓にローカルホストの欲しいところに行ってポチポチするでもいいってことか。
それでもいい。で、実際の今本番で運用しているようなURL入力しても、AIに指示はそのまま与えられるから、一応それ上手いこと解釈して、この辺りの修正だなって理解して対応もしてくれるようにする。
そのビジュアルエディターみたいなのはどこからいけるの?ブラウザ今立ち上がりました、僕の手元で。
はいはいはい。
えっと、そしたらさ、今さ、何でしょう。URLを入力するような上の、まあ普通のアドレスバーあるじゃん。
うんうんうんうん。
あそこの右横に、なんかその矢印がついてると思うんだよね。枠に矢印マークみたいな。
出てこない。
矢印?ブラウザ、ブラウザの方やんな。
そうそうそう、ブラウザっていうのはあれだよ、カーサー内の。
カーサーが開いた。あ、カーサーない、なんか外部ブラウザ開いたね俺。
あいやいや、そうじゃないなそれは。カーサーの方でブラウザの方じゃん。
分かった、このチャットのところのブラウザタブで開くってしないといけないんだ。
あの、なんか、チャット、AIに指示出すところのさ、右下にコネクティットトゥブラウザタブっていうのがあって、
そこにGoogle Chromeとかブラウザタブとかみたいなのがあるんだけど、それを俺Google Chromeにしちゃってた。
あ、そっか、その設定も必要なのか。
そっか、ブラウザタブで開くようにしないといけないっていうのが前提条件だった。
はいはいはい、あれか、なんかどっかで設定、カーサーの設定項目で、あれか。
あ、今日チャットからいけた。
あ、はいはいはい、じゃあこれ多分ブラウザ開いてって言わなくてもいいわ。そもそも。
え、嘘?
うん。
どうやって開くの?逆に。逆にどうやって開くの?
なんかこのブラウザタブっていう方に、なんかGoogle Chromeって変えて設定を。
で、その後ブラウザタブに変えると、もう勝手に。
あ、開いた。あ、ほんとだ。
うん。あ、いけたいけた。
で、この矢印ボタンか。画面に矢印みたいなボタンね。
あ、そうそうそう。
うん。あ、移動できた。
そうそう。
なるほど。画面に矢印のこのボタンを押すと、
押したら青色になって、で、それをこうポチポチとすると、変えれるようになった。
そう、細かい移動。テキストの移動だったり、あとは大きい画像とかも別の場所に移動したりとか、ボタンの順番変えたりとか、結構自由にできちゃって。
なるほど、なるほど。で、これをアプライティブにすると、AIが勝手にこの通りに直してくれるんだ。
そう、アプライティブにすると直してくれる。
この機能よく考えられてるね。すごいね。
やっぱり一番大きいのは、ビジュアルエディターって言って、フィグマみたいな、何でしょう、デザインツールみたいなのが右で立ち上がってると思うんですよ。
テキストの、何でしょう、並びを中央揃え、右、左揃えとか、あとはピクセル単位の調整の窓とか。
これがあるがゆえに、細かい調整も効かせやすいし、その調整をプログラムがわからない人とかでも、
もう見た目をボタンポチポチでできちゃうっていうのがすごくありがたい。
これ結構すごいね、なるほど。
でね、なんかね、この間、これはね、まあモデルがシンプルに優秀っていうのもあるのかもしれないけど、
その、修正してほしいのを、この青い枠がさ、ハイライトつくから、ここをクリックしながらチャットに、
ここの部分を言語化して、今のUIの状態を書き出してくださいっていうと、
この中身をちゃんと見てくれるのか、結構そのUIの詳細情報までをきれいに言語化してくれるんですよ。
今までプレイライトとか、クロームデブツールのMCPとか使って言語化をお願いしても、
なんかそんなに詳細なところまで書き出してくれなかったんですけど、
今回このカーサーのビジュアルエディター経由でお願いをしたら、かなり細かいことまで書き出してくれて、
これをベースに、じゃあこう書き換えたいよねって話の議論を結構細かいところまでできたから、
UIの改善っていうのがやりやすくなったんですよ。
なるほど、なるほど。これって、今言ってるのは、別に何かを選択しなくても画面開いてるのって感じかな。
開いてる画面あるじゃん、ブラウザブで。その画面について、別に何かこの矢印ボタンを押したら選択できると思うけど、
選択せずともちゃんと把握してくれてるっていう。
いや、そこは選択が必要だったかなって。
AIによる修正機能
選択は必要、いやけど今俺試したらちゃんと画面構成把握してくれてるわ。
本当に?
だから今ブラウザタブで開いてるものはちゃんと認識してくれてるんだ。
じゃあブラウザで開いたものはコンテキストとしても与えられるんだろうね、きっと。
そういうことやね。
で、よりベージュ的にってなったらこの矢印ボタンでちゃんと選択して聞くみたいな感じか。
なるほど。これいいね、便利だね。
あとね、結構面白い機能がこの中にあって、
リアクトとかってプロプスでコンポーネントのUIをプロプスで書き換える。
例えばボタンの表示をアクティブからディスアブレにプロプスでステータスを渡して変更するっていう。
基本的にそういうふうに使うじゃないですか、UIの状態変更。
この状態変更をこのビジュアルエディターが自動でプロプス認識してくれて、
ドロップダウンでボタンのアクティブから非アクティブまで変更できるようなボタンもこのビジュアルエディター上に表示してくれるんですよ。
単純に今表示しているページの状態だけじゃなくて、
ユーザーが実際に操作した後のデザインとかもこの場でチェックできるようにちゃんとそういうのが反映されるようになってるみたいなんですよね。
これどうやってるのかわかんないですけど。
この画面自体を、しかもAIが操作もしてくれるってことだよな。
操作はわからないな。やってもらったことがないかな。
そうなんだ。
どっちかっていうと、ビジュアルエディターってフィグマっぽい見た目を介して、僕らが修正しやすくなっているっていう。
修正とか変更を加えやすいっていうのが大きなところだなって思ってますね。
今ね、ちょっとお願いしてみたので、クリックしてくれるかどうか。
一応こいつは了解です。まずこの環境のクリック操作が要素指定必要なので、クリックツールの仕様を確認した上でログインボタンを指定してクリックしますって言ってる。
クリック自体は実行できたが、次に何が起きたの?通信がしたのか。ネットワークリクエストでコンソールで確認しますと。
ちゃんと今押したっぽいね。
え、押せんの?
押してるっぽいよ。なんか操作今したっぽいよ。もう一回やってみよう。
あ、押した。押してくれてる。
すごい。
押してもらうときに画面に矢印の要素指定するようなやつにフォーカスを当ててると、あくまでもそれをクリックしたみたいな感じになるから、選択モードというかビジュアルエディターモードは解除した状態でお願いしないといけない。
はいはいはい。
うん、けどクリックしてくれるわ、このブラウザタブ自体。
じゃあカーサーがもうプレイライトみたいなの用意してんだな、中で。
うん。
すごいね。
いやまじでね、一段非エンジニアの人がいろいろデザインを調整したりとかっていうのはやりやすくなったんじゃないかな。
最近だとデザイン系の会社さんでマークアップとかお手伝いすることもあったりするんだけど、なんか俺いらないんじゃないかなって最近思って。
それは頼むからいる状態にしといてほしいな。
言っちゃったもん。これ僕いらなくなるんですけどこういう機能ありますって話してた。
すごいね。結構すごいなこれ。
あとカーサー関連で言うとデバッグモードを最近ちょっと俺も使ってて、デバッグモードも結構優秀で、
もともと俺が思ってたのって単純にプロンプトがデバッグ用にチューニングされてるだけかなって思ってたんやけど、
そうじゃなくて、カーサーがおそらくデバッグログをカーサー側で受け付けるようなAPIを用意してて、
そこにログを送信するためのコードを仕込んでくれるんよね。
だから大体バーって操作して、この辺が悪そうみたいなところにカーサー自身が自分でログ取れるようにログを仕込んでいってくれるのよ。
で、その上でこの操作を、このステップの操作をしてくださいみたいな、この要素をまずログインしてもらって、
ここの画面にアクセスして、ここの画面のこの要素をクリックして、次にこれを入力してください。
その上で送信してください。ここまでやったら教えてくださいみたいなのを指示書みたいな感じで出してくれるのよね。
で、それの通りに俺が操作するじゃん。
そうすると仕込んだログが勝手に発火して、カーサー側で受け取れるようになってて、ログが溜まると。
で、それを基に作業完了しましたって言ったら調査してくれるのよ、ログ見て。
それはどうやってそのログ取得してんだろうね。コンソールログとか、要はデバックログみたいな各言語のやつを
そういうのじゃなくて、多分APIを作ってて、だからポスト通信するコードを埋め込んでるっぽい。
カーサー側にそのAPIを用意されてて、そこに対してポストするような感じのコードを埋め込んで、
で、カーサー側で検知できるようにしてるっていう。面白いよね。
すっげーなそれ。
すごいよね。
これの機能の難点は、完全に調査が終わりましたで放置してると、仕込んだログのコードが残ったままになるから、
ちゃんと最後までクリーンアップしてくれって言わないといけないっていう。
それだいぶ気をつけないといけないよね。
そうそう、だいぶ気をつけないといけない。
あ、でもなんかそこまでエディターをやってくれる。なんか、何でしょう。
ジェットブレイン系のエディターとかだと。
レッドマインとか使ってたっけ?
レッドマインとかね。
デバッグモードの活用
あ、ブレイクポイントだ。
レッドマインとか、一応VSコードにもあるけど、ブレイクポイントみたいなのがっていう機能があって、
このコードを上から順にしていったら、このタイミングで止めてその瞬間のログを表示してあげますみたいなのが、
昔ながらにあるエディターの機能はあるんですけど、
それをさらに一歩、その情報をそのままAIに投げてくれるみたいな感じがして。
すごいよね。結構すごいと思う。
カワソウの最近出す機能、なかなかすごい機能が多いよね。
そんな感じですかね。他なんかある?最近の。
スキル図がめっちゃ…あ、そうだ。その前に、ゴスティ?
ゴスティね。
ゴスティを試してみたんですよ。
ゴスティっていうのが、ターミナルなんですけど、
G-H-O-S-T-T-Yでゴスティっておそらく読むだろうと思ってゴスティって言ってるんだけど、
これがすごいクロードコードとか扱うときにいいみたいなのを言ってるのをXで投稿してる人を見て、
何がいいんだろうって思って調べたんだけど、何がいいのかわかんなくて。
おそらくGPUで描画する前提の設計になってるから、
描画とかその辺が速いとか、その辺なのかなって。
あとジグ言語っていうやつを使ってるらしくて、結構高速で起動してみたいな、レンダリングも結構すごいスムーズですみたいな書いてたから、
その辺りなのかなっていうふうに思って。あと画像表示ができるとかね、GPUベースのようなのから。
みたいなのが、一応ザッと調べた中で出てきたんだけど、実際に使ってみて、
コーデックスとか使ってるとさ、上とか下とかカーソルを移動するとさ、文字化けみたいなのして動かなくなるやつあるじゃん。
ちょっと俺まだ使い始めて2日ぐらいやから、完全に絶対にとは言われへんけど、あれが何やねん。起きなくなった。
何が違うんだろうね。
よくわからんけど。
あれ自体が何で起きてるのかよくわからんけどね、そもそも。
あれね、IMEの入力に何かバグがあるのかなとか思ってるけど、
日本人だけの固有のバグなのか、全世界で起きてるものなのかもよくわかんないから。
一応それ以外にもGhostyのちょっといいところみたいなの書いてて、調べたらあって。
例えばクロードコードのフックスでさ、完了通知音鳴らすとするじゃん。
Ghostyと通知機能
で、Ghostyの機能で通知音を送ると、それでポチって通知きたから、完了しましたってきたからそれをポチって押すと、
TMAXのあのペインが、その該当のペインのところにフォーカスされた状態で立ち上がる。
それすごいね、どうやってんだろうね。
完全に分割しててもそのところに行くの?
って書いてた。ちょっと俺試してないからわからんけど。
調べてたらそういうことができるみたいなことを書いてた。
そう、だからGhostyいいんじゃないかなって思ってるんで、ちょっとだけ試しておこうかなって。
ちなみに今までItem2使ってて、最近はずっとKittyを使ってて、今Ghostyにいってるみたいな感じなんで、
KittyもItem2も両方文字化系の問題起きる。
純正のやつでも起きるし、なぜかGhostyだけに乗る。
ちょっとまだ長期間使ってないから実際にどうなるかわからんけど、みたいな感じですね。
それがちょっと俺の最近の気づきというか。
あとはスキル図いいよねっていう話?
Ghostyで画像レンダリングできるのか、どんぐらいの解像度でレンダリングできるのかめっちゃ今気になってたけど。
ちょっとその話はまたおいおいにしよう。
スキル図かな。スキル図自体登場したのはいつ頃なんだろう。
結構前だね。
クロードコードにスキル図が登場したっていうのは知っていたんだけど、2ヶ月くらい前かな。
そもそもクロードコードあの時あんま使わなくなってて、コーデックスがメインだったのかな。
ちょうど2ヶ月前だな。最新アップで10月17って書いてるから。
ちょうど2ヶ月前だね。
だからあんまり触ってなかったんですよ。
そんなスキル図って何がいいのかなってわかってなかったんですよ。
なんでかっていうとスラッシュコマンドでやってほしいことを細かくプロンプトチューニングして書き込めば、
それなりにちゃんと動くっていうのはスキルが登場する以前から成功体験としてあったんで、
あえてスキルって必要なのかなって思ってたんですけど、
最近クロードコードを使う、また戻ってきて触ってて、
まずスキルの前に感じた課題っていうのが、
MCPめっちゃコンテキストク問題があって、
それは羽生ちゃん言ってるよね。
僕とかはいろんなプロジェクトでいろんな言語とかいろんなツールとかを使ってるから、
とにかくどんどんどんどんMCP使って、便利なものは入れて、
AIが働きやすくできたらなと思って、どんどんMCP入れてたんですけど、
ある時気づいたんですよ。
MCPってクロードコードを立ち上げた瞬間に、そのMCPの使い方、
各MCPの使い方がコンテキストとして注入されていて、
すでに起動した時点で、10何%とか20%とか、
下手したら40%ぐらい、コンテキストウィンドウ圧迫してるみたいなところからスタートになるっていうのに気づいたんですよ。
それはどうも使ってて一瞬でコンパクト走るなぁみたいな感覚があって、
調べてた時に気づいたんですけど、
MCPってそもそもタスクの性質によって、
使うものと使わないものって結構分かれるじゃないですか。
例えばバグの調査をする時って、
それこそさっき話したリニアのMCPだったり、
ノーション、バックログの、
いわば課題が上がってくるところを見に行くMCPを使うと結構便利だったりするんですけど、
単純に自分が新規開発したくてテキストを入力してる時って、
別にそのMCP使わないじゃないですか。
けどそれのオンオフとかっていうのがあまり簡単にできないので、
とりあえず起動してMCPでコンテキスト食われて積んどく状態で、
でも全くMCP使わないからただ無駄になってコンテキスト消費してるみたいなのが、
ずっとクロードコード使っててもやもやしてる部分だったんですよ。
それ解決するためにどうすればいいかなっていうふうに探した時に出てきたのが、
エージェントスキルっていう一つやり方で、
スキルっていうのが、
単純にそのマークダウン、テキストファイルに、
こういう作業をする時はこういう知識が使えますよっていうのを、
テキストで入力しているだけっていうのが、
基本的なスキルの機能にはなってるんですけど、
一つ特殊している部分は、
スキルに記載する本文の前に、
ヤムル形式でそのスキルの名前と概要をディスクリプションという形で書き込めるんですよ。
これってあれよね、前提としてそのスキルのディレクトリを切れる。
だからファイル単位じゃないよね。
ファイル単位じゃないね。
ディレクトリ単位でスキルは管理することになる。
そういうことだよね。
クロードは起動した時に、
そのスキルの一覧をバッと見て、
本文とかディレクトリ内にあるファイル全部を見るんじゃなくて、
まずは名前とその概要だけを把握して、
こういう専門知識があるんだなっていうのを、
軽くインプットした状態でタスクを始めてくれるんですよ。
それがスキルMDに書くっていうことだよな。
そうそう、スキルMDっていうのがエントリーポイント、
各スキルの一番最初のエントリーポイントになる部分。
そういうことだよね。
だから料理スキルっていうディレクトリを切ったら、
そこには確実にスキルMDっていうファイルを入れて、
そこの中に書くっていうのが今の話ってことだよね。
そうそう。
スキルMDの中に本文で詳細なことを書くだけじゃなくて、
概要としてYAMLで書けるので、
それを読み込んでくれるっていうのがスキルの概要にはなってるんだけど、
MCPとは決定的に違うのは、
起動時点で読み込むコンテキストの量がスキルの方が圧倒的に少ないんですよ。
その概要だけだからね。名前と概要だけだから。
MCPとかだとそのMCPの概要だけじゃなくて、
書く使えるツールが何があるのかとか、
そのツールはどういうものなのか、
っていうところまでも全部読み込んでスタートしてしまうので、
コンテキストを圧迫しちゃうんだけど、
スキルは今言ったように、
エージェントスキルの利点
概要だけをサラッとなめて起動するっていう状態。
インデックスしてるだけみたいな感じだね。
そうそう。
しかもそのスキルってスクリプトの実行とかもできるようになってるので、
例えば料理スキルっていうディレクトリを切って、
スキル図にその料理ができる人のトランプ等を書いたとして、
例えばその料理に必要なプログラムを実行したいっていうときのユースケースとかもそこに書いて、
で、同じスキルを使って、
スクリプトの実行とかもできるようになっているので、
スクリプトを配置しておけば、
それを呼び出して実行するっていうこともできてしまうので、
スクリプツだよね。
スクリプツかな。
実質、MCPをスキルでだいたいできちゃうっていう。
しかもなんかテンプレートとかも、
スキルを使って、
スクリプトを配置しておけば、
それを呼び出して実行するっていうこともできてしまうので、
しかもなんかテンプレートとかも用意できるんだ。
これ結構、なんか要件定義とかもこれで、
templates.txtでできるって書いてるね。
はいはいはい。
テンプレートっていうのもあるんだ。
そうは知らなかったな。
テンプレート、なんかその、
マイスキル、料理スキルのディレクトリ切って、
スキルMDに概要書くじゃん。
それだけリクワイヤードで、
他はオプショナルで、
examples.md、
スクリプツの中に、
なんか何かしらのスクリプト。
で、テンプレートの中にテキストファイルで、
template.txt、
おそらく.mdとかもできるんだけど、
やろうけど、みたいな管理ができるみたい。
テンプレートって何に使えるんだろうね。
例えば要件定義でさ、
こういうふうな、
フォーマット?
フォーマットにしてほしいみたいな、
そういう話かなって思うんだけど。
それができたら、確かに。
こういう回答をしてほしいですっていうのも、
スキルに詰め込めるからいいよね。
めっちゃいい。
ちょっと脱線しちゃったけど、
そのスキルを使うことで、
そのmcpみたいな初手でコンテキストクールっていうのを、
完全にスキルの中に、
例えばバックログのスキルを作って、
APIのアクセスの方法、
アクセスするためのスクリプトは事前に用意しておいて、
そのスクリプトの起動の仕方っていうのを、
スキルMDに書いておくだけで、
必要になった瞬間にAIが、
そういえばバックログのスキルあったなっていうのを思い出して、
それを使ってくれるんですよ。
だから初手でコンテキスト圧縮せずに、
mcp的に外部にもちゃんとアクセスできるっていう、
その状態を担保できるので、
結構使い勝手がいいなっていうふうに。
ちなみにこれサンプル見てると、
Pythonコードがスクリプトに入ってるんだけど、
これって他でもできるの?Pythonだけ?
いや、何でもできる。
要はスクリプトっていうところに、
そのスキルが使うプログラムを配置するっていうルールだけで、
言語は全く問われない。
例えばだからスキルMDに、
この言語でこういう実行してくださいって言うだけだから。
今開発しているプロジェクトのスタックによるってことか。
そうだね。どうしたいかによるかな。
そういうことか。だからうちみたいに、
リアクトでやってたらタイプスクリプトで実行するように、
みたいな感じになるかな。
そうだったね。僕だったら、
今はタイプスクリプトでプロジェクト管理してると思うので、
BANっていうツール使って、
高速に起動してもらえるようにっていうので書いてたりしてるんだよね。
なるほどなるほど。
それはいいですね。
しかもそのスキルのいいところは、
サブエージェントっていうのをクロードコードって定義できるじゃないですか。
あのサブエージェントの中にも明示的にこのスキルを使いなさいっていうのを指定することができて。
なるほどね。
だから例えばコードレビュー。
例えばタイプスクリプトのプロジェクトでコードレビューのエージェントを作ったときに、
コードレビューで必要になるようなスキルって結構いろいろあるじゃん。
命名とかアーキテクチャーとか、
それを全部エージェントの中に書き込むんじゃなくて、
スキルとして切り出しておくことで、
何でしょう、汎用性が高く使い込めるんですよ。
例えば命名のスキルって別にコードレビューだけじゃなくて、
実装するときも必要じゃない。
だからスキルとしてもっと書き出しておいて、
それぞれのエージェントに組み込んであげることで、
汎用的に使い回せるっていうのも結構推しポイントなんですよね。
はいはいはい。なるほどね。
だからまあそういう意味では今まではエージェントっていうのが中に全部詰め込んでたけど、
結構明確に役割分担ができるようになったって感じ。
なるほどなるほど。
なんかスラッシュコマンドの役割が本当にあれだね。
だんだんどっちかというと初手のいつも与えてる指示めんどくせえな、
ちょっと置いとくスニペット機能ぐらいにしかなくなってきてるね。
そうだね。なんか初手のトランプと、まあそうだね。
あとね。
基本サブエージェントで起動したいじゃん。
そうそうそうそう。
結局。
確かにプロンプトチューニングするところは多分スラッシュコマンドに入れてって、
どういう風になんでしょう、どういう指示を与えたいかっていうのは、
スラッシュコマンドに寄せていく感じになるのかな。
まあでもそれも正直サブエージェントにどんどん変えていくこともできはするから、
ちょっと役目が減ってきてるかなっていうのは。
なんかそうやんな。なるほどね。
あと最近はね、さらにルールズっていうのが登場したよね、クロードコード。
なんか盛り上がってたね、X。
本当?
うん。
カーサーの新機能
これもなかなか良くて、ルールズは特定のパターンに一致したファイル。
例えば.tsっていうファイルに一致したときだけ呼び出されるプロンプトみたいな。
一致したときっていうのはその読み込んだときってこと?
そうそう、なんか編集するときなのかな。
どっかのトリガーでこのファイルに触ったときに意思メモリーとして与えられるっていうような。
.mdとかだったらみたいな感じか。
Mazeの書き方こんな感じだよみたいな。
そうそうそうそう。
だからそのファイルとか、あとはディレクト、例えばすらパッケージに触ったときはパッケージのアーキテクチャの情報だけがパッと入ってくるみたいな。
こういう細やかな制御ができるようになったんよね。
それ結構デカいね。
そうそうそう。
クロード.mdが肥大化せずに済むね。
クロード.mdは本当に中核のなんでこのプロジェクトが存在するのかとかを書くだけでいいぐらいになってきて。
ルールとスキルに預けて、しかもそれは毎回読まれるわけじゃないからコンテクシスが無駄に消費されるわけではないと。
だからクロード.mdにはどっちかというと本当に核となるお願い事を書くだけ。
管理大変になってくるね、だんだん。
まあそうね、どこに何を配置するみたいな悩みがちょっと増えてくるよね。
今の話聞くと悩むこともなさそうだけど管理は大変そうだなって感じかな。
整理は今までよりはしやすくなったような気がするけどね。
いや、というよりは今まで1箇所にぶち込むだけだったけど。
みんなで統一してみたいな感じでね。
そういう意味で、できることが増えたから管理が大変になったって感じかもしれない。
俺逆にクロード.mdとかがすごい文章量になってるプロジェクトとかも見てたから、
これをそれなりに1000行くらいになったやつの中に新しいルールを追加したい時に、
どの辺に追加しようかなみたいな悩みがさ、
セクションの切り分けとかが微妙にミイシーじゃなくて、
いや微妙だなみたいな思ったりもしてたから、
そういう悩みからちょっと解放されやすくなるのかなって思ったね。
スキルとかルール図っていうのはね、
このフォルダにはこういうルールっていうのはもう明示的に切り分けることができるし、
こういう作業する時はこのスキルが必要っていうのはもう明確に分かれるから、
確かにファイルとかいろいろ煩雑になったりとかもあるかもしれないですね。
なんかそうだな、ちょっと煩雑になるなっていう感覚はあるけど、
どっちかというとできることが増えていくからって感じかな。
てかコンテキスト効率を上げるためにできることが増えるみたいに近いかもしれないけど。
そうだね。どちらも基本的にはコンテキスト効率のアップに繋がるんだな。
あんまり質に対するというよりはコンテキスト効率、
それがイコール関節的には質に繋がってくるけど、そんなイメージだな。
あとはスキルが最近コーデックスにも取り込まれて、
コーデックスでもスキルが使えるようになったっていうのは嬉しいですね。
なるほどね、確かにそれも嬉しい。
共通でできるのは嬉しいね。
もしかしたらMCPのあり方がまた変わってくるんじゃないかなって。
やっぱりコンテキストみんな気にしてたりするから、
今の状態だとかなり圧迫感があるので、
例えば初回の起動時は控えめになるとか、
もうちょっと比較レベルで仕様が変わってきたりするんじゃないかな。
それかみんなスキルにどんどん移動していくのかっていうのが僕としては嬉しい気がするね。
なんかけど、コーデックスそんな感覚ないのはなんでやろうな。
そこがね、僕も謎ないよね。
圧迫してる感ないよね。
圧迫してる感ない、初手の読み込み時で。
まあコーデックス使ってて基本的にあんまりコンパクト走らないし、
確信に迫るのが上手いからね、コーデックスの方が。
割と直球に向かってってくれてる感は、
あっちこっち悩みながら進むよりかは。
そうなんよね。なるほどね。
まあちょっと引き続き使っていきましょうって感じですね。
あとこのクロードコードのエージェントSDKが何なのかが気になってる。
今さら。
おそらくクロードコード自体は汎用エージェント的に作られてるから、
それをなんか自分好みにというか、
ちょっと非エンジニア的な使い方も含めてできるようになりますってみたいな話なのかなとは思ってるんだけど、
拡張していくというか、どういう住み分けなんだろうって。
ので、ちょっとそれも調べてまた話しましょう。
全然違うかもしれないし、調べてみたら。
なんかでもあれなんかマストラみたいな感じなんかなーって思ってたけどね。
そうそう、そんな感じ、俺もそんな感じのイメージで思ってるけど、
ある程度のことクロードコードでできちゃうじゃん、とはいえ。
そうだね。
だからちょっとなんかどんな感じなのかなーっていうのが気になってるっていう感じですね。
ちょっとそれはまた次回以降とかで話しましょうか。
はい。
じゃあぼちぼちいい時間なんで、
今日はザックバランにやってることを細々話すみたいな回になりましたが、
はい、じゃあ本日もありがとうございました。
ありがとうございました。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。
はい、今回はですね、ちょっと結構いろいろな話題に触れましたが、
はじめはDevynのウィキですね、
こううまくプロジェクトに取り組んでいく方法を、
ちょっと最終的にっていうわけではないですけども、
ちょっと取り組み始めましたよみたいな話から、
カーサーの話ですね、
ビジュアルエディターとデバッグモード、
結構いいよねっていう話をして、
その後にGhosty Terminalを使ってみて、
文字分けの問題は起きないからいいねっていう話をした後に、
クロードコードのスキル図のお話をしてっていう感じで、
プロジェクト管理の効率化
かなり多くのトピックについて話しましたが、いかがでしょうか。
他にもこれ気になってるから、
お話してほしいんだよねとか、調べてほしいんだよねみたいなことがあったら、
ぜひコメントでもいいので、
要望いただけると大変嬉しいです。
もしこのポッドキャスト気に入ってくれた方は、
いいね、高評価、フォローぜひよろしくお願いいたします。
それでは本日以上できればと思います。
ではまた次回もお楽しみください。バイバイ。
