n8nの新アシスタント、ワークフローを作った後もデバッグまで担う

n8nがワークフロー自動化プラットフォームの中心に対話型ビルダーを据えました。注目すべきなのはデモではなく課金の仕組みです。n8n Assistantは、キャンバス上にワークフローを描いたところで手を離しません。実際に実行し、実行データを開き、どこが壊れたかを判断して再び試します。その試行のひとつひとつが、プランに付随するAIクレジットを消費します。一度で通るリクエストは安く済みますが、4回の修正を要するリクエストはそうはいきません。

要点

• n8n Assistantは自然言語のリクエストから標準的で編集可能なn8nワークフローを生成し、未検証の成果物を渡す代わりに自ら実行してデバッグします。
• 従来のAI Workflow Builderを完全に置き換え、利用量は各プランに既に割り当てられたAIクレジットから別枠で集計されます。
• 新規のn8n Cloudインスタンスでは既定で有効です。セルフホストのDocker利用者はバージョン2.36以降と自前のモデルキーが必要で、Enterpriseは現時点で対象外です。

手元に何が残るのか

一文から自動化を生成する機能は、すでに差別化要因ではなくなりました。n8nが掲げるのは持続性です。コーディングエージェントに連携構築を任せれば、誰かがホストし保守しなければならないコードが残ります。一方、作業をこなすだけの汎用アシスタントは、実行が終わった時点で何も残しません。どちらの結果も、その場にいなかった同僚に引き継ぐのは容易ではありません。

Assistantが出力するものは、意図的にありふれています。人が手で組み立てたのと同じノードグラフが、同じプロジェクトに、同じ実行履歴とともに置かれます。そのためチームの誰もが中身を確認でき、バージョン管理でき、モデルが何を判断したかに立ち返らずに説明できます。ホスティング型のノーコード競合に対して「ロジックを自分の目で見て所有できる」ことを訴求してきたプラットフォームにとって、生成されたワークフローにまでその性質を広げるのは、宣伝文句ではなく筋の通った立場です。

生成は安い部分にすぎない

エンジニアリングの大半は、キャンバスが埋まった後に控えています。Assistantは自らが構築したものを実行し、開発者が開くのと同じノード単位の入力・出力・エラーを読みます。成果物が出たことをもって成功と報告するのとは、意味の異なる主張です。失敗すれば診断し、修正案を提示し、パッチを適用して再実行します。その間にJSONを書き出したり、ツール間でコピー＆ペーストしたりする必要はありません。

曖昧な指示には推測ではなく質問が返ってきます。フォームの回答を振り分けてほしいという漠然とした依頼には、どのフォームでどこへ送るのかを問い返します。認証情報は事前にまとめて求めるのではなく、該当ノードが必要とした時点で要求されます。最初の結果を見る前に設定しておくべきものがない、という意味です。認証情報へのアクセス許可とワークフローの有効化という2つの操作は、明示的な人の承認の下に残されました。本番環境で何かが静かに動き出すのを防ぐ仕組みです。

誰が、どの条件で使えるか

提供範囲は3つに分かれます。新規のn8n Cloudインスタンスは、操作なしで有効な状態で提供されます。Enterprise Cloudはこの既定から外れており、広範なEnterprise対応はロードマップ上の項目としてのみ言及されています。セルフホストにはDocker環境とn8n 2.36以降、自前のモデルキー、そしていくつかの追加環境変数が必要です。

チームが試し始める前に見積もっておくべきなのはクレジットの計算です。既存の割当量には手が加えられず、利用量も置き換え対象のビルダーとは分けて集計されるため、すでに組んだ予算が変わることはありません。ただし消費量は修正サイクルの回数に比例して増え、追加購入の手段はまだ数週間先の話です。込み入った連携をAssistantに委ねるチームは、デモから想像するよりメーターが速く回るのを目にするかもしれません。

できないことは明記されている

今回の発表は、限界について珍しく率直です。生成物がそのまま本番投入できる保証はなく、結果の確認は人の責任のままです。アカウントを持っていないサービスを代わりに用意することもできないため、サードパーティ側の設定作業が消えたわけではありません。より適切なタイミングへ移っただけです。性質も能動型ではなく受動型で、インスタンスの監視はせず、好みを学習せず、自発的な提案もしません。対象は単一インスタンスに限られ、ブラウザや端末には触れません。ブラウザを介した認証情報設定は検討段階にあります。

今後の見通し

プレビュー表記は順番待ちではなく開発が進行中であることを示すもので、機能自体はすでに既定でクラウド利用者に届いています。本当の試金石は、修正と再実行のループがデモよりはるかに大きなワークフローでも収束するかどうかです。その規模では、エージェントが的を外した修正を繰り返してクレジットだけを燃やしかねません。これが持ちこたえるなら、より興味深いのは方向性のほうです。使い捨ての実行ではなく、残って検証できる成果物を生むエージェントツールという流れは、今年誰も話しかけていない間も動き続けるよう設計されたエージェントにも表れていました。設定の詳細はn8n Assistantのドキュメントにまとめられています。

よくある質問

n8n AssistantはAI Workflow Builderを置き換えますか？

はい、完全に置き換えます。n8nが示す違いは、従来のビルダーがワークフローを生成して終わっていたのに対し、Assistantは生成したものを実行し、実行データを読んで改善を繰り返す点です。

セルフホスト環境でもAssistantを使えますか？

バージョン2.36以降のDockerデプロイであれば有効化できます。n8n Cloudと異なり、セルフホストでは自前のモデルキーを用意し、追加の環境変数を先に設定する必要があります。

本番システムに直接向けても安全ですか？

生成物は下書きとして扱うべきです。認証情報へのアクセスと有効化はいずれも利用者の確認を要し、n8n自身も最初に生成されたワークフローが本番投入可能だとは保証しないと明言しています。業務上重要なものを有効化する前に、ノードを読み、認証情報を確認し、ログを点検してください。