Sequesign

@sequesign/mcp

Sequesign 向けの Model Context Protocol サーバーです。MCP 対応エージェントが、自ら委任された作業について暗号学的に検証可能なレシートを生成し、オフラインで検証できます。

@sequesign/sdk を使用する、ローカル stdio の薄いラッパーです。エージェントの署名鍵がマシンの外に出ることはありません。direct モードでは、SDK が各アクションにローカルで署名し、ホストされた証人はハッシュに共同署名するだけです。

ツール

ツール	機能
sequesign_start_session	記録セッション（署名済みアクションチェーン）を開始します。ほかのすべてのツールで使用するsessionId（レシート ID）を返します。レシートをポリシーに紐付けるには、policyContextオブジェクトを渡します（L3_POLICY_BOUNDに到達します）。任意のmode（direct／managed）を指定すると、セッションごとにサーバーのデフォルトを上書きできます。
sequesign_record_action	署名済みアクションをチェーンに追加します。evidenceはハッシュ化され、署名されます。actionIdを返します。
sequesign_record_approval	記録済みアクションに、ローカルで署名された承認を添付します（例：人間またはエージェントのレビュアーによる承認）。
sequesign_record_counterparty_attestation	記録済みアクションに、取引相手の署名付き確認を添付します（例：ベンダーによる金額の確認）。SDK は、証明対象のアクションからコンテンツの紐付けを導出します。
sequesign_approve_receipt	すでにシール済みのレシートに、独立した証人による承認を添付します（遅延サテライト）。人間または別のエージェントであるレビュアーが、事後に承認するためのものです。承認者は記録エージェントとは別でなければなりません。
sequesign_countersign_receipt	すでにシール済みのレシートに、独立した証人による取引相手の確認を添付し（遅延サテライト）、特定のアクションに紐付けます。
sequesign_finalize	レシートをシールして証人を付与し、SDK 独自の検証を実行します。セッションを終了します。
sequesign_verify	シール済みレシートをオフラインで検証します。3 つのモードがあります。ローカルパッケージの完全性を自己チェックするモード（デフォルト）、証人が公開した鍵を渡すサードパーティのexternalチェック、またはreceiptUrlを渡してブローカーに保存されたレシート（登録済み ID を含む正式なコピー）を検証するモードです。後者では、公開済みの証人と登録アンカーを自動取得します。

セッションごとのモードの選択

サーバーのデフォルトはSEQUESIGN_MODEですが、sequesign_start_sessionではmode引数（directまたはmanaged）を指定できるため、設定を編集せずに1つの実行中サーバーで両方のモードを利用できます。mode: "managed"のセッションには、managed モードのシークレット（SEQUESIGN_API_KEYとSEQUESIGN_AGENT_PRIVATE_KEY）が必要です。これらが設定されていない場合、呼び出しはすぐに失敗します。

保存済み（登録 ID 付き）レシートの検証

managed モードでは、ブローカーは登録済みのagent_identity_attestationをローカルエンベロープではなく、保存済みレシートに記録します。そのため、ローカルで検証するとself_assertedと表示されます。finalizeから得られるreceipt_urlをreceiptUrlとしてsequesign_verifyに渡すと、保存済みレシートを取得し（SEQUESIGN_API_KEYを使用）、ローカルパッケージと照合して検証します。また、公開済みの証人と登録アンカーも自動取得するため、結果にはexternalの信頼性とregisteredの ID が表示されます。

複数当事者／事後の証明（封印後）

sequesign_approve_receipt と sequesign_countersign_receipt は、すでに確定済みのレシートに対して証明を行いますが、レシート自体は変更しません。それぞれ、ハッシュによって封印済みレシートに紐付けられ、それぞれの実施時点で独立して証人の確認を受ける、分離されたサテライトを生成し、パッケージの attestations.jsonl サイドカーに書き込みます。検証時には、有効なサテライトがレシート内のものと同じ承認／相手方のレッグに統合されます。これらのツールには、実行中のセッションではなく、封印済みの packageDirectory を渡します。そのため、パッケージを持っていれば、別の当事者が、別のマシン上の別のモデルであっても、後から承認や連署を行えます。これが複数当事者のワークフローの基盤です。あるエージェントが作業を記録して封印し、2人目の当事者が承認し、3人目が確認します。1つのレシートに、独立したタイムスタンプ付きの署名が3つ記録されます。

