n8n 2.34.6：Google Ads ノードが sunset 済み v21 API から v25 へ — 気づけない止まり方の実例

要約

n8n の 2.34.6（stable）が 2026-08-14 に公開されました。内容はバグ修正3件です。

中心は Google Ads ノードの API 移行（#36260）です。提供終了済みの v21 から v25 へ切り替わりました。裏を返せば、それまで n8n の Google Ads ノードは sunset 済みの API を叩き続けていたことになります。該当ノードを使っているワークフローには、既に実害が出ていた可能性があります。

2件目は Microsoft Teams ノードの Group.ReadWrite.All OAuth2 スコープの復元（#36187）です。過去に外れていたスコープを戻す修正で、Teams ノードの一部操作が権限不足で失敗していた状態が直ります。3件目は continueErrorOutput モードで details フィールドを許可する変更（#36229）です。

同日の 2.35.3（pre-release、2026-08-14T10:21:09Z）には、上記に加えて機能追加が入っています。同一の Instance AI セッション内で作成されたワークフローについて、更新承認をスキップする変更（#36106）です。AI がワークフローを作った直後に編集するたび承認を求められる煩雑さを解消します。あわせて、ワークフロー publication outbox のレコード処理に中断デッドラインを設定（#36286）、エディタの ready-to-run デモテンプレートを現行の OpenAI モデルへ更新（#36201）が含まれます。

2.35.3 は pre-release で、stable 側は 2.34 系のバックポートが続いています。2.35 系の stable 昇格はまだありません。

何が変わったか

• 2.34.6（stable）: Google Ads ノードが sunset 済みの v21 API から v25 へ移行（#36260）
• 2.34.6（stable）: Microsoft Teams ノードの Group.ReadWrite.All OAuth2 スコープを復元（#36187）
• 2.34.6（stable）: continueErrorOutput モードで details フィールドを許可（#36229）
• 2.35.3（pre-release）: 同一 Instance AI セッション内で作成したワークフローの更新承認をスキップ（#36106）
• 2.35.3（pre-release）: ワークフロー publication outbox のレコード処理に中断デッドラインを設定（#36286）
• 2.35.3（pre-release）: エディタの ready-to-run デモテンプレートを現行の OpenAI モデルへ更新（#36201）
• 2026-08-12、08-13、08-14 と3日連続でパッチが出ている

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

対象は Google Ads / Microsoft Teams ノードの利用者に限られます。ただし止まり方が分かりにくい種類の不具合であり、影響範囲の狭さと発見しにくさは別の話です。

Google Ads の件は、自動化が抱える構造的なリスクがそのまま出た例です。ワークフロー側は何も変えていません。作ったときは動いていました。それでも、依存先の API が提供を終了すれば止まります。しかも利用者から見ると、自分は何も触っていないのに動かなくなったように見えます。n8n のリリースノートを読まない限り、なぜ止まったのかが分からないという点が、この種の障害の厄介なところです。

ここから引き出すべき運用は具体的です。使っているノードの一覧を持ち、リリースノートで該当ノード名を検索する。これだけで、大半の「気づけない止まり方」は先回りできます。ワークフローが増えるほど、どのノードに依存しているかを把握している人がいなくなるので、一覧そのものを資産として管理する価値があります。

Microsoft Teams のスコープ復元は、権限スコープが変わると何が壊れるかの実例です。スコープは画面上に見えません。設定した当時は通っていた操作が、スコープが外れた版では権限不足で失敗する。失敗して初めて気づく種類の変更であり、認証まわりを含む自動化では、更新のたびに主要な操作が通るかを確かめる手順があると安全です。

2.35.3 の「同一 Instance AI セッション内なら更新承認をスキップ」は、AI が作ったものにどこまで承認を求めるかという設計判断です。毎回承認を求めれば安全ですが、煩雑で使われなくなります。セッション単位で緩めるのは折衷案として妥当で、自社で似た仕組みを設計するときの参考になります。ただし 2.35.3 は pre-release であり、本番環境へそのまま入れる版ではありません。

3日連続でパッチが出ている事実も、そのまま運用判断の材料です。機能リリース直後の版を本番へ即時適用しないという方針の裏づけになります。

副業・個人活用視点

個人で n8n を使っている場合、直接影響するのは Google Ads か Microsoft Teams のノードを使っているときだけです。該当するなら、2.34.6 へ上げれば直ります。

それより効くのは、「動いていたものが自分のせいでなく止まる」という前提を持っておくことです。個人の自動化は、作った本人以外に管理者がいません。止まったときに調べるのも自分です。ワークフローを増やすほど、どこが依存先の変更で壊れうるかを把握しておく価値が上がります。使っているノードを書き出しておくだけでも、障害時の調査時間がかなり変わります。

クライアントワークとしては、n8n の運用保守そのものが商材になるという見方ができます。ワークフローを作って納品して終わり、という形だと、半年後に外部 API の変更で止まったときに誰も対応できません。依存ノードの一覧、リリースノートの追い方、更新の適用基準をセットで設計して渡すと、構築とは別の継続的な仕事になります。今回の Google Ads の件は、その必要性を説明する具体例としてそのまま使えます。

発信のネタとしては、外部 API の sunset で自動化が止まる話が書けます。n8n に限らず、Zapier でも Make でも自作スクリプトでも同じ構造で起きます。「自動化は作って終わりにできない」という主張を、実際のリリースノートの番号付きで裏づけられる記事は、抽象論より説得力が出ます。