【Claude】EC2のWindows ServerからClaude DesktopをAmazon Bedrock経由で使う方法

スポンサーリンク
AWS
スポンサーリンク

以前、EC2上のWindowsからChatGPT Desktop / CodexをAmazon Bedrock Runtime経由で使う話を書いた。今回はその Claude 版で、EC2上のWindows Server 2025から、Claude DesktopをAmazon Bedrock経由で使えるようにした。Anthropicのアカウントにサインインするのではなく、AWSの認証とBedrockをモデルの提供元として使う形だ。

環境と構成

  • AWS EC2(東京リージョン)上のWindows Server 2025
  • Claude Desktop 2.7032.0.0
  • EC2にはBedrockを呼べるIAMロールを付与済み
  • 使うモデルはjp.anthropic.claude-opus-5-5(Claude Opus 5.5)

構成はこうなる。

Claude Desktop(サードパーティ推論 = Bedrock)
    ↓
AWSプロファイル claude-ec2
    ↓
EC2のIAMロールの一時認証情報
    ↓
Amazon Bedrock Runtime(ap-northeast-1)
    ↓
jp.anthropic.claude-opus-5-5

Claude Desktopの設定

まず前提として、AWS側の設定(.aws/configなど)を用意しただけでは、Claude Desktopのチャットの接続先は切り替わらない。Claude Desktop側で「サードパーティ推論」をBedrockに設定する必要がある。

開発者モードを有効にする

サードパーティ推論の設定画面は、最初は普通のメニューからは開けない。インストール直後の「始める」画面のまま、左上のメニューから「ヘルプ → トラブルシューティング → 開発者モードを有効にする」を選ぶ。

Claude Desktop左上のメニューから、ヘルプ、トラブルシューティング、開発者モードを有効にするを選ぶ画面

確認ダイアログが出るので「有効にする」を選ぶ。

開発者モードを有効にしますかという確認ダイアログ

サードパーティ推論を設定する

開発者モードを有効にすると、左上のメニューに「開発」が増える。ここから「サードパーティ推論を設定...」を開く。

左上メニューの開発から、サードパーティ推論を設定を選ぶ画面

開いた直後は、送信先が「Gateway」になっている。

サードパーティ推論の設定画面を開いた直後。送信先がGatewayになっている

「接続」で送信先をBedrockに変え、認証情報の種類はクラウドベンダープロファイルを選ぶ。リージョンとBedrockのベースURLは東京リージョンに合わせた。

サードパーティ推論の設定画面。接続先がBedrock、認証情報の種類がクラウドベンダープロファイル、リージョンがap-northeast-1

続けて、AWSプロファイル名・AWSの設定ディレクトリ・AWS CLIのパスを指定する。

AWSプロファイル名にclaude-ec2、AWSの設定ディレクトリとAWS CLIのパスを指定した画面
項目 設定値
AWSプロファイル名 claude-ec2
AWSの設定ディレクトリ C:\Users\<User>\.aws-claude
AWS CLIのパス C:\Users\<User>\AppData\Local\Programs\Amazon\AWSCLIV2\aws.exe

AWSの設定ディレクトリは、既定の%USERPROFILE%\.awsではなく専用の.aws-claudeにした。既存の共有AWS設定(他のツールが使っている[default]プロファイルなど)に手を入れずに、Claude Desktop用の設定だけを分離できる。既定の.awsで問題なければ、このディレクトリ指定は不要だ。

モデルリストにはjp.anthropic.claude-opus-5-5を追加した。最初のエントリがデフォルトのモデルになる。

モデルリストにjp.anthropic.claude-opus-5-5を追加し、表示名をClaude Opus 5.5にした画面

設定後は、画面右下の「変更を適用」を押してClaude Desktopを再起動する。保存しただけでは反映されない(後述)。

この設定が済むと、左下のアカウントメニューに「推論設定」が出てくるようになる。以降の設定変更はここから開ける。

設定後に左下のアカウントメニューに表示される推論設定の項目

AWSプロファイルの用意(EC2のIAMロールを使う)

今回のケースでは、EC2のIAMロールでBedrockを利用する必要があった。ところがClaude Desktopは、上で見たとおり何かしらのAWSプロファイル(config)を指定しないと使えない。そこで、EC2のIAMロールの認証情報を取ってくるプロファイルをcredential_processとPowerShellスクリプトで用意した。

ちなみに前回のCodexの場合は、config.tomlでモデルプロバイダーなどを指定するだけで、EC2のIAMロールをそのまま使えた。Claude Desktopはプロファイル経由でしか認証情報を受け取れないので、このひと手間が必要になる。

専用ディレクトリのconfigに、次のプロファイルを書く。同じディレクトリに空のcredentialsファイルも置いておく。

[profile claude-ec2]
region = ap-northeast-1
credential_process = powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\Users\<User>\.aws-claude\imds-creds-direct.ps1
専用ディレクトリのconfigファイル。credential_processでPowerShellスクリプトを呼び出している

