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

Slide 1

Slide 1 text

「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの考え⽅‧育て⽅ 2025年6⽉18⽇ AI Engineering Summit 株式会社ログラスシニアソフトウェアエンジニア佐藤有⽃ 1

Slide 2

Slide 2 text

⾃⼰紹介株式会社ログラスプロダクト開発部シニアソフトウェアエンジニア株式会社ログラスに2020年12⽉に⼊社。 2025年2⽉からログラスの全エンジニアに対してCursorの導⼊のリードを⾏ってきた。得意分野は型と⾃動テストで技術情報誌やブログなどでよく発信をしている。佐藤有⽃（ゆいと） @Yuiiitoto 2 n月刊ラムダノート Vol.4, No.3(2024) https://www.lambdanote.com/products/n-vol-4-no-3-2024

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

5 今⽇話すこと「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの考え⽅‧育て⽅

Slide 6

Slide 6 text

6 今⽇話すこと「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの考え⽅‧育て⽅数年以上、数⼗⼈で開発を続けているコードを持つ、AIネイティブではないプロダクトに対して

Slide 7

Slide 7 text

7 今⽇話すこと「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの考え⽅‧育て⽅ AIエージェントに⾃⾛してもらうためにCursorルールをどう⾔語化するか？

Slide 8

Slide 8 text

8 今⽇話すこと「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの考え⽅‧育て⽅そのルールをどう育てていくか？どうAIエージェントをトレーニングをしていくか？

Slide 9

Slide 9 text

1. はじめに 2. なぜCursorルールを整備する必要があるのか 3. 良いCursorルールとは 4. 3つのCursorルール 4.1. コーディング規約 4.2. ドメイン知識 4.3. オペレーション 5. ルールの評価と育て⽅ 6. まとめと未来予想アジェンダ 9

Slide 10

Slide 10 text

1. はじめに 10

Slide 11

Slide 11 text

11 私たちの知る開発の終わり https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/ 1. はじめに

Slide 12

Slide 12 text

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. はじめに

Slide 13

Slide 13 text

13 ログラスも2025年からAI駆動開発へ⼤きくシフト 1. はじめに https://comemo.nikkei.com/n/n26dc284dcd5a

Slide 14

Slide 14 text

14 1年間の育休からの異世界転⽣ 1. はじめに https://x.com/jamgodtree/status/1927682077719498893

Slide 15

Slide 15 text

15 1. はじめにまさに私たちが知っている開発の終わり AIエージェントと開発するAI駆動開発の始まり

Slide 16

Slide 16 text

16 1. はじめに AI駆動開発時代に⼤事なことは？

Slide 17

Slide 17 text

17 1. はじめに AIが働きやすい環境を作ること

Slide 18

Slide 18 text

18 1. はじめに AIのオンボーディングが必要

Slide 19

Slide 19 text

19 1. はじめに AIのオンボーディングとは？ => 知識と経験をAIが読めるようにする

Slide 20

Slide 20 text

20 1. はじめに AIのオンボーディングとは？ => 知識と経験をAIが読めるようにする => Cursorルールの整備

Slide 21

Slide 21 text

21 1. はじめに暗黙知（知識と経験）をアクセス可能（API化）にし、AIと共同する時代へ https://comemo.nikkei.com/n/n782dc3c31531

Slide 22

Slide 22 text

2. なぜCursorルールを整備する必要があるのか 22

Slide 23

Slide 23 text

23 2. なぜCursorルールを整備する必要があるのか？ Cursorをオンボーディングするため Cursorが⾃律的に開発するため

Slide 24

Slide 24 text

24 オンボーディングが完了しているエンジニアとそうでないエンジニア 2. なぜCursorルールを整備する必要があるのか？オンボーディングが完了しているエンジニア - 抽象的な指示だけでHowをお任せできる - 自走できる。レビューの頻度が少ないオンボーディングが完了していないエンジニア - 具体的な指示をしないと動けない - 自走できない。レビュー頻度が多い

Slide 25

Slide 25 text

25 Cursorを「ペアプログラミングツール」として使うならルールの整備は必要ない。 2. なぜCursorルールを整備する必要があるのか？ - ペアプロは常に具体的に指⽰ができる - ペアプロは常に考えを同期することができる → その場でルールに相当するものを伝えることができる。しかし、これはAIエージェントではない

