あと3ヶ月でテックブログ毎週更新も2年連続達成です！
はじめに
こんにちはログラスのエンジニアの @Yuiiitoto です。
みなさんはCursor使っていますか？
そしてCursorのルールをどのように改善していますか？
作りっぱなしになっていないですか？
そんなあなたに今回は 「ファイル復元トレーニング」 というルールについてのトレーニング方法をご紹介します。名前は自分が適当につけていますが、おそらく自分と同じことをやっている人は他にもいそうです。いたら連絡ください。
まずは手っ取り早くトレーニング方法を紹介します。その後はどういう観点で評価するのかなどにも触れます。
ファイル復元トレーニング
大仰な名前をつけていますが、非常に簡単です。
既存のファイルを消して、そのファイルをCursorに復元させるだけです。
その後、Cursorが復元したコードと元のファイルを見比べて、ルールをチューニングして再度ファイルをゼロから復元させます。この繰り返しをすることでルールを最適化させます。
詳しい手順
- 今回作りたいルールを考える（Repositoryの書き方、React Hookの書き方など）
- 1で考えたルールを守っているお手本ファイルを削除する。その変更をgitコミットする
- そのファイルを再作成するようにCursorに指示を出す（〇〇のReositoryを作って）
- 復元したファイルを削除したファイルと見比べてできていない差分をルールに書き足す。git diff で確認
- 2に戻り、以下繰り返し
非常に簡単ですね。ちなみにファイルの削除は自分の手で行ってください。
ファイルの削除をCursorがすると、削除したファイルがコンテキストに載ってしまいます。なるべくバイアスがかからないようにしてください。
また、再作成の指示は繰り返しの都度セッションが引き継がれないようにしてください。
削除ファイルは一度コミットしておくと、そのあとCursorが作ったファイルとgit diffで差分が見えるのでお勧めです。
このやり方の何が良いかというと リアルタイムにルールをチューニングできることです。
既存の（よくできた）コードはいわばCursorにとっては正解です。その正解を目隠しでCursorに再現させます。その差分を確認して徐々にゴールに近づけていきます。
どのようなルールが良いかはプロジェクトによって違うのですが、どのプロジェクトもそのプロジェクトの価値観で「良い」とされている正解に近いファイルを持っているのでそれを目印にルールを改善していこうというわけです。
ちなみにこのトレーニングは人間にはやらないでください。上司がいきなりファイル削除してきて、「このファイルを今から復元しろ！合格するまで諦めるな！」とか言われたら自分だったら泣きます。
どうルールを評価するか？
ファイル復元トレーニングで評価するポイントとしては3つあります。
- 望み通りにコードを生成しているか
- プロンプトにHowを含めずに指示できるか？
- 意図通りにルールがアタッチされているか
1. 望み通りにコードを生成しているか
1に関しては読んで字の如くなので割愛します。削除したファイルと復元したファイルはgitで差分を見ることができるので比較してみましょう。
2. プロンプトにHowを含めずに指示できるか？
次に、自分が指示したプロンプトにHowを含めずに思い通りの成果が出せるか評価してください。
Cursorルールの本質は「How（実装の詳細）の指示を省略し、プロンプトをWhat（やりたいこと）だけにすることができる」 だと思っています。
たとえば「△△のORMを使って、〇〇のRepositoryを作って」みたいなプロンプトの前半部分はHowで後半部分はWhatですね。「△△のORMを使って」の部分はプロジェクトで基本変わらないのでルールに書くべきということです。
ルールの書き方によっては△△を使ってくれなかったりするのでこのトレーニング方式で書き方をチューニングして書けるようにしましょう。
例を少し出すと「JooqのORMを使ってPostgresqlのDBに保存するような、Taskエンティティのリポジトリを作って。」みたいな「JooqのORMを使ってPostgresqlのDBに保存する」は完全にHowの話ですね。これをWhatだけの「Taskエンティティのリポジトリを作って」というプロンプトにするにはルールとしてどのようなHowが定義されているかによります。
人間に例えるとわかりやすいです。たとえば、入社3日目のエンジニアにはオンボーディングも兼ねて「どのORMを使って欲しい」とか細かく指示を出すかもしれませんが、熟練のエンジニアにはもっとアバウトな指示を出すかと思います。Cursorでもそれを目指していきたいですね。
3. 意図通りにルールがアタッチされているか？
最後はルールのアタッチに関してです。
Cursorのルールには色々なルールの参照の仕方があります。全てを常に参照してしまうとコンテキストが大きくなり、情報が抜け落ちたり、重要な情報がどれかわからなくなってしまいます。
逆に全てをマニュアルで参照させると、すべてのエンジニアがルール内容を正確に把握しておかないといけなくなり新入社員がキツくなります。
理想としてはルールの存在を意識せずに自動で参照される。かつコード生成に対して無駄のないルールが参照されることです。
ログラスでは general.mdcというすべてのプロンプトに自動で参照されるルールに 「必ず発言冒頭で使用中の全てのルールを宣言: ルールのファイル名, ...」 という文章を入れています。
これですべての応答でどのルールが呼ばれているかわかるようになります。色々試行錯誤してルールが綺麗に当たるか確認してください。
ちなみにこのやり方をしている時に意図せずいらないルールが参照されることもあります。その場合はそのルールのアタッチ方法を見直してください。
期待値調整。完璧を目指さない。
このやり方でも100%の成果物は現在（2025年6月時点）のLLMではできないことを理解してください。
このやり方で再現できる書き方はせいぜい肌感70%くらいで、どうしても30%は手直しが必要になります。そしてその30%のコードの修正は全体にかける時間のそのまま30%といきません。期待値を正しく持ち、優しさを持ってCursorと接しましょう。では！
書籍『Vibe Coding: The Future of Programming』のEarly Release版（2025年8月にO'Reillyから出版予定）には、AIは70%のコードを生成するには最高だが、残りの30%を完璧に生成するには多大な苦労が伴うという話が紹介されています。
This “70% problem” reveals something crucial about the current state of AI-assisted development. The initial progress feels magical - you can describe what you want, and AI tools like v0 or Bolt will generate a working prototype that looks impressive. But then reality sets in.
The 70% is often the straightforward, patterned part of the work – the kind of code that follows well-trod paths or common frameworks. As one Hacker News commenter observed, AI is superb at handling the “ accidental complexity” of software (the repetitive, mechanical stuff) while the “essential complexity” – understanding and managing the inherent complexity of a problem – remains on human shoulders. In Fred Brooks’ classic terms, AI tackles the incidental, but not the intrinsic, difficulties of development.
和訳)
この「70%問題」は、AI支援開発の現状について決定的な何かを明らかにしている。最初の進捗は魔法のように感じられる。作りたいものを説明すれば、v0やBoltのようなAIツールが見事な見た目の動作するプロトタイプを生成してくれる。しかし、その後現実が立ちはだかる。
その70%は、よくある定型的な作業、つまり、定石や共通のフレームワークに沿ったコードであることが多い。あるHacker Newsのコメント投稿者が指摘したように、AIはソフトウェアの「偶発的な複雑性」（反復的で機械的なもの）を扱うのが非常に得意である一方、「本質的な複雑性」—問題に内在する複雑性を理解し管理すること—は人間の肩にかかっている。フレデリック・ブルックスの古典的な言葉で言えば、AIは開発における付随的な困難には取り組むが、本質的な困難には取り組まない。```
と書いている通り、70%はいわゆるプロジェクトのお作法的な書き方 + 簡単なドメインの処理でカバーできます。
最後の30%は本質的な複雑性と言われる、立ち向かう課題に元から存在する複雑性を含んでいて、コード量としては最後の30%だが、そこを完璧に再現させることをAIに期待することはお勧めしません。
「まあ完璧は難しいよね。最後は一手間加えるよね。」とか、「そもそも人間にも難しいような複雑なものはAIが取り扱えるレベルまで自分で大枠を書いちゃうよね」くらいの期待値の方が現時点ではいいかもしれません。
宣伝
実は今度 Findyさん主催の AI Engineering Summitで登壇します！
本記事のトレーニングも含めたより体型的なCursorルールマネジメントについてお話するので今回の記事が面白いと思ったらぜひお越しくださいー！
Discussion