ガイド

著者 Matt Connor 2026-08-20 ・更新日 2026-08-21

Claude APIの認証方法4選、キーとBedrock・Vertex・Foundry

Q: Bedrock または Vertex で Claude を使用する場合、Anthropic API key は必要ですか？

いいえ。Amazon Bedrock では、SDK が AWS credentials を使用して SigV4 で各リクエストに署名します。Google Cloud では、Application Default Credentials を通じて取得した Google access token を送信します。どちらの構成にも Anthropic が発行した secret は存在しません。利用料金は Anthropic ではなく、各 cloud account に請求されます。これが、これらのホストの ANTHROPIC_API_KEY に Anthropic key を残すことが危険な理由でもあります。cloud endpoint を指定した汎用 client は、その key をそこへ送信してしまいます。

Q: Azure で Claude は利用できますか？

はい。旧称 Azure AI Foundry の Microsoft Foundry を通じて利用できます。Foundry resource を作成し、Claude model をそこへ deploy して、https://{resource}.services.ai.azure.com/anthropic/v1/messages を呼び出します。認証には、api-key header の Azure-issued key または Microsoft Entra bearer token を使用します。利用料金は Claude Consumption Units として Azure Marketplace 経由で請求されます。request body の model field には deployment name を指定する必要があります。deployment の名前を変更するまでは、deployment name と model identifier は同じです。

Q: Linux server では Claude API key をどこに保存すべきですか？

root が所有し、mode 600 を設定した file に保存し、systemd unit の EnvironmentFile= から読み込ませます。systemd は unit の User= に切り替える前に root としてその file を読み込むため、service account がその file にアクセスする必要はありません。repository、unit file 自体、container image layer には保存しないでください。unit file は誰でも読み取れ、systemctl cat によって表示されます。また、docker history --no-trunc は ENV または --build-arg で設定された内容をそのまま表示するため、container image layer にも残さないでください。

Q: 何も変更していないのに、Claude API request が 401 を返すようになったのはなぜですか？

最も一般的な原因は、作成時に指定した有効期限に key が達したことです。有効期限は作成時に設定され、後から変更できません。短期間の key は、警告メールなしで期限切れになります。期限切れの key は再有効化できないため、replacement を作成し、environment file に書き込み、service を再起動してから古い key を revoke します。key が確実に有効な場合は、古い credential が優先されていないか確認してください。ANTHROPIC_API_KEY が空の文字列に設定されていても、他のすべての credential source より優先されます。

VPS上のClaude APIクライアントで使える認証を4方式で整理します。Anthropicキー、BedrockのAWS IAM、VertexのGoogle ADC、FoundryのEntraと安全な保管方法を解説します。

Claude API の4つの認証方式

Claude API の認証は、クライアントがどの認証情報をネットワーク上で送信するかという1つの判断に集約されます。選択肢は4つあり、1つの仕組みの派生形ではありません。直接 Anthropic API を利用する場合は、静的なキーを x-api-key ヘッダーで送信します。Amazon Bedrock では、すべてのリクエストに AWS 認証情報で署名するため、この構成内に Anthropic のキーは存在しません。Google Cloud では、有効期間の短い Google アクセストークンを送信します。Microsoft Foundry では、Azure が発行したキーまたは Microsoft Entra トークンを使用します。

このガイドでは、SDK (software development kit) を Linux サーバー上で実行するサービスに組み込みます。代わりに Claude Code コマンドラインツールを設定する場合は、変数と処理の流れが異なります。Claude Code を Bedrock または Vertex に接続するを参照してください。サービスがまだ存在しない場合は、まず VPS 上で最初の Claude API アプリを作成するに従って構築し、その後ここに戻って認証情報を設定してください。

以下の内容は、2026年8月時点の Anthropic のプラットフォームドキュメントと照合済みです。モデル識別子、料金、SDK のバージョン、エンドポイントの形式は変更されるため、このガイドでは、古くなる値を記載せず、各プロバイダーのページを参照しています。

Route 1: Anthropic API key

これは直接的な方法で、Anthropic がシークレットを発行する唯一の方法です。リクエストは Anthropic の API ホストにある Messages エンドポイントへ送信し、各リクエストに3つのヘッダーを付けます。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

