Claude Actions + Cursor による開発効率化

2026/3/24に、データ推進室イベントで発表した上津の資料になります。

Transcript

1. © Recruit Co., Ltd. All Rights Reserved 株式会社リクルート データ推進室 SaaSデータソリューション部 データエンジニアリンググループ 上津 将⼠ 2026/03/24 Claude Actions + Cursor による開発効率化
2. © Recruit Co., Ltd. All Rights Reserved Agenda 1. Introduction 2. 開発フェーズ別LLM利⽤事例 3. LLMの効果と課題 4. 移⾏中のAIを軸とした開発フロー 2
3. © Recruit Co., Ltd. All Rights Reserved Agenda 1. Introduction 2. 開発フェーズ別LLM利⽤事例 3. LLMの効果と課題 4. 移⾏中のAIを軸とした開発フロー 3
4. © Recruit Co., Ltd. All Rights Reserved データ推進室 SaaSデータソリューション部 データエンジニアリンググループ  2024-2026 『Air ビジネスツールズ』のFAQチャットボットの開発 2025-2026 Finance 事業のバックエンドのAPI開発 上津 将⼠ Uetsu Masashi Profile 経歴  所属 4
5. © Recruit Co., Ltd. All Rights Reserved Agenda 1. Introduction 2. 開発フェーズ別LLM利⽤事例 3. LLMの効果と課題 4. 移⾏中のAIを軸とした開発フロー 5
6. © Recruit Co., Ltd. All Rights Reserved フェーズ 入力 出力 既存実装理解 対象コードベース全体 → アーキテクチャ解説・データフロー図 (複雑な依存関係の紐解き ) 要件定義 企画メモ・ビジネス要求 (Confluence) → 機能仕様書・エッジケースの洗い出し (曖昧な仕様の構造化と壁打ち ) 設計 機能仕様書 ＋ 関連する既存コード → 技術設計書 (API定義 / DBスキーマ) (既存の設計思想を踏襲した提案 ) 実装 技術設計書 ＋ 類似コンポーネント → プロダクションコード ＋ 単体テスト (カバレッジ担保) レビュー PR差分 ＋ チームのコーディング規約 → ロジックの不備指摘・リファクタリング案 (属人性の排除と機械的なルールの自動チェック ) エラー調査 スタックトレース → 解決策の提示・コード修正案 6 開発フェーズ別LLM利⽤事例 開発のあらゆるフェーズでLLMを利用
7. © Recruit Co., Ltd. All Rights Reserved Agenda 1. Introduction 2. 開発フェーズ別LLM利⽤事例 3. LLMの効果と課題 4. 移⾏中のAIを軸とした開発フロー 7
8. © Recruit Co., Ltd. All Rights Reserved 8 「ふんわりした要望」を「堅牢な技術仕様」へ変換 企画担当者のメモ (曖昧な要件 ) 「新しい決済機能を追加したい。ユーザー が購入ボタンを押したら、在庫を減らして、 外部の決済APIを叩く。もし失敗したら在 庫を戻す感じでよろしく！」 AIへのプロンプト 「企画要件を詰めて仕様を検討してくださ い。実装上懸念があれば合わせて提示し てください。」 APIタイムアウト : 決済APIからの応答がタイ ムアウトした場合、決済完了か未完了かの状 態判定（不整合）をどう解決しますか？ 在庫の競合 : 同時に複数人が最後の 1つの 在庫を購入しようとした時の排他制御（悲観 的ロック等）が要件から漏れています LLMによる 構造化
9. © Recruit Co., Ltd. All Rights Reserved 9 LLMによる「開発⼒」の底上げ LLMのコーディング支援による、 1人当たりアウトプットの劇的な増加 3ヶ月間で5件以上実装者を対象とした PR消化数で比較 期間 2024/12 - 2025/2 14.3件 / 人 計 143件 / 10人 期間 2025/12 - 2026/2 20.6件 / 人 計 165件 / 8人 初期実装の自動完了 仕様やプロンプトを渡すだけで、ベースとなる機能の 初期実装が丸ごと完了。「ゼロからコードを書き始め る」時間が事実上消滅 「空気」を読む実装 既存ファイルをコンテキストとして渡すことで、チーム 独自のアーキテクチャや命名規則、コーディング ルール等をAIが踏襲。「書き直し」の手戻りを防止。 テスト生成のハードル低下 人間が面倒くさがりがちな「境界値・異常系のテスト コード」も、実装とセットで即座に生成。カバレッジを 保ったまま開発速度が向上。 生産性 1.4倍 (+44%)
10. © Recruit Co., Ltd. All Rights Reserved 10 待機時間ほぼゼロの「AIファースト‧レビュー」 変更概要とアーキテクチャ このPRは決済フローにおける XXの追加で す。Terraform側でのジョブ追加と、 Python 側での実装が同期しています。 ✨ 良かった点 ・トランザクションの境界が明確で素晴らしい です 👍 ・テストケースでエッジ値（境界値）がしっかり 網羅されています 👏 🛠 改善点・トリアージ 🔴 【高】必須対応: N+1クエリの発生箇所 （user_repository.py L45） 🟡 【中】 推奨対応: 共通化できそうなバリデーション ロジック 🔵 【低】IMO: 変数名の微修正 AI Review リードタイム約 5分 PR作成から一時レビューまで コンテキストスイッチを排除 AIの一次レビューによる レビュアー負荷の軽減 　AIコメント割合 68% 　100件のPRのコメントを集計 　AI: 269件、Author以外の人: 121件 レビュイーの心理的安全性の確保
11. © Recruit Co., Ltd. All Rights Reserved 11 AIは万能ではない：現場で直⾯している3つの壁と対策 1. 非機能要件の不在（「動けばいい」の限界） • 課題: 機能要件には忠実だが、暗黙的な非機能要件を満たさない • 具体例 : 処理データ量に対する最適化やレイテンシ制約の考慮漏れ • 対策: プロンプトや .cursorrules に制約を明文化 2. AI特有のオーバーエンジニアリング • 課題: 汎用的で「綺麗な」設計を求めすぎ、現在のプロダクトに対して複雑すぎるコードを生成 • 具体例 : 小さな機能に過度な抽象化を適用し、コード量と認知負荷を増大させる • 対策: 「YAGNI原則」を人間が指示 3. 「AI可読性」と「人間可読性」の乖離 • 課題: AIにとっては処理しやすいが、人間にはメンテナンスしにくい構造が生まれる。 • 具体例 : 冗長で説明的なだけの「無駄なコメント」の増殖。巨大でフラットな設定ファイル。 • 対策: 「人間がメンテナンスするコードであること」を前提に、可読性ガイドラインを遵守させる
12. © Recruit Co., Ltd. All Rights Reserved Agenda 1. Introduction 2. 開発フェーズ別LLM利⽤事例 3. LLMの効果と課題 4. 移⾏中のAIを軸とした開発フロー 12
13. © Recruit Co., Ltd. All Rights Reserved 要件定義 13 これからのAIエンジニアリング Issue作成 レビュー 仕様 実装 設計 テスト 企画・判断は人 ビジネス価値の 定義・論点整理 「意図」と「振る舞い」の最終 担保 動作確認 コンテキストを人が作り プロダクトをAIが形にする 実務・詳細化はAI 抜け漏れ検知・壁打ち エッジケースの提示 GitHub / Cursor上での自律 的なコード生成・テスト