Whitepaper
AI時代の共有事故に、どう備えるかを整理しました
資料請求
従来の共有運用の限界
教育と注意喚起だけでは防ぎきれない、誤送信・放置リンク・AI経由共有の課題を整理します。
事故前提の共有設計
事故をゼロにするのではなく、起きても広がりにくくする設計原則を示します。
社内ストレージだけでは埋めにくい外部送付の空白地帯
社内保管・共同編集と、外部送付の瞬間に必要な共有停止・回数上限・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にも同じ統制をかける考え方を整理します。
AIエージェントコマースへの拡張
AI基盤やモデルが変わっても、社外取引の目的・責任主体・予算・quote・支払い・履行・取消を一つのcanonical ledgerへ固定する考え方を整理します。Threes／OnePlaceとeSIMはパートナーstagingとして区別します。
信頼性強化ロードマップ
日本の法令と業務運用を前提とした整備、第三者診断、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
信頼性強化は、運用整備から先に進めます
公開済み
セキュリティ、プライバシー、保持期間、サブプロセッサー、法務情報の説明ページを公開し、運用境界を明示。
次の優先事項
第三者による Web アプリケーション脆弱性診断と是正、結果に応じた公開情報・営業資料・whitepaperの更新。
中期検討
プライバシーマーク、ISMS / ISO 27001の適用範囲、電気通信事業法上の届出要否を、事業規模と要件に応じて専門家と確認。
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を回復処理まで照合