sign-cli

sign-cli

完全オフラインで使える電子署名 CLI です。組み込みの PAdES 署名機能（/ByteRange 内の PKCS#7、自己発行証明書）により、サインアップやサードパーティープロバイダーなしで、暗号学的に検証可能な署名済み PDF を生成できます。また、外部の信頼アンカーが必要な場合は、Dropbox Sign／DocuSign／SignWell を経由できます。署名者ごとの承認トークン（TTL で有効期間を制限し、1 つのメールアドレスにスコープを限定）、ハッシュチェーン監査イベント、RFC 3161 タイムスタンプ、名前付きプロファイル、19 個のツールを備えた MCP サーバー、20 個のルートを備えた HTTP API を提供します。

非対称性がアーキテクチャの要です。エージェントは、実際の署名操作以外のすべての手順を実行できます。署名操作だけは人間の承認が必要です。

contract-ops CLI スイートの一部ですが、利用は任意です。 sign-cli は単独で完全に動作します。また、contract-ops スイートの署名＋監査ステップでもあります。template-vault-cli → draft-cli → nda-review-cli → docx2pdf-cli → sign-cli の順に進み、compare-cli で差分を検出します。

まずはこちら

npx @drbaher/sign-cli demo

このコマンド 1 つで、オフラインのローカルプロバイダーを使ってライフサイクル全体を実行し、その後すべてを削除します。作成（同意とメール確認のゲートを有効化）→送信→ゲートによって署名がブロックされることを確認→メールを確認→同意を取得→承認→署名→チェーンを検証→受領書をエクスポート。サインアップ不要、キー不要で、約 5 秒です。

ライブデモ → — 読み取り専用で、4 時間ごとにリセットされます。セルフホストについては、deploy/README.md を参照してください。

次に読むページ

対象	こちらから
新規ユーザー（ツールを評価する方）	この README のクイックスタート、続けて標準的なユーザージャーニー
運用担当者（ホスト型プロバイダーを接続する方）	docs/setup/ — Dropbox／DocuSign／SignWell／埋め込み型
LLM エージェント（CLI を操作する方）	AGENTS.md → docs/agent-guide.md → docs/recipes/
監査担当者（署名済みバンドルを検証する方）	docs/reference/audit-chain.md、docs/reference/legal.md
コントリビューター	docs/reference/architecture.md、docs/regression-testing.md
スイートに新しい CLI を追加する方	スイート内のすべての CLI が従う規約をまとめたCLI 構築プレイブック

概念の詳しい解説は docs/reference/ に、タスク別のレシピは docs/recipes/ にあります。

クイックスタート

# Install
npm i -g @drbaher/sign-cli

# Or run without installing
npx @drbaher/sign-cli demo

# After install, the binary is named `sign`
sign --version
sign demo
sign init        # wizard: provider selection + .env
sign doctor preflight   # structured per-check readiness report

または、Releases からスタンドアロンバイナリをダウンロードしてください — ./sign-linux-x64 demo。すべてのインストール方法については、DISTRIBUTION.md を参照してください。

提供する機能

