AI搭載デートアシスタント：わずか1円で特別な告白ページを作成

AI分野において、MCP（Microsoft Copilot Plugin）技術は半年以上にわたり絶えず人気を博し、現在最も注目を集めている「新進気鋭」の技術となっています。初期の地図アプリケーションから、続々と登場するニュース系、ツール系MCPエージェントまで、様々なシーンでの応用が絶えずに拡大し、関連製品も数多く登場しています。

嬉しいことに、最近ついに支払い関連のMCPツールがリリースされ、個人開発者から企業まで、より効率的に商業化や収益モデルを構築できるようになりました。また、新たなエージェントプラットフォームである「宝箱エージェントプラットフォーム」にも注目が集まっています。

私は多くのエージェントプラットフォームを試してきましたが、最近偶然「宝箱エージェントプラットフォーム」を発見しました。試してみたところ、サポートされている機能の多さに驚かされました。

そこで、私はカップル向けのインタラクティブエージェントを構築することにしました。このアイデアは、大学時代の少し「古風」だった告白体験から着想を得ています。当時はプライベートチャットで「好きです」と言っただけで、その後「付き合うことになった」という投稿をしただけでした。今考えると、プログラマーとしての技術的な強みを全く活かせていませんでした。

そこで今回は、宝箱エージェントプラットフォームを利用して「君と」という名前のエージェントを迅速に構築することにしました。名前の意味はシンプルです - 食べたり飲んだり、遊んだり、すべての素晴らしい時間が「君と」に関連しているということです。目的もシンプルです - 遊びガイド+手をつなぐコツ+ウェブ告白。特に、恋愛初期で感情表現に戸惑いがちな人に最適です。当時の青くて不器用な自分へのレッスン、といったところでしょうか。

では、私がどのようにしてこの「君と」エージェントを構築したか、ステップバイステップで解説していきます。もし実際にどのようなものか早く見てみたい場合は、後の【デモンストレーション】セクションに直接飛んでみてください！

アシスタント概要

まず、私のエージェントアシスタントは対話型ワークフローに基づいて構築されています。主な理由は、この方法論が論理的により制御可能であり、明確に管理したいインタラクションのリズムと出力内容を処理するのに適しているからです。基本的な構造は以下の通りです：

図が見にくい？心配しないでください。動画で詳しく解説しています、直接効果を見てみてください。

それでは、このアシスタントが何ができるか見てみましょう。現在主に以下の機能を含んでいます：

  • 🎮 遊びガイドの提供 + 心温まる 手をつなぐ/ファッションのコツ
  • 💳 Alipay決済によるメンバーシップ機能の解放、例えば：パーソナライズされた告白ページの迅速なデプロイ、カスタムコンテンツなど
  • 💌 ユーザーは告白ページコンテンツを自分で編集でき、より儀式的な体験！
  • ❓ その他の日常的な質問にも対応可能、質問を恐れません

これらの機能の実装は、基本的にワークフローのネストによって行われます。
なぜメインインターフェースで直接行わないのか？論理が複雑になると、メインインターフェースが遅くなったり混乱したりするため、ワークフロー内でモジュールを直接導入する方法を選びました。これにより、効率が高く、スムーズな体験が実現できます。

構築プロセス

プロンプト設計

まず最も重要な部分であるプロンプト設計について説明します。これはアシスタントの「脳指令」であり、極めて重要です。

私の設計では、大モデルが異なるプラグインを呼び出す際に、自由に発想したりランダムに回答を生成したりするのではなく、事前に設定されたテンプレート形式に厳密に従ってコンテンツを返すことを望んでいます。これにより、特に構造化されたコンテンツ（ウェブテキストや攻略テンプレートなど）の場合、出力の安定性と制御可能性を保証できます。

私のプロンプト設定も参考にしてみてください。内容は以下の通りです👇

あなたは【カップル専用ロマンチックプランナー】として、恋人に心温まる食事や娯楽の提案を提供します。以下のルールに従って応答してください：

---

## 🧠 判断ロジック

**ロジック判断前処理：まずユーザーの質問に以下のキーワードが含まれているか判断してください：**