Slide 26

Slide 26 text

26 ⽬指すべきは複数のAIエージェントのマネジメント 2. なぜCursorルールを整備する必要があるのか？ 󰳕🤖 ⼀緒に開発 󰳕 🤖🤖 🤖 複数のAIに指⽰

Slide 27

Slide 27 text

27 ⽬指すべきは複数のAIエージェントのマネジメント 2. なぜCursorルールを整備する必要があるのか？ 󰳕🤖 ⼀緒に開発 󰳕 🤖🤖 🤖 複数のAIに指⽰オンボが完了していないオンボが完了している

Slide 28

Slide 28 text

28 2. なぜCursorルールを整備する必要があるのか？ Cursorが⾃律的に開発するためのルールを考えていく

Slide 29

Slide 29 text

3. 良いCursorルールとは 29

Slide 30

Slide 30 text

30 3. 良いCursorルールとは？良いCursorルールはプロンプトをやりたいこと（What）の指⽰だけにできる

Slide 31

Slide 31 text

31 3. 良いCursorルールとは？良いCursorルールの定義 - 良いCursorルールはプロンプトをやりたいこと（What）だけの指⽰にできる - Howは完全にお任せできる - 出⼒したコードがやりたいことを達成していて、かつコードがそのプロダクトにおいて「綺麗な」コードになっている - 良いCursorルールは⾃動でアタッチされる - ⼈間がそのルールの存在を知らなくてもCursorが⾃動でルールを使うかどうか判断できる

Slide 32

Slide 32 text

32 3. 良いCursorルールとは？良いCursorルールの定義 - 良いCursorルールはプロンプトをやりたいこと（What）だけの指⽰にできる - Howは完全にお任せできる - 出⼒したコードがやりたいことを達成していて、かつコードがそのプロダクトにおいて「綺麗な」コードになっている - 良いCursorルールは⾃動でアタッチされる - ⼈間がそのルールの存在を知らなくてもCursorが⾃動でルールを使うかどうか判断できるこの発表は⼀つ⽬にフォーカス

Slide 33

Slide 33 text

33 3. 良いCursorルールとは？良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる〇〇を保存できるようにしたい。 ××というORMを使って△△というテーブルにデータを保存して。実装後はコンパイルを実⾏して

Slide 34

Slide 34 text

34 3. 良いCursorルールとは？良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる〇〇を保存できるようにしたい。 ××というORMを使って△△というテーブルにデータを保存して。実装後はコンパイルを実⾏してやりたいこと

Slide 35

Slide 35 text

35 3. 良いCursorルールとは？良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる〇〇を保存できるようにしたい。 ××というORMを使って△△というテーブルにデータを保存して。実装後はコンパイルを実⾏してどう実現するか

Slide 36

Slide 36 text

36 3. 良いCursorルールとは？良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできる〇〇を保存できるようにしたい。 ××というORMを使って△△というテーブルにデータを保存して。実装後はコンパイルを実⾏してこれがプロンプトのゴール

Slide 37

Slide 37 text

37 3. 良いCursorルールとは？良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできるタスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。実装後は./gradlew compileKotlinを実⾏して

Slide 38

Slide 38 text

38 3. 良いCursorルールとは？良いCursorルールは、プロンプトをやりたいこと（What）だけの指⽰にできるタスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。実装後は./gradlew compileKotlinを実⾏して

Slide 39

Slide 39 text

4. 3つのCursorルール 39

Slide 40

Slide 40 text

40 4. 3つのCursorルール良いCursorルールを作るためにルールを3つのカテゴリに分類してみる - Cursorルールを「コード規約」、「ドメイン知識」、「オペレーション」に分類してみるタスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。実装後は./gradlew compileKotlinを実⾏して

Slide 41

Slide 41 text

タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。実装後は./gradlew compileKotlinを実⾏して 41 4. 3つのCursorルール良いCursorルールを作るため3つのカテゴリに分類してみる - Cursorルールを「コード規約」、「ドメイン知識」、「オペレーション」に分類してみる - コード規約実装の詳細 jooqを使うなどのルール

Slide 42

Slide 42 text

タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。実装後は./gradlew compileKotlinを実⾏して 42 4. 3つのCursorルール良いCursorルールを作るため3つのカテゴリに分類してみる - Cursorルールを「コード規約」、「ドメイン知識」、「オペレーション」に分類してみる - ドメイン知識タスク管理というドメインについての背景補⾜のルール

