こんにちは！
遠隔見守りシステム「REMONY」のPMをしている寺本です。
最近はやわらかジューシーな鶏胸肉のサラダチキン作成方法の研究とAI活用にハマっています！
さっそくですが、
「営業やCSからの仕様やバグに関する質問対応に追われる日々...」
そんな課題を抱えるPMは多いのではないでしょうか。
今回は、DifyとCursorを活用して構築したchatBotシステムにより、この課題を解決した事例をご紹介します。
REMONYとは
私たちが開発しているREMONYは、充電不要のウェアラブルデバイス「MOTHER Bracelet®」と連携する遠隔体調管理システムです。
システム構成
REMONYは以下の要素で構成される複雑なシステムです：
- ゲートウェイ: データ収集・転送の中継点
- MOTHER Bracelet: 充電不要のウェアラブルデバイス
- ファームウェア: MOTHER Bracelet内蔵の制御プログラム
- ダッシュボード: 管理画面（事業者向けWebアプリケーション）
活用領域
- 介護現場: 入居者管理、バイタルデータ監視、アラート管理
- 工場: 作業員の安全管理・体調監視、アラート管理
このような「複雑なシステムであること」と「包括的なドキュメントの作成ができていなかったこと」により、営業やCSから仕様に関する質問が日々多く寄せられていました。
「また仕様の質問が...」「同じ質問に何度も答えてる...」
そんな状況を解決するために、DifyとCursorを活用したchatBotシステムを構築しました。その結果、以下のような成果を実現できました。
実現した成果
- 質問対応時間の大幅削減 - PMの工数負荷を軽減
- 営業からの質問数の減少 - 自己解決率が向上
- 戦略業務への集中時間確保 - 本来業務により多くの時間を投資できるように
なぜこの解決が必要だったのか
私たちが直面していた課題
開発初期からアジャイル開発を続けてきた結果、体系的な仕様書が存在しない状況になっていました。
なぜドキュメントを軽視してしまったのか
アジャイル開発で進めているような企業では、同様の問題があるのではないでしょうか...？
ドキュメントをしっかり作っていなかった理由：
- 日々変わる仕様に対して仕様書の更新を行なっていくのが大変
- 更新作業の漏れが必然的に発生してしまう
- 「動くソフトウェア」を優先してきた結果
アジャイル開発とドキュメント軽視が生んだ課題：
🔹 情報の分散と検索困難
- 仕様情報がPMの記憶、ソースコード、実際のソフトウェア/ハードウェアの挙動、開発時の部分的なドキュメントなどに分散
- 営業から「ゲートウェイとMOTHERが繋がらない場合の対処法は？」「アラートの詳細仕様を教えて」といった質問が日々寄せられる
- 散在する情報を統合して回答できるのがPMのみという状況
🔹 アジャイル開発の弊害
- スプリントごとに仕様が変更される
- 「動くソフトウェア」を優先した結果、情報共有や仕様書の作成が後回しになる
🔹 持続可能でない質問対応
- 同じ質問に何度も答える非効率性
- PMが情報のボトルネックになってしまう構造
- 戦略的な業務に集中する時間が確保できない
LLMの発展が可能にした解決策
これらの課題が最近のLLMの発展によりコストが低く実現できる時期がきたと考えました。
そこで、実際にシステムを作成し運用まで行なってみることにしました。
目指した理想の状態
PMに聞かなくても、社内メンバーが必要な時に正確な仕様情報を確認できる環境
この理想を実現するために、以下の要素が必要と考えました：
- 仕様やバグに関する質問に答えるchatBot ←今回実装
- リリースのたびに仕様書が自動更新される仕組み（今後実装予定）
- 最新の仕様書からchatBotが回答するように
- 営業やCSがいつでも最新の情報にアクセスできるように
本記事では、chatBotの作成方法に焦点を当てて解説します。残りの2つの要素については、今後の展望として後述いたします。
解決のアプローチ
前述した情報の分散と検索困難さと持続可能でない質問対応の課題を解決するため、LLMを活用したchatBotシステムの構築に取り組みました。
選択したツール組み合わせ
Cursor + Dify + Notion + Slack の連携でchatBotシステムを構築
各ツールの概要
Cursor
- AIが統合されたコードエディタ
- MCP（Model Context Protocol）でNotionなど外部サービスと連携可能
- 自然言語での指示でコードやドキュメントを効率的に作成可能
Notion
- チーム向けの情報管理・共有プラットフォーム
- マークダウン記法に対応し、構造化されたドキュメント作成が可能
- APIやMCPを通じて他のツールとの連携をサポート
Dify
- ノーコードでAIエージェント・chatBotを構築できるプラットフォーム
- 複数のデータソース（Notion、Google Drive等）と連携可能
- GPT-4、Claude、Gemini等の主要LLMを選択して使用可能
Slack
- ビジネス向けチャットツール
- Bot APIで外部システムとの連携が容易
- 多くの企業で既に導入済みのコミュニケーション基盤
なぜこの組み合わせを選んだのか？
Cursor選定理由
- 2025年4月の実装時点で最も適切なAIエディタの選択肢と判断
- NotionとのMCP連携によるドキュメントの編集が可能
- AI支援により仕様書作成を効率化
Notion選定理由
- Cursorで作成したマークダウン記法で書かれたドキュメントをそのまま反映できる
- Difyとの連携でchatBotのデータソースとして活用可能
- 見やすく共有が容易で、チーム全体での情報アクセスを実現
- 例えば、Githubでドキュメント管理した場合はエンジニア以外はドキュメント参照がしにくくなる
Dify選定理由
- ノーコードでのchatBot構築が容易で開発工数を最小化
- 複数のLLMモデル（GPT-4、Claude等）から最適なものを選択可能
- chatBotの回答精度や動作を非エンジニアでも調整・改善できる
Slack選定理由
- 弊社の既存ワークフローに自然に組み込める
- 営業・CSが新しいツールを覚える必要がない
- 質問のハードル低下：いつも業務で使用しているSlackで気軽に質問可能
実装ステップ
Step 1: Cursorを使った仕様書の作成
Cursorの利用が初めての方へ
Cursorの使い方については、以下の記事が詳しく解説してくれています。
効率的な仕様書作成のポイント
テンプレート化で品質を統一
- Cursor rulesを活用して仕様書のテンプレートを作成
- 一貫した構造とトーンで仕様書を生成可能
ルールの記載方法については以下に詳細が記載されているので、使い方がわからない方は参照してみてください。
マークダウン記法を活用
- Notionへの直接エクスポートが可能
- AIが内容を理解しやすい形式
- 書式を気にせず内容を記載し、後からCursorのエージェントモードでマークダウンに整形
実践的なアプローチ
- 最初は雑な記載でも問題なし
- Cursorに読みやすい文章に変換してもらう
実装時の学び
自動生成の限界と対策
- ソースコードからの自動仕様書生成も試行したが、満足のいく品質には至らず
- 2025年4月の段階ではCursorは全てのソースコードを読み仕様書を作成するまでの能力は試したところなかった
- 各種モデルやCursorの能力向上、さらにClaude Codeの台頭などにより、現在では実現可能となっている可能性がある
- REMONYはバックエンドとフロントエンドのリポジトリが別々なためより、コードからに仕様作成が難しい状況だった
- 2025年4月の段階ではCursorは全てのソースコードを読み仕様書を作成するまでの能力は試したところなかった
- 最終的にCursorと協働しながら手動で作成する方式を採用
Step 2: CursorとNotionのMCP連携
Cursorで統合・整理した仕様書を、チーム全体がアクセスできるNotionに転記し、情報の統合管理を実現する。
MCPとは
MCPとは、「アプリケーションがLLMにコンテキストを提供する方法を標準化するオープンプロトコル」
詳細は以下を参考：
連携設定の参考資料
NotionとCursorのMCP連携方法については以下の記事が詳しく紹介しています：
実装時の注意点
- 弊社内での仕様書共有が主な目的のため、チームに合った使いやすいシステムを選択を推奨
- CursorからNotionへのMCP転記は文字量が多いと時間がかかったりトークンの消費が多いため注意が必要
※ 2025年8月13日現在、Notin公式サイトにてMCPのアップデートにより「時間がかかる問題」および「トークン消費量の問題」が改善されたとの報告があり、解消されている可能性が高い。
Step 3: Difyを使ったchatBot構築
具体的なDifiを使ったchatBotの作成方法について以下の記事を参考にしてください。
実装しての学び
- 回答精度を上げるにはナレッジのチャンク設定、インデックス方法の設定などが重要
- webアプリのどこにどの機能があるかをchatBotに回答させてい場合は、mermaid記法のフローチャートが有効
Step 4: Slack連携
最後に、営業・CSが日常的に使用しているSlackにchatBotを配置し、質問のハードルを下げる環境を整えます。
連携方法については以下の記事が詳しいので参照ください。
運用結果
チームからの反応
実際に営業に使ってもらうと、
「良い回答が返ってくるし、会話も成立するから使い勝手が良い」
「PMへの質問が減りそうです」
などといった声をもらいました。
以下が、実際に営業がchatBotへ質問している様子です。
実際の運用フローの変化
導入後は、以下のような質問フローが定着：
- まずchatBotに質問 - 営業・CSが最初にBotに確認
- Botで解決しない場合のみPMに確認 - より複雑な状況や特殊なバグなどの場合
この2段階フローにより、PMへの質問数がかなり減少し、本来の業務により多くの時間を投資できるようになりました。
今後の展望
今回構築したchatBotをベースに、以下の機能拡張を計画しています：
仕様書の自動更新
Pull Requestやリリース内容を確認し、変更点を自動で仕様書に反映する仕組みを構築予定。GitHub ActionsとDifyを組み合わせた自動化を想定しています。
ユーザー向けchatBot作成
現在の社内向けchatBotをベースに、顧客が直接利用できるヘルプ機能としての展開を検討中です。
chatBot回答精度の向上
仕様書の記載方法やDifyの設定を継続的に調整し、より正確で有用な回答ができるよう改善を進めます。
一緒に開発しませんか？
メディロムグループでは以下のようなサービスを展開しています。
- 全国300店舗以上のリラクゼーションスタジオ「Re.Ra.Ku」
- 世界初！充電不要の活動量計「MOTHER bracelet」
- ヘルスケアコーチングアプリ「Lav」
ヘルスケア領域に興味があるエンジニア、PMを絶賛募集中です！
興味がある方は以下からエントリー可能です。直近はAI活用にも力を入れていますので、AIを使った開発をしたい方もお待ちしております。
一緒に新たなヘルスケアサービスを作りましょう🔥
「Re.Ra.Ku」など全国 300 店舗以上のリラクゼーションスタジオを展開. 自社管理のサイト・決済・アプリ開発、充電不要な活動量計「MOTHER bracelet」関連開発を行っています. 主な技術スタック Ruby / TypeScript / Swift / Kotlin / AWS / GCP など.
Discussion