SharePoint エージェントの複数サイト横断｜20 ソースの上限と設計

はじめに

SharePoint エージェントを検証してみたものの、実際の社内環境に当てはめようとすると別の課題が出てきます。部門ごとにサイトが作られ、文書が分散している状態です。「技術資料は情シスのサイト、規程類は総務のサイト、手続きは人事のサイト」といった具合に、10 や 20 では収まらない数のサイトが並んでいる組織も珍しくありません。

この状態で「社内の情報をまとめて検索したい」という要望に応えるには、複数のサイトを 1 つのエージェントから横断させる必要があります。本記事では、既存の SharePoint サイトへ後からエージェントを組み込み、複数サイトを横断させる手順と、その過程で判明した制約を扱います。

前提として、従量課金の設定とエージェントの作成が済んでいる環境を想定しています。設定手順そのものは別記事で扱っているため、本記事では既存環境への組み込みに絞ります。

結論を先に示します。作成済みのエージェントに後からサイトを追加することは可能で、複数サイトをまたいだ回答も得られます。権限についても SharePoint の設定がそのまま継承されるため、アクセス権のないサイトの情報は回答から除外されます。

一方で、ハブサイトをソースとして指定することはできませんでした。 ハブに関連付けたサイトが自動的に対象になることもありません。サイトは 1 つずつ指定する必要があり、上限は 20 です。サイトが乱立している環境では、この上限が設計上の制約として効いてきます。

もう 1 点、作成しただけでは利用者のもとにエージェントが現れません。 Copilot ライセンスを持たない利用者の画面には自動で並ばないため、共有リンクを配布する仕組みが必要になります。

エージェントの配置場所と参照先の関係

複数サイトの横断を考える前に、エージェントの構造を整理しておきます。ここを誤解していると、設計を間違えます。

.agent ファイルの置き場所と参照先は別

エージェントは .agent という拡張子のファイルとして SharePoint 上に保存されます。ドキュメントライブラリから作成した場合、そのライブラリに保存されます。

ここで混同しやすいのが、保存場所と参照先は別物という点です。

つまり、情報システム部門のサイトにエージェントを 1 つ置き、そこから総務や人事のサイトを参照させる、という構成が可能です。エージェントを各サイトに配置して回る必要はありません。

作成画面の右下には「エージェント ファイルの場所」という表示があり、保存先のライブラリが示されます。この表示があること自体が、保存場所と参照先を区別する設計であることを表しています。

利用者がアクセスするのは 1 つのエージェント

この構造から導かれる設計は、次のとおりです。

情報システム部門のサイト（エージェントの保管場所）
    └─ 社内ナレッジアシスタント.agent
            ├─ ソース 1: 情報システム部門のサイト
            ├─ ソース 2: 総務のサイト
            ├─ ソース 3: 人事のサイト
            └─ ... 最大 20

利用者はこのエージェント 1 つにアクセスすればよく、サイトを順に回る必要はありません。「この情報は総務のサイトだから、まず総務のサイトを開いて…」という手間が発生しない構成です。

ここは実務上、重要な意味を持ちます。ナレッジが分散していること自体が課題なのに、利用者に「どのサイトのエージェントに聞くか」を判断させると、課題が形を変えて残るだけになります。入り口を 1 つにできることが、この構造の価値です。

ソース 20 の上限が設計を決める

一方で、上限があります。エージェントの編集画面には次の記載があります。

サイト、フォルダー、ファイル、ページ、またはリストからソースを 20 まで選択します。

サイト単位でカウントして 20 が上限です。サイトが 30 も 50 もある環境では、すべてを 1 つのエージェントに含めることはできません。

粒度を選べる点は柔軟です。サイト全体を指定することも、特定のライブラリやファイルだけを指定することもできます。ただしどの粒度で指定しても、1 つとしてカウントされます。

たとえば「総務サイトの規程ライブラリだけ」を指定すれば、総務サイトの他のコンテンツは対象外になります。参照範囲を絞ることは、回答精度の向上にもつながります。 不要な文書が候補に入らなくなるためです。

