社外からアップされたファイルを見落とさない。Box Webhookとn8nで自動検知・記録するワークフローを紹介！

社外のサプライヤーと発注書や納品書類をやり取りするとき、Boxの共有フォルダを窓口にしている会社は多いはずです。案件の管理はkintoneで、ファイルの受け渡しはBoxで、という組み合わせはよく見かけます。

上がっていたはずの修正版に気づかず、古い版のまま手配を進めてしまった。そんなヒヤリとした覚えのある方もいるのではないでしょうか。

その原因は、この組み合わせにある片方向の穴です。kintoneに保存したファイルを社外へわたすことはできても、社外がBoxに上げたファイルをkintoneへ自動で記録する機能は、Box連携プラグインに用意されていません。上げてもらった事実を残すかどうかが、担当者の手作業と注意力にゆだねられたままになります。

この記事では、その足りない「Box→kintone」方向を、Box Webhookとn8nでどう埋めるかを、自社の検証環境で試した内容をもとに解説します。実装でつまずく場所は3か所に絞れます。そこを先に押さえ、実装の体制を整えられれば、社外がファイルを上げた瞬間に、kintoneの案件レコードへ自動で記録し、Teamsへ通知するところまで組み上げられます。

kintone box 連携を入れているのに、社外がBoxに上げたファイルはなぜkintoneに載らないのか

まず、よくある運用を思い浮かべてください。社外のサプライヤーとは、Boxの共有フォルダで発注書や納品書類をやり取りしています。案件そのものはkintoneのレコードで管理し、Boxとの連携プラグインも導入済みです。

この状態だと、「連携しているのだから、社外が上げたファイルもkintone側に自動で載っているはずだ」と考えるのは自然でしょう。「連携」という言葉が、双方向のやり取りを思い浮かべさせるからです。

ところが実際には、社外がBoxに書類を上げても、kintoneには何も表示されません。担当者が自分でBoxのフォルダを見に行き、「いつ・誰が・何を上げたか」を確認して、kintoneの案件レコードへ手で書き写しています。忙しい時期には、この確認と書き写しがまるごと抜け落ちます。

なぜ、連携プラグインを入れているのに、この手作業が残ってしまうのでしょうか。

社外がBoxにアップした瞬間、kintoneの案件レコードに自動記録してTeamsへ通知できる

kintone box 連携の全体像。社外のBoxアップロードをWebhookで検知し、n8n経由でkintoneに自動記録・Teams通知する流れの図

先に到達点をお見せします。今回組んだ仕組みでは、社外がBoxの共有フォルダにファイルを上げた瞬間に、そのファイルの情報がkintoneの該当案件レコードへ自動で記録されます。 あわせて、担当者のTeamsにも通知が飛びます。

記録される情報は、ファイル名・アップロードした人・日時・フォルダ・共有リンクです。人がBoxを見張っていなくても、上げてもらった事実がkintone側にそのまま履歴として残ります。

案件レコードには、受け取ったファイルを記録するフィールドをあらかじめ用意しておきます。記録前は空だったこのフィールドに、社外がファイルを上げると情報が自動で追加されます。

使ったのは、kintoneのBox連携プラグインと、外部の連携ツールであるn8nの組み合わせでした。

ここで押さえておきたいのは、Box連携プラグインが担うのは「kintone→Box」方向だけだという点です。kintoneに保存したファイルの共有リンクを社外へわたす用途には対応しています。ただし、その逆の「Box→kintone」方向、つまり社外が上げたファイルを検知して取り込む用途は含まれていません。

足りない半分は、Box Webhookとn8nで補います。

kintone box 連携の方向。プラグインはkintone→Box方向のみ、Box→kintone方向はBox Webhookとn8nで補うことを示す図

なぜ「手で確認して転記する」が今も残ってしまうのか

自動化に価値があるのは、コスト削減のためではなく、業務の運用そのものが変わるからです。

