ClaudeとSignWellを連携する方法 — 電子署名の送付を会話で回す

Claude SignWell連携とは何か

SignWell連携は、電子署名サービスのSignWellが提供するMCPサーバーをClaudeに接続し、署名依頼の作成から送付、進捗確認、署名済みPDFの取得までを会話で進める仕組みです。契約書を署名に回すたびにSignWellの画面を開く手間を省けます。

Connectorsディレクトリでは「Anthropic verified」の表示付きで、開発元はSignWell、追加時期は2026年3月です。Claude DesktopやClaude Code、Cursorなど、MCPに対応したクライアントから使えます。

注意したいのは、多くのConnectorと接続方式が違う点です。ブラウザでログインして承認するOAuth方式ではなく、SignWellのAPIキーを渡して手元でMCPサーバーを動かす方式が案内されています。Connector全般の仕組みはClaude Connectorsの解説にまとめています。同じ電子署名領域の先行例はClaudeとDocuSignの連携です。

接続前に用意するもの

必要なものは次の4つです。最初の2つはどの導入方法でも要ります。

Desktopのコネクタ一覧から入れる場合は、Node.jsもターミナルも要りません。SignWell側はこの経路を推奨としています。

Claude Desktopから入れる手順

最短の経路です。APIキーを貼るだけで済みます。

ツールが出てこないときは、トグルがEnabledか、Desktopを完全に再起動したかを見ます。SignWell側のトラブルシューティングも、この2点を最初に挙げています。

Claude Codeなどコマンドラインから入れる手順

Claude CodeやCursorでは、同梱のセットアップウィザードが設定ファイルまで書いてくれます。

npx @signwell/mcp setup

ウィザードはAPIキーを尋ね、どのクライアントに設定するかを聞きます。終わったらクライアントを再起動します。書き込み前に内容を見たいときは --print(短縮は -p)を付けます。CIなど対話できない環境では --yes --api-key=... が使えます。--clients=claude-desktop,cursor のように、対象のクライアントを絞ることもできます。

ウィザードが書き換える先はクライアントごとに決まっています。

書き込み前には各ファイルのバックアップが取られます。以前のClaude Codeが ~/.claude/mcp.json に残した古い signwell の項目があれば、バックアップのうえで、その項目だけが取り除かれます。

手動で登録する場合

ウィザードを使わず、Claude Codeに直接登録することもできます。

claude mcp add signwell -- npx @signwell/mcp

この後、APIキーを環境変数 SIGNWELL_API_KEY として渡します。エンドポイントを変えたいときは SIGNWELL_API_BASE_URL、HTTPのタイムアウトを変えたいときは SIGNWELL_API_TIMEOUT_MS(既定90000ミリ秒)です。通常は上書きしなくて構いません。登録の書式やJSONでの渡し方はclaude mcp add-jsonの手順で扱っています。Claude Codeの全体像から辿ることもできます。

ウィザードを使うと、キーはOSごとの設定ディレクトリ(macOSなら ~/Library/Application Support/SignWell/MCP/env)に、パーミッション0600で保存されます。キーの置き場が一箇所にまとまります。

使えるツール一覧と読み分け

Connectorsディレクトリに載っているツールは14個です。読み取り系、書き込み系、補助系に分けると見通しがよくなります。

file_store で預けたファイルは、メモリ上に60分だけ保持され、サーバーの再起動でも消えます。ディスクには残りません。

GitHubのREADMEにだけ出てくるツール

GitHubのREADMEは、上の一覧にない操作も説明しています。

• document_update_recipients:送信済み文書の署名者の名前とメールアドレスを直す
• document_delete:文書を削除し、進行中の署名依頼を取り消す

署名者の修正では、直す対象は「署名をまだ始めていない」署名者に限られます。名前とメールアドレスは両方を渡し、変えない側は元の値を入れます。どちらも実行には確認用の引数(confirm_update: true、confirm_delete: true)が要る設計です。

ディレクトリのツール一覧にこの2つは載っていません。手元のバージョンで使えるかどうかは、接続後にClaudeへツール一覧を尋ねて確かめるのが確実です。

下書きから送信までの流れ

このコネクタの設計で重要なのは、送信が二段階に分かれていることです。

document_create と template_create_document は、常に draft: true で文書を作ります。この時点では誰にもメールが届きません。実際に送るのは document_send_draft で、confirm_send: true を渡したときだけです。Claudeが勝手に送ってしまう事故を、仕組みの側で減らしています。

