Amazon Bedrock + Dify + αで AI エージェントとデータ利活⽤を⺠主化する

弊社 BX 本部では、SEO 事業のような成熟した主⼒事業から、⼩規模な新規事業まで幅広いビジネスを展開しています。そのため、各事業やチームが直⾯する課題や必要とするシステムは多種多様です。従来のアプローチでは、エンジニア部⾨が中央集権的に各事業向けのシステムを開発していましたが、この⽅法では限られたリソースを⼤規模事業に優先的に配分せざるを得ず、⼩規模事業や新規事業への IT ⽀援が⼗分に⾏き届かないというボトルネックが⽣じていました。 そこで 2024 年に今後の IT 戦略として、Speee のカルチャーにあうアプローチとする以下の仮説を⽴てました。

1. セルフサービスアプローチを可能とするプラットフォームがあれば、各事業・チームが自立的に自分が欲しい機能・データを作る・活用することができるのではないか ?
2. 生成 AI が上記のアプローチを強烈に後押しするのではないか ?
3. 結果として、事業規模に寄らず全チームがテックの恩恵を受け、自立的なスケールを目指すことができるのではないか ?
   

つまり、セルフサービス型の仕組みを作りボトルネックを解消するというアプローチです。デメリットとして、利⽤する側に⼀定以上のリテラシーが求められます。 この仮説のもと、以下の 2 点を要件とするシステムを企画・定義しました (2024 年 2 ⽉)。

• セルフサービスのアプリ開発 : セルフサービスで⽣成 AI を組み込んだワークフロー型のアプリケーションを業務ユーザーでも⼀定のリテラシーがあれば作成できるプロダクトを作れること
• データ統合によるセルフサービスデータ活⽤ : セルフサービスで⾃社データを活⽤し、レポーティングの⾃動化や AS-IS データ分析や予測系の分析が可能な業務ユーザーフレンドリーなプロダクトを上記に組み込む

その後、システム要件定義やアーキテクチャ設計を進めていたところ、偶然、Dify という OSS が話題になっていることがわかり (ちょうど、ワークフロー機能を発表した 2024 年ゴールデンウィーク)、内容を確認するとなんと要件の半分が満たされる業務ユーザーフレンドリーなプロダクトが SNS 上でホットになっていました。

この規模の要件をスクラッチで、かつ、UI を含めて作るとなるとかなりの労⼒であること、また、OSS であるが故にもう 1 点の要件であるデータ統合もカスタムできる可能性を秘めていたため、Dify を⼤々的に導⼊する意思決定をし、2025 年 11 ⽉に運⽤を開始し、これまで継続的に改善を重ねています。

⼀⽅で悔しさもあります。あと半年早く企画して⾼速にプロダクトを開発していれば、ホットなプロダクトを世の中に排出できたということですから。

以降、弊社における Dify on AWS の構成と活⽤について記載します。

Dify はオープンソースの AI アプリ開発プラットフォームであり、主に以下の特徴を備えています。

• 業務ユーザーフレンドリーな UI を持つ
• ノーコードでチャットやワークフロー型のアプリケーションを開発することができ、LLM を組み込むことができる
• LLM はツールをコール可能なため、結果として、⾃然⾔語ベースで業務ロジックを実装可能な、ノーコードアプリケーション開発プラットフォームである
• 最新のバージョンではツールをマーケットプレイスからインストール可能となり、これを LLM に組み込みうまくプロンプトを記述することで、実装可能なロジックに広がり続けて いる

このため、利⽤者にワークフローやロジックの作成に関するある程度のリテラシーがある場合、可能性は無限⼤とも⾔えます。よって、特にテック系企業やウェブ系企業に親和性が⾼いと⾔えます。 また、生成 AI で業務改善を行おうとしているが潤沢なエンジニアリソースが無い企業も、最小限のエンジニアで、かつ業務ロジックに詳しい業務ユーザーが生成 AI アプリケーションのロジックを組み立てる環境を用意することが可能になります。

Dify は OSS として公開されており、弊社 BX 本部では Dify Community Edition を利⽤しています。AWS 上での構築・運⽤事例を以降で解説いたします。

各領域のポイントを以下に解説します。