Slide 43

Slide 43 text

タスクに対してコメントを複数つけるようにしたい。 jooqというORMを使ってpostgresqlの commentsというテーブルにデータを保存して。実装後は./gradlew compileKotlinを実⾏して 43 4. 3つのCursorルール良いCursorルールを作るため3つのカテゴリに分類してみる - Cursorルールを「コード規約」、「ドメイン知識」、「オペレーション」に分類してみる - オペレーション実装以外のルーチンワークについてのルール

Slide 44

Slide 44 text

44 4. 3つのCursorルール良いCursorルールを作るため3つのカテゴリに分類してみる - Cursorルールの公式ドキュメントも似たスタイルで分類している（workﬂowsがオペレーションに相当） https://docs.cursor.com/context/rules

Slide 45

Slide 45 text

45 4. 3つのCursorルール良いCursorルールを作るため3つのカテゴリに分類してみる - .cursor/rules配下にディレクトリを作成する - .cursor - rules - coding-rules - domain-knowledge - operations

Slide 46

Slide 46 text

46 4. 3つのCursorルール 3つのCursorルールの全体感フロントエンドバックエンドプレゼンテーション層アプリケーション層ドメイン層インフラストラクチャ層コンポーネントフックス

Slide 47

Slide 47 text

47 4. 3つのCursorルール 3つのCursorルールの全体感フロントエンドバックエンドプレゼンテーション層アプリケーション層ドメイン層インフラストラクチャ層コンポーネントフックス - コーディング規約→レイヤー別の書き⽅

Slide 48

Slide 48 text

48 4. 3つのCursorルール 3つのCursorルールの全体感フロントエンドバックエンドプレゼンテーション層アプリケーション層ドメイン層インフラストラクチャ層コンポーネントフックス - ドメイン知識→ドメイン、コンテキスト、機能別の情報タスク管理ユーザ管理

Slide 49

Slide 49 text

実装 49 4. 3つのCursorルール 3つのCursorルールの全体感 - オペレーション→実装以外のルーチンワークに関するルール要件定義、タスク管理テストコードレビューと修正リリース

Slide 50

Slide 50 text

50 4. 3つのCursorルール > 4-1. コーディング規約コーディング規約 - How（実装の詳細）をいちいち指⽰しなくても「そのプロダクトにとっての綺麗なコード」を出⼒できるようにするルール - (レイヤー) × (シーン別) × (実装 or テスト)で書いていくのがおすすめ - 例）アプリケーション層の、Write処理時に、テストの書き⽅（write-usecase-integration-test-implementation.mdc） - 例）インフラ層の、リポジトリの、実装の仕⽅（repository-implementation.mdc）

Slide 51

Slide 51 text

51 4. 3つのCursorルール > 4-1. コーディング規約コーディング規約の具体例 - 実際のルールを⼀部抜粋

Slide 52

Slide 52 text

52 4. 3つのCursorルール > 4-1. コーディング規約コーディング規約の具体例 - テキスト部分 - テキストは実はあまり書いていない - 実装例で表現しづらいことを書く - どの情報をどう書くべきはプロダクトに完全に依存するのであくまで参考程度に

Slide 53

Slide 53 text

53 4. 3つのCursorルール > 4-1. コーディング規約コーディング規約の具体例 - 実装例 - 実装例は厚めに書くこと（ルールの2/3が実装例） - Few-shotプロンプティング

Slide 54

Slide 54 text

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)

Slide 55

Slide 55 text

55 4. 3つのCursorルール > 4-2. ドメイン知識ドメイン知識 - いわゆるドメインに即した⽂脈、背景、仕様の情報 - Howの省略ではなく、Whatの省略をするための情報 - コーディング規約はHowの省略、ドメイン知識はWhatの省略

Slide 56

Slide 56 text

56 4. 3つのCursorルール > 4-2. ドメイン知識ドメイン知識 - いわゆるドメインに即した⽂脈、背景、仕様の情報 - 「タスク」といきなり⾔われて新⼈エンジニアに通じるか？タスクの複数のコメントを追加できるようにしたい jooqというORMを使ってpostgresqlの tasksというテーブルのデータを保存して。実装後は./gradlew compileKotlinを実⾏して

