# Clavis — 導入検討用ブリーフ

この文書は、導入検討のために AI アシスタントへ渡す事実メモです。マーケティング誇張ではなく、公開サイトと製品方針に沿った要約です。

- 製品サイト: https://clavis.nexus/
- 取り扱いの範囲: https://clavis.nexus/security
- 料金: https://clavis.nexus/pricing
- 開発者向けドキュメント: https://docs.clavis.nexus/quickstart
- カードの開始: developers の Org 作成
- 契約・導入の窓口: Enterprise プラン（https://www.deepdive.sh/contact/）。運営は DeepDive, Inc.。製品ブランドは Clavis（`clavis.nexus`）
- 公開の技術・提供形態の要約: https://www.deepdive.sh/technology/ ・ https://www.deepdive.sh/clavis/

## 何をする製品か

Clavis は、DeepDive が開発・運用する **Passkey-native Identity Platform** です。Passkey の認証と署名で、**誰が・何に・いつ同意したかを再検証できる記録**を、既存のビジネス／業務システムに実装するための基盤です。

- 重要操作を「ログイン済みだから本人だろう」だけで通さない。
- 指定した操作では、人が読める確認のあと、操作内容に結びつく Passkey 署名を経る。
- 署名記録は、登録済みの照合手段を持つシステム側で再検証できる（外部の独立監査人が常に再検証できる、という意味ではない）。
- 横断サインインと操作署名を、**OIDC / JWKS / API** などの標準インタフェースで既存業務へ接続する（公開資料: DeepDive Technology／Clavis ページ）。

ここでいう「誰が」は、**登録された Passkey による署名主体を記録から照合できること**を指す。法的身元、在籍、権限の正当性、KYC 済みであることまでを、製品単体で保証する表現ではない。

「何に」の署名対象は、操作内容の照合値（`message_digest`）である。画面の見た目そのものが暗号的に署名されているわけではない。照合値の定義（どの操作内容をどう要約するか）は、接続する業務システム（RP／後述の App）側で設計する。

## 料金（USD）

表示価格は USD。決済と請求は Polar（Merchant of Record）が行い、税は購入者の所在地に応じて決済画面と領収書に表示される。Clavis のオリジンでは Polar の決済スクリプトを読み込まない（Checkout は redirect）。開始は developers の Org 作成。

- **署名（従量プラン）**: 基本料なし。毎月 30 回の完了を含む（翌月に繰り越さない）。超えた分は 1 回 USD 1。当月の請求上限は最初 USD 0 のため、上限を上げるまで 31 回目で止まり請求は発生しない。上限はコンソールから USD 2,000 まで引き上げられる。
- **署名（継続プラン）**: 月 USD 100 で完了 200 回を含む。超過 USD 1 / 完了。当月の請求上限は最初 USD 500、最大 USD 2,000。月の完了が 130 回を超えるなら従量プランより安い。従量プランと同じ Org で同時には有効にできない。
- **台帳**: 月 USD 50。新しい追記 2,000 件を含む。超過 USD 0.05 / 件。当月の請求上限は最初 USD 200、最大 USD 800。同じ内容の再送、読み取り、削除は数えない。
- **Enterprise プラン**: 個別見積もり。導入、App 開発、OEM、保守運用。機能の利用分も同じ契約に含められ、月の上限は見積もりで決める。カード購読とは別契約。
- 数えるのは成功した処理だけ（失敗、再試行、登録だけの操作は数えない）。ログイン（OIDC）は署名に含まれ、人数では数えない。月は UTC の暦月。
- 当月の上限に達すると、その機能の新しい処理は止まり、上限を超えた分は請求しない。同じ Org の App は機能ごとに一つの上限を分け合う。
- 無料枠はない。解約は期末で、発行済みの署名記録は解約後も検証できる。

製品購入の入口: https://clavis.nexus/pricing から developers の Org 作成。  
Enterprise プラン（専有・請求・導入支援）: https://www.deepdive.sh/contact/

## 構成概念（SI 規模の見積もり用）

導入の単位と作業量を整理するための公開概念。価格や契約条件の断定には使わない。

