先日(2025/12/8)に実施したMicrosoft 365 SharePoint 勉強会の第2回目の資料と録画を公開しています。
2回目のお題は OneDrive (Business) の基礎と最新情報です。
Microsoft 365 Copilot などによる AI エージェントが組織に導入される際に欠かせないのがドキュメント管理であり、その基盤の一つが OneDrive です。同期の話やAIエージェントの今後の展望も含めて説明しています。
今後も不定期で勉強会(無料)を行っていく予定です。ご興味のある方は下記 Connpass のページをご参照ください。
Microsoft 365 SharePoint 勉強会 - connpass
先日(2025/10/31)実施したMicrosoft 365 SharePoint 勉強会の第1回目の資料と録画を公開しています。
初回のお題は SharePoint ナレッジエージェントです。 SharePoint でのナレッジマネージメントに関して機能の紹介だけでなく、今後、ナレッジマネージメントの基盤を十分に管理をしていくうえで何学んでおくべきかについても、弊社で行っている研修を含めご紹介しています。
今後も不定期で無料の勉強会を行っていく予定です。ご興味のある方は下記 Connpass のページをご参照ください。
Microsoft 365 SharePoint 勉強会 - connpass
(補足) 勉強会中に説明している「SharePoint Premium」 は現在、「Microsoft 365 ドキュメントのドキュメント処理」という名称に変わっており、名称自体がいつの間にか消滅しているようです。その前の名称の SharePoint Syntex はまだドキュメントに記載が一部残っています。 なお、11月にはSharePoint ナレッジエージェントは2026年初頭に Microsoft 365 Copilot に全機能を含めるという発表がありました。
Microsoft 365 Copilot などの生成AI およびナレッジマネージメントの観点でのデータ整備が待ったなしとなってきています。
データ整備の観点はいろいろと考えられますが、例えば次の3つの仕組みはいまでこそ Microsoft Purview に役割および機能が移管していますが、実は SharePoint がもともと標準搭載していたものです。
このあたり過去の経緯をご存じない方も多くなっていると思うので、どういういきさつで現在に至っているのかなど踏まえてみたいと思います。
SharePointで機密情報を保護するために行うべきことというのはまずはコンテンツに対する適切なアクセス権限設定を行うことです。不必要にコンテンツの所在を明らかにしないことです。機密情報の存在自体を不必要な範囲に公開しないようにすることで、うまく情報を隠蔽できます。「存在を知らない」物は例えば外部に流出させようがないわけです。
ただし、これだけでは十分な守りとは言えません。実際には情報を持ち出して漏洩させるのは「適切なアクセス権限を持っているユーザー」であるということです。よく顧客リストの流出などがニュースになることがありますが、これも日頃、こうした情報にアクセスできるからこそ、不意もしくは故意に流出させるリスクがあります。
Microsoft Purview につながる機密保持の仕組みが登場したのは、2003年ごろにさかのぼります。Microsoft は Windows Server 2003 向けに、データ漏洩防止 (Data Loss Prevention) を行うためにRights Management Servies (RMS) というサービスをリリースしました。これはサーバークライアント型のモデルとなっており、Information Rights Management (IRM)クライアントというソフトウェアと共に使うようになっており、主にはOffice アプリケーションに追加インストールできるようになっていました。
その後、RMSは Windows Server 2008から Active Directory Rights Manaement Services (AD RMS) と名称を変更し、Active Directoryと統合されます。これがクラウド環境になると Azure RMS が登場し、現在は Microsoft Purview Information Protectionに統合されています。
またIRM機能は Office 2007 以降、Office アプリケーションに標準搭載されるようになります。IRM機能を利用すると、例えば適切な権限を持っていてExcel ファイルは開けるけれど、別名でのファイル保存や印刷ができないよう一部の操作が制限させる。また、適切なアクセス権限を持っていなければ社外にファイルが流失しても暗号化が施されているのでファイルが開けない。というように、適切な権限を持つユーザーが情報流出できないようにファイルを暗号化したり、一部のアプリケーション操作を制限したり、参照できる期限を限定することなどがができたのです。
オンプレミスのサーバーであったSharePoint Server 2007以降、ドキュメントライブラリはIRM機能が統合できるようになっていました。もともとファイル単位での構成が必要なのですが、これをユーザーがファイルごとに判断して利用するのは煩雑で徹底できない。そこで、SharePoint のドキュメントライブラリにIRM設定を行っておくことで、このライブラリにアクセスできるユーザーは印刷ができないなどの一括設定をしておけたのです。
この機能は、現在は Microsoft 365 環境下では Microsoft Purivew で構成・管理する「秘密度ラベル」に移管されています。といっても、いまだにドキュメント ライブラリにはInformation Rights Management の設定は残ってはいます。ですが、この機能は下位互換のために残されていると考えるのが妥当であり非推奨になっています。
余談ですが、このRMSと IRM の仕組みは長年提供されてきましたが、なかなか流行はしなかったのです。理由の一つは「利便性とセキュリティのトレードオフ」にあります。IRM時代は現在の秘密度ラベルに比べるといろいろと運用上の課題も多く、この設定でかえって業務効率が下がるという声も少なくなかったようです。
※当時はRMSとIRMはデモ環境を構築するだけでも、いろいろと構成が難しくとても苦労した覚えがあります。特に一番最初のリリース時などは情報がほとんどなく手探りでの構築でIRMからの認証が通らないとか、内部的にロックボックスができるとか、Microsoft に聞かないとよくわからないことも多かったんですよね。。。今のクラウド環境はそういった悩みがなくすぐ使えるのでいい時代になりました。。。
「セキュリティを高める」ことと「利便性を担保する」ことはなかなか両立しづらいものですが、現在の Microsoft Purviewのアップデートを追かけてみている限り、利便性をうまく担保できるようにずいぶんと改善がされてきているなと感じます。
ということで、Microsoft Purview で利用できる「秘密度ラベル」はもともとはファイル単位で設定するものであり、だれがどの秘密度ラベルを使えるのかは管理者側で決定します。Microsoft 365 環境ではファイル単位での利用以外に、コンテナ単位での利用も可能で Microsoft 365 グループや SharePoint サイトへ適用することもできます。コンテナ単位の場合は、例えばMicrosoft 365 グループの場合は外部のユーザーを追加できないようにするとかプライベートグループを強制するなどできますし、SharePointサイト場合もサイトの共有設定を強制的に厳しいものに変えるとか、ダウンロードを禁止するなどが可能です。Teams Premium のライセンスがあればTeams会議に秘密度ラベルを適用して、会議のオプションをセキュリティレベルの高い設定を自動的に構成したりとセキュリティ機能を統括管理できるようになります。
コンテンツのライフサイクル管理とはファイルが生成されて削除するまでの一生をきちんと面倒を見ましょうという話です。つまり適切に「削除」をしようね、ということです。
SharePoint にはリストやライブラリ単位で設定できる「情報管理ポリシー」というものがありました。このポリシーでは保持期限の設定や監査対象を設定することなどができていました。たとえば、昔は(といっても未だにお知らせリストを使っている組織もあると思いますが)、社内周知には「お知らせ」というリストを使っていましたが、一定期間経過した古いお知らせを自動削除するためにこれを構成することはよくありました。
今も、クラッシクなサイトテンプレートから作成したサイトであればアクセスできます。ただし、昔の名残であり、ほとんどの機能が使えなくなっているので改めて利用する必要はありません。
とはいえ、どんな構成だったかをスクリーンショットで挙げていきましょう。これは手元のMicrosoft 365 環境に残っている昔研修で使っていたサイトです。改めて構成手順を確認してみると、当時は手順がこんなに多かったか! と思いますね。たしか、古い「ひと目でわかる」シリーズには書いていたはず。。
この設定はコンテンツ タイプ単位で構成できるようになっていました。
この画面がポリシーの構成画面ですね。保持期限を有効化したり、監査を有効化したりできます。ちなみに、バーコードとかラベルはOfficeとの連携機能でメタデータを画像として埋め込んで印刷できるようにする機能であり、秘密度ラベルとは関係ありません。これ、研修で説明はしていたけれど、実際に使っていたところはほとんどないんじゃないかなぁ。
保持の構成のところではレコードとか非レコードという言葉が登場しますが、レコードの説明は後ほど説明します。さて保持期間ですが、作成日、更新日などをベースに決定することができ、指定した期限が来ればごみ箱に移動させたり別のトキロに移動させたり、ワークフローを開始したり(このワークフローは 当時あったSharePoint Designerというツールで作るものです)などいろいろと指定できました。
さて、この保持の仕組みは現在は Microsoft Purview のデータライフサイクル管理の機能に移管されています。保持ポリシーや保持ラベルという仕組みです。保持ポリシーや保持ラベルは、一定期間削除させないように内部的にコンテンツを保持したり、一定期間後、自動削除した利する仕組みを提供します。重要な情報を間違って消してしまった! とか、なんらかの目的で収集した個人情報は一定期間後確実に削除する必要があったり、ある案件で顧客から入手した情報もプロジェクト終了後は速やかに削除しなければいけないのに、うっかり削除せずにいるというケースもあるでしょう。こういう不用意に保持する情報が情報漏洩につながる可能性もあります。また、生成AIのシナリオでいえば、古くなってしました情報が今となっては間違った情報を参照してしまう可能性があるため、古い情報は削除するとかアーカイブするといった対策が必要です。
ちなみに、ファイルレベルでのアーカイブは 2026年初夏あたりにリリースが予定されています。これと保持の仕組みを組み合わせた利用も可能になってくると思います。
もともと、保持の仕組みは各サイト管理者がSharePointサイトごとに設定する必要がありましたが、組織での一元的な管理はできなかったという経緯があります。しかし、現在は Microsoft Purviewへと機能が移管したことで組織全体のポリシー(ルール)を決定して、これを任意のサイトに適用できる。この保持期限の仕組みは、SharePoint だけにとどまらず、OneDrive およびTeams のチャットなどでも利用できるようになっています。たとえば、一定期間経過したら特定のユーザーのチャットを強制削除するような仕組みも構成できます。Microsoft Purview になり一か所からSharePointに限らず、各サービスへのコントロールがしやすくなったわけです。
続いて監査についてですが、これは「誰がいつ、どのコンテンツにどんな操作をしたのか記録する」仕組みのことです。不正アクセスなどを監視するのが主な目的です。オンプレミス時代はSharePoint 上での監査は SharePoint のサイトコレクションごともしくはリストやライブラリ単位でどの項目を監査するのか決定し、監査ログもサイトの管理者が閲覧できるようになっていました。
ですが、この監査機能も現在は Microsoft Purview に移管されています。SharePoint サイトごとに決めていた監査項目も自動的に必要な項目が監査されるようになっており、Microsoft Purview の「監査の検索」から監査ログのレポートが取得できます。
ちなみに、監査ログは SharePoint だけでなく Microsoft 365 の各サービスの監査ログが取得できるようなっており一元的に利用できるようになりました。
SharePoint 側では従来のようにサイトコレクションの管理者が自由にログの確認をすることはできなくなってしまいましたが、監査ログ自体もそもそも機密性の高い情報ではあるため、適切な権限を持つユーザーだけが確認できるようになったとも言えます。
ちなみに、ライセンスによっては監査ログの保持期限は異なりますが、最低180日保持されるようになっています。長いと1年、最大10年まで保持できます(ライセンスによる)。ちなみに、少し前までは標準カントログは90日間保持というルールになっていた時期がありましたが、昨今のサイバーセキュリティ攻撃を鑑み調査のためにログの保持期間を長くするように米国政府がMicrosoft に働きかけ、2023年10月17日以降、どのライセンスでも最低180日保管されるようになりました。
[参考] Microsoft Purview の監査ソリューションについて説明します | Microsoft Learn
SharePoint Server 2007のころからレコード管理という機能があります。レコード管理という言葉を聞きなれない方もいるでしょう。レコード(Record) = 記録 ということで、記録文書と言ったりもします。
国や業界でレコードとする対象が多少異なりますが、日本では一般的に法定保存文書や業務上重要な記録(ここでは主にドキュメント)を法令や社内規程に従って管理することを言います。もともと電子データに限らず紙、マイクロフィルム、磁気テープなどの記録媒体も含まれていますが、ここでは SharePoint を軸に話を勧めたいので、ドキュメントを対象とします。
例えば、電子帳簿保存法で法定保存期間が定められているものとしては、税務関連書類、契約書などありますし、業務遂行や監査に必要な記録としては議事録や品質管理記録などがあります。
こうした一定期間保管すべきものを適切に保管する仕組みが SharePoint のレコード管理という仕組みです。SharePoint Server 2007にこの機能が標準搭載されたのには理由があります。
SharePoint などの文書管理システムではレコード管理システムを搭載する重要性を再認識させる事件がかつてありました。エンロン社の粉飾決算事件です。エンロン社は、2001年に巨額の粉飾決算が発覚し、破綻します。この事件を発端に、企業の内部統制やコーポレートガバナンスを強化が必要であると、アメリカ政府は2002年にサーベンス・オクスリー法（SOX法）を制定します。この法律により、企業は財務データの正確性を確保するために、厳格なレコード管理システムを導入する必要があったわけです。日本では2008年4月から日本版SOX法として JSOXの運用が開始されました。
参考文献
こうした経緯があり、そもそもSharePointはレコード管理システムを備えていたのですが、日本は電子データの扱いに関する法整備が遅れたため、ほとんどこの機能の認知は浸透しなかったのです。特に財務報告の信頼性の確保をする際の電子データの取り扱いに関する法整備は米国と比較するとかなり遅れました。
本格的な電子データ対応への流れは、2015年以です。電子帳簿保存法は1998年に制定はされたもののさまざまな要件が厳しかったのですが、そこから何度も改正されてきました。クラウドの台頭とコロナ禍も後押しすることになり、令和3年に帳簿保存法が改めて改正されてペーパーレス化が加速することになったのです。
ですから、こうした法定保存文書に対応する機能は SharePointは米国に合わせていち早くもっていたのです。先ほど昔の SharePointで使っていた「情報管理ポリシー」でもレコード管理の設定項目があります。
また、以前は SharePoint でレコード管理する場合は、専用の「レコードセンター」サイトテンプレートというものが用意されており、ここでレコード管理を行っていたのです。それがいつしか、どこにレコード管理対象のファイルが格納されていたとしても管理できるように、インプレースレコード管理機能なども登場します。Microsoft 365 の SharePoint サイトもサイトコレクションの管理者なら、「サイトの設定」にある「サイトコレクションの機能」の一覧に今も「インプレース レコード管理」機能があるのがわかるでしょう。
これを有効にするとサイトコレクション単位でレコードをどう扱うかを決めることができるようになっていました。
あとは、ライブラリ単位でインラインレコード管理を有効化するかどうかを決めて、、、という流れですね。
手動でレコード宣言する場合は、ファイルの「コンプライアンス詳細」からレコード宣言します。
(試しに宣言したら、これで以前はファイルの名前の横に鍵のアイコンが表示されていたのですが、今はそういった表示もなくチェックアウトのアイコンになってしまっていました。まぁ、Purview に移管したのでこれは昔の名残ですからね。)
しかし、この機能も現在は Microsoft Purview のレコード管理機能へと移管しており、保持ラベルの拡張機能としてレコード管理ができるようになっています。なお、レコード管理機能は Microsoft 365 E5 を持っていないと利用できないので注意してください。逆に持っているユーザーは利用できますから、せっかくの機能をうまく使ってみて欲しいところです。
レコードとして作成する保持ラベルは、編集のブロックを行えるように設定できます。これを構成すると、サイトコレクションの管理者であっても編集できなくなりますし、バージョン履歴の削除も不可になり、「改ざん防止」が強固なものになります。
レコードの保持ラベルを適用すると錠前のアイコンが表示されるので、ひと目でわかります。
レコード管理するところまでの一連の流れは去年した Japan Microsoft 365 コミュニティカンファレンスのセッションで一通りデモをしているのでよかったこちらもご覧ください。
A13「Microsoft 365 のドキュメント管理徹底詳解 フル機能を使った高度な管理」
参考: Microsoft 365 でのドキュメントとメールのレコード管理 | Microsoft Learn
ということで、私がMicrosoft 365 での Microsoft Purview での機密情報保護やライフサイクル管理の重要性をよく話をしているのですが、これは2007年からずっと説明してきた流れなのです。
電子帳簿保存法対応なども SharePoint + Purview の仕組みで対応可能です。また、Microsoft 365 Copilot を導入する際の組織内のデータ整備にも欠かせないため、ぜひ知見を深めてみてください。
Microsoft Purview へSharePointの持っていた機能が一通り移管され、管理機能も充実してきたので、数年前から弊社でもこれに対応する研修を私の方でオリジナル開発して提供しています。
なかなか独学だとわかりにくい部分ですが、研修とフォローアップのコンテサルティングも実施しておりますので、興味のある方はぜひ、弊社サービスをご利用ください。
【オフィスアイ株式会社】Microsoft Purview コンプライアンス入門～Microsoft 365 ファイルおよびメールに対する機密情報保護と情報ガバナンス～
SharePoint サイトにはごみ箱が用意されています。つい先ほど、たまたまなんとなく Microsoft サポート文書でごみ箱の説明を読んでいたら、あれそうだったの? ということが書かれていました。この資料を読んだのももう何年も前で自分が単に忘れているだけかもしれませんが、せっかくなので整理しておこうと思います。
SharePoint サイト内のコンテンツを削除しても即削除されるのではなく、いったんごみ箱に移動してからしばらくの猶予期間ののち実際に削除されるようになっています。
ごみ箱には第1段階のごみ箱と第2段階のごみ箱の2種類があります。サイトコレクションの管理者だけが第2段階のごみ箱にアクセスできるようになっています。
それぞれの名称は次のようにも呼ばれます。
チームサイトだと既定では左側ナビゲーションからアクセスできるのが第1ごみ箱です。コミュニケーションサイトの場合はサイトのコンテンツページからアクセスできます。
サイトのごみ箱はサイト内のメンバーや管理者などのユーザーが共通して利用するところであり、他のユーザーが削除したものも確認できますし、復元できます。
次のスクリーンショットはサイトのごみ箱です。サイトコレクションの管理者としてサインインしているため画面下部には「第2段階のごみ箱」へのリンクが表示されています。
ユーザーがサイトのごみ箱からさらに削除したりサイトのごみ箱を空にすると、いきなり削除ではなく第2段階のごみ箱であるサイトコレクションのごみ箱に移動します。これによってユーザーが間違って削除した場合でも、サイト コレクションの管理者であれば復元できる可能性があるわけです。このようにサイトコレクションのごみ箱はユーザーによる誤操作を救済するセーフティーネットになっています。
ユーザーがサイト内のアイテム(ファイルやフォルダーを含む)を削除するとゴミ箱に移動し、いずれのステージのごみ箱にいても削除してから93日間保持されたのち完全に削除されるようになっています。
つまり、削除してからすぐに93日後に削除されるというカウントダウンタイマーが発動しているような状態です。たとえ、サイトのごみ箱からサイトコレクションのごみ箱に移動したからといっても、元の場所に復元しない限りは、すでに始まっている削除までのカウントダウンがリセットされることはありません。
なお、サイトコレクションのごみ箱についてはサイトコレクションのごみ箱が持っている容量を超えた場合は古いものから削除されるようになっています。
ちなみに、93日というのは1か月を31日で換算して3か月間保持するということです。
ごみ箱内の容量もサイトの容量消費としてカウントされるようになっています。ただし、サイトのごみ箱の容量はストレージ使用量のメトリックス含まれます。しかし、サイトコレクションのごみ箱に移動しているものはサイトのストレージ使用量のメトリックスにはカウントされません。実際にサイトコレクションのごみ箱から削除されて完全削除されるとストレージ使用量のメトリックスに解放された容量が返されます。
先述した通り、サイトコレクションのごみ箱の容量がクォータ(容量の割り当てサイズ)を超過している場合は93日を待たず古いものから削除され始めます。サイトコレクションのごみ箱のクォータはサイトコレクションに割り当てられた容量の2倍(200%)です。
たとえば、サイトコレクションのクォータが100GBなのであれば、サイトコレクションのごみ箱の容量は200GBとなります。これはサイトコレクションのクォータを超えてごみが溜まってもすぐには影響がでないようにするためのバッファーとみるべきで、最終的には200%を超えてしまえば、古いものから削除されていってしまいます。
弊社では SharePoint に関する各種トレーニングをご用意しており、私がテキスト作成および講師を担当しています。SharePointに20年以上携わってきているので、これまでの SharePointの変遷、今後の展望、アンチパターンやベストプラクティスなどを交えながら Teams を使った対面形式講義を行っていまする
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 365 ではキーワード検索が主流でした。しかし、単なるキーワード検索だとどうしても「検索キーワード」の揺らぎが対応しにくいという課題があります。例えば、「ライオン」でも「百獣の王」でも意味は同じなのにキーワードとしては一致しないのでヒットしない。さらには言語の壁もあります。日本語でも英語でも意味合いが同じなら検索したいところですが、キーワードが一致するかどうかしか判定していない検索ではそれも難しいのです。そもそも日本語などの半角スペースで単語間を分かち書きをしない言語だと、単語分割もうまくいかないこともしばしばあります。どこで単語を区切っていいのかが文脈で異なり、そこを踏まえたキーワードの一致を試みるという仕組みはなかなかうまくいかなかったのです。
ここにきて、検索の仕組みを一変させたのが、Microsoft Graph + ベクトル検索の組み合わせです。Microsoft 365 Copilot が応答に必要な情報取得するために使う検索はベクトル検索がベースとなっています。ドキュメント、文章、単語などすべてをその意味や特徴でそろえた数値の並び(ベクトル)に変換します。これによって意味的に似たデータとして例えば、犬、猫、ペットなどはベクトル空間内で近い位置に配置されます。Copilot への質問もベクトルに変換されます。
Microsoft 365 Copilot のライセンスを持っているテナントでは、メールやチャット、SharePoint のファイルなどMicrosoft 365 に蓄積されているコンテンツに対してセマンティック インデックスと呼ばれる膨大なベクトルが生成されています。ここから質問のベクトルに最も距離が近い(類似する)データを高速で見つけられるようになっています。
つまり従来の検索では不可能だった「文脈の理解」をしたうえでの情報の収集が可能になっているのです。Microsoft Graph による単なるコンテンツの情報だけでなく、そこに関わりのあるコンテンツ同士の関係性やアクセス権限、人とのかかわりなども含めた情報を付加して情報を収集します。
ちなみに、Microsoft 365 では引き続きキーワード検索も行えるためベクトル検索とのハイブリッド検索環境になっています。
こうした仕組みが使えるのが、Microsoft 365 Copilot の有償ライセンスが利点です。生成AIは、モデル自身がすでに学習している内容以上のことは公開された情報はBingを使って検索できますが、これに加えて有償ライセンスがあれば組織内に蓄積された公けになっていない情報も情報にもアクセスしてその組織ならではの情報が生成できる。しかし、無償版の場合は、あくまでもアクセスできるのは一般的なWebのみで Bing 検索の範疇までとなり、ネットに公開されていない非公開の情報は当然取得できないということです。
そして、組織にはさまざまな人が作ったファイルややり取りした会話などが蓄積されていっています。これはその組織内で汗水たらして試行錯誤しながら醸成してきた知恵やノウハウなどです。ものごとの経緯なども含めてたまっている。畑で例えれば、それぞれの組織ごとに異なる成分の土壌が醸成されているわけで、この養分が組織の財産であり、先人の知恵を有効活用して後人がさらに新たなナレッジを積み重ねていくことで、その組織ならではの文化ともなっていくわけですね。愛社精神とか従業員エンゲージメントにつながっていく話です。
Microsoft 365 Copilot が利用できれば、セマンティックインデックスが生成される。つまりは、膨大な量の情報を生成AI なら効率よく引き出せる可能性が高まります。無論、データ整備は必要ですが(ごみはゴミ箱にすてるとかそういうことです)。だからこそ、ドキュメントのライフサイクル管理としてしかるべきときに破棄するということも視野に入れたナレッジマネージメントが重要なのです。
SharePoint Technical Notes : Microsoft 365 Copilot のセマンティックインデックスとは?
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 が提供するデータに推論に特化した生成AIの力を添えて、エージェントがユーザーの文脈、関係性・意図を理解できるようにするわけですね。
少し前までは生成AIは単なる人間みたいな話し相手だったチャットボットだったものが、「ユーザーに代わって仕事をこなしてくれる」というAIエージェントへと進化しました。
現在、Microsoft 365 ではビルトインのエージェントだけでなく、Copilot Studio などを使ったカスタム エージェントや 3rdパーティのエージェントも利用できるようになっています。がしかし、これだけ多くのエージェントがあれば、どんな時にどのエージェントを使えばいいかユーザーが判断しなくてはならいない。これをそのユーザーの行動などからどんな仕事を日々行っているのかといったことも含めて情報を持っており Work IQは、その場で適切なAIエージェントの提案および実行も含めて面倒を見てくれる。
そしてMicrosoft 365 Copilot ユーザーが様々なLLMモデルを使用した複数のエージェントを安心・安全に使えるように組織として統制・管理し、発見・展開を支援する仕組みとして Agent 365 が登場したわけです。
SharePoint Technical Notes : Microsoft Agent 365 とは?
Microsoft が考えている構想は、実によくできているなと感じます。
ということで、有償の範囲と無償の範囲は、検索を軸にしたストーリーで見るとわかりやすいように思います。
無償版で十分という場合は、組織内の情報をうまく再利用するという土壌が醸成されていないか、そういったことを必要とする業務スタイルにないのかもしれません。全体最適化の話の一部で、部分最適化ではないので。