1. はじめに
こんにちは。株式会社タイミーのデータサイエンスグループ（以下、DSG）でグループマネージャーを務めている菊地です。
前回の記事では、タイミーのDSGが認知負荷をコントロールするために仮想チームという形態をとり、チームトポロジーの考え方をベースに組織を運営していることをお話ししました。
その中で、MLOpsエンジニア主体のプラットフォームチームの役割を「専門性を最大化するための共通基盤を提供すること」と定義しました。現在、その基盤の上でホットなトピックとなっているのが、LLMをはじめとする基盤モデルの活用です。
昨今の基盤モデルの急速な進化に伴い、タイミーの各プロダクトチーム（チームトポロジーにおけるStream Aligned Team、以下SA Team）からも「基盤モデルを使ってユーザー体験を向上させたい」というアイデアが次々と生まれています。プロダクト内のコンテンツ生成から業務の効率化まで、基盤モデルを活用することで解決できる課題の幅は非常に多岐にわたります。
ただ、基盤モデルをプロダクトの機能として組み込むプロセスは、従来のソフトウェア開発とは異なる考慮事項も多く、不確実性も伴います。
- 「そもそもこの課題に基盤モデルは最適なのか？」
- 「精度の評価はどう客観的に行えばいいのか？」
- 「セキュリティやコストの管理はどうすべきか？」
これらの問いに対して、すべての案件にMLOpsエンジニアやデータサイエンティストが付きっきりで関与していると、どうしても開発のスピード感を維持するのが難しくなることもあります。DSGがボトルネックになるのではなく、SA Teamが自分たちの力で自律的に、かつ安全に基盤モデルを活用した機能をリリースできるような状態を整えていく必要があります。
そのような背景から、DSGとして「基盤モデルを用いた機能開発のガイドライン」を策定しました。
本記事では、SA Teamのセルフサービスな開発を支援し、組織全体で価値提供を加速させるためのガイドラインのエッセンスをご紹介します。
2. 開発体制パターンとDSGの関わり方
基盤モデルを活用した機能開発を進めるにあたり、まず私たちが整理したのが、開発の特性に応じた開発体制パターンです。
すべての開発を同じフローに乗せるのではなく、技術的な複雑さや求められる専門性に応じて役割分担を明確にすることで、SA Teamが迷わずに開発を開始できるようにしています。
選択の指針：スピードか専門性か
これら2つのパターンのどちらを選択するかは、主に「基盤モデルの出力がそのまま価値になるか」、それとも「複雑なロジックや既存システムとの高度な統合が必要か」という観点で判断します。
パターン1. セルフサービスパターン（ガイドラインのメイン対象）
SA Teamが主体となり、クラウドプロバイダーが提供するAPIを利用して開発を進めるパターンです。基盤モデル周辺の実装が比較的シンプルに完結し、プロンプトの調整や基本的なRAG（検索拡張生成）の構成で十分な価値が出せるケースを想定しています。
- 主なユースケース：定型文の生成、ドキュメントの要約、シンプルな分類タスクなど。
- 責任の所在：機能の企画、プロンプトエンジニアリング、実装、評価までをSA Teamが完結して持ちます。
- DSGの役割：DSGは、API利用環境の払い出しや、セキュリティ・コストのガードレール提供、技術的な壁打ち相手としての伴走（Enabling）に徹します。
このパターンの最大のメリットは、DSGとの調整コストを最小化し、SA Teamのスピード感で価値検証のサイクルを回せることにあります。
パターン2. Complicated Subsystemパターン
システムやロジック自体が高度に複雑で、運用・改善にデータサイエンティストやMLOpsエンジニアの専門知見が不可欠なケースです。例えば、基盤モデルの出力を独自の数理モデルや推薦アルゴリズムと組み合わせる場合や、ドメイン特有の複雑な評価指標が必要な場合が該当します。
- 主なユースケース：複雑なマッチングロジックへの組み込み、高度な推論パイプラインの構築など。
- 責任の所在：DSGがアルゴリズムやバックエンドの主要ロジックに責任を持ち、SA Teamと協力してプロダクトへ統合します。
- DSGの役割：モデル選定からパイプライン構築、精度評価の設計までを深くリードします。
専門性が求められる部分をDSGが引き受けることで、SA Teamが基盤モデルの深い専門知識をすべて学習する負荷を下げつつ、プロダクトのコア価値を最大化します。
3. 不確実性を乗りこなす5つの開発フェーズ
基盤モデルを活用した機能開発は、従来のソフトウェア開発に比べて不確実性が高く、やってみないとわからないことが多い領域です。そのため、ウォーターフォール型で一気に作り込むのではなく、アジャイルなアプローチで段階的に仮説検証を進めることが成功の鍵となります。
ガイドラインでは、開発プロセスを以下の5つのフェーズに定義しています。ここでは、各フェーズの概要と、私たちが重視している検証のポイントを紹介します。
実際のガイドラインでは、各ステップで「どのような性質の成果物が求められるのか」を具体的に定義しています。さらに、過去の成功事例で作成したシステム構成図や、投資対効果（ROI）の判断資料、プロンプトの評価ログなどを参照できるようにしており、各ステップで目指すべきゴールを明確にイメージできるように工夫しています。
Phase 1: 計画・設計フェーズ
プロジェクトの目的を定義し、ビジネス価値と技術的実現性の両面から、プロジェクトの妥当性を検証します。
- 検証のポイント：解決したい課題に対して基盤モデルが最適な手段であるか、成功を測るための指標（KGI/KPI）が明確か、既存システムとの安全な連携が可能か。
- 期待される成果物の例：成功基準を定義したドキュメント、全体的なシステム構成案、想定されるリスクと対策方針の整理。
Phase 2: PoC開発フェーズ
「この機能は本当にユーザー価値があるか？」という仮説を検証するため、最小限のコストで迅速にコア機能を構築するフェーズです。
- 検証のポイント：基盤モデルの応答性能が実用レベルに達しているか、提示されたユーザー体験（UX）が課題解決に繋がっているか。
- 期待される成果物の例：主要なプロンプトの初案、コア機能が実際に動作するプロトタイプ、コストや性能を可視化する簡易的なモニタリング環境。
Phase 3: PoC評価・本番移行計画フェーズ
PoCで得られた定量的・定性的なデータに基づき、本番開発へ進むべきかを客観的に判断するフェーズです。
- 検証のポイント：精度、コスト、速度を総合的に評価した際に、十分な投資対効果（ROI）が見込めるか。
- 期待される成果物の例：本番開発への移行を判断するための意思決定ドキュメント。
- 意思決定のプロセス：タイミーでは、本番移行にあたって技術およびプロダクト責任者による承認を必須としており、スピードとガバナンスの両立を図っています。
Phase 4: 本番開発フェーズ
検証された価値を、全ユーザーに安定して提供できる、スケーラブルで信頼性の高い機能を構築するフェーズです。
- 検証のポイント：最大トラフィックに耐えうる負荷対策がなされているか、プロンプトの変更が品質劣化を招かないための評価基盤が整っているか。
- 期待される成果物の例：環境分離（dev/stg/prod）が徹底された本番機能、品質劣化を防ぐための自動評価（リグレッションテスト）環境、運用のための各種レポート。
Phase 5: 本番運用・継続的改善フェーズ
安定稼働を維持しつつ、収集したデータに基づいて継続的に機能を改善し、ビジネス価値を最大化するフェーズです。
- 検証のポイント：実際の利用データに基づき、KPIが想定通り改善されているか。
- 期待される成果物の例：段階的なリリース計画、インシデント発生時の対応フロー、ユーザーフィードバックの収集・分析プロセス。
- 継続的改善：新しいモデルの登場やモニタリング状況の変化に合わせ、迅速にプロンプトやモデルをアップデートできる体制を維持します。
4. プロダクト品質を支える技術ナレッジの体系化
開発プロセスが整っても、個々の技術的な判断基準が属人化していては、プロダクト全体の品質を一定に保つことはできません。ガイドラインでは、SA Teamが自律的に最適な意思決定を行えるよう、基盤モデル活用の勘所を技術ナレッジとして集約しています。
ここでは、私たちがガイドラインで定めている技術ナレッジの概要をいくつかご紹介します。
本当に「基盤モデル」が最適か？
基盤モデルは極めて汎用性が高いツールですが、すべての課題に対する正解ではありません。私たちは、開発を始める前に「本当にその課題を基盤モデルで解くべきか？」を立ち止まって考えることを推奨しています。
- 基盤モデルが得意なこと: 創造性が求められる文章生成、膨大な情報の要約、そして「文脈やニュアンス」を汲み取った高度な分類・抽出、画像や音声を統合して理解するマルチモーダルな処理。
- 基盤モデルが苦手なこと・適していないこと: 100%の正確性が求められる、シンプルな条件分岐で済むルールベースの処理、すでに特定のタスクに特化した専用AI APIが存在するケース。
「最新技術だから使う」のではなく、コスト・精度・安定性のバランスを鑑みて、従来通りのプログラムや専用APIの方が優れていないかを冷静に見極める眼を養うための基準を明文化しています。
素早い価値検証とデータ資産の積み上げ
一方で、基盤モデルの大きな強みは「機械学習の事前準備をショートカットできること」にあります。
従来の機械学習プロジェクトでは、特定のタスクを解くために大量の学習データを準備し、モデルをトレーニングするという数週間〜数ヶ月単位のプロセスが必要でした。基盤モデルを使えば、この重たい工程を飛び越え、プロンプトの調整だけで数日〜数週間でユーザーへの提供価値を検証できる可能性があります。
たとえ初期のAPIコストが高くついたとしても、まずは最速で「そもそもこの機能がユーザーに求められているか」という本質的な仮説に答えを出す。そして検証の過程で蓄積された「ユーザーの入力」と「フィードバック」は、将来的に専用モデルや自社独自のモデルへ移行する際の貴重な学習データとなります。
「まずは基盤モデルで素早く価値検証を行い、成功すればそのデータを基に、より最適なソリューションへ進化させていく」という、時間軸を味方につけた戦略も取りうることを明文化しています。
処理の安定性と信頼性
基盤モデルの出力をプログラムで安定して扱うためには、自由な文章ではなく、後続の処理で扱いやすい形式でデータを受け取ることが不可欠です。これは一般的に構造化出力と呼ばれていますが、私たちは構造化出力を実装における標準として定義しています。
プロンプトによる指示に加え、モデルのネイティブ機能やバリデーション用のライブラリを適切に組み合わせることで、システムの安定性を高めます。また、APIの利用制限や一時的な負荷増大によるエラーに備え、自動的な再試行や代替モデルへの切り替えといった、プロダクション環境に耐えうる信頼性設計のパターンを共通化しています。
5. おわりに
今回ご紹介したガイドラインは、一度策定して終わりではありません。現場からのフィードバックや日々進化する技術動向を取り入れながら、常にアップデートし続けるドキュメントとして運用しています。
私たちがこのガイドラインを通じて実現したかったのは、不確実性の高い、基盤モデルを活用した開発において、各プロダクトチームが余計な迷いなく自律的に動けるよう、必要な指針を示し、環境を整えることでした。
DSGがすべての案件を抱え込むのではなく、専門知見を標準化して組織全体に開放していく。このプロセスこそが、タイミーが技術の力でミッションを達成するための大きな原動力になると信じています。
We’re Hiring!
タイミーでは、データサイエンティストやMLOpsエンジニアはもちろん、今回ご紹介したようなガイドラインや基盤を使い倒してプロダクトに価値を届けるエンジニア、プロダクトマネージャーなど、全方位で一緒に働くメンバーを募集しています！
最新の技術をどう社会実装するかという仕組みづくりに興味のある方は、ぜひカジュアル面談でお話ししましょう。皆さんの挑戦をお待ちしています！
