2025年の春頃話題になったn8nというツールを知っていますか？

当時は、ZapierやMakeの代替になるAI時代の自動化ツールとして話題になりました。Webhookを受け取る、外部APIを呼び出す、SlackやTeamsに通知する、スプレッドシートに記録する。そういった業務自動化にAIエージェントを組み込めるツールとして活躍していました。

ただ、最近は以前ほどn8nという名前を聞かなくなった気がします。n8nって、もうオワコンですか？

今回は、最近のn8nのアップデートや、Claude Code・CodexのようなAIコーディングツールとの違いも踏まえて、2026年時点でn8nをどう見るべきかを整理してみます。

n8nが以前ほど話題にならなくなった理由

n8nが以前ほど話題を聞かなくなった理由を、ブーム期からClaude Code・Codex注目期までの流れで示した図

n8nが以前ほど話題にならなくなった理由は、n8n自体が終わったからではなく、AI業界の話題の中心が移ったからだと思います。

2024年から2025年前半にかけては、AIエージェント、自律型AI、MCP、AIワークフローといった言葉がかなり盛り上がっていました。その流れで、n8nも「AIエージェントを作れるツール」として注目されていた時期がありました。

しかし、2025年中盤からClaude CodeやCodexなどのCLIベースのバイブコーディングが流行り始めたことにより、わざわざn8nで自動化を組まなくてもバイブコーディングで丸ごと自動化すれば良くない？となったと思っています。

直近のn8nのアップデートでわかる方向性

直近のn8nは運用強化に寄っていることを、Visual diff・OpenTelemetry・実行データのマスキング・IdPロールマッピング・Microsoft Agent 365 Triggerの5機能で示した図

最近のn8nのアップデートを見ると、「業務で安全に運用するための機能」が強化されていました。たとえば、直近では以下のようなアップデートがあります。

  • ワークフローの変更差分を視覚的に確認できるVisual diff
  • ワークフローやノード実行を外部の監視基盤で追えるOpenTelemetry対応
  • 実行データ内の機密情報を隠すExecution data redaction
  • SSOや権限管理に関わるIdP role mapping
  • Microsoft 365内でn8nのエージェントをチームメンバーのように扱えるMicrosoft Agent 365 Trigger node

これらを見ると、n8nは単なる個人向けの便利な自動化ツールではなく、組織の中でワークフローを管理・監査・運用する基盤に寄っているように見えます。

n8nの価値は「最新のAIエージェントが作れること」ではなく、「AIやAPIを使った業務フローを、見える状態で運用できること」に移っているのだと思います。

Claude CodeやCodexで作ればよくない？という疑問

Claude Code・Codexとn8nの違いを、自由度・コード・エンジニア向き vs 流れが見える・運用しやすい・非エンジニア向きで比較した図

n8nを使いこなせる人は、そもそもClaude CodeやCodexも使えるのではないか。それなら、わざわざn8nでワークフローを組まずに、AIにコードを書かせて自前で作った方が楽なのではないか。

これはかなり正しい疑問だと思います。

実際、API連携やバッチ処理、Webhook、データ変換、通知処理くらいであれば、今はClaude CodeやCodexに頼めばかなりの部分を作れます。Hono、Cloudflare Workers、D1、Queues、Cron Triggers、Google API、Slack APIなどを組み合わせれば、自分用の自動化基盤を作ることもできます。

そして、純粋な自由度でいえば、コードで作った方が強いです。

  • 複雑なロジックを書ける
  • テストを書ける
  • GitHubで管理できる
  • CI/CDに乗せられる
  • 既存のプロダクトに組み込める
  • 自社の設計思想に合わせられる

そのため、エンジニアが自分のプロダクトや社内システムの一部として作るなら、n8nではなくコードで作った方が良い場面は多いと思います。

では、n8nの価値はどこにあるのでしょうか。

エンジニアが使うAIコーディングと、非エンジニアのバイブコーディングは違う

