00:00:00皆さんの多くはすでにshad cnを最も広く使われているUIライブラリの一つとしてご存知でしょうが、
00:00:05AIエージェントでこれを使って構築する場合、
00:00:07問題が発生することがあります。ワンショットのランディングページを作成する場合はそれほど大きな問題はありませんが、
00:00:13新しいアプリを構築したり新機能を実装したりする場合、
00:00:16不具合が発生し、
00:00:17アプリの他の部分も壊してしまいます。しかし、
00:00:19これは何も新しいことではありません。この問題はすでに解決されており、
00:00:23現在エンジニアがアプリを構築する方法なのです。AIエージェントは常に自分が書いたコードをテストしますが、
00:00:28これらのエージェントは大規模なコンテキストでは信頼性が低くなります。そのため、
00:00:32エージェントが与えられた作業を確実に完了させる方法が必要です。ここでエージェンティックループの概念が登場し、
00:00:38Anthropicはこれをralphループを使用して解決しています。私のUI問題を解決するために、
00:00:43ralphループを実装しようとしました。最初は完全に失敗しましたが、
00:00:47すぐにralphループのせいではなく、
00:00:49それと一緒に実装したプロセスのせいだということがわかりました。ralphは実際にAnthropic自身がリリースした新しいプラグインですが、
00:00:56これは彼らのオリジナルのアイデアではありません。他の誰かの技術に基づいており、
00:01:00Anthropicがそれを実装してオープンソース化したのです。基本的にralphはループであり、
00:01:05Claud Code Hooksについて知っている方ならわかると思いますが、
00:01:09これはClaudが答えの出力を停止したときに実行されるストップフックを使用しています。停止するとすぐに、
00:01:15AIエージェントに初期プロンプトファイルが再び供給され、
00:01:18これにより作業を反復的に改善できるようになります。さて、
00:01:21ここで重要な質問は、
00:01:22実際にいつループから抜け出すかということです。完了約束(completion promise)と呼ばれるものがあり、
00:01:28これは入力できる任意の単語です。Claudがタスクが完了したと感じると、
00:01:32この約束を自分で出力します。たとえば、
00:01:34この場合の約束は「complete」という単語です。約束が返されたプロンプトにある場合、
00:01:39ループは再び実行されません。つまり、
00:01:41Claudが約束を出力するまで停止しないのです。これにより、
00:01:44Claudが好きなときに勝手に終了しないようにします。プラグインをインストールすると、
00:01:48ralphループコマンド、
00:01:50キャンセルコマンド、
00:01:51ヘルプコマンドの3つのコマンドが使えるようになります。ループコマンドでは、
00:01:55エージェントに何度も供給されるプロンプトを提供する必要があります。時には解決できない不可能なタスクを受け取って無限ループに陥る可能性があるため、
00:02:03最大反復回数を設定することは本当に良い習慣です。ralphループに与えるプロンプトのベストプラクティスがあるので、
00:02:09リポジトリへのリンクを下に残しておきますが、
00:02:11このビデオでは、
00:02:12これから紹介するUIワークフローに関連するものだけを取り上げます。それでは、
00:02:16このアプリに2つの機能を実装したいとしましょう。1つはコマンドパレットで、
00:02:20アプリを検索して他のコマンドを実行するメニューを追加します。この新機能がアプリの他の部分を壊さないようにするには、
00:02:26テストから始めます。これはテスト駆動開発と呼ばれます。これに慣れていない場合は、
00:02:30Claud Codeにテスト駆動開発の構造をセットアップするよう依頼できます。そこでは、
00:02:35エンドツーエンドのテストフォルダ、
00:02:37UI問題をチェックするためのスクリーンショットフォルダ、
00:02:40および対応するテストを作成します。もう1つ実装する機能は、
00:02:43データベース内のボードビューで、
00:02:44Notionがデータベースで行えるようにしているものと同様です。もうお気づきかもしれませんが、
00:02:49テスト駆動開発は、
00:02:50コードを実装する前にテストを書くアプローチです。しかし、
00:02:53これは初期のテストが常に失敗することを意味します。コマンドパレット機能を実装する場合、
00:02:58いきなりコードを書き始めるのではなく、
00:03:00まず詳細なテストを書きます。その後、
00:03:02それらのテストに合格するために必要な最小限のコードを書きます。それが完了したら、
00:03:06リファクタリングして機能を追加し、
00:03:08追加するたびにテストがまだ合格することを確認します。もう1つ興味深いことは、
00:03:12これらのテストは自動化されており、
00:03:14Playwrightをインポートして視覚的検証に使用できることです。Playwright MCPを使用してブラウザを介してこれを自律的に検証していると思っているなら、
00:03:23それは間違いです。テスト駆動開発では、
00:03:25各機能的動作に対してスクリーンショットを撮ることができます。たとえば、
00:03:28機能的動作がカードの追加である場合、
00:03:30スクリーンショットにはボードに追加されたカードが表示されます。つまり、
00:03:34AIエージェントがしなければならないことは、
00:03:36それらのスクリーンショットを見て、
00:03:38これらのshad cnコンポーネントが実装される方法に問題がないことを確認することだけです。これらのテストファイルは、
00:03:44何か新しいものが追加されたとき、
00:03:46または機能が構築されている間、
00:03:48すべての動作要件が満たされることを保証します。しかし、
00:03:51私たちの場合、
00:03:51スクリーンショットを純粋にUI検証に使用したいと考えています。しかし、
00:03:55すでにテスト駆動開発があるのに、
00:03:57なぜralphループが必要なのでしょうか。すでに述べたように、
00:04:00より大きなタスクとコンテキストウィンドウがほぼ満杯になると、
00:04:03これらのモデルは突然タスクを終了し、
00:04:05人間の絶え間ない入力が必要になります。したがって、
00:04:08実装したい任意のタイプの関数のために事前にテストを書いておき、
00:04:11ループを使用して何をすべきかを指示することができ、
00:04:14どのようなワークフローに従うかを伝え、
00:04:16いつ約束を出力できるかの条件を与えることで、
00:04:18自律的に作業できます。この場合、
00:04:2025個のユニークなテストすべてに合格したときに、
00:04:22タスクを完了してループを終了します。ralphスラッシュコマンドを使用して、
00:04:26コマンドパレット機能を反復的に構築するようプロンプトを与えました。プロンプトでは基本的に、
00:04:31いくつかの基本的な要件とともに機能を実装するように指示していました。これらはテストでも要件を見つけることができるため、
00:04:37実際には重要ではありませんが、
00:04:39ワークフロー全体を概説しました。そのワークフローでは、
00:04:42テストを実行することから始めることになっていました。テストが失敗することはわかっており、
00:04:47その後、
00:04:47それらを合格させるためにコンポーネントを実装する必要があります。それが全体の目標です。さて、
00:04:52これがはるかに広範なタスクである場合、
00:04:54コンテキストウィンドウが満杯になったり、
00:04:56Claudが混乱したりすると、
00:04:58自動的に終了する可能性があります。完了約束を出力することはなく、
00:05:01約束を出力しないため、
00:05:02プロンプトが再び供給され、
00:05:04最初からやり直さなければなりません。つまり、
00:05:06反復的に作業を続けることになります。しかし、
00:05:08これは小さなタスクだったので、
00:05:10実際にはすべてを一度に実装し、
00:05:12すべてのコンポーネントを書き出して、
00:05:13すべてのテストを合格させることができました。テストに合格した後、
00:05:17ワークフローはコマンドパレットのすべてのスクリーンショットをレビューするように指示します。これらは、
00:05:22使用しているshad cnまたは他のコンポーネントライブラリが正しく実装されており、
00:05:27小さな問題がないことを確認するために、
00:05:29さまざまな段階で撮影されたスクリーンショットです。その後、
00:05:32UI変更後もテストを再度実行し、
00:05:33まだ合格することを確認する必要があります。すべてのテストが合格し、
00:05:37スクリーンショットがレビューされたため、
00:05:39完了約束を出力しました。これがループが停止し、
00:05:41再び継続しなかった場所です。しかし、
00:05:43これには本当に大きな問題があり、
00:05:45コマンドパレット機能では気づきませんでした。なぜなら、
00:05:48UIエラーの可能性が非常に少なかったからです。しかし、
00:05:51ボードビューの実装に移ったとき、
00:05:53システムに大きな間違いがあることに気づきました。同じプロンプトでボードの実装を始めました。もちろん要件は異なりましたが、
00:05:59ワークフローはほぼ同じでした。一度にすべての要件を完了したときは少し驚きました。誤解しないでください、
00:06:04実際にすべてのテストが合格することを確認していましたが、
00:06:07それを行っている間、
00:06:08成功したテストの数が実際に減少するケースがありました。なぜなら、
00:06:12何かを変更することで他の何かを壊してしまうからです。これがテスト駆動開発が実際に非常に重要である理由です。この再帰的なテストとすべてが機能することを確認するためです。しかし、
00:06:21主な問題は、
00:06:22完了したことを確認した後、
00:06:23私がUIをチェックしに行ったとき、
00:06:25ほとんどのものは正しく実装されていましたが、
00:06:27このようなUIエラーを完全に見逃していたことです。スクリーンショットもチェックしましたが、
00:06:32それらのスクリーンショットにもエラーが表示されていました。そこで尋ねて、
00:06:36実際に何が間違っていたかを分析しました。本当の問題は、
00:06:39特にUIの修正に関してプロセスの失敗でした。何が起こったかというと、
00:06:42テストファイルを何度も実行することになっていたため、
00:06:45すべてのテストに合格しましたが、
00:06:47スクリーンショット以外にUIの特定のテストはありませんでした。いくつかを一瞥し、
00:06:51見たUIエラーのいくつかを無視することさえありました。一部のファイルは完全に無視されました。つまり、
00:06:56主な問題は、
00:06:57約束ステートメントを時期尚早に出力し、
00:06:59UIが実際に修正されたかどうかを検証しなかったことです。これをどのように修正できるかについて、
00:07:04全体的なブレインストーミングセッションを行い、
00:07:06リポジトリからのプロンプト作成のベストプラクティスをClaud Codeに与えましたが、
00:07:11最終的に、
00:07:12UIが常に正しいことを保証するいくつかの特定のルールとプロセスの変更を考え出しました。これはテストとは何の関係もありませんでした。なぜなら、
00:07:19それらは常に実行されるからです。コマンドパレットに使用したプロンプトは、
00:07:23機能や実装が非常に大規模な場合に本当に役立ちます。Claudがタスクを完了したと幻覚を起こすのではなく、
00:07:28コンテキストウィンドウが満杯になったり、
00:07:30タスクの複雑さのために突然終了したりします。Claud Codeはすでに本当に自律的です。それについては疑いの余地がありません。しかし、
00:07:38修正する必要があるこのような問題がまだあります。メインプロンプトで多くのことを変更しました。最初はスクリーンショット検証プロトコルでした。各画像に、
00:07:46Claudがスクリーンショットを読んだかどうかを示すシンプルなプレフィックスを追加しました。しかし、
00:07:51最初にこれを実装したとき、
00:07:52まだすべての画像を読んでいませんでした。いくつかを読み、
00:07:55その上にverifiedと書いて、
00:07:57以前と同じように早期に終了していました。これを解決するために、
00:08:00異なる方法で考えるよう促しました。すべてのスクリーンショットの名前を変更した後、
00:08:05まだ約束を出力しないように、
00:08:06つまりタスクが完了したとみなさないように、
00:08:08次の反復で完了を確認させるようにしました。つまり、
00:08:11少なくとも2つのループが実行されるべきです。次の検証で何が起こるかというと、
00:08:15Claudがすべてのファイルにverifiedプレフィックスがあることを確認します。もちろん、
00:08:20これは画像検証を機能テストから分離するためにテストを変更する必要があることを意味しました。次の反復では、
00:08:26すべての画像にverified結果があることを確認し、
00:08:28Claudが何かを見逃した場合は、
00:08:30それらを再度見て出力を修正します。この変更により、
00:08:33直面していた小さなUIエラーが最終的に修正され、
00:08:36これらすべての機能を正しく実装できました。次のループに入ると、
00:08:39テストを再度実行しました。いくつかのエラーを見つけたので、
00:08:42それらを修正し、
00:08:43すべてのファイルにverifiedという単語が含まれていたため、
00:08:46最後のテストを実行しました。今回は2つのループでタスクを完了し、
00:08:50アプリ内のすべての主要なUIエラーを修正することができました。では、
00:08:53Automataについてお話ししましょう。何百万人もの人々にAIで構築する方法を教えた後、
00:08:58これらのワークフローを自分たちで実装し始めました。これまで以上に速く、
00:09:02より良い製品を構築できることがわかりました。アプリでもウェブサイトでも、
00:09:06あなたのアイデアを実現するお手伝いをします。私たちの動画を見て、
00:09:09「素晴らしいアイデアがあるけど、
00:09:11それを構築する技術チームがない
00:09:12」と思っているかもしれません。それがまさに私たちの出番です。私たちをあなたの技術的な副操縦士と考えてください。何百万人に教えたのと同じワークフローをあなたのプロジェクトに直接適用し、"
00:09:22採用や開発チームの管理という頭痛の種なしに、
00:09:24コンセプトを実際に機能するソリューションに変えます。あなたのアイデアを現実に加速させる準備はできていますか?hello@automata.devまでご連絡ください。チャンネルをサポートし、
00:09:34このような動画を作り続けることを手伝いたい場合は、
00:09:37下のスーパーサンクスボタンを使用してサポートできます。いつもご視聴ありがとうございます。次回お会いしましょう。