Box連携プラグインの弱点「署名の自動反映」をn8nで補う！kintone×Box連携で契約管理を自動更新する仕組みを紹介

Box連携プラグインを入れれば、Box Signの署名完了もkintoneに反映されると思っていないか

契約書のやり取りを電子署名に切り替えると、押印や郵送の手間が一気に減ります。Box Signを使えば、Boxのなかで追加費用なしに署名依頼から締結まで完結できるからです（プランによって月あたりの署名リクエスト数に上限がある点は、あらかじめ確認しておくと安心でしょう）。

ただし、この署名完了をkintoneと連携させて契約管理に反映するには、もうひと工夫が要ります。

ここで、Box連携プラグイン for kintoneを導入済みの方、あるいは導入を検討している方は、こう考えていないでしょうか。「Boxとkintoneはプラグインでつながっているのだから、Box Signの署名が終われば、kintoneの契約管理アプリも自動で締結済みになるはずだ」と。

ところが、実際にやってみると署名が終わっても契約レコードは動きません。締結済みのステータスに変えるのは、あいかわらず担当者の手作業です。

プラグインを入れている（入れる予定な）のに、なぜ署名完了だけはkintoneに反映されないのでしょうか。この記事では、その「プラグインの守備範囲の外」をどうやってkintoneへ連携させるかを扱います。なぜ反映されないのか、どこで詰まるのか、どう乗り越えるのかを順番に見ていきます。

プラグインが扱わない署名完了イベントは、n8nで受けてkintoneに反映できる

先に結論からお伝えしましょう。Box Signの署名が完了すると、対象の契約レコードのステータスが自動で「締結済み」に変わり、署名日と完了後のPDFの参照までまとめて記録される。ここまでを人がkintoneに触らずに実現できます。

kintone box 連携の全体像。Box Signの署名完了をWebhookでn8nが受けkintone契約管理を締結済みに自動更新するフロー図

仕組みはシンプルです。Box連携プラグインが扱わない「署名が完了した」というイベントを、連携ツールのn8nがBoxから通知として受け取り、その内容をkintoneの契約レコードへ書き込みます。プラグインを置き換えるわけではありません。プラグインの守備範囲の外側だけを、n8nで補う形です。

大がかりなシステム開発を発注する必要はなく、n8n側の設定とkintoneの更新処理を組むだけで実現できます。ただし、これは「どの契約レコードを更新するのかを特定できていること」と「同じ通知で二度更新しないこと」の2か所を押さえていればの話です。

この2か所を知らずに始めると、署名は完了しているのにレコードが動かなかったり、逆に二重に締結済みになったりします。詰まる場所を先に知っておけば、遠回りせずに組めるでしょう。

プラグインの守備範囲（ファイル連携）と、その外側（署名イベント）を切り分ける

署名完了の反映だけが手作業で残るのは、Box連携プラグイン for kintoneが担っている役割に理由があります。

このプラグインが提供するのは、レコードに紐づくBoxフォルダの自動作成、添付ファイルのプレビュー表示、社外共有用リンクの発行といった機能です。いずれもBoxの「ファイル・フォルダ」をkintoneレコードに結びつける役割を担っています。

契約書というファイルの保管や共有については、これで十分に回るでしょう。

一方で、「署名が完了した」というのはファイルの話ではなく、業務上の出来事（イベント）です。Box Signで署名が終わった瞬間に何かを起こすという動きは、ファイル・フォルダを扱うプラグインの役割の外にあります。だから署名完了の反映だけが、プラグインの外に取り残されて手作業で残るのです。

この手作業が残ると、契約管理の一覧は署名の実態から少しずつずれていきます。締結済みかどうかを人が読み取って書き写している限り、書き忘れや取り違えは避けられません。

たとえば、署名を依頼しただけでまだ相手方の署名が完了していない契約を、締結済みと同じように扱ってしまう場合があります。そのまま取引開始や製造手配などの後続を進めてしまえば、契約が成立しないままリスクを抱えることになるでしょう。

署名の完了状況を人の注意力ではなく仕組みで反映できれば、一覧は常に実態と一致し、契約進捗をそのまま信頼できる状態になります。

kintone box 連携の役割分担図。ファイル連携はBox連携プラグイン、署名完了イベントの反映はn8nが担う切り分け

ここで一つ、先に切り分けておきたい点があります。この連携は、API連携やWebhookの設定にある程度慣れた担当者であれば手が届く範囲の作業です。ただし、技術的に実現できることと、社内で手を動かす時間を確保できることは別の話でしょう。時間や体制の面で判断がつかない場合の相談先は、記事の最後で案内します。

