Difyでしくじった話：楽しくツール開発ができる落とし穴

はじめに

はじめまして。株式会社リンクアンドモチベーションの阿部です。
現在、社内の生成AI活用促進を行っています。

弊社の社内DXチームでは、8月からDifyを使い始め、チームとして100個以上Difyでツールを開発しました。
（Difyを使い始めたきっかけはこちらです）

背景

これはDifyを触ったことある方には伝わると思うのですが、

• Difyでツールのプロト作るのめちゃ簡単にできる！！
• Difyで簡単にツールを作れてしまうのはめっちゃ楽しい

誰でも『僕のヒーローアカデミア』の発目明（はつめめい）になれてしまう！

つまり、「ドッ可愛いベイビー（＝ツール）」がどんどん量産できる！

そんな革命が私たちのチーム内でも起こりました

しかし、その楽しさのあまり、失敗したことも多々発生しました。

記事の内容と対象

内容
この記事では、私自身のしくじりエピソードを通じて、
同じような失敗を防ぐためのポイントを共有します。

対象

• 自分自身の効率化だけでなく、他者の業務効率化を支援するツールをDifyで開発している方
• 「Difyで簡単にツールを作れる楽しさを知っている！」という方
• 初めてのツール開発をDifyで行う方

しくじりエピソード①：課題よりもツール開発・リリースに目が向いた

背景

Difyの便利さに惹かれ、「どんどんツールを作りたい！」という気持ちが先行した結果、
以下のような問題が発生しました。

具体的な課題

1. 要件定義が甘く、手戻りが無限に発生してしまう😵‍💫

   • 情報の粒度が曖昧で、必要な機能を正確に定義できていなかった。
   • ユーザーごとのニーズに応じた期待値調整が不十分だった。

2. ヒアリング対象の偏りがあり、リリースしても一部のユーザーにしか刺さらない💔

   • 若手メンバーや部署のマネージャーだけに意見を聞いたことで、案件を具体的に監督している中間層の視点が欠けてしまった。
   • また、特定のマネージャーの進め方にしか適用できないプロセスを取り入れてしまい、他のマネージャーのチームメンバーには使えないツールになった。

教訓

課題設定の部分で、さまざまな教訓があったのですが、その中で一つご紹介します。

• エレベーターピッチを活用し、情報整理・合意形成を行うのが良い
  Difyで実装する前に、以下のエレベーターピッチを作成し、自分自身での課題の明確化とユーザーの合意形成を行うべきでした。

エレベーターピッチの型

エレベーターピッチとは、ツール開発において、アイデアを簡潔かつ魅力的に伝えるための方法です。

• 開発者にとっては、ツールの目的を整理し、開発ツールの価値を明確にする助けとなります。
• 利用者にとっても、そのツールが何を実現するのか、どのように役立つのかを分かりやすく理解できるため、認知度や受け入れやすさが向上します。

端的に、関係者や利用者にツールの価値を伝えられるのが、大きな利点です。

例）

「顧客情報収集でいろんなサイトを探し回る手間」を解決したい。  

「○○部署のコンサルタント」向けの、  
「顧客情報収集Bot」は、  
「顧客に関わる記事のリストと要点をまとめてくれるBot」である。  

これは、「内部mtg前に調べておくべき最低限の情報を1発で検索すること」ができる。  

「Google検索」とは違って、複数の調べるべき項目を一括で調査できる。

「Perplexity」とは違って、  
「会社の”最新情報”を必ず取得でき、調査の観点もあらかじめまとまっている」。

学びと今後の改善策

1. ヒアリング対象の多角化

   • 若手、マネージャー、その間の役職の方など、業務への視界が異なるメンバーから広く意見を集める。
   • プロセスの違いを把握し、共通の進め方は何か、違う部分は何かを明らかにする

2. エレベーターピッチによる方向性の明確化

   • 上記のピッチ例のように、課題、対象ユーザー、ツールの機能、既存のツールとの差別化ポイントを整理することで、開発前の目的を明確にする。

しくじりエピソード②：Difyでなくて良いものをDifyで作ってしまう

「Difyで何か作って貢献したい」という気持ちから色々なツールを爆速で作りましたが、振り返ってみると課題の解決方法がDifyではなくてよかったものがありました。

今回は2つお伝えします。

筆者はツール開発が初めてだったため、とりあえずDifyで何でも試してみた結果、陥った罠です

❶LLMで解決が難しいものを作成してしまう

背景

社内では、誰でもDifyを使ってツールを開発できるぞ！という革命が起こったため、初めてツール開発をする（＝他ツールで開発したことがない）非エンジニアがLLMで解決が難しいものに何度かチャレンジしてしまいました。

失敗例

• ⑴「数値を正確に読み取って文章を作成することが求められるもの」を作成する
• ⑵ 回答を生成する際に、「分岐ごとにほぼテンプレ文章を作成した方が良いもの」を作成する

  • 例

    • アンケート内容を読みこませ、数値をテキスト抽出し、その上で数値の大小を比較した上で回答を生成するもの
      • 
    • ※分岐が多すぎて途中で断念しました
      • 入力：PDFやExcel
      • 出力：テキストに記載してある数値がXの時は「〜〜は前回比Xptの上昇、で⚪︎⚪︎⚪︎⚪︎⚪︎ということが言える」という固定の文章を数種類作成する
    • 課題
      • そもそもテキスト抽出の際に、数値を100%は正確に読み取れない
      • LLMで数値の大小を正確に判定するのが難しい
      • どのようなロジックで出力されたかワークフローの途中経過がわからないため、それっぽい文章は出せるがユーザーが信頼しづらい

  • 解決策

    • スプシの関数のみで対応
      • GPTでパターン別の関数（textjoinなど）を大量に作成し、スプシの関数で結合する方が早かった
      • ユーザーにもロジックがわかりやすく、納得感のない回答が出た際に修正しやすい