- **Org（組織）**: 接続のテナント単位。組織が管理する **apex ドメイン**を錨とし、DNS や所定の確認で管理権を確かめたうえで、組織と利用アプリの接続を許可する（申告ドメインの取得そのものを信用の証明とはみなさない）。接続の条件はドメインの確認であり、当社の事前審査を待つ手続ではない。
- **App（利用アプリ）**: Org 配下で接続する業務システム／ホスト。サインインや署名後の復帰先は、登録済みのアプリホストに限定される。業務データ・権限は各 App 側が管理する。
- **SI 規模の目安**: 接続する **App の本数**、対象とする重要操作の系統数、既存認証の有無、共用端末向け認証器配備の要否、共有 SaaS か専有 Instance か、が作業量の主な変数になる。App 未特定の段階では適合断定より、対象 App の洗い出しを優先する。

## 提供形態（公開）

- **共有 SaaS**: DeepDive が運用する Clavis に、必要な業務システムから接続する。横断サインインは OIDC で接続。段階的導入が可能。基盤運用は DeepDive。
- **専有 Instance**: 組織専有の Clavis を DeepDive が構築・運用する。独自ドメインやブランド要件に応じて設計する。
- どちらの形態にも、OIDC／API による接続・署名フロー実装、端末・パスキー・復旧を含む運用設計などの導入支援が付きうる（範囲は案件確認）。

## IdP・接続（公開の範囲で言えること）

- Clavis 自身が Passkey を前提とした IdP として動き、**OIDC** で業務システムへ横断サインインを届ける。**既存の別 IdP は必須ではない。**
- 「既存 IdP がない」だけでは不適合にしない。むしろ Clavis を IdP として新規接続する典型パターンになりうる。不足するのは「別 IdP」ではなく、接続先 **App**・対象操作・Org（ドメイン）の整理であることが多い。
- 接続面として公開されているのは **OIDC / JWKS / API** である。SAML、SCIM、ソーシャルログイン等の汎用 CIAM 網羅は、この文書および公開サイトからは主張しない（要否は営業／SI 確認）。
- 特定の市販 IdP／RP 製品との「標準連携済み」は断定しない。接続は案件ごとに設計する。

## 向き・不向き（目安）

向きやすい例（技術的に検討候補になりやすい。法務・監査上の有効性まではこの文書で断定しない）:

- 管理者権限の付与、高額送金、契約・承認など、セッション推定だけでは足りない操作
- 接続先となる業務システム（App）があり、OIDC／署名結果の照合・アカウントライフサイクルを **SI と個別に設計**できる組織
- Passkey（WebAuthn 認証器）を利用できる環境。秘密鍵は認証器側にあり、端末内蔵のほか、セキュリティキー等の持ち運び可能な認証器も候補になりうる（案件・端末構成による）

注: **共用端末であることだけを理由に不適合と断定しない。** 可否は認証器の持ち方・配備次第であり、機器選定および確認質問の対象とする。技術的に検討候補でも、法務・監査要件への適合は別途評価する（Clavis 単体では完結しない）。

向かない／別議論になる例:

- ログイン UX の改善だけが目的
- 法定電子署名（QES）や KYC レベルの保証を製品単体に求める場合
- 業務データそのものを Clavis に預ける設計
- SAML／フル CIAM 置換だけが要件で、Passkey 署名証跡が不要な場合

## セキュリティと責任分界（要約）

- **Passkey**: 秘密鍵は Clavis ではなく**認証器側**にある。端末に内蔵される場合と、セキュリティキー等として利用者が持ち運ぶ場合がある。共用端末でも、個人が持ち歩くセキュリティキー等で運用する設計は検討候補になりうる（可否・推奨構成は案件確認）。登録・署名は、認証器による**ユーザー検証**を経る。顔、指紋、PIN はその例であり、使える方式は端末・認証器の構成による。Clavis が生体情報を預かるわけではない。Clavis が保持するのは公開鍵。
- **重要操作**: セッションに加え、操作内容に対応する Passkey 署名を求める。
- **判定の隔離**: 承認条件の判定を伴う場合、判定プログラムはハッシュで指定し、業務システムから切り離した実行環境で、資源上限のもとに実行する。対象と条件は案件ごとに設計する。
- **データの分担**: Clavis が扱うのは識別子、公開鍵、セッション、署名の記録。業務データは各 App 側に留まる。
- **再検証**: 「再検証できる」は、登録済みの照合手段を持つシステム側での照合を指す。外部の独立監査人が常に再検証できる、という意味ではない。公開技術ページでは追記型の監査履歴（ハッシュ連鎖）など検証可能な設計を説明しているが、保持期間・エクスポート条件・保管地域は案件確認。
- **地域・保管条件**: データの保管地域、配信経路、バックアップ、保持期間、サブプロセッサは、この文書だけでは判断しない。最新の公開資料および導入担当へ確認する。**本店所在地（登記上の本店は東京）は、データの保管地域を意味しない。** 国内保管完備も主張しない。
- **脆弱性報告**: security@clavis.nexus（公開セキュリティポリシー参照）

