Claude Media
Compliance APIでClaude Code Artifactsを一覧・取得・削除する手順

Compliance APIでClaude Code Artifactsを一覧・取得・削除する手順

Compliance APIでClaude Code Artifactsを棚卸しする手順です。next_pageで一覧を最後まで取り、バージョンを保存し、不要なものを削除するまでのコマンドと取りこぼしの条件をまとめます。

Compliance APIには、Claude Code Artifactsを扱う専用のエンドポイントが4本あります。一覧(GET /v1/compliance/apps/code/artifacts)、特定バージョンの取得、最新内容のダウンロード、削除です。親組織のキー1本で、配下の組織が公開したArtifactsをまとめて棚卸しできます。

この記事では、一覧を最後まで取り切る方法、バージョンを保存する方法、削除する前に何を確かめるかを、リファレンスの仕様に沿って説明します。管理画面での公開範囲や保持期間の設定はClaude Code Artifactsの組織管理にあります。

4つのエンドポイントの使い分け

パスはすべて https://api.anthropic.com/v1/compliance/apps/code/artifacts 配下です。

やりたいことメソッドとパス返るもの
組織のArtifactsを棚卸しするメソッドとパスGET /v1/compliance/apps/code/artifacts返るものメタデータとバージョン一覧(JSON)
特定バージョンの中身を保存するメソッドとパスGET .../{artifact_id}/versions/{version_id}返るものそのバージョンの内容(ストリーム)
最新の中身を保存するメソッドとパスGET .../{artifact_id}/content返るもの最新バージョンの内容(ストリーム)
消すメソッドとパスDELETE .../{artifact_id}返るものtype と id を持つJSON

一覧だけがJSONで、残りはファイルの中身がそのままレスポンスボディに流れてきます。保存するときは curl -o でファイルに落とします。

認証は他のCompliance APIと同じで、x-api-key にCompliance Access Keyを渡します。キーの作り方とスコープの考え方はCompliance APIのセットアップとアクセスキー作成にまとめています。リファレンスのcurl例は Authorization: Bearer で書かれていますが、エラー仕様のページと各エンドポイントのヘッダー定義は x-api-key を前提にしているので、この記事の例も x-api-key で統一します。

一覧を取る: 絞り込みとレスポンスの読み方

一覧の絞り込みは4種類です。

パラメータ内容上限
limit内容1ページの件数。既定20上限100
organization_ids内容組織ID(org_... または組織UUID)で絞る上限500個
user_ids内容所有者のユーザーIDで絞る上限200個
updated_at内容gt / gte / lt / lte で更新時刻を絞る(RFC 3339)上限—

組織IDは GET /v1/compliance/organizations、ユーザーIDは組織のユーザー一覧で調べます。取得方法はCompliance APIで組織のユーザーとグループを取得する手順で扱っています。

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/apps/code/artifacts" \
  --data-urlencode "limit=100" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

レスポンスの data の各要素は、リファレンスのサンプルに沿うと次のような形です。

{
  "id": "cart_01Tu9VwXyZaBcDeFgHiJkLmN",
  "artifact_type": "code",
  "organization_uuid": "a1b2c3d4-e5f6-4789-a012-3456789abcde",
  "owner_user_id": "user_01WCz1FkmYMm4gnmykNKUu3Q",
  "published_version_id": "1741803761-9f3a",
  "read_mode": "org",
  "updated_at": "2025-03-14T09:05:17.456789Z",
  "user": { "id": "user_01WCz1FkmYMm4gnmykNKUu3Q", "email_address": "jane.doe@example.com" },
  "versions": [
    { "id": "1741803761-9f3a", "created_at": "2025-03-12T18:22:41.123456Z", "name": "Team dashboard" }
  ]
}

棚卸しで見るべき項目は次のとおりです。

  • read_mode: owner / users / org / public の4値。public は誰でも閲覧できる状態なので、外部公開の点検はここで絞ります
  • artifact_type: code のほか、claude_docs / claude_slides / claude_design / claude_design_systems / claude_motion / other が返ります
  • owner_user_id と user: エージェントのセッションが公開したArtifactでは null です。オーナーのアカウント削除後は user が null になっても、owner_user_id は残ります
  • versions: 直近およそ20件のメタデータだけです。それより古いバージョンは保持されません
  • updated_at: このフィールドが記録される前に公開されたArtifactでは null です

見落としやすいのは artifact_type です。エンドポイント名は code/artifacts ですが、スキーマにはClaude DocsやSlidesなど他の種類の値も載っています。Claude Codeから公開されたものだけが欲しいときは、artifact_type == "code" でクライアント側で絞ってください。

next_pageを最後まで追う

