LiteLLMでAmazon Bedrock・Vertex AI・Azure AI FoundryのLLMを呼び出してみる

はじめに

データ事業本部のkobayashiです。

前回の記事 ではLiteLLMの基本的な使い方を紹介しましたが、実際のプロダクション環境ではOpenAI・Anthropic・GoogleのAPIを直接利用するのではなく、エンタープライズ要件（データ所在地、VPC内からの呼び出し、既存クラウド契約との統合など）からクラウド経由でLLMを利用するケースが多くあります。

https://dev.classmethod.jp/articles/python-litellm/

代表的な選択肢は以下の3つです。

• Amazon Bedrock: Claude、Llama、Titan、Nova、Mistralなどを提供
• Google Cloud Vertex AI: Gemini、Claude、Llamaなどをマネージドで提供
• Azure AI Foundry (旧 Azure OpenAI Service): OpenAIのモデルをAzure上で提供

今回はこれら3つのクラウドプロバイダーをLiteLLMから利用する際の使い方と、各クラウドで利用可能な認証パターンを利用環境とともに整理します。

• LiteLLM - GitHub
• LiteLLM - ドキュメント

環境

今回使用した環境は以下の通りです。

Python 3.13
litellm 1.83.14

クラウド経由でLLMを使うメリット

各クラウドプロバイダー経由でLLMを利用する主なメリットは以下になります。

• データガバナンス: 入出力データが指定したリージョン内で処理され、プロバイダー側のモデル学習に利用されない
• ネットワーク分離: VPC EndpointやPrivate Endpoint経由でインターネットを介さず呼び出し可能
• IAMによるアクセス制御: 既存のIAM基盤でLLMへのアクセス権を一元管理
• 課金の一元化: 既存のクラウド契約と同じ請求書に集約
• 監査ログ: Cloud Audit Logs / CloudTrail / Azure Monitor で呼び出しを追跡可能

一方でモデルの提供開始タイミングがネイティブAPIより遅れる、リージョンごとの可用モデルが異なるといった制約もあります。

LiteLLMの認証の仕組み

LiteLLMは各クラウドプロバイダーのSDKをラップしているため、認証方法もそれぞれのSDKの仕組みに準拠しています。認証情報の指定方法は大きく分けて3つのパターンがあります。

以降、Amazon Bedrock・Vertex AI・Azure AI Foundryそれぞれの具体的な使い方と認証パターンを見ていきます。

Amazon Bedrock

Amazon BedrockではAnthropic Claude、Meta Llama、Amazon Nova、Mistral、Cohereなど複数ベンダーのモデルを統一APIで利用できます。AWSの認証基盤（IAM）を利用し、boto3のCredential Chainに準拠しているため、環境変数、プロファイル、IAMロールなど多様な認証方法が利用可能です。

セットアップ

BedrockはAWS標準のboto3認証チェーンを利用するため、LiteLLM本体に加えてboto3もインストールします。

$ uv pip install litellm boto3

認証パターン1: 環境変数によるアクセスキー認証

最もシンプルな方法です。IAMユーザーのアクセスキーを環境変数に設定します。

$ export AWS_ACCESS_KEY_ID="AKIA..."
$ export AWS_SECRET_ACCESS_KEY="..."
$ export AWS_REGION_NAME="ap-northeast-1"

from litellm import completion

response = completion(
    model="bedrock/anthropic.claude-sonnet-4-6",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
)

print("=== Bedrock (環境変数認証) ===")
print(response.choices[0].message.content)
print(f"モデル: {response.model}")
print(f"トークン: {response.usage.total_tokens}")

手軽ですがアクセスキーの管理が必要なため、ローカル開発やCI/CDでの一時利用に留めるのが望ましいです。

認証パターン2: AWS Profile認証

~/.aws/credentials に定義されたプロファイルを利用する方法です。複数のAWSアカウントを使い分ける開発環境で便利です。

from litellm import completion

response = completion(
    model="bedrock/anthropic.claude-sonnet-4-6",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
    aws_profile_name="{プロファイル名}",
    aws_region_name="ap-northeast-1",
)

print("=== Bedrock (Profile認証) ===")
print(response.choices[0].message.content)

