AI駆動開発の現在地〜職種の壁を越えて、我々は何をすべきか〜　/ ai-driven-development-3-layer

by 中村翼

Slide 1

Slide 1 text

AI駆動開発の現在地〜職種の壁を越えて、我々は何をすべきか〜レバテック Meetup 〜AIエージェントと共に進化する開発現場〜 2025年7⽉24⽇株式会社ログラスエンジニア中村翼（@nakamura_meg） 1

Slide 2

Slide 2 text

Slide 3

Slide 3 text

ログラスのAIツールの歩み 2月エンジニア全員に Cursor、一部に Devinを配布。時間軸

Slide 4

Slide 4 text

ログラスのAIツールの歩み 2月エンジニア全員に Cursor、一部に Devinを配布。 4月エンジニアだけではなくPdM・デザイナーまで波及時間軸

Slide 5

Slide 5 text

ログラスのAIツールの歩み 5 2月エンジニア全員に Cursor、一部に Devinを配布。 Cursor道場開始 4月エンジニアだけではなくPdM・デザイナーまで波及時間軸 6月 Claude Codeが全エンジニア使える状態

Slide 6

Slide 6 text

ログラスのAIツールの歩み 6 2月エンジニア全員に Cursor、一部に Devinを配布。 Cursor道場開始 4月エンジニアだけではなくPdM・デザイナーまで波及時間軸 6月 Claude Codeが全エンジニア使える状態 Claude CodeでPdM が機能リリース。デザイナーがプロトタイプを作る 6~7月

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Anthropic CEO ダリオ‧アモデイ談 https://www.foxnews.com/video/6373601741112

Slide 9

Slide 9 text

Anthropic CEO ダリオ‧アモデイ談 AIは今後1〜5年間で、エントリーレベルのホワイトカラー職の半数が失業し、失業率を10〜20％まで急上昇させる可能性がある ※参考⽇本の完全失業率: 約2.5％リーマンショック時の失業率: 約5.5％

Slide 10

Slide 10 text

Anthropic CEO ダリオ‧アモデイ談「今から3〜6か⽉もすれば、AIがコードの90%を書いている世界になる」「12カ⽉（1年）後には、ほぼすべてのコードをAIが書いている世界になるかもしれない」 https://www.youtube.com/watch?v =esCSpbDPJik

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

チーム全員AI-Nativeにするための取り組み

Slide 14

Slide 14 text

PdMもリリースできる時代

Slide 15

Slide 15 text

