BYOK モデルとは何か — WordPress プラグインに AI 機能を載せるときの最重要設計判断

WordPress プラグインに LLM (Claude / GPT / Gemini など) を載せて何か機能を提供するとき、最初に決めないといけない設計判断 が「API キーをどう扱うか」です。

選択肢は大きく 3 つ。

• マネージド型: プラグイン側 (= ベンダー) が API キーを管理する。ユーザーには見えない
• BYOK 型 (Bring Your Own Key): ユーザーが自分の AI プロバイダー API キーを取得して、プラグインに登録する
• ハイブリッド型: 両方サポート

どれを選ぶかでプラグインのアーキテクチャ、料金モデル、プライバシーポリシー、サポート工数、技術的責任範囲が全部変わります。機能設計より先に決まる べき判断です。

この記事では、

1. それぞれの長所短所 (ユーザー視点 + 開発者視点)
2. YomuForm が BYOK を選んだ理由
3. BYOK 実装時の技術的注意点
4. ユーザー側の選択基準

を整理します。WordPress プラグイン開発者、もしくは AI 機能付きプラグインを評価検討中の方向けの記事です。

各方式の比較

観点	マネージド	BYOK	ハイブリッド
ユーザー側のセットアップ	楽 (鍵不要)	API キー取得が必要	選べる
料金モデル	プラグイン側で従量課金 / サブスク	月額固定 + ユーザーが直接 AI 業者に払う	両方
データ通信経路	User → Vendor → AI	User → AI (直行)	選べる
プライバシー	Vendor サーバー経由する	Vendor 経由しない	経由する場合あり
プラグイン側のコスト破綻リスク	高い (ヘビーユーザー対策必須)	無い (ユーザー側が払う)	部分的
サポート工数	高い (AI 障害も Vendor 責任)	中 (キー設定エラーは多い)	高い
API レート制限の責任	Vendor	User	ハイブリッド

各観点を詳しく見ていきます。

マネージド型のメリット・デメリット

メリット

• セットアップが圧倒的に楽。ユーザーはプラグインを有効化するだけで使える
• エンタープライズ向きに見える: プロバイダ抽象化、SLA、ベンダーロックインの説明責任
• 収益モデルが従量制で組める: 「月 1000 件まで ¥980」みたいな細かい単価設計が可能

デメリット

• ユーザーの送信内容が Vendor のサーバーを必ず通る。プライバシー観点でユーザーが懸念しやすい
• コスト破綻リスク: 重ユーザーが想定の 100 倍リクエストすると赤字。レート制限とアカウント別クォータの実装が必要
• AI 障害がベンダーの責任になる: Anthropic / OpenAI 側で障害が起きると、ユーザーから Vendor にクレームが飛ぶ
• エンドユーザー → Vendor → AI Provider の 2 段ホップでレイテンシが増える
• AI Provider との 専用契約 / Enterprise tier が必要なことが多い。スタートアップ初期は割高

向く製品

• 「鍵管理を意識しないで使いたい」非エンジニア向けプラグイン
• AI を呼ぶ回数が予測可能で、単価が単純な機能
• すでに大規模ユーザーベースを持っていて Vendor 側でクォータ管理する体制があるサービス

BYOK 型のメリット・デメリット

メリット

• データ通信が User → AI Provider に直行。Vendor サーバーを経由しない = プラグイン側がユーザーデータを見られない構造的保証
• コスト破綻リスクが構造的に無い: 重ユーザーは自分で AI Provider に大きく払うだけ。プラグイン側の課金とは独立
• 透明性: ユーザーは Anthropic / OpenAI のダッシュボードで 実コスト を見られる。「このプラグインを使うと月いくら掛かる」が完全に予測可能
• AI 障害時の責任分離: Vendor が悪いんじゃなくて Anthropic が悪い、と切り分けがクリア
• プラン設計が単純: 機能フラグだけで Free/Plus/Pro が決まる。リクエスト数で課金しない

デメリット

• ユーザー側のセットアップが面倒: Anthropic アカウント作成 → API キー発行 → プラグインに貼り付け、というフローを通す必要がある
• API キーのバリデーション UI が必須: 間違ったキーが入った時に分かりやすく弾く必要
• AI プロバイダーごとの実装差: Anthropic / OpenAI / Gemini で API 仕様が違うので、Vendor 側は全部を抽象化する必要がある
• 判定通信のサポート不可: ユーザーから「判定がおかしい」と言われても、Vendor 側はその通信を見られない (= ユーザー側ログだけが頼り)