aws_profile_name パラメータで直接指定するほか、AWS_PROFILE 環境変数でも指定可能です。

$ export AWS_PROFILE="{プロファイル名}"
$ export AWS_REGION_NAME="ap-northeast-1"

なお、AWS Organizations環境でIAM Identity Center（旧AWS SSO）を利用している場合も、事前に aws sso login --profile my-sso-profile でログインしておけば、同じく aws_profile_name でSSOプロファイルを指定するだけで利用できます。boto3がSSOトークンを自動的に解決してくれるため、LiteLLM側のコードは通常のProfile認証と同じです。

# ~/.aws/config
[profile my-sso-profile]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-northeast-1
sso_account_id = 123456789012
sso_role_name = BedrockUser
region = ap-northeast-1

認証パターン3: IAMロール認証（EC2 / ECS / Lambda）

EC2インスタンスプロファイル、ECSタスクロール、Lambda実行ロールなど、AWSサービスに付与されたIAMロールを自動的に利用する方法です。認証情報の管理が不要で、最もセキュアなパターンです。

from litellm import completion

# IAMロールが付与された環境であれば、リージョンだけ指定すればOK
# export AWS_REGION_NAME="ap-northeast-1"

response = completion(
    model="bedrock/anthropic.claude-sonnet-4-6",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
)

print("=== Bedrock (IAMロール認証) ===")
print(response.choices[0].message.content)

コード上では認証情報を一切指定しません。boto3がEC2メタデータサーバーやECSコンテナ認証情報から自動的にIAMロールの認証情報を取得します。

認証パターン4: AssumeRole（クロスアカウント）

STSのAssumeRoleを利用して、別のAWSアカウントのBedrockを呼び出す方法です。マルチアカウント構成でBedrockが有効化された特定のアカウントにアクセスする場合に使用します。

LiteLLMには2つの指定方法があります。

方法1: LiteLLMのパラメータで直接指定

from litellm import completion

response = completion(
    model="bedrock/anthropic.claude-sonnet-4-6",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
    aws_role_name="arn:aws:iam::123456789012:role/BedrockAccessRole",
    aws_session_name="litellm-session",
    aws_region_name="ap-northeast-1",
)

aws_role_name にRoleのARNを指定するだけで、LiteLLMが内部でSTSのAssumeRoleを実行してくれます。

方法2: boto3でAssumeRoleして一時クレデンシャルを渡す

import boto3
from litellm import completion

sts_client = boto3.client("sts")
assumed_role = sts_client.assume_role(
    RoleArn="arn:aws:iam::123456789012:role/BedrockAccessRole",
    RoleSessionName="litellm-session",
)
credentials = assumed_role["Credentials"]

response = completion(
    model="bedrock/anthropic.claude-sonnet-4-6",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
    aws_access_key_id=credentials["AccessKeyId"],
    aws_secret_access_key=credentials["SecretAccessKey"],
    aws_session_token=credentials["SessionToken"],
    aws_region_name="ap-northeast-1",
)

方法2はAssumeRoleの前にMFA認証を挟んだり、セッションポリシーを付与したりと、より柔軟な制御が必要な場合に向いています。

Bedrock 認証パターンまとめ

モデルの呼び出し

ここからはBedrockで利用できる代表的なモデルの呼び出し方を見ていきます。

Claudeを呼び出す

bedrock/ プレフィックスにBedrockのモデルIDを指定します。

from litellm import completion

response = completion(
    model="bedrock/anthropic.claude-sonnet-4-6",
    messages=[{"role": "user", "content": "Amazon Bedrockの特徴を3つ挙げてください"}],
)

print(response.choices[0].message.content)
print(f"入力トークン: {response.usage.prompt_tokens}")
print(f"出力トークン: {response.usage.completion_tokens}")

Bedrockのモデルはリージョンごとに提供状況が異なります。利用前に aws bedrock list-foundation-models で利用可能なモデルを確認しておくと確実です。

クロスリージョン推論プロファイル

Bedrockでは、単一リージョンに閉じず複数リージョンへ自動ルーティングされる「クロスリージョン推論プロファイル」が提供されています。LiteLLMから利用する場合は、プロファイルIDを指定します。