プラグインの外側を埋めようとして、更新先の特定と二重通知で止まった

「署名完了の通知さえ受け取れれば、あとはkintoneを更新するだけだろう」。そう考えて着手したものの、まずプラグインの設定だけで済ませられないかをたしかめ、それでも残った本題の2か所で手が止まりました。踏んだ順に開示します。

プラグインの設定画面を開き、署名完了で動く項目を探して回った

わざわざ連携ツールを持ち出さなくても、プラグインの設定だけで完結できないか。まずそれをたしかめるために、設定画面を開き、署名が完了したときにレコードを動かせる項目がないかを探して回りました。

見つかったのはフォルダやファイルに関する項目ばかりで、署名完了をきっかけにステータスを変えるような設定はどこにもありません。ここで、プラグインの中だけで解決する道はないと判断し、外側を補う方針に切り替えました。

下の画面が、実際に開いたプラグインの設定です。並んでいるのはフォルダ作成やプレビュー、共有リンクといったファイル・フォルダに関する項目ばかりで、署名の完了を合図にステータスを動かすような設定は見当たりません。

署名完了の通知だけでは、kintoneのどの契約か特定できない

次の詰まりは、通知を受け取ったあとに来ました。Box Signは署名が完了すると、その署名依頼（sign request）に関する情報を通知として渡してくれます。ところが、この通知だけでは「kintoneのどの契約レコードを更新すればよいのか」が分かりません。

通知に含まれるのは、あくまで「どの署名依頼が終わったか」という署名依頼側の情報だけです。kintoneの契約レコードとの結びつきは、こちらが最初に仕込んでおかない限り、通知のどこにも入っていません。

案件番号のような手がかりを署名依頼に持たせずに送ってしまうと、完了通知が来ても更新先を決められず、そこで止まってしまいます。

同じ完了通知が二重に届き、契約レコードが二度更新される

3つ目が、一番気づきにくい詰まりです。通知の仕組み（Webhook＝Boxからの通知を受け取る仕組み）は、ネットワークの都合で同じ「署名完了」を複数回送ってくることがあります。

これを何も考えずに受けると、同じ契約を二度「締結済み」に更新してしまいます。署名日が上書きされたり、あとから見返したときに記録が食い違ったりと、静かに事故が起こるのです。

しかも通知が二重に来ていること自体に気づきにくいため、原因の切り分けに時間がかかりました。

プラグインと役割を分け、n8n側で確実に1回だけ更新する

ここから先は、ファイル連携はプラグインに任せたまま、署名完了の反映だけをn8nで組み立てます。前の章で開示した詰まりに、一つずつ対策を当てていきましょう。

なお、n8nそのものが初めての方は、先に【超入門】n8nとは？kintoneと生成AI連携のはじめかたに目を通しておくと、以降の話が入りやすくなります。

まず、これから組むワークフローの全体像です。Box Signの署名完了の通知を左端で受け取り、右へ向かう一本道のなかに、これから説明する2つの対策（更新先の特定と、一度だけ処理する仕組み）が、そのままノードとして並びます。全体像を先に押さえておくと、それぞれのノードが何のためにあるのかを見失わずに組めるでしょう。

署名依頼に案件番号を外部参照IDとして持たせ、更新先を一意にする

更新先が特定できない問題は、署名依頼を作る段階で先回りして解決しましょう。Box Signの署名依頼には、外部システムのIDを紐づけるためのフィールド（external_id）が用意されています。ここに、kintoneの契約レコードを一意に指し示す案件番号を入れておきましょう。

こうしておけば、署名完了の通知にこの案件番号が乗って返ってくるため、n8n側は「どの契約レコードを更新すればよいか」を迷わず決められます。external_idを使わずに、ファイル名やフォルダ名の命名規則で紐づける方法もありますが、あとから見て分かりやすいのは、番号を明示的に持たせておくやり方でしょう。

下の画面は、署名完了の通知に乗って返ってきた外部参照ID（external_id）から、更新先の案件番号を取り出しているノードの中身です。ここで取り出した番号で、kintoneの該当する契約レコードを検索します。

n8nのWebhookで受け、sign_request.idで同じ通知を一度だけ処理する

二重通知への対策は、n8nの入り口で行います。まず、Box Signの署名完了を受け取る窓口をn8nのWebhookノードで用意し、同じ通知が二度来ても一度しか処理しない仕組みを入れておきましょう。

