【ITニュース解説】The Wait Node Is the Easy Part: 6 Ways an n8n Human-Approval Step Breaks (and the .NET Fixes)

今日のITニュースでは、AIが生成したコンテンツを人間が確認し、承認してから公開するまでのプロセスに潜む意外な落とし穴と、それをどう防ぐかについて解説する。自動化ツールであるn8nと、それと連携するウェブAPIを使って、大規模言語モデル（LLM）が作った記事のドラフトを人間が承認する仕組みを構築する場合、一見簡単に見える「人間が承認する」という部分が実は複雑で、多くの問題が発生しやすい。この解説では、システムエンジニアを目指す初心者の皆さんにも分かりやすいように、その課題と解決策を具体的に説明していく。

このシステムでは、まずn8nというワークフロー自動化ツールが、LLMを使って記事のドラフトを作成する。次に、そのドラフトをウェブAPIに送り、n8nは一時停止して人間の承認を待つ状態になる。人間はAPIの画面を通じてドラフトを確認し、承認、却下、または修正依頼のいずれかの決定を下す。APIはその人間の決定をn8nに通知し、n8nは通知された決定に基づいて記事を公開したり、再編集を促したり、停止したりする。つまり、n8nが全体の流れを管理し、APIが人間の決定を管理するという役割分担になっている。この「n8nとAPIの間でのデータのやり取り」が特に難しく、予期せぬ問題を引き起こしやすい部分である。

一つ目の問題は、データの送り主の認証が壊れることだ。n8nからAPIへドラフトを送る際、悪意ある第三者からの偽装を防ぐため、データに「署名」を付けて送るのが一般的だ。この署名は、データが改ざんされていないか、そして確かに正規のn8nから送られてきたものかを確認するための重要な仕組みである。しかし、n8nがデータをJSON形式で署名する際と、それをHTTP通信で送る際に、データの形式が微妙に変わってしまうことがある。例えば、空白の入り方やデータの順番が変わるだけで、署名の計算結果が異なり、API側で「偽物だ」と判断されてしまうのだ。こうなると、送り主が正しくても認証に失敗してしまう。この問題の解決策は、n8n側でJSON形式の文字列を一度だけ完全に作り上げ、その完成した文字列に対して署名を計算することだ。そして、API側では、受け取ったデータを一切加工せず、生のバイト列のままで署名が正しいかを確認する。これにより、署名と検証の対象となるデータが完全に一致し、認証が失敗するのを防げる。

二つ目の問題は、一度送られた有効なデータが、時間に関係なく何度でも再利用されてしまうことだ。データに署名がついていても、それは「誰が送ったか」を証明するだけで、「いつ送られたか」までは保証しない。もし悪意のある第三者が、正規のn8nから送られた署名付きのデータを盗み取った場合、それを何日後、何週間後でも好きな時にAPIに送りつけ、正規のリクエストであるかのように見せかけることができてしまう。この問題の解決策は、署名に「タイムスタンプ」、つまりリクエストが送られた時刻の情報を組み込むことである。具体的には、データ本体だけでなく、そのデータを送った時刻も一緒に署名する。そしてAPI側では、受け取ったデータのタイムスタンプが、現在の時刻から一定の短い時間範囲内（例えば5分以内）に収まっているかを確認する。もし古すぎるデータや、未来の時刻が設定されたデータであれば、たとえ署名が正しくても不正なリクエストとして拒否する。これにより、盗み取られたデータが後で再利用されるのを防ぐことができる。

三つ目の問題は、n8nの再試行機能によって、同じドラフトが複数回作成されてしまうことだ。n8nは、ネットワークの不具合などでAPIへの通信が失敗した場合に備えて、通常は自動的にリクエストを何回か再試行するように設定されている。しかし、もしAPI側では一度ドラフトが正常に保存されたにもかかわらず、その後の「保存しました」という応答がネットワークの途中で失われてしまった場合、n8nは応答がないため「失敗した」と判断し、同じドラフトをもう一度APIに送ってしまう。結果として、APIには同じ内容のドラフトが二つ保存され、レビュー担当者は混乱してしまうことになる。この問題の解決策は、「べき等性キー（idempotency key）」という仕組みを使うことだ。これは、n8nが同じリクエストを再試行する際に、常に同じ一意の識別子（キー）をリクエストに含めて送るようにする仕組みである。API側では、このキーを受け取ると、まずそのキーを持つドラフトが既に存在するかどうかを確認する。もし同じキーのドラフトが既にあり、内容も同じであれば、それは単なる再試行と判断し、新たにドラフトを作成せずに、既に保存されているドラフトの情報を応答として返す。もし同じキーのドラフトが存在するが、内容が異なる場合は、これは何らかのバグとして衝突（コンフリクト）エラーを返す。これにより、同じドラフトが複数回作成されることを防ぎ、常に一度だけ処理されるように保証できる。この「キーの確認と保存」は同時に行われる必要があるため、データベースでは一意制約などを使って安全に処理される。