MODEL_ID を Anthropic の models overview にある現在の識別子へ置き換えます。正常なレスポンスは、content 配列と usage オブジェクトを含む JSON です。無効または期限切れのキーを使用すると、authentication_error とともに HTTP 401 が返ります。anthropic-version ヘッダーがない場合は別のエラーになります。このヘッダーはすべてのリクエストに必要であり、SDK が自動的に設定します。

クライアントの構築は4つの方法の中で最も簡単です。構築するものがないためです。公式 SDK はすべて、環境変数から ANTHROPIC_API_KEY を自動的に読み取ります。

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

キーと同じ環境にモデル識別子も保存することを推奨します。モデル名は管理下にないスケジュールで変更されるため、1つの文字列を編集するためだけにコードを再デプロイする作業を避けられます。

キーは Console で作成します。作成時に有効期限を選択します。選択肢は、3 hours、1 day、7 days、30 days のプリセット、カスタム期間、Never です。有効期限は作成時に固定され、後から変更できません。 Anthropic は長期間有効なキーの期限が切れる前に、キーの作成者へメールを送信します。ただし、有効期間が短いキーの期限切れについては、警告メールが一切送信されません。期限切れのキーは 401 を返し、再有効化できません。そのため、常に新しいキーを作成して対応します。

直接 API ではリージョンを選択する必要がなく、料金は Anthropic organization に直接請求されます。Workspaces を使用すると、キーを1つのプロジェクトに限定できます。単一のサービスの利用額を把握するには、この方法が最も明確です。料金計算の仕組みについては、トークン単位の API 料金とサブスクリプションの比較を参照してください。

ここでは、静的なシークレットを完全に排除できるもう1つの方法にも触れておきます。Workload Identity Federation を使用すると、すでに信頼している identity provider の OpenID Connect (OIDC) トークンを、POST /v1/oauth/token にある短期間有効な Anthropic トークンと交換できます。SDK はトークンの期限が切れる前に更新します。sk-ant-api... 文字列が生成されたり、どこかにコピーされたりすることはありません。これは、すでにプラットフォーム ID を持っている Kubernetes、GitHub Actions、cloud VM に適しています。通常の VPS にはそのような issuer がないため、そのサーバーではファイルに保存した API key を使うのが現実的な方法です。このガイドの以降の説明も、その前提で進めます。

Route 2: Amazon Bedrock で AWS 認証情報を使用する

Bedrock では Anthropic key を保持する必要がありません。SDK は通常の AWS credentials を使用し、各 HTTP request に AWS Signature Version 4 (SigV4) で署名します。AWS は、その caller に model の invoke が許可されているかを判定します。

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity は、credentials が解決する identity の account number と ARN (Amazon Resource Name) を出力します。ほかの処理より先に実行してください。これが失敗する場合、Claude call も失敗します。SDK は同じ chain をたどるためです。最初に constructor arguments、次に AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN、AWS_REGION の environment variables、その後に AWS config file と、SSO、assumed roles、ECS task role、instance metadata service などの標準 chain を確認します。

client の構築で変わるのは class と1つの argument です。

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

ここでは Region は単なる表示情報ではありません。Bedrock endpoint は region ごとに分かれています。model access も AWS console で region ごとに許可されます。また、region は SigV4 signature の一部です。そのため、ある region 用に計算した signature は別の region では拒否されます。service environment で AWS_REGION を明示的に設定してください。Anthropic のドキュメントによると、AnthropicBedrock client は AWS_REGION を読み、未設定の場合は us-east-1 にフォールバックします。また、region の指定に ~/.aws/config は読み取りません。これが、同じ host 上で AWS CLI は Claude models を正常に一覧表示できる一方、Python process の client は失敗する理由です。CLI は config file を読み取りますが、client は読み取りません。

EC2 instance では IAM (identity and access management) role を attach します。instance metadata service が SDK に temporary credentials を渡すため、secret が disk に保存されることはありません。AWS 外部の VPS には instance role も metadata service もありません。その場合は、box 上に IAM user の long-lived access key pair を置くか、federation を使用するかを選択します。前者は Anthropic key と同じ種類の secret です。federation では identity provider に対して authenticate し、AWS STS (security token service) を呼び出し、返された temporary credentials を使用します。Bedrock は AWS_BEARER_TOKEN_BEDROCK による bearer token も受け付けます。ドキュメントでは有効期間の上限を 12 hours としており、AWS はこれを最も推奨しない方法と説明しています。

