Dify
日本語
日本語
  • 入門
    • Difyへようこそ
      • 特性と技術仕様
      • モデルプロバイダーリスト
    • クラウドサービス
    • コミュニティ版
      • Docker Compose デプロイ
      • ローカルソースコードで起動
      • aaPanelでのデプロイ方法
      • フロントエンドDockerコンテナを単独起動
      • 環境変数の説明
      • よくある質問
    • Dify Premium
    • Dify 教育版
  • マニュアル
    • モデル
      • 新しいプロバイダーの追加
      • 事前定義されたモデルの追加
      • カスタムモデルの追加
      • インタフェース
      • 配置ルール
      • 負荷分散
    • アプリ・オーケストレーション
      • アプリの作成
      • チャットボット
        • 複数モデルのデバッグ
      • エージェント
      • ツールキット
        • コンテンツモデレーション
    • ワークフロー
      • キーコンセプト
      • 変数
      • ノードの説明
        • 開始
        • 終了
        • 回答
        • LLM
        • 知識検索
        • 質問分類
        • 条件分岐
        • コード実行
        • テンプレート
        • テキスト抽出ツール
        • リスト処理
        • 変数集約
        • 変数代入
        • 反復処理(イテレーション)
        • パラメータ抽出
        • HTTPリクエスト
        • エージェント
        • ツール
        • 繰り返し処理(ループ)
      • ショートカットキー
      • オーケストレートノード
      • ファイルアップロード
      • エラー処理
        • 事前定義されたエラー処理ロジック
        • エラータイプの概要
      • 追加機能
      • プレビューとデバッグ
        • プレビューと実行
        • ステップ実行
        • 対話/実行ログ
        • チェックリスト
        • 実行履歴
      • アプリケーション公開
      • JSON形式での出力
      • 変更通知:画像アップロード機能がファイルアップロード機能に統合されました
    • ナレッジベース
      • ナレッジベース作成
        • 1. オンラインデータソースの活用
          • 1.1 Notion からデータをインポート
          • 1.2 Webサイトからデータをインポート
        • 2. チャンクモードの指定
        • 3. インデックス方式と検索オプションの設定
      • ナレッジベースの管理
        • ナレッジベース内ドキュメントの管理
        • APIを活用したナレッジベースのメンテナンス
      • メタデータ
      • アプリ内でのナレッジベース統合
      • リコールテスト/引用帰属
      • ナレッジベースの要求頻度制限
      • 外部ナレッジベースとの接続
      • 外部ナレッジベースAPI
    • ツール
      • クイック統合ツール
      • 高度統合ツール
      • ツールの設定
        • Google
        • Bing
        • SearchApi
        • StableDiffusion
        • Perplexity Search
        • AlphaVantage 株式分析
        • Dall-e
        • Youtube
        • Serper
        • SearXNG
        • SiliconFlow(Flux AI サポート)
        • ComfyUI
    • アプリ公開
      • シングルページWebアプリとして公開
        • Web アプリの設定
        • テキスト生成アプリ
        • 対話型アプリ
      • Webサイトへの埋め込み
      • API基づく開発
      • フロントエンドテンプレートに基づいた再開発
    • アノテーション
      • ログとアノテーション
      • アノテーション返信
    • モニタリング
      • データ分析
      • 外部Opsツール統合
        • LangSmithを統合
        • LangFuseを統合
        • Opikを統合
    • 拡張
      • API 拡張
        • Cloudflare Workers を使用した API ツールのデプロイ
        • コンテンツモデレーション
      • コード拡張
        • 外部データツール
        • コンテンツモデレーション
    • コラボレーション
      • 発見
      • メンバーの招待と管理
    • 管理
      • アプリの管理
      • チームメンバーの管理
      • 個人アカウントの管理
      • サブスクリプション管理
      • バージョン管理
  • ハンドオン工房
    • 初級編
      • ゼロからAI画像生成アプリの構築方法
      • AIエージェントの実践:個人のオンライン旅行アシスタントの構築方法
    • 中級編
      • チャットストリームエージェントを使用した Twitter アカウントの分析方法
      • ファイルアップロードを使用した記事理解アシスタントの構築方法
  • コミュニティ
    • サポートの求め
    • 貢献者ガイド
    • ドキュメントへの貢献
  • プラグイン
    • 機能紹介
    • クイックスタート
      • プラグインのインストールと活用
      • プラグイン開発の入門
        • 開発環境のセットアップ
        • ツール型プラグイン
        • モデル型プラグイン
          • モデルプロバイダーの構築
          • 定義済みモデルの組み込み
          • カスタムモデルの組み込み
        • エージェント戦略プラグイン
        • 拡張機能型プラグイン
        • バンドル
      • プラグインのデバッグ方法
    • プラグイン管理方法
    • スキーマ仕様
      • Manifest(マニフェスト)
      • Endpoint(エンドポイント)
      • Tool(ツール)
      • Agent(エージェント)
      • Model(モデル)
        • モデル設計規則
        • モデルスキーマ
      • 一般的な標準仕様
      • 永続化されたストレージ
      • Difyサービスの逆呼び出し
        • アプリ
        • モデル
        • ツール
        • ノード
    • ベストプラクティス
      • Slack Bot プラグインの開発
      • Dify MCP プラグインガイド:ワンクリックで Zapier に接続してメールを自動送信
    • プラグインの公開
      • プラグインの自動公開
      • Difyマーケットプレイスへの公開
        • プラグイン開発者ガイドライン
        • プラグインのプライバシー保護に関するガイドライン
      • 個人GitHubリポジトリへの公開
      • ローカルでの公開と共有
      • 第三者署名検証のためにプラグインに署名する
    • よくある質問
  • 開発
    • バックエンド
      • DifySandbox
        • 貢献ガイド
    • モデルの統合
      • Hugging Faceのオープンソースモデルを統合
      • Replicateのオープンソースモデルを統合
      • Xinferenceでデプロイしたローカルモデルを統合
      • OpenLLMでデプロイしたローカルモデルを統合
      • LocalAIでデプロイしたローカルモデルを統合
      • Ollamaでデプロイしたローカルモデルを統合
      • LiteLLM Proxyを使用してモデルを統合する
      • GPUStackとの統合によるローカルモデルのデプロイ
      • AWS Bedrock上のモデル(DeepSeek)の接続
    • 移行
      • コミュニティ版を v1.0.0 に移行する
  • もっと読む
    • 活用事例
      • DeepSeek & Dify連携ガイド:多段階推論を活用したAIアプリケーション構築
      • Ollama + DeepSeek + Dify のプライベートデプロイ:あなた自身のAIアシスタントの構築方法
      • あなた専用のQAチャットボットのトレーニング方法
      • コードなしでMidjourney プロンプトボットを作成する方法
      • Notion AI アシスタントを構築する
      • 数分で業務データを持つ公式サイトのAIチャットボットを作成する方法
      • DifyチャットボットをWixサイトに統合する方法
      • AWS Bedrockのナレッジベースに統合する方法
      • Difyで大規模言語モデルの「競技場」を体験する方法:DeepSeek R1 VS o1 を例に
      • Difyスケジューラーの構築
      • DifyクラウドでAI Thesis Slack Botを構築
    • さらに読む
      • LLMOpsとは何ですか?
      • 配列変数とは何ですか?
      • 検索拡張生成(RAG)
        • ハイブリッド検索
        • Rerank
        • リトリーバルモード
      • プロンプトエンジニアリング
      • DifyでJSONスキーマ出力を使用する方法
    • FAQ
      • ローカルデプロイに関するFAQ
      • LLM設定と使用に関するFAQ
      • プラグイン
  • ポリシー
    • オープンソースライセンス
    • ユーザ規約
      • 利用規約
      • プライバシーポリシー
      • 合規性レポートの入手方法
