「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの 考え方・育て方 / Cursor Rules for Coding Styles, Domain Knowledges and Operations

Transcript

1. 「規約、知識、オペレーション」から考える 中規模以上の開発組織のCursorルールの 考え⽅‧育て⽅ 2025年6⽉18⽇ AI Engineering Summit 株式会社ログラス シニアソフトウェアエンジニア 佐藤有⽃ 1
2. ⾃⼰紹介 株式会社ログラス プロダクト開発部 シニアソフトウェアエンジニア 株式会社ログラスに2020年12⽉に⼊社。 2025年2⽉からログラスの全エンジニアに対してCursorの導⼊の リードを⾏ってきた。 得意分野は型と⾃動テストで技術情報誌やブログなどでよく発信を している。 佐藤 有⽃（ゆいと） @Yuiiitoto 2 n月刊ラムダノート Vol.4, No.3(2024) https://www.lambdanote.com/products/n-vol-4-no-3-2024
5. 5 今⽇話すこと 「規約、知識、オペレーション」から考える 中規模以上の開発組織のCursorルールの 考え⽅‧育て⽅
6. 6 今⽇話すこと 「規約、知識、オペレーション」から考える 中規模以上の開発組織のCursorルールの 考え⽅‧育て⽅ 数年以上、数⼗⼈で開発を続けているコードを持つ、AIネイティブではないプロダクトに対して
7. 7 今⽇話すこと 「規約、知識、オペレーション」から考える 中規模以上の開発組織のCursorルールの 考え⽅‧育て⽅ AIエージェントに⾃⾛してもらうためにCursorルールをどう⾔語化するか？
8. 8 今⽇話すこと 「規約、知識、オペレーション」から考える 中規模以上の開発組織のCursorルールの 考え⽅‧育て⽅ そのルールをどう育てていくか？どうAIエージェントをトレーニングをしていくか？
9. 1. はじめに 2. なぜCursorルールを整備する必要があるのか 3. 良いCursorルールとは 4. 3つのCursorルール 4.1. コーディング規約 4.2. ドメイン知識 4.3. オペレーション 5. ルールの評価と育て⽅ 6. まとめと未来予想 アジェンダ 9
10. 1. はじめに 10
11. 11 私たちの知る開発の終わり https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/ 1. はじめに
12. 12 There’s a lot of chatter in the media that software developers will soon lose their jobs to AI. I don’t buy it. It is not the end of programming. It is the end of programming as we know it today. 訳）メディアでは、ソフトウェア開発者がすぐにAIに仕事を奪われるとい う噂が広まっています。私はこれを信じません。 これはプログラミングの終わりではありません。現在知られている形での プログラミングの終わりなのです。 私たちの知る開発の終わり 1. はじめに
13. 13 ログラスも2025年からAI駆動開発へ⼤きくシフト 1. はじめに https://comemo.nikkei.com/n/n26dc284dcd5a
14. 14 1年間の育休からの異世界転⽣ 1. はじめに https://x.com/jamgodtree/status/1927682077719498893
15. 15 1. はじめに まさに私たちが知っている開発の終わり AIエージェントと開発するAI駆動開発の始まり
16. 16 1. はじめに AI駆動開発時代に⼤事なことは？
17. 17 1. はじめに AIが働きやすい環境を作ること
18. 18 1. はじめに AIのオンボーディングが必要
19. 19 1. はじめに AIのオンボーディングとは？ => 知識と経験をAIが読めるようにする
20. 20 1. はじめに AIのオンボーディングとは？ => 知識と経験をAIが読めるようにする => Cursorルールの整備
21. 21 1. はじめに 暗黙知（知識と経験）をアクセス可能（API化）にし、AIと共同する時代へ https://comemo.nikkei.com/n/n782dc3c31531
22. 2. なぜCursorルールを整備する 必要があるのか 22
23. 23 2. なぜCursorルールを整備する必要があるのか？ Cursorをオンボーディングするため Cursorが⾃律的に開発するため
24. 24 オンボーディングが完了しているエンジニアとそうでないエンジニア 2. なぜCursorルールを整備する必要があるのか？ オンボーディングが完了しているエンジニア - 抽象的な指示 だけでHowをお任せできる - 自走できる 。レビューの頻度が少ない オンボーディングが完了していないエンジニア - 具体的な指示 をしないと動けない - 自走できない。 レビュー頻度が多い
25. 25 Cursorを「ペアプログラミングツール」として使うならルールの整備は必要ない。 2. なぜCursorルールを整備する必要があるのか？ - ペアプロは常に具体的に指⽰ができる - ペアプロは常に考えを同期することができる → その場でルールに相当するものを伝えることができる。しかし、これはAIエージェントではない
26. 26 ⽬指すべきは複数のAIエージェントのマネジメント 2. なぜCursorルールを整備する必要があるのか？ 󰳕🤖 ⼀緒に開発 󰳕 🤖🤖 🤖 複数のAIに指⽰
27. 27 ⽬指すべきは複数のAIエージェントのマネジメント 2. なぜCursorルールを整備する必要があるのか？ 󰳕🤖 ⼀緒に開発 󰳕 🤖🤖 🤖 複数のAIに指⽰ オンボが完了していない オンボが完了している
28. 28 2. なぜCursorルールを整備する必要があるのか？ Cursorが⾃律的に開発するための ルールを考えていく
29. 3. 良いCursorルールとは 29
30. 30 3. 良いCursorルールとは？ 良いCursorルールはプロンプトを やりたいこと（What）の指⽰だけにできる
31. 31 3. 良いCursorルールとは？ 良いCursorルールの定義 - 良いCursorルールはプロンプトをやりたいこと（What）だけの指⽰にできる - Howは完全にお任せできる - 出⼒したコードがやりたいことを達成していて、かつコードがそのプロダクトにおいて「綺麗な」コードになっている - 良いCursorルールは⾃動でアタッチされる - ⼈間がそのルールの存在を知らなくてもCursorが⾃動でルールを使うかどうか判断できる
32. 32 3. 良いCursorルールとは？ 良いCursorルールの定義 - 良いCursorルールはプロンプトをやりたいこと（What）だけの指⽰にできる - Howは完全にお任せできる - 出⼒したコードがやりたいことを達成していて、かつコードがそのプロダクトにおいて「綺麗な」コードになっている - 良いCursorルールは⾃動でアタッチされる - ⼈間がそのルールの存在を知らなくてもCursorが⾃動でルールを使うかどうか判断できる この発表は⼀つ⽬にフォーカス
33. 33 3. 良いCursorルールとは？ 良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる 〇〇を保存できるようにしたい。 ××というORMを使って△△というテーブルに データを保存して。 実装後はコンパイルを実⾏して
34. 34 3. 良いCursorルールとは？ 良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる 〇〇を保存できるようにしたい。 ××というORMを使って△△というテーブルに データを保存して。 実装後はコンパイルを実⾏して やりたいこと
35. 35 3. 良いCursorルールとは？ 良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる 〇〇を保存できるようにしたい。 ××というORMを使って△△というテーブルに データを保存して。 実装後はコンパイルを実⾏して どう実現するか
36. 36 3. 良いCursorルールとは？ 良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる 〇〇を保存できるようにしたい。 ××というORMを使って△△というテーブルに データを保存して。 実装後はコンパイルを実⾏して これがプロンプトの ゴール
37. 37 3. 良いCursorルールとは？ 良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。 実装後は./gradlew compileKotlinを実⾏して
38. 38 3. 良いCursorルールとは？ 良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。 実装後は./gradlew compileKotlinを実⾏して
39. 4. 3つのCursorルール 39
40. 40 4. 3つのCursorルール 良いCursorルールを作るためにルールを3つのカテゴリに分類してみる - Cursorルールを「コード規約」、「ドメイン知識」、「オペレーション」に分類してみる タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。 実装後は./gradlew compileKotlinを実⾏して
41. タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。 実装後は./gradlew compileKotlinを実⾏して 41 4. 3つのCursorルール 良いCursorルールを作るため3つのカテゴリに分類してみる - Cursorルールを「コード規約」、「ドメイン知識」、「オペレーション」に分類してみる - コード規約 実装の詳細 jooqを使うなどの ルール
42. タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。 実装後は./gradlew compileKotlinを実⾏して 42 4. 3つのCursorルール 良いCursorルールを作るため3つのカテゴリに分類してみる - Cursorルールを「コード規約」、「ドメイン知識」、「オペレーション」に分類してみる - ドメイン知識 タスク管理という ドメインについての 背景補⾜のルール
43. タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。 実装後は./gradlew compileKotlinを実⾏して 43 4. 3つのCursorルール 良いCursorルールを作るため3つのカテゴリに分類してみる - Cursorルールを「コード規約」、「ドメイン知識」、「オペレーション」に分類してみる - オペレーション 実装以外の ルーチンワーク についてのルール
44. 44 4. 3つのCursorルール 良いCursorルールを作るため3つのカテゴリに分類してみる - Cursorルールの公式ドキュメントも似たスタイルで分類している（workflowsがオペレーションに相当） https://docs.cursor.com/context/rules
45. 45 4. 3つのCursorルール 良いCursorルールを作るため3つのカテゴリに分類してみる - .cursor/rules配下にディレクトリを作成する - .cursor - rules - coding-rules - domain-knowledge - operations
46. 46 4. 3つのCursorルール 3つのCursorルールの全体感 フロントエンド バックエンド プレゼンテーション層 アプリケーション層 ドメイン層 インフラストラクチャ層 コンポーネント フックス
47. 47 4. 3つのCursorルール 3つのCursorルールの全体感 フロントエンド バックエンド プレゼンテーション層 アプリケーション層 ドメイン層 インフラストラクチャ層 コンポーネント フックス - コーディング規約→レイヤー別の書き⽅
48. 48 4. 3つのCursorルール 3つのCursorルールの全体感 フロントエンド バックエンド プレゼンテーション層 アプリケーション層 ドメイン層 インフラストラクチャ層 コンポーネント フックス - ドメイン知識→ドメイン、コンテキスト、機能別の情報 タスク管理 ユーザ管理
49. 実装 49 4. 3つのCursorルール 3つのCursorルールの全体感 - オペレーション→実装以外のルーチンワークに関するルール 要件定義、タスク管理 テスト コードレビューと修正 リリース
50. 50 4. 3つのCursorルール > 4-1. コーディング規約 コーディング規約 - How（実装の詳細）をいちいち指⽰しなくても「そのプロダクトにとっての綺麗なコード」を出⼒できるようにするルール - (レイヤー) × (シーン別) × (実装 or テスト)で書いていくのがおすすめ - 例）アプリケーション層の、Write処理時に、テストの書き⽅（write-usecase-integration-test-implementation.mdc） - 例）インフラ層の、リポジトリの、実装の仕⽅（repository-implementation.mdc）
51. 51 4. 3つのCursorルール > 4-1. コーディング規約 コーディング規約の具体例 - 実際のルールを⼀部抜粋
52. 52 4. 3つのCursorルール > 4-1. コーディング規約 コーディング規約の具体例 - テキスト部分 - テキストは実はあまり書いていない - 実装例で表現しづらいことを書く - どの情報をどう書くべきはプロダクトに完全に依存する のであくまで参考程度に
53. 53 4. 3つのCursorルール > 4-1. コーディング規約 コーディング規約の具体例 - 実装例 - 実装例は厚めに書くこと（ルールの2/3が実装例） - Few-shotプロンプティング
54. 54 4. 3つのCursorルール > 4-1. コーディング規約 Few-shot プロンプティング - いわゆる具体例のこと - サンプルコードを厚めに書くことで精度を上げる https://www.oreilly.co.jp/books/9784814401130/ 例示による説明は人間同士のコミュニケーションでも効果的ですが、 LLMとのやり取りにお いてはさらに重要な意味を持ちます。これは、 LLMがプロンプト内のパターンを認識し、それ を踏襲 して補完を生成することに長けているためです。 Few-shotプロンプティングを活用 することで、質問の解釈方法を示すだけでなく、期待する補完の具体的な形式まで明示する ことができます。 John Berryman、Albert Ziegler　著、服部 佑樹、佐藤 直生　訳. LLMのプロンフプトエンジ ニアリング (p. 90)
55. 55 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識 - いわゆるドメインに即した⽂脈、背景、仕様の情報 - Howの省略ではなく、Whatの省略をするための情報 - コーディング規約はHowの省略、ドメイン知識はWhatの省略
56. 56 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識 - いわゆるドメインに即した⽂脈、背景、仕様の情報 - 「タスク」といきなり⾔われて新⼈エンジニアに通じるか？ タスクの複数のコメントを追加できるようにしたい jooqというORMを使ってpostgresqlの tasksというテーブルのデータを保存して。 実装後は./gradlew compileKotlinを実⾏して
57. 57 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識 - いわゆるドメインに即した⽂脈、背景、仕様の情報 - 「タスク」といきなり⾔われて新⼈エンジニアに通じるか？ - →「やりたいことの」の裏には膨⼤な仕様やコンテキストが隠されている（この例は簡単だけど） HogeTasks SaaSというサービスにはタスクという概念があります。 タスクは必ず⼀つのプロジェクトに属します。 プロジェクトという概念は〜。 タスクはステータス管理できて、未着⼿、進⾏中、完了の3つのステータスがあります。 タスクには複数のユーザーをアサインできます。 アサインされたユーザーのみステータスを完了に変更することができます。 タスクには複数のコメントをつけることができます。 コメントはコメント作成者のみ編集と削除ができます。 ~~~ ~~~ タスクの複数のコメントを追加できるようにしたい jooqというORMを使ってpostgresqlの tasksというテーブルにデータを保存して。 実装後は./gradlew compileKotlinを実⾏して
58. 58 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識に属するもの - 仕様書 - ドメインモデル図（集約はどの範囲やモデルとモデルの関係性、ふるまいなど） - ⽤語集 - ユースケース図など
59. 59 だがしかし 4. 3つのCursorルール > 4-2. ドメイン知識
60. 60 実はあまり上⼿く運⽤できていない 4. 3つのCursorルール > 4-2. ドメイン知識
61. 61 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識をルールにする必要ない説（急な⼿のひら返し） - そもそもAIはコードを読めばある程度仕様がわかる - 現実世界の概念とコードがずれなく表現できていれば（DDD）、コードが仕様書になるのでドメイン知識のルールは必要性が減る
62. 62 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識をルールにする必要ない説 - そもそもAIはコードを読めばある程度仕様がわかる - 現実世界の概念とコードがずれなく表現できていれば（DDD）、 コードが仕様書になるのでドメイン知識のルールは必要性が減る class Task( val projectId: ProjectId, val title: TaskTitle, val description: TaskDescription, val status: TaskStatus, ) enum class TaskStatus { TODO, IN_PROGRESS, DONE, }
63. 63 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識をルールにする必要ない説 - そもそもAIはコードを読めばある程度仕様がわかる - 現実世界の概念とコードがずれなく表現できていれば（DDD）、 コードが仕様書になるのでドメイン知識のルールは必要性が減る class Task( val projectId: ProjectId, val title: TaskTitle, val description: TaskDescription, val status: TaskStatus, ) enum class TaskStatus { TODO, IN_PROGRESS, DONE, } タスクは必ず1つのプロジェクト に属するんだなー 3つのステータスがあるんだなー
64. 64 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識をルールにする必要ない説 - そもそもAIはコードを読めばある程度仕様がわかる - 現実世界の概念とコードがずれなく表現できていれば（DDD）、 コードが仕様書になるのでドメイン知識のルールは必要性が減る /** * タスク * ステータスは未着手 →進行中→完了の順に遷移する */ class Task( val projectId: ProjectId, val title: TaskTitle, val descritption: TaskDescription, val status: TaskStatus, val comments: List<Comment>, ) enum class TaskStatus { TODO, IN_PROGRESS, DONE, } そもそもコードに仕様を 書けばいい
65. 65 4. 3つのCursorルール > 4-2. ドメイン知識 Agent Rules as Domain Parser https://speakerdeck.com/yodakeisuke/agent-rules-as-domain-parser-10303fa7-cf85-4df5-a1fa-6f511f88d5a7
66. 66 4. 3つのCursorルール > 4-2. ドメイン知識 Agent Rules as Domain Parser https://speakerdeck.com/yodakeisuke/agent-rules-as-domain-parser-10303fa7-cf85-4df5-a1fa-6f511f88d5a7
67. 67 4. 3つのCursorルール > 4-2. ドメイン知識 Agent Rules as Domain Parser https://speakerdeck.com/yodakeisuke/agent-rules-as-domain-parser-10303fa7-cf85-4df5-a1fa-6f511f88d5a7 【理想】コードから仕様を常に 再計算可能にする。 コードからドメイン知識のルールを作る
68. 68 4. 3つのCursorルール > 4-2. ドメイン知識 ドメイン知識をルールにする必要ない説 考察 - 「コーディング規約以外の情報」としてドメイン知識という情報は概念上存在する - しかし現時点の所要時間の短いタスクをAIに任せる上ではそこまでドメインの情報は必要ない（ことが多い） - AIがコード読んでわからない仕様ならコードや仕様そのものを疑ってもいい - 今後もっとAIが複雑なタスクをするなら整備する必要があるかも - ルールを保守するのではなくコードからルールを常に再計算可能にするという考えもある（Agent Rule as Parser） - サマリ、インデックスとしてのドメイン知識（コードを全て読まなくてもすぐに全体像を理解できる。⼈間にも有⽤）
69. 69 オペレーション 4. 3つのCursorルール
70. 70 4. 3つのCursorルール > 4-3. オペレーション オペレーション - プログラミングだけが開発ではない 要求定義 要件定義 コード レビュー 手動テスト マージ リリース ユーザーからの フィードバック 設計 実装 静的解析・ コンパイル 自動テスト リファクタリ ング
71. 71 4. 3つのCursorルール > 4-3. オペレーション オペレーション - 各⼯程でルーチンワークがあるはず - →ルールによる⾔語化 要求定義 要件定義 コード レビュー 手動テスト マージ リリース ユーザーからの フィードバック 設計 実装 静的解析・ コンパイル 自動テスト リファクタリ ング 似たファイルを読み込 んでから実装して 実装したら必ず コンパイルして 手動テストの ID、パスはこれで Playwright MCPで動作確認 ブランチの命名規則、 プルリクエストの作り方、 レビューコメントへの対応 タスク管理方法
72. 72 4. 3つのCursorルール > 4-3. オペレーション おすすめのオペレーションルール - 必ずコンパイルすること、必ずlintを実⾏すること - alwaysApplyモード推奨 - 実⾏前に似たファイルを読み込むこと - alwaysApplyモード推奨
73. 73 4. 3つのCursorルール > 4-3. オペレーション おすすめのオペレーションルール - git操作 - ブランチ名 - プルリクエストに⼊れるべき項⽬ - 差分コードの⾃動分析など
74. 74 4. 3つのCursorルール > 4-3. オペレーション おすすめのオペレーションルール - ⼿動テスト - ログインID、パスは何を使うか？ - どのツールでテストを⾏うか？ - 実験的にPlaywright MCPを使っています。 - 例）「localhost:~~にアクセスして、〇〇で きるかテストして」 https://github.com/microsoft/playwright-mcp
75. 75 4. 3つのCursorルール > 4-3. オペレーション 上⼿くいかなかったオペレーションルール - タスク管理 - タスク管理をCursorに⾏わせてみたが上⼿くいかな かった - ルール通りに動いてくれたり、くれなかったり - Claude Code Actionsなども出てきているので、 タスク管理は GitHubの Issuesに寄せるのが良さそう
76. 5. ルールの評価と育て⽅ 76
77. 77 Cursorルールをどう評価し、育てるか？ 5. ルールの評価と育て⽅
78. 78 まず⽣成したコードの評価を考える 5. ルールの評価と育て⽅
79. 79 そもそも私たちはコードをどのように評価しているか？ - 評価ポイント - 1. やりたいことが実現できているか？（⾮機能要件含む） - 2. そのコードがプロダクト上「綺麗」とされているコードか？ 5. ルールの評価と育て⽅
80. 80 そもそも私たちはコードをどのように評価しているか？ - 評価ポイント - 1. やりたいことが実現できているか？（⾮機能要件含む）→What、外部品質 - 2. そのコードがプロダクト上「綺麗」とされているコードか？→How、内部品質 5. ルールの評価と育て⽅
81. 81 そもそも私たちはコードをどのように評価しているか？ - 評価ポイント - 1. やりたいことが実現できているか？（⾮機能要件含む）→What、外部品質 - ⾃動テスト - 2. そのコードがプロダクト上「綺麗」とされているコードか？→How、内部品質 - ⼈間によるレビュー 5. ルールの評価と育て⽅
82. 82 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 - What→観察可能なふるまい - クライアントが⽬標を達成するために使う公開された操作 - クライアントが⽬標を達成するために公開された状態 - How→実装の詳細 - 上⼆つの定義以外のもの 5. ルールの評価と育て⽅
83. 83 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 - What→観察可能なふるまい - タスクには複数のコメントを追加することができる - ⼀つのコメントは最⼤100⽂字まで - How→実装の詳細 - コメントはcommentsテーブルにjooq経由で保存される 5. ルールの評価と育て⽅
84. 84 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 実装 リファクタリング テスト 観察可能なふるまいの定義 実装の詳細の変更 観察可能なふるまいを変えずに 実装の詳細を最適化する 5. ルールの評価と育て⽅
85. 85 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 実装 リファクタリング テスト 観察可能なふるまいの定義 実装の詳細の変更 観察可能なふるまいを変えずに 実装の詳細を最適化する - 外部品質‧Whatは⾃動テストで担保 5. ルールの評価と育て⽅
86. 86 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 実装 リファクタリング テスト 観察可能なふるまいの定義 実装の詳細の変更 観察可能なふるまいを変えずに 実装の詳細を最適化する - 内部品質‧Howは⼈間のコードレビュー 5. ルールの評価と育て⽅
87. 87 改めてルールの評価を考える 5. ルールの評価と育て⽅
88. 88 Cursorルールが「ちゃんと」仕事しているか評価する - 良いCursorルールとはプロンプトをやりたいこと（What）だけの指⽰にできる - 外部品質：Whatの指⽰ - 内部品質：Howの指⽰ 5. ルールの評価と育て⽅
89. 89 Cursorルールが「ちゃんと」仕事しているか評価する - 良いCursorルールとはプロンプトをやりたいこと（What）だけの指⽰にできる - 外部品質：Whatの指⽰→⾃動テストで担保し、ルールはあまり関与しない - 内部品質：Howの指⽰ 5. ルールの評価と育て⽅
90. 90 評価関数とAIエージェント 5. ルールの評価と育て⽅ https://x.com/t_wada/status/1922110843270885789 - テストコードを評価関数として使う
91. 91 Cursorルールが「ちゃんと」仕事しているか評価する - 良いCursorルールとはプロンプトをやりたいこと（What）だけの指⽰にできる - 外部品質：Whatの指⽰→⾃動テストで担保し、ルールはあまり関与しない - 内部品質：Howの指⽰→Howを省略できる & ⽣成したコードがそのプロジェクトにとって綺麗なコードかどうか 5. ルールの評価と育て⽅
92. 92 では具体的にどう評価し、育てるか？ 5. ルールの評価と育て⽅
93. 93 既存の良いとされているファイルとの 乖離を評価する 5. ルールの評価と育て⽅
94. 94 「ファイル復元⽅式トレーニング」 でルールを評価し、育てる🏋 5. ルールの評価と育て⽅
95. ループ 95 ファイル復元⽅式トレーニングとは - お⼿本ファイルを削除して、ルールとプロンプトだけでそのファイルをCursorに復元→その差分を⾒てルールを改善していくトレーニン グ⽅法 5. ルールの評価と育て⽅ お手本ファイルを 削除→gitコミット お手本ファイルを 復元できるように ルールを修正 最小限のプロンプトで Cursorに指示 人間の目で 成果物とお手本ファイルを 比較（git diff）
96. 96 ファイル復元⽅式トレーニングとは - お⼿本ファイルを削除して、ルールとプロンプトだけでそのファイルをCursorに復元→その差分を⾒てルールを改善していくトレーニン グ⽅法 5. ルールの評価と育て⽅ https://zenn.dev/loglass/articles/10cb41eff3139d
97. 97 Step1. お⼿本ファイルを削除→gitコミット 5. ルールの評価と育て⽅
98. 98 Step2. お⼿本ファイルを復元できるようにルールを修正 5. ルールの評価と育て⽅
99. 99 Step3. 最⼩限のプロンプトでCursorに指⽰ 5. ルールの評価と育て⽅ タスクのRepositoryを作って データ保存できるようにして jooqというORMを使ってpostgresqlの tasksというテーブルのデータを保存して。 実装後は./gradlew compileKotlinを実⾏して - WhatだけでHowを指⽰しないこと
100. 100 Step4. お⼿本ファイルと⽐較 5. ルールの評価と育て⽅ - git diffするだけ
101. 101 Step5. 再度ルールを修正 5. ルールの評価と育て⽅ - 復元できなかった項⽬に対してルール項⽬や具体例を追加 - 指⽰しなくてもわかるルール項⽬を削除 - ⽬標達成に対してなるべく最⼩限のルールを作る。書きすぎると何が⼤事かCursor⾃⾝がわからなくなってしまう（体験談） - 明確な⽂章量があるというより、Cursorが実⾏することに対して必要な情報がちゃんと効いて⽣成されたコードが正しいかを 逐⼀確認しながら調整する - 「Kotlinで書いて」とかはわざわざ指⽰をしなくてもわかる
102. 102 その他のTips：今どんなルールを参照しているかを常にCursorに出⼒させる 5. ルールの評価と育て⽅ - そもそも指定したルールが参照されていないことがある - 意味のないルールが参照されていて、ノイズになっている場合がある
103. 103 その他のTips：週に1時間くらいはルールトレーニングの時間を！ 5. ルールの評価と育て⽅ - 忙しい開発の中で意識をしないとルールトレーニングの時間は取りづらい。 - ログラスではCursor道場という時間を設けていて、そこで他の⼈のオンボーディングをしつつ⾃分はルールの改善に着⼿しています
104. 6. まとめと未来予想 104
105. 105 6. まとめと未来予想 まとめ - なぜCursorルールが必要？ - CursorをAIエージェントとして使⽤し、マネジメントをするならCursorルールが必要 - 良いCursorルールはCursorに⾃⾛⼒を与える。 - 良いCursorルールはプロンプトをやりたいことの指⽰だけにできる - 3つのCursorルール 1. コーディング規約→Howを省略するためのルール 2. ドメイン知識→Whatの背景を省略したいが、理想はコードからわかるようにすべき 3. オペレーション→ルーチンワーク⾃動化のためのルール - ルールの評価と育て⽅ - 内部品質を担保するためのルール作りは難しい - お⼿本ファイルをルールとプロンプトで復元させるファイル復元トレーニングでルールを育てていく
106. 106 6. まとめと未来予想 未来予想と私がログラスで 実現したいこと
107. 107 6. まとめと未来予想 https://prtimes.jp/main/html/rd/p/000000160.000052025.html
108. 108 6. まとめと未来予想 https://speakerdeck.com/loglass2019/whats-loglass?slide=39
109. 109 6. まとめと未来予想 2年で+15新規プロダクト？？？ 無理じゃない？🤔
110. 110 6. まとめと未来予想 採⽤の限界とプロダクトと組織の崩壊 - 肌感として組織は1年で2倍以上にならない - これを超えるとマネジメントが回らなくなり組織が崩壊する - しかし事業の成⻑スピードに対してエンジニアが必要 - →どうする？ - →業務委託や外部の開発会社を⼤量に頼る - →背景や⽬的を伝えきれず、品質が下がる（⚠業務委託、開発会社が悪いのではなく、上記同様マネジメントの問題）
111. 111 6. まとめと未来予想 2年で +15プロダクトの現実性 - プロダクトによるがSaaSの新規開発は1stリリースまで半年〜1,２年ほどかかる（初期の構想フェーズも含む） - Loglassも1年ほど開発をかけている - 1年で7~8つのプロダクト開発を同時進⾏するのか？（今近しいことを本当にしてます） - リリース後ももちろん改善するのでエンジニアは減らせない - エンジニアを⼤量採⽤したいが、前スライドの通り限界値があるというジレンマ
112. 112 6. まとめと未来予想 この⾮現実的状況に対しての AIエージェントという希望
113. 6. まとめと未来予想 AIエージェントの未来予測 - AIエージェントは⼈間の確認なしで、より⻑く、より正しく動作するようになる - AIエージェントは⼩数の⼈間の管理下において、無限に並列稼働するようになる - 1⼈のエンジニアがメガベンチャーのプロダクト組織を超える⼒を持つようになる 💻 💻 💻
114. 114 6. まとめと未来予想 AIエージェントの未来予測 - AIエージェントは⼈間の確認なしで、より⻑く、より正しく動作するようになる - AIエージェントは⼩数の⼈間の管理下において、無限に並列稼働するようになる - 1⼈のエンジニアがメガベンチャーのプロダクト組織を超える⼒を持つようになる - アウトプットを出すスピードが天元突破する - 開発に1, 2年かかる競合に対して数週間で新サービスを市場投⼊できるようになる - 今とは⽐較にならないレベルでエンジニアリングが⽐較優位になる時代が来る - ⼿作り開発 vs AI駆動開発
115. 115 6. まとめと未来予想 AIでソフトウェア開発を ゲームチェンジしたい
116. 116 6. まとめと未来予想 AIでゲームチェンジしたい⼈、お待ちしてます！ありがとうございました！ https://pitta.me/matches/aASXVeKhDtcS Pittaで⾃分と話せます！ Xで質問も受け付けてます！ https://x.com/yuiiitoto