Difyとは何か、社内のAIをどう組むか｜作れる範囲を見極める

「触ってみたら1日で問い合わせ用の窓口ができたので、社内の仕組みはこれで全部作れると思っていました」「逆に、結局は開発ですよねと言われて手が止まりました」——情報システムやAI推進の担当者から届く相談は、この両極に割れます。どちらも同じ誤解の裏表で、Difyは開発をなくす道具ではありません。本当は作る対象を、あらかじめ用意された部品の組み合わせに置き換える道具です。この記事では、Difyで組める4種類の仕組みと、それぞれどこまでが自分たちで作れてどこから先が作れないのかを、発注や内製を決める前に見極められる形で整理します。

「画面で組める」が指しているのは、部品を並べるところまで

Difyは、公開されている基盤の上でAIを使った仕組みを組み立てるための道具です。画面に部品を置き、線でつないで、対話や処理の流れを作ります。提供元の環境をそのまま使う形と、公開されている版を自社の環境で動かす形の両方があり、どちらでも同じ画面で組み立てます。ここまでは、多くの紹介記事に書かれている通りです。

実務で効くのは、その先です。Difyが肩代わりしているのは組み立ての部分だけで、材料ではありません。AIの本体は外部の事業者のものを呼びます。答えの元になる資料は自社が用意します。つなぐ先の社内システムは情報システム部門が用意します。つまり、Difyを入れても材料の準備は減りません。減るのは、材料をつなぐ配線を書く作業です。

逆に言えば、配線が仕事全体の何割を占めるかで、効き目が変わります。配線が9割の仕事、たとえば決まった聞かれ方に決まった形で返す、届いた文章を要約して分類する、といった仕事は、Difyを使うと大きく短くなります。一方で、散らばった手順書を統一する、基幹システムの項目名を揃えるといった材料の整備が9割の仕事は、Difyを入れてもほとんど変わりません。短くなるのは配線の時間であって、材料をそろえる時間ではありません。ここを取り違えると、導入したのに何も速くならない、という結果になります。

組めるのは大きく4種類。分けて見ないと工数が読めない

紹介記事では「なんでも作れる」と書かれがちですが、実際に社内で組まれるものは4種類に集約されます。会話の窓口、手元の資料を読ませて答えさせる仕組み、決まった手順を順に流す仕組み、外部の道具を呼ぶ仕組みの4つです。この4つは、立ち上げにかかる時間も、つまずく場所も、必要な技能も違います。

種類	できること	立ち上げの目安	つまずくところ
会話の窓口	指示文を与えて答えさせる	半日から1日	作れるが使われ続けない
資料を読ませて答えさせる	自社の文書を根拠に答えさせる	数日から2週間	資料の状態で精度が決まる
決まった手順を流す	入力から出力までを一方向に処理する	2週間から1か月	分岐と例外で膨らむ
外部の道具を呼ぶ	社内システムや外部のサービスを呼ぶ	1か月以上	権限と失敗したときの扱い

この表で見てほしいのは日数ではなく、右端の列です。上の2つは作れるが使われないという形で失敗し、下の2つはそもそも作りきれないという形で止まります。失敗の種類が違うので、防ぐ手立ても違います。上2つには運用の設計が要り、下2つには技術の裏付けが要ります。

相談を受けるときに最初にやるのは、相手がどの行の話をしているかを確かめることです。「Difyでできますか」という問いには答えようがありませんが、「この4行のどれですか」と聞き返すと、話が10分で先へ進みます。社内の稟議でも、この4行のどれを作るのかを1行目に書くだけで、審査する側が見るべき論点が変わります。

会話の窓口は半日で立つ。難しいのはそのあと

いちばん早いのが会話の窓口です。役割・答え方・断り方を書いた指示文を用意し、呼び出すAIを選び、公開します。公開の形は、専用の画面を配る、既存の社内の画面に埋め込む、外から呼べるようにする、の3通りが用意されています。慣れた担当者なら半日、初めてでも1日あれば動くところまで行きます。公開されている入門解説でも、社内の問い合わせ用の窓口が数十分から数時間で立つ例が紹介されています。

問題は、そのあとです。半日で立つということは、部門ごとに似た窓口が並ぶということでもあります。指示文がそれぞれ違うので答え方が揃わない。指示文を直しても、誰がいつ直したかが残らない。窓口の数が増えるほど、どれが正なのかが分からなくなります。作りやすさが、そのまま散らかりやすさになります。

