オーラリングの体験
おはようございます、inadyです。
この番組では、現役エンジニアのinadyが、日々業務で試したAI活用術や最新ツール、開発生産性向上のノウハウをシェアします。
感想は、ハッシュタグデブログfmまで。
この番組は、Apple PodcastとSpotifyで配信しております。
ぜひ、お好きなプラットフォームからサブスクライブしてください。
最近ですね、風邪をひいてしまいまして、熱が39度ぐらいまで上がったんですね。
今日、雑談として話したいのは、最近オーラリングをつけ始めて、このオーラリングの凄さが分かったという話なんですけれども、
今までであれば、熱が上がって治った後も、ちょっと毛だるさが残ると思うんですけれども、気のせいだと思って、
頑張ろうとして、結局頑張れないんですけれども、頑張ろうとやっていたんですが、
オーラリングを最近つけることによって、オーラリングのデータを見ると、
あなた体調めちゃめちゃ悪いから休んでくださいっていうアラートが出るんですね。
このオーラリングのリアルなデータと、自分の体調の悪さっていうのが合致すると、
確かにこれ休まないといけないなっていう気持ちになって、
このオーラリングの凄さってかですね、データを可視化する意味っていうのが非常に分かって、
オーラリングつけてしばらく経ってるんですけれども、オーラリングのありがたさってかですね、良さ、
なんかやっと気づいたなっていうところで、皆さんもオーラリング、
もし興味があるって方いたら試してみていただけるといいかなというふうに思います。
少し前まではですね、アップルウォッチをつけてたんですけれども、
やっぱりアップルウォッチで充電が1日で切れるとかですね、そもそも形が大きいので、
つけてる感覚非常にあるんですけれども、このオーラリングであれば、
だいたい電池も1週間くらい持ちますし、つけてる感覚も、最初はちょっと違和感ありますけれども、
だんだん無くなってくるので、非常におすすめで、僕はアップルウォッチは売ってしまって、
今オーラリングだけでやってるという感じです。
クロードコードの活用
それでは今日のメインパートなんですけれども、前回はオープンコードの話をしたんですけれども、
やはりメインではクロードコードを使っていまして、
このクロードコードの具体的な使い方、自分なりの理解というところを、
皆さんに共有したいかなというふうに思っています。
具体的に言うと、クロード.md、それからルールズ、スキルズ、スラッシュコマンドって色々ありますけれども、
これの違いと使い分けについてお話ししていきたいというふうに思っています。
まず初めに話していくのは、クロード.mdについてです。
そもそも理解しておかないといけない点で言うと、
LLMって毎回ユーザーとのやりとりを忘れてしまう。
新しいセッションが始まると、前回話したことって当然忘れてしまうというところを、
まず認識しておかないといけないというふうに思います。
昔ですね、チャットGPTとかが出始めた頃は、皆さんどうやってやっていたかというと、
毎回プロンプトで背景情報とか、自分は何者なのかとか、どういうレスポンスをしてほしいのかとか、
毎回プロンプトをスニペットでペッて貼ってやっていたわけですね。
それが面倒だよねということで、事前にある程度書いておいて、
それを毎回自動的に読み込ませましょうよという仕組みの一つが、このクロード.mdになっています。
なので、このクロード.mdにやってほしいこと、
LLMに必ず覚えておいてほしいことを書いておくと、
それが自動的にセッションが始まるために読み込まれて、
それを踏まえてレスポンスが返ってくるというところがあるので、
このクロード.mdがクロードコードにおいて一番大事なツールの一つだなというふうに考えています。
このクロード.mdをそもそも書いていないというパターンも結構あると思うんですが、
まずこれは必ず書きましょうと。
クロードコードを使うにあたって、このクロード.mdを書いていないということは、
かなり使いこなしていない部類に入ってしまうので、
必ず書きましょうというところはまず言いたいかなというふうに思います。
その上でいくつかベストプラティスがあるんですけれども、
まず一つ目がレスイズモアと言われていて、
つまりは少なければ少ないほどいいということです。
できれば300行以内ぐらいで書くといいというふうに言われています。
この背景はどういうところにあるかというと、
皆さんも経験あると思うんですけれども、
LLMとチャットをしていると途中で指示したことを忘れて、
いきなり変なことを始めるとかいう経験あると思うんですけれども、
LLMに対しての指示って、
あまりたくさん書いてしまうと忘れてしまうという特性があるんですね。
クロードコードのセッションが始まったときには、
すでにこのクロードコードのアントロピックが指示している裏側の指示文がたくさん入っていて、
それに加えてクロード.mdに指示をたくさん書いてしまうと、
中途半端に忘れていってしまって、
期待した答えが返ってこないということが起こります。
なので、短く書く、つまりは指示の個数が少なくなるということなので、
まず少なく書きましょうというところが一番大事なベストプラクティスです。
次に大事になってくるのは、明確な指示をしましょうというところなんですけれども、
例えば開発コードのフローでいうと、
最後にプルリクエストを作成するようにしてくださいとクロード.mdに書いたとして、
これだとまだ曖昧で、より具体的に書くのであれば、
ghコマンドを使ってプルリクエストを作成してくださいと書くとより明確ですよねと。
さらに言うと、ghコマンドの例を貼って、
これを使ってくださいと指示するとより明確で、
毎回全然違うコマンドを打つことはなくて、
基本的には決まりきったコマンドを実行してくれるということがあるので、
曖昧な指示ではなくて明確な指示。
コードベースで書けるのであれば、
コードベースで書いてそれを貼るということをするとすごくいいかなというところです。
3番目に大事なベストプラクティスは、
スラッシュイニットに頼らないというところです。
クロードコードでスラッシュイニットってやると、
リポジトリの構成とかを読んだ上で、
クロード.mdを自動的に書いてくれるという仕組みがあるんですけれども、
これを使って書いてしまうと、結構長い文章で書いてきてしまうんですね。
それが起きると、さっき話したように、できるだけ短く書きましょうとか、
明確な指示でしましょうというところが、
読められないクロード.mdが書かれることが非常に多いです。
なんですけれども、このクロード.mdをいきなりゼロから書くのって非常に難しいと思うので、
まず一旦スラッシュイニットで書いた上で、
それを参考にしながら、もう一回ゼロベースで自分の手で書くというのが、
非常にいいやり方かなというふうに私は考えています。
最後にティップスとしてあるのは、
クロードコードで使えるモデル、オーパス、ソネット、ハイクとありますけれども、
それぞれのモデルを切り替えてあげながら、
このクロード.mdの説明は説明しすぎの部分がないですか、
逆に説明不足の部分がないですかというふうに聞いてあげるんですね、それぞれモデルごとに。
そうすると、例えばオーパスであれば非常に大規模なモデルなので、
わりとロバストに書いても理解してくれるので、
ちょっとここは説明しすぎですと書いてきたりとか、
逆にハイクは非常に小さいモデルなので、
より具体的に書いてあげないと変な行動してしまうということがある。
ということがあるので、このオーパス、ソネット、ハイクと、
皆さんが日々クロードコードを使うときに使うであろうモデル、
それぞれに対してこのクロードコードって正しく書いてますかって聞いてあげて、
そのフィードバックをもとに改善したものを性として展開していくということが
ベストプラクティスかなというふうに思っています。
以上がクロード.mdを使うときのベストプラクティスで、
まずクロードコード.mdを書きましょうというところがまず言いたいところです。
ルール図とスキル図の説明
次に話すのはルール図です。
ルール図であまり使わない方がいるかもしれないんですけれども、
特定のディレクトリとかファイル拡張しの場合のみ参照してほしいプロンプトを書くために使うものです。
ルール図もマークダウンで書くんですけれども、
マークダウンの最初にパスパターンを書いておくことができるというのが特徴です。
これはいつ使うかというと、
例えばですけれどもリポジトリの中にPythonとTypeScriptのコードがあって、
それぞれのコードスタイルを記述したいとLLMに指示したいというときに、
PythonであればパスパターンのところにAsterisk.pyと書いて、
その下にPythonのベストプラクティスを書いてあげる。
Asterisk.tsと書いた上でTypeScriptのベストプラクティスを書いてあげるということができます。
それから例えばテストコードを書くときのルール。
これは言語によって違いますけれども、
例えばスラッシュ.テストスラッシュの配下にテストコードがあるのであれば、
そのパスパターンを書いてあげた上で、
テストコードを書くときのルールベースを書いてあげるというふうな使い方をルール図ではやります。
ルール図を使うときのベストプラクティスも共有したいんですけれども、
いきなりルール図を書くのは正直難しいと思っていて、
まずcloud.mdに全部書いてしまって、
書いた上で先ほど話したように300行を超えてきたら、
そのときにこれって特定のディレクトリとかファイル拡張しのときだけ参照してくれればいいルールだなって、
判断したものをガツッとルール図にコピーして持っていくというやり方が非常にやりやすいかなというふうに考えています。
それ以外のベストプラクティスはcloud.mdと同じで、
どれだけ短く指示文を書きましょうというところと、
明確な指示にしましょうというところと、
オーパスソネット俳句にこのルール図がベストなのか、
説明しすぎがないのか、説明不足がないのかって聞いてチェックするというところが
同じようなベストプラクティスだというふうに考えています。
では次に紹介したいのはスキル図です。
スキル図はちょっとルール図と似ている部分はあるんですけれども、
特定の指示条件の場合のみ参照してほしいプロンプトを書くためのものです。
スキル図も同じようにマークダウンで書くことができるんですけれども、
マークダウンの最初にスキル図の説明、ディスクリプションを書いておくことができるというのが特徴です。
スキル図をいつ使うかというと、
例えばですけれどもディスクリプションにこのスキル図はコミットの方法を示したものです。
ユーザーがコミットしてと指示した場合に参照します。
みたいなふうに書いておくと、ユーザーが実際にコミットしてと言ったときに
初めてこのスキル図の中身がロードされて実行されるという仕組みになっています。
ルール図との違いなんですが、ルール図は先ほども説明したみたいに
パスパターンで自動的に呼び出されるという仕組みです。
なんですけれども、パスパターンで指定できないものっていろいろありますよね。
例えば先ほどお話したコミットしてみたいなものはパスパターンではないので、
特定のディレクトリーとか特定の拡張して条件付けできない場合にスキル図を使うと良いです。
スキル図はこのディスクリプションに自然言語で呼び出しする条件を設定することができるので
非常に自由度が高いというメリットがあります。
一方で、時折このディスクリプションに書いているんだけれども
呼び出されるように実行されない、無視されるということが起きるので
パスパターンで明確に書けるのであれば
ルール図に書いておいた方が自動的に読み込まれていいかなと思います。
スキル図のベストプラクティス
では、スキル図のベストプラクティスもいくつかあるんですけれども
まず一つ目はネーミングルールです。
クロードのドキュメントに書いているのは
例えばテスティング-コードみたいに
同時かけるingの形でスキル名を書いておきましょうというのが書いています。
これが一つ目です。
それからディスクリプションを第三者視点で書きましょうというふうに書かれています。
これはつまりあなたは何とかですとか
私はこうですみたいなディスクリプションではなくて
このスキル図はこうこうこういうものですみたいな感じで
第三者視点で書くということです。
これはディスクリプションの部分とネームの部分が
システムプロンプトに入っていくんですけれども
スキルによってあるスキルは一人称で書いていたりとか
あるスキルは二人称で書いていたりとか
あとはネーミングの規則がバラバラになっていると
それこそLNが混乱してしまって
正しくスキルを呼び出してくれないという挙動になってしまいます。
なのでできるだけ名前の規則とかディスクリプションの規則を合わせてあげるということが
このスキル図が正しく読み込まれるためのベストプラクティスです。
それ以外のベストプラクティスは今まで話した
クロール.mdとかスキルルール図と同じで
短く書くとか明確な指示をするとか
オーパスハイクソネットにこの説明が正しいかどうかをチェックするところは同じです。
スラッシュコマンドの理解
最後に紹介したいのはスラッシュコマンドです。
だんだん増えてきてわけがわからなくなってきたところだと思うんですけれども
この後解説しますのでご安心ください。
まずスラッシュコマンドについて解説したいと思います。
スラッシュコマンドは特定のプロンプトをブックマークみたいに保存しておいて
ユーザーが任意のタイミングで呼び出して使うためのものです。
いつ使うかを整理するとまずスキル図とかルール図は
AIもしくはロジックで呼び出すタイミング図を自動的に判断して
実行されますという部分でしたね。
スラッシュコマンドについてはユーザーが呼び出すタイミングを
自律的にコントロールするというためのものです。
なので今コミットしたいとか今テストしてほしいとか今コードレビューしてほしい
みたいに今この瞬間明示的にこのプロンプトをやってくれという場合に
使うのがこのスラッシュコマンドです。
このスラッシュコマンドのベストプラクティスについては
もうこれは全く他のやり方と同じで
短くかくとか明確な指示をするとかその辺は全く同じです。
ここで混乱してくるのはスキル図と何が違うんですか
というところがわからなくなってくると思います。
私も最初はこのスキル図が出た時に
スラッシュコマンドと何が違うんだという風に思ったのをすごく覚えているんですけれども
例えば混乱する例で言うとコミットしたいという時に
スキル図を作ってあげてコミットしてってプロンプトに指示文に書くのと
スラッシュコマンドでスラッシュコミットって呼び出すのと
何が違うんですかと
いややってること一緒じゃないですか
どうせ明確に呼ぶんだったらスラッシュコミットって
明確に呼び出してあげた方がいいんじゃないですかという風に疑問に思うと思うんですけれども
結論を変えるとこのスキル図とスラッシュコマンドは
ほぼ同じな場合が結構あるというところです
要は呼び出し方の違いの問題であって
コミットしてと自然言語で言いたいか
スラッシュコミットって明示的にコマンドとして打ちたいか
この違いだけなんですね
それでこの最多の例が最近の機能で
スキル図をスラッシュコマンドで呼び出せるようになった
っていうアップデートがありました
例えばコミッティングギットっていうスキル図を作っていて
本来であればコミットしてって自然言語で呼び出すんですけれども
スラッシュコミッティングギットって呼び出すこともできるようになってきました
まさに公式が認めたようにスキル図とスラッシュコマンドって
ほとんど同じ条件で使うものですよねっていうところが一つ証明かなという風に思っています
でも一方で基本的には今後はスキル図に寄せていった方がいいかな
っていうのは私の考えです
一つまず理由があるのはスラッシュコマンドがだんだん増えてくると
覚えるの大変ですよねっていうところがあります
自分で書いたスラッシュコマンドであればまだいいんですけれども
例えばメンバー他のエンジニアが書いたスラッシュコマンドまで
全部覚えられるかっていうとだんだん数が増えてくると難しくなってくるし
いつ使うべきかっていうところをみんな共通認識として持っていないと
正しく使うことができないんですね
なのでこのスキル図にちゃんとディスクリプションに
こういう場合にこのスキル図を呼び出しますって書いておけば
別にユーザーが意識しなくてもクロードコードで開発している間のテキストを読んでくれて
自動的にこの瞬間このスキル図を使うべきだって自動的に判断してくれるので
このスラッシュコマンドが増えてきて覚えるのが大変だから
スキル図に寄せていきましょうって考えた方がまず一つ
それからスラッシュコマンドで全部ユーザーが指示をしていると
それこそ開発成長性が上がっていかないという問題があるかなというふうに思っています
例えばですけどコミットしてほしいときにスラッシュコミットって打つまで
クロードコードが何もしてくれないんだったら非常に不便ですよね
それよりかは自動的にこのスキル図を読んでくれて
コードの実装が終わったらこのスキル図を呼び出してコミットしてっていうふうに
ディスクリプションを書いておいてそれで自律的に動いてくれて
その後にテストのスキル図をまた自律的に読んでくれて
プルリクエストのスキル図をまた自律的に読んでくれてっていうふうにやってくれた方が
ユーザーから手離れが多くて自律的にLLMが動いてくれて
開発成長性が上がるというふうに考えているので
スラッシュコマンドを使うのは最低限にしておいて
ツールの使い分け
基本的に全部スキル図にしてしまってユーザーは
ある意味でどういうスキルがあるかを把握しておかなくていいという状態に持っていくことが
非常に今後大事になってくるかなというふうに思っています
ここまででcloud.md ルール図スキル図スラッシュコマンドと説明したんですけれども
増えてくるとだんだんわけがわからなくなってきます
私も少し前まではそうでした
これをわかりやすく理解するための方法が2つあります
まず一つ目は一旦cloud.mdを書きます
書いた上でこの段段長くなってきました
長くなってきたものに対してこの部分はルール図にしたほうがいいなとか
ここはスキル図にしようとか
ここは明示的に使うときだけ呼び出せばいいのでスラッシュコマンドにしようかなというふうに
cloud.mdを基本にしてだんだんと他のツールに切り替えていくという方法が一つあります
それから2つ目の理解は結局全部プロンプトであって
呼び出されるタイミングが違うだけだというふうに認識しておくことです
よく混乱するやってしまいがちな方法としては
これcloud.mdに書くべきなのかなルールなのかなスラッシュコマンドなのかなスキル図なのかなって
まず考えた上で指示文を考えてしまうんですけれども
そうではなくてまず一旦指示文を書きますマークダウンで
書いた上でこの指示をいつ読んでほしいかっていうのを考えて
cloud.mdに書くのかルール図に書くのかスキル図に書くのかっていうのを考えるっていう
逆転の発想が必要かなというふうに思っています
具体的にはまず指示文を書きますよね
この指示文をセッションが始まるたびに毎回絶対読んでほしいのであれば
cloud.mdに書くし特定のパスパターンで呼べば十分なのであれば
ルール図に書けばいいし特定の自然言語指示条件で呼び出されたいのであれば
スキル図に書けばいいし自分が明示的にこの指示文を呼び出したいのであれば
スラッシュコマンドに書けばいいっていうふうに理解すると
このたくさんあるツールの使い分けがだんだん整理されて分かってくるんじゃないかなというふうに個人的には思っていて
自分の中ではこの整理によって使い分けが非常にやりやすくなったかなというふうに思っているところです
皆さんもぜひこの考え方で新しいルール図とかスキル図とか作ってみていただければというふうに思います
ということで今回はクロードコードのcloud.mdスキル図ルール図スラッシュコマンドの使い方という話をしてみました
皆さんのクロードコードマスターの道に一歩でも貢献できたら何よりかなというふうに思っております
それでは次回の配信でお会いしましょう
ではでは
