ELYZA_Findy AI Engineering Summit登壇資料_AIコーディング時代に「ちゃんと」やること_toB LLMプロダクト開発舞台裏_20251216

Slide 1

Slide 1 text

AIコーディング時代に toB LLMプロダクト開発舞台裏「ちゃんと」やること齋藤暢郎 (@tarunon)   プロダクト事業部ソフトウェアエンジニアチームマネジャー村⼭卓朗プロダクト事業部機械学習チームマネジャー (@zakktakk)  

Slide 2

Slide 2 text

2 Agenda 本日の流れ 1. 私たちについて 2. ELYZA Worksについて 3. ELYZA Works開発における AI活用 4. 品質維持の取り組み

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

(C) 2025 ELYZA 課題①：AIツールの利⽤者のAIスキルに依存 ● チャットAIが組織で導⼊されているが、個⼈のプロンプトスキルに依存し、活⽤が限定的 ● 活⽤⽅法が共有されず、知識が属⼈化 ● プロンプトの共有だけでは、利⽤の浸透が困難企業のAI活⽤を阻む、2つの課題を解決します ELYZA Worksが解決する課題課題②：⾃社専⽤AIアプリをつくることが困難 ● 業務理解とAI知⾒のある開発/運⽤⼈材の不⾜ ● 個別開発による⾼額な初期コスト ● モデルのアップデート等に伴うプロンプト調整やメンテナンスの負荷 AIスキルに依存することなく利⽤、チームで共有/改善が可能 ● ⾃社業務に特化したAIアプリが業務のプロセスに組み込まれることで、利⽤者‧利⽤範囲が拡⼤ ● AIアプリの内容を確認して質の⾼いものだけを組織に展開 AIの伴⾛により現場で⾃社専⽤AIアプリの開発/運⽤が可能 ● 専⾨家のベストプラクティスに基づき、⾃社業務に特化したAIアプリをAIが⾃動⽣成 ● 実際に利⽤する現場社員が主導して、AIに指⽰することで改善が可能 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

(C) 2025 ELYZA ● アプリを利⽤する ○ AIスキルがそこまで⾼くないメンバーがターゲット ○ アプリ作成者が作った品質の⾼いAIアプリを利⽤することができる ● アプリをつくる ○ AI導⼊に熱意のある / AIスキルを持ち合わせているドメインエキスパートがターゲット ○ AIアプリ = LLM処理を内包するフォーム / チャット形式のアプリを作成する 12 課題①：AIツールの利⽤者のAIスキルに依存に対するアプローチスキルの⾼いユーザーがAIアプリを作成し、それ以外のユーザーが利⽤する形で提供機能を分離

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

(C) 2025 ELYZA AIソリューションとELYZA Worksの棲み分け技術的難易度が⾼いかつ影響度の⼤きい業務課題は現状AIソリューションの領域 ELYZA Worksはプロダクト単独で解決可能な課題の幅を広げていく 16 業務への影響度：⼤技術難易度：⾼ (≒コスト：⾼) 技術難易度：低 (≒コスト：低) 業務への影響度：⼩ AIソリューションプロ⼈材による伴⾛で重要スコープの活⽤を推進 ELYZA Works (+ CS伴⾛⽀援) AIアプリを⾃⾛して開発するためのツールを提供し、より多数のスコープで活⽤を推進

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

(C) 2025 ELYZA ELYZA Worksのアーキテクチャアプリケーションの主体はAWS、可変性の⾼い基盤は切り離したアーキテクチャとしている 21 アプリケーション LLMホスティング基盤 Agent 基盤 LLM Hosting / Agentはいずれも技術の潮流が極めて早い領域、スクラップアンドビルドも⾒据えて独⽴性の⾼い構成に Pd⽤ ML処理 A社専⽤ ML処理 ML処理 MCPサーバー

Slide 22

Slide 22 text

(C) 2025 ELYZA ELYZA Worksのアーキテクチャ：Agent基盤の詳細 Vertex AIのエコシステムを中⼼とした構成、Agent ProxyでELYZA Works独⾃仕様を吸収 22 ● Good ○ 最⼩限のシンプルな構成 ○ Agent Proxyを介して分離しているので、Agent側はビジネスロジックを意識しなくて良い ● Motto ○ 認証‧認可部分の多くを⾃前で独⾃実装している ○ Vertex AI Serviceだけでは完結せず、⼀部3rd party Serviceに頼る必要がある ○ （ADKは⾃由度が⾼く、想定通りの制御が難しい）

Slide 23

Slide 23 text

