カテゴリ「Microsoft 365 Copilot」の15件の投稿 Feed

2025年11月26日 (水)

Adobestock_1529894649

Microsoft 365 Copilot の有償ライセンスと無償で使える Microsoft 365 Copilot Chat との違いが判らないという話をよく耳にします。

そもそも組織としてのナレッジマネージメントをビジネスリーダークラスがきちんと考えたことがあるかどうかという違いは一つ大きな壁としてあるでしょう。

Microsoft 365 Copilot では Microsoft 365 内に蓄積されている様々なコンテンツをもとに応答が生成できます。一方、無償の Microsoft 365 Copilot Chat で得られるのは原則は利用しているモデルが事前学習している範疇までの知識であり、たとえば GPT-5 では2024年9月までの情報しか学習していません。そのため、Copilot はその差を埋めて最新情報なども踏まえるために Bing 検索を使ってインターネット上に公開されている情報にアクセスします。アクセスできるのはあくまでも「公に公開されている」情報までです。しかし、Microsoft 365 Copilot ではMicrosoft 365 内に蓄積されている情報としてファイル、メール、チャットだけでなく、人とのつながり、情報の関連性など様々な付加情報も利用できるのです。

検索の変遷

Microsoft 365 Copilot とは何かについて改めて、「情報検索」をキーワードに説明してみようと思います。

クラウドになってから、キーワード検索は Microsoft Graph + Microsoft 独自AIとして発展してきました。検索に AI の力が添えられるようになったことは、Microsoft 365 管理センターも検索の構成メニューは「検索とインテリジェンス」という名称になっていることからも窺い知れます。

Microsoft Graph とはMicrosoft 365 内のあらゆるコンテンツにシームレスにつないでくれる仕組みです。もともと Microsoft Graph API という API がありますが、これは初期のころは Office 365 Unified API と呼ばれており、Outlook, Viva Engage (当時はYammer)、SharePoint, OneDrive, OneNote など Microsoft 365 内の個別のサービスやアプリにシームレスにアクセスできるようにするための仕組みとしてばらばらになりがちなAPIを統合したわけです。これが基盤となり Microsoft Graph へと発展していきました。 Microsoft 365 内のデータとデータ、ユーザーとデータの「関係性」をグラフ構造としてとらえる “Graph” の概念が導入され、APIの統一だけでなく Microsoft Graph へとつながっていきます。「ひと」と情報の関わりまで踏み込んで情報を得ることができる土台ができたわけです。

こうした基盤が整備されたことで、現在、Microsoft 365 の検索では SharePoint スタートページなどから Outlook, Teams, SharePoint など横断的に検索できるようにもなっていますし、以前は Microsoft Graph コネクターと呼ばれていて現在は Copilot コネクターに名称が変わっていますが、これを使えば、ファイルサーバーや 3rdパーティ製品(ServiceNow, JIRAクラウド、Googlドライブ, Box など) も Microsoft 365 から検索できるようになっています。

キーワード検索とMicrosoft Copilot 検索

従来の Microsoft 365 ではキーワード検索が主流でした。しかし、単なるキーワード検索だとどうしても「検索キーワード」の揺らぎが対応しにくいという課題があります。例えば、「ライオン」でも「百獣の王」でも意味は同じなのにキーワードとしては一致しないのでヒットしない。さらには言語の壁もあります。日本語でも英語でも意味合いが同じなら検索したいところですが、キーワードが一致するかどうかしか判定していない検索ではそれも難しいのです。そもそも日本語などの半角スペースで単語間を分かち書きをしない言語だと、単語分割もうまくいかないこともしばしばあります。どこで単語を区切っていいのかが文脈で異なり、そこを踏まえたキーワードの一致を試みるという仕組みはなかなかうまくいかなかったのです。

ここにきて、検索の仕組みを一変させたのが、Microsoft Graph + ベクトル検索の組み合わせです。Microsoft 365 Copilot が応答に必要な情報取得するために使う検索はベクトル検索がベースとなっています。ドキュメント、文章、単語などすべてをその意味や特徴でそろえた数値の並び(ベクトル)に変換します。これによって意味的に似たデータとして例えば、犬、猫、ペットなどはベクトル空間内で近い位置に配置されます。Copilot への質問もベクトルに変換されます。

Microsoft 365 Copilot のライセンスを持っているテナントでは、メールやチャット、SharePoint のファイルなどMicrosoft 365 に蓄積されているコンテンツに対してセマンティック インデックスと呼ばれる膨大なベクトルが生成されています。ここから質問のベクトルに最も距離が近い(類似する)データを高速で見つけられるようになっています。

つまり従来の検索では不可能だった「文脈の理解」をしたうえでの情報の収集が可能になっているのです。Microsoft Graph による単なるコンテンツの情報だけでなく、そこに関わりのあるコンテンツ同士の関係性やアクセス権限、人とのかかわりなども含めた情報を付加して情報を収集します。

ちなみに、Microsoft 365 では引き続きキーワード検索も行えるためベクトル検索とのハイブリッド検索環境になっています。

Microsoft 365 Copilot 有償ライセンスとセマンティックインデックス

こうした仕組みが使えるのが、Microsoft 365 Copilot の有償ライセンスが利点です。生成AIは、モデル自身がすでに学習している内容以上のことは公開された情報はBingを使って検索できますが、これに加えて有償ライセンスがあれば組織内に蓄積された公けになっていない情報も情報にもアクセスしてその組織ならではの情報が生成できる。しかし、無償版の場合は、あくまでもアクセスできるのは一般的なWebのみで Bing 検索の範疇までとなり、ネットに公開されていない非公開の情報は当然取得できないということです。

