AI 業務自動化診断報告書の見本

想定する相談

「これまで動いていた日次集計のn8nフローが、外部サービスのデータ取得で止まるようになった。どこを確認し、何を直せばよいか整理してほしい」

対象範囲

• 対象フロー：外部サービスからデータを取得し、集計結果を社内シートに記録する既存フロー1本
• 対象症状：外部API呼び出しで401が記録され、後続処理が実行されないこと
• 例示する構成：定時起動 → 外部APIから取得 → 集計 → 社内シートに記録

処理名は説明用の呼び名です。n8nの画面表示やエラーメッセージを再現したものではありません。

影響の整理

例示資料に含まれる失敗実行では、集計とシートへの記録が行われていません。そのため、その実行で更新する予定だった集計結果が反映されない状態です。

未反映の期間・件数、別の実行や手作業による補完の有無は未確認です。「全データが失われた」「過去分がすべて未処理」とは判断していません。

以下は、この見本で受領したと仮定する資料です。実際のファイルやログを添付したものではありません。

表は横にスクロールして確認できます。

認証情報は資料から除外します。APIキー、トークン、パスワード、Cookie、認証ヘッダーの値を、報告書や通常のやり取りに貼り付ける必要はありません。画面画像やログに含まれる個人情報・不要な業務データも除外します。

この章の「確認」は、架空の例示資料を読んだ場合の記載例です。実環境での調査・再現テストは行っていません。

例示資料から確認できること

• 資料1では、データ取得処理の後に集計・記録処理が接続されている
• 資料2では、データ取得処理に401が記録され、同じ実行の後続処理は未実行となっている
• 資料3では、対象ノードに認証用設定が選択され、個別ヘッダー欄にも認証に関する指定がある。認証情報の値は除外されているため、両者の内容が同じか、どちらが実際の送信に使われるか、有効な情報かは未確認

HTTPの仕様では、401は対象への要求に有効な認証情報が欠けている場合の応答です。このコードだけでは、期限切れ・失効・認証情報の未送信などを区別できません。RFC 9110 の401の定義

原因候補と確認の順序

資料3で認証に関する指定が二か所に見られるため、最初にその関係を確認します。二か所あること自体を不具合とは断定していません。以下は確認の順序であり、原因の確率や確定順位を示すものではありません。

表は横にスクロールして確認できます。

これらは確認先を示す候補です。採用する認証方式やAPI側の仕様によって、該当しない候補もあります。n8nのHTTP Requestノードにも複数の認証方法があるため、特定の方式への切り替えを一律には勧めません。n8n公式 Authentication の説明

未確認の事項

• 対象APIのサービス名・公式認証仕様と、利用中のn8nのバージョン・稼働環境
• 最後に成功した実行と、最初に失敗した実行の間にあった変更
• API応答本文・応答ヘッダーに含まれる、秘密情報を除いた診断情報
• 実行時に認証情報がどのように適用され、API側で何を理由に拒否されたか
• 未反映のデータ範囲と、安全に再処理できる条件

ここまでの資料では原因を一つに確定できません。追加確認では、各候補を裏づける情報があるかを調べ、不要な設定変更を避けます。

最初に、認証用設定と個別ヘッダー欄の二つの指定を、APIの公式仕様と照合します。 確認結果に応じて、次のように修正方針を選びます。

認証方法や参照先の不一致が分かった場合

対象ノードが正しい認証用設定を参照するようにする、またはAPI公式仕様に合わせて送信方法を修正する案です。二つの認証指定が不要な重複と確認できた場合は、必要な指定に整理します。変更前に、同じ認証用設定を使う他の処理への影響を確認します。

認証情報が無効と分かった場合

サービスの公式手順に従って、再認証・更新・再発行のうち必要な対応を選びます。必要以上に権限を広げず、他の処理で同じ認証情報を使っているか確認してから進めます。

接続先環境との不一致が分かった場合

意図した接続先と、その環境で使用できる認証情報の組み合わせに合わせる案です。本番・検証の区別と、取得するデータの範囲を先に確認します。

追加確認でも原因が絞れない場合

対象ノードの設定、発生時刻、応答コード、秘密情報を除いた応答内容を整理し、API提供元への問い合わせや追加調査に引き継ぎます。問い合わせ文への認証情報の貼り付けは避けます。

いずれも修正案であり、実施済みの作業ではありません。修正の要否・作業範囲・費用は、確認結果に基づいて判断します。

依頼者に確認をお願いすること

1. 対象サービスと稼働環境を教えてください。対象APIの公式資料、n8nのバージョン、本番用か検証用かが分かる情報があると、照合対象を決められます
2. 最後に成功した時点と、その後の変更の有無を教えてください。変更内容が不明な場合は「不明」で構いません
3. サービス管理者に、認証情報の有効状態と接続先環境との対応を確認してください。認証情報そのものの提出は不要です

資料の確認箇所が分からない場合は、秘密情報を含まない画面の範囲で、どこを見ればよいか案内します。

修正担当者への引き継ぎ

• 変更前の設定を復元できるように記録し、他のフローと共有している設定がないか確認する
• 原因候補を確認したうえで、変更箇所を絞る。エラーを無視して後続処理だけを進める対応は、今回の解決策として採用しない
• APIへの送信内容、書き込みや通知などの副作用、利用料金の発生有無を確認し、許可された環境・最小限のデータで試験する
• 認証が通ることだけでなく、必要なデータが取得できること、集計と記録が期待どおりであることを別々に確認する
• 本番の再実行前に、手作業や別実行による記録済みデータと照合し、重複記録を防ぐ。未反映分の再処理は対象範囲を決めて行う

修正後の受入確認では、「401が出なくなった」ことに加えて、対象データが取得され、期待した集計結果が重複なく記録されることを確認します。この見本では、これらの試験は実施していません。