Powered by GitBook
On this page
  • 事前準備
  • 新規プロジェクトの作成
  • モデルプラグインテンプレートの選択
  • プラグイン権限の設定
  • モデルタイプ設定の説明
  • 新しいモデルプロバイダーの追加
  • 1. モデルプロバイダー設定ファイルの作成
  • 2. モデルプロバイダーコードの記述
  • カスタムモデルプロバイダー
  1. プラグイン
  2. クイックスタート
  3. プラグイン開発の入門
  4. モデル型プラグイン

モデルプロバイダーの構築

Previousモデル型プラグインNext定義済みモデルの組み込み

Last updated 2 months ago

Modelタイプのプラグインを作成する最初のステップは、プラグインプロジェクトを初期化し、モデルプロバイダーファイルを作成することです。その後、具体的な定義済みモデルやカスタムモデルを接続します。

事前準備

  • Difyプラグインのスキャフォールディングツール

  • Python環境(バージョン3.12以上)

プラグイン開発用のスキャフォールディングツールの準備方法については、を参照してください。

新規プロジェクトの作成

スキャフォールディングツールのコマンドラインから、新しいDifyプラグインプロジェクトを作成します。

./dify-plugin-darwin-arm64 plugin init

このバイナリファイルをdifyにリネームし、/usr/local/binにコピーした場合は、次のコマンドで新しいプラグインプロジェクトを作成できます。