has_more が true でも、次のページが空のことがあります。リファレンスは「next_page が無くなるまで続ける」ことを求めています。1ページ目の件数が limit より少なくても、終わりとは限りません。

並び順は作成時刻ではなくArtifactの識別子順です。このため、一覧を取っている最中に新しく公開されたArtifactが、すでに通り過ぎた位置に入り込み、取りこぼされることがあります。リファレンスは、時点で完全なエクスポートが必要なら、公開が落ち着いてからもう一度列挙し直すよう書いています。

next_page は不透明なトークンです。中身を解釈せず、そのまま page に渡します。

base="https://api.anthropic.com/v1/compliance/apps/code/artifacts"
page=""
: > artifacts.ndjson
 
while :; do
  resp=$(curl --fail-with-body -sS -G "$base" \
    --data-urlencode "limit=100" \
    ${page:+--data-urlencode "page=$page"} \
    --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
    --header "anthropic-version: 2023-06-01") || exit 1
  echo "$resp" | jq -c '.data[]' >> artifacts.ndjson
  page=$(echo "$resp" | jq -r '.next_page // empty')
  [ -z "$page" ] && break
done
 
wc -l artifacts.ndjson

終了条件を has_more ではなく next_page の有無にしているのが要点です。|| exit 1 を付けておくと、途中の401や429で黙って打ち切られ、不完全な一覧を完全なものと誤認する事態を避けられます。

時刻フィルタは完全性を保証しない

updated_at のフィルタは、結果整合性のあるインデックスに対して効きます。リファレンスは、コンプライアンス用途で漏れなく列挙したいなら時刻フィルタを付けないよう求めています。公開直後のものがインデックスに反映される前だと、窓の境目で漏れるためです。

日次の増分エクスポートで時刻フィルタを使うなら、前回の終端より十分に手前から取り直し、id で重複を除きます。窓を隙間なく並べるやり方は、インデックスの遅れで取りこぼします。

目的別の呼び方

同じ一覧でも、聞きたいことによって絞り込みの組み合わせが変わります。

  • 特定の退職者のArtifactsを洗い出す: user_ids にそのユーザーIDを渡します。アカウントが削除済みの場合、user は null になりますが owner_user_id は残るので、IDで突き合わせられます
  • 特定の子組織だけを見る: organization_ids を渡します。削除済みの子組織が所有していたArtifactsは、一覧に返りません
  • 外部公開の有無を調べる: 絞り込みパラメータに read_mode はないため、全件を取ってから read_mode == "public" で抽出します
  • 利用者に見えている版を知る: published_version_id を見ます。オーナーが固定した版があればその版、なければオーナーの最新版です。read_mode が owner のときは非オーナーに何も表示されませんが、フィールドには「広げた場合に出る版」が入ります

オーナーが版を固定している場合、published_version_id が最新の版を指すとは限りません。外から見える内容を控えたいときは、この版を指定して取得します。

中身を保存する: バージョン指定と最新版

一覧で見つけたArtifactの中身は、2通りの取り方があります。

  • 特定のバージョンを取る: 一覧の versions[].id を使い、/versions/{version_id} を呼びます
  • 最新を取る: /content を呼びます。最新バージョンを、バージョン指定の取得と同じ形で返します
artifact_id="cart_01Tu9VwXyZaBcDeFgHiJkLmN"
version_id="1741803761-9f3a"
 
curl --fail-with-body -sS -o version.out \
  "https://api.anthropic.com/v1/compliance/apps/code/artifacts/$artifact_id/versions/$version_id" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

バージョンに複数のファイルがあると、そのままでは422で断られます。multi_file_format=zip を付けると、ファイル群とインデックス files.json を入れたZIPで返ります。ファイルが1つだけのバージョンは、このパラメータを付けても単体のファイルのまま返ります。

curl --fail-with-body -sS -o artifact.zip \
  "https://api.anthropic.com/v1/compliance/apps/code/artifacts/$artifact_id/content?multi_file_format=zip" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

files.json の omitted_files には、Artifactが型(同じ種類のArtifactをすべて表示するアプリ)からコピーしたファイルのうち、型を別の組織が所有しているために含められなかったものが並びます。ZIPの中身が見た目より少ないときは、まずここを見ます。

失敗したときの扱い

ステータスごとに、再試行してよいかが分かれます。

応答意味対処
404(バージョン取得)意味Artifactが無い、別の親組織のもの、または後続の公開でバージョンが保持履歴から押し出された対処一覧を取り直して新しい versions[].id を使う
404(最新取得)意味Artifactが無い、またはキーで読めない対処IDと対象組織を確かめる
503意味内容のアップロードが進行中、または中断された。最新取得では内容を今は作れない対処Retry-After があればその秒数待つ。無ければバックオフで再試行
422 multi_file_unavailable意味複数ファイルのバージョンを multi_file_format=zip なしで要求した対処zipを付ける。再試行では直らない
422 file_set_unavailable意味複数ファイルの中に、APIが書き出せない名前のファイルがある対処再試行しない
400 cmek_key_disabled(最新取得)意味顧客管理の暗号化キーが無効化・失効などで使えない対処キーの状態を管理者に確認する

