Activepieces のフローに、OpenAI 互換の AI プロバイダーを。

早わかり: 管理画面の AI 設定にプロバイダーを1つ追加するだけ。

Activepieces の管理コンソールで AI 設定ページを開き、OpenAI Compatible タイプのプロバイダーを追加します。フォームには Display Name、API Key、Base URL、API Key Header、任意のデフォルトヘッダー、そして各エントリが Model ID・Model Name・Model Type を持つモデルリストがあります。 APIsRouter 向けの値はこうです。Base URL は https://api.apisrouter.com/v1(コードベース自体が組み込みの互換プロバイダーに使っているのと同じ形)、API Key Header は Authorization、キー欄にはゲートウェイキーを入れます。知っておく価値のある実装上の細部が1つあります。Activepieces はそのヘッダーに、あなたが入力した文字列をそのまま送り、Bearer プレフィックスを自動では付け足しません。そのため正式な形としては "Bearer sk-..." のように入力してください。APIsRouter は Authorization ヘッダーに生のキーが来ても受け付けるため、どちらの書き方でも動作します。そのうえで、フローに見せたい各モデルを、カタログと正確に一致する Model ID で追加してください。

Admin Console -> AI setup -> Add AI Provider
  -> OpenAI Compatible

Display Name:   APIsRouter
Base URL:       https://api.apisrouter.com/v1
API Key Header: Authorization
API Key:        Bearer sk-YOUR-APISROUTER-KEY

Models (Add Model):
  Model ID: claude-haiku-4-5-20251001  Type: TEXT
  Model ID: deepseek-v4-flash          Type: TEXT
  Model ID: claude-sonnet-4-6          Type: TEXT

Activepieces がカスタムプロバイダーをどう使うか。

Activepieces(GitHub スター数はおよそ23K)は、代表的なオープンソースのノーコード自動化プラットフォームです。トリガーと piece からフローを組み立てる、Zapier に似た形でありながらセルフホスト可能で、MIT ライセンスの piece フレームワークと大きなコミュニティカタログを備えています。その AI 機能(テキスト生成ステップ、エージェント、AI ユーティリティ piece)は、プラットフォームに設定された AI プロバイダーを通じてモデルを解決するため、プロバイダーのエントリはすべてのフローに一度に効くルーティングの決定になります。 裏側では、OpenAI Compatible プロバイダーがあなたの Base URL に対して標準的なクライアントを構築し、選んだヘッダー名のもとにキーを添付し、さらに実行ごとにプロジェクトとフローを識別するメタデータヘッダーを付加します。登録した Model ID は、チャット補完リクエストの model 文字列としてそのまま渡されます。このプロバイダータイプにはモデルの自動検出がありません。フローが選べるのはリストに追加したモデルだけであり、それがピッカーを乱雑にせず意図的なものに保ちます。 プロバイダーの設定はプラットフォームレベルです。管理者が一度定義すれば、インスタンス上のすべてのプロジェクトとフローが、登録済みのモデルから選択します。この一元化こそがガバナンス上の利点です。どのモデルが存在するかを決める場所は1つ、すべての AI ステップを計測するキーも1つ、そしてリクエストごとのフロー単位のメタデータが、ログを読むときに利用状況を紐づけ可能にします。

フルセットアップと、保存時の注意点。

このフォームは接続を検証せずに保存されます。プロバイダーの実装は OpenAI Compatible タイプについて、明示的に接続チェックをスキップしているのです。これは便利な反面(保存時にエンドポイントを探りに行かない)、間違った Base URL や不正な形式のキーが、後になって、AI ステップに触れる最初のフロー実行で失敗することを意味します。本番フローに組み込む前に一度手動でエンドポイントを検証し、最初の実行をセットアップの一部として扱ってください。 Model Type は、そのエントリをどの piece が使えるかに関わります。テキストステップには TEXT モデルが必要です。id はカタログの綴りと正確に一致させて登録してください。Model Name は表示用のラベルであり、読みやすければ何でも構いません。同じ基盤モデルを、チームごとに異なる価格・性能のティアとして使いたい場合は、Model ID ごとに1回登録してください。表示名がピッカーの中でそれらを区別可能に保ちます。

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

自動化ステップ向けのモデル選び。

プロバイダーがプラットフォーム全体に及ぶため、モデルのガバナンスは1画面で完結します。承認した id を追加し、1週間分のキーごとの利用状況を観察し、誰も使うべきでないものを間引く。フロー作成者は、あなたが厳選したリストの中で自由を保てます。

