Activepiecesの使い方と料金：自動化を移行する前の判断ガイド

2026年11月6日に、Activepiecesの公開料金、ドキュメント、GitHubのソースで確認しました。本記事は資料に基づく評価と構築手順の解説であり、実環境に導入して検証したものではありません。判断の軸は、必要なアクションの有無、エディションごとの機能範囲、ワークフローの費用、そして運用責任です。

Activepiecesとは：画面上で組み立てるワークフロー自動化

Activepiecesは、視覚的に操作できる自動化プラットフォームです。イベントをきっかけにフローが始まり、配置したステップがデータの読み取りや条件判断、連携アプリでの処理を行います。連携部品はpiecesと呼ばれます。AIモデルでアクションを選ぶAgentsと、構造化されたレコードを保存するTablesも用意されています。ライセンスの説明では、MITライセンスのコアと商用ライセンスの機能を区別しています。MITという表記はコアのソフトウェアライセンスを指しており、ホスト型製品の全体が無料という意味ではありません。

クラウドかセルフホストかは設置先の選択であり、Communityか商用版かは機能の選択です。 無料のクラウドプランとCommunityのインストール環境は、別々に評価する必要があります。Communityは自動化のコアです。クラウドで案内されているAgentsやChatまで含むとは考えないでください。現行のセルフホスト版ライセンスガイドによると、すべての料金プランをセルフホストで利用でき、PlusとTeamのサブスクリプションはアプリ内で有効化します。個別のエンタープライズ契約ではライセンスキーを使います。組み込みデータベースを使うHobby構成では、そのEnterpriseエディションは動かせません。自社サーバーに置くものを一括して「無料版」と呼ぶより、この区別が重要です。

どんな人に向くのか、見送るべきなのか

Activepiecesは、一般的なアプリ連携を画面上で保守したい担当者に向いています。セルフホストが必要なら、インフラの責任者も欠かせません。見込み客の通知、オンボーディングの更新、定期レポートを移そうとする創業者は、まずその具体的な業務から評価するとよいでしょう。

比較候補のZapierはホスト型のアプリ自動化サービス、Makeは視覚的なシナリオビルダー、n8nはホスト型とセルフホスト型を備えるワークフロープラットフォームです。課金の単位が違うため、同じ利用枠でも処理できる仕事量は同じではありません。

n8nの記載は現行の料金ページに基づきます。Zapierのタスク集計ルールは、成功したアクションとトリガーを区別し、例外も列挙しています。これらは比較の出発点であり、同じ処理量に対する見積もりではありません。

移行自体が連携開発の案件になるなら、Zapierを継続しましょう。 現在使っているトリガー、検索、書き込みの各操作を、Zapierのアプリ一覧とActivepiecesの対応pieceで照合します。同じロゴが並んでいるだけでは不十分です。既存のZapが動いていて、代替先ではAPIコネクターの保守が必要になるなら、その作業を賄えるだけの利用料削減が必要です。

担当者がMakeの複雑なシナリオをすでに把握しているなら、そのまま使う判断も合理的です。 ルーターの説明には、フィルター付き分岐やフォールバック経路が示されています。稼働中の受注処理シナリオを、サービスの乗り換えだけのために作り直すと、削減額以上の費用がかかることがあります。Activepiecesも分岐に対応しています。問題は分岐の可否ではなく、再構築の負担とそれを担う人です。

コードを中心にワークフローを管理するなら、n8nが有力です。 CodeノードはJavaScriptとPythonに対応し、セルフホストではnpmのインポートも設定できます。独自のデータ変換を保守する開発者には具体的な利点です。一方で、Activepiecesの制約の少ないコアライセンスは、それ自体が選ぶ理由になります。

乗り換えの理由を広く検討するならZapier代替ツールの候補一覧を、課金単位を比較するならn8n・Zapier・Makeの比較を参照してください。

Piecesはアプリ名よりアクションを確認する

Activepiecesのpiecesは、接続先サービスの操作をフローで使えるようにまとめたものです。公式リポジトリではTypeScriptパッケージと説明され、ビルダーの機能としてループ、分岐、HTTP呼び出し、コードステップなどが挙げられています。製品紹介だけでは判断できない点は、連携コードで確認できます。

連絡先を管理するフローを考えます。受信したレコードをメールアドレスで検索し、存在しなければ作成、存在すれば更新する必要があります。Google SheetsのpieceにはFind or Create RowとUpdate Rowがあるため、スプレッドシートの連絡先台帳ではこれらを使えます。別の顧客データベースへ移すなら、同等の操作があるかを先に確認してください。「自社のCRMと接続できる」だけでは、必要なオブジェクト、検索フィールド、更新処理に対応しているとは限りません。

