昨今、生成AIの活用による業務効率化の取り組みは激しくなっています。皆さんの中にも、「自社でもAIを導入したいけれど、何から始めれば良いのだろう？」「どうすれば全社的にAI活用を浸透させられるのだろう？」といった課題をお持ちのDX推進担当者、現場のリーダーの方もいらっしゃるのではないでしょうか。
この記事では、私たちサイバーエージェントAIオペレーション室が生成AIによる競争力獲得のため、ChatGPTやGeminiなどのLLM（大規模言語モデル）を使ったアプリケーションの構築プラットフォームOSS「Dify」を活用して、全社的な業務効率化を推進している取り組みをご紹介します。
筆者は昨年8月に当社に参画するまで、LangChain等での生成AIアプリ開発経験はあるもののWeb/クラウド技術を中心としていた経緯もあり、キャッチアップしながらPMに取り組みました。
Difyとは
Difyは、米国のLangGenius社が開発しているOSS（オープンソースソフトウェア）およびSaaSです。ChatGPTをはじめとする様々なLLMと、SlackやGoogle検索APIといった外部サービスやRAG（Retrieval Augmented Generation：検索拡張生成）により保存した業務ナレッジを連携させ、コーディングの知識がなくてもAIアプリケーションを構築できるプラットフォームです。
Flowiseなど類似のOSSも存在する中でDifyを選んだ大きな理由は、その直感的で理解しやすいUI/UXの質の高さです。これにより、エンジニアだけでなく、マーケターや営業担当者といったビジネス職のメンバーでも、自分たちの手でAIアプリを作成し、活用できると判断し、推進しています。
プロダクトレッドグロース型のDify全社展開
当社は約8,000名の従業員が在籍し、インターネットを軸に、メディア&IP事業、インターネット広告事業、ゲーム事業などを中心にビジネスを展開しています。このような多様な業態に対して収穫逓増的に成果があげられるよう、このサービスを社内SaaSと捉え、そこでとられるプロダクトレッドグロースを模すアプローチをとりました。これは、製品自体が新規ユーザーの獲得や利用継続を促進する戦略です。
この方法は成功し、開始6ヶ月で社内ユーザー数は約1,800名弱に達し、そのうちそのうち25%以上が毎週コンスタントに利用するアクティブユーザーとなるなど、比較的速いペースで利用を拡大できています。
具体的には、まずDify利用のスムーズな自動オンボーディングを構築し、その後は、社内SNS（Slack）で利用者を募りながら、利用による成果がさらなる利用拡大につながるような好循環を生み出す施策（下図の青網掛け部分）を継続的に行っています。
DifyへのOSSカスタマイズによる高品質のオンボーディング
OSSであるDifyを社内のAWS環境にホスティングする際、オンボーディング体験の向上と迅速化に重点を置いたカスタマイズを行いました。
運用工数をかけずに一気に利用者を拡大するだけでなく、Difyを使いたいというユーザーの熱意が冷める前に、すぐに実利用を開始、価値実感できるようにしました。この速さは、社内SaaSを提供する上では重要な指標(Time-to-Value)です。これによる離脱防止も寄与し、アクティブユーザー率は27%前後と比較的高く推移しています。
具体的には、Geminiにより作った大多数の社員像にトーンを合わせた告知文を全グループ共通のSlackチャンネルに投稿し、そこに直接利用申請フォームを設置します。申請後すぐに、DMで利用者にマニュアルと全社で策定している生成AIに対するコンプライアンス上の判断ガイドが送付され、最短5分程度で不安なく利用開始できるUXとしています。
生成AIの利用ガイドラインの策定 – CyberAgent Developers Blog
この際、同時にSlack上のコミュニティにも参加してもらうことで、不明点の相談など通じてすぐに業務に活かせるようにしています。
実装
これらのUXの実装は、SSOでもいいですが、Difyには公式サポート外であるものの「Console API」という機能にユーザー招待のAPIがあり、（ workspaces/current/members/invite-email エンドポイント）これを利用して一連のユーザー登録プロセスをSlack上で完結できるよう自動化しています。
この体験は製品価値が多く依存する部分となるため、可能なら以下の書籍で言及される通り、非同期キューの仕組みをとり、システム障害中に利用申請があった場合も、復旧後に自動で再登録されるようにしたり、デプロイ前に自動E2Eテストおくなど、安定運用の確保を検討するとよいと思います。
デュアルトラックアジャイルによる社内プロダクト開発
私たちのチームは、「デュアルトラックアジャイル」という手法で社内プロダクト開発を進めています。これは、プロダクト開発を以下の2つのトラック（流れ）で並行して進めるアプローチです。両チームが同じ周期で仮説検証と開発を繰り返すことで、ユーザーニーズを最短で実装に反映させることを目指しています。
| トラック | 概要 | 本件での担当 |
| Discoveryトラック | 社内コンサルティングやSlackサポートを通じたフィードバック収集、仮説の構築・検証 | 筆者を含む社内コンサルタント・Slack運営担当の2名 |
| Deliveryトラック | 実際の機能開発 | AWS/開発エンジニア2名 |
透明性を高める公開ロードマップ
利用者との信頼構築のためにも、現在運営として何を考えているかわかるよう、機能ロードマップもSlackのリスト機能を活用して公開しています。
v0 (Vercel社が提供する生成AIによって画像・自然言語からUIコードを生成するツール)を使ったプロトタイプなどを使い、ここでやり取りすることにより、各部署/グループ会社のAI活用推進者とも連携をとりつつ、個々のステークホルダーとのやり取りが断片化しないように合意形成を進められます。
OpenView Partners （PLGの提唱企業）によるNotionなどの事例
継続的なカスタマイズ開発
私たちのプロジェクトでは、Difyをシングルテナントのまま、全ユーザーが自由な相手を選べるReBAC（関係ベースのアクセス制御）のアプリ共有機能を独自に実装しました。これにより、利用者ごとの組織・利用形態に合わせた柔軟にアプリ共有できるようにしています。主にこれを後述のDify活用コンサルティングにおけるフィードバックを元に、仕様に落としこんでいます。
システムのインフラ面などでは、通常の業務システム同様アクセスユーザー数は多くはないため、AWSのベストプラクティスに沿っていれば、注意する部分は以下のような特有の負荷のみと考えます。
- 大容量のRAG登録
- スクリプトによるアプリAPI連続呼び出しによるパフォーマンス不足
RAG登録は想定を超える大容量で行われることがコンサルティング時に判明したため、ベクトルデータベースとしてPaaS型のTiDBを採用し、スケーラビリティを確保しました。
また、API連続呼び出しによるパフォーマンス低下は、真の問題としては特定ユーザーの高負荷によるパフォーマンス低下が他のユーザーにまで影響を及ぼしてしまうこと(ノイジーネイバー問題)といえます。これはDifyコード内の環境変数APP_MAX_ACTIVE_REQUESTSによる1アプリごとの最大並列リクエスト数を制限で防止できます。
2週間でアプリ完成を目指す！Dify一日ハンズオンワークショップ
Difyアプリの社内導入を加速させるため、一日ハンズオンワークショップという形で社内コンサルティングを実施しています。このゴールは、マーケターをはじめとするビジネス職の社員が、自らの手で使うAI業務アプリを作成し、運用できることです。前述のスプリントと同期し、2週間ごとに各参加者（6〜7名程度）のアプリ開発を個別に支援し、ワークショップ当日にはアプリの完成を目指します。
（もちろん、その後も実務導入のためのサポートは継続します）。
Google People+AI Guidebookを意識した要件定義
要件定義は深い領域ですが、通常のエンジニアリングからの延長で行うのであれば、Googleが公開し、最近では生成AIにも対応してアップデートされている「People+AI Guidebook」が有用でしょう。これはAIアプリケーションのUXリサーチのためのガイドですが、業務自動化における要件定義においても非常に有用です。
200ページ以上とボリュームがあるため、特に実践しやすい部分をピックアップして活用しています。
大まかな流れとしては、まずユーザーから既存業務のフローをヒアリングし、AIでどこまで自動化できるか、それで業務として満足できるかを明確にします。ここで重要なのは、「生成AIが本当に適しているか」「精度はどこまで求めるべきか」といった判断です。
ドメインエキスパートからのインプットを得る
前述の通り、業務を最もよく知るビジネス担当者自身がAIアプリを作り、フィードバックしていくことで、実際のニーズとの乖離を防ぎます。また、これにより利用によって新たな要件(いわゆるEmerging Requirement)が生まれ、さらなる業務改善の機会につながることも少なくありません。
ルールベースシステムと使い分ける
生成AIは、入力された言葉から次に来る言葉を予測して文章などを生成する仕組みです。そのため、得意なことと不得意なことがあります。これを間違えると、作ってからアウトプットの質が不十分で使えない、ということにもなりえます。
| 生成AI向き | ルールベース向き |
| 専門的なツールを使った認知負荷の高い作業 | 一貫性が求められる |
| 文脈や複数の情報を使った動的な回答 | 失敗コストが高い |
| 創作と表現の拡張・共創支援 | 論理的な根拠が必要 |
例えば、高額なコストを使う広告配信に対する設定処理はGASや専用システムなどのルールベースが適していますが、後述するような専用検索ツールなど多用するSEOでの競合調査などではDifyと生成AIは好相性です。
Difyを使う前提では開発コストが低く抑えられるため、短時間で自動化したい場合も生成AIは選択肢に挙がるでしょう。
また、両方の条件を求める業務としてアンケートの結果を探索的な分析が挙げられます。これはLLMへの日本語の指示が有用であるものの、数値ズレのない計算結果が求められるため、Difyアプリの利用は難しいです。このような場合ではChatGPT Data Analysisが補足的に利用できます。これは指示に対して分析用のPythonコード生成→そのコードで分析という流れを取るため、数値計算のズレが起こさず両方のメリットを得られます。
Precision / Recallのバランスを見極め、満足できる精度を目指す
従来のシステム開発同様に、「AIが期待通りの情報処理を行う精度」も実行・開発コストや処理時間などとのトレードオフを考慮し、満足できる条件以上の最適化は行わないという点が重要です。
このAI出力の精度は、主に以下の2つの指標があり、これらもトレードオフの関係にあります。
- Precision（適合率）： AIが出力した結果のうち、本当に正しかったものの割合。これが高いと、間違いが少ないと言える。
- Recall（再現率）： AIが検出・出力すべき情報のうち、実際に検出・出力できたものの割合。これが高いと、見逃しが少ないと言える。
例えば、「ブログ記事からのカテゴリ出力」のようなユースケースで人間によるAIのアウトプットへの事後チェックが前提となっていた場合では、間違った出力が多少あってもよく、むしろ役立つ情報を多く出せることが重要となる。
| Precision重視 | Recall重視 |
| そのまま指示 (抜け漏れなく見つけて) | そのまま指示 (判断できなければ出力しないで) |
| 創発的に、などのクリエイティブ系の指示 | 具体的な判断基準を与え、 出力にも根拠を添えさせる |
実際の活用内容: 見えてきたDifyで業務効率化する３つのステップ
Difyをビジネス職のメンバーに使ってもらう中で、元々の知識や習熟度に応じて段階的に利用が進み、それに伴って効果も大きくなることが見えてきました。ハンズオンワークショップなどを通じて、私たちは以下のような3つのステップでDify活用を進めることを推奨しています。
まずは、エージェントで理解する
Difyエージェント機能はシステムプロントと任意のツール(時刻取得やGoogle検索API)を設定できるチャットボットのようなものです。
日本語でビジネスロジックを記述できるため予備知識が一切必要なく、ビジネス担当者がスムーズに馴染みのあるツールと連携させたAIエージェントを作ることができます。精度が比較的出せない、ツールの使用回数に制限があるなど、機能としては限定的になるものの、「やってみて、これもできると思った」、結果を調整したいなどの場合に日本語での指示変更だけで対応できるため初期のプロトタイプにも向いています。
社内でもこの使いやすさからエージェントを起点とした展開も進めています。
ワークフローで一気に自動化する
Difyのワークフロー機能を使うと、画面上でフローチャートを描くように、AIアプリケーションの処理の流れを組み立てることができます。フローチャートの各要素でLLMの処理を記述できるため、より複雑な業務ロジックや、複数の情報源を組み合わせた処理も構成できます。
「AI前提」で業務フローを再構築する
ワークフローを使うと繰り返し処理などができる上、APIとして外部のシステムとの連携もできるため、既存業務での量を超えたアウトプットが出せます。このため、一度自動化した後に、ボトルネックになっている箇所をDifyアプリに置き換えを再検討すると大きな成果が出せます。
結論・展望
Difyによりビジネス職の方を中心に自身の業務にフィットさせた生成AI活用を進める取り組みは一定成功したように思います。今後はMCPによる社内外システムとAIエージェント連携など、ノーコードプラットフォームゆえにさらなる活用拡大が期待できると考えています。