向く製品

• プライバシー要件が厳しい業界 (法務 / 医療 / 金融 / B2B エンタープライズ)
• ユーザーの送信内容が 守るべき個人情報 を含む可能性がある
• 月額固定 + 機能ベース課金で十分なシンプルな料金モデルを志向するプロダクト

YomuForm が BYOK を選んだ 4 つの理由

YomuForm は「問い合わせフォームの本文を AI が読む」プラグインなので、扱うデータの性質上 BYOK 一択でした。理由は 4 つ。

理由 1: フォーム本文に個人情報が混入する可能性が高い

問い合わせフォームには名前 / メアド / 場合によって電話番号や住所が入ります。これを マネージド型で Vendor サーバーを経由させると、プラグイン側がそのデータを保管 / 二次利用しない誓約を立てる必要 が出てきます。

BYOK なら 構造的にプラグイン側がデータを触らない。データ責任の議論がそもそも発生しない。これだけで法務 / プライバシーポリシーの設計が大幅に簡素化します。

理由 2: 利用量の予測がつかない

YomuForm を入れたサイトのフォーム送信量は、月 30 通のサイトもあれば月 1 万通のサイトもあります。マネージド型だと 重ユーザーへの対策 (= レート制限、追加課金、enterprise tier 設計) が必須で、これは小規模プラグインベンダーには重い実装責任です。

BYOK なら ユーザー側が自分の利用量に対応する。重ユーザーは Anthropic に多く払うだけで、YomuForm 側のサーバー負荷もコスト構造も変わりません。

理由 3: 料金モデルをシンプルに保ちたかった

マネージド型を選んでいたら、「月 100 件まで ¥X、それ以上 ¥Y」みたいな段階課金になります。これはユーザーから見て 予測が難しい料金構造 で、購入判断のハードルになりがちです。

BYOK + 機能フラグだけの ¥980/月 (Pro) は、ユーザーが事前に総コストを試算できる モデルになります (= AI Provider 単価 × 想定送信数 + 月額)。法人ユーザーの稟議が通りやすい構造です。

理由 4: 「自分のキーを使う」という信頼感

エンジニア寄りのユーザーには「マネージド型 = ブラックボックス」、「BYOK = 透明」と映ります。意思決定者 (= 開発リーダーや CTO) が技術系の場合、BYOK を提示しているプラグインの方が信頼を得やすい傾向があります。

特に B2B SaaS の問い合わせフォームみたいに、CV 1 件が高い金額になる業界では、「この通信は誰のサーバーを通ってるのか」という疑問は深刻な懸念事項です。

BYOK 実装時の技術的注意点

YomuForm を実装する中で当たった、BYOK で気をつけたい点を 7 つ。

1. API キーの保存場所

WordPress では基本的に wp_options テーブルに保存。update_option( 'plugin_xxx_api_key', $key ) です。

注意: wp_options は autoload=yes だと毎リクエストでメモリに乗る。API キーは autoload=no で保存しましょう:

update_option( 'yomuform_api_key', $key, false ); // autoload=false

これだけで「API キーが必要な処理が走るときだけ DB から取り出す」挙動になり、毎リクエスト広がるメモリの中身に鍵が乗らずに済みます。

2. 暗号化を入れるか入れないか

WordPress プラグイン界の伝統的なジレンマ。「入れた方が良い vs 入れても結局意味が無い」の議論が長く続いている領域です。

YomuForm の判断: 入れない。理由:

• 暗号化キーをどこに保存しても、結局 DB アクセスできる攻撃者は同時に PHP コードへもアクセスできる (= 復号鍵も取れる)
• 「暗号化されている」と書くと逆にユーザーに偽の安心感を与えてしまう
• WordPress の標準セキュリティ (= ファイルアクセス権限 / DB 認証情報の保護) を破られた時点で、暗号化の有無は本質的には変わらない

その代わり、

• API キーの取り扱いをドキュメントに明示
• 入力フィールドは type="password" 形式 (UI でマスクされる)
• AJAX で送る時は必ず HTTPS

を徹底しています。

3. キーバリデーションを「保存前」に行う