AI エージェント開発やデータ統合の中核となる⼤規模⾔語モデル (LLM) には、Amazon Bedrock を利⽤しています。標準的なユースケースでは Claude 3.5 Haiku を基本モデルとして採⽤し、 より⾼度な理解や複雑な処理が必要な場合には Claude 3.7 Sonnet を使い分けることで、性能とコストのバランスを最適化しています。

複数のクラウドサービスの LLM を検証した結果、Amazon Bedrock を採⽤した主な理由は以下の通りです。

1. IAM による細やかなアクセス制御が可能
   
2. AWS の既存インフラとのシームレスな統合
3. コスト管理のシンプル化
4. 他サービスと比較して高い API リクエスト上限 (Rate Limit)
5. Claude モデルの優れた性能と安定性
   

また、現在では Amazon Bedrock は Embedding や Rerank 向けのモデルも提供していますので、Dify のナレッジ機能 (UI から簡単に RAG を作る機能) でも⼀律で Amazon Bedrock で対応できるようになりました。

エンタープライズで Dify を活⽤する際は、Amazon Bedrock が⾮常に親和性が⾼いと考えています。

Dify Community Edition の主要サーバーコンポーネント (web, worker, api, sandbox) は、Amazon ECS on AWS Fargate にデプロイしています。コンポーネント間の通信が相応にあるため、シンプル化や障害点削減のため web+api+sandbox を⼀つのサービスとし同⼀ホスト上にデプロイを、他のコンポーネント との通信がなく Amazon ElastiCache との通信ができれば問題がない worker については、個別のサービスとして切り出してデプロイしています。

主要サーバコンポーネント以外の Dify コンポーネント (データベース、ベクトル DB、Redis、nginx、ssrf proxy) はそれぞれ Amazon RDS、Amazon OpenSearch Service、Amazon ElastiCache for Valkey、Application Load Balancer、IAM+Security Group にて実装しています。

Dify は v1.0 からプラグインの仕組みが導⼊され、Dify Marketplace からのプラグイン導⼊が可能となりました。これは素晴らしい仕組みなのですが、プラグインの実⾏に必要なコンポーネントが新たに追加され (以降、plugin daemon と記載)、以下の特徴があり、AWS インフラに⼤きな影響のある変更でした。

• プラグインを利⽤すると、api コンテナから plugin daemon コンテナへの通信が発⽣し、 pluing daemon 上で処理が実⾏される
  
• プラグインが UI 上でインストールされると、plugin daemon コンテナ上でソースコードの展開と実⾏環境のデプロイが⾛る
  
  

残念ながら、2025 年 4 月 30 日時点では、プラグインの実⾏に必要なコンポーネント (Plugin Daemon) はロードバランシングには対応していないため、独⾃に AWS Lambda 上に機能を構築しデプロイしています。押さえておくべき Plugin Daemon の挙動として、以下が挙げられます。

• Plugin Daemon はプラグインインストール時に、各プラグインのソースに加えて実⾏環境を サーバーにインストールするため、インストールリクエストがあったサーバー上にのみ実⾏環境がインストールされる
• 上記を考慮し、アプリケーションレベルでのルーティングが実装されているが、インストール済みサーバーの URL や IP をサーバー間で互いに知っていることが前提であったり、インストール済みサーバーが落ちるとプラグイン実⾏不能に陥るなど、設計が複雑でありエンタープライズの実⽤に耐えるのは難しい

このため、弊社では独⾃にこの機能をサーバーレスモードとして AWS Lambda に実装しています。プラグインは実態がソースコード + requriements.txt などで構成されるため、対応する Docker コンテナを動的に作り AWS Lambda に登録しコール可能にすることで対応は可能です。

事業部別に Dify Community Edition の環境をデプロイし、テナントごとのドメインを払出し Application Load Balancer にてテナント別の振り分けを⾏うことでマルチテナントでの利⽤を可能としています。

Dify は弊社では社内システムとして利⽤しています。このため、Dify へのアクセスは Application Load Balancer にて社内 IP からのアクセスのみ許可する⼀⽅ (security group)、Google workspace や Slack アプリケー ションなどオープンインターネット経由での Dify アプリケーション連携がしたい要望が社内で⾮常に強いです。

これをセキュアに実現するため、WAF でのアクセス先ドメインの認証 + Amazon Cognito での OAuth 認証によりセキュアな通信路を確⽴し、その経路経由のみのアクセスを許容することでセキュリティを確保しています。