Slide 57

Slide 57 text

57 4. 3つのCursorルール > 4-2. ドメイン知識ドメイン知識 - いわゆるドメインに即した⽂脈、背景、仕様の情報 - 「タスク」といきなり⾔われて新⼈エンジニアに通じるか？ - →「やりたいことの」の裏には膨⼤な仕様やコンテキストが隠されている（この例は簡単だけど） HogeTasks SaaSというサービスにはタスクという概念があります。タスクは必ず⼀つのプロジェクトに属します。プロジェクトという概念は〜。タスクはステータス管理できて、未着⼿、進⾏中、完了の3つのステータスがあります。タスクには複数のユーザーをアサインできます。アサインされたユーザーのみステータスを完了に変更することができます。タスクには複数のコメントをつけることができます。コメントはコメント作成者のみ編集と削除ができます。 ~~~ ~~~ タスクの複数のコメントを追加できるようにしたい jooqというORMを使ってpostgresqlの tasksというテーブルにデータを保存して。実装後は./gradlew compileKotlinを実⾏して

Slide 58

Slide 58 text

58 4. 3つのCursorルール > 4-2. ドメイン知識ドメイン知識に属するもの - 仕様書 - ドメインモデル図（集約はどの範囲やモデルとモデルの関係性、ふるまいなど） - ⽤語集 - ユースケース図など

Slide 59

Slide 59 text

59 だがしかし 4. 3つのCursorルール > 4-2. ドメイン知識

Slide 60

Slide 60 text

60 実はあまり上⼿く運⽤できていない 4. 3つのCursorルール > 4-2. ドメイン知識

Slide 61

Slide 61 text

61 4. 3つのCursorルール > 4-2. ドメイン知識ドメイン知識をルールにする必要ない説（急な⼿のひら返し） - そもそもAIはコードを読めばある程度仕様がわかる - 現実世界の概念とコードがずれなく表現できていれば（DDD）、コードが仕様書になるのでドメイン知識のルールは必要性が減る

Slide 62

Slide 62 text

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, }

Slide 63

Slide 63 text

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つのステータスがあるんだなー

Slide 64

Slide 64 text

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, ) enum class TaskStatus { TODO, IN_PROGRESS, DONE, } そもそもコードに仕様を書けばいい

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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 【理想】コードから仕様を常に再計算可能にする。コードからドメイン知識のルールを作る

Slide 68

Slide 68 text

68 4. 3つのCursorルール > 4-2. ドメイン知識ドメイン知識をルールにする必要ない説考察 - 「コーディング規約以外の情報」としてドメイン知識という情報は概念上存在する - しかし現時点の所要時間の短いタスクをAIに任せる上ではそこまでドメインの情報は必要ない（ことが多い） - AIがコード読んでわからない仕様ならコードや仕様そのものを疑ってもいい - 今後もっとAIが複雑なタスクをするなら整備する必要があるかも - ルールを保守するのではなくコードからルールを常に再計算可能にするという考えもある（Agent Rule as Parser） - サマリ、インデックスとしてのドメイン知識（コードを全て読まなくてもすぐに全体像を理解できる。⼈間にも有⽤）

Slide 69

Slide 69 text

69 オペレーション 4. 3つのCursorルール

Slide 70

Slide 70 text

70 4. 3つのCursorルール > 4-3. オペレーションオペレーション - プログラミングだけが開発ではない要求定義要件定義コードレビュー手動テストマージリリースユーザーからのフィードバック設計実装静的解析・コンパイル自動テストリファクタリング

Slide 71

Slide 71 text

71 4. 3つのCursorルール > 4-3. オペレーションオペレーション - 各⼯程でルーチンワークがあるはず - →ルールによる⾔語化要求定義要件定義コードレビュー手動テストマージリリースユーザーからのフィードバック設計実装静的解析・コンパイル自動テストリファクタリング似たファイルを読み込んでから実装して実装したら必ずコンパイルして手動テストの ID、パスはこれで Playwright MCPで動作確認ブランチの命名規則、プルリクエストの作り方、レビューコメントへの対応タスク管理方法

Slide 72

Slide 72 text

72 4. 3つのCursorルール > 4-3. オペレーションおすすめのオペレーションルール - 必ずコンパイルすること、必ずlintを実⾏すること - alwaysApplyモード推奨 - 実⾏前に似たファイルを読み込むこと - alwaysApplyモード推奨

