はじめに：Claude Codeの現状とベストプラクティスドキュメントの紹介
こんにちは。
いつもの、突然、真面目な技術。略して、いつまじラジオのJです。
上原です。
今回は、先週に引き続き、AI界ということで、
今日は、クロードコードについて話そうかなと思っています。
上原さん、普段クロードコードを使う機会はありますか?
クロードコードは一応課金をしていて、
プライベートだとGeminiは使えないっていうか、
会社のアカウントじゃないんで、
クロードコードをプライベートでは使ってますね。
業務では全然使ってない?
業務では、そうですね。
Geminiとの比較とかで使ったりはするけど。
Geminiがこう言ってきたけど、どう思う?みたいな。
いや、同じ文章を加わせた時に、
どっちがいい感じに構成してくれるかなっていう、
使い方を結構してますね。
そんなクロードコードですが、
去年の6月頭ぐらいにユーザーが増えて、
それまでAPIでしか使えなかったのが、
クロードプロプランでもクロードコードが使えるようになって、
ユーザーが増えたかなと思うんですけど、
多くもそのタイミングぐらいで使い始めていて、
とはいえそんなに使い方を、
テクニックみたいなのはあんまり調べずに
軽く使ってるぐらいな感じだったんですが、
今年はもうちょっとAIと仲良くなろうと思っているんですね。
アンソロピックから先月の1月22ぐらい、
正確な日付はわかんないんですが、
Xで観測したのは1月22なんですが、
とあるドキュメントが追加されていて、
それが今日話す、
ベストプラクティシーズフォーククロードコード
っていうのが出てるんですね。
こんなの出てたの知ってました?
クロードコードの最適な使い方みたいなのが、
Xで確かにバズってたのは見た。
中身、アンソロピックの人が、
Xで投稿してたのかな?
きっとそれの関連だと思うんですが、
僕もその頃にふーんと思ってたぐらいで、
あんまちゃんと見てなかったんですが、
やっとある程度、ちゃんととは言いませんが、
ある程度は見たんで、
今日はそれについて話していこうかなと思っています。
詳しく深掘っていくっていうよりは、
これをまだ読んでいない人が、
読んでみようかなというふうになるような、
とっかかりになるような回になればと思っています。
早速内容に入っていくんですが、
コンテキストウィンドウの重要性と基本的な説明
まず前提というか、
大事な部分っていうのが最初に書かれていて、
コンテキストウィンドウが大事ですよ、
みたいなことが書かれてたんですね。
コンテキストウィンドウって、
僕そんなにハッキリとは詳しくしゃべれないんですが、
ちなみに上原さんってコンテキストウィンドウ説明できたりします?
いや、僕もあんまり調べてないからわかんないけど、
でも名前的には、
要するに文脈を結構分けてやりなさいみたいなイメージなのかなっていうのと、
最近のAIの使い方として、
その評価パイプラインみたいなのをつけて、
大きな文脈で話すんではなくて、
小分けにして評価とかもしなさいよみたいなことが言われてるんで、
そういう意味合いでの、
多分コンテキストウィンドウが重要って言ってるのかなっていう。
たぶんそんな感じで、
なんで上原さんに聞いたかというと、
先週AI社会を話していて、
この辺も学ぶ範囲に入ってたかなと思って、
淡い記載をして投げたって感じでした。
なるほど。
先週のだとやりとり繰り返すっていうよりは、
1回ドンと投げて帰ってくるっていう感じだから、
そんなにがっとりコンテキストウィンドウを意識するっていう感じじゃないってことですよね。
あれはそうですね、
あんまりコンテキストウィンドウとかを意識はしていない。
コンテキストウィンドウを意識するときって何かものを作る、
どちらかっていうと、
プロダクトに搭載する機能というよりも、
その搭載する機能を評価とか品質をチェックする、
なんかCIとかに組み込めたら組み込みたいようなパイプラインみたいなのに、
のを作るときに意識すべきなのかなって理解ですね。
その辺の知見があんまりないんで、
そうなんですよとはちょっと僕は言えないんですが。
なんかオライディから出てるAir Engineeringっていう書籍があって、
それが結構網羅的にいろいろ今のAIの使い方とか、
注目すべきところみたいなの書かれてるんでおすすめです。
AI周りの書籍はまだ読んでないんで、
まだ優先順位上がってはないんですが、
いつか読みたいと思います。
戻るんですが、
コンテキストウィンドウは大事だよっていうことが書いてあって、
簡単な説明もあって、
例えばデバッグさせたりとか、
コードベースの探索をしたりとか、
っていう依頼をしたりすることもあると思うんですが、
そうすると平気で数万トークンとか消費したりするらしいんですが、
コンテキストウィンドウがいっぱいになってくるにつれて、
パフォーマンスが低下するっていうのは言われていて、
そうなってくると指示を、最初の指示を忘れたりとか、
間違いを犯したりとかっていうことが増えてくるっていうことですね。
なのでコンテキストウィンドウの管理はすごく大事だよっていうことが、
最初に書かれていました。
ベストプラクティス1：検証方法を与える
ここからベストプラクティスの話をしていくんですが、
7つ書いてあって、
プラスしてよくある失敗パターンみたいなのが書いてあったんで、
7つのうち5つ今日は紹介しようかなと思います。
その除いた2つは今日はいいかなみたいな感じの内容だったんで、
5つです。
まず1つ目が検証方法を与えるっていうもので、
例えばテスト、何々したらテスト実行してねとか、
スクリーンショット渡して比較してねとか、
何かしらの実装した結果の効果、
結果を検証する方法があると、
パフォーマンスが劇的に良くなるよみたいなことが書かれていました。
検証方法、違うな、戦略か。
戦略として3つほどページには載って、
そのページは概要欄には貼っておこうと思うんですが、
3つほど戦略が書いてあって、
1個目1つ紹介すると、
検証基準を提供するっていうようなことが書かれていまして、
悪いプロンプトとして、
メールアドレスを検証する関数を実装するっていうようなことが書かれていて、
それを良いプロンプトとしては、
バリットEメール関数を書く。
テストケースの例、
user.example.comはtrue、
invalidはfalse、
user.comはfalse、
実装後にテストを実行する、
みたいな感じでやることで、
何は良くて何はダメで、
でテストを実行したいみたいな感じでやると、
良いよというようなことが書かれてますね。
結構、この生成AIでのコードを書くっていう話において、
TDDと相性が良いって話はよく聞くんで、
その辺の話ってこういうことなんだろうな、
みたいな感じで思ったっていうところですね。
個人的な実感としても、
先にTDDとはちょっと違うんですが、
がっつりとテストだけ書いた状態でクロードに依頼すると、
そのテストはちゃんと通すまでやってくれるんで、
ここは実感としてもあるところではありますね。
次が、まずは調査、
ベストプラクティス2：調査、計画、実装、コミットのワークフロー
次に設計、そして実装みたいな話で、
実装ストリートだって推奨されるワークフローとして、
4つのフェーズがあるということで、
まず1つ目が探索。
探索っていうのは、
まず探索の段階でプランモードに入って、
修正したい周辺のコードを読み込むように、
クロードコードに依頼をする。
2つ目が計画ですね。
計画の段階で探索した結果を基に計画を立ててもらう。
3つ目が実装で、
クロードコードのプランモードだと、
計画を立ててもらった後に実装するときは、
Enterをポンと押せば実装してくれるので、
計画を承認すればやってくれるというところで、
最終的にはコミット。
4つ目はコミットという感じですね。
補足的なところですが、
プランモードにするには、
スラッシュプラン、プランコマンドでプランモードにするか、
シフトタブでモードの切り替えができるので、
通常モードから、
自動実行モードとプランモードの3つの切り替えができるので、
それにプランモードに変えることで、
プランモードには変えられます。
僕もプランモードは結構使うんですけど、
この探索っていうのはあまりやってないなと。
ざっくりとCダウンと出して、
この計画立ててっていう風にやっているケースが多いので、
そうすると多分この1番の探索って、
実装したい関連コードを読んでもらうような感じになるんだと思うんですが、
僕のやり方だと関係ないところも色々コードを見に行くんで、
必要以上にトークンを消費してしまっているという状況があると思うので、
多分この探索っていうフェーズが大事なんだろうなという風には思っていますね。
ただ修正範囲が分からないケースもあると思うので、
そういった場合は一旦後範囲に調査依頼して、
別のセッションで調査してもらった内容を元にプロンプト投げていくっていうのも、
多分いいやり方なんだろうなと、
コンテキストウィンドウ観点だと思ったりもしました。
クロードコードってターミナル経由で使うの?
そうですね、基本的にはターミナル経由で使うやつですね。
プランモードとかモードみたいなのが書かれてるけど、
これは何かで切り替えられる?コマンドみたいなので切り替えるみたいな?
そうですね、コマンドが用意されているのと、
あとShiftプラスタブを押すとモードが切り替わるんですよ。
普通のモードって何かって言われてるんですか?
普通のモードと自動実行モード、承認聞かずにどんどん実行していくモードとプランモード。
プランモードは基本的には変更は加えずに色々と調査をして、
その調査結果を基に計画を立てて、こんな実装しようと思ってますっていうのを向こうが提示してくれて、
それで問題なければOKみたいな感じでやると実装してくれるというやつです。
プランとノーマルで使ってるAIっていうかモデルが違うみたいな、
中身の話だから分かんないかもしれないけど。
モデルは一緒だけど多分それに実装に対するアプローチが違うっていう感じですかね。
プランモードは一旦ガガーッと全部関連するところを見て、それを基に実装計画を立てる。
通常モードもある程度読み込んではいると思うんですけど、
つどつどここを変更します、じゃあお願いします、
次のところ行ってここを変更しようと思います、こっちがお願いしますっていうのをやり取りしつつやってますね、通常モードは。
アプローチの違いだと思います。
自動モードっていうのは多分通常モードのつどつど聞いてくるのを自動でどんどんやってもらうみたいなイメージだというふうに認識してます。
探索をするときって範囲を指定したほうがいいって感じなの?
それとも自由に探索してくれでいけるものなの?
トークンとかコンテキストウィンドウっていう文脈を無視するのであればどっちでも大丈夫です。
じゃあ範囲が広ければ広いほどやっぱりトークンの消費も増えていくっていうことでね。
だと思いますね。別々のプロンプト投げてトークン数の違いとかを比べたことはないんですけど、
多分そういうそこのコンテキストウィンドウだろう、トークンだろうっていうところの違いが一番大きいんじゃないかなとは思う。
入力のトークンが文字の数でやっぱ増えていくから、
っていうことはやっぱりコメントとかも読み込まないようにしてあげた方がトークンの圧縮にはつながるのか。
それは確かにそうかもしれないですね。
どうやらビビタルもんな気もするけどコメント外だったら。
なるほど。
ベストプラクティス3：プロンプトに具体的なコンテキストを含める
次がプロンプトに具体的なコンテキストを含めるっていうところで、
ちょうどあくればちゃんと指示しようねっていう話ではあるんですが、
戦略としてこれも4つ挙げられていて、
このうち2つぐらい読もうと思うんですが、
まずソースを指摘する。
悪い例としてExecutionFactoryみたいなメソッドクラスがあるとして、
ExecutionFactoryがこんなに奇妙なAIPIを持っているのはなぜですかと。
ちょっと直訳っぽい文章ですが。
っていうのが悪いので、
良い方として挙げられているのは、
ExecutionFactoryのGit履歴を調べて、
そのAPIがどのようになったか予約するという感じで書いてあって、
ここで言うソースっていうのがGitですね。
それがどういう経緯でなったのかとか、
そういった調査はGitを元にしてね、
というような情報ソースを与えてあげることで、
いろんなところを見に行くんじゃなくて、
Gitに絞って見に行くことで、
トークンを無駄に消費しないとか、
そういう話なんだと思います。
こうやってGitの履歴を持って調べてくれるんだ。
そうですね、Gitの、
この後またちょっと触れようとは思っているんですけど、
Gitとかそういう何だろうな、
AWSとかいろいろコマンドとかは、
あくまでやっぱりターミナルベースであるんで使えるんで、
何かしらのコマンドを使った上でやっているんだとは思うんですけど、
そういうことはできます。
調査とか便利だね、そう考えると。
調査にはよく使っている、
今実装する、ポジション的に実装はしないけど、
グロードコードに依頼して調査をしているっていう人はやっぱりいるイメージはありますね。
なるほどね。
これは何モードで使う?プランモード?
ノーマルモードで調査ってする?
ノーマルでいいと思います。
調査してくださいって言えば、
実装こういうふうに変えますとかっていうことは向こうから投げてこず、
調査で終わってくれるんで基本的には。
オートモードにすると勝手に聞かせて実装し始めたりする可能性があるんで、
オートモード以外だったらどっちでもいいかもしれない。
あともう一つ挙げておくと症状を説明するってあって、
悪い例としてはログインバグを修正するとだけ投げるのが悪い例としたがっていて、
良い例としてはユーザーはセッションタイムアウト後にログインが失敗すると報告しています。
SRCすらオースすらの認証フロー、特にトークン更新を確認します。
問題を再現する失敗テストが修正するみたいな。
具体的にどういうことが起きていますよっていうことをちゃんと伝えてあげようねっていうことが書かれていますね。
ちなみにここの今の挙げた戦略と最初の戦略って何が違うんだっけ?
最初の方は検証方法を教えてあげようねっていう話で、
今回はその状況とか背景の知識を適切に与えてあげようねっていうことです。
一つ目が検証方法を与える。今回のが具体的なコンテキストを含める。
取っかかるにあたっての情報が今回で、取っかかった後の検証方法を与えるのが最初の。
これは2つ同じプロンプトで伝えてねっていう感じ?
そうなると思いますね。
プロンプトはある程度長くはなると思いますが、背景を与えて検証方法を与えてっていうのは一つでやると思います。
コンテキストを提供するにあたって、こんな方法を使えますよっていうことが分かっていて、
まずアットマークを先頭につけてあげると、ファイルの参照先を教えてあげたりできるので、
これを使うとか、あと画像の貼り付け、マスク紙を取ってクロードコードに貼り付けて参照させるとかできたりするのと、
APIのドキュメントのURLを渡して読んでもらうとか、そういったことができるので、
コンテンツの提供もしていこうねっていうことが図られてますね。
ベストプラクティス4：環境を構築する（cloud.md, パーミッション, CLIツール, Skills）
次が環境を構築するっていうところですが、まず何といってもcloud.mdですね。
cloud.mdっていうのは全てのセッションで必ず読み込まれるもの。
こちらが指示しなくても勝手に読みに行くファイルになるんで、
ここに情報を載せてあげると、そこからもう知識を得るっていうような動きになっています。
ただ逆に言うと必ず読みに行くんで、調査してほしいときに細かい実装方法とか書かれているとそれはノイズになってしまうので、
必要なものはしっかりと絞り込んで書くほうがいいとされています。
なので、不要なものはどんどん消していこうねみたいなことが書いてあって、
その判断基準的なことも書いてあったんですが、
日本語訳ですが、これを発作除するとcloudが間違いを犯す原因になりますかというふうに自身に問いかけてみて、
その間違いを犯す原因にはならなさそうだなと思えば消しちゃうんで。
ところでどんどん削っていくほうがいいみたいですね。
いくつか例も入ってあるんで、いくつか出していくと、
含めたほうがいいものとしては、cloudが推測できないバッシュコマンドとか、
こういうときにこのコマンドを使ってねとかそういった情報だと思います。
あとはプロジェクト固有のアーキテクチャとか、
デフォルトと異なるコードスタイルとか。
逆にこういうの入れなくていいよっていうのは、
cloudがコードを読むことで理解できるものだったりとか、
一般的な言語の書き方とか、
あとは長い説明だったり、チュートリアルとか頻繁に変わる情報とか、
こういったものはあまり含めるべきではないっていうふうに書かれています。
ざっくりですがcloud.mdとしてはこんな感じです。
次にパーミッションの設定っていうのがあって、
cloudコード何かしらコマンドを実行するとき、
こっちにこういうコマンドを実行していいですかっていうふうに聞いてくるんですが、
そのタイミングで選択肢として実行してよし、実行しない、
中間択としてこのコマンドは実行するかつ、
このコマンドはもう今後確認取らなくてOKみたいなのがあるんで、
破壊的な変更をしてしまうようなコマンドは多分許可、
永続的な許可はしない方がいいとは思うんですが、
例えばファインドとかファイル探すコマンドだったりとか、
LSとか、ただ参照するだけのコマンドなんかは
パーミッション設定で許可しておいていいのかなと思います。
基本的にはファインドとかLSみたいなCDコマンドとか、
そんなのは許可してあげて、
今後は勝手にやってもらうようにするといいのかなと思います。
次がCLIツールっていうところで、
さっきちょっとGitHubだと何だろうって話したんですけど、
GitHubのGHコマンドとかっていうところも使えるようにしておいてあげると、
例えばGitHubのURLとか渡して、
僕とかよくやるんですが、
もらったGitHubのプルリクのURLぶん投げて、
コメント来てるから対応してって言ってやると、
コメント読んだ上で対応までやってくれるとかっていうのもあるんで、
そういう使い方ができるとか、
あと僕はあんまりやったことないですが、
AWSコマンドとかそういったものも使ったりとか、
セントリーとかっていうところも上がってたんで、
そういうのを駆使すれば、
わざわざ自分で例えばセントリー見て、
セントリーの情報を自分で解釈して、
クロード講座に投げるんじゃなくて、
セントリーの情報を直接見に行ってもらって、
っていうことができるようになるのかなと思います。
あとはSkillsっていうのがあって、
ここはちょっと僕もまだ勉強中、
勉強し始めぐらいであんまり語れないんですが、
さっきクロード.mdはシンプルにしようねっていう話があったんですが、
Skillsっていうのが逆に何かに特化した情報を載せるようなものだと思います。
例として上がっているのは、
Fix Issueっていうスキルを登録すると。
なので、IssueをGitHubとかのIssueを実装するとかしたいときは、
このSkillsを使って実装するように、
このコマンドでIssueを見て、
こういう実装してねみたいな手段が書かれているっていうようなものになるんで、
具体的なことを書くときはこっちなのかなと思います。
次、5番目が、
ベストプラクティス5：効果的なコミュニケーションとセッション管理
効果的なコミュニケーションを図るっていうところなんですが、
ここは端折っちゃおうかなと思っています。
個人的なイメージとしては、
さっきちょっと話したんですが、
調査で使うとか何だとかっていうふうに扱い方をするようなときに、
ここのプラクティスが使われるかなと思うんですが、
中には特別なプロンプトは必要ありませんとすら書いてあったんで、
多分みんないい感じにコミュニケーションして、
調査してもらったりしてるかなと思うんで、
ここは端折っていきます。
6番目がセッションの管理ですと、
最初に話したコンテキストウィンドウに関わる話なのかなと思うんですが、
Cloudとの会話っていうのは過虐的なので、
なるべく間違いがあれば修正とか方向修正しようねみたいなことが書かれていて、
ここでも4つの手段が書かれていて、
まずEscapeキーですね。
Escapeキーを押すとCloudの動作を途中で停止することができます。
ただCloudのその瞬間のやり取りというか、
Cloudの動きを止めるだけなんで、
これまでのコンテキストはここでされるんで、
誤ったほうがここに行きそうだなと思えばEscapeキーで止めて、
別の知事出したりできますよっていうのがあったりとか、
あとはEscapeキーを2回押す、
もしくはスラッシュコマンドのリワインドを使う。
これは例は僕も最近知ったばっかなんですが、
後でまたちょっと触れるんですが、
会話履歴を少し前の会話履歴に戻って、
そこから再度スタートできるみたいなコマンドです。
3つ目がUndo that。
これは使ったことはないんですが、
Cloudが行った変更の取り消しをできるようです。
これを多分会話の文章、
このプロンプトの中に含めるって話だと思います。
1回も使ったことないんで多分そうだと。
スラッシュコマンドのクリアですね。
次のタスクを行うときは今のコンテキストウィンドウを捨てて、
次のコンテキストセッションでやる際に一度スラッシュクリアして、
リセットしてあげるっていうところですね。
リワインドについてまた触れるんですが、
さっき話したようにEscapeを2回押すか、
スラッシュリワインドで会話の復元ができますというもので、
使いどころとしては、
例えばさっきプランモードの話をしたんですが、
プランモードで上がってきた内容で
実装意図がわからなかったりするケースってあるんですけど、
その場合にここってなんでこうするの?っていう
追加質問をしたりするケースがあるんですけど、
そうするとその質問したことも
当然コンテキストウィンドウに含まれてしまうので、
これからの実装においてはノイズになっちゃうっていうところがあるんで、
そのノイズ、追加質問の前の計画を出したところに
リワインドで戻ってあげることで、
自分自身の知識は保管しつつも、
クロードとしては元の計画を上げたばかりの
比較的フレッシュな状態に戻すっていう風なことができるっていうようなものなんで、
いろいろとわからなくて聞いたこととかがあるんであれば、
聞く前に戻ってから次に進む方がいいよっていうようなやつです。
あと他に上がってたものとしては、
調査にサブエージェントを使用するっていうものがあって、
ここもあまりキャッチアップできてないんですけども、
サブエージェントは別のコンテキストウィンドウが存在するようで、
メインのセッションとは独立してるらしいです。
なので調査とかするときはサブエージェントに調査依頼するような
ロンプトを書くのか、
クロード.mdに入れたほうがいいのかとかちょっとわかんないんですけど、
そこのサブエージェントに依頼することで、
メインのセッションのコンテキストウィンドウは汚さずに調査ができる。
その調査結果だけもらうっていう感じだと思います。
最後7つ目が自動カトスケールっていうところなんですが、
ベストプラクティス6：自動カトスケール（応用編）
ここはこれまでの話と比べると結構応用編みたいな感じだったんで、
ここは興味ある方は見ていただければなと思っています。
ということでベストプラクティス7つとしては以上で、
よくある失敗例とその対策
次はよくある失敗例なんですが、
5つほど載ってますが、
これまでの話を踏まえるとなるほどなっていうような内容ばかり。
なのでざざっと話していこうと思うんですけど、
まず1つ目がキッチンシンクセクション、セッション。
これ聞いてもあんまりよくわかんないんですが、
ざっくり言えばセッション中に関係ない質問をするなというところですね。
余計なノイズを増やすなというところです。
2つ目が何度も修正する。
1回の対応で依頼でうまく実装ができずに、
ここ直してってやって直してもらって、
ここも直してみたいな感じで何度か修正依頼するっていうこともあると思うんですが、
そういったことを繰り返すとコンテキストウィンドウがどんどん
状態が悪くなっていくんで、何度も修正したことを踏まえた上で、
もう一度プロンプトを作り直して、
1回やるほうがいい結果になるよっていうようなものです。
3つ目がCADに指定されたcloud.mdですね。
さっきcloud.mdのところでも話したんですけど、
この中身が長すぎると重要なルールを見落とす恐れがあるんで、
なるべく短くしていこうねっていうことですね。
容赦なく削除しろみたいな感じで書いてます。
4つ目がまず信頼し、後で検証するという動き。
AI、行動に限らず最もらしい実装だったりとか返答っていうのをしてくるんで、
ちゃんと検証しようねっていう話ですね。
最後が無限探索。
探索依頼する際はある程度スコープ絞って依頼しようねっていう、
最初のほうで話した話です。
探索の範囲が広くなるのであればサービスエージェントを活用してねみたいなことも流行ってます。
5つよくある失敗例として分かっていました。
直感を養う：AIとの付き合い方と開発者の役割
最後に直感を養うみたいなところも書いてあったんで、
そこも読み上げます。
いいことが書いてある感じがあるんで。
このガイドで紹介しているパターンは決して絶対的なルールではありません。
あくまでも一般的に効果が高いとされる出発点であり、
あらゆる状況において最適であるとは限りません。
時には複雑な問題に深く取り組んでおり、
それまでの経緯が重要な意味を持つため、
あえてコンテキストを蓄積させたほうが良い場面もあります。
また探索的なタスクであれば、
あえて計画を立てずにクロードに任せてみるのも一つの手です。
さらに制約を加える前にクロードが問題をどう解釈するのか、
見極めたいときはあえて曖昧なプロンプトを与えるのは正解ということもあります。
みたいな、もうちょっといろいろ書いてあるんですが、
雑に言うと、予約すると銀の段階の9から繰り返し直感を養ってね、
みたいなと書かれているんで、
これはクロードコードに限らず、あらゆるところに入れるような話が入ってあって、
お締めの言葉としては、なるほどな、いい締めだったなと思ったので、
ぜひ読んでみてください。
ざっくりとこんな感じのことが、
このクロードコード、なんだっけ、
Best Practices for Clod Codeに書いてあった内容でした。
という紹介でした。
これを知っているか知っていないかで、
クロードコード力がある程度、いや全くじゃない、
実際に比べれば結構違ってくるんだと思います。
どうでした?
なんか、クロードコードの使い、クロードコードの存在は知ってたけど、
やっぱり今開発してないから、
ほとんど使ってなかったけど、
なるほど、そういう使い方かっていうのが、
分かったのは良かったなって思いました。
もしも僕が、これまでの開発経験から、
使いどころを選ぶのだとしたら、
設計をする前の調査を、
調査をする際にも多分どこを調べるかっていうのをまず、
計画を立てるんだけど、
そこは多分人間の手でやって、
その計画を与えて調査結果をもらい、
それを元にまた、多分実装計画を立てることになるんだけど、
その実装計画はまたこちらで立て、
実装部分をお願いするみたいな感じになりそうだなみたいなの。
イメージしましたね。
もうちょっとAIに任せればいい気がするけど。
AIをどこまで創造的な生き物だと、
生き物なのか機械なのか、無機物だと、
生き物として捉えるかっていうのが結構重要。
どこまで任せるかの境界線になりそうだなとは、
思ってはいたんだけど、
個人的にまだやっぱり、
人間みたいに考えたりとか、
これまでの経験から来る直感的なアイディアだとかっていうのは、
ないものだと思ってしまっているがゆえに、
頼めないっていうのがあるかなっていう。
そうですね。
これも最後の直感を養うところにかかってくるけど、
いろいろと使っていくうちに、
こいつここできるんかっていうふうに、
分かってくる部分とかもあるでしょうから、
そこで任せていく範囲とかも、
ちょっとずつ調整していくっていうことも
していくんだろうなと思いますが。
そうだね。
多分タスクによっても、
さっきの僕が言ったように、
調査計画を立てる部分で、
もっと任せられる部分が多くなったりとか、
実装計画を任せ、
実装計画を作る場面で、
もっと任せられることがあるとは思うんだけど、
でも今確実にこの内容を聞いて、
できるなって思ったのは、
その探索、調査の部分と、
コードを書くっていう部分かなと思いますね。
今、うちのチームでも、
僕が勝手にやってるんですけど、
今年は僕にとってのAI元年にしようと思っているんで、
いろいろとさっき話した、
Cloud.mdとか、
Skillsとか、
その辺に手を出し始めていて、
僕は主にAPIの実装することが多いんで、
今まさに使ってるんですけど、
なかなか細かい部分がうまくいかないっていうことがあったりして、
よく言う、ちょっと細かいところ忘れたけど、
最初の8割を実装する時間と、
残りの2割を実装する時間が同じくらいかかるみたいな話ってあるじゃないですか。
それをむちゃくちゃ実感するというか、
調整するのに、
この辺はこう出してくれるのかと思って見ていくと、
それっぽい実装になってるんだけど、
よく見るとここちょっと違うぞみたいなところがあって、
また.mdのファイルをいじりにいって、
ということを繰り返すと、
最後の調整がむちゃくちゃ時間かかってて、
これがそもそもやり方として正しいのか、
最初はそういうものなのか分からずやってるっていうところがあるから、
なかなか苦しみながらやってますね。
なるほど。
実験的な取り組み、
さっきの直感養うじゃないけど、
クロードコードとどう付き合っていくかっていう部分、
割と実験的に進めていく必要があるような気がするから、
実務って部分だとどうなんだろうって思ったりしている。
そうですね。なかなか難しいところはありますが、
とりあえず最初整えてしまえば、
以降楽になるだろうと信じて、
今その辺取り組んでます。
月々だよね、やり方。
割と多分僕がやるんだったら、
このドキュメントとか読み込むし、
他の関連資料も読み込んだ上で、
ある程度もう把握した上で、
境界線を決めて業務に落とし込みそうだなって感じた。
僕もさっき宮原さんが言ったように、
そんなにがっつりAIがどこまでやれるかみたいなところを
理解してなかったり、
信用しきれてないっていうところがあるから、
結局まだまだレビューコストみたいなのが高くて、
そこがなかなか難しいなとは思っているので、
何度も調整していくうちに、
百発百中になることはあるのかわからないですが、
それに近しいぐらいの確率になってくれば、
もうちょっと楽になるんだろうなとは思うんですけど、
まだちょっと大変だなっていうのが、
今の僕のAI力的には感じてるっていうところですね。
なるほど。
調査はすごい上手そう。
確かにスコープをちゃんと決めて、
結果をあるがままの事実を伝えるっていうことは、
すごく上手そうなんだけど、
やっぱ想像性がいる部分は多少難しいなって思うのと、
悲しいけど、確かにコード書くのも指示通りだったら
うまくできると思うんだけど、
自分としてコード書くの好きだから、
書きながら気づくこともいっぱいあるし、
そこで想像的なアイディアが生まれる場面も結構あるから、
あとフローに入れるというか、
没頭できる没入感みたいなのもあって、
好きだから、
それを全部AIにモデルに汎用モデルに持っていかれるっていうのは、
ちょっと悲しいなっていう気持ちがあるっていう。
確かに今のお話聞いて思ったんですけど、
その実装中に気づくエッジケースとかってあるじゃないですか。
ある。
そういうのを拾えなくなってる感覚は確かにあるかもしれないですね。
そうなんだよね。
だからあれって書きながらあれって思う瞬間が絶対にあって、
あとリファクタリングしてて、
あれって思う部分があったり、
ここにこの関数を置くのってちょっと責務的に微妙かもなとか、
感じる場面が結構あるから、
割とあの瞬間は個人的には大切にしているというか。
そうですね。
結局クロードコードが持ってきたやつをレビューするって、
レビューって大事なフェーズというか取り組み、
活動だと思うんだけど、レビューしてる、
いやもしかしたらいるのかもしれないけど、
何かを指摘するって楽しいことではないなって個人的には思っていて、
なんか自分で生み出してるわけでもないから、
確かに教育的なアプローチとして、
誰かそのレビューを受ける人の教育的な価値としては高いと思うんだけど、
それもなんかAIじゃなくて人を育てたよねって思っちゃう。
レビューそこまで好きじゃないっていうのもあるけど、
やっぱ自分で書いたり、自分でリファクターしてる方がすごい楽しいなって思ったりする。
ディストのフェーズでも、
YapCのキーノートをピーヤマさんという方がしていて、
その中で話していた内容にめちゃくちゃ共感する、
そうそうって思った話があって、
実装をどういうふうに実装しようかなみたいな感じで、
考えてる瞬間っていうのは楽しいんですよ、僕も。
ただそのディストを浮かんでそれを実際にコードに落とし込む作業って、
僕は社境の感覚なんですよ。
だからそこのフェーズは別に楽しくないんです。
だからそこを変わってくれるんであれば非常にありがたいなっていうのは思います。
そうでもないですか?
個人的には、僕かなり設計するタイプ、細かくかなり詳細までいくタイプで、
それをそれ通りに作るっていうフェーズも結構楽しんでる。
で、リファクターが好きだから、
何だろう、ザーって作った後に綺麗にしていく作業っていうのがすごい好きで、
書くのをかなり好きなタイプなんだよね。
まあ派閥ある気がするけど。
だからそういう意味だと、最初に出始めたコパイロットはめっちゃタブで保管できるようになったぐらいの、
あれのちょっと上位互換ぐらいがちょうどよかった。
僕はそうかも。
僕もそれぐらいなら全然、
全然違った感じで実装されるとリファクターが大変だなっていう懸念ぐらいで、
一旦の叩きの汚いコードを叩きで作ってくるっていうのは別にいいかなとは思ったりする。
それからリファクターを自分でやればいいみたいな。
その度合いにもよるから、そこにもやっぱり結構な計画が必要なんだろうなって思う。
でもテストコードはすごく上手に作ってくれそうだから、そこは期待してるかもしれない。
確かにそのテストケース出しとかを手伝ってもらうことは確かにありますね。
そうそう、網羅性は高そうだもんね。
出てるケースを見てHケースとかいないかとか言ったら、これもあるかっていうのを出してくれたりするんで、それはすごくありがたいです。
テストは結構しんどいっていうか、繰り返しになる部分もあったりして、
最初の数パターン作ったら想像的なところないし、パターン増やすだけになっちゃうけど、
ユニットテストって網羅テスト上手だからやらせとくべきだよねって品質のことを考えると思うとやるけど、
あの作業本当に無駄だなっていつも思う。
無駄ではない。
無駄ではないんだよ、無駄ではないんだけど時間的になんかもったいないなーみたいなのは思ったり。
面白くねーしって思いながら。
まとめと今後の展望
なんだかんだ50分ぐらい話してるんで、そろそろ終わろうかな。
はい。
ということで、ベストプラクティスシーズフォークロードコードを読んだという回でした。
ありがとうございました。
ありがとうございました。