送信後の返答には、状態が非同期で更新される旨の警告が付きます。READMEの例では、署名者の send_email は埋め込み署名の設定であって、メールの配信確認ではない、とも書かれています。

送信時に変えられる設定と、変えられないもの

document_send_draft は、送信と同時に文書名、件名、本文メッセージ、有効期限、リマインダーを更新できます。指定しなかった項目は元のまま残ります。

一方、署名者、ファイル、署名欄は、このツールでは編集できません。また、変更だけを保存して送らない使い方もできません。署名欄の配置が必要な文書を、下書きの段階でどう整えるかは次の節で説明します。

署名欄の置き方:テンプレートかテキストタグ

アップロードしたファイルから作った文書は、署名欄を人が置く必要があります。SignWellの案内では、Claudeが下書きを作り、欄を配置して送るためのリンクを返す流れです。会話だけで完結させたいなら、手段は2つあります。

テキストタグは、書式が {{type:signer_number:required}} です。たとえば次のようになります。

署名日付の扱いには、READMEに補足があります。{{autofill_date_signed:1:y}} か {{date:2:y::::::y}} の形なら、署名日が自動入力され、署名者は変更できません。素の {{date:1:y}} は編集可能なままです。署名日を固定したい文書では、前者の書き方を指定します。タグの解析は非同期なので、処理後は document_get で欄が置かれたかを見ます。書式を事前に調べたいときは file_validate_text_tags を使います。

本番の相手に届かないよう、試すときは test_mode: true が使えます。拘束力のないテスト文書が作られ、API課金も発生しません。

実際の指示の出し方

SignWellのページが載せている指示例を、使い分けの観点で並べ直します。

• テンプレートから送る:「NDAのテンプレートで、Sarah Chenに相手方の役割で送って。自社側の役割は私の情報を使って」
• 状況を聞く:「Sales Agreementの状態は?」
• 署名済みを取る:「Sales Agreementの署名済みPDFをダウンロードして」
• 催促する:「Contractor Agreementの未署名者にリマインドを送って」
• 順番を付ける:「オファーレターを先に採用担当、次に候補者へ。この順で署名してもらって」

文書の状態は、Draft(未送信)、Pending(署名待ち)、Completed(全員署名済み)、Expired(期限切れ)、Declined(辞退)の5つで返ります。

添付できるファイルは、PDF、Word、Pages、PowerPoint、Keynote、Excel、Numbers、画像(JPG・PNG・TIFF・WebP)で、上限は25MBです。

契約書をClaudeに書かせる場合

SignWellは、Claudeに契約書を書かせ、テキストタグで欄を付けて送る使い方も例示しています。ただし、Claudeが書いた条項を、そのまま署名に回すかは別の判断です。条項の確認は、人が文面を読んだうえで下書きを送信する、という二段階に組み込むのが無理のない運用でしょう。法務の一次レビューをどう分担するかはCoworkの法務活用が参考になります。

運用前に押さえる点

送ってはいけない相手に届かないように

document_send_draft は、実在のメールアドレスに通知を送る操作で、取り消すには document_delete か署名者の修正が要ります。Claude Desktopの許可設定で、書き込み系のツールだけ毎回承認を挟む運用が合います。権限設定のつまずきはClaude Connectorsの権限設定でよくある失敗と対策にまとめています。

データの流れ

プライバシーの記述では、MCPサーバー自体はデータや利用状況を収集せず、第三者にも共有しないとされています。通信はあなたのマシンとSignWellのサーバー(https://www.signwell.com/api/v1)の間で直接行われます。APIキーはローカルに保存され、テレメトリーもありません。

この説明が当てはまるのは、手元で動かすMCPサーバーの挙動です。文書そのものはSignWellに渡り、SignWell側の取り扱いは同社のプライバシーポリシーに従います。READMEは、このサーバーについてHIPAA対応をうたっています。

署名の法的な扱い

SignWellは、米国のESIGN法、UETA、EUのeIDAS規則に沿った署名だと説明しています。完了した文書には、タイムスタンプ、IPアドレス、署名者の情報を含む監査証跡が付きます。SignWellの説明が挙げる法令は米国とEUのもので、日本の電子署名法への言及はありません。自社の契約類型で電子署名を使えるかは、法務部門での確認が前提になります。

つまずきやすい点

まとめ

SignWell連携の核は、下書きと送信を分けた二段階の設計にあります。Claudeに任せるのは作成と進捗の確認までとし、送信は文面と宛先を見てから明示する、という分担が合います。OAuthでなくAPIキー方式なので、キーの保管先と、書き込み系ツールの承認設定を先に決めておくと、導入後に迷いません。