上限への対処は本記事の後半で扱いますが、先に方向性だけ示しておきます。選択肢は「サイトを選定して絞る」「エージェントを用途別に分ける」「ナレッジを集約する」の 3 つです。いずれも一長一短があり、組織の状況によって選択が変わります。

既存サイトをソースに追加する手順

すでに稼働しているエージェントに、後からサイトを追加します。作り直す必要はありません。

作成済みエージェントの編集画面を開く

エージェントを保管しているサイトのドキュメントライブラリを開き、.agent ファイルを選択します。

1. .agent ファイルをクリックしてチャット画面を開く
2. 画面上部の「エージェントを編集」を選択

「エージェントを編集」という表示に切り替わり、「概要」「ソース」「動作」の 3 タブが並びます。作成時と同じ画面構成です。

この編集操作には、エージェントを保管しているサイトの編集権限が必要です。 また、エージェントの作成と同様に Microsoft 365 Copilot ライセンスが求められます。利用するだけであればライセンスは不要ですが、設定を変更する側には必要になります。

検索または URL でサイトを追加する

「ソース」タブを開くと、現在指定されているソースの一覧が表示されます。その上に「ソースを追加」という入力欄があります。

追加の方法は 2 つです。

検索ボックスにサイト名の一部を入力すると、候補が表示されます。目的のサイトを選択すると、一覧へ追加されます。

追加できるのは、操作しているユーザーがアクセス権を持つサイトに限られます。 権限のないサイトは検索結果に現れません。エージェントの管理者が、参照させたいすべてのサイトへアクセスできる必要があります。

追加が済んだら「保存して閉じる」を選択します。この時点でエージェントの設定が更新され、次回以降の質問から新しいソースが対象になります。

なお、「名前を付けて保存」を選ぶと別のエージェントとして複製されます。既存のエージェントを更新したい場合は「保存して閉じる」です。

サイト・ライブラリ・ファイルの粒度を使い分ける

ソースの指定は、サイト全体だけでなく細かい粒度でも可能です。

一覧に表示されたサイトの左側にある展開マークを開くと、配下のライブラリが表示されます。ここから特定のライブラリだけを選ぶこともできます。

どの粒度で指定しても、ソース 1 つとしてカウントされます。 そのため、上限が気になる場合はサイト単位で指定するほうが効率的です。

一方で、精度を優先するなら絞り込むほうが有利です。サイト全体を指定すると、作業中の下書きや過去の版も候補に入ります。回答の根拠として不適切な文書が混じるリスクを避けたい場合は、ライブラリ単位での指定を検討する価値があります。

横断検索の動作と権限の扱い

ソースを追加したら、実際の挙動を確認します。ここでは 3 サイト（技術・総務・人事）を対象にした構成で検証しました。

複数サイトにまたがる質問での挙動

検証にあたり、意図的に情報を分割した文書を配置しています。

3 つの文書には共通して拠点コードが記載されていますが、それ以外の情報は重複していません。 この状態で、3 領域すべてにまたがる質問を行います。

旭川営業所について、ネットワーク方式、施設の執務席数、
今後の要員計画を教えてください

管理者アカウント（3 サイトすべてにアクセス権あり）で実行した結果、3 項目すべてに回答が得られました。 回答は見出しごとに整理され、それぞれに引用元の脚注が付きます。

各項目の参照元は次のとおりでした。

1 つの質問に対して、3 つのサイトから情報を集めて回答を構成しています。 利用者はサイトの所在を意識する必要がありません。

権限のないサイトの情報は回答から欠落する

同じ質問を、権限の異なるユーザーで実行します。

検証用のユーザー A は、技術サイトと総務サイトには閲覧権限を持ちますが、人事サイトには権限がありません。 Copilot ライセンスも持たず、従量課金の対象グループに所属している状態です。

結果は次のとおりでした。

権限のあるサイトの情報だけが回答され、人事サイトの情報は欠落しました。 サイト単位の権限が、そのまま継承されていることになります。

