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が提供するモデルがまとめて登録されます。使わないモデルは個別にオフにできます。
3.1 プラグイン0.0.82では「コンフィグ」と「モデルを追加」が分かれている
Bedrockプラグインは更新が速く、0.0.82ではモデルプロバイダーの画面構成が変わっています。上のスクリーンショットと見比べて迷わないよう、対応関係を整理しておきます。
| 0.0.82での操作 | 何をする場所か |
|---|---|
| カード右上のコンフィグ | 認証情報（bedrock-tokyoなど）の設定。本記事の手順3はこちら。未設定なら「APIキーを追加」と表示される |
| モデルの表示 | プラグインに組み込まれているモデル一覧の確認とオン・オフ |
| モデルを追加 | 組み込みリストに無いモデルを、推論プロファイルを指定して自分で足す |
間違えやすいのが「モデルを追加」のほうです。 プロバイダー全体の認証を設定する画面ではなく、モデルを1件ずつ登録する画面で、入力項目もまったく異なります。
| 項目 | 注意点 |
|---|---|
| Model Name | 推論プロファイルを指定すると自動で埋まる |
| Model Type | LLM / TEXT EMBEDDING / RERANK から選ぶ。必須 |
| Authentication Method | ここでも既定はIAM Role。手順1で付けたロール権限がそのまま効く |
| Inference Profile ID | 必須。プレースホルダは0j6r4a8fn6zeのような短いIDで、これはアプリケーション推論プロファイルの形式 |
| AWS Region | 既定値がUS East (N. Virginia) |
| Enable CloudWatch request metadata | 任意。既定はDisabled |
いちばん注意したいのはAWS Regionの既定値です。認証情報側をAsia Pacific (Tokyo)にしていても、この画面はバージニア北部から始まります。気づかずに追加すると、東京で用意したロール権限では通らないリージョンを指すことになります。
またダイアログの下部には「Get your Access Key and Secret Access Key from AWS Console」というリンクと、「APIキーは PKCS1_OAEP の技術で暗号化されて保存されます」という但し書きが出ます。手順3の「APIキー認証設定」と同じ紛らわしさで、IAM Roleを選んでいる限りキーの入力は不要です。表示に引きずられてアクセスキーを発行しないでください。
なお、この画面はプラグイン0.0.82で確認したものです。モデルを追加した後の動作までは検証していません。
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モデルはユースケース申請が別途必要
- プラグイン0.0.82では「コンフィグ」と「モデルを追加」が別画面。後者はAWS Regionの既定がバージニア北部なので必ず変更する
本記事の手順は東京リージョンで実際に構築して確認したものです。Dify 1.16.1、Bedrockプラグイン 0.0.77 での動作になります。プラグインは更新が速いため、画面が異なる場合は認証方式の選択肢を手がかりに読み替えてください。0.0.82での画面の変化は手順3.1にまとめました。
次回は、DifyのファイルストレージをS3に切り替える手順を解説します。
AWSを効率的に学習する方法
私が効率的にAWSを学習するために実施した方法は以下の通りです。
①最初に書籍（ハンズオンができる）を購入、座学でAWSの基礎を学習
②AWS資格試験を取得ための学習
※私の場合は①と②を合わせて2か月でソリューションアーキテクトを取得できました。
①AWS基礎学習
最初に購入した書籍は「Amazon Web Services 基礎からのネットワーク&サーバー構築」です。
Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂4版
この本では、AWSの基本サービスを利用したハンズオンを通じて、AWSの基礎を学習することができます。
また、タイトル通りAWSのネットワークやインフラに関しても網羅しているため、もともとインフラ系の技術者ではない人たちにとっても分かりやすい内容だと思います。
とりあえずAWS上にサーバーを設定して開発を行うための準備までするには最良の一冊です。
Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂4版
②AWS資格取得
AWSの基礎をある程度学習することができたら、次はAWS資格を取得しましょう。まずはAWSソリューションアーキテクトを目指しましょう。
資格勉強のための問題集をひたすら解きながら、AWSの知識を積み重ねて習得していきましょう！
苦行ではありますが、この問題集を3周ほどすればAWS用語や構成に関しても習得できているはずです。
独学だと手が止まってしまう場合は、ササエル のようなインフラエンジニア向けのオンラインスクールを使う手もあります。ネットワークやサーバーの分野に絞ったカリキュラムなので、業務でインフラを触る人が学び直すのにも使えます。
コメント