クラウドとプライバシー

アウトライナーやノートアプリには、 仕事のメモ、考え途中のアイデア、個人的な記録など、 さまざまな情報が蓄積されていきます。 こうしたツールでは、 データがどこに保存され、誰がアクセスできるかが重要になります。

Kosshi のデータは各デバイスに SQLite データベースとしてローカル保存されています。 デバイス間の同期には Apple の CloudKit を使っており、 同期データはユーザーの iCloud アカウントに保存されます。 開発者がその内容にアクセスすることはできません。

この記事では、 クラウドを利用するツールのデータ保存方式の違いと、 Kosshi がこのアーキテクチャを選んだ理由を説明します。

同期サービスとデータの保存先

ツールがデバイス間でデータを同期する方法は、 主に以下のパターンがあります。

サービスのサーバーに保存する方式。 Notion や WorkFlowy などが採用しています。 データはサービス提供者のサーバーに保存され、 クライアントアプリやブラウザがそれを取得して表示します。 どのデバイスからでもアクセスでき、共同編集にも向いています。

ローカルファイルとして保存する方式。 Bike がこの方式です。 データは端末上のファイルとして存在し、 同期は行わないか、ファイル同期サービスに委ねます。 データの管理は完全にユーザーの手にあります。

エンドツーエンド暗号化（E2EE）を用いる方式。 Standard Notes などが採用しています。 データはサーバーに保存されますが、 クライアント側で暗号化してからアップロードするため、 サーバー上では内容を読めない仕組みです。 プライバシーの保護としては強い方式ですが、 後述するように技術的な制約があり、 実際に採用しているサービスは限られています。

Kosshi はデータをデバイスにローカル保存しつつ、 同期には Apple の CloudKit を使っています。 CloudKit は Apple のメモ（Notes.app）や リマインダーでも使われている iCloud の同期基盤です。 つまり、iCloud でメモを同期している人は、 Kosshi と同じインフラをすでに利用していることになります。

サーバーにデータを預けるということ

多くの生産性ツールは、 サービス提供者のサーバーにデータを保存しています。 一般的な方式であり、 それ自体が危険ということではありません。

ただし、この方式にはいくつかの特徴があります。

• サービス提供者が技術的にデータにアクセスできる状態にある
• サービスが終了した場合、エクスポート手段の有無がデータの継続性を左右する
• 利用規約の変更がデータの取り扱いに影響する可能性がある

個人利用であれば、 信頼できるサービスを選べば実際に問題になることはほとんどありません。 多くのサービスは適切なセキュリティ対策を講じており、 データを安全に管理しています。

一方、組織で利用する場合は状況が変わることがあります。 取引先や顧客に関する情報を扱うとき、 データの保管場所や第三者のアクセス可能性は セキュリティ監査やコンプライアンスの対象になります。 「どのサーバーに、誰がアクセスできる状態で保管されているか」を 説明する必要がある場面があります。

エンドツーエンド暗号化について

E2EE はサーバー側でデータの内容を読めなくする技術です。 クライアントで暗号化し、 サーバーには暗号化されたデータだけが保存されます。 サービス提供者が内容にアクセスすることを技術的に防ぎます。

原理上はデータの秘匿性が高い方式ですが、 実用上のトレードオフがあります。

• 暗号鍵の管理がユーザーの責任になる。鍵を紛失するとデータを復元できない
• サーバー側でデータの内容を扱えない。全文検索、バージョン履歴の比較、データ破損時の復旧などが制限される

これらの制約により、 実際に E2EE を実現しているサービスは限られています。

E2EE は「サーバーに預けるが、中身を見せない」という方式です。 「サーバーに預けない」方式とは異なります。

Kosshi が CloudKit を使う理由

Kosshi の同期には CloudKit の「プライベートデータベース」を使用しています。 データはユーザーの iCloud アカウントに紐づく専用のストレージに保存され、 開発者が個々のユーザーのデータを閲覧する API は提供されていません¹。

この仕組みには以下の利点があります。

データは常にデバイス上にある。 アウトラインのデータは各デバイスにローカル保存されているため、 オフラインでも通常通り使えます。 CloudKit はデバイス間で変更を同期するために使われるもので、 データの主な保管場所はあくまでユーザーのデバイスです。

同期データの所有者がユーザー自身である。 同期のためにクラウドに保存されるデータは、 ユーザーの iCloud コンテナに入ります。 Apple の iCloud ストレージの一部として管理され、 開発者のサーバーには保管されません。

アカウント作成が不要。 同期には Apple Account を使います。 新たにアカウントを作成する必要がなく、 メールアドレスやパスワードを開発者に預ける必要もありません。

Apple のインフラを利用できる。 データは Apple のデータセンターに保存され、 転送時と保存時の両方で暗号化されます。 iCloud の「高度なデータ保護」を有効にすると、 CloudKit のデータにもエンドツーエンド暗号化が適用されます²。

開発者側にサーバーがない。 データを保持するサーバーが開発者側に存在しないため、 そのサーバーからの情報漏洩というリスクがありません。 これは買い切りモデルを可能にしている理由でもあります。 サーバーの維持コストがないため、 サブスクリプションなしでサービスを継続できます。

組織での利用について

個人のメモであれば、 どの方式でも大きな問題になることはほとんどありません。 業務で使う場合は、 データの取り扱いについてより慎重な判断が求められます。

サービスのサーバーにデータを保存する方式では、 サービス提供者のセキュリティ体制を確認する必要があります。 SOC 2 レポート、データセンターの所在地、 従業員のアクセス権限、インシデント対応体制などが 監査の対象になることがあります。

CloudKit 方式の場合、 データの保管先は Apple の iCloud インフラです。 Apple は SOC 2、ISO 27001 などの認証を取得しており³、 Apple Business Manager による iCloud アカウントの管理にも対応しています。 サービス提供者（アプリの開発者）のサーバーを 監査対象に加える必要がない点は、 組織にとって判断材料になる場合があります。

ただし、CloudKit 方式にも制約があります。 Apple エコシステムに限定されること、 共同編集に対応していないこと、 管理者向けの詳細なアクセス制御がないことなどです。 組織の要件によっては、 サーバー方式のツールの方が適している場合もあります。

まとめ

同期の方式によって、データの所在と管理者が異なります。

Kosshi は CloudKit を使うことで、 デバイス間の同期を実現しながら、 データをユーザーの管理下に置いています。