(C) 2025 ELYZA ELYZA Worksのアーキテクチャ：LLMホスティング基盤の詳細 GKEベースの推論基盤を構築、70BサイズのLLM運⽤実績あり 23 ● Good ○ Kubernetesを採⽤することで環境のポータビリティを担保 ● Motto ○ モデルバイナリが超巨⼤なため、スケールアップにリードタイムがかかる ○ (ELYZAが利⽤している国内リージョンでは) GPUリソースが奪い合いの状態で安定確保が難しい

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

(C) 2025 ELYZA ELYZA Worksのアーキテクチャプロダクト (ELYZA Works) とAIソリューションを同⼀基盤 / サービスで提供している 27 プロダクト向けのML処理と同様にソリューション向けのカスタムML処理を提供 Pd⽤ ML処理 A社専⽤ ML処理 AIソリューション顧客向け画⾯ callされるML処理は異なるが、ユーザーが触るアプリケーションは(ほぼ)同じ AIプロダクト顧客向け画⾯

Slide 28

Slide 28 text

(C) 2025 ELYZA Platform ServiceとしてのELYZA Works プロダクト (ELYZA Works) とAIソリューションを同⼀基盤 / サービスで提供している 28 ：AIプロダクトのみ提供：AIソリューションのみ提供：両⽅の顧客に提供共通機能認証/認可 Rate Limit 暗号化ロギング汎⽤ML処理顧客特化のML パイプライン Subsystems ML Processing Backend Frontend バッチ処理ドキュメント管理プロダクト固有機能契約管理請求管理プロダクト固有機能アプリ⾃動⽣成合成データ⽣成共通機能ユーザー管理アプリ利⽤アプリ作成利⽤状況確認プロダクト固有機能請求管理

Slide 29

Slide 29 text

(C) 2025 ELYZA 29 プロダクト⇔ソリューションのシナジーが⽣み出しやすい構造 ■ ソリューション事業にとって ● 顧客においてプロダクトからのアップセルが狙いやすい ● PoCが「やって終わり」にならない ■ プロダクト事業にとって ● ソリューション顧客とプロダクト検証ができる ● 顧客の業務‧課題を深く理解しプロダクト改善に還流できる ● 顧客においてソリューションとのクロスセルが狙いやすい ■ 顧客にとって ● プロダクト⇔ソリューションのシームレスな体験 ● データが同じ場所に蓄積されるため、再利⽤しやすいプロダクトとソリューションが同居することのメリット

Slide 30

Slide 30 text

(C) 2025 ELYZA 30 プロダクトマネジメントの観点 1. 要求の優先順位付けが難しい ● プロダクトとソリューションそれぞれで追うべき指標が異なる中で、⼀様に寄せられる要求を横並びで優先順位付けする必要がある 2. オーナーシップの曖昧化 ● ⽚⽅の事業でしか利⽤しない機能の責任境界が曖昧になり、結果として機能改善が劣後されてしまう 3. ロードマップの予測可能性低下 ● ソリューションは緊急度が⾼く対応を求められるがあり、突発的な割り込みタスクが発⽣しうる ● 当該タスクが増加すると中⻑期の計画が意味をなさなくなる 1. コードベースの複雑化 ● プロダクトとソリューションそれぞれの固有機能が存在するため、「特定顧客にのみ提供」という条件分岐が各所に発⽣する ● コードベースが複雑になった結果、新機能追加の影響範囲確認‧実装難易度が上がり、⽣産性が下がる 2. 品質保証の難易度が上がる ● ソリューション顧客ごとに異なる設定‧カスタマイズがあり、テストシナリオが爆増する ● 結果としてQAにかかる⼯数も増える（もしくはQAカバレッジが下がる） 3. サービスレベル、セキュリティへの⾼い要求 ● プロダクト顧客に⽐べてソリューション顧客は⾼い SLAや個別のセキュリティ基準への準拠を求める開発の観点プロダクトとソリューションが同居することのデメリット

Slide 31

Slide 31 text

(C) 2025 ELYZA 31 プロダクトマネジメントの観点 1. 要求の優先順位付けが難しい ● プロダクトとソリューションそれぞれで追うべき指標が異なる中で、SaaS / PaaSに寄せられる要求を横並びで優先順位付けする必要がある 2. オーナーシップの曖昧化 ● 片方の事業でしか利用しない機能の責任境界が曖昧になり、結果として機能改善が劣後されてしまう 3. ロードマップの予測可能性低下 ● ソリューションは緊急度高い対応が求められるケースもあり、突発的な割り込みタスクが発生しうる ● 割り込みが常態化すると中長期の計画が意味をなさなくなる 1. コードベースの複雑化 ● プロダクトとソリューションそれぞれの固有機能が存在するため、「特定顧客にのみ提供」という条件分岐が各所に発⽣する ● コードベースが複雑になった結果、新機能追加の影響範囲確認‧実装難易度があがり、⽣産性が下がる 2. 品質保証の難易度が上がる ● ソリューション顧客ごとに異なる設定‧カスタマイズがあり、テストシナリオが爆増 ● 結果としてQAにかかる⼯数も増える（もしくはQAカバレッジが下がる） 3. サービスレベル、セキュリティへの⾼い要求 ● プロダクト顧客に⽐べてソリューション顧客は⾼い SLAや個別のセキュリティ基準への準拠を求める開発の観点プロダクトとソリューションが同居することのデメリット ELYZAの開発チームが直⾯しているハードルを乗り越えるための地道な取り組みについて、この後お話しします