• 自動化 AI は高ボリュームで短いプロンプトの作業です。チケットの分類、フィールドの抽出、メッセージの下書き、webhook ペイロードの要約など。claude-haiku-4-5-20251001・gpt-5.4-mini・deepseek-v4-flash が、ボリューム料金でほとんどのステップをカバーします。
• 判断を伴うステップには、より強力な id を確保しておきましょう。顧客向けの返信を下書きしたりルーティングを決定したりするフローには claude-sonnet-4-6 が値し、フロービルダーでステップごとに選択できます。
• MiniMax-M2.7 と DeepSeek ファミリーは、1日に数千回の実行が普通となる大量変換フロー(フィード、スクレイピングのクレンジング、エンリッチメント)向けに、極めて良い価格性能を示します。
• フローは無人で実行されるため、コストはスケジュール × 実行あたりのトークン数です。実行あたりの数字は利用ログが教えてくれますが、スケジュールはあなた次第です。
• モデルは意図的に少数だけ登録しましょう。ピッカーには追加したものだけが表示されるため、厳選されたリストは、100人のフロー作成者がそれぞれ違うものを選ぶ事態を防ぎます。

従量課金 · 公式価格より安い

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Activepieces に特有の失敗パターン。

静かな保存、うるさい初回実行。OpenAI Compatible プロバイダーは接続検証をスキップするため、あらゆる配線ミス(間違った Base URL、/v1 の欠落、不正なキー、間違ったヘッダー名)は、フォームエラーではなく、フロー実行時の AI ステップの失敗として表面化します。プロバイダー変更の直後に AI ステップが失敗する場合は、フローよりも先にプロバイダーのエントリを疑ってください。 Bearer プレフィックスの問題。キーは選んだヘッダーのもとに、そのまま送られます。文字通り Bearer プレフィックスを要求するエンドポイントでは、キー欄にそれを書き込む必要があります。APIsRouter はどちらの形式も受け付けますが、このプロバイダーを将来別のエンドポイントに向け直す場合、プラットフォームがプレフィックスを代わりに付けてくれないことを覚えておいてください。 Model ID は正確でなければなりません。タイプミスのある id はフォームを通過し(ラベルは自由記述です)、実行時に model-not-found で失敗します。ゲートウェイの /v1/models の出力が、正しい綴りの拠り所です。 自動検出がないのはバグではなく仕様です。モデルがフローのピッカーに見当たらない場合、それはプロバイダーに登録されていないということです。フロービルダーの中を探し回るのではなく、管理コンソールで追加してください。 そして piece レベルの接続は頭の中で分けて考えてください。OpenAI piece のような個々の piece は、接続ごとに独自の認証情報を持てますが、ここで説明しているプロバイダーのエントリは、プラットフォームの汎用 AI 機能を支えるものです。フローがベンダー固有の piece を独自の接続で使っている場合、そのトラフィックはあなたのゲートウェイのエントリを経由しません。

ゲートウェイ経由で Activepieces を使うのは誰か。

• 数十のフローにまたがって AI を標準化するセルフホストチーム。プロバイダーのエントリ1つ、キー1つが、あちこちに散らばった piece ごとの認証情報を置き換えます。
• モデルガバナンスを求めるプラットフォーム管理者。厳選されたモデルリスト、キーごとの利用状況、そしてフローに触れることなく背後のエンドポイントを差し替えられる自由。
• 1つのインスタンスでクライアント向けの自動化を運用する代理店。同じカタログ上で別々のキーを使い、クライアントごとに AI の利用状況を計測します。
• ボリュームステップと判断ステップが混在するフローを作るビルダー。1つのエンドポイントを通じて、速い id とフロンティア級の id をステップごとに組み合わせます。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初の AI ステップをデバッグする。

プロバイダーを保存する前に、上記の2つの curl を実行してください。キー、Base URL、モデル id をまとめて証明でき、それはまさにフォームが代わりに確認してくれない部分です。 セットアップ後にフローの AI ステップが失敗する場合は、ステップのエラーを読んでください。認証失敗はキー欄かヘッダー名が間違っている(あるいは Bearer プレフィックスを要求するエンドポイントでそれが欠けている)ことを意味します。model-not-found エラーは、登録した id がカタログと一致していないということです。接続エラーはたいてい Base URL の /v1 が抜けていることを意味します。ステップが選択可能なモデルを一つも見つけられない場合は、プロバイダーは保存されているものの、そのモデルタイプのモデルリストが空だということです。 フローが動き始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。スケジュール化された自動化は静かに積み重なっていくため、キーごとの利用状況ビューこそが、プラットフォーム管理者が、請求書が来る前に、どのフローがそのトークンに値するかを見極める方法です。

よくある質問