社外から受け取ったファイルを記録するかどうかが、いまは担当者の意志にゆだねられています。記録が人の注意力に依存しているため、忙しいと抜けます。 抜けたことに気づけるのは、たいてい後になってからです。

たとえば、社外が上げた修正版に気づかず、旧版のまま手配を進めてしまう、といった事態です。そうなると、Boxには最新の書類があるのに、kintoneの案件レコードにはその事実がどこにも残っていません。ファイルはあるのに記録がない、という食い違いが生まれるのです。

情報を探す時間の一部が、実際には「あったはずの記録が無い」ことの確認や、社外への問い合わせに費やされているケースもあります。記録を人手にゆだねている限り、抜けを完全にゼロにはできません。これは、担当者の意欲や能力の問題ではなく、記録するかどうかを人の判断に任せているという仕組みの問題です。

Boxへのアップロードを検知する部分を自動化すれば、この「確認して書き写す」という手作業がまるごと消えます。担当者がフォルダを見に行かなくても、上がった事実がkintoneに残るからです。

実装を誰が担うかについても、あらかじめ触れておきます。今回の構成は、kintoneの日常操作に加えて、n8nの基本的な使い方を覚える必要があります。情報システム部門や外部の連携先と分担して組んでも構いません。

大切なのは、技術的に実現できるかどうかと、社内で手を動かす時間を確保できるかどうかを、別の問題として切り分けることです。

費用の目安も、判断の材料になります。n8nには、自前のサーバーで動かすセルフホスト版と、提供元のクラウドを使うクラウド版があり、セルフホスト版は無料で始められます。

クラウド版には有料プランもありますが、金額は改定されることがあるため、最新の内容はn8nの公式料金ページでご確認ください。

なお、n8nそのものがはじめての方は、n8nとは？kintoneと生成AI連携のはじめかたで基礎から解説しています。

自動記録を組むときに、実際につまずくのはこの3か所

Box→kintone自動記録でつまずく3か所。プラグインの片方向、Webhookの重複配信、ファイル名だけでは案件特定不可を示す図

ここからは、実際に組むときにつまずく場所を、踏む順番で開示します。つまずくのは、大きく3か所です。 どれも着手する前には見えにくく、手を動かして初めて気づく種類のものでした。

Box連携プラグインの設定を探しても、「Box→kintone」に取り込む項目が見つからない

最初につまずくのは、既存のプラグインで何とかできないかと設定画面を探す段階です。

kintoneのBox連携プラグインは、kintoneに保存したファイルの共有リンクを社外へわたすための機能です。つまり自動化してくれるのは「kintone→Box」方向で、社外がBoxに上げたファイルをkintoneへ取り込む項目は、設定のどこにもありません。

実際にプラグインの画面を開いても、指定できるのは「kintoneのファイルをBoxへ」わたす方向だけで、取り込み側の項目はどこにも現れません。

プラグイン自体の仕様については、Box連携プラグイン for kintoneのページで確認できます。

方向が片側だけだと気づけると、次の一手が「取り込み側を自分で作る」ことだと定まります。その取り込み側の入口になるのが、Box Webhookです。Boxは、フォルダで起きた出来事を外部へ知らせる仕組みを持っており、その仕様はBox Developer Documentationで公開されています。

Box Webhookが同じアップロードを何度も送ってきて、kintoneに同じ記録が二重に増える

次につまずくのは、Box Webhookを受け取り始めた段階です。

Box Webhookは、1回のアップロードに対して、同じ通知を複数回送ってくることがあります。送信先から時間内に受け取りの応答がないと、Boxが配信をやり直す仕組みがあるためで、これはBox側の仕様です。素直に受け取ってそのまま記録すると、1つのファイルに対して、kintoneの案件レコードへ同じ行がいくつも積み上がります。

この二重記録は、動かし始めてしばらくしてから気づくことが多い問題です。テストで1回だけ上げているうちは表面化せず、実運用で件数が増えてから「なぜか同じファイルが何行も並ぶ」という形で現れます。

ファイル名だけでは、どの案件レコードに紐づければいいか決まらない