ここで分けて考えたいのが、使う人がエンジニアかどうかです。

もともとエンジニアで、コードが読める人がClaude CodeやCodexを使うなら、コードで作った方が速い場面は多いです。

  • AIが書いたコードを読める
  • おかしい部分をレビューできる
  • ログを見て原因を追える
  • 設計を自分で判断できる
  • 必要ならテストやCI/CDにも乗せられる

この場合、n8nよりコードの方が自由度も高く、長期的に見ても管理しやすいことがあります。

一方で、非エンジニアがバイブコーディングで自動化を作る場合は、少し事情が違います。AIに頼めば、動くものは作れるかもしれません。しかし、そのコードが何をしているのかを自分で理解できない場合、運用が難しくなります。

  • 少し変更したいだけでも、またAIに聞く必要がある
  • エラーが出たときも、どこで止まっているのか判断しづらい
  • APIの認証情報や環境変数の扱いも不安が残る
  • 数ヶ月後に見返したとき、自分で直せない可能性もある

つまり、バイブコーディングは「作る」ところまでは速い一方で、「自分で理解して直し続ける」ところに壁があります。

この点で、n8nにはまだ価値があります。n8nは、処理の流れが画面で見えます。

  • どこからデータを受け取っているのか
  • どのノードでAIに投げているのか
  • どこで条件分岐しているのか
  • どのSaaSに送っているのか
  • どこで人間の確認を挟んでいるのか

こうした流れを、コードを読まなくても追いやすいです。

また、ちょっとした変更に毎回AIを呼ぶ必要がありません。

  • 通知先を変える
  • 文章テンプレートを直す
  • 条件分岐を少し変える
  • 実行タイミングを変える
  • 一部の処理を止める

このような変更は、n8n上で直接できます。AIにコードを書かせる場合、変更のたびにプロンプトを投げ、コードを修正させ、動作確認をする必要があります。非エンジニアにとっては、そのたびにAIへの依存が発生します。一方でn8nなら、一度ワークフローの形ができていれば、小さな運用変更は自分で触りやすいです。

つまり、n8nは「AIでコードを書けない人のための代替手段」というより、非エンジニアや事業側の人が、自動化の流れを理解しながら運用するための道具だと考えるとわかりやすいです。

n8nは「作る」より「見える状態で回す」ためのツール

Claude CodeやCodexは、作る力を広げてくれます。n8nは、作った後に見える状態で回し続ける力をくれます。ここに大きな違いがあります。

コードで作れば自由です。n8nで作れば見えます。

もちろん、すべての処理をn8nで作る必要はありません。プロダクトの中核機能、複雑なロジック、長期的に保守するシステムはコードで作った方が良いです。一方で、社内業務、通知、下書き生成、承認フロー、SaaS連携、ちょっとした運用改善はn8nで作る方がわかりやすい場面があります。

特にAIを使った半自動化では、n8nのように処理の流れが画面で見えることは大きなメリットです。AIがどの入力を受け取り、どこで要約し、どこで人間に確認を求め、承認後にどのSaaSへ反映するのか。この流れをコードだけで管理すると、作った本人以外には見えにくくなります。しかしn8nなら、少なくともワークフローの全体像を画面上で確認できます。

n8nでやると良さそうなこと

今からn8nを使うなら、いきなり大きな自動化を作るのではなく、小さな半自動化から始めるのが良いと思います。

たとえば、問い合わせ対応の一次整理です。問い合わせフォームやメールをトリガーにして、AIが内容を分類します。料金相談、導入相談、不具合報告、営業メール、採用関連などに分け、要約と返信案を作ります。ただし、そのまま送信はしません。担当者が確認し、必要に応じて修正してから送信します。

ブログやSNS運用にも使えます。ブログを公開したら、その内容をもとにX、Threads、インスタグラム、メルマガ用の投稿文の下書きを作る。自動投稿はせず、人間が確認してから公開する。これなら、投稿作成の負担を減らしつつ、ブランドのトーンや誤情報のチェックは人間が担保できます。

