クラウドサイン契約管理をClaudeで効率化する方法

クラウドサイン契約管理をClaudeで効率化するとは

法務・バックオフィスでクラウドサインを使っていると、「誰の確認で止まっているか」を毎回管理画面で確認して回る作業が発生します。この一覧化と催促の判断は、クラウドサインのWeb APIをClaude Codeにつなげば任せられます。Claudeとクラウドサインの連携設定が済んでいることが前提です。

できるのは、締結が止まっている契約書の洗い出し、待ち相手ごとの滞留状況の整理、催促を送るべき書類の絞り込みです。催促メールの送信までを無条件に自動化するのはおすすめしません。取引先に誤った催促が届くと信用に関わるため、送信前に人が対象を確認する一手間を挟む設計にします。

その理由は、APIの仕様にあります。Web APIによる書類の送信には、クラウドサインの承認機能による送信制御が働きません。社内の承認フローを設定済みでも、API経由の呼び出しはそこを通らないため、承認の関所は自分で作る必要があります。

Web APIはスタンダード・コーポレート・ビジネス・エンタープライズの各プランが対象で、管理画面の「Web API設定」で「利用する」に切り替えます。APIオプションの契約がないユーザーからのリクエストは403(webapi_option_required)で返ります。

止まっている契約書はstatusで絞り込む

GET /documentsは、APIを実行したユーザーが関係者に含まれる書類だけを、1ページ100件ずつ返します。statusパラメータで状態を絞れるので、全件を取ってからClaudeに選ばせる必要はありません。滞留の対象はstatus=1(先方確認中)です。

返ってくる書類には、宛先ごとの状態も入っています。宛先のstatusが4(確認待ち)のものが、いま書類を止めている相手です。登録順に進む書類では、止まっているのは現在確認作業を行う方です。AND署名(全員が署名)のグループがある書類では、statusが4の宛先が複数になることがあります。

TOKEN=$(curl -s -X POST https://api.cloudsign.jp/token \
  -d client_id="$CLOUDSIGN_CLIENT_ID" | jq -r .access_token)
 
curl -s "https://api.cloudsign.jp/documents?status=1&with_files=n" \
  -H "Authorization: Bearer $TOKEN" \
  | jq '.documents[] | {id, title, sent_at, last_processed_at,
      waiting: [.participants[] | select(.status == 4) | {name, organization}]}' \
  > pending-documents.json

with_files=nは、ファイル情報が不要なときにレスポンスを軽くするための指定です(y以外の値ならファイル情報は付きません)。宛先の情報は既定で返るため、上の例ではwith_participantsを付けていません。クライアントIDが他人に漏れるとなりすましが成立するので、CLOUDSIGN_CLIENT_IDは環境変数に置き、CLAUDE.mdやリポジトリには書きません。

経過日数の起点は、送付日(sent_at)ではなくlast_processed_atが向いています。先方確認中の書類では、この値が「最後に誰かが同意または却下した日時」を指します。宛先が3人いて2人目まで終わっている書類は、送付から日が経っていても、止まってからはまだ短いかもしれないためです。

滞留した期間での絞り込みは、API側でもできます。fromとtoで書類の最終処理日時を指定でき、fromは開始日時をRFC3339形式で渡します。GET /documentsとGET /team_documentsのどちらでも使えます。

取得したJSONをClaude Codeに渡し、「待ち相手ごとにまとめ、last_processed_atが古い順に並べて」と依頼すれば、会議にそのまま出せる滞留リストになります。

催促は「送信と同じエンドポイント」に注意する

クラウドサインWeb APIには催促専用のエンドポイントがありません。POST /documents/{documentID}が、書類の状態によって2つの動作を切り替えます。

呼び出しの直前には、対象書類の状態をGET /documents/{documentID}で1件ずつ確かめます。書類IDを取り違えると下書きがそのまま送信されるため、Claude Codeに催促を依頼するときは、対象IDと現在のstatusをセットで出させてから実行に進めます。一覧用のGET /documentsを引き直すと、最大100件の中から該当IDを探す手間が増え、取り違えの余地も残ります。