• 自己発行証明書を使ったオフライン PAdES 署名 — 実際の PKCS#7 署名付き PDF を作成できます。登録も API キーも不要です。
• 必要に応じて利用できる 3 つのホスト型プロバイダー：Dropbox Sign、DocuSign、SignWell。4 つすべてで同じインターフェースを利用できます。
• 署名者ごとの承認トークン（単回使用、有効期間の上限あり、1 つのメールアドレスに紐付け）。トークンはエージェントではなく人に送られます。
• 同意と帰属を示す証拠はリクエストごとにオプトイン：--require-consent を指定すると、記録された署名意思の表明と電子記録への同意に基づいて署名が制限されます（バージョン管理された正規テキストは監査チェーンにハッシュとして記録されます）。--require-email-verification を指定すると、メールボックスの管理権限を確認するコードに基づいて署名が制限されます。signer record-identity は、本人確認をオフラインでどのように行ったかを記録します。設計上、KYC データは収集されません。詳しくは docs/reference/consent-and-identity.md をご覧ください。
• ハッシュチェーン型の監査チェーン。追記専用の DB トリガーと RFC 3161 アンカーを使用します。詳しくは docs/reference/audit-chain.md をご覧ください。
• 冪等性を備えた request send — --force true を指定しない限り、二重送信を拒否します。安全に再試行するには --idempotency-key を併用してください。
• 複数文書・複数署名者のリクエストに対応。CSV を使った一括送信もできます。
• request from-template を使って、各プロバイダーのダッシュボードからテンプレートを利用できます。
• 署名フィールドの自動検出（sign pdf detect-signature-field + sign sign --auto-place）。AcroForm の /Sig ウィジェットと、英語およびフランス語／EU の慣習に基づくアンカーテキストを検出します。
• 署名済み PDF の検査には sign pdf inspect を使用します。sign-cli などの生成元による PAdES PKCS#7（Adobe、DocuSign、Dropbox Sign、SignWell を含む）を解析します。署名者の CN／メールアドレス、証明書のサブジェクトと発行者、有効期間、フィンガープリント、信頼ラベル（self_signed_local / self_signed_other / ca_signed / unknown）、メッセージダイジェストの一致を返します。
• カウンター署名の可視化 — signer fetch-document と MCP の signer_fetch_document ツールは existingSignatures を表示するため、署名者は署名前にカウンター署名の対象を確認できます。
• DOCX から封印済み PDF をワンショットで作成するには sign document を使用します（同梱の docx2pdf-cli、配置の自動化、スタンプ、PAdES による封印、検証を、スコープを限定した一時 DB に対する 1 回の呼び出しで連続実行します）。
• mcp serve と serve の両方で --read-only true によるサンドボックス化が可能です。変更を伴うツール／ルートは FORBIDDEN_READ_ONLY を返します。
• すべての入力パスと出力パスにパストラバーサル対策を適用しています。詳しくは docs/reference/security-controls.md をご覧ください。
• 名前付きプロファイルには、プロバイダー、dbPath、認証情報をまとめられます（シェルで管理するシークレットには {{env:VAR}} 形式の参照を使用）。詳しくは docs/reference/profiles.md をご覧ください。
• PDF のエンドツーエンド検証を完全オフラインで実行できます。request verify-signed-pdf はダイジェストを再計算し、X.509 署名者証明書を抽出します。--recipient <email> を指定すると、単一署名者向けの情報を秘匿したビューを表示し、署名者ごとの trust ラベルを報告します。

標準的なユーザージャーニー

sign request create \
  --title "Mutual NDA" \
  --document ./nda.pdf \
  --signer name:Alice,email:[email protected],order:1 \
  --signer name:Bob,email:[email protected],order:2 \
  --provider signwell

sign approve --request-id <id> --token <token1>
sign approve --request-id <id> --token <token2>

sign request send --request-id <id> --provider signwell --test-mode true

sign request watch \
  --request-id <id> --provider signwell \
  --interval-seconds 5 --fetch-final true \
  --out ./signed.pdf

sign audit show --request-id <id>

または、完全オフラインで実行する場合：

sign request create --title "Mutual NDA" --document ./nda.pdf \
  --signer name:Alice,email:[email protected],order:1 \
  --signer name:Bob,email:[email protected],order:2 \
  --provider local --auto-approve true
sign request send --request-id <id> --provider local
# Each signer runs:
sign sign --request-id <id> --token <their-token> \
  --require-hash <sha256> --require-title "^Mutual NDA$"

プロバイダーごとの詳しいセットアップについては、docs/setup/ をご覧ください。

DOCX から封印済み PDF をワンショットで作成

sign document contract.docx \
  --signer "Alice Founder" --signer-email "[email protected]" \
  --name-signature "Alice Founder" --auto-place first \
  --out contract.sealed.pdf

sign document は、変換（同梱の docx2pdf-cli を使用）→署名フィールドの検出→スタンプ→PAdES による封印→チェーンの検証を連続して実行します。中間状態はすべて、スコープを限定した一時 DB に保存されます。

MCP サーバー（LLM エージェント向け）

sign mcp serve                  # stdio MCP server
sign mcp serve --read-only true # sandboxed: mutating tools return FORBIDDEN_READ_ONLY
sign mcp tools                  # print the catalog (live; don't hardcode the list)

読み取り専用と変更可能なものに分かれた 19 個のツールを提供します。CLI で確認できるものと同じ SignCliError エンベロープを使用します。完全なディスカバリーコントラクト、接続設定のスニペット（Claude Desktop、Cursor）、読み取り専用の利用手順については AGENTS.md をご覧ください。3 種類のリソース形式（request://<id> スナップショット、.../document PDF BLOB、.../audit チェーン）と、エージェントが署名者となるための 4 つのプロンプトテンプレート（review_and_sign、policy_check、inbox_triage、verify_receipt）も公開されています。

