カテゴリ「Microsoft 365 - SharePoint」の374件の投稿 Feed

2025年11月29日 (土)

Adobestock_765845293

SharePoint サイトにはごみ箱が用意されています。つい先ほど、たまたまなんとなく Microsoft サポート文書でごみ箱の説明を読んでいたら、あれそうだったの? ということが書かれていました。この資料を読んだのももう何年も前で自分が単に忘れているだけかもしれませんが、せっかくなので整理しておこうと思います。

SharePoint サイト内のコンテンツを削除しても即削除されるのではなく、いったんごみ箱に移動してからしばらくの猶予期間ののち実際に削除されるようになっています。

ごみ箱には第1段階のごみ箱第2段階のごみ箱の2種類があります。サイトコレクションの管理者だけが第2段階のごみ箱にアクセスできるようになっています。

それぞれの名称は次のようにも呼ばれます。

  • 第1ごみ箱…サイトのごみ箱
  • 第2ごみ箱…サイトコレクションのごみ箱

サイトのごみ箱

チームサイトだと既定では左側ナビゲーションからアクセスできるのが第1ごみ箱です。コミュニケーションサイトの場合はサイトのコンテンツページからアクセスできます。

サイトのごみ箱はサイト内のメンバーや管理者などのユーザーが共通して利用するところであり、他のユーザーが削除したものも確認できますし、復元できます。

次のスクリーンショットはサイトのごみ箱です。サイトコレクションの管理者としてサインインしているため画面下部には「第2段階のごみ箱」へのリンクが表示されています。

20251129_182714

サイト コレクションのごみ箱

ユーザーがサイトのごみ箱からさらに削除したりサイトのごみ箱を空にすると、いきなり削除ではなく第2段階のごみ箱であるサイトコレクションのごみ箱に移動します。これによってユーザーが間違って削除した場合でも、サイト コレクションの管理者であれば復元できる可能性があるわけです。このようにサイトコレクションのごみ箱はユーザーによる誤操作を救済するセーフティーネットになっています。

ごみ箱の保持期限

ユーザーがサイト内のアイテム(ファイルやフォルダーを含む)を削除するとゴミ箱に移動し、いずれのステージのごみ箱にいても削除してから93日間保持されたのち完全に削除されるようになっています。

つまり、削除してからすぐに93日後に削除されるというカウントダウンタイマーが発動しているような状態です。たとえ、サイトのごみ箱からサイトコレクションのごみ箱に移動したからといっても、元の場所に復元しない限りは、すでに始まっている削除までのカウントダウンがリセットされることはありません。

なお、サイトコレクションのごみ箱についてはサイトコレクションのごみ箱が持っている容量を超えた場合は古いものから削除されるようになっています。

ちなみに、93日というのは1か月を31日で換算して3か月間保持するということです。

ごみ箱の容量

ごみ箱内の容量もサイトの容量消費としてカウントされるようになっています。ただし、サイトのごみ箱の容量はストレージ使用量のメトリックス含まれます。しかし、サイトコレクションのごみ箱に移動しているものはサイトのストレージ使用量のメトリックスにはカウントされません。実際にサイトコレクションのごみ箱から削除されて完全削除されるとストレージ使用量のメトリックスに解放された容量が返されます。 

先述した通り、サイトコレクションのごみ箱の容量がクォータ(容量の割り当てサイズ)を超過している場合は93日を待たず古いものから削除され始めます。サイトコレクションのごみ箱のクォータはサイトコレクションに割り当てられた容量の2倍(200%)です。

たとえば、サイトコレクションのクォータが100GBなのであれば、サイトコレクションのごみ箱の容量は200GBとなります。これはサイトコレクションのクォータを超えてごみが溜まってもすぐには影響がでないようにするためのバッファーとみるべきで、最終的には200%を超えてしまえば、古いものから削除されていってしまいます。20251129_222002

バックアップ

サイトコレクション内の全コンテンツは Microsoft側で14日間はバックアップされています。そのため管理者は Microsoft のサポートに連絡して14日以内の間いずれかの時点まで戻すようリクエストできます。しかし、あくまでもサイトコレクション全体の状態を任意の時点に巻き戻すだけであり、特定のファイル、リスト、ライブラリを復元できるわけではないので注意しましょう。

なお14日以上バックアップする必要がある場合は、Microsoft 365 バックアップを利用することを検討しましょう。

参考情報

弊社の研修のご紹介

弊社では SharePoint に関する各種トレーニングをご用意しており、私がテキスト作成および講師を担当しています。SharePointに20年以上携わってきているので、これまでの SharePointの変遷、今後の展望、アンチパターンやベストプラクティスなどを交えながら Teams を使った対面形式講義を行っていまする

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 が考えている構想は、実によくできているなと感じます。

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

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

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 の利活用から運用管理を考えた研修コンテンツのラインナップを取り揃えています。

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

2025年11月 8日 (土)

SharePoint のドキュメント ライブラリにリストと同じくフォーム機能が追加されます。

[参考] UX Updates, AI Actions & Forms in Document Libraries | Microsoft Community Hub

これにより、フォームに追加したファイルをメタデータとともにアップロードできるようになります。

20251108_223250

📅ロールアウト

対象リリーステナントでは2025年10月22日~ロールアウトが開始されています。Microsoft 365 ロードマップでは対象リリーステナント以外でも11月にGA予定です。

実際の操作ビデオは次の通りです。音声はありません。

この機能を利用する場合は対象となるライブラリにアップロード先となるフォルダーを作成することになります。

ちなみに、ドキュメントには言及されていませんが、"ファイルの要求"機能を応用しているのではないかと思います。ファイルの要求機能はフォルダーが必要ですし。

また、フォームのリンクが利用できるのは社内のユーザーのみであり、社外や特定のグループのみが利用できるリンクを作成することはできません。

この機能の利点

ファイルを収集する際にアップロード先のサイトやフォルダーに対して、アップロードする相手となるユーザーへのアクセス許可を付与する必要がありません。

既に冒頭で述べたようにファイルアップロード時に必要なメタデータを付与してもらうことができます。従来のようにアップロード後に対象となるファイルを探してメタデータ(プロパティ)を設定してもらう必要がありません。無論、SharePoint 従量課金サービスのオートフィル機能を使えばAIによる自動設定は可能ですが、こうしたサービス契約がない場合でも、手動で確実にメタデータを追加できるというメリットがあります。

さらに動画でも少し紹介していますが、アップロードできるファイルの種類とサイズの上限を指定できます。

アップロードできるファイルの種類

  • すべて

  • Word

  • PowerPoint

  • Excel

  • PDF

  • Image

  • Media

20251108_144752

アップロードできるファイルの最大サイズ

  • 1 MB

  • 10 MB

  • 100 MB

  • 256 MB

20251108_144805