n8n 2.35.0：Agent Builder に公開前テストと人の判断が入り、レビュー付きで出せるようになった

要約

n8n の 2.35.0 が 2026-08-11 に公開され、同日 stable へ反映されました。2.34.0 からのマイナーリリースですが、内容はエージェント機能の成熟に寄っています。

中心は Agent Builder のテスト実行です。これまで作ったエージェントの挙動を確かめるには、実際に動かして結果を見るしかありませんでした。今回テスト実行が入り、あわせて human-in-the-loop（HITL） にも対応しました。公開前にエージェントを走らせ、途中で人の判断を挟みながら検証できます。エージェントを「作れるようになった」段階から、「出す前に確かめられる」段階へ進んだ更新です。

エージェント周辺では他にも動きがあります。チャットチャネルに Discord が加わりました。既存の Slack / Telegram に加えて、Discord を運用の中心に置いているチームがそのまま乗せられます。ローカルでのエージェントトークンカウントも実装され、消費量を手元で把握できるようになりました。

管理・API 面の追加も実務的です。カスタムロールを作成するエンドポイントが入り、ロール設計を API から扱えるようになりました。ワークフロー更新エンドポイントには publishIfActive オプションが追加され、稼働中のワークフローに対する更新の扱いを制御できます。MCP の get_workflow_details には detailLevel が入り、返す情報量を選べるようになりました。エージェントにワークフロー詳細を渡すとき、コンテキストを食い潰さずに済みます。

ワークフローレビューの流れも強化されました。レビュー詳細ペインに変更差分タブが付き、提出時にバージョンの説明を書けます。ノード側では Kafka ノードの v2（新ライブラリ経由の送信と圧縮オプション）、Salesforce Trigger の OAuth2 JWT 認証、Slack ノードの Real-time Search API 利用が加わりました。

見落とされがちですが、修正側にも権限の変更が入っています。Code ノードの console 出力に redaction ポリシーが適用されるようになり、data table への書き込みが行を返す場合は行の読み取りスコープを要求するようになりました。過大なエージェントツールの結果には上限が設けられています。

何が変わったか

• Agent Builder でテスト実行ができ、human-in-the-loop を挟めるようになった
• エージェントのチャットチャネルに Discord が追加された
• エージェントのトークン消費をローカルでカウントできるようになった
• カスタムロールを作成する API エンドポイントが追加された
• ワークフロー更新エンドポイントに publishIfActive オプションが追加された
• MCP の get_workflow_details に detailLevel オプションが入り、返す情報量を選べる
• ワークフローレビューに変更差分タブが付き、提出時にバージョン説明を書ける
• Kafka ノード v2（新ライブラリ経由の送信・圧縮オプション）、Salesforce Trigger の OAuth2 JWT 認証、Slack ノードの Real-time Search API 対応
• Code ノードの console 出力に redaction ポリシーが適用されるようになった
• data table への書き込みが行を返す場合、行の読み取りスコープを要求するようになった

業務インパクト（一般企業向け）

n8n でエージェントを本番に載せようとすると、必ず同じところで止まります。「誰がこのエージェントを承認したのか」を説明できないという問題です。ワークフローは作れる、動きもする、しかし本番の業務データに触れるものを、作った本人の判断だけで公開してよいのかという話になります。

2.35.0 は、この承認プロセスを n8n の中で組むための部品を揃えてきました。テスト実行で挙動を確認し、HITL で判断を挟み、レビューの差分タブで何が変わったかを見て、バージョン説明を付けて提出する。作成者とレビュアーを分ける運用が、外部ツールを持ち込まずに成立するようになります。カスタムロールを API から作れるようになった点も、この文脈で読むと意味がはっきりします。「作れる人」と「公開できる人」を分けるロール設計を、コードで管理できるということです。

権限まわりの修正も見過ごさないでください。Code ノードの console 出力に redaction が効くようになったのは、デバッグ出力から機微情報が漏れる経路が塞がれたということです。data table の書き込みで行の読み取りスコープを要求するようになったのも同様で、書き込み権限だけを渡していたつもりが結果として行の中身を返していた、という状態が是正されます。セルフホストで運用している場合、これらはアップグレードの理由として十分です。

Discord 対応は、社内コミュニケーションの実態に合わせやすくなったという話です。ただし、エージェントのチャネルを増やすということは、承認や通知が流れる場所が増えるということでもあります。どのチャネルで何を承認するのかを決めずに増やすと、HITL の判断が見落とされます。

副業・個人活用視点

n8n を受託で扱っているなら、2.35.0 は納品物の質を上げる材料になります。これまで「動くワークフローを作って納品」で終わっていたところに、テスト実行とレビューの仕組みを組み込めるようになりました。クライアント側の担当者がレビュアーとして関与できる構成にすれば、納品後に「思っていた動きと違う」が起きにくくなります。差分タブとバージョン説明があるので、変更の履歴を追える形で引き渡せます。

カスタムロールの API 化は、複数人が触る環境を任されている場合に効きます。ロール設計をコードで管理できるということは、環境を作り直すときに同じ権限構成を再現できるということです。手作業の設定を引き継ぐ形の納品より、明らかに保守しやすくなります。

エージェントのトークンカウントがローカルで取れるようになった点は、見積もりの精度に直結します。「このエージェントを月にこれくらい回すといくらか」を実測ベースで答えられるかどうかは、提案の説得力を左右します。推測でコストを話す提案と、実測値を出せる提案の差は大きい。

学習面では、HITL を実際に組んでみる価値があります。全自動のワークフローを作るより、**どこで人の判断を挟むべきかを設計する方が難しく、そして実務ではそちらが求められます。**Agent Builder のテスト実行で HITL を試せるようになったので、本番データに触れずに練習できる環境が整いました。自動化の提案をするとき「ここは人が見ます」と言える設計は、クライアントの不安を下げる効果もあります。