料金は Anthropic ではなく AWS account に請求されます。通常、これが Bedrock を使用する主な理由です。2026年8月のドキュメントによると、regional endpoint には global endpoint より 10% の割増料金がかかります。権限の問題に見えて、実際には異なる Bedrock error に注意してください。Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model. これは model routing の問題であり、credential を変更しても解決しません。

Route 3: Vertex AI で Google 認証情報を使用する

Google Cloud は Application Default Credentials（ADC）を使用します。これは、認証情報を明示的に指定しなくても認証情報を探せるよう、Google の認証ライブラリが使用する固定の検索順序です。ADC は最初に GOOGLE_APPLICATION_CREDENTIALS を確認し、次に gcloud auth application-default login が書き込んだファイルを確認します。その後、metadata server を介してアタッチされた service account を確認します。

pip install -U "anthropic[vertex]"
gcloud auth application-default login

ワークステーションでは、ログインによって $HOME/.config/gcloud/application_default_credentials.json が書き込まれるため、それで完了です。サーバーでは、この方法は適切ではありません。保存される認証情報は人間のユーザーに属し、そのユーザーのアカウントとともに無効になるためです。Google Cloud の外部には metadata server もありません。そのため、ADC は GOOGLE_APPLICATION_CREDENTIALS に進み、service account key file を参照します。この JSON ファイルは長期間有効な Secret であり、このガイドの後半で説明する方法で厳格に管理する必要があります。Google Cloud 内では、VM に service account をアタッチしてください。保護すべきファイルはありません。

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

SDK より下の層で raw HTTP を使用すると、2 つの点が変わります。モデル識別子は request body から URL path に移動し、anthropic_version は header から body に移動します。body 内では vertex-2023-10-16 と記述する必要があります。認証情報は通常の Google access token です。

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Region は独立した引数です。global は可用性に応じて動的にルーティングします。us と eu は multi-region の識別子です。us-east5 のような名前を指定すると、単一の region に固定されます。2026 年 8 月のドキュメントに記載されているとおり、multi-region と regional の endpoint は global より 10% 高くなります。Billing は Google Cloud project 経由で処理されるため、quota と invoice は Google が管理します。

ルート 4: Microsoft Foundry は Azure のルートです

Azure 上で Claude を検索した場合は、このセクションが対象です。サポートされているルートが実際にあります。Claude は Microsoft Foundry（旧称 Azure AI Foundry）で実行され、Azure Marketplace を通じて Claude Consumption Units で課金されます。Foundry リソースを作成し、その中に Claude モデルをデプロイして、https://{resource}.services.ai.azure.com/anthropic/v1/* にある Azure ホストのエンドポイントを呼び出します。

使用できる認証情報は 2 種類です。1 つ目は、Foundry ポータルのデプロイメントの Details タブに表示される Azure 発行キーです。api-key または x-api-key ヘッダーで送信します。2 つ目は Microsoft Entra トークンです。サーバーではこちらが適しています。Azure のロールベースアクセス制御によって、エンドポイントを呼び出せるユーザーを管理できるためです。

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

model フィールドには、モデル識別子ではなくデプロイメント名を指定します。デフォルトでは両者が一致します。しかし、デプロイメントに独自の名前を付けた時点で一致しなくなります。これは、正しいリクエストで発生する Deployment not found エラーの一般的な原因です。Python SDK と TypeScript SDK は、環境から ANTHROPIC_FOUNDRY_API_KEY と ANTHROPIC_FOUNDRY_RESOURCE を読み取ります。すべての SDK が Foundry をサポートしているわけではありません。2026 年 8 月時点のドキュメントでは、C#、Java、PHP、Python、TypeScript がサポートされています。Go SDK と Ruby SDK では、Foundry のベース URL を指定した汎用クライアントが必要です。

この回避策には注意点があります。環境に ANTHROPIC_API_KEY が残っていると、汎用クライアントがその値を取得し、Anthropic のキーを Microsoft のエンドポイントへ送信します。変数の設定を解除するか、クライアントで環境変数のデフォルト値を無効にしてください。Entra トークンの有効期限は約 1 時間です。そのため、長時間実行するプロセスでは、起動時に 1 つ取得して保持するのではなく、トークンを更新する必要があります。

サーバー上の認証情報はどのくらいの期間有効ですか？

ChartDocumented maximum credential lifetime by route, hours

label

max_lifetime_hours

Anthropic key, 30-day preset

720

Anthropic key, 7-day preset

