はじめに
NTTドコモ データプラットフォーム部（以下DP部）外山です。
DP部では「『あらゆる業務・現場のニーズに応じられる』柔軟なデータ活用環境」を目指し、社内データ活用プラットフォームPochi*1の開発を進めています。現場ニーズへ迅速に応えるには (1) 事業変化に追従する高速試作 と (2) 実運用に耐えるユーザー起点のアプリ開発 が鍵となる中で、この2点を成立させるには、要件定義初期に利用者との認識（期待する体験・操作感）を素早くそろえることが不可欠です。つまり、画面イメージをいかに高速に作成し、修正を加えながら認識合わせを行えるかが重要となります。
今回は、画面イメージを Vibe Coding を使って生成し認識合わせを簡単かつ高速化できた取り組みを紹介します。
なお、本記事に掲載の取組については、DP部小林祐貴さんに進めてもらっており、以下は、小林さんに執筆いただいています。
社内データ活用プラットフォームPochiとは
私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームを開発・推進しています。このプラットフォームは、24年度は30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。
ASCII.jp：NTTドコモ、Streamlit利用の“ポチポチ分析アプリ”開発で社内データ活用を促進 (1/3)
本記事を読んで解決されるプロダクトの課題
ずばり 開発初期の画面イメージ作成がとても辛い という点が、本記事で解決される課題となります。
初期段階では、利用者側の要望がまだ抽象的で相互理解も浅く、UI案を形にする工数が膨らみがちとなります。かといって初期の画面イメージがないと認識合わせや論点整理が前に進まないため、優先度は非常に高く後回しにできません。従来は Power Point で静的な図を手作業配置しながら作成しており、次の課題がありました。
| 観点 | 課題 |
|---|---|
| 工数 | 細かな部品配置・レイアウト調整に時間がかかり、 さらにユーザー確認→差分反映の反復で工数が膨らむ |
| 認識齟齬 | UIモック作成主体が開発者となるため、ヒアリング内容を開発側解釈で再構成してしまい 「意図の過剰反映」「機能抜け」「操作感のずれ」が発生しやすい |
| 実装整合性 | 実装しにくいUIを提示し、後工程レビューで差し戻し・再設計が発生するリスク |
実際に私が担当した案件では、要件定義期に Power Point で画面イメージ図を作成しレビューと修正を往復するだけで約2週間を要することもありました。 当時の案件の全工程期間は1か月であり、その約半分の稼働がこの往復に割かれた計算になります。 さらにその後実際の画面実装に着手すると、合意したはずのイメージ図との齟齬（配置や操作フローの差異）が再び生じ、再調整が発生してしまうといった事象が発生しておりました。
そんな中Vibe Codingがプロジェクト内で使用可能となった
近年のAI活用ブームに本部署も追随し、Coding Agent である Cline が導入され、これにより、自分でコードを書かずともプロンプトを入力するだけでコーディングが可能となり、動く画面の試作も短時間で形にできる環境が整いました。*2
そこで、プロンプト≒要件 を伝えるだけで画面を即座に生成できるなら、従来 Power Point で作っていた画面イメージ図もここに寄せてしまえばよいのではないか、という発想に至りました。 本記事では認識合わせ用のユーザー起点UIを Vibe Coding で生成するまでの試行錯誤と改善プロセスを紹介します。
とりあえずやってみた ～全然思い通りの実装をしてくれない～
とりあえずやってみようということで、実際にプロンプトに要件を入力して生成してみました。
結論としては、たしかに記載した要件自体は満たしているのですが "何か違う" ものが出力されました。
「絶望的にUIセンスがないな...」 というのが率直な感想です。
一部具体例で示してみると、当初は以下のようなプロンプトを打ち込んでおりました。
注記: 以下は業務・実データとは関係のない説明用サンプルです。数値等は架空であり、実際の社内要件や判断材料とは無関係です。
■初期プロンプト
## 選定した店舗の月別売上推移を確認する ### UI - エリアマネージャーとして、選択した各店舗の月別売上推移（直近3か月）を確認したい。表示は y軸を売上、x軸を月とした折れ線グラフとする。 - 売上推移は店舗ごとに独立した折れ線グラフでも確認したい。理由は、売上が100万円未満の店舗と該当月を把握したいため。
■生成された画面
左右2枚は本来縦スクロールで続く1つの画面となります。（左：上部, 右：下部)
この画面を見て気になった点をいくつか挙げてみると、次のとおりです。
- 直近3か月しかないのに横幅が広く余白が多い
- 多数の店舗グラフを縦方向へ長く並べており視認性が低い
- 売上100万円未満を一応示してはいるが、その後の行動（重点確認・調査）につなげる工夫がない
- 売上が100万円未満の店舗と該当月はわかるけども、だから何という
どうしてこうなった ～"絶望的なUIセンス"の正体～
初期プロンプトは 「表示したい要素」を列挙しているだけで、ユーザーがその画面を使って何を達成し、次にどう行動するかが十分に記述されていませんでした。
そのため生成されたUIは 要素は並んでいるが使い方が直感できない状態になってしまってます。
たとえば、問題点として挙げた「店舗グラフが縦方向へ長く並んでいる」という点について、なぜ"絶望的なUIセンス"と感じられたのか、その背景をユーザー視点で整理してみます。
担当する複数店舗を同時に選択する目的を考えると、これは全体を俯瞰してどの店舗・どの月に売上目標（例:100万円）未達が生じているかを迅速に把握するためです。 さらに、未達月が特定店舗に偏っているのか、各店舗で低迷が同じ月に集中しているのかなど、"低い月"の発生パターンを比較したいという意図があります。 ところが、現状の縦長スクロールUIでは一画面に表示できる店舗数が限られ、未達状況と発生傾向を一覧で即座に比較できません。
要するに、「なぜ複数店舗を選択/複数店舗のグラフを表示したのか」というユーザー起点での利用目的がUI側に反映されていないことが、"絶望的なUIセンス"と感じた違和感の本質です。
プロンプトを"UI体験設計"へ転換 ～ユーザーストーリーマッピングの利用～
これを踏まえ、実際に使用するユーザーの利用目的、すなわち ユーザーストーリーのコンテキストをプロンプトに反映していきます。 ここで活用されるのが、ユーザーストーリーマッピングという、要件をアプリユーザー起点でまとめるフレームワークです。
ユーザーストーリーマッピングとは
ユーザーへのヒアリング内容を整理する際に、次の3層で「誰が何を達成しどう使うか」を構造化するフレームワークのこと。以下の3点を縦積みで考えていく。
- ユーザーアクティビティ
- ユーザーが目的達成のために行う大きな仕事のまとまり（誰が／何をしたいか）
- ユーザーストーリー
- アクティビティの中の具体的な行動シナリオ
- 機能
- ストーリーを支えるUI要素・処理
- なぜその機能が必要か（利用意図）まで記述する
加えて、「なぜアプリが必要なのか（現状課題）」を明示する ことで、画面生成エージェントが配置より体験意図を解釈しやすくなります。
以下はこの枠組みに沿って再構成した改善後プロンプトです。
注記（再掲）：以下は説明用の架空サンプルです。数値・店舗等は実データ/社内要件とは無関係です。
■改善後プロンプト
# ペルソナ（想定利用者） ## 属性 - 某携帯キャリアのエリアマネージャー（担当店舗: 15～30店） ## 現状課題 - 売上関連データの所在が部門・レポート・Excelに分散し一本化されていない - 担当店舗間で「どこを優先的に改善すべきか」を客観指標で並べて判断できない - 3か月サイクルで施策を打っているが効果検証が遅れ、次サイクルに反映しづらい - 未達店舗の抽出と理由整理に毎回時間がかかる（前処理が手作業） # ユーザーストーリーマッピング ## ユーザーアクティビティ エリアマネージャーが担当複数店舗の直近売上推移を俯瞰し、支援優先度（重点フォロー店舗と該当月）を **素早く特定** したうえで、次の深掘り分析や現場アクションにつなげる。 ### ユーザーストーリー1：俯瞰と優先度付け 担当する複数店舗の直近3か月の売上トレンドを一画面で比較し、全体の傾向（伸長・停滞・急落）を把握する。 #### 機能 - 複数店舗をマルチセレクトで選択する - なぜ: 自分が担当する店舗だけに絞り込むことで、不要な情報を排除し、判断の精度とスピードを上げるため - 全選択店舗の直近3か月の折れ線グラフを1店舗1グラフで表示する（全選択店舗の売上推移 x=月 y=売上） - なぜ1: 複数店舗の売上推移グラフを1画面に収めるように並べて表示することで、ひと目で全体の傾向や異常値を相対的に把握できるため - なぜ2: どの店舗が特に改善が必要かをひと目で見つけ、優先順位付けを迅速に行うため - 縦軸に基準線（例: 100万円）を設け、閾値未満の店舗と該当月を目視で即座に抽出する - なぜ: 売上目標未達の店舗や月をすぐに特定し、重点的な支援や追加分析の対象を明確にするため - 表示順を並び替える（最新月売上順 / 売上低下幅順 / 未達回数順） - なぜ1: 支援優先度の高い店舗をひと目で抽出するため - なぜ2: 過去に施策を実施した店舗が相対的に売上伸長しているかを即座に確認するため
■生成された画面
左右2枚は本来縦スクロールで続く1つの画面となります。（左：上部, 右：下部)
これにより、初期版では「単に折れ線を並べる指示」だったものが、生成側に"配置目的","比較意図","判断アクション"を伝えるプロンプトへ転換され、UIが単なる図表配置ではなく体験設計に沿う確率を高められる構成になっています。
得られた成果
実際にこの手法を案件に取り入れることで、以下の定性的・定量的観点での成果を得ることができ、従来課題の解決へとつながりました。
1. Power Point → Vibe Coding 転換で得られた効果（従来課題の解消+α）
- 作成スピードアップ:
- 手作業レイアウト → 自動生成で初期モック期間が短縮
- 初期作成に2週間かかっていたものが3日間までに！
- 手作業レイアウト → 自動生成で初期モック期間が短縮
- 修正反復が容易に:
- 図形再配置中心 → プロンプト差分修正で反復が高速化
- 手戻り減少:
- 実在コンポーネントでの作成により、「実装不可UI」の差し戻しゼロへ
- そのまま初期コード資産となる:
- 画面イメージ作成＝動く土台コード生成となり、後工程着手前倒し
- レビュー効率の向上:
- 静的画像共有 → 実際に触れるUIで具体指摘（操作感/遷移/余白）
2. ユーザー起点プロンプト化で得られた効果
- 認識合わせ精度の向上:
- 開発者の思う"ユーザー起点"が反映され、より認識合わせに役立つ画面イメージに
- 齟齬早期顕在化:
- 操作フロー / 優先度 / 機能抜けのズレを 画面生成作業時に発見可能に
- 要件の補完・精緻化:
- ヒアリング内容を「ストーリー＋機能＋理由」に再構成する過程で抜け漏れを補填
- 再利用性:
- ペルソナ / 課題 / アクティビティ / ストーリー / 機能+理由 の型がテンプレ化
おわりに
本取り組みを通じて強く感じたのは、ユーザー起点プロンプト設計では、最初に「どの機能を置くか」ではなく、利用者がその画面で何を達成し次にどう動くかを徹底的に言語化するヒアリングが要であるという点です。
このため 「ヒアリング → ユーザーストーリーマッピング化」の再現性向上が次の課題となってきます。
この課題に対し、現代ではオンライン会議の議事録をAIが自動生成できるため、このログからユーザーストーリーマッピングの骨組みに必要な要素を抽出し、半自動でプロンプト土台を作る仕組みを試したいと考えています。
これが実現できれば、属人的な「聞いた人しか再構成できない」工程を脱し、個人差に左右されず誰でも類似品質の初期プロンプトを短時間で再現できる状態に近づけます。
Vibe CodingをはじめとするAI活用は特別作業ではなく開発プロセスへ溶け込む段階に入っています。何かを打ち込めば何らかの返答が得られるがゆえに場当たり的運用になりやすく、使い方が曖昧化しがちです。 これを勘に委ねず言葉で構造化し、共有可能な手順（プロンプト作成フロー）に落とし込むことが再現性と初速最大化の鍵であるため、再現可能なプロセス化を重点テーマとして継続検証を進めていきたいです。
ここまで読んでいただきありがとうございました。ユーザー起点プロンプト設計を現場改善に持ち帰る一助となれば幸いです。
