重要:本記事について
本記事で紹介する構成は PoCおよび検証用途 を想定しています。 実装前に必ず セキュリティ上の重要な注意事項 をお読みください。
目次
はじめに
こんにちは。サービスイノベーション部の田尾です。
私は普段、社内での生成AIの活用推進を担当しております。
今回は完全プライベートの時間を使い、クライアント完結構成 × Cursor × Gemini Canvas で高速にアプリを開発することで、ユーザ検証を素早く実施した話をします。
私は、新しいアイデアを検証する際、最も重要なのは 「動くものを、いかに早くユーザーが触れるレベルで出し、フィードバックを得るか」 だと考えています。
今回、学習伴走型AIプロダクトのPoC(Proof of Concept:概念実証)において、以下の構成で開発を行いました。
- バックエンド一切なし(完全クライアント完結)
- Cursor × Gemini Canvas の往復による開発フロー
開発期間の内訳: - 1日目(約6時間): 機能実装(音声認識、Gemini API統合、ストレージ設計) - 2日目(約4時間): UI/UX改善(Canvas活用、プロンプト調整) - 合計: 実働約10時間
使用ツールの補足: - Cursor: AI支援コードエディタ(VSCodeベース) - Gemini Canvas: Geminiの対話型UI生成機能
本記事では、開発プロセス、バックエンドの代わりにロジックを担った「システムプロンプト」 の設計、アプリをユーザに触ってもらって見えてきた課題についてご紹介します。
開発したアプリイメージ
毎日のちょっとした雑談から、自然に知識と表現力が身につく。コーチング・ニュース・豆知識を、楽しく続けられる学習アプリです。

■アプリの概要:
【コアバリュー】 AIとの会話で、自然と知識が身につく
【アプリへの想い】賢い先輩と話すと自分自身も知識が身に付き成長できていると実感したことがあり、その体験をアプリで再現したかった。
【3つの特徴】
①雑談で知識に触れる:毎日のちょっとした会話で、知識を自然に使う習慣づくりができます。
②AIがやさしくコーチング:「先生」ではなく「パートナー」として、褒めて伸ばし、自然な表現へ修正してくれます。
③ニュース・豆知識も学べる:興味のあるトピックで学習できるため、飽きずに続けられます。
システム構成
今回は「検証」が目的であるため、DBやAPIサーバーは不要と割り切り、フロントエンドのみで完結させる構成を採用しました。
| 領域 | 技術スタック | 選定理由 |
|---|---|---|
| Frontend | React + Tailwind CSS | 高速なイテレーションのため |
| AI Model | Google Gemini 2.5 Flash | 高速応答かつマルチモーダル(Text & TTS)対応 |
| Voice Input | Web Speech API | ブラウザ標準の音声認識(マイク入力) |
| Voice Output | Gemini TTS | AI生成による自然な音声合成 |
| Storage | LocalStorage | インフラ構築ほぼ不要 |
すべてのデータをブラウザに保存し、デプロイは静的ホスティングのみ。通信待ち時間を極限まで減らし、対話体験に集中できる設計です。
コスト感
- Gemini API: 無料枠内で収まる(2日間で約500リクエスト、TTS含む)
セキュリティ上の重要な注意事項
本記事はPoC・検証用途を想定しています。実装前に必ずお読みください。
今回の構成では、LocalStorageにデータを格納しています。 セキュリティ上リスクがあるため、「 個人情報や機密データは保存しない」という暫定運用となります。 この構成は検証用です。本番化の際は必ず上記対策を実施してください。
実装フロー
開発の流れ: まず機能をCursorで実装 → 次にUIをCanvasで生成 → 統合
1. Cursorで機能実装(ロジック)
まずは見た目を気にせず、音声認識やGemini呼び出しなどの機能を一気に実装しました。この段階では、UIは簡素な管理画面のような状態です。
2. Gemini CanvasでUI再構築(デザイン)
次に、Gemini Canvas を導入し、UI/UXを全面的に再構築しました。