3か所目は、記録先を決める段階です。

社外が上げたファイルを検知できたとしても、それをkintoneのどの案件レコードに結びつけるかという手がかりが、ファイル名だけでは決まりません。「見積書.pdf」という名前が届いても、それがどの案件のものかは、名前を見ただけでは判断できないためです。

ここを場当たりで進めると、あとから「このファイルはどの案件だったか」を人が調べ直すことになり、自動化したはずの手間が別の形で戻ってきます。記録先を機械が特定できるようにするには、フォルダやファイルの名前の付け方を、先にそろえておく必要があります。

3か所を踏まえた、Box→kintone自動記録の組み方

つまずく3か所が分かったところで、それを踏まえた組み方を、実行する順番で示します。前半の3つは先ほどの詰まりへの対策で、最後の1つは、はじめに約束した到達点（Teamsへの通知まで）を完成させる仕上げの工程です。なお、ここも情報システム部門や外部の連携先と分担して構いません。

まず、これから組むワークフローの全体像です。Boxからの通知を受け取り、左から右への一本道で、これから説明する3つの対策が、そのまま順番にノードとして並びます。全体像を先に押さえておくと、それぞれのノードが何のためにあるのかを見失わずに組めます。

Box Webhookは「FILE.UPLOADED」を社外共有フォルダに絞って受け取る

まず、取り込みの入口を作ります。Box側で、ファイルがアップロードされたことを知らせるFILE.UPLOADEDというイベントのWebhookを設定し、その送り先をn8nのWebhookトリガーにします。

このとき、監視の対象は社外との共有フォルダの配下だけに絞ります。社内のあらゆるフォルダの動きまで受け取ってしまうと、関係のない通知でフローが動くためです。

n8n側では、受け取った通知のイベント種別を確認し、FILE.UPLOADED以外は先へ流さないようにします。これで、社外が対象フォルダにファイルを上げたときだけ、処理が始まります。

下の画面が、その絞り込みを担うノードの中身です。イベント種別がFILE.UPLOADEDかどうかだけを判定し、削除や移動など関係のない通知は、ここで止めています。

event.id（またはファイルID＋バージョン）で重複を弾いてから記録する

次に、二重記録への対策を入れます。ここが、この仕組みで一番の勘所です。

Box Webhookが同じ通知を複数回送ってくることへの備えとして、すでに処理した通知かどうかを、記録の前に必ずたしかめます。

この通知には、その出来事ごとに割り振られる識別子が、ペイロード直下のidとして含まれています。このidは、Boxが同じ通知を再送しても変わりません。値を控えておき、同じidが再び届いたら、そこで処理を止めます。

なお、受信のたびに変わるヘッダー側の配信IDは、再送を見分ける用途には使えません。ペイロード直下のidのほうを鍵にしてください。イベントの識別子が扱いにくい場合は、ファイルのIDとバージョン番号の組み合わせを鍵にしても構いません。

こうして「同じ出来事は一度しか記録しない」状態を作っておくと、Boxが通知を何度送ってきても、kintoneの案件レコードに同じ行が積み上がることはなくなります。この考え方を、エンジニアの世界では冪等化（べきとうか）と呼びます。外部からの通知を扱う自動化では欠かせない備えです。

下の左の画面が、処理済みのidを控えておき、同じidが再び来たら止める、冪等化ノードの中身です。同じ通知データでフローを続けて2回実行すると、2回目はこのノードで止まり、その先へは進みません。当然、kintone側にも同じ行は増えないことになります。

フォルダ名・ファイル名の命名規則で、記録先の案件レコードを特定する

続いて、記録先を機械が特定できるようにします。

あらかじめ、案件番号をフォルダ名やファイル名に含めるルールを決めておきます。たとえば、案件ごとにフォルダを分け、フォルダ名の先頭に案件番号を入れておく、という取り決めです。