Slide 73

Slide 73 text

73 4. 3つのCursorルール > 4-3. オペレーションおすすめのオペレーションルール - git操作 - ブランチ名 - プルリクエストに⼊れるべき項⽬ - 差分コードの⾃動分析など

Slide 74

Slide 74 text

74 4. 3つのCursorルール > 4-3. オペレーションおすすめのオペレーションルール - ⼿動テスト - ログインID、パスは何を使うか？ - どのツールでテストを⾏うか？ - 実験的にPlaywright MCPを使っています。 - 例）「localhost:~~にアクセスして、〇〇できるかテストして」 https://github.com/microsoft/playwright-mcp

Slide 75

Slide 75 text

75 4. 3つのCursorルール > 4-3. オペレーション上⼿くいかなかったオペレーションルール - タスク管理 - タスク管理をCursorに⾏わせてみたが上⼿くいかなかった - ルール通りに動いてくれたり、くれなかったり - Claude Code Actionsなども出てきているので、タスク管理は GitHubの Issuesに寄せるのが良さそう

Slide 76

Slide 76 text

5. ルールの評価と育て⽅ 76

Slide 77

Slide 77 text

77 Cursorルールをどう評価し、育てるか？ 5. ルールの評価と育て⽅

Slide 78

Slide 78 text

78 まず⽣成したコードの評価を考える 5. ルールの評価と育て⽅

Slide 79

Slide 79 text

79 そもそも私たちはコードをどのように評価しているか？ - 評価ポイント - 1. やりたいことが実現できているか？（⾮機能要件含む） - 2. そのコードがプロダクト上「綺麗」とされているコードか？ 5. ルールの評価と育て⽅

Slide 80

Slide 80 text

80 そもそも私たちはコードをどのように評価しているか？ - 評価ポイント - 1. やりたいことが実現できているか？（⾮機能要件含む）→What、外部品質 - 2. そのコードがプロダクト上「綺麗」とされているコードか？→How、内部品質 5. ルールの評価と育て⽅

Slide 81

Slide 81 text

81 そもそも私たちはコードをどのように評価しているか？ - 評価ポイント - 1. やりたいことが実現できているか？（⾮機能要件含む）→What、外部品質 - ⾃動テスト - 2. そのコードがプロダクト上「綺麗」とされているコードか？→How、内部品質 - ⼈間によるレビュー 5. ルールの評価と育て⽅

Slide 82

Slide 82 text

82 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 - What→観察可能なふるまい - クライアントが⽬標を達成するために使う公開された操作 - クライアントが⽬標を達成するために公開された状態 - How→実装の詳細 - 上⼆つの定義以外のもの 5. ルールの評価と育て⽅

Slide 83

Slide 83 text

83 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 - What→観察可能なふるまい - タスクには複数のコメントを追加することができる - ⼀つのコメントは最⼤100⽂字まで - How→実装の詳細 - コメントはcommentsテーブルにjooq経由で保存される 5. ルールの評価と育て⽅

Slide 84

Slide 84 text

84 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 実装リファクタリングテスト観察可能なふるまいの定義実装の詳細の変更観察可能なふるまいを変えずに実装の詳細を最適化する 5. ルールの評価と育て⽅

Slide 85

Slide 85 text

85 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 実装リファクタリングテスト観察可能なふるまいの定義実装の詳細の変更観察可能なふるまいを変えずに実装の詳細を最適化する - 外部品質‧Whatは⾃動テストで担保 5. ルールの評価と育て⽅

Slide 86

Slide 86 text

86 WhatとHow→観察可能なふるまいと実装の詳細 https://book.mynavi.jp/ec/products/detail/id=134252 実装リファクタリングテスト観察可能なふるまいの定義実装の詳細の変更観察可能なふるまいを変えずに実装の詳細を最適化する - 内部品質‧Howは⼈間のコードレビュー 5. ルールの評価と育て⽅

Slide 87

Slide 87 text

87 改めてルールの評価を考える 5. ルールの評価と育て⽅

Slide 88

Slide 88 text

88 Cursorルールが「ちゃんと」仕事しているか評価する - 良いCursorルールとはプロンプトをやりたいこと（What）だけの指⽰にできる - 外部品質：Whatの指⽰ - 内部品質：Howの指⽰ 5. ルールの評価と育て⽅

