Bolt x Difyで記事作成!AIアプリ開発入門
学習ポイント
- チャットアプリを構成する基本UI要素(ヘッダー、メッセージエリア、サイドバー等)の役割と定義方法
- バイブコーディングにおいて、ラリー回数を減らし一発で理想のUIを出力するためのプロンプト設計、リセマラ術
- ブラウザの開発者ツールを使用したAPIレスポンスの確認と、Bolt.newのバージョン履歴機能によるデバッグ・復元
本日のゴール
アジェンダ
ウォームアップ(前回のおさらい)と今日のゴールを説明(5分)
チャットアプリのUIの決め方を理解しょう(15分)
プロンプトを実際に書いてみよう(30分)
実際に作ってデバッグさせてみよう(10分)
UI・UXの説明用Webサイト
https://beginner-chat-app-ui-2nxx.bolt.host/
https://ai-chat-data-persist-nppa.bolt.host/
前提
今回から、bolt有料プランの機能を利用します。こちらの講座を進める際にはbolt Proプランに事前に加入することをおすすめします。
配布物
ウォームアップ(前回のおさらい)と今日のゴールを説明します
第3回は、前回(DeFi全体像/バックエンドAPIとプロンプト記述)の復習を踏まえ、画面遷移を伴うチャットアプリ等のフロントエンドに本格着手。UIの要素・構造・フレームワークを理解し、適切なプロンプト設計と履歴の保存方法を学ぶ。併せて、エラー時の切り分けと粘り強いデバッグで自力解決力を鍛えるのが今日のゴール。
チャットアプリのUIの決め方を理解しよう
https://beginner-chat-app-ui-2nxx.bolt.host/
チャットアプリのUI設計では、まずWeb画面の基本要素と用語を理解する。一般サイト同様にヘッダー/フッターがあり、メインにはメッセージエリア・スレッド・入力欄、必要に応じてハンバーガーメニューが並ぶ。これらを覚えると、AIや開発者へ「どこをどうしたいか」を言語で具体指示でき、インスペクタ不要でも意図が通じやすい。結果として設計の解像度とコミュニケーション効率が高まる。
プロンプトを実際に書いてみよう(30分)
ここでTomさんにDifyワークフローについて説明してもらう
このパートでは、実際に「キーワードまたはYouTube URLからノート記事の草案を生成するチャットアプリ」を実装するためのプロンプト設計を行う。まずアプリの目的を明確化し、バックエンドAPI(DiFy)を使ってストリーミング形式の対話を実現する構成を定義。画面構成は、①テーマ選択ボタン(色指定含む)→②メッセージエリア遷移→③入力欄・スレッド・サイドバーなどの定義→④記事確認画面という流れを設計する。また「はい」と入力して確認・保存するなど、ユーザー操作の流れも明示する。さらにDB設計をプロンプトに記述し、ユーザーID(タイムスタンプ生成)や会話リスト管理を実装。これにより、セッション単位でユーザー識別や会話保存が可能となる。最後にDifyのAPIキーとURLを設定して接続すれば、フロントからバックまで連携したチャットアプリが完成する。
目的を決める
# 目的
キーワードまたは YouTube URL から Note用の記事草案を生成するチャットアプリを実装する。
バックエンドはDify APIでストリーミングで対話形式で実装する。構成画面を考える
# 目的
テーマまたは YouTube URL から Note 用の記事草案を生成するチャットアプリを実装する。
Dify API(サーバ側プロキシ経由)でストリーミングで対話生成する。
# 画面構成
ヘッダー:
「Note記事制作ツール」+サブコピー「テーマまたはYouTube URLから記事を生成」。
モード選択ボタン:
横並びで以下の色で構成する
「キーワードから自動生成」= エメラルド
「YouTubeから自動生成」= グレー
メッセージエリア:
初回メッセージ送信後、永続的なチャットUIに遷移します。
入力フィールドと送信ボタンは画面下部に固定表示され、継続的な入力ができるようにする。
メッセージ入力ボタン:
選択モードに応じて文言を動的変更。
「キーワードから記事を生成」ボタン。
メッセージ表示:
ユーザーメッセージは右寄せのバブル、アシスタントメッセージは左寄せのバブルで表示します。
アシスタントメッセージにMarkdownが含まれる場合はレンダリングし、平文はそのまま表示します。
サイドバーと会話管理:
固定された左サイドバーを実装します。
上部: 「+ 新しい記事を作成」ボタンを配置します。
中央: 会話履歴をローカルストレージで表示します。履歴がない場合は「まだ会話履歴がありません」と表示します。
下部: 「ゲストユーザー」「オンライン」と歯車アイコンを含むユーザーカードを配置します。細かい調整(応用)とDB要件を明言する
# 目的
テーマまたは YouTube URL から Note 用の記事草案を生成するチャットアプリを実装する。
Dify API(サーバ側プロキシ経由)でストリーミングで対話生成する。
# 画面構成
ヘッダー:
「Note記事制作ツール」+サブコピー「テーマまたはYouTube URLから記事を生成」。
モード選択ボタン:
横並びで以下の色で構成する
「キーワードから自動生成」= エメラルド
「YouTubeから自動生成」= グレー
メッセージエリア:
初回メッセージ送信後、永続的なチャットUIに遷移します。
入力フィールドと送信ボタンは画面下部に固定表示され、継続的な入力ができるようにする。
メッセージ入力ボタン:
選択モードに応じて文言を動的変更。
「キーワードから記事を生成」ボタン。
メッセージ表示:
ユーザーメッセージは右寄せのバブル、アシスタントメッセージは左寄せのバブルで表示します。
アシスタントメッセージにMarkdownが含まれる場合はレンダリングし、平文はそのまま表示します。
サイドバーと会話管理:
固定された左サイドバーを実装します。
上部: 「+ 新しい記事を作成」ボタンを配置します。
中央: 会話履歴をローカルストレージで表示します。履歴がない場合は「まだ会話履歴がありません」と表示します。
下部: 「ゲストユーザー」「オンライン」と歯車アイコンを含むユーザーカードを配置します。
確認アクションにおけるクイック返信機能:
アシスタントメッセージに「『はい』と入力してください」または「「はい」と入力してください」という確認メッセージが含まれる場合、「はい」のクイック返信バッジを表示します。
このバッジをクリックするか、「はい」と入力して送信すると、同一のconversation_idで継続メッセージを送信します。
データ保持要件:
一意のユーザーID(chat_user_id)を管理し、存在しない場合はuser_{timestamp}形式で生成。
会話リスト(chat_conversations)を更新があるたびに保存します。
新しい会話はリストの先頭に追加され、最初のメッセージの先頭50文字からタイトルを生成します。
Difyからの初回応答受信時、一時IDは URL/ストアの主キーとして 維持し、
Dify の conversation_id は difyConversationId として同レコードに保存する。Dify APIに関する記述
# 目的
テーマまたは YouTube URL から Note 用の記事草案を生成するチャットアプリを実装する。
Dify API(サーバ側プロキシ経由)でストリーミングで対話生成する。
# 画面構成
ヘッダー:
「Note記事制作ツール」+サブコピー「テーマまたはYouTube URLから記事を生成」。
モード選択ボタン:
横並びで以下の色で構成する
「キーワードから自動生成」= エメラルド
「YouTubeから自動生成」= グレー
メッセージエリア:
初回メッセージ送信後、永続的なチャットUIに遷移します。
入力フィールドと送信ボタンは画面下部に固定表示され、継続的な入力ができるようにする。
メッセージ入力ボタン:
選択モードに応じて文言を動的変更。
「キーワードから記事を生成」ボタン。
メッセージ表示:
ユーザーメッセージは右寄せのバブル、アシスタントメッセージは左寄せのバブルで表示します。
アシスタントメッセージにMarkdownが含まれる場合はレンダリングし、平文はそのまま表示します。
サイドバーと会話管理:
固定された左サイドバーを実装します。
上部: 「+ 新しい記事を作成」ボタンを配置します。
中央: 会話履歴をローカルストレージで表示します。履歴がない場合は「まだ会話履歴がありません」と表示します。
下部: 「ゲストユーザー」「オンライン」と歯車アイコンを含むユーザーカードを配置します。
確認アクションにおけるクイック返信機能:
アシスタントメッセージに「『はい』と入力してください」または「「はい」と入力してください」という確認メッセージが含まれる場合、「はい」のクイック返信バッジを表示します。
このバッジをクリックするか、「はい」と入力して送信すると、同一のconversation_idで継続メッセージを送信します。
チャットデータ:
一意のユーザーID(chat_user_id)を管理し、存在しない場合はuser_{timestamp}形式で生成します。
会話リスト(chat_conversations)をlocalStorageに保存し、更新があるたびに保存します。
新しい会話はリストの先頭に追加され、最初のメッセージの先頭50文字からタイトルを生成します。
Difyからの初回応答受信時、一時IDは URL/ストアの主キーとして 維持し、
Dify の conversation_id は difyConversationId として同レコードに保存する。
DifyAPI連携について:
localStorage と state に以下を保持:
userId(初回生成・以後固定)
conversationId(1ターン目の応答から取得)
## 4) 送信先・ヘッダ・認証
URL:https://dev-app.myuuu.co.jp/v1/chat-messages
APP_TOKEN="app-HPuaBLnKSlTCfY0gbVZ1VZqC"# 目的
テーマまたは YouTube URL から Note 用の記事草案を生成するチャットアプリを実装する。
Dify API(サーバ側プロキシ経由)でストリーミングで対話生成する。
# 画面構成
ヘッダー:
「Note記事制作ツール」+サブコピー「テーマまたはYouTube URLから記事を生成」。
モード選択ボタン:
横並びで以下の色で構成する
「キーワードから自動生成」= エメラルド
「YouTubeから自動生成」= グレー
メッセージエリア:
初回メッセージ送信後、永続的なチャットUIに遷移します。
入力フィールドと送信ボタンは画面下部に固定表示され、継続的な入力ができるようにする。
メッセージ入力ボタン:
選択モードに応じて文言を動的変更。
「キーワードから記事を生成」ボタン。
メッセージ表示:
ユーザーメッセージは右寄せのバブル、アシスタントメッセージは左寄せのバブルで表示します。
アシスタントメッセージにMarkdownが含まれる場合はレンダリングし、平文はそのまま表示します。
サイドバーと会話管理:
固定された左サイドバーを実装します。
上部: 「+ 新しい記事を作成」ボタンを配置します。
中央: 会話履歴をローカルストレージで表示します。履歴がない場合は「まだ会話履歴がありません」と表示します。
下部: 「ゲストユーザー」「オンライン」と歯車アイコンを含むユーザーカードを配置します。
確認アクションにおけるクイック返信機能:
アシスタントメッセージに「『はい』と入力してください」または「「はい」と入力してください」という確認メッセージが含まれる場合、「はい」のクイック返信バッジを表示します。
このバッジをクリックするか、「はい」と入力して送信すると、同一のconversation_idで継続メッセージを送信します。
データ保持要件:
一意のユーザーID(chat_user_id)を管理し、存在しない場合はuser_{timestamp}形式で生成。
会話リスト(chat_conversations)を更新があるたびに保存します。
新しい会話はリストの先頭に追加され、最初のメッセージの先頭50文字からタイトルを生成します。
Difyからの初回応答受信時、一時IDは URL/ストアの主キーとして 維持し、
Dify の conversation_id は difyConversationId として同レコードに保存する。
DifyAPI連携について:
localStorage と state に以下を保持:
userId(初回生成・以後固定)
conversationId(1ターン目の応答から取得)
## 4) 送信先・ヘッダ・認証
URL:https://dev-app.myuuu.co.jp/v1/chat-messages
APP_TOKEN="app-HPuaBLnKSlTCfY0gbVZ1VZqC"
HTTPヘッダ:
Authorization: Bearer <APP_TOKEN>(必須)
Content-Type: application/json
Accept: text/event-stream
---
## 5) マルチターン送信ルール(最重要)
1ターン目:response_mode: **"streaming"** で呼び出し、返却JSONの conversation_id を取得して保持。
2ターン目以降:毎回 同じ user と conversation_id を指定。inputs は毎回必須(空でも {} を送る)。
ファイル:フロントでテキスト抽出→ inputs.document_text に貼る、または別APIにアップロード→参照情報を inputs に含める。
response_mode: "streaming" + Accept: text/event-stream で逐次受信。
HTTPヘッダ:
Authorization: Bearer <APP_TOKEN>(必須)
Content-Type: application/json
Accept: text/event-stream
---
## 5) マルチターン送信ルール(最重要)
1ターン目:response_mode: **"streaming"** で呼び出し、返却JSONの conversation_id を取得して保持。
2ターン目以降:毎回 同じ user と conversation_id を指定。inputs は毎回必須(空でも {} を送る)。
ファイル:フロントでテキスト抽出→ inputs.document_text に貼る、または別APIにアップロード→参照情報を inputs に含める。
response_mode: "streaming" + Accept: text/event-stream で逐次受信。実際に作ってデバッグさせてみよう
このパートでは、実際に実装したチャットアプリを動かしながらデバッグ手法を学ぶ。例として「キーワードから記事生成」を行い、入力→生成→投稿の一連の流れを確認する。投稿時には「投稿に成功しました。ログインし確認してください」とメッセージが先に表示され、その後処理が完了する構造になっている。これは処理待機中の操作を制限する仕組みであり、シングルページアプリケーション(SPA)特有の動作制御を体験できる。デバッグ時はキーワードを複数回試し、生成の安定性や操作制限の挙動を観察する。例えば「NVIDIA」と入力すると記事生成後に一時的に操作がロックされ、投稿完了後に「はい」を押すことでノートへ遷移する。この流れを通して、非同期処理・UI制御・フロー管理といったフロントエンド実装の理解を深め、実際に発生する制約や挙動を確認しながら改善点を把握することが目的となる。