FessのMicrosoft 365クロールでPurview機密ラベルを扱う

Microsoft 365データストアのOneDriveDataStoreに、Microsoft Purviewの機密ラベルを読み取り、ラベルに応じてクロール結果を制御する変更が入りました。OneDrive、SharePointの文書ライブラリー、Microsoft 365グループのドライブで、本文を取り込まない運用や対象から外す運用を選べます。

有効化とポリシー例

初期値はsensitivity_label_enabled=falseです。データストア設定のパラメーター欄に、1行ずつ次のように設定します。

sensitivity_label_enabled=true
sensitivity_label_policy.Highly Confidential=skip
sensitivity_label_policy.Confidential=no_content;restrict:{group}legal@example.com

この例ではHighly Confidentialとその子ラベルを取り込まず、Confidentialとその子ラベルは本文を取得せず、法務グループに絞ります。indexは通常の取り込み、skipは除外、no_contentは名前などのメタデータだけの取り込み、restrictは閲覧ロールの絞り込みです。

ラベルのID、名前、親ラベル、暗号化を示す@protected、残りを表す*をルールに利用できます。複数ラベルの結果は厳しい側へ組み合わせます。ルールが不正な場合はクロールを停止するため、実際のラベルと権限を用意してから設定します。

権限と取得対象

ファイルの機密ラベル取得には既存のFiles.Read.Allを使います。ラベルの名前、親子関係、暗号化設定を読むには追加でSensitivityLabel.Readが必要です。定義を取得できない場合、基本的にはそのラベル自身のIDと*だけで一致判定します。名前や親ラベルによる規則を安全に解決できない場合は失敗ポリシーへ進みます。

初期設定の取得対象はOffice形式とPDFです。対象ファイルごとにGraphへの追加リクエストが発生します。sensitivity_label_extensionsで対象拡張子を指定できます。取得APIは古いラベルを再抽出し、Microsoft 365側のメタデータを更新する場合もあります。

制限はACLとの共通部分

restrictは既存ACL、デフォルト権限、クロール設定の権限から作るロールを狭めます。新しい閲覧権限を与える設定ではなく、共通するロールがなくなると取り込みません。Graphから暗号化ラベルの許可ユーザー一覧を取得できないため、管理者が対応するロールを指定します。グループ経由ではなく直接権限を与えたユーザーが除外される場合にも注意してください。

必要ならスクリプトでsensitivity_label=file.sensitivity_label_namesとマッピングできます。検索APIへ返す場合やフィールド検索に使う場合は、対応する追加フィールド設定も必要です。

暗号化ファイルと失敗時の扱い

定義を取得できる暗号化ラベルのファイルは、個別ルールがない場合、原則として本文なしで取り込みます。Graphが返すファイルは暗号化されたままで、本文を抽出できません。定義を取得できないとこの暗号化判定が使えない場合があります。

sensitivity_label_failure_policyの初期値skipは、ラベルを取得できないファイルを失敗URLとして記録して取り込みません。index_without_labelへ変えると取得できた情報で処理を継続するため、意図した制限を適用できない可能性があります。二重キー暗号化のファイルは423 Lockedで失敗ポリシーへ進みます。

このPRの検証はGraphの模擬応答によるもので、実テナントの検証は行われていません。変更を含むMicrosoft 365プラグインを用意し、少数のファイルでラベル・権限・失敗URLを確認してから対象を広げてください。

利用できるバージョン

Fess 15.9.0に含まれる予定の機能になります。現時点では、まだ、リリースしていないので、今後のテストで変更される可能性もあります。

関連PR

Fessのカナ表記と長音記号の揺れを検索時に吸収する

Fessの日本語検索で、カナの一部の表記揺れと、長音記号の代わりに使われたダッシュを吸収する変更が入りました。「ラヴ」と「ラブ」、「サ―バ-」と「サーバー」のような違いを検索しやすくします。

今回増えた正規化

標準のtitle、content、important_contentで使う辞書は、これまでもひらがなや小書き文字、半角カナを大きな全角カタカナへ変換していました。今回、ゐ・ゑ、小さいヵ・ヶなど、変換されず残っていた文字を補っています。

ヴ、ゔ、半角のヴ、ウやうに結合濁点を付けた表記も、ブなどに統一します。*_jaフィールドの日本語辞書にもヴ系の変換を追加しますが、形態素解析に必要なひらがなと小書き文字はそのまま保持します。

カナの後のダッシュを長音として扱う

新しい文字フィルターで、カナに続く―、−、全角の-などをーへ変換します。対象は標準のインデックス用・検索用アナライザーです。新規インデックスでは標準設定として適用し、機能を有効にする追加スイッチはありません。

