KINTO FACTORYから学ぶ生成AI活用戦略

Transcript

1. KINTO FACTORY から学ぶ 生成AI 活用戦略 KINTO テクノロジーズ株式会社 上原直希 1
2. 自己紹介 上原直希 経歴 2024 年7 月にKINTO テクノロジーズ JOIN KINTO FACTORY でバックエンドエンジニアとして 開発・保守運用やっています 得意領域 好きなもの バックエンド Rust Go NeoVim Claude Code パフォーマンスチューニング 2
3. KINTO FACTORY とは サービス概要 お持ちの愛車にTOYOTA 、LEXUS の純正オプションを後付けできるアップグレードサービス リフォーム 内装や外装のリフレッシュ/ 再生 アップグレード 車の基本性能を向上させる パーソナライズ ドライバーに合わせて車を進化 3
4. チーム体制 メンバー構成 マネージャ - 1 名 ディレクタ - 1 名 PdM - 1 名 フロントエンド - 4 名 バックエンド - 3 名 QA エンジニア - 1 名 協力会社 - 数名 4
5. バックエンドで使用されている技術領域 技術スタックの特徴 BFF + マイクロサービスで構築 その他バッチ処理や管理ツールも存在 使用技術 AWS Cloud BFF/API バッチ処理 ECS Lambda SQS S3 Step Functions BFF Aurora MySQL いくつかの マイクロサービス EventBridge Factory User gRPC GraphQL Kotlin Go Rust Docker AWS サーバレス 5
6. Factory で活用しているAI ツール Claude Code エージェント型コーディングツール 特徴 人間との対話を通じてタスクを遂行 高度な思考力による調査・設計・コー ド開発に強み 使い所 新規機能開発などの比較的難易度の高 いタスク インターフェース CLI GitHub Devin AI ソフトウェアエンジニア 特徴 自律的にタスクを遂行 複数のリポジトリを跨いだ調査・分 析・コード開発に強み 使い所 既存のコード改修といった簡単なタス ク 複数レポジトリにまたがるタスク インターフェース ブラウザ Slack GitHub 6
7. 生成AI 活用アプローチ FACTORY が抱える課題への戦略的AI 活用 7
8. FACTORY で抱えていた課題 サービスグロースで増 えていくタスク vs 少人数チーム 複数レポジトリ横断の 開発・調査 様々なレポジトリを巡る コードの旅 技術負債の蓄積 改善タスクが積まれ続ける 8
9. 事例1: サービスグロースで増えていくタスク vs 少人数チーム 何が大変だったか 新規機能開発のため、設計や実装をやるのに考慮点が多く時間がかかる そのようなバックエンドのタスクを、エンジニア3 人 + 協力会社で捌くため余裕がない 解決アプローチ Claude Code を活用 Claude Code の高度な思考力を借りて、調査・設計・コード開発を高速化 新規機能開発だとビジネス的な要求をどうコードに反映するか絶えず意思決定をする必 要がある 人間とAI で壁打ちしながら進める方がやりやすい 9
10. 活用フロー 1/6: 要件整理 DesignDoc 、jira チケットに実現したいことを記述 要件や実装の方向性を定義 10
11. 活用フロー 2/6: 情報連携 背景情報を調査させる MCP を通じてJira や関連ドキュメントを自動取得し、既存仕様や背景について調査させる 必要な作業を記述したプロンプトを事前に準備しコマンド(/investigate) で呼び出す https://zenn.dev/solvio/articles/cefce25e803b50 調査できたらAI の理解が正しいかチェック 方向性を誤っていたら、適宜人間がフォローする 11
12. 活用フロー 3/6: 計画策定 実装計画を立ててもらう AI に実装計画を提案させる 必要な作業を記述したプロンプトを事前に準備しコマンド(/plan) で呼び出す 人間が実装計画をレビューし、必要に応じて軌道修正 12
13. 活用フロー 4/6: 実装 タスク実施 実装計画に応じて実装を進めてもらう 人間は別のタスクを進めつつ、必要であればAI に介入して軌道修正させる 人間が指摘した箇所は、再発防止策をCLAUDE.md に盛り込んでルール化する 13
14. 活用フロー 5/6: PR 作成 PR 提出 Claude Code でPR を自動作成 PR テンプレートに基づいて説明文を自動で作成させる 14
15. 活用フロー 6/6: レビュー対応 GitHub でClaude Code を使ってレビューコメント対応 コメントで @claude でメンションすることで、Claude Code を呼び出す コメントに応じて修正〜レポジトリへのpush までやってくれる 15
16. 事例1 の成果 デプロイ頻度の向上 Claude Code (+ 一部Devin) を活用することでデプロイ頻度が増加 16
17. 事例2: 複数レポジトリを横断するコード調査が大変 何が大変だったか インシデント発生時の影響範囲の調査に時間がかかる マイクロサービス & サービスごとにレポジトリが分かれている バックエンドだけで15 個のGit レポジトリが存在 ついでに改修も大変 解決アプローチ Devin を活用 複数レポジトリ+ 既存のコードベースの調査はDevin が得意 自律的に調査して対応内容を判断、コードを修正してくれるので楽 勝手に色々やった結果、思いもよらぬ修正をされてしまうリスクも低い 17
18. インシデント対応フロー 1/5: インシデント発生 システムで異常が検知される OpenSearch によるエラーの検出 Slack に通知 18
19. インシデント対応フロー 2/5: 自動連携 自動的にZapier がDevin にメンションして調査依頼 Slack メッセージをトリガーに、Zapier が起動 Devin へ調査タスクを投入 19
20. インシデント対応フロー 3/5: 調査実施 Devin が複数レポジトリを横断して調査・結果をSlack に送信 複数レポジトリのコードを横断調査 エラーの根本原因を特定 調査結果をSlack に自動投稿 20
21. インシデント対応フロー 4/5: 修正判断 必要であれば人間がDevin に修正依頼 人間が調査結果を確認 修正の必要性を判断 修正方針を決定 21
22. インシデント対応フロー 5/5: 修正実施 Devin が自律的に修正PR 作成 修正コードの実装 テストの実行 PR の自動作成 22
23. 事例2 の成果 インシデント対応の効率化 アラート発生から約3 分でDevin が調査結果を提示してくれるので、状況をいち早く把握 できるように 人間は本番DB のデータを覗いたり、根本対応を決定するなどAI にはできない作業に集中 できるようになった Devin に一次調査・暫定対応を任せる 23
24. 事例3: 技術負債の蓄積への対応 何が大変だったか 技術負債や改善点は改善タスクとして切られる 日々のタスクで忙殺され改善の時間が取れない 解決アプローチ 改善DAY を作って、Devin + Claude Code と一緒に改善する 改善DAY: 週に1 日、改善タスクに集中する日を作る 予定管理アプリにもMTG が入らないようブロックしておく 24
25. なぜ改善DAY が必要か？ 改善していくには人間の意識が重要 日々のタスクに取り組んでいると、改善へ意識を向けることは難しい 近視眼的になり、長期的にメリットのある改善へ意識が向かない 現状、AI が完全に自律的に動くことはない 人間がAI にタスクを依頼しないと、AI は動かない ただAI を手元に置くだけでは、何も変わらなない 改善DAY があることで、チームとして改善に集中する雰囲気を作れる 「この日は改善DAY だから〜を直そう」という会話が生まれる 人間とAI が協働することで、初めて歩みを進められる 25
26. 事例3 の成果 AI と改善DAY の導入により、改善タスクの消化スピードが向上 26
27. 成果と今後の展望 得られた成果 AI の活用によって開発、改善速度アップ インシデント対応などで発生する調査・改修タスクの負担軽減 やっていきたいこと コーディングルールの整備 AI にコードを書いてもらっていても、アーキテクチャやベストプラクティスから外れてし まう AI に高品質なコードを書いてもらうにはルールが重要 コーディング以外の上流工程でもAI 活用を推し進めていく PRD やDesign Doc 等のドキュメント生成・知見蓄積 27
28. まとめ AI ツールを導入するだけでなく、それを活用する仕組みと文化づくりが成功の鍵 課題1 サービスグロースで増えて いくタスク 解決策 Claude Code 高度な思考力で機能開 発を高速化 課題2 複数レポジトリを横断する 開発・調査 解決策 Devin 自律的な調査・分析を 担わせる 課題3 技術負債の 蓄積 解決策 改善DAY + AI 改善タスクへ意識を向 ける仕組みづくり 28