| タイプ | キーワード例 |
|------|-------------|
| 🎬 映画類 | 「映画おすすめ」、「上映スケジュール」、「公開中」、「何を見るか」、「近くの映画館」、「流浪地球は公開されましたか」 |
| 🎟️ 観光地類 | 「どこへ行く」、「近くで楽しいものは」、「観光地おすすめ」、「週末どこへ」 |
| 🍽️ 食べ物類 | 「近くで何を食べる」、「レストランおすすめ」、「カップルデートご飯」 |

---

### 🧭 コアロジック判断

#### ✅ **ロジック1：曖昧なシーンの質問（具体的な内容が不明確）**

例：  
- 「近くで何が面白いですか？」
- 「カップルは週末どこへ行くべきですか？」
- 「今日は何をするのに適していますか？」

以下の操作を実行します：
1. 地理エンコードツールを自動呼び出し現在位置を取得：
   - 経度：`{{input_hgtoen-client_properties/pos_lng-経度}}`
   - 緯度：`{{input_hgtoen-client_properties/pos_lat-緯度}}`
2. 都市名に基づき天気情報を照会し、カップル向けファッションを推奨
3. 経度・緯度に基づき、5km以内のロマンチックなスポット（カフェ、映画館、公園など）をそれぞれ3つ検索
4. 淘票票の現在公開中の映画を取得

---

#### ✅ **ロジック2：明確な情報の質問（キーワードを含む）**

例：  
- 「流浪地球3は公開されましたか？」
- 「今日の映画おすすめは？」
- 「オッペンハイマーは何時に上映ですか？」
- 「故宮のチケットはいくらですか？」

以下の操作を実行します：
- キーワード `{{input_hgtoen-currentChatByUser-現在の会話情報}} + カップルデート推薦` を使用してQuark検索エンジンを呼び出し
- 高マッチ度のコンテンツを返し、ロマンチックに書き直す（テンプレート参照）

---

## 📝 応答テンプレート

### 🎭 ロジック1応答テンプレート（曖昧な質問）：

愛しい人よ、{都市名}の雲があなたたちのためにハート形に折りたたまれました～  

🌤️ 天気小調 & カップル衣橱  
{日付}の天気メロディ：  
{擬人化天気説明}（{温度範囲}）、{風向}が髪を揺らす  

👫 二重奏スタイル：  
>「彼女」：{女性ファッションストーリー}  
>「彼」：{男性ファッションシーン}  
{温度差彩蛋}：{カップルインタラクション小劇場}  

🌹 ドキドキ加速！ロマンチック座標TOP3  
{場所名} {雰囲気記号} {心臓鼓動スローガン}  
{位置隠喩} {画像リンク}  
💌 私語：{ロマンチック行動提案}  

🎬 銀幕のラブレター・映画館特供  
{作品名} {感情記号} {親密接触予告}  
{上映時間}→{ロマンチック暗喩} {チケット購入リンク} {ポスター}  
🍿 ポップコーン劇場：{カップル専用映画鑑賞時間}  

{星空の祝福語}✨

---

### 🔍 ロジック2応答テンプレート（明確な質問）：

✨ **魔法タグ**  
`{ロマンチックシーン分類}`｜`{感情キーワード}`｜`{カップル特権マーク}`  
> *{詩的説明}*  
▸ 隠しパスワード：`{独占的秘訣}`（例：閉館前30分のゴールデンキスタイム）

---
### 📜 二重情報簿  
**{メインタイトル}**  
[({オブジェクトカバー図})]  

**🌿 基本情報**  
{原始データ}  

**💘 心臓動かす次元**  
{ハイライト売りポイント}  
- • {実用的情報} → 🌟 {ロマンチック意義}  
- • {制限条件} → 🛡️ {解決策}  

**📍 座標結界**  
`{具体的住所}`  
_{地理的利点}_（例「あなたから1.2kmの月光トンネル」）  

**⏳ 時間の砂時計**  
{時間情報}  
{推奨時間帯} + 💞 {愛の暗号}（例：17:20=「一緒に愛してる」上映）

---

### 🧩 変数説明

📍 現在の経度・緯度：  
経度={{input_hgtoen-client_properties/pos_lng-経度}}  
緯度={{input_hgtoen-client_properties/pos_lat-緯度}}

❓ ユーザーの質問：  
"{{input_hgtoen-currentChatByUser-現在の会話情報}}"  
🗂️ ユーザーの過去会話：  
"{{input_hgtoen-historyChat-過去会話情報}}"