登録済み（保存済み）レシートへの紐付け。 デフォルトでは、サテライトはローカルの receipt.json に紐付けられます。管理モードでは、ブローカーに保存されたコピーに登録済みの agent_identity_attestation（別のハッシュ）が含まれるため、approve_receipt／countersign_receipt に receiptUrl として receipt_url を渡してください。ツールは保存済みのレシートを（認証済みかつオリジンが許可リストに登録された状態で）取得し、サテライトをそこに紐付けます。その後 sequesign_verify --receiptUrl を実行すると、登録済みのアイデンティティと統合された承認／相手方のレッグが、1つのレシート上に表示されます。サテライトの mode は、レシートを封印したときのモードに合わせてください。

収束に関する注意（クロスプラットフォーム）。 ブローカーはサテライトを保存しません。封印済みのサテライトは、ローカルパッケージの attestations.jsonl に追記されます。そのため、異なるマシン／プラットフォームを使う当事者が、検証可能な1つのレシートに収束するには、.sequesign パッケージを当事者間で受け渡す必要があります（オーケストレーターがパッケージを移動し、各当事者が自身のサテライトを追記します）。サーバー側でサテライトを保存して個別に送信する機能は、今後のブローカー機能として予定されています。

証明による保証（検証済みの当事者）

キーを渡さない場合、sequesign_record_approval と sequesign_record_counterparty_attestation は一時的なキーを生成するため、そのレッグは present_unverified として検証されます。present_verified（証明による保証済み）のレッグにするには、まずプラットフォームに当事者のキーを登録し、登録済みの秘密鍵 PEM と、返された identityProofRef の両方を渡してください。その後、プラットフォームが公開している登録キーを sequesign_verify に渡すと、レッグは present_verified に切り替わります。

設定

すべての設定は環境変数を使用します。

変数	デフォルト	備考
SEQUESIGN_MODE	direct	デフォルトのトランスポートです。direct（ローカルキーを使用し、独立した証人が共同署名します）または managed（ブローカーを使用します）。mode ツール引数でセッションごとに上書きできます。
SEQUESIGN_WITNESS_URL	https://witness.sequesign.com	direct モードの証人です。
SEQUESIGN_BROKER_URL	https://broker.sequesign.com	managed モードのブローカーです。
SEQUESIGN_DASHBOARD_API_URL	https://dashboard-api.sequesign.com	receiptUrl の検証パスで、公開済みの登録キーを取得するためのソースです。
SEQUESIGN_RECEIPT_LIBRARY_URL	https://library.sequesign.com	レシートストアのオリジンです。receiptUrl の取得時、API キーはこのオリジンまたはブローカーのオリジンにのみ転送されます。キーが送信される前に、それ以外のオリジンはすべて拒否されます（キー流出防止）。
SEQUESIGN_API_KEY	—	managed モードでは必須です（書き込みクラスのキー）。direct モードでも証人に渡されます。ホスト型の証人は署名 POST を認証するため、認証なしの署名を許可する証人を SEQUESIGN_WITNESS_URL に指定しない限り、direct モードでも必要です。
SEQUESIGN_TIER	hosted	managed のティアです。hosted、hash-only、または ephemeral を指定します。
SEQUESIGN_AGENT_PRIVATE_KEY	—	エージェントキー用の Ed25519 PKCS#8 PEM です。direct モードで未設定の場合、セッションごとに新しい一時キーが生成されます（ID は self_asserted と読み取られます）。managed モードでは必須です。API キーに登録されているキーを指定する必要があります（ブローカーはそれ以外のエージェントキーを拒否します）。
SEQUESIGN_PACKAGE_DIR	<tmpdir>/sequesign-mcp	レシートパッケージの書き込み先です。

セッションはプロセスの存続中、メモリ内に保持されます。sessionId はサーバーの再起動または sequesign_finalize の実行後には維持されません。

インストール

Claude Desktop Extension（.mcpb）として — 推奨

