SharePointのドキュメントライブラリで、Policy259.docxのようにファイル名末尾へIDを付けてもfilename:*259では検索できない――この“あるある”は、検索エンジンの仕様を知ると腑に落ちます。末尾IDに頼らず、関連文書を確実に束ねて孤立文書（オーファン）を防ぐ実務的な方法をまとめます。
SharePointで「ファイル名末尾（サフィックス）ID」がワイルドカード検索にヒットしない理由
結論から言うと、SharePointの検索はファイルシステムのように「ファイル名を1本の文字列」として扱っているわけではありません。検索対象はインデックス化された“用語（トークン）”で、ワイルドカード（*）も基本は前方一致（プレフィックス一致）を目的に設計されています。そのため、filename:*259のような末尾一致（サフィックス一致）狙いの検索は期待どおりに動きません。
MicrosoftのKQL（Keyword Query Language / KeyQL）の説明でも、ワイルドカードは「単語の先頭から一部を指定して前方一致させる」用途であること、そしてワイルドカードを先頭に置く（先頭*）形の前方一致はサポートされないことが明記されています。つまり、*259のような“後ろ側を固定して前を任意”という検索は、SharePoint検索の得意分野ではありません。
なぜ「259Policy.docx」だと見つかって「Policy259.docx」だと見つからないのか
ユーザー体験としては不思議ですが、仕組みで見ると単純です。
259Policy.docxのようにIDが先頭にあると、検索クエリをfilename:259*のように書けます。これは前方一致なのでヒットしやすい。Policy259.docxのようにIDが末尾にあると、やりたいのはfilename:*259ですが、これは末尾一致なのでヒットしにくい。
さらに、検索はインデックス（全文検索インデックス）に格納された“個々の用語”に対して一致判定します。ファイル名がどのように分割（単語分割／ワードブレーク）されてインデックスされるかによっても、部分一致の期待値が変わります。SharePoint検索は「選んだ語がインデックス上の用語と一致するか」を基本にしているため、従来のOS検索の感覚で末尾一致を当てにするとズレが生まれます。
| やりたいこと | ファイル名例 | 試しがちな検索 | SharePoint検索の結果 | ポイント |
|---|---|---|---|---|
| 同じIDの関連文書をまとめて抽出 | Policy259.docx / Form259.docx | filename:*259 | ヒットしにくい | 末尾一致（サフィックス一致）は非対応 |
| 先頭IDでまとめて抽出 | 259_Policy.docx / 259_Form.docx | filename:259* | ヒットしやすい | 前方一致（プレフィックス一致）は得意 |
結局どうするのが正解？「ファイル名検索だけで解決」を捨てるのが近道
SharePointで“孤立文書（オーファン）”を防ぐ本質は、関連付けのキー（Policy ID）を、検索が得意な場所に持たせることです。ファイル名は人間にとって便利でも、検索やガバナンスの軸としては弱い。ここからは、実務で再現性が高い代替策を優先度順に解説します。
推奨策：メタデータ列（例：Policy ID）で関連付ける
最も確実で、運用が破綻しにくいのがドキュメントライブラリに「Policy ID」列（メタデータ）を追加する方法です。検索・フィルター・ビュー・Power Automateなど、SharePointの機能は“列”を軸に最適化されています。ファイル名の末尾にIDを埋め込むより、列として独立させた方が圧倒的に強いです。
列のデータ型は「数値」か「テキスト」か
Policy IDをどう扱うかで、列の型選びが変わります。特に「先頭ゼロがあり得る」「IDにハイフンが入る」などは、後から型変更すると苦労します。
| 要件 | おすすめの列型 | 理由 | 例 |
|---|---|---|---|
| 純粋な連番で、先頭ゼロは不要 | 数値 | 数値として整合性を保ちやすい（範囲や大小比較も可能） | 259 |
| 先頭ゼロが必要／桁数固定 | 1行テキスト | 数値型だと00259の表現が崩れる | 00259 |
| 枝番や記号を含む（改訂版など） | 1行テキスト | 「ID＝文字列」と割り切った方が運用が安定 | POL-259, 259-A |
運用を強くするための設定（必須化・既定値・入力ミス対策）
- 列を必須（Required）にする：アップロード時にID未入力を防げます。
- 選択肢が決まっているなら「選択肢」や「管理メタデータ（タクソノミー）」も検討：表記ゆれを抑制できます。
- ポリシーの“親”情報も一緒に持たせる：例）
Policy名、主管部門、状態（有効/廃止）、廃止日。
検索ではなく「ビュー」と「フィルター」を主役にする
「ポリシー廃止時に関連文書をまとめて見たい」という目的なら、まずは検索よりもライブラリのビューが強力です。ビューはインデックスの遅延影響を受けにくく、操作がブレません。
- ビュー例：Policy ID = 259 のビューを用意して、関連文書だけを一覧表示
- ビュー例：Policy ID が空（未設定）だけを抽出する「監査ビュー」を常設し、オーファン候補を早期発見
サイト横断で検索したい場合は「検索スキーマ（マネージドプロパティ）」を整える
関連文書が複数サイト／複数ライブラリに散らばる場合、KQLのプロパティ検索（例：PolicyID:259）ができると一気に楽になります。そのためには、列が検索インデックスに入るように検索スキーマでマネージドプロパティへマッピングする設計が有効です。マネージドプロパティは、クロールドプロパティの値を検索で扱いやすい形に“昇格”させるイメージです。
- テナントまたはサイトコレクションの検索スキーマで、対象のクロールドプロパティを適切なマネージドプロパティへマップする
- 新規／変更したプロパティを検索で使うには、対象ライブラリ／リストの再インデックスが必要になることがある
設定手順（最短で“現場が回る”ところまで）
「Policy ID列を作る」と言っても、現場が迷わず使える形に落とし込むのが肝です。以下は、ドキュメントライブラリ単位で始める場合の手順です（サイト列やコンテンツタイプに昇格するのは、運用が固まってからでもOK）。
- ドキュメントライブラリの設定から「列」を追加し、列名を
Policy IDにする - 列を必須にする（新規アップロード時の入力漏れを止める）
- 既定のビューに
Policy IDを表示し、一覧画面で見える状態にする - 既存ファイルには、一覧の「グリッドビュー（クイック編集）」で一括入力する
- ビューを2つ作る：「Policy ID未設定」と「廃止（Retired）候補」
検索と抽出に効くKQL例（“覚えておくと得する”最小セット）
SharePoint検索は、自由検索（キーワード）とプロパティ指定（property:value）を組み合わせると精度が上がります。KQLの例として、公式ドキュメントでもfilename:budget.xlsxのような指定が紹介されています。運用に合わせて「列（マネージドプロパティ）」へ寄せると、ポリシー廃止時の一括抽出が安定します。
| 目的 | 例 | 使いどころ |
|---|---|---|
| 特定のファイル名に一致 | filename:Policy259.docx | ピンポイントで探す |
| 拡張子で絞り込み | filetype:docx | Wordだけ拾いたい |
| プレフィックス一致 | filename:259* | ID先頭の命名を採用した場合 |
| 列（Policy ID）で絞り込み | PolicyID:259 | サイト横断で“関連文書だけ”抽出したい |
コンテンツタイプで「ポリシー文書一式」を標準化する
規模が大きくなると、ライブラリごとに列を増やすだけでは統制が難しくなります。そこで効くのがコンテンツタイプです。コンテンツタイプはテンプレートや列（メタデータ）、ワークフローなどを“再利用可能なひとまとまり”として定義でき、部門やサイトをまたいでも同じ入力ルールを適用しやすくなります。
- 例：コンテンツタイプ「Policy（本体）」と「Policy（付属文書）」を用意し、どちらも
Policy IDを必須にする - 例：付属文書は
文書種別（フォーム/チェックリスト/手順書…）を必須にして、後から棚卸ししやすくする
廃止時の実務フロー例（オーファンを出さない）
最後に“廃止時の手順”を決めると、設計が完成します。おすすめは、検索より先にビューで抽出→一括処理の流れを固定することです。
| 手順 | 操作 | 狙い |
|---|---|---|
| 関連文書の抽出 | ビュー/フィルターでPolicy ID=259を表示 | 漏れなく“対象だけ”を確定 |
| 不足の確認 | 文書種別（フォーム等）で並べ替え、必要文書が揃っているか確認 | セット管理の品質担保 |
| 状態更新 | 状態=廃止、廃止日を一括設定 | 後から検索・監査できる形に |
| アーカイブ | Document Set単位、またはPolicy ID単位でアーカイブ先へ移動 | 運用場所を分け、現用を軽くする |
「ファイル名からIDを抜き出して列に自動設定」する（運用負荷を下げる）
人手入力が増えると、必ず未入力や入力ミスが起きます。ここはPower Automateで補うと一気に現場が回ります。代表的な設計は次のとおりです。
- トリガー：ファイルが作成されたとき（または作成/更新）
- 処理：ファイル名（拡張子除外）から末尾の数字を抽出（例：正規表現
(\\d+)$） - 更新：抽出した値を「Policy ID」列へ書き込み
- 例外処理：抽出できない場合は担当者に通知／「要確認」フラグ列を立てる
この設計にしておくと、命名規則を守ってアップロードするだけで自動的に紐づき、廃止時はPolicy IDで一括抽出できます。ファイル名はあくまで入力のヒントで、検索の本命は列、という役割分担ができます。
推奨策：ドキュメントセット（Document Set）で「ポリシー単位」に束ねる
関連文書が「ポリシー本体＋フォーム＋チェックリスト＋参考資料」のようにセットで動くなら、Document Setが非常に相性が良いです。Document Setは、関連文書の集合をひとつの単位（1つのエンティティ）として扱える仕組みで、セットに共通のメタデータを持たせたり、テンプレート文書を自動作成したりできます。
Microsoftの説明でも、Document Setは関連文書をまとめて管理でき、共有メタデータ（shared metadata）を指定できること、既定の文書を自動的に用意できることなどが紹介されています。ポリシー運用の「毎回同じ付属文書が必要」「一括でレビュー/承認したい」「まとめてアーカイブしたい」といった要件に刺さります。
Document Setが向いているケース
- ポリシー番号（Policy ID）を軸に、常に複数ファイルをセットで扱う
- ポリシーごとに、既定のフォームや雛形を自動で揃えたい
- レビュー/承認、アクセス権、保存場所（アーカイブ）を“まとめて”運用したい
Document Set運用のイメージ（例）
| 単位 | 名前例 | 中に入れるもの | 共通メタデータ例 |
|---|---|---|---|
| Document Set | Policy 259 | Policy259.docx, Form259.docx, Checklist259.xlsx… | Policy ID=259, 主管部門, 状態, 改訂日 |
「どうしてもファイル名末尾IDを残したい」場合の現実的な落としどころ
組織の慣習や外部提出の都合で、ファイル名の末尾にIDを残したいケースもあります。その場合でも、末尾一致検索に固執するより、次の“検索されやすい形”へ寄せると被害が減ります。
落としどころ：区切り文字を入れて「IDを単語として切り出しやすくする」
Policy259.docxより、Policy-259.docx/Policy_259.docxの方が“259”を独立した要素として扱いやすくなります。- ただし、これでも
filename:*259が動く保証にはなりません。最終的な担保はメタデータ列に置きます。
落としどころ：命名規則は「人間の可読性」と「プレフィックス検索」の両取りにする
| 命名例 | 人間の見やすさ | プレフィックス検索 | 推奨度 |
|---|---|---|---|
Policy259.docx | ◯ | △ | 低（検索依存に弱い） |
259_Policy.docx | ◯ | ◎（259*で拾える） | 中（暫定策として有効） |
Policy-259.docx | ◎ | △ | 中（補助的に） |
Policy259.docx＋Policy ID列 | ◎ | ◎（列で抽出） | 高（本命） |
孤立文書（オーファン）を出さないための「運用設計」チェックリスト
仕組みを入れても、運用が崩れると結局オーファンは出ます。SharePointで長く回る設計は、次のチェックポイントを満たしているかで決まります。
- 関連付けのキーが列として存在し、必須化されている（Policy IDが空の文書が増えない）
- 監査ビュー（Policy ID未設定、状態=廃止、など）があり、定期的に棚卸しできる
- 自動化（Power Automate等）で入力負荷とミスを下げている
- ポリシー廃止時の手順が決まっている（例：Policy IDで抽出→Document Setごとアーカイブ→状態更新）
よくあるつまずきと対処
検索に出てこない／出るまで時間がかかる
SharePoint検索は、アップロード直後に必ず即時反映されるわけではありません。検索スキーマの変更やマッピングを行った場合は、再インデックス（再クロール相当）が必要になることもあります。検索での抽出に寄せすぎず、まずはビュー・フィルターで確実に運用できる状態を作ってから、必要に応じて検索を強化するのが安全です。
列を作ったのに、入力が徹底できない
このパターンは「必須化していない」「入力導線が悪い」「例外時の扱いが決まっていない」のどれかです。必須化＋自動抽出（できない場合は通知）にすると、現場の負担を増やさずに品質が上がります。
まとめ：末尾ID検索はこだわらず、メタデータで“確実に”紐づける
SharePointの検索は、ワイルドカードで末尾一致検索をする設計ではありません。ファイル名末尾のIDに依存すると、検索漏れ＝オーファンの温床になります。最短で効果が出るのは、Policy IDを列として持たせ、ビュー/フィルターで抽出できる状態を作ること。関連文書が常にセットで動くなら、Document Setで束ねるとさらに強固になります。
コメント