Whitepaper
AI時代の共有事故に、どう備えるかを整理しました。
暗号化方式、URL共有と Chrome拡張を含むデータフロー、保持期間、監査ログ、標準モードと最強モードの境界に加え、個人依存の共有運用がなぜ限界を迎えるのか、そして人とAIを含む共有をどう統制すべきかまで確認できます。
資料請求
従来の共有運用の限界
教育と注意喚起だけでは防ぎきれない、誤送信・放置リンク・AI経由共有の課題を整理します。
事故前提の共有設計
事故をゼロにするのではなく、起きても広がりにくくする設計原則を示します。
B社 / G社 で埋めにくい外部送付の空白地帯
社内ストレージ基盤と、外部送付の瞬間に必要な共有停止・回数上限・AI監査文脈の違いを比較で整理します。
暗号化プロトコル
ファイルと短い機密テキストのブラウザ内暗号化、標準 / 最強の境界、パスコード分離の仕組みを説明します。
データ保管と保持期間
暗号化ファイル共有、暗号化テキスト転送、監査付きURL共有で、何を保管し、何を保管せず、いつ本体削除や共有停止の対象になるかを整理します。
監査ログと説明可能性
作成、開封、試行、ダウンロード、外部リンク遷移、共有停止、アーカイブ、AIエージェント操作をどこまで記録するかを示します。
Slack を次の送付導線にする設計
Business 以上の Slack workspace 連携で、channel / DM へ Sealith の共有リンクを送るときに、どこまで policy と監査を寄せるべきかを整理します。
人とAIの共有統制
Agent Token、purpose、jobId、aiProvider、aiClient、tokenId、MCP連携の扱いに加えて、Claude Code / Cursor のようなローカル実行型と ChatGPT / Claude App のようなリモート実行型で file 転送体験がどう変わるかを含め、人にもAIにも同じ統制をかける考え方を整理します。
信頼性強化ロードマップ
日本の法令と業務運用を前提とした整備、第三者診断、Pマーク / ISMS までの優先順位を示します。
送信側AI
現行実装の主ユースケースです。自社の人やAIが送信者となるとき、どのAIに何の目的で渡したかを用途・期限・送信先ドメイン付きで固定し、purpose、jobId、aiProvider、aiClient を必須監査メタデータとして持たせた上で、転送作成、転送完了、共有停止、監査追記を自動化します。
受信側AI
受信企業も Sealith アカウントを持つ場合、Business 以上で receive_handoff を使い、受信した資料を自社AIワークフローへ回す導線を持てます。受信後の再共有まで含めて、個人判断ではなく統制付きフローとして扱う形です。
今できること
Chrome拡張では、現在のページURL、クリップボードのURL、手入力URLをそのまま Sealith の監査付きURL共有へ変換できます。Gmail と Google Drive では軽い検知バナーも表示できます。現場の共有行動を、無理なく監査付き導線へ寄せるための実装です。
Slack連携の位置づけ
Business 以上では、接続済み Slack workspace の channel / DM に Sealith の共有リンクを投稿できます。メールの代替ではなく、次の B2B 送付導線として扱い、revoke、監査、workspace ごとの posting policy を Sealith 側に残します。
まだやっていないこと
Google Workspace 全体の強制統制、未経由共有の完全検知、管理者向けポリシー適用は現時点では未実装です。そこは次段階の Workspace 管理連携として切り分けています。
公開状況
Chrome拡張は Chrome Web Store で公開済みです。導入手順と利用条件は拡張ページで確認でき、ストアからそのままインストールできます。
Sealith の全体図
ファイル転送、機密テキスト転送、URL共有を同じ統制基盤で扱い、暗号化データ、共有停止、アクセス監査、AI 利用時の追跡まで一つの運用として整理した図です。共有を単なる送付機能ではなく、事故が起きても止められ、追え、説明できる運用構造として捉えるための全体像です。
- ファイルと短い機密テキストはブラウザ内で暗号化し、平文本体を保管前提にしません。
- URL共有では、リンク先権限は外部サービス側、受け渡しと監査は Sealith 側で担います。
- Slack 連携では、共有リンクの配布先を channel / DM まで広げつつ、workspace ごとの allow / deny や strict mode を Sealith 側で管理します。
- 人と AI、AI と AI の受け渡しも同じ監査文脈で追える構成です。
- AI クライアント経由の file 転送は、ローカル実行型とリモート実行型で完結性が変わるため、MCP クライアントごとの実行環境も確認対象です。
Trust roadmap
信頼性強化は、運用整備から先に進めます。
MVP 段階では認証ロゴを先に増やすより、日本の法令と業務運用を前提にした整備、第三者診断、公開説明責任を優先します。思想だけでなく、どこまで整備できているかを開示するためのロードマップです。
30日
個人情報保護法、特商法、特定電子メール法、電子帳簿保存法を踏まえた運用整備と、セキュリティ説明ページの公開。
90日
第三者による Web アプリケーション脆弱性診断と是正、営業資料や whitepaper への反映。
180日
プライバシーマーク着手、ISMS / ISO 27001 の適用範囲整理、電気通信事業法届出要否の専門家確認。