Perplexity（パープレキシティ）のAgent API、MCP・コネクタの呼び出しを実行前に承認できる require_approval を追加既定は承認なしのまま

Perplexity（パープレキシティ）は、Agent APIのmcpとconnectorツールに、呼び出しを実行前に人が確認できるrequire_approvalを追加しました。同社のAPI更新履歴（Changelog）の「October 2026」の項に載っています。同社の説明では、承認が必要な呼び出しは実行されずにmcp_approval_requestという項目で返り、承認するか拒否するかは開発者側からmcp_approval_responseを送って伝えます。何も設定しなければ、従来どおり承認なしで実行されます。

3行まとめ

1. Perplexityが、Agent APIのmcp・connectorツールにrequire_approvalを追加。承認待ちの呼び出しはmcp_approval_requestで返り、実行されない（同社更新履歴）
2. "always"で全件を確認、絞り込み用のオブジェクトで一部のツールや読み取り専用ツールだけ承認を省ける。既定は承認なしのまま。Python SDK 0.43.8・TypeScript SDK 0.38.8が対応（同）
3. 承認が効くのはmcp_callだけ。Sandbox内のコマンドは対象外で、承認を有効にするとSandboxにはコネクタの認証情報が渡されない（コネクタ公式ドキュメント）

本記事の内容は、日本時間10月20日2時台に公式ページで確認したものです（更新履歴・コネクタのページとも2時24分に取得）。

何が追加されたのか

更新履歴の記載は次のとおりです。

Set require_approval on an mcp or connector tool to review calls before they run. A call that needs approval returns an mcp_approval_request item and does not run. To approve or deny it, send an mcp_approval_response with previous_response_id.

（mcpまたはconnectorツールにrequire_approvalを設定すると、呼び出しを実行前に確認できる。承認が必要な呼び出しはmcp_approval_requestの項目を返し、実行されない。承認または拒否するには、previous_response_idを付けてmcp_approval_responseを送る。）

流れにすると次の3段です。

1. 開発者がmcpまたはconnectorツールにrequire_approvalを付けてリクエストを送る
2. 承認が必要な呼び出しは実行されず、mcp_approval_requestが返る
3. 開発者のアプリが、previous_response_idを付けてmcp_approval_responseを送り、承認か拒否を伝える

コネクタ経由の場合は、mcp_approval_requestに、その呼び出しを提案したコネクタのID（connector_id）も入る、とコネクタのドキュメントにあります。

承認の範囲は選べるのか

更新履歴によると、"always"を指定すると全件を確認でき、フィルター用のオブジェクトを渡すと「選んだツール」または「読み取り専用のツール」について承認を省けます。フィルターオブジェクトの具体的な書き方は、今回取得した2ページには載っていません（更新履歴は「MCP approvals」のページを参照先に挙げていますが、そのページは今回取得していません）。

コネクタ側のパラメーター表では、require_approvalの型は「string・object・null」で必須ではない項目とされています。

SDKは対応しているのか

更新履歴は「Python SDK 0.43.8とTypeScript SDK 0.38.8に承認用の型が含まれる」と書いています。型が入ったという記述であり、それ以前のバージョンで動くかどうかは、今回の2ページからは分かりません。

Sandboxと一緒に使うときの注意

コネクタのドキュメントには、承認とSandbox（コード実行環境）の関係について、見落としやすい記述があります。

• 承認が適用されるのは、mcp_callとして現れるコネクタ呼び出しだけ。Sandbox内でコネクタの認証情報を使って動くコマンドには適用されない
• GitHubのように、MCPツール経由とSandbox経由の両方に対応するコネクタでは、"never"以外の承認ポリシー（フィルターオブジェクトを含む）を指定すると、コネクタはMCPツール側に切り替わる。その場合、Sandboxはコネクタの認証情報を受け取らない
• GitHubコネクタの説明によると、allowed_toolsを指定した場合も同様に、Sandbox内のgit・ghコマンドは認証なしで動く
• 承認は、Sandbox内の個々のコマンドを承認・拒否するものではない

つまり、GitHubコネクタをSandboxと組み合わせ、gitやghでpushやプルリクエスト作成までさせる使い方では、承認を入れた時点で動かし方そのものが変わります。承認を付けたのに「Sandboxの操作も止まる」わけではなく、「Sandboxに認証情報が渡らなくなる」という形になる点は、設計時に押さえておく必要があります。

誰がいつから使えるのか、料金は

今回取得した2ページには、承認機能の提供開始日、対象プラン、追加料金、日本での提供についての記載は見当たりませんでした（承認機能の項目と、コネクタのページを確認した範囲です）。更新履歴の項は「October 2026」の見出しの下にあり、日付そのものは本文に表示されていません。当サイトが受け取った更新履歴のフィードでは、この項の日付は協定世界時10月19日17時21分（日本時間10月20日2時21分）でした。

コネクタの設定そのものについては、ドキュメントに次の記載があります。

• マネージドコネクタはGitHub、Slack、Google Drive、Datadog、Linear、Notionの6つ（現時点の一覧）
• コネクタの接続にはProject管理者の権限が必要
• 自前のリモートMCPサーバーもカスタムコネクタとして登録でき、認証はAPIキーまたはなし、通信はStreamable HTTPまたはSSE
• 同じProject内のAPIキーなら、どれでもそのコネクタを使える

同じProject内のどのAPIキーでもコネクタを使える設計なので、キーを使うアプリが多いほど、実行前の確認を挟む意味は大きくなる、と筆者は見ています。

前と何が違うのか

更新履歴は、承認なしの動作を既定のまま残すと明記しています。コネクタのドキュメントも「Connector calls run without approval by default（コネクタの呼び出しは既定では承認なしで実行される）」と書いています。これまでのコードは、書き換えなしで従来どおりに動く、という読み方になります。

変わるのは、Slackへのメッセージ送信（例として載っているツール名はslack_send_message）のように、外部に書き込むツールを持つコネクタを使うとき、「モデルが呼ぶ前に人が見る」段を自分で挟めるようになった点です。

公式ページを見て気づいたこと

日本時間2時24分にコネクタのページを取得して読んだところ、ページ内のサンプルコード（Slackの要約とGitHubのプルリクエスト作成）はどれもrequire_approvalを付けていませんでした。承認の説明は文章だけで、承認を付けたリクエストとmcp_approval_responseを返すコードの例は、このページの中にはありません。実装の具体例は、更新履歴が参照先に挙げる「MCP approvals」のページを別に当たる必要がありそうです。筆者はこの機能を実際には動かしていません。ここに書いたのは、取得した2ページの記載だけです。

今回の2ページでは分からなかったこと

• 更新履歴が参照している「MCP approvals」のページは今回取得しておらず、フィルターオブジェクトの書式、承認・拒否のレスポンスの正確な形は未確認
• 承認の追加が発表された具体的な日付、対象プラン、料金への影響は、今回の2ページには載っていない
• 日本語のドキュメントがあるかどうかは確認していない。取得した2ページはいずれも英語
• 動作はすべてPerplexity自身の記述であり、第三者による検証や筆者の実機確認ではない

出典と確認時刻

• Changelog — Perplexity（日本時間2026年10月20日2時24分に取得）
• Connectors — Perplexity（同2時24分に取得）

同じ更新履歴の10月分には、Gemini 4 Argonへの対応もあります。そちらは別の記事にまとめました。本記事は続報があり次第更新します。