具体的には、署名依頼には一件ごとに固有のID（sign requestのid）が振られているので、これを「処理済み」として控えておきましょう。通知が届いたら、まずこのIDを照合し、すでに処理済みなら何もせずに終えるようにします。初めて見るIDのときだけ、この先の更新処理に進む形です。

下の画面が、その判定を担うノードの中身です。届いた署名依頼のID（sign requestのid）を処理済みとして控えておき、同じIDが再び届いたら、その先へは進めずに、ここで止めています。

こうしておけば、通知が何度届いても契約レコードが二度更新されることはありません。

n8n kintone連携の勘所2点。案件番号を外部参照IDで持たせ更新先を特定し、署名依頼IDで二重更新を防ぐ対策図

署名者・完了日時・完了PDFを取得して契約レコードに記録する

更新先が決まり、二重処理も防げたら、最後に記録します。署名完了の通知をもとに署名依頼の詳細を取得すると、以下を受け取れます。

  • 署名した相手（signers）
  • 全員の署名が終わった完了日時（finished_at）
  • 署名済みのPDF（sign_files）

これらをn8nからkintoneの契約レコードへ書き込みましょう。ステータスを「締結済み」に更新し、あわせて署名日と完了PDFの参照も残します。こうすれば一覧を見るだけで、締結の事実とその証跡（いつ・誰が署名し、どのPDFが正本か）がそろった状態になるのです。

下の2枚は、この仕組みを検証環境で動かす前と、動かした後の、同じ契約レコードです。動かす前はステータスが「署名依頼中」で、署名日・署名者・完了PDFはいずれも空でした。署名完了の通知が届いて処理が走ると、ステータスが「締結済み」に変わり、署名日と署名者、完了PDFの参照までが自動でそろいます。この間、担当者はkintoneに一度も触れていません。

【実装担当向け】Webhook受信は署名検証で守る

実装を担当する方向けの補足になります。読み飛ばしても、この記事の理解には支障ありません。

n8nでWebhookの窓口を公開すると、そのURLは仕組みのうえでは誰でも呼び出せてしまいます。Boxから届いた正当な通知だけを受け付けるために、通知に付いてくる署名を検証する処理を入れておきましょう。

Webhook連携のセキュリティについては、n8nとkintoneを安全に連携！n8nの強力なセキュリティの仕組みを解説で詳しく解説しています。

プラグインとn8nで役割を分ければ、署名から管理まで手作業なしでつながる

ここまでを振り返ると、やっていることは役割分担です。ファイルの保管や共有はBox連携プラグインに任せ、プラグインが扱わない署名完了イベントの反映だけをn8nが引き受けます。この二つを分けて組み合わせるだけで、署名の完了から契約管理の更新までが、人の手を挟まずにつながるのです。

そして、詰まる場所は無限にあるわけではありません。押さえるべきは「どの契約レコードを更新するか（案件番号による特定）」と「同じ通知で二度更新しないか（一度だけ処理する仕組み）」の2か所だけです。この2か所を先に知っておけば、残りは素直に組み上がるでしょう。

最後に、もう一度だけ切り分けておきます。ここで説明したのは、技術的にどう実現するかという話です。

実際に自社で組むとなると、Box Signの署名運用や契約管理アプリの構造は会社ごとに違いますし、誰がその手を動かすかという体制の問題も出てきます。技術的に可能かどうかと、社内でそれを回せるかどうかは、分けて考える必要があるでしょう。

自社の契約管理アプリや署名の運用にあわせて、どう設計すればよいか判断がつかない場合は、ものづくりAI自動化ファクトリーで無料相談を受け付けています。詰まりやすい場所を踏まえたうえで、実際に回せる形まで一緒に考えましょう。

まとめ

Box Signで電子署名を導入しても、その署名完了をkintoneに反映する最後の一手が手作業のままだと、契約管理の一覧は少しずつ実態からずれていきます。Box連携プラグイン for kintoneはファイルとフォルダの連携を担う機能であり、署名完了というイベントはその守備範囲の外にあるからです。

この外側を、n8nがBox Signの署名完了通知を受け取って埋めれば、契約レコードのステータス・署名日・完了PDFまでが自動でそろいます。ファイル連携はプラグイン、署名イベントの反映はn8nと役割を分けることで、署名から契約管理までが手作業なしにつながり、締結状況の可視性を仕組みで担保できるでしょう。

関連記事