Slide 1

Slide 1 text

ソフトウェアエンジニアと AIエンジニアの役割 分担についてのある事例 Encraft #22 on 2025/12/23

Slide 2

Slide 2 text

© Knowledge Work Inc. 自己紹介 2009年 博士課程中退(音声認識・文字認識) 2009年〜 チームラボ株式会社で主にバックエンド開発 2021年〜 株式会社Poeticsで本日紹介するプロダクトを開発 2025年7月〜 経営統合により株式会社ナレッジワークに入社        引き続き同プロダクト開発を行う 犬の散歩と田んぼ作業が好きです 2 2 山本 遼 ソフトウェアエンジニア@ナレッジワーク

Slide 3

Slide 3 text

© Knowledge Work Inc. 3 本発表のテーマ プロダクションサービスの開発において ソフトウェアエンジニアと AIエンジニアが どのように責任範囲を分担すべきか?

Slide 4

Slide 4 text

© Knowledge Work Inc. 本発表で伝えたいこと 責任範囲の境界の引き方を試行錯誤してきた 最終的に境界をぼかし、 モチベーションと担当範囲を一致させた コーディングエージェントがそれを可能にした 4

Slide 5

Slide 5 text

© Knowledge Work Inc. ナレッジワーク AI商談記録について 5

Slide 6

Slide 6 text

© Knowledge Work Inc. AI商談記録の主な機能 6 商談記録の様々な機能を網羅的に提供しています 商談内容の分析レポート自動作成 商談の要約に加え、商談後のネクストアクションの提示、商談へ のフィードバックなどをAIが自動作成します 商談の自動文字起こし オンライン(Web会議・IP電話)・オフライン(対面訪問)のあらゆ る商談をAIにより自動で文字起こしできます CRM/SFAの自動入力 商談内容をセールスフォースに自動入力できます ナレッジワーク AI商談推進への連携 商談内容をナレッジワークAI商談推進のミーティングメモに 自動連携できます

Slide 7

Slide 7 text

© Knowledge Work Inc. AI商談記録の歴史 7 株式会社ナレッジワーク 
 株式会社Poetics 
 商談解析AI「JamRoll」 経営統合 ナレッジワーク AI商談記録 システム統合 本発表はPoetics時代の取り組みも含みます

Slide 8

Slide 8 text

© Knowledge Work Inc. AI商談記録のアーキテクチャ 8 アプリケーション 推論 ワークフロー 学習パイプライン 学習データ モデル更新 商談音声 文字起こし・要約

Slide 9

Slide 9 text

© Knowledge Work Inc. AI商談記録のアーキテクチャ 9 アプリケーション ビジネスロジックを実装 構成要素 ● DB ● APIサーバ ● フロントエンド ● スマホアプリ ● etc... バックエンドの技術スタック ● golang ● terraform

Slide 10

Slide 10 text

© Knowledge Work Inc. AI商談記録のアーキテクチャ 10 学習 パイプライン DNNモデルの学習を行う ● 音声認識モデル ● 話者識別モデル トランスクライバーチーム(※)が教師データ作成し 定期的にモデル重みを再学習 ※文字起こしと話者ラベル付けを行う専門チーム 技術スタック ● python ● AWS CDK

Slide 11

Slide 11 text

© Knowledge Work Inc. AI商談記録のアーキテクチャ 11 アプリケーション 推論 ワークフロー 学習 パイプライン ここが本発表の中心です!

Slide 12

Slide 12 text

© Knowledge Work Inc. ● 入力:商談の録音音声 出力:文字起こし・要約など ● StepFunctionsでバッチジョブを実行 ○ Lambda Function, Fargate Task で個別処理 ● その他の構成要素 ○ ジョブDB ○ イベント送受信 ○ メトリクス・アラート ○ 管理画面 ● 技術スタック ○ python ○ AWS CDK ● オンデマンドのコンピュート処理が多い ● AWSサーバレスインフラに強く依存 推論ワークフローのアーキテクチャ 12

Slide 13

Slide 13 text

© Knowledge Work Inc. 参考記事 13 https://zenn.dev/knowledgework/articles/feb2823365e8cd

Slide 14

Slide 14 text

© Knowledge Work Inc. AI商談記録のアーキテクチャ 14 アプリケーション 推論 ワークフロー 学習パイプライン 学習データ モデル更新 商談音声 文字起こし・要約

Slide 15

Slide 15 text

© Knowledge Work Inc. ソフトウェアエンジニアと AIエンジニアの 責任分担 15

Slide 16

Slide 16 text

© Knowledge Work Inc. ナレッジワークにおける組織構造 16 ナレッジワークではこのように、専門性によって組織を分けています AIエンジニア 
 ソフトウェアエンジニア 
 Engineering Unit に所属 AI Unit に所属 AI SW

Slide 17

Slide 17 text

© Knowledge Work Inc. ナレッジワークにおける組織構造 17 AIエンジニアチーム 
 ソフトウェアエンジニアチーム 
 AI SW プロダクトの正しい動作に責任を持つ 設計やインシデント対応を 組織的に行う仕組みがある プロダクトの推論品質に責任を持つ 精度や速度の向上が チームの目標として設定される

Slide 18

Slide 18 text

© Knowledge Work Inc. チームの仕組みが生む指向性の違い 18 システムの安定性向上・保守性向上への モチベーションと専門性が強い 推論の精度向上や速度向上への モチベーションと専門性が強い システムを改善するモチベーションと専門性に違いがある チームの取り組みがこの違いを生んでいる AIエンジニア 
 ソフトウェアエンジニア 
 AI SW