リマインドが失敗する条件も仕様書に載っています。次のいずれかに当たると、400(bad_request)が返ります。

• 組込み署名(SMS認証)が設定された受信者にリマインドしようとした場合
• 送信者にマイナンバーカード署名が選ばれている場合
• 参加者(送信者と1人以上の受信者)やファイル(1つ以上)が不足している書類を操作した場合

組込み署名の書類を扱う組織では、催促対象から外すか、メールなど別の経路で連絡する運用が必要です。

状態が合わない呼び出しは403で止まります。下書きでも先方確認中でもない書類(締結済みなど)に操作しようとすると、errorの値はnot_acceptableです。

間違えて送ってしまったときに使える操作は、PUT /documents/{documentID}/declineによる却下です。対象は、自分が送信した先方確認中の書類に限られます。却下理由はcommentで添えられ、最大1000字です。1001文字以上は400(bad_request)になります。

催促の要否を判断させる基準表(設計例)

何日止まったら催促するかは、取引慣行で決めるものです。以下は運用設計の一例で、日数は調整します。起点は前節のlast_processed_atです。

Claudeに任せるのは「洗い出しと下書き作成」までにし、実際の催促は承認後の別ステップにします。

承認の関所は権限設定だけに頼らない

Claude Codeには、特定のコマンドを実行前に確認させるaskルールがあります。催促の呼び出しはcurlで行うため、次のように書けば、curlを打つたびに確認が出ます。

{
  "permissions": {
    "ask": ["Bash(curl *)"]
  }
}

ただし、このルールは安全境界にはなりません。Bash(curl *)が止めるのはcurl https://example.comの形で、/usr/bin/curl https://example.comやsh -c 'curl https://example.com'は止められません。curlの引数の形で絞る書き方も、オプションの順序やリダイレクトで抜けるため推奨されていません。

確実に止めたい場合は、公式のページがネットワーク制限にサンドボックスを、コマンド全文の検査にPreToolUseフックを挙げています。承認が本当に必要な1本の呼び出しだけを、フックで止める構成が現実的です。

もうひとつの手は、催促を実行するスクリプトを1本に集約する方法です。状態確認と承認者名の入力をスクリプトの中に組み込めば、承認のステップを1か所に置けます。ただし、このスクリプトにaskを掛けても境界にはならず、curlを直接叩く経路は残ります。その経路は、前述のフックかサンドボックスで塞ぎます。

週次の滞留チェックを定型作業にする

毎回ゼロから確認するより、「毎週月曜の朝に滞留リストを見る」という定型作業にするほうが運用は安定します。差分だけを見る流れは次のとおりです。

前回取得したJSONをファイルとして保存しておき、次回の新しいレスポンスと突き合わせれば、差分だけをClaude Codeに渡せます。手順はCLAUDE.mdにワークフローとして書いてチームに共有しておくと、担当者が変わっても引き継げます。

APIの上限と、エラーのあとの扱い

滞留チェックを自動で回すなら、クラウドサイン側の上限と挙動を先に押さえておきます。

リマインドを呼んで504が返ったとき、そのまま呼び直すと二重に催促が届くおそれがあります。再送の前に、GET /documents/{documentID}で状態を見ます。

連続してリクエストを送るときは、前のレスポンスを待ってから次を送ります。待たずに送ると、処理が競合して正しく動かない場合があります。書類の作成・更新・削除のAPIを呼んだ直後は、反映に時間がかかることがあるため、次の呼び出しまで数秒〜10秒ほど待つ設計が推奨されています。

全社分を見たいときの権限の壁

自分が関係者に入っていない書類の滞留まで見たいときは、GET /team_documentsを使います。メンバー全員がやり取りした書類の一覧を返しますが、条件があります。

• 返るのは「先方確認中」「締結済」「取消、または却下」「インポート書類」のみで、下書きとテンプレートは含まれない
• 管理者権限のないアカウントは使えない(403)
• 複数部署管理を使っているアカウントは使えない(403)

エンタープライズプランでは、利用ガイドが/team_documentsと/meを利用できない操作として挙げています。管理者権限、複数部署管理、プランのどれに当たるかで返る結果が変わるため、全社の滞留を見る前に、自分のアカウントでどの条件に当たるかを確かめます。

