Dify×AIで「企業のネガティブニュース」をチェックするアプリを作ってみた

はじめに

お疲れさまです。CXマーケ・コンテンツプランニング2部、コンテンツ推進1課のM.Nです。

業務の中で、転職サイトに掲載する新着求人の社名を選定することがあります。
その際に気にしておきたいのが、掲載対象となる企業に、直近で大きなネガティブニュースや話題が発生していないかどうかです。

もちろん、1社ずつ検索してニュースを確認していけば調べることはできます。
ただ、対象企業が複数あると、記事を探して、内容を読んで、注意が必要かどうかを判断するまでにそれなりに時間がかかります。

しかも、確認する人によって見るポイントがぶれやすい、という難しさもあります。

そこで今回、選定した企業ごとの直近ニュースを確認し、ネガティブな話題の有無を整理して返してくれるアプリを作れないかと思い、Difyで試してみることにしました。

私はDify未経験で、最初は初期設定の段階から手探りでした。Dify利用ガイドライン（e-learning）で概要は確認したものの、いざ「ワークフローを設定してください」と言われても、「そもそもワークフローって何だろう？」というところからのスタートでした。

そのため、行き詰まったときにはUdemyのDify関連講座から、今回作りたいアプリに近そうな内容の章を、その都度参考にしながら進めていきました。

ここでは、Difyを使用するうえでの最適解をご紹介するというよりも、正解が分からないままAIを頼りに進めたワークフロー設計の試行錯誤をまとめています。

同じように、業務課題をきっかけにDifyを使ってみたいと考えている方や、AIに相談しながら手探りでワークフローを組んでいる方の参考になればうれしいです。

当初イメージしていたフロー

今回作りたかったのは、複数企業の直近ニュースをまとめて確認し、リスクとなり得るネガティブな話題がないかを整理して返すアプリです。

まず企業名をリスト化し、企業ごとにニュースを検索する。次に、見つかった記事を1件ずつ確認しながら、本文の取得、要約、ネガティブ判定を進めていく。最後に、その結果を企業ごとにまとめて一覧にする――そんな流れを想定していました。

最初に行ったのは、やりたいことをAIに伝え、Difyで実現するにはどのようにノードを構成すればよいかを聞いてみることでした。

AIから返ってきた要件を見ると流れはとても自然で、「このままDifyのワークフローにすれば作れそうだ」と考えていました。

ただ、実際に組んでみると、頭の中では自然に見えていた流れと、ツール上で無理なく実装できる形には少しズレがありました。ここから試行錯誤が始まります…

当初は、企業ごとの処理の中で記事ごとの処理を回す二重構造をイメージしていました。 整理すると、次のような構成です。

• 外側の反復：企業ごとの処理
• 内側の反復：記事ごとの処理

ただ、この時点ではまだ「やりたいこと」と「Dify上で扱いやすい構造」の違いをあまり意識できていませんでした。

最初の壁は、「自然な設計」がそのまま実装できるとは限らない

実際に組み始めてみると、最初に大きくつまずいたのは、企業ごとの処理に加えて、その中でさらに記事ごとの処理も回さなければならない部分でした。

要件としてはそれほど不自然ではないのですが、実際にワークフローに落とし込もうとすると、思ったようにデータが流れなかったり、構成に無理が出たりして、全体がどんどん複雑になっていきました。その結果、うまく動かない場面も多く、エラーも頻繁に発生しました。

さらに難しかったのは、単純に実装が詰まったという点だけではありませんでした。ある程度インプットをしてから着手したつもりでも、実際に自分で組んでみると、まだ理解しきれていない部分が多く、何が原因なのかを整理するのも簡単ではありませんでした。

たとえば、こんなことをずっと考えていました。

• これはDifyの制約なのか
• 自分の理解不足なのか
• そもそも処理の分け方・設計の考え方が違うのか
• AIが提案した案をどこまで信じてよいのか…

振り返ると、詰まっていたのは単なる実装ではなく、「どこを見直せば前に進めるのか分からない」状態そのものだった気がします。

AIに相談すると、それらしい設計案や代替案はちゃんと返ってきます。それ自体はとても助かりました。ただ一方で、その提案がDifyの実際の挙動や運用感にどこまで合っているのかは、未経験の私では判断しづらい、という難しさもありました。

AIを使えば前には進めます。でも、提案の妥当性を見極める力まで自動で手に入るわけではない。この点は、今回かなり強く感じたところでした。

「構造を守る」より、目的に届く形へ組み替える

二重ループ前提の構成に無理を感じた段階で、いったん発想を切り替える必要がありました。

ここで大事だったのは、最初に思い描いた構造を守ることではなく、目的を満たせる範囲で、Difyで扱いやすいやり方に組み直すことでした。

それまでは、「企業ごとに回して、その中で記事ごとに回す」という構造ありきで考えていました。でも途中からは、もう少し別の観点で整理するようになりました。

• どの単位で処理を持つと無理が少ないか
• どこで中間結果を保持するか
• どこで判定し、どこで集約するか
• どの時点で不要な情報を落とすか