Slide 89

Slide 89 text

89 Cursorルールが「ちゃんと」仕事しているか評価する - 良いCursorルールとはプロンプトをやりたいこと（What）だけの指⽰にできる - 外部品質：Whatの指⽰→⾃動テストで担保し、ルールはあまり関与しない - 内部品質：Howの指⽰ 5. ルールの評価と育て⽅

Slide 90

Slide 90 text

90 評価関数とAIエージェント 5. ルールの評価と育て⽅ https://x.com/t_wada/status/1922110843270885789 - テストコードを評価関数として使う

Slide 91

Slide 91 text

91 Cursorルールが「ちゃんと」仕事しているか評価する - 良いCursorルールとはプロンプトをやりたいこと（What）だけの指⽰にできる - 外部品質：Whatの指⽰→⾃動テストで担保し、ルールはあまり関与しない - 内部品質：Howの指⽰→Howを省略できる & ⽣成したコードがそのプロジェクトにとって綺麗なコードかどうか 5. ルールの評価と育て⽅

Slide 92

Slide 92 text

92 では具体的にどう評価し、育てるか？ 5. ルールの評価と育て⽅

Slide 93

Slide 93 text

93 既存の良いとされているファイルとの乖離を評価する 5. ルールの評価と育て⽅

Slide 94

Slide 94 text

94 「ファイル復元⽅式トレーニング」でルールを評価し、育てる🏋 5. ルールの評価と育て⽅

Slide 95

Slide 95 text

ループ 95 ファイル復元⽅式トレーニングとは - お⼿本ファイルを削除して、ルールとプロンプトだけでそのファイルをCursorに復元→その差分を⾒てルールを改善していくトレーニング⽅法 5. ルールの評価と育て⽅お手本ファイルを削除→gitコミットお手本ファイルを復元できるようにルールを修正最小限のプロンプトで Cursorに指示人間の目で成果物とお手本ファイルを比較（git diff）

Slide 96

Slide 96 text

96 ファイル復元⽅式トレーニングとは - お⼿本ファイルを削除して、ルールとプロンプトだけでそのファイルをCursorに復元→その差分を⾒てルールを改善していくトレーニング⽅法 5. ルールの評価と育て⽅ https://zenn.dev/loglass/articles/10cb41eff3139d

Slide 97

Slide 97 text

97 Step1. お⼿本ファイルを削除→gitコミット 5. ルールの評価と育て⽅

Slide 98

Slide 98 text

98 Step2. お⼿本ファイルを復元できるようにルールを修正 5. ルールの評価と育て⽅

Slide 99

Slide 99 text

99 Step3. 最⼩限のプロンプトでCursorに指⽰ 5. ルールの評価と育て⽅タスクのRepositoryを作ってデータ保存できるようにして jooqというORMを使ってpostgresqlの tasksというテーブルのデータを保存して。実装後は./gradlew compileKotlinを実⾏して - WhatだけでHowを指⽰しないこと

Slide 100

Slide 100 text

100 Step4. お⼿本ファイルと⽐較 5. ルールの評価と育て⽅ - git diﬀするだけ

Slide 101

Slide 101 text

101 Step5. 再度ルールを修正 5. ルールの評価と育て⽅ - 復元できなかった項⽬に対してルール項⽬や具体例を追加 - 指⽰しなくてもわかるルール項⽬を削除 - ⽬標達成に対してなるべく最⼩限のルールを作る。書きすぎると何が⼤事かCursor⾃⾝がわからなくなってしまう（体験談） - 明確な⽂章量があるというより、Cursorが実⾏することに対して必要な情報がちゃんと効いて⽣成されたコードが正しいかを逐⼀確認しながら調整する - 「Kotlinで書いて」とかはわざわざ指⽰をしなくてもわかる

Slide 102

Slide 102 text

102 その他のTips：今どんなルールを参照しているかを常にCursorに出⼒させる 5. ルールの評価と育て⽅ - そもそも指定したルールが参照されていないことがある - 意味のないルールが参照されていて、ノイズになっている場合がある

Slide 103

Slide 103 text