対策は、作る前に決まります。窓口は部門ではなく答える範囲で1つにまとめること。そして、指示文に必ず「分からないときはこう答える」を書いておくことです。答えられない場合の振る舞いを先に書いておくと、後から出てくる不満の大半が消えます。答えを作り込むより、断り方を作り込むほうが、実際の運用は安定します。窓口に対する社内の不信は、間違った答えが返ったときよりも、分からないことをそれらしく答えたときに生まれるからです。

資料を読ませて答えさせる：作るのは数日、直すのは数か月

2つ目は、自社の資料を登録して、その中身から答えさせる仕組みです。資料を取り込み、検索できる形にしてから、会話の窓口に紐づけます。取り込める形式は広く、Difyの日本法人が公開している解説では、30種類を超えるファイル形式や外部のサービスに接続できるとされています。ここまでの手数だけを見れば、数日で形になります。

ところが、この仕組みの出来を決めるのは部品の並べ方ではなく、資料そのものの状態です。同じ内容の手順書が3世代あってどれが最新か分からない、表がPDFの中で画像になっていて文字として読めない、同じものを指す言葉が部署ごとに違う。この3つが揃っていると、どう組んでも答えは安定しません。実務で数か月かかるのは、組み立てではなくこの片づけです。

もう1つ、あとから変えにくい設定があります。資料をどの単位で切って覚えさせるか、という分割の方式です。章ごとに切るのか、見出しと本文を親子の関係で持つのか、質問と答えの組にするのか。同じ解説でも、この分割の構造は試作の段階で決めておく必要があり、あとから変えるのは難しいと明記されています。試作で確かめるのは答えの良し悪しではなく、資料の切り方が自社の文書に合っているかです。ここを確かめずに本番へ進むと、精度が出ないたびに指示文をいじる作業に入り込み、原因にたどり着けなくなります。

決まった手順を順に流す：分岐を増やした瞬間に止まる

3つ目は、入力から出力までを一方向に流す仕組みです。受け取った文章を分類し、条件で分け、AIに書かせ、決まった形に整えて返します。並べられる部品には、AIを呼ぶもの、条件で分けるもの、外部に問い合わせるもの、人の承認を待つものなどがあります。1本の流れとして図に描けるので、業務の担当者にも中身が見えるのが利点です。

ここで起きるのが、分岐の増殖です。最初は3つの分かれ道で始めたものが、例外を拾うたびに増えていきます。公開されている入門解説でも、最初から条件分岐を10個入れた流れを作ろうとすると挫折する、とはっきり書かれています。分岐が増えると、1か所直すたびに全部の経路を確かめ直す作業が発生し、直すこと自体が重くなります。

• 例外を全部拾おうとする：分岐が増えるほど、直すたびに全経路の確認が必要になる
• 1本の流れに5つの仕事を詰める：どこで失敗したのかを特定できなくなる
• 途中の出力を誰も見ない：ずれた結果が最後まで通り、外へ出てから発覚する
• 作る人と、その業務をしている人が別：現場にしかない例外の存在に気づけない

現実的な作り方は逆です。例外は流さず、はじきます。決まった形に当てはまるものだけを流し、当てはまらないものは人の手元に落とします。自動で流す割合を上げるより、はじいた件を人が確実に受け取れるようにするほうが定着します。7割を確実に流して3割を人が拾う形は、10割を狙って全体が止まる形より、はるかに長く使われます。

外部の道具を呼ぶ：ここから先は情報システム部門の領分

4つ目は、社内のシステムや外部のサービスを呼ぶ仕組みです。案件の情報を取ってくる、在庫を見に行く、承認の依頼を投げる。Difyには外部と通信する部品があり、AIと道具をつなぐための共通の決まりごとであるMCPにも対応が進んでいます。画面の上では、これも部品を1つ置くだけの作業に見えます。

しかし、ここから必要になるのは別の技能です。呼ぶ先の仕様を読むこと、認証のための鍵を安全に置くこと、呼んでよい回数の上限を守ること、失敗したときに再試行するのか止めるのかを決めること、呼んだ記録を残すこと。どれも画面の外にある話で、業務部門だけでは決められません。線をつなぐのは画面でできますが、つないでよいかの判断は画面の外にあります。

そのため、4つ目に手を出す時点で、作る主体は情報システム部門かその委託先になります。実務でいちばん詰まりにくいのは、外部を呼ぶ部分だけを部品として情報システム部門が用意し、業務部門はその部品を並べるだけにする形です。呼び先ごとに部品を1つ作っておけば、認証と記録の面倒が1か所に集まり、業務部門は仕様を読まずに済みます。この分担にしておくと、あとから呼び先の仕様が変わったときも、直す場所が1か所で済みます。