ASCIIの-や、漢字・英数字の後のダッシュは対象にしません。テスト-ケース、東京-大阪、2026−10−02を一律に長音へ変換しないためです。また、複合語の形態素解析を崩す可能性があるため、この長音フィルターはjapanese_analyzerには追加しません。

既存環境へ反映する

既存インデックスの解析設定と辞書は更新だけでは変わりません。メンテナンスの再インデックスで「辞書のリセット」を選び、新しい設定と辞書で作り直す必要があります。

辞書のリセットは管理画面で加えたmapping.txtやja/mapping.txtの編集も上書きします。独自の変更がある環境では、内容を保存してから再構築してください。

今回の変更は「取り扱い」と「取扱い」、あるいは任意の長音の有無を全て吸収する同義語辞書の追加ではありません。日本語フィールド全体のひらがな・カタカナ統一も行いません。適用後は実際の文書を使い、ヒット数やハイライト、複合語への影響を確認するとよさそうです。

利用できるバージョン

Fess 15.9.0に含まれる予定の機能になります。現時点では、まだ、リリースしていないので、今後のテストで変更される可能性もあります。

関連PR

FessでAmazon BedrockをRAGと埋め込みに利用する設定

Fess 15.9向けのドキュメントに、Amazon BedrockのLLM・埋め込みプロバイダーの設定が追加されました。fess-llm-bedrockを使い、チャットはConverse API、文書チャンクの埋め込みはInvokeModel APIで実行します。

前提とインストール

プラグインはFess 15.9以降、Java 21以降を対象とします。利用リージョンでモデルへアクセスできるAWSアカウントと、モデル呼び出し用の認証情報が必要です。Fessのバージョンに合うプラグインを配置して再起動します。現時点の最新リリース15.8.0へそのまま適用する手順ではありません。

チャットの設定

管理画面の「システム」>「全般」、またはsystem.propertiesでプロバイダーを選びます。

rag.llm.name=bedrock

fess_config.propertiesではチャットを有効にし、リージョンとモデルを設定して再起動します。

rag.chat.enabled=true
rag.llm.bedrock.region=us-east-1
rag.llm.bedrock.model=us.amazon.nova-2-lite-v1:0

チャット自体の初期値は無効です。Bedrock側のリージョン初期値はus-east-1、モデルは上記のNova 2 Liteの米国クロスリージョン推論プロファイルです。モデルとリージョンは実際に利用できる組み合わせへ変更してください。リージョンはこの設定から取得し、AWS_REGIONは参照しません。

APIキーの初期値は空で、その場合はAWS認証情報を解決しSigV4署名を使います。IAMロールかFess実行ユーザーの共有認証情報を使う構成を検討できます。必要な権限はbedrock:InvokeModelとbedrock:InvokeModelWithResponseStreamです。推論プロファイルを使う場合は、ルーティング先のモデルにも権限が必要になります。IAM Identity CenterのSSOプロファイルには対応しません。

文書チャンクの埋め込み

こちらはsystem.propertiesに設定します。チャットの設定ファイルとは異なり、fess_config.propertiesへ書いても読み込まれません。

content_chunker.enabled=true
content_chunker.embedding.name=bedrock
content_chunker.embedding.dimension=1024
content_chunker.embedding.bedrock.region=us-east-1
content_chunker.embedding.bedrock.model=amazon.titan-embed-text-v2:0

Bedrock埋め込みのモデル初期値はTitan Text Embeddings V2です。Titanは256・512・1024次元を利用できます。Cohere Embed v3は1024次元、v4は256・512・1024・1536次元で、モデルが返せる次元数と設定を合わせる必要があります。埋め込みは子JVMで実行するため、WebプロセスだけのJVM認証情報では届かない場合があります。

制限と運用上の注意

Cohere v3は1テキスト2048文字までで、プラグインは自動短縮・分割しません。ストリーミングは開始前のリクエストを再試行できますが、回答が流れ始めた後の失敗は再試行しません。

APIキーはチャット用ならfess_config.properties、埋め込み用ならsystem.propertiesの専用キーで指定すると管理画面のシステム情報でマスクします。環境変数やJVMシステムプロパティ経由のキーはそこでマスクされないため、長期キーをその方法で渡す運用は避けてください。fess-storage-s3と併用する場合は、AWS SDKの版を合わせるためプラグインも一緒に更新します。

利用できるバージョン

Fess 15.9.0に含まれる予定の機能になります。現時点では、まだ、リリースしていないので、今後のテストで変更される可能性もあります。

関連PR