103 その他のTips：週に1時間くらいはルールトレーニングの時間を！ 5. ルールの評価と育て⽅ - 忙しい開発の中で意識をしないとルールトレーニングの時間は取りづらい。 - ログラスではCursor道場という時間を設けていて、そこで他の⼈のオンボーディングをしつつ⾃分はルールの改善に着⼿しています

Slide 104

Slide 104 text

6. まとめと未来予想 104

Slide 105

Slide 105 text

105 6. まとめと未来予想まとめ - なぜCursorルールが必要？ - CursorをAIエージェントとして使⽤し、マネジメントをするならCursorルールが必要 - 良いCursorルールはCursorに⾃⾛⼒を与える。 - 良いCursorルールはプロンプトをやりたいことの指⽰だけにできる - 3つのCursorルール 1. コーディング規約→Howを省略するためのルール 2. ドメイン知識→Whatの背景を省略したいが、理想はコードからわかるようにすべき 3. オペレーション→ルーチンワーク⾃動化のためのルール - ルールの評価と育て⽅ - 内部品質を担保するためのルール作りは難しい - お⼿本ファイルをルールとプロンプトで復元させるファイル復元トレーニングでルールを育てていく

Slide 106

Slide 106 text

106 6. まとめと未来予想未来予想と私がログラスで実現したいこと

Slide 107

Slide 107 text

107 6. まとめと未来予想 https://prtimes.jp/main/html/rd/p/000000160.000052025.html

Slide 108

Slide 108 text

108 6. まとめと未来予想 https://speakerdeck.com/loglass2019/whats-loglass?slide=39

Slide 109

Slide 109 text

109 6. まとめと未来予想 2年で+15新規プロダクト？？？無理じゃない？🤔

Slide 110

Slide 110 text

110 6. まとめと未来予想採⽤の限界とプロダクトと組織の崩壊 - 肌感として組織は1年で2倍以上にならない - これを超えるとマネジメントが回らなくなり組織が崩壊する - しかし事業の成⻑スピードに対してエンジニアが必要 - →どうする？ - →業務委託や外部の開発会社を⼤量に頼る - →背景や⽬的を伝えきれず、品質が下がる（⚠業務委託、開発会社が悪いのではなく、上記同様マネジメントの問題）

Slide 111

Slide 111 text

111 6. まとめと未来予想 2年で +15プロダクトの現実性 - プロダクトによるがSaaSの新規開発は1stリリースまで半年〜1,２年ほどかかる（初期の構想フェーズも含む） - Loglassも1年ほど開発をかけている - 1年で7~8つのプロダクト開発を同時進⾏するのか？（今近しいことを本当にしてます） - リリース後ももちろん改善するのでエンジニアは減らせない - エンジニアを⼤量採⽤したいが、前スライドの通り限界値があるというジレンマ

Slide 112

Slide 112 text

112 6. まとめと未来予想この⾮現実的状況に対しての AIエージェントという希望

Slide 113

Slide 113 text

6. まとめと未来予想 AIエージェントの未来予測 - AIエージェントは⼈間の確認なしで、より⻑く、より正しく動作するようになる - AIエージェントは⼩数の⼈間の管理下において、無限に並列稼働するようになる - 1⼈のエンジニアがメガベンチャーのプロダクト組織を超える⼒を持つようになる 💻 💻 💻

Slide 114

Slide 114 text

114 6. まとめと未来予想 AIエージェントの未来予測 - AIエージェントは⼈間の確認なしで、より⻑く、より正しく動作するようになる - AIエージェントは⼩数の⼈間の管理下において、無限に並列稼働するようになる - 1⼈のエンジニアがメガベンチャーのプロダクト組織を超える⼒を持つようになる - アウトプットを出すスピードが天元突破する - 開発に1, 2年かかる競合に対して数週間で新サービスを市場投⼊できるようになる - 今とは⽐較にならないレベルでエンジニアリングが⽐較優位になる時代が来る - ⼿作り開発 vs AI駆動開発

Slide 115

Slide 115 text

115 6. まとめと未来予想 AIでソフトウェア開発をゲームチェンジしたい

Slide 116

Slide 116 text

116 6. まとめと未来予想 AIでゲームチェンジしたい⼈、お待ちしてます！ありがとうございました！ https://pitta.me/matches/aASXVeKhDtcS Pittaで⾃分と話せます！ Xで質問も受け付けてます！ https://x.com/yuiiitoto

Slide 117

Slide 117 text

117