作れる範囲は、腕前より契約の枠が決めている

見落とされやすいのが、契約の枠です。提供元の環境をそのまま使う形には、はっきりした上限が置かれています。公式の料金表では、無料の枠は呼び出しに使える回数が200、作れるアプリが5つ、登録できる資料が50件、容量が50メガバイト、作業できる人が1人、記録の保存が30日です。年590ドルの枠では呼び出しが月5,000回、年1,590ドルの枠では月10,000回に増えます。

枠	無料	年590ドルの枠	年1,590ドルの枠
呼び出しに使える回数	200	月5,000	月10,000
作れるアプリの数	5	50	200
登録できる資料	50件	500件	1,000件
容量	50メガバイト	5ギガバイト	20ギガバイト
同じ場所で作業できる人	1人	3人	50人
記録の保存	30日	無期限	無期限

この表は、人数の欄から読むと社内展開の形が決まります。上位の枠でも、同じ作業場に入れるのは50人です。全社の数千人が使うことと、数十人が作ることは、枠の上では別の話です。枠に当たるのは使う人の数ではなく、作る人の数です。作る人を増やす計画があるなら、最初から上限の側から設計しておくと、途中で作り直さずに済みます。

公開されている版を自社の環境で動かす形には、この上限がありません。代わりに、動かす場所の用意、更新、障害への対応が自社の仕事になります。置き場所そのものの選び方は別の論点なので深追いしませんが、発注前に見るのは1点で足ります。上限に当たるのが先か、面倒を見る人が足りなくなるのが先か。どちらが先に来るかを見積もると、置き場所の答えはほぼ自動的に決まります。記録の保存期間が30日で切れる点も、無料の枠で試すときには押さえておきたいところです。

誰に開くか。情報システム部門に閉じるか、現場にも開くか

Difyを入れた会社が最初に迷うのが、作る権限を誰に渡すかです。情報システム部門に閉じると、品質は揃いますが、作りたいものの待ち行列ができます。現場に開くと、数は出ますが、揃いません。どちらが正解かという問いではなく、どちらの副作用を引き受けるかの選択です。

判断の材料は、先の4種類の分け方がそのまま使えます。会話の窓口と、資料を読ませて答えさせる仕組みは、現場に開いてよい範囲です。作れるものの上限がはっきりしていて、失敗しても影響が窓口の中に収まるからです。一方、手順を流す仕組みと外部の道具を呼ぶ仕組みは閉じます。外部を呼び始めた時点で、失敗の影響が社外や基幹のデータに届きます。開くかどうかは、人ではなく、作るものの種類で決めます。

実際に開くなら、開く前に用意するものが3つあります。使ってよい資料の範囲を書いた1枚、公開してよい相手の区分、そして詰まったときの相談先です。この3つがないまま研修だけを開くと、作られたものが片づけられずに残ります。研修の日程を決める前に、この3つの担当者名を決めておくほうが、結果として早く広がります。

現場に開いたときに、実際に起きること

開いたあとに起きることは、会社が違ってもよく似ています。数か月で似たアプリが並ぶ。作った人が異動して直せる人がいなくなる。指示文の中に取引先の名前が直接書き込まれている。試したまま公開の状態で放置される。どれも悪意なく起きるので、注意喚起では止まりません。

• 同じ用途のアプリが部門ごとに並ぶ：作る前に「既にあるか」を確かめる場所を1か所決める
• 作った人が異動する：アプリごとに持ち主と代理の2名を登録してから公開する
• 指示文に固有名詞が直接書かれる：変わる情報は資料として登録し、指示文には書かない
• 試作のまま公開が続く：作った日を起点に、見直す日をあらかじめ決めておく

このうち、いちばんあとになって効いてくるのが持ち主の不在です。窓口は動き続けるので、壊れるまで誰も気づきません。そして壊れたときには、作った人がもういません。動いているものほど、持ち主がいないことに気づけません。

対策は難しくありません。台帳を1枚作ります。アプリの名前、目的、持ち主、使ってよい相手、参照している資料、外部を呼んでいるかどうか。この6項目だけの表を、作った時点で埋めることを公開の条件にします。台帳がないまま数が増えると、あとから棚卸しする作業のほうが、作った作業より重くなります。台帳は増えてから作るものではなく、1個目のときに作るものです。