from litellm import completion

response = completion(
    model="bedrock/jp.anthropic.claude-sonnet-4-6",
    messages=[{"role": "user", "content": "クロスリージョン推論のメリットを教えてください"}],
)

print(response.choices[0].message.content)

提供されているプレフィックスはモデル・地域ごとに異なります。プレフィックスを付けることで該当地域の複数リージョンにリクエストが分散されるため、スロットリングが起きにくくなる一方、データが複数リージョンで処理される点に注意が必要です。

Vertex AI

Google Cloud Vertex AIでは、Geminiシリーズに加えAnthropic Claude、Meta Llama、Mistralなどのサードパーティモデルを統一的に利用できます。Google Cloudの認証基盤を利用するため、APIキーではなくサービスアカウントやADC（Application Default Credentials）による認証が中心になります。

セットアップ

LiteLLMでVertex AIを利用するには、Google関連の依存関係を含めてインストールする必要があります。

$ uv pip install 'litellm[google]'

認証パターン1: Application Default Credentials（ADC）

ローカル開発で最も手軽な方法です。gcloud auth application-default login を実行済みであれば、プロジェクトIDとリージョンを環境変数に設定するだけで利用できます。

$ gcloud auth application-default login
$ export VERTEXAI_PROJECT="{プロジェクトID}"
$ export VERTEXAI_LOCATION="us-central1"

from litellm import completion

response = completion(
    model="vertex_ai/gemini-2.5-flash",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
)

print("=== Vertex AI (ADC認証) ===")
print(response.choices[0].message.content)
print(f"モデル: {response.model}")
print(f"トークン: {response.usage.total_tokens}")

ADCは以下の優先順位で認証情報を探します。

1. GOOGLE_APPLICATION_CREDENTIALS 環境変数で指定されたサービスアカウントキー
2. gcloud auth application-default login で取得したユーザー認証情報
3. Compute Engine / Cloud Run 等のメタデータサーバー（サービスアカウント）

認証パターン2: サービスアカウントキーファイル（GOOGLE_APPLICATION_CREDENTIALS）

CI/CDパイプラインやオンプレミス環境など、gcloud CLIが使えない環境ではサービスアカウントのJSONキーファイルを利用します。

$ export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"
$ export VERTEXAI_PROJECT="{プロジェクトID}"
$ export VERTEXAI_LOCATION="us-central1"

コードはパターン1と同じです。GOOGLE_APPLICATION_CREDENTIALS を設定することで、ADCがサービスアカウントキーを自動的に読み込みます。

認証パターン3: JSONキーを直接パラメータで渡す

サービスアカウントのJSONキーの内容を vertex_credentials パラメータに直接渡す方法です。AWS Secrets ManagerやGoogle Cloud Secret Managerから動的に認証情報を取得する場合に有用です。

import json
import os

from litellm import completion

# Secrets Manager等からJSONキーを取得する想定
service_account_json = os.environ.get("VERTEX_SA_JSON", {})

response = completion(
    model="vertex_ai/gemini-2.5-flash",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
    vertex_credentials=service_account_json,
    vertex_project="{プロジェクトID}",
    vertex_location="us-central1",
)

print("=== Vertex AI (JSONキー直接指定) ===")
print(response.choices[0].message.content)

vertex_credentials にはJSON文字列を渡します。vertex_project と vertex_location もパラメータで明示的に指定するため、環境変数の設定は不要です。

認証パターン4: JSONキーファイルパスをパラメータで渡す

vertex_credentials にはファイルパスを渡すことも可能です。GOOGLE_APPLICATION_CREDENTIALS 環境変数を設定できない環境や、複数のサービスアカウントを使い分けたい場合に便利です。

from litellm import completion

SA_KEY_PATH = "/path/to/service-account.json"

response = completion(
    model="vertex_ai/gemini-2.5-flash",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
    vertex_credentials=SA_KEY_PATH,
    vertex_project="{プロジェクトID}",
    vertex_location="us-central1",
)

print("=== Vertex AI (JSONキーファイルパス指定) ===")
print(response.choices[0].message.content)

vertex_credentials にJSON文字列を渡した場合はその内容を直接利用し、ファイルパスを渡した場合はファイルを読み込んで利用します。