PdM‧デザイナーがClaude Code Actionを使⽤して開発する PdM デザイナー

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2025 Loglass Inc. AI駆動開発の課題 // AIが⽣成しがちな問題のあるコード例 class OrderService { // 問題1: 在庫チェックなし fun createOrder(customerId: String, items: List): Order { val order = Order( id = generateOrderId(), customerId = customerId, items = items, total = calculateTotal(items), status = OrderStatus.PENDING ) // 在庫減算を後で⾏う（在庫切れの可能性無視） items.forEach { item -> reduceStock(item.productId, item.quantity) } return saveOrder(order) } // 問題2: 割引計算の論理的制約無視 fun applyDiscount(order: Order, discountRate: Int): Order { // 負の割引率や100%超の割引を許可 val discountAmount = order.total * discountRate / 100 // 結果が負になる可能性を考慮せず return order.copy( total = order.total - discountAmount, appliedDiscount = discountAmount ) } }

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 2025 Loglass Inc. なぜこのようなことが起きるのか？ AI駆動開発の課題 2. ハッピーパスへの集中 // AIが想定する理想的なケース val product = products[productId] // 商品は必ず存在 product.stock -= quantity // 在庫は⼗分にある val subtotal = price * quantity // 正の値同⼠の掛け算 AIの思考:「正常ケースで動けば要件を満たしている」現実: 異常ケース、境界値、競合状態が存在する

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© 2025 Loglass Inc. Discovery (発⾒) 開発者‧QA‧PdMなど関係者全員でユースケースを取り上げ、具体的な「例」を出し合い、仕様や要求の認識を揃える Formulation (定式化) 発⾒した「例」を⾃動化できる⽅法 (Gherkin記法など) で誰でも読める形に落としこむ Automation (⾃動化): 定式化したシナリオを⾃動テストとして実装し、CI/CDで常に検証できるようにする BDDとは 33 https://cucumber.io/docs/bdd/#three-practic es

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2025 Loglass Inc. BDDとは「Aの時はBになる」を事前に定義することで、AIが何をすべきか明確になる Scenario: 複数商品のまとめ買い割引 Given 以下の商品が登録されている | 商品名 | 価格 | 在庫 | カテゴリ | | ノートPC | 80000 | 5 | 電⼦機器 | | マウス | 3000 | 10 | 電⼦機器 | | キーボード | 8000 | 8 | 電⼦機器 | | 本 | 2000 | 20 | 書籍 | And まとめ買い割引が以下のように設定されている | カテゴリ | 商品数 | 割引率 | | 電⼦機器 | 3個以上 | 15% | | 書籍 | 5冊以上 | 10% | When ⽥中さんが以下の商品をカートに追加する | 商品名 | 数量 | | ノートPC | 1 | | マウス | 2 | | キーボード | 1 | | 本 | 3 | Then 注⽂が確定される And 注⽂⾦額が以下のように計算される | カテゴリ | ⼩計 | 割引適⽤ | 割引後⾦額 | | 電⼦機器 | 94000 | 15% | 79900 | | 書籍 | 6000 | なし | 6000 | | 配送料 | | | 1000 | | 合計 | | | 86900 | 振る舞いを定義する

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© 2025 Loglass Inc. 形式⼿法とは // 基本シグネチャ：商品 sig Product { id: one String, // 商品ID（厳密に1つ） name: one String, // 商品名（厳密に1つ） price: one Int, // 価格（厳密に1つ） stock: one Int, // 在庫数（厳密に1つ） category: one Category, // カテゴリ（厳密に1つ） tags: set Tag, // タグ（0以上） seller: one Seller // 販売者（厳密に1つ） } 基本⽂法 - シグネチャ

Slide 40

Slide 40 text

