Transcript
00:00:00このチャンネルをしばらくご覧の方ならご存知かもしれませんが、私たちはこれまで多くのデザイン
00:00:03ワークフローやツールを取り上げてきました。何ヶ月もテストを重ね、ついに突き止めました。
00:00:08同じモデルを使っているのに、完全にカスタムされたように見えるものと、いかにも
00:00:13AI生成だと分かるものが生まれる理由は何なのか。それは3つのレベルに分かれています。レベル1は単一ページの設計で、
00:00:19ほとんどの人が見落としている重要なポイントがあり、それこそが成果物が凡庸に見えるすべての原因です。レベル2は、
00:00:23ページの設計をやめてシステムの設計を始める段階であり、ここでのワークフローは
00:00:28まったく異なります。そしてレベル3は、実際に機能するバージョンを見つけるためにデザイン同士をテストし合う方法であり、
00:00:34現在ではすべての実際のプロジェクトで私たちが用いている部分です。つまりレベル1は、
00:00:39単一ページの良いデザインを作成することに関係しています。これは優れたデザインの土台であるため、
00:00:44ほとんどの人が教えるレベルです。前回の動画では、Opus 4.7のデザイン
00:00:50能力がどれほど向上し、かつてよく見られたAIの粗削りな出力がどのように消え去ったかについてお話ししました。以前は、
00:00:55ランディングページの作成のような単純なプロンプトを与えると、紫と白のテーマをそのまま採用し、
00:00:59その周囲すべてを構築していました。その特定のパターンは改善されています。しかし、
00:01:04他のAIモデルと同様に、このモデルも安全なパターンに収束します。そして、私たちのあらゆるテストや
00:01:09試行錯誤の結果、毎回特定のスタイルにデフォルトで落ち着くことが分かっています。そのため現在では、
00:01:15そのスタイルを見かければ一目でOpus 4.7製だと分かりますし、次のAIの凡庸な成果物になるのは時間の問題です。
00:01:21そのため、このウェブサイトをより良く見せるための別の方法が必要になります。さて、
00:01:25このレベルは主にプロンプトエンジニアリングと、アプリの指定方法にかかっています。なぜなら、
00:01:30プロンプトを適切に構築すれば、アプリを一度の指示ですっかり作成できるからです。プロンプトは、
00:01:35構築を目指すウェブサイトの意図から始め、次に絶対に譲れない条件、例えば
00:01:39アプリにどうしても入れたい要素やUI要素の見た目の希望を記述します。その後に、
00:01:44色彩システムを指定します。ここではOKLCHを使用します。これは基本的には明度、クロマ、色相の測定値です。
00:01:49通常のRGBやHSLの代わりにOKLCHを使用する方が優れています。なぜなら、人間の目が実際に色彩を知覚する方法で色を表現するため、
00:01:55明度やバランスの調整に優れているからです。また、不自然に見えがちなカラーコードとは異なり、
00:01:59より滑らかなグラデーションを作り出します。配色を設定したら、
00:02:04コントラストの流れについても言及する必要があります。コントラストはUIデザインにおいて非常に重要な要素です。
00:02:08なぜなら、重要なものに視線を導く階層構造を実際に作り出すからです。明確なコントラストがないと、
00:02:13モデルはすべての要素を同じように重要であるかのように扱ってしまい、
00:02:18視覚的な階層を形成しづらくなるためです。そして、ウェブサイトがいかにも
00:02:22AIが作ったもののように見えないようにするためには、プロンプトからタイポグラフィも制御しなければなりません。AIらしい粗さのために
00:02:27禁止するフォントや、デザインの異なる領域でどのフォントを使用すべきかを定義します。InterやGeistのようなフォントは、
00:02:33あらゆるエージェントがデフォルトで使用するためAIらしい凡庸さの象徴になっており、明示的に除外することで
00:02:38モデルに別の選択肢を探すよう強制できます。次に、ウェブサイトのレイアウトとリズムを定義しますが、
00:02:42その前に対称性と非対称性について知る必要があります。対称的なレイアウトはコンポーネントが
00:02:47グリッド上に均等に配置されバランスの取れた見た目になり、プロフェッショナルで
00:02:51堅実なデザインに向いています。しかし、より芸術的な見た目を目指すなら、実験の余地が広がる非対称を選びましょう。
00:02:56ネガティブスペース（余白）を活用する必要がある場合に特に効果的であり、デザインに
00:03:01息吹を与えられます。どのような製品を構築しているかによって、どちらが適しているかが決まります。その後、希望するすべてのセクション、
00:03:06使用する素材、そしてウェブサイトがレスポンシブにどう動作すべきかを定義します。そして最も重要な
00:03:11部分は、アンチパターンに言及することです。これらは、単純に中央揃えされたCTAや、
00:03:17Lucidアイコン、グラスモーフィズムデザインといったAI特有の安っぽさの象徴です。このプロンプトをClaude Codeや
00:03:22使用しているエージェントに渡せば、アプリを分析して実装の詳細を確認してくれます。その後、
00:03:27芸術的な目的と余白の適切な活用を念頭に置いた非対称性を備え、プロンプトに記述された通りのアプリを構築してくれます。
00:03:34レベル2は、サイトのすべてのページで一貫したデザインを維持することに関するものです。というのも、ほとんどのエージェント生成アプリは
00:03:40ランディングページを離れた瞬間に崩壊してしまうからです。エージェントを使ってアプリ全体を生成する際、
00:03:45まさにこのような経験をしたことがあるかもしれません。ランディングページは大体かなり良い出来ですが、他のページに移動すると、
00:03:50本来のUIスタイルが一貫して維持されません。ダッシュボードでは異なる
00:03:55ボタンのスタイル、異なる間隔、異なるタイポグラフィになってしまい、まるでエージェントが同じアプリを
00:04:00作っていることを忘れてしまったかのようです。他のページはもはや同じサイトの一部ではないかのように見え、
00:04:05エージェントによって生成されたサイトであることが露呈してしまいます。認証ページではデザインが保たれることもありますが、
00:04:10ダッシュボードに移行した途端、スタイルが完全に崩壊します。そのためには、最も重要な2つのファイル、
00:04:15Claude.mdとDesign.mdを作成する必要があります。これら2つのファイルこそが、サイト全体を通してデザインの一貫性を保つ要です。
00:04:21Claude.mdには、これまで何度もお話ししたように、デザインではなくプロジェクト情報のみを記述します。
00:04:27これは、ファイルが常にセッション内に読み込まれた状態になるためであり、そこにデザインのコンテンツがあると
00:04:32エージェントが別の作業をしているときに気が散ってしまう原因になるからです。しかし、優れたデザインにつながる
00:04:37プロジェクトの文脈を保持するため、依然として重要なファイルです。デザイン自体については、
00:04:42ビジュアルシステム、レイアウト、色彩、タイポグラフィ、およびレベル1で取り上げたすべての詳細に関する
00:04:47あらゆる要素を網羅した別のファイルが必要になります。Design.mdは、どのアエージェントが読んでも
00:04:52ビジュアルシステムが何であるかを即座に理解できるようなファイルであるべきです。そして前のレベルと同様に、
00:04:57OKLCHでのカラーシステム定義もここで行います.
00:05:03両方のファイルを生成させました。Claude.mdはプロジェクトの詳細だけを含む短いものです。
00:05:09Design.mdは、カラーコードやタイポグラフィの選択など、あらゆる詳細を盛り込んだ長めのものです。しかし、
00:05:15Design.mdはそれで終わりではありません。時間をかけて洗練させ続ける必要があります。
00:05:20そのため、見つけた新しいデザイン上の価値をこのファイルに追加するようエージェントに指示する一文を冒頭に入れています。
00:05:25そうすることで、どのセッションも前回よりも洗練されたバージョンのデザインシステムから始めることができます。
00:05:30しかし、ClaudeにDesign.mdを作らせるだけでは十分ではありません。
00:05:35生成されたものがベストプラクティスを適切に踏襲していないためです。Googleは
00:05:40Design.mdファイル用のテンプレートをオープンソースとして公開しています。このテンプレートには、Design.mdをそれと照らし合わせて相互検証し、
00:05:46エラーにフラグを立てるためのコマンドも含まれています。そのため、それらのコマンドを使って反復作業を行うようエージェントにプロンプトを指示するだけで、
00:05:51Design.mdを完璧なものに仕上げることができます。そして、これでレベル2が終わりというわけではありません。このレベルで十分な品質のデザインを生成するには、
00:05:56既存のデザイン原則に照らし合わせて監査する必要もあります。そのためには、
00:06:00まさにそれを実行してくれるオープンソースのスキルが多数存在します。どれを使用しても構いませんが、私たちはVersaLabのスキルを使用しています。
00:06:06なぜなら、スキル内にすべての原則をハードコーディングするのではなく、
00:06:11積極的に保守されている外部のソースを参照しているからです。これにより、スキルが最初に書かれた時点での最先端の状態で固定されることなく、
00:06:16原則を現在のベストプラクティスに常に最新の状態で合わせることができます。このスキルをプロジェクトにインストールして実行すれば、
00:06:21デザインが以前よりもはるかに優れた形に仕上がります。しかし、先へ進む前に、
00:06:25スポンサーからのメッセージをご覧ください。私は最近ZillysCloudを使い始めたのですが、その理由をお話ししましょう。
00:06:30ほとんどのRAGアプリは少数のドキュメントであればうまく機能しますが、実際のデータを放り込んだ途端、
00:06:35セットアップがそのような負荷を処理できるように設計されていないため、機能しなくなってしまいます。
00:06:40MilvusはGitHubで4万4千以上のスターを獲得している最も人気のオープンソースベクトルデータベースであり、
00:06:46そのような負荷に対応するように構築されていますが、セルフホストするということは自分でインフラを管理することを意味します。
00:06:51そこで登場するのがZillysCloudです。これは同じAPIを備えた完全マネージド版であり、
00:06:56最大10倍高速で、コードを1行も変更することなく数分でセットアップできます。
00:07:00私たちがZillysCloudでセマンティック検索クエリを実行したところ、キーワードだけでなく意味を理解してくれるため、
00:07:05結果が実際に有用なものになりました。大規模なデータセットであっても、応答時間はほぼ一瞬です。
00:07:11また、1つの記事を基にした推薦クエリも実行しました。データセット全体から類似度の高い上位5つの記事を
00:07:16類似度順に1秒未満で探し出してくれました。さらに、ダッシュボードではクラスターのパフォーマンス、
00:07:21ストレージ使用量、コレクションやエンティティの数を含むデータメトリクスをリアルタイムで追跡できます。クレジットカードは
00:07:27不要です。固定コメントのリンクをクリックして、ZillysCloudを無料で試してみてください。
00:07:31レベル3は、エンジニアがTDDでコードを検証するのと同じように、プログラムによってデザインをテストすることに関するものです。
00:07:36コードのように視覚的にテストを書くことができないのはご存知の通りです。コードの場合、
00:07:41すべてに対して明確な入力と出力が存在します。デザインには主観的であり、
00:07:46コードのように数値化できないためそれがありませんが、主観的だからといってテストが書けないわけではありません。
00:07:51コードでTDDが機能する理由は、テストが振る舞いの仕様を固定し、
00:07:57実装がその仕様を満たす必要があるためです。同じ考え方が、異なる種類の仕様を用いて
00:08:01デザインにも適用されます。私たちが構築していたアプリでは、最初のステップは以前と同様に、
00:08:05実装を考えるよりも前にclod.mdとdesign.mdファイルを作成することでした。テストは常に
00:08:12コードよりも前に書かれるべきであり、そうすることで実装をテストで実際に検証できるようになります。もし実装の後に
00:08:17テストを書くと、エージェントが手を抜いてしまいます。すでにコードがコンテキスト内にあるため、その
00:08:22既存のコードに最適化されたテストケースばかりを書いてしまうのです。最初にテストを書くことで、
00:08:27実装がテストに合わせるのではなく、テストに実装を合わせる形にします。そのため、デザイン
00:08:32ファイルをテストの信頼できる情報源として使用します。これらのファイルには、プログラムで検証
00:08:37可能なすべてのアンチパターンが含まれているためです。design.mdのすべてのアンチパターンがテストケースになります。すべてのカラールール、
00:08:44すべてのスペーシング制約、すべてのタイポグラフィの選択に対して、プログラムによるチェックが行われます。Claude Codeに
00:08:49詳細なプロンプトを与え、焦点を当てるべきすべてのセクションを指定してテストケースを作成させます。また、
00:08:54このコンテンツをお楽しみいただけましたら、このようなコンテンツをさらに作成し、より多くの人々に届ける
00:08:59助けとなりますので、高評価ボタンを押すことをご検討ください。プロンプトを使用すると、アプリのデザイン用の
00:09:04すべてのテストケースが作成されます。複数種類のテストが書き出されます。プロンプトで言及した
00:09:09アンチパターンを直接チェックする静的テストがあります。次に、基本裏側で
00:09:14Playwrightを使用し、回帰テストを実行してサイトを段階的に改善していくビジュアルテストがあります。さらに、
00:09:19スキャンやレポートといった他のコンポーネントやヘルパー関数のテストケースも作成されます。これらのテストは
00:09:24静的なアンチパターンをチェックしますが、デザインのテストには別のものが必要です。そのためには、
00:09:28UI向けのTDDを実行するCLIであるVisly Testという別のツールを使用します。その仕組みは、
00:09:34コードの変更に合わせてデザインを確認できる、ローカルTDDを実行するというものです。これにより、
00:09:39エージェントの自己監視に頼るのではなく、自分で差分を監視できるようになります。また、メタデータや
00:09:44その他の詳細が含まれた優れた差分が得られるため、レビューがより迅速になります。そのメタデータがない場合、
00:09:49単に2つのスクリーンショットを並べて比較し、違いが見つかることを期待するだけになってしまいます。Vislyを使用すれば、
00:09:54どのピクセルがどのように変更されたのかが正確に示されます。使用するには、まずドキュメントからインストールコマンドを実行してCLIをインストールします。
00:10:00セットアップと初期化が完了すれば、準備完了です。あとはClaude Codeを開き、
00:10:05TDDを使用して、テスト媒体としてVisly CLIを使いながらUIの任意のパーツを実装するように指示するだけです。
00:10:10Visly TDDコマンドを実行すると、ローカルサーバーが起動し、スクリーンショットの変更を監視します。スクリーンショットを送信するため、
00:10:16ClaudeはVislyという名前の独立したテストを記述します。これらのテストではPlaywrightの
00:10:21スクリーンショット機能を使用して、サーバー上のビューアーに画像を送信します。そこから、デザインを
00:10:27承認または却下し、前のバージョンと比較した差分を表示できます。却下された各差分は、
00:10:32エージェントが次のパスを調整するために使用するフィードバックとなります。数回繰り返すことで、デザインはエージェントが
00:10:37「あなたが望むだろう」と思うものではなく、あなたが実際に望むものへと収束していきます。ここで使用されているプロンプトは、
00:10:43この動画およびこれまでのすべての動画についてAI Labs Proでご覧いただけます。そこからダウンロードしてご自身の
00:10:47プロジェクトで利用できます。私たちの活動に価値を見出し、チャンネルをサポートしたい場合は、これが一番の方法です。リンクは
00:10:52説明欄にあります。これでこの動画は終わりとなります。チャンネルをサポートし、
00:10:57このような動画を作り続けるのを手伝っていただける場合は、下の「Super Thanks」ボタンをご利用ください。いつも
00:11:02ご視聴ありがとうございます。また次回の動画でお会いしましょう。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video