Claude Media
Claude Compliance Settings APIでCompliance APIを切り替える
Claudeチュートリアル

Claude Compliance Settings APIでCompliance APIを切り替える

Compliance APIのオン・オフは、画面のトグルのほかにCompliance Settings APIでも切り替えられます。GETとPOSTの使い方と、disabledが元に戻る条件を扱います。

読了目安 約13分

Compliance Settings APIは何を切り替えるのか

Compliance Settings APIは、組織のCompliance APIが有効かどうかを読み書きするエンドポイントです。URLは/v1/organizations/compliance_settingsの1本で、GETが現在の状態の取得、POSTが状態の更新を担います。

扱う値はstateひとつです。enabledにするとCompliance APIが有効になり、組織のアクティビティイベントの記録が始まります。disabledにすると、APIと記録の両方が止まります。画面のトグルと同じ効果を、スクリプトや運用基盤から呼べるわけです。

このリソースは組織ごとにちょうど1つだけある単一リソースで、IDは指定しません。リソースのtypeは常にcompliance_settingsが返ります。

仕様

このAPIで決まること

  • 読む

    GETで現在のstateを返します。親組織を持つ組織は、親の設定から継承された状態を読みます。

  • 書く

    POSTでenabledかdisabledを指定します。同じ値の再送は成功し、何も変わりません。

  • 止まるもの

    disabledの間は、Compliance APIの利用とアクティビティの記録が両方止まります。

キーの作り方とスコープの選び方はClaude Compliance APIキーの作成手順にあります。APIそのものの位置づけはClaude Compliance APIとはで扱っています。

現在の状態を取得する

まずGETで状態を確かめます。ヘッダーに必要なのはanthropic-versionとAPIキーで、リクエストボディはありません。

curl https://api.anthropic.com/v1/organizations/compliance_settings \
    -H 'anthropic-version: 2023-06-01' \
    -H "X-Api-Key: $ANTHROPIC_API_KEY"

レスポンスのstateはオブジェクトで、typeにenabledかdisabledが入ります。例えば次のような形です(公式の例に沿った形)。

{
  "state": {
    "type": "enabled"
  },
  "type": "compliance_settings"
}

ここで見落としやすいのは、親組織を持つ組織の読み方です。親組織を持つ組織は、親の設定から継承された状態を読みます。Claude Enterpriseのように親組織の配下へ複数のリンク組織がぶら下がる構成では、リンク組織側の値は親の設定を映したものです。リンク組織でdisabledが返ったら、原因は自組織でなく親側の設定にあります。

公式ページの例は$ANTHROPIC_API_KEYを使っていますが、このエンドポイントにどの種類のキーとどのスコープが必要かは、取得・更新どちらのページにも記載がありません。キー側の条件は、手元のキーで呼んで返るステータスを見て切り分けます。

stateをenabledかdisabledに更新する

更新はPOSTで、ボディにstateを渡します。

curl https://api.anthropic.com/v1/organizations/compliance_settings \
    -H 'Content-Type: application/json' \
    -H 'anthropic-version: 2023-06-01' \
    -H "X-Api-Key: $ANTHROPIC_API_KEY" \
    -d '{"state": {"type": "enabled"}}'

stateは文字列の省略形でも渡せます。ボディを{"state": "enabled"}と書いても同じ意味で、レスポンスは常にオブジェクト形式で返ります。シェルスクリプトに埋め込むなら、省略形のほうが読みやすくなります。

curl https://api.anthropic.com/v1/organizations/compliance_settings \
    -H 'Content-Type: application/json' \
    -H 'anthropic-version: 2023-06-01' \
    -H "X-Api-Key: $ANTHROPIC_API_KEY" \
    -d '{"state": "disabled"}'

現在値と同じ値を送っても、リクエストは成功してリソースは変わりません。有効化済みの組織にenabledを再送してもエラーにならないので、構成管理ツールから毎回「望む状態」を送る使い方に向いています。

disabledにしても元に戻るのはどんなときか

このAPIで最も注意が要るのは、disabledが永続とは限らない点です。disabledの要求は、次のどちらかが起きるまで有効なままです。

  1. 後からenabledの要求が来る
  2. 組織で、Access Transparencyを有効にするプロビジョニング操作が次に実行される

2つ目が罠になります。Access Transparencyを有効にすると、そのイベントを配信するCompliance APIも有効になる仕様だからです。プロビジョニングは再実行も含めて、disabledにした後でもCompliance APIを再び有効にします。

一方で、自動のプロビジョニングがコンプライアンス設定をdisabledにすることはありません。有効側にだけ倒れる非対称な作りです。

切り分け

disabledにしたはずが enabled に戻っているとき

  1. QAccess Transparencyに加入している組織か?
    答えが加入していない

    別の管理者がenabledを送った可能性があります。GETで現在値を確かめ、変更履歴を管理者に確認します。

    答えがはい
  2. Q加入後にプロビジョニングの再実行があったか?
    答えが再実行はない

    Access Transparency側の操作が見当たらなければ、親組織の設定が継承されている可能性を疑います。

    答えがはい

再プロビジョニングによる再有効化

disabledは次のプロビジョニングで上書きされます。止めたままにしたい場合は、Access Transparencyの有効化を担当するチームと運用を揃えます。

