監査ログからファイル名が消えた。しかも過去分も。Claude の Compliance API の変更

要約

Claude Platform は 2026-09-24、Compliance API の Activity Feed から名称フィールドを削除しました。API Release Notes の 09-24 の日付見出しに記載されています。

具体的には、Activity Feed がファイル名、プロジェクト文書名、アーティファクトのタイトルを返さなくなりました。filename と title のフィールドは空になるか、省略されます。

問題は適用範囲です。 公式は “including historical ones” と書いており、この扱いは過去のアクティビティにも遡って適用されます。 新しく記録されるログだけが変わるのではありません。すでに記録済みのアクティビティを取り直しても、名称は返ってきません。

名称が必要な場合の代替経路は用意されています。read:compliance_user_data スコープを持つ Compliance Access Key を使って、ID から名称を引き直すという手順です。情報そのものが消えたのではなく、取得経路が1段深くなり、追加のスコープが必要になったという変更です。

これは取得できる情報が減る、後退方向の API 変更です。 機能追加ではありません。プライバシー保護の強化として読むのが自然な方向ですが、公式は理由を明示していません。いずれにしても、Activity Feed の filename を前提に組んだ実装は、この日を境に動かなくなります。

同じ 09-24 の日付見出しでは、もうひとつ告知があります。Claude for Microsoft 365 のローカルセッション endpoint がベータを抜けました。 対象は Excel、PowerPoint、Word、Outlook のセッションです。こちらは前進方向の変更で、Office アプリ内での Claude 利用を監査対象に組み込む前提が整ったことになります。

なお本記事は、2026-09-25 の日次巡回で同じ日付見出しのうち拒否課金の変更のみを記録し、Compliance API の変更を取りこぼしていたぶんの追補です。Claude Platform の Release Notes は1つの日付見出しの下に複数の更新を持つため、見出し単位ではなく項目単位で拾う必要があります。

何が変わったか

• Compliance API の Activity Feed が、ファイル名・プロジェクト文書名・アーティファクトのタイトルを返さなくなった
• filename と title のフィールドは空になるか省略される
• この扱いは過去のアクティビティにも遡って適用される（“including historical ones”）
• 名称が必要な場合は、read:compliance_user_data スコープを持つ Compliance Access Key で ID から引き直す
• Claude for Microsoft 365 のローカルセッション endpoint がベータ解除（Excel / PowerPoint / Word / Outlook）

業務インパクト（一般企業向け）

最初に確認すべきは、自社の監査ログ実装が filename を読んでいるかどうかです。 読んでいれば、今日から空になります。 よくあるのは3つの使い方です。監査ログの全文検索でファイル名をキーにしているもの。分類やタグ付けで拡張子や命名規則から種別を判定しているもの。DLP 判定でファイル名のパターン（契約、人事、_confidential など）を条件に使っているもの。どれも名称が空になると成立しません。

遡及するという点が、通常の API 変更と性質を分けています。 破壊的変更であっても、普通は「その日以降のデータが変わる」だけです。過去分を取り直せば元の形で取れるのが前提で、移行の猶予はそこから生まれます。今回はそれがありません。「移行期間中は旧形式で読む」という逃げ道が無く、当日から新しい経路に切り替える以外の選択肢がない構造です。

新たに必要になるのは、キーの管理です。 read:compliance_user_data スコープを持つ Compliance Access Key を発行し、ID から名称を引く処理を追加することになります。このスコープは名称という個人特定に繋がりうる情報へのアクセスを意味します。 つまり、従来は Activity Feed を読むだけで手に入っていた情報が、より強い権限の下に移されたと読めます。キーを誰が持つか、どこに置くか、ログに残すかを決める作業が発生します。 監査の仕組みを維持するために、監査すべき対象が増えるという構図です。

eDiscovery や訴訟対応の文脈では、影響がさらに重くなります。 過去のアクティビティから名称が取れないということは、「いつ誰がどのファイルを扱ったか」を Activity Feed 単体で示せなくなるということです。ID からの引き直しが前提になるため、証拠としてのログの完全性を説明する手順が変わります。 法務と情シスの間で、どう記録を保全するかの合意を取り直す必要が出ます。

Microsoft 365 のローカルセッション endpoint のベータ解除は、こちらは導入を進める側の材料です。 Excel / PowerPoint / Word / Outlook でのセッションが正式に監査対象として扱えるようになったため、「Office アプリ内での利用はログが取れないから禁止」という制限を続ける理由が薄くなりました。 禁止を維持している組織は、根拠の見直し時期です。

副業・個人活用視点

個人の利用者として直接触る API ではありません。 Compliance API は Enterprise 相当の管理者向けです。それでも、この変更から取れるものが2つあります。

1つ目は、案件としての価値です。 遡及する破壊的変更は、顧客側で確実に作業が発生します。 監査ログのパイプラインを組んだ会社は、今週それが壊れていることに気づきます。**「Claude の Compliance API の変更で監査ログのファイル名が取れなくなった、ID 引き直しの処理を追加したい」**という相談は、規模の小さな確実な仕事です。こういう変更を把握していること自体が、声をかけられる理由になります。リリースノートを読む習慣が案件に変わる典型例です。

2つ目は、設計の教訓としてです。 外部 API のレスポンス項目を、そのまま検索キーや判定条件に使うと、項目が消えた瞬間に機能が落ちます。 今回は名称でしたが、同じ構造はどの API でも起こります。ID を主キーにして、表示名は必要なときに引くという設計にしておけば、今回の変更の影響は「引く先が変わる」だけで済みました。自分の案件で外部 API を扱うとき、どの項目に依存しているかを把握しておくことが、そのまま保守コストの差になります。

リリースノートの読み方そのものも、実務スキルです。 今回の変更は、Opus 5.5 の発表や拒否課金の変更と同じ日付見出しの下に埋まっていました。 派手な発表の隣に、静かに後退方向の変更が置かれる。日付単位で「確認済み」にすると取りこぼすという点は、自分の運用にもそのまま当てはまります。