LLMでソフトウェアエンジニアリングを改善 「コードの90%をAIが⽣成」 どう実現したか？開発はよくなったか？ 

池松 恭平 / ike @ike002jp 　2021/05〜　カウシェ 　・Backend Engineer 　・EM / PdM 　・CTO 　2014/04〜　DeNA 　・Backend Engineer 　・EM 

「コードの90%をAIが⽣成」 世間のAI事例はすごそう でも、現実だと少しギャップないですか？ 

「コードの90%をAIが⽣成」 ⾃分たちもこのような状態にして、 開発をすごくスピーディーにしたい 

組織へのAI活⽤の浸透、活⽤⼒の向上によって、 事例のように改善できる、と最初は思っていた が、現実はやや違った… 奮闘‧改善して得た知⾒をご紹介 

プロダクト‧組織の概要 

タイトル ソーシャル×発⾒型で “⽇本のECを再発明する” 

全社で47名、プロダクト系は23名 Farm Team
 PdM 新卒 Designer Backend ex-Showcase Gig Mobile EM ex-メルカリ Mobile ex- チームラボ QA Mobile Backend EC Team
 PdM 新卒 Designer Backend ex-Speee Mobile ex- スタンバイ ML Mobile ex-サイバー エージェント Backend ex-HRBrain Backend Partner Team
 PdM ex-DeNA Backend ex-freee Webfront ex-ラクスル QA ex- LINEヤ フーコミュニ ケーションズ Backend ex-サイバー エージェント 5名
 
 ※CX部、EC部
 18名
 
 ※テクノロジー部 
 
 ※CTO除く
 Backend EM ex-ラクスル Ad/UX Team
 Backend 

主要技術スタック Backend / ML / Analytics
 Mobile
 Swift
 SwiftUI
 Kotlin
 Firebase
 Bitrise
 アイコン 画像 アイコン 画像 Go
 Cloud Run
 BigQuery
 Vertex AI
 Cloud
 Spanner
 Terraform
 GitHub
 Actions
 Fastly
 Jetpack
 Compose
 gRPC
 ChatGPT,
 Codex
 Claude,
 Claude Code
 Cursor
 Cline
 Gemini
 Open
 Router
 LLM系サービス抜粋
 

【再掲】「コードの90%をAIが⽣成」 ⾃分たちもこのような状態にして、 開発をすごくスピーディーにしたい 

「コードの90%をAIが⽣成」 ➝ 活⽤⼒UPして、常時AI起点に実装を試みる 「開発をすごくスピーディーに」 ➝ Doployの頻度を定量トラッキングする 

活⽤⼒UPして、常時AI起点に実装を試みるために ● AI活⽤振り返り会 ○ 活⽤習慣化と、知⾒流通のために ● AI起点Pull Requestの計測 ○ 客観的な評価のために 

No content

No content

● AI起点の場合、ブランチにsuffixを付与したり、Pull Requestにラベルを付与 ● Vibe codingで計測スクリプトを実装 ➝ デイリーで計測 ● 参考情報：実現⽅法の詳細 ○ suffixやラベルの付与⽅法 ■ 「これはAI起点で作る」の場合に付与 ■ 付与はRulesで⾏うか、または⼈が付与 ■ suffix例）xxx-by-cursor, xxx-by-claude, etc ○ 「これはAI起点で作る」はどういう基準にしたか ■ 実装またはテストを、まずAIにやってもらう、となっていればOK ● 「これ実装して」「これテスト書いて」➝ その後に⼈が修正 ➝ PR作成完了 ■ 厳密な⽣成割合の計測ではないが、現実的にはこれで問題ないと判断 AI起点Pull Requestの計測 

結果と学び ● 活⽤⼒UPし、AI起点率は80-90%へ 🚀 ○ 会の効能 ■ 「やっていこう！」の呼びかけだけよりも、意識変容できた ■ ⾃然に、⽇常的に、みんな意識できる ■ 獲得した知⾒の流通も起こりやすい ○ 計測の効能 ■ 「今だとチームによって数値に差があるね、埋まるのかな」 「こういうプルリクはAI起点にしにくいのかな」 などの客観的な議論‧対応を、EM中⼼にできた 

⼀⽅でDeployの頻度は、ほぼ横ばいの状態だった ● Pull Requestの作成頻度、Merge頻度、リードタイムなど様々⾒ていた ● 体感では、開発はスピーディーになっている ● が、数値で⾒ると、いずれもほぼ横ばい… 