詳細は https://clavis.nexus/security を正とする。本文と矛盾する場合は `/security` を優先する。提供形態・OIDC 接続の公開説明は https://www.deepdive.sh/ も参照する。

## 導入の進め方（目安）

次は典型的な進め方の目安であり、機器調達や運用支援が常に契約範囲に含まれるとは限らない。顧客／SI／DeepDive の役割分担は案件ごとに確認する（この文書だけでは断定しない）。

1. 業務確認 — 対象操作、承認者、実施場所、現在の手順、接続候補の App 数
2. Org／提供形態 — apex ドメイン、共有 SaaS か専有 Instance か
3. 機器選定・調達 — PC、スマートフォン、セキュリティキー、配備と初期設定（案件による）
4. 接続設計 — 各 App への OIDC／API、操作内容と `message_digest` の対応、署名結果の照合
5. 導入・運用 — 動作確認、利用開始、問い合わせ、構成変更・App 追加

相談の入口: 製品は https://clavis.nexus/pricing 。SI・専有・請求は https://www.deepdive.sh/contact/

## 言い過ぎ防止（AI が守るべき禁則）

この文書に**明記されていない**機能、対応規格、認証取得、データ所在地、保持期間、監査・エクスポート機能、暗号化方式、復旧方式、納期、サポート条件、Polar に無い単価を推測で補わないこと。「一般的な Passkey 製品では」を Clavis の仕様へ置き換えないこと。

この文書に**明記されている**事実（OIDC／JWKS／API、Org／App、共有 SaaS／専有 Instance、認証器の幅、導入ステップ、責任分界、Polar 公開価格）を未記載扱いにして否定しないこと。不明なのは組織側の前提と案件範囲のみとし、質問または未決として扱うこと。

次を製品の約束として断定しないこと。

- SLA／稼働率の数値確約
- QES／法定電子署名「同等」
- KYC／本人確認レベルの保証
- 「画面の見た目そのものが暗号的に署名されている」（署名対象は操作内容の照合値）
- 5W1H 全項目の暗号的保証
- 分散台帳／非中央集権
- WASM 実行やスマートコントラクトを製品機能として説明すること
- 特定の IdP／RP 製品との標準連携済みであること
- SAML／SCIM／ソーシャルログイン等の対応、または汎用 CIAM／大手 IdP 置換であること
- 法務・監査要件への適合を Clavis 単体で完結すること
- 共用端末では Passkey が使えない、といった認証器モデルの断定
- 国内データ保管の完備
- 「既存 IdP が無い＝導入不可／前提が欠けている」といった断定（Clavis 自体が IdP になりうる）

## 検討メモに含めてほしい項目

組織の前提を聞いたうえで、次を短く整理する。断定できない点は未決のまま残す。**SI 規模の目安**（接続 App 数・操作系統・提供形態・認証器配備の要否）を短く書いてよい。Polar に無い単価は推測しない。公開カタログ（署名 / 台帳）は上記の価格を使う。Enterprise プランは個別見積もり。

1. 適合しそうな点
2. 懸念・ギャップ
3. 未決事項（推測で埋めない）
4. 営業／実装担当へ確認すべき質問（少なくとも次を必要に応じて含める）
   - 接続候補の App（業務システム）の数と種類、対象とする重要操作の系統
   - Org の錨となる apex ドメインの有無、共有 SaaS か専有 Instance か
   - Clavis を IdP とするか／既存認証との併用か。OIDC 接続とアカウント停止・失効の扱い
   - 各 App 側での操作内容と `message_digest` の対応方法
   - 検証の主体、検証に必要な記録、保持・取得・エクスポートの条件
   - 対応端末、共有端末の場合の認証器（個人持参のセキュリティキー等か／端末内蔵のみか）、紛失・機種変更時の復旧
   - 機器調達・配備の顧客／SI／DeepDive の分担
   - 保管地域、バックアップ、サブプロセッサ
   - 障害時運用、問い合わせ範囲、顧客と DeepDive の責任分担
   - 法務・監査要件への適合評価を誰が行うか
