上司-「どんなことやってみたい?」
私-「学生時代にLLMに関する研究をやっていたので、それに関連するプロダクトを作ってみたいです」
こんなやり取りから私の開発は始まりました。新卒1年目の私が挑んだのは、「Vertex AI Gemini」を活用したナレーション付き動画自動生成アプリの開発です。入社してすぐのプレッシャーを感じつつも、主体的にプロダクトを開発できる。技術者としての第一歩のワクワクする挑戦でした。
しかし、技術的な興味だけで突き進んだ先には、「ただ動くだけでは、課題解決にならない」といった壁がありました。
実際にユーザーにヒアリングしてみると、想像していた以上に多様で具体的なニーズがあることが分かりました。説明用・研修用・広告用で求められる口調が全く違う。社内用語の読み上げが正確でないと使い物にならない。スライドの内容次第で必要な台本が変わる――。
「これは単に技術を組み合わせるだけでは済まない」
この経験から、開発を「作る」から「届ける」へとシフトしました。この記事は、ユーザーの"生の声"に導かれながら、プロトタイプが現場で活用できるツールへブラッシュアップしていく過程をご紹介します。
TL;DR
PDFスライドから自動でナレーション付き動画を生成するアプリを、7月中旬から約2ヶ月半で開発し、10月社内プロダクトとしてリリースしました。GeminiとStreamlit、Google Cloudを活用しています。ユーザーヒアリング駆動の開発により、台本スタイル選択機能や専門用語辞書機能を実装し、実際の業務課題解決に貢献しています。開発を通じて、技術選択の重要性とユーザー中心設計の価値を学びました。
自己紹介
NTTドコモデータプラットフォーム部(以下DP部)の小澤です。現在新卒1年目として社内データ活用プラットフォームPochiの開発を担当しています。 今回は、LLM活用アプリを、実際のユーザーの声を聞きながら社内プロダクトをリリースするまでの過程をご紹介します。
社内データ活用プラットフォームPochi※1とは
私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームを開発・推進しています。このプラットフォームは、24年度は30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。
ASCII.jp:NTTドコモ、Streamlit利用の"ポチポチ分析アプリ"開発で社内データ活用を促進 (1/3)
※1: Pochiは社内の開発コードネームです
想定する読者
- 新卒でもこんな技術チャレンジができる環境に興味のある学生の方
- LLMを活用したアプリケーション開発の実践例や、ユーザー中心設計の進め方に興味のある方
この記事の流れ
この記事では、以下のような流れでアプリ開発のストーリーをお伝えします。そのなかで失敗や学んだことをまとめました。
- プロトタイプ作成: 最初のナレーション付き動画生成ツールの実装
- ヒアリング: 想定とのギャップと見えてきた壁
- 機能実装: ユーザーの声を具体的な機能に
- リリース: 最初のフィードバックと新たな課題
- 継続改善: リリース後の改善活動
背景
社内では日々、報告会や研修、宣伝・周知を目的としたスライド資料が多く作成されています。これらは動画化することで、オンデマンド研修や繰り返し視聴、説明の補足など、より幅広い形で展開できます。 一方で、実際の動画化には編集や音声追加などの工程が多く、手間がかかるのが現状です。スライドを手軽にナレーション付き動画として展開できれば、研修や宣伝コンテンツの活用範囲を大きく広げられます。
開発したアプリ
今回開発したのは、PDFスライドからナレーション付き動画を自動生成するAI支援ツールです。ユーザーが動画化したいスライドをアップロードするだけで、スライドの内容を理解した自然なナレーション台本を自動生成し、さらにそれを音声化して最終的に動画まで完成させることができます。
技術的な仕組み
処理の流れ
PDFアップロード → 画像変換 → LLM台本生成 → 音声生成 → 動画作成 → 最終出力
アーキテクチャ図
PyMuPDF、Gemini、Google TTS、FFmpegを組み合わせて一連の自動化を実現しています。
プロトタイプの実装
まずは「スライドをそのままアップロードして動画化する」というシンプルな流れを想定してプロトタイプを実装しました。台本作成に用いているGeminiは、テキストだけでなく、スライド内に記載されている図やグラフの内容を同時に理解し、それらの関係を反映した台本を生成できることが大きな強みです。
実際に生成した台本
スライドのアップロードから動画生成まで一気通貫で動いて、手動で細かい修正も可能であるため、ある程度幅広いユースケースにも対応できると想定していました。しかし、プロトタイプ版を元に実際にユーザーにヒアリングを実施すると、そう簡単ではないことがすぐに分かりました。
ヒアリングで実際にいただいた意見
「用途によって、求める口調が全然違う」
説明用の動画では専門的で正確な解説が重視される一方、研修用では親しみやすく理解しやすい語りかけが求められ、広告用では聞き手の関心を引き付ける魅力的なプレゼンテーションが必要。同じスライドでも、目的次第でかなり異なるトーンの台本が必要になるのです。
「専門用語が正しく読まれないと、使い物にならない」
社内用語や業界特有の専門用語が間違った発音で読み上げられたり、異なった意味で説明されてしまうと、動画の信頼性が一気に損なわれてしまいます。「Pochiをポチと読んでほしい。」「LLMはエルエルエムと読んでほしい」――こうした細かいニーズが、動画の品質を左右する重要なポイントだと感じました。
「スライドを動画化する」という当初の構想が、機能として需要と可能性はあるものの、実際に現場で使われるまでにはまだ乖離がある。でも同時に、本当に価値あるツールを作るための具体的なヒントをたくさん頂けました。
振り返ると、ユースケースを曖昧にしたまま作り始めたため、「誰に届けるのか」が設計に反映されていなかったと思います。「一気通貫で動く」という技術的な部分に注力してしまい、実際に使う人の多様性や細かなニーズを想定できていませんでした。きちんとユースケースを明確にし、誰がどう幸せになるのかを最初から考えることの重要性を、このヒアリングで学びました。
ユーザーの声を形に
ヒアリングで得られた貴重な意見を踏まえ、実際の業務ニーズに応える機能の実装に取り組みました。
台本のスタイル調節機能
利用者のニーズに応じて、説明用、研修用、プレゼン用など、異なるトーンで台本を生成できるようにしました。それぞれのスタイルに応じたプロンプトテンプレートを事前に用意し、ユーザーが選択できる形式で実装しています。
辞書登録機能
社内の専門用語や固有名詞を正確に発音するため、SSML(Speech Synthesis Markup Language)に反映できるカスタム辞書システムを構築しました。ユーザーが事前に用語と読み方を登録しておくことで、社内でよく使われる専門用語であっても正しく意味を汲み取って自然な発音で読み上げることができるようになりました。
台本スタイル選択・カスタム辞書登録(設定画面)
社内リリース、実際に使ってみてもらったフィードバック
嬉しかった評価
「台本の内容、期待以上に正確ですね」 「音声も自然でスムーズ!」
従来の手作業と比較して台本作成にかかる時間が短縮され、作業効率が大幅に向上したというコメントは、開発側として本当に嬉しかったです。
また、ステップバイステップのUI設計について、「進行状況が直感的に把握できる」「初めて使うユーザーでも迷わない」と評価していただけたのも嬉しかったです。Pochiの開発で学んだUIガイドラインを活かせた成果だと感じています。
課題指摘
一方で、改善すべき課題も見つかりました。
「ブラウザをリロードすると、最初からやり直しになっちゃうんですね...」
開発中は気にしていなかった点ですが、実務で使うとなると致命的な問題です。また、PowerPointファイルを事前にPDFに変換しなければならない手間や、一部のケースで音声が乱れてしまう現象なども指摘されました。
これらのフィードバックは貴重な学びだと思いました。実際に使ってみて初めて分かる課題。これこそが、ユーザー中心設計の真髄なのだと実感しました。「作った」だけでは終わらない。「使われる」ためには、ブラッシュアップを続けていく重要性を感じました。
ユーザーフィードバックに基づく継続的な改善
実際にアプリをリリースした後も、ユーザーの声を聞きながら継続的に改善を重ねています。
音声の聞き取りやすさの改善
課題: 「音声が速すぎて内容が頭に入ってこない」「急に声が高くなったり、速度が変わったりして聞きづらい」
リリース直後、ユーザーから音声の聞き取りづらさに関するフィードバックが複数寄せられました。読み上げ速度が速すぎて情報を消化する時間が不足し、一文が長く自然な息継ぎポイントが不足していました。
解決策:
プロンプトエンジニアリングによる改善を実施しました。SSML生成時に速度調整タグを自動挿入し、読み上げ速度を0.8倍速に調整。トーンやピッチの変更は行わず、一貫したトーンで読み上げ、適切な間(pause)の調整のみ行うよう制約を明示的に指定しました。台本生成プロンプトには、一文50文字以内を目安とし、適切な箇所に読点を入れるルールを追加しました。
継続的な改善により、「自然で聞きやすい音声になった」という評価を得られました。
利用者の拡大
継続的な改善活動の結果、アプリの月次利用者数は着実に増加しました。
月次利用者数の推移
- リリース時: 60人/月
- 改善周知後: 150人/月（2.5倍に増加）
- その後も120人/月で推移
一時的な減少はありましたが、リピートユーザーは増加傾向にあり、継続的に使われるツールへと成長しています。この数字は、単に「動くツール」を作るだけでなく、ユーザーの声に耳を傾け、継続的に改善を重ねることの重要性を改めて感じました。
さらなる展望
現在のアプリでは、スライドアップロードから動画作成までの一気通貫の流れは実現できていますが、さらなる価値提供に向けて以下の展望を描いています。
今後の展望
- 音声品質の向上: より自然で聞きやすい音声生成、読み間違い防止機能の強化
- 台本スタイルの自由設定: 事前設定からユーザーが自由にカスタマイズできる機能への発展
- 専門用語システム改良: 個別登録方式から包括的で学習機能を持ったシステムへ
- 長編動画対応: 短いプレゼンテーション向けから長時間コンテンツへの対応拡大
- スライド生成機能：スライドの作成から動画化までを一気通貫で実施できる
昨今、動画生成や音声合成の分野では優れたサービスが登場しており、今後はそれらをうまく活用していくことも重要だと考えています。一方で、今回あえて自ら手を動かして開発したからこそ、ブラックボックスな機能を使うだけでは見えない技術の勘所や、ユーザー独自の細かなこだわりを深く理解できました。便利なサービスを「使う」ことと、柔軟に「作る」こと。双方のメリットを活かし、課題解決のために最適な手段を選び取っていく姿勢を、今後も大切にしていきたいと思います。
最後に
この開発プロジェクトを通じて印象深かったのは、アプリを実際に形にしてユーザーに使ってもらうことで初めて見えてくる課題や要望の多さでした。事前の設計段階では想像もしていなかった細かな使い勝手の問題や、実際の業務フローに合わせた機能の必要性など、机上では分からない多くの学びがありました。
「作る」から「届ける」へ。この言葉の意味を、私はプロトタイプを使ってもらったときの反応で初めて実感しました。「動くものを作った」という達成感とは別に、ユーザーの反応には「自分が気づいていなかった現実」が詰まっていました。単に機能するツールを作るだけでなく、それが実際に誰かの手に届き、日常の業務の中で使い続けてもらえるものにすること――それが「届ける」ということだと、この開発を通じて理解しました。
今回のプロジェクトでは、AIコーディング支援ツールをはじめとする最新技術を積極的に取り入れながら開発を進めることができました。 新しい技術にいち早く触れ、実際のプロダクト開発に活用できる点は、エンジニアとして大きな成長機会だと感じています。
立場に関係なく、「やりたい」から挑戦できる環境がドコモにはあると思います。このようなプロジェクトに取り組ませていただけた環境に感謝するとともに、今後も利用者に寄り添ったアプリ開発を目指していきたいと思います。技術は手段であり、最終的にはそれを使う人たちの課題解決や価値創造に貢献できるかが重要だということを実感しました。
最後まで記事を読んでいただき、ありがとうございました。皆さんも新しい技術に挑戦する際は、ぜひユーザーの声を大切にしながら進めていただければと思います。
