こんにちは、生成AI研究開発チームのエンジニアリングマネージャーの鳥越です。最近の生成AIのお気に入りの使い方は、好奇心旺盛な小学生の息子の不思議な質問を一緒に聞くことです。「四天王があるのに、五天王がないのはなぜか」「工事現場には春日部ナンバーがなぜ多いのか」「秋休みがないのはなぜか」など、どこで役に立つかわからない知識が増えてますが、なかなか楽しいです。
さて、カケハシでは生成AIを社内活用するだけでなく、プロダクトのエンハンスメントでも組み込みを始めていますが、従来の機械学習(以下ML)を活用したプロダクト開発と、生成AIを活用したプロダクト開発とでは、直面する課題や運用上の論点、それを踏まえたチームの構成が違うなと考えています。生成AIの社内活用の話が続いていますが、本日は少し趣向を変えまして、生成AIをプロダクトに組み込むチームを作る時に抑えておきたいポイントについて、今の考えを書いてみたいと思います。
従来のMLプロダクトの特徴とチーム構成について
まずは、従来のMLプロダクトの特徴と典型的なチーム構成について簡単にまとめます。
明確な責任分界点
従来のMLプロダクトでは、対象となるユースケースが比較的明確に定義できる傾向にありました。例えば以下のようなものです。
- 需要予測：販売数やアクセス数を予測するモデルを開発し、ビジネス判断に活用。
- 推薦システム：ユーザーに対して最適な商品やコンテンツを提示。
- 与信スコアリング：個人や法人の信用リスクを定量的に評価。
これらのユースケースはいずれも、入力と出力が構造化されており、精度の指標も明確なため(KPIの関係性の担保等、deep diveすると難しい点はもちろんありますが)、モデル学習・評価・運用という一連のフローを比較的安定して構築できました。
高いML Ops負荷
もう一つ大事な特徴として、機械学習モデルを自ら学習して運用する従来の機械学習チームは、環境変化に対応したり、運用負荷を低減するために、以下のようなML Opsに多くのリソースを割く必要がありました。
- 学習データのバージョニングとスナップショット管理
- 学習パイプラインの構築と継続的学習の仕組み
- モデルのデプロイ、A/Bテスト、ドリフトによる精度劣化の検出と再学習 など
これらはMLモデル運用にとって非常に重要なポイントである一方、そのモデルが活用されるプロダクト全体としては知る必要がないため、認知負荷を下げるために、技術詳細を隠蔽した方がよいポイントでもあります。
マイクロサービス化と機械学習エンジニアを中心としたチーム構成
こうした「責任分界点を明確にでき」「ML Opsに多くのリソースを割く必要がある」点を背景として、基本的にはプロダクト初期から機械学習部分をマイクロサービス化します。また、コミットするチーム構成としても、MLに専門性を持つエンジニアが中心となり、特定の課題に深くフォーカスするアプローチがベストプラクティスだったかと思います。ここ数年、デファクト化しているTeam Topologiesの4類型(Stream-aligned, Complicated-subsystem, Enabling, Platform)でいうと、明確にComplicated-subsystemに当たると思います。カケハシでも、医薬品の需要予測プロダクトを運用しておりますが、こうした考えに基づいて、プロダクトの分離とチーム組成を行っています。チームの記事はこちらです。
生成AIプロダクトに求められる変化
さて、本題の生成AIプロダクトの話です。留意点を簡単に整理しつつ、チーム組成に必要な視点をまとめてみます。
責任分界点を明確にしづらい
やや大げさですが、生成AIをプロダクトに組み込み、汎用性を活かそうとするほど、結果としてユーザー視点での「正しい」評価が一筋縄ではいかない難しいユースケースを扱うことになると思います。(定量評価がしやすい要素技術としてLLMを使うユースケースももちろんあります)
例えば、専門的なチャットボットにおける回答生成や、文書要約をはじめとする文章構造化などでは、「良い出力」が必ずしも一意に決まるわけではありません。また、ユーザーは、生成AIによる出力単体だけではなく、UX、AI部分の品質、制御するロジックが密接に絡み合ったプロダクト体験全体として「正しさ」を評価される傾向があります。そうした難しいユースケースに対して、従来の「ML部分だけを切り出して任せる」という構造が機能しづらくなります。対処するためには、ML部分の問題設定と評価をそれぞれスコープを変えながら改善することに加え、依存関係がある周辺のシステムも含むプロダクト体験全体として問題を捉え、解を探るという姿勢が必要になると考えています。
ML OpsからLLM Opsへ。特に品質評価の難しさと対峙する。
生成AI、とくに大規模言語モデル（LLM）は、自前で学習・再学習せず、APIを通じて事前学習済みモデルとして提供されるものを使うのが一般的だと思います。そのため、当たり前ではありますが、モデルそのものの構築/学習関連のML Opsにかかる従来の負荷は大幅に軽減されます。一方、代わりに発生するのが、LLM Opsです。以下のような軸が典型です
- プロンプトの管理（バージョン管理、テンプレート最適化）
- 出力の一貫性や信頼性の担保（ハルシネーションの制御）
- モデルアップデート時の挙動の変化に対する対応
- 従量課金モデルのコストコントロール
- 定量面での一次評価、および人間評価も含むフィードバックループ
いろいろ書きましたが、一言でいえば評価が難しい中で、ソフトウェアだけでなく人手評価も含めて効率と品質を追求しながら、早くユーザーに価値提供できることが大事だと思います。
チーム組成に必要な3つの視点
生成AIを実戦投入するために、プロダクトチームには以下のような視点を持ちながら、「組織が生み出すアウトプットは組織のコミュニケーション構造を模倣したものになる」というコンウェイの法則を逆手にとった逆コンウェイ戦略を意識してチーム構成を行う必要があると考えています。
1. フルスタックな技術体制
「責任分界点を明確にしづらい」難しいタスクを扱う中では、チームとして出力結果をプロダクト体験として最適化する力がチームとして問われると思っています。つまり、プロンプト設計 → UI設計 → 出力評価 → 収集フィードバック → 改善まで一貫してチームとして見通し、複数のレバーを引ける力が必要です。このためには、フロントエンドやUXに強いエンジニア、LLMのプロンプト設計と評価に詳しいエンジニア、ソフトウェアアーキテクチャを設計・保守できるバックエンドエンジニア、など「MLエンジニアだけ」が専門的に存在するのではなく、技術的多様性が必要だと考えています。Team Topologiesでいうところの、Stream-aligned Teamになるということだと思っています。
２. ドメインエキスパートの存在
評価が難しい生成AIプロダクトにおいて、何が正しくて何が誤っているのかを判断する軸が非常に重要になります。LLM as a judgeの活用など、技術で補完することはできますが、人手評価は必須だと考えています。また、評価の考え方自体も一種の関数であり、システムであり、インクリメンタルに改善していく必要があります。
たとえば、弊社が扱うような医療文書の要約といった専門的なユースケースでは、その分野の専門知識（ドメイン知識）を持つ人材の協力が不可欠です。チームがいくら技術的に優れていても、評価軸やビジネス観点の設計を誤れば、実用性の低いプロダクトになってしまいます。また、チーム外にドメインエキスパートが存在していたとして「委託受託」構造のような形をとってしまっているとスピード感もでませんし、評価基準そのもののアップデートもできません。こうした考え方から、弊社ではチーム内に1名 ドメインエキスパートである薬剤師が所属しています。
3. 目新しい論点の対処能力
生成AIをプロダクト内部で使い開発を行なっていくと、上記で記述した難しい品質の担保のほか、データセキュリティや利用規約、法律や業界ガイドラインへの対応など、新しい論点に遭遇する確率が非常に高いです。ものによっては業界コンセンサスもとれておらず、法務やコンプライアンス、リスクマネジメント、経営陣、外部の法律事務所等を巻き込んで、障害を取り除いていく必要があります。ロールというよりは、こうした論点に対処して開発を前に進めるには、こうした観点への感度の高さと巻き込み能力が高いメンバーを所属させておく必要があると考えています。
おわりに
以上いろいろと書きましたが、現時点で書いたような内容が100点でできているとは思ってないですし、考え自体も発展途上です。また、こうした考え方のチームは、私自身は従来MLチームと比較してStream-aliged teamとして捉えましたが、おそらく外側からはComplicated-subsystem teamとして見えていると思います。幾何学(トポロジー)のように、見る階層や相対感によって見え方が異なるようで面白いですね。また中で働く身としては、私はもちろん、チームのエンジニアにとっても、変わった特徴を持っているチームでありチャレンジになるのではないかなと考えています。カケハシでは、こうした新しい変化を受け入れて、楽しんでチャレンジしてくださるエンジニア、エンジニアリングマネージャーを募集しています。もしご興味がある方は、ぜひカジュアルにお話しをさせていただけると嬉しいです。