止め方と権限を、部品を並べる前に決める

作る話は盛り上がりますが、止める話は後回しになります。実務では、止め方が決まっていないものは本番に出せません。決めるのは4つ、誰が使ってよいか、何を入れてよいか、どこまで自動で進めてよいか、誰がどう止めるかです。順番に並べると次のようになります。

5番目は軽く見られがちですが、あとから追加できません。記録がない状態で「おかしな答えが返った」と報告が来ても、再現も原因の特定もできないからです。Difyの日本法人が公開している解説では、資料を取り込む工程について、試し実行や実行の履歴によって失敗の原因を1工程ずつたどれると説明されています。この「たどれる」状態を作る側の条件にしておくと、運用の相談が短く済みます。

参照できる範囲を絞る仕組みも用意されています。同じ解説では、利用者の属性や認証に応じて、資料に付けた印で参照できる範囲を制御する方法が挙げられています。全社に開く窓口ほど、この制御が要ります。全員が同じ答えを受け取ってよいかを、公開の前に一度考えておくかどうかで、人事や法務からの差し戻しの回数が変わります。

AIに判断させない線を、部品の並びで引く

ここまでで何度か触れましたが、いちばん壊れやすいのは判断を任せたときです。金額を決める、可否を出す、優先度を付ける。これらを最後まで自動で通すと、間違いが人の目に触れないまま外へ出ます。しかも、返ってくる文章は一見すると筋が通っているので、受け取った側も疑いません。

この線は、部品の並びで引けます。人の承認を待つ部品を、外へ出る直前に置く。そして、承認の画面に出す情報に、結果だけでなくその結果の根拠になった資料の箇所を必ず含めます。結果だけを見せる承認は、押すだけの儀式になります。根拠を並べて出させることが、承認を実質のあるものにします。

指示文の側でも、根拠を書かせます。答えの末尾に参照した資料名と該当する箇所を必ず付けること、資料に見当たらない場合は推測せず「資料にない」と答えること。この2行を入れるだけで、人が確かめる作業が「全部読み直す」から「根拠の箇所だけ見る」に変わります。人が確認する範囲を先に決めておくと、確認は続きます。範囲を決めずに全部確認としてしまうと、2週間で誰も見なくなります。

作ったあとに効いてくる費用

費用は3つに分かれます。基盤そのものの利用料、呼び出した量に応じてかかるAI本体の費用、そして面倒を見る人の時間です。見積もりで抜けるのは、たいてい2つ目と3つ目です。基盤の利用料は表に載っているので誰でも数えられますが、残りの2つは作ってみないと分かりません。

呼び出しの量は、使う人の数ではなく1件あたりの処理の重さで決まります。資料を読ませて答えさせる仕組みは、1回の質問で複数回AIを呼びます。手順を流す仕組みは、並べた部品の数だけ呼びます。だから、利用者が10倍になったら費用も10倍という素直な比例にはならず、部品を1つ足しただけで全体が増えます。増えるのは人数ではなく、1件あたりの呼び出しの回数です。試作の段階で1件あたり何回呼んでいるかを数えておくと、あとの見積もりが立ちます。

3つ目の人の時間は、資料の更新に集中します。手順書が変われば登録し直す。用語が変われば直す。答えがずれたという報告が来れば確かめる。この作業は毎月発生し、アプリの数に比例します。20個作れば20個分の面倒を見ることになります。増やす前に、1個あたり月に何時間かかるかを実測しておくと、増やしてよい数の上限が自社の人員から逆算できます。

向かない用途を、先に外しておく

何が作れるかを考えるより、何を作らないかを先に決めるほうが早く進みます。外すべきは3種類、判断そのものを任せる用途、正確さが法的に問われる用途、そして根拠を示せないと成立しない用途です。この3つを最初に外しておくと、残った範囲での議論が具体的になります。

判断そのものというのは、採否・与信・評価・処分のように、結果が人の扱いを変えるものです。ここに自動の結果をそのまま使うと、説明を求められたときに答えられません。Difyで組めるかどうかという問題ではなく、組んではいけない領域として先に線を引いておく話です。人が見る工程を挟んだとしても、示された結果に人が引きずられる点は変わらないので、そもそも点数を出させない設計のほうが安全です。

正確さが法的に問われるのは、契約の条項の解釈、税や法令の適用の判断、安全に関わる手順の指示です。生成AIの答えは、確からしく見えるほど確かめにくくなります。この領域で使うなら、役割を候補の提示と該当箇所の抜き出しに限り、結論は必ず人が出します。出させるのは候補と根拠であって、結論ではありません。社外にそのまま出る文章、たとえば提案書や回答書も同じ扱いにしておくと、社内の合意が取りやすくなります。

