Claude Designのデータ保持とセキュリティ — アップロードした資産はどう扱われるか
Claude Designにアップロードした資産は永続的に保存され、他のAnthropic Enterprise製品と同じ削除ポリシーに従います。データレジデンシー非対応など導入前の要点をまとめます。
Claude Designにアップロードした資産はどう保存されるか
Claude Designでは、ブランド資産・スクリーンショット・コードベースなど、デザインシステムの元になる素材をアップロードします。アップロードした資産は永続的に保存され、Anthropicの他のEnterprise製品と同じデータ保持・削除ポリシーの対象になります。個別に専用の保持ルールがあるわけではなく、Claude Design用の特別扱いは存在しません。
データガバナンス要件を持つ組織にとって重要なのは、この「特別扱いがない」という点そのものです。Claude Designだけ別ルールで動いていると考えていると、実際の挙動と食い違います。
アップロードする素材の中身
デザインシステムの設定でアップロードする対象は、コードベースやスライド資料などのデザイン参照、ブランド資産・ガイドライン、スクリーンショットです。プロジェクト作業中にも、参照用のスクリーンショットや既存デザインファイルをその都度アップロードする場面があります。具体的な設定手順はClaude Designで自社のデザインシステムを設定する手順で扱っているので、ここではアップロードした後にデータがどう扱われるかに絞ります。
素材の中でも扱いに注意が要るのは、コードベースの接続です。プロダクトのコンポーネントライブラリをClaude Designにリンクすると、社内の実装パターンや命名規則も含めて資産としてアップロードされます。ロゴやカラーパレットのような公開前提の素材とは機密度が異なるため、社内の情報取り扱い規程で「どのリポジトリなら接続してよいか」を先に決めておくと、あとから資産の扱いで揉めずに済みます。
Team/Enterpriseの標準ポリシーとどうつながるか
「他のEnterprise製品と同じ保持・削除ポリシー」という説明は、抽象的に聞こえるかもしれません。実際にはTeam・Enterpriseプランの共通ルールに従うという意味です。製品画面上でチャットや会話履歴を削除すると、見える履歴からは消えます。一方でバックエンドのシステムには別の保持ルールがあり、Enterprise顧客は組織のデータに対してカスタムの保持期間を設定できます。この二層構造(画面上の削除とバックエンド保持)はClaude Team/Enterpriseの送信データの削除とバックエンド保持の境界で詳しく扱っています。公式ガイドは「他のEnterprise製品と同じ保持・削除ポリシー」とだけ述べており、この二層構造がClaude Designのアップロード資産に具体的にどう当てはまるかは明記されていません。
デザインシステムの削除とカスタム保持期間の対象範囲
Enterprise管理者向けのカスタムロールでは、組織のデザインシステムを公開・既定設定・削除する操作を特定メンバーに絞れます。公式ガイドは、この削除操作を「組織からデザインシステムを完全に除去する」と明記しています。一方で、デザインシステムを削除したときに元になったアップロード資産がどう扱われるかは、公式ガイドに記載がありません。削除操作の対象範囲がデザインシステム自体に限定されるのか、元のアップロード資産にも及ぶのかは公表情報からは判断できず、組織として厳密に管理したい場合は前提を置かずAnthropicの営業担当に確認するのが確実です。
Enterprise顧客が組織データに設定できるカスタム保持期間は、公式ガイド上ではチャットとプロジェクトを対象に説明されており、Claude Designのアップロード資産が同じ設定の対象になるとは明記されていません。組織として保持期間を厳密に管理したい場合は、この対象範囲を前提に運用を検討してください。
データレジデンシー要件を満たせない
Claude Designはデータレジデンシー要件に対応していません。特定の地域内にデータを留めることが契約や規制で求められる組織にとっては、この制約が導入可否を直接左右します。
Claude APIには、推論を実行する地域(inference geo)とワークスペースの地域(workspace geo)を分けて扱うデータレジデンシーの仕組みが用意されています。詳しい仕組みはClaudeのデータレジデンシー — inference geoとworkspace geoの違いにまとめています。Claude Designがこの枠組みの対象に含まれるかどうかは公式に説明されていません。データレジデンシーが必須要件の組織は、要件が整うまでClaude Designの利用範囲を限定するという選択肢が現実的です。
プレビューのサンドボックス分離はどう働くか
Claude Designで作ったプロジェクトのプレビューは、Anthropicが運営する別のコンテンツドメイン上で、サンドボックス化されたiframe内で動きます。各プレビューは互いに独立した領域で実行され、プレビュー内のコードがユーザーのClaudeアカウントやログイン情報、エディター本体に到達することはありません。
アクセス制御には署名付きトークンを使います。短命なトークンが、そのプレビューを開く権限を持つかどうかを都度証明する仕組みです。Claudeは共有設定に対してこのトークンを毎回照合するため、誰かのアクセス権を外すと、その場で閲覧できなくなります。
サードパーティ環境からの利用可否
Claude Designはclaude.ai/designのWebインターフェース経由でのみ利用できます。既存のクラウドプロバイダー契約の枠内でClaude Designを使いたい組織は、Anthropicの営業担当に直接問い合わせる必要があります。特定のクラウド環境内にデータを閉じ込めたい組織にとっては、この提供形態自体が事実上のデータレジデンシー制約として働きます。
エクスポート・外部連携で組織の外にデータが出る経路
Claude Designで生成したデザインは、HTMLバンドル・PPTX・PDFの各形式でエクスポートできるほか、Claude Codeへのハンドオフや外部パートナーサービスとの連携が用意されています。公式ガイドが名前を挙げている連携先は、Adobe・Base44・Canva・Gamma・Lovable・Miro・Replit・Vercel・Wixです。必要なフォーマットや連携先が一覧にない場合は、Anthropicの営業担当への問い合わせが窓口になります。
データ保持・削除ポリシーを検討するときに見落としやすいのは、これらの経路がAnthropicの管理環境の外にデータを送り出す点です。アップロード資産や生成物の保持ルールをどれだけ厳密に決めても、エクスポートしたPPTXファイルや外部パートナーに渡したデータは、それぞれの保存先の管理下に置かれます。データガバナンス方針を検討する組織は、Claude Design内部の保持ポリシーだけでなく、エクスポート・連携先ごとの運用ルールもあわせて確認する必要があります。
権限設計とデータ扱いを同時に検討する
データの保存・削除ポリシーを理解したうえで、組織内で誰が資産をアップロードし、誰がデザインシステムを公開・削除できるかという権限設計もあわせて検討する必要があります。Enterpriseプランでのカスタムロール設計はClaude Designの管理者権限をカスタムロールで制御するで扱っています。データガバナンス要件が厳しい組織ほど、アップロードできる人数自体を絞る運用と組み合わせる価値があります。
導入前に確認すべきこと
- アップロード資産はTeam/Enterpriseの標準保持・削除ポリシーの対象で、Claude Design専用のルールは無い
- データレジデンシー要件がある場合、Claude Designでは満たせない
- プレビューはサンドボックス化されたiframeと署名付きトークンで隔離されており、アクセス権の即時失効が可能
- 監査ログには対応していない(利用状況はAnalyticsダッシュボードで代替する必要がある)
- エクスポートや外部パートナー連携を使うと、データがAnthropicの管理環境の外に出る
- コードベース接続時は、機密度の高いリポジトリを対象から外すルールを組織側であらかじめ決めておく
上の5点は公式ガイドに明記された制約です。最後のコードベース運用ルールは公式ガイドにはなく、データガバナンス上の実務的な推奨事項として付け加えています。制約は将来のアップデートで変わる可能性があるため、契約前提となる要件がある場合は、Anthropicの営業担当に対応状況を確認するのが確実です。
まとめ
Claude Designにアップロードした資産は永続的に保存され、他のAnthropic Enterprise製品と同じ保持・削除ポリシーに従います。個別の専用ルールは存在しません。一方でデータレジデンシーには対応しておらず、プレビューはサンドボックスと署名付きトークンで隔離される設計です。監査ログは未対応で、エクスポートや外部パートナー連携を使うとデータがAnthropicの管理環境の外に出ます。アクセス権を外した時点で閲覧できなくなる即時失効の仕組みはあっても、それだけでは足りず、事前の権限設計とアップロード対象・連携先の線引きで運用を固めておく発想が要ります。データガバナンス要件を持つ企業は、これらの制約を権限設計とあわせて確認したうえで導入範囲を決めることになります。