次世代ビジネスファイル転送サービス
機密ファイル共有の
新しい基準へ
PPAPを置き換える、安全で確実なファイル受け渡し基盤
ブラウザ内暗号化
平文のまま送らない設計
送信後も統制
共有停止・開封確認・監査ログを一体化
人×AI×AI
用途と期限を限定した安全な受け渡し
事故が広がりにくい
個人運用に依存しすぎない共有基盤
人の注意力だけに頼る共有は、もう限界です。
Sealithは、ヒューマンエラーやAI時代の不確実性を前提に、事故が広がりにくい共有構造を提供します。
監査ログ完備 / 日本の法令と業務運用を前提に設計 / JIS Q 27001適合運用を想定
Why now
「気をつけて共有する」だけでは、事故は防ぎきれない
送る相手や共有経路の判断が個人任せになりやすい
リンクや権限が送信後も放置されやすい
誰がいつ開いたか、あとから説明しにくい
Principles
Sealithの3つの原則
01
サーバーに復号鍵を置かない
ファイル共有では、ファイル鍵はクライアント側で生成され、受信URLのフラグメントまたはパスコードから復元されます。運営側は暗号化済みファイルだけを保持します。
02
URLとパスコードを分離する
最強モードでは別経路で手動伝達し、標準モードでは遅延メールで通知します。どちらもURLとパスコードを同じ通知に載せません。
03
操作を監査可能にする
作成、閲覧、パスコード試行、ダウンロードまたは外部リンク遷移、失効を監査ログとして記録し、人、AI、システムのどの操作だったかまで追跡できます。
Agent Handoff
AIにも、共有の例外権限を渡さない
許可を固定する
purpose、allowedUse、recipientTypeを必須の文脈として扱い、AIが動く前に何を許可したかを記録します。
操作を絞る
転送作成、確定、失効、ログ取得、監査文脈追記をスコープ単位で許可します。
説明可能に残す
agent、purpose、jobId、tokenId、ハッシュ付き監査ログで、あとから誰が何のために触ったかを確認できます。
Agent workflows
人とAIの受け渡しを、個別運用ではなく業務フローにする
1
渡す相手を限定
人、社内AI、外部AIごとに閲覧できる範囲を分けます。
2
用途を固定
contract_reviewやinvoice_processingなど、作業目的を記録します。
3
終わったら追跡・失効
AIの結果、jobId、tokenId、失効までを監査ログに残します。
契約レビューの一次確認
営業が受け取った契約書を、法務担当とレビューAIだけが触れる形で受け渡します。
営業担当
契約書をSealithに登録
Sealith
法務とレビューAIだけに期限付き共有
契約レビューAI
リスク条項を抽出し結果を追記
法務担当
原本とAIの指摘を確認
監査ログ
purpose、jobId、tokenIdを記録
Sealithは原本を復号せず、誰がどの目的でAIに渡したか、AIが何を返したかを監査ログに残します。
請求書と証憑の自動照合
取引先から届く請求書を、会計AIと経理担当が必要な範囲だけ見られるようにします。
取引先
請求書と証憑を提出
Sealith
会計AIに用途限定の閲覧権限を発行
会計AI
金額、発注書、証憑を照合
経理担当
差分を承認
Sealith
承認結果を記録し共有を失効
会計システム
処理結果だけを保存
Sealithは請求処理だけに使える権限を渡し、承認後は失効まで含めて履歴を残します。
M&Aデューデリジェンスの資料共有
売り手側の資料管理AIと買い手側の分析AIが、期限、回数、目的を絞ってDD資料を扱います。
売り手担当
DD資料をSealithに登録
資料管理AI
相手、期限、回数、目的を指定
Sealith
買い手分析AIに限定アクセスを発行
買い手分析AI
資料を要約し質問候補を作成
FA・責任者
要約とアクセス履歴を確認
Sealithを間に置くことで、AI同士でも直接渡しっぱなしにせず、取得、分析、失効を説明できます。
Why not everything on-chain
すべてをブロックチェーンに載せない。必要な証拠だけを検証可能にする
機密本文と業務文脈は公開しない
ファイル本文だけでなく、宛先、purpose、ファイル名、取引先も機密や個人情報になりえます。公開台帳へ永続記録せず、業務に必要な範囲で保持します。
操作履歴は追記専用ログで改変を検知する
Sealithは組織内の追記専用ログとハッシュ連鎖で、記録の欠損や改変を検証できるようにします。必要な訂正も元記録を書き換えず、追加の監査文脈として残します。
外部合意が必要な事実だけ、外部証拠を参照する
機密データはオフチェーンに保ち、JPYCのtx hashやProviderの結果など、外部で確定した事実だけを業務記録へ結びます。ブロックチェーンを否定せず、適切な証拠に限定して使います。
Protocol
暗号化はブラウザ内で完了します
Sender
送信者
ブラウザ内でファイルを暗号化し、復号に必要な情報をURLとパスコードに分けます。
Sealith
暗号文だけを預かる
保管するのは暗号化済みファイルと送信管理に必要なメタデータです。ファイル本文はここでは読めません。
Recipient
受信者
URLとパスコードを受け取り、受信者のブラウザ内でだけファイルを復号します。
標準モード
- Sealithが保持するもの
- 暗号文、宛先、有効期限、監査ログ、遅延送信用に暗号化されたパスコード
- Sealithが保持しないもの
- ファイル本文、復号済みファイル鍵、通常時のパスコード平文
- サーバー側の復号補助情報
- あり。予約送信と再通知のために、KMS前提の暗号化済み補助情報を扱います。
最強モード
- Sealithが保持するもの
- 暗号文、宛先、有効期限、監査ログ、パスコード照合用の復元できない値
- Sealithが保持しないもの
- ファイル本文、復号済みファイル鍵、パスコード平文、パスコードを復号する手段
- サーバー側の復号補助情報
- なし。サーバー側に復号を助ける手段を残さず、復号条件を送信者と受信者に限定します。
1
ファイル鍵生成
Web Crypto APIでAES-GCM鍵を生成
2
暗号化
ファイル本体をブラウザで暗号化
3
保管
暗号文をR2、メタ情報をFirestoreへ保存
4
復号
受信者のブラウザでのみ復号
サーバーに復号鍵を置かない、とは何が違うのですか？
これはファイル共有の境界を指します。Sealith側がどこまで復号を助ける手段を持つか、という違いです。標準モードは予約送信や再通知のために、KMS前提で暗号化された補助情報を扱います。最強モードはその補助情報も持たず、受信時の復号条件を送信者と受信者に限定します。URL共有ではリンク自体を保持し、受け渡しと監査を担います。
サーバーにデータ自体も置いていないのですか？
いいえ。Sealithが保管するのは暗号化済みファイル、URL共有で指定されたリンク、宛先、期限、監査ログなどの運用情報です。ファイル本文を平文のまま保管せず、受信者のブラウザ内でのみ復号します。
Data handling
データの取り扱いを先に開示する
機密情報を扱う以上、何を保管し、何を保管せず、いつ共有停止や本体削除の対象になるかを明確にします。
保管するもの
暗号化済みファイル、宛先、有効期限、ダウンロード制御、監査ログ、運用に必要なメタデータを保持します。
保管しないもの
平文ファイル、復号済みファイル鍵、最強モードでの復号補助手段は保持しません。
共有停止の条件
手動停止、期限到達、ダウンロード上限到達により、受信リンクの利用を停止できます。
本体削除のタイミング
保持期間が満了すると、暗号化ファイル本体は削除され、転送履歴と監査ログは保持されます。
アーカイブの意味
アーカイブは通常一覧から隠すための整理機能です。削除ではなく、共有状態と監査ログは維持されます。
Audited URL sharing
共有URLも、“送った後は見えない”ままにしない
共有URLをそのまま使える
Google Drive、Box、Notion などの共有URLを登録し、受信者には Sealith 経由で渡せます。
有効期限とアクセス回数を制限できる
転送ごとに有効期限（最短1時間〜最長30日）とアクセス回数上限を設定できます。期限超過または上限到達でリンクは自動停止します。
アクセス履歴を残せる
誰に渡したか、いつ受信ページへアクセスしたか、外部リンクを開いたかを監査ログとして確認できます。
あとから共有停止できる
リンク先のデータはそのままに、Sealith 側の受け渡し導線だけを止められます。
境界を明示します
リンク先の閲覧権限やデータ保護は Google Drive などの提供元サービス側に依存します。Sealith は、URL の受け渡しとアクセス監査を担います。
Chrome extension
普段の共有を、無理なく統制の中へ寄せる
Chrome拡張でその場で変換
現在のページURL、クリップボードのURL、手入力URLを、そのまま Sealith の監査付きURL共有へ変換できます。全プランで利用できますが、利用量は各プラン上限に従います。
Gmail と Drive で軽く警告
Chrome拡張では、Gmail と Google Drive 上で『そのまま送ると履歴が残りません』という軽い検知バナーを表示できます。
強制統制ではなく、まず寄せる
最初から全共有を強制するのではなく、業務フローを大きく変えずに Sealith 経由へ寄せる導線として使えます。
AI roles
AI 活用は送信側と受信側で役割が違います
送信側AI
自社が送るときに AI を使う
契約レビュー、請求処理、DD 資料整理のように、自社が送信者となって AI に安全な受け渡し権限を与える使い方です。現行実装の主ユースケースはここです。
自社の人や AI が transfer を作成する
purpose、allowedUse、recipientType、scope、recipient domain を絞る
送信、失効、監査追記まで同じ基盤で扱う
受信側AI
受け取ったあとに社内 AI で処理する
受信企業も Sealith アカウントを持っていれば、受け取った資料を自社の AI ワークフローへ回す導線を持てます。受信後に新しい送信者として再び Sealith を使う形です。
受信した契約書をレビュー AI へ回す
受信した請求書を会計 AI で照合する
誰がどの AI で扱ったかを自社ログとして残す
Comparison
人、AI、エージェント間の受け渡しを同じ基準で守る
人と人
既存のやり方
メール添付、パスワード付きZIP、一般的なクラウド共有
URL、パスコード、ファイル本文、共有権限が同じ経路や同じ管理画面に集まりやすく、期限切れや再送の履歴も運用任せになりがちです。
Sealithなら
ファイルはブラウザ内で暗号化し、URLとパスコードを分離。期限、DL回数、失効、受信確認を監査ログとして残します。
人とAI
既存のやり方
担当者がAIツールへファイルを直接アップロード、または共有URLを貼り付け
どのAIに、何の目的で、どの範囲のファイルを渡したかが業務ログに残りにくく、作業後のアクセス失効も人の判断に依存します。
Sealithなら
Agent Tokenでpurpose、許可する利用範囲、受け渡し先種別、期限、送信先、操作スコープを限定。AIの結果、jobId、tokenIdまで同じ監査ログで追跡します。
AIとAI
既存のやり方
社内AIと外部AI、または複数エージェント間でAPIキーや共有ストレージを使い回す
AI同士の受け渡しは人の目に見えにくく、直接連携にすると権限が広がりすぎたり、あとから経路を説明しにくくなります。
Sealithなら
Sealithを中継点にして、AIごとに用途限定のアクセスを発行。取得、分析、監査文脈追記、失効までを説明可能にします。
Use cases
機密度の高い業務に合わせた転送
機密性が高いほど、共有の安全は現場判断ではなく制度として持つ必要があります。
法務・契約
NDA、契約書、訴訟資料の授受
金融・M&A
投資資料、財務資料、DD資料、KYC
医療・個人情報
期限と回数を制御した資料共有
金融AIエージェント
KYC審査・月次決算・財務監査AIへの目的限定開示
金融AIエージェント向け
KYC・月次決算・財務諸表監査AIへの対応ガイド
金融特化エージェントと連携する際の情報開示制御・操作ログ・FISCの確認観点を解説します。
AI Work Governance to Agent Commerce
AIが作ったものには、来歴を。外へ出すものには、承認を。取引したものには、履行と回復を
AIが作ったものの来歴をWork Passportへ、社外へ出す判断をRelease Controlへ、その先の予約・購入・履行・回復を一つの取引線へ結びます。
AI WORKSPACE / HARNESS
AIが考え、仕事を作る
Cloudflare OS、Gemini、Copilot、OpenClaw、独自エージェント
AI WORK PASSPORT / RELEASE CONTROL
会社の責任として外へ出す
委任・来歴信号・成果物binding・policy・人間承認
SEALITH TRANSACTION BOUNDARY
会社が取引を委任する
目的・責任主体・予算・quote・承認・冪等性
PROVIDER / PAYMENT RAIL
社外で履行される
OnePlace、eSIM、JPYC、将来のProviderを回復処理まで照合
Pricing
無料から、組織利用まで
Free
¥0
月額
100 MB / 7日
Starter
¥980
組織 / 月
1 GB / 30日
Team
¥2,980
ユーザー / 月
3 GB / 60日
Business
¥9,800
組織 / 月
5 GB / 最大3年（管理者設定）
Enterprise
応相談
契約準拠
50 GB / 無期限（管理者設定）
Next