はじめに
生成AI技術の進化に伴い、企業が生成AIアプリケーションの開発に挑戦する機会が増えています。しかし、従来のソフトウェア開発手法では、生成AI特有の課題に十分に対応しきれない場面も多く見られます。モデルの予測不能な挙動やUX設計上の不確実性が高いため、柔軟性のある開発スタイルが求められます。
本記事では、私たちのチームが実践しているアプローチを踏まえつつ、生成AIアプリケーション開発においてどのような開発スタイルが最適なのかを考察していきます。
結論
本記事での主な知見は以下の通りです。
生成AI開発にはアジャイル開発が効果的
- 不確実性への対応
- 迅速なフィードバックサイクル
- データ駆動型の継続的改善
効果的な体制作りの重要性
- 役割の専門分化
- 効率的なミーティング設計
- チーム間の密接な連携
プロトタイプ駆動開発の有効性
- 早期の課題発見
- UX改善の迅速な実現
- データに基づく意思決定
自動評価システムの導入によるスケール
- LLM-as-a-Judgeによる評価自動化
- 一貫性のある品質評価の実現
- 人的リソースの最適活用
- ハルシネーション対策や著作権侵害リスクへの対応（CCC）を含め、継続的かつ広範囲なモニタリングが可能に
これらの要素を総合的に組み合わせることで、不確実性の高い生成AIアプリケーション開発でも効果的な開発プロセスを実現できると考えています。
開発手法の選択と課題
ウォーターフォール開発の限界
ウォーターフォール開発は、設計段階で仕様を固め、その後は一方向的に工程を進めていく手法です。これは従来のアプリケーション開発では有効なケースもありますが、以下の理由から生成AI開発との相性は必ずしも良くありません。
- 不確実性の高さ
モデルの精度やユーザーの反応が予想しにくく、設計時点で要件を厳密に定義しづらい。 - UX設計の難しさ
生成AIのUXは実際に試用してみないと見えない部分が多く、プロダクト段階で初めて課題が明確化する場合がある。 - 手戻りリスクの増大
設計をもとに実装しても、実運用時に課題が判明した際は、大幅な修正コストがかかる可能性が高い。
アジャイル開発の有効性
アジャイル開発は、不確実性の高いプロジェクトに適した反復的な手法であり、生成AIアプリケーションでも特に有効です。私たちのチームでも、主に以下の理由からアジャイル開発を採用しています。
- 反復的なプロセス
プロトタイプを早期に作り、短いスプリントでフィードバックを収集しながら改善を重ねる。 - 柔軟な方針転換
AIモデルの挙動やUXの問題点に応じて、開発方針を迅速に修正できる。 - データドリブンな改善
フィードバックや利用データを基に、次の開発サイクルでの課題をより明確化できる。
実践的なアプローチと体制づくり
効率的なミーティング設計
私たちのチームではアジャイルの原則を取り入れつつも、典型的なスクラムの形をそのまま踏襲しているわけではありません。理由としては、部署内で複数のプロジェクトを掛け持つメンバーが多く、各メンバーのスケジュールが多様だからです。そこで、以下のようにミーティングを柔軟に設計しています。
- 週1回の開発内MTG
技術的な課題共有と解決策のディスカッション。 - 隔週の全体MTG
開発チーム・分析チーム・推進チーム間で認識をすり合わせ、優先度を見直す。 - スポットMTGの活用
特定の課題が浮上した際には、必要に応じて迅速にミーティングを設定する。
さらに、各機能の推進者を明確にすることで責任範囲をはっきりさせ、進捗が止まりにくい体制を整えています。しかし、一方で以下の課題も浮上しています。
- 知見の属人化リスク
機能別に担当を分けているため、特定領域のノウハウが特定メンバーに集中しがち。- この課題を緩和するため、最近はコード実装にも生成AIの力を積極的に取り入れ、メンバー同士でインプット効率を高める工夫を進めています。
- ただし、当チームはペアプロ文化がまだ十分に根付いていないため、それをどのように浸透させていくかは残課題です。
- 特に、各メンバーが複数の案件を掛け持ちしていることから、ペアプロや技術共有のための時間調整にハードルがあるのが現状です。
- レビュー品質の課題
- 全員が複数案件を抱えているため、レビュー体制を十分に確立しづらい。
- ただし、これは一部署や一チームだけで解決できる問題ではなく、組織的に開発リソースやプロジェクト数を再調整するなど、より広い視点での改善が求められます。
- 全員が複数案件を抱えているため、レビュー体制を十分に確立しづらい。
開発体制の改善
生成AI開発では、フロントエンドとバックエンドが密に連携することが重要です。最初はNext.jsによるフルスタック開発を試みましたが、メンバーの興味・得意分野に合わせて役割を専門分化させる形に移行しました。
現在は以下のような構成です。
- LLM用サーバーの分離
FastAPIを採用し、サーバーを分割することで負荷分散とスケーラビリティを実現。 - 役割の専門分化
フロントエンドとバックエンドの担当範囲をはっきり分け、それぞれの専門性を最大限活かす体制を構築。
ただし、フルスタックでの開発を経験してみたい方には積極的に挑戦することを推奨しており、実際にフルスタック実装へと領域を広げているメンバーもいます。
技術的課題への対応
ハルシネーション対策
生成AIにおいては、誤った情報をあたかも正しいかのように返す「ハルシネーション」への対策が欠かせません。私たちのチームでは、以下の方法で影響を最小化するための取り組みをしています。
- UX設計での配慮
もし誤情報が出てもユーザーがすぐに疑問を持てるUIや注意喚起メッセージを用意。 - プロンプト管理・評価
プロンプト管理はLangfuseを活用し、LLM-as-a-Judge機能と連携することでモデル出力を評価。
また、RAG（Retrieval-Augmented Generation）に関する検証にはRagasを導入し、出力品質を継続的にモニタリングできる土台を構築。 - ログ分析
アプリケーション内で発生するログデータを分析チームにもバッチで共有することで、モニタリングを共同で行い、後追いでも調査できる体制を敷いています。
著作権侵害への対策（CCC対応）
ハルシネーション対策とは別に、著作権侵害への懸念にも注意を払う必要があります。特に、Azure OpenAI Service を利用する場合は、Microsoft が提供する Customer Copyright Commitment (CCC)(※1) に準拠する形でモデルを運用するのが重要です。
私たちのチームでも、CCC対応を強化するため、著作権侵害リスクを軽減するメタプロンプトの設定や出力テストの実施といった運用プロセスを取り入れ、モデル出力のコンプライアンスを維持するために取り組んでいます。
プロトタイプ駆動開発の実践と課題
生成AIのUXは、実際に触れてみて初めて見える課題が多いため、プロトタイプを中心に据えた開発が重要です。以下の利点と課題があります。
- 利点
- デザイン段階の確認: Figma上でのデザイン案をもとに、基本的なUXを早期に評価。
- 実装段階でのテスト: ステージング環境での動作確認により、設計時には想定できなかった課題を早期に発見。
- データ駆動型の改善: ユーザーの操作データや行動傾向を分析し、次の開発サイクルに反映できる。
- 課題
- ドキュメント整備の遅れ: プロトタイプ作成を優先するあまり、後になってからドキュメントを整備するケースが多い。
- 求められるスキルの多様化: デザインから実装まで、幅広い知識・技術が必要となり、属人的になりやすい。
LLM-as-a-Judgeによる評価自動化
生成AIアプリケーションの規模拡大により、モデル出力の評価を人手だけでカバーすることが難しくなっています。そこで私たちのチームでは、LLM-as-a-Judgeによる自動評価システムの導入を進めています。
- スケーラビリティの確保
社内文書の増加や変動に対して、大量データの評価を短時間で行える。 - 評価の一貫性担保
定めた基準に基づいて自動評価するため、人間による評価ばらつきを減らせる。 - リソースの最適化
手動評価の負荷が一部軽減されることで、開発チームはより価値の高い業務に専念しやすくなる。
ただし、現時点では以下のような課題も残っています。
- ヒューマンインザループの必要性
完全自動化は現実的ではなく、定期的に人間のレビューや基準調整が求められる。 - 評価基準の最適化
自動評価システムで用いる判断基準を継続的に改善・微調整し続ける必要がある。 - コストバランス
システム導入の運用コストと人件費のバランスを最適化しなければならない。
これらの取り組みの詳細については、「社内向け生成AIチャットサービス：社内文書検索機能の正式版リリースとLLM-as-a-Judge導入に向けた改善の取り組み」（techtekt, 2024年10月28日）にて公開しています。
チーム間連携
生成AIアプリケーションの効果的な開発には、以下のチーム間連携が不可欠です。
- 推進チーム
ユーザー要望の収集や優先順位の設定。 - 分析チーム
プロトタイプ段階でのデータ分析と意思決定支援。 - 開発チーム
UXや機能改善を迅速に反映する実装。
たとえば新機能の検討を行う際は、開発チームが分析チームと協議して、改修内容が既存分析基盤へ与える影響を確認したうえで、推進チームと新しい施策案やデータ取得方針を検討するといった流れをとっています。こうして技術面・分析面・プロモーション面の全方位で情報を集約することで、より適切な意思決定を目指しています。
さらに、2024年度からは年に一回、合宿形式で各チームの代表者が集まり、プロダクトの軸や今後の戦略についてディスカッションする場を設けています。5W3Hの観点からプロダクトの意義や方向性を言語化することで、各チームの目線を一致させる狙いがあります。
このように、日常的なミーティングに加え、合宿を通じた高い視座での戦略連携を組み合わせることで、生成AI開発の不確実性への対応を図っています（合宿での詳しい取り組みは別記事でご紹介できたらと思っています。）。
今後の展望
生成AIアプリケーション開発では、UXの“正解”がプロトタイプを経て初めて見えてくることが多く、その正解自体も時間の経過や新しい学習データの追加によって変化します。こうした不確実性に対応するには、アジャイルを基盤とした柔軟な開発スタイルが現状では最適と考えられます。
今後も継続的な改善や体制の見直しを続けながら、AIを活用したユーザー体験の質を高め、よりスピード感のある開発を目指していきたいと考えています。
さらに、2024年度からは年に一回合宿形式で、開発・分析・推進チームの代表者が集まり、プロダクトの軸や今後の戦略をディスカッションする場を設けました。5W3Hの観点からプロダクトの意義や方向性を言語化することで、各チームの指向性を揃えています。今後はこの合宿の開催頻度を高め、変化の激しい生成AI領域でも共通のビジョンを共有しながら、迅速かつ柔軟に開発を進めていきたいと考えています。
注釈
※1: CCC(Customer Copyright Commitment)とは、MicrosoftがAzure OpenAIの出力コンテンツに関連する知的財産権のクレームから顧客を保護するための取り組みで、必要な軽減策を実施することでこの保護を受けられます。詳細は、Customer Copyright Commitment Required Mitigationsを参照。
梅本 誠也 Seiya Umemoto
デジタルテクノロジー統括部 生成系AIエンジニアリング部 生成系AIエンジニアリンググループ リードエンジニア
韓国で5年間正規留学し、その間に業務委託で機械学習とデータエンジニアリング方面の開発を経験。新卒でアプリケーションエンジニアとしてフロントエンド、バックエンド、インフラを幅広く経験。パーソルキャリア入社後はデータエンジニアとして、社内のデータ分析基盤の構築と運用保守を担当。一方で、生成系AIを用いたアプリケーション開発にも携わっている。
※2025年1月現在の情報です。