n8nのフローでは、届いたファイルのフォルダ名やファイル名から案件番号を取り出し、その番号でkintoneの該当レコードを検索します。レコードの検索や追記には、kintoneのREST APIを使います。使えるAPIの一覧はcybozu developer networkで確認できます。

下の画面は、フォルダ名から案件番号（たとえばPJ-2025-0003）を取り出すノードの中身です。決めておいた命名規則に沿った並びを手がかりに、番号の部分だけを抜き出しています。ここで取り出した番号で、kintoneの該当レコードを検索します。

命名規則を先に固めておくことが、この工程の成否を分けます。名前の付け方が人によってばらばらだと、機械は案件を特定できません。逆に言えば、社外にもこの名前の付け方を共有しておけば、あとは自動でつながります。

記録できたら、誰が見ても分かるようメタ情報付きでTeamsに知らせるところまで仕上げる

最後に、記録を仕上げます。ここは詰まりへの対策ではなく、記録を「誰が見ても分かる」状態まで完成させる工程です。

n8nのフローで、Box APIからファイルの詳細情報を取得します。取得するのは、次のような項目です。

  • ファイル名
  • アップロードした人
  • アップロードの日時
  • 保存されたフォルダ
  • 共有リンク

これらを、先ほど特定したkintoneの案件レコードへ追記します。あわせて、担当者のTeamsへ通知を送り、「この案件に、この書類が上がりました」と知らせます。ここまで組むと、社外がBoxにファイルを上げてから、kintoneへの記録とTeamsへの通知までが、人の手を介さずにつながります。

下の画面は、実際にTeams通知用のノードを設定した例です。案件番号・ファイル名・共有リンクが載っているので、Teamsを見ただけで「どの案件に、何が上がったか」が分かります。

詰まる場所が分かっていれば、記録漏れは人の注意力ではなく仕組みで防げる

仕組みが動き出すと、業務の状態そのものが変わります。社外が上げたファイルは、もう「気づいた人が転記する」ものではなく、上がった瞬間にkintoneの中の記録になります。 案件と紐づいた履歴として、誰かの注意力に頼らずに残るのです。

そして、つまずく場所はあらかじめ分かっています。プラグインが片方向であること、Box Webhookが通知を重複して送ってくること、ファイル名だけでは案件が決まらないこと。この3か所を先に押さえておけば、あとは順番に組み上げるだけです。

ひとつだけ、切り分けておきたい点があります。技術的に組めるかどうかと、社内でその手を動かす時間を確保できるかどうかは、別の話です。前者はこの記事で道筋を示せますが、後者は各社の体制によって変わります。もし「自社の場合はどう進めればいいか」の判断がつかない場合は、あとで触れる無料相談をご利用ください。

まとめ

社外とのBox受け渡しでは、「上げてもらった事実をkintoneに残す」工程が、人の手作業と注意力にゆだねられがちです。Box連携プラグインが担うのは「kintone→Box」方向だけで、その逆の「Box→kintone」方向は守備範囲に入っていません。

この足りない半分は、Box Webhookとn8nで補えます。組むときにつまずくのは、次の3か所でした。

  • Box連携プラグインには「Box→kintone」に取り込む項目がないこと
  • Box Webhookが同じアップロードを重複して送ってくること
  • ファイル名だけでは記録先の案件レコードが決まらないこと

実装の体制さえ整えられれば、社外がファイルを上げた瞬間に、kintoneへ自動で記録し、Teamsへ通知するところまで組み上げられます。記録漏れと確認の二度手間を、人の注意力ではなく仕組みで防げるようになります。

最後に

ここで示した組み方は、自社の検証環境で試した内容です。実際に導入する際は、社外との共有フォルダの構成や、案件番号の付け方によって、つまずく場所も対策も変わってきます。

「自社の場合はどう組めばいいか」「どこまで自社の手で回せるか」の判断がつかない場合は、無料の相談をご利用ください。連携の設計から実装の分担まで、実際の業務にあわせてご一緒に整理します。詳しくはものづくりAI自動化ファクトリーをご覧ください。

関連記事