Claude Designの実践投入とワークフローの変化
こんにちは、AI駆動開発部の日常へようこそ。 このポッドキャストは、日々AI駆動開発を行う
企業家の山本とエンジニアの阿部が AI駆動開発のリアルをゆるーく語り合う番組です。
はい、じゃあ本日よろしくお願いします。
よろしくお願いします。
はい、じゃあちょっと今日は前回か前々回ぐらいかな、 話したClaude Designについて、
もう少し開発用途とかでも使ってみたので、 その辺の話がまずできたらなっていう風に思っております。
阿部ちゃんはまだ使ってないんよね?
実際そう使うケースになくて、まだ使えてないですね。
じゃあちょっと僕の実際に使ってみた話とか、 使い方の部分とか、その辺を話して、
その上で、じゃあこんなことできそうだよねみたいな話に 広げていけたらいいのかなという風に思ってます。
前回のClaude Designについての話題のおさらいというか、 振り返りをすると、
YouTubeとかもやっていて、 YouTubeの周りのフレームを作ったりとか、
そういう素材を実際に、例えばコメントを その素材の中に埋め込みたいんだよねみたいな時に、
その文章ごと変えれるみたいな。
だからシステムと、AIが組んだデザインを、 本当にデザインシステムみたいな感じで、
ちょっと文言を変えたりして、柔軟に取り扱える。
しかも再現性を持って柔軟に取り扱えるみたいな仕組みで、
かなりそもそもデザインの管理システムとして、
優秀なシステムを構築してくれるな、 みたいな話をしてたと思ってます。
その時はまだYouTubeのクリエイティブとか、 そういうのにしか使っていなくて、
今までAIで画像を生成させようとすると、 なかなか再現性取れないよねみたいな話があったんですけど、
システムをそもそも組んで、そこの文字とか写真とかを 特快非快しながらデザインを組めるように、
クロード側がシステムを組んでくれるので、 再現性高くデザインできるっていうのは、
かなり革新的だなっていう話をしたのかなと思ってます。
ちょっとそこから、僕実際にAIが出したデザイン、
どっちかというとクロードデザインではなくて、 オープンコードとか使って、
普通にUI実装してもらったデザインで、 ちょっと気に食わないことがあって、
のぺっとした、なんかちょっと洗練されてないような 見た目だなみたいなとか思ったりとか、
情報構造がバラバラで視覚的に見づらく感じちゃうような、 UX的にも悪いようなみたいなものとかの整理をしてもらいたくて、
そういえばクロードデザインいいんじゃないかなと思って、 実際にクロードデザインに投げてみたと。
そうするとサービスのプロジェクト用のやつを立てて、 ローカルのプロジェクトをアップロードするみたいな、
同期するみたいなことができて、 GitHubの連携もできるみたいなけど、
そういうのができて、だから自分のリポジトリを ちゃんと把握した上でデザインを組んでくれるみたいな感じなので、
まずそこ結構いいなっていうところと、 あと結構驚いたのが、
気に入らない画面のスクショペンって送って、 ここが黒縁の枠線でちょっとのぺっとした印象になるから、
もうちょっと洗練させて欲しいっていうのを バグって言っただけなんやけど、
そうするといくつか質問を画面上で聞いてくれて、 例えばプライマリーカラーはリポジトリを把握してるから、
プライマリーカラーで塗りつぶしますかとか、 白ベースにしますかとか、そういうのを聞いてくれたりとか、
あと2,3案出せばいいですか、1案だけでいいですか、 4案以上欲しいですか、聞いてくれたりとか、
そもそも仕様の話、こういうふうにやってもいい、 折りたたむみたいなやり方でもいいですか、
みたいな動線設計の話とかしてくれて、 それでいくつか答えていったら、
なかなかいいデザインが上がってきて、 それをしかも右上にシェアボタンっていうのがあるんだけど、
クロードコードとかにハンドオフで渡せるみたいな、 実体としてはAPIのURLが発行されて、
それを叩くとファイルがダウンロードされて、 それを一時的にクロードが見ながらデザインをするみたいな感じだと思うけど、
スキルも一緒になってんのかな、 そういうのを情報として見たことあるけど、
実体はちょっと分かってないんだけど、 クロードコードにそのまま渡すとか、
クロードコードウェブにそのまま渡すとかもできて、 実際にデザインを見ながらやってくれるみたいな、
デザインを見ながら開始を進めてくれるみたいなのがあって、 この体験めっちゃいいなと思って、
だから一発バーッと作らして、 UIがちょっとガタガタでもそっちにスクショ渡して、
デザイン洗練させてって言って、 そうすると既存のコードのコンテキストも食ってる前提になるんで、
そんなに外れ値を引くこともなく、 しっかり洗練された良いデザインを出してくるみたいな感じ。
多分ハーネス側で結構デザイン向けのプロンプトが 仕込まれてるんやと思うけど、
なかなかいいなと思って、 しかもそうしていくと勝手に作ってるサービスのコンテキストが、
その中に溜まっていくから、 最終的に本当にデザインシステム組み上がっていくなみたいな。
Pencilとの比較と開発順序の議論
そうなんですね。すごいな。
前にPencilっていうアプリを紹介したと思うんですけど、 僕あの時結構興奮していて、
Pencilってアプリでダウンロードしたら Figmaみたいにデザインを自分で組むこともできるし、
基本的にはAIに書かせて、それがJSONでデータとして 吐き出されるから、Gitで管理されるから、
とりあえず管理できるようになって、 デザインシステムを組むことができる可能性があるよね。
すごい興奮していたのがあったんですけど、 実際Pencilを使ってると、
あんまりデザインを整えたりとかっていうのを あんまりできなかったっていうところもあって、
結局その開発としてのデザインシステムを組むことが 運用としてできなかったっていうのが半年前ぐらいかな、
もう年明け前ぐらいかなにあったんですけど、
それがもうクロードデザインでまるっとできるようになったんだな みたいな感覚を、
山ちゃんが横でやってるのを見ていてすごい感じて、
Pencilでできたらよかったけどな、みたいな。
そういうのをPencilでやりたかったんだけどなっていうのがちょっと残念というか。
アブちゃんちょっとPencilフィギュアなのか分かんないけど。
フィギュアなのはあって、
あの当時にそういうのができるっていうのが なかなかなかったっていうのがあったっていうところと、
デザインに関しては結構僕あんまり得意な、苦手な意識があるので、
AIがそういうのをやれるようになったら結構夢があるっていうところがまず1個よかったか。
Pencil推しのところの1個と、
あの当時アプリケーションの中にAIをそのまま組み込んで、
裏側はクロードコードを叩くような仕組みになってるんですけど、
そういうハーネスを抱き合わせにしたアプリケーションってあんまりなかったんですよ。
なので結構これって今後主流になりそうだなみたいな興奮もあったので、
Pencil推しだったんですけど、
実際うまくこうデザインを組むっていう意味では把握しないで使えなかった。
そういうのがあったんですよ。
なんか1回阿部ちゃんがPencilでデザインを作って俺に見せてくれた時にさ、
いやなんかもうそのステップ無駄だから早く実装しちゃってくれっていう話をしたことがあったじゃん。
そうだよね。
あの時って多分Pencilでデザイン組んでも実装で普通にCodexとかで出してくるデザインもあんまり変わらんくて、
だから出たものをごちゃごちゃするで十分じゃんっていう感じだったんですけど、
今このクロードデザインになって多分大きな違いがやっぱりちゃんとデザインしてくれる。
多分ハーネス側のプロンプトというかチューニングでちゃんといいデザインをしてくれるってなると、
そのワンステップ進む価値が出てくるなって思って。
実際は多分一番いいフローは今俺の中でやってる一番いいフローはオープンコードでプロメテウスで計画出せさせて、
一回Phystosでレビュープランかけて、それでAtlasでプランを実行するみたいな感じで、
その実行しきったやつを持ってその画面を見せて、スクリーンショットで見せて、
なんか分かりにくいところとかあるから情報整理してデザイン洗練させてくださいみたいなことを言うと、
そこそこいいものができて、その前提でさっき言ったハンドオフでロードコードに渡して、
このデザインの通りにやってくださいって言って、まずそのまま実行させると、
あんまりスマホのことも考えないでやられたりするよね。
なんかちょっとレスポンシブとかの検討が甘かったりするから、
一回プランモードでそのプロンプト渡して、そこから実行するみたいなステップを踏むと、
かなりワークするなみたいな感じがあって。
なので今の俺の中での開発ルーティンというか流れはそんな感じ。
オープンコードで計画とかやって、ロジック面しっかりガチガチ作るっていう。
とはいえプランの中でよっぽど逸脱したことがなければそのまま進めて、
最終的にアウトプットといったらそんなに悪くないものを出すんですね。
とはいえちょっとノペットしてるなとか野暮ったいなって感じるから、
それをスクショして渡して改変していくみたいなのが多分いいループというか。
結局のところ、前安倍ちゃんが言ったみたいな実装する前にペンシル貯めるみたいなことは、
これは安倍ちゃんだからどうかとかがありそうやけど、
俺はどちらかというとロジックをしっかり作ってほしいんで、
デザインをこっちからガチッと指定して、それをコンテキストにやるのちょっともったいなく感じるんだね。
以前はデザインをまず作ってから実装させてみようかなみたいなところもあったんだけど、
ある程度要件を詰めて仕様というかが決まっていれば、
まずは実装させて動くところというか、
ロジックがちゃんとしているところだけに注力して、デザインは一旦いいからやってもらって、
出来上がったものをごちごち変える。
確かにそっちのほうがクロードデザインがデザインする上でも、
そもそも必要な要素って何だろうみたいなのを、
とりあえず叩きで作った画面からちゃんと推測できるようになる状態だと思うから、
多分そっちのほうがすんなりいくよねみたいなイメージだったな。
あとワンステップ無駄やもんね。
どっちにしろそこそこいいデザイン作ってくれるんだったら、
ワイヤレベルで作ってくれるんだったら、
もうそれで機能要件しっかりしてロジックちゃんとしてたら、
あとはいかようにもできるという意味で言うと。
そうだね、確かに。
たまに多分あるけどね、思いっきり回らなきゃいけないことはあると思うけど、
今やってる感じじゃほとんどそういうケースがなくて、
今までは基本的には出してもらって、
デザイン的にダメなUIとか動線的にダメなところをガチャガチャ変えていくみたいなスタイルでやってて、
それで大きく変更になってもう破綻したみたいなことはなかったんで、
大きくて戻ったみたいなことは実は結構なくて。
その体験もあったから、
阿部ちゃんにはデザイン始め挟むの意味なくないみたいな話をした。
あとデザインを始めに固めてもその通りにしてくれないじゃん、ある意味というか。
なるほどね。
そう、っていうのもあるかもしれないね。
出来上がった状態でコードがある状態でこの通りにやってって言ったら、
ある程度精度高くやってくれるんだけど、
何もないところからこのデザインを目指してくれって言っても、
あんまりちょっとずれてたりすることが結局あるから、
やったら最後どうせデザイン調整っていうステップがあるんだったら、
そこで集約しちゃえばいいじゃんみたいな考えが結構あるのか。
そうだね。あと僕の場合、
現在の開発ルーティンとデザイン調整のループ
何で最初にデザイン作ったかみたいなところで言うと、
僕はあまりフロントエンドのデザインみたいなのは得意じゃないというか、
苦手意識があるがゆえに、
ある程度最初にどういう操作感になるのかなみたいなのをイメージ沸かせてから、
もうちょっと自分の要件にそもそも抜け漏れないかっていうのをチェックしたかったっていうところが、
結構最初の方はあったりしたんだけど、
最近で言うとその辺も含めてAIが割と吉野に補完してることもあったりするので、
一旦作らせて、その上で作らせたものを操作して、
自分の中でそれを操作したことによって、
得られるフィードバックを修正として積み上げてっていうほうが早いかなっていうところ。
早いよね。結局早いっていうね。
どっちにしろ発生する調整業務だからね、そこは。
うん、そうだね。
仮に、そうだな、山ちゃんが今言ってたような、最初に作らせてデザインをブラッシュアップするっていうのを、
多分今あれだよね、ペンシルでそれ同じことやろうとしても、
多分ペンシルには同じぐらいのデザインをブラッシュアップするみたいな能力はおそらくない。
多分デザインを管理しやすくするっていうのと、
あとハンドオフ的に機嫌側でフリグマっぽく調整できるっていうのが売りで、ペンシルは。
クロードコードはそこを完全にAIにデザイナーとして立ち回ってもらおうっていうところだから、
そこが結構思想として違うんじゃないかなっていう気はするよね。
そうだよね。結果的にそれでちゃんとデザイン起こして、
しかもデザインシステムまで落とし込める未来が見えるんだったら、
圧倒的にクロードコード、クロードデザインを使うっていうのが、
ワークしそうだなっていう感じがする。
なんかワークしそうな気はしてる。
Claude Designの活用とデザインシステムの構築
だから出来上がったものをちゃんとブラッシュアップする過程で、
最終的に着地したものをちゃんと保持しといて、
いらないものはクリーンアップちゃんとしてもらうっていう、クロードデザイン上でね。
ほっといたら残しとくからさ、あいつ。
これで行きますって言って残すんよね。違反候補名のやつも。
クリーンアップちゃんとしてって言ってクリーンアップして、
それでも多分画面単位でやると、今正直画面ちゃんとデザイン調整してみたいので言うと、
5、6画面なんやけど、5、6画面ダイアログとか含めてっていう感じで、
それで3メガぐらい行くんよね、実際に。
5、6画面で3メガぐらい。
インストラクションをクロードコードにハンドオフ的に渡すんやけど、
そのインストラクションをやるとフェッチして取ってくるみたいな感じのことをするんやけど、
そのコンテキストのデザイン。それが大体3メガなんやね。
結構大きそうやね。
結構大きくて、5、6画面でそんなんだから、最終的にはイメージとしては、
本当に画面単位というよりはコンポーネント単位でまとめた別のプロジェクトを立てたりする方がいいんだろうなっていう気はしてる。
デザインシステム的に使うのであれば。
プロジェクトを分けてしまって、デザインシステムコンポーネント用のプロジェクトと、
実際に画面を管理するというか、1画面ずつなのか何かの単位ずつとかで管理するプロジェクトを分ける。
うんうんうん。
そう。
まあ、になるのかな。
コンテキストが分離されるような気もするんだけど。
大丈夫なのか。
プロジェクトが例えば、分かれてるから。
だから俺のイメージで言うと、システムで流用しやすいような管理をしていくための別プロジェクトみたいなのを作る。
けど今確認したら、クローズデザインでHTMLページでフェッチするっぽい、今確認したけど。
だから、どっちかというと同じプロジェクトの中にコンポーネントを管理するためのページを作って、
それを必要な指示にするだけでいいかもしれない。
うん。
それができたらいいよね。
なるべくは一つの管理しておく。
大規模コンテキストモデルSubQと分散データベースTurso
これは100万トークンコンテキストを扱えるからっていう。
クロードのオーパスがね。
うんうん。
あれ見た?サブキューって読むの?
サブキューかな?2000万トークン?1200万トークンだっけ?
120Mって書いてたから、1億2000万トークン。
1億2000万。ほんとかな。
しかもクロードのオーパスより安くて、そこそこ頭もいいよねみたいな。
ベンチも結構オーパス4.6に匹敵するぐらい水位ベンチですけど。
12Mだね。12Mだわ。だから1200万トークンか。
まあとはいえ。
とはいえすごい。
いや俺嘘じゃないかなって思ってるけど勝手に。さすがに。
何かしらブレイクスルーが起きてない限り、結構到達不能な数値な気がするよね。
そうだね。ちょっと僕はウィッシュリストに登録するのをためらってます。
俺はウィッシュリストに登録しました。
これ詐欺とかあったら嫌だなみたいな。メール抜かれたら嫌だなみたいな勝手に。
すごい素敵な発想が頭の中によぎってやめとこって。
なるほどね。俺はちょっと一瞬で登録しちゃったわ。
そうかなと思ったから、見た瞬間登録しそうだなと思ったけど。
でも本当にそれがいくんだったら、それこそデザインとかももっと幅広くできるんだろうなって感じがする。
結構期待はしてるっていうのはある?
そうだね。あとクロードコードに渡す時にプランでやってっていうのをプランを挟んで実行するみたいなことをやると結構精度上がるから
割と軽いタスクはクロードコードに預けるようになったね。
これもちょっと大きな進化かもしれない。
このデザインをすごいよね。ローカルにある大量のコードのファイルとかもドカッと渡して
本物というか色とかもちゃんと認識した上でクロードデザインがデザイン組み上げてくれるって
今まであんまりこんなドカッとファイル渡すのって
クロードチャットとかチャットGPTとかもファイルの10ファイルぐらいがせいぜい上限だったりしたのにもかかわらず
こうやってフォルダごとドカンと渡せるのがすごいなっていう。
ハーネスというか。しかもそれがローカルのアプリとかじゃなくて
完全にクラウド上で完結できる。
結局あれなんよね多分。例えばローカルで開発してて調査お願いしたら
リポジトリを添付フォルダみたいなところにクローンして落としてきて調査したりする振る舞いするじゃんAIが。
それと多分同じ感じで、前も言ったけどクロードデザイン上に一つのデザインシステムを組むリポジトリが作られるみたいなイメージになってるから
だからそこにクローンしてきてると同じ感覚なんだろうなって思ってる。
そうだよね。クロードデザイン的にはユーザーがプロとしてクローンしてきてみたいなね。
ここの環境を構築できたっていうのは、デビンとかもやってたけどね。それが一個の発明というか。
完全にフォルダとかもちゃんと整理して保存されていくから、これがオンラインでできるようになったのは結構すごい。
もちろんデビンも昔からやってるっていうのはあるけど。
すごいなって感じですね。
サービスに組み込みたいところですね。
今僕もオンラインでそういうエージェントを動かすハーネスを実際に作ってはいるんですけど、結構こういう仕組み作るの難しくて。
しかもそれが不特定多数のユーザーが使うとか、そういうのも想定した上で考えると結構難しいから、これやりきって本当に僕は感動したというか、すごいなって。
ターソー、トゥルソー、今日ちょっとちらっと話した。
TURSOかっていうエージェント単位とか、一つの店舗単位とか、そういうのでデータベースサーバーを持てるみたいな感じなのかな。
それはもう持てるのはいくらでも持てて、有料プランだったら。あくまでも読み書きするのに重量課金するみたいな。
そういう仕組みがあれば、一個複数の人が使う前提になるからこそ生まれる複雑さっていうのを排除できるから、なんかちょっとシンプルになりそうやんな。
そういうのを使ってるのかもしれないね、もしかしたら裏側で。
もしかしたらね、いわゆるマルチテナント型とか、RLSみたいな、一つのデータベースとか一つのインフラでいろんなユーザーを抱えるんじゃなくて、
もうTURSOとかはインフラごと分離するよみたいな、マルチサーバー的な感覚というか、そういうのもしかしたらやってるかもしれないですね。
なんかそれやんないと結構怖いもんね、プロンプトインジェクションとかを含めて。
そうだね、データを分離して完全にユーザーごとにサンドボックスにさせるみたいなのを考えていかなきゃいけないから。
確かに、インフラごと分離するとかも一つの方法論ではあるよね。
でもこれがクロードとかGPT、チャットGPTみたいな、数千万人、数億人が使う規模とかだと、一体どうやってるんだみたいな。
そういうのもあるけど。
だからこそこういうTURSOみたいなのが出てくるんでしょうね。そこを簡略化してくれる。
そうだね。
だってテナント単位とかにできれば、情報量も1テナントに限られるから、負荷分散にもなるもんね。
確かにね。分散はできるよね。
だからそういう意味でも結構いいんだろうな。TURSOは口コミ的にはまだ本番で使えないレベルだみたいなのを見たりとかもしたりとか。
実験的なプロジェクトとかだったら使ってたりとかみたいな。まだこれからって感じなイメージだけど。
そういうのが整備されてくると、結構エージェント開発とか。
前回前々回ぐらいの話でした。コンテキストをいかに渡してあげるかみたいな。
まだ話してないかな。ログをできるだけ取っておくと、AIにユーザーの行動っていうのがちゃんと世界を認識させられるという意味で重要だよねってなった時に、
どうしてもログの量とかが多くなりすぎたりとかするから、そうした時にも結構良さそうよね。分離すると初めから。
エージェント開発とログ管理の重要性
まあそんな感じでちょっとクロードデザインかなり良かったですっていう話です。
はい。じゃあ今日はこんなところで終わりましょうか。
はい。じゃあありがとうございました。
ありがとうございました。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。いかがでしたでしょうか。
本日はクロードデザインですね。実際にシステム開発領域でも結構使えるなっていう所感を得たので、そこの共有になりました。
こんな感じでいろいろなサービス使っておりますので、もし気になった方は、いいねやフォロー、高評価ぜひお願いいたします。
それではまた次回もお楽しみください。バイバイ。