---

## 🎯 カップルシーンキーワード認識ルール表

| カテゴリ | キーワード例（スペース/正規表現でマッチ） | 推奨ロジック |
|------|----------------------------------|----------|
| 🎬 **映画類キーワード** | 映画、映画館、上映スケジュール、公開、作品名（オッペンヘイマーなど）、今日の映画、カップル向け映画、上映時間、映画情報、チケット購入、淘票票、流浪地球、ポップコーン、スクリーン、ホール | **ロジック2：明確な情報照会** |
| 🏞️ **旅行/観光地類キーワード** | どこへ行く、観光地、デート場所、近くで楽しい、カップルスポット、デートに適した、カップル向け、週末どこへ、ロマンチックな場所、カップルの聖地 | **ロジック1：曖昧な照会** |
| 🍽️ **飲食類キーワード** | 何を食べる、ご飯、レストラン、アフタヌーンティー、夕食推薦、デートレストラン、カップルレストラン、ロマンチックな夕食、スイーツ店、カップルカフェ | **ロジック1：曖昧な照会** |
| 🌦️ **天気/ファッション類キーワード** | 天気はどうですか、何を着るのに適している、カップルファッション、今日の気温、天気推薦 | **ロジック1（追加天気処理）** |
| 🧭 **目的が明確なキーワード（明確な情報+場所）** | 故宮のチケット、ある場所の営業時間、交通ルート、チケットはいくら、何時に閉まる、予約、予定、××までタクシー | **ロジック2：明確な情報照会** |
| 💡 **曖昧な表現（指向性がない）** | 何がおすすめですか、今日の予定は、ロマンチックにしたい、推薦をお願い、カップル向けのものは | **ロジック1：曖昧な照会**（地理的定位と文脈判断が必要） |

---

## 🧠 判断ロジック提案（疑似コード思路）


IF ユーザーの質問に【映画類キーワード】が含まれる
    → ロジック2（明確な情報照会）に移行
ELSE IF 【旅行/飲食/ファッション/曖昧なキーワード】が含まれる
    → ロジック1（曖昧な照会）に移行
ELSE IF 【目的が明確な場所+情報】が含まれる
    → ロジック2（ある場所のチケット/開館時間など）に移行
ELSE
    → デフォルトでロジック1に移行し、「以下はカップル向けロマンチック推薦です」と提示


以下のような表現を避ける：

「あなたの質問はXXルールをトリガーしました」
「検索エンジンを呼び出します」
「今あなたのサポートを始めます」
結果のみを表示し、プロセスを公開しないでください。

したがって、期待されるインタラクション体験を実現するために、天気照会や周辺検索など、多元的な能力を持たせるために複数のプラグインを統合する必要があります。

ただし注意すべき点は、宝箱プラットフォームではプラグインの数に制限があることです - 同時に最大10個のプラグインしか接続できません。以下の図の通り👇

すべての論理フローと呼び出しルールは、プロンプトで明確に記述する必要があり、曖昧な部分があってはなりません。そうしないと、大モデルが「自由に発想」し、質問から逸れた回答をしたり、プラグインの呼び出しをスキップしたりして、アシスタントの動作が制御不可能になる可能性があります。

すべての論理が適切に設定されると、アシスタントは期待通りに各プラグインを順次呼び出し、カスタマイズされたカップルインタラクション攻略を生成できます～以下の図の通り👇

もちろん、他のタイプの問題を処理するためにもう一つのプロンプトがあります。この部分は比較的シンプルなので、記事の長さを制御するためにここでは詳述しません。

意図認識

意図認識は本当に重要な機能です！私の場合、伝統的な分岐ノードを使うだけでなく、実際には意図認識ノードも頻繁に使用して分岐ロジックを処理しています。これにより、ユーザーが言った内容に基づいて、次にどこへジャンプするかをスマートに判断でき、インタラクションがよりスムーズになります～

以下の図の通り👇

実際、これは大モデルが各専用プロンプトに焦点を当てて回答できるようにするためのものです。

一つのプロンプトが複雑すぎたり、カバー範囲が広すぎたりすると、後の調整がより困難になります。それよりも、複数の独立したプロンプトに分割して、それぞれが役割を担うようにした方が、管理と最適化が容易です。