権限も判断を左右します。SlackのpieceのSearch Messagesにはユーザートークンが必要です。通知を投稿できる接続でも、検索を多用するエージェントの要件を満たすとは限りません。Slackアクション一覧で、この違いを確認できます。

アクションが足りなければ、HTTPリクエストや独自pieceで補える場合があります。ただし、認証、ページネーション、再試行、接続先APIの変更追従という作業が隠れています。要件に合う既製アクションを使い、独自連携は保守担当者が必要なソフトウェアとして扱いましょう。 初期設定後に開発者以外がフローを管理できるかは、ここで決まります。

Activepiecesの使い方：SheetsからSlackへの通知を作る

Activepiecesでは、AIステップを使わずに、スプレッドシートに追記された行をチャンネル通知へ変換できます。営業の受付業務を移す担当者にとって、最初の移行に向いた例です。入力を確認でき、出力も目で見え、障害箇所を切り分けやすいためです。ActivepiecesはSheetsとSlackの連携例を公開しています。以下は、その例に現行トリガーのソースとフローのドキュメントを組み合わせた手順です。

目標は、新しい見込み客の行ごとに、識別子、氏名、会社名を含むSlackメッセージを送ることです。構築中はテスト用のワークシートとチャンネルを使います。以下の名称やフィールド構成は例示です。

この構築例の合格条件は、新しい行から正しい通知が生成され、担当者が障害箇所を特定できることです。拡張する前に、任意フィールドが空のケースと、値に句読点や記号を含む行をテストします。検索、承認、AIのステップを加えるのは、この単純な経路が動いてからです。

ActivepiecesのAIエージェントを管理されたフローで使う

Activepieces Agentsは、与えられたツールから使うものをモデルが選ぶ仕組みです。問い合わせが請求関連なのか、人による対応が必要なのかを判断するなど、依頼の解釈が必要な仕事に向いています。決められたチャンネルへの送信のように手順が明確な処理は、フローのステップに明示します。

実用的な拡張例は、問い合わせの振り分けです。受信メッセージの本文をエージェントに渡し、返された分類に応じて担当者へ回します。フロー内でのAgents利用ガイドでは、AIのpieceにあるRun Agentアクションを使います。保存・公開済みのエージェントを選び、そのエージェントに設定されたモデルを使う場合はAI Modelを空欄にします。

役割は限定します。メッセージを分類し、振り分けの理由を短く説明して、category、urgency、needs_humanを返すようにします。これらはドキュメントで使われている構造化フィールドです。後続の条件分岐では、毎回表現が変わる文章を解釈する代わりに、needs_humanを調べられます。

エージェントエディターでモデル、指示、必要なツールを選び、Max stepsを設定して、Publishの前にTestします。各操作はエージェント作成ガイドに説明されています。ツールの種類は、個別のアプリアクションであるPiece tool、定義済みワークフローであるFlow tool、外部のツールサービスであるMCP serverです。分類だけが仕事なら、顧客レコードを変更できるツールを与えずに始めます。要約を投稿させるなら、モデルに送信先を選ばせず固定してください。

保存したエージェントは、複数のフローが共有する依存先です。 変更を公開すると、利用するすべてのフローに次回実行から反映されます。各フローの再公開は不要です。共有の振り分けエージェントを変える前に、依存するフローが受け取る種類のメッセージでテストしましょう。ある受付キューに都合のよい限定的な指示が、別のキューを壊す場合があります。

有効なのは、予測できる業務手順の中で柔軟な解釈を使う組み合わせです。固定の条件で振り分けられるなら、その条件を使いましょう。不要な判断にエージェントを入れると、モデルによる結果の揺れと利用量が増えます。

MCP：AIクライアントからフローを作成・点検する

ActivepiecesのMCP Serverを使うと、外部のAIアシスタントから自動化プラットフォームを操作できます。MCPはModel Context Protocolの略で、AIクライアントがツールを見つけて呼び出すための標準的な接続方式です。Activepiecesのフロー内で動くAgentとは別の仕組みです。

ドキュメントにある設定手順は、Settings → MCP Server → 有効化 → Server URLをコピーです。そのURLをクライアントに追加し、OAuthで認証します。Discoveryツールは読み取り専用で常に利用でき、それ以外のツール分類はプロジェクトごとに有効・無効を切り替えられます。MCPの概要では、フローの構築と公開、テーブル、テスト、実行の点検を扱っています。