そして、組織にはさまざまな人が作ったファイルややり取りした会話などが蓄積されていっています。これはその組織内で汗水たらして試行錯誤しながら醸成してきた知恵やノウハウなどです。ものごとの経緯なども含めてたまっている。畑で例えれば、それぞれの組織ごとに異なる成分の土壌が醸成されているわけで、この養分が組織の財産であり、先人の知恵を有効活用して後人がさらに新たなナレッジを積み重ねていくことで、その組織ならではの文化ともなっていくわけですね。愛社精神とか従業員エンゲージメントにつながっていく話です。

Microsoft 365 Copilot が利用できれば、セマンティックインデックスが生成される。つまりは、膨大な量の情報を生成AI なら効率よく引き出せる可能性が高まります。無論、データ整備は必要ですが(ごみはゴミ箱にすてるとかそういうことです)。だからこそ、ドキュメントのライフサイクル管理としてしかるべきときに破棄するということも視野に入れたナレッジマネージメントが重要なのです。

SharePoint Technical Notes : Microsoft 365 Copilot のセマンティックインデックスとは?

Delve そして Work IQ、Agent 365 

Microsoft はこの Microsoft Graph と組み合わせて独自のAIを開発して、個々のユーザーに最適化したコンテンツを提案していくというコンシェルジュ的な機能を提供していました。「あなたが必要とするファイルは、もしかしてこれではない?」と提案してくれるような仕組みでDelve (デルブ) というアプリとして提供されていました。ただ、このDelve は去年の2024年12月16日をもってシャットダウンされてしまいました。生成AI の登場により、ナレッジマネージメント関連で Microsoft が開発してきた技術はどんどん生成AIベースに置き換わってきている印象があります。以前は、社内版 Wikipedia を独自AIで作らせるような取り組みとして Viva Topics というものがありましたが、Microsoft は生成AIへと大きく舵を取りCopilot へと役割が移管することになり、ついに日本語対応は正式に行われることなく 2025年2月22日にサービスが終了してしまいました。こうしてみると、Microsoft が独自に開発してきたAIの一部については、長らく言語の壁も抱えてきたように思います。

Delve がシャットダウンされて、およそ1年後となる2025年11月の Microsoft Ignite 2025では Work IQ が発表されました。Work IQ は、Delve が進もうとしていた方向性を生成 AI を使って再定義した強力な仕組みととらえることもできるでしょう。

Microsoft Graph の強みを生かし、ユーザー自身の仕事(メール、ファイル、会議、チャットなど)を理解して、先回りして様々なタスクなどを提案したり実行してくたりする仕組みです。単なるファイルの提案でなく、「仕事をしてくれる」というところまで踏み込んでいます。Work IQ によって最適なAIエージェントを提案・支援してくれるということにもなるでしょう。

Microsoft はWork IQ は「知能レイヤー」であるとしています。Work IQ は次の3つの要素から構成されています。

  • データ… Graph から取得する組織内の知識(メール、ファイル、会議、チャットなど)
  • メモリー…ユーザーの好み、習慣、業務、人間関係など
  • 推論…データとメモリーを組み合わせて次のとるべきアクションを予測

Graph が提供するデータに推論に特化した生成AIの力を添えて、エージェントがユーザーの文脈、関係性・意図を理解できるようにするわけですね。

少し前までは生成AIは単なる人間みたいな話し相手だったチャットボットだったものが、「ユーザーに代わって仕事をこなしてくれる」というAIエージェントへと進化しました。

現在、Microsoft 365 ではビルトインのエージェントだけでなく、Copilot Studio などを使ったカスタム エージェントや 3rdパーティのエージェントも利用できるようになっています。がしかし、これだけ多くのエージェントがあれば、どんな時にどのエージェントを使えばいいかユーザーが判断しなくてはならいない。これをそのユーザーの行動などからどんな仕事を日々行っているのかといったことも含めて情報を持っており Work IQは、その場で適切なAIエージェントの提案および実行も含めて面倒を見てくれる。

そしてMicrosoft 365 Copilot ユーザーが様々なLLMモデルを使用した複数のエージェントを安心・安全に使えるように組織として統制・管理し、発見・展開を支援する仕組みとして Agent 365 が登場したわけです。

SharePoint Technical Notes : Microsoft Agent 365 とは?

Microsoft が考えている構想は、実によくできているなと感じます。

ということで、有償の範囲と無償の範囲は、検索を軸にしたストーリーで見るとわかりやすいように思います。

無償版で十分という場合は、組織内の情報をうまく再利用するという土壌が醸成されていないか、そういったことを必要とする業務スタイルにないのかもしれません。全体最適化の話の一部で、部分最適化ではないので。

Adobestock_572683802

Microsoft Ignite 2025で Microsoft Agent 365 がアナウンスされました。

ここでは Agent 365 といったいどういったものなのかの概要をつかめるように要点を抑えていきたいと思います。

なお、現時点では Microsoft Agent 365 はプレビューでありいち早く機能を利用してみるには Frontier プレビュープログラムに参加する必要があります。また利用するテナントでは少なくとも1つの Microsoft 365 Copilot ライセンスを持っており、 Microsoft Agent 365 を Frontier で有効化する必要があります。詳しくは下記のリンク先を参照してください。

Microsoft Agent 365の概要 | Microsoft Learn

Agent 365 とは?

IDC (International Data Corporation) によると2028年までに作成されるエージェントは13億にも上るだろうと予測されています<IDC レポート #US53361825>。

エージェントの技術革新と共に、増え続ける組織内のAI エージェントの制御手段を整備することは急務です。つまり「単にエージェントを導入して終わり」ではなく、それらを制御し、監視し、保護し、より効果的に活用するための適切なツールも同時に整える必要が3あります。そうした背景から登場したのが Agent 365 です。

Agent 365 はエージェントの制御プレーン (Control Plane) であるとMicrosoft の資料には書かれているのですが、プレーンという言葉に馴染みのない方もいるでしょう。プレーンとはシステムやネットワーク内でのある役割を担う「層」のことを呼びます。役割が階層化されていているときには「レイヤー」といいますが、特に階層があるわけでなく、特定の役割を担う機能などの集まりを表現する際には「プレーン」呼びます。

