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 ファイルおよびメールに対する機密情報保護と情報ガバナンス～
実行後は元のURLにアクセスすると 404 Not Found エラーになります。URLを変更したためそのページは存在しないといわれるのです。
