Tweet
Tweet

Slide 1

Slide 1 text

生成AIに振り回された3か月間の成功と失敗 Developer Productivity Unit / イネーブリンググループ 鵜木 義秀

Slide 2

Slide 2 text

@nokki_y 株式会社リンクアンドモチベーション イネーブリンググループ 鵜木義秀（うのきよしひで） #Vue.js #TypeScrip #Design #Vue.js_Japan_User_Group 自己紹介

Slide 3

Slide 3 text

会社紹介

Slide 4

Slide 4 text

プロダクト紹介

Slide 5

Slide 5 text

モチベーションクラウド

Slide 6

Slide 6 text

3ヶ月前はAIに対して斜に構えていた おれ、プロンプトエンジニアじゃないし。 おれはアプリケーションエンジニアだし。 それAIじゃなくても良くない？ AI使わなくてもユーザー価値のある アプリ作れるし。

Slide 7

Slide 7 text

お酒の勢いで登壇テーマを生成AIに決めた 登壇テーマ迷ってるんですよねぇ。 いや、でもAIとか全然わからないですよ。 最近良く困ってるライブラリのアップデートを AIで解決した事例とかいいじゃん！ OpenDevinが流行ってるらしいよ！

Slide 8

Slide 8 text

お酒の勢いで登壇テーマを生成AIに決めた 「わからないからやらない」は 「やらない理由にならないでしょ！」 そもそも、エンジニアはできないことを できるようにするのが楽しいんじゃん！ たしかに・・・。 ここでやらないと一生やらなそうだ・・・。 やります！

Slide 9

Slide 9 text

実は同じ境遇の同期と一緒にやった

Slide 10

Slide 10 text

「生成AIはもっともっと人間らしく扱うと良いかも」

Slide 11

Slide 11 text

01 事例_1 OpenDevinを使い「ライブラリアップデート工数の削減」に取り組んでみた 02 事例_2 Difyを使い「ESLintのIgnore解消工数の削減」に取り組んでみた 03 まとめ 成果と学び、これから取り組むこと

Slide 12

Slide 12 text

01 事例_1 「ライブラリアップデート工数の削減」に取り組んでみた

Slide 13

Slide 13 text

OpenDevinは自律的なAIアシスタント LLM 指示 途中経過・完了結果 入力 出力 OpenDevin 情報を拡張 コード取得・修正 ・テスト実行 コード情報 ・テスト実行結果 Source Code < / > Chat の入力内容に応じて、自律的に処理する

Slide 14

Slide 14 text

OpenDevinは自律的なAIアシスタント 画像出典: © OpenDevin, MITライセンス リンク: OpenDevin GitHubリポジトリ

Slide 15

Slide 15 text

ライブラリアップデート時に必要なコードの修正をさせたかった BEFORE After AI 工数削減 use Devin 01 アップデート情報の確認 02 コードの修正 対象ライブラリの更新 API変更に伴うリファクタリング 依存関係に応じた周辺ライブラリの更新 03 動作の確認 手動テストの実行と動作確認 自動テストの実行と動作確認 01 アップデート情報の確認 02 コードの修正 対象ライブラリの更新 API変更に伴うリファクタリング 依存関係に応じた周辺ライブラリの更新 03 動作の確認 手動テストの実行と動作確認 自動テストの実行と動作確認

Slide 16

Slide 16 text

結果は失敗 失敗：成功率 5%以下 After 01 アップデート情報の確認 02 コードの修正 対象ライブラリの更新 API変更に伴うリファクタリング 依存関係に応じた周辺ライブラリの更新 03 動作の確認 手動テストの実行と動作確認 自動テストの実行と動作確認

Slide 17

Slide 17 text

失敗：成功率 5%以下 ## タスクi S npmライブラリのアップデート ## 目的i S 対象のnpmライブラリを最新のバージョンに更新し、
 APIの変更に伴うソースコードのリファクタリングを行って
 既存のコードベースと互換性があることを確認すること。 ## 対象ライブラリi S ライブラリ名: [ライブラリ名] ## ライブラリのリリースノート: ``` ### [ライブラリ名] リリースノート #### バージョン 1.x.x - [変更内容] ``` ## 指示: 1. 現在のライブラリバージョンの確認: 2. ライブラリの更新: 3. API変更の確認とリファクタリング: 4. 互換性チェック: Prompt 結果は失敗

Slide 18

Slide 18 text

ライブラリ APIの変更情報 マイグレーション手順 アプリケーションコード コーディングルール 技術スタック レイヤー構造 依存ルール アプリケーションコードに関する情報が不足していた

Slide 19

Slide 19 text