ワンクリックでインストールできます。GitHub リリースから sequesign.mcpb をダウンロードし、Claude Desktop で開きます（設定 → 拡張機能 → ファイルからインストール）。Desktop はマニフェストの user_config からセットアップフォームを表示します。次の項目を入力してください。

フィールド	備考
モード	direct（デフォルト）または managed。
API キー	書き込みクラスのキーです。managed では必須です。direct ではホスト型の証人の認証に使用されます。OS のキーチェーンに保存されます。
エージェント秘密鍵（PEM）	Ed25519 PKCS#8 PEM です。managed では必須です（API キーに登録されているキーと一致する必要があります）。direct では、セッションごとに一時キーを生成する場合は空欄にします。OS のキーチェーンに保存されます。
レシートパッケージのディレクトリ	封印済みパッケージの書き込み先です。空欄の場合は、一時ディレクトリを使用します。

シークレットは OS のキーチェーンに保存され（マニフェストには保存されません）、空欄のオプション項目にはデフォルト値が適用されます。このバンドルは自己完結しているため、npm／node プロジェクトのセットアップは不要です。API キーとエージェントキーはどこで入手できますか？ 以下のキーの取得方法を参照してください。

ソースから .mcpb をビルドする方法：

npm run build:mcpb -w @sequesign/mcp
# → packages/sequesign-mcp/sequesign.mcpb (+ the staged mcpb-dist/ directory)

ビルドでは、esbuild を使ってサーバーとすべての依存関係を単一ファイルにバンドルし、プロトコルレジストリ／スキーマ／プロファイルをその隣にコピーした後、@anthropic-ai/mcpb でパッケージ化して検証します。生成された .mcpb と表示された SHA-256 を GitHub リリースに添付してください。

npm と公式 MCP レジストリへのリリースは自動化されています。詳しくは PUBLISHING.mdを参照してください。

npm 経由

Desktop 以外の MCP クライアントを使用する場合（または設定を自分で管理する場合）は、npm からインストールし、環境変数で設定してください。詳しくは以下の使い方を参照してください。

キーの取得方法（および使用される ID）

2 つのシークレット、API キーとエージェント秘密鍵は、Sequesign ダッシュボードの「Create API key」フローで取得できます。managed モードで使用するキーは、API キーに登録されているキーでなければなりません。

管理モード — 登録済みのID

ダッシュボードで API キーを作成します（Settings → API keys → Create key）。 登録はデフォルトでオフになっているため、明示的に有効にする必要があります。

1. 「Register this key with an agent public key」を有効にします（作成ダイアログのチェックボックスです。デフォルトではオフになっており、有効にしないと通常の API キーのみが発行され、秘密鍵 PEM は取得できません。これでは管理モードには不十分です）。
2. 「Generate keypair (recommended)」を選択します。するとダッシュボードがブラウザー内で Ed25519 キーペアを生成します（秘密鍵が当社のサーバーに送信されることはありません）。公開鍵はアカウントに登録され（プラットフォームがそのフィンガープリントに紐づく登録レコードに署名します）、秘密鍵 PEM は一度だけ表示されます。表示されたらダウンロードしてください。
3. API キーと秘密鍵 PEMをコピーします。

セットアップフォームに両方を貼り付けます（または SEQUESIGN_API_KEY と SEQUESIGN_AGENT_PRIVATE_KEY を設定します）。インストール先やマシンが異なっても同じものを使い続けてください。毎回新しいキーを作成する必要はありません。

独自の鍵を持ち込む（上級者向け）。「Generate keypair」の代わりに、「Bring your own public key (advanced)」を選択し、自分で生成した鍵の公開 PEM（HSM で生成した鍵など）を貼り付けることもできます。秘密鍵は自分で管理し、プラットフォームには公開鍵が記録されます。管理モードで完全にサポートされています。

ブローカーが受け付けるのは、API キーに登録されたエージェント鍵のみです。ダッシュボードで生成した鍵でも、自分で用意した鍵でも同様です。未登録の鍵（ローカルで生成したまま登録していない鍵）は拒否されます（agent_public_key_not_registered）。API キーに鍵が登録されていなければならず、その紐付けは API キーの作成時に行われる、というのがルールです。

ブローカーに保存されたレシートを検証すると、登録済みのエージェントIDが表示されます（下記の receiptUrl 検証パスを参照）。

