License 管理実務 – アクティベーション・更新・監視・コンプライアンスの運用ガイド

Dify Enterprise の License 管理は、導入時に一度アクティベーションすれば終わりではない。有効期限の監視、更新手続き、複数インスタンスへの配分、namespace 変更時の対応 – これらは継続的な運用タスクとして SOP（標準作業手順）に組み込む必要がある。

公式ドキュメントから確認できる重要な事実として、License は Kubernetes cluster の namespace に紐づく。つまり License 管理はインフラ運用の一部であり、単なる管理画面のクリック操作ではない。

1. License の基本構造

1.1 License とデプロイ環境の関係

graph TB
    subgraph "Dify Enterprise License"
        L[License ID: DIFY-ENT-xxxx]
    end
    subgraph "Kubernetes Cluster"
        subgraph "namespace: dify-production"
            A[dify-enterprise Pod]
            B[dify-api Pod]
            C[dify-worker Pod]
        end
    end
    L -->|bound to namespace| A
    A -->|License 検証| B
    A -->|License 検証| C

1.2 主要な制約事項

1.3 オンラインモード vs オフラインモード

2. アクティベーション手順

2.1 オンラインアクティベーション

# 1. values.yaml で License モードを確認
enterprise:
  enabled: true
  licenseMode: "online"

# 2. Helm デプロイ（または既存環境の場合は upgrade）
helm upgrade -i dify dify/dify \
  -n dify-production \
  -f values.yaml \
  --wait

# 3. Enterprise 管理コンソールにアクセス
#    https://enterprise.dify.example.co.jp
#    → License 画面で License キーを入力

# 4. アクティベーション成功を確認
kubectl get pods -n dify-production -l app=dify-enterprise
# STATUS が Running であること

2.2 オフラインアクティベーション

# 1. values.yaml で License モードをオフラインに変更
enterprise:
  enabled: true
  licenseMode: "offline"

# 2. Helm デプロイ
helm upgrade -i dify dify/dify \
  -n dify-production \
  -f values.yaml \
  --wait

# 3. License ファイルの配置
#    公式ドキュメントの手順に従い、License ファイルを
#    所定のパスに配置する

# 4. Enterprise Pod を再起動
kubectl rollout restart deployment/dify-enterprise -n dify-production

# 5. 起動確認
kubectl rollout status deployment/dify-enterprise -n dify-production

2.3 アクティベーション後の確認チェックリスト

• Enterprise 管理コンソールにログインできる
• License 情報（有効期限・プラン内容）が正しく表示される
• API / Worker / Web の各 Pod が正常に Running 状態
• アプリケーションの作成・実行が正常に動作する
• License 情報をスクリーンショットまたはテキストで台帳に記録する

3. License 台帳管理

3.1 管理すべき 3 つの台帳

エンタープライズ運用では、以下の 3 つの台帳を整備する。

台帳 1: License 基本情報

台帳 2: インスタンス情報

台帳 3: 更新・操作履歴

4. 有効期限の監視

4.1 多段階アラートの設計

License の期限切れは Dify Enterprise の全機能停止に直結するため、十分な猶予を持って対応する。

gantt
    title License 有効期限アラートスケジュール
    dateFormat  YYYY-MM-DD
    section アラート
    90日前通知 (更新交渉開始)   :milestone, m1, 2026-10-15, 0d
    60日前通知 (契約締結目標)   :milestone, m2, 2026-11-14, 0d
    30日前通知 (技術準備完了)   :milestone, m3, 2026-12-15, 0d
    14日前通知 (最終確認)       :milestone, m4, 2026-12-31, 0d
    7日前通知 (緊急対応)        :milestone, m5, 2027-01-07, 0d
    期限満了                    :milestone, m6, 2027-01-14, 0d

4.2 自動監視の実装方針

自動監視は以下の方法で実装できる。

• シェルスクリプト + cron: Enterprise Pod から License 有効期限を取得し、残日数に応じて Slack / メールで通知するスクリプトを日次実行
• Prometheus + AlertManager: License 残日数をメトリクスとして公開し、PrometheusRule でアラートを定義

4.3 Prometheus によるメトリクス監視

# PrometheusRule 例
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: dify-license-alerts
  namespace: monitoring
