Dify を macOS でローカル検証:Docker Compose で最短起動する手順

AI アプリケーション開発の現場では、本番環境にデプロイする前にローカル環境で動作を検証することが欠かせません。特に Dify のような LLM アプリケーション開発プラットフォームでは、API の動作確認やワークフローのテストをローカルで行うことで、開発サイクルを大幅に短縮できます。
本記事では、macOS 環境で Dify を Docker Compose を使って最短で起動する手順を、初心者の方にもわかりやすく解説します。実際のコマンド例やトラブルシューティングも含めて、スムーズに環境構築できるようガイドしますね。
Dify とは
Dify の概要
Dify は、LLM(Large Language Model)アプリケーションを開発するためのオープンソースプラットフォームです。ChatGPT や Claude などの AI モデルを活用したアプリケーションを、ノーコード・ローコードで構築できる点が大きな特徴でしょう。
以下の図は、Dify の基本的なアーキテクチャを示しています。
mermaidflowchart TB
user["開発者"]
dify["Dify プラットフォーム"]
llm["LLM<br/>(OpenAI/Claude など)"]
db[("PostgreSQL<br/>データベース")]
redis[("Redis<br/>キャッシュ")]
user -->|ブラウザアクセス| dify
dify -->|API 呼び出し| llm
dify -->|データ保存| db
dify -->|セッション管理| redis
llm -->|応答| dify
dify -->|結果表示| user
主な機能は以下の通りです。
# | 機能 | 説明 |
---|---|---|
1 | ビジュアルワークフローエディタ | ドラッグ&ドロップで AI ワークフローを構築 |
2 | プロンプト管理 | バージョン管理可能なプロンプトテンプレート |
3 | RAG(検索拡張生成) | 独自データを活用した回答生成 |
4 | API エンドポイント | 作成したアプリを API として公開 |
5 | マルチモデル対応 | OpenAI、Claude、Azure OpenAI など複数の LLM に対応 |
Dify を使うことで、プロンプトエンジニアリングやベクトルデータベースの構築といった複雑な作業を、GUI 上で直感的に行えます。
ローカル環境で検証するメリット
Dify はクラウド版も提供されていますが、ローカル環境での検証には以下のようなメリットがあるんです。
開発効率の向上
ローカル環境では、コードの変更やプロンプトの調整を即座に反映できます。クラウド環境へのデプロイを待つ必要がないため、試行錯誤のサイクルが格段に速くなるでしょう。
コスト削減
開発段階での API 呼び出しやリソース使用料を抑えられます。特に LLM の API は従量課金制のため、テスト段階でのコスト管理は重要ですね。
データプライバシーの保護
機密性の高いデータや顧客情報を扱う場合、ローカル環境であればデータが外部に送信されません。GDPR や個人情報保護法への対応も容易になります。
オフライン開発の実現
インターネット接続が不安定な環境でも開発を継続できます。移動中や出張先でも作業を進められるのは大きな利点でしょう。
カスタマイズの自由度
ソースコードの修正やプラグインの追加など、プラットフォームのカスタマイズを自由に試せます。本番環境に影響を与えることなく実験できるんです。
事前準備
必要な環境
Dify を macOS でローカル起動するには、以下の環境が必要です。
# | 項目 | 最小要件 | 推奨要件 |
---|---|---|---|
1 | macOS バージョン | macOS 10.15 (Catalina) 以上 | macOS 13 (Ventura) 以上 |
2 | CPU | Intel または Apple Silicon | Apple Silicon (M1/M2/M3) |
3 | メモリ | 8GB | 16GB 以上 |
4 | ディスク空き容量 | 10GB | 20GB 以上 |
5 | Docker Desktop | 4.0 以上 | 最新版 |
6 | Git | 2.0 以上 | 最新版 |
メモリは Docker コンテナが複数起動するため、16GB あると快適に動作します。8GB でも起動は可能ですが、他のアプリケーションを閉じることをお勧めしますね。
以下のコマンドで、現在の macOS バージョンを確認できます。
bash# macOS バージョンの確認
sw_vers
実行結果の例です。
bashProductName: macOS
ProductVersion: 14.0
BuildVersion: 23A344
Docker Desktop for Mac のインストール
Docker Desktop は、Docker コンテナを macOS 上で実行するための公式ツールです。Dify はマイクロサービスアーキテクチャで構成されており、複数のコンテナを Docker Compose で管理します。
Docker Desktop のダウンロード
Docker 公式サイトから、お使いの Mac のチップに合わせたインストーラをダウンロードしてください。
- Intel チップの Mac: Docker Desktop for Mac with Intel chip
- Apple Silicon の Mac: Docker Desktop for Mac with Apple chip
お使いの Mac のチップは、以下のコマンドで確認できます。
bash# CPU アーキテクチャの確認
uname -m
x86_64
と表示されたら Intel チップ、arm64
と表示されたら Apple Silicon です。
インストール手順
ダウンロードした DMG ファイルを開き、Docker.app を Applications フォルダにドラッグ&ドロップします。
bash# アプリケーションフォルダから Docker を起動
open /Applications/Docker.app
初回起動時は、Docker Desktop が特権アクセスを要求します。macOS のパスワードを入力して許可してください。
インストール確認
Docker Desktop が起動したら、ターミナルで以下のコマンドを実行して正しくインストールされているか確認しましょう。
bash# Docker のバージョン確認
docker --version
bash# Docker Compose のバージョン確認
docker compose version
以下のような出力が表示されれば、インストールは成功です。
bashDocker version 24.0.6, build ed223bc
Docker Compose version v2.23.0
Docker Desktop の設定
メニューバーの Docker アイコンから「Preferences」を開き、Resources タブで以下の設定を確認します。
# | 設定項目 | 推奨値 | 説明 |
---|---|---|---|
1 | CPUs | 4 | Dify の複数コンテナに割り当てる CPU コア数 |
2 | Memory | 8GB | コンテナに割り当てるメモリ容量 |
3 | Swap | 2GB | メモリ不足時に使用するスワップ領域 |
4 | Disk image size | 60GB | Docker イメージとコンテナデータの保存領域 |
設定を変更したら「Apply & Restart」をクリックして Docker を再起動してください。
Git のインストール確認
Git は Dify のソースコードをクローンするために必要です。macOS には Xcode Command Line Tools に Git が含まれているため、多くの場合すでにインストールされています。
以下のコマンドで Git がインストールされているか確認しましょう。
bash# Git のバージョン確認
git --version
Git がインストールされていれば、以下のような出力が表示されます。
bashgit version 2.39.2 (Apple Git-143)
もし「command not found」というエラーが表示された場合は、以下のコマンドで Xcode Command Line Tools をインストールしてください。
bash# Xcode Command Line Tools のインストール
xcode-select --install
ダイアログが表示されるので、「インストール」をクリックします。インストールには数分かかる場合がありますので、完了を待ちましょう。
インストール後、再度 git --version
を実行して確認してください。
Docker Compose での起動手順
Dify リポジトリのクローン
Dify の公式 GitHub リポジトリから、ソースコードをローカルにクローンします。作業ディレクトリは任意の場所で構いませんが、ここではホームディレクトリ配下に projects
フォルダを作成する例を示しますね。
bash# プロジェクト用ディレクトリの作成
mkdir -p ~/projects
cd ~/projects
次に、Dify のリポジトリをクローンします。
bash# Dify リポジトリのクローン
git clone https://github.com/langgenius/dify.git
クローンが完了したら、dify ディレクトリに移動しましょう。
bash# dify ディレクトリへ移動
cd dify
ディレクトリ構造を確認すると、以下のようなファイルやフォルダが含まれています。
bash# ディレクトリ構造の確認
ls -la
主要なファイルとフォルダは以下の通りです。
# | 名前 | 種類 | 説明 |
---|---|---|---|
1 | docker | フォルダ | Docker 関連の設定ファイル |
2 | api | フォルダ | バックエンド API のソースコード |
3 | web | フォルダ | フロントエンド UI のソースコード |
4 | docker-compose.yaml | ファイル | Docker Compose の設定ファイル |
5 | .env.example | ファイル | 環境変数のサンプルファイル |
docker-compose.yaml の確認
docker-compose.yaml
は、Dify を構成する複数のサービス(コンテナ)を定義するファイルです。内容を確認してみましょう。
bash# docker-compose.yaml の内容確認
cat docker-compose.yaml
このファイルには、以下のサービスが定義されています。
以下の図は、Docker Compose で起動される各サービスの関係性を示しています。
mermaidflowchart TB
subgraph frontend["フロントエンド層"]
nginx["nginx<br/>(リバースプロキシ)"]
web["web<br/>(Next.js UI)"]
end
subgraph backend["バックエンド層"]
api["api<br/>(Flask API)"]
worker["worker<br/>(Celery Worker)"]
end
subgraph data["データ層"]
postgres[("db<br/>(PostgreSQL)")]
redis[("redis<br/>(Redis)")]
weaviate[("weaviate<br/>(ベクトル DB)")]
end
nginx --> web
nginx --> api
api --> postgres
api --> redis
api --> weaviate
worker --> redis
worker --> postgres
# | サービス名 | 役割 | ポート |
---|---|---|---|
1 | db | PostgreSQL データベース | 5432 |
2 | redis | キャッシュとメッセージキュー | 6379 |
3 | weaviate | ベクトルデータベース(RAG 用) | 8080 |
4 | api | Flask ベースのバックエンド API | 5001 |
5 | worker | Celery ベースの非同期ワーカー | - |
6 | web | Next.js ベースのフロントエンド | 3000 |
7 | nginx | リバースプロキシ | 80 |
通常は、この docker-compose.yaml
をそのまま使用できます。ただし、ポート番号を変更したい場合は、後述の設定で調整可能です。
環境変数の設定
Dify の動作には、API キーやデータベース接続情報などの環境変数が必要です。リポジトリには .env.example
というサンプルファイルが含まれているので、これをコピーして .env
ファイルを作成します。
bash# .env.example を .env にコピー
cp .env.example .env
.env
ファイルを任意のテキストエディタで開いて、必要な設定を行いましょう。
bash# .env ファイルを編集(例: nano エディタを使用)
nano .env
最低限必要な設定項目は以下の通りです。
必須設定項目
bash# アプリケーションのシークレットキー(ランダムな文字列を設定)
SECRET_KEY=your-secret-key-here
# データベース設定(デフォルトのままで OK)
DB_USERNAME=postgres
DB_PASSWORD=difyai123456
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify
# Redis 設定(デフォルトのままで OK)
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=difyai123456
SECRET_KEY
は、セッション管理や暗号化に使用される重要な値です。以下のコマンドでランダムな文字列を生成できます。
bash# ランダムな SECRET_KEY の生成
openssl rand -base64 32
生成された文字列を SECRET_KEY
の値として設定してください。
オプション設定項目
LLM プロバイダーの API キーを設定すると、すぐに AI 機能を利用できます。
bash# OpenAI API キー(OpenAI を使用する場合)
OPENAI_API_KEY=sk-your-openai-api-key
# Anthropic API キー(Claude を使用する場合)
ANTHROPIC_API_KEY=sk-ant-your-anthropic-api-key
API キーは後から Dify の管理画面でも設定できるため、初回起動時は省略しても構いません。
ファイルの編集が完了したら、保存して閉じましょう(nano の場合は Ctrl + X
、Y
、Enter
)。
コンテナの起動
環境変数の設定が完了したら、Docker Compose でコンテナを起動します。初回起動時は Docker イメージのダウンロードとビルドが行われるため、5〜10 分程度かかる場合がありますね。
bash# Docker Compose でコンテナを起動(デタッチモード)
docker compose up -d
-d
オプションは、コンテナをバックグラウンドで起動するためのオプションです。
起動中は以下のような出力が表示されます。
bash[+] Running 7/7
✔ Container dify-db Started
✔ Container dify-redis Started
✔ Container dify-weaviate Started
✔ Container dify-api Started
✔ Container dify-worker Started
✔ Container dify-web Started
✔ Container dify-nginx Started
すべてのコンテナが「Started」と表示されれば、起動は成功です。
起動状態の確認
以下のコマンドで、起動中のコンテナの状態を確認できます。
bash# コンテナの状態確認
docker compose ps
すべてのコンテナの STATE
列が Up
になっていれば正常です。
bashNAME IMAGE STATE
dify-api dify-api:latest Up
dify-db postgres:15-alpine Up
dify-nginx nginx:latest Up
dify-redis redis:6-alpine Up
dify-weaviate semitechnologies/weaviate:latest Up
dify-web dify-web:latest Up
dify-worker dify-api:latest Up
もし Exited
や Restarting
と表示されているコンテナがある場合は、ログを確認して原因を調べる必要があります。
bash# 特定のコンテナのログを確認(例: api コンテナ)
docker compose logs api
起動確認とアクセス方法
すべてのコンテナが正常に起動したら、ブラウザから Dify にアクセスしてみましょう。
ブラウザを開いて、以下の URL にアクセスしてください。
arduinohttp://localhost
または
arduinohttp://localhost:80
Dify のセットアップ画面が表示されれば、起動は成功です。
アクセスできない場合の確認ポイント
もし「接続できません」というエラーが表示される場合は、以下を確認してください。
- すべてのコンテナが起動しているか(
docker compose ps
で確認) - ポート 80 が他のアプリケーションで使用されていないか
- Docker Desktop が起動しているか
ポート 80 が使用されているか確認するには、以下のコマンドを実行します。
bash# ポート 80 を使用しているプロセスの確認
lsof -i :80
何も表示されなければ、ポート 80 は空いています。
API の動作確認
API が正常に動作しているか、以下のコマンドで確認できます。
bash# API のヘルスチェック
curl http://localhost/api/health
{"status": "ok"}
というレスポンスが返ってくれば、API は正常に動作しています。
初期設定
管理画面へのアクセス
ブラウザで http://localhost
にアクセスすると、Dify の初回セットアップ画面が表示されます。この画面で管理者アカウントを作成しましょう。
セットアップ画面には、以下の入力フィールドがあります。
# | 項目 | 説明 | 例 |
---|---|---|---|
1 | 管理者のメールアドレス | admin@example.com | |
2 | Password | 管理者のパスワード(8 文字以上) | SecurePass123! |
3 | Name | 管理者の表示名 | Admin User |
4 | Company | 会社名(任意) | My Company |
すべての項目を入力したら、「Continue」ボタンをクリックしてください。
初回ログイン設定
アカウント作成が完了すると、自動的にログインされ、ワークスペース作成画面が表示されます。
ワークスペースの作成
ワークスペースは、アプリケーションやデータを管理する単位です。以下の情報を入力しましょう。
bash# ワークスペース名の例
Workspace Name: Development
ワークスペース名は後から変更できるので、まずは「Development」や「Test」など、わかりやすい名前で構いません。
「Create Workspace」をクリックすると、Dify のダッシュボードが表示されます。
基本設定の確認
ダッシュボードが表示されたら、基本的な設定を確認しておきましょう。
LLM プロバイダーの設定
画面右上のアカウントアイコンをクリックし、「Settings」→「Model Providers」を選択します。
ここで、使用したい LLM プロバイダーの API キーを設定できます。OpenAI を使用する場合の設定例です。
# | 項目 | 値 |
---|---|---|
1 | Provider | OpenAI |
2 | API Key | sk-your-openai-api-key |
3 | Organization ID | (任意) |
API キーを入力したら、「Save」をクリックしてください。
言語設定の変更
Dify のインターフェースは日本語にも対応しています。言語を変更するには、画面右上のアカウントアイコンから「Settings」→「Account」を選択し、「Language」で「日本語」を選択します。
設定を保存すると、インターフェースが日本語表示に切り替わるんです。
データ保存場所の確認
Dify が作成するデータ(アプリケーション設定、会話履歴など)は、PostgreSQL データベースに保存されます。データの保存場所は以下のコマンドで確認できます。
bash# Docker ボリュームの確認
docker volume ls
dify_postgres_data
という名前のボリュームがデータの保存場所です。このボリュームは、コンテナを削除しても保持されるため、データが失われる心配はありません。
動作確認
サンプルアプリの作成
Dify が正常に動作しているか、簡単なチャットボットアプリを作成して確認してみましょう。
ダッシュボードで「Create new app」ボタンをクリックします。
アプリタイプの選択
以下のアプリタイプから選択できます。
# | タイプ | 説明 | 用途 |
---|---|---|---|
1 | Chatbot | 対話型チャットボット | カスタマーサポート、FAQ 応答 |
2 | Text Generator | テキスト生成アプリ | 文章作成、要約、翻訳 |
3 | Agent | 自律的なエージェント | タスク実行、ツール連携 |
ここでは「Chatbot」を選択して、「Create」をクリックします。
基本設定
アプリ作成画面が表示されたら、以下の項目を設定しましょう。
bash# アプリ名の設定
App Name: Test Chatbot
bash# 説明の設定(任意)
Description: ローカル環境での動作確認用チャットボット
プロンプトの設定
「Prompt」セクションで、チャットボットの振る舞いを定義します。以下のような簡単なプロンプトで構いません。
あなたは親切なアシスタントです。ユーザーの質問に丁寧に答えてください。
モデルの選択
「Model」セクションで、使用する LLM モデルを選択します。先ほど設定した OpenAI の API キーを使用する場合は、「OpenAI」→「gpt-3.5-turbo」を選択しましょう。
# | 設定項目 | 推奨値 | 説明 |
---|---|---|---|
1 | Model | gpt-3.5-turbo | コストパフォーマンスに優れたモデル |
2 | Temperature | 0.7 | 回答の創造性(0-1、低いほど一貫性重視) |
3 | Max Tokens | 1000 | 1 回の応答の最大トークン数 |
設定が完了したら、画面右上の「Publish」ボタンをクリックしてアプリを公開します。
テスト実行
公開が完了すると、画面右側にチャットインターフェースが表示されます。試しにメッセージを送信してみましょう。
こんにちは。Dify について教えてください。
AI から適切な回答が返ってくれば、アプリは正常に動作しています。
API の動作テスト
作成したアプリは、API としても利用できます。API の動作を確認してみましょう。
API キーの取得
アプリの詳細画面で、「API Access」タブをクリックします。「API Key」セクションに表示されているキーをコピーしてください。
API キーの形式は以下のようになります。
app-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
API リクエストの送信
ターミナルから、以下の curl コマンドで API にリクエストを送信します。
bash# API エンドポイントへリクエスト送信
curl -X POST http://localhost/v1/chat-messages \
-H "Authorization: Bearer app-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"inputs": {},
"query": "こんにちは",
"response_mode": "blocking",
"user": "test-user"
}'
app-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
の部分は、先ほどコピーした実際の API キーに置き換えてください。
レスポンスの確認
リクエストが成功すると、以下のような JSON レスポンスが返ってきます。
json{
"event": "message",
"message_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"conversation_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"mode": "chat",
"answer": "こんにちは!Difyについてご説明しますね。Difyは...",
"metadata": {
"usage": {
"prompt_tokens": 25,
"completion_tokens": 150,
"total_tokens": 175
}
}
}
answer
フィールドに AI の応答が含まれていれば、API は正常に動作しています。
ストリーミングモードのテスト
response_mode
を streaming
に変更すると、リアルタイムでレスポンスを受信できます。
bash# ストリーミングモードでリクエスト
curl -X POST http://localhost/v1/chat-messages \
-H "Authorization: Bearer app-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"inputs": {},
"query": "Difyの主な機能を3つ教えてください",
"response_mode": "streaming",
"user": "test-user"
}'
ストリーミングモードでは、Server-Sent Events (SSE) 形式でレスポンスが返されます。
トラブルシューティング
ポート競合エラーの解決
Docker Compose でコンテナを起動する際、「port is already allocated」というエラーが表示されることがあります。これは、Dify が使用しようとしているポートが、すでに他のアプリケーションで使用されている場合に発生するんです。
エラーメッセージの例
bashError response from daemon: driver failed programming external connectivity on endpoint dify-nginx:
Bind for 0.0.0.0:80 failed: port is already allocated
このエラーは、ポート 80 が既に使用されていることを示しています。
使用中のポートの確認
どのプロセスがポートを使用しているか確認しましょう。
bash# ポート 80 を使用しているプロセスの確認
lsof -i :80
以下のような出力が表示されます。
bashCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 1234 user 6u IPv4 0x... 0t0 TCP *:http (LISTEN)
この例では、nginx がポート 80 を使用しています。
解決方法 1:競合するプロセスの停止
競合しているプロセスが不要な場合は、停止します。
bash# プロセス ID を指定して停止(上記の例では PID 1234)
sudo kill 1234
Apache や nginx などの Web サーバーが起動している場合は、以下のコマンドで停止できます。
bash# Apache の停止(macOS の場合)
sudo apachectl stop
bash# Homebrew でインストールした nginx の停止
brew services stop nginx
解決方法 2:Dify のポート番号変更
競合するプロセスを停止できない場合は、Dify が使用するポート番号を変更します。
docker-compose.yaml
ファイルを開いて、nginx サービスのポート設定を変更しましょう。
yaml# 変更前
services:
nginx:
ports:
- '80:80'
yaml# 変更後(ポート 8080 を使用)
services:
nginx:
ports:
- '8080:80'
この変更により、Dify には http://localhost:8080
でアクセスするようになります。
ファイルを保存したら、コンテナを再起動してください。
bash# コンテナの停止と再起動
docker compose down
docker compose up -d
コンテナ起動エラーの対処
特定のコンテナが起動しない、または繰り返し再起動される場合の対処法です。
エラー診断:ログの確認
まず、問題が発生しているコンテナのログを確認します。
bash# 全コンテナのログを表示
docker compose logs
特定のコンテナのログのみを表示する場合は、サービス名を指定します。
bash# api コンテナのログを表示
docker compose logs api
bash# データベースコンテナのログを表示
docker compose logs db
よくあるエラー 1:データベース接続エラー
vbnetError: could not connect to server: Connection refused
Is the server running on host "db" (xxx.xxx.xxx.xxx) and accepting TCP/IP connections on port 5432?
このエラーは、API コンテナがデータベースに接続できない場合に発生します。
原因と解決方法は以下の通りです。
# | 原因 | 解決方法 |
---|---|---|
1 | データベースコンテナが起動していない | docker compose ps で db コンテナの状態を確認し、停止していれば docker compose up -d db で起動 |
2 | .env ファイルのデータベース設定が誤っている | DB_HOST が "db"、DB_PORT が "5432" になっているか確認 |
3 | データベースの初期化が完了していない | db コンテナのログで初期化完了メッセージを待つ(30 秒〜1 分程度) |
よくあるエラー 2:Redis 接続エラー
vbnetError: Error 111 connecting to redis:6379. Connection refused.
Redis への接続に失敗している場合のエラーです。
bash# Redis コンテナの状態確認
docker compose ps redis
Redis コンテナが起動していない場合は、再起動します。
bash# Redis コンテナの再起動
docker compose restart redis
よくあるエラー 3:パーミッションエラー
vbnetERROR: failed to open stream: Permission denied
Docker のボリュームに対する権限がない場合に発生します。
bash# Docker Desktop の再起動で解決することが多い
docker compose down
# Docker Desktop を完全に終了して再起動
docker compose up -d
完全なリセット
上記の方法で解決しない場合は、すべてのコンテナとボリュームを削除して再構築します。
bash# すべてのコンテナとボリュームを削除
docker compose down -v
bash# イメージの再ビルドと起動
docker compose up -d --build
注意:-v
オプションを使用すると、データベースのデータも削除されます。重要なデータがある場合は、事前にバックアップを取ってくださいね。
メモリ不足エラーへの対応
macOS でメモリが不足すると、コンテナが予期せず停止したり、動作が極端に遅くなったりします。
症状の確認
以下のような症状が見られる場合、メモリ不足の可能性があります。
- コンテナが突然停止する(
docker compose ps
で Exited と表示される) - API のレスポンスが極端に遅い
- Docker Desktop のダッシュボードでメモリ使用率が 90% 以上
メモリ使用状況の確認
Docker コンテナのメモリ使用状況を確認しましょう。
bash# コンテナごとのリソース使用状況を表示
docker stats
以下のような出力が表示されます。
bashCONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM %
abc123 dify-api 5.23% 512MiB / 8GiB 6.25%
def456 dify-db 2.15% 256MiB / 8GiB 3.13%
ghi789 dify-weaviate 8.45% 1.5GiB / 8GiB 18.75%
解決方法 1:Docker Desktop のメモリ割り当て増加
Docker Desktop の設定で、割り当てメモリを増やします。
メニューバーの Docker アイコン → Preferences → Resources → Memory で、スライダーを調整してください。
メモリ容量 | 推奨設定 |
---|---|
8GB | 6GB を Docker に割り当て |
16GB | 8-10GB を Docker に割り当て |
32GB 以上 | 12-16GB を Docker に割り当て |
設定を変更したら「Apply & Restart」をクリックします。
解決方法 2:不要なコンテナの停止
Dify 以外の Docker コンテナが起動している場合は、停止してメモリを解放しましょう。
bash# 起動中のすべてのコンテナを表示
docker ps
bash# 特定のコンテナを停止(コンテナ名または ID を指定)
docker stop container_name
解決方法 3:macOS の他のアプリケーションを閉じる
Docker Desktop は macOS 全体のメモリを使用するため、Chrome や IDE などメモリを大量に消費するアプリケーションを閉じることで改善する場合があります。
Activity Monitor(アクティビティモニタ)を開いて、メモリ使用量の多いアプリケーションを確認してください。
bash# Activity Monitor の起動
open -a "Activity Monitor"
解決方法 4:Weaviate を無効化
RAG 機能を使用しない場合は、ベクトルデータベースの Weaviate を無効化してメモリを節約できます。
docker-compose.yaml
を編集して、weaviate サービスをコメントアウトします。
yaml# services:
# weaviate:
# image: semitechnologies/weaviate:latest
# ...(以下省略)
ただし、この場合 RAG(検索拡張生成)機能は使用できなくなりますので、ご注意くださいね。
まとめ
本記事では、macOS 環境で Dify を Docker Compose を使ってローカル起動する手順を解説しました。
最後に、要点を振り返っておきましょう。
起動までの主要ステップ
- Docker Desktop と Git のインストール
- Dify リポジトリのクローン
.env
ファイルの作成と環境変数の設定docker compose up -d
でコンテナ起動http://localhost
にアクセスして初期設定
重要なポイント
- Docker Desktop には最低 8GB、推奨 10GB 以上のメモリを割り当てる
SECRET_KEY
は必ず独自の値に変更する- LLM の API キーは後から設定可能なので、初回起動時は省略可
- ポート競合が発生した場合は、
docker-compose.yaml
でポート番号を変更
トラブル発生時の基本対応
docker compose logs
でログを確認docker compose ps
でコンテナの状態を確認- 問題が解決しない場合は
docker compose down -v
で完全リセット
Dify をローカル環境で動かすことで、本番デプロイ前の検証やプロトタイプ開発を効率的に進められます。独自のデータを使った RAG アプリケーションや、複雑なワークフローの構築など、さまざまな実験を気軽に試せるのが魅力ですね。
ぜひローカル環境を活用して、Dify の機能を存分に体験してみてください。
関連リンク
- article
Dify を macOS でローカル検証:Docker Compose で最短起動する手順
- article
Dify と LangGraph/LangChain を比較:表現力・保守性・学習コストのリアル
- article
Dify でジョブが止まる/再実行される問題の原因切り分けガイド
- article
Dify の内部アーキテクチャ超図解:エージェント・ワークフロー・データストアの関係
- article
2025年 Dify コミュニティとエコシステムの最新動向
- article
Dify × GitHub Actions で DevOps 自動化
- article
Redis セットアップ完全版(macOS/Homebrew):設定テンプレ付き最短構築
- article
FFmpeg を macOS で最適導入:Homebrew +オプション選定で機能漏れゼロ
- article
Python を macOS で快適構築:pyenv + uv + Rye の最小ストレス環境
- article
ESLint を Yarn + TypeScript + React でゼロから構築:Flat Config 完全手順(macOS)
- article
Dify を macOS でローカル検証:Docker Compose で最短起動する手順
- article
Prisma vs Drizzle vs Kysely:DX・型安全性・最適化余地を実測比較
- blog
iPhone 17シリーズの発表!全モデルiPhone 16から進化したポイントを見やすく整理
- blog
Googleストアから訂正案内!Pixel 10ポイント有効期限「1年」表示は誤りだった
- blog
【2025年8月】Googleストア「ストアポイント」は1年表記はミス?2年ルールとの整合性を検証
- blog
Googleストアの注文キャンセルはなぜ起きる?Pixel 10購入前に知るべき注意点
- blog
Pixcel 10シリーズの発表!全モデル Pixcel 9 から進化したポイントを見やすく整理
- blog
フロントエンドエンジニアの成長戦略:コーチングで最速スキルアップする方法
- review
今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
- review
ついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
- review
愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
- review
週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
- review
新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
- review
科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来