受付フローなら、クライアントを接続し、SheetsのトリガーとSlackのアクションを特定させ、選択した接続を使って下書きを作らせます。その後、設定を点検します。本番の処理を有効にする前に送信先をテストしてください。運用開始後は、失敗した実行や入力の調査にも使えます。こうした具体的な運用作業には役立ちますが、自然言語で作れたというだけでフィールドのマッピングが正しいとは判断できません。

MCPにも課金の境界があります。ap_run_actionは呼び出しごとにクレジットを消費し、ツール呼び出しから開始されたフローには通常のフロー課金が適用されます。AIクライアント経由の実行がすべて無料だとは考えないでください。

セルフホストはサーバーを立てて終わりではない

Activepiecesのセルフホストは、実行場所を選ぶ必要があり、運用担当者を割り当てられる場合に適しています。比較的少額の自動化費用を抑えたいだけの創業者なら、まずクラウドで試す方が進めやすいでしょう。

現行のDocker Composeガイドの要件は、Docker Compose v2、最低2 vCPU、4 GB RAMです。WindowsではWSL2内で動かします。インストーラーはアプリケーション、ワーカー、PostgreSQLデータベース、Redisキューを起動します。記載されている導入コマンドは次のとおりです。

curl -fsSL https://get.activepieces.com | sh

使用するサーバー上で実行します。先にインストーラーを確認したい場合は、shへパイプせずにURLから取得してください。導入後は、生成されたactivepiecesディレクトリへ移動し、構成の稼働状態を確認します。

docker compose -p activepieces ps
curl http://localhost:8080/api/v1/health

ポート8080のサービスを開き、最初の管理者アカウントを作成します。アプリからWebhookを受けるには、AP_FRONTEND_URLを外部から到達できる本番用アドレスに設定してください。ノートPC内だけで通じるアドレスでは、Sheetsの例でGoogleからの通知を受け取れません。

最小構成で導入できることは、処理能力の保証ではありません。本番環境の設定ガイドは、同時実行するフローごとに独立したワーカーを用意し、マネージドPostgreSQL、Redis、S3互換オブジェクトストレージを同じリージョンに置く構成を推奨しています。基準となるワーカーは0.5 vCPU、1 GB RAMです。月間の総実行回数だけでなく、処理が最も重なる時間帯に合わせて規模を決めましょう。少数の遅い処理が能力を占有し、新しいトリガーが待たされることがあります。

バックアップと復旧も構築の一部です。データベース、保存ファイル、保存済み接続に使う暗号化キーを保全します。災害復旧ガイドは、キュー喪失のケースも示しています。受理された非同期Webhookイベントでも、実行レコードの作成前にRedisから失われると消える可能性があります。データベースのバックアップだけでは、すべての受信イベントを再実行できるようにはなりません。

セルフホストが必須のチームは、機能エディション、インフラ、復旧手順、障害対応の責任者まで含めて購入を判断します。サーバーを自社で持つとホスティング先への依存はなくなりますが、自動化を稼働し続けさせる責任も引き受けます。

Activepiecesの料金：運用に合うプランを選ぶ

Freeでは足りなくなった小規模な運用なら、Activepieces Plusが妥当な出発点です。以下は2026年11月6日に確認した、Activepiecesの料金ページの月払いの条件です。

• Free： $0、月間1,000クレジット、最大5ユーザー。定常業務ではこの利用枠が実質的な上限になります。
• Plus： 月額$20、10,000クレジット、最大5ユーザー。追加利用は1クレジットあたり$0.007で、自分のAIキーを持ち込めます。
• Team： 月額$200、50,000クレジット、25ユーザー。プロジェクト、シングルサインオン（SSO）、Plusを超える共同管理が必要な場合の選択肢です。
• Community： コアのソフトウェアライセンス料は不要です。インフラと保守の費用は別途見積もります。高度な商用要件には、該当する有料プランか個別見積もりが必要です。

通常の実行では、ステップ数に関係なく1クレジットを使います。AI利用分は追加です。自分のキーを持ち込んでもプラットフォーム側の課金は残り、モデル提供元からの請求も別に発生します。フロー数が無制限でも、実行まで無制限になるわけではありません。

費用の計算例： AIを使わない処理が月に5,000回成功し、追加のテストや再試行によって利用枠を超えないとします。Plusの完了した実行あたりの費用は、$20 ÷ 5,000で**$0.004**です。これはプラットフォーム費用だけの試算であり、実測値ではありません。連携アプリの料金、ホスティング、人件費は含みません。

Freeの利用枠リセットについては記述が一致していません。月間の枠として説明される一方、別の箇所では使い切った実行は翌日まで待つとされています。重要な業務をFreeに任せる前に、自分のアカウントでリセットの条件を確認してください。

