Activepieces 0.93.0は2026年11月8日に公開され、OAuth 2.0で保護されたMCPサーバーへの接続において、サービス側が必要な情報を提供している場合、クライアントIDやシークレットを手動で入力する必要がなくなった。接続を設定する担当者はサーバーのURLを入力し、アクセスを承認するだけでよい。フローの設定方法が変わり、エージェントが外部ツールと連携する際の手間が大幅に減った。今回のアップデートでは、コードステップの実行環境のデフォルトも変更された。
このリリースはGitHub上のActivepieces公式リリースノートに記載されている。9月22日付の技術提案には。Alephが提供するMCPサーバーを用いたローカル検証とともに本機能の詳細が示されている。実装は10月18日に統合され、11月8日公開のバージョンで配布された。
MCPクライアントが外部サービスに接続する仕組み
言い換えると、MCP（Model Context Protocol）とは、あるプログラムが別のサービスの公開ツールを発見・呼び出せるようにするプロトコルだ。クライアントは接続を開始するプログラム、サーバーはツールを公開するプログラムを指す。今回のアップデートではActivepiecesがクライアントとして機能する。外部アシスタントがActivepiecesの独自MCPサーバー経由でツールを利用するという逆方向の接続は、別機能として扱われる。
両者の違いを理解するには、フローが必要とするアクションの種類から考えると分かりやすい。MCPサービスを使う場合、自動化処理はサーバーが宣言した関数（例：ドキュメントアーカイブ内の検索）を呼び出す。Vercel Labsのagent-desktopはアプリケーションのインターフェースを操作するという別のケースに対応している。Activepiecesのリリースにおける重点は、各操作ごとにサービスのインターフェースを経由することなく、すでにサーバーが公開しているツールにアクセスすることだ。
URLから認可へ：自動メタデータ検出の役割
GitHubの技術提案には、具体的な課題が記されている。一部のサーバーはOAuthを要求しながら、クライアント設定にコピーするためのIDやシークレットをユーザーに提供しない。Activepiecesはこのケースに対応するため、認可メタデータの自動検出機能を追加した。必要な情報が利用可能な場合、担当者がドキュメントに記録された検証で手動入力したのはサーバーのアドレスだけだった。
接続ボタンを押すと認可ウィンドウが開く。そこからユーザーはアクセスを許可できる。MCP仕様によると。クライアントはトークンを使用して保護されたサービスにリクエストを送信する。リクエスト元のアイデンティティと、サービスが許可する機能の範囲を分離することには意味がある。GeminiエージェントのケースでもIDと権限の範囲は別の問題として扱われる。設定が簡略化された接続であっても、どの機能を認可するかという選択の余地は残る。
読み取りと書き込みは異なる権限だ
言い換えると、社内の問い合わせに回答するためにドキュメントを検索するフローを想定してみよう。そのタスクを完了するには関連するコンテンツの読み取りが必要だ。ドキュメントの変更や削除が可能になれば。設定手順が同一であっても接続の範囲は大きく変わる。MCP仕様ではサーバーが認可スコープを指定できる。リクエストして取得できる内容はサービスの設定に依存する。
このアップデートを評価するひとつの方法は、フローのタスクと、認可後に利用可能なツールを照合することだ。AnthropicがClaudeのインターネットアクセスを制限したテストでは、付与されたツールが観察された動作の具体的な変数となっていた。Activepiecesのコンテキストは異なるが、運用上の問いは同じだ。自動化処理が予期しない動作をした場合、実際にどのような操作が実行できるのか。その答えはエージェントへの指示だけでなく、サービス側の制御にも依存する。
Alephとのテストが示す互換ケース
Alephを使ったローカル検証では。OAuth 2.0の選択、認可ウィンドウの表示、その後のツール検出と呼び出しが実演された。このテストは特定サービスを使ったそのプロセスを記録したものだ。リリースノートには、動作が確認済みのサーバー一覧や異なる環境での設定時間に関するデータは含まれていない。組織は、登録手順や追加設定が必要なサーバーを含む自社環境でこのユースケースを再現できる。
この区別は他のツールのドキュメントを読む際にも重要だ。GitHubとFeishu向けエージェントプロトタイプでは、プロジェクトが宣言した統合が出発点となる。今回はソフトウェアがパブリックリリースとして配布されているが、接続の動作はつなぐサービスに依存する。複数のフローを管理する担当者にとって有益な情報は、どのエンドポイントが追加の手動手順なしに最初の使用から設定できるかを把握することだ。
コードステップのデフォルトがDenoに変わった
Activepiecesのchangelogによると、コードステップの実行環境のデフォルトがDenoに変更された。この変更はフローがカスタムコードを実行する箇所に影響する。MCPを使用しないユーザーにも関係する可能性がある。デフォルトの変更により、設定した接続とは独立してスクリプトを確認する必要が生じる。リリースノートには、既存のCommonJSコードをDenoで動作させるための対応も含まれているが、全ユーザーのスクリプトを対象とした検証は公開されていない。
インストールを管理する担当者にとって有効なチェックは、最もよく使うフローをテスト環境で実行し、出力を比較することだ。インポート、依存関係、エラーの発生方法を確認する必要がある。これらはフローを実行するソフトウェアに関するチェックであり、エージェントを制御するモデルの選択とは別の問題だ。アップデート後に異なる結果が生じた場合は、モデルや接続に帰属させる前に、その原因となっているステップを特定すべきだ。
Activepieces 0.93.0 まとめ
- 確認済み：11月8日のリリースで、MCPクライアントへのOAuth 2.0対応とコードステップのデフォルト実行環境がDenoに変更。
- 非公開：互換性が確認されたサーバーの完全なリスト。
- 要確認：使用中のフローの動作と、新しい接続で実際に付与される権限。
全体像から見るこのリリースの意味
このリリースの価値は、接続が再利用可能になった瞬間に現れると考える。フローを作成する担当者は互換サーバーのURLから始めて認可できる。サービスを管理する側は、どのツールを公開するかを決める役割を引き続き担う。エージェントがバックグラウンドで動作する場合には、この区別がより重要になる。接続は最初に設定されたインタラクション後にも呼び出される可能性があるためだ。
次に得られるべき有益なフィードバックは具体的だ。検証で使用したサーバー以外での接続の成功、実運用条件下での認可の更新と失効、そしてランタイム変更後のスクリプトの一貫した結果が求められる。これらのデータがあって初めて、設定作業のどれだけが実際に省力化されるかが判断できる。Activepiecesを使う担当者にとって最も有益なテストは自分自身のフローだ。必要なデータを取得しつつ、想定したアクセス範囲を維持できているかを確認してほしい。