また、Web APIは「高度な管理機能」に対応していません。閲覧権限のある閲覧側チームのAPIでは、配下の開示側チームの書類は取得できません。

誰が承認したかを記録に残す

催促を人の承認を経て実行するなら、後から「なぜこの契約先に催促が届いたのか」を説明できるように記録を残します。承認のたびに、次の項目を別ファイルへ追記させる運用が軽く済みます。

• 対象の書類IDとタイトル
• 承認者の名前と承認した日時
• 呼び出す直前に確認したstatus
• APIが返したHTTPステータス

最後の項目が、上で触れた504の再送判断に効いてきます。件数が少ないうちは口頭確認でも回りますが、対象契約書が増えるほど、この記録の有無が差になります。

本番に触る前にサンドボックスで試す

催促ロジックを組んだら、本番の書類に向ける前にサンドボックスで試せます。接続先はapi-sandbox.cloudsign.jpで、本番とはデータベースやストレージが完全に切り離されています。申し込みは営業担当への連絡またはチャットで受け付けています。

サンドボックスの制約も押さえておきます。実際の契約締結には使えず、テンプレート・書類・ユーザーは本番へ移行できません。あくまで、催促の呼び出しとClaudeの判断ロジックを検証するための環境です。宛先には、自分で受け取れるアドレスを使います。

契約書以外の法務業務との切り分け

クラウドサイン連携が扱うのは、締結プロセスの進捗管理です。契約条項そのもののレビューや社内規程の整備は範囲外で、そちらはClaude Cowork法務活用で扱っている業務です。

条項レビューでは契約の文言をClaudeに読ませますが、進捗管理で扱うのはAPIが返す状態と日付だけです。1つのワークフローに詰め込むとアクセス権限も広がるため、最初から別の担当範囲として設計しておくほうが扱いやすくなります。

よくあるつまずき

• 全件を無条件で催促対象にする: 送付直後の書類まで催促すると、相手に急かしている印象を与えます。経過日数で対象を絞ります
• トークンの期限切れに気づかない: 失効後のリクエストは401で返ります。定期実行のスクリプトでは、401を受けたらトークンを再取得する処理を入れます
• 差分チェックの基準日を更新し忘れる: 前回のJSONを比較対象のまま放置すると、解消済みの書類がいつまでも「滞留リスト」に残ります。チェックのたびに最新のレスポンスで上書きします
• 担当者不在の書類を放置する: 宛先の担当者が異動・退職している契約は、リマインドを送っても動きません。滞留リストの中でも「相手の連絡先が生きているか」は別軸で確認します

まとめ

最初に決めることは2つです。1つ目は、自分のアカウントが/team_documentsの条件(管理者権限があり、複数部署管理を使わず、利用できるプランであること)に当たるかどうか。当たらなければ、全社の滞留はこのAPIでは見られません。2つ目は、承認の関所をフックとスクリプトのどちらで作るかです。askルールは境界にならないので、承認が要る1本の呼び出しをPreToolUseフックで止めるか、催促を1本のスクリプトに集約してそこで承認を取るかを選びます。定期実行の仕組みを自作MCPサーバーとして常設化する場合は、MCPサーバー自作ガイドの手順が参考になります。

よくある質問

催促メールの文面もClaudeに作らせられますか

下書きなら作れますが、リマインドのAPI呼び出しは文面を受け取りません。受信者へのメッセージ(message)を設定できるのは、書類を作成するPOST /documentsと、下書きを更新するPUT /documents/{documentID}です。個別に一言添えたい場合は、Claudeが作った下書きを担当者から相手に直接送ります。

複数の契約書をまとめて催促できますか

リマインドは書類IDごとに1件ずつです。確認済みの対象に順番に呼ぶ処理はClaude Codeにさせられます。

締結が完了した契約書の証明書も一覧で取得できますか

GET /documents/{documentID}/certificateで書類ごとに取得します。一覧APIとは別のエンドポイントのため、status=2(締結済)の書類IDを先に洗い出し、証明書が必要なものだけ個別に呼びます。