![[アップデート] Bedrock Managed Knowledge BaseのユーザーマネージドセットアップでConfluenceをつないでみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e3065182082062711612153bbdcf1d96/c04359de689df2f56eb066576ab63fb5/amazon-bedrock?w=3840&fm=webp)
[アップデート] Bedrock Managed Knowledge BaseのユーザーマネージドセットアップでConfluenceをつないでみた
はじめに
こんにちは、スーパーマーケットが大好きなコンサルティング部の神野です。
2026年9月4日のアップデートで、Amazon Bedrock Managed Knowledge Base に SharePoint・OneDrive・Confluence 向けの「ユーザーマネージドセットアップ（3LO）」が追加されました！
何が・・・便利になったのでしょう！気になりますね！
今回はConfluenceを対象に、検証用ページの取り込みから検索までを試してみました！
誰が何を許可するのか
まずこの3LOがどういった仕組みか理解したいですよね。
接続時の認可と、文書を取り込んで検索するまでの流れを図に整理しました！
実線が取り込みと検索、破線が認可とトークンのやり取りです。
まず、データソースの登録作業を行う人がConfluenceへサインインします。そのアカウントで接続を許可すると、Managed Knowledge Baseが読み取りに使うリフレッシュトークンが発行され、AWSアカウント内に自動作成されるSecrets Managerのシークレットへ保存されます。
このシークレットを使って、Confluenceの情報をManaged Knowledge Baseが同期をとって検索が可能になります！
接続の認可と検索時の権限は別もの
ただ気をつけたいのが、この接続方式が文書単位のアクセス制御（ACL）に対応していない点です。そのため、ナレッジベースへの検索権限を持つユーザーは、取り込まれたすべての文書を横断して検索できます。
Confluenceを直接開くときはConfluence側で権限が判定されますが、ナレッジベースの検索ではナレッジベース側の権限だけで判定されます。閲覧制限のあるページを取り込むと、その内容が他の利用者にも参照可能です。検索を使う全員に公開してよい文書を専用スペースにまとめ、そこから同期するのが安全に思えますね・・・！
利用者ごとに絞りたいならBasic認証
仮に利用者ごとに権限を絞りたい場合はどうでしょうか？
この場合は、認証方式を Basic認証 にして、データソース作成時にACLを有効化します。
ただ、これは認可ではなくフィルタリングで、ナレッジベース側では利用者の認証を行わず、アプリから渡されたメールアドレスをもとに検索結果を絞り込みます。手前の認証やそもそも検索の許可を与えるかはアプリ側でカバーしましょう！
これは同期時に取り込んだACLで候補を絞り、そのうえでIDをもとにConfluenceに現在の権限を問い合わせる作りとなっています。
長々と話していてあれですが今回はこの仕組みを使えません！
話は切り替えて、さっそく3LOによるセットアップを試していきましょう！
前提
Managed Knowledge Base そのものの作成や検索の流れは、リリース時に試した記事も参考にしてみてください。
今回の検証環境はこちらです。
| 項目 | 値 |
|---|---|
| AWSリージョン | バージニア北部（us-east-1） |
| データソース | Confluence Cloud |
| 認証方式 | Sign in with your account（3LO） |
| 検証用スペースのキー | MFS |
スペースキーは、Confluenceのスペースに付く短い識別子です。スペースのURL（/wiki/spaces/MFS）に出てくる部分ですね。
検証用スペースには、初期状態で入っていたサンプルページ4件に、次の内容の簡単な検証用ページを1件加えた計5件を用意しました。
サービス名やメールアドレスはもちろんダミーです。
Harbor Demo サポート窓口
検証識別子：MKB-CONFLUENCE-20260917
サポート受付時間：平日09:00〜17:00（日本時間）
問い合わせ先：support@example.com
ユーザーマネージドセットアップで接続する
まずはナレッジベースを作って準備していきましょう！
ナレッジベースを作る
Amazon Bedrock コンソールの左メニューから「構築」→「ナレッジベース」を開き、「マネージド KB を作成」を選択します。
埋め込みモデルの設定は Managed のまま進めました。
データソースにConfluence Cloudを選ぶ
続いてデータソースタイプを選びます。
一覧には Confluence Data Center も並んでいますが、3LO で接続できるのは Confluence Cloud のほうです。
認証方式を選ぶ
「ソース」に接続先の Confluence URL を入力したら、認証の設定に進みます。
項目名は「Authentication grant type」で、選択肢は2つです。
| 画面上のラベル | 説明 |
|---|---|
| Sign in with your account (3LO) | 既存の認可シークレットを使うか、サインインして新しく作る |
| Use service credentials (2LO) | サインインなしでクライアント認証情報を使う。選ぶとさらにBasic認証とOAuth 2.0 認証を選べる |
3LO を選ぶと、その場で ACL に関する警告が表示されます。先ほど触れた仕様が、画面上でもはっきりアナウンスされる形ですね。
Document-level ACLs (Access Control Lists) are not supported with 3LO authentication. All content visible to the 3LO credential provider will be indexed and available via retrieve APIs.
「Prefix for generated secret」には、自動生成されるシークレット名の接頭辞を指定できます。
confluence-3lo-demo と入力したら19文字で弾かれたので、conf-3lo-demo に短縮して進めました！
Prefix must be 16 characters or fewer.
マックスでも16文字までなので注意が必要ですね。
Confluenceへのアクセスを許可する
「Sign In to Confluence」を押すと、Atlassian の同意画面に遷移します。
表示されるアプリ名は Amazon Bedrock Prod IAD です。
AWS 側が用意した OAuth アプリを使うため、自分でアプリを登録する必要はありません！要求される権限はすべて View 系です。ただし、アクセス範囲には注意書きが添えられています。
Important: By granting access, you allow this app to act on your behalf across all Atlassian sites where you have access and this app is installed.
注意書きに記載があるように、認可の範囲は対象のサイトだけでなく、そのユーザーがアクセスでき、かつ本アプリが導入されている Atlassian サイト全体に及びます。業務アカウントでサインインする場合は、影響範囲を確かめておいたほうが良さそうです。
そのため、どのアカウントで連携するかが実質的なアクセス制御の境界になります。Confluence の管理者アカウントでサインインすると、社内の全スペースが検索対象に入ってしまうため注意が必要です！
認可されるとシークレットが自動で作られる
同意画面で Accept を選択すると、コンソールに戻ってシークレットが自動的に作成されます。
Authorization complete
AWS secret bedrock-managedkb-oauth/conf-3lo-demo/CONFLUENCEV3/f1706568-... created and is available for reuse across other data sources of same type.
生成されたシークレット名は次の形式でした！
bedrock-managedkb-oauth/conf-3lo-demo/CONFLUENCEV3/f1706568-e2a2-44a9-bf32-de6c33f84281
ちなみに画面下部の「Sign in with a different account」で別のアカウントに切り替えると、現在の認可が解除されて既存のシークレットが上書きされます。
取り込み範囲を絞る
「同期スコープ」でクロール対象を指定すると、取り込む範囲を絞り込めます！
初期設定では、ページ・ページの添付ファイル・ブログ・ブログの添付ファイルの4つにチェックが入り、アーカイブ済みページ、アーカイブスペース、個人用スペースは除外されています。
対象を特定のスペースに絞る場合は「エンティティ URL」を使います。ウィザードにスペースキーを指定する欄はなく、次のようなスペースのURLを登録する形です。
https://example.atlassian.net/wiki/spaces/MFS
このスペースのURLはAPIの inclusionSpaceUrls でも試せるのですが、ページのURLや無効な文字列を渡すとエラーにはならず、0件のまま同期が成功扱いで終わりました。打ち間違えても気づけないので、スキャン件数は必ず確認しておきたいところです。
なお、APIなら inclusionSpaceKeys にスペースキーを直接指定できます。コンソールもひととおり探してみたのですが、キーを入れられる欄は見当たりませんでした・・・（もし見つけた方いたら教えてください！）
キーで管理したいならAPI側で登録する形となります。APIへのリクエスト例も折りたたみで載せておきますね。
APIからデータソースを作る場合の設定例
CreateDataSource に渡す dataSourceConfiguration です。authType の MANAGED_OAUTH2 が3LOであることを表していて、自分でOAuthアプリを登録する方式では OAUTH2 になります。secretArn には認可で自動生成されたシークレットを指定可能で、すでにシークレットがある場合は認可をやり直さずに使い回すこともできます。
{
"type": "MANAGED_KNOWLEDGE_BASE_CONNECTOR",
"managedKnowledgeBaseConnectorConfiguration": {
"connectorParameters": {
"type": "CONFLUENCE",
"version": "1",
"aclEnabled": false,
"connectionConfiguration": {
"type": "SAAS",
"authType": "MANAGED_OAUTH2",
"hostUrl": "https://example.atlassian.net",
"secretArn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:REPLACE_WITH_GENERATED_SECRET"
},
"dataEntityConfiguration": {
"crawlPage": true,
"crawlBlog": false,
"crawlPageAttachment": false,
"crawlBlogAttachment": false
},
"filterConfiguration": {
"inclusionSpaceKeys": ["MFS"]
}
}
}
}
aws bedrock-agent create-data-source \
--name confluence-3lo-demo \
--knowledge-base-id <knowledge-base-id> \
--data-source-configuration file://confluence-managed-connector.json
作られたデータソースを確認する
これで作成が一通り進んだので、作られたデータソースを確認してみます。
認証方式が「Sign in with your account (3LO)」、ACL のクロールは「無効化済み」、「自動シークレットローテーション」も無効と表示されています！
同期を実行すると、2〜3分ほどで完了しました。
{
"status": "COMPLETE",
"statistics": {
"numberOfDocumentsScanned": 5,
"numberOfNewDocumentsIndexed": 5,
"numberOfDocumentsFailed": 0
}
}
取り込まれた5件はサンプルページ4件とテストページ1件で、同じサイト内の個人スペースはチェックを入れていないため除外されていました！
補足 実行ロールを自分で作るなら PutSecretValue に注意
CLIなどでサービスロールを自分で用意する場合は引っかかるポイントが1つあります。
ドキュメントに載っているConfluence用のサンプルポリシーは secretsmanager:GetSecretValue のみで、PutSecretValue には「OAuth 2.0 認証でリフレッシュトークンを使う場合に必要」という注記が付いています。3LOでもリフレッシュトークンを使うため、この権限が必要です。気をつけてくださいね。
GetSecretValue だけを付けて試したところ、ウィザードを完了した直後にこのメッセージが出ました。
データソースの作成は完了していますが、自動同期の開始に失敗しています。手動で同期を実行しても、1分ほどで FAILED になりました。
The customer data-source role is missing permission to access AWS Secrets Manager.
Mitigation: Add the required Secrets Manager permissions
(secretsmanager:GetSecretValue, secretsmanager:PutSecretValue)
to the data-source role and retry the sync.
エラーに必要なアクションが明記されているので、原因はすぐに分かります。権限を付与してあげれば問題なく同期できるようになります。
検索して、更新の反映も確かめる
同期が取れたので、Retrieve APIで検索します！
「MKB-CONFLUENCE-20260917 のサポート受付時間は？」というクエリで、1位に次のチャンクが返ってきました。
score: 0.8048
検証識別子：MKB-CONFLUENCE-20260917
サポート受付時間：平日09:00〜17:00（日本時間）
問い合わせ先：support@example.com
location: https://example.atlassian.net/wiki/spaces/MFS/pages/5111809/Harbor+Demo
しっかりと意図通り検索結果が返ってきましたね！
続いて更新の検知です。Confluence側で受付時間を「平日10:00〜18:00」に書き換えてから再同期しました。
{
"status": "COMPLETE",
"statistics": {
"numberOfDocumentsScanned": 5,
"numberOfNewDocumentsIndexed": 0,
"numberOfModifiedDocumentsIndexed": 1,
"numberOfDocumentsFailed": 0
}
}
スキャンされた5件のうち、編集した1件が更新としてカウントされました。
同じクエリで検索し直すと、受付時間の変更もしっかり反映されています。
score: 0.8057
サポート受付時間：平日10:00〜18:00（日本時間）
定期的に最新化したい場合は、同期スケジュールを設定しておくとよさそうです。
直近のアップデートで自動化もできるようになりましたもんね！
結局これは何を3LOと呼んでいるのか
ここまで動かしてみて気になったのが、3LOと銘打たれている割に、振る舞いがサービスアカウントとあまり変わらないことです・・・！
どの場面で利用者が介在するのかを整理してみます。
認可のフェーズは確かに3LOですね。セットアップを行うユーザーが個人のAtlassianアカウントでサインインし、自身に見えているリソースへのアクセスを許可します。
一方で、その後の同期処理には人が介在しません。Secrets Managerに保管されたトークンをManaged Knowledge Baseが読み込み、Confluenceから文書を取得します。検索の際も、誰がクエリを実行しても同じ文書が返ってきます。資格情報の取得手順こそ3LOですが、取得後のトークンの扱われ方はサービスアカウントと変わらない気がします。
AgentCore Identityのようにユーザーごとのトークンを保持して本人としてリクエストを中継する仕組みと比べると、同じ「3LO」でも性質はかなり違い、あくまで同期をする上で簡単にしたよと理解するとわかりやすいですね！
おわりに
Confluenceのユーザーマネージドセットアップを試してみました！検索する人を見る3LOではなく、接続した人の権限で同期を簡単にするための仕組みと捉えておくとよさそうです！管理者のようなユーザーがサクッと自分の権限で同期したい際には便利そうですね！
本記事が少しでも参考になりましたら幸いです。
最後までご覧いただきありがとうございました！
補足 SharePointとOneDriveはどうなのか
ちなみに、今回のアップデートではSharePointとOneDriveにも同じ方式が追加されています。公式ドキュメントをもとに、Confluenceとの差分を整理しました。
シークレットの命名規則や、実行ロールに GetSecretValue と PutSecretValue の両方が要ること、authType に MANAGED_OAUTH2 を指定すること、ACL非対応である点など、Confluenceとの共通点は多いです。ACLが必要なら別の認証方式を使う案内になっているのも、ConfluenceでBasic認証を案内していた流れと似通っています。
| Confluence | SharePoint / OneDrive | |
|---|---|---|
| 承認する人 | Atlassianのサイト管理者 | Microsoft 365の管理者 |
| 適用範囲 | サイトごと | テナント全体に一括 |
| 事前承認の手段 | 管理者が自分で接続を作る | 同意画面で「組織を代表して同意する」にチェック、またはMicrosoft Entra管理センターから付与 |
こちらは管理者が一度テナント全体に同意しておけば、以後は各ユーザーが同意画面を経由せずに接続できます。テナント設定でサードパーティ製アプリへのユーザー同意を禁止している場合は、管理者の同意が必須になります。
要求される権限も確認してみると、Microsoft側はRead系の3〜4個といった形ですね。
| データソース | 要求される委任権限 |
|---|---|
| SharePoint | Sites.Read.All、User.Read、offline_access、AllSites.Read（SharePoint Online） |
| OneDrive | Files.Read.All、User.Read、offline_access |