Slide 32

Slide 32 text

Slide 33

Slide 33 text

(C) 2025 ELYZA 齋藤暢郎(@tarunon) ● 2014 - 2016 ○ LINE福岡株式会社ファミリーアプリ/本体iOSアプリの開発 ● 2016 - 2019 ○ 株式会社メルカリ US/JPでiOSアプリの開発 ● 2019 - 現在 ○ 株式会社ELYZA サービス開発に従事。推論学習以外のシステム開発を全般担当。現在はソフトウェアエンジニアグループのマネージャー。⾃⼰紹介 33

Slide 34

Slide 34 text

(C) 2025 ELYZA 34 ● コーディング速度は上がる ○ 引き換えに、検証が重くなる ○ コーディングが早くなれば⽐率として増えるのは当然 ○ 検証の量が増えてトータルの⽣産量は横ばい、となってないだろうか？ ● 検証の効率化や、開発全体の再現性が重要に ○ 古典的な⾃動化 ○ ClaudeCodeのカスタムコマンド ● ELYZAの開発チームの⽣産量推移 ○ 概ね1.5~1.6倍で推移 ○ ※メンバー数 5->6 開発においてAIを活⽤するということ AI活⽤ ↔ 検証のサイクルを確実‧⾼速に週あたりマージしたPR数の遷移

Slide 35

Slide 35 text

Slide 36

Slide 36 text

