株式会社ディーネットでは、AWS上にDifyを自社構築（セルフホスト）して社内のAI基盤にしています。月にかかっている費用は約5.5万円です。その前に使っていたChatGPT Teamは、全社員ぶんで約22万円でした。ChatGPT Teamで社員がAIに慣れたぶんは、そのまま引き継いでいます。
金額だけの話ではありません。人数ぶんの固定費だったものが、使ったぶんの変動費になりました。
この記事では、その費用の内訳と、建てたあとにかかっている手間を、自社の実測値で書きます。
この記事で書くのは、次の4つです。
- 月22万円が5.5万円になった内訳と、その5.5万円に入っていない人の時間
- 構築で判断が必要だった3点
- いま実際に動いているアプリと、その中身
- そして、「作れる人を増やす」がうまくいかなかった話
前提を先に書いておきます。ここに出てくる金額は、約60名規模・日常的な利用を前提とした自社の実測値です。そのまま他社に当てはまる数字ではありません。
先に、結論だけまとめます。
| 移行前（ChatGPT Team） | 移行後（AWS×Dify） | |
|---|---|---|
| 費用のかたち | 人数ぶんの固定費 | 使ったぶんの変動費 |
| 月額 | 約22万円 | 約5.5万円 |
| かかる人手 | ほぼなし | 初期3人日＋月3〜8時間 |
出典: 株式会社ディーネット 社内実測（2025年3月時点／約60名規模・日常的な利用が前提／1ドル150円換算）
出典: 株式会社ディーネット 社内構成（AWS上にDifyをセルフホストし、API接続はVPC内のLambda経由で行う構成）
移行前：ChatGPT Teamをやめた理由は、ひとつだけでした
移行前は、ChatGPT Teamを全社員ぶん契約していました。個人の作業は速くなり、AIに触れたことがない社員はほぼいなくなりました。ライセンス費を払った価値は、そこにありました。
ただ、業務のフローそのものは変わりませんでした。チャットは入力が自由なので、出てくるものがそろわず、業務の手順として配れないからです。私たちがDifyの自社構築へ移ったのは、この一点が理由です。
移行前の1年で何が足りなかったのかは、別の記事に分けて書いています → 生成AIが定着しない3つの理由
なぜDifyの自社構築（セルフホスト）を選んだのか
Difyは、生成AIのアプリやワークフローをノーコードで組み立てられるプラットフォームです（dify.ai）。私たちが注目したのは、機能の多さではありません。プロンプトを「アプリ」として固定できるという一点です。
チャットは、毎回ゼロから話しかける道具です。Difyのアプリは、入力欄と手順が決まっています。この違いが、そのまま「個人の工夫」と「業務の手順」の違いになります。
Difyには、提供元が運営するクラウド版もあります。それでも自社構築（セルフホスト）を選んだのは、次の3つを自社の基準で決めたかったからです。
- 誰がアクセスできるか — 社内からだけにするのか、社外からも通すのか
- 入力した内容がどこへ行くか — 学習に使われない形にできるか
- 既存のしくみとどうつなぐか — 社内のデータやサービスと接続できるか
置き場所にAWSを選んだ理由は、ややあっけないものです。私たちはAWSの運用を本業にしています。すでに毎日見ている環境の中に置いたほうが、新しく増える負担がいちばん少なくて済む。それだけです。
裏を返すと、これは「AWSを見慣れた人が社内にいるかどうか」で難易度が変わる選択でもあります。この点は、記事の最後にもう一度触れます。
全社共通と個別開発：AI基盤を二階建てにした理由
Difyへ移るとき、アプリの作り方を二階建てにしました。
- 1階：全社共通のAIチャット — 全員が今日から使える入口。用途を決めない汎用のもの
- 2階：業務ごとの個別アプリ — 特定の仕事のために、入力欄と手順を決めたもの
分けたのには理由があります。全社に配るものは、用途を決めないほうがいい。決めた瞬間に、当てはまらない人が使わなくなるからです。一方で、業務のやり方が変わるのは2階のほうです。1階は入口、2階が本丸、という整理をしました。
では2階には、実際に何が置かれているのか。ここからが本題です。
実際に動いているアプリ：入力欄が決まると、仕事は変わりました
AIは、配っても業務を変えません。変わるのは、入力欄が決まったときです。
社内でいま動いているものを、3つご紹介します。全員が使う汎用のチャット、一部のメンバーが使っているワークフロー、そして展示会の名刺対応です。おもしろいのは、後ろの2つのほうでした。
① 全社で使う、共通のAIチャット
Difyで汎用のチャットアプリをつくり、全社に公開しています。調べもの、文章の下書き、要約。日常的に使うAIチャットとして、そのまま定着しました。
LLMには、Amazon Bedrock経由のClaudeや、OpenAIのGPTモデルなど、その時点で最新の汎用モデルを使っています。チャットにはツールを足せるので、Google検索、Perplexity、DALL·E 3などを、プロンプトに応じて自動で呼び出します。対話の幅は、ここでひろがりました。
Chromeなどブラウザの拡張機能からも開けるようにしています。使いはじめるまでの手数を、なるべく減らしたかったからです。
ただ、ここまでは移行の前と後で、やっていることが大きくは変わっていません。配る側の仕事としては、ここが終点でした。
② コラム記事から、ショート動画の企画をつくる
本題はこちらです。自社のコラム記事から、AWSの解説ショート動画の企画をつくるワークフローを、Dify上に用意しています。
使い方はかんたんです。担当者がコラムのURLをDifyに渡して、ワークフローを走らせます。しばらくすると、動画の企画が返ってきます。あとは、それをもとにショート動画を制作するだけです。
大事なのは、短くなった時間の話ではありません。Difyを入れる前は、そもそも企画そのものができていませんでした。
この仕事は、チャットではうまくいきませんでした。やろうとすると、毎回おなじ長い指示を打ち込むことになります。どんな観点で記事を読むのか。尺はどれくらいか。何を先に見せるのか。それを覚えている人だけが、まわせる仕事だったのです。覚えている人がいなければ、企画は1本も生まれません。
ワークフローにしてからは、入力欄がURLひとつになりました。手順は、アプリの中に入っています。だから、指示を覚えていない人でも走らせられます。やる人がいなかった仕事が、やれる仕事に変わりました。
時短の事例ではありません。できなかったことが、できるようになった事例です。私たちがDifyへ移して、いちばん手ごたえがあったのは、この一件でした。
③ 展示会でもらった名刺から、その日のうちにフォローする
展示会の名刺対応にも、Difyを組みこんでいます。名刺をその場で撮ると、S3に置かれた画像をきっかけにLambdaが動き、Difyが読み取りと要約、フォロー文の作成まで行います。そこからSlackへの通知と、ショートメッセージの送信までつながります。
数字はこうなりました。名刺を撮ってから入力が終わるまで30秒。手入力の工数は2人日から0.5人日へ。フォローが終わるまでの時間は、それまで3営業日かかっていたものが、8割は当日中に終わるようになりました（読み取りの精度は89%）。
この仕組みは、別の記事で詳しく書いています → Dify×AWSで実現する展示会リード即時フォロー
ただ、正直に付け加えます。これはノーコードだけで組んだものではありません。S3、Lambda、DynamoDB、外部サービスのAPI。つないでいるのは、開発ができるメンバーです。この話は後半でもう一度します。
違いは、入力欄があるかどうか
並べてみると、境目がはっきりします。汎用のチャットは、何を入れてもいい代わりに、何を入れるかが人しだいです。動画の企画と名刺の対応は、入れるものが決まっている代わりに、誰が走らせても手順が同じです。
業務のやり方が変わったのは、後の2つでした。全社に配ったチャットは土台です。そこから先は、どの仕事の入力欄を決めるか、という作業になります。1年やってみて、いちばん大きな学びがここでした。
とはいえ、社内でこうしたワークフローをつくれるメンバーは、まだ多くありません。これがもうひとつの学びにつながるのですが、その話は後半でします。
つくったあとを、誰が見るか。
ワークフローは、いちど動きはじめると業務に組みこまれます。そのぶん、止まったときに困る人も増えます。土台のDifyとAWSを、この先だれが見続けるのか。御社の場合どうなりそうかを、事例をもとに30分でお話しします。
30分、壁打ちする（無料） →
https://cloudassist.jp/contact/
AWS×Difyの構築手順：公式のとおりに進めて、判断が必要だった3点
基本の流れは、AWSの公式記事のとおりです。私たちもこれを見ながら建てました。
参考：Dify と Amazon Bedrock を使って、簡単にセキュリティオペレーション自動化（AWS builders-flash）
ここでは手順をなぞる代わりに、社内で実際に使う基盤にするうえで、判断や対処が必要だった3点を書きます。うちはAWSの運用が本業です。だからこそ、そうでない会社が詰まる場所も、たぶん分かります。
① 構成は、EC2 1台のスモールスタートにした
冗長化やコンテナ化まで作りこむ選択肢もありました。実際、AWSにはそのための道具がそろっています。それでも最初は、EC2を1台立てるだけの構成にしました。
理由は単純です。使われるかどうか分からないものに、先に大きな器を用意しないと決めたからです。まず動かして、足りなくなってから考える。結果として、この判断でよかったと思っています。凝った構成にしていたら、あとで説明する運用の手間が、さらに増えていたはずです。
社内向けの基盤を建てるとき、いちばん高くつくのは「使われないまま立派に動いているもの」です。
② 社内限定と、外部との連携をどう両立させるか
Difyの画面には、社内からだけアクセスできるようにしました。ここは早い段階で決めています。
ただ、それだけだと外部のサービスとつなげません。AIアプリは、外のAPIを呼びたい場面がどうしても出てきます。そこで、API接続はVPC内に置いたLambdaから行う構成にしました。人が出入りする入口は閉じたまま、必要な通り道だけを開ける、という考え方です。
この形にしておくと、あとから「あの外部サービスとつなぎたい」と言われても、通り道の設計を毎回やり直さずに済みます。
この判断は、思っていたのとは別の形でも効きました。いまは、Difyをバックエンドとして使い、フロントエンドをサーバーレスで自作するメンバーも出てきています。Difyの画面をそのまま使うのではなく、業務に合わせた入口を別に用意して、処理のほうはDifyに任せる、という組み方です。APIの通り道を先に開けておいたので、この使い方は追加の設計なしで始められました。
③ 建てるより、そのあとのバージョンアップのほうが重い
これがいちばん伝えたい点です。
Difyは更新が速いプロダクトです。私たちも不定期にバージョンを上げています。そして正直に書くと、上げると、それまで動いていたアプリが動かなくなることが少なくありません。だから上げる前と後で、そのつどテストが必要になります。
建てること自体は、そんなに大変ではありませんでした。長いのは、その後です。ここが次のコストの話に、そのままつながります。
社内情報を守りながら使う：4つのセキュリティ施策
自社で建てる一番の利点は、セキュリティを自社の基準で決められることです。私たちがとっている対策は、大きく4つです。
① 社内ネットワークからだけ使えるようにする
Difyの画面は、社内からのアクセスに限定しています。インターネットに開いていないので、URLを知られただけでは入れません。
社外から使うときは、まず社内ネットワークへVPNで接続します。そのうえでDifyを開く、という手順です。在宅勤務のメンバーも、この経路で同じように使っています。
② 外に出ていくのは、APIだけにする
外部サービスとの通信は、VPC内に置いたLambda（サーバーを持たずに処理を動かすAWSのサービス）を通します。呼び出す側にはAPIキーによる認証をかけ、通す相手を限定しています。人が出入りする入口と、システムが通る道を、はっきり分けている形です。
③ 入力した内容を、学習に使わせない
LLMと接続するときは、入力した内容がモデルの学習に使われない設定を選んでいます。「AIに社内の情報を入れていいのか」という不安は、ここをはっきりさせないとなくなりません。
④ 他人の入力を、管理画面から見られないようにする
これは社内から出た声への対応です。「自分が入力した内容を、他の人に見られたくない」。もっともな話でした。
そこで、ALB（ロードバランサー）のルールで、Dify管理画面のログ閲覧のパスを遮断しています。管理者を含め、通常の運用では他の人の入力内容を開けません。見られているかもしれない、と思われた時点で使われなくなるからです。
安くなった、より、「固定費が変動費になった」
お金の話をします。まず内訳です。
| 移行前（ChatGPT Team） | 移行後（AWS×Dify） | |
|---|---|---|
| 費用のかたち | 固定（人数ぶん） | 変動（使ったぶん） |
| ライセンス | 25ドル × 約60名 ＝ 約1,500ドル | — |
| AWS利用料 | — | 約1.5万円（EC2ほか。ほぼ固定） |
| LLM API利用料 | — | 約4万円（従量課金） |
| 月額合計 | 約22万円 | 約5.5万円 |
※ 1ドル150円換算。ChatGPT Teamは年契約時の1アカウント25ドルで計算しています（月契約は30ドル）。AWS・APIの金額は2026年時点でも同じ水準です。
※ 約60名規模・日常的な利用が前提の自社実測です（2025年3月時点）。同じ結果になるとは限りません。
出典: 株式会社ディーネット 社内実測（2025年3月時点／約60名規模・日常的な利用が前提／1ドル150円換算）
年額にすると、約200万円の差になります。ただ、私たちがいちばん大きいと感じているのは、削減額そのものではありません。料金体系が変わったことです。
人数ぶんの固定費だったものが、使ったぶんの変動費になりました。これには実務上の効きめがあります。人が増えても、その人数ぶんがそのまま上乗せされるわけではありません。「全社に配る」という判断のハードルが、静かに下がりました。使っていない人のぶんを払い続ける、という気まずさもなくなります。
この5.5万円に、入っていないもの
ここからは、書かないと不誠実になる部分です。この5.5万円には、人の時間が入っていません。
- 初期構築：3人日
- 運用：月3時間ほど。バージョンアップがある月は8時間
金額には換算しません。単価は会社ごとに違いますし、換算した数字だけが独り歩きします。月3〜8時間という時間のまま置いておきますので、自社の単価で計算してみてください。
もうひとつ。LLMのAPIは従量課金です。使われるほど増えます。うまく定着するほど削減幅は縮む、という構造になっています。私たちはいまのところ想定の範囲に収まっていますが、上限のアラートは設定しておくことをおすすめします。
そして、この月3〜8時間は、誰かの通常業務の上に乗ります。さきほど書いたバージョンアップのテストも、ここに含まれます。
月22万円が5.5万円になった話より、その5.5万円を誰が見ているかの話のほうが、たぶん大事です。
この5.5万円に入っていない部分だけを、引き受けることもできます。
AWS上のDifyの監視、バージョンアップへの追従、障害対応。土台の運用だけを切り出してお任せいただく形です。すでに建ててある環境の引き継ぎからでも構いません。
Dify導入支援（マネージド）を見る →
https://cloudassist.jp/ai/dify/#pricing
もうひとつの壁：作れる人は、増えませんでした
Difyへ移したとき、私たちはこう考えていました。ノーコードで作れるのだから、テンプレートとドキュメントを整えれば、作れるメンバーは増えるはずだと。そうはなりませんでした。
自社構築の場合、これは運用の話に直結します。Difyはバージョンアップのたびにテストが要り、動かなくなったときに手を入れられるのは、結局つくった本人だからです。だからいまは、作れる人を増やすことを目標にせず、作ったものを誰が見るかを先に決めるようにしています。
自社構築を考えるときに、いちばん先に決めておいたほうがいい論点でもあります。自分にしか触れないものを、もう一つ増やしますか。 番をすることは、その人の価値ではないはずです。
なぜ作れる人が増えなかったのかは、別の記事で詳しく書いています → 生成AIが定着しない3つの理由
配ることが仕事だった1年から、「誰が見続けるか」を決める仕事へ
ChatGPT Teamで得たものは、そのまま引き継げました。
- 社員のAIリテラシー
- 個人レベルの業務改善
- 「AIで何かできないか」と考える習慣
そこにAWS×Difyで足したのが、いまの姿です。
- 業務フローへの本格的な組み込み
- 使ったぶんだけの変動課金
- 自社の基準で決められるセキュリティ
この間に学んだことは、二つあります。
- 配っても業務は変わらない。変わるのは、入力欄が決まったときです
- その入力欄を決められる人は、簡単には増えません
1つ目だけを読むと、「じゃあアプリを作ろう」で終わります。でも2つ目まで含めて考えると、話が変わります。作る前に決めておくことがあるからです。作った後を、誰が見るのか。
私たちは自社で回しています。AWSの運用が本業で、見続ける人が社内にいるからです。逆に言えば、そうでない会社が同じ形をそのまま採る必要はありません。この記事を読んで「うちでは無理だ」と思ったなら、その勘はたぶん正しいです。
無理なのは、たいてい「建てること」ではなく「見続けること」のほうです。であれば、そこだけを分けて考えれば済みます。建てるところは自社でやり、運用だけを外に出す。あるいは最初から一緒に設計する。選び方はいくつもあります。
もし、いま社内でAIの話が止まっているとしたら、次に決めるべきなのは、たぶんツールではありません。誰が見続けるかです。
この記事は2026年7月時点の運用にあわせて更新しています。社内アンケートの数値は2025年初頭の調査によるものです。
「作った後を、誰が見るか」から話しませんか。
Difyで何かできそうだが、何を相談すればいいか分からない。その段階のご相談がいちばん多く、いちばん歓迎です。30分の壁打ちで、御社の状況を伺いながら「何から確かめるべきか」を一緒に言葉にします。その場で契約を迫ることはありません。
30分、壁打ちする（無料） →
https://cloudassist.jp/ai/dify/お問い合わせ →
https://cloudassist.jp/contact/
よくある質問
Q. Difyのクラウド版（有料プラン）と自社構築では、どちらが安いのですか？
料金のかかり方が違うので、人数で分かれます。クラウド版は利用者の数に応じた料金プランで、人が増えれば増えます。自社構築は実費（AWSの利用料＋LLMのAPI従量課金）なので、人数が増えても同じようには増えません。私たちの場合、約60名の時点で月約22万円と約5.5万円の差がつきました（2025年3月時点の自社実測）。
ただし、自社構築側には料金表に出てこないものが乗ります。初期構築に3人日、運用に月3〜8時間です。少人数で、チャットとして使うだけなら、クラウド版のほうが総合的に安く済むこともあります。
出典: 株式会社ディーネット 社内実測（2025年3月時点／約60名規模・日常的な利用が前提／1ドル150円換算）
Q. うちでも同じようにコストは下がりますか？
条件によります。本事例は「約60名規模」「日常的に利用」「API従量課金へ移行」という前提のもとで、月約22万円から約5.5万円になった自社の実測値です（2025年3月時点）。人数や使い方が変われば結果も変わりますし、APIは使うほど増えます。ただ、人数ぶんの固定費が使ったぶんの変動費になるという構造の変化は、規模にかかわらず起きます。
Q. ノーコードなら、非エンジニアでも業務アプリを作れますか？
画面や処理を組み立てるところは、ノーコードでできます。ただ、私たちの実感としては、そこは難所ではありませんでした。難しいのは、どの業務を切り出すか、何を入力欄にするか、出てきたものが実務で使えるかを判断する部分です。テンプレートとドキュメントを整えれば作れる人が増えるだろうと考えていましたが、思ったようには増えませんでした。作れる人を増やすことよりも、作ったものを誰が見続けるかを先に決めることをおすすめします。
Q. Difyでも結局、属人化しませんか？
チャットよりは抑えられる形になります。入力・処理・出力をアプリとして固定できるので、使う側の属人化は確実に減ります。一方で、つくる側の属人化は残ります。むしろ、アプリが増えるほど「これを直せるのはあの人だけ」という状態は生まれやすくなります。テンプレートや命名ルールの整備に加えて、担当が抜けたときに誰が引き継ぐのかを、先に決めておく必要があります。
Q. セキュリティ面はChatGPTより安全ですか？
「安全」というより「制御できる」と表現するのが正確です。社内限定のアクセス、API認証、学習データに使わせない設定、ログ閲覧の制限などを、自社の基準で組み合わせられます。どこまでやるかを自分たちで決められることが、自社構築のいちばんの利点です。
Q. テレワーク中心の会社でも使えますか？
使えますが、アクセス経路の設計は必要になります。私たちはDifyを社内ネットワークからのアクセスに限定しています。社外から使うときは、社内へVPN接続したうえでDifyを開く形です。在宅勤務のメンバーも、この経路で問題なく使っています。ただ、テレワークが中心の会社では、VPNを前提にするのか、別の認証のしくみを入口に置くのかを、最初に決めることになります。
Q. Difyのバージョンアップは、誰が見るのですか？
これは自社構築を選ぶときに、いちばん先に決めておくべき点です。Difyは更新が速く、上げるとそれまで動いていたアプリが動かなくなることが少なくありません。そのつどテストが必要になります。私たちの場合は運用に月3時間ほど、バージョンアップがある月は8時間ほどかかっています。社内で担当を置くのか、外に出すのかを、建てる前に決めておくことをおすすめします。
Q. ChatGPT Teamは完全に解約したのですか？
ほぼ解約しました。全社共通のAIチャットがDify側にあるため、同じ用途で二重に持つ必要がなくなったためです。ただし、開発まわりではClaude Codeを使っているメンバーが数名います。すべてを1つに寄せる必要はなく、用途で使い分ければよいと考えています。
Q. 小規模な会社でも導入する価値はありますか？
目的しだいです。チャットを使いたいだけであれば、自社構築は過剰になる可能性があります。一方で「業務フローに組み込みたい」「入力と出力をそろえたい」という課題があるなら、規模に関係なく効果は出やすいです。ただし、見続ける人を確保できるかどうかは、規模が小さいほどシビアな条件になります。