Dify へのアクセス時の認証サービスとして Amazon Cognitoを導⼊し、他テナントの Dify アプリケーションへのアクセス制限を実現しています。具体的には、Application Load Balancer にて URL ごとに Amazon Cognito 認証と連携するように設定することで実装しています。また、ユーザープールはテナントごとの Dify のユーザー情報を定期的に抽出してユーザープールに同期することで実現しています。

なお、細かいですが以下のような注意点もあります。Dify は UI がシングルページアプリケーションでありバックエンド (api コンテナ) との通信が全て Rest API で実装されている関係上、Application Load Balancer にてルールを分けることで⼗分対応が可能です。

• API コールで Dify アプリケーションを呼び出す際は SSO 認証突破が難しいが、API Key でのセキュリティが確保されている API での Dify アプリ連携は Amazon Cognito 認証の対象外とする。API コールのケースは URL が異なるため Application Load Balancer にて認証に回さないルールにすることで対応可能です
• ユーザーアカウント作成時、アクティベーション通信は認証回避が必須だが、Application Load Balancer にて URL 指定で認証に回さないように設定する事で対応
  

api コンテナ上で動作する RAG 作成 (dify のナレッジ機能) の⼀部の処理において、⾮常に重い処理があります。Dify のアプリケーションは基本的にネットワーク IO が多く、CPU クロックや⼤量メモリを必要とするワークロードはないのですが、このケースCPU・メモリともに占有する傾向があり、インスタンスタイプを⼩さくしすぎるとサーバーごと落ちてしまうトラブルが多発します。しかし、ナレッジ作成は頻度が低いリクエストになりますので、インスタンスを⾼いものにするのも現実的ではありません。このため、 AWS Lambda にオフロードすることで Dify のナレッジ作成機能利⽤時に ECS サービスが落ちることがないようにしています。

なお、本対応においては、ソースコードを改変しているわけではありません。Dify は UI が SPA (Single Page Application) でありバックエンドとの通信は Rest API (Flask) により実装されています。主に以下の対応を行うことで、Flask アプリとして実装されている Dify api コンテナのコード改変を行うことなく AWS Lambda にデプロイし運用しています。

• 該当の URL に対応する Application Load Balancer のリスナールールを作成し AWS Lambda へ振り分け
  • 弊社では /console/api/datasets/indexing-estimate と /console/api/datasets/init を対象として選定しています
• Amazon ECR に登録した Dify api コンテナイメージを AWS Lambda 関数として設定
• AWS Lambda 関数には AWS Lambda Adaptor を組み込み、Flask アプリである api コンテナがウェブアプリとして公開されるように設定
• 登録した AWS Lambda 関数から api コンテナへの通信があるため、内部 Application Load Balancer を作成し api への通信経路を確保
• 環境変数をオーバーライドするスクリプトが起動時に実行されるよう Dockerfile を調整。主に上記の api コンテナへの宛先 URL 環境変数の上書きなどが必要になります。

データレイクの基盤として Databricks を導⼊し、Dify アプリケーションによるデータ蓄積や、⾃社他システムデータを蓄積することで、Dify アプリケーションや Databricks の UI からデータを利活⽤可能としています。例えば、蓄積したデータに対して弊社独⾃の Dify プラグインから SQL を発⾏可能とすることで、Dify のワークフローやエージェントからレポーティングツールを作成することが可能です (例 : 何段階かに分けて SQL で中間データを作り、最後にエクセルにデータを貼り付けてレポー トを更新してメールや Slack で利⽤者に通知する、など)。また、データ・ビジネスアナリスト向けに Databricks のユーザーを払い出しアクセス可能とし、Databricks 上で BI Dashboard や予測系の分析機能を提供するなど、データ利活⽤を⺠主化する基盤として活⽤する予定です。

上記のデータ統合に包含される要素ではありますが、弊社 BX 本部ではデータドリブンでのコンサルティング業務が多いため、Amazon Quicksight を活⽤しています。実は Amazon Quicksight はプログラムインターフェースの提供が豊富です。このため、弊社独⾃の Dify プラグインとして Amazon Quicksight プラグインを開発し、ダッシュボード構築オペレーション⾃動化機能などを業務ユーザーに提供する事で、ダッシュボード構築の効率化を図っています。

