前回、私はHostingerでサーバーを契約し、そこにDifyを構築しました。
Difyの画面が表示された。
ログインできる。
AIアプリも作れる。
そして、Makeとも接続できるようになった。
ようやく、
LINE → Make → Airtable → Dify → AI → Make → LINE
という、自分が作りたかった自動化の仕組みが形になってきました。
でも、私がDifyを使いたかった理由は、単純にAIを自動化に組み込みたかったからではありません。
すでにGeminiをMakeにつないで、AIに自動回答させること自体はできていました。
問題は、
「回答が思っていたものと違う。」
ということでした。
AIは答えてくれる。
でも、私が求めている答えではない。
そこでDifyを使い、
AIに役割を与える。
回答のルールを決める。
必要な情報を持たせる。
そして、
自分が求める形で回答するAIを作る。
これに挑戦しました。
普通のAIは、基本的に一般的な回答をする
例えば、架空の旅館があるとします。
その旅館についてAIに、
「チェックインは何時ですか？」
と質問します。
すると、普通のAIなら、
一般的な旅館のチェックイン時間は、15時から18時頃です。施設によって異なるため、公式サイトをご確認ください。
といった回答をするかもしれません。
間違ってはいません。
でも、私が知りたいのは、
「一般的な旅館のチェックイン時間」
ではありません。
その旅館のチェックイン時間です。
当然、普通のAIは、その旅館独自の情報を知らなければ正確には答えられません。
そこで、Difyを使います。
例えば、
チェックインは15時から20時まで。
夕食付きプランの場合は18時までに到着。
20時を過ぎる場合は事前連絡が必要。
こうした独自の情報を、AIが参考にできるように設定します。
すると、回答は変わります。
チェックインは15時から20時までです。ただし、夕食付きプランをご利用の場合は18時までにお越しください。20時を過ぎる場合は、事前にご連絡をお願いします。
私が欲しかったのは、これです。
一般論を答えるAIではなく、自分が用意した情報をもとに答えるAI。
Difyを使うことで、ようやく私が作りたかったものが見えてきました。
同じ質問でも、誰に答えるかで回答は変わる
Difyで変えられるのは、AIが参考にする情報だけではありません。
どんな相手に、どんな言葉で回答するのか。
これも設定できます。
例えば、
「どうして空は青いの？」
とAIに質問します。
普通のAIなら、
太陽光が地球の大気中を通過するとき、波長の短い青色の光が空気中の分子によって強く散乱されるため、空は青く見えます。この現象をレイリー散乱と呼びます。
と答えるかもしれません。
正しいです。
でも、小学校低学年の子どもに説明するなら、少し難しい。
そこでDifyに、
小学1年生でも分かる言葉を使う。
難しい専門用語を避ける。
短く説明する。
最後に興味を持てる一言を加える。
というルールを設定します。
すると、
太陽の光には、いろいろな色がまざっています。その中でも青い光は、空気の中でいろいろな方向に広がりやすいので、私たちの目には空が青く見えるんだよ。実は、夕焼けが赤く見えるのにも理由があるんだ！
このような回答に変えることができます。
同じAIモデル。
同じ質問。
でも、設定する役割やルールによって回答が変わる。
私はこの仕組みを知って、
「これなら、自分が作りたかったAIに近づけるかもしれない。」
と思いました。
答えていいことと、勝手に答えてほしくないこともある
さらに、AIを実際のサービスで使うなら、
「何を答えるか」
だけではなく、
「何を勝手に答えないか」
も重要になります。
例えば、架空のネットショップに、
「昨日買った商品を返品したいです。返金してもらえますか？」
という問い合わせが届いたとします。
普通のAIなら、
多くのオンラインショップでは、一定期間内であれば返品や返金が可能です。購入したショップの返品ポリシーをご確認ください。
と答えるかもしれません。
これも一般論としてはおかしくありません。
でも、そのショップには独自のルールがあります。
例えば、
未開封の商品は、到着から7日以内なら返品可能。
開封済みの商品は原則返品不可。
初期不良の場合は開封済みでも対応する。
AIは返金を確約してはいけない。
判断できない場合は担当者への問い合わせを案内する。
こうしたルールを設定します。
すると、
未開封の商品で、到着から7日以内であれば返品を受け付けています。開封済みの場合は原則として返品できませんが、初期不良の場合は対応可能です。実際の返品・返金可否は商品の状態によって異なるため、注文番号を添えてお問い合わせください。
というように、自分が決めたルールに沿った回答に近づけることができます。
私はここで、Difyを使う意味がようやく分かってきました。
ただAIに質問して、答えてもらうだけではない。
どんな役割で答えるのか。
何を参考にするのか。
どんな言葉を使うのか。
何を答えてはいけないのか。
それを自分で決めていく。
私が欲しかったのは、まさにこれでした。
Geminiをつないだだけでは、求めていた回答にならなかった
私はすでに、MakeにGeminiを接続していました。
LINEから質問する。
Makeが受け取る。
Geminiへ送る。
Geminiが回答を作る。
その回答をLINEへ返す。
仕組みとしては動きます。
初めてAIから自動で回答が返ってきたときは、
「おお、できた。」
と思いました。
でも、実際に何度か質問してみると、少し違和感がありました。
回答は返ってくる。
でも、一般的すぎる。
説明が長い。
難しい言葉を使う。
こちらが想定していない方向へ話が進む。
同じような質問でも、回答の形が変わる。
私が欲しかったのは、
「AIなら何でも自由に答えていい仕組み」
ではありませんでした。
自分が決めた目的がある。
回答してほしい範囲がある。
使ってほしい情報がある。
守ってほしいルールがある。
その中で回答してほしい。
そこで登場したのが、Difyでした。
Difyに、自分が求めるAIの仕様を設定した
Dify側で、AIの役割を設定しました。
どんな相手に回答するのか。
どんな口調で話すのか。
難しい言葉を使うのか、使わないのか。
回答は短くするのか、詳しく説明するのか。
どの情報を参考にするのか。
分からないことを推測で答えていいのか。
答えられない質問が来たらどうするのか。
一つずつ、自分が求める回答に近づくように設定していきます。
そして、もう一度質問しました。
LINEから質問を送る。
Makeが受け取る。
必要な情報を確認する。
Difyへ送る。
Difyに設定した役割やルールをもとに、AIが回答を作る。
Makeがその回答を受け取る。
そしてLINEへ返す。
しばらくして、LINEに回答が表示されました。
私は、その文章を読みました。
「これだ。」
ようやく、求めていた回答が返ってきました。
Difyを連携させることで、求めていた回答を出すことに成功した
ここまで、本当に長かったです。
最初に私がやりたかったことは、とても単純でした。
LINEで質問したら、AIが自動で回答する。
ただ、それだけです。
でも実際には、
LINE公式アカウントを作る。
Makeを知る。
モジュールを設定する。
APIを知る。
アクセストークンを取得する。
Webhookを設定する。
Airtableをつなぐ。
Geminiをつなぐ。
AIのAPI料金を知る。
でも、回答が思っていたものと違う。
Difyを知る。
Hostingerでサーバーを契約する。
ドメインを取得する。
Difyを構築する。
HTTPで公開する。
Makeとつながらない。
HTTPSにする。
そして、ようやくDifyとMakeがつながる。
その先で初めて、
自分が求めていた回答が、LINEに返ってきました。
最終的な仕組みは、
LINE → Make → Airtable → Dify → AI → Make → LINE
です。
最初は、Makeの丸いアイコン一つを見ても何をすればいいのか分かりませんでした。
トリガーも知らない。
モジュールも知らない。
APIも知らない。
Webhookも知らない。
サーバーも分からない。
HTTPとHTTPSの違いも分からない。
それでも、AIに聞きながら一つずつ進めていったら、本当にここまで来ました。
もちろん、すべてを理解したわけではありません。
今でも分からないことはたくさんあります。
でも、
「自分にはできないと思っていた仕組みが、本当に動いた。」
この瞬間は、かなり感動しました。
ただ、このときの私は、まだ知りませんでした。
仕組みを作ることと、それを24時間安定して動かし続けることは、まったく別の話だということを。
そして次は、
「これを本当に自動化して、24時間動かせるのか？」
という、新しい問題に向き合うことになります。