(C) 2025 ELYZA 36 古典的な⾃動化 (1/3) その他古典的なアプローチにより検証の効率化や、開発全体の再現性を⾼める ● Lint, Formatを徹底 ○ eslint-pluginで実現できないFormatter をClaudeCodeで⽣成（お試し中） ● 差分に対してのCI (Format, Build, Test) ● git-ﬂow ○ develop ← (QA)ーfeature/** ○ feature/**← (CodeReview) ーwork/** ● featureブランチごとの開発環境

Slide 37

Slide 37 text

(C) 2025 ELYZA 37 古典的な⾃動化 (2/3) その他古典的なアプローチにより検証の効率化や、開発全体の再現性を⾼める ● Lint, Formatを徹底 ○ eslint-pluginで実現できないFormatter をClaudeCodeで⽣成（お試し中） ● 差分に対してのCI (Format, Build, Test) ● git-ﬂow ○ develop ← (QA)ーfeature/** ○ feature/**← (CodeReview) ーwork/** ● featureブランチごとの開発環境

Slide 38

Slide 38 text

(C) 2025 ELYZA 38 古典的な⾃動化 (3/3) ● Lint, Formatを徹底 ○ eslint-pluginで実現できないFormatter をClaudeCodeで⽣成（お試し中） ● 差分に対してのCI (Format, Build, Test) ● git-ﬂow ○ develop ← (QA)ーfeature/** ○ feature/**← (CodeReview) ーwork/** ● featureブランチごとの開発環境その他古典的なアプローチにより検証の効率化や、開発全体の再現性を⾼める

Slide 39

Slide 39 text

Slide 40

Slide 40 text

(C) 2025 ELYZA 開発環境の⾃動追加/削除 (2/3) 40 PR #8819 迅速な検証を⾏うために、開発環境をPRに連動して⾃動作成/削除（最⼤5個） PR #9012 PR #9161 PR Open => Terraform Apply & Deploy Draft PR Open => Terraform Apply & Deploy Draft PR Open => Terraform Apply & Deploy

Slide 41

Slide 41 text

Slide 42

Slide 42 text

(C) 2025 ELYZA 42 ⽇々の業務はClaude Codeでカスタムコマンド化し、チーム内で作業の再現性を上げる Claude Codeカスタムコマンド 1. ローカル開発 /ﬁnalize 2. PR作成 3.セルフレビュー 4.QA準備 5.リリース準備 /create-pr /code-review /create-qa /release-precheck ローカルの差分箇所に対してのCIチェックを動かす & フォーマットエラーなどの必要な修正を⾏う現在の作業を適切な単位にコミットし、新しいPR にまとめてDraft PRをつくる PRに対してコードレビューを⾏い、改善提案をPR中にコメントする（セルフチェック⽤） featureブランチに対して developとの差分から必要なQA項⽬のドラフトを作成する⼈⼿で⾏なっていたリリース時のチェック項⽬確認を（問題がない限りは）⾃動で実⾏

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

(C) 2025 ELYZA 45 ● テストを維持できる仕組みづくり ○ /code-review により、テスト記載がない、或いは不適切なテストについての指摘を実⾏ ○ 上記指摘からテストの記載、改善まで進められる ● feature/** <- work/** のPRは、Unit Testの通過が必須 ● api ○ Serviceレイヤを中⼼にテストを記載 ● 70~95%程度のカバレッジ ● web ○ コンポーネント（atoms, molecules） ● 60~80%程度のカバレッジ ○ 今後reducerやmiddlewareのテストが必要 ● 基盤のみテストを追加した状況各種テストの充実 (1/3) Unit Test

Slide 46

Slide 46 text

(C) 2025 ELYZA 46 ● 開発チーム⾃らPre QAを実施 ○ その上で、E2Eテストの追加/メンテナンスも⾏う ● featureブランチごとに開発環境が独⽴しており、安定したE2E Testの運⽤とメンテナンスが可能 ● 基本的な機能利⽤のシナリオはほぼ網羅 ● Playwright Test Agentsを使った取り組みが進⾏中（そのうち技術ブログ出します） ● develop <- feature/** のPRは、E2E Testの通過が必須 ● リリース前後でstg/prodでも実施各種テストの充実 (2/3) E2E Test

Slide 47

Slide 47 text

(C) 2025 ELYZA 47 ● ELYZA Worksで提供するアプリや、Solutionの成果のリグレッションテスト ● アプリの⼊⼒と想定される出⼒をyaml形式で定義 ● リリース前に⼀括実⾏し、結果を編集距離で判定、リグレッションテストとして実施 ○ 共通モジュールの変更や、モデルのアップグレードによる ● 完全⼀致 or Levenshtein距離ベースで成功/失敗判定する各種テストの充実 (3/3) ML Regression Test

Slide 48

Slide 48 text

Slide 49

Slide 49 text

(C) 2025 ELYZA ● 3. DesignDoc AIレビュー ○ Notion AIを活⽤。DesignDocチケットのテンプレートにAIブロックを設置 ● 精度はまだまだ改善の途上 ● 実装含めてレビューできるClaude Codeに移⾏中 ○ OWASP ASVS v5.0/OWASP LLMSVS v0.1 に基づいたチェックを⾏う 49 AI x セキュリティ (2/3) セキュリティの取り組み

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

(C) 2025 ELYZA ● ⼀部業務はELYZA Worksを活⽤ ● 活⽤例1. Redashのクエリつくるくん ○ ユーザーの動向や、障害の調査の際にRedashで実⾏するクエリを組み⽴てるのに利⽤ ○ 開発だけでなく、プロダクトチーム全体で⼀番⼈気のアプリ ● 活⽤例2. 障害‧復旧速報メール⽂⾯作成⽀援, お客様向け障害報告下書き作成 ○ 障害発⽣時の速報や、対応完了後の報告書の作成に利⽤ ○ Prod環境が障害で動かない場合、そのまま利⽤できない弱点あり😂 52 ELYZA Worksを活⽤した品質保証の取り組み ELYZA Worksの活⽤

Slide 53

Slide 53 text

(C) 2025 ELYZA まとめ 53 ● AI活⽤の背景 ○ ELYZA WorksはSaaSプロダクトとソリューションの提供基盤という2つの側⾯を持ち合わせている ○ 開発⽣産性と品質の両取りを満たすような開発が現場には求められている ● 開発⽣産性向上の取り組み ○ ドキュメントファーストな取り組みを⾏い、AIコーディングの活⽤範囲と精度を向上 ○ ClaudeCodeのコマンドをチームで共有し、チーム全体で⽣産性を向上 ● 品質向上の取り組み ○ 各種テストの充実 ○ AIを活⽤した、より上段からのセキュリティ対応の実施 ○ ⾃らQAを⾏い、E2E Testへの反映を⾏う AIとの協働では地道な「ちゃんとやる」の積み重ねが⼤切

Slide 54

Slide 54 text

最後に、少し宣伝

Slide 55

Slide 55 text

▶ カジュアル⾯談はページ下部の概要欄より！まずは気軽に話しませんか？（オンライン or リアルOK）カジュアル⾯談実施中 ● ソフトウェアエンジニア（フルスタックエンジニア） ● 機械学習エンジニア（プロダクト事業） ● 機械学習エンジニア（ソリューション事業） ● リサーチャー / リサーチエンジニア ● プロダクトマネージャーなど、全⽅位で採⽤しています。 ELYZAは絶賛、仲間を募集しています