旅程生成AIの開発とリリースで直面した、技術・評価・体制のリアルな課題

はじめに

2025年6月、旅行予約アプリ『NEWT（ニュート）』は、AIを活用した旅行プラン提案機能「トラベルプランナー（ベータ版）」をリリースしました🎉

この機能は、NEWTに掲載されたツアー情報をもとに、AIが自動で旅程を作成してくれるものです。カスタマーが旅行日程を入力してボタンを押すと、飲食店・観光スポットを、朝・昼・夜ごとに1日単位で提案し、視覚的に確認できる旅程表を生成します。

生成AIとリアルな旅行情報を組み合わせた本機能の開発では、次のような現実的な課題に直面しました。

• AIのアウトプット品質をどう評価するか？
• コストをどう持続可能に設計するか？
• 生成AIプロジェクトにおける役割分担をどう整理するか？

この記事では、それぞれの課題にどう向き合い、どんな知見を得たのかを開発事例とともにご紹介します。

本記事の想定読者

• 生成AIを使ったプロダクトを検討中のPMの方、開発中のエンジニアの方
• LLM活用のPoCから本番運用へステップアップしようとしているチーム
• LLMの品質評価・コスト管理・チーム体制構築に課題を感じている方

トラベルプランナーの概要

トラベルプランナーは、以下のような体験を提供します：

• カスタマーがツアーを選び、旅行日程を入力
• AIが各日の朝・昼・夜の飲食店と観光スポットを自動提案
• チェックイン・アウトや空港との移動時間も現実的に考慮
• 「王道」「リラックス」「カルチャー」「ショッピング」などの旅の目的に合わせて生成

この新しい体験を支えるために、ベースのプロンプトに加え、人数やホテル情報、旅行先の地域なども明示的に注入しています。

あなたは旅行プラン作成の専門家です。提供されたすべての日程に基づいて旅行プランを作成してください。このプランは、指定された人数（大人、子供、幼児の内訳を含む）、ホテル、および旅行先の広域エリアに基づいて作成されるべきです。提供されたベーススケジュールに基づいて、旅行中の各日に観光スポット、イベント、レストラン、アクティビティなどを追加してください。

<条件>
アーキタイプ: \${theme}
旅行者: \${travelers}
ホテル: \${hotel}
エリア: \${area}
全体の旅行日程: \${dates}
</条件>

技術構成

開発スタックとしては、Vercel AI SDK × Gemini を組み合わせています。コストと精度とパフォーマンスの観点からモデルはGemini 2.5 Flashを採用しています。

  const result = streamObject({
    model: google("gemini-2.5-flash-preview-05-20"), 
    system: BASE_PROMPT,   // ベースのプロンプト
    prompt: dynamicPrompt, // セッションごとの動的なプロンプト
    schema: daySchema,     // zodスキーマでJSON構造に誘導
    output: "array",
  });

クライアント側もVercel AI SDKの useObject フックにより、非常に簡単に型安全にストリーミングすることができます。

  const { object } = experimental_useObject<DeepPartial<TravelPlan>>({
    api: `/api/thread`,
    schema: travelPlanSchema, // daySchemaを包含するスキーマにより型を共通化
  });

課題1：AIのアウトプット品質をどう評価するか？

問題となった背景

生成AIの出力は人間の目から見ると「それっぽく見える」ことが多く、定量的な品質評価が困難です。特に旅行のような主観性が高い領域では、「良し悪し」の判断軸が曖昧になります。開発中は、「これはリリースできる水準か？」という議論が、チーム内でも何度か起きました。

対応策

この課題を解決するために、以下のような評価と改善の仕組みを構築しました：

• 社内25名に対し、想定旅行パターンに沿ったプロトタイプの使用とフィードバックを依頼
• 「スケジュールの完全性」「滞在先との関連性」「独自性」「有用性」の4項目を、5段階スコア＋自由記述コメントで評価
• 評価結果は LangSmith に取り込み、バージョンごとのスコアを自動集計・可視化
• テキストコメントは LLM に渡して重要度順に要約し、プロンプト改善の優先度を明確化
• 各指標の 平均スコアが80点以上(0.80) を「リリース水準」として設定 ✅

結果

以下は「スケジュールの有用性」に関する、1回目と2回目の評価スコアの比較です。

• 初回評価の平均スコアは0.74と合格ラインに達していませんでしたが、LLMによるフィードバック要約を通じて改善ポイント（例：「日程密度が低い」「最終日に活動が少ない」など）を抽出
• プロンプトを修正した2回目の評価では、平均0.80を達成し、定量的な改善を確認

このように、スコア変化を明確に可視化しながら改善サイクルを回す仕組みが実現できました。

スケジュールの有用性の平均値が2回目の評価で80点を超えた様子

得られた知見💡

生成AIの品質は、主観ではなく、明確な評価軸 × 定量スコア × 要約可能な自由記述によって、はじめて改善可能な対象となりました。特に LangSmith のような評価基盤は、出力の品質を継続的に比較・トラッキングする仕組みとして非常に有用でした。