© 2025 Loglass Inc. 形式⼿法とは sig Customer { // 必須情報（厳密に1つ） customerId: one String, email: one String, registrationDate: one Date, // オプション情報（0または1つ） phoneNumber: lone String, // 複数可能な情報（1つ以上） addresses: some Address, // 住所は最低1つ必要 // 任意の複数情報（0以上） paymentMethods: set PaymentMethod, // ⽀払⽅法は任意 } 基本⽂法 - 多重度

Slide 41

Slide 41 text

© 2025 Loglass Inc. 形式⼿法とは // 確定した注⽂の商品数量合計が在庫を超えない fact InventoryConstraintsReadable { all p: Product | { let confirmedStatuses = Confirmed + Processing + Shipped + Delivered let confirmedItems = {oi: OrderItem | some o: Order | oi in o.items and o.status in confirmedStatuses} let productItems = {oi: confirmedItems | oi.product = p} let totalQuantity = sum oi: productItems | oi.quantity totalQuantity <= p.stock } } 基本⽂法 - 制約条件

Slide 42

Slide 42 text

© 2025 Loglass Inc. 形式⼿法で発⾒する暗黙的なルール: 割引の併⽤ルール fact DiscountCombinationRules { all o: Order | all oi: o.items | { // BDD: 「まとめ買い割引が適⽤される」 // 疑問: セール価格との併⽤は？ (o.categoryDiscountRate > 0) implies { // パターン1: セール価格を基準にカテゴリ割引 oi.appliedPrice = oi.product.salePrice // oi.individualDiscount = (salePrice * categoryRate) / 100 // パターン2: 定価を基準にカテゴリ割引（セール無効） // oi.appliedPrice = oi.product.regularPrice // パターン3: より有利な⽅を選択 // let categoryTotal = regularPrice * (100 - categoryRate) / 100 // let saleTotal = salePrice // oi.appliedPrice = min[categoryTotal, saleTotal] } } }

Slide 43

Slide 43 text

© 2025 Loglass Inc. もしこんな状況があったら... Given ノートPCに10%の個別割引クーポンが適⽤可能 And 電⼦機器のまとめ買い割引15%も適⽤可能 When 両⽅の条件を満たす注⽂をする Then どちらの割引が適⽤される？暗黙的なルール ‧まとめ買い割引が適⽤される場合、個別商品の割引クーポンは無効 ‧顧客に有利な⽅を⾃動選択するのか？ ‧明⽰的に選択させるのか？

Slide 44

Slide 44 text

© 2025 Loglass Inc. 形式⼿法で制約をかけるこの制約は以下を保証する 1. 二重割引の防止 : まとめ買い15% + 個別10% = 25%割引は発生しない 2.システムの一貫性 : 1つの注文に1つの割引のみ適用 3.最適化の自動判定 : システムが顧客に最も有利な割引を選択 fact DiscountExclusivity { all o: Order | // まとめ買い割引と個別商品割引は重複適⽤されない o.hasCategoryDiscount = true implies all oi: o.items | oi.individualDiscount = 0 }

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

© 2025 Loglass Inc. 型例: 割引の同時適⽤を型で制限 sealed class DiscountSystem { object None : DiscountSystem() data class CategoryDiscount( val discounts: Map ) : DiscountSystem() data class IndividualDiscount( val itemDiscounts: Map ) : DiscountSystem() // CategoryDiscount と IndividualDiscount の同時適⽤を型レベルで防⽌ }

Slide 48

Slide 48 text

© 2025 Loglass Inc. 型例: オーダーの処理順序を型で制限 sealed class OrderStatus { object Pending : OrderStatus() data class Confirmed(...) : OrderStatus() data class Shipped( val previousState: Confirmed // 必ずConfirmedから遷移 ) : OrderStatus() data class Delivered( val previousState: Shipped // 必ずShippedから遷移 ) : OrderStatus() // 不正な状態遷移を型レベルで防⽌ // × Pending → Delivered (中間状態のスキップ) は不可能 }

Slide 49

Slide 49 text

© 2025 Loglass Inc. 型例: 商品種別による適⽤ルールを型で制限 sealed interface Product { // 共通プロパティ val id: ID val name: ProductName val code: ProductCode // 商品タイプによる分岐 val productType: ProductType get() = when (this) { is PhysicalProduct -> ProductType.PHYSICAL is DigitalProduct -> ProductType.DIGITAL is ServiceProduct -> ProductType.SERVICE } }

Slide 50

Slide 50 text

© 2025 Loglass Inc. メリット: コンパイル時の完全性保証 // これはコンパイルエラーになる val order = Order( status = OrderStatus.Delivered( previousState = OrderStatus.Pending // 型エラー ) ) // 正しい状態遷移のみ可能 val confirmed = OrderStatus.Confirmed(...) val shipped = OrderStatus.Shipped(previousState = confirmed) val delivered = OrderStatus.Delivered(previousState = shipped)

Slide 51

Slide 51 text

© 2025 Loglass Inc. メリット: 不正なビジネスロジックの排除 // 実⾏時まで発⾒されない危険なコード fun applyDiscount(order: Order) { // 両⽅の割引を同時適⽤ applyCategoryDiscount(order) applyIndividualDiscount(order) // バグ } // 型安全な実装 fun applyDiscount(system: DiscountSystem): Price = when(system) { is DiscountSystem.None -> originalPrice is DiscountSystem.CategoryDiscount -> applyCategory(system.discounts) is DiscountSystem.IndividualDiscount -> applyIndividual(system.itemDiscounts) // 同時適⽤は型システムにより不可能 }

Slide 52

Slide 52 text

© 2025 Loglass Inc. メリット: AIによる安全なコード⽣成 // AIが⽣成するコード例 fun processOrder(order: Order): OrderResult = when (order.status) { is OrderStatus.Pending -> validateAndConﬁrm(order) is OrderStatus.Conﬁrmed -> prepareShipment(order) is OrderStatus.Shipped -> trackDelivery(order) is OrderStatus.Delivered -> completeOrder(order) // 全てのケースが強制的にハンドリングされる }