ダイレクトモード — 自己申告のID

ダイレクトモードにはアカウントも登録もありません。エージェント鍵が証明するのは継続性（同じ署名者がこれらのレシートを作成したこと）だけであり、プラットフォームによって保証されたIDではありません。選択肢は2つあります。

• 鍵を空欄のままにする → サーバーがセッションごとに新しい一時鍵を発行します。手早く作成できる、単発の匿名ながら検証可能なレシートに適しています。レシートごとに異なる self_asserted 鍵が使われます。
• 固定の PEM を貼り付ける → セッションをまたいで再利用される、安定したIDになります。Ed25519 PKCS#8 PEM であれば使用できます（ダッシュボードで生成できる鍵や、openssl genpkey -algorithm ed25519 など）。その鍵が SEQUESIGN_API_KEY に登録された鍵でない限り、self_asserted のままです。その鍵が登録済みの場合、同じ鍵を認証する witness が一致を確認するため、レシートは登録済みIDとして検証されます。つまり、ダイレクト署名と登録済みIDの両方が使えます。（witness は、API キーに登録されていない鍵による署名も拒否するため、API キーを使って未登録の鍵でレシートを発行することはできません。）

使用方法

stdio サーバーとして MCP クライアント（Claude Desktop など）に追加します。

{
  "mcpServers": {
    "sequesign": {
      "command": "npx",
      "args": ["-y", "@sequesign/mcp"],
      "env": {
        "SEQUESIGN_MODE": "direct"
      }
    }
  }
}

または、直接実行します。

npm install -g @sequesign/mcp
sequesign-mcp

プロンプトの例

サーバーの設定後、MCP 対応のエージェント（Claude Desktop など）にこれらを入力してください。実際に依頼するような書き方になっており、エージェントがツールを選択します。

1. 1件の作業を記録して封印し、検証します。

Sequesign を使用して、[email protected] から委任されたタスク q3-refund-review のセッションを開始し、証拠 { "invoice": "INV-2231", "amount_usd": 480, "reason": "duplicate charge" } とともにアクション refund_approved を記録してから、レシートを確定し、検証してください。パッケージディレクトリと、検証に成功したかどうかを教えてください。

start_session → record_action → finalize → verify（ローカル整合性セルフチェック）を実行します。

2. 複数の当事者：1つのエージェントが記録し、あとから2者が証明します。

<packageDirectory> にあるレシートはすでに封印済みです。Sequesign で、[email protected]（人間のレビュアー）として承認を追加し、続けてアクション refund_approved に対するカウンターパーティ確認を vendor-globex として、目的 refund_amount_confirmation で追加してください。その後、パッケージを検証し、承認とカウンターパーティのレッグを表示してください。

approve_receipt と countersign_receipt（すでに確定済みのレシートに紐づく、後から追加されるサテライト）、続いて verify を実行します。パッケージを持っていれば、別の当事者でも——別のマシン上の別のモデルでも——これらを実行できます。

3. ブローカーに保存された登録済み ID のコピーを検証します（マネージドモード）。

マネージドモードのレシートを確定しました。receipt_url は <receipt_url>、ローカルパッケージは <packageDirectory> にあります。Sequesign で、保存されたレシートを私のパッケージと照合して検証し、外部の信頼と登録済みエージェント ID が示されているかどうかを教えてください。

receiptUrl を指定して verify を実行します。権威のある保存済みエンベロープ（登録済みの agent_identity_attestation を含む）を取得し、公開済みの witness と登録アンカーを自動取得して、external 信頼と registered ID を報告します。

フローの例

1. sequesign_start_session → { taskId, delegatorId, policyContext } → sessionId を返します。
2. sequesign_record_action → { sessionId, actionType, evidence } → actionId を返します。
3. （任意）sequesign_record_counterparty_attestation → { sessionId, counterpartyId, attestedActionId, attestationPurpose }。
4. （任意）sequesign_record_approval → { sessionId, approverId, approvedActionType, approvalContext }。
5. sequesign_finalize → { sessionId } → パッケージディレクトリと検証の概要を返します。
6. sequesign_verify → { packageDirectory } → いつでもオフラインで再検証できます。

ライセンス

Apache-2.0