--- title: "AIワークスペースのプライバシー設計: Kylonの多層防御アーキテクチャ" description: "KylonはAIエージェントを信頼しない前提で設計。VM分離、bubblewrapサンドボックス、RBAC、接続アクセス制御、HITL承認の多層防御でデータを保護します。" url: "https://kylon.io/ja/blog/kylon-privacy-architecture" language: "ja" --- MEDIA AI活用の最前線 [HOME](https://kylon.io/ja)\>[ブログ](https://kylon.io/ja/blog)\>[プライバシーと信頼](https://kylon.io/ja/blog/topics/privacy-and-trust)\>AIワークスペースで最も難しい課題はプライバシーである Research2026年7月24日·9分で読める # AIワークスペースで最も難しい課題はプライバシーである AIエージェントがファイルを読み、外部サービスを操作し、ユーザーの代わりに行動する。そのとき、プライバシーは設定画面の問題ではなく、アーキテクチャの問題になります。Kylonの多層防御設計を解説します。 K Kylon Team Engineering · 9分で読める ## AIワークスペースのプライバシー 多くのAI製品にとって、プライバシーとは設定画面のトグルスイッチです。データ保持のオン/オフ。モデル学習へのオプトアウト。フッターに並ぶコンプライアンスバッジ。 AIがチャットボットとして別タブで動いているうちは、それで十分でした。しかし、AIがワークスペースのメンバーとしてファイルを読み、外部サービスを操作し、データベースに書き込み、ユーザーの代理で行動するようになった瞬間、その前提は崩れます。 ## なぜエージェントがプライバシーを難しくするのか 従来のSaaSアプリケーションには明確な信頼境界があります。ユーザーが認証し、アプリが権限を検査し、データ層がアクセスを制御する。コードは決定論的で監査可能です。AIエージェントはこのモデルに適合しません。アクションを確率的に生成し、プロンプトインジェクションによって操作される可能性があり、チャンネル・接続・ユーザーをまたいで動作します。 モデルに境界を守らせることは、確率的テキスト生成器にセキュリティ判断を委ねることと同じです。そこでKylonは、**モデルを信頼しない入力として扱い**、モデルが触れることのできないインフラ層ですべての境界を強制します。 KYLON公式LINE ### 仕事で使える生成AI情報を、LINEで毎週チェック 重要な生成AIニュースと、企業での活用事例をコンパクトにお届けします。営業、顧客対応、採用、バックオフィスで使える実務のヒントも、週ごとにまとめます。 [Kylon公式LINEを友だち追加](https://lin.ee/UM9AHkx) ![Kylon公式LINE QRコード](https://kylon.io/assets/line-qr.png)登録は無料です。配信停止はいつでもLINE上で設定できます。 ## 多層防御アーキテクチャ ![Kylonの多層防御アーキテクチャ](https://kylon.io/blog-assets/privacy-layers.webp) VM分離からサニタイズまで、独立した防御層 ### エージェントごとのVM分離 すべてのエージェントは、専用のハードウェア仮想化microVMで実行されます。カーネル、メモリ空間、ディスクが完全に分離されたフル仮想化です。エージェントAは、エージェントBのプロセス、メモリ、ファイルシステムを物理的に観測できません。侵害されても、影響範囲はそのVM1台に限定されます。 > “原則: 信頼するのではなく、封じ込める。すべてのエージェントは侵害される前提で設計し、侵害されても影響が退屈なほど小さくなるようにする。” ### コマンド単位のbubblewrapサンドボックス すべてのシェルコマンドを**bubblewrap**ベースのnamespaceサンドボックス内で実行します。ホワイトリストモードで動作し、ルートファイルシステムは空のtmpfsから始まり、明示的に指定されたパスのみがマウントされます。 - **書き込み可能パスは1つだけ**。エージェントの一時作業ディレクトリのみ - **読み取りホワイトリストはコマンド呼び出しごとに再計算**。現在のチャンネルのディレクトリ、エージェント自身の設定ディレクトリ、共有ワークスペースナレッジのみ - **ブロック対象パス**はゼロ権限のオーバーレイで遮蔽 - **ネットワークアクセス**はコマンド単位で制御可能 - **プロセス生成**はseccompフィルタでfork、cloneなどのsyscallを遮断 ホワイトリスト外のパスは「アクセス拒否」ではなく、namespaceにマウントされていないため、**存在しない**状態です。#engineeringのエージェントが#hrのファイルを読もうとしても、lsでもfindでもヒットしません。 > “原則: 未認可のパスは「禁止」ではなく「不可視」にする。アクセス拒否はパスの存在を示唆する。空のnamespaceは何も伝えない。” ### RBACによるファイルアクセス制御 ワークスペースのファイルはクラウドストレージから読み取り専用でマウントされ、単一ワークスペースにスコープされます。永続化にはワークスペースAPIを経由し、チャンネルメンバーシップ、パスポリシー、エージェントID検証のフルRBACチェックを実行します。 ### 接続アクセス制御 ![フラットアクセスとユーザーごとの接続所有権の比較](https://kylon.io/blog-assets/privacy-connections-ja.webp) 従来のAIツールとKylonの接続モデルの違い こうした場面を想定してみてください。エージェントが「チームカレンダーを確認して」と依頼を受け、あるメンバーのカレンダー接続で別のメンバーの非公開予定を読み取ってしまう。プロンプトインジェクションではなく、ワークスペースレベルで共有された接続にユーザー単位のスコープがないというアーキテクチャ上のギャップが原因です。Kylonの接続モデルはこの種の障害を防ぐ設計になっています。 - **接続は個人に帰属**。Gmailの接続はユーザー本人のもの - **エージェントには明示的な個別付与が必要**。一括付与ポリシーはACL層でエージェントを除外 - **委任はスコープされ、仲介される**。エージェントは生の認証情報を保持しない - **認証情報は暗号化して保存**。実行時のみメモリ上で復号 > “原則: 接続はAIではなく、人間のものである。すべての委任は明示的で、スコープされ、取り消し可能でなければならない。” ## 外部アクション: AIは下書きだけ、送信は人間だけ ![人間によるレビューと承認のフロー](https://kylon.io/blog-assets/privacy-hitl-ja.webp) AIが下書き、システムが遮断、人間が確認、承認後に送信 エージェントがメールを送信しようとすると、システムがそれを遮断し、レビュー可能な下書きに変換します。承認は**アクションごとのフィンガープリント**に紐づいており、承認後に何かが変更されると自動的に無効化されます。 この攻撃を想定してみてください。プロンプトインジェクションで無害に見えるメールの承認を取得し、送信前に宛先と本文を差し替えるよう指示する。フィンガープリントチェックがこれをブロックします。承認は1通の正確なメッセージに対して発行されており、改変後のバージョンとは一致しません。送信は失敗し、改変された内容は人間のレビュアーに可視化されます。 > “原則: AIは下書きできる。送信できるのは人間だけ。人間が承認するのは正確な内容であり、白紙委任ではない。” ## 継続的モニタリング - **サンドボックス違反の異常検知**。ホワイトリスト外へのアクセス試行はブロック済みでもログに記録。パターン分析でプロンプトインジェクションの兆候を検出 - **接続アクセスの監査**。すべての委任がログに記録。異常パターンでアラートを発報 - **フィンガープリント不一致の追跡**。HITL検証失敗時、変更前後の内容がログに記録 > “原則: ログだけでなく、ループを監視する。アーキテクチャが何かを検出したときに教えてくれる仕組みが必要。” ## まとめ AIワークスペースのプライバシーが難しい理由は、暗号化やACLが複雑だからではありません。モデルが影響を与えられないインフラ層、正確な内容を検証する人間のゲート、そして継続的モニタリングの組み合わせで解決します。AIが実際の行動権を持つとき、プライバシーにはこのアーキテクチャが求められます。 Kylonのセキュリティアーキテクチャについて、詳しくお話しします。 [無料相談を予約する](https://cal.com/forms/5bd983bd-70e5-4afa-afd7-098b78cde6c3) ## 関連記事 [プライバシーと信頼をもっと見る](https://kylon.io/ja/blog/topics/privacy-and-trust) [ ### AIエージェントの権限管理｜Kylonの閲覧範囲と利用権限を決める4つの設定 この会話は誰が見られるのか。AIエージェントは何を参照できるのか。アプリのデータは何が更新するのか。連携した自分のアカウントは誰が使えるのか。Kylonの権限は、この4つの設定で決まります。実際の製品画面とあわせて、1つずつ整理します。 つきのこ·2026年9月15日 ](https://kylon.io/ja/blog/how-permissions-work-in-kylon)[ ### Kylonとは：人のチームとAI社員のチームで売上を最大化するワークスペース AI社員がチャンネルに入り、実際の業務を担当するワークスペースがKylonです。従来ツールとの違い、チャンネル、メモリ、コネクション、アプリ、ワークフロー、スキルといった機能、権限とセキュリティ、料金、そして実際に動いているユースケースとCRMの画面まで、製品の全体像を1本にまとめました。 つきのこ·2026年8月28日 ](https://kylon.io/ja/blog/kylon-product-overview-2026)