n8n CloudのGateway creditsで外部アカウントなしでモデルとAPIを試す
アカウント作成前に動かすための仕組みと対象範囲
n8nでテンプレートを試したり未知のノードを置いた直後に、外部サービスの登録に進まされることがある。 この回り道は、支払い方法の追加やAPIキー発行、n8n側の認証設定まで含み、探索の腰を折りやすい。 資料は、この初動の摩擦を避ける仕組みとしてGateway creditsを提示している。
self-serviceのn8n Cloudプランで対応ノードを追加すると、ベンダーの資格情報を入力せずに実行できると記されている。 ノード側で自前の資格情報の代わりにGateway creditsを選ぶと、利用はn8n内の前払い残高から差し引かれる。 残高は実通貨で表示され、Cloud Admin Panelでワークフロー別やサービス別に消費を確認できる。 費用は各提供者の公表リスト価格に従う方針で、すべてのレートを事前に確認できる単一の公開ページに並べるとしている。
共有範囲については、選択した提供者に送られるのはリクエスト本文（プロンプトや文書など）であって、利用者の身元情報やn8nアカウントの詳細は含まれないと説明されている。 将来ベンダーと直接の関係に切り替えたい場合は、これまで通り自前のAPIキーを持ち込めるとしている。 Gateway creditsはn8n Assistantを介したプロンプトからの自動化生成にも使え、初回実行までの手順を減らす位置づけである。 また、対象はAIモデル提供者や外部ツールのノードで、現時点で6つのモデル提供者と5つのツールサービスが利用可能と記されている。
料金表示とプラン記述の突き合わせ
ブログ本文は、利便性の対価としての上乗せを目的にしていないとし、各提供者の公表価格に追随する意図と、単一ページでのレート開示を明示している。 この方針により、実行前に見積もり可能な状態を用意することを強調している。 いっぽうで、どのプランでこの仕組みが有効かは前提として押さえる必要がある。
価格ページの記載では、Hosted by n8nのStarterとProに「AI models without API keys」とともに月次のAssistant creditsが含まれるとある。 具体的にはStarterで1,600、Proで最大9,600のAssistant credits/月と書かれている。 ここでブログが用いる「Gateway credits」と、価格ページの「Assistant credits」の呼称は一致していない。 両者が同一の残高を指すかを資料は断言していないが、APIキー不要でAIモデルを使える枠として連続した説明になっている。
また、ブログはself-serviceのn8n Cloudを前提とする一方で、価格ページではBusinessにSelf-hostedの注記が見られる。 この読み替えから、Gateway creditsの適用範囲はクラウドプランに限られると理解するのが安全で、Self-hostedのみの構成では同様の扱いを当然視しないほうがよい。 提供者ごとのレートはn8n側の公開ページを基準に確認する前提で運用設計を立てたい。
共有されるデータとコスト把握の実務への影響
データ共有の範囲は、プロンプトや入力文書などのリクエスト本文が提供者に渡り、利用者の身元やn8nアカウント情報は送られないと資料は述べている。 したがって、本人特定情報の拡散リスクは抑えやすいが、入力内容そのものは第三者に処理されるため、送信データの分類や削除方針をチームで明確にする必要がある。 監査の観点では、n8n側のパネルでワークフロー別やサービス別に消費を見られる点が、原因調査や費用の配賦に役立つ。
運用負荷の面では、共有の前払い残高を用いることでベンダーアカウントや請求書の点数が減ると資料は示している。 既存ワークフローでもモデルやツールの差し替え実験が容易になり、実務の検証速度が上がる余地がある。 ただし、提供者やモデルの違いでレートや応答特性が変わるため、実行前にn8n側のレート表で単価を見直し、想定コストの逸脱を抑えたい。 コストの可視化とデータ送信の前提を同時に満たす設計が、試行の自由度とガバナンスの両方を担保する。
どの場面で使い、どこで自前のキーに戻すか
Gateway creditsを使う価値が高いのは、テンプレートの評価や短時間の検証、少人数のチームがまず一度動かしたい場面である。 新規のベンダー登録やAPIキー管理を保留したまま、ノードの出力品質や前後処理の整合を確かめられる。 共有残高と実通貨表示、ワークフロー別の消費確認により、検証の繰り返しでも費用を追いやすい。
自前のAPIキーを選ぶ条件は、提供者との直接契約が求める統制や割引がある場合である。 たとえば、提供者側の組織ポリシー、地域別のデータ処理、専用の請求やボリュームディスカウント、提供者の監査ログを必須要件にしているときは自前のキーが適する。 また、Gateway creditsの対象外ノードやSelf-hosted主体の構成では、従来の資格情報の設定が前提になる。 最初はGatewayで着手し、要件が固まった時点で一部のノードだけ自前のキーに段階移行する進め方が、実装と統制の両立に向く。