Dify運用事例｜カカクコムはワークスペース・APIキー・監視ジョブをどう設計したか

Difyを試験導入から全社展開へ進めるときに詰まるのは、ツールの機能ではなく運用の設計です。カカクコムは部門ごとのワークスペース分割とAPIキーの個別発行、公開範囲の制限、定期的な監視ジョブを組み合わせて、作る人を増やしながら統制を保っています。

設計で先に決めておかないと後から直せないのは3点あります。コストを誰の単位で追うか、作ったアプリをどこまで公開してよいことにするか、試す場所と本番を分けるか。

この記事では、同社が公開している技術ブログをもとに、ログイン統合からダッシュボード構築までの設計を順に見ていきます。読み終えると、自社の展開ルールの草案が書けます。

カカクコムがDifyを全社導入した理由

カカクコム(食べログ運営元)の設計は、既存のIDシステムと連携したログイン統合、「お試し」専用のサンドボックスワークスペースによる検証と本番の分離、BigQueryとLooker Studioで組んだ自前の利用状況ダッシュボードまで含みます。

以下の内容は、同社AIトランスフォーメーション推進部・遠藤怜氏が公開した技術ブログ記事をもとにしています。

カカクコムがDifyエンタープライズ版を全社導入した背景について、遠藤氏は3つの課題を挙げています。ひとつは、生成AIを使ったアプリを作れるAIエンジニアが社内に不足していたこと。

ふたつめは、PoC(概念実証、小規模な試作で実現性を検証する工程のことです)を終えた後、実際の業務利用に進むまでに時間がかかっていたこと。みっつめは、個別に作られたアプリが増えるほど、運用の負荷が積み重なっていたことです。

この3つの課題は、単発のツール導入では解決しません。エンジニアを増やさずに現場がアプリを作れる基盤を用意し、かつ、作られたアプリが増えても運用側が破綻しない仕組みを同時に用意する必要があります。

カカクコムの運用設計は、この2つの要請に応えるものになっています。

ワークスペースとAPIキーで、現場の自由と部門のコスト管理を両立する

ワークスペース分割: 主要部門から始めて、必要に応じて細分化する

カカクコムは、Difyのワークスペース(チームやプロジェクトごとに区切られた作業スペースのことです)を、まず主要な部門ごとに作成するところから始めました。

全部署を最初から細かく分けるのではなく、利用が広がるのに合わせて、必要な部署やプロジェクト単位でワークスペースを追加していく方針を取っています。

最初から完璧な組織図をワークスペースに反映させようとせず、使われながら粒度を調整していく設計です。

APIキー管理: 部署・プロジェクト単位でコストを追跡する

ワークスペースを分ける効果は、権限の分離だけにとどまりません。カカクコムは、ワークスペースごとに異なるAPIキーを発行しています。

AIモデルの呼び出しはAPIキー単位で計測できるため、「どの部署・プロジェクトで、どれだけAI利用コストが発生しているか」を後から正確に追跡できる状態を作っています。

全社共通の1つのAPIキーだけで運用してしまうと、利用が増えたときにコストの内訳がわからなくなり、どの部門の利用を伸ばすべきか、どこに無駄があるかを判断できなくなります。

ワークスペースとAPIキーを対応させる設計は、この問題を先回りして防ぐ仕組みです。

アプリの公開範囲とログイン基盤を同時に設計する

現場でアプリを作れるようになると、次に問題になるのは「誰が使えるようにするか」です。カカクコムはここにも具体的なルールを敷いています。

「探索」機能を基本にし、公開URLの発行を原則禁止にする

Difyで作ったアプリは、同じワークスペース内のメンバーだけが使える「探索」機能で公開するのが基本です。ワークスペースの外、つまりインターネット上に誰でもアクセスできる「公開URL」を発行してアプリを共有することは、原則として禁止しています。

社内向けに作ったアプリのURLがそのまま外部に漏れると、社内のデータや機能が意図せず外部からアクセス可能になるリスクがあるためです。

実際の制御は、公開URLのパターンへのアクセスをGoogle Cloud Armor(Googleが提供するWebアプリケーション向けの防御サービスです)で制限することで実現しています。

