c15t

c15tとは？

c15tは、モダンなウェブアプリケーションにおけるCookie同意とスクリプト読み込みを管理するためのオープンソースフレームワークです。主な目的は、開発者が同意の収集方法を制御し、その同意状態に基づいてトラッキングやその他のスクリプトを有効化（またはブロック）できるようにすることです。

プロジェクトは「developer-first」で「headless」と位置づけられており、基盤となる同意ロジックがユーザーインターフェースから分離されているため、チームは独自のスタックでバナーやダイアログの体験を構築でき、不透明なベンダーロジックに依存する必要がありません。

主な機能

• モダンなウェブアプリ向けのオープンソース同意フレームワーク。Cookie、同意、プライバシーコンプライアンスワークフローに特化。
• クライアント/エッジ実行向けの同意とスクリプト読み込み制御。関連する同意状態が設定されるまでリクエストをブロックすることを目標。
• 複数のフレームワークに対応するヘッドレスコア（対応例: React, Vue, Svelte, Angular, Next.js, Nuxt, SvelteKit, Astro, Solid, Qwik など）。
• CLIスキャフォールディングでCookieバナーを迅速に生成、または「ヘッドレスロジックをドロップイン」して体験を完全に制御。
• 独自のCSS/デザイントークンによるUIカスタマイズ。バナー/ダイアログコンポーネントはスタイリングと統合可能。
• バナーの言語/ロケール処理のためのi18nサポート（一度翻訳すればどこでも同意）。
• ジオロケーションに基づく言語と表示オプション。「最終言語で最終バナーを提供」可能で、表示しない選択も（記述通り）。
• 15以上のプライバシー法管轄域をカバーする管轄域ターゲティング（GDPR、CCPA/CPRA含む）。LGPD、PIPEDA、PIPL、APPIの例あり。

c15tの使い方

典型的なセットアップは、c15tのフレームワーク固有プロバイダとUIコンポーネントを追加し、同意モード、バックエンドURL、同意後にゲートするスクリプトで設定します。

ページのNext.js例から：

1. プロバイダとUIコンポーネントをインポート（例: ConsentManagerProvider、ConsentBanner、ConsentDialog）。
2. プロバイダ設定にスクリプトを追加（例: metaPixel({ pixelId: "..." }) でMeta Pixel）。
3. mode（例: hosted）やbackendURL（環境変数から）を含むオプションを設定。
4. <ConsentBanner /> と <ConsentDialog /> をレンダリングしてユーザーがプライバシー設定を管理。

サイトではCLIによるクイックスタート（npx @c15t/cli）も参照。

ユースケース

• 同意バナーと設定ダイアログが必要なNext.jsアプリ。同意状態をスクリプト読み込みに連動（例: ユーザー選択後に特定アナリティクススクリプト有効）。
• 複数フレームワークチーム向け。単一の同意ロジックに独自UIコンポーネントで構築。ヘッドレスで多フレームワーク互換。
• ローカライズ重視製品。ビルトインi18n/ロケール処理で同意バナーテキストをユーザーの言語で表示。
• 地域横断製品。プライバシー法メッセージ（またはバナー表示有無）を管轄域と言語で変える。ジオロケーションと管轄域設定で対応。
• バナー/ダイアログにカスタムスタイリングとデザイントークン統合を好むチーム。プリベイクUIではなく。

FAQ

• c15tはUIのみのソリューションですか？ いいえ。サイトではヘッドレスコアを記述し、開発者が「ヘッドレスロジックをドロップイン」して体験とスタイリングを制御可能。

• どのフレームワークに対応していますか？ ページではReact, Vue, Svelte, Angular, Next.js, Nuxt, SvelteKit, Astro, Solid, Qwik などと互換性を記載。

• バナーの見た目をカスタマイズできますか？ はい。ページでは独自CSSとデザイントークンでスタイリング可能で、体験を制御すると記載。

• 複数言語をサポートしますか？ はい。ページではビルトインロケール処理付きi18nサポートを記載。

• 異なるプライバシー管轄域をどう扱いますか？ ページではジオロケーションと管轄域ターゲティングを記述。GDPR、CCPA/CPRAなどの例で15以上を言及。

代替案

• ヘッドレス同意管理ライブラリ/フレームワーク非依存: 専用の同意フレームワークを使わず、チームが独自に同意状態管理を構築し、UIの背後でスクリプト読み込みを制御できます。これにより、実装作業を既製フレームワークから移す点が異なります。
• UIに特化したCookie/バナーコンポーネント: 一部のソリューションは主に設定可能な同意バナーを提供します。これらは通常、ヘッドレスアプローチに比べて同意ロジックとスクリプト制御の開発者主導性を犠牲にします。
• 同意モード付きタグ/スクリプト管理ツール: アナリティクス/タグ管理カテゴリの代替案は、同意対応のスクリプトトリガリングを提供する場合があります。ワークフローはヘッドレス同意コアの直接統合ではなく、タグルール中心です。
• プライバシー/コンプライアンスプラットフォーム: これらは通常、より広範なコンプライアンスワークフローを管理します。c15tで説明されたフレームワーク非依存・開発者制御の同意とスクリプト読み込みパターンとは適合度が低い場合があります。