プラグイン機能の導入
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う企業家の山本とエンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。
はい、ということで、今回もよろしくお願いします。 よろしくお願いします。
最近出たニュース、ちょっと早速本題みたいな感じなんですけれども、ニュースについて話したいなーと思っていて、
ClaudeCodeの新しい機能で、プラグインの機能ができましたと。ちょっとこれについて、どんな可能性があるのかみたいなところを話していけたらなというふうに思っています。よろしくお願いします。
お願いします。プラグインの機能が追加されたんですね。
これ簡単に言うと何かというと、今までフックスとか、あとエージェント、コマンズとかいろいろあった、スラッシュコマンズとかいろいろあったと思っていて、
あれを今までは個人個人とか、もちろんGitHubで管理して、プロジェクト内で管理するみたいなことはできた部分はあったんだけれども、
あくまでもそのプロジェクトに自分たち設定していかないといけない。もしくはルートディレクトリに設定しておかないといけないみたいなことがあったんだけれども、それをプラグイン的に導入できるようになるっていう機能ですね。
結構多分組織開発とかそういうのをするとか、あとは例えばすごくみんなが注目しているインフルエンサーの人が使っているフックスとか、スラッシュコマンドとかエージェントとかを実際に公開してもらえたら、それをプラグイン的に導入できるみたいな、
そういう機能なので結構広がりがあるプロダクトとか機能になるのかなというふうに個人的にすごいいいなというふうに思ってました。
で、ちょっとこれをこの話する前に一旦あれですかね、僕たちがどういうふうに今までは管理していたのかみたいな話をして、その辺楽になるよねみたいな話で盛り上がれたのかなというふうに思ってます。
これ実際はクロードコードのあくまでもプラグイン機能だから、我々はCodexなのでまだ恩恵を享受できない。
Codexが頑張ってくれたら恩恵を享受できるようになるんだろうけれどもみたいな感じなので、そういう方も結構いるのかなというところで、僕たちなりの今の運用方法みたいなのを紹介ができたらいいのかなというふうに思ってます。
その前の前提としてこういうふうに共有できたら、やっぱり会社としては、スラッシュコマンドとかエージェントの定義とか、コーデックスはできないけどエージェント、フックスもコーデックスはできないけど、できないこと多いな。
なんだけれども、資産にちゃんとしていける。だから一人のバリバリ使いこなしてるエンジニアだけの知識というか資産じゃなくて、会社全体の共有財産にできるというのが結構でかいのかなというふうに思ってます。
実際に僕らもね、僕がスラッシュコマンドを更新したら、今コーデックスでしか運用してないけど、コーデックスもクロードコードもマスターのスラッシュコマンドみたいなのをGitで管理していて、それをプッシュするとみんなに配信できてきて共有できるよねっていう使い方をしてるよね。
厳密にはクロードコードはスラッシュコマンドだけじゃなくて、エージェントとか。
フックスとかもね。
一緒に共有してるっていう感じなんですけど。そんな感じなんですけれども、社内的に打ちたるとどういうふうに管理しているのかみたいなところを、それをちょっと説明した上で、プラグインだったらここまでしなくていいよねみたいなところで、どういうメリットがあるのかみたいな話ができたらいいのかなっていうふうに思っているので。
できるだけ具体的な情報を知れた方がいいと思うので、どういうふうにGit管理しているのかっていうところの説明を阿部さんお願いできますでしょうか。
わかりました。僕たちがクロードコードでみんな共通のスラッシュコマンドとかそういったものを管理するときにどういうふうな流れだったかっていうところだと、
まずその共通のスラッシュコマンドとかっていうのが、Macのルートディレクトリの配下にある.cloudっていうフォルダーの中で一括管理できるような仕組みがそもそもクロードコードの方で提供されています。
このルートディレクトリ配下の共通の設定っていうのは常にスラッシュコマンドとかそれこそフックスとかの設定を書いていけばいいんですけど、
これはチーム開発、チーム全体で共通化していくっていうためにはやっぱりGit管理をしなければいけないのかなっていうところで1個課題がありました。
最初僕がそういうふうにプロジェクト共通のスラッシュコマンドとか作っていたのを他のメンバーに共有するためにまずリポジトリを作って、それを.cloud配下でそのまま管理をするように始めました。
チームメンバーに共有するにあたってはみんなそのGitをクローンしてもらって.cloud配下の部分にファイルを取り込んでもらうようにするんですけど、このとき管理を楽にするためのツールとしてGHQっていうGitの管理ツールを使ってました。
GHQとかを使うとGitHubのリポジトリを簡単に取り込めることができますし、.cloud配下に移動することも簡単にできるので、そちらにそれを使ってまずGitHubの共有をしてもらって取り込んでもらった上でそこの.cloud配下の更新を各々みんなして、
更新したらリポジトリにプッシュしてもらってみんなプールすることで全体に共有されていくっていう仕組みを作ったっていうのが結構大きな流れなのかなと思います。
あとあれかな、GHQで管理するときのコツみたいなところで言うと、GHQでGitを取り込むときってroot directory配下のGHQフォルダーの中に全部のリポジトリが一元的に管理されるんですけど、.cloudはGHQのフォルダーの中には入っていない、当然入っていないっていうところがあるので、
そのままGHQで管理するとファイルの場所が異なってしまう。cloudコードが期待しているフォルダーにリポジトリが降りてこないっていう問題があるので、そこはGHQの設定をGitのコンフィグで変更することができるので、
Gitコンフィグを修正することで向き先をGHQでクローンしても.cloud配下に向き先が変わるように設定をして管理しているような形で今運用しています。
依存パッケージの管理
GHQ便利よね。知ってる人も多いかもしれないけど、GHQもし知らなかったら本当にコントロール括弧とかでショートカットで、今GHQで管理しているリポジトリ一覧が全部バーって出てくるから、それで選んでペッて押したらそのリポジトリに一気に飛べるっていう、すごい楽だなっていう。
GHQの主要な機能はやっぱりリポジトリを、なんかリポジトリってGitHubのリポジトリだけじゃなくて、GitLabとかあとはAWSもリポジトリ作ることができるんだけど、そういうのを全部GHQフォルダーの配下で一元管理できるっていうのは。
どっちかっていうとそのためのもので、そのさっき言ってた括弧で管理しているリポジトリの一覧出すとかっていうのは、なんかPECOっていう機能。ファイルのリストを取ってきて、それをPECOでファジファインドできるようにしているっていうだけだから。
GHQのあれじゃないの。GHQの中の管理化をPECOで自動で取れるようにして。
そうそうそうそう。どっちかっていうとそれで便利になってるよね。でもそうするためにはやっぱりGHQフォルダーの中に全リポジトリが、管理している全リポジトリが一元的にあるっていう状態を作るのが重要だから。
そういう意味ではまずGHQで管理する。かつPECOとかで検索してディレクトリに移動するっていうのを楽にするっていうのを僕らはやってるよね。
それでGitConfigでルートディレクトリに貼れるのも便利よね。
クライアントによってはそもそもリポジトリをルートディレクトリ配管に配置しておかないと動きませんみたいな案件とかもあるんですよ。
これはプロ機種の設定とかいろいろあってそういうふうにしてくださいみたいな形になってるんだけど。
それもちゃんと貼れるからいけるってことか。
結構関わってる案件とか作ってるソースコードが多ければ多いほどリポジトリの管理っていうのがどんどんどんどん煩雑になってくるから。
やっぱりこういうときにGHQはめちゃくちゃ便利かなっていう。GHQの話になっちゃうけど。
儲け度でいいと思います。
でもAIがやっぱり今盛んに、AI駆動開発っていう前提になった時期にいろんなこう、
ビルドアンドスクラップではないけど、いろんなプロジェクトを作ったりっていうのはより。
活発になるよね。そうなるとプロジェクト管理が結構肝になったりとか、どのようにすぐ切り替えれるかみたいなのが結構重要になったりとかするよね。
育てるとNixとかそういうのも便利になってくる。
パッケージマネージャーという意味では多分Nixとかが重要で、やっぱ環境依存が少ない状態で、
プログラムを管理できる、ソースコードの依存しているパッケージを管理できるっていうのは結構思想としてはNixいいんじゃないのかなって。
確かにPCスペックはいるけど。
めちゃくちゃPCスペックいるね。
スペックはいるけど。
ストレージ。
不合的に使うから、もう管理するパッケージはスナップショット取って、全部マウントディレクトリに配置しとくみたいな。
不合的にってあれね。大不合の不合。
大不合で。
どんだけストレージあることを想定してるのかわかんないよってぐらいもうストレージ専用するからあれ使ってると。
そうやね。全部まるっと管理してるみたいなもんね。
依存するパッケージ全部常に持っておいて、キャッシュみたいな形で全てをストレージに持っておいて、管理しちゃうっていうやり方を。
まあじゃあ、そんな感じで管理してますと。
だいぶ。
管理しているっていう中で、その中でも課題があって。
プラグイン機能の利便性
例えば、僕がこれめっちゃいいじゃんって思って突っ込んだら、それやると他のプロジェクトでつぶんだよみたいな、本当に超汎用的なスラッシュコマンドであったりとかサブエージェントとか。
もちろんサブエージェントとかは名前でプロジェクト名定義して、プロジェクト名でちゃんとわかるようにして、これはもうこれ用だっていうふうに使わないようにとかっていう工夫を今までしてたけど、
やっぱり特にMCPとかは自動デッキを起動しちゃうから、しかもそれでコンテキスト消費しちゃうっていう問題があるから、
そうするとやっぱりプロジェクト固有にしないといけないものっていうのが、便利ツールであってもどうしても出てくると。
そこがやっぱり、まあまあもちろんね、管理できるじゃんっていう前提なんだけど、Gitでプロジェクトの方で管理したらいいやんっていうところなんだけど、
やっぱりどうしてもなんか煩雑さが増すみたいなところを、このプラグイン機能とかで解決できるのかな、できないのかな、わかんないな、みたいな感じの。
でも僕一個だけこれ明確にいい使い方あるかなっていうのが一個だけあって、
さっき山ちゃんが言ってたように、めっちゃ便利なスラッシュコマンド、エージェントなんだけど、入れると共通として使おうとすると他のプロジェクトの影響を及ぼしちゃうっていうのが例えばあるじゃん。
例えば、スラリントとかスラフォーマットみたいなエージェント、スラッシュコマンド作って、タスクが終わった後にリントを走らせたり、静的解析を走らせたり、
フォーマットさせるっていうのを、便利だから最初、全プロジェクト共通のものとして使おうとしたけど。
あれフックスやね。
フックスに僕が良かると思って、プリティアのフォーマットを自動でコードを実装して終わると、自動でフォーマットかかるように良かると思ってしたら、
これやると動かなくなるプロジェクトあるからって言って怒られたわけですよ。
僕がね、携わってる案件の一つに、フォーマットをかけると壊れるっていうすごい謎なものがあって、
だから共通で走らされるとすごい困るっていうのが起きてたんだよね。
でもそれって共通で絶対使いたくなるはずだけど、特定のプロジェクトだけでは適用できないよねっていうのがあるので、
そういうのはプラグイン的に導入できると、共通的にこういう指示を与えたいとか、常に管理してたいんだけど、
その与える、適用するプロジェクトはABCだけとかだと、そのABCだけにプラグインで導入しておけば、
あとはプラグイン側で変更を加えればABCに全適用されるよねっていうのがあるから、
そういうなんか切り分けができるようになったらすごい便利な、よかったポイントの一つかなって思って。
スラッシュコマンドの応用
あとやっぱ、他の人のプラグインマーケットプレイスで他の人のやり方を学べるっていうのは結構でかいかもね。
うちだと例えばすら、アスクコマンドみたいなので、絶対に編集させないし、
あとちょっと反数させて、自分の回答がユーザーに対して忖度してないのかとか、忖度度をちゃんとこう。
そうだね。
信憑性がどれくらいなのかっていう点数をあえて付けさせることによって、
僕たちユーザーがする質問に対しての正当度合いというか、
忖度のないフラットな回答がちゃんとできてるかっていうのをAIがちゃんと自分で自己認知できるようにしてあげて、
精度の高い回答を得られるようにしようみたいなスラッシュコマンドがあったりするんですけど、
そういうのってもしかしたら意外とやってないかもしれないし、意外とみんなやってるかもしれないしみたいなのが、
なんとなくこう、みんなが公開し始めると分かってくるっていうのはちょっと楽しみなところ。
まあなんか、どっちかと言っても僕の楽しみはそっちかな。
他の人のスラッシュコマンドとか、いろいろ設定、こういうのが多分ベストプラクティスだみたいな形で多分みなさん出してくれたら。
いろんな人の考えを見てそれを自分たちのスラッシュコマンドとかに落とし込んでいけるっていうのは結構でかいよね。
エージェントの作りとかもそうだよね。
そうだね。
やっぱ自由度が高い分、どういう風にするかっていうのをみんな、僕たちもそうですけど試行錯誤してるから。
そうだね。結構ね、僕たちも試行錯誤してる中でスラッシュコマンド常に日々変化してる内容ではあるから。
サブエージェントのしかりで、みなさんがどう考えて書いてるのかっていうのがすごく気になってるかなって。
そうだね。正直、スラッシュコマンドでスペックドリブンデベロップメント?
あるね、今。
SDD、仕様食道開発か。やってたしね。別に出る前に。
今のCC…何だっけ?スペックコマンドだっけ?なんか色々出てきてるけど、僕らも自然とそこに行き着いてたから、
意外とね、僕らもなんか良い線行ってるんじゃないかなっていうところもあると思うし、逆にね。
逆にね。
そうそうそう。学ぶことは多い気がします。
もっとやってる人も絶対いるし、だからそういう意味では、色々学べる機会が増えるっていうのは良いことよね。
今後このマーケットプレイスみたいな形でプラグインが公開されていく中で、有料のプラグインを作れるようになったりとかするのかな?
けど、思想がなんかOSSに寄ってるから…
あんまりないかな?
あんまりないし、買いたいと思うかなって気がするけどね。
あ、そう?
うーん…
なんか一定、それこそインフルエンサーとかが出してるスラッシュコマンドをなんかね、有料で配布しますみたいな。ありそうな気がするんだけどね。
無くはないと思うけどね。無くはないと思うけど、メインストリームにはならないんじゃないかな?
うーん、なんかどうなんだろう。
まあ、ここでね、ぶっ飛んだのが出てくるのが世の中なんで。
まあ今日実際、有料化はされてないけど、このプラグインマーケットプレイスっていう機能が出る前は、ちゃんとOSSとしてクロードコードをもうちょっと拡張してやれるようなNitHubのリポジトリが公開されてたりとかしたじゃん。
だからそれがよりやりやすくなった。
まあけど、このあくまでもプラグインマーケットプレイスのフレームに乗っかってしかできないっていうので、どこまで…っていうのはまあちょっとわかんないよね。
クロードコードがそういう課金システムみたいなのを作んないとなかなか難しいんだろうなっていうのはあるけどね。
うーん…
プラグインって言われると、なんとなく有料のプラグインが出てくるんじゃないかと。
はいはいはいはい。
思ったけども。
まあ…どうなんでしょうね。
プライベート…これあれか、GitHubで配布できるから、プライベートのGitHubリポジトリを作って。
あ、そうっすね。
そうそうそう、招待制にして、支払いしたらプライベートリポジトリに招待して、できますよ。
でもなんか、結構それ難しいなと思うのがやっぱ、テキストなのですぐコピーできちゃうっていうのは。
うーん…
なんか…
まあけど買い切りじゃないんだから、サブスクとかじゃなくて。
買い切りだね。
で、招待するためのっていうのと。
まああとは、やっぱコンテキスト量の問題が解決しないと、多分どんだけ重厚な…
僕もめちゃくちゃスラッシュコマンド作り込んだ時があって、その時に結局読み込ませるテキスト量が膨大になるんで、逆に非効率みたいなのが途中で起き始めるんですよね。
そうだね。
コンテキストが圧迫する。スラッシュコマンド1個を読み込ませるだけでコンテキストが圧迫するから、だからなんか本末転倒みたいな状況になる…
なんか行き地というか、境があって。だから、なんかそこがちょっと改善されない限りはあんまり…
まあ改善されるでしょうけどね、そのうちに。
まあ…コンテキストの許容量はどこまで広がるか次第になると思うけどね。
そうそうそうそう。って感じなのかな。
まあそんな感じで、プラグイン機能。結局Codex使ってるから使えないんだけどっていう。
そうだね。Codex…もうちょっと…まあ開発はね盛んに進んでるんだけども、もうちょっとね、いろいろできるようになりたいな。
まあちょっとサブエージェントは少なくても欲しいな。プラグイン用も別になくてもいいから。
プラグインマーケットプレイスの展望
そうだね。サブエージェント欲しいよね。
あとスラッシュコマンドの引数ももうちょっとちゃんとして欲しいな。
まあでもなんかね、最近その引数形式もまあ悪くないのかなって思ってきたけどね。
なんか今だと引数…もうなんか1から9までの引数と、あとは自由な引数与えれるようになってるけど、
スラッシュコマンドのマークダウンファイルの中に$1$2って書いとけば、そこに直接置換されるようになるから、
割と指示がより具体的にできるようになるっていうのは結構…
逆にね。逆にカチッとできるみたいなね。
そこはある種Codexにとっては、まあね、カチッと指示与えたらカチッと動くみたいな特性があるので、
意外とハマったりするのかな。
あとまあその自由な引数がその$argumentsで、もうCodexにスラッシュコマンドで与えた引数全部argumentsっていうので取得できるから、
追加の要望とか追加のコメントがあればその$argumentsで出力して、これが追加の指示ですよっていうのをスラッシュコマンドに書いてさえすれば、
わりかし柔軟にできるようになるのかな。
なるほどね。
まあそれで言うと意外といいところはあるのか。
なんか、まあけど正直、クロードホーズでもやってたんよ。
はいはい、知観してねっていうか、ここに。
ClaudeCodeの新機能と活用法
そう、なんか1個目はこれで2個目はこれでみたいなんで、なんか擬似的な、けどそれでも別に回ってたんよね。
まあまあまあまあ。
なんかその引数っていう概念じゃなくて、スラッシュコマンドの後に文章をくっつけるだけじゃん。
そうなんです。
なんだけど、それを擬似的になんかできてたからさ、なんかむしろこう制限が強まった感覚にはなるよね。
エンジニア的にはより関数的というか、なんだろう、普段の振る舞いと同じような感じだから自然に感じるのかな、もしかしたら。
まあそうだね、あとまあコンテキストをやっぱりとにかく節約したいっていう動機もあると思うから、
なんかそういったもうカッチリはめることでギリギリまでカリカリにこうコンテキストを減らせるっていうのは1個あるかなって思うけどね。
まあそれがなんかそんな言うほど変わらんじゃんみたいなところは若干ありつつも、まあ少しでも削減できるっていうのは大きいのかな。
エンジニア的にはクロードコードのこうフラット感が良かったかな。
まあまあまあ楽さね、もう作りやすさ、使いやすさ、双方ともにクロードコードの方がやりやすいっていうのはあると思うけどね。
それでもなおコーデックスを使い続けてしまうこのモデルの頭の良さ、そのパワー。
どんなに使いにくいとか言いながら結局コーデックス使ってるから。
ユーゲームコーデックス使い続けてる?俺はもう完全にコーデックス使い続けてるわ。
俺ももう完全にコーデックスかな。
クロードコードはこの間の回とかでも話してるけど、やっぱりこのドキュメントとかクライアント向けのメッセージを書くときにたまに使うけど、基本的にコーデックスかな。
けどあのクロードコードのレビューあるやんか、アクションズの。
インターバーアクションズのね。
あれ精度上がったやん。
あれは単純にモデルが4.5になったから。
上がったから精度上がって俺は満足した。あれ結構いいな。
あそこ用に使ってるって感じかな今の。課金した。
一応クロードコードも課金して、ソネット4.5に上がったから課金して結局使わなくなったけど、今の使いみっとすればGitHubアクションズ。
GitHubアクションズとお客さんへの連絡事項の整理。
まあそんな感じかな。今だとね、バックログとかああいうの使ってるけど、課題管理。
バックログMHCPを使ってその課題の情報を吸い出して、コーデックスに仕様整理してもらって、コメントまでやってもらおうと思うんだけど。
コメントがあまりにもぶっきらぼうすぎるし、それをちょっと改善してくださいってお願いしても、ちょっと全然違う感じの出力になったりするから。
なんかそのコーデックスがまとめた内容をクロードコードに教えて、整理してバックログに共有しておいて、みたいな。
クロードコードのほうが世の中を理解してるね。
そうそうだね。社会を理解してる。
社会を理解してる。
ゆえにおせっかいすぎる時があったりするんだけど。
そんな感じですかね、今回は。
はい、まあ結論としてプラグイン24だよね。
Codexと管理方法
僕たちはこんな感じでスラッシュコマンドとか、諸々の管理をしてますよ、共有と。
けどコーデックスがやっぱいいよね、以上って感じですかね、まとめると。
今日はそんな話になったかな。
はい、OKです。なんかいつもコーデックスいいねっていう話で終わるから。
ちょっと、もうちょっといろいろクロードコードいいねとか、こういうところいいね。
いいんだけどね。
まあいいんだけど。
やっぱサブエージェントが並列で動く時の、なんか気持ちよさみたいなのもあるけど。
うん、まあやっぱ並列で実行できてると、なんかこうAIを使いこなしてる感覚があるよね。
人間だとさ、並列でできないけど、作業。
やっぱAIとか計算だから、計算システムだからこそ並列で動けるって考えると。
まあいろいろ並列実行してる時の気持ちよさは。
まあコーデックスを並列で立ち上げたらいいだけなんじゃないかな。
いやまあそうなんだけどね、やってるんだけどね結局。
結局それやるんだけど、だからもっとこう自律的に並列になってほしいわけじゃないですかね。
まあそんなことはさておき、じゃあこれくらいにしましょうか。
はい、そうですね。
ありがとうございました。
ありがとうございました。
はい、本日もAI駆動開発部の日常をお聞きいただきありがとうございました。
いかがでしたでしょうか。
今回の話題はマクロードコードの新しい機能ですね、プラグインの話と、
あとは普段僕たちがどういうふうにスラッシュコマとかを管理しているのかというところのお話でした。
もしBotcastで今後こういうこと、こういうトピックについて話してほしいとか、
そういったご要望があればコメントとかいただけると大変嬉しいです。
あと気に入ってくれた方は、いいねであったりとかフォローとか高評価とか、
ぜひ励みになりますのでお願いできればと思います。
それではまた次回もお楽しみください。
じゃあねー。