dify plugin init

モデルプラグインテンプレートの選択

スキャフォールディングツール内のすべてのテンプレートには、必要なコードが全て含まれています。LLMタイプのプラグインテンプレートを選択してください。

プラグインタイプ: llm

プラグイン権限の設定

このLLMプラグインには、次の権限を設定します。

  • Models

  • LLM

  • Storage

モデルタイプ設定の説明

モデルプロバイダーは、以下の2つのモデル設定方法をサポートしています。

  • predefined-model 定義済みモデル

    一般的な大規模モデルタイプで、統一されたプロバイダー認証情報を設定するだけで、モデルプロバイダーが提供する定義済みモデルを利用できます。たとえば、OpenAIモデルプロバイダーは、gpt-3.5-turbo-0125やgpt-4o-2024-05-13など、様々な定義済みモデルを提供しています。詳細な開発手順については、定義済みモデルの接続を参照してください。

  • customizable-model カスタムモデル

    各モデルの認証情報設定を手動で追加する必要があります。たとえば、XinferenceはLLMとText Embeddingの両方をサポートしていますが、各モデルには一意のmodel_uidがあります。両方を同時に接続する場合は、各モデルにmodel_uidを設定する必要があります。詳細な開発手順については、カスタムモデルの接続を参照してください。

これら2つの設定方法は共存可能です。つまり、プロバイダーがpredefined-modelとcustomizable-modelの両方、またはpredefined-modelのみをサポートしている場合、プロバイダーの統一認証情報を設定することで、定義済みモデルとリモートから取得したモデルを使用できます。さらに、新しいモデルを追加した場合は、それに基づいてカスタムモデルを使用することも可能です。

新しいモデルプロバイダーの追加

新しいモデルプロバイダーを追加するには、主に次の手順が必要です。

  1. モデルプロバイダー設定YAMLファイルの作成

    プロバイダーディレクトリにYAMLファイルを追加し、プロバイダーの基本情報とパラメータ設定を記述します。ProviderSchemaの要件に従って記述し、システムの仕様との整合性を確保してください。

  2. モデルプロバイダーコードの記述

    プロバイダークラスのコードを作成します。システムのインターフェース要件に準拠したPythonクラスを実装して、プロバイダーのAPIに接続し、コア機能を実装します。


以下は、各ステップの詳細な操作手順です。

1. モデルプロバイダー設定ファイルの作成

ManifestはYAML形式のファイルで、モデルプロバイダーの基本情報、サポートされているモデルタイプ、設定方法、認証情報ルールを定義します。プラグインプロジェクトのテンプレートには、/providersパスに設定ファイルが自動的に生成されます。

以下は、Anthropicモデルの設定ファイルanthropic.yamlのサンプルコードです。

provider: anthropic
label:
  en_US: Anthropic
description:
  en_US: Anthropic's powerful models, such as Claude 3.
  zh_Hans: Anthropicの強力なモデル(例:Claude 3)。
icon_small:
  en_US: icon_s_en.svg
icon_large:
  en_US: icon_l_en.svg
background: "#F0F0EB"
help:
  title:
    en_US: Get your API Key from Anthropic
    zh_Hans: AnthropicからAPIキーを取得
  url:
    en_US: https://console.anthropic.com/account/keys
supported_model_types:
  - llm
configurate_methods:
  - predefined-model
provider_credential_schema:
  credential_form_schemas:
    - variable: anthropic_api_key
      label:
        en_US: API Key
      type: secret-input
      required: true
      placeholder:
        zh_Hans: APIキーを入力してください
        en_US: Enter your API Key
    - variable: anthropic_api_url
      label:
        en_US: API URL
      type: text-input
      required: false
      placeholder:
        zh_Hans: API URLを入力してください
        en_US: Enter your API URL
