これは5つの決定のうち5番目、可視性(Visibility)です。これまでに展開のコストを設定してきました。このレッスンでは可視性、すなわち3つの要素(Compliance API、OpenTelemetry、保持期間)と、その中で後戻りが難しい1つの決定について扱います。
可視性は何のためにあるのか
最初の4つの決定は、Claudeが何を行うかを設定するものでした。可視性は、それらが機能しているかどうかを判断する手段です。可視性はまた、事後に具体的な質問に証拠をもって答えることも可能にします。特定のアカウントに触れたメンバーは誰か。機密性の高い会話でClaudeは何を生成したか。その会話はどのくらいの期間保持されるか。こうした答えは、あらかじめ取得していた記録からしか得られません。
だからこそ、可視性はメンバーがアクセスできるようになる前に設定しておくべきであり、後からでは遅いのです。最初のアクセスから記録をオンにする日までの期間は、後から埋めることのできない記録の空白を残してしまいます。3つの要素がこのカバレッジを提供します。Compliance API(会話コンテンツに加え、監査ログイベント)、OpenTelemetry(各サーフェスがどのように稼働しているか)、そして保持期間(コンテンツがどのくらいの期間保持されるか)です。この記録の一部は、Compliance APIがオンになっている間にのみ取得されます。アクティビティフィードのイベントや、CoworkやClaude Codeなど、メンバーのマシン上で行われたセッションのトランスクリプトがこれに該当します。
Compliance API:会話コンテンツの記録
Compliance APIは、コンテンツを保持する記録です。Claude chatを対象とし、組織の既存のCompliance Access Keyと設定でCoworkおよびClaude Codeのセッションにも対象範囲が及ぶため、追加で統合する必要はありません。どのプランで利用できるかはヘルプセンターのCompliance APIの記事(新しいタブで開きます)で、どのアプリのセッションを記録するかはClaude Platform Docsのセッショントランスクリプトを取得する(新しいタブで開きます)で確認してください。アクティビティフィードのイベント、チャットデータ、ファイルコンテンツを保持しているため、「誰がいつログインしたか」だけでなく、「何が話されたか」「何が共有されたか」にも答えることができます。特定の法的要件や規制要件を満たすかどうかは、法務・コンプライアンス担当者の判断に委ねられます。すでに運用しているCASB、DLP、eDiscovery、SIEMツールと統合してください。これらのベンダーの多くがCompliance API上に統合機能を構築しており、Claude Compliance API統合の利用を開始する(新しいタブで開きます)に一覧があります。
Compliance APIは、他の2つの記録と混同されがちです。
- 監査ログはメタデータのみです。 誰が、いつ、何をしたか(管理者およびメンバーの操作)というイベントを記録しますが、プロンプトや応答の内容は含まれません。Compliance APIには監査ログイベントも含まれるため、1つの記録で両方をカバーしますが、この区別は依然として重要です。コンテンツを求められたときに、メタデータだけでは答えになりません。
- フルデータエクスポートは、別個のPrimary Owner向け機能です。 ケースごとに確認するのではなく、組織のデータを一括で取得するためのものです。
Compliance APIを有効化するのはPrimary Ownerです。アクセスキーは作成時にスコープが決まります。Primary Ownerのキーは親組織配下のすべての組織をカバーできる一方、Ownerのキーはそのオーナー自身の組織のみをカバーします。Primary Ownerは、親組織全体をカバーするキーだけでなく、単一の組織(親組織の子組織)に限定したキーを作成することもできます。スコープはロールによって固定されるのではなく、作成時にキーごとに選択するものです。その後に重要になる決定は、誰がそれを読むかです。誰もレビューしない記録は、実質的には統制になりません。多くの企業には、すでにセキュリティログの集約先(SIEMやセキュリティツールの中央収集ポイント)があり、それをレビューするオーナーがいます。Compliance APIをそこにルーティングすれば、Claudeはすでに存在するレビュープロセスの中のもう一つの情報源になります。
OpenTelemetry:各サーフェスがどのように稼働しているか
OpenTelemetryエクスポートは、使用パターンやパフォーマンスといった運用テレメトリを可観測性スタックに送信し、一部のサーフェスでは会話コンテンツも送信します。Claude Codeには、エンジニアリングチームが有効化した場合にプロンプトをログに記録するオプトイン機能がドキュメント化されていますが、デフォルトではそのテレメトリは運用データです。現行バージョンのClaude Desktopでは、Coworkのエクスポートはメタデータのみを保持します。プロンプトテキスト、Claudeの応答、ツール入力はデフォルトでオフになっており、otlpContentCaptureデバイスポリシーによってオンになります。一部の旧バージョンでは、ポリシーをメタデータのみに設定しない限りそのコンテンツを送信します(方法についてはCoworkのモニタリング(新しいタブで開きます)を参照)。また、メタデータには常にメンバーのメールアドレスと接続先フォルダのパスが含まれるため、組織で必要な場合はコレクターでそれらをフィルタリングしてください。OpenTelemetryは「どのように稼働しているか」を示すものとして扱い、Compliance APIの「何が話されたか」を補完するものであり、任意のものです。コンテンツについて頼るべき記録はテレメトリではなくCompliance APIです。プラットフォームチームがすでに可観測性スタックを運用している場合、これはそのチームへのルーティング作業になります。
保持期間:コンテンツがどのくらいの期間保持されるか
保持期間(Retention)とは、会話コンテンツが削除されるまで保持される期間のことです。デフォルトのままにしておくと、コンテンツはあなたまたはメンバーが削除するまで無期限に保持されます。代わりにカスタムの保持期間を設定すると、コンテンツは設定したスケジュールに従って自動的に削除され、プロジェクト内に保持されているチャットについては、チャット自体の期間ではなくプロジェクトの期間が適用されます。保持期間の起算点と、カスタム期間の対象外となるものについては、カスタムデータ保持(新しいタブで開きます)と、組織で統合Claude体験を使用している場合はその設定記事(新しいタブで開きます)を参照してください。設定可能な最短のカスタム期間は30日です。この設定にゼロ保持のオプションはありません。
Compliance API経由でアクセスするアクティビティフィードのイベントとセッショントランスクリプトは、それぞれ独自の保持モデルに従います。
- アクティビティフィード:設定した期間にかかわらず6年間。
- リモートセッショントランスクリプト(claude.aiのWebまたはモバイルで開始され、Anthropicが管理するクラウド環境で実行されるCoworkセッション、およびクラウドで実行されるCoworkのスケジュールタスクの各実行):メンバーがそれより早くセッションを削除しない限り6年間。
- CoworkおよびClaude Codeのローカルセッショントランスクリプト:有限のカスタム期間を設定している場合はその期間、設定していない場合は6年間。HIPAA対応が有効な組織では、カスタム期間がそれより長い場合でも、取得から30日間。
チャット、ファイル、プロジェクトのコンテンツは設定した期間に従うため、短い期間を設定すると、メンバーが保持できる内容とCompliance APIが返せる内容の両方が制限されます。
保持期間は組織全体に適用される設定であるため、この種のコンテンツについて自社がすでに持っているデータガバナンスポリシーと照らし合わせて選択し、そのポリシーの所有者を巻き込んで、設定する前にその数値の承認を得るようにしてください。規制対象の部門が、組織の他の部分が望むよりも短い期間を必要とする場合、全員がその短い期間を適用されることになるため、影響を受けるチームにそのトレードオフを伝え、認識してもらうようにしてください。
その話し合いに持ち込むべき提案の一つが推論フック(inference hooks)です。Claude chat、Cowork、Claude Codeからのすべてのプロンプトは、Claudeが応答する前に許可・拒否を判断するために、セキュリティチームまたはそのベンダーが運用するサーバーに送られます。これにより、Claudeに一切届くべきではないコンテンツは、事後に保持期間で管理されるのではなく、入口の時点でブロックされます。ヘルプセンターの推論フックの概要(新しいタブで開きます)に、それが何であるか、誰が有効化できるかが記載されています。
以下のインタラクティブウィジェットは、これらの各決定が、事後にデータに関する質問に答える能力にどのように影響するかを示しています。
Plutoの可視性
PlutoのPrimary Ownerは、全社展開前にCompliance APIを有効化し、Plutoがすでに実施しているセキュリティレビューにルーティングしたため、指名されたレビュー担当者が既存のプロセスの一環としてそれを確認しています。CoworkとClaude CodeのセッションはCompliance APIの対象範囲に含まれ、それらの運用テレメトリはPlatformがすでに運用している可観測性スタックにエクスポートされます。また、Payments & Trustが他の部門が選びたかったよりも短い期間を必要としたため、リスクオーナーは組織全体の保持期間をその短い数値に設定しました。レビュー担当者は、Plutoがその期間を超えて保持しなければならないものを、削除される前にPluto独自のアーカイブに取り込みます。なぜなら、保持期間によって削除されたチャット、ファイル、ローカルセッショントランスクリプトは、Compliance APIでは返せないからです。
1 · あなたの決定
どの保持期間を設定しますか。また、Compliance APIは有効化され、レビュー担当者にルーティングされていますか。
2 · 選べる選択肢
| 選択肢 | 選ぶべき場面 | 意味と影響 |
|---|---|---|
| 既存のデータポリシーに合わせる、Compliance APIオン | デフォルト。この種のコンテンツに対するデータガバナンスポリシーがあり、指名されたレビュー担当者がすでに実施しているセキュリティ/コンプライアンスレビュープロセスがある場合。 | 保持期間は、この種のコンテンツについてデータガバナンスポリシーがすでに定めている内容に設定されます。Compliance APIはオンになり、すでに実施しているレビューにルーティングされます。 |
| 規制対応の姿勢、Compliance APIの利用を想定 | 規制対象データを扱っている場合。 | Compliance APIは任意から、利用が想定されるものへと変わります。保持期間は通常、一般的なデータポリシーではなく、規制上・契約上の義務に照らして組織全体で設定されます。その判断はリスクオーナーが行います。組織全体が、規制対象グループの数値を適用されます。 |
| Compliance APIオフ、条件を文書化 | レビュープロセスが存在せず、予定もない場合。 | 当面Compliance APIをオフのままにし、それをオンにする条件を書き留めておきます。オンになるまでは、その期間に関する質問に答えるためのアクティビティフィードイベントやローカルセッショントランスクリプトが存在しないことに注意してください。 |
自社データの一部を他の部分から完全に分離する必要がある場合、それは保持期間の設定の問題ではありません。それはレッスン4で扱った組織分離の問題ですので、ここで解決しようとせず、そちらに差し戻してください。
3 · 後から変更する場合
Compliance APIとOpenTelemetryは、いつでも変更できるトグルと送信先ですが、Compliance APIがオフになっている期間は、後からオンにした場合と同じ空白を残します。保持期間はこれとは性質が異なります。設定自体は自由に変更できますが、削除されたコンテンツは戻ってきません。後から期間を短縮すると、メンバーが以前の期間の下で積み上げてきた履歴が消去されます。そのため、メンバーが後で変更したくなるような数値の下で作業を積み上げてしまう前に、一度で期間について合意しておいてください。
リソースの設定
判断が決まったら、保持期間とCompliance APIは組織設定(Organization settings)で設定し、Primary OwnerがCompliance APIを有効化します。
- Enterprise Planのカスタムデータ保持制御を設定する(新しいタブで開きます):組織全体の保持期間を設定します。
- Compliance APIにアクセスする(新しいタブで開きます):記録を有効化し、すでに実施しているレビューにルーティングします。
- 監査ログにアクセスする(新しいタブで開きます):管理者およびメンバーの操作の記録で、会話記録と合わせてCompliance API経由で取得します。
- Team PlanおよびEnterprise Planの利用状況分析を表示する(新しいタブで開きます):導入状況の読み取り(レッスン12)。
- Coworkのモニタリング(新しいタブで開きます):Coworkのエクスポートが保持する内容と、プロンプト、応答、ツール入力を含めるかどうかを決定するデバイス設定。
- モニタリング(新しいタブで開きます):Claude Code向けのOpenTelemetryエクスポートの有効化と設定。
- 推論フックの概要(新しいタブで開きます):Claudeに一切届くべきではないコンテンツに対して、応答前の許可・拒否ゲートを提案します。
- Claude Compliance API統合の利用を開始する(新しいタブで開きます):ベンダーがCompliance API上に構築したCASB、DLP、eDiscovery、SIEM統合。
レッスンの演習
これは通常エスカレーションされる2つの決定のうちの1つであるため、このコンパニオンのセクションは、レッスン2で指名した可視性オーナーに渡す概要資料を兼ねています。この決定についてはリスクリードが判断を下します。以下の4つの部分にまとめてください。
- 3つの要素(会話コンテンツ、運用テレメトリ、保持期間)、それぞれが組み込まれる自社のプロセス、そしてそのプロセスの所有者。既存のプロセスがない要素は、レビュープロセスをゼロから構築することになる要素です。展開前にフラグを立ててください。そうした要素は立ち上げに最も時間がかかるためです。
- 推奨する保持期間と、それが合致する既存のポリシー。
- Compliance APIに関する推奨事項と、それを読む担当者の名前。
- テレメトリの送信先。
可視性オーナーに持参するもの:3つの要素、保持期間に関する推奨事項、Compliance APIに関する推奨事項とそれを読む担当者、そしてテレメトリの送信先です。レッスン2で指名した可視性オーナーに渡し、その判断が返ってきたら記録してください。
→ これをワークアロング・コンパニオンのレッスン11のセクションに記録してください。
ダウンロード
次のステップ
これで、何が起きたかを証明できるようになりました。展開が機能しているかどうかは別の問いであり、別の答えを持ちます。それは、レッスン1で設定した展開目標に照らして読み解く、分析レポートが示す導入シグナルです。次のレッスンでは、それらの読み方、誤解を招きかねない点、そして目標にタイムラインを与えるペース目標の設定方法を紹介します。