次世代ビジネスファイル転送サービス
機密ファイル共有の
新しい基準へ
PPAPを置き換える、安全で確実なファイル受け渡し基盤
ブラウザ内暗号化
平文のまま送らない設計
送信後も統制
共有停止・開封確認・監査ログを一体化
人×AI×AI
用途と期限を限定した安全な受け渡し
事故が広がりにくい
個人運用に依存しすぎない共有基盤
人の注意力だけに頼る共有は、もう限界です。
Sealithは、ヒューマンエラーやAI時代の不確実性を前提に、事故が広がりにくい共有構造を提供します。
監査ログ完備 / 日本の法令と業務運用を前提に設計 / JIS Q 27001適合運用を想定
Why now
「気をつけて共有する」だけでは、事故は防ぎきれない。
誤送信、放置リンク、過剰共有、AI経由の再利用。共有のリスクは、保管先だけでなく運用の複雑さから生まれます。Sealithは鍵の所在だけでなく、事故が起きた後も止められ、追え、説明できる構造を設計の中心に置きます。
送る相手や共有経路の判断が個人任せになりやすい
リンクや権限が送信後も放置されやすい
誰がいつ開いたか、あとから説明しにくい
Principles
Sealithの3つの原則
Sealithは、利用者が常に正しく判断できることを前提にしません。共有事故を起こしにくく、起きても広がりにくい構造を3つの原則で支えます。
01
サーバーに復号鍵を置かない
ファイル共有では、ファイル鍵はクライアント側で生成され、受信URLのフラグメントまたはパスコードから復元されます。運営側は暗号化済みファイルだけを保持します。
02
URLとパスコードを分離する
最強モードでは別経路で手動伝達し、標準モードでは遅延メールで通知します。どちらもURLとパスコードを同じ通知に載せません。
03
操作を監査可能にする
作成、閲覧、パスコード試行、ダウンロードまたは外部リンク遷移、失効を監査ログとして記録し、人、AI、システムのどの操作だったかまで追跡できます。
Agent Handoff
AIにも、共有の例外権限を渡さない。
AI活用が進むほど、誰が何の目的で情報に触れたかは見えにくくなります。Business以上では、用途、送信先ドメイン、操作スコープ、有効期限を絞ったAgent Tokenを発行し、人にもAIにも同じ統制原則を適用します。
用途を固定する
contract_review、invoice_processing、due_diligenceなど、エージェントの作業目的を必須化します。
操作を絞る
転送作成、確定、失効、ログ取得、監査文脈追記をスコープ単位で許可します。
説明可能に残す
agent、purpose、jobId、tokenId、ハッシュ付き監査ログで、あとから誰が何のために触ったかを確認できます。
Agent workflows
人とAIの受け渡しを、個別運用ではなく業務フローにする。
Sealithは人や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 blockchain
ブロックチェーンではなく、検証可能な監査ログを選ぶ。
機密ファイル転送に必要なのは、公開台帳への永続記録ではなく、復号能力を持たない設計と、必要な範囲で検証できる操作履歴です。重要なのは、誰もが見られる台帳ではなく、共有事故の説明に使える証跡です。
合意形成より、復号不能性を優先する
ブロックチェーンは複数組織が同じ記録を信頼するための仕組みです。機密ファイル転送では、誰が台帳を持つかより、サービス側が中身を復号できないことが先に来ます。
監査に必要な情報だけを残す
宛先、時刻、操作目的、ファイル名などは業務上の機密や個人情報になりえます。Sealithは公開台帳ではなく、組織内の追記専用ログとハッシュ連鎖で検証可能性を確保します。
訂正、削除、開示範囲を統制する
監査証跡は残しながら、開示先、保存期間、法務対応、退職者や取引先への見せ方を組織の権限で管理できます。外部固定が必要な場合は、ログのチェックポイントだけを別経路で保全できます。
Protocol
暗号化はブラウザ内で完了します。
最強モードではサーバーがパスコード復号手段を持ちません。標準モードではブラウザ内でシステム公開鍵により追加ラップし、遅延送信時のみKMSで復号します。
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も、“送った後は見えない”ままにしない。
ファイル転送が主役のまま、Google Drive や Box などの共有URLも監査付きで渡せます。Sealith が担うのは、URL の受け渡し、パスコード保護、アクセス記録です。共有事故を送信時の判断ミスだけで終わらせないための構造です。
共有URLをそのまま使える
Google Drive、Box、Notion などの共有URLを登録し、受信者には Sealith 経由で渡せます。
有効期限とアクセス回数を制限できる
転送ごとに有効期限（最短1時間〜最長30日）とアクセス回数上限を設定できます。期限超過または上限到達でリンクは自動停止します。
アクセス履歴を残せる
誰に渡したか、いつ受信ページへアクセスしたか、外部リンクを開いたかを監査ログとして確認できます。
あとから共有停止できる
リンク先のデータはそのままに、Sealith 側の受け渡し導線だけを止められます。
境界を明示します
リンク先の閲覧権限やデータ保護は Google Drive などの提供元サービス側に依存します。Sealith は、URL の受け渡しとアクセス監査を担います。
Chrome extension
普段の共有を、無理なく統制の中へ寄せる。
実装済みの Chrome拡張では、ブラウザ上で見えている共有URLをそのまま Sealith の監査付き共有へ変換できます。最初から Google Workspace 全体を強制統制するのではなく、まず共有を寄せる導線として使います。
Chrome拡張でその場で変換
現在のページURL、クリップボードのURL、手入力URLを、そのまま Sealith の監査付きURL共有へ変換できます。全プランで利用できますが、利用量は各プラン上限に従います。
Gmail と Drive で軽く警告
Chrome拡張では、Gmail と Google Drive 上で『そのまま送ると履歴が残りません』という軽い検知バナーを表示できます。
強制統制ではなく、まず寄せる
最初から全共有を強制するのではなく、業務フローを大きく変えずに Sealith 経由へ寄せる導線として使えます。
AI roles
AI 活用は送信側と受信側で役割が違います。
今の主ユースケースは送信側ですが、受信企業が Sealith アカウントを持てば、受信後の社内 AI 処理まで同じ発想で広げられます。
送信側AI
自社が送るときに AI を使う
契約レビュー、請求処理、DD 資料整理のように、自社が送信者となって AI に安全な受け渡し権限を与える使い方です。現行実装の主ユースケースはここです。
自社の人や AI が transfer を作成する
purpose、scope、recipient domain を絞る
送信、失効、監査追記まで同じ基盤で扱う
受信側AI
受け取ったあとに社内 AI で処理する
受信企業も Sealith アカウントを持っていれば、受け取った資料を自社の AI ワークフローへ回す導線を持てます。受信後に新しい送信者として再び Sealith を使う形です。
受信した契約書をレビュー AI へ回す
受信した請求書を会計 AI で照合する
誰がどの AI で扱ったかを自社ログとして残す
Comparison
人、AI、エージェント間の受け渡しを同じ基準で守る。
従来の共有手段は、利用者が都度正しく判断することを前提に設計されがちです。Sealithは人とAI、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への対応ガイド
Anthropicの金融特化エージェント10種と連携する際の情報開示制御・操作ログ・FISC対応を解説します。
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
AI時代の共有事故に、どう備えるかを整理しました。
暗号化方式や保持データだけでなく、個人依存の共有運用の限界、事故を広げにくい設計原則、人とAIを含む共有統制の考え方までホワイトペーパーで確認できます。