自動化の診断書

自動化は、静かに止まります。

認証が切れる。誰かが API のキーを更新する。公開中のワークフローに、失敗の通知先が設定されていない。思ったより多く、実行されている。どれも、お客様や、使っている人に気づかれるまで、作った本人は知りません。

このサイトの試験の中でも、同じ週に、こんなことが起きました。

• Google スプレッドシートの認証が切れて、書き込みが止まった（再接続が必要になった）
• Chatwork の認証で、Bearer を付けて、401 になった
• Gmail の認証も、同じ週に切れていた（これは、あとで、診断が見つけるまで、気づきませんでした）

そこで、自動化を見張る自動化を作りました。

• 毎朝、7つのサービスの認証が、まだ通るかを、1回ずつ試す
• 手で入れた期限（API キー、ドメイン）が近づいたら、知らせる
• 毎週、n8n の API で、ワークフローごとの実行回数、失敗、急な増加、月の予測を、まとめる
• 公開中のワークフローの穴（失敗の通知先がない、認証のない Webhook、ノードの中の秘密のような文字列）を、一覧にする
• AI は使いません。 軽い呼び出しと、計算だけです

automation-checkup.json をダウンロード

n8n 公式のテンプレートへの提出は、まだしていません（審査中の枠が空いたので、提出するかどうかを決めます）。提出したら、結果を、この記事に書きます。

毎朝：認証の健康診断

次の7つに、費用のかからない、読み取りだけの呼び出しを、1回ずつ試します。

サービス	試す呼び出し
Chatwork	自分のアカウントの情報（/me）
LINE	ボットの情報
Slack	auth.test
Anthropic	モデルの一覧（1件）
Gemini	モデルの一覧（1件）
Google スプレッドシート	スプレッドシート1つの、メタ情報だけ
Gmail	自分のプロフィール

判定は、次のとおりです。

• 200番台：正常
• 401 や 403：認証が無効、期限切れ、または権限が足りない
• 429 や 5xx：警告（回数制限や、相手側の障害。認証そのものは、無事かもしれない）
• 応答がない：n8n 自身のエラー文を、そのまま出す（たとえば、「The credential “Gmail account” needs to be reconnected」）

失敗は「結果」として扱い、「エラー」にしません。 1つの認証が壊れていても、ほかの6つの確認は、止まりません。

Slack は、認証が無効でも、200 を返し、本文の ok: false で伝える、と理解しています（Slack の公式の説明による理解です。この試験では、悪い Slack のトークンでは、確かめていません）。そのため、Slack だけは、本文まで見て判定します。

手で入れた期限も、一緒に見ます。たとえば、「Anthropic の API キーは、2026-10-27」「ドメインの更新は、2027-09-01」のように、設定のノードに書いておくと、14日前から知らせます。

何もなければ、静かにしています（毎日の「異常なし」は、読まれなくなるので）。月曜だけ、「全部正常」と知らせます。

毎週月曜：実行回数と、棚卸し

n8n の API で、全ワークフローと、残っている全実行を読みます。

実行回数

• ワークフローごとの、直近24時間、7日、30日の実行回数
• 失敗の数
• 急な増加： 直近24時間が、その前の7日の1日あたりの平均の3倍以上（20回以上のとき）
• 月の予測： 直近7日を、30日に延ばしたもの（予測であって、実測ではありません）
• AI 呼び出しの上限の目安： 実行回数 × そのワークフローの AI ノードの数。実際に、全部のノードが動くとは限らないので、上限です
• いちばん古い実行の日付： n8n は、古い実行の記録を消すので、30日の数は、この日以降の分しか、含みません

棚卸し

• 公開中なのに、失敗の通知先（エラー用ワークフロー）が設定されていないもの
• 公開中で、認証のない Webhook があるもの（署名を、自分で確認する作りなら、問題ありません）
• ノードの中に、秘密のように見える文字列（Slack、Anthropic、OpenAI、Google、GitHub のトークンの形）
• 公開中なのに、一度も動いていないもの

実際に動かした結果

自分の n8n（2.36.8、パソコンの中で動かしているもの）で、動かしました。

毎朝の診断

• 作った直後の1回目の実行で、Gmail の認証が「再接続が必要」と出ました。 Chatwork、LINE、Slack、Anthropic、Gemini、Google スプレッドシートの6つは、正常でした。
• わざと間違ったトークンを渡した Chatwork は、「401：認証が無効、期限切れ、または権限不足。再接続か、再発行を」と報告されました。

毎週の報告（62本のワークフロー。ほとんどは、試験で作った、公開していないものです）

