22,753 文字
私はCursorを400時間以上使用してきました。自分のスタートアップ全体をCursorで構築し、世界最高のCursorの達人たちにインタビューもしてきました。この動画では、400時間分のCursorの生の知識を1本に凝縮してお伝えします。
最初に少し宣伝させてください。vectaを一緒に開発してくれる開発者を募集しています。フルスタック経験があり、チームに参加したい方は、動画の下のリンクからご応募ください。
さて、Cursorを使い始める際にまず必要なのは、do curs rulesファイルを作成することです。まずCursorの設定画面に行き、このオプションにチェックが入っていることを確認してください。それからプロジェクトのルートディレクトリにファイルを作成し、必要な情報を入力します。
このファイルをマークダウンとして扱いたい場合は、右下の「Plain text」をクリックして「markdown」と入力します。
最初のセクションには、プロジェクトの概要を入れます。ここにはプロジェクトのビジョンを記載します。次に、Cursorに持たせたい性格を設定するセクションを作ります。例えば、「シニア開発者のように教えて」といった具合です。
テクニカルタグも非常に重要です。ここにはフロントエンド、バックエンド、データベースなど、プロジェクトに関する技術的な情報をすべて含めます。
次の2つは任意ですが、プロセスに関するものです。ビルドやコーディングに関連して繰り返し行う指示がある場合は、そのためのプロセスを作成しましょう。例えば、「ステップ1：エラーを簡単な言葉で説明する」「ステップ2：3段落で説明を書く」といった具合です。
そしてここには環境変数を入れます。これが必要な理由は、おそらく.env.ignoreという2つ目のファイルを持っているからです。そこには環境変数を入れて、チャットやコンポーザーが誤って書き換えないようにできます。ただし、その場合、cursor rulesファイルに環境ファイルの内容を記載する必要があります。そうしないとCursorは.envファイルの存在や場所が分かりません。
現在のファイル構造については、treeコマンド（brew tree）を使って取得できます。無視すべきものは明確にして、100行あっても全部ここに貼り付けてください。
これもプロセスの一つで、GitHubへのプッシュに関するものです。これは皆さんも持っているべきですね。基本的に、GitHubにプッシュする際は、どのブランチにいるか確認し、コアブランチに切り替えて、明確なコミットメッセージでプッシュするように指示します。1日に10回GitHubにプッシュするなら、これで多くの時間を節約できます。
これは重要なセクションです。ここではcursor rulesファイルのどこかから最も重要な指示を繰り返し記載します。非常に重要な指示がある場合は、始めや中間、終わりで繰り返します。
その他のコンテキストは、cursor rulesファイルに含めたいその他の情報のためのものです。
そしてコメントについては、ここでコメントを書くことの重要性を強調します。コードには必ずコメントを含めるようにしましょう。
cursor rulesファイルは非常に重要で、毎日更新する必要があります。
次に知っておくべきなのは、repo promptについてです。これは実はCursorのネイティブツールではありませんが、入手可能なツールで、説明のリンクを下に貼っておきます。このツールでは、例えばここでコードベースのフォルダを選択すると、コードベース全体がここに読み込まれます。
選択して、例えば「私を悩ませているフロントエンドのバグを見つけて」などのプロンプトを書くと、下に約4,400トークンと表示されます。これにより、コードベース全体をプロンプトに入れることができ、AIモデルがより正確で信頼性の高い応答を返せるようになります。
このツールはまだテスト段階なので、知っている人は多くありませんが、これは絶対に知っておくべき重要なハックです。
では、Cursor内でどのAIモデルを使うべきでしょうか。設定を見てみましょう。Cursorの設定を開いて、モデルをクリックします。
最も重要なのは、新しいGlo 3.5 Sonetです。1022で終わる新しいバージョンを使用してください。これらはすべてチェックを外しておいて構いません。
これら2つは現在のGeminiの中で最高のモデルだと思います。これらを有効にしましょう。それからGPD 40は、anthropic APIに問題がある場合のバックアップとして。推論モデルとしては01とo1 miniです。
個人的には新しいSonetを99%使用しています。Sonetで行き詰まった場合、他のモデルで解決できることもあるので、これらのモデルを有効にしておくといいでしょう。ただし、デフォルトではSonetを有効にし、例えばターミナルを使用する時も同様です。
ここでもモデルを選択できますし、command Kで何かを書き換える時にもモデルを選択できます。すべての場所で適切なモデルを選択するようにしましょう。
プロンプトのテクニックについて、これは非常に興味深く、毎週上達していきます。最も重要なものをいくつか紹介します。
「コードは少ない方が良い」というのは、私が何度も使用したものです。例えばコンポーザーを使って新しい関数を書いたり、コードをリファクタリングする時、単にそれを指示するだけだと、AIは印象付けようとして不必要に高度な実装をしようとすることがあります。しかし、「コードは少ない方が良い」という一文を最後に加えるだけで、余計な行のない、よりクリーンで最小限のコードを書いてくれます。
「シニア開発者として進めて」や「10x エンジニアとして進めて」というのは、古典的なプロンプトエンジニアリングの基本ですね。
これは興味深いもので、最近発見したのですが、「この機能を完全に実装するまで作業を止めないでください」というプロンプトです。これによってモデルの「怠慢さ」が大幅に減ります。例えば4段階の変更が必要な場合、2段階か3段階だけ実行して「最後の段階に進みますか？」と聞いてくることがありますよね。正直、誰もそれは好みません。試してみてください。
推論パラグラフも非常に重要です。例えばエラーで行き詰まった時、ここにエラーがあるとします。単純な例えですが、例えば「try」の代わりに「dry」と書いてしまっているような場合です。エラーが出ていて解決できない、複雑な状況だとします。
その場合、全体をコンポーザーに読み込んで、「AIエージェントにエラーがあります」とタグ付けします。関連するファイルには必ずタグを付けてください。そして「まず3段階の推論パラグラフを書いて、エラーの可能性を分析してください。結論を急がないでください」と指示します。
これは非常に重要です。この指示がないと、「あ、エラーが分かりました」と言ってしまいます。この例のような単純なエラーなら問題ありませんが、より複雑なエラーの場合は大きな問題になります。なぜなら、「エラーが分かりました」と言ってしまうと、その間違った方向に固執してしまうからです。
LLMは次のトークンを予測する仕組みなので、エラーを確信していると言い始めると、もう終わりです。この指示を入れることで、コードを変更する前に3段階のパラグラフを書くことになり、正しい解決策を見つける可能性が大幅に高まります。そのため、大きな変更やエラーの場合は、3段階の推論パラグラフを書かせることが非常に重要です。
「簡潔に答えて」というのは明白ですね。モデルは往々にして冗長になりがちなので、「簡潔に答えて」と指示すると多くの時間を節約できます。
「コメントを削除しないで」というのも自明です。モデルにはコメントを削除する傾向があります。
「現在の状態の要約」というのは興味深いものです。これは主にクロードに関係していて、後でCLAの代わりにカーソルを使うべき時について説明しますが、この「現在の状態の要約」を使う状況というのは、例えば長いコンポーザーがあって新しいものに切り替えたい場合です。
ところで、新しいコンポーザーに切り替えるべき時について触れておきましょう。奇妙な動作が見られ始めた時、つまりコンポーザーが突然全く関係のないことを言い出したり、重要な情報を忘れたりし始めた時に切り替えるべきです。
これは、コンテキストウィンドウが過負荷になっている、つまりコードや参照ファイルが多すぎることを意味します。新しいコンポーザーに切り替える時期です。
ただし、新しいコンポーザーに切り替える問題点は、これまで築いてきた重要なコンテキストを失うことです。ここで「現在の状態の要約」が活きてきます。私がこのプロンプトを書いた理由です。
「進める前に、現在の状態の要約を出してください」というプロンプトを使います。途中で一時停止して、必要なら写し取ってください。私のプロンプトをすべて入手したい場合は、new Societyにあります。
new Societyのクラスルーム、テンプレートとプリセットの中に、私のシステムプロンプト、指示、AIエージェントの自動化、そして動画用のコードがすべて入っています。まだnew Societyに参加していない方は、ぜひ参加してください。これは間違いなく価値があります。
プロンプトと指示の中に、私のcurs RO file、cursシステムプロンプト、その他必要なものがすべて見られます。必要な方は、下のリンクからSocietyに参加してください。
とにかく、これが「現在の状態の要約」のプロンプトです。一時停止して写し取ることもできますが、基本的には、シニア開発者が別のプログラマーに説明するように、重要な情報を要約します。
プログラマーがこのプロジェクトで作業するのに必要なその他の情報、何をしたのか、何が上手くいかなかったのか、どのファイルが更新されたのかなどです。これは非常に重要です。
「仮説や理論は含めず、事実だけを述べてください」というのがポイントです。このプロンプトは、コンポーザーからの重要な情報を要約して、完全に一からやり直すことなく新しいコンポーザーに持ち込むことができます。私は毎日1、2回は使用しています。
もう一つ知っておくべきプロンプトは、「偏りのない50/50」です。こんな感じです：「答える前に、それぞれの解決策について詳細な2段落を書いてください」
例えば2つの可能な進め方があって、どちらが良いか分からない場合です。問題は、クロードがイエスマンになりがちなことです。ユーザーが望んでいると感じたことには「はい」と言い、ベストプラクティスの原則に違反しない限り、完全なイエスマンになります。
意見を表明しない場合でも、前の考えに同意してしまいます。これはLLMが次のトークンを予測する仕組みだからです。このプロンプトは、そのパターンを打破し、両方の可能な解決策を実際に分析させます。
重要なのは、「結論を急がず、両方のアプローチを真剣に検討してください。その後で、どちらの解決策が明らかに優れているか、その理由を教えてください」という部分です。
これは非常に重要です。そうしないと、最初の解決策を実行している時点で推奨してしまいます。応答の最初の5%か10%でそう言ってしまうと、残りの90%は無駄になります。なぜなら、すでに一方の解決策にコミットしているからです。
「結論を急がず、両方のアプローチを検討してください」と指示し、両方のパラグラフを書かせた後で、どちらが良いかを言わせる必要があります。
使うべきもう一つのプロンプトは、「適切に形成された検索クエリ」です。Cursorには、例えばADD webなどのウェブ機能があります。03について知りたい場合、個人的にはこの機能を使ったことはありません。まあまあ動くようですが、少し遅いようですね。
ワオ、本当に遅いですね。とにかく、これは遅いだけでなく、Perplexityほど優れてはいません。そこで使うべきなのが、私が最適化したこのプロンプトです。これは一段落の検索クエリで、Perplexityへの指示方法を伝えます。
通常、AIモデルはGoogleを使うように問題を形成してしまいます。信じられないかもしれませんが、AIモデルでさえAIモデルの使い方を知らないのです。「あなたの仕事は、人間の研究者に何を探すべきか伝えるように、関連するすべてのコンテキストを含めて1段落の検索クエリを書くことです」と伝える必要があります。
「研究者が探すべきものを明確な指示として段落を形成し、関連する場合はコードスニペットや技術的な詳細を要求してください」と指示すると、この指示を書いてくれます。これをPerplexityやChatGPTに貼り付けることができます。これらはCursorよりも優れたウェブ検索機能を持っており、最新のドキュメントを見つけたり、エラーで行き詰まった時に解決策を探したりするのに役立ちます。
web検索をしたい時は、「このエラーがあります」と言って、このプロンプトを貼り付けます。結果として出てきた段落をPerplexityに貼り付け、ChatGPTにも貼り付けて、両方の結果をコピーしてCursorに戻します。魔法のように機能します。
このプロンプトは本当に美しい作品です。まさにプロンプトエンジニアリングの完成形です。実は今日の早い時間に、vectalに新機能を追加している時に発見したものです。
ところで、まだvectalを使っていない方、何をしているのですか？これは生産性の未来です。実際、OpenAIが私を事業から追い出そうとしています。彼らはちょうどCGBD tasksを発表しました。これは私が過去3、4ヶ月間話してきたことそのものです。
AIパワーの生産性ツールが登場し、バックグラウンドでAIエージェントが動作する – これが実現すると言ってきました。人々は「ああ、デイビッド、それはただのTo-Doリストだよ」と言っていましたが、今やOpenAIがそれを追加しているということは、私が正しかったことを明確に証明しています。
これはまさにダビデ対ゴリアトのような状況です。私は単独の開発者で、文字通り最初の開発者を採用しようとしているところです。そして1,800億ドルの企業が同じことをしようとしています。
繰り返しますが、まだvectalを使っていないなら、vectal.aiにアクセスしてください。明日、私はノードと呼ばれる新機能を追加します。これによりタスク以外でもvectalを使用できるようになります。タスクではないもの、例えばノート、リマインダー、アイデア、ランダムな考えなど、書き留めたいものすべてをvectalで使用できるようになります。
とにかく、これは今日早くvectalのAIエージェントの1つを構築している時に発見したプロンプトです。先ほど説明した、AIモデルが自信を持って始めると終わりという問題に対処するものです。すでに一つの解決策にコミットしてしまうと客観的になれません。
これは本当に美しく表現されています。推論パラグラフは多くの不確実性を持って始め、項目についてより深く考えるにつれて徐々に確信を得ていくべきだというものです。
これを使う場面の一つは、AIエージェントを構築していて、システムプロンプトを持ちたい場合です。システムプロンプトで良いことは、AIモデルに最初に推論させることです。
例えばJSONを出力させたい場合、フィールドを直接指定するのではなく、最初に「reasoning」という追加フィールドを設定し、このプロンプトを含めます。そうすることで、AIモデルは実行する前に考えることを強制されます。信じてください、これは信頼性とパフォーマンスを大きく向上させます。
これらは私が日常的に使用しているプロンプトテクニックのほんの一部です。プロンプトエンジニアリングを本当に習得したい場合は、new Societyの上級プロンプトエンジニアリングワークショップがあります。教室の上級AIチュートリアルの下に、プロンプトエンジニアリングについて知っておくべきことをすべて教える8つの専用モジュールがあります。
さらにCursorについて学びたい場合は、Cursorの使い方、他の人の使い方、ヒントやコツ、よくある間違いなど、必要なものすべてについて200近い投稿があります。ぜひnew Societyに参加してください。リンクは下にあります。
実際に構築する際のプロンプトの構造について説明します。状況によって変わる可能性はありますが、ほとんどの場合これで上手くいきます。
まず、2〜4文で何をしているのかを説明します。次に関連するファイルにタグを付けます。これは非常に重要です。タグを付けないと抽出されてしまいます。
また、長いコンポーザーを構築している場合、上部のファイルが参照すべきものとは限りません。基本的に、この操作に直接関係のないファイルは参照しないでください。
次に、実行方法と避けるべきことを説明します。シニア開発者のように考えるとか、その関数だけを変更して他には触れないでといった指示です。
次はコンテキストのダンプです。ここには、例えばウェブからのドキュメントや、知っておくべきその他の情報を含めます。生のまま、すべてを含めてください。
プロンプトエンジニアリングの観点では、これら4つの「デリミタ」と呼ばれるものを使用します。これはOpenAIの共同創設者であるGreg Brockmanの講演から学びました。
これによりLLMは「ここで区切りがある」と認識し、次に来るものにより注意を払います。前に来たものとは分離されているという合図です。
ここでコア指示を繰り返します。これは基本的にこれと同じです。プロンプトエンジニアリングの最良の方法の一つは、最も重要なことを繰り返すことです。
長いコンテキストのダンプを行うと、しばしば忘れられてしまいます。最後のものが非常に重要なので、ここでコア指示を繰り返します。
その後、出力フォーマットを指定します。「簡潔に答えて」や「コードは書かずに簡潔に答えて」、あるいは「非常に詳細に、多くのコメントを含めて」など、使用例に応じて指定します。
このプロンプトフォーマットは、ほとんどの状況で十分に機能します。
特殊なMDファイルの作成について、これはデータベースのセットアップなどで非常に重要です。私のフォルダ構造を見てください。バックエンドとフロントエンドがあります。
コードベースが十分に長くなったら、これらを分割すべきです。もちろん、どのファイルが添付されているかは重要です。プロジェクトが十分に大きくなれば、バックエンドとフロントエンドで別々のcursorワークフローを持つべきです。
最初からではありませんが、必ず持つべきなのは、instructionsやpromsといったフォルダで、そこに特殊なMDファイル（マークダウンファイル）を置きます。例えば、superbase.MDやどんなデータベースでも、database-setup.MDとして名付けることができます。
ここにはすべてを含めます。テーブル構造、テーブルの数、IRSポリシー、どのフィールドがあるか、どのフィールドが必須か、デフォルト値は何か、どのフィールドがnullable可能か、テーブル作成に使用するSQLクエリなど、データベースに関連する絶対に知っておくべきことをすべて含めます。
データベースに関連する作業をする時は常に、このファイルにタグを付けることができます。例えば、ここに行って「superbase.MD」とタグを付けると、この場合は新しいSonet 3.5ですが、LLMは必要なことをすべて知ることができます。
適切に文書化されたファイルにタグを付けたからです。基本的に、各パーツの内部文書のようなものです。これはデータベースでは必須です。
また、デザイン原則、つまりフロントエンドのUIとUXの原則なども同様です。基本的に、単一のプロンプトではなく、ファイル全体が必要な、繰り返し参照する必要のあるものはすべて、MDファイルを作成し、必要な時にタグ付けして参照できるようにします。
次のステップは、話すことと入力することについてです。多くの人は入力が非常に遅いです。個人的には上位0.5%で、1分間に120単語ほど入力できますが、それでも話すよりは遅いです。
絶対に入手すべきなのはwhisper flowです。これは無料のAIツールで、実はプロバージョンも無料です。どういう仕組みなのかは正確には分かりませんが、これで話すことができます。
これは間違っています。計算方法は分かりませんが、明らかに間違っています。話す時は少なくとも1分間に200単語、おそらく250単語くらいは話せます。今やってみることもできます。
今それを有効にして、プロンプトを話すことができます。例えば「okay、AIエージェントのPythonファイルを更新して、anthropic APIを呼び出し、それからopen APIに行って、AIエージェントが出力したJsonを渡して、専用のJsonファイルに保存する必要があります」といった具合です。
これほど速く入力することはできません。このツールを使えば、これを送信できます。多くのコンテキストをダンプしたい時には非常に便利です。
もちろん、まだ入力したい場合や、例えば公共の場で話せない場合もあるでしょう。それはそれで問題ありません。しかし、すべての指示を出したい時や、複雑なアイデアがたくさんあって、他のファイルに関連していて、できるだけ速く頭の中から出したい時は、flow voice、別名whisper flowと呼ばれるこのツールは非常に重要です。
これも動画の下にリンクを貼っておきます。世界最速のタイピストの一人で、1分間に200単語入力できる人でない限り（もしそうなら素晴らしいですね）、私たちのほとんどは話すスピードほど速く入力することはできません。
このツールは絶対に入手すべきです。コメントを書くことは明らかに重要で、初心者のプログラマーでもそれは知っています。しかし、CursorのようなAIツールで作業する際のコメントは、ますます重要になってきています。
その理由は、人間が書くコードが少なくなってきているからです。例えばここを見てください。ionファイルを開いてみましょう。この関数が何をするのかを説明する2行のコメントを追加することは非常に重要です。
特に、コードベースが複雑になればなるほど重要です。なぜなら、将来的にはコーディングの100%がAIによって行われ、私たちは関連するファイルにタグを付けるだけになるからです。
データベースの文書化と同じアイデアで、ファイルに十分なコメントがあり、このファイルの目的、存在理由、他のどのファイルが参照しているか、関数をどのように使用すべきか、その背後にあるビジョン、どの関数が最もよく使用されているかなどを説明していれば、想像もできないほど役立ちます。
もちろん、コメントに無関係で無用な情報を入れてはいけません。それはAIエージェントを混乱させるだけです。しかし、あなたが書いているコメントの量は、おそらく十分ではありません。
真剣に、コード3〜4行に対して1行のコメントを書くべきです。これくらいを目指すべきです。このように、緑色の部分が20〜30%、場合によっては40%くらいになるようにします。
もちろん、複雑さによって変わります。プレーンテキストで明白な説明やプロンプトがある場合は、コメントを追加する必要はありません。しかし、ほとんどのコードには、もっと多くのコメントを追加すべきです。これは将来を見据えた考え方です。現時点では重要に見えないかもしれませんが、将来的には、AIモデルがファイルを見て、コードベース内での関連性をどれだけ早く理解できるかが重要になります。
大量のコメントを追加し、AIに思考プロセスをコメントで説明させ、明白でない部分をすべてコメントで説明させることで、それを達成できます。信じてください。これは長期的な取り組みで、今後1〜2年で大きな違いを生むでしょう。
今すぐには見返りがないかもしれませんが、今からこれを始めれば、コーディングを完全に担当する、より高度なAIが登場した時に、その価値が分かるはずです。
技術的負債は何としても避けてください。これは馬鹿げて聞こえるかもしれません。「もちろんデイビッド、技術的負債は避けたいよ」と。しかし、理解していないのは、結局のところAIは完璧ではないということです。
2、3年後には完璧になるかもしれませんが、現時点では完璧ではありません。そのため、創業者や開発者であるあなたは、まだ多くのことを学ぶ必要があります。
これは多くの初心者が犯す間違いの一つです。すべてをAIに任せて、学ぶことを拒否します。これは最悪のマインドセットの一つです。AIが大部分のコーディングを行っていても、必ず学び続けるようにしてください。
あなたのスキルレベルがボトルネックになります。例えば、あなたのスキルレベルがこのくらいだとすると、AIはここまでできるかもしれません。スキルレベルをここまで上げると、AIは突然ここまでできるようになります。
なぜなら、ファイルがどのように関連しているかを理解でき、何かを承認する前に「これは問題があり、将来的にエラーや問題が発生するだろう」と気付くことができるからです。
AIからどれだけ多くを引き出せるかは、本質的にあなたの能力によって制限されます。そのため、コードの理解力、抽象化能力、論理的思考力を絶対に向上させるよう努めるべきです。
そのため、技術的負債を避け、代わりにより多くを学び、理解できるものだけを実装するようにすべきです。突然AIに5つの新しいファイルを作成させ、それぞれが200〜300行のコードで、その内容を何も理解していないとしたら、意味のあるものを構築するのは困難でしょう。
エラーで何日も行き詰まり、何が起きているのか分からず、どこに問題があるのかも分からず、正しい方向に進むための手がかりさえ分からないでしょう。なぜか？それはあなた自身のスキルレベルに焦点を当てず、自身を向上させていなかったからです。
AIは素晴らしいツールですが、単一の機能を実装することは得意でも、特に独自のスタートアップを立ち上げ、一般公開し、フロントエンド、バックエンド、データベースなどすべてを備えた消費者向けアプリを持ちたい場合、製品のビジョンを持つことは得意ではありません。
技術的負債を避けないと、自分の足を撃ち、場合によっては頭も撃つことになるでしょう。
では、CursorではなくCLAを使うべき時はいつでしょうか？個人的には、両方を非常に異なる目的で使用しています。Claudeはプロジェクトのアドバイザー、シニアコンサルタントとして使用します。
ここで「この機能を追加すべきか？」「どのように追加すべきか？」「どんな感じになるか？」「次のステップは何か？」といったブレインストーミングをします。
一方、Cursorでは実際にそれを実装します。Cursorだけを使いたい場合は、もちろんチャットでそれらの目的に使用できます。
問題は、大量のコードを読み込み始めると、それも過負荷になる可能性があることです。また、CLAに専用のプロジェクトを持つのも良いことです。
ここにvectlがありますが、これは私のcursor rulesとよく似ています。すべてを知っており、Cursorとは完全に分離されています。「タグを付けすぎていないか」「これは一部のファイルの影響を受けているか」といった心配をする必要がありません。
これを完全に分離して、より偏りのない、現在のコードの影響を受けにくい状態にし、本当に必要なファイルだけを与えることができます。
Cursorをプログラマーとして使い、CLAをアドバイザー、コンサルタントとして使用する – これが私にとって最も効果的なセットアップです。
ファイルの一番上に名前を付けること – これは超シンプルですが、必要です。例えばここで、ファイル名を一番上に付けます。これもAIのためです。将来を見据える必要があります。コーディングはAIによって変化しており、将来的にはAIエージェント、AIモデルがすべてのコーディングを行うようになります。
ファイルの一番上に名前を付け、特に場所を示すことで – 例えばここでは、AI agent、つまりbackend/sl/agent.pyとすべきでした。
4つの異なるフォルダ構造があるとします。backend/sl、survey/sl、その他、そしてファイルがあります。フロントエンドではさらに重要で、app/utils/sl/off/page.tsxのようになります。
特にNode.jsやNext.jsを使用している場合、page.tsxファイルがたくさんある可能性があります。ファイルの正確な場所を、どのフォルダに入っているかを含めて記載することで、ファイルにタグを付ける時に常にAIがそれを知ることができます。
特にCLAにコピー＆ペーストする場合、Cursorが持っている知識をCLAは持っていません。Cursorならその場所を知っているかもしれませんが、CLAは知りません。
これはシンプルな習慣ですが、各ファイルの正確な場所をコメントとして一番上に記載することは、害になることは決してなく、利点しかありません。
新しいコンポーザーを作成する時期については既に話しました。チャットをいつ使用するかについて、これは好みの問題ですが、Cursorはかなりシンプルにしています。
何かを質問する必要がある時はチャットを使用し、変更を加えたい時はコンポーザーを使用します。例えば「フロントエンドで使用しているフォントは何？すべてのフォントをリストアップして」や「このコンポーネントで参照している正確な色は何？すべてリストアップして」といった場合です。
これらはチャットで行うべきです。コンポーザーは複雑な変更に使用し、特にエージェントモードでは、より多くのことができます。
エージェントモードでは、「ツールを使用し、ターミナルコマンドを実行し、ファイルを編集できる」と書かれているように、さらに多くの時間を節約できます。
複数のファイルに関わる大きな変更がある場合、通常はお勧めしませんが、時には「やってみよう」と試してみることもあります。成功する可能性は5%くらいかもしれませんが、成功すれば数時間を節約できます。
失敗しても大したことはありません。パーツに分割して一つずつ進めればいいだけです。基本的に、常にエージェントを使用してください。
通常モードの方が予測可能かもしれませんが、エージェントを使用しない利点は特に見当たりません。エージェントを使用することを強くお勧めします。
ほとんどの場合、コンポーザーとエージェントにとどまり、相談が必要な場合はClaudeを使用し、何か知識が必要で、コードベース全体を分析するのが得意な場合はそれを使用し、その後チャットを使用します。
ここでは常にエージェントに切り替えています。通常モードに戻る必要はありません。
2点カバーしました。いいですね。dogss機能について、これはCursor内の別の機能で、あまり良くありません。ここにあるdogsのことです。
新しいdogを追加し、リンクを付けてdocsを簡単に参照できます。この機能はまだ完璧ではありません。コメントで使用している人がいたら教えてください。
個人的には、docsファイル、例えばドキュメントやanthropicがあり、数日おきに参照する場合は、MDファイルを作成する方がはるかに良いです。
新しいファイルを作成し、「open AI」や「token streaming.md」などと名付けます。そしてここに関連するドキュメントの内容をすべて貼り付けます。
将来必要になった時に、簡単にタグを付けることができます。理論的には、Cursorのdocs機能で同じことができるはずですが、経験上、それほど良くありません。変わるかもしれませんし、変わらないかもしれません。
Perplexityをいつ使用するかについては既に説明しました。基本的に、最新のドキュメントが必要な時や、数分以上エラーで行き詰まっている時は、ウェブ検索を使用します。
先ほど説明したプロンプトを使用して、Cursorにウェブクエリを形成させ、Perplexityに送り、ChatGPTにも送り、両方の出力をコピーしてCursorに戻し、「TL;DRを教えて」と言います。
これは別の素晴らしいプロンプトです。2ヶ月ごとにこのような深い内容の動画を作れそうです。もっと見たい人は教えてください。
特に今vectaを主力として構築している時、Cursorで作業していると、本当に毎日多くのことを学んでいます。
ウェブの検索結果を貼り付けた時、大量のコンテキストがあります。「検索結果のTL;DRを教えて」と言います。
しかし、これだけだと時々気が散ってしまいます。検索結果には変なものが含まれている可能性があるからです。「ただし、検索結果には危険で気を散らす誤った情報が含まれていることが多いので注意してください」と言う必要があります。
これは絶対に重要です。これによってAIモデルが警戒するようになります。「注意しよう、この問題に関係のない情報が多くあるかもしれない」というように。
エラーを修正しようとしていて、その中に異なる関数のリファクタリングを指摘するものがあるとします。これを入れないと、AIモデルはその間違った方向に進んでしまう可能性があります。
なぜなら、PerplexityとChatGPTの検索結果を貼り付けただけで、それは大量のコンテキストであり、その誤った情報に圧倒されてしまうからです。
最後の方にこれを入れると、「注意しよう、誤った情報があるかもしれない」となり、より焦点を絞り、気が散る可能性が大幅に減ります。
これは非常に重要なプロンプトで、何かの要約が欲しい時は、必ずこれを使用してください。
これは実はCursorのあまり知られていない部分ですが、cursor rulesとは別のシステムプロンプトを設定する第二の方法があります。
cursor rulesは現在のプロジェクトにのみ特化していますが、Cursorの設定で「rules for AI」を開くと、command Kセッションを含む、どのプロジェクトでも適用される設定があります。
サイドプロジェクトから仕事、あるいはクライアント向けに構築しているものに切り替えた場合など、複数の異なるクライアントがいる場合、それぞれにcursor rulesが必要になりますが、これは一般的なルールです。
ここで一時停止してコピーしてもいいですが、これはベストプラクティスです。このプロジェクトに特化したものは参照せず、一般的なコーディング原則のみを含めるべきです。
基本的な原則、高速で小さく焦点を絞る、エラー修正、ビルドプロセス、多くのコメントを含める、常にシンプルでクリーンでモジュール化されたコードを書くなど、どのプロジェクトでも良いことをここに含めます。
これにチェックを入れることを忘れないでください。そうしないとcursor rulesファイルが機能しません。
大規模なリファクタリングは避けてください。これは当たり前かもしれませんが、4つの異なるファイルに関わるリファクタリングがあるとします。一度にやろうとするかもしれません。一か八かでやってみて、うまくいくかどうか見てみるのもいいでしょう。
しかし、適切に行いたい場合で、大きな変更になりそうだと感じたら、一度にその変更を行うのではなく、「必要なステップに分解してください」と言いましょう。
もう一つ必ず使うべきプロンプトは、「本当に必要なステップだけを含めてください」です。このプロンプトを追加しないと、オプションとして良いものや、エラー処理の詳細、フォーマット、パース、デバッグなど、必要でない可能性のあるものを多く追加してしまいます。
「本当に必要なステップだけを含めてください」と言うのは非常に重要です。
大規模なリファクタリングを4、5つのステップに分解すれば、それだけで魔法のような効果があります。各ステップを一つずつ処理し、「ステップ1が実行されました、良さそうですね」と言えます。
テストすることもできます。これは素晴らしいことです。テストして良ければ、GitHubにプッシュしてコミットできます。突然、大規模なリファクタリングの20%が完了します。
しかし、大規模なリファクタリングを一度に行おうとして、最後の方で問題が発生したり、完了はしたものの、テストすると動作せず、なぜ動作しないのか分からない場合、すべてやり直さなければなりません。
ステップに分解して、継続的に進歩を積み重ねていく方がはるかに良いです。
roadmap.MDについて、これは指示フォルダに持つべき別のマークダウンファイルです。新しいファイルとしてroadmap.MDを作成し、ここに開発ロードマップを含めます。
現在何に焦点を当てているか、次のステップは何か、将来的に行いたい他のことなどを入力し、より多くのコンテキストがある時は追加します。「Xを試したけど上手くいかなかった」といった具合です。
これは、スタートアップや会社、プロジェクトがどのような状態にあるのか参照する必要がある時に役立ちます。必ずしもコードに関連することではなく、何が起きているのか、例えばクライアントからプレッシャーがかかっているとか、この機能が壊れたとか、バックエンドに重大なエラーがあるとか、そういったことをここに記載します。
そうすることで、AIはあなたが持っているコンテキストをすべて持つことになります。これらのプロンプト、コメント、指示で試みているのは、基本的に私たちの頭の中にあるコンテキストとCursorを同期させることです。
より良く同期できれば、Cursorはより良く機能します。AIの使用に問題がある場合や、「AIでのコーディングは価値がない、機能しない、それほど良くない」と思っているなら、それはあなたのプロンプトが悪いからです。
十分なコンテキストを与えていないか、間違ったコンテキストを与えているのです。間違ったコンテキストを与えると、気が散ってしまうだけです。頭の中の内容とより良く同期できれば、より良く機能します。
特に2025年、O3、O3 mini、CLA 4が登場するにつれ、これはますます重要になります。今からこれらのベストプラクティスを始めれば、他の人の2〜3倍生産的になれます。
これは誇張ではありません。なぜなら、将来的には人間がコードに触れることさえ許されなくなるからです。文字通り、CursorのようなIDEがあり、コードベースに入ろうとすると「人間さん、本当にいいの？これはAIの仕事だよ、複雑なものだよ、コードベースに触れて本当にいいの？何か壊してしまうかもしれないよ、O3に任せた方がいいんじゃない？」となるでしょう。
今からこれらのベストプラクティスを始め、roadmap.MDファイルを含めて、スタートアップの全般的な状況や、現在の焦点、次の焦点は何かを記録しましょう。そうすることで、AIはあなたと同じページにいることができます。
モデルの知識のカットオフについて、多くの人はこれを知っていますが、モデルと作業する時に内在化していません。忘れやすいですが、すべてのモデルには本質的に知識のカットオフがあります。
ツールを使用してウェブにアクセスすることはできますが、ChatGPT、Perplexity、CLAなどのモデルを使用し、Perplexityを使用して、例えばモデルとしてCLAを使用する場合でも、モデル自体はウェブを閲覧できません。それは外部ツール、Google検索のようなものです。
Cursor内のCLAも、ADD web機能を使用しない限り（使用して実験することはできますが、個人的にはPerplexityの方が良いと思います）、これらのモデルはウェブアクセスを持っていません。
そのため、「最新のドキュメントを使用しましょう」と言うのは大きな間違いです。最新のドキュメントが何か知らないからです。Pythonやnext.jsの最新バージョンが何か知りません。
なぜなら、特定の知識のカットオフがあるからです。「あなたの知識のカットオフはいつですか？簡潔に答えてください」と聞くことができます。そのカットオフ以降に起こったことは、単に知らないのです。
これはAI分野では18年分に相当する18ヶ月前で、これは terrible（ひどい）ことです。特に最新の状態を保つ必要があるものや、新しいAIツールに関連するエラーがある場合には注意が必要です。
例えばdeep seekについて知っていますか？これについて知っているなら驚きです。私たちが考えていること、知っていることの多くについて…
なるほど、いくつかのことは知っているようですね。その場合、early 2024について嘘をついたことになります。2024年初頭のことをどうやって知っているのでしょう？
はい、これは奇妙です。非常に奇妙です。CLA sonは恐らく2024年4月くらいだと思いますが、なぜ6月と言ったのかは分かりません。
言うことさえ信用できませんが、それが私の指摘したいポイントです。ドキュメントを確認してください。文字通り何時間もの苦痛を避けることができます。
例えばsuperbaseやデータベースを使用している場合、確認するだけでいいのです。私自身がこの間違いを犯したから言っているのです。
私の動画「AI起業家の1週間」を見れば分かりますが、AIを信頼しすぎて、その問題で丸1日行き詰まってしまいました。その代わりにsuperbaseのドキュメントを確認すべきでした。
これはコーディングのベストプラクティスですが、AIではさらに重要です。なぜなら、AIを信頼したくなるからです。非常に自信を持って話すので、それが問題です。
AIモデルが自信を持っていても関係ないということを理解する必要があります。人々はこれを「幻覚」と呼びますが、多くの場合、それは単に不適切なプロンプトやユーザーの無知によるものです。
とにかく、ドキュメントを頻繁に確認し、特に最新の状態を保つ必要があり、頻繁に変更される何かに取り組んでいる場合は、AIモデルを完全には信頼しないようにしてください。
次に、AIに何をすべきか教えてもらうことは必須です。例えば、現在私はフロントエンドについて非常に新しく、フロントエンドのデバッグの仕方さえよく分かりません。
もちろんF12を押してChrome開発者ツールを開くことはできますが、何を探せばいいのかさえ正確には分かりません。
そのため、AIに何をすべきか教えてもらいます。AIは実はこれが得意です。エラーについて説明し、「Chrome webツールを使ってデバッグしたいです」や、バックエンドの場合は「ターミナル、Postman、curlなどを使ってデバッグしたいです」と言います。
経験レベルについて正直になることを忘れないでください。「バックエンドについては初心者で、fast APIのデバッグをしたことがありません。何をすべきか教えてください」と伝えれば、必要な情報をAIに与えられるよう、明確な指示を出してくれます。
これは一つの抽象化レイヤーです。知っていることを伝えるだけでは、より複雑なエラーの場合は十分ではありません。エラーが非常に単純な場合は、知っていることを説明するだけで解決できるかもしれません。
しかし、エラーが非常に複雑で、それが分かっている場合、かなり困ったことになります。そのため、AIに「これは知っているけど、十分ではありません。もっと情報を与えられるよう、Chrome web開発者ツールを使ってデバッグしましょう。どうやったらもっと情報を与えられますか？」と言うべきです。
それを与えて、もう一度試してみても足りない場合は、また試します。そして突然、より多くのコンテキストを追加していくうちに、エラーが修正されます。
AIに指示を与えてもらいましょう。「どのようなテストを実行すれば、関連するコンテキストを与えられますか？」「このプロジェクトのシニアソフトウェア開発者だったら、このエラーを解決するためにどのようなコンテキストが必要ですか？そのコンテキストを与えられるよう、ステップバイステップの指示を教えてください」
これは魔法のように機能します。特に非常に複雑なエラーに遭遇した場合や、既に知っていることを伝えるだけでは不十分な複雑な機能に取り組む場合に効果的です。
新機能をどのように追加すべきか、MVPアプローチについて。これは主にスタートアップを構築し、何百時間も費やして学んだことですが、新機能を追加したい時は、完璧にしたくなる誘惑が非常に強いものです。
私たち全員がそうです。完璧なアプリを想像して座っているのは簡単です。vealをより良くするために追加すべきことを100個簡単に考えつくことができます。
しかし、それは難しい部分ではありません。実装することの方が難しく、さらに難しいのは、正しいことに取り組むことです。
これがイーロン・マスクを非常に効果的にしている理由です。彼は自分のビジネスの真のボトルネックが何かを特定し、それに専念して取り組むことができます。
それが解決されると、再評価して「次のボトルネックは何か」を考えます。彼の場合は別の会社に移るかもしれませんが、あなたは複数の会社を持つべきではありません。
気が散るべきではないし、あなたはイーロン・マスクではありません。一つのメインプロジェクトを持ち、それに取り組むべきです。
この新機能のMVPは何かを特定すること、つまり先ほど言ったように、私はvectalにノードを追加していますが、その完璧な実装を考えるのは非常に簡単です。
ちなみに、これは明日実装される予定なので、vectalユーザーの方は楽しみにしていてください。しかし、より難しいのは「MVPは何か、どの機能が80/20の法則を実現できるか」を考えることです。
つまり、20%の労力で80%の成果を得られる機能は何か、この機能の最小限の実用的な製品は何かということです。なぜなら、機能のほとんどの部分は必要ないからです。
これは最初の段階では非常に見分けにくいので、2段階で行う必要があります。最初の段階は、機能についてブレインストーミングを始める時です。
文字通り、その機能に欲しいものすべてをブレインダンプします。vectalの場合がどのようなものだったか見せることもできます。
ブレインストーミングの後のMVPがこのようになりました。驚くべきことに、これさえも削減することにしました。MVPに必要なのはこれだけでした。
恐らくこの5倍くらいのアイデアがありましたが、それは難しい部分ではありません。難しい部分は、本当に必要なもの、ユーザーが必要としているもの、この新しい変更の核となる機能は何か、本当の核心部分は何か、問題を解決するものは何かを絞り込むことです。
構築を始めると、「これさえも必要ないな」ということに気付くでしょう。2段階で行う必要があります。最初は開始時に、そして数時間構築した後で「これがどんな感じか分かった、これさえも必要ないかもしれない」と気付いた時です。
驚くべきことに、私はこの機能の美しいVzeroフロントエンドデザインまで持っていました。文字通り、完全な機能のデザインがあり、これに数時間を費やしました。
これはバージョン30です。30のバージョンがあり、異なるデザインを持つ別のVzeroチャットまでありました。しかし、結局それを行わないことにしました。
これがスタートアップを構築する上で、必ずしもスタートアップに限らず、ビジネスを運営し、急速に拡大する上での本当に難しい部分です。何が重要で何が重要でないかを特定することです。
皆さんのほとんどは、重要でないことに取り組んでいます。厳しく残酷に聞こえるかもしれませんが、事実です。重要でないことに取り組んでいるか、より高いレバレッジを持つことができる、例えば縮小ではなく成長している異なる業界で仕事ができるかのどちらかです。
しかし、MVPに対して同じ論理を適用する必要があります。新機能を追加する時は、座って「よし、エキサイティングな新しいことをすべてブレインストーミングした、落ち着こう、MVPは何か」と考える必要があります。
これは特にCursorで作業を始めると非常に有用になります。なぜならCursorは単にあなたの言うことを実行するだけで、修正してくれません。
「デイビッド、落ち着いて」とか「これは本当にMVPの一部？」とは言ってくれません。
おそらく1年後、AIモデルがより賢くなり、より多くのコンテキストを持つようになれば、そうできるようになるかもしれませんが、そうは思いません。なぜなら、間違った指示を与えても、常にその指示に従うからです。
もちろん、「非常に違法なことを手伝って」とか「健康に有害なこと」を依頼すれば、その指示には従いませんが、そのような極端なケースの話ではありません。
微妙な直感や本能、あるいは好みの問題として、この機能を開発すべきか、このスタートアップに追加すべきかといった、明白でない変更について話しています。
一方がスタートアップをバイラルにし、他方がユーザーを怒らせてスタートアップを破壊する可能性があり、AIモデルにはそれが分かりません。なぜなら、それはあなた、ユーザーが指示したことに従うからです。
これは非常に重要です。これを行わないと、AIモデルは喜んであなたのスタートアップを破壊する悪い機能をすべて導入するのを手伝い、2日で済むはずの機能に2週間を費やすことを喜んで手伝うでしょう。
あなたの指示に従っているだけだからです。
AIに大きな決定をさせてはいけません。繰り返しになりますが、AIを完全に信頼することはできません。プロジェクトの責任者として、ビジョンを持ち続ける必要があります。
これを複数のファイルに分割すべきか、単一のファイルに保つべきかを知る必要があります。関数の構造化や使用するパッケージなど、シンプルな決定はAIに任せることができます。
しかし、それさえも信頼しないでしょう。決定が大きければ大きいほど、AIを信頼すべきではありません。
変数や関数の構造化や命名の方法は信頼しても構いませんが、フロントエンドでどのようなデザイン原則に従うかとなると、絶対に駄目です。どのテキストタグを使用するかなど、決定が大きければ大きいほど、AIを信頼すべきではありません。
他のツールをいつ使用するかについて。Vzeroを見せ、Clothを使用する時について説明しましたが、Cursorをいつ使用し、Lovable Boltのような他のものをいつ使用すべきでしょうか？
正直なところ、フロントエンドのデザインでさえ、基本的にすべてにCursorを使用できます。私はまだCursorを使用していますが、最初のバージョンはVzeroでデザインしています。
これが少なくとも私が見つけた最良の原則です。Clothの使い方とそれをいつ使用するかについては既に説明しました。
しかし、Lovable BoltやLavableのような他のツールについて言えば、実際にはバックエンドデータベースの最初のバージョンをデザインするのに使用するでしょう。
superbaseの経験がない場合、Lavableはsuperbaseと素晴らしい統合を持っています。彼らのやったことは本当に印象的です。
しかし繰り返しになりますが、何が起きているのかを理解する必要があります。AIにsuperbase DBをデザインさせて、どのテーブルがあるのか、どのアレスポリシーがあるのか、テーブルにどのような列があるのかまったく分からないままでは、何か印象的なものを非常に速く構築できるかもしれませんが、多くの痛みに遭遇し、行き詰まり、結局諦めてしまうでしょう。
これが残酷な真実です。何が起きているのか理解せずにAIを実行させると、非常に多くの技術的負債を蓄積することになり、遅かれ早かれ諦めることになります。
使用するどのツールでも、何が起きているのかを理解していることを確認する必要があります。これが、本当に速く素晴らしいMVPを提供できる、これらの超クラックツールの危険な点です。
確かに、BoltとCursorを3、4回使用すれば、クライアントに送って感動させられる、かなりしっかりしたウェブサイトを持つことができます。
しかし、クライアントが細部について、手を汚してバックエンドに入り、実際にBoltからCursorに移行して自分で何かをする必要のあるカスタマイズを要求し始めると…そうなった時の良い運を祈ります。
正直なところ、CursorとCLAの使用にとどめることをお勧めします。最初のデザインにはVzeroを使用しても構いませんが、デザインに満足したら、できるだけ早くCursorに移行するよう努めてください。
機能を構築しないでください。できるだけ早くコードベースと接続してください。技術的負債が蓄積されていることを示す内部レーダーを開発する必要があります。
技術的負債が蓄積されている時は、パニックになるべきです。「ああ、何が起きているのか本当に分からない」という大きな赤い警報です。それは危険な領域です。
AIに何が起きているのかを説明させ、「一時停止して、これを止め、Cursorと統合し、現在のコードで機能することを確認し、多くのテストを実行して、技術的負債を減らし、何が起きているのかを理解し、機能したらGitHubにプッシュし、その後でより多くのものを追加できる」と言うべきです。
これはより感覚的なもの、内部レーダーのようなもので、開発する必要がありますが、これらの他のツールでは非常に速く多くの技術的負債を蓄積する可能性があります。
そのため危険なのです。Curs ignoreについては既に触れました。
以上です。これが1本の動画に詰め込まれた400時間以上のCursorレッスンでした。
価値があると感じたなら、ぜひチャンネル登録をお願いします。そしてもう一度言いますが、vector.aiにアクセスしてください。これは生産性の未来です。
これは実際に時間を節約する、世界初のAIパワーの生産性アプリです。文字通り2日おきに改善され、左右に更新をプッシュしています。
また開発者も採用中なので、開発者が加わればアップデートの量はさらに加速するだけです。
もし何か大きなものの始まりに立ち会いたい、最初期のユーザーの一人になりたいと思うなら、ぜひ試してみてください。後悔することはないと約束します。
以上です。ご視聴ありがとうございました。素晴らしく生産的な一週間をお過ごしください。では。
コメント