認証パターン5: サービスアカウント Impersonation

「ログインユーザーが別のサービスアカウントになりすましてVertex AIを呼び出す」パターンです。SAキーをローカルに置かずに済むため、開発環境のセキュリティを高めたい場合に有効です。事前にユーザーへ roles/iam.serviceAccountTokenCreator を対象SAに対して付与しておく必要があります。

gcloud で impersonation を設定すれば、ADCが自動的にimpersonationを適用するため、LiteLLM側のコードは認証パターン1（ADC）と全く同じものを使えます。

$ gcloud auth application-default login
$ gcloud config set auth/impersonate_service_account \
    target-sa@{プロジェクトID}.iam.gserviceaccount.com
$ export VERTEXAI_PROJECT="{プロジェクトID}"
$ export VERTEXAI_LOCATION="us-central1"

設定後は通常のADC認証と同じコード（vertex_ai_adc.py）でそのまま動作します。SAキーJSONをローカルに置く必要がなく、誰がいつ・どのSAになりすました呼び出しを行ったかをCloud Audit Logsで追跡できる利点があります。

認証パターン6: Workload Identity / Workload Identity Federation

GCP上の本番環境やGCP外のCI/CDから「SAキーファイルを置かずに」Vertex AIを呼ぶパターンです。

• GKE Workload Identity: KubernetesのServiceAccountにGCP SAを紐づけることで、Pod内のプロセスがメタデータサーバー経由でトークンを取得する仕組み
• Workload Identity Federation: GCP外のID（OIDCトークン、AWS IAM、Azure AD等）でGCPに認証する仕組み。GitHub Actionsからの利用などが代表例

いずれも google-auth がADCの仕組みで自動解決するため、LiteLLM側のコードは通常のADC認証と同じです。GKE Pod内では GOOGLE_APPLICATION_CREDENTIALS の指定は不要、WIFの場合は外部IDとの交換設定を記述したJSONを GOOGLE_APPLICATION_CREDENTIALS に指定するだけで利用できます。SAキーをリポジトリやSecretsに保管する必要がなくなるため、本番・CI環境で推奨される構成です。

Vertex AI 認証パターンまとめ

Azure AI Foundry

Azure AI Foundry（旧Azure OpenAI Service）はOpenAIのGPTシリーズを中心に、Azureのエンタープライズ基盤上でLLMを利用できます。APIキー認証とMicrosoft Entra ID（旧Azure AD）によるトークン認証の2つの認証基盤を提供しています。

セットアップ

Azureはデプロイ単位でエンドポイントを作成する点が他のプロバイダーと大きく異なります。事前にAzure Portalでモデルをデプロイし、デプロイ名・エンドポイント・APIキーを取得しておきます。

認証パターン1: APIキー認証（環境変数）

Azure Portalから取得したAPIキーを環境変数に設定する最もシンプルな方法です。

$ export AZURE_API_KEY="{APIキー}"
$ export AZURE_API_BASE="https://{Azureリソース名}.openai.azure.com/"
$ export AZURE_API_VERSION="2024-12-01-preview"

from litellm import completion

response = completion(
    model="azure/{デプロイ名}",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
)

print("=== Azure AI Foundry (APIキー認証) ===")
print(response.choices[0].message.content)
print(f"モデル: {response.model}")
print(f"トークン: {response.usage.total_tokens}")

注意点として、Azureの場合はモデル名に azure/ プレフィックス + デプロイ名を指定する必要があります（モデル名ではない点に注意）。また、api_base にはAzureリソースのエンドポイントURLを、api_version にはAPIバージョンを指定します。

認証パターン2: APIキーをパラメータで直接指定

環境変数を使わず、completion() のパラメータに直接指定する方法です。複数のAzureリソースを使い分けたい場合や、Secrets Managerから動的に取得する場合に有用です。

import os

from litellm import completion

api_key = os.environ.get("MY_AZURE_API_KEY", "")

response = completion(
    model="azure/{デプロイ名}",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
    api_key=api_key,
    api_base="https://{Azureリソース名}.openai.azure.com/",
    api_version="2024-12-01-preview",
)