体感とのギャップはなにか、様々な原因を議論‧分析した ● 確からしい要因が、なかなか掴めなかった ○ ツールの学習曲線で相殺？ ○ Prompt, Rules, Contextの改善可能性？ ○ レビューが重くなっている？ ○ 要件定義の質？ ○ 妨害タスクが実は多い？ ○ タスク並列化ができていない？ ○ etc 

有効度⾼いユースケースと、やや不安定なユースケース 要件定義‧設計 実装〜リリース ✅ 仕様や調査をAIに質問 ✅ PRDやDesign Doc等の初稿を作成 ✅ Branch差分からQA観点の初稿を作成 プログラミング要素強 ✅ 範囲が狭い実装 ✅ モックやデモ、個⼈利⽤ツール、個⼈で保守すればOKなプロダクト ソフトウェアエンジニアリング要素強 ✅ Version up, Migrationなど、既存ロジックの置き換え ✅ iOS実装基にAndroidを実装など、参考実装ありの新規ロジック実装 🔺 参考実装がない新規ロジック実装（やや不安定、だが業務の⼤半） 

有効度⾼いユースケースと、やや不安定なユースケース 要件定義‧設計 実装〜リリース ✅ 仕様や調査をAIに質問 ✅ PRDやDesign Doc等の初稿を作成 ✅ Branch差分からQA観点の初稿を作成 プログラミング要素強 ✅ 範囲が狭い実装 ✅ モックやデモ、個⼈利⽤ツール、個⼈で保守すればOKなプロダクト ソフトウェアエンジニアリング要素強 ✅ Version up, Migrationなど、既存ロジックの置き換え ✅ iOS実装基にAndroidを実装など、参考実装ありの新規ロジック実装 🔺 参考実装がない新規ロジック実装（やや不安定、だが業務の⼤半） ● うまくいく場合はある ● ただし、うまくいかない場合や、 動くけど品質課題がある場合なども多数 ● うまくいかせるために時間を使いすぎて、 全体で相殺されている説が濃厚 

どうしたか ● 何が起こっているかの仮説 ○ 実装を⼤きく任せる、そのための様々な⼯夫をする ➝ 全体で相殺 ○ つまり、⼤きく任せる ➝ 安定的に成功、ができていない ● ⼩さく任せて安定性を担保する ⽅針へ ○ △：どうRulesやContext等⼯夫すれば、全部⼀気にうまくいくか ○ ◯：どのくらい⼩さく分割すれば、安定的に成功する粒度になるか ● 「⼩さく分割してAIに任せる」をチームとして実⾏していくために、 "実装計画" を作るプロセスを導⼊‧標準化した 

実装計画のフォーマットイメージ 

実装計画のフォーマットイメージ 

結果 ● まだ評価中だが、改善傾向が継続中 🚀 ○ PR数など各種メトリクスの上昇や、Deploy頻度の上昇が継続（10-50%） ● 定性的な効能 ○ AIに任せやすい ○ ⼈がレビューしやすい ○ タスク並列の可能性ができやすい ○ ⾃動化の可能性の広がりがありそう ○ LLMが進化するとより有効そう ○ “実装計画” を作るコストはあるが、実装者‧レビュー者の体験は良い 

まとめ 常にAI起点にして開発をスピーディーに！の奮闘過程で得たこと ● AIについて定期的に話す場は有⽤ ○ ⾃然と、⽇常⾏動が変わる、ナレッジが溜まっていく ● 計測による客観的な評価は⼤切 ○ 主観とのギャップが否が応でも判り、真因を探る⾏動に繋げやすい ● Rules, Context等も重要だが、今だと、課題サイズの管理も重要 ○ AIが低品質なアウトプットで⼈の⾜を引っ張る、をなくすために重要 ● ⼈がボトルネックになることも多いが、その防⽌にも、課題サイズ管理は重要 ○ レビュー等が楽になり、AIと⼈との共闘がスムーズになる 

告知 ● 📣 採⽤中です📣 ○ Backend、Mobile、SRE、Platform、ML、 EM、VPoE、PdM、Designer ... ● 🔥プロヒス2025アフターイベント🔥 ○ 9/25（⽊） 18:30〜21:00 ○ 効果があった他の施策など、今回話しきれなかったこと ○ https://youtrust.jp/lp/after-prohis ● 🚀 toCのスーピーディーなデリバリを⽀える、技術的な取り組み 🚀 ○ 10/8（⽔） 12:00〜1300 ○ 実装計画の詳細 ○ https://kauche.connpass.com/event/368490 

ご静聴ありがとうございました