kintone×クラウドサイン×n8nで、契約書送付と締結後の処理をどちらも自動化するワークフロー

連携コネクタの紹介で「契約締結まで全自動」と思ったのに、自動になるのは契約書への項目差し込みだけだった

受注が決まってから製造に着手するまでの間には、NDAや基本契約の締結という手続きがはさまります。
案件の情報はkintoneで管理し、契約はクラウドサインで結んでいる会社であれば、「この2つを連携させれば、契約まわりの手作業はまとめて自動になるのではないか」と考えるのは自然な発想です。

そう思って連携コネクタの紹介ページを開くと、「契約書の自動作成」「電子契約の締結」といった言葉が並びます。
これを見て「連携さえすれば、契約締結まで全自動でつながる」と期待するわけです。

ところが、よく読むと自動になるのは案件情報を契約書に差し込んで作成するところ、つまり「項目連携」まででした。
どの案件でいつ送るかの判断も、締結が終わったあとの反映も、その先の製造手配や請求の準備も、手作業のまま残ります。

ここでいう「全自動」とは、受注が確定してから締結後の次の業務までが、人の手をはさまずに流れる状態を指します。
期待していたその状態と、実際に自動になる範囲との間には、思っていたよりも大きな開きがあるのです。

連携コネクタの先にn8nを一段足すと、受注確定から締結後の次工程までが一続きで流れる

先に結論をお伝えします。
連携コネクタが止まってしまう場所の前後に、自動化ツールのn8nを一段足すと、受注の確定から締結後の次の業務までが、人の判断をはさまずに一続きで流れるようになります。

これまで担当者が手作業でつないでいた契約締結の前後が、そのまま自動でつながった状態です。
ただし、これは「連携コネクタがどこで止まるのか」を先に知っていればの話になります。

止まる場所を知らないまま同じ構成を組もうとすると、コネクタの範囲で手が止まり、結局もとの手作業に戻ってしまいます。
自動化すべきなのは「案件情報の受け渡し」ではなく、契約締結の前後にある「送信の起動」と「締結後の起動」のほうだからです。
この見極めが、すべての出発点になります。

連携コネクタが自動でつなぐのは契約書の項目まで。契約締結を停滞点にしない起動はその前後にある

なぜ、契約締結が受注後の停滞点として残り続けるのでしょうか。
理由は、連携コネクタが引き受けている仕事の範囲にあります。

クラウドサインとkintoneをつなぐ連携サービスに、クラウドサイン MAKE for kintoneなどがあります。
これらが自動でつなぐのは、案件情報を契約書に差し込んで作成する「項目連携」までです。

締結が済んだ契約書ファイルをkintoneに保管するところまでは対応します。
ただし、引き受けてくれるのはそこまでです（2026年8月時点、公式の連携サービス紹介ページで確認）。

つまりコネクタが担うのは、整ったデータをやり取りするところまでです。
「どの業務のタイミングで動くか」という段取りの部分は持っていません。
だからこそ、契約締結が受注後の停滞点として取り残されるのです。

契約締結を停滞点にしない鍵は、この段取りの前後をつなぐことにあります。
前後がつながると、契約締結の待ち時間がなくなり、締結の完了がそのまま次の業務を起こす運用に変わります。
契約業務の効率化は、書類作成そのものよりも、この前後の自動化から生まれるのです。

kintone クラウドサイン 連携で自動になるのは項目連携までで、送信の起動と締結後の起動をn8nが担う範囲を示した図

具体的にどこで手が止まるのかは、次の章で自社の検証記録として順に見ていきましょう。

実装として組むのは、締結完了の通知を受け取る処理と、案件ステータスの書き戻しです。
アプリ作成や連携設定を自分で進めてきた会社であれば、この2つは無理なく組める範囲に収まります。
大がかりな開発を新たに立ち上げる話ではありません。

とはいえ、この実装に手を動かせる人員や時間を社内で確保できるかは、技術の話とは別に残ります。
この点については記事の最後であらためて触れましょう。

連携コネクタを入れても、契約締結の前後は人手のまま残った

自社で実際に検証すると、大きく3か所で手が止まりました。
「コネクタを入れれば契約まで面倒を見てくれるはず」という前提で運用を始めると、つまずくのはいつも決まった場所です。
踏んだ順に見ていきましょう。

どの案件でいつ送るかの判断と送信操作は、コネクタでは自動にならない

最初のつまずきは、送信のきっかけです。
項目連携で契約書そのものは作れても、「この案件はもう送ってよいのか」という判断と、実際に送信する操作は人の手に残りました。

繁忙期になると、この送信があとまわしになります。
気づいたときには「あの案件、契約書まだ送ってない」という状態が起こり、受注は決まっているのに着手が遅れていくのです。
契約書の作成が自動になっても、送るきっかけを人が握っている限り、この抜けはなくなりません。

締結が終わっても、その進み具合が案件のステータスに反映されない

2つ目のつまずきは、締結の進み具合の見えなさです。
コネクタは締結が済んだ契約書ファイルをkintoneに保管してくれますが、送付・閲覧・完了といった締結状況を案件のステータスに反映する仕組みは持っていませんでした。

そのため、いま契約がどこまで進んでいるかを知るには、担当者がクラウドサインの管理画面をそのつど見に行くしかありません。
見に行った結果を、今度はkintoneの案件へ手で書き写します。
この画面の確認と手転記が、締め切り前のまとまった手間として積み上がっていきました。

締結完了後の製造手配・請求準備が、自動では動き出さない

3つ目は、締結が終わったあとの静けさです。
契約が締結されても、製造の手配や請求の準備といった次の業務は、だれかが締結を確認して動き出すまで止まったままでした。