Slide 19

Slide 19 text

© Knowledge Work Inc. AI商談記録の責任範囲の分担 19 アプリケーション 推論 ワークフロー 学習 パイプライン AI SW

Slide 20

Slide 20 text

© Knowledge Work Inc. AI商談記録の責任範囲の分担 20 アプリケーション 推論 ワークフロー 学習 パイプライン ソフトウェアエンジニ アの責任範囲 AI SW

Slide 21

Slide 21 text

© Knowledge Work Inc. AI商談記録の責任範囲の分担 21 アプリケーション 推論 ワークフロー 学習 パイプライン ソフトウェアエンジニ アの責任範囲 AIエンジニアの 責任範囲 AI SW

Slide 22

Slide 22 text

© Knowledge Work Inc. AI商談記録の責任範囲の分担 22 アプリケー ション 学習 パイプライン ソフトウェアエンジニ アの責任範囲 AIエンジニアの 責任範囲 AI SW ? 推論ワークフロー

Slide 23

Slide 23 text

© Knowledge Work Inc. コンテナで境界を引いた 23 アプリケー ション 学習 パイプライン 推論ワークフロー AIエンジニア:コンテナイメージを作る ソフトウェアエンジニア:システム全体を作る ソフトウェアエンジニ アの責任範囲 AIエンジニアの 責任範囲 AI SW

Slide 24

Slide 24 text

© Knowledge Work Inc. コンテナで境界を引いた結果 24 課題
 よかった点 
 一般的で分業しやすい デプロイが楽 変更時に両チームが同時に動く必要あり 境界を越える変更を避けがちになる

Slide 25

Slide 25 text

そんな中、新プロジェクトがスタート! 「リアルタイム音声認識 API」サービスを作ることに

Slide 26

Slide 26 text

© Knowledge Work Inc. 新プロジェクトの要件 26 リアルタイム音声認識APIサービス ● リアルタイムに音声認識するために、インフラの試行錯誤が必要になった ○ Lambda Function / Fargate Service ○ 処理分割による部分的な並列化 コンテナで境界を引くと、インフラの試行錯誤がしにくいので分担を変える

Slide 27

Slide 27 text

© Knowledge Work Inc. モジュールで境界を引いた 27 推論サービス ジョブキュー ワーカー アプリケー ション 学習 パイプライン AIエンジニア:モジュールを作る ソフトウェアエンジニア:システム全体を作る ソフトウェアエンジニ アの責任範囲 AIエンジニアの 責任範囲 AI SW

Slide 28

Slide 28 text

© Knowledge Work Inc. モジュールで境界を引いた結果 28 課題
 よかった点 
 アーキテクチャ変更が ソフトウェアエンジニアだけで完結 構築時アーキテクチャの試行錯誤ができる 安定性・保守性のための改善がしやすい AIエンジニアからみてブラックボックス化 推論品質を改善したいのはAIエンジニア 触れるのはソフトウェアエンジニア 推論品質の改善が進みにくい

Slide 29

Slide 29 text

© Knowledge Work Inc. 境界を明確にした合理性 ● 専門性を活かした効率的な分担 ● 初期開発では必然的な選択 出てきた課題 ● 境界を超える変更を避けがちになった ● 改善したい人と、改善できる人がずれた ● AIエンジニアは推論を改善したいのにインフラに触れない 2つの境界を振り返って 29

Slide 30

Slide 30 text

そんな中、1件の Pull Requestが AIエンジニアから届いた!

Slide 31

Slide 31 text

© Knowledge Work Inc. 「CIが遅いので高速化してみました」 ● インフラコードにかなり踏み込んだリファクタリング ● Claudeに相談しながら実装したとのこと ● マージしたらデプロイ時間が半分以下に 届いたPR 31

Slide 32

Slide 32 text

コーディングエージェントで障壁が下がった 境界を「ぼかせる」ようになった!

Slide 33

Slide 33 text

© Knowledge Work Inc. AIエンジニア:推論インフラの実装を主導 ソフトウェアエンジニア:枠組み・基盤整備を主導 必要に応じてお互いの領域に越境できる 共同開発体制 - 設計時:DesignDocを相互レビュー - 実装時:Pull Requestを相互レビュー 境界をぼかした 33

Slide 34

Slide 34 text

© Knowledge Work Inc. 境界をぼかした 34 学習 パイプライン アプリケー ション 推論ワークフロー AIエンジニア の責任範囲 ソフトウェアエンジニ アの責任範囲

Slide 35

Slide 35 text

© Knowledge Work Inc. インフラ変更を含む推論速度の向上(AIエンジニア主導) ● 話者識別のGPU処理化 ● 音声認識の並列化 ● 処理時間 120分→10分(1時間音声) それを支える基盤整備(ソフトウェアエンジニア主導) ● インフラ面のレビュー ● ワークフローのリファクタリング ● 負荷試験の計画 ● 安定リリースのための基盤 この体制で実現したこと 35 モチベーションに沿った分担ができるようになった

Slide 36

Slide 36 text

© Knowledge Work Inc. コーディングエージェントが技術的な障壁を下げたことで 境界をぼかし、モチベーションと担当範囲を一致させることができた ● ソフトウェアエンジニア:安定性・保守性 ● AIエンジニア:推論精度・推論速度 まとめ 36

Slide 37

Slide 37 text

皆さんの開発体制においても 当時は合理的だった境界があるかもしれません。 見直すタイミングかも?