四つ目の問題は、複数のレビュー担当者が同時に決定を下した際に、どちらの決定が最終的なものになるか分からないことだ。例えば、一人のレビュー担当者が「承認」ボタンを押した瞬間に、別の担当者が「却下」ボタンを押すといった状況が考えられる。このような場合、特別なルールがなければ、最後にAPIに到達した決定が採用されてしまい、どちらか一方の意図しない結果になるか、あるいはn8nが異なる決定で複数回再開されてしまう可能性がある。この問題の解決策は、ドラフトの状態を管理する「ステートマシン」の考え方を導入することだ。ドラフトは「承認待ち」の状態から、「承認済み」「却下済み」「修正依頼中」のいずれかの最終的な状態に一度だけ遷移できる、というルールを明確に定める。一度最終的な状態に移行したら、それ以降は状態を変更できないようにする。例えば、一度承認されたドラフトを後から却下することはできない。また、レビュー担当者がテキストを編集して承認する場合にのみ、その編集が有効になるようにしたり、「修正依頼」の場合には必ず具体的なコメントを要求したりするなど、細かいルールも設ける。これにより、複数の決定が競合しても、常に一貫した状態と結果が保証される。

五つ目の問題は、人間の決定をn8nに通知する「コールバック」が失敗し、決定が失われてしまうことだ。レビュー担当者がドラフトを承認し、APIがその決定を受け取ったとする。しかし、その直後にAPIがn8nへ決定を通知しようとした際、n8nが再起動中だったり、一時的に利用できなかったりして、通信が失敗することがある。もしAPIが決定を保存する前に通知だけを行ってしまうと、通知が失敗した時点で人間の決定が無かったことになり、レビュー担当者もその事実を知ることができない。この問題の解決策は、「まず保存、次に通知」という手順を徹底することだ。つまり、人間の決定を受け取ったら、まずその決定内容をAPIのデータベースなどに確実に保存する。その後、保存された決定に基づいてn8nへの通知を行う。通知が失敗した場合でも、決定自体は保存されているため、後から手動で、または自動的に再試行することが可能になる。APIからn8nへの通知は、何度か自動で再試行する仕組み（リトライハンドラ）を組み込み、それでも失敗した場合は、その状況（失敗したこと、エラー内容など）をドラフトの記録として残す。必要であれば、保存されている決定をもう一度n8nへ送り直すための専用の機能も用意することで、決定が失われるのを防ぐ。

六つ目の問題は、APIがn8nから渡された任意のURLに対して、無制限にアクセスしてしまう危険性だ。n8nからAPIへ送られるドラフトのデータの中には、「承認されたらこのURLに通知してください」というn8nのコールバックURLが含まれている。しかし、もしこのシステムが悪意のある第三者によって操作され、悪質なURLが仕込まれてしまった場合、APIは攻撃者の意図する任意のウェブサイトや、内部のシステムにまでアクセスしてしまう可能性がある。これはセキュリティ上の重大な脆弱性となる。この問題の解決策は、「許可されたURLのリスト（allow-list）」を導入することである。API側で、通知先として許可されているn8nのホスト名やURLのプレフィックス（URLの先頭部分）を事前に設定しておく。そして、n8nから受け取ったコールバックURLが、この許可リストに含まれていない場合は、そのリクエスト自体を不正なものとして拒否する。さらに、通知時に追加の認証情報をヘッダーに含めることで、もしURLが正しくても認証なしではアクセスできないようにする。また、コールバックURLは非常に機密性の高い情報なので、外部に公開されるレビュー担当者向けの画面などには決して表示しないよう細心の注意を払う。

これらの対策を講じることで、ようやく人間が承認する自動化パイプラインを安全に運用できるようになる。実際にシステムを開発する際には、これらの問題が本当に解決されているかを徹底的にテストすることが不可欠だ。例えば、署名が一つでも文字が変わったら失敗するか、古いデータが拒否されるか、同時に複数の決定が行われても一貫した結果になるか、といった点を、様々な状況をシミュレートして確認する必要がある。また、人間の承認フローには、最大で何回まで修正依頼を受け付けるかといった「ループ回数の制限」を設けることも重要だ。これらの点を事前に確認するためのチェックリストを作成し、開発の各段階でクリアしているか検証することで、より堅牢で信頼性の高いシステムを構築できる。AIが生成したコンテンツを公開する責任を人間が担う以上、そのプロセスが安全で確実であることが最も重要なのである。