前回、Difyには大きく分けて2つの使い方があると紹介しました。
一つは、Difyのクラウド版をそのまま使う方法。
もう一つは、自分でサーバーを契約して、そこにDifyを構築する方法です。
私は後者を選びました。
理由は単純です。
「自分でサーバーを用意すれば、Dify自体は無料で使える。」
そして何より、
AIに聞けば、私でもできるんじゃないか。
そう思ったからです。
このときの私は、サーバーの知識なんてほとんどありませんでした。
ドメイン。
VPS。
Docker。
SSL。
HTTPS。
知っているようで、ほとんど分かっていません。
それでも私は、Hostingerのサーバーを契約しました。
そして、ここからまたAIとの二人三脚が始まります。
Hostingerでサーバーを契約したときは、少し感動した
私はHostingerでサーバーを契約し、ドメインも取得しました。
正直、このときは少し感動しました。
自分のサーバーがある。
自分のドメインがある。
そこに、自分専用のDifyを入れる。
少し前までMakeのモジュールすら分からなかった私が、今度は自分でサーバーを契約してAI環境を作ろうとしている。
「なんか、本格的になってきたな。」
そんな気分でした。
もちろん、契約しただけでは何もできません。
サーバーはある。
ドメインもある。
でも、
「で、ここから何をすればいいの？」
当然、分かりません。
そこで、またGeminiに聞きながら作業を始めました。
またAIとの二人三脚が始まった
やりたいことは明確です。
HostingerのサーバーにDifyを構築して、自分のドメインで使えるようにしたい。
私はGeminiに質問しました。
何を設定すればいい？
どこを開けばいい？
この画面で合ってる？
次は何をすればいい？
分からないことが出るたびにAIへ聞きます。
AIが説明する。
私が設定する。
エラーが出る。
スクリーンショットを見せる。
またAIが説明する。
これまでと同じです。
ただ、今回はサーバーです。
MakeやAirtableの設定とは違い、見たことのない画面や専門用語が次々に出てきます。
そして、肝心なところになると、なかなかAIとの会話が噛み合わない。
AIが説明している画面と、私が実際に見ている画面が違う。
言われた場所に設定項目がない。
同じ質問をすると、さっきとは違う方法を案内される。
「また始まったな。」
もう、この頃には少し慣れていました。
そこで登場したのが、Hostinger内のAIだった
今回、私にとって大きかったのが、Hostinger側に用意されていたAIです。
私はこのAIに、自分がやりたいことを伝えました。
ドメインを使いたい。
サーバーを設定したい。
Difyを構築したい。
すると、作業が進んでいきます。
ドメイン。
サーバー。
Dify。
私が一つひとつコマンドを理解して操作するというより、AIにやりたいことを伝えながら環境を作っていく。
これは、かなり感動しました。
少し前まで、
「トリガーって何？」
「Webhookって何？」
と言っていた私が、AIと一緒に自分のサーバーへDifyを構築している。
もちろん、私はサーバーエンジニアになったわけではありません。
何が裏側で起きているのか、完全に理解していたわけでもありません。
それでも、
自分のドメインで、自分のサーバー上にDifyが動いている。
実際に画面が表示されたときは、
「本当にできた。」
と思いました。
これは、かなり嬉しかったです。
ついに、自分のDifyが動いた
Difyの画面が表示されました。
ログインできる。
設定もできる。
AIアプリも作れる。
私はようやく、
「これでDifyを使い始められる。」
と思いました。
そして当然、次にやることは決まっています。
これまで作ってきたMakeのシナリオと接続することです。
私が作ろうとしていた仕組みは、
LINE → Make → Airtable → Dify → AI → Make → LINE
という流れです。
Dify単体で動いても、私が作りたい自動化は完成しません。
MakeからDifyへ質問を送る。
Difyが設定したルールや知識を使って回答する。
その回答をMakeが受け取る。
そしてLINEへ返す。
いよいよ、これまで作ってきたものが全部つながる。
そう思っていました。
ただ、一つ問題がありました。
私はDifyを、
HTTPで公開していました。
当時の私には、HTTPとHTTPSの違いなんて、ほとんど分かっていません。
とりあえずDifyの画面は開く。
ログインもできる。
動いている。
だったら問題ない。
そう思っていました。
MakeとDifyをつないだら、エラーが連発した
Difyの設定が完了。
次はMakeとの連携です。
Make側に必要な情報を入れる。
テストする。
エラー。
設定を確認する。
もう一度テスト。
またエラー。
AIに聞く。
設定を変える。
もう一度試す。
やっぱりエラー。
理由が分かりません。
Difyは動いている。
ブラウザからも開ける。
サーバーも動いている。
ドメインもある。
Make側の設定も、AIに確認しながら進めている。
それなのに、つながらない。
この頃には、Makeのエラーにも少し慣れていました。
でも、慣れたからといって原因が分かるわけではありません。
エラーが出る。
AIに聞く。
設定を変える。
またエラー。
別の方法を試す。
さらに別のエラー。
そして、ようやく原因が分かりました。
原因は、HTTPだった
私が公開していたDifyは、
HTTP。
でも、Makeなどの外部サービスと安全に連携するためには、
HTTPSでアクセスできる状態にする必要がありました。
私は思いました。
「最初に言ってよ。」
Difyは動いていました。
画面も開けました。
だから、完成したと思っていました。
でも、
「Difyがブラウザで開く」
ことと、
「外部サービスと正常に連携できる」
ことは別でした。
今なら分かります。
でも当時の私は、
HTTP。
HTTPS。
SSL証明書。
リバースプロキシ。
ポート。
DNS。
そんなものは、ほとんど分かりません。
私はただ、
自分のサーバーにDifyを入れて、Makeとつなぎたかっただけです。
そして、ここから新しい地獄が始まりました。
HTTPS設定の地獄が始まる
原因は分かった。
だったらHTTPSにすればいい。
そう思いますよね。
私も思いました。
「じゃあ、HTTPSに変更すれば終わりじゃん。」
終わりませんでした。
むしろ、ここからが本番でした。
SSL証明書。
DNS設定。
ドメイン。
サブドメイン。
ポート。
Nginx。
リバースプロキシ。
設定ファイル。
コマンド。
また知らない言葉が次々に出てきます。
一つ設定する。
エラーが出る。
AIに聞く。
コマンドを実行する。
別のエラーが出る。
設定を書き換える。
今度はDifyが開かなくなる。
元に戻そうとする。
でも、どこを変更したのか分からなくなる。
Difyを使いたかっただけなのに。
私はいつの間にか、HTTPSと戦っていました。
そして、このHTTPS設定については、あまりにも長くなったので別の記事にしています。
Difyを使うためにサーバーを契約した。
AIの力を借りて、実際にDifyを構築できた。
そこまでは、本当に感動しました。
でも、Difyが動いたからといって、それで終わりではありませんでした。
動くことと、外部サービスとつながることは違う。
私はまた一つ、新しいことを知りました。
そして次は、
「HTTPで動いているDifyを、どうやってHTTPSにするのか？」
という、初心者にはあまりにも長い戦いが始まります。