ユーザーが API キーをペーストして「保存」を押した瞬間、実際に AI API を 1 回叩いて検証 します。失敗したら「無効なキーです」と即フィードバック。これが無いと、ユーザーは「設定したつもり → 実は誤キー → フォーム送信時に静かに失敗 → 数日後に発覚」というワーストパターンに入ります。

実装イメージ:

$ok = test_anthropic_key( $key ); // 軽量な API call、例: messages.create with max_tokens=1
if ( ! $ok ) {
    return new WP_Error( 'invalid_key', 'API キーが無効です' );
}
update_option( 'yomuform_api_key', $key, false );

4. API 障害 / レート制限へのフェイルセーフ

AI Provider が落ちる / レート制限に当たる / タイムアウト、これは現実によく起きます。判定が失敗したらどうするか をプラグイン設計に組み込みます。

YomuForm の方針:

• 失敗時はフォーム送信自体は通す (= 「全件 unknown 扱い」で運営者に届く)
• 判定ログに error ステータスで記録 (後で振り返り可能)
• ユーザーが Slack 通知で「judge error」のシグナルを受け取れる

「判定失敗で送信ブロック」は 本物の問い合わせをロストする ので絶対にダメ。ロストする 99% の確率より、たまに営業が Slack に紛れる方を許容します。

5. プロバイダー抽象化レイヤー

Anthropic Messages API、OpenAI Chat Completions、Gemini Generative Language Service、それぞれ:

• リクエスト形式が違う
• レスポンス形式が違う
• 認証ヘッダが違う
• レート制限のヘッダーが違う

これを抽象化する PHP の Provider Strategy パターン:

interface LlmProvider {
    public function classify( string $body ): Verdict;
}

class AnthropicProvider implements LlmProvider { ... }
class OpenAiProvider implements LlmProvider { ... }
class GeminiProvider implements LlmProvider { ... }

切り替えはユーザー設定の yomuform_provider 値だけで決まる構造に。新プロバイダー追加時の改修範囲が 1 ファイルに閉じます。

6. プロンプトとモデル選択の責任分担

BYOK だと モデル選択もユーザーが行えるべきです。

• Claude Sonnet vs Haiku → 精度 vs コスト
• GPT-4 vs GPT-4o-mini → 同上
• Gemini 1.5 Pro vs Flash → 同上

ユーザーが「Haiku で十分」と判断すれば $/月のコストが 5 分の 1 になります。マネージド型だと提供側が一律に決めるしかありませんが、BYOK ならユーザー裁量で最適化できます。

YomuForm はデフォルトで Haiku 4.5 / GPT-4o-mini / Gemini 2.5 Flash を推奨、上級ユーザーは Pro モデルに切り替えられる、という UI にしています。

7. キー削除時の清掃

ユーザーがアンインストールする時、API キーがゴミとして残らないように uninstall.php で:

delete_option( 'yomuform_api_key' );
delete_option( 'yomuform_provider' );
// 判定ログテーブルも DROP するかはユーザー選択

「アンインストール後に DB に API キーが残ってる」はセキュリティ事故になり得ます。

ユーザー視点での選び方

プラグインを評価する側 (= サイト運営者) からの判断軸:

観点	BYOK が向く	マネージドが向く
個人情報を含むデータを AI に渡す	◎	✗
エンジニアが社内にいる	◎	○
サイト規模が大きい / 利用量が多い	◎	△
API キー管理が分からない / 面倒	△	◎
月額予測を厳密に立てたい	◎	△
AI Provider に直接アカウントを持ちたくない	✗	◎

迷ったら BYOK のプラグインを選ぶ方が、長期的に安全だと考えています (= プラグイン会社が買収・廃業しても、自分の API キーは手元にあるので)。

まとめ

• AI 機能付き WordPress プラグインの設計は、API キーの扱い方 (マネージド / BYOK / ハイブリッド) で根本的に変わる
• BYOK の本質的価値は 「ユーザーデータが Vendor サーバーを経由しない」構造的保証。プライバシーポリシーが簡素化し、コスト破綻リスクも消える
• 実装上の重要ポイント: 鍵の autoload=no、保存前バリデーション、フェイルセーフ、プロバイダー抽象化、モデル選択の解放
• ユーザー側は、個人情報を扱うプラグインを選ぶ場合は基本的に BYOK を優先するのが安全

YomuForm は 「フォーム本文に個人情報が含まれる」プラグインなので、BYOK 一択でした。同じ判断が必要な開発者の方の参考になれば。