HTTP API（MCP 以外のクライアント向け）

sign serve --port 4000 --auth-token <t> --read-only true --rate-limit 5
curl http://127.0.0.1:4000/v1/openapi.json    # discover the route catalog

/v1/* 以下に 20 個のルートがあり、MCP ツールのインターフェースと 1 対 1 で対応します。入力形式、パストラバーサル対策、読み取り専用の制御も同じです。--auth-token または SIGN_HTTP_AUTH_TOKEN による Bearer 認証を使用します。成功時のレスポンスは { ok, result }、失敗時は標準のエラーエンベロープです。

署名者側のフロー（エージェント向け）

--provider local の場合、エージェントはメールリンクを使わずに、署名者として最初から最後まで処理できます。SIGN_LOCAL_AUTOCOMPLETE=false を設定すると、各署名者が明示的に sign sign を実行するまで、ローカルプロバイダーは sent の状態を維持します。

# As the requester (agent or human)
sign request create --title "Mutual NDA" --document ./nda.pdf \
  --signer name:Alice,email:[email protected],order:1 \
  --signer name:Bob,email:[email protected],order:2 \
  --provider local --auto-approve true
# response includes per-signer tokens
sign request send --request-id <id> --provider local

# As the signer, with their token
sign signer list --signer-email [email protected]
sign signer fetch-document --request-id <id> --token alice-tok-... --out ./nda.pdf
# fetch-document surfaces `existingSignatures` so the signer can see what they're countersigning
sign sign --request-id <id> --token alice-tok-... \
  --require-hash <sha256> --require-title "^Mutual NDA$" --require-signer-email [email protected]
# or
sign signer decline --request-id <id> --token alice-tok-... --reason "Terms changed"

複数の署名者の場合、すべての署名者が signedBy[] に含まれた時点でのみ、ステータスが completed に切り替わります。署名前の安全性チェック（--require-hash / --require-title / --require-signer-email）では、状態が変更される前に PRE_SIGN_*_MISMATCH がスローされます。

テンプレート

プロバイダーダッシュボードで定義したテンプレートを再利用します（PDF のアップロードは不要です）。

sign request from-template \
  --template-id tmpl_abc --provider dropbox \
  --signer role:Buyer,name:Alice,email:[email protected],order:1 \
  --signer role:Seller,name:Bob,email:[email protected],order:2 \
  --prefill name:purchase_price,value:1000 \
  --auto-approve true

sign request send --request-id <id> --provider dropbox --test-mode true

各 --signer には、テンプレートのロールに一致する role:<roleName> を指定する必要があります。--prefill name:K,value:V[,signer:N] はテンプレートのフィールドに値を入力します。プロバイダーごとの動作は次のとおりです。DocuSign は署名者ごとのテキストタブを使用し、Dropbox は custom_fields を使用し、SignWell は placeholders を使用します。

フィールドの配置

デフォルトでは、ホスト型プロバイダーは汎用的な署名ページを自動的に追加します。実際の契約書では、request create に --field（繰り返し指定可能）を渡してください。

sign request create \
  --title "NDA" --document ./contract.pdf \
  --signer name:Alice,email:[email protected],order:1 \
  --field signer:1,page:1,x:100,y:200,type:signature \
  --field signer:1,page:1,x:100,y:240,type:date

仕様：signer:<order>（必須）、doc:<i>（複数文書のインデックス）、type:signature|initials|date|text|name|email、page:<n> x:<pt> y:<pt>（座標）、または DocuSign 専用の anchor:"text"（x-offset / y-offset / anchor-units は任意）。フィールドはリクエストに保持され、送信時にプロバイダーへ転送されます。

署名フィールドの自動検出

--provider local の場合、sign sign --auto-place は検出器を呼び出し、信頼度が高い（≥0.8）候補が一意であれば、最上位の候補を使用します。

# Inspect candidates first
sign pdf detect-signature-field --pdf ./contract.pdf

# Auto-place (errors loudly on ambiguity)
sign sign --request-id <id> --token <t> --name-signature "Alice" \
  --auto-place first   # or true | last | all | page:N | index:N

調整戦略は優先順位順に、underline-snap（0.95）、below-anchor-probe（0.85、フランス／EU の慣習）、whitespace-probe（0.75）、shrink-to-fit（0.50）です。日付アンカーは sign pdf detect-date-field で別途検出されます。詳細は docs/agent-guide.md §6.4a をご覧ください。

一括送信

sign request bulk \
  --csv ./signers.csv \
  --document ./contract.pdf --provider dropbox \
  --title "Q2 NDA for {{email}}" --test-mode true

各行は autoApprove: true の個別のリクエストになります。タイトルテンプレートでは {{email}}、{{name}}、{{row}} を使用できます。いずれかの行で失敗した場合の終了コードは 3 です。JSON 出力には各行の結果が含まれます。

プロバイダーを超えた信頼性

# Inspect any signed PDF (ours, Adobe's, DocuSign's, …) — no DB lookup required
sign pdf inspect --pdf ./signed.pdf

# Inspect the embedded PKCS#7 of a request we sent
sign request verify-signed-pdf --request-id <id>
sign request verify-signed-pdf --request-id <id> --recipient [email protected]   # single-signer view

# Anchor the audit head against a public RFC 3161 TSA
sign audit anchor --request-id <id>

# Bundle for archival
sign audit export --request-id <id> --out ./bundle/

audit verify はローカルのハッシュチェーンをたどって検証します。request verify-signed-pdf は /ByteRange の SHA-256 を再計算し、埋め込まれた PKCS#7 内の messageDigest と比較します。さらに、署名者証明書の公開鍵（RSA/ECDSA）を使って PKCS#7 の署名値を検証するため、署名後に変更された PDF だけでなく、偽造または改ざんされた署名も検出され、終了コード 3 になります。sign pdf inspect は、リクエスト ID がなくても、任意の署名済み PDF で動作します。audit anchor は TSA からタイムスタンプトークンを発行します。モデルの全容については docs/reference/audit-chain.md をご覧ください。

プロファイル

sign profile init --name prod --provider signwell --db "~/.sign-cli/prod.db" --strict-provider true
sign profile set --name prod --key credentials.SIGNWELL_API_KEY --value "{{env:SIGNWELL_API_KEY}}"
sign --profile prod request show --request-id <id>
# Or implicitly via a project-level sign-profile.json (git/npm-style upward discovery)

解決順序：フラグ > 環境変数 > プロジェクトプロファイル > ユーザープロファイル > 組み込みのデフォルト。profile show では、デフォルトで認証情報が伏せられます（表示するには --show-secrets true を指定してください）。MCP HTTP トランスポートでは、--http-auth-token が設定されていない場合、show_secrets は拒否されます（stdio MCP と CLI では引き続き使用できます）。docs/reference/profiles.md をご覧ください。

Doctor

sign doctor                       # legacy env-report; always exits 0
sign doctor preflight             # structured per-check report; exit 0 ok, 1 failed
sign doctor providers             # capability matrix across all providers
sign doctor account-check --provider signwell   # provider /me check

preflight はすべてのプロバイダーで環境の健全性チェック（runtime:node_version、storage:db_path）を実行し、その後、プロバイダー固有のチェックを追加で実行します。エージェントによる自己復旧のために、checks[].name に基づいて分岐してください。

セキュリティに関する注意事項

• .env や API キーをコミットしないでください。
• チャットやログで共有したキーはローテーションしてください。
• 開発中はテストモードを有効にしてください。
• パストラバーサル対策、シークレットの秘匿、冪等性、読み取り専用モードについては、docs/reference/security-controls.md をご覧ください。
• チェーンによって証明されることと、証明されないことについては、docs/reference/security-model.md をご覧ください。

ライセンス

MIT。LICENSE をご覧ください。

関連項目

• AGENTS.md — エージェント向けクイックスタート（出力契約、終了コード、検出、障害からの復旧）。
• docs/agent-guide.md — エージェント向けの標準リファレンス（コマンドごとのスキーマ、副作用、冪等性）。
• docs/setup/ — プロバイダーのセットアップ（Dropbox、DocuSign、SignWell、組み込み）。
• docs/recipes/ — タスク別レシピ（事前チェック、agent-loop-mcp、週次アンカー、監査担当への引き継ぎ、Alice として署名、EU NDA）。
• docs/reference/ — 概念の詳細解説（監査チェーン、終了コード、プロファイル、セキュリティモデル、アーキテクチャ、法的な位置付け、比較）。
• TROUBLESHOOTING.md — エラーカタログ。
• CHANGELOG.md — 追加内容とその時期。
• integrations/ — Claude Desktop の設定、LangChain スターター。
• deploy/ — ホスト型デモ用の Fly／Render／Railway 設定。