アプリケーションコードに関する情報が不足していた ライブラリのアップデート作業よろしく！ ライブラリのアップデート情報はこれだよ！ ここがコーディングルールに従ってないです。 依存関係を考えるとここの修正も必要です。 コードを見た感じこのあたりを 修正すればいいのかな。やってみよう！ ・・・　これでどうでしょう？ そんなの聞いてないんだけど・・・

Slide 20

Slide 20 text

仮説_1 （アプリケーションコードに関する情報も含めて） 作業内容を具体的に指示することが重要かもしれない

Slide 21

Slide 21 text

01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 After this...

Slide 22

Slide 22 text

アプリケーションコードに関する情報を具体的にして再挑戦 After 01 アップデート情報の確認 02 コードの修正 対象ライブラリの更新 API変更に伴うリファクタリング 依存関係に応じた周辺ライブラリの更新 03 動作の確認 手動テストの実行と動作確認 自動テストの実行と動作確認 失敗：成功率 ほとんど変わらない

Slide 23

Slide 23 text

アプリケーションコードに関する情報が不足していた 思ってたのと違うぞ。 アプリケーションコードに関する情報はこちら！ 改めて修正お願い！ 指示にあったアプリケーションコードの情報と 異なるコードが有るぞ？ちょっと考えて修正してみるか。 ・・・　これでどうでしょう？

Slide 24

Slide 24 text

01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 After this... 検証失敗

Slide 25

Slide 25 text

01 事例_1 作業内容を具体的に指示することが重要かもしれない 工数の削減対象をESLintのIgnore解消に変更

Slide 26

Slide 26 text

01 事例_1 作業内容を具体的に指示することが重要かもしれない 工数の削減対象をESLintのIgnore解消に変更 利用ツールをOpenDevinからDifyに変更

Slide 27

Slide 27 text

自律性を活かしにくい状況になった ライブラリのアップデート 対象のライブラリによって 作業手順が異なる 不確実性が大きいため 自律性が活かしやすい ESLintのIgnore解消 ルールが異なっても 作業手順は大体同じ 不確実性が小さいため 自律性が活かしにくい

Slide 28

Slide 28 text

02 事例_2 「ESLintのIgnore解消工数の削減」に取り組んでみた

Slide 29

Slide 29 text

DifyはLLMアプリをGUIで開発できるプラットフォーム Source Code < / > 修正 ・テスト実行 コード情報 ・テスト実行結果 Assign Review ・Merge Source Code Edit Server Dify Workflow Github Repository Commit ・Pull Request作成 コード取得・修正 ・テスト実行 コード情報 ・テスト実行結果 LLM 入力 出力

Slide 30

Slide 30 text

Workflowの構成

Slide 31

Slide 31 text

対象プロジェクトのチェックアウトとターゲットファイルの取得 対象プロジェクトのチェックアウト ターゲットファイルの取得

Slide 32

Slide 32 text

Ignoreの削除とESLintの実行と確認 対象プロジェクトのチェックアウト ターゲットファイルの取得 Ignoreの削除 ESLintの実行(Auto Fix Mode)と確認

Slide 33

Slide 33 text

LLMによるファイルの修正と更新、そしてPull Request作成 対象プロジェクトのチェックアウト ターゲットファイルの取得 Ignoreの削除 ESLintの実行(Auto Fix Mode)と確認 LLMによるファイルの修正と更新 Pull Request作成

Slide 34

Slide 34 text

コードレビュー以外の作業を委譲させたい BEFORE After AI 工数削減 use Dify 01 Ignoreコメントの削除 02 修正箇所の確認 ESLintの実行 エラー内容の確認 03 コードの修正 04 Pull requestの作成 動作の確認 Commit・Pull Requestの作成 05 コードレビュー 01 Ignoreコメントの削除 02 修正箇所の確認 ESLintの実行 エラー内容の確認 03 コードの修正 04 Pull requestの作成 動作の確認 Commit・Pull Requestの作成 05 コードレビュー

Slide 35

Slide 35 text

BEFORE After 01 Ignoreコメントの削除 02 修正箇所の確認 ESLintの実行 エラー内容の確認 03 コードの修正 04 Pull requestの作成 動作の確認 Commit・Pull Requestの作成 05 コードレビュー 運用が実現的な成功率になった 5分程度の時間で1PRが作成可能に 成功：成功率 50%以上

Slide 36

Slide 36 text

01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 After this... 検証完了

Slide 37

Slide 37 text

Dify 20分に1PR × エンジニア数 5分に1PRすると1時間12PR 新たな問題：レビューコスト

Slide 38

Slide 38 text

Dify 20分に1PR × エンジニア数 新たな問題：レビューコスト エンジニアのレビュー工数が 1PRあたり10-20分程度 必要な状況になっていた。 5分に1PRすると1時間12PR