その節目を、後続の業務が自動では受け取れないのです。
結局のところ、送信のきっかけも、締結後のきっかけも人の手に頼ったままで、「契約締結」が受注後の停滞点として居座り続けました。

前後をn8nに寄せると、契約締結が業務イベントで自動的に流れる工程になる

つまずく場所が3つに整理できれば、打ち手も見えてきます。
コネクタが止まる場所の前後をn8nに引き取る設計を、実行する順に見ていきましょう。
先ほどの3つの詰まりに、それぞれ対応させています。

kintone クラウドサイン 連携をn8nで組み、受注確定の自動送信から締結完了の書き戻し・次工程の自動起動までをつなぐワークフロー図

この流れを、実際にkintoneとn8nで組んでいきます。まず検証に使った案件管理アプリには、通常の案件項目に加えて、自動化のための「送信済みフラグ」と「クラウドサイン書類ID」を持たせています。

そのうえで、契約締結の前後をつなぐワークフローをn8nに組みます。上段が「送信の起動」、下段が「締結後の起動」の2本です。

案件ステータスが受注確定になったら、n8nがクラウドサインへ契約書を自動送信する

1つ目の詰まり、送信のきっかけへの打ち手です。
kintoneの案件ステータスが「受注確定」に変わったことを業務イベントとしてn8nが受け取り、対象の案件についてクラウドサインへ契約書の送信を起こします。

送るきっかけを人の判断からステータスの変化へ移すことで、繁忙期でも送付の抜けが起こらなくなります。
「まだ送っていない案件」を頭のなかで管理する必要がなくなるのです。

この「受注確定」をn8nが受け取るには、kintone側でWebhookを設定します。トリガーは「プロセス管理のステータスの更新」を選び、n8nの受信URLを登録します。

締結完了をクラウドサインから受け取り、kintone案件のステータスへ書き戻す

次に対応するのは、締結状況の反映です。
クラウドサイン側で送付・閲覧・締結完了といった状況が変わったことをn8nが受け取り、その内容をkintoneの案件ステータスへ書き戻します。

これで、契約がいまどこまで進んでいるかがkintoneの案件を見るだけで分かるようになります。
管理画面をのぞきに行って手で書き写す作業が、まるごと不要になるのです。

締結完了を受け取ってkintoneのステータスへ書き戻す部分は、n8nのノードでこのように組みます。書き戻す案件は、送信時に記録しておいた「クラウドサイン書類ID」で特定します。

締結完了を合図に、製造手配と請求準備のレコードを自動で起こす

最後が、次の業務のきっかけです。
締結が完了したという合図を受けて、n8nが製造手配や請求準備のレコードをkintone側に自動で作成します。

この節目が、次の業務を起こすきっかけに変わるわけです。
同じ考え方で請求まわりまで自動化した例は、kintone×マネーフォワード×n8nで請求作業を自動化した記事でも紹介しています。

【実装担当向け】締結完了の受け取りは、クラウドサインの通知をn8nで受ける

実装を担当する方に向けた補足です。
読み飛ばしても記事全体の理解には差し支えありません。

締結完了をn8nが受け取る部分は、クラウドサインからの締結完了の通知をn8n側で受ける形で組みます。

kintoneとn8nをつなぐ基本的な設定や、外部サービスとの認証の考え方については、販売管理システムとkintoneをn8nで連携した記事で扱っています。

連携先サービスのAPIや通知の仕様は改定されることがあるため、実装時はクラウドサインの公式ドキュメントで最新の仕様をたしかめてください。

期待していた自動化の範囲と現実の差が、対処できる3つの詰まりどころに置き換わる

ここまでの設計を組むと、契約締結まわりの景色が変わります。
契約締結は担当者の手作業の待ち時間から外れ、締結の完了がそのまま次の業務を起こす状態になるのです。

「連携すれば締結まで自動になるはず」という漠然とした期待が、対処できる3つの詰まりどころへと置き換わるわけです。
詰まる場所は、もう分かっています。
送信のきっかけ、締結状況の反映、次の業務のきっかけという3つです。

契約締結が手作業の停滞点だったBeforeと、締結完了が次工程を自動で起こすAfterを対比した図

締結が完了すると案件のステータスが「締結完了」に変わり、製造手配と請求準備のレコードが自動で作られます。

この3つを先に押さえれば、kintoneでアプリを組んでいる会社であれば、着手しやすい範囲に入ってきます。

n8nで前後の業務をつなぐ発想は、FormBridgeの入力の先をn8nでつないだ記事でも同じ形で使えます。

一方で、技術的に組めることと、社内でその作業に人員や時間を割けることは別の問題です。
n8nには無料で使えるセルフホスト版と、月額数千円台から使えるクラウド版があります。

小さなワークフローなら低コストで試せますが、構築や運用にかかる工数は、契約の種類や後続の業務の複雑さによって変わります。
自社の場合にどれくらいの工数がかかるかは、無料相談で見立てを確認するのが早いでしょう。

自社ではどこで連携が止まるか、無料相談で確かめる

契約締結のどこが停滞点になっているかは、受注から製造・請求までの流れの組み方や、契約の種類によって会社ごとに変わります。
使っている連携コネクタや、案件管理の運用の実態によっても、つまずく場所は少しずつ違ってくるものです。

「自社の契約まわりのどこにこの仕組みを組み込めるか」「どこで連携が止まっているのか」を具体的にたしかめたい場合は、ものづくりAI自動化ファクトリーの無料相談をご利用ください。
現状の運用をうかがったうえで、自動化できる範囲と、体制として検討すべき点を切り分けてご案内します。

関連記事