認証
APIキー、Workload Identity Federation、またはApp Attestを使用してClaude APIに認証します。
Claude APIは、リクエストを認証する3つの方法をサポートしています。
| 方法 | 認証情報 | 最適な用途 |
|---|---|---|
| APIキー | Authorizationヘッダーにベアラートークンとして送信される静的なsk-ant-api...シークレット | ローカル開発、プロトタイピング、スクリプト、およびシークレットストレージを自分で管理するサーバー |
| Workload Identity Federation | IDプロバイダーのIDトークンから交換される短命のベアラートークン | クラウドプラットフォーム(AWS、Google Cloud、Azure)、CI/CDパイプライン、およびKubernetes上の本番ワークロードで、静的シークレットを排除したい場合 |
| App Attest | 登録済みのiOSまたはmacOSアプリの正規かつ認証済みのインストールに発行される短命のアクセストークン | バックエンドやプロキシなしでアプリが直接Claude APIを呼び出す、エンドユーザーに配布されるiOSおよびmacOSアプリ |
APIキーとWorkload Identity Federationは、Claude APIエンドポイントへの同じアクセスを付与します。すぐに始めるにはAPIキーを選択してください。自分の開発用には個人キーを、共有するものにはサービスアカウントキーを使用します。ワークロードがすでにフェデレーションできるプラットフォーム発行のIDを持っている場合は、Workload Identity Federationに移行してください。エンドユーザーに配布するiOSおよびmacOSアプリにはApp Attestを使用してください。
APIキー
APIキーは、Claude Consoleで生成し、すべてのリクエストでAuthorizationヘッダーにベアラートークンとして送信する静的なシークレットです。
キーの種類
キーを作成する際、その種類を選択します。これにより、キーができること、動作する場所、および動作しなくなるタイミングが決まります。
| キーの種類 | 動作する主体 | 動作する場所 | 動作しなくなるタイミング |
|---|---|---|---|
| 個人キー | あなた(ユーザー)自身。あなたのロールと権限で動作します | 単一のワークスペース、またはあなたのロールでAPI使用が許可されているワークスペース。キーの作成時に選択します | あなたが組織へのアクセス権を失ったとき。単一ワークスペースのキーは、そのワークスペースへのアクセス権を失った場合や、そのワークスペースがアーカイブされた場合にも機能しなくなります。組織から削除されると、個人キーはアーカイブされます。再招待された場合は新しいキーを作成してください。アーカイブされたキーは復元されません |
| サービスアカウントキー | サービスアカウント | 単一のワークスペース、またはサービスアカウントがアクセスできるすべての場所。キーの作成時に選択します。サービスアカウントは、Default Workspaceと、追加されたワークスペースにアクセスできます | サービスアカウントがアーカイブされたとき。単一ワークスペースのキーは、サービスアカウントがそのワークスペースから削除された場合や、そのワークスペースがアーカイブされた場合にも機能しなくなります |
| ワークスペースキー(レガシー) | 誰でもない:作成されたワークスペースに属します | そのワークスペース | 有効期限が切れたとき、無効化または削除されたとき、またはそのワークスペースがアーカイブされたとき。作成者が組織を離れるかどうかに関係なく |
個人キーとサービスアカウントキーはIDに裏付けられています。それぞれが組織ですでに管理しているユーザーまたはサービスアカウントに属し、すべてのリクエストはそのIDとして動作します。そのIDが組織から削除されると、キーは機能しなくなります。これにより、キーを所有する人やワークロードよりもキーが誤って長く存続することがなくなります。新しい統合では、ワークスペースキーよりもこれらを優先してください。
自分の開発やスクリプトには個人キーを使用してください。共有された個人キーは1人の人物として動作し、その人が離れると機能しなくなります。共有または自動化されたワークロード(CI、本番サービス)の場合は、組織管理者にサービスアカウントを作成してもらい、ワークロードが独自のIDを持つようにしてください。
ワークスペースAPIキーは引き続き機能しますが、レガシーと見なすべきです。ID連携型キーまたはWorkload Identity Federationが推奨されます。移行するには、ワークスペースAPIキーの置き換えを参照してください。
キーの作成と使用
- キーを作成する: Claude ConsoleでAPIキーページ(
platform.claude.com/settings/keys)に移動し、Create keyをクリックします。キーに名前を付け、有効期限を選択します。個人キーの場合はLinked accountを自分自身に、複数のユーザーで共有するキーの場合はサービスアカウントに設定します。キーのスコープを特定のワークスペースに限定することもでき、これにより今後のリクエストでワークスペースIDを手動で設定する手間を省けます。 - キーを使用する: 直接のHTTPリクエストでは
Authorization: Bearer <key>として送信するか、ANTHROPIC_API_KEY環境変数を設定すると、クライアントSDKが自動的に読み取ります。
POST /v1/messages
Authorization: Bearer YOUR_API_KEY
anthropic-version: 2023-06-01
content-type: application/jsonレガシーのx-api-key: YOUR_API_KEYヘッダーは、Authorizationの代わりに引き続きサポートされています。
APIキーはシークレットマネージャーに保管し、定期的にローテーションし、漏洩が疑われるキーは無効化または削除してください。Claude ConsoleのAPIキーページでは、Disableは元に戻すことができます(Admin APIはキーのstatusを"inactive"として報告し、Re-enableで"active"に戻ります)。一方、Deleteは永続的です。キーはアーカイブされ、List API Keysにstatus: "archived"として引き続き表示されます。有効期限が切れたキーは削除することしかできません。また、キーの作成時に有効期限を設定して、漏洩した認証情報が使用可能な期間を制限することもできます。
client = Anthropic(api_key="my-anthropic-api-key")
# または、環境に ANTHROPIC_API_KEY を設定した場合:
client = Anthropic()ワークスペースの選択
特定のワークスペース用に作成されたAPIキーはそのワークスペースでのみ機能し、これらのキーを使用するAPIリクエストではワークスペースIDを省略できます。
APIキーのスコープがワークスペースに限定されていない場合は、各リクエストでanthropic-workspace-idヘッダーにワークスペースIDを指定する必要があります。リクエストまたはSDKでこのヘッダーを設定する方法については、次の例を参照してください。
Admin APIは、キーが特定のワークスペースにスコープされていない場合にのみ、個人キーまたはサービスアカウントキーを受け入れます。
ワークスペースのIDは、Claude Consoleのワークスペースページ(platform.claude.com/settings/workspaces)のID列で確認するか、List Workspacesエンドポイントを呼び出して確認できます。List Workspacesは、include_default=trueを渡した場合にのみDefault Workspaceを含めます。Default WorkspaceのIDは、そこで実行されるすべてのリクエストのanthropic-workspace-idレスポンスヘッダーにも含まれています。
client = Anthropic() # reads ANTHROPIC_API_KEY
# ワークスペースにスコープされていないキーでは、すべてのリクエストで必須です。
# 単一のワークスペースにスコープされたキーでは extra_headers を省略します。
message = client.messages.create(
model="claude-opus-5-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello, Claude"}],
extra_headers={"anthropic-workspace-id": "wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ"},
)
print(message.content)
# または、このクライアントからのすべてのリクエストに対して一度だけ設定します:
workspace_client = Anthropic(
default_headers={"anthropic-workspace-id": "wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ"},
)ワークスペースにスコープされていないキーで行われたリクエストがヘッダーを省略した場合、APIは400 invalid_request_errorを返します。
{
"type": "error",
"error": {
"type": "invalid_request_error",
"message": "This API key is not scoped to a workspace, so this request must include the anthropic-workspace-id header with the ID of the workspace to use. Add the header, or use an API key that is scoped to a workspace."
},
"request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}有効なワークスペースIDではないヘッダー値は、anthropic-workspace-id header must be a valid workspace ID.というメッセージとともに400 invalid_request_errorを返します。ワークスペースが存在しない場合、またはキーのユーザーやサービスアカウントがそれにアクセスできない場合、APIはWorkspace `<id>` not found.というメッセージとともに404 not_found_errorを返します。これは不明なワークスペースに対するレスポンスと同じです。
Workload Identity Federationは、代わりにトークン交換時にワークスペースを選択します。詳細については、WIFリファレンスを参照してください。
キーの有効期限
Claude ConsoleのAPIキーページからAPIキーを作成する際に、有効期限を選択します。プリセット(3時間、1日、7日、または30日)、カスタム期間、またはシークレットマネージャーに保管して自分でローテーションするキーの場合はNeverを選択できます。組織に最大有効期限ポリシーがある場合、Consoleはプリセットとカスタム期間をポリシーの最大値に制限し、Neverは使用できなくなります。既存のキーは現在の動作を維持します。有効期限は作成時に設定され、後から変更することはできません。Claude ConsoleでAdmin APIキーを作成する場合にも、同じ有効期限の選択が適用されます。
Anthropicは、有効期限が近づくとキーの作成者にメールを送信します。有効期間が14日以上のキーの場合は有効期限の7日前、有効期間が7日以上のキーの場合は1日前に送信されます。有効期間がより短いキーは、警告メールなしで有効期限が切れます。
キーの有効期限が切れた後、そのキーで行われたリクエストは401 authentication_errorを返します。アクセスを復元するには新しいキーを作成してください。有効期限切れのキーは再有効化できません。
ConsoleのAPIキーテーブルには各キーの有効期限が表示され、Admin APIはList API KeysおよびRetrieve API Keyエンドポイントで各キーのexpires_atタイムスタンプを報告するため、期限切れになる前にキーを監査してローテーションできます。有効期限のないキーの場合、このフィールドはnullです。
有効期限は漏洩した認証情報の有効期間を制限しますが、シークレット管理の代替にはなりません。有効期限に関係なく、キーはシークレットマネージャーに保存し、漏洩が疑われるキーは無効化または削除してください。
ワークスペースAPIキーの置き換え
ワークスペースキーをお持ちの場合は、Workload Identity Federationまたは個人キーやサービスアカウントキーに置き換えることをお勧めします。これにより、セキュリティと可観測性が向上します。
長期間有効なキーよりも推奨されるWorkload Identity Federationの設定の詳細については、WIFリファレンスを参照してください。
ワークスペースキーを個人キーまたはサービスアカウントキーに置き換えるには:
- キーの種類を決定します。 自分のツールには個人キーを使用する必要があります。共有または無人のワークロードにはサービスアカウントキーを使用する必要があります。
- 必要に応じてサービスアカウントを作成します。 組織の管理者に依頼して、Claude ConsoleのService accountsページ(
platform.claude.com/settings/service-accounts)でサービスアカウントを作成し、関連するワークスペースに追加してもらう必要がある場合があります。 - 新しいキーを作成します。 統合が複数のワークスペースを必要としない限り、その統合のワークスペース専用に作成してください。
- 新しいキーをデプロイします。 統合が古いキーを読み取っているすべての場所(通常は
ANTHROPIC_API_KEY環境変数またはシークレットマネージャーのエントリ)で、古いキーを置き換えます。ワークスペースにスコープが限定されていないキーの場合は、ワークスペースの選択に示すようにanthropic-workspace-idヘッダーも送信してください。 - 古いキーを削除します。 リクエストが成功することを確認してから、Claude ConsoleのAPIキーページでワークスペースキーを削除します。
Workload Identity Federation
Workload Identity Federation(WIF)を使用すると、ワークロードは、すでに信頼している「identity provider」(IDプロバイダー)、すなわちIdPが発行する短期間有効なIDトークンで認証できます。このようなIdPには、AWS IAM、Google Cloud、および標準に準拠した任意のOIDC発行者(GitHub Actions、Kubernetesサービスアカウント、SPIFFE、Microsoft Entra ID、Oktaなど)が含まれます。ワークロードはIdPが発行したJWTをPOST /v1/oauth/tokenで短期間有効なClaude APIアクセストークンと交換し、SDKはそのトークンが期限切れになる前に自動的に更新します。発行、配布、ローテーションが必要なsk-ant-api...文字列はありません。
フェデレーションにより、長期間有効なClaude APIキーが環境から取り除かれるため、漏洩した認証情報が引き起こす被害を抑えられ、クラウドリソースにすでに使用しているのと同じIdPの制御でアクセスを管理できます。ただし、それだけでエンドツーエンドのセキュリティが保証されるわけではありません。信頼チェーンの強度はIDプロバイダーの構成に依存し、そのチェーンの一段前にある長期間有効なシークレット(たとえば、IdPトークンを発行できる静的なクラウド認証情報)によって損なわれる可能性があります。フェデレーションは、IP許可リスト、MFA、監査ログなどのプロバイダーの制御と組み合わせて使用してください。
フェデレーションを設定するには、Claude Consoleで3つのリソース(サービスアカウント、フェデレーション発行者、フェデレーションルール)を作成し、SDKをそのルールに向けます。完全なセットアップの手順については、Workload Identity Federationを参照してください。
App Attest
App Attestは、デバイスから直接Claude APIを呼び出すiOSおよびmacOSアプリを認証します。各インストールは、AppleのApp Attestサービスを使用して、Claude Consoleで登録したアプリの正規かつ改変されていないビルドであることを証明します。その後、Anthropicはデバイスに短期間有効なアクセストークンを発行し、使用量はあなたのワークスペースに課金されます。トークンのスコープはワークスペースに限定され、1時間後に期限切れとなり、Messages APIの呼び出しのみを許可します。
アプリを登録してクライアントIDを取得するには、iOSおよびmacOSアプリ向けApp Attestを参照してください。
次のステップ
発行者、ルール、サービスアカウントを設定し、トークンを交換します
AWS、Google Cloud、Azure、GitHub Actions、Kubernetes、SPIFFE、Oktaのステップバイステップガイド
環境変数、検証ルール、プロファイル設定、エラーリファレンス
APIキーを配布せずに、アプリの正規のインストールがClaude APIを呼び出せるようにします
Python、TypeScript、C#、Go、Java、PHP、Ruby、およびCLI
Was this page helpful?