ClaudeとJotform Signを連携する方法 — 署名書類の作成から送信まで

Claude Jotform Sign連携でできること

Jotform Sign連携は、Jotformの電子署名サービスをClaudeの会話から操作するコネクタです。プロンプトから署名つきの書類を生成し、署名者を設定し、メールで送り、署名の進み具合を確かめるところまでを、チャットの中で進められます。

コネクタ一覧では「Anthropic verified」の表示があり、開発元はJotform、追加は2026年7月です。利用にはサインインが必要です。説明文には、契約書、入社手続きの書類、同意書、NDA、賃貸契約、社内の承認書類といった用途が並んでいます。

Jotformには、同じ「MCP Apps」という枠でフォーム用、アプリ作成用、署名用の3つのサーバーがあります。この記事が扱うのは署名用だけです。フォームの作成と回答集計はClaudeとJotformの連携で取引先アンケートを作り集計する、アプリ作成はClaudeでJotform App Builderコネクタを使う方法にあります。

接続の前に押さえる条件

接続前に確かめる条件は3つです。

認証はOAuth 2.0(PKCE付き)で、Jotformで発行したAPIキーは受け付けません。スコープは readOnly と full の2種類です。クライアントの動的登録に対応しているので、クライアントIDやシークレットを自分で用意する必要はありません。

署名用のエンドポイントは次のとおりです。

https://mcp.jotform.com/mcp-sign-v1

対話型の画面が出るのは、MCP Appsに対応したクライアントだけです。対応していないクライアントでも、ツールは動き、画面なしで結果を返します。この仕組みはClaudeのインタラクティブコネクタとはで扱っています。

料金面では、Jotform側のFAQに「MCPサーバーは追加料金なしで使える。既存のJotformプランの上限と機能はそのまま適用される」とあります。署名機能そのものの枠はプランに従うので、書類の送信件数などの上限は、Jotform側のプラン表で先に見ておく必要があります。

Claudeに接続する手順

Claudeでは、コネクタ一覧から追加するのが最短です。

コネクタ全般の仕組みと、プランごとの追加の可否はClaude Connectorsの解説にまとめています。

Claude Codeから使う場合

Claude Codeに追加するときは、次のコマンドを実行してから、/mcp でサーバーを選んでサインインします。

claude mcp add --transport http jotform-sign \
  https://mcp.jotform.com/mcp-sign-v1

Claude Codeは対話型の画面を描画しないので、書類のプレビューは出ません。ツールの結果だけが返ります。見た目を確かめながら書類を直す作業は、画面を出せるクライアントで行うほうが進めやすくなります。

接続の許可を取り消す

接続したクライアントは、Jotformのダッシュボードで管理できます。My AccountのConnected AppsからJotform MCPを選び、右のパネルのClientsを開くと、OAuthでつないだクライアントが一覧で出ます。各行のメニューからRevokeを選ぶと、そのクライアントは即座にアクセスを失います。

署名書類を作って送るまでの流れ

署名依頼は、書類の生成、署名者の設定、送信、状況の確認という順に進みます。ツールの対応は次のとおりです。

1. 書類を生成する

create_sign_document は、必須の入力が prompt だけです。公式の例は「2年契約の請負人向けNDA」のような一文です。タイトルは document_title で指定でき、省略すると生成された内容から付きます。

既存のPDF、画像、DOCXを document_file として渡すこともできます。ただし、この添付は「内容の参考」として分析されるだけで、最終的な書類そのものにはなりません。手元の契約書の様式をそのまま署名に回したい場合、元ファイルがそのまま署名対象になるとは読めない点に注意が要ります。また、渡してよいのは会話でアップロード済みのファイルに限られます。

依頼文には、次の材料を入れておくと手戻りが減ります。

業務委託契約書を作ってください。
- 当事者: 甲(発注側)と乙(受託側)
- 期間: 契約日から1年、自動更新なし
- 署名欄: 甲乙それぞれの署名と日付
- 署名の順序: 乙が先、甲が後
作成後、署名者の役割の一覧を見せてください。

生成された本文は、あくまでAIが書いた下書きです。条項の中身は、法務の確認を経てから署名に回す運用が前提になります。契約書レビューとの分担はClaudeとDocuSignを連携する方法の「法務レビューとの役割分担」と同じ考え方です。

2. 署名者を設定する

署名者は「署名欄を持つ参加者」です。get_signers は、書類IDから参加者ID、名前、メール、役割、署名の順番、署名状況を返します。署名欄などが割り当てられていない役割は、一覧に含まれません。

update_signer は、役割に名前とメールを入れる、または別の人に付け替えるためのツールです。必須の入力は document_id、participant_id、name、email で、署名の順番は任意です。役割ごとに1回ずつ呼ぶ設計です。

この仕組みには、見落としやすい性質があります。署名者の役割は書類に固定されていて、「署名者を追加する」という別の手順はありません。一人用の書類でも、役割を別の人に付け替えて再び送れば、何人にでも別々のコピーを送れます。送信のたびに、独立した書類のコピーが1部ずつできるわけです。同じ書類を複数の相手に配る場面では便利ですが、付け替え前の宛先を残したまま送ってしまうと、意図しない相手に届きます。

