Claude Designの活用と阿部氏の評価
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う、
企業家の山本とエンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあよろしくお願いします。
はい、よろしくお願いします。
はい、じゃあちょっと最近、僕がずっとクロードデザインを押しまくってたと思うんですけれども、
2回ぐらい話したのかな。
そうだね。
実際ちょっと阿部ちゃんも使ってくれて、使ってくれてって誰目線やねんって感じやねん。
何の人、あなたみたいな感じやけど。
アンサーキックの社員ですか。
社員ですかみたいな感じやけど、阿部ちゃんも使ってくれて、ちょっと阿部ちゃん的に、
どんな感じだったかみたいなところをシェアをしていただけたらいいなというふうに思ってます。
で、僕もね、ちょっと前回こういうフローで開発したらいいんじゃないかみたいなことを言ってたと思うんですけれども、
その後、別の先にクロードデザインでデザインを作ってから要件定義をしていくみたいなとか、
ちょっと別フローもいろいろ試してみたので、その辺の共有もその後できたらなと思っておりますので、よろしくお願いします。
はい、お願いします。
はい、じゃあちょっと阿部ちゃん早速、クロードデザインの説明は前回前々回とか聞いてもらえたらいいかなと思っておりますので、
ちょっとざっくりと説明だけすると、もう本当にクロードとか勝手にデザインしてくれて、
で、それをクロードコードとかにハンドオフできるというようなのが結構魅力的だよっていうところと、
あとただデザインしてくれるだけじゃなくて、どっちかというと本当にデザイン管理システムみたいなのを作ってくれるので、
YouTubeとかでも、YouTubeの例えばワクセンを作ってタイトルを動的に変更しないみたいなのも、
原理的にはプログラムを書いてるみたいなのと一緒だから、そこの設定をするフォームを作ってというのも、
クロードデザイン側出てきちゃうというような感じで、かなり使う幅が広いなというようなもので、
それで僕がテンション上がってたみたいなのがあるんですけれども、それがシステム開発でも結構使えますよねみたいな話で、
僕も実際システム開発分野で使ってみて、かなり威力があったっていうところだったんですけれども、
前回までまだ阿部ちゃんは触ってなかったっていうところがあったんで、そこからどうだったかみたいなところの話を聞けたらと思います。
どうでしたか、実際使ってみて。
革命的ですね、これは。最高でしたよ。
デザインをまず、既にあるようなシステムのデザインをアップロードして、割かし綺麗にデザインを組んでくれるっていうところももちろんそうなんですけど、
そこに対して新しいデザインを導入したいときに、やっぱりいろいろなパターンを考えた上で最終的なデザインを決めたいなって思うんですけど、
それをAIと今まではフロントエンドで実際に作ってもらったりして、どうしよっかな、微妙だなって変えてもらったりっていう問答を繰り返すことが多かったと思うんですけど、
結構すごいなって思ったら、まずデザインしたいですって依頼をすると、結構細かくヒアリングされるんですよね。
しかもヒアリングがクロードデザインのキャンバスっていうんですかね、デザインがレンダリングされるところに質問フォームみたいなのが出現してきて、
出てくるね、出てくるね。
そうそう、5個とか6個ぐらい、何なら自由の、5個か6個ぐらいの質問が出てきて、選択肢でこういうのがいいとかっていうのを選択できたりとか、追加情報とか、あとは最後に追加でメッセージがあればどうぞみたいな感じで送れるんですけど、
そこでかなり、自分が最初に投げた依頼のプロンプトに対してさらに精度高く情報を収集してくれるっていう仕組みがあったり、そこで複数のパターンを見比べたいですっていうふうに依頼をすると、自動でTweaksっていうんですかね、微調整っていうらしいんですけど、
そういう微調整用のパネルみたいなのが登場して、出来上がったフロントエンドに対してパターンを何個か切り替えて試せるような、そういう仕組み自体が最初から提供されてるので、
いろんなデザインパターンを深く検討しながら、希望するデザインに落とし込んでいけるっていうのが、結構他のデザインツールにはなかったんで、結構すごいなところが。
大平 結構Tweaks、クロードデザイン自体が無視してることもある、メインはね。
しばやん わかるわかる。
大平 フロントのプログラム側でやっちゃったみたいなときもあるし、ちゃんとTweaks上でやってくれるときもあるし、どっちでもいいっちゃいいい。正直比較できたらいいので、どっちでもいいかなと思いながら。
しばやん それくらい自由度がクロードデザイン側にもあるっていうところは面白い。
大平 あとやっぱ複数提案あるの結構いいよね。
しばやん 本当にそれがありがたい。僕は特にデザインとかを言語化して伝えることって結構苦手だし、何がいいかってそもそも分かってないことがあるので、
叩き台として複数提案してもらった中で、こっちの方がいいなって気づきとか、こういうパターンがあるならこっちの方がもっと良くなるかもみたいな感覚も含めてフィードバックを返すこともできるようになるので、
やっぱり複数パターンあるっていうのはかなり、最初にもうAIが1個だけ作ってそれに対して吟味するっていう、それが本当にいいものかどうかっていう、暗中模索しながらやるよりも幅広い選択肢がある中で選べる。これすごくいいですよね。
うん。いや、分かる分かる。あと地味にいいのは選択肢、こういう風にしたいみたいな選択肢の中にディサイドフォーミっていうのがあって、ちょっともうよく分かんねーわみたいなときはそれとりあえず押しておくみたいな。
そういうのがあるんだ。
そうそうそう。明確にこういう方向こういう方向こういう方向みたいなのがあるのと、あともうクロードに任せるみたいなディサイドフォーミみたいなのがあって。悩んでもまあそれとりあえず押しとくみたいなのがあるから。結構いいよね。
あとなんか、俺割とね、あとそれで言うとクロードデザインのすごいなって思ったのが、デザインを例えば3パターン4パターンみたいなのを出してもらうじゃん。で、その中で一番保守的なやつデザインと保守的プラスこういうパーツを追加したパターンみたいなのと、
あとかなり抜本的な改善をして、よりビジュアルを良くするようなみたいな3つのパターンを提案してくれて、今までのLLMで普通にお願いしたパターンで、この一番尖ったデザインの変換をするみたいなのって、
大体ぶっ飛んでるしかつAIっぽいなみたいなデザインが出てくることが多かったと思うんやけど、俺結構それ選ぶこと多くて最終的に。割とちゃんとしてる。今までのデザイン画面に引きずられずに、
フラットに考えて、デザイナーとしてこうしたら一番良いんじゃないみたいな提案がちゃんと来るみたいな感じがあって。
なるほどね。
Claude Designの機能と複数提案の利点
そうそうそうそう。だからぶっ飛んだ提案みたいなの言ってるんだけど、別にそれはぶっ飛んだ提案ではなくて、ちゃんとデザイン的に破壊的に変更してはいるんだけど、かなり良い提案をしてくれるなっていうのが。
今までだったらAIに提案されて一番今までと全然違うアイディアでみたいなので、基本的にはもうお遊びみたいなもんやったんやか。
そうだね。だからもうAIのデザインみたいなね。
そうそうそうそう。それがね意外と使えるというか、確かにこういう見せ方あったらみたいなんで選んじゃうみたいなデザインをちゃんと提案してくれるっていうのがなかなか。
それいいね。
やっぱりなんかアンソロピック側、クロード側で結構デザインに関する知見っていうのが溜まってて、スキルとかで結構矯正するようになってるのかね。
まあおそらくそうなんじゃないかな。
っていうか多分、多分なんやけど、そういうふうに型化しやすい知識だった。体系化、すでに世の中的に体系化されてる知識であったとかそういうのもあるんじゃない。デザインとか。
なんかまあシステムは特にそうかもしんないけど。
なるほどね。
僕は確かに、この間、いくつかあの後使ってみた中の一つに、そういう保守的な今のベースにっていうのと、生命のもの、結構ドラスティックに変えます。
あとは中間っていうのがあって。
僕は生命のやつは最終的に選ばなかったんですけど、思い返してみれば、確かにそんなにAI臭さがなく、でも新しいコンポーネントを提案してくれたり、こういう見せ方どうですかっていうのは確かにしてたんで。
結構、自然かつ、最終的にはその時はたまたま採用しなかったんですけど、いいデザインを出してくれたなっていうのは感じますよね。
あとあれかな、例えばこの1、2、3、A、B、C案が出てきて、C案のこことB案のこことA案のここ多いから統合してみたいな。
いいよね、それができるよね。
それができるのがかなり良くて、しかも統合してって言っても方向性が違うから、ただ統合してもガチャガチャしたデザインになるっていうところをうまく吸収して、ちゃんとした見た目として整合性のあるような形で統合してくれるみたいなのも結構いいねっていう。
確かにそうだね。
あとあれだね、カーソル、カーサーとか、これまでもなんかIDEベースでブラウザで表示、IDE内でブラウザを表示して、それをクリックすることでコンテキストを与えてここを修正してくださいみたいな依頼を上げれるような体験っていうのは普通あったりしたと思うんだけど、
クラウドデザインにも当然その機能はあって、やっぱりデザインをちゃんと作ってくれるっていうところと、そこのコンテキストを適切に与えられるっていうところがやっぱりうまくマッチしているというか、あれがあることでちょっとした指摘もすごいしやすくなるし、
それで出てくるアウトプットのデザインも、今までのIDEで別のAIツールとか使って書いてるよりもはるかにいいアウトプットを出してくれるから、全てが三位一体となってデザインツールとして秀逸な作りになってるなみたいなのはちゃんと感じましたね。
カーサーだとN並列で一気にいろんな案を提案してくれるみたいなのが昔からあるじゃん、並列でエージェント同じプロンプトンに対してみたいな、あれのようなことを一体でやってくれるみたいな。
たぶんカーサーでみんながやってたのも、もちろん仕様レベルで、ロジックレベルでみたいなこともあったと思うけど、おそらくいろんなデザイン見てみたいとか、そっちのほうが用語としてケースとしては多かったんじゃないかなと思うと、カーサーだとちゃんと実装してもらったやつを6個みたいなので、
意外とコンテキスト、全体的に消費するトークンも抑えつつ、カーサーのN並列みたいなのの利便性を獲得できてるみたいな。あれを4個提案しても勿体ないなって気分にならないというか、個人的に。
そうだね。
みたいな。
そうだね。
そうそうそうそう。っていう感じもあるのが良かった。なんか阿部ちゃんがね、なんか結構いい使い方あったよってシェアしてくれたから、なんかその辺の話も聞きたいなと思って。
既存デザイン再現の課題とSingleFileの活用
あーそうだね。
クロードデザインを使ってる中で、すごくいいなと思いつつも若干うまくデザイン、元あるシステムのデザインを再現してそれを改善してほしいなっていうときに、どうしても完璧に既存のデザインをまず土台として作ってくれないっていうのがあって。
やっぱり若干の食い違いというか、こういうデザインないのに出てきたなみたいなことがあって。
クロードデザイン自体、なんかローカルのファイル、要するにプロジェクトのコードのすべてを読み込ませて、それをベースにデザインをまず作るっていう仕組み自体はあるんですよ。
これも結構すごいなと思って、ローカルの数百もあるファイルを全部読んでデザイン組んでくれる。結構すごいことだと思うんですけども、それでも完璧じゃないっていうところがあって、これの理由っていうのが僕は、あくまで僕の予想なんですけど、結局フロントエンドの開発をしてると、
HTMLだったり、それはリアクトで書いてたりとかっていうのがあるんですけども、そのHTMLをレンダリングするためのDOMの構造を定義するファイルと、実際にそれに対してスタイルを与えるCSSのファイルっていうのは別々に基本的に分離されているっていうのがある。
実際に画面上に表示されるものって、データ込みでようやく何が描画されるかっていうのが決定されるっていうので、プログラム自体はどういう画面表示をするかっていう定義と、それがどういうスタイルになるのかっていう定義と、そこに入ってくるデータって三つの要素が組み合わさって、ようやく初めて僕たちがウェブを見ているような画面になるんですけど、
やっぱりそれって全部コンテキストが分離しているので、どうしても完璧に再現するのは難しいんだろうなっていう感じでいて。
確かに、データは把握できないもんね。
そう、データは特に本番とかにあったりすると、実際のデータは見れないとかっていうのがあるので、特に再現性に乏しいっていうところがどうしても課題としてあるかなと思ったんですけど、
そこで考えたのが、実際に自分が今見ているウェブサイトのページをスナップショット的にデータとしてダウンロードして、それを渡せばいい参考データになるんじゃないかなっていうのを考えましたと。
ただ、ブラウザって今見ているところ、例えば特にパソコンのブラウザとかだと、コマンドCとか保存っていうボタンを押すと、そのままウェブページをダウンロードすることができるんですよ。
描画しているページのHTMLファイルと、それに紐づくCSSとか画像とか、あとはJavaScriptのファイルを一括でダウンロードして保存することができるんですよ。
最初それを渡そうとしたんですけど、単純にそれをやってしまうと、結構データ量が多くなるんですよ。
それは、まずはページを表示するために必要な全データが投入されるので、すごいデータ量が多くなるんですけど、実際に表示するのに使っているパーツって、本当にごくわずかだったりするんです。
だからダウンロードすると10メガとかっていうファイルになるんですけど、実際必要なのって数千キロバイトぐらいでしかないっていうことがあって、
じゃあこれをクロードデザインに渡すのはきついなと思ったときに、Chrome拡張機能で、シングルファイルっていう拡張機能があって、
これがちょうど今見ている画面のデータに必要なものだけを引っこ抜いて変換して、それだけを保存できるっていうようなChrome拡張機能。
1つのHTMLファイルに全部を押し込めるんで、クロードデザインにはそのファイル1個アップロードすれば画面を完璧に再現できるよねみたいな発想として、
試しにシングルファイルっていうChrome拡張機能を入れて使ってみたんですけど、これだったら結構複雑なダッシュボードのデザインだったんですけど、
割と体感80%ぐらい若干色が違うなみたいなのがあったりしたんですけど、あとフォントが違うなとかっていうのはあったんですけど、
ほぼほぼ再現されて、十分それを叩き台にして改善できるぐらいのデザインに一発で起こしてくれたんで、こういう部分は結構ありなんじゃないかなっていうふうに気づきを得ましたね。
おだしょー なるほどね、なるほどね。
ちょっとこれ1個注意があって、シングルファイルを使ってもダウンロードすると意外と10メガぐらいとかになることがあったんですよ。
一応その見ているスナップショット、画面のスナップショットとして保存してくれるのは確かなんですけど、
ここにフォントのデータが入ってくるとかなりデータ量が増えるみたいで、それはフォントデータとして文字列で埋め込まれるんですよね、サイトとか。
ダウンロードしたHTMLの中にフォントデータ、アイコンとかちょっといろんなゴシックタイとかメイリオっていろんなフォントがあると思うんですけど、
そういうフォント情報が全部埋め込まれて、かなりの容量になってしまうので、僕はこのダウンロードしたファイルに対してフォントデータだけ削減するスクリプト、
数行で作れるんで、それを作って変換して削減したものをアップロードするみたいな形でやってました。
そうするとアイコンデータが消えたりとかしちゃうんですけど、それで十分使えるかなと。
Kimi Web Bridgeとの連携と将来展望
それあれやね、スキルにして、このChrome拡張の機能っぽいのをスクリプトとして持っておいて、スキルとして定義して、最近とかだとあれとかが出てきて、
Kimi Web Bridgeっていうのが出てきて、それはKimiが提供しているWeb Bridgeなんで、Chromeの自分のプロファイルのブラウザをローカルのクロードコードとかがスキルで勝手に立ち上げてくれるみたいなやつなんだけど。
これと組み合わせたら、例えば自社サイトのやつをこういうふうに置き換えたいみたいなとかがあったときに、自社サイトの全ページのサイトマップを渡して、
それを全部バーって立ち上げてはこのシングルファイルみたいなのを実行して、HTMLでどんどん落としていって、それをした後に自分のこのクロードデザインのやつをバーって複数タブで開いて、
それぞれ1画面ずつこれ画面をやってくれみたいな感じで、全部再現してくれって言ってやったら、自分の持っているサイトのデザイン全部クロードデザイン側に落として、その上でしかも複数案提案してもらうみたいなのを並列でやっていくみたいなのができそうやな。
なるほどね。AIにそこのソフトは全部やらせるってことね。
そうそう。
いや、できそうだな。
そう、できそうだな。それできるとデザインをアップデートしたいなみたいな案件とか、そういうのが非常にやりやすくなりそうだなっていう。
いいね、確かに。自分が普段使っているブラウザのプロファイルで開くみたいな技術は結構最近ブラウザユーズとか、プレイライトも最近サポートしていて。
サポートし始めたんだ。
そうそう。そういうのが流れとして起きているので、結構やりやすくはなっている。君ブラウザブリッジだっけ?ウェブブリッジだっけ?
ウェブブリッジ。
それ以外の方法でもっても、MCPとか活用してそういうのができると思うので、ちょっとやってみたいかもね。僕たちが今運営しているサイトとかも結構フロントエンド改善したいなって思うことあるし。
それできると結構すごいなって思って。
かなり使えること多そうだよね。うちの今作っているシステムの、ちょっと文脈はずれるけど、うちが今作っているシステムのユーザーマニュアルって全部AIがやってるじゃん。
基本的にプルリクルの多分見てAIが書いてみたいな。もう人の手は開催しないようになってて、そこをスクショとかつけたいなとかって思ったりするわけですよね。
けどそのスクショを取るためにそのデータを用意するっていうのは結構大きいから、例えばほぼ完全再現がクロードデザインでできるんだったら、クロードデザインベースで作られたやつを取ってきての方がデータ再現という意味では、
データを再現する必要もなく普通にそこの文字を埋め込んだらいいだけみたいな感じにできるから、コンテキスト効率も低く割と再現性を持って、クロードデザインをどうデザインのマスターとしていくかみたいなところが課題だなって思ってたんやけど、
完全再現できるのであればっていう過程だと思ってたけど、割とそういうこともできそうだなっていうふうに思った。もう1バージョンぐらいクロードがレベル上がってくれるとできそうだね。
そのうちクロードが自分で探索とかする機能とかできてきそうだよね。この君Webブリッジみたいな機能を内蔵して自分でやりますみたいなのが出てきたりとかもしそうだよね。
クロードもインクロームっていうクローム拡張機能を出してるからそれとの組み合わせでやれそうやもんね。そのためのパーツはクロードはすでに持ってるなって思うよね。
ちょまど そうだね。もうちょっと話変わるけど、やっぱなんかすごいなって思ったのがクロードデザインのファイルシステムがちゃんと整っているっていうのも結構すごいなって思って。
僕が使っててアップロードしたファイルとかはちゃんとアップロードっていうフォルダ切ってその中に全部補完するようになってて、スレッドを新しいのに切り替えたとしてもアップロードされたファイルとかを見てスレッドとしては分断されてるんだけどコンテキストは維持されてるみたいなそういうのもちゃんと作られているので、
あとはその中には実際に成果物として存在しているJavaScriptというかリアクトのプロジェクトとか実際にレンダリングするHTMLのファイルとかがあるので、そこ見てこういうデザインがあるからこれ真似してこっちにも適用するみたいなことをやってたので、結構そういう仕組みが用意されているっていうのはすごいなと思って。
さっき話していたクロードインクロームとかで例えばスクリーンショットを撮ってもらったのをそのファイルシステムのアップロードとかに配置してもらうとかっていうのがもしできるようになれば、完全にクロードデザインとの統合も果たしそうだなっていうところがあるし。
そうなんだよ。だから本当にデザイン、俺ほらやってたデザインシステム作ってっていうだけでさ、なんか全部のコンポーネントとか用意してくれてみたいな一覧化してくれるみたいなのとか、あれもすごいよね一発ドンでやってくれるみたいな。
本当にすごい。
本当に結構クロードデザイン、使い勝手もいいし、使う幅がでかいよね。使える幅が大きい。ユーザー側の工夫によっていくらでも拡張できるっていう、それはやっぱりAIサービスの醍醐味だなって。
AI駆動開発における実体生成と記号設置問題
そうだね。
なんか思うよね。あとあれか、俺の使ってるフロー、開発フローについてのシェアとしては、以前話したときに一回まずオープンコードでバーって作ってもらって、要件定義して作ってもらった後にそれをスクショ取って、これ改善してみたいな感じのことを言ったみたいな話をしてたと思うんやけど、
その流れじゃないときついっていうことが分かりました。
生物として出来上がってるものじゃないと厳しいんだなっていうのが分かったっていうのがあって、それはなぜかというと、
俺が今回試したフローは2パターンなんだけど、要件定義して、要件定義書がある状態と実装計画書がある状態で、こういう計画書考えてるからデザイン起こしておいてみたいな。
そのデザインを起こしたものを実行計画の中にまた盛り込んでするみたいな感じと、あとは要件定義書を作る前にこういう要望があるからデザイン起こしといて、
その要件定義、そこのデザインをまず定義されたやつを見て要件定義してくれみたいな話をして、特にエンジニアじゃない人からするとデザインで決まってるやつからやっていくほうが楽じゃん。
システムセキュラー制約を考えずにデザインを決めて、この画面っぽいやつを要件定義にしてっていうほうが依頼もしやすいし、その画面がそもそも要件定義だからみたいな感じになるっていう感じがあるから、
多分非エンジニア的にはそっちの流れのほうがシステム知見が不要なので楽なんですけど、けどそのお願いの仕方をしちゃうと、そもそもない機能とかがデザインの中に入ったりしちゃう。
最終的にデザインとの乖離が生まれる出来上がったシステムみたいなのがあって、それをまた直してもらうのも結構大変みたいな感じになってて、それが要件定義書があって、この要件定義書でやるんだよって言ってもやっぱちょっと入っちゃうみたいで。
だけど最終的にオープンコードとかで開発し終えた、開発した成果物のスクショと、あと実際のコードベースを渡すと、余分な起こり得ないデータ表示みたいなのが抑制されるから、
だからやっぱあの流れじゃないとちょっとワークしづらいなっていうのを感じたっていうところがあって、なので一回バーって作らせるみたいなんで、表示する項目とかは固定化してしまうみたいな。
でそれをなんかさらに多分阿部ちゃんが言ったみたいなシングルショットやったっけ、シングルショットの拡張機能とかで、より高精度に今の状態を渡せたりした方がいいんだろうなみたいなのを感じていて。
はいはい。
そうそうそう。
結局あれですよね、格闘というか具体のものがないと保管という、結局なんか保管を押し出したりして、間違ったところに行ってしまうみたいなのがありがちって感じ。
起こる、そう。だからやっぱ実態があってそれをどう改善するかの方が、AIクロ開発してると思うけどやっぱ強いじゃんAIって。
余計なことしないし、みたいなのがあったと思う。だからなんか実態が動くものができてそれをどうするかみたいな話をした方が頭いいよねみたいな話って阿部ちゃんと何回かしたことあると思うんだけど。
はいはいはい。
なんかまさにそれだなっていう風に。
なるほどな。いや僕ね、それで言うとね、ちょっと最近面白い気づきを得たことがあって。
うん。
なんか確かYahooのホースだったかな、なんかで記号設置問題っていうのがあるっていうのを知ったんですよ。
それはなんかどっちかっていうとLLMとか全く関係なくて、なんか小学生が学習するときに、
大人が意味を伝えてこれはこういうものだよっていう風に教えたとしても、
それが具体の話と紐づかないから、その意味だけ伝えてもどうしても理解ができない、正しい答えを出すのができないっていうのがあるらしくて、
なんかそういうのを記号設置問題みたいなの言うらしいんですけど。
はいはいはい。
なんかLLMってまさにそれだなみたいな。LLM自体はすごく推論は得意だけど、意味自体はちゃんと理解していない。
僕たちがデザインの意味とか何をしたいかっていうのを伝えたとしても、それの中身についてはなんかあくまで推論するしかなくて、
なんか今実態として何が起きてるかとかの結びつけとかは全く考えることができないから、
具体例を渡して、実際にこうなってるっていうものをもう実物として渡さないと、どうやっても正しい回答、
正しいというかミスリードの結果を生んでしまうみたいな、いう風なことを言っていたので、
なんかすごくこれが似てるなと思って。
確かに確かに。そうかもしれないね。
こういう言葉があるらしくて、まさにそれじゃんみたいなのを思ったりしてました。
なるほどね、確かに。記号設置問題、確かにそれだわ、それだね。
多分その関係性とか、今顕在化しているものもあるんだけどもちろん実態として。
けど、その実態がこうなるところに関係してるみたいなのでは、なかなか関係性を見出せないのか。
今の限界というか、根的その限界みたいなところなのかなと思うと、やっぱそういうことなんだろうね、結局。
なので実態をまず作るっていうことはいかに大事かっていう。
ハンドオフ前のリファクタリングとコンテキスト効率
だからそうすると、やっぱ要件定義をAIと問答でやってからやるっていうのが、今のViveコーディングの最適解なのかなっていう。
そうだね、そして実態を作ってデザインとかをブラッシュアップしたいんだったら、
まず作ってものができた状態で、そこに対してどう改善を生むかっていうのを考えてもらう。
やっぱそこが大事なんだろうなみたいなのを感じましたね。
クロードデザイン使ってて何のコンテキストも渡さないで、こういうシステムなのでこういうデザイン欲しいですって言ってもやっぱりちょっと違う感じになってしまう。
さっき言っていたようにシングルファイルみたいなものを渡すとかなり効くっていうのは、そういう実態があるからこそなのかなみたいなのを感じますね。
うんうんうん。
まあそんな感じかな、クロードデザイン。
でもあとあれです。僕最後一つだけ話したいことあります。
ハンドオフができるって話あったじゃないですか。クロードデザインでデザインした後に、それをクロードコードに引き継ぐっていう時に、
ちょっと注意というか、これやるとより良くコンテキストを渡せるなっていうのがあったんで、ちょっと一個だけシェアしておきたい。
何かっていうと、デザイン終わって、最初は今日の初めの方に話していた微調整が複数パターン。
複数パターンを提案してくれて、それで選択したりとか微調整ができるみたいな話をしたんですけど、
ハンドオフをクロードコードに出力するためのハンドオフを取得する段階で、
特に気にしてないと、コードの中にハンドオフとしてダウンロードされるファイルって、
結局クロードデザインのファイルシステムがそのままダウンロードされるだけではあるので、
そのファイルの中に選択肢のゴミデータとかが溜まってる時があるみたいなんですよ。
デザインが終わって、ある程度複数あったやつから一つに絞ったりして、
これが決まった時に、もうクロードデザインにもうこの一つに決まったんで、
他のゴミデータがなくなるようにリファクタリングをお願いしますっていうのを一言言うだけで、
ファイルサイドが結構グッと落ちたりして、また後は正しいコンテキストになるっていうのがあるかなと思うので、
結構ここは最後ハンドオフの手前で一回リファクタリングをお願いするっていうのは大事かなっていう風に思います。
それは確かにそうだね。俺もクリーンアップしてみたいな感じの実際言ってて、
全コード読みに行くから、コンテキスト効率とか何も考えてないサービスなんだよ、あれ。
会話データも全部載ってるから、会話データ読んで読み解いてくれるみたいなのもいいところであるんだけど、
できるだけクロードデザインのプロジェクトの中のデータはシャープに保つっていう意識をユーザー側が持ってないと、
コンテキストの問題にすぐぶち当たるっていう。
あれは多分クロードが自分のサービスで100万トークコンテキスト使えるかなっていう結果、
コンテキスト効率なんか全然考えてない。
ゼロコンテキストでの情報伝達と効率化
しかもこれがやっぱり難しいところだよね。LLMのプロバイダーって使ってもらえば使ってもらうほど結構儲かる仕組みになってて、
だからコンテキスト効率を考えるインセンティブってそんなになくて。
確かにそうだね。
むしろコンテキスト効率悪くできた方が儲かるっていう仕組みになっちゃって。
だからそこがちょっと構造的にそういう考えに、むしろコンテキスト効率を考えるよりもコンテキストいっぱい与えて、
よりユーザーのことが理解してくれたような振る舞いをAIがした方がユーザー体験としても上がるから、
なかなかコンテキスト効率を考えるっていうところに行きにくいっていう構造上の問題がLLMのプロバイダーにはあって、
なのでそれが如実に出たサービスだなっていうのはすごい。
いや、そうだね、確かに。
そうそうそうそう。
なんかその辺が今後多分LLMプロバイダーじゃないサービサーが目指すところの一つの答えの一部でもあるんだろうなっていう。
やっぱりLLMプロバイダーが構造上考えたくない、考えづらいところをどう洗練させていくかっていうのはサービスの差別化になるはずなんで。
なので僕が最近、山ちゃんが言ってるようなハンドオフしたコンテキストとかを計画、クロード構造に形させて実装してもらうっていうところとかも前提にしつつ、
僕が最近クロードデザインで完成した後にやってるフローってすると、今話したようにリファクタリングをしてもらうっていうところがまず一つと、今回決まった仕様について整理して言語化してくださいっていうので、
まずどういうものをどういう修正したとか、どういうデザインになってるかっていうところ、クロードデザイン上でテキストに吐き出してもらってからハンドオフするようにしてます。
ハンドオフをボタンクリックすると、このURLを見てくださいみたいなプロンプトが画面に表示されて、そのURLをクリックするとそのままZIPファイルをダウンロードできるんで、
そこをクリックして開くと、そのプロジェクトのファイルとこれまでのプロンプトのチャットの履歴が全部突っ込まれてて、これが非常に無駄なコンテキストが含まれてるので、本当に必要なプロジェクトのコードファイルを抜き取って、
最後にチャットの中でも、僕が最後に依頼した仕様の出力だけをコピーして、それだけをAIに渡すようにすると、一番テキスト効率よく情報を渡せるのかなっていうので、これを前提として考えたっていうのを最近はやってますね。
その時に俺のちょっとしたオススメが、これの変更を言語化してみたいな時に、補足として他の開発者にこれを持って開発してもらうんで、その開発者向けにっていう言葉を使うと、このファイルの中のどこを見ればいいっていうところまで教えてくれるんよね、その言語化の中に。
なので、それは結構いいかもなって思ってる。
確かに、良さそう。
目的語というか、対象、渡す対象を伝えることで、そういう振る舞いをしてくれたから、結構いいなっていう。
確かに。
それで言うと、僕最近やってるのはあれですね。そういう話も確かに必要だなと思うし、ゼロコンテキストで読んでも一発で全て理解できるように説明してくださいみたいな文章を入れると、結構効率よくて、僕とAIが会話してる中で溜まってる不要なコンテキストも最後のアウトプットに出したりするんですよ。
こういう候補があってこういう変更したみたいな。でもそれって実装者からすると過程はいらなかったりする場合もあって。
確かに。それでいいね、確かに。ゼロコンテキストって言葉、俺結構これはクロードデザインじゃなくて、オープンコードでまずいったんディープシークとバーってやりとりして、方針というか決めるんよね。
その方針はある程度決まったものをプロメテウスとか計画で立ててもらうみたいなフローをするんだけど、その時にこれを計画を他の開発者に依頼するんでみたいな感じでお願いするんだけど、その時に今回の経緯も含めて詳細に言語化してくださいみたいな言い方をするんだけど、
ゼロコンテキストでもできるようにっていうので、かなり省略できそうだなって。そのいちいち俺がつらつらなかなかと前提とか含めて書いてみたいなとかって言ったやつを。ゼロコンテキストでいいね。ゼロコンテキストでもこの計画をできる。今まで知らないこと。
今まで全く知らなかった人でも計画を立てられるぐらいの情報量っていうことだと思うから、なんかそれで相当コンテキスト絞れるなって。
そうだね。意外とこれで調子良くなったので、最近は活用してる感じですね。
あと、あなたと私の間での会話都合の内容を省くとか、この更新履歴を思わせるような表現、メタ的な表現を避けてくださいとかっていうのを、ゼロコンテキストの話とともに3分ぐらい書くこともちょっとありますね。
そんな感じで最近は書いてる感じかな。
まとめと今後の展望
てな感じです。
はい。
じゃあ、そんな感じですかね。
はい。こんな感じで。
じゃあちょっと引き続き、グローデザインとか他のAIサービスもそうやけど、ちょっと君WebBleacher使ってみたいね。
そうだね。いろいろちょっとやってみたいね。
じゃあ、いい感じの時間なので、本日は以上にできればと思います。
ありがとうございました。
ありがとうございました。
本日もAI駆動開発部の日常をお聞きいただき、誠にありがとうございました。いかがでしたでしょうか。
今回はまた引き続き、グローデザインを使ってみてというところの話題になりました。
こんな感じで、日々AIのサービス使ったりしているので、もし気に入ってくれた方は、いいねやフォロー、高評価ぜひお願いいたします。
それでは、また次回もお楽しみください。バイバイ。