導入判断を変え得る制約

Activepiecesには、機能一覧以上に重要な運用上の境界があります。特に移行やセルフホストの判断を左右しやすいのは、次の点です。

エージェントの監査ログは全操作を記録しない

Agent Toolsのドキュメントは、監査ログ付きプランでも記録に抜けがあると説明しています。外部MCPツールの呼び出し、エージェントが作成・実行したコード、送信したメールでは、列挙されているエージェント操作の監査イベントが作成されません。読み取り操作は対象外で、アクションの入力値も保存されません。

請求書の変更経緯を再現する必要があるなら、監査ログ機能を購入しただけでは、あらゆるエージェントの処理経路を追える証拠にはなりません。重要な書き込みは、仕様が明記されたpieceのアクションかフローで行い、結果のレコードを確認します。プランを選ぶ前に設計の範囲を絞るべき理由です。

処理時間と応答時間の上限は異なる

制限のリファレンスによると、Cloudのフローのアクティブな実行時間は10分でタイムアウトしますが、同期Webhookの応答には30秒の上限があります。遅延や承認待ちは、アクティブな実行時間に含まれません。顧客からの依頼にエージェントの長い調査が必要なら、同期接続を開いたままにせず、受付を返して後から結果を届ける設計にします。

CloudのPlusでは、プロジェクトごとに10件まで同時実行できます。超過分はキューで待機します。月額費用が許容範囲でも、集中時の即時処理が保証されるわけではありません。

ファイルの保存先とは別に、実行ログの大きさで失敗する

Cloudのフロー実行ログの合計上限は25 MBです。オブジェクトストレージへ移した出力も、元のサイズがこの制限に含まれます。出力を切り分けるしきい値を下げても、全体の上限は増えません。大きなレスポンスを繰り返しログに残すフローは、ファイル自体が別の場所に保存されていても失敗する可能性があります。処理を分割し、後段に必要な情報だけを渡しましょう。

MakeやZapierの既存フローは、作り直す価値があるか判断する

カタログに利用アプリが載っているだけでは、Activepiecesへ移る理由として不十分です。Webhookの挙動、指定できるアクション入力、認証、送信先での処理の意味まで、既存業務に合う必要があります。今回のSheetsの例は、即時に動くという想定との具体的なずれを示しています。トリガー自身が通知の遅延を注意事項に挙げているためです。

Makeのクレジットの説明では、繰り返しのバンドルが後続のオペレーションを消費する仕組みを説明しています。これはステップの長い通常フローでActivepiecesを評価する理由になります。ただし、移行作業と置き換え後の挙動も含めた判断が必要です。信頼性を維持するための作業より削減効果が小さいなら、既存のプラットフォームを継続しましょう。

セルフホストでも全機能が使えるとは限らず、全データがローカルに残るわけでもない

外部のモデルやアプリケーションへ送ったデータは、その相手に渡ります。処理を取りまとめる基盤を自社でホストしても、Slack、Google Sheets、外部のモデルが自社ネットワーク内へ移るわけではありません。ローカル処理が厳格な要件なら、すべての送信先と提供元を個別に確認する必要があります。

エディションの違いは他の候補にも当てはまります。n8nのCommunityの機能一覧では、ワークフローと認証情報の共有、プロジェクト、SSOなどが対象外です。ライセンスの説明では、MITライセンスではなく、利用制限のあるfair-codeモデルとされています。どちらの製品も、無料で導入できる構成を商用機能の全部入りと考えるべきではありません。

結論：範囲を絞った業務から試験移行する

Activepiecesが合うのは、確認済みのpiecesで必要な業務を構築でき、選ぶエディションに必要な管理機能があり、障害とアップグレードの責任者がいる場合です。コアのライセンスと通常実行単位の課金は、十分に検討する価値があります。ただし、足りないアクションや管理者不在のサーバーを補えるものではありません。

試験移行で必要な挙動を維持でき、継続的な削減効果が追加のホスティングと保守の負担を上回るなら、乗り換えましょう。 稼働中の連携を経済的に置き換えられないならZapierを継続し、複雑なシナリオの再構築で利点が消えるならMakeを残します。開発者の独自ロジックが中心ならn8nを優先します。

来週、リスクの低い受付通知をActivepiecesに複製してみてください。区別できるサンプルレコードで本番トリガーの動作を確認し、失敗した実行を調べ、クレジット消費量を記録します。保守担当者が結果と復旧手順の両方を説明できるようになってから、対象を広げましょう。

よくある質問