注目したいのは、回答の作り方です。要員計画について「確認できませんでした」と述べたうえで、参照できた範囲の情報は提示しています。 「小規模拠点であり、在籍人数の目安が 50 名未満であることのみ記載されている」といった具合に、探索した事実と限界が伝わる回答になっていました。

権限継承の詳細な挙動については、単一サイト内での検証を別記事で扱っています。ファイル単位で権限を絞った場合の挙動もそちらで確認できます。

同じ質問でも人によって回答が変わる

この結果は、運用設計に直結します。

同じエージェントに同じ質問をしても、実行するユーザーによって回答の内容が変わります。 しかも、質問全体が拒否されるのではなく、一部だけが欠落するという形で現れます。

これは技術的には正しい挙動です。しかし利用者の視点では、次の問題が生じます。

• 情報が存在しないのか、自分に権限がないのか区別できない
• 他の人には回答が得られたのに、自分には得られないという状況が起きる
• 「システムの不具合ではないか」という問い合わせにつながる

エージェントは、権限がないことを明示的には伝えません。 「見つかりませんでした」という表現になるため、利用者は文書が存在しないと解釈します。

対策としては、利用案内に一文を加えておくことが有効です。

回答はご自身がアクセス権を持つ資料の範囲に限られます。必要な情報が得られない場合は、該当資料の管理部門へアクセス権をご確認ください。

この一文があるだけで、問い合わせの性質が変わります。「使えない」ではなく「権限を確認したい」という形になり、対応する側も判断しやすくなります。

なお、この挙動はセキュリティ上は望ましい設計です。 権限のない情報が漏れないだけでなく、その文書の存在自体も伝わりません。予算額や人事情報のような機密性の高い文書を扱う場合、この性質は必須の要件になります。

ハブサイトは使えるのか

サイトが多い環境では、「ハブサイトでまとめれば、20 の上限を回避できるのではないか」という発想が出てきます。SharePoint には複数のサイトを束ねるハブサイトという仕組みがあるため、自然な考え方です。

結論から述べると、この方法は使えませんでした。 2 つの観点で検証しています。

ハブサイトをソースに指定できるか

まず、ハブサイトそのものをソースとして指定できるかを確認します。

検証環境では、技術サイトをハブサイトとして登録し、総務サイトと人事サイトをそのハブへ関連付けました。SharePoint 管理センターの「アクティブなサイト」から、対象サイトを選んで「ハブ」>「ハブ サイトとして登録」で設定できます。

登録時には「サイトをこのハブと関連付けることができるユーザー」という入力欄がありますが、これはハブへの関連付け操作を委譲する相手を指定するものです。空欄の場合、SharePoint 管理者とグローバル管理者のみが操作できます。エージェントの動作とは関係しません。

関連付けが完了すると、各サイトの上部にハブのナビゲーションバーが表示されます。この状態でエージェントの編集画面を開き、ソースの検索ボックスにハブ名を入力しました。

ハブサイトは検索結果に現れませんでした。 ソースとして選択できるのは個別のサイトのみで、ハブという単位は扱えません。

ハブ配下のサイトは自動的に含まれるか

次に、別の可能性を確認します。ハブという単位で指定できなくても、ハブの親サイトを指定したときに配下も暗黙的に含まれるのであれば、実質的に同じ効果が得られます。

検証手順は次のとおりです。

1. エージェントのソースから、総務サイトと人事サイトを削除
2. ハブの親サイトである技術サイトのみを残す
3. 3 領域にまたがる質問を、管理者アカウントで実行

管理者は 3 サイトすべてにアクセス権を持つため、権限による除外は発生しない条件です。

結果は次のとおりでした。

ハブに関連付けたサイトは、自動的には対象になりません。 アクセス権があるにもかかわらず参照されていないため、権限ではなくソース指定の問題であることが確定します。

検証結果から言えること

2 つの検証結果を整理します。

サイトは 1 つずつ指定する必要があり、上限は 20 です。 ハブサイトによる回避策は存在しません。

エージェントのソース指定にハブという概念が実装されていないことから、配下を辿る動作も期待できないという構造です。ハブサイトはナビゲーションと検索スコープを束ねる仕組みであり、エージェントのナレッジソースとは別系統で管理されていると考えられます。