これは後から振り返ると、かなり大きな転換でした。
ノーコードのツールは、画面上でノードをつなげられるぶん、「流れがつながっているか」に意識が向きやすい印象があります。でも実際には、どこで何を確定させるのか、どこで分岐させるのか、どこで集約するのかを明確にするほうが重要なのだと感じました。

企業ごとの処理の中で記事ごとの確認を回す、当初想定していたループの中にさらにループを入れる構造は、実装や制御が一気に複雑になります。意図した形で安定して処理を進めるのが難しく、組んでいても「これは無理なく回せる形なのか？」という迷いが残りました。

そこで、入れ子構造でまとめて処理するのではなく、配列の要素を1つずつ順番に見ていくフロー（イテレーション型）に変更しました。

ループの中にさらにループを持つ構造ではなく、各回の確認結果を踏まえて条件を調整しながら進める流れに組み替えたことで、当初の構想からは少し離れました。それでも、構造としてはむしろ整理しやすくなった感覚がありました。

検索期間も、柔軟さより先に「まず成立すること」を優先した

もう一つ、途中で大きく見直したのがニュース確認の対象期間です。

当初は、以下のように期間を選べるようにしたいと考えていました。

• 過去30日
• 過去90日
• 過去180日

用途によって必要な期間は違いますし、選択肢があるほうが便利です。
仕様としても、こちらのほうが高機能に見えます。

ただ、ワークフローとして考えると、期間が長くなるほど検索対象の記事数が増え、後続処理の負荷も大きくなります。

• 検索件数が増える
• 取得する記事URLが増える
• 本文の取得回数が増える
• 要約・判定の回数も増える
• 最後の集約も重くなる

しかも今回は、私自身まだDifyの運用感覚を十分につかめていませんでした。90日や180日まで対象期間を広げたときに、どこでボトルネックが出るのかも、正直まだ見えていない状態でした。

複数の期間を指定できたほうが機能としては魅力的です。とはいえ今回は、まずは破綻しにくく、安定して運用できる形を優先したかったため、対象期間は過去30日に絞ることにしました。

一見すると仕様を絞ったようにも見えるのですが、実際はそこまで後ろ向きな判断ではありませんでした。今回やりたかったのは、長期的な傾向を分析することではなく、直近で注意が必要なニュースが出ていないかを効率よく確認することです。そう考えると、30日という範囲でも実務上は十分そうだと感じました。

むしろ、まだツールの癖をつかみきれていない段階では、最初から広く作ろうとするより、まずは範囲を絞って確実に動くものを作るほうが進めやすかったため、結果的に、この判断はよかったと思っています。

DSLファイルのセルフチェックは、“間違い探し”以上の意味があった

構造を見直していく中で助けられたのが、社内環境で利用しているセルフチェック用のアプリでした。

このアプリは、Difyで作成したアプリの定義ファイル（DSL）をもとに、設定の不備や改善ポイントを洗い出すために使用しています。

ワークフローを作っていると、どうしても処理の流れやノード構成に意識が向きがちです。私自身も最初は、「まずは動くかどうか」を優先して見ていました。

でも、実際に気づかされたのは、もう少し手前にある入力設計の部分でした。

作業を進める中で、企業ごとの処理を回すイテレーションには実質30回ほどの上限がありそうだとわかり、入力欄に「※最大30社まで」という注意書きを入れました。

ただ、実際にはその上限をシステム側で制御していたわけではありません。設定していたのは「文字数300まで」だけで、社数そのものに制限はかけていませんでした。

そのため、「最大30社まで」と案内はしているものの、実際にはそれ以上も入力できてしまう状態でした。これは単なる設定漏れというより、使う人にとってわかりやすく、迷いにくい形にするところまで考えきれていなかったのだと思います。

そこで最終的には、入力内容を判定する分岐を見直し、31社以上が入力された場合は後続の処理に進まず、エラーを返す形に修正しました。注意書きを添えるだけでなく、入力条件を満たさない場合はその場で止まるようにしたことで、案内と実際の挙動をそろえることができました。

作る側としては「注意書きを入れているから問題ない」と考えがちですが、実際に使う人は「入力できるなら使えるはず」と判断し、条件を満たさない内容でも入力してしまうことがあります。

その結果、エラーになってしまえば相手の時間を無駄にしてしまいます。だからこそ、単に注意書きを用意するだけでなく、実際の使い勝手まで含めて設計することの重要性をあらためて実感しました。

セルフチェックアプリを活用することは、単なるエラー探しではなく、仕様と実装のズレを見直すための視点として、とても大きかったです。

＜Dify上の実際のシステム構成＞

難しかったのは、「作ること」より「これで合っているのか分からないまま進めること」だった

今回の作業で、個人的にいちばん印象に残っているのはこの点かもしれません。

Difyに詳しい方なら、「この場合はこう組む」「この構成は避けたほうがいい」といった判断も、もっと早くできたのかもしれません。でも今回は、そういう勘どころがまったくない状態からのスタートでした。

そのため、何かを修正するたびに、「これで本当にいいのかな」と毎回少しずつ迷っていました。

