投稿する
📚 Bolt・Difyで作るAIアプリケーション開発講座

Git入門:Boltで学ぶバージョン管理と開発効率化

AI開発ツール「Bolt」とGit/GitHubを連携させ、本番環境を壊さずに新機能を開発する「ブランチ管理」や「プルリクエスト」の仕組み、エンジニアの評価基準について解説します。

学習ポイント

  • Gitのブランチ機能を使い、パレレルワールド(並行世界)で安全に開発・検証する方法
  • プルリクエストとマージを用いた、複数人でのコードレビューと本番反映のプロセス
  • フェーズ(MVP・収益化後・エンタープライズ)に応じた適切な開発フロー(Git Flow)の使い分け

本日のゴール

アジェンダ

  1. ウォームアップ(前回のおさらい)と今日のゴールを説明(5分)

  2. Gitの仕組みを理解しよう!(20分)

  3. 実際にGitの動作を確認しながらBoltの開発をしてみよう(20分)

  4. 質問タイム(15分)

ウォームアップ(前回のおさらい)と今日のゴールを説明(5分)

ではウォームアップから。前回は、開発の全体像とチームでのコラボの流れを確認し、Boltで小さな変更を反映するところまで体験しました。今日はその土台の上で、なぜGitが必須なのかを体感しながら学びます。ゴールは二つ。①Gitの仕組みを理解 ②実際に手を動かして動作確認。経営者や非エンジニアにも役立つ視点で進め、Gitの仕組みを説明したら実演に入ります。

Gitの仕組みを理解しよう!(20分)

https://web-app-git-branchin-iylg.bolt.host/

本題:なぜGitか。UI→API→認証→Stripe課金を足していく途中で「ログインが壊れた!」という典型的事故が起きたとします。原因は即時には特定できず、状態は戻したい、でも本番は直さねばならない。単なる“時系列の作業履歴”だけでは、未完成の課金画面ごとデプロイするか、課金実装を消してバグ修正を入れるかの二択で詰みがちです。ここで効くのが“並行世界”=ブランチ。main(お客さまに見せる線)から緊急のhotfixブランチでバグだけ直して本番復旧、未完成の機能はfeatureブランチで安全に続行——これで「戻せる/隔離できる/選べる」が揃います。AIコーディングは不確実性が高く、同じ指示でも結果が揺れるため、複数ブランチで試行→最良だけをmainにマージ、失敗は捨てる運用と相性抜群です。チーム開発の定番GitFlowは、developで日常開発+feature統合、release(staging)で最終検証、mainへリリースという三層で“安全に出す”仕組み。ただしMVPや小規模なら過剰になりやすく、まずは「本番(または簡易検証)×feature/hotfix」で十分。目安としては、チーム5人超・QA担当あり・“本番を絶対壊せない”状況、ユーザー200人・MRR50万円超あたりからGitFlow検討が現実的。要はGitは、実験できる遊び場とロールバック性、意思決定の選択肢を同時に担保する、経営・非エンジニアにも価値のある基盤です。

実際にGitの動作を確認しながらBoltの開発をしてみよう(20分)

BoltにGitを採用する手順の要点:Boltを開いて最初のプロンプト入力→「Gitリポジトリ登録」へ。Gitアプリ連携(Gitでログイン)済みなら、リポジトリ名/URLを入れてボタンを押すだけでGitHubに新規作成・同期されます。以後の編集は自動でコミット履歴に残り、いつ何を変えたか追跡可能。実践では“ブランチをたくさん切って安全に実験”が肝。UIの「+」でブランチ作成→そのブランチで更新すればproductionに影響なし。GitHubで一元管理しておくと、Boltトップから常にproduction状態を起点に編集開始でき、差分比較・ロールバック・検証後のmainマージもスムーズ。これがBolt×Gitの実運用メリットです。

プロンプト

# 目的

テーマまたは YouTube URL から Note 用の記事草案を生成するチャットアプリを実装する。
対話生成ロジックはDify APIで実装する。

# 画面構成

認証画面:
メールアドレスとパスワードを入力する認証画面からログインした場合に、
以下に記載しているチャット機能ページへ遷移する。

ユーザー登録時に、メールアドレスの存在を確認し、

ユーザー名はメールアドレスとしてアプリの処理を作成してください。

ヘッダー:
「Note記事制作ツール」+サブコピー「テーマまたはYouTube URLから記事を生成」。

モード選択ボタン:
横並びで以下の色で構成する
「キーワードから自動生成」= エメラルド
「YouTubeから自動生成」= グレー

メッセージエリア:
初回メッセージ送信後、永続的なチャットUIに遷移します。
入力フィールドと送信ボタンは画面下部に固定表示され、継続的な入力ができるようにする。

メッセージ入力ボタン:
選択モードに応じて文言を動的変更。
「キーワードから記事を生成」ボタン。

メッセージ表示:
ユーザーメッセージは右寄せのバブル、アシスタントメッセージは左寄せのバブルで表示します。
アシスタントメッセージにMarkdownが含まれる場合はレンダリングし、平文はそのまま表示します。

サイドバーと会話管理:
固定された左サイドバーを実装します。

上部: 「+ 新しい記事を作成」ボタンを配置します。
中央: ユーザー単位で会話履歴を表示します。履歴がない場合は「まだ会話履歴がありません」と表示します。
下部: 「ユーザー名称」、歯車アイコンを含む設定アイコン及びログアウトボタンを配置します。

確認アクションにおけるクイック返信機能:
アシスタントメッセージに「『はい』と入力してください」または「「はい」と入力してください」という確認メッセージが含まれる場合、「はい」のクイック返信バッジを表示します。
このバッジをクリックするか、「はい」と入力して送信すると、同一のconversation_idで継続メッセージを送信します。

チャットデータ:
メールアドレス(user_email)をIDとして、ID・会話履歴単位でデータを保持します。
Difyからの初回応答受信時、一時IDは URLもしくはキーワードをPrimary Keyとして保持し、
Dify の conversation_id は difyConversationId として同レコードに保存する。

## 4) 送信先・ヘッダ・認証
DBに以下を保持:
userId(初回生成・以後固定)
conversationId(1ターン目の応答から取得)

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ターン目:認証メールアドレスをユーザー名として、返却JSONの conversation_id を取得して保持。
2ターン目以降:毎回 同じ user と conversation_id を指定。inputs は毎回必須(空でも {} を送る)。
response_mode: "streaming"
Accept: text/event-stream

実際に作った3つのブランチ

https://bolt.new/~/sb1-y1qqe2du

https://bolt.new/~/github-r8n5ge86

https://bolt.new/~/github-gm6rn7sn

Note自動投稿ワークフローについて

Dify Workflowの特典では、構築が難しい部分を補うため、指定URLにアクセスしIDとパスワードを設定するだけでワークフローが動作します。流れとしては、まずLAMでタイトルと本文を分解し、続いてメールアドレスとパスワードからセッショントークンを取得。その後、コード実行によりトークンを利用して下書きを自動投稿し、ステータスを更新すれば投稿完了となります。DSLファイル設定後にパスワードを入力すれば利用可能です。

ワークフローDSLファイル

📎 note自動投稿_説明用.yml

使用して頂くlambda関数に関して

  • 技術習得のための範囲でご使用して頂き、他の利用者様を考慮してバッチで複数回叩くなどをしないようお願いします。

  • Note側のAPIの仕様の変更など外的要因により使えなくなることがありますので、ご参考用のAPIとしてご使用ください。