3. 送信する

send_for_signature は、署名者にメールで書類を送ります。入力は次のとおりです。

順番を守らせたい契約では、enable_signing_order をtrueにしないと、全員に同時に届きます。前節のプロンプト例に署名の順序を書いたのは、この設定をClaudeに渡すためです。

ツールの説明には「実在の人にメールを送るので、呼ぶ前に利用者へ確認すること」とあります。Jotform側の分類でも、このツールは「破壊的」(既存のデータを削除または上書きできる区分)で、外部への影響を示す openWorldHint が真です。一度送ったメールは取り消せません。

4. 署名の進み具合を見る

get_signing_status は、書類全体の状態と、署名者ごとの状態(送信済み、閲覧済み、署名済み、辞退)を、主な時刻つきで返します。フォームのIDや下書きのIDを渡した場合は、送信済みのコピーをすべて集計します。送信済みの書類のIDを渡した場合は、そのコピーだけが対象です。

署名の記録を一覧で見るときは list_submissions を使います。特定の書類を指定することも、全書類を横断することもできます。書類そのものの一覧には使えず、そちらは search の役目です。

10個のツールと、権限の分かれ目

Jotform側のドキュメントでは、ツールは10個で、アクセスの区分が付いています。

「破壊的」の3つは、書類の中身、署名者の宛先、メールの発信を変えます。Claudeの承認設定で、読み取り専用のツールは自動で許可し、この3つは毎回確認にする、という分け方が運用しやすくなります。承認設定の考え方はClaudeとDocuSignを連携する方法の「読み書き権限の扱いと承認設定」と同じです。

edit_sign_document は prompt で「秘密保持条項を足して」「期間を3年にして」のように指示を渡し、内容を再生成します。ここで注意したいのは、ツールの説明に「新しい指示から内容を再生成できる」と書かれている点です。細部の修正のつもりが、本文全体の作り直しになる可能性があります。送信前の確認は、編集のたびにやり直すのが安全です。

get_signing_links は、自分のアカウントのメールアドレス宛に送られた書類に、自分が署名するためのリンクを返します。説明には「署名はチャットでは行われない。ブラウザで役割ごとに署名する」とあり、リンクは署名の順番が来た役割の分だけ出ます。Claudeに署名そのものを代行させることはできません。

コネクタ一覧とJotformドキュメントの食い違い

コネクタ一覧のツール欄は、Jotformのドキュメントと一致していません。

一覧は11個、ドキュメントは10個です。共通するのは8個になります。一覧にだけ載っている3つは、ドキュメントの表に説明がありません。名前からは書類の表示や内容更新の役割が想像できますが、説明が無いので、動作は断定できません。同じJotformのApp Builderコネクタでも、mcp_app_request が一覧にだけ載る同じ状況があります。

この食い違いが運用に及ぼす影響は2つあります。

• 承認設定で個別のツールを許可するとき、実際にClaudeに表示される名前は、接続後のツール一覧で確かめる
• 「破壊的」かどうかの区分がドキュメントに無いツールは、書き込みを伴うものとして扱い、初回は毎回確認にする

業務で使うときの注意点

署名は「法的な効力」の話と切り分ける

コネクタの説明文は「法的に有効な電子署名」を掲げています。ただし、署名の法的な効力は、契約の種類、相手の国、書面を求める法令の有無で変わります。コネクタが保証する範囲ではないので、書面や押印を求められる類型の書類は、法務に確かめてから回します。日本の電子契約サービスの接続例はClaudeクラウドサイン連携の設定方法を参照してください。

個人情報と規制環境

Jotform側のFAQでは、MCPサーバーはアカウントのコンプライアンス設定に従うとされています。HIPAAの保護対象データは、アカウントがHIPAA対応プランで、利用者が保護対象の情報を含むスコープを明示的に許可したときだけ見えます。署名書類には氏名やメールが入るので、チャットに貼る内容は、会話の取り扱い方針と合わせて決めておく必要があります。

Enterpriseの追加機能

Enterpriseでは、毎分600リクエストまでの高い上限、MCP画面のブランド化、シングルサインオンとアクセス制御、優先サポートが用意されています。大量の送信を自動化したい場合は、この上限が1つの目安です。

似たサービスとの違い

同じ電子署名の領域では、DocuSignやSignWellにもClaude向けの接続があります。接続方式の違いは次のとおりです。

Jotform Signの特徴は、書類の本文をプロンプトから生成する点です。既存の契約書ファイルを署名に回す前提のサービスとは、出発点が違います。

よくあるつまずき

まとめ

Jotform Sign連携の肝は、書類の生成から署名者の設定までをClaudeに任せても、送信だけは人の目を通す、という線引きです。send_for_signature が実在の相手にメールを出し、取り消せない以上、ここを毎回確認にするだけで事故の大半は防げます。

もう1つは、コネクタ一覧とドキュメントでツールの数が合わない点です。承認設定は、接続後に表示される実際のツール名で組み直してください。