Difyをセルフホストする理由のひとつが「社内データを外部のSaaSに預けたくない」という制約への対応です。その流れでモデルプロバイダーにAWS Bedrockを選ぶと、認証情報をどう持たせるかが次の課題になります。
アクセスキーとシークレットキーを発行してDifyに貼り付ける方法もありますが、長期間有効な認証情報をアプリに持たせるのは避けたいところです。現在のDifyのBedrockプラグインはIAMロール認証に対応しているため、EC2上で動かしているならアクセスキーを一切発行せずに済みます。
本記事では、EC2のインスタンスプロファイルをそのまま使ってDifyからBedrockを呼ぶ手順を解説します。AWS側の準備（Anthropicモデルのユースケース申請と推論プロファイル）についてはBedrockでモデルが呼べないときの切り分けにまとめてあります。
1. EC2のIAMロールにBedrock権限を追加する
DifyのBedrockプラグインは、認証方式にIAM Roleを選ぶとEC2のインスタンスメタデータから認証情報を取得します。つまり、インスタンスに割り当てたロールに権限を持たせておけば設定は完了です。
CloudFormationでEC2を構築している場合、ロールに次のポリシーを追加します。
InstanceRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: ec2.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Policies:
# Dify の Bedrock プロバイダは認証方式に IAM Role を選べる。
# このロールに権限を持たせておけば、アクセスキーを発行せずに済む。
- PolicyName: BedrockInvoke
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: ListModels
Effect: Allow
Action:
- bedrock:ListFoundationModels
- bedrock:GetFoundationModel
- bedrock:ListInferenceProfiles
- bedrock:GetInferenceProfile
Resource: "*"
- Sid: InvokeModels
Effect: Allow
Action:
- bedrock:InvokeModel
- bedrock:InvokeModelWithResponseStream
- bedrock:Converse
- bedrock:ConverseStream
Resource:
# 推論プロファイル経由で呼ぶ場合、両方が必要になる
- arn:aws:bedrock:*::foundation-model/*
- !Sub arn:aws:bedrock:*:${AWS::AccountId}:inference-profile/*適用したら、インスタンス上で権限が効いているか確認しておきます。Difyのコンテナから呼ぶ前に、ホスト側で通ることを確かめておくと切り分けが楽になります。
# インスタンスロールで動いていることを確認する
aws sts get-caller-identity
# Bedrock を呼べるか確認する
aws bedrock-runtime converse \
--region ap-northeast-1 \
--model-id "jp.anthropic.claude-haiku-4-5-20251001-v1:0" \
--messages '[{"role":"user","content":[{"text":"Say OK"}]}]' \
--inference-config '{"maxTokens":16}' \
--query "output.message.content[0].text" --output textassumed-role/...として認識され、OKが返ってくれば準備完了です。
2. Bedrockプラグインを導入する
Dify 1.x では、モデルプロバイダーはプラグインとして追加します。初期状態ではBedrockは入っていません。
- 左メニューのマーケットプレイスを開く
- 検索欄に
bedrockと入力 - Amazon Bedrock（作者
langgenius）を選んで「インストール」
同名の紛らわしいプラグインがいくつか並びます。作者がlanggeniusのものが公式なので、そこで見分けてください。「Aws Bedrock Knowledge Base」は別物（ナレッジベース連携用）です。
3. IAMロール認証を設定する
インストールが終わると「連携」→「モデルプロバイダー」に Amazon Bedrock が現れます。「APIキーを追加」から認証情報を設定します。
設定する項目は実質2つだけです。
| 項目 | 値 |
|---|---|
| 認証名 | 任意。bedrock-tokyoなど、リージョンがわかる名前にしておくと管理しやすい |
| Authentication Method | IAM Role（既定値） |
| AWS Region | Asia Pacific (Tokyo) |
| Bedrock Endpoint URL | 空欄でよい |
| Available Model Name | 空欄でよい |
| Bedrock Proxy URL | 空欄でよい |
注目したいのは、IAM Roleを選んでいるとアクセスキーの入力欄そのものが表示されないことです。認証方式をAccess-Secret Keyに切り替えたときだけ入力欄が現れます。項目名が「APIキー認証設定」となっているため紛らわしいのですが、IAMロールを使う場合はキーの入力は一切不要です。
保存すると、利用できるモデルが一覧に並びます。
Anthropic Claude、Amazon Nova、Meta Llama、Mistral AIなど、Bedrockが提供するモデルがまとめて登録されます。使わないモデルは個別にオフにできます。
4. 設定は保存できるのにモデルが呼べない場合
ここが今回いちばん共有したいハマりどころです。
Anthropicモデルのユースケース申請が済んでいなくても、Difyの設定は問題なく保存できます。 保存時の検証はモデル一覧の取得（ListFoundationModels）までで、実際の推論までは行わないためです。
そのため、設定画面上は成功しているのに、いざアプリからモデルを呼ぶと次のエラーで落ちます。
ResourceNotFoundException: Model use case details have not been submitted for this account.「設定が保存できた＝使える」ではない点に注意してください。Difyで設定を終えたら、実際にチャットボットを1つ作って応答が返ることまで確認しておくと確実です。
原因の切り分け方はBedrockでモデルが呼べないときの切り分けにまとめてあります。
5. アクセスキー方式との使い分け
IAMロールが使えるのはAWS上でDifyを動かしている場合です。手元のPCやオンプレミスで動かしているなら、認証方式にAccess-Secret Keyを選ぶことになります。
| 動かす場所 | 推奨する認証方式 |
|---|---|
| EC2 / ECS / EKS | IAM Role。キーの発行・管理・ローテーションが不要になる |
| ローカルPC・オンプレミス | Access-Secret Key。最小権限のIAMユーザーを別途作る |
なお、Bedrock APIキーという方式も選択肢にあります。用途に応じて選んでください。
6. まとめ
DifyからBedrockを使う設定の要点を整理します。
- Dify 1.x のBedrockプラグインはIAMロール認証に対応している。EC2上ならアクセスキーは不要
- インスタンスに割り当てたロールにBedrock権限を持たせるだけでよい
- 推論プロファイル経由で呼ぶため、IAMポリシーにはプロファイルと基盤モデルの両方を書く
IAM Roleを選ぶとアクセスキーの入力欄は表示されない。項目名が「APIキー認証設定」なのは紛らわしいが気にしなくてよい- 設定が保存できても使えるとは限らない。Anthropicモデルはユースケース申請が別途必要
本記事の手順は東京リージョンで実際に構築して確認したものです。Dify 1.16.1、Bedrockプラグイン 0.0.77 での動作になります。プラグインは更新が速いため、画面が異なる場合は認証方式の選択肢を手がかりに読み替えてください。
次回は、DifyのファイルストレージをS3に切り替える手順を解説します。
コメント