メルマガ作成にも向いています。ブログ記事、最近のAIニュース、自社で試したツール、セミナー情報などを集めて、メルマガの構成案を作る。AIに本文のたたき台を作らせる。最後は人間が確認して配信する。

セミナーや研修の運営業務にも使えます。申込者への案内、前日リマインド、当日後のフォロー、アンケート回収、回答の要約などは、n8nと相性が良いです。特に研修やセミナーは、毎回似たような作業が発生します。テンプレート化しておけば、かなり効率化できます。

n8nを使うときの注意点

n8nは便利ですが、何でも勢いで自動化すると危険です。

特にAIと組み合わせる場合は、最初から書き込み権限を渡しすぎない方が良いです。最初は、読み取りや下書き作成に限定するのが安全です。

また、ワークフローを増やしすぎないことも大切です。n8nは簡単にワークフローを作れるため、気づくと似たようなワークフローが増えていきます。最初は便利でも、しばらくすると何がどこで動いているかわからなくなります。そのため、最初から命名ルールを決めておくべきです。用途がわかる名前にしておくと後から見返しやすくなります。

さらに、失敗時の処理も重要です。自動化ワークフローは、必ず失敗します。

  • APIが落ちることもある
  • 認証が切れることもある
  • 入力データの形式が変わることもある
  • AIの出力が想定と違うこともある
  • 外部サービスの仕様が変わることもある

だからこそ、失敗したときに通知する、どこで失敗したかわかるようにする、再実行しやすくする、二重送信や二重登録を防ぐ、といった設計が必要です。「動いたからOK」ではなく、「失敗しても原因がわかる」状態にしておくことが重要です。

n8nは誰に向いているのか

n8nが向いているのはこんな人を、業務フローを見える状態にしたい・非エンジニアでも流れを理解したい・小さな変更を自分で直したい・AIの出力に人間の確認を挟みたい・小規模チームで雑務を半自動化したいの5つで示した図

n8nは、全員におすすめできるツールではありません。

もともとエンジニアで、Claude CodeやCodexを使ってコードを書き、レビューし、運用できる人なら、コードで作った方が良い場面は多いです。特に、プロダクトの中核機能や、自社システムと密接に関わる処理は、コードで管理した方が長期的には強いです。

一方で、n8nが向いているのは、次のような人です。

  • 業務フローを画面で見える状態にしたい人
  • 非エンジニアでも流れを理解できるようにしたい人
  • 小さな変更を毎回AIに頼らず自分で直したい人
  • SaaS連携や通知、承認フローを素早く組みたい人
  • AIの出力をそのまま実行せず、人間の確認を挟みたい人
  • 一人会社や小規模チームで、雑務の下ごしらえを自動化したい人

こういう人にとって、n8nはまだ十分に使えるツールです。

結論：n8nはオワコンではない。ただし見方を変える必要がある

n8nは、以前ほどAI業界の中心で語られていないかもしれません。少しピークを過ぎたように感じる人もいると思います。

しかし、だからといってn8nの価値がなくなったわけではありません。むしろ、AIを実際の業務に落とし込む段階では、n8nのようなツールの価値は増していると思います。

AIに全部任せるのではなく、AIに下書きさせる。AIに要約させる。AIに分類させる。ただし、重要な判断は人間が行う。送信、公開、削除、更新のような操作には確認を挟む。実行ログを残す。失敗したら止める。あとから見返せるようにする。このような設計が、これからのAI活用では重要になります。

Claude CodeやCodexは、作る力を広げてくれます。n8nは、作った後の流れを見える状態で回し続ける力をくれます。

ただし、「AIエージェントを作れる最新ツール」として見るのではなく、「AI・API・人間の確認・既存SaaSをつなぐ業務フローの制御盤」として見る。この見方に変えると、n8nは2026年でもかなり現実的で、実務に使いやすいツールだと思います。