credential_processは、AWS CLIが認証情報を必要としたときに指定したコマンドを実行し、その標準出力のJSONを認証情報として使う仕組みだ。一時認証情報には期限があるが、期限が来れば再度このスクリプトが呼ばれて取り直してくれる。呼び出すスクリプトimds-creds-direct.ps1の中身はこうした。

$ErrorActionPreference = 'Stop'
# Bypass proxies only inside this short-lived credential process.
[System.Net.WebRequest]::DefaultWebProxy = New-Object System.Net.WebProxy
$base = 'http://169.254.169.254/latest'
$token = Invoke-RestMethod -Method Put -Uri "$base/api/token" -Headers @{'X-aws-ec2-metadata-token-ttl-seconds'='60'} -TimeoutSec 10
$headers = @{'X-aws-ec2-metadata-token'=$token}
$role = (Invoke-RestMethod -Uri "$base/meta-data/iam/security-credentials/" -Headers $headers -TimeoutSec 10).Trim()
$c = Invoke-RestMethod -Uri "$base/meta-data/iam/security-credentials/$role" -Headers $headers -TimeoutSec 10
if ($c.Code -ne 'Success' -or !$c.AccessKeyId -or !$c.SecretAccessKey -or !$c.Token) { throw 'IMDS did not return valid credentials.' }
@{Version=1;AccessKeyId=$c.AccessKeyId;SecretAccessKey=$c.SecretAccessKey;SessionToken=$c.Token;Expiration=$c.Expiration} | ConvertTo-Json -Compress
imds-creds-direct.ps1をエディタで開いた画面

IMDSv2(インスタンスメタデータサービス)のトークンを取ってから、EC2に付けたIAMロールの一時認証情報を取得し、credential_processが求める形式のJSONで返している。

3行目は、OSにプロキシが設定されている環境向けの1行だ。Windows PowerShellのInvoke-RestMethodは既定でOSのプロキシ設定に従うため、メタデータ(169.254.169.254)への要求までプロキシへ流れてしまうことがある。このスクリプトの中でだけプロキシを無効にして、確実にこのEC2自身のメタデータを取るようにしている。OS全体のプロキシ設定は変えていない。プロキシのない環境なら、あっても害はない。

なお、このスクリプトを手動で実行すると、出力されるのは認証情報そのものなので取り扱いには注意してほしい。

接続を確認する

いきなりClaude Desktopの接続テストから始めると、失敗したときにどこが悪いのか分からない。次の順番で確認していくのが確実だ。

  1. 用意したプロファイルでSTSのGetCallerIdentityを実行し、EC2に付けたIAMロールになっているか確認する
  2. AWS CLIでBedrockのConverseが通るか確認する
  3. 最後にClaude Desktopの推論設定画面で「接続をテスト」を押す

1の確認は、例えばPowerShellで次のように専用ディレクトリの設定を指定して行える。

$env:AWS_CONFIG_FILE = "$env:USERPROFILE\.aws-claude\config"
$env:AWS_SHARED_CREDENTIALS_FILE = "$env:USERPROFILE\.aws-claude\credentials"
aws sts get-caller-identity --profile claude-ec2

ここで表示されたロールが想定と違うなら、その先に進んでも失敗する。BedrockでAccessDeniedが出たときも、IAMの権限を足す前に、まずここで「今どのロールとして動いているか」を確認した方がいい。

3まで通れば、あとは普段通りClaude Desktopでチャットするだけだ。今回の環境では、接続テストは1トークンの応答で約6.3秒で成功した。

ハマりポイント:接続テストが「CLI exited」で失敗する

最初に接続テストを押したときは、「CLI exited」というエラーで失敗した。このときは設定を保存しただけで、「変更を適用」→再起動をしていなかった。適用・再起動をしてから再テストすると成功した。

ただ、このときは同時に認証まわりの設定も直していたので、このエラーの原因が「適用・再起動をしていなかったこと」だけだったとは言い切れない。同じエラーが出たら、適用・再起動をしたかどうかと、上の1・2の確認が通るかどうかの両方を見てほしい。

注意点

  • アクセスキーやトークンを設定ファイルに直接書く必要はない。一時認証情報はcredential_processが期限ごとに取り直す
  • このスクリプトはEC2のメタデータを前提にしているので、EC2以外の環境ではそのまま使えない
  • 新しいモデルやリージョンを追加して拒否されたときは、まずSTSでロールを確認する。本当にIAMの変更が必要なら、必要な権限を特定したうえで最小権限で追加する

今回分かったこと

  • Claude DesktopをBedrock経由で使うには、開発者モードを有効にしてから「開発 → サードパーティ推論を設定」でBedrockに切り替える
  • 認証情報の種類は「クラウドベンダープロファイル」で、AWSプロファイル名・設定ディレクトリ・AWS CLIのパスを指定する
  • Claude DesktopはAWSプロファイルがないと使えないので、EC2のIAMロールを使うならcredential_processでプロファイルとして渡す
  • 設定後は保存だけでなく「変更を適用」→再起動が必要
  • うまくいかないときは、STS → CLIのConverse → Claude Desktopの接続テスト、の順に切り分ける
スポンサーリンク

コメント

タイトルとURLをコピーしました