spec:
  groups:
    - name: dify-license
      rules:
        - alert: DifyLicenseExpiringSoon
          expr: dify_license_days_remaining < 30
          for: 1h
          labels:
            severity: warning
          annotations:
            summary: "Dify License の有効期限が 30 日以内です"
            description: "残り {{ $value }} 日です。更新手続きを確認してください。"
        - alert: DifyLicenseExpiryCritical
          expr: dify_license_days_remaining < 7
          for: 1h
          labels:
            severity: critical
          annotations:
            summary: "Dify License の有効期限が 7 日以内です"
            description: "残り {{ $value }} 日です。至急更新してください。"

5. License 更新手順

5.1 更新フロー

sequenceDiagram
    participant PM as 購買担当
    participant Dify as Dify Sales
    participant IT as 情報システム部
    participant K8s as Kubernetes Cluster
    
    PM->>Dify: 更新見積もり依頼 (90日前)
    Dify->>PM: 見積もり提出
    PM->>PM: 社内承認プロセス
    PM->>Dify: 発注 (60日前)
    Dify->>IT: 新 License キー送付
    IT->>IT: ステージング環境で検証 (30日前)
    IT->>K8s: 本番 License 更新 (14日前)
    K8s->>K8s: enterprise Pod 再起動
    IT->>IT: 動作確認・台帳更新

5.2 更新の実施手順（共通）

# 1. ステージング環境で事前検証（新 License キーまたはファイルを適用）

# 2. 本番環境で License 更新
#    オンライン: 管理コンソールから新しい License キーを入力
#    オフライン: 新しい License ファイルを配置

# 3. enterprise Pod を再起動（更新反映のため必須）
kubectl rollout restart deployment/dify-enterprise -n dify-production
kubectl rollout status deployment/dify-enterprise -n dify-production --timeout=300s

# 4. 動作確認
curl -s https://enterprise.dify.example.co.jp/api/health | jq .
# 管理コンソールで新しい有効期限が反映されていることを確認

6. 複数インスタンスの License 配分

6.1 環境別の配分戦略

企業が複数の Dify Enterprise インスタンスを運用する場合、License の配分方針を明確にする。

6.2 namespace 変更時の注意事項

License は namespace に紐づくため、以下の場合は再アクティベーションが必要となる。

• namespace 名を変更した場合
• 別のクラスタに移行した場合
• DR 用クラスタにフェイルオーバーした場合

# namespace 変更時の対応手順
# 1. 新 namespace にデプロイ
helm upgrade -i dify dify/dify \
  -n dify-production-v2 \
  -f values.yaml \
  --wait

# 2. 再アクティベーション
#    管理コンソールから License キーを再入力
#    オフラインの場合は License ファイルを再配置

# 3. 旧 namespace のクリーンアップ
kubectl delete namespace dify-production-old

6.3 DR（災害復旧）環境での License

DR 環境では、DR 用 License の要否確認、フェイルオーバー時の再アクティベーション手順の文書化、オフライン環境への License ファイル事前配置を行っておく。復旧訓練時に License アクティベーションも含めて検証すること。

7. コンプライアンスと内部統制

7.1 License 関連の統制ポイント

7.2 監査対応

内部監査や外部監査（J-SOX 等）に備え、License 台帳・更新承認フロー文書・作業記録・有効期限監視ログ・是正手順を整備しておく。

8. よくある問題と対処

9. まとめ

License 管理を確実に運用するための 5 つの原則を以下にまとめる。

1. 台帳を整備する: License 基本情報・インスタンス情報・操作履歴の 3 つの台帳を作成し、最新状態を維持する
2. 多段階アラートを設定する: 90 / 60 / 30 / 14 / 7 日前の 5 段階で通知し、余裕を持って更新手続きを進める
3. 更新手順を SOP 化する: ステージング検証 → 本番更新 → 動作確認 → 台帳更新のフローを標準化する
4. namespace との紐づきを意識する: 移行・DR・namespace 変更時には再アクティベーションが必要であることを常に念頭に置く
5. コンプライアンスを担保する: 棚卸し・利用状況レビュー・証跡保管を定期的に実施し、監査に備える

License は Dify Enterprise の「動作の前提条件」である。ここが途切れればすべてのサービスが停止する。だからこそ、License 管理をインフラ運用 SOP の一級項目として位置づけることが重要である。