セッション記録を取るAPIが正式版になった。監査ログの設計が要る

2026年8月26日、Compliance API のセッション記録取得エンドポイントが正式版になった。Cowork と Claude Code のセッション記録（ローカル実行分）が対象である。

あわせて対象が広がった。Claude Science のセッションと、Excel・PowerPoint・Word・Outlook 上で動く Claude for Microsoft 365（office_agents）のセッション記録が加わっている（Enterprise 向けベータ）。

既にある3つの経路との関係

Claude の利用ログを外に出す手段は、これで3系統になった。一次ソースはこの使い分けを明記している。

	性質
Compliance API	セッション記録をプログラムから取得する。今回正式版になったのはここ
CSV エクスポート	手動での書き出し
OpenTelemetry ロギング	メトリクスとトレースを既存の監視基盤へ流す

同じ「ログ」でも粒度と用途が違う。混ぜて設計すると、どれも中途半端になる。

で、SEの実務ではどう使うか

取れるようになったということは、取らない理由を説明する番が回ってきたということである。

生成AIの社内導入で情シスが必ず聞かれるのは「誰が何を投げたか分かるのか」である。これまでは「APIがベータなので」で止められた。正式版になると、その答えは使えない。

決めることは3つある。

どこに流すか。 既存の SIEM に入れるのか、別に持つのか。Compliance API はプログラムから取得する形なので、取得して置くところまでは自分で作る必要がある。 ログ基盤があるなら OpenTelemetry のほうが素直な場合もある。一次ソースが使い分けを書いているのは、そこが分岐だからである。

どれだけ保つか。 セッション記録には、社員が業務で書いた内容がそのまま入る。保持期間を決めずに溜め始めると、後から消す判断のほうが難しくなる。先に期間を決めておくほうが安い。

誰が見られるか。 監査目的で取ったログを、上長が日常的に閲覧できる状態にすると、性質が変わる。監査ログと勤務管理は別物として設計しないと、導入そのものへの抵抗を生む。

稟議に書くなら「取得手段は正式版として提供されている。保持期間と閲覧権限をこう設計する」の形になる。 「まだ取れません」は今月から使えない。

対象が Microsoft 365 上の Claude まで広がっている点も見落とせない。Excel や Outlook で使われた分も記録の対象になるので、想定する範囲が事前の見積もりより広がる可能性がある。