社内ルールとして周知するだけでなく、技術的にアクセス経路そのものを塞いでいる点が特徴です。

SSOで既存のIDシステムと統合する

ログインの管理も、Dify単体では完結させていません。

既存のIdP(IDプロバイダー、社員のアカウントを一元管理する認証基盤のことです。Azure ADやOktaなどが該当します)と連携し、SSO(シングルサインオン、複数のシステムに1回のログインでアクセスできる仕組みのことです)を実現しています。

退職者のアカウントを個別に無効化する手間や、パスワード管理のばらつきといった、利用者が増えるほど負荷が増す作業を、既存の認証基盤にまとめて任せる設計です。

使われ方を可視化して、放置・野良アプリを防ぐ

ワークスペースと公開範囲を設計しても、実際にどう使われているかが見えなければ、放置されたアプリや、審査を経ていない機能の利用に気づけません。カカクコムは、ここでも3つの仕組みを組み合わせています。

サンドボックスワークスペース: 「お試し」と本番利用を分ける

カカクコムには、通常の部門用ワークスペースとは別に、「サンドボックス」と呼ぶお試し用のワークスペースがあります。これからDifyを使ってみたい人が最初に触れる場所として、また、アプリの作り方を学ぶ講習会の実習環境としても使われています。

本番のワークスペースと分けておくことで、慣れないうちの試行錯誤が、実際に稼働しているアプリや部門のコスト集計に影響しない状態を作っています。

監視ジョブ: 未審査のモデルやツールを定期的にチェックする

Difyは、外部のAIモデルや連携ツールを柔軟に追加できる仕組みを持っています。柔軟であるぶん、審査を経ていないモデルやツールがいつの間にか有効化されているリスクも生まれます。

カカクコムは、この状態を人の目でその都度確認するのではなく、定期的な監視ジョブ(決まった間隔で自動的に実行されるチェック処理のことです)を走らせて、未審査のモデルやツールが有効化されていないかを継続的に確認する運用にしています。

BigQuery+Looker Studio: 自前のダッシュボードで利用状況を可視化する

もうひとつの柱が、利用状況そのものの可視化です。

カカクコムは、Dify自身が利用状況などを蓄積するCloud SQL(データベースのことです)のログを、BigQuery(Googleのデータ分析基盤です)に連携させています。

そのデータをLooker Studio(Googleの可視化ツールです)につなぎ、ダッシュボードを構築しています。

アカウント数やアプリの作成数といった指標を、既存のGoogle Cloud環境の延長で可視化できる状態にしている点が特徴です。

新しく可視化専用の製品を導入するのではなく、社内に既にあるデータ基盤の上に、運用の可視化をそのまま乗せている設計だといえます。

遠藤氏が2025年5月13日に公開した記事(全社導入から約1か月後の時点)によれば、当時のアカウント登録率は全従業員の約3割、作成されたアプリは約70個、稼働していたワークスペースは5個でした。

利用頻度を尋ねた社内調査では、回答者の約8割が「ほぼ毎日」または「週に2〜3回」利用していると答えています。

その後、Dify公式ブログ(2025年11月21日公開)によれば、カカクコムの登録率は全従業員の75%まで伸び、社内で使われているアプリは約950個に達しています。

象徴的な例として、ある製品データ抽出ツールは、導入からわずか3時間で本番稼働まで到達したと紹介されています。同じ会社の同じ取り組みでも、公開時点によって数字が大きく異なる点には注意が必要です。

全社展開の前に、何を設計しておくべきか

すでにDifyを試験導入していて、これから対象部署を広げようとしている場合、カカクコムの設計は次の順番で参考にできます。

まず、ワークスペースを現状の主要部門に沿って区切り直し、ワークスペースごとに個別のAPIキーを発行します。これだけで、あとから部門別のコストを追跡できる状態が作れます。

次に、アプリの公開範囲を「探索」機能に統一するルールを決め、公開URLを使う場合は個別申請制にするなど、外部公開の経路を限定します。

ログイン管理は、可能であれば早い段階で既存のIdPと連携させておくと、利用者が増えてからアカウントを整理し直す手間を避けられます。

