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

Bolt x Dify 実践！APIキー秘匿化入門

オンライン学習プラットフォーム「Bolt.new」を活用したアプリ開発講座の最終回。PoCから本番環境へのスケール時に不可欠な、環境分離、ドメイン設定、APIキーなどの秘匿情報管理の要諦を解説します。

学習ポイント

  • 開発・検証・本番の3層環境による安全なデプロイ体制の構築方法
  • APIキーの露出を防ぎセキュリティを高める「シークレット」とサーバー関数の運用
  • 個人情報保護、コスト管理、ログ監視など、サービス拡大時にエンジニアへ引き継ぐべき重要項目

本日のゴール（そのまま使える）

  • これからスケールしていく上で押さえるべき最小項目を理解

  • なぜシークレット運用が重要かを腹落ち

  • PoC段階の最小限のシークレット運用を実践

タイムライン（45分）

  1. スケールに向けた全体像（5分で俯瞰）（合計10分枠の前半）

  2. シークレットの基礎（概念整理）（10分）

  3. 露出確認デモ（Boltで作ったサイトをDevToolsで覗く）（10分）

  4. 正しい管理パターン（Secrets＋サーバ関数）（10分）

  5. 終わりに

スケールに向けて必要なことを学ぶ

https://poc-to-production-gu-r3pa.bolt.host

プロダクトをスケールさせる際に最も重要なのは「安全・安定・効率」の3軸をどうバランスさせるかです。まず第一に取り組むべきは環境分離（Environments）。開発（Dev）、検証（Staging）、本番（Prod）の3環境を用意することで、リリース時の影響を最小化できます。ただし環境を増やすほどコストも上がるため、最初は2環境（開発＋本番）から始め、事業が成長した段階で段階的に拡張するのが現実的です。

次に重要なのが**ドメインとTLS（HTTPS）**の設定。独自ドメインを取得し、SSL証明書を導入することで信頼性と安全性が確保されます。Bolt.newなどを利用すれば、独自ドメインやサブドメインの設定、HTTPS対応も簡単に行えます。理想はOGP画像設定などSEOまで含めた設計ですが、まずは「安全な接続」が第一歩です。

デプロイ運用ではGitによるバージョン管理と履歴管理が鍵となります。誰が・いつ・何を変更したのかを可視化することで、チーム開発が格段に安全になります。

そして最もリスクが高いのがSecrets（シークレット）管理。APIキーやトークンが漏洩すると、金銭的損害やシステム停止につながるため、必ずコード直書きを避け、Boltの「Secrets設定」などで安全に管理しましょう。「鍵はSecrets、呼ぶのはサーバ、フロントは結果だけ」というルールが鉄則です。

加えて、ログ・モニタリングはスケール段階での重要要素です。ユーザー行動やエラーを可視化することで、改善ポイントを迅速に特定できます。特にBtoCサービスではログが唯一の顧客理解手段となるため、早めの導入を推奨します。

データポリシーの整備も忘れてはいけません。個人情報を扱う場合は、規模に関わらず利用規約・プライバシーポリシーの設置が必須です。

最後にコスト／レート管理。優れたエンジニアは「機能開発＋コスト最適化」を両立できる人材です。クラウド料金やAPIの利用料を意識した設計を行い、無駄な支出を抑えることが長期的な成長を支えます。

全て説明すると時間がかかりすぎるため、今回はシークレットに絞って解説していきます。

シークレットの基礎（概念整理）（10分）

https://web-secrets-manageme-5atk.bolt.host

はい、それではシークレット管理について簡単にまとめていきます。まず基本的に方法は3つあります。1つ目が「ハードコーディング」、これはコードに直接キーを書いてしまう方法で、原則NGです。ただしMVPフェーズなど、影響範囲が小さくスピード優先のときは一時的に使うこともあります。2つ目が「フロント環境変数（VITE_など）」で、こちらは誰でも見られる状態になるので、公開しても問題ない値だけ入れるようにします。そして3つ目が「シークレット」。これが最も安全で、サーバー側だけが読み取れる非公開の値です。BoltやVercelなどのホスティングサービスには必ずこの機能があるので、APIキーなど重要な情報はすべてここに登録しましょう。もし設定漏れがあると「Missing Secrets」バナーが出るので、それを目印に設定を完了させるのが正しい運用です。

露出確認デモの作成

まず最初に以前作成したアプリからネットワークタブでAPIキーが見れることを確認します。

露出確認デモでは、まずこれまで作成したアプリを使い、DevToolsのネットワークタブからAPIキーなどの情報が実際に露出しているかを確認します。特にPayLoad内にキーやIDが含まれている場合、第三者に悪用されるリスクがあり、APIの不正利用や情報漏洩につながる恐れがあります。こうした問題は初心者が作るPoC段階のアプリで多く見られ、攻撃対象になりやすい点に注意が必要です。BtoBサービスでは契約や認証によりリスクを抑えられますが、一般公開するBtoCアプリでは特にシークレット管理を徹底することが重要です。次に、この露出を防ぐための正しい対策方法を見ていきます。

以前使ったプロンプト

# 目的

テーマまたは 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

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

https://note-article-chat-cr-hvza.bolt.host/

ペイロードハッキング

正しい管理パターン

次に正しい管理パターンであるものを確認します。

正しい管理パターンでは、APIキーなどの機密情報を必ずシークレットとして登録することが基本です。プロンプト上でも「この値はシークレットに入れてください」と明示し、AppTokenなどを直接コードに書かないようにします。ただし、Claudeなど一部モデルではSupabase MCPへのシークレット渡しがうまくいかない場合もあり、その際は手動で設定する必要があります。手動設定ではAPIキーを「Secrets」に登録し、一時トークンを利用することで期限付きの安全なアクセスを実現できます。これにより、ネットワーク上でのキー露出を防ぎ、仮に漏れても期限切れで無効化されるため、セキュリティが大幅に向上します。

正しくなるようなプロンプトを作成する。

# 目的

テーマまたは 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

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

https://note-article-draft-c-hn3w.bolt.host/

終わりに

講座はいかがだったでしょうか。今回の内容はやや難しい部分も多かったと思いますが、技術を少し理解するだけで、一人でものづくりの幅が大きく広がることを実感いただけたのではないでしょうか。本シリーズでは、POC（実証実験）までをノーコード／ローコードで完結させ、そこから先をエンジニアと連携して進めるという世界観を目指しました。短時間の講座のため要点のみの解説となりましたが、ぜひChatGPTなどを活用しながら自走力を高め、自分でアプリを作り挑戦する“バッターボックス”に立ってほしいと思います。6回にわたる受講、本当にありがとうございました。