models:
  llm:
    predefined:
      - "models/llm/*.yaml"
    position: "models/llm/_position.yaml"
extra:
  python:
    provider_source: provider/anthropic.py
    model_sources:
      - "models/llm/llm.py"

接続するプロバイダーがカスタムモデル(たとえば、OpenAIがファインチューニングモデルを提供する場合)を提供する場合は、model_credential_schemaフィールドを追加する必要があります。

以下は、OpenAIファミリーモデルのサンプルコードです。

model_credential_schema:
  model: # ファインチューニングモデル名
    label:
      en_US: Model Name
      zh_Hans: モデル名
    placeholder:
      en_US: Enter your model name
      zh_Hans: モデル名を入力
  credential_form_schemas:
  - variable: openai_api_key
    label:
      en_US: API Key
    type: secret-input
    required: true
    placeholder:
      zh_Hans: APIキーを入力してください
      en_US: Enter your API Key
  - variable: openai_organization
    label:
        zh_Hans: 組織ID
        en_US: Organization
    type: text-input
    required: false
    placeholder:
      zh_Hans: 組織IDを入力してください
      en_US: Enter your Organization ID
  - variable: openai_api_base
    label:
      zh_Hans: API Base
      en_US: API Base
    type: text-input
    required: false
    placeholder:
      zh_Hans: API Baseを入力してください
      en_US: Enter your API Base

2. モデルプロバイダーコードの記述

/providersフォルダに、同じ名前のPythonファイル(たとえば、anthropic.py)を作成し、__base.provider.Provider基本クラス(たとえば、AnthropicProvider)を継承するclassを実装します。

以下は、Anthropicのサンプルコードです。

import logging
from dify_plugin.entities.model import ModelType
from dify_plugin.errors.model import CredentialsValidateFailedError
from dify_plugin import ModelProvider

logger = logging.getLogger(__name__)


class AnthropicProvider(ModelProvider):
    def validate_provider_credentials(self, credentials: dict) -> None:
        """
        Validate provider credentials

        if validate failed, raise exception

        :param credentials: provider credentials, credentials form defined in `provider_credential_schema`.
        """
        try:
            model_instance = self.get_model_instance(ModelType.LLM)
            model_instance.validate_credentials(model="claude-3-opus-20240229", credentials=credentials)
        except CredentialsValidateFailedError as ex:
            raise ex
        except Exception as ex:
            logger.exception(f"{self.get_provider_schema().provider} credentials validate failed")
            raise ex

プロバイダーは、__base.model_provider.ModelProvider基底クラスを継承し、validate_provider_credentialsプロバイダー統一認証情報検証メソッドを実装する必要があります。

def validate_provider_credentials(self, credentials: dict) -> None:
    """
    Validate provider credentials
    You can choose any validate_credentials method of model type or implement validate method by yourself,
    such as: get model list api

    if validate failed, raise exception

    :param credentials: provider credentials, credentials form defined in `provider_credential_schema`.
    """

もちろん、validate_provider_credentialsの実装を後回しにして、モデル認証情報検証メソッドの実装後に直接再利用することもできます。

カスタムモデルプロバイダー

他のタイプのモデルプロバイダーについては、以下の設定方法を参照してください。

Xinferenceのようなカスタムモデルプロバイダーの場合、完全な実装手順を省略できます。XinferenceProviderという名前の空のクラスを作成し、その中に空のvalidate_provider_credentialsメソッドを実装するだけで済みます。

詳細説明:

  • XinferenceProviderは、カスタムモデルプロバイダーを識別するためのプレースホルダーとして機能します。

  • validate_provider_credentialsメソッドは実際には呼び出されませんが、親クラスが抽象クラスであるため、すべてのサブクラスがこのメソッドを実装する必要があります。空の実装を提供することで、抽象メソッドが実装されていないことによるインスタンス化エラーを回避できます。

class XinferenceProvider(Provider):
    def validate_provider_credentials(self, credentials: dict) -> None:
        pass

モデルプロバイダーを初期化した後、プロバイダーが提供する具体的なLLMモデルを接続する必要があります。詳細については、以下を参照してください。

モデルプラグイン権限

より詳細なモデルプロバイダーYAMLの仕様については、を参照してください。

モデルインターフェースドキュメント
定義済みモデルの接続
カスタムモデルの接続
開発ツールの初期化