2026年に入って変わったところ

直近の半年で増えているのは、作る機能よりも作ったあとを支える機能です。2026年3月には、作った流れを型として公開したり、公開されている型を取り込んだりできる仕組みが公式に案内されました。同じ月には、提供元が3,000万ドルの資金調達を公表しています。基盤を長く使うかどうかを判断するとき、提供元が続くかどうかは実際の検討材料になります。

資料を扱う側では、2025年9月の版で、資料を取り込んで整える工程そのものを画面上の流れとして組める仕組みが入りました。取り込み、抽出、変換、保存の4工程に分かれ、どの工程で失敗したかを追えます。それ以前は、資料の前処理が入れてみるまで分からない箱でした。ここが見えるようになったことで、精度が出ない原因を指示文のせいにする回数が減ります。

つなぐ側では、AIと道具をつなぐ共通の決まりごとへの対応が進み、作った流れを他の仕組みから道具として呼べるようになっています。2026年7月には、命令を打ち込んで作ったアプリを呼び出せる公式の道具が公開されました。2026年8月には、実行した内容をあとから検証できる記録を残す部品も加わっています。増えているのは作る機能ではなく、作ったあとを説明する機能です。この向きは、社内の審査を通すときの説明のしやすさに直結します。

この記事に出てきた言葉のミニ解説

社内で話すときに言葉が揃っていないと、議論が空回りします。提案を受ける側が押さえておけば足りる範囲に絞って、ここまでに出てきた言葉を短くまとめます。細かい仕様まで覚える必要はなく、聞き返せる程度で十分です。

この8語が揃うと、提案を受けたときに「どの部品で作るのか」「資料はどの方式で切るのか」「1件あたり何回呼ぶのか」を、その場で聞き返せます。聞き返せる言葉を持っているかどうかが、見積もりの妥当性を判断できるかどうかを分けます。逆に、この8語を使わずに説明してくる相手には、もう一段の説明を求めたほうが安全です。

発注や内製を決める前に確かめる項目

最後に、社内で作るか外に頼むかにかかわらず、着手の前に確かめる項目を並べます。すべてに答えが出ている必要はありません。答えの出ていない項目がどれかが分かることが、この一覧の目的です。

• 作ろうとしているものが、4種類のどれに当たるかを一言で言えるか
• その用途が、判断そのものを任せる領域に入り込んでいないか
• 答えの元にする資料が、最新版に一本化されているか
• 資料をどの単位で切るかを、試作の段階で確かめる計画になっているか
• 使ってよい相手の区分と、入れてはいけないデータの線を、文書にしたか
• 社外や基幹のデータへ出る直前に、人が確かめる工程が入っているか
• 答えに参照した資料名と該当箇所を必ず添えさせる指示になっているか
• 誰がどう止めるかが、代理の担当まで含めて決まっているか
• 1件あたり何回AIを呼んでいるかを、試作の段階で数えたか
• 作る人の数が、契約の枠に収まっているか
• アプリの持ち主と代理を登録する台帳が、1個目から用意されているか
• 資料の更新に月あたり何時間かけるかを、アプリ1個あたりで見積もったか

この一覧のうち、外部に相談する前に自社だけで埋められるのは、資料に関する項目と線引きに関する項目です。ここが埋まっていれば、見積もりの往復は目に見えて短くなります。埋まらなかった項目が、そのまま相談すべき論点になります。

まとめ

Difyは開発をなくす道具ではなく、組み立ての部分を画面の上に移す道具です。だから見極めるべきは「作れるかどうか」ではなく、「どの種類を作ろうとしているか」になります。会話の窓口と資料を読ませて答えさせる仕組みは現場に開いてよく、数日から2週間で形になります。手順を流す仕組みと外部の道具を呼ぶ仕組みは、権限と失敗時の扱いが要るので情報システム部門の領分です。そして、作れる範囲を最終的に決めるのは腕前ではなく、呼び出しの回数・資料の件数・作業できる人数といった契約の枠です。作ったあとには、呼び出した量に応じた費用と、資料を更新し続ける人の時間が毎月かかります。判断そのものはAIに任せず、答えには根拠を書かせ、人が確かめる範囲と止め方を部品を並べる前に決める。この3つを先に決めておけば、あとから作り直す範囲はずっと小さくなります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。