導入計画を立てる際は、この上限を前提に設計する必要があります。「まずハブでまとめてから」という手順を組み込んでいると、その工程が無駄になります。

なお、ハブサイトの登録自体はエージェントの動作に悪影響を与えません。ナビゲーションの統一など別の目的で使う分には問題なく、あくまで「エージェントのソース管理には使えない」という話です。

エージェントを利用者へ届ける

エージェントを作成し、複数サイトを横断できる状態にしても、それだけでは運用が始まりません。利用者がたどり着けなければ、存在しないのと同じです。

ここは見落とされやすい工程ですが、検証したところ想定と異なる挙動がありました。

作成しただけでは利用者に見えない

管理者アカウントで Microsoft 365 Copilot アプリを開くと、左側のメニューに「エージェント」というセクションがあり、作成したエージェントが並びます。ここから選択すれば、全画面でエージェントを利用できます。

SharePoint のサイドパネルと比べて表示領域が広く、日常的に使うのであればこちらが適しています。

ところが、Copilot ライセンスを持たない利用者の画面には、このエージェントが並びません。 検証用のユーザー A で同じ画面を開いたところ、左メニューの「エージェント」セクションに該当するエージェントは表示されませんでした。「その他のエージェント」を開いても見つかりません。

つまり、エージェントを作成しただけでは、利用者は存在に気づけません。 管理者の画面では並んでいるため、「作ったから使ってください」と案内してしまいがちですが、利用者側には現れていないという状態が起こります。

共有リンクの取得と配布

利用者へ届ける確実な方法は、共有リンクの配布です。

1. エージェントを保管しているライブラリで .agent ファイルを選択
2. 「リンクのコピー」または「共有」を選択
3. 取得した URL を利用者へ配布

このリンクを開くと、権限を持つ利用者であればエージェントのチャット画面が表示されます。

エージェントの作成完了時に表示されるダイアログにも「エージェントの共有」というボタンがあり、その場で共有設定へ進むこともできます。

エージェントはファイルであるため、共有の仕組みも通常のファイルと同じです。 特別な配布機能があるわけではなく、SharePoint の共有機能をそのまま使います。

ライセンスの有無で表示が変わる

共有リンクからアクセスした場合、管理者と利用者では表示される画面が異なります。

利用者側の画面は、SharePoint のファイルビューアーです。上部にはダウンロードやお気に入りといったファイル操作のアイコンが並び、タイトルもファイル名で表示されます。

機能面での制約は確認できませんでした。 全画面で表示され、質問の入力、回答の表示、チャット履歴の参照はいずれも利用できます。表示領域も十分に広く、実用上の支障はありません。

ただし、説明資料を作る際は注意が必要です。 管理者が自分の画面をキャプチャして案内すると、利用者は別の画面に遭遇します。「画面が違う」という問い合わせを避けるため、案内資料には利用者が実際に見る画面を掲載することをおすすめします。

配布先の選択肢

リンクをどこへ置くかは、組織の運用に合わせて選びます。

社内ポータルへの掲載を軸にするのが確実です。 「あのリンクどこだっけ」という状態を避けられます。

エージェントを 1 つに集約する設計と、入り口を 1 箇所に固定する運用は対になっています。複数サイトを横断できるように構成しても、利用者が入り口を探し回るのでは効果が半減します。設計と導線をセットで考えることが、運用を軌道に乗せる条件になります。

20 ソース上限への対処

ハブサイトによる回避策が使えない以上、20 という上限は設計上の与件になります。サイトが乱立している環境では、何らかの選択が必要です。

万能な解はありません。組織の状況に応じて、次の 3 つから選ぶことになります。

サイトを選定して絞り込む

最も素直な方法です。全社的に価値のあるナレッジを持つサイトを 20 以内に選び、そこだけを対象にします。

選定の基準としては、次の観点が考えられます。

この方法には副次的な効果があります。 参照先を絞るほど回答の精度が上がる傾向があるため、闇雲に全サイトを含めるより結果が良くなる可能性があります。