MCPの統合

このプロジェクトでは、2つのMCPツールを使用しました：

  1. Alipay決済MCP（体験版）：正式版を申請する計画でしたが、商家資格が必要なため条件に合わず、最終的に体験版を代替として使用しました。
  2. ウェブデプロイMCP：これはもう一つの非常に重要なツールで、私たちのコードをパブリックネットワークにデプロイするために使用されます

Alipay決済

Alipay決済MCPの接続は比較的簡単で、ワークフローに関連ノードを追加するだけで実現できます。

しかし実際の使用において、最大の問題は注文番号の管理にあります。ワークフローで固定の注文番号を使用すると、システムは現在の支払い行為がどのユーザーからのものであるかを区別できず、支払い情報の混乱を引き起こす可能性があります。

この問題を解決するために、各ユーザーに動的に一意の注文番号を生成するための補助ワークフローを設計しました。これにより、支払いがトリガーされるたびに注文番号が現在のユーザーに正確にバインドされ、後続の検証の正確性が保証されます。

図の通り：

各ユーザーが支払いを開始する際に常に一意で安定した注文番号を使用するために、システムではユーザーと注文番号間のマッピング関係を永続的に保存するデータベースを導入しています。

永続化しないと、各フロートリガーで新しい注文番号が生成され、支払い記録が正しくユーザーに関連付けられない可能性があります。そのため、ここでは注文番号生成後にデータベースに書き込みます。その後、同じユーザーが支払いを完了していない場合に再度フローをトリガーすると、システムはまず既存の注文番号をクエリして再利用し、重複生成を避けます。

データテーブルの構造は非常にシンプルで、以下の通りです：

各ユーザーが一意で安定した注文番号を持つことを保証するために、システムでは以下のロジックを採用しています：

  1. まずデータベースをクエリ：注文番号が既に存在するかどうかを確認します
  2. 存在する場合：その注文番号を直接使用します
  3. 存在しない場合：コードノード（Pythonスクリプト）を呼び出して新しい一意の注文番号を生成し、ユーザーIDとともにデータベースに書き込みます

これにより、ユーザーが繰り返し「支払い」を行う際に複数の異なる注文番号が生成されるのを避けられます。

これで注文番号生成とユーザーバインディングの前提ロジックが整いました。次のステップはAlipayインターフェースの支払いパラメータを構築して渡すことです。

現在体験版MCPを使用しているため、設定した支払金額はわずか0.01元（1銭）であり、Alipayは翌日自動的に返金を行うため、ユーザーには実際のコストはかかりません。

以下の図のように、支払いパラメータ構築ノードは以下の通りです：

注文番号の生成とAlipayパラメータの構築が完了すると、システムはメッセージカードを通じてユーザーに支払い情報を表示し、支払いボタンを提供します。ユーザーがクリックするとAlipay支払いページにジャンプし、支払い操作を完了します。

これで支払い機能は完了です。

カスタムウェブページのデプロイ

ユーザーが支払いを引き受ける背景には、明確な機能や価値を得たいという動機があるはずです。さもなければ、彼らが財布を開く理由はありません。そのため、私たちは支払い行為の返礼品として「カスタム告白ウェブページ」機能を正式にリリースしました。

説明が必要なのは、これらの告白ウェブページがリアルタイムで生成されるわけではないということです。現在の大モデルは実際にリアルタイムでウェブページコンテンツを生成する能力を持っていますし、論理構造と文法の正確性において安定していますが、ページの美しさやユーザーの感情表現において、依然としてユーザーの期待との間に一定のギャップが存在します。さらに、リアルタイムでコンテンツを生成する速度も遅く、全体的な体験に影響を与える可能性があります。そのため、「ローカル開発+AI補助」の方法で2つのページコードを開発しました。

ワークフローの詳細は以下の通りです：

もちろん、ここでもコンテンツの入力にコードノードを活用しています。最初の情詩ウェブページでは、ユーザーの要求に基づいて大モデルに生成させる必要があります。プロンプトは以下の通りです：