Slide 39

Slide 39 text

この時なにが起きていたか「AIを信用できない」 レビュー時に行われていたこと ローカル環境での動作確認 レビュワーの心情 「AIによる修正はどこか不安になるため、慎重にレビューしたい」

Slide 40

Slide 40 text

「AIによる修正はどこか不安になる」を更に掘り下げる 1_ 人間には期待値があるが、AIには期待値がない 例えば「○○さんが修正したなら、おそらくこの辺は大丈夫であろう」 といった期待値が人間に対してはあるが、AIに対してはない。 2_ AIは実装者として責任を取ることができない 実装車となるAIが責任を取ることができない分、レビュアーとしての 責任感いつも以上にが強くなる。

Slide 41

Slide 41 text

01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 対人間以上に信頼度を高めるための工夫が必要かもしれない 検証完了

Slide 42

Slide 42 text

02 事例_2 対人間以上に信頼度を高めるための工夫が必要かもしれない 作業プロセスが間違っていないことを証明する 十分にテストが実施されていることを証明する

Slide 43

Slide 43 text

ただ、、 「対人間以上に信頼度を高めるための工夫が必要かもしれない」については、 本日の登壇までに機能リリースして、効果を検証するに至りませんでした。 そのため、この先の内容はソリューションの仮説になります。 この検証結果は追って、弊社のテックブログで公開したいと考えています。

Slide 44

Slide 44 text

作業プロセスが間違っていないことを証明して信頼度を高める

Slide 45

Slide 45 text

作業プロセスが間違っていないことを証明して信頼度を高める 「正しい作業プロセスに基づいて修正されたかどうか」 を明記することで、信頼度を高める。

Slide 46

Slide 46 text

十分にテストが実施されていることを証明して信頼度を高める インスタントテストとは その場限りのテストコード。 つまり、そのときLLMが修正した関数の品質を担保するためだけに 使用するテスト。 その場限りのテストコードの作成とそのテストにより担保される 観点をコメントさせる仕組み。

Slide 47

Slide 47 text

十分にテストが実施されていることを証明して信頼度を高める 「正しいテスト観点に基づいて修正されたかどうか」 を証明することで、信頼度を高める。

Slide 48

Slide 48 text

01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 対人間以上に信頼度を高めるための工夫が必要かもしれない 検証完了 検証中

Slide 49

Slide 49 text

03 まとめ 成果と学び、これから取り組むこと

Slide 50

Slide 50 text

本日までに得られた成果 削減された工数 1ファイルあたりの修正工数: 20分 5分 1ファイルあたりのレビュー工数: 20分 取り組み中 開発者体験の変化 能動的に修正 受動的にPull Requestを確認するのみ

Slide 51

Slide 51 text

今回の取組だけを見ればインパクトはわずか 今回の経験を転用して、以下のような改善を自動化していく TypeScriptへの移行 Unitテストカバレッジの向上 リアーキテクチャに伴う横断的なリファクタリング ライブラリのアップデート ただし重要なのはこれから

Slide 52

Slide 52 text

今後の展開を見据えて更に検証したいこと 1_ 膨大な量のトークンを入力できるモデルの検証や活用 例えばアプリケーションコードの情報をより多く入力することで 生成AIが対応できる範囲を広げていきたい。 2_ 自社データの活用 まずはコードレビューの結果を蓄積し活用していきたい。

Slide 53

Slide 53 text

今後の展開を見据えて更に検証したいこと TypeScriptへの移行 Unitテストカバレッジの向上 リアーキテクチャに伴う横断的なリファクタリング ライブラリのアップデート

Slide 54

Slide 54 text

今後の展開を見据えて更に検証したいこと TypeScriptへの移行 Unitテストカバレッジの向上 リアーキテクチャに伴う横断的なリファクタリング ライブラリのアップデート 膨大な工数が必要になるため 実現可能性を感じていなかった

Slide 55

Slide 55 text

今回、AIの積極的に活用したことで AIを知り、これまで解消できていなかった課題を 解消できる可能性が生まれた。

Slide 56

Slide 56 text

3ヶ月前はAIに対して斜に構えていた おれ、プロンプトエンジニアじゃないし。 おれはアプリケーションエンジニアだし。 それAIじゃなくても良くない？ AI使わなくてもユーザー価値のある アプリ作れるし。

Slide 57

Slide 57 text

新しい技術が登場した時 触ってみて初めて分かることありますよね？ AI触ってますか？ そこには新しい発見やエンジニアとしての 楽しみがあるかもしれません。

Slide 58

Slide 58 text

Vue Fes Japan 2024 Otemachi PLACE HALL & CONFERENCE
 2024.10.19 SAT

Slide 59

Slide 59 text

No content