一方で、選定から漏れたサイトの情報は検索できません。「なぜうちの部門のサイトは対象外なのか」という調整が発生する可能性はあります。選定基準を先に決めて公開しておくと、判断の説明がしやすくなります。

エージェントを用途別に分ける

1 つのエージェントに収まらない場合、複数のエージェントを作る方法があります。それぞれが 20 ソースまで持てるため、実質的な上限が拡張されます。

分け方の例です。

ただし、この方法には注意点があります。 利用者から見ると「どのエージェントに聞けばよいか」という判断が発生します。

もともとの課題は「情報がどこにあるか分からない」ことでした。エージェントを分けすぎると、「どのエージェントに聞くか分からない」という形で課題が残ります。 入り口が増えるだけで、本質的な解決になっていない状態です。

分けるのであれば、次の条件を満たす形が望ましいと考えます。

• 利用者が所属や業務から自然に判断できる区分にする
• 数は 3 つ程度までに抑える
• 各エージェントの対象範囲を、社内ポータルに明記する

ナレッジを集約する

3 つ目は、サイト構成そのものを見直す方法です。乱立したサイトをそのまま対象にするのではなく、正式なナレッジを集約するサイトを新たに設けます。

遠回りに見えますが、属人化の解消という目的に照らすと、これが本筋です。

サイトが乱立している状態は、多くの場合「どこに置いてもよい」という運用の結果です。この状態のまま検索できるようにすると、その運用が固定化されます。文書がどこにあっても検索で見つかるため、集約する動機がなくなるからです。

集約の進め方としては、次の順序が考えられます。

1. 正式ナレッジの定義を決める（承認された文書、現行版であること等）
2. 集約先のサイトとライブラリ構成を設計する
3. オーナーと更新責任者を明確にする
4. 各部門から該当する文書を移管する
5. 集約先をエージェントのソースに指定する

工数はかかりますが、この工程自体が形式知化の実務です。エージェントの導入はその後の話になります。

導入前に権限を棚卸しする理由

どの方法を選ぶ場合でも、避けて通れない工程があります。権限の棚卸しです。

前述のとおり、エージェントは SharePoint の権限をそのまま継承します。権限のない情報は漏れません。 これはセキュリティ上、望ましい設計です。

ただし、逆の見方も必要です。権限が緩く設定されているサイトの文書は、すべて検索可能になります。

乱立したサイトは、往々にして次の状態にあります。

• 作成時の権限設定のまま放置されている
• 「全社員」に閲覧権限が付いている
• 異動者や退職者が権限を持ったままになっている

これまでは「どこにあるか分からない」ことが実質的な防御になっていました。横断検索を有効にすると、その防御が失われます。 従来は誰も見つけられなかった文書が、質問 1 つで到達可能になります。

したがって、進め方としては次の順序が安全です。

1. 対象候補のサイトを洗い出す
2. 各サイトの権限を棚卸しする
3. 棚卸しが済んだサイトから順に、ソースへ追加する

「まず全サイトを対象にして、問題があれば外す」という進め方は避けたほうがよいと考えます。一度見えてしまった情報は、取り消せません。

まとめ

SharePoint エージェントは、作成済みの状態から後付けで複数サイトを横断させることができます。権限も SharePoint の設定がそのまま継承されるため、アクセス権のない情報が漏れることはありません。一方で、ハブサイトによるサイトのとりまとめは機能せず、ソース 20 という上限が設計上の制約として残ります。また、作成しただけでは利用者のもとにエージェントが現れないため、配布の仕組みを別途用意する必要があります。

• 作成済みエージェントへ後からサイトを追加可能
• 複数サイトにまたがる質問にも回答が得られる
• 権限のないサイトの情報は回答から欠落する
• 同じ質問でも実行するユーザーによって回答が変わる
• ハブサイトはソースに指定できず、配下も自動では含まれない
• ソースの上限は 20。サイト選定か分割か集約かの選択になる
• 利用者へは共有リンクの配布が必要

以上、最後までお読みいただきありがとうございました。