一方で、こうした評価体制を機能させるには、初期段階で一定の人数による目視評価やスコア付けが必要であり、人的コストや工数をある程度かけないと精度は担保できないという点も明確になりました。この点は今後の課題として残りました。

課題2：従量課金制のAIでコスト増大をどう防ぐか？

問題となった背景

生成AIはトークンベースの従量課金制であるため、カスタマーの増加や利用頻度の上昇が、そのまま運用コストに跳ね返るという構造的な課題があります。

特にプロダクション環境では、急なトラフィック増加やユースケースの拡張により、想定以上のコストが発生するリスクがあります。

対応と工夫

本プロジェクトでは、以下の対策を通じてコスト増大リスクに備えました：

• 想定UU × 利用率 × 平均トークン数の式に基づき、月次トークンコストを事前に試算
• 初期フェーズではWeb展開を見送り、アプリ限定のミニマムリリースにスコープを絞ることで、初期のトラフィックとトークン消費を制御

得られた知見💡

生成AIや外部APIを活用するプロダクトでは、機能要件よりも前に「コスト構造そのもの」を設計に組み込む必要があると強く感じました。

今回は実装終盤でコスト試算に立ち返りましたが、これを開発初期から織り込むことで、モデル選定・チャネル戦略・UI設計における意思決定の自由度を大きく広げられます。

生成AIを活用するプロジェクトにおいては、「性能」や「精度」だけでなく、スケーラビリティとコストの両立を視野に入れた技術的意思決定が、継続的な運用の鍵になると再認識しました。

課題3：複数チームでの開発をどう進めるか？

背景と課題

生成AIのプロダクト開発には、プロンプト設計・モデル選定・UX設計・ストリーミング制御など、多岐にわたるスキルセットが必要になります。NEWTの開発でも、MLチームとプロダクトチームの横断プロジェクトとなったことで、当初は役割分担が不明瞭な状態に陥りました。

特に課題となったのは、プロダクトチーム側にLLMの知見が不足していた点です。そのため、MLエンジニアがプロンプトの設計から出力の形式調整まで基盤を構築することになり、以下のような直列的な開発フローが発生していました：

プロンプトの改善（MLチーム） 
→ API設計・スキーマ調整（MLチーム）
→ フロントエンド実装（プロダクトチーム）

この分業体制により、各工程が順番待ちになってしまい、実装全体が遅延するという問題が顕在化しました。

対応

リリース後は、以下のように役割分担を明確化しました。

• MLチーム：モデル・プロンプト改善、品質評価、スコア設計
• プロダクトチーム：AI SDKの組み込み、UI実装、導線整備

今後は、フロントエンドでもLLMを直接扱える体制へ移行予定です。

得られた知見💡

生成AIのプロダクト開発を進める中で実感したのは、もはやAIの活用は「MLチームだけの領域ではない」時代になったということです。プロンプト設計や評価指標の策定、LLMとのインタラクション設計など、従来は専門職の領域とされていたタスクが、徐々にプロダクト側のエンジニアも学習が必須になってきました…🔥

VercelのAI SDKはLLM/クライアントとのやり取りが高度に抽象化されており、その第一歩としてふさわしいライブラリでした。ぜひ使ってみてください🙆🏻‍♂️

おわりに

本記事では、NEWTの「トラベルプランナー」開発を通じて、生成AIプロダクトにおける以下の3つの本質的な課題と、それにどう向き合ったかをご紹介しました。

• AIの品質評価は、主観に頼らず、明確な評価軸と定量スコアを導入することで、改善可能な領域へと転換できる
  • 一方で、初期段階での品質担保には、より少ないコストで回せる工夫が今後の課題です
• コスト設計は、モデル選定や提供チャネルに直結するため、設計初期からの考慮が不可欠
• チーム体制は、生成AIの民主化に伴い、従来のML／プロダクトという分業構造の見直しが求められている

これらの取り組みを通じて強く実感したのは、生成AIはもはやMLチームだけの専任領域ではなく、プロダクトエンジニアが品質・コスト・UX設計まで広く関与する時代に入ったということです。今後もNEWTでは、AIを活用したプロダクトを継続的にリリースしながら、より汎用的で持続可能な設計と体制を構築していく予定です。

生成AIを実プロダクトで活用してみたい方、本質的な開発に関心のある方は、ぜひカジュアルにお話ししましょう。 こちらからいつでもご連絡ください👍🏻
https://hrmos.co/pages/reiwatravel/jobs/0000098

お知らせ

令和トラベルでは毎月技術的な知見を共有しあうための勉強会を毎月開催・参加しています。
https://findy.connpass.com/event/360678/
https://kauche.connpass.com/event/358309/

また、令和トラベルでは一緒に働く仲間を募集しています。興味がある方はぜひご連絡ください。
https://www.reiwatravel.co.jp/recruit

それでは、次のブログもお楽しみください✈️