テナントが多いこともあり、原則としてインフラ構築は全て AWS Cloud Development Kit により⾃動化しています。ただし、Datadog や Databricks など AWS Cloud Development Kit で実現困難なものは Terraform にて構築しています。

ここでは、Dify による AI エージェントのケイパビリティの可能性の広さと、弊社 BX 本部における取り組みを簡単にご紹介します。

Dify v1.0 のリリースにより、チャットフローやワークフローにエージェントノードが登場し、 MCP Agent Strategy を採⽤することで MCP との連携が容易になりました。また、Function Calling Agent を利⽤することで、⼩難しい条件分岐やイテレーション処理を使わずとも、⾃然⾔語だけで AI エージェントの実装が可能となりました。

これは⾮常に⼤きな進歩であり、コア業務の⼿順・思考のフレームワークなどを体系化・標準化できるリーダークラスの⼈材であれば、コア業務に適⽤可能な優れた AI エージェントをかなり簡単に作れるようになったことを意味します。

不⾜している機能がある場合にのみ、エンジニアが MCP サーバーや独⾃プラグインを開発することで、ほとんどの業務に適⽤可能なエージェントを業務ユーザーが独⾃に作ることができます。

さらに、Dify アプリケーションは "ツールとしてのワークフロー" 公開または API 経由で他の Dify アプリケーションをコール可能であるため、以下のような事までできてしまいます。

• AI エージェントを責務に応じて分割し、互いに作業を委譲することで、多層構造を持つ⾼度な AI エージェントを (エンジニアでなくても) 作れてしまう
• AWS 連携の独⾃のプラグインを開発することで、Dify アプリケーション間でイベントドリブンでコールする仕組みを容易に作れるため、リテラシーとモチベーションの⾼い業務ユーザーであれば、マルチエージェントまでも実装できてしまう (*エンジニアが仕組みを作る必要あり。また、無限ループに注意が必要)
  

⼀⽅で、業務を知り尽くしたリーダークラスのメンバーを AI エージェント開発にアサインするのは難しいケースもあります。しかし、エンジニアが全て開発していては本システム導⼊のコンセプトに反しますし、エンジニアでは良いプロンプトはそもそも書けません。本当に価値のある AI エージェントは、業務ユーザーだけが開発できる、と考えています。 そこで弊社 BX 本部では、以下のアプローチで開発を推進しており、コア業務に適⽤可能な、本当に意義のある AI エージェントの開発・利活⽤を今後も模索・推進していく予定です。

• 草の根運動として、トレーニングやマニュアルの充実を図り、セルフサービスでの開発を促す

• Dify オフィスアワーを⾼頻度で開催し、利⽤者の悩みを⾼速で解決する仕組みを運⽤する

• Dify を⽤いた AI エージェント開発コンテストを開催し、誰もがエージェントを作った成功体験をつくり、それを通して定着・理解の促進を図る

• 特に重要でインパクトの⼤きい業務について⼀時的にエンジニアを増員し、業務コアメンバーとタッグを組み、AI エージェント開発のお⼿本として使えるものを作り展開し、コア 業務で本当に役に⽴つ AI エージェントの作り⽅を学ぶ機会を提供し、成功体験を積んでもらう

本稿では、弊社 BX 本部における Dify on AWS の導⼊・運⽤事例、そして Dify による AI エージェントのセルフサービス開発の可能性の広がりについてご紹介しました。やや複雑に⾒えるかもしれませんが、⾃部⾨だけでシングルテナントでクイックに利⽤するだけであれば、AWS 上へのデプロイはそれほど難しくありません。セルフサービス型アプローチでの AI エージェント開発・利活⽤にご興味のある⽅は、ぜひチャレンジして頂きたいです。

本件は、AWS で弊社を担当していただいているテクニカルアカウントマネージャーの方とは⻑きに渡り定期的な情報共有・議論のミーティングを設けていただき、⼿厚いサポートをいただけたことでここまで取り組むことができました。この場をお借りして改めてお礼を申し上げます。

今後の展望ですが、既述の通り、業務のコアで本当に価値のある AI エージェントの開発・活⽤を引き続き推進しつつ、進化をキャッチアップし続け、Dify に限らず、新しい要素・技術を本統合業務効率化システムに継続的に取り込み、進化を続けていきます。