さて、話を戻しましょう。

Agent 365 はエージェントの制御プレーンであり、エージェント制御を目的とした機能群として提供されます。

企業がユーザー管理に使っている既存インフラをエージェントに対しても対応できるように拡張するものです。つまり、Agent 365 は人間の従業員が使っているのと同じレベルのアプリやセキュリティ保護機能をAI エージェントに対しても提供し、安心して業務に取り組めるようにします。AI エージェントは人の代理で動く以上、ある意味「ひと」と同等に管理する必要があるわけですね。

また、Agent 365 が人間の従業員が使っているのと同じレベルのアプリやセキュリティ保護機能をエージェントに対しても提供することで、ユーザーは安心して業務に取り組めるようなります。

Agent 365 には次のMicrosoft のセキュリティと生産性ソリューションが含まれます。

  • Defender

  • Enra

  • Purview

IT部門は Microsoft 365 管理センターでエージェントが管理でき、Microsoft 365 アプリ上だけでなく、他の業務フローにおいても人間のマネージャーと一緒にコラボレーションできるよう設定できます。

Microsoft Ignite 2025 のブレイクアウト セッション

Agent 365 を理解するのに Microsoft Ignite 2025 のセッションの中でも「Explore Microsoft Agent 365 security and governance capabilities (BKR269)」から情報を抜粋しながら情報を整理していきます。このセッションは概要をつかむのにとても分かりやすかったためです。

エージェントはユーザーと同じく保護される必要がある

20251125_113737

  • ユーザーとエージェントのやり取りの保護
  • エージェント同士のやり取りの保護
  • エージェントがモデルポイズニングを媒介しないように保護

ユーザーとエージェントのやり取りは保護する必要があります。Agent 365 ではどのエージェントにアクセスできるかを管理して、プロンプトやレスポンスを保護することで、プロンプト インジェクションのようなユーザーからのエージェントへ侵害を防ぎます。

エージェント同士のやり取りについては、どのエージェント同士が接続できるのかをガードレール設定し、Agent to Agent 間の接続を保護し、エージェント間の過剰共有を防ぎます。

エージェントがモデルポイズニングの媒介にならないように保護する必要もあります。Copilot自体はモデルポイズニングされるような経路は存在しませんが、3rdパーティ製エージェントや外部LLM との連携ではこの点は考慮する必要があります。そのため、どのエージェント、どのLLMを許可するのかを制御できる必要があるのです。

Agent 365 の5つの機能

Agent 365 にはデジタル資産全体のエージェント管理に必要なすべての機能が含まれています。機能は次の5つに分類できます。

  • レジストリ (Registry)…Agent 365 は組織が利用するエージェントすべてのインベントリを提供するレジストリを持つ

  • アクセス制御 (Access Control)…エージェントの権限管理やリソース保護を行う

  • ビジュアル化 (Visualization)…エージェントと人、データの関係をマッピングして、その行動やパフォーマンスをリアルタイムで監視できる

  • 相互運用 (Interop)…エージェントをアプリやWork IQ と連携させることができるようにして、エージェントが人間の業務フローに参加して業務の文脈が理解できるようにする

  • セキュリティ (Security)…エージェントを標的とした脅威を防止・検出・対応できる「脅威からの保護」とエージェントが作成・使用するデータを過剰共有・漏洩・リスクのある行動から守る「データセキュリティ」の提供

Agent 365 のエコシステム

Agent 365 は Microsoft だけのものではなく、どんなエージェントにも対応できるようになっています。既にパートナーエコシステムを構築してきており、現在も日々、広がっているそうです。

20251125_135240

パートナーは自社開発しているエージェントを Agent 365 SDK と統合することで、Microsoft 365 の Defender, Entra や Purview といったセキュリティ製品もその SDK の一部として機能するため、その恩恵を受けることが可能になります。

エージェントIDの保護

これからは、従来のユーザーID管理と同様にエージェントにIDを持たせることによる管理も必要になってきます。

  • エージェントIDとライフサイクルの管理
  • 誰がエージェントを作成し管理できるのかの統制 (ポリシー定義)
  • エージェント権限の管理
  • アプリ、ツール、システムや他のエージェントにアクセスするエージェントアクセスの保護 (リソースアクセスの保護)
  • 悪意のあるもしくはコンプライアンスに準拠しないトラフィックからのエージェントの保護 (インターネット脅威からの保護)

Microsoft Entra Agent ID

20251125_140942

Microsfot Entra にはエージェントごとにエージェントIDが登録できます。

20251125_160201

20251126_153704

エージェントごとに割り振られるエージェントIDとレジストリを使うことで、すべてのエージェントのライスサイクルをワークフローで発見・管理し、アクセスガバナンスも行えるようになります。

Agent ID はユーザーIDと同じように扱うことができるため、エージェントの権限やライフサイクルも管理も可能です。エージェントID があるので条件付きアクセス、ID保護も可能できます。

条件付きアクセスによるトラフィックス フィルタリングを使えば、エージェントのリソースアクセスも保護できます。

現在、Entra 条件付きアクセスではポリシーの割り当て対象にエージェントを選べるようになっています。20251125_164427

展開のための Agent blueprint

20251125_151046

エージェント展開のために、Agent blueprintというものがあります。これはエージェント展開のための青写真、つまりは設計図です。

アプリケーション内に複数のエージェントが含まれていることはよくありますが、例えば、すでにセキュリティ コパイロットには12のエージェントがあるような状況です。とはいえ、増え続ける個々のエージェントのインスタンスを大規模に管理するのは大変です。

そのため大規模展開では、テンプレート化された設計図(blueprint)が必要であり、これがないと管理が破綻することになってしまいます。