• この修正はちゃんと前進になっているのか
• その場しのぎでつないでいるだけではないか
• Difyのセオリーから外れていないか
• 後から見たときに、壊れやすい作りになっていないか

しかも今回は、AIに相談しながら進めていたので、その難しさもありました。

AIは、考えを整理したり、代替案を出したりするのが本当に得意です。
ただ、そのぶん一見もっともらしい答えが返ってくるので、それが本当に今の状況に合っているかどうかは、また別の話でした。

実際にやってみて感じたのは、「AIがあるから簡単に作れる」というよりも、AIに相談しながら進めることで、自分がまだ理解しきれていない部分や、判断に迷っているポイントが見えやすくなる、ということです。

そういう意味では、AIは答えを出してくれる存在というより、考えを整理し直すための相手として使うことが大切なのだと思いました。これは個人的にもかなり大きな学びでした。

生成AIを使うと、前に進むスピードはたしかに上がります。でも、設計の妥当性を見極める責任までなくなるわけではありません。むしろ、自分がまだ十分に理解できていない領域ほど、「何が分かっていて、何が分かっていないのか」を意識しながら進める必要があると感じました。

それでも、手探りのまま形にできたことには意味があった

ここまで書くと、ずっと不安だったようにも見えるかもしれません。
実際、不安はありました…。

ただ一方で、知識ゼロの状態からでも、AIを補助線にして一定の形までは持っていけた、という手応えもありました。

もちろん、現時点の構成が最適解だとは思っていません。もっとシンプルな設計があるかもしれませんし、もっと負荷の少ない組み方や、判定精度を上げる工夫、ノイズを減らす方法もあるはずです。

それでも今回の経験で得られたのは、最初から正しい設計が描けなくても、課題をひとつずつ整理し、Difyの制約を受け止め、少しずつ組み替えていけば、実務で使えるところまでは進める、という感覚でした。

ノーコードのツールは、思い描いたものを何でも簡単に形にできるわけではありません。でも、正解が見えない状態でも、仮説を試しながら前に進める環境ではあると感じました。 今回のDify体験は、まさにそれを実感する機会になりました。

今回の試行錯誤から学んだこと

今回の経験は、Difyの使い方そのもの以上に、AI時代にどう設計を進めるかを考える機会になりました。

1. 人が話す言葉で書かれた要件は、そのままワークフローにはならない

「こうしたい」という要件は出発点として大事です。ただ、実装に落とすには、反復・分岐・集約の単位に分解し直す必要がありました。

2. “自然だと思える構造”が、ツール上でも自然とは限らない

分かりやすい構成が、そのままDifyで扱いやすい構成とは限りません。最初の構造を守ることより、目的に届く形へ組み替えることのほうが大事でした。

3. 未経験のツールでは、まず成立範囲を狭く取るのが有効

今回でいえば、対象期間を30日に絞った判断がこれにあたります。最初から柔軟性を持たせるより、まずは壊れにくい範囲で成立させるほうが前に進みやすいと感じました。

4. AIは強力な助けになるが、妥当性判断までは難しい

AIは整理や発想にとても役立ちます。ただし、その案が本当に今の制約の中で有効かどうかを判断するには、やはり人間側の視点が必要でした。

5. チェックツールは、仕様と実装のズレに気づく助けになる

今回、入力欄に「最大30社まで」と書いていたにもかかわらず、実際には文字数300の制限しか設定していなかったように、自分では整合しているつもりでも、仕様と実装の間にズレが残っていることがあります。

チェックツールは、そうした見落としを補い、設計の精度を上げる助けになると感じました。

おわりに

今回、Difyで企業のネガティブニュース確認アプリを作ってみて感じたのは、ツールを使うことと、正しい設計ができることは同じではないということでした。

特に今回は、Difyの知識がほとんどない状態から、AIを活用しながら手探りで進めたため、途中で何度も「これで本当に合っているのだろうか」と感じました。ループの考え方、処理単位の切り方、期間設定、条件分岐の置き方など、一つひとつの判断に最初から確信があったわけではありません。

それでも、

• 最初の構造にこだわりすぎないこと
• 対象範囲を狭めて成立性を優先すること
• チェックツールを設計見直しの材料として使うこと
• AIの提案をそのまま受け取らず、試しながら調整すること

を意識したことで、少なくとも実務で使える形に近いところまではたどり着けたと思っています。

ただ、この取り組みは完成報告というより、現時点での実践記録です。
もしDifyに詳しい方や、ワークフロー設計に知見のある方がご覧になっていたら、

• このケースなら、もっとこう設計したほうがよい
• その分岐は別の切り方がある
• 処理単位の持ち方を変えたほうがよい

といったご意見を、ぜひ伺えたらうれしいです。

今回の経験でいちばん大きかったのは、分からないことだらけの状態でもAIを使いながら試行錯誤を繰り返し、少しずつ形にしていけたことでした。

そして同時に、その先にはまだ改善余地が多く残っていることもよく分かりました。

だからこそ、この取り組みは単に「できた」で終わりではなく、今後さらに改善を重ねながら、ほかの業務にも活用できることはないか考えていきたいと思います。

この記事が少しでもみなさまのお役に立ちましたら幸いです。