168

AWS STS assumed role

Bedrock bearer token

Entra ID access token

Federated Anthropic token

The data behind this chart

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

これらは各プロバイダーが公開している上限値とデフォルト値であり、2026年8月時点で確認したものです。実測値ではありません。重要なのは、認証情報の漏えいに気付いて調査している間も、漏えいした認証情報がどのくらいの期間使われ続けるかを示す点です。グラフ下部の短期トークンは、それぞれ 1 時間有効です。SDK が更新するため、短い有効期間が運用上の負担になることはありません。Assumed role は 12 時間有効です。30日間のプリセットで作成した key は 720 時間有効で、サーバー上のファイルに1か月間保存される認証情報はこれです。

VPS 上で認証情報を保管する場所

Secret は、root だけが読み取れるファイルに保存し、systemd からプロセスへ渡します。この方法は SDK のバージョンに左右されないため、最初に適切に設定しておく価値があります。

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

ファイルにはプレーンな KEY=value 行を記述します。export、引用符、shell 構文は使用しません。systemd 自身が解析し、shell を介して実行するわけではないためです。

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd は EnvironmentFile= を root として読み取り、User=claudeapp に移行する前に処理します。そのため、サービスアカウントにファイルの読み取り権限を与える必要はありません。root が所有し、モードを 600 にすれば十分です。上記の install コマンドは、この状態を設定します。sudo systemctl enable --now claude-app で起動し、systemctl status claude-app で unit が active (running) に到達し、再起動を繰り返していないことを確認します。

避けるべきことは4つあります。いずれも、理由を自分で確認できます。

unit file 内で Environment= を使って key を記述しないでください。/etc/systemd/system 配下の unit は誰でも読み取れるため、systemctl cat claude-app を実行すると、ローカルユーザーに Secret が表示されます。
commit しないでください。.gitignore は新しいファイルを commit 対象から外すだけで、すでに commit されたファイルには何もしません。git history には、渡された内容がそのまま残るためです。
container image に埋め込まないでください。ENV の行と --build-arg の値は image layer に記録され、docker history --no-trunc で表示できます。後の layer でファイルを削除しても、前の layer からは削除されません。代わりに、--env-file または mount したファイルで実行時に Secret を渡してください。
プロセスの環境変数が root から非公開だと考えないでください。sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ で key を表示できます。目的は、ホスト上の他のアカウントから Secret を隔離することであり、root から隔離することではありません。root は、どのような方法でも Secret を読み取れます。

最後の点は、この設計で実現できる範囲を示しています。Secret を読み取れるのがサービスと root だけであれば、環境変数は Secret の格納先として適切です。プロセスが自分で作成していない code を実行する場合は、適切ではありません。プロセスが実行できるものは、そのプロセス自身の環境変数を読み取れるためです。AI agent の手の届かない場所に Secret を保管するでは、このケースを扱います。これは別の問題であり、解決方法も異なります。

キーを停止時間なしでローテーションする方法

新しいキーを先に切り替え、最後に古いキーを失効させます。

Console で新しいキーを作成します。古いキーと同じ workspace を選択します。
/etc/claude-app/env に sudoedit で書き込みます。
sudo systemctl restart claude-app を実行します。
サービスがリクエストに応答することを確認してから、Console で古いキーを失効させます。

EnvironmentFile は unit の起動時に読み込まれるため、実行中のプロセスは起動時に渡された値を保持します。systemctl daemon-reload は unit ファイルを再読み込みしますが、実行中のプロセスの環境変数には触れません。そのため、新しいキーを反映するには再起動だけが必要です。手順 1 で古いキーを失効させると、手順 3 まで停止時間が続きます。

残りの 3 つの方式では、プロバイダー側でローテーションします。IAM user は同時に 2 個の有効な access key を保持できるため、2 個目を作成してデプロイし、その後で 1 個目を削除します。Google service account key も同じ方法でローテーションします。Foundry key はポータルで再生成すると古いキーが直ちに無効になるため、クリックする前に新しい値を書き込んでください。Entra token と federated Anthropic token はローテーション自体が不要です。可能な場合にこれらを使用する最大の理由はこの点です。

Console を開いている間に、workspace に spend limit も設定してください。漏えいしたキーは、他の何よりも先に高額な費用を発生させます。VPS 上の agent が使用できる金額を制限する方法では、制御方法を説明しています。

