Bedrock Knowledge Base に 3LO、SharePoint・Confluence を管理者なしで繋ぐ

既存の接続は何も変わらない。変わるのは、これから SharePoint・OneDrive・Confluence を Amazon Bedrock Managed Knowledge Base に繋ごうとしている人の手順だ。AWS は 2026年9月4日付の What’s New で、この三つのデータソースに user-managed setup（3LO） を追加したと告知した。第三者サービス側で認証情報を発行してもらう工程が、自分のアカウントでのサインインに置き換わる。

影響を受けるのは、SharePoint のドキュメントや Confluence の wiki を根拠にしたアシスタントを試したいのに、それらの管理者権限を持っていないチームだ。告知はまさにその状況を、時間がかかり、管理者権限のないユーザーには手が届かないものだったと説明している。すでにサービスアカウントで本番接続を組んでいるなら、告知の範囲では移行を促す記述はない。

管理者に頼んでいたのは認証情報の発行だけ

従来の手順では、SharePoint・OneDrive・Confluence それぞれの側で 2LO の認証情報を生成する必要があった。告知は従来方式を 2LO と呼び、別の箇所ではサービスアカウント認証とも呼んでいる。発行には対象システムの管理者レベルの権限が要るため、開発者は IT 管理者に依頼を出し、認証情報が返ってくるまでナレッジベースの設定が止まっていた。

user-managed setup では、開発者が自分の既存アカウントで対象サービスにサインインし、認証の処理は Amazon Bedrock Managed Knowledge Base 側が引き受ける。数分でデータソースの設定を終えられる、というのが告知の説明だ。数分という表現は告知の言葉であって、環境ごとの実測ではない。

3LO と 2LO という略語を、告知は展開していない。言えるのは、2LO がサービス側で発行する認証情報を、3LO がユーザー自身のサインインを指して使われている、という対応関係までだ。

二つの方式は置き換えではなく並存

新方式は既存のサービスアカウント認証を補完するものと位置づけられている。本番ワークロード向けには、プログラムから扱えるエンタープライズ向けの選択肢が残ると告知は明言する。二つの方式の性格は次のように整理できる。

方式	認証情報を用意するのは誰か	告知が示す用途
サービスアカウント認証（告知では 2LO）	第三者サービス側で発行する。管理者レベルの権限が要る	本番ワークロード。プログラムから扱えるエンタープライズ向けの選択肢
user-managed setup（告知では 3LO）	開発者自身が既存アカウントでサインインする。認証処理は Bedrock 側	試作。IT 管理者との調整なしに数分で設定できるとされる

出典：AWS What’s New「Amazon Bedrock Managed Knowledge Base introduces user-managed setup for SharePoint, OneDrive, and Confluence data sources」（2026年9月4日）

表の右列が示すとおり、告知は二つの方式を速さと本番向けとで分けている。ただし、user-managed setup を本番で使ってはいけないとは書いていないし、サービスアカウント方式が試作に向かないとも書いていない。用途の線引きは告知の推奨であって、技術的な制約として提示されているわけではない。

告知に書かれていないこと

本番に持ち込む前に、告知だけでは判断できない点が残る。

サインインしたユーザーの認証状態がどれだけ持つかは、その筆頭だ。パスワード変更や退職で失効するのか、定期的に再サインインを求められるのか、告知には記述がなく、ユーザー個人のアカウントに紐づく以上、本番運用ではまずここを確かめることになる。

同期される文書の範囲も同じだ。user-managed setup で繋いだナレッジベースが読めるのは、サインインしたユーザーに閲覧権限のある文書だけなのか、サービス全体なのか、告知は触れていない。権限の異なるメンバーが同じナレッジベースを共有する設計なら、ここが決まらないと構成も決められない。

設定の経路については、告知はサービスアカウント方式だけを、プログラムから扱える選択肢だと形容している。裏を返せば user-managed setup はコンソールからのサインインを前提にしている可能性があるが、これは言い回しからの推測で、API や IaC から扱えるかどうかは告知に書かれていない。

既存のデータソースに後から適用できるかも、告知からは読み取れない。告知は新しくデータソースを設定する場面として説明しており、すでにサービスアカウントで繋いだデータソースの認証方式を切り替えられるかには触れていない。対応リージョンと料金への影響も、告知には出てこない。

試作は 3LO、本番はサービスアカウントのまま

立場ごとの動きは短い。

• サービスアカウントで接続済みなら、告知の範囲で変えるものはない。告知は既存方式を残すと明言している。
• 管理者権限がなく試作が止まっていたなら、user-managed setup で自分のアカウントからサインインして繋ぐ。告知は手順の参照先として、Amazon Bedrock User Guide の SharePoint・OneDrive・Confluence 各ページを挙げている。
• 試作を本番に昇格させるなら、認証の失効条件と同期範囲を確かめたうえで、告知が本番向けとするサービスアカウント方式へ切り替える前提で設計しておく。

user-managed setup が減らすのは待ち時間であって、本番の設計判断ではない。管理者への依頼が消えた分、失効条件と同期範囲の確認は開発者側の仕事として残る。本番に載せたエージェントの台帳管理は別の話題で、AWS Agent Registry の記事で扱っている。