「Everything Claude Code」リポジトリの紹介
おはようございます、inadyです。デブログfmでは、プログリッドでエンジニアをしているinadyが、AI活用時には最新ツール、開発生産性向上のノウハウをシェアします。
この番組は、YouTube、Apple、Podcast、Spotifyなどで配信しております。ぜひ、お好きなプラットフォームからサブスクライブをお願いします。
では、今日のトピックをご紹介します。
公式を超えた非公式リポジトリ Everything Claude Codeが教えるAIエージェント設計の本質
という話をしてみたいと思っております。
まずはじめに、Everything Claude Codeという、クロードコードのベストプラクティスとか、スキルズとかプラグインが公開されているリポジトリがありまして、
これが、アファン・ムスタファさん、発音が合っているかわからないですが、この方が作っているリポジトリで、
私が今収録している時点では、126Kのスターがついています。
この126Kがどれくらいすごいかというと、アントロピック公式のクロードコードのリポジトリがあります。
これは実際にクロードコードのコードが載っているわけではなくて、使い方みたいな説明のリポジトリなんですけれども、
それが90Kのスターになっているので、公式のクロードコードのリポジトリよりも、
非公式の人が作ったツールのリポジトリの方が圧倒的にスター数が上回っているというところで、非常に注目が集まっているという話です。
この方は何者かというと、2025年の9月に行われたアントロピックのハッカソンで優勝した方。
その優勝した経験とかを踏まえつつ、それ以降の日々の使い方を踏まえて、
この方がこれがベストだという設定集をGitHub上でオープンソースとして紹介したというものになっています。
今回のDevGrove FMでは、このガイドの中にある、
そもそもクロードコードの使い方のベストプラクティスみたいな話の記事、ドキュメントと、
それから具体的なエージェントとかスキルとかがどういう風になっているかみたいなところから、
1個1個ヒントを見つけていきたいという風に思っています。
まず1個目からいきたいんですが、これがガイドですね。
Claude Codeのベストプラクティス：MCPとスキル図
ガイドが3つまずあるんですね。
これですね、スタンダードガイド、ロンガーガイド、セキュリティーガイドとこの3つがある中で、
その中からロングガイドの説明からしていきたいという風に思っています。
まず、一番最初に書いているところで言うと、
MCP、すごく便利な機能ではあるんですが、
多くの場合において、MCPをそのまま使うのではなくて、
スキル図として特性の機能だけ抜き出して、
スキル図の中にCLIコマンドを書きましょうということが書いています。
これは結構知っている人が多いんじゃないかなという風に思うんですが、
MCPはかなりコンテキストを使います。
最近はレージローディングといって、ディスクリプションだけ最初にインプットして、
後で中身をローディングするみたいな機能はあるんですが、
それでもまだ結構コンテキストウィンドウを使い潰してしまうという問題があるんですが、
そうではなくて、スキル図プラスシンプルなCLIをそこに中に入れるということによって、
トークンの使用率を最適化しつつ、やりたいことが実現できるという風なアプローチですね。
なので、MCPをガンガン入れるのではなくて、本当に使いたいものだけ入れて、
かつ、すごくMCPのツールが多いやつです。
例えばGitHubのMCPとかは結構中身がいっぱい入れることがあるんですけども、
実際やることとしては、プロリクをする、プロリクストを作るみたいなぐらいだと思っているので、
そういった場合においては、単品機能だけスキル図に自分で起こして、
CLIで実装するようにしましょうという話が書いておりました。
メモリ管理とフックスの活用
次がメモリーマネジメントの話です。
このEverything Cloud Codeのフックスとかを使うことによって、
自分がやり取りした内容がセッションの情報として、
この.cloud配下にテンプファイルとして配置されますよという機能が実装されています。
これを使うことによって、新しくいろいろ作業しました。
で、終わって、また次の日やるときに、
普通であれば前の日のことは全て忘れてしまっているんですけれども、
この前日の作業内容をもう一回プロンプトとして渡してあげることによって、
機能の続きからやることができるというような機能になっています。
どうやって差し込むかというと、
例えば昨日やったものが残っているのであれば、
--system promptで囲んであげて、機能のやつを差し込むみたいな、
そういったやり方でできますという話。
さらに、これ面白いなと思ったやり方なんですが、
特定の実装、特定の作業みたいなことをするときに、
あらかじめ決まっているプロンプト、--system promptを入れるという、
cloud-system promptで何とか何とかreview.mdみたいなやつを差し込んでおく。
かつ、これをエイリアスとして設定しておくことによって、
いつもやる作業が自動的に入っている状況で、
実装を開始できるというこのやり方、
非常にユニークで面白いなというふうに思いました。
最後にですね、このeverything-cloudコードに
hooksのサンプルが書いているんですけれども、
これを使うことによって何ができるかというと、
まず、play-compact-hookですね。
コンテキストが埋まってくると、
コンパクトという作業をすることによってコンテキストを圧縮して、
続きからまたやるという作業があるんですけれども、
これをコンパクトがトリガーされた瞬間に、
コンパクトする前に今までのやり取りを
添付ファイルに保存しておくという機能がありますね。
これは何でやっているかというと、コンパクトをすると、
結構今までやってきたことを忘れちゃうみたいなことがあるので、
そのバックアップとして保存しておくみたいな意味だというふうに思っています。
2つ目がstop-hookのトリガーですね。
これはセッションが終わったときに、今までのやり取りを
同じようにメモリとして添付ファイルに保存しておくというようなアプローチですね。
最後が、いちいちシステムプロンプトで渡さないといけないのかと、
めんどくさいよねというところがあるので、
セッションスタート-hookを使うことによって、新しいセッションが立ち上がったときに、
自動的に過去のメモリが呼び出されて、
機能のことを覚えている状況でスタートできますというような機能ですね。
こういったものが紹介されていました。
ただ、これにおいては、私は場合によって使うかなというふうに思っていて、
まず一つは、クロードコードのネイティブにも最近メモリ機能が含まれたので、
そっちを使ってもいいんじゃないかなというところと、
あとは、メモリの、クロードコードのメモリのどういうメモリが保存されているかって、
実際に.cloudハイカーで見ることができるんですけども、
見てみると、あんまりあってないんですかね。
やっぱり、AIが私とAIとのやりとりをサマライズしたものが入っていくので、
ちょっと意味を取り違っていたりとかいうところがあって、
そのメモリがある状態で次のセッションを始めてしまうと、
間違っているものをあたかも正解かのようにやってしまうと。
これは、ChatGPTとかGeminiとかの皆さんが使うチャットプロンプと同じことが起きると思うんですが、
変に間違った覚え方をされてしまっているものが、
ずっとあなたってこうですよねみたいなことを言われるみたいなところがあると思うんですが、
そういったことが起こる可能性があるので、
私は結構メモリ機能っていうのは使わないようにしていますね。
どっちかというと、もちろん便利な側面はあるんですけども、
やはりちょっとロバスト感があるというかですね、
曖昧さがあるというところはあるので、トレードオフかなと。
その人の性格とかにもよるんじゃないかなと思っているんですが、
私はどっちかというと、きちんとと定義したいみたいな派なので、
こういうメモリみたいな機能を使うんではなくて、
しっかり継続的にやるものであれば、
Cloud.MDとかSkillsにちゃんと落とし込んでいきたいなという派なので、
私はすごくいいアプローチだと思うんですけど、
使わなさそうだなというものかなというふうに思いました。
Continuous Learning V2による学習の自動化
では次に行きましょうか。
これが結構私が感動したものなんですけれども、
Continuous Learning V2というスキルです。
これは何かというと、
日々やり取りをしますよね、Cloud Codeと。
やり取りしている中で、
これって同じパターンだよなというのがいっぱい出てきます。
AIは正解したり成功したり失敗したりする中で、
それを本当であれば自分でSkillsにしたりとか、
Cloud.MDにしていくことによって精査性が上がっていくんですけれども、
それを自動化しようというような仕組みですね。
どういうふうな動きをするかというと、
ここに書いているんですけれども、
まずセッションが立ち上がりますので、
何かプロンプトを打ちます、
何かツールを呼び出しますってなると、
フックが呼び出されて、
その人が何をやったのかっていうのが、
JSON Lファイルにどんどん保存されていきます。
この保存された情報をバックグラウンドで配布がですね、
これは重要なディシジョンなのか、
継続的にAIが間違ってしまうやり方なのか、
ユーザーが好む動き方なのかみたいなところを認識して、
それぞれカテゴライズしていきますというふうな機能ですね。
かつ、それがそのリポジトリだけの話なのか、
例えばその人の好みとかであれば、
別にリポジトリ関係なくグローバルな話だと思うので、
グローバルなスコープなのかみたいなところを自動的に判別します。
それができた後、何が出来上がるかというと、
プロジェクト配下、プロジェクトスラッシュ配下、
もしくはインスティンクトパーソナル配下、
要はグローバルですね。
グローバルの中にこういうふうなユーザーの好みがあるとか、
こういうふうな実装の傾向があるみたいなところを、
重みをつけた上で分類して、
ファイルを作ってくれるっていう機能があります。
最後にこのEvolveっていうコマンドを打つと、
それらのユーザーの今までの好みだとか、
実装のパターンみたいなものを、
じゃあこれをこういうふうなスキルズにしましょうとか、
こういうふうなエージェントにしましょうみたいなところを提案していってくれて、
それが実際にスキルズとかエージェントにどんどん反映されていくっていう機能です。
この点がすごく面白いなと思ったところは、
まずユーザーの動作みたいなところをログとしてしっかりとっているというところですね。
これによって同じパターンとか傾向をしっかり認識できるというところと、
かつそれを裏側でカテゴライズして分類して評価してみたいなところが動いていくので、
ユーザーが何か作業している間に、
これって同じパターンだよなとか、
これって自分の好みの実装パターンだよなとか、
これってAIがよく間違えるなみたいなところを自分で考えなくていいっていうところは、
自分の脳のメモリとかそのリソースを削減するという意味では非常に面白いかなというふうに思いました。
最後にそれを評価しただけでは意味がないので、
それを実際にコマンドとかスキルとかサブエージェントとかに落とし込んでいくというコマンドもありますというところがあるので、
これを本当に日々繰り返していけば非常に自分に合ったというか、
非常に賢い、精査性が高いクロードコードが出来上がっていきそうだなというふうに思いました。
トークン最適化とモデルの使い分け
次がトークンの最適化ですね。
トークンの使用量を最適化する方法としては、
こちらの方はサブエージェントをしっかり使いましょうというふうな説明をしています。
これはどういうことかというと、
例えばですけど全部オーパスでやるとすごいコストがかかるんですけれども、
例えばリサーチとか何かファイルの中身を調べるみたいなところは、
ハイクのモデルを使えばいいし、すごく簡単な変更であればそれも同じくハイクでやればいいですよねと。
一般的な複数ファイルの実装ですね。
これはソネットを使って、
例えばプランニングをするとか、
セキュリティに非常に重要なミスをしてはいけないセキュリティの判断みたいなところは、
オーパスモデルを使うみたいなことをすることによって、
適切に賢い賢くない値段が高い低いモデルを使い分けることによって、
コストとかトークンの使用量を最適化するという話ですね。
もうちょっと詳しく書いているのがこの行なんですけれども、
大体90%の要素においてはソネットでいいですというふうに書いています。
じゃあオーパスいつ使うかというと、
何か実装したときに初回の実行で間違えちゃった場合は一旦オーパスに切り替えるというところとか、
あとは5個以上のファイルを編集した場合はオーパスの方がいい可能性があるというところと、
あとはアーキテクチャの判断ですね。
コード全体を見直した上でこういう判断をした方がいいという大きなディシジョンをするときとか、
あとはすごくセキュリティに重要なコードを書かないといけないという場合だけオーパスを使うといいですよねということが書かれていますね。
どんどんいきたいと思います。
Claudeの並列実行とカスケードメソッド
残り2つちょっと私が気になったものをご紹介していきたいというふうに思っています。
次はですね、クロードの並列実行ですね。
よく私もXとかで見るのはクロードコードを何十個も開いて、
夜中に全部やらせていたら何か20個できましたみたいなそういうのを見るんですけど、
あれは正直ですね、AI驚き屋というかAI商材屋さんがやっているパターンが99%なんだろうなというふうに思っていて、
実際あんなこう20個も30個もターミナルしかもわざわざ綺麗に並べてやる人って本当のエンジニアでいないんじゃないかなというふうに思うんですが、
例えばですね、このボーリスさんが5個ターミナルでクロードを動かしているぞみたいなことをポストしているものに対して、
このエブリシングクロードコードを書いた著者はわりと否定的な意見を持っていて、
別に5個動かす必要ないよねみたいなことを言っていて、
本当に5個いるんだったら5個やればいいし、別に2個で目的達成するんだったら2個とか1個とかでもいいよねっていうことを言っています。
これはもう本当におっしゃる通りだなというふうに思っていて、
あとはその人間の脳のキャパシティの限界みたいなことがあるなというふうに思っていて、
5個もタスクを同時に実行することって人間かなり不可能だと思っていて、
もし似たような機能の実装であれば2,3個立ち上げることはできると思うんですが、
本当に深くフォーカスしてやらないといけないタスクがある場合は、
それを1個ディープフォーカスしないといけないタスクA, B, Cっていうのをそれぞれ動かして、
それを同時並行でやれるんですかっていうふうに考えた時には、
やっぱり本当に最小のクロードコードの数、ターミナルの数でやるべきだなというふうに私も思っていて、
チョーさんも同じような考え方を述べているというところですね。
それから細かいディープとしては、これはもう今やっている方は非常に多いと思うんですが、
ワークツーリーを使って作業しましょうと、そうすることによって、
ワークツーリーを使わないとコンフリクトが起きてしまうので、
ワークツーリーでちゃんと作業環境を分けてそれぞれの機能を実施しましょうというところと、
あとはこのリネーム機能も使って、このセッションが何の作業をしているのかみたいなところを
ちゃんと名前を付けることによって迷子にならないようにするというようなことをお勧めしていました。
あと最後に、このカスケードメソッドという考え方は、
非常にエンジニアの仕事のやり方のマインドセットとして面白いなというふうに思いました。
これは何を言っているかというと、複数のクロードコードのインスタンスを立ち上げますと、
その3つとか4つとか立ち上げた場合に、
これをマネジメントするためにカスケードパターンというのを使いましょうというのを推奨しています。
どういうフローかというと、まず新しいタスクを一番左のターミナルのタブで開きます。
それが終わったらどんどん右に、隣に隣に持っていって、一番左が一番新しいタスクで、
ちょっとずつ右に移っていくと。
このターミナルが、今ビデオポッドキャストを見ている方は画面が見れていると思いますけど、
この場合では2個立ち上がっていますが、まず左を立ち上げると。
古くなったものを右に、右に持っていくというような話ですね。
最終的には画面全体としても3つか4つぐらいにしておいて、そこにフォーカスして作業しましょうというようなレコメンデーションをされていました。
オーケストレートコマンドによるエージェントワークフロー
では最後ですね、オーケストレートコマンドという、このエブリシングクロードコードの実際のコードの中身を最後紹介したいなと思っていて、
これが結構私は感動したというか、これやりたいなと思ったものでした。
これはどういうことかというと、エージェントのワークフローをコマンドとして定義しているというものですね。
使い方としてはスラッシュオーケストレートでどういう実装のタイプなのかと、その実際のタスクの内容みたいなことを定義するというような機能です。
例えばスラッシュオーケストレートフィーチャーであれば、このワークフローで動きます。
プランナーが動き、TDDガイドのエージェントが動き、コードレビュアーのエージェントが動き、最後セキュリティレビュアーのエージェントが動くみたいなものが、
自動的に反映されていくと。なので、プロンプトを入れるときにまずプランナーエージェントを動かして、
TDDガイドのサブエージェントを動かしてって言わなくても、このスラッシュオーケストレートでやりたいことを書くだけで、
自動的にサブエージェントのワークフローを組んでくれるというものですね。
どういったワークフローのタイプがあるかというと、この例でいうと、フィーチャー、バグフィックス、リファクター、セキュリティってあって、
それぞれフィーチャーとバグフィックスであれば、最初プランナーがいて、その後実装がいる。
リファクターであれば、まずアーキテクトがいて、コードレビューして、最後TDDガイドがいる。
セキュリティであれば、まずセキュリティのレビュアーのエージェントが立ち上がって、コードレビュアーが来て、
最後にアーキテクトが立ち上がるみたいなパターンになってますね。
あと、この実装で私が面白いなというふうに思ったのは、このハンドオフドキュメントフォーマットというものですね。
この前のエージェントから次のエージェントに何か作業を依頼するときに、コンテキストが消えてしまうという問題があります。
例えば、これやってくださいと次のエージェントに渡すときに、その背景とかが分かってないと、
なんでこれやってるんだっけってのが分からなくて、ぐちゃぐちゃな結果になるみたいなことがあるんですが、
このハンドオフドキュメントのフォーマットを定義していることによって、
次のエージェントに対して、前々のタスクで何をやっていて、どういうことが分かって、どういう問題があって、
次はどういうことを解決していきたいかみたいなところを、ちゃんと定義されたドキュメントとして渡すことによって、
コンテキストが変にならずに、どんどんエージェントを次から次に渡していくことができるというアーキテクトになっていて、
これは非常に面白いかなというふうに思いました。
最後が、これは参考例が書いているものになっていて、
例えばフィーチャーでこういうものをやってくださいって言ったら、
プランナーが動き、TDDガイドが動き、コードレビューが動き、セキュリティレビューが動き、みたいなものですね。
じゃあですね、せっかくなのでこれで動いているプランナーのエージェントもちょっと見てみたいというふうに思うんですが、
オーケストレートでよく使っているこのプランナーというエージェントですが、
得意してすべきなのは、モデルをオーパスで選定しているということですね。
あと中身はそんなに難しいことは書いていなくてですね、あなたのロールはこういうものですよとか、
プランニングプロセスとしてまず要求項目をちゃんと分析して、アーキテクチャのレビューをして、
それをステップでブレイクダウンして、どういう順番でやるかみたいなところを書きましょうと。
最後にこういうふうなフォーマット、プランのフォーマットはこういうドキュメントフォーマットで出力しましょうというようなパターンが書いていますというような感じですね。
このオーケストレーションは、私もエージェントを使うことはあるんですけど、
毎回このエージェントを使ったとこのエージェントを使ってやっていたんですが、プロンプトで自分で入れてやっていたんですが、
この参考例のようにオーケストレーションみたいなコマンドを作って、そこで機能実装の場合はこの流れ、調査レポートの場合はこの流れみたいなところを事前に定義しておけば、
いちいち言わなくても自律的に判断してやってくれるし、かつプランニングはオーパスモデルを使って実装はソネットモデルを使うみたいなところで、
トークンの使用量を抑えることにも非常に貢献できそうだなというふうに思いました。
「Everything Claude Code」が話題の理由と活用法
では最後にですね、このエブリシングクロードコードが何でこんなに話題になっているだろうかみたいなちょっとメタ的なところを捉えていきたいんですけれども、
コーディングエージェントの性能っていうのは単にモデルが賢いだけじゃないよねっていうのがみんなだいぶ分かってきましたと。
例えばオーパスモデルを使う場合においてクロードコードで使うよりもカーサーでやった方が性能が高いですよねみたいなレポートがあったりするんですけれども、
要はプロンプト、ユーザーが知らない裏側で送られているプロンプトがどういうものであるとか、それからそれを取り巻くスキルズとか、
クロード.mdとかメモリーがどういう設計になっているのかっていうところが最終的な生産性に大きく変わってくるというところですね。
もっと言うと、じゃあそもそもモデルをそのツールに最適化しようというところで、前回話したようにカーサーのコンポーザー2みたいなのが出てくるみたいな話かなというふうに思っています。
あとはこのEverything Cloud Codeっていうのは非常に巨大なリポジトリですごいいっぱいスキルズがあったりサブエージェントがいたりコマンドがいっぱいあるんですけれども、
これを全部入れると結構ぐちゃぐちゃするっていうか何がどうなっているのかわからなくなってしまうので、
これ家でうまくいかなかったわみたいなのはちょっと違うのかなというふうに思っています。
ちゃんとこのリポジトリを見てどういった機能があるかみたいなことを把握して、その上で全部入れるのか、
必要なものだけ取り入れていくのかみたいなところをやっていくといいんじゃないかなというふうに思っていて、
今回私が実際にやってみたようにこのリポジトリを実際に眺めてみて、他にもいろんな機能がいっぱいありますので、
どういう風なプロンプト指示の書き方がいいんだろうかみたいなさまざまなヒントになるので、
ぜひ一度このEverything Cloud Codeのリポジトリを眺めてヒントを得てもらったらいいかなというふうに思っています。
ということで今回はEverything Cloud Codeについてお話をしてみました。
番組紹介とエンディング
自分も結構Cloud Codeの設定はどっちかでどこっている方だとは思っていたんですが、
このリポジトリを見てまだまだ改善の余地あるというか、改善の余地しかないなというふうに感じたところでした。
ということで最後に番組のご紹介をしてください。
この番組はYouTube、Apple Podcasts、Post Finalで配信しております。
ぜひお好きなアパラットフォームからサブスクライブをお願いします。
ご感想リクエストもしございましたら、ハッシュタグでブログFMでつぶやいていただくか、
概要欄のフォームコメント欄にいただけますと幸いです。
それでは次回の配信でお会いしましょう。
ご視聴ありがとうございました。