画面のトグルとの違いも押さえておきます。画面側のトグルはスタンドアロンのClaude Console組織ならConsoleの設定画面、Claude Enterpriseなら親組織のPrimary Ownerがclaude.aiの組織設定で操作します。APIで切り替える手順を組み込む場合も、どの組織のどのロールが実行するのかを決めておく必要があります。

disabledにすると何が止まるのか

disabledにすると、記録とAPI利用の両方が止まります。止まる範囲は、Compliance APIの有効化手順に書かれた警告のとおりです。

  • 組織のアクティビティイベントが記録されず、Activity Feedに新しいイベントが入らない
  • Access Transparencyに加入している組織では、そのイベントの配信も止まる
  • 記録されなかった分のアクティビティは、後から復元できない
  • Claude Enterpriseでは、ローカルセッション(ユーザーのマシン上のセッション)のトランスクリプトの取得も止まり、オフの間のセッションは取得できない

enabledに戻すと、その時点から記録が再開します。記録済みのアクティビティは消えませんが、止まっていた期間は空白のままです。

オフの間のAPI呼び出しは、キーが有効でも400で返ります。メッセージはCompliance API is not enabled for this organizationで、管理者がAPIをオフにしたときにも同じ応答に戻ります。SIEM連携が突然400を返し始めたら、キーを疑う前にこのエンドポイントでstateを見ると早く切り分けられます。

落とし穴

Activity Feedで無効化に気づくことはできない

disabledの間はイベント自体が記録されません。「Activity Feedを監視していれば誰かがオフにしたと分かる」という設計は成り立たず、状態の確認はGETの定期実行など、フィードの外で行う必要があります。

組織の形態ごとに、状態を決める場所が違う

GETが返すstateの意味は組織の形態で変わります。画面での有効化の手順を形態別に並べると、次のようになります。

組織の形態画面で有効化する人と場所GETで読む値
Claude Enterprise(親組織)画面で有効化する人と場所Primary Ownerがclaude.aiの「Organization settings > API」で有効化GETで読む値親組織自身の設定
親組織にリンクされたClaude Console組織画面で有効化する人と場所自組織側でオンにする操作はなく、親組織のPrimary Ownerに依頼GETで読む値親の設定から継承された状態
単体のClaude Console組織画面で有効化する人と場所管理者ロールのメンバーが「Settings > Security」のトグルをオンGETで読む値自組織の設定

親組織で有効化すると、claude.aiとClaude Consoleの両方のリンク組織に反映されます。つまりAPIで親組織のstateをdisabledにした場合も、配下のリンク組織すべてで記録が止まる構図になります。ただし、リンク組織側のキーからPOSTしたときに何が起きるかは、更新ページに記載がありません。リンク組織の値を変えたいときは、親組織側の設定を操作するものと考えて計画します。

単体のClaude Console組織でトグルが見当たらないときは、管理者ロールがない、親組織にリンクされている、セルフサービスの対象外のいずれかです。画面側の条件は、公式のセットアップ手順に沿って確かめます。

状態を点検する運用のかたち

公式ページに書かれているのは仕様までで、運用の組み方は載っていません。ここからは、仕様の挙動を前提にした一例です。

disabledが空白期間を生み、復元もできない以上、「今オンか」を定期的に確かめる価値は高くなります。GETの結果がenabled以外だったときにアラートを上げるだけの小さなチェックで足ります。

state=$(curl -s https://api.anthropic.com/v1/organizations/compliance_settings \
  -H 'anthropic-version: 2023-06-01' \
  -H "X-Api-Key: $ANTHROPIC_API_KEY" \
  | jq -r '.state.type')
 
if [ "$state" != "enabled" ]; then
  echo "Compliance API is $state" >&2
  exit 1
fi

このスクリプトは、ジョブスケジューラーの失敗通知にそのまま乗せられます。終了コードが1なら、disabledか、応答が取れなかったことを意味します。

POSTを自動化に組み込むなら、enabledだけを送る形に絞るのが安全です。再送が無害な仕様なので、「常にenabledを宣言する」構成管理にしても副作用がありません。disabledを送る処理は、人の承認を挟む手順に分けておくと、空白期間を意図せず作る事故を避けられます。

Access Transparencyを使う組織では、もう一点あります。加入の流れは、Anthropicのアカウント担当への依頼、適格性の確認、組織単位での有効化の順です。加入すると新しいエンドポイントも認証情報も要らず、既存のActivity Feedにanthropic_accessが現れます。Access Transparencyの記録は2営業日以内に配信され、リアルタイムの通知手段としては使えません。加入の中身はClaude Access Transparencyとは何かで扱っています。

まとめ

Compliance Settings APIは、stateひとつだけの小さなAPIです。読むのがGET、書くのがPOSTで、同じ値の再送が無害なので宣言的な構成管理に向きます。

覚えておく点は2つです。disabledはAccess Transparencyの再プロビジョニングでenabledに戻ること。そしてdisabledの間の活動は、記録も復元もされないことです。キー側の条件は公式ページに載っていないため、手元のキーでGETを試し、403や404が返るならエラーの違いをCompliance APIのエラー400/403/404の違いで引くのが近道です。

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

関連する記事

Claude をもっと見る →