print("=== Azure AI Foundry (APIキー直接指定) ===")
print(response.choices[0].message.content)

認証パターン3: Microsoft Entra ID（Azure AD）トークン認証

azure-identity ライブラリの DefaultAzureCredential で取得したトークンを azure_ad_token_provider パラメータに渡す方法です。APIキーを管理する必要がなくなり、よりセキュアです。LiteLLMが必要なタイミングで自動的にトークンをリフレッシュします。

$ uv pip install azure-identity

from azure.identity import DefaultAzureCredential, get_bearer_token_provider

from litellm import completion

token_provider = get_bearer_token_provider(
    DefaultAzureCredential(),
    "https://cognitiveservices.azure.com/.default",
)

response = completion(
    model="azure/{デプロイ名}",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
    azure_ad_token_provider=token_provider,
    api_base="https://{Azureリソース名}.openai.azure.com/",
    api_version="2024-12-01-preview",
)

print("=== Azure AI Foundry (Entra ID トークン認証) ===")
print(response.choices[0].message.content)

api_key ではなく azure_ad_token_provider に渡す点に注意してください（api_key に渡すと api-key ヘッダで送信されてしまい、Entra IDトークンの場合は認証エラーになります）。DefaultAzureCredential は環境変数による認証情報、マネージドID、Azure CLI（az login）など複数のソースから自動的に認証情報を解決してくれるため、ローカル開発（az login 状態）とAzure上（マネージドID）の両方で同じコードが動きます。

認証パターン4: マネージドID認証（自動フォールバック）

Azure VM / App Service / Functions / Container Apps / AKS 上で動作する場合、litellm.enable_azure_ad_token_refresh = True を設定するだけで、LiteLLMが内部的に DefaultAzureCredential を使ってトークンを自動取得・リフレッシュします。DefaultAzureCredential の解決順でマネージドIDが拾われるため、Azure上で動かしているプロセスでは追加設定なしでマネージドIDが使われます。

$ export AZURE_API_BASE="https://{Azureリソース名}.openai.azure.com/"
$ export AZURE_API_VERSION="2024-12-01-preview"

import litellm
from litellm import completion

# DefaultAzureCredentialへの自動フォールバックを有効化
litellm.enable_azure_ad_token_refresh = True

response = completion(
    model="azure/{デプロイ名}",
    messages=[{"role": "user", "content": "LiteLLMとは何ですか？一言で教えてください"}],
)

print("=== Azure AI Foundry (マネージドID認証) ===")
print(response.choices[0].message.content)

enable_azure_ad_token_refresh を有効にすると、LiteLLMはまず環境変数経由のService Principal認証（AZURE_CLIENT_ID / AZURE_CLIENT_SECRET / AZURE_TENANT_ID）を試し、それが利用できない場合は DefaultAzureCredential にフォールバックします。Azure上ではマネージドIDが自動採用されるため、認証情報を一切ハードコードせずにLLMを呼び出せます。

ユーザー割り当てマネージドIDを使いたい場合は、AZURE_CLIENT_ID 環境変数にマネージドIDのクライアントIDを設定しておくと、DefaultAzureCredential がそれを優先利用します。

Azure AI Foundry 認証パターンまとめ

まとめ

LiteLLMを使ってAmazon Bedrock・Vertex AI・Azure AI Foundryの3つのクラウドプロバイダー経由でLLMを利用する方法と、それぞれの認証パターンを整理しました。

LiteLLMの強みは、クラウドごとに異なるSDK・認証・モデルID体系を統一インターフェースで吸収してくれる点にあります。completion() 関数のモデル名を bedrock/...・vertex_ai/...・azure/... に切り替えるだけでプロバイダーを変更でき、認証も環境変数による設定、パラメータでの直接指定、クラウドネイティブな認証（IAMロール、ADC、マネージドID）の3つのアプローチを環境に応じて使い分けることで、セキュリティと利便性を両立できます。

エンタープライズでのLLM導入時には、データガバナンスやIAM統合の観点からクラウド経由での利用が必要になるケースが多いため、LiteLLMの統一インターフェースを活用することで実装・運用の負荷を大きく減らせます。

最後まで読んでいただきありがとうございました。