補足:Canvasによる改善プロセス:
「カフェで友人と話しているような、温かいチャットUI」といった抽象的な指示をCanvasに投入
生成されたコンポーネントをプレビューしながら微調整
確定したデザインコードを Cursor のロジック側に統合
「骨組みはCursor」「見た目はCanvas」と割り切ることで、デザインスキルがなくても使いたいUIを素早く実装できました。
システムプロンプトの工夫
サーバーがないため、AIの振る舞いを制御するシステムプロンプトがアプリケーションのロジックそのものになります。
通常、バックエンドで行う「データ検証」「フォーマット変換」「エラーハンドリング」を、すべてプロンプト設計で代替しました。以下、4つの機能ごとに工夫したポイントを紹介します。
1. 【基本会話】TTSに最適化した「ノイズ除去」と「構成強制」
課題: サーバー側で正規表現などのテキスト整形処理を挟めないため、AIが出力する段階で「読み上げに適したクリーンなテキスト」にする必要がある。
工夫のポイント:
- Markdown禁止:
**(太字)や#などの記号はTTSで読み上げられるとノイズになるため、システムレベルで禁止 - 3ステップ構成の強制: 冗長にならないよう、「共感 → 豆知識 → 問い」のリズムをプロンプトで固定
あなたはユーザーの知的好奇心を刺激する親しみやすいパートナーです。 【制約事項】 1. 出力はプレーンテキストのみ: Markdown、絵文字、URLは一切使用禁止。(音声読み上げのノイズになるため) 2. 文字数: 60〜90文字程度。一息で聞ける長さに収める。 3. 構成: 必ず以下の3ステップ構成で出力すること。 [Step 1] ユーザーへの共感・リアクション(短く) [Step 2] 関連する事実ベースの豆知識・心理学・科学トリビア [Step 3] 思考を促す「1つの」問いかけ
2. 【英語学習】言語切り替えを意識した「バイリンガル制御」
課題: 英語学習モードでは、日本語(解説)と英語(例文)を混在させる必要がある。TTSエンジンが言語を誤認識すると、不自然な読み上げになる。
工夫のポイント:
- 役割の明確化: 訂正するだけでなく、「なぜその表現が良いのか」を添えることで学習効果を高める
- TTS対策: 日本語と英語が混ざる際、読み上げが自然になるよう「スペースや読点で区切る」指示を含む
あなたはユーザーの英語アウトプットを全力で肯定し、少しだけ洗練させるコーチです。 【基本姿勢】 - 役割: 先生(Teacher)ではなく、伴走者(Partner)。 - 言語: 解説や励ましは「日本語」、例文やリキャストは「英語」。 【フィードバックの3ステップ】 1. **Positive Feedback**: まずは挑戦した姿勢や、通じている部分を日本語で具体的に褒める。 2. **Refinement**: もし不自然なら、「こう言うともっとネイティブっぽいよ」と *Better Version* を提示する。 3. **Next Challenge**: そのフレーズを使って、別のシチュエーションで使うための短い誘導をする。
3. 【ニュース解説】「自分ごと化」するブリッジ生成
課題: ニュースを単に要約するだけでは、ユーザーが「他人事」として聞き流してしまう。生活との接点を作る必要がある。
工夫のポイント:
- 自分ごと化: 記事の「事実」と、ユーザーへの「影響」を明確に分けることで、ニュースを「自分ごと」として捉えてもらう設計
あなたは「ニュースを隣で一緒に見てくれる博識な友人」です。 提供された記事データに基づき、ユーザーの生活に関連付けて解説してください。 【振る舞いルール】 1. **要約の極意**: 専門用語を使わず、中学生でもわかる言葉に言い換える。 2. **自分ごと化**: 「これが社会にどう影響するか」ではなく「ユーザーの生活がどう変わるか」という視点で補足する。 3. **事実の厳守**: 記事に書かれていないことは「推測ですが」と断るか、言及しない。 【回答フォーマット】 記事の要点(事実)→ 生活への影響(解釈)→ ユーザーへの問い(対話)
4. 【分析機能】JSONモードによる「UIの制御」
課題: 学習の振り返り機能では、会話ログ(非構造化データ)から、UIで表示するスコアやハイライト(構造化データ)を抽出する必要がある。
工夫のポイント:
- スキーマの厳格化: フロントエンドが
JSON.parse()でエラーを起こさないよう、Markdown記法の混入(```json 等)を禁止
Geminiの JSONモード (response_mime_type: "application/json") を活用することで、確実にパース可能なJSONを生成させました。
以下の会話ログを分析し、ユーザーの学習成果を構造化データとして抽出してください。
【抽出ルール】
1. **Highlights**: 会話の中でユーザーが「実際に使った単語」「興味を示したトピック」を抽出。
2. **XP**: 会話の量と質に基づいて、100〜500の間でスコアを算出(整数)。
【出力形式】
JSON形式のみを出力してください。Markdownのコードブロックは不要です。
{
"level": "String (例: ルーキー)",
"xp": Number,
"comment": "String",
"highlights": ["String", "String", "String"]
}
このように、「プロンプトエンジニアリングでバックエンドロジックを代替する」 ことこそが、このアーキテクチャの肝と言えます。
システムプロンプトの役割: - TTS品質の担保(ノイズ除去) - UI連携のための構造化(JSON生成) - ユーザー体験の向上(パーソナライゼーション)
サーバーレス構成では、プロンプトの精度がアプリの品質に直結します。
今後の課題と改善アイデア
見た目は改善されましたが、ここで重要な転換点 がありました。
実際のユーザーに使ってもらう
自分で素敵なアプリができた!と思っても、他の人が操作すると予想外の反応が返ってきます。 複数人に触ってもらった結果、次の 3つの課題 がクリティカルでした。

1. 初回体験が不親切
「何すればいい?」とユーザーが迷ってしまう。パッといいユーザー体験を提供できないと顧客が離れてしまう。
2. 温かみが足りない
機械的な対応では、ユーザーとの情緒的な繋がりが築けない。もっと「一緒に学んでいる感覚」が必要。
3. 最大の壁:3〜5秒のラグ
音声再生までの待ち時間が長く、会話のテンポが悪い。これがユーザーにストレスを与えてしまう。
これらの課題を解決することが、次のステップになるなと、改善の方向性が見えてきました。
まとめ
- Cursor × Canvasの分業: AIをロジックとデザインを使い分けることで個人開発の限界を超えられる
- ユーザの声を早めに聞きに行くことは超重要: ユーザの声でアプリの課題が明確化され、改善の方向性が見えた
- プロンプトエンジニアリングの重要性: システムプロンプト設計がアプリの品質を左右する
本番化には堅牢なアーキテクチャが必要ですが、0→1のフェーズで「まず体験を出す」が大切だとより実感 しました! 引き続きユーザーの声を聞きながら、継続的に改善し、実用化に向けて進めていきます!