クライアントが 401 または 403 を返すのはなぜですか？

直接 API で authentication_error を伴う 401 が返る場合。 暗号鍵が誤っているか、失効しているか、有効期限を過ぎています。有効期限は見落とされやすい項目です。コードが変わっておらず、前日までリクエストが成功していた場合でも該当します。Console で鍵の有効期限の列を確認するか、Admin API から expires_at を読み取ってください。有効期限を設定していない鍵では、null になっています。

SDK が federation の設定を無視し、代わりに鍵を使用する場合。 ANTHROPIC_API_KEY と ANTHROPIC_AUTH_TOKEN は認証情報の優先順位で federation より上位にあるため、どちらかが federation を隠します。特に注意が必要なのは、空文字列として export された変数でも、その位置を占有する点です。そのため ANTHROPIC_API_KEY="" では、SDK は後続の認証方式に移らず、空の鍵で認証します。unset ANTHROPIC_API_KEY を使用してください。

federation で、メッセージだけの Authentication failed を伴う 401 が返る場合。 このメッセージは、考えられる原因にかかわらず意図的に同一です。これにより、呼び出し元がエラーテキストからルール設定を推測できないようにしています。実際の理由は、Console の認証履歴ページに記録されます。JWT を推測する前に、まずそのページを確認してください。

Foundry で 403 が返る場合。 トークンによる認証は成功していますが、Azure アカウントにその呼び出しを許可するロールがありません。リクエストを実行する ID に、Foundry User（旧称 Azure AI User）や Cognitive Services User などの Azure RBAC ロールを割り当ててください。

Bedrock で発生するすべてのエラー。 まずサービスユーザーとして aws sts get-caller-identity を実行してください。これにより、そのホストに使用可能な AWS 認証情報があるかを確認できます。認証情報の問題と、モデルアクセスの問題またはリージョンの不一致を切り分けられます。モデルへのアクセスは AWS console でリージョンごとに許可されます。あるリージョンでは有効にしたものの、別のリージョンを呼び出しているという状況が起こりやすいため、注意してください。

FAQ

Bedrock または Vertex で Claude を使用する場合、Anthropic API key は必要ですか？

いいえ。Amazon Bedrock では、SDK が AWS credentials を使用して SigV4 で各リクエストに署名します。Google Cloud では、Application Default Credentials を通じて取得した Google access token を送信します。どちらの構成にも Anthropic が発行した secret は存在しません。利用料金は Anthropic ではなく、各 cloud account に請求されます。これが、これらのホストの ANTHROPIC_API_KEY に Anthropic key を残すことが危険な理由でもあります。cloud endpoint を指定した汎用 client は、その key をそこへ送信してしまいます。

Azure で Claude は利用できますか？

はい。旧称 Azure AI Foundry の Microsoft Foundry を通じて利用できます。Foundry resource を作成し、Claude model をそこへ deploy して、https://{resource}.services.ai.azure.com/anthropic/v1/messages を呼び出します。認証には、api-key header の Azure-issued key または Microsoft Entra bearer token を使用します。利用料金は Claude Consumption Units として Azure Marketplace 経由で請求されます。request body の model field には deployment name を指定する必要があります。deployment の名前を変更するまでは、deployment name と model identifier は同じです。

Linux server では Claude API key をどこに保存すべきですか？

root が所有し、mode 600 を設定した file に保存し、systemd unit の EnvironmentFile= から読み込ませます。systemd は unit の User= に切り替える前に root としてその file を読み込むため、service account がその file にアクセスする必要はありません。repository、unit file 自体、container image layer には保存しないでください。unit file は誰でも読み取れ、systemctl cat によって表示されます。また、docker history --no-trunc は ENV または --build-arg で設定された内容をそのまま表示するため、container image layer にも残さないでください。

何も変更していないのに、Claude API request が 401 を返すようになったのはなぜですか？

最も一般的な原因は、作成時に指定した有効期限に key が達したことです。有効期限は作成時に設定され、後から変更できません。短期間の key は、警告メールなしで期限切れになります。期限切れの key は再有効化できないため、replacement を作成し、environment file に書き込み、service を再起動してから古い key を revoke します。key が確実に有効な場合は、古い credential が優先されていないか確認してください。ANTHROPIC_API_KEY が空の文字列に設定されていても、他のすべての credential source より優先されます。

#claude #api #authentication #bedrock#vertex#secrets-management