最後に、利用状況を追う仕組みを決めます。BigQueryやLooker Studioを使わなくても、まずは定期的にワークスペースごとのアプリ数・利用者数を確認するだけの簡易な棚卸しから始めて構いません。

なお、Difyには料金プランによって利用できるワークスペース数やメンバー数、SSO機能の対応範囲に違いがあります。

エンタープライズ版に相当する契約形態や価格については、カカクコムの公開情報にも明記がなく、正確な条件はDifyの公式情報で個別に確認する必要があります。最新の料金プランはツール詳細ページで確認できます(Difyの詳細ページ)。

まとめ: 運用設計はカカクコムの実例がそのまま手本になる

Difyを試験導入した段階では、ワークスペースをひとつ、APIキーもひとつで動かしていても大きな問題は起きません。問題が起きるのは、対象部署が増え、作られるアプリの数が増えてからです。

カカクコムの設計は、ワークスペース分割・APIキー管理・公開範囲の制御・SSO・サンドボックス・監視ジョブ・自前ダッシュボードという一連の要素を、全社導入の初期段階からセットで組み込んでいる点に価値があります。

全社展開を検討する際は、次の点を確認しておくと迷いにくくなります。

• ワークスペースを部門単位で区切り、APIキーも対応させているか
• アプリの公開範囲を「探索」機能などに統一するルールを決めているか
• ログイン管理を既存のIdPと連携させる計画があるか
• 利用状況を定期的に確認する仕組み(簡易な棚卸しでも可)を用意しているか

これらは、Difyに限らず、社内で複数の部署がノーコードでアプリを作れる基盤全般に応用できる考え方です。

CTA

自社での展開設計そのものを相談したい場合、AIリスキル株式会社では生成AIの導入支援を行っています。「試験導入は終えたが、全社展開の運用設計に自信が持てない」といったご相談は、お気軽にどうぞ。

お問い合わせはこちら

この記事の出典

• カカクコムにおけるDifyエンタープライズ版の全社導入と活用ポイント(食べログTech Blog、遠藤怜氏/AIトランスフォーメーション推進部、2025年5月13日)
• Kakaku.com Accelerates AI Adoption with Dify: Fast, Secure, and Scalable(Dify公式ブログ、英語、2025年11月21日)
• Dify公式料金ページ(確認日2026年8月2日)

---

執筆メモ: 出典の詳細と時点の注意(本文非掲載、内部記録用)

• 食べログTech Blog記事(2025年5月13日、著者: 遠藤怜氏/AIトランスフォーメーション推進部)は、全社導入から約1か月後の時点の数字(登録率3割・アプリ約70個・ワークスペース5個・利用頻度8割がほぼ毎日/週2〜3回)を報告している。ワークスペース設計・APIキー管理・公開範囲制御(探索機能限定・公開URL原則禁止・Google Cloud Armorでの制限)・SSO(既存IdP連携)・サンドボックスワークスペース・監視ジョブ・BigQuery+Looker Studioダッシュボードの記述はすべてこの記事が一次情報
• Dify公式ブログ(英語、2025年11月21日公開、著者Jing Yan/Technical Writer、確認日2026-08-02)は、より後年の到達点の数字(登録率75%・アプリ約950個・製品データ抽出ツールの3時間本番稼働)を報告している。**この2つの記事は調査時点が異なるため、本文では明示的に時点を区別して引用した**
• Dify公式料金ページ(確認日2026-08-02)。エンタープライズ版の価格・契約形態は非公開のため、本文では「カカクコムの公開情報にも明記がない」と限界事項として明記し、独立章にせず該当セクションに畳み込んだ
• 既存記事`docs/ai-context/drafts/2026-07-31-ricoh-dify-dashboard.md`はリコー・カカクコム2社を並べた記事で、カカクコムの扱いは3〜4文の要約に留まる。本記事と情報源(食べログTech Blog記事)は共通するが、掘り下げる項目(SSO・サンドボックス・BigQuery+Looker Studioの構築フロー・監視ジョブの位置づけ)と想定読者(検討層ではなく運用設計層)が異なるため、重複記事ではなく別の切り口の記事として成立している

---