具体的な要求に基づき、オリジナルの中国語の恋愛詩を創作してください。
各行には完全な詩句のみを出力してください（2行を1行にまとめないでください）
本文では句読点（コンマ、ピリオドを含む）を使用しないでください
タイトル、説明、その他の追加情報は不要です。詩句の本文のみを出力してください。
感情は真実で繊細であり、言葉は美しいことを要求します。恋愛詩の本文のみを厳密に出力し、タイトル、説明、説明、その他の追加情報は不要です。
ユーザーが案2を言及した場合は、空の文字列を直接返すだけです。
具体的な要求：{{input_hgtoen-text_nq2ybj-案}}

情詩ウェブページの効果は以下の通りです：

もちろん、記憶アルバムウェブページもあります。主にユーザーがすべての画像をアップロードする必要がありますが、ここでは最近アップロードされた4枚の画像のみを保持できます。操作例は以下の通りです：

画像をアップロードした後、アシスタントに以下のように言うことができます：

告白ウェブページをオンラインに：案二

最終的な効果は以下の通りです：

もちろん、すべての記録は安全にあなたの個人データベースに保存され、完全に独立してプライベートであり、データのセキュリティとプライバシー保護を保証します。安心してご使用いただけます。以下にデータベースの構造設計を示します：

これで主要機能の開発は基本的に完了し、次の焦点は商業化方向への探索と拡張に移ります。恋愛初心者にとって、実用的な「手をつなぐコツ」を提供することは、初期の緊張や不安を効果的に和らげ、彼らの恋愛自信を高めるのに確かに役立ちます。

また、心を込めて設計された「告白ウェブページ」は、感情表現にさらなる儀式感をもたらすだけでなく、相手の感情への印象を深めることもでき、結果として全体的なユーザーエクスペリエンスと製品の感情価値を向上させます。

デモンストレーション

商業化についての考察

商業化方向は完全に実現可能であると私は考えます。現在市場には数千万の「恋愛初心者」がおり、青少年から中高年までのあらゆる年齢層をカバーしています。彼らは恋愛、告白、感情コミュニケーションなどにおいて普遍的なニーズを持っています。初期の『恋愛バイブル』から現在のあらゆる恋愛コースや感情コンサルティングサービスに至るまで、この種のコンテンツは常に安定した層基盤を持っています。言い換えれば、市場は存在し、ユーザーのニーズも実在します。

現在私が構想している商業化モデルは、カスタマイズされた告白ウェブページサービスの提供です。ユーザーは象徴的な価格、例えば1銭のみを支払うことで、専用のオンライン告白ページを生成できます。このような低いハードルで強い感情付加価値を持つサービスは、それ自体に一定の魅力があります。もちろん、ユーザーエクスペリエンスと転換率をさらに向上させるためには、いくつかの単純なカスタムウェブページだけでは不十分です。より豊富なインタラクション機能、より精緻なビジュアルデザイン、より多くの参加可能なコンテンツモジュールを提供する必要があります。そうでなければ、ユーザーは「カスタマイズ」の価値を感じ取り、それに支払う意思を持つことはできません。

また、私は多ユーザーデータベースに基づいた「オンラインお見合いコーナー」機能を開発することも構想しましたが、現在のリソース投入、技術的複雑さ、およびエージェントの主要利用者層から見ると、この方向の実現には大きな困難があり、短期間での優先開発価値はありません。したがって、このアイデアは一時的に保留しています。

もちろん、もっと実現可能で、着地性が高く、ユーザーとの適合度の高い商業化のアイデアや機能提案があれば、ぜひお聞かせください。

支援のお願い

最後に、私のこの創造性やアイデアがあなたにインスピレーションを与えた場合、または「君と」エージェントの使用過程で実用的な提案や助けをもたらした場合、ブロガーをサポートしていただくことも大歓迎です。あなたの支援はすべて、この製品をさらに完善させ、創作を続けるための最大の励みです。

支援ボタンは使用インターフェース上にあります。以下の図の通り

それほど目立つわけではないかもしれませんが、あなたの気持ちはきっと伝わると思います😊

では、「君と」エージェントについての解説はここまでにします。もっと多くのアイデア、提案、協意向きがあれば、いつでもお気軽にお問い合わせください。一緒に感情製品をより温かく、より楽しいものにしていきましょう。

タグ: AI MCP デートアシスタント ウェブ開発 alipay

5月22日 01:13 投稿

ホットタグ

©2026 異端開発室