実際には、事前にこれから展開するエージェントに対するAgent Blueprint (エージェントの名前、所有者、アクセス権限など) を定義して、これに基づいてエージェントにアクセストークンを発行することになります。Blueprint に紐づくサービスプリンシパルを作成して、資格情報(クライアントシークレットやマネージドID)を設定します。このトークンがあることでエージェントが認証・認可を受けてドさできるようになるわけです。

最終的には組織で利用可能なエージェントとして Microsoft 365 のレジストリエントリとして登録しまするこれによって管理者はエージェントの存在を把握し、アクセス制御・監査・ポリシーが適用できるようになります。

なお、Agent blueprint の作成などは、Agent 365 CLI を使います。

詳しい情報は次のリンク先を参照してください。

Microsoft Entra - Agent registry

Entra ID にはエージェント レジストリがあります。これには3つの目的が存在します。

  • エージェント フリート全体を可視化
  • エージェント同士で発見させる
  • エージェントの許可と検疫を行う (どのエージェントを許可してどのエージェントを隔離するかを制御)

ちなみに、現時点では Entra Agent ID を持つエージェントがすでにある場合と、自分で登録する Agent ID とがあります。

前者は Copilot Studio で作るエージェントが該当します。後者は、開発者やユーザーが自分で登録するエージェントで、外部ベンダーが提供するエージェントの登録などです。

これに加えて シャドーエージェントも見つけてくれるようになるとのこと。組織内で非公式に導入しているエージェントも見つけて管理できるようにするということですね。

エージェント管理に関する役割

AIエージェント管理には「スポンサー」という役割が登場します。Entra ではエージェント管理のための管理者が3つあり、その一つです。

  • 所有者
  • スポンサー
  • マネージャー

所有者

Agent blueprint と Agent ID の運用管理担当。技術管理者。

スポンサー

ビジネス担当者。技術的な管理アクセスはせず、アクセスレビュー、インシデント対応などエージェントの目的とライフサイクルの決定に責任を持つ。スポンサーとなっているユーザーの退職や移動では別の人やグループに役割を継承させる必要がある。

マネージャー

組織階層内のエージェントの担当をする個々のユーザー。Entra レポート エージェントのアクセスパッケージを要求できるユーザー。

スポンサーという概念が含まれるのが興味深いですね。技術者とビジネス的な判断をする人を分離するための考え方です。

[参考] Microsoft Entra エージェント ID の管理関係 (所有者、スポンサー、およびマネージャー) - Microsoft Entra Agent ID | Microsoft Learn

まとめ

Agent 365 はこれから増え続けるエージェントを適切に管理するための仕組みであり、組織はAI エージェントに関してはベスト・オブ・プリードの考え方で導入していくことになるため、部分最適化を合理化しつつ、組織としては統合とガバナンスを考慮しなくてはいけない。その根っこの部分を Agent 365 で管理していくことになるということです。ここには、Mirosoft が持つ既存のインフラソリューションとして、Entra, Purview, Defender をうまく取り込んで有効活用する形にしているのは、うまい戦略だと思います。

参考情報

コース紹介

弊社「オフィスアイ株式会社」では、Microsoft 365 に関するオリジナルトレーニングを提供しています。AI エージェントのナレッジ基盤となる SharePoint を中心に、Microsoft Copilot Studioによるエージェント開発入門コースや Microsoft Purview による機密情報保護やライフサイクル管理など体系的に学べます。

【オフィスアイ株式会社】Microsoft 365 関連研修コース

2025年11月24日 (月)

Adobestock_1564169999

検索というとこれまでの「キーワード検索」を思い浮かべる人も多いでしょう。ファイル名や文章内に合致するキーワードがあるかどうかで検索する方法です。一方、Microsoft 365 Copilot は単なるキーワード検索ではなく、意味や文脈を理解して情報を探し出せます。

これを支えているのがセマンティック インデックスという技術です。マンティック インデックスはMicrosoft 365 専用の技術ではなく、自然言語処理(NLP)や検索エンジンの分野で広く使われている一般的な概念です。

キーワード検索とベクトル検索

Microsoft 365 の検索では従来はキーワード検索を行ってきました。検索キーワードに合致するコンテンツを探してくるという検索方法です。