• 直近7日で163回の実行（24時間で82回）。このままだと、月に約699回
• いちばん多かったのは、通しの試験のために公開して動かした、テスト2本（24時間で、38回と35回）。「急な増加」として、検出されました。Slack のボット自身の投稿でも動くため、と考えられます（この2本で、原因までは調べていません）。前に測った「1通あたり約3回」とは、矛盾しません
• 公開中の2本は、どちらも、失敗の通知先がありませんでした。認証のない Webhook も、どちらにもありました（LINE の署名を、自分で確認する作りです）
• ノードの中の、秘密のように見える文字列は、0件（このテンプレート自身も、含めて）
• 残っている、いちばん古い実行の日付は、2026-09-27でした

つまずいた3つと、直し方

1. 実行の取得で、「limit は 250 以下」のエラー

n8n の標準ノードで、実行を取るとき、「件数の指定」を使うと、250件を超える数は指定できません（request/query/limit must be <= 250 という 400 のエラーになります）。「全件を取る」にして、直しました。 実行の記録が多い n8n では、読むのに時間がかかるかもしれません（この試験は、数百件です）。

2. API の接続先を空にして、「Couldn’t connect」

n8n の API の認証情報で、接続先（Base URL）の欄の薄い文字は、入力例であって、値ではありません。 空のまま保存すると、「Couldn’t connect with these settings」になります。自分の n8n の場合は、http://localhost:5678/api/v1 のように、自分で入れます。

3. 「30日」の数が、思ったより小さい

n8n は、古い実行の記録を、自動で消します。そのため、「直近30日」の数は、実際より小さく出ます。この診断は、いま残っている、いちばん古い実行の日付を、一緒に出して、「30日の数は、この日からの分だけです」と書きます。

使うための設定

1. n8n の API キーを作る

n8n の「Settings → n8n API」で、API キーを作ります。次の3つを、守ってください。

• 名前を付ける（用途が分かるもの）
• 有効期限を付ける（「なし」にしない。切れる日は、診断の期限の一覧に足す）
• 権限は、読み取りだけにする（ワークフローと実行の、一覧と読む）

そのあと、「Credentials」で、「n8n API」の認証情報を作ります。Base URL を、必ず、入れてください（上の「つまずいた2」）。

2. 使う確認だけを残す

7つの確認のノード（Check …）で、自分の認証情報を選びます。使わないサービスの確認は、ノードごと削除してください。 削除したノードは、報告から自動で外れます。

3. Slack と、設定

• Slack のノードが2つ（認証の報告、実行回数の報告）。チャンネルを選びます。ボットは、そのチャンネルに招待しておきます
• 「Credential settings」：スプレッドシートの ID を1つ（その認証で開けるもの）、期限の一覧
• 「Usage settings」：月の実行回数の上限（お持ちの料金プランの数字）、急な増加と失敗のしきい値

4. 公開する

公開したら、2つの「Run now」で、すぐに報告を見られます。

使う前に知っておくこと

• 「通る」ことしか、確かめません。 読み取りの権限があっても、書き込みの権限がない、という場合は、見つけられません
• 月の予測は、直近7日の延長です。 週末や、月末に偏る処理は、外れます
• どの実行が、料金の「実行回数」に数えられるかは、確かめていません。 初期設定では、手動の実行は数えません。お持ちのプランの数え方に合わせて、設定を変えてください
• 全ワークフローの中身を読みます。 私の62本で、実行の記録に残るデータが、約1MBになりました。ワークフローが非常に多い n8n では、時間がかかるかもしれません
• 秘密の検出は、挙げた形だけです。 見慣れない形の秘密は、見つけられません
• n8n の API キーは、このワークフローの入口になります。 権限を、読み取りだけにして、期限を付けてください

確認していないこと

• 読み取りだけの権限（ワークフローと実行の、一覧と読む）で、動くか。 私は、作ったキーの権限の内訳を、確かめていません。権限が足りないときは、403 になります
• n8n クラウド。 自分のパソコンで動かす n8n（セルフホスト）だけで試しました。クラウドの Base URL は、認証情報の入力例にある https://<名前>.app.n8n.cloud/api/v1 の形のはずですが、試していません
• 悪い Slack のトークン。 上に書いたとおり、Slack の公式の説明による理解だけです
• 確認のノードを削除したときの動き。 コードは、ないノードを飛ばす作りですが、削除して動かす試験は、していません
• ほかのサービス。 7つ以外は、自分で、確認のノードを足す必要があります
• ワークフローが数百本ある n8n。 試したのは、62本です

次に読む

• 失敗したときの通知先を作るなら n8n のエラーワークフロー
• n8n の実行回数の数え方と、実際の費用なら n8nの料金と実際の費用
• 同じ「確かめる」考え方を、AI の出力に使った例なら Chatwork の記録をシートへ
• 同じ考え方を、LINE と Slack で使った例なら LINE×Slack 学習する窓口