大きな内容がエンコードされて返る場合、途中でストリームが切れることがあります。リファレンスによれば、ヘッダーと先頭のバイトは届いたのにボディが早く終わる、チャンク転送の中断だけが切り詰めの合図です。Content-MD5 は、変換されずに保存されている内容にだけ付きます。付いているときは、保存したファイルのハッシュと突き合わせます。

Claude Docsは別の取り方になる

artifact_type が claude_docs のものは、一覧の versions が空です。Docのバージョンが持つのは、文書を表示するWebページだけで、本文テキストではないためです。本文は /content?multi_file_format=zip で、テキストタブごとのWordファイルを入れたZIPとして取ります。タブが無い、またはゴミ箱にあるDocは422 document_unavailable、書き出しが16 MiBを超えると document_too_large です。

削除する: 取り消せない操作の前に控えを残す

DELETE /v1/compliance/apps/code/artifacts/{artifact_id} は、Artifactとそのすべてのバージョンを完全に削除します。取り消せません。200が返った時点は「削除が開始され、Artifactが確保された」状態で、内容の消去は非同期に進みます。

レスポンスは次の形です。

{ "id": "cart_xyz789", "type": "code_artifact_deleted" }

存在しないArtifact、別の親組織のArtifact、削除済みのArtifactへの再実行は、いずれも404です。スクリプトを途中から流し直すときは、404を「すでに消えている」として扱えば冪等に動きます。

実行前に、一覧から削除候補を書き出して目で確かめ、控えを保存する流れにしておくと安全です。

# 1. 外部公開されているcode型Artifactの候補を抜き出す
jq -r 'select(.artifact_type=="code" and .read_mode=="public")
  | [.id, .user.email_address, .updated_at] | @tsv' \
  artifacts.ndjson > candidates.tsv
 
# 2. candidates.tsv を目で確認し、消すIDだけを残す
 
# 3. 控えを保存してから削除する
while read -r id _; do
  curl --fail-with-body -sS -o "backup-$id.out" \
    "https://api.anthropic.com/v1/compliance/apps/code/artifacts/$id/content?multi_file_format=zip" \
    --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
    --header "anthropic-version: 2023-06-01" || continue
  curl --fail-with-body -sS -X DELETE \
    "https://api.anthropic.com/v1/compliance/apps/code/artifacts/$id" \
    --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
    --header "anthropic-version: 2023-06-01"
  sleep 0.5
done < candidates.tsv

控えの取得に失敗したIDは continue で飛ばし、削除に進みません。リファレンスのサンプルをもとにした形で、実際に流す前に少数のテスト用Artifactで動作を確かめてください。

権限・レート制限・つまずき

削除に必要なスコープは、チャットやファイルの削除と同じ系統とみなせます。エラー仕様のページでは、削除系のエンドポイントは Needed: として delete:compliance_user_data を示し、読み取りキーとは別に作る必要があると説明しています。ただしArtifactsの4ページ自体にはスコープ名が載っていません。実際に必要なスコープは、403の Got: と Needed のメッセージで確かめるのが確実です。スコープは作成後に変えられないため、足りなければ新しいキーを作ります。403の読み方はCompliance APIのエラーハンドリング完全ガイドにあります。

レート制限は、親組織あたり毎分600リクエストで、全キー・全 /v1/compliance/* エンドポイントの合算です。ダウンロードと削除をバッチで回すと、他の連携(SIEMへの転送など)の枠も使います。429が返ったら retry-after の秒数を待ちます。

最後に、取りこぼしを防ぐ点検項目を並べます。

  • 一覧のループは next_page が無くなるまで回しているか
  • 完全性が要るエクスポートで、時刻フィルタを外しているか
  • 増分取得では、窓に重なりを持たせて id で重複を除いているか
  • artifact_type で code に絞ってから、削除候補を作っているか
  • 削除の前に、中身の控えを保存しているか

チャットやファイルの削除はCompliance APIでチャットを削除する手順が扱っています。Code Artifactsのエンドポイントは、そのチャット側とは別系統のパスなので、同じループを流用するときはパスを取り違えないようにします。

まとめ

Code Artifactsの棚卸しは、next_page を最後まで追う一覧と、artifact_type と read_mode での絞り込みが出発点です。取りこぼしを嫌うなら時刻フィルタは外し、削除は控えを取ってから実行します。

この記事を共有:XはてブLinkedIn