キーワード検索といえば、SharePoint はオンプレミス時代から長年、独自の検索エンジンを持っています。また Outlook は Outlookで独自の検索の仕組みを持っていたりします。各サービスで検索機能がバラバラであるため、2019年に Microsoft 365 の共通検索基盤として Microsoft Search が登場しました。Microsoft Search では SharePoint 検索を内包しています。この検索では SharePoint だけでなく、自身のメールボックスや Teams 内の会話なども幅広く検索できるようになっています。Microsoft 365 Copilot の検索 (https://m365.cloud.microsoft/search) や SharePoint スタートページ(https://<テナント名>/_layouts/15/sharepoint.aspx)からの検索は Microsoft Search によるコンテンツの横断的な検索ができます。SharePoint サイト上ではサイト内に閉じた検索、ライブラリやリストではライブラリ内またはリスト内に閉じた検索になります。検索範囲に関しては下記の記事も参照してください。

SharePoint Technical Notes : SharePointの検索は検索を開始する場所によって検索範囲が異なる

Microsoft 365 Copilot が行う検索

一方でMicrosoft 365 Copilot が応答に必要な情報取得するために使う検索はベクトル検索がベースとなっています。ドキュメント、文章、単語などすべてをその意味や特徴でそろえた数値の並び(ベクトル)に変換します。これによって意味的に似たデータとして例えば、犬、猫、ペットなどはベクトル空間内で近い位置に配置されます。Copilot への質問もベクトルに変換されます。

Microsoft 365 Copilot のライセンスを持っているテナントでは、メールやチャット、SharePoint のファイルなどMicrosoft 365 に蓄積されているコンテンツに対して、セマンティック インデックスといわれる膨大なベクトルが生成されています。ここから質問のベクトルに最も距離が近い(類似する)データを高速で見つけられるようになっています。

つまり従来の検索では不可能だった「文脈の理解」をしたうえでの情報の収集が可能になっているのです。

ちなみに、Microsoft 365 Copilot Chat のみ(いわゆる有償版ライセンスを持っていない場合)では、組織内のデータを探しに行くことはできず、あくまで参照するのは Web上のオープンな情報のみです。 

インデックスの種類

そもそもインデックスとは、検索を素早く正確に検索できるようにするための「情報の索引」のようなものです。Microsoft 365 では検索エンジンのクローラーが定期的に実行され、インデックスが作成・更新されています。

Microsoft 365 には次の2種類のインデックスが存在します。

  • キーワードインデックス
  • セマンティックインデックス

キーワード インデックス

キーワード インデックスは、従来から SharePoint などで作成されてきているものであり、ファイルの内容などをもとにインデックスを作成します。検索エンジンは定期的に Microsoft 365 内のコンテンツをダウンロードして解析して、言語判定、単語分割、アクセス権限情報の抽出、情報同士の関連性など踏まえてインデックスに登録していきます。この情報をもとに検索する際に用いられるキーワードと照合して合致する情報のうち、サインインしているユーザーが閲覧権限を持っているコンテンツを結果として表示するわけです。ただし、この単語の分割が、半角スペースによる分かち書きをしない言語の場合は文脈で分割する必要があるのですがこれがうまくいかないケースも多い。また、キーワードが一致するかどうかのみを見るので、同じ意味の違う言葉などのいわゆる "ゆらぎ" をうまくとらえることができないという問題を抱えています。

セマンティック インデックス

一方のセマンティックインデックスでは単語だけでなく意味や文脈も理解できるようにベクトル変換によりインデックスが作られるようになっており、例えば先ほどと同様に「議事録」と検索すると、今度は「ミーティングメモ」「会議記録」など、意味が近いファイルも見つかります。

このようにセマンティックインデックスとは、Microsoft 365内のファイルやメール、チャットなどの情報を、AIが「意味のつながり」で整理・分類できるようにベクトルを使ったインデックスが生成されます。ですから自然言語での検索も可能になっており、たとえば「先月の売上データを見せて」と言われたとき、Copilotは「売上」「先月」「データ」という言葉の意味を理解し、関連するExcelファイルやレポートを探します。

ちなみに、セマンティック インデックスはユーザーレベルのインデックスとテナント レベルのインデックスの2種類があります。自分のOneDriveに作成したドキュメントや編集したもの、自身のメール、チャットなど個人に紐づくコンテンツはユーザーレベルのインデックスとして即座に作成されます。一方のテナントレベルのインデックスとは SharePoint サイトに格納されているファイルが対象であり、そのファイルに対して2人以上と共有されている場合にインデックスが作成されます。このことについては下記リンク先にインデックスの更新という情報があり詳しくかかれています。

Microsoft 365 Copilotのセマンティック インデックス作成 | Microsoft Learn

ここに記載されている内容を確認すべく試すと確かにサイトレクションの管理者として自分だけしかアクセスできない1人ぼっちファイルを作成しても、意味的な検索はできませんでした。共有リンクも含めて二人以上と共有するとインデックスが作られるようです。ただし、原文では英語の方も同様に「サイトに追加された新しいドキュメントは毎日インデックスが作成されます」と書かれているのですが、こう書かれていると即時ではなく一日一回インデックス生成がされているイメージです。そんなにタイムラグがあるって本当かな? と試したのですが、2人以上で共有されていれば即座にインデックスは作られているようです。すでに共有されているサイトに新規に追加しても、1人ボッチファイルから共有変更した場合も即時でした。この辺りはドキュメントが古いままアップデートされていないのかもしれません。このブログを書いている時点の上記記事の最終更新日は 2025年3月8日で、すでに半年以上は経過しています。

Copilot 検索

2025年4月よりMicrosoft 365にCopilot検索が正式に導入されました。このCopilot 検索は従来のキーワード検索に加えてAIによる「意味の理解=セマンティック検索」を組み合わせたユニバーサル検索体験を提供するものです。


💡Point: Copilot検索は、Microsoft 365 Copilotのライセンスを持つユーザーであれば追加費用なしで利用できます。Microsoft 365 Copilot Chat のみで有償ライセンスがない場合はオンにできません。


<pCopilot検索はトグルメニューでオン/オフに切り替えが可能です。オフにすると従来通りのキーワード検索となります。人物の詳細検索などはキーワード検索の方が優れている場合もあるため必要に応じて切り替えて利用します。

Copilot 検索では自然言語での検索が可能になっています。

20251124_112438

20251124_112551

Microsoft 365 Copilot における検索

ここまでを簡単にまとめておきましょう。Microsoft 365 Copilot のシステムでは従来のキーワード検索とセマンティックインデックスを用いたベクトル検索の両方のハイブリッドな検索の仕組みを利用できるようになっています。セマンティック インデックスを持てるというのが、Microsoft 365 Copilot の有償版ライセンスの有意な点の一つです。

検索方式 特徴 使用例
キーワード検索 正確な単語に一致する情報を探す SharePointの検索、Outlookの検索など
セマンティック検索 意味や文脈に基づいて関連情報を探す

Copilotによる自然言語検索およびCopilot 検索での検索

参考情報

2025年11月16日 (日)

2025年11月13日付で、Microsoft 365 Copilot が Data Loss Prevention(DLP)ポリシーをサポートするようになりました。

Learn about the Microsoft 365 Copilot location | Microsoft Learn

概要

Microsoft Purview のDLPによって秘密度ラベルが適用されているアイテムを Microsoft 365 Copilot のプロンプトに対する応答要約内で使うことを防止できるようになりました。

これをセットアップするには、DLPポリシーを作成して処理したくない秘密度ラベルを含むファイルなどを除外するよう、 Microsoft 365 Copilot ポリシーのローションにある「コンテンツを含む」>「秘密度ラベル」を追加します。

結果の引用元には引き続き情報が表示さますが、実際には当該コンテンツは使われません。

Copilot の処理に使われると問題となる情報の主な例は次の通りです。こうした情報は秘密度ラベルを適切に適用して保護する必要があります。

説明
個人情報 社員名簿、住所、電話番号、給与情報など。個人情報保護法やGDPRに抵触する可能性がある。
契約・取引情報 顧客との契約書、価格表、見積書。競合に知られると価格戦略が崩れるリスクがある。
内部方針・計画 来期の事業計画、マーケティング戦略。公開されると競争優位性を失う。
認証情報やシステム構成 サーバー設定、APIキー、パスワード。これが漏れるとセキュリティ事故に直結する

ポリシー構成上の注意

  • Microsoft 365 Copilto ポリシーの場所はカスタム ポリシーテンプレート内でしか利用できません。
  • Microsoft 365 Copilot ポリシーの場所を選択すると、他のポリシーはすべて無効化されます
  • DLPアラート、DLP通知とポリシーシミュレーションモードはサポートされます
  • DLPポリシーに対する更新は Microsoft 365 Copoilot 内に反映するまで、最大4時間かかります。

カバー範囲

Microsoft 365 Copilot ポリシー場所は Copilotが複数のエクスペリエンス間で処理する特定のコンテンツをサポートします。

  • 保存されているファイルおよびアクティブに開いているファイル
  • 2025年1月以降に送信されたEmail
  • カレンダー招待はサポートされない。またローカルファイルもサポートされない
  • Word, Excel, PowerPoint のようなMicrosoft 365 アプリ内のCopilot 用のDLPはファイルをサポートされるが、Emailはサポートされない

Word, Excel, PowerPoint 内でファイルが開いていて、DLPポリシーでMicrosoft 365 Copilotによって処理されないように指定している秘密度ラベルが適用されているとき、これにのアプリ内のスキルは無効化されます。

20251116_202804

管理単位のサポート

Microsoft 365 Copilot ポリシーの場所では管理単位はサポートされません。

サポートされる条件とアクション

Microsoft 365 Copilot ポリシーの場所はでは次の条件とアクションをサポートします。

  • 条件: コンテンツを含む>秘密度ラベル
    選択した秘密度ラベルがファイルや Exchange 内のE-mail で内で検出された時
  • ポリシーアクション: Copilot がコンテンツをしよりするのを防止する
    アイテムのコンテンツが Copilot によって処理されず、応答サマリでも利用できないようにする。ただし、応答の引用元としては当該アイテムが使われる可能性がある

ポリシーの作成結果

Microsoft Purview でカスタムのDLPポリシーを作成してみました。まず場所として “ Microsoft 365 Copilot および Copilot Chat” を選択します。

20251116_144303

ポリシー設定でまず条件として「コンテンツに含まれている」で「秘密度ラベル」を指定します。また、操作では、「 Copilot によるコンテンツの処理を制御する」を選択しています。

20251116_172809

以上の設定内容で DLPポリシーを新規に作成しました。

20251116_173513

ポリシーを作成してからしばらく経ったあと、実際に Microsoft 365 Copilot Chat で当該の秘密度ラベルが適用されているファイルを使った実験をします。今回は “花 - Demo.pptx” を使います。

20251116_193546

このファイルをCopilot Chat のコンテキストIQから参照して、プロンプトを作成します。すると、「組織のセキュリティポリシーにより取得できませんでした。そのためファイルの要約を行うことができません」というメッセージが表示されます。ちなみに、ソースとして利用しようとしたファイルは表示されていますが、処理はされていません。

20251116_193524

弊社関連コースのご案内

弊社では Microsoft Purview によるMicrosoft 365 内ファイルおよびメールに特化した、機密情報保護やコンテンツのライフサイクル管理機能についてじっくり学べる研修をご用意しています。

Photo

2025年11月14日 (金)

Adobestock_1515892969

Microsoft の SharePoint ショーケースとして「メタデータとナレッジ エージェントとが Microsoft 365 Copilot の応答精度をいかに高めるか」に関する記事が公開されています。ここでは主要な点について考察を交えながら解説します。

SharePoint Showcase: How Metadata and the Knowledge Agent Elevate Microsoft 365 Copilot Responses | Microsoft Community Hub

メタデータの重要性

Microsoft は2025年11月から SharePoint ナレッジエージェントだけでなく Microsoft 365 Copilot にもメタデータを理解・活用できる機能を追加します。つまり、Microsoft 365 Copilot Chat などでファイルやフォルダー、ライブラリ参照時するときに、メタデータを含めた文脈でAIが推論できるようになるということです。

メタデータはファイル本文以外の次のような情報のこと言います。

  • ファイル名
  • ファイルの拡張子
  • ファイルの作成者・更新者
  • ファイルの作成微・更新日
  • ドキュメント ライブラリ内の列の値

ここでの注目点はドキュメント ライブラリ内に追加する任意の列の値も生成AI(microsoft 365 Copilot や SharePoint ナレッジエージェント)が利用できるようなったということです。

SharePoint の場合は、ファイルの仕分け方はファイルの要件ごとにライブラリを複数に分け、ライブラリ内で共通する列を追加することです。そのうえで必要があればさらにフォルダーで物理的に仕分けていくという流れです。ここがファイルサーバー的な発想でのバイアスに縛られていると、ついライブラリ自体はフォルダーと表現されないのでルートフォルダー的なとらえ方をしてしまい、単一のライブラリ内に異なる種類・性質のファイルをフォルダーで仕訳けていくという使い方をしてしまいがちです。しかし、そもそも SharePoint での考え方はサイトやライブラリという粒度でまずは情報を仕分け、フォルダーにあまり依存せずにりようできるようになっています。

SharePoint エージェントによるメタデータ管理機能の強化

さて、現在、SharePoint ナレッジエージェント(プレビュー)ではライブラリ内のファイルをもとに列を提案し、Autofillまで設定できる仕組みとして「ライブラリの整理」という機能がありますが、従来からさらにメタデータ管理を強化していこうとしているわけです。

SharePoint が取り組んできたこれまでのメタデータ管理の経緯

SharePoint でメタデータ管理というと、最近急にそんなことを言い出したように感じる方もいらっしゃるようですが、メタデータは SharePoint Server 2007から利用できるものであり、この機能強化はその後も継続しています。急に出てきた機能ではありませんし、そもそも SharePoint の根幹機能の一つはドキュメント管理システムです。世の中のドキュメント管理システムは、メタデータを使ってナレッジ管理をしていく製品がほとんどであり、ずいぶん昔からメタデータ管理に取り組んでいるのです。決して付け焼刃的なものではなく、長年にわたり Microsoft も試行錯誤してきた経緯があります。メタデータ管理で最も厄介なのが、だれが妥当なタグ付けをしていくのかということです。ドキュメントアップロードと同時に関連付けたCSVファイルから属性情報を付加するような機能を持つ製品もあります。要は、人が手動で設定していくというのが基本です。ただ、昨今のように組織が抱えるコンテンツ量が膨大になると、もはや人海戦術的なアプローチだけでは不十分であり、そこにきて AIによってメタデータを付加していこうという流れが生まれるのは必然的なことです。ただ、Microsoft が開発してきたAI機能はたとえば、SharePoint Syntex などでのモデル生成機能などがありましたが、定型的な請求書フォームなどのデータはある程度は対応できたものの、非定型な(非構造化)契約書などのフォーマットの場合、モデル作成するためのメタデータ抽出の学習はなかなか骨の折れる作業であり、しかも英語のみが対応している状況が続き、日本語対応はできないままでした。ですが、ここに生成AIの登場です。生成AIの場合は、非定型的なデータ(非構造化データ)から文脈を読み取るのが得意であり、言語の壁も比較的簡単にクリアしてきています。SharePoint ナレッジエージェントが持つ「ドキュメントの整理」機能で列を自動生成し、かつ値もAIにより本文から抽出してくれますが、日本語でも動作します。つまり、自動的にメタデータを抽出して適切に設定することができるようになったわけです。

ファイルの数が少なければ、フォルダーの階層構造で仕訳けていくのが比較的容易ですが、コンテンツ量が膨大になっていくと階層は複雑化し、かつ分類も複数のフォルダー分類にまたがる可能性があるものもでてくる。そうなると、どの階層をたどればよいかが判別しにくい。しかも、ファイルを探すのに、手がかりはフォルダー構造とファイル名頼みで、人は「暗記」に頼るしかなくなる。それでも覚えきれず、フォルダーなどのショートカットを作成して、決まった場所を使い続けていくことになります。ユーザーがアクセスする範囲は局所的になってしまう。ファイルサーバーだと検索なども十分にできませんし、しかもバージョン管理機能がないので似たファイル名でバックアップを山ほど作成して、どれが正規版かわからない。適切に削除もされないので、古い情報もたまっていくばかり。日の目を見ないコンテンツもあるでしょうし、似たようなファイルが複数作成されているかもしれない。組織のナレッジがうまく蓄積・整理・共有できないという状況になってしまいます。

組織に蓄積されているコンテンツは本来は、各従業員が蓄積してきたノウハウや知恵・知識の宝の山です。これを生かしてよりよい仕事の仕方ができるよう工夫する糧になるはずで、ひいては人材を大切に育成することにもつながっていくはず。

こうした情報を埋もれさせず、捨てるべきは捨て、秘匿するものは秘匿するという仕組みを作ってくために必要な情報の一つがメタデータです。ようはファイルにタグ付けを必要な数だけ行えばファイルの格納場所に依存せずに、いろいろな切り口で情報を見つけることができるようになる。このようにまずは組織が抱えるコンテンツを把握できるような見通し確保できないと、組織の宝となるナレッジを十分に利用できません。ちなみに、SharePointは最初のバージョンから検索エンジンを持っており、蓄積+検索を視野に入れています。ファイルサーバーに不足している「大量コンテンツをいかに再利用しやすくするのか」という点にフォーカスを当てて、製品が進化してきています。

検索がうまくいかないという声をX.comでも時々目にしますが、まったくヒットしないということはないはずで、たぶん、検索範囲というものがあることを知らないだけではないかと思います。その点は以前の記事で取り上げているのでよかったらどうぞ。

SharePoint Technical Notes : SharePointの検索は検索を開始する場所によって検索範囲が異なる

メタデータによりMicrosoft 365 Copilot による組織内のデータを高精度で取得できる

さて、冒頭でも述べましたが2025年9月には SharePoint ナレッジエージェントはライブラリの列をメタデータとして利用できる機能がロールアウトされました。2025年11月には、さらに Microsoft 365 Copilot にも拡大されるということです。

メタデータのある SharePoint コンテンツをグラウンディングするエージェントは、メタデータがあることで、本文だけでなく、タグや分類、業務的背景も含めて、推論できるようになるのでより精度の高い回答が導けます。これはMicrosoft エコシステム内で構築されたAIだからこそ実現できる独自の強みと言えます。

LLMs は確率論的である。これをメタデータを組み合わせて決定論的なものに変容させる

そもそも、LLMというものは性質上、確率論的です。LLMsが生成するものは、データのパターンに基づくものにすぎません。

しかし、法務や財務、エンジニアリングやヘルスケアなどの特定の産業では決定論的な回答が求められます。つまり、生成AIから得られる回答は常に一定である必要があるわけです。常に同じ条件なら同じ答えが返ってくる。さらに言えば事実に基づいて再現性があり、曖昧さや揺らぎがないことを求められるわけです。

しかし、AIを完全に決定論的に追及していくことは、LLMの持ち味である創造性や微妙なニュアンスが犠牲になることにつながりる。となれば、解決策の一つは、AIが安全に動作できるような決定論的な環境を整えることです。

SharePoint のコンテンツに対してメタデータによって情報を付け加えることでAIの創造性をしっかりと維持したまま情報の境界線を明確にできる。メタデータは “アンカー(錨)” のような役割を果たし、Copilot やエージェントが創造性を保ちつつ、信頼性の高いビジネス向けの回答を提供する一助となります。

LLMs は本質は常に確率論的ですが、構造化されメタデータが豊富な環境では、ビジネス上のニーズに応じて、AIはよりはるかに高い精度での応答が可能になるのです。

実際に原文の記事では、メタデータとして列を追加している場合と追加していない場合とでCopilotの解答の精度の違いを実験しています。メタデータの有無によりかなり結果が変わってきます。

フォルダー構造と「複数のライブラリ+メタデータ」

従来通りファイルサーバーと同様にフォルダー構造を使うほうが良いのか、メタデータを使うほうが良いのかという議論は、よく話題に上がります。私としては、これまでもこのブログ、拙筆の書籍、弊社の研修、コミュニティ勉強会などでも一貫してメタデータを組み合わせることの重要性は説明してきています。

ただ、このようにメタデータの重要性を説明すると「愛さんは、フォルダーは嫌いなんでしょう?」と声をかけられることがあります。これは単に個人的な好みで好きとか嫌いという話ではなく、いかに業務を合理化するかという話にすぎません。どうしても新しい概念が登場すると大抵の人は「とっつきにくさ」があるため、あまり考えずに今まで慣れている「フォルダー」作成をしがちなです。そのためフォルダーを作らなくても済むように一度よく考えてみて欲しい、という啓蒙的な観点でフォルダーはなるべく持たせないようにしましょうと言っているだけなのです。

いくつか現場を拝見する際に、業務の内容によっては従来通りフォルダー構造にして "場所" で格納場所を覚えてそこから必要な情報を掘り起こしていく方が向いているケースももちろんあります。こうしたケースでは、コンテンツを格納するスピード感が優先され、整理整頓する時間が十分に取れないことがよくあります。それでも、精度が多少低くともある程度は生成AIが情報を検索してくれるでしょうから、人の手で探すよりは Microsoft 365 Copilot の有償版をうまく活用するのが吉と出ると思います。

ただ、多くの人が「探す」ことに時間を費やすことが多い、手順書や手続き、仕様書、社内規程、法定保存文書(契約書、見積書、請求書など)、教材などは、探す時間を短縮しかつより正確な情報を取得できるようメタデータを活用できるのが望ましいと思っています。

適材適所でうまく使い分け、業務によっては従来通りのフォルダー構造が良ければそれを使えばいいし、それでも「探す時間」がかかることが業務効率の低下につながっているようなケースではサイトやライブラリの分け方を再考して、メタデータを活用する方向で舵を切りたいところです。

機密情報保護とコンテンツのライフサイクル

最後に付け加えておくのが、機密情報保護とコンテンツのライフサイクル管理です。

Copilot が組織の重要情報をもとに不用意に回答を作成しないようにMicrosoft 365 ではファイル単位で「秘密度ラベル」というのもを付加できます。この秘密度ラベルもファイルに対するメタデータの一種です。ラベルの設定によってはファイルを暗号化でき、社外にデータが持ち出されても正規のユーザーでないとファイルを開けないようにできます。また、機密情報が含まれているメールを外部に共有できないようにするといったことも可能です。

ライブラリ単位で既定の秘密度ラベルを設定しておくことも可能で、新規に格納したファイルは既定で常にライブラリに指定した秘密度ラベルが自動適用される。そのため、このライブラリは機密情報を格納する場所にしよう! というように決めておけます。フォルダーではなくライブラリ単位であることに注意してください。

またこの秘密度ラベルは SharePointサイトに適用することも可能です。ラベルによっては共有リンクのオプションを自動的に変更したり、コンテンツのダウンロードを禁止するような設定が可能です。

また、コンテンツのライフサイクル管理は重要です。ようは、寿命を決めてしかるべきタイミングできちんとコンテンツを削除するという話です。ファイルサーバーだけでは、これが適切にはできなかったのですが、SharePointではこうしたライフサイクル管理が可能です。一定期間は削除できないとか、期限が来たら削除できるようになる、もしくは自動的に削除する、Power Automate のフローで削除の判断をするなどできます。

こうした機密情報保護やコンテンツのライフサイクル管理は SharePoint 単独ではなく Microsoft 365 に含まれる Microsoft Purview と共に管理していくことになります。こうした管理を組み合わせれば、SharePoint + Purview で電子帳簿保存法にもしっかりと対応できます。

さらに、Microsoft 365 Copilot 有償ライセンスを持つ組織であれば、SharePoint サイトのガバナンス管理機能が強化されます。サイトのライフサイクル管理も可能で、使わなくなったサイトは一定期間サイト管理者から応答がなければ、読み取り専用に変えるとか、アーカイブしてストレージコストを抑えるといったことも可能です。

こうした一連の管理タスクなども踏まえて Microsoft 365 Copilto を利活用を推進できるのが望ましいといえます。

弊社で用意しているオリジナル研修

弊社では、こうしたMicrosoft 365 および Microsoft 365 Copilot の利活用から運用管理を考えた研修コンテンツのラインナップを取り揃えています。

お問い合わせや研修のお申込みは次のリンク先からお願いいたします。