Amazon Bedrock AgentCore Managed Harness で LiteLLM Proxy をモデルソースとして設定してみた
はじめに
こんにちは、ラ・ムーが好きなコンサル部の神野です。
Amazon Bedrock AgentCore の Managed Harness では、これまで Amazon Bedrock / OpenAI / Google Gemini をモデルソースとして選択できましたが、新たに LiteLLM が追加されていました！
LiteLLM Proxy を間に挟むことで、仮想 API キーの発行や、チーム単位のアクセス制御や使用量トラッキング、ガードレールの適用など、プロキシ層ならではのガバナンス機能を Harness に組み込めるようになります。
今回は LiteLLM Proxy の構築から Harness への接続まで、一気通貫で試してみました。
前提
本記事は下記の環境で検証しています。
| 項目 | 値 |
|---|---|
| Amazon Bedrock AgentCore | us-east-1 |
| LiteLLM Proxy | main-v1.81.14-stable（ECS Fargate + ALB） |
| Terraform | >= 1.5 |
Amazon Bedrock で Claude Sonnet 4.5 / Claude Haiku 4.5 のモデルアクセスが有効になっている必要があります。
LiteLLM Proxy のデプロイ
リポジトリのクローン
LiteLLM Proxy を AWS 上にデプロイするための Terraform コードを用意しています。まずリポジトリをクローンします。
git clone https://github.com/yuu551/lite-llm-sample.git
cd lite-llm-sample/terraform
LiteLLM Proxy の構築について詳しく知りたい方は、下記記事もあわせてご覧ください。
terraform.tfvars の設定
terraform.tfvars.example をコピーして設定を編集します。
cp terraform.tfvars.example terraform.tfvars
今回は仮想 API キーの管理に RDS が必要なので enable_rds を true にします。ガードレールは今回使わないため無効にしています。
aws_region = "us-east-1"
name_prefix = "litellm-harness"
litellm_version = "main-v1.81.14-stable"
litellm_master_key = "sk-xxxxxxxxxxxxxxxxxxxxxxxx"
ecs_cpu = 512
ecs_memory = 1024
desired_count = 1
enable_rds = true
enable_redis = false
enable_guardrail = false
litellm_master_key は管理用の認証キーです。十分にランダムな文字列を設定してください。
config.yaml の確認
デプロイ時に自動生成される config.yaml の元となるテンプレートを確認しておきます。
model_list:
- model_name: claude-sonnet
litellm_params:
model: bedrock/us.anthropic.claude-sonnet-4-5-20250929-v1:0
aws_region_name: ${aws_region}
- model_name: claude-haiku
litellm_params:
model: bedrock/us.anthropic.claude-haiku-4-5-20251001-v1:0
aws_region_name: ${aws_region}
model_name として定義している claude-sonnet と claude-haiku が、後ほど Harness 側で指定するモデル ID のベースになります。LiteLLM Proxy はこれらのエイリアスを受け取ると、裏側で Bedrock の対応するモデルにルーティングしてくれます。
デプロイ
Terraform で一発デプロイします。
terraform init
terraform apply
数分でデプロイが完了します。出力される service_url が LiteLLM Proxy のエンドポイントです。
Apply complete! Resources: 42 added, 0 changed, 0 destroyed.
Outputs:
alb_dns_name = "litellm-harness-xxxxxxxxxx.us-east-1.elb.amazonaws.com"
service_url = "http://litellm-harness-xxxxxxxxxx.us-east-1.elb.amazonaws.com"
ヘルスチェックで正常に起動していることを確認します。
curl -s "$(terraform output -raw service_url)/health/liveliness" | jq .
"I'm alive!" と返ってくれば問題ありません！
仮想 API キーの発行
AgentCore Harness から LiteLLM Proxy に接続する際、認証用の仮想 API キーが必要です。LiteLLM の Admin API を使って、チームの作成とキーの発行を行います。
LiteLLM のチーム・キー管理について詳しくは下記記事で紹介しています。
まず、環境変数にエンドポイントとマスターキーをセットしておきます。
export LITELLM_PROXY_URL="$(terraform output -raw service_url)"
export LITELLM_MASTER_KEY="sk-xxxxxxxxxxxxxxxxxxxxxxxx"
チームの作成
AgentCore Harness 用のチームを作成します。
curl -s "${LITELLM_PROXY_URL}/team/new" \
-H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
-H "Content-Type: application/json" \
-d '{
"team_alias": "agentcore-harness",
"models": ["claude-sonnet", "claude-haiku"]
}' | jq .
{
"team_alias": "agentcore-harness",
"team_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"models": ["claude-sonnet", "claude-haiku"],
...
}
models でアクセス可能なモデルを制限しています。レスポンスに含まれる team_id は次のキー発行で使います。
仮想 API キーの発行
このチームに紐づく仮想 API キーを発行します。
curl -s "${LITELLM_PROXY_URL}/key/generate" \
-H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
-H "Content-Type: application/json" \
-d '{
"team_id": "<上で取得した team_id>",
"key_alias": "agentcore-harness-key"
}' | jq .
{
"key": "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"key_name": "agentcore-harness-key",
...
}
レスポンスの key が仮想 API キーです。この値を次のステップで AgentCore Identity に登録します。
AgentCore Identity で Credential Provider を作成
Harness から LiteLLM Proxy に接続する際、API キーを直接入力するのではなく、AgentCore Identity の Credential Provider を経由して認証情報を管理します。裏側で AWS Secrets Manager に暗号化保存されるため、セキュアに API キーを扱えるのはありがたいですね。
AgentCore コンソールの左メニューから Identity を開きます。
Outbound Auth セクションの「Add Outbound Auth」ボタンから「Add API key」を選択します。
下記情報を入力します。
- Name に
litellm-proxyと入力 - API key type は API key only を選択
- API key に先ほど LiteLLM Proxy で発行した仮想 API キーを入力
- 「Add」ボタンを押下
作成が完了すると、Outbound Auth の一覧に litellm-proxy が表示されます。この Credential Provider の ARN は Harness の設定時にドロップダウンから選択できるため、特に控えておく必要はありません。
Harness の設定
Harness の作成
AgentCore コンソールの左メニューから Harness を選択し、Quick create harness でサクッと作成します。30 秒ほどでデフォルト設定の Harness が出来上がります。
LiteLLM をモデルソースとして設定
作成した Harness の編集画面を開き、Model and system prompt セクションを設定していきます。
Model source で LiteLLM を選択すると、LiteLLM 固有の設定項目が表示されます。
下記の通り設定します。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| Model source | LiteLLM | LiteLLM Proxy 経由でモデルにアクセス |
| Model | litellm_proxy/claude-haiku | litellm_proxy/ + config.yaml の model_name（後述） |
| Credential provider ARN (API key) | litellm-proxy の ARN | 前のステップで作成した Credential Provider を選択 |
| LiteLLM API base | http://<ALB_DNS> |
terraform output で取得した service_url |
| System prompt | 任意のプロンプト | エージェントの振る舞いを定義 |
上のスクリーンショットでは Model に claude-haiku と入力していますが、この指定だとエラーになります。正しくは litellm_proxy/claude-haiku です。理由は動作確認セクションで説明します。
Credential provider ARN (API key) のドロップダウンから、先ほどコンソールで作成した litellm-proxy を選択します。ドロップダウンに表示されない場合はリフレッシュボタンを押してみてください。
LiteLLM API base には terraform output で取得した service_url を指定します。
設定が完了したら Save ボタンを押下して保存します。
動作確認
Harness playground を開いて、早速試してみます！
・・・おや、エラーが出ていますね。
Error: litellm.BadRequestError: LLM Provider NOT provided.
Pass in the LLM provider you are trying to call.
You passed model=claude-haiku
エラー文から、Harness 側のリクエスト処理で LiteLLM の provider 判定が走っているように見えます。claude-haiku のようなエイリアスだけではどのプロバイダーに送ればよいか判定できないんですね。
Strands Agents の LiteLLM ドキュメントを確認すると、LiteLLM Proxy 経由でモデルを呼ぶ場合は litellm_proxy/ プレフィックスを付ける必要があると記載されています。Model ID を litellm_proxy/claude-haiku に変更してみます。
・・・無事レスポンスが返ってきました！！よかった！！
続けて、Model を litellm_proxy/claude-sonnet に playground で切り替えてみます。
Sonnet でも問題なく動いていますね！！モデルの切り替えも体験できました。
リソースの削除
検証が終わったら、Terraform で作成したリソースを忘れずに削除しておきます。
cd lite-llm-sample/terraform
terraform destroy
AgentCore 側の Harness と Credential Provider もコンソールから削除してください。
おわりに
LiteLLM Proxy の構築から Harness への接続まで一通り試してみましたが、仮想 API キーを Credential Provider に登録してエンドポイントを指定するだけで、Harness から簡単に使えてシンプルでした！
本記事が少しでも参考になりましたら幸いです。最後までご覧いただきありがとうございました！
