本日はアドベントカレンダー２５日目の投稿となります🎄
皆さんプレゼントは届きましたでしょうか・・・（大人になってからサンタさん見てない・・・🎅）
◎はじめに◎
こんにちは！NTTドコモの河内です。
普段の業務では、道路や橋などの社会インフラにおけるDX*1に係る技術開発をしています。
本日は簡単に生成AIアプリを作れる！（少し遅いかもですが・・・）と話題のDifyの勉強がてら、 簡単な市民通報システムを作ってみました。
その様子を皆様にお届けします！
ご興味ある方はぜひご覧ください◎
◎市民通報システムってなに？◎
市民通報システムとは、 街で見つけた「困ったこと」をスマホやパソコンから市役所に知らせることができるシステムです。
例えば…
- 道路に穴が開いてる！
- 公園の遊具が壊れてる！
- ゴミが不法投棄されてる！
- 街灯が消えてて危ない！
なんて時に、市民通報システムを使えば、写真や位置情報と一緒に簡単に報告できます。
わざわざ市役所に電話したり、来訪する必要がないので、とっても便利！
一方で、現行の市民通報システムは簡易なアルゴリズムで機械的にフローチャートで処理しているものがほとんどです。
通報内容をその場で理解してユーザーと対話したり、ユーザーに寄り添った対応は難しく、一方通行のコミュニケーションになっています。
◎そもそもなんで市民通報システム？◎
たまたまとある市の市民通報システムを触ってみた際に「もっと使いやすくできないかな？」と考えたのがきっかけです。
現行の市民通報システムはLINEなどの活用によって24時間対応を実現しているところはありますが、途中で回答を間違えるとやり直しになったり、意図しない回答をするとエラーになったり、返信が機械的で内容を理解して返答してくれるわけではなく、少し使いづらさを感じていました。
そこで、理想って何だろうと考えながら、市民も便利に、市役所職員の方の稼働も低減することを目的に、生成AIを用いた市民通報システムを考えてみました！
※実際に全ての通報対応業務を生成AIで代替するのは様々な事情から不可能かと思いますが、一種のエンタメとしてご覧ください。
◎システムの概要◎
今回作りたいシステムを頭に思い描きながら、簡単に図面に落とし込んだものがこちらです。
左側にUIイメージと処理、右側に通報対応のカテゴリリストを記載してます。
処理のイメージですが、まずは通報内容や画像からキーワードを抽出します。
その後、通報に不足の情報は自律的に生成AIがユーザーへ質問し、情報がそろったらDBに登録・更新します。
登録後は、対応可否や修繕日等も生成AIからユーザに通知する想定です。
通報対応のカテゴリリストおよび通報対応のカテゴリ分けについては、市民通報データを体系的に分析した研究論文の内容・考え方を引用しました。*2
ちなみに、これまでの市民通報システムと今回の生成AIを用いた市民通報システムの違いは下記のようになっており、生成AIによって市民参加型の幅を広げ、より便利な市民通報システムをめざしました。
◎Difyについて◎
DifyはオープンソースのLLMアプリ開発プラットフォームです。
簡単に生成AIを用いたアプリを作ることができるそうです。
公式リファレンスを主としつつ、適宜インターネットで調べながら触っていきました。
早速試してみましょう！
◎いざ！◎
環境構築
Webアプリ版とローカル版の両方が利用可能ですが、今回はローカル環境（Ubuntu 24.04.1 LTS）でDifyを利用しました。
Docker*3で利用可能で、下記の公式ドキュメント通りに進めることで簡単に環境構築ができます。
ブラウザから操作画面を開き、アカウント作成後にログインすることで使えるようになります。
モデルのセットアップ
DifyはOpenAIのAPIからOllamaのローカルLLMまで、数百種類のLLMと簡単に連携することができます。
今回はOpenAIのGPT-4oを選択します。
テンプレートの参照
Difyでは作成するアプリのタイプをはじめに選択することができます。
- チャットボット：RAG*4対応のチャットボット
- テキストジェネレーター：入力を元に所定の出力を吐き出すAIツール
- エージェント：外部ツールと連携しながら処理を行うAIエージェント
- ワークフロー：フローチャートで自由に組めるAIツール
また、沢山のテンプレートがあるので、そこから作りたいアプリに近いタイプのものを選択し、それを加工しながら作ることができます。
今回は、Patient Intake Chatbotという、患者さんの病状から受診先の科へ誘導するアプリを参照しました。
おもいのままに・・・
Difyはプログラミングスキルがなくても簡単に使えますが、if文やforループの概念を理解していると、フローチャートを作成するイメージでより細かい処理を構築できます。
LLMとの応答回数によって対話内容を変えたり、要所で呼び出すLLMのモデルや、temperature*5などのパラメータも変えることも可能ですし、今回は通報のカテゴリーやその内容、通報場所の住所を記憶しておくことで、カテゴリーによってその後の対話のストーリーを分岐させていく、ということも実現しています。
また、RAGの構築もシンプルで、必要な箇所だけベクトルストアを参照することも簡単にできます。
一般的な市民通報では市民が現地確認することはありませんが、見た人がそのまま現地確認すれば自治体職員の方も楽かも！と思い、市民自身が現地確認するか否か選べるようLLMに提案してもらうよう構築しました。
完成！
◎こんな感じ◎
実際に曖昧な問いかけでも、内容を理解しながら情報を集め、現地確認をするか否かも聞いてくれています。
◎今後の展望◎
より通報位置を選択しやすいように地図から選択できる機能の実装（現状、Dify上では地図の埋め込み対応してないため、別途開発必要）や、対話機能の強化、より多くの通報への対応などが必要になってきそうです。
また、通報対応業務自体のフローが変わるため、現場で使えるかなどの検証も含めるとアクションアイテムは山盛りですね・・・（汗）
私の担当では道路運営のDXを加速する”Digital Twin Road Management構想”を掲げており、本構想につながる技術検証・開発をこれからも進めてまいります。
◎まとめ◎
気になっていた「Dify」を実際に使った感想は、 非常に使いやすい＆頭の中で考えていることをすぐに表現できるすごいツールだと思いました！
プログラミングが苦手でもできるし、思いついたらまず作ってみるを こんなにも簡単に実現できちゃうのは素晴らしすぎる・・・
皆様もぜひ触ってみて、理想のアプリを作ってみてはいかがでしょうか！
それでは、良いクリスマスをお過ごしください🎄
*1:digital transformationの略。情報技術の浸透が、人々の生活をあらゆる面でより良い方向に変化させること
*2:狩野英司, ”市民通報データを用いた地域課題の分析手法に関する研究”, 筑波大学審査学位論文（博士）, 2020.
*3:Docker：アプリケーションとその動作に必要な環境をまとめて「コンテナ」という単位で管理・実行できるプラットフォーム
*4:RAG：Retrieval-Augmented Generation、生成AIに情報検索機能を組み合わせた手法
*5:temperature：生成される文章や回答の創造性や多様性をコントロールするためのパラメータで、低い値だとより決定的であり、高いと創造性や多様性が高まる