学び：スループットで外してはいけない観点を明らかにしてから実装する

ユーザーからヒアリングした、インプット情報と作りたいアウトプットを元に実装すると、
「それっぽい文章」は作れるのですが、ユーザーが重要にしたい観点とズレることがありました。

これらの失敗を防ぐためには以下が重要でした。

• 回答生成の過程で絶対に外してはいけない観点を整理する
  • ほぼ100%の精度での出力が必要な場合、LLMを使うのではなく完全ルールベースで作成した方が良いものもある
    • 例
      • 請求書の数字チェックなど、Excelで関数を組むorGASで実装する方が正確なもの
      • アンケート分析結果に、定量分析の観点（どのくらいの割合の人数が回答しているかを確実に表すなど）が重要になるもの
  • ワークフローでの回答生成ロジックも、ユーザー自身で詳細確認できるような工夫が必要
    • 例
      • 引用元URLを必ず載せる
      • どの情報からどのような思考で結論を出したのかを記載する

❷既存利用ツールで代替可能なものを作ってしまう

背景

社内では9割以上の社員が生成AI（主にChatGPTやPerplexity）を活用しており、多くの業務がこれらのツールだけで効率化されています。そのため、Difyで開発したツールが以下のような条件を満たさないと使われにくい状態です：

• ChatGPTやPerplexity単発での回答を超える情報を提供できる
  • プロンプトの工夫だけでは難しいものなど
• 少ない手間で想定するアウトプットを得られる
  • 1~3つの情報入力で、複数の処理が行われ、期待する出力が出るもの
• 頻繁に発生する業務
  • 1回の作業時間は短くても、頻繁に発生するもの

ツール展開に失敗した例

色々なサイトから顧客情報を収集するツールをDifyで開発しました↓

アウトプット情報
・企業の公式ページ
・企業の最新ニュース
・顧客のインタビュー記事など
・そこから読み取れる想いや価値観
など

ユーザーへのアンケート結果（ショーン・エリステスト）

プロトタイプが完成したのち、フィットジャーニーに従い、
PMFの達成指標である「ショーンエリステスト」をターゲット部署で小規模に実施したのですが

• 「とても残念」38%
• 「残念ではない」38%
  とぱっくり分かれる結果になり、ツールの全体展開には至りませんでした。

「とても残念」と答えたのは課題のヒアリング対象だった方とそのチームのメンバーで、

「残念ではない」と回答した方には
このツールで得られる情報がChatGPTやPerplexityで代替可能と捉えられてしまい、ツールを活用するメリットが伝わらなかったです。

問題点と学び

1. 自己満足の罠に陥ってしまった
   Difyで複雑なワークフローを作れたことに満足してしまっていた（自分のベイビーちゃんに恋をしていた）ところがありました。

2. ヒアリング対象の偏りがあった
   ヒアリング対象が特定の人に限られ、人によって収集する情報の観点や重要度が違う部分を十分に把握できていませんでした。

3. 必ず検索情報がヒットするものではなかった
   オープン情報が存在しない場合、このツールを使っても十分にヒットしない項目がありました。その場合、ユーザーの初期体験が悪く（1度試してみた際に自分の顧客に関する情報が出ない）、価値を感じてもらえないことがありました。

4. 小さい課題の解決になってしまい、ツール乗り換えコストを越えられなかった
   ChatGPTやPerplexityに慣れ親しんでいるユーザーは、同じような結果を得られる場合、少しの効率化ではDifyツールをわざわざ開いて使おうと思わないことがわかりました。このプロセスの前後に、効率化できるものと一緒にできないか、課題設定の際に立ち止まって検討することが大事でした。

Difyでの開発には限らないと思うのですが、
他の既存ツールと競合した時に、自分のツールに明確な価値があるか？
は、都度開発しながら問いかける必要があると感じました。

今後、改善を続けていく予定です。

まとめ：無邪気に開発したしくじりから学んだこと

Difyでサクサク楽しく実装する前に、
一度立ち止まって以下を確認することが大事でした。

1. ツールの目的や価値、既存ツールとの差別化ポイントをエレベーターピッチで整理する
2. ユーザーが重要にしたい観点を、Difyで実現できるのかを立ち止まって考える

最後に

Difyでは、誰もが思い描いたアイデアを素早く形にできる楽しさがあります。
しかし、その楽しさゆえに課題設定を丁寧に行わないと、
一見アウトプットはすごそうに見えても
実際には価値を届けられないツールになってしまうという学びを得ました。

また、個人的に
以前プログラミングで挫折した経験があるのですが
Difyのおかげでツール開発の難易度が下がり、
「ツールを作る楽しさ」を知ることができ、Difyにはとても感謝しております🥹

Difyで色々ツールを作ったのをきっかけに、
Dify単体では実装が難しい、他の技術も学んで活用の幅を広げたい気持ちになったので、
今後はn8n連携にもチャレンジしていきたいと思います！！