SharePoint Onlineでカスタムページテンプレートからページ／ニュースを作成すると、Site Assets（サイトの資産）内に作られるサブフォルダー名がページタイトルではなくGUIDになる――そんな挙動に遭遇すると、運用や整理が一気にやりづらくなります。本記事では、なぜ起きるのかの捉え方と、現場で事故らない回避策・運用設計を具体的にまとめます。
起きていることを短く整理（結論から）
結論として、カスタムページテンプレート経由で作成したページの資産フォルダーがGUIDになる挙動は「現行の動作（仕様側）」として扱われ、フォルダー名をページタイトルに戻すことはサポートされていない、という前提で考えるのが現実的です。
- Microsoft提供の既定テンプレート：Site Assets配下のフォルダー名がページタイトル（またはページ名に近い文字列）を反映しやすい
- カスタムページテンプレート：資産管理用にGUIDのフォルダーが作られることがある
- 後からフォルダー名だけをページタイトルに合わせる：リンク切れや参照不整合の原因になりやすく、基本的に避けるべき
そのうえで、業務上の落としどころは「公式テンプレートへ寄せる」か「GUID前提で運用を組み替える」かの二択に近くなります。
現象の全体像：どこにGUIDが出るのか
SharePointのモダンページでは、ページ内に画像やファイルを挿入した際に、裏側でSite Assets（サイトの資産）ライブラリにファイルが置かれるケースがあります。特に「ローカルからアップロードして貼る」「ページ編集中にドラッグ＆ドロップする」などの操作では、ページに紐づく保存先が自動で作られることが多く、そこでフォルダー名の差が表面化します。
| 観点 | 既定テンプレート（Microsoft提供） | カスタムページテンプレート |
|---|---|---|
| Site Assets配下のフォルダー名 | ページタイトル（または近い名称）になりやすい | GUIDになりやすい |
| 運用上の見た目 | 直感的で探しやすい | 人間が見ても判別しづらい |
| 衝突（同名）への耐性 | 運用次第で衝突し得る | GUIDでユニーク性が高い |
| 後からの改名 | 推奨されない（参照が壊れる可能性） | 推奨されない（参照が壊れる可能性） |
ここで重要なのは、「フォルダー名がページタイトルかどうか」は表示上の都合であり、SharePoint内部の“ページと資産の紐づけ”は別のIDやメタデータで動いている、という点です。見た目の分かりやすさと、内部の一意性・整合性はトレードオフになりやすく、カスタムテンプレートでは内部整合性が優先される形になっている、という捉え方をすると整理しやすくなります。
なぜGUIDになるのか：よくある理由を噛み砕く
「前はページ名だったのに、ある時期からGUIDになった」「テンプレートを作り直しても改善しない」という場合、現場目線では不具合に見えます。ただ、GUID化には実務的な理由がいくつか考えられます。
同名衝突を避けるため（運用が大きいほど起きやすい）
ページタイトルは人間にとって分かりやすい一方で、次のような状況で衝突しやすい名前でもあります。
- 同じタイトルのニュースを複数回出す（例：月次報告）
- タイトルを後から変更する（ページ自体の識別子としては不安定）
- 多言語や表記揺れ、記号・絵文字などが混ざる（フォルダー名として安全に変換しづらい）
GUIDはこの問題をまとめて回避できます。テンプレート経由で“自動生成”の度合いが高い場合、衝突回避の設計が強く出るのは自然です。
既定テンプレートとカスタムテンプレートで内部のひも付け処理が違う
Microsoft提供の既定テンプレートは、SharePointの内部処理（メタデータやコンテンツ生成フロー）が既知・最適化されており、ページタイトルをフォルダー名に反映しても整合性を保ちやすい作りになっている可能性があります。
一方、カスタムテンプレートは「見た目や構成をテンプレ化する」ことはできても、内部的な生成フローまで同一にはなりません。その結果、資産格納の段階でページタイトルではなく、内部ID（＝GUID）をキーとしてフォルダーが作られる、という動作になり得ます。
フォルダー名は“後で変わらないID”として扱われやすい
運用では「ページタイトル＝フォルダー名」だと嬉しいのですが、ページタイトルは変更されることがあります。フォルダー名をタイトルにしてしまうと、タイトル変更のたびにフォルダー名を追随させたい誘惑が生まれますが、これが一番危険です。
ページ内に埋め込まれた画像やファイルは、URL参照を持っていることが多く、フォルダーを改名・移動すると参照先が変わってリンク切れになります。SharePoint側がそのリスクを避けるなら、最初からタイトルではなくGUIDで固定する設計は合理的です。
まず確認したい切り分けポイント（「テンプレの問題」か「保存方法の問題」か）
GUIDフォルダーが作られるかどうかは、テンプレートだけでなく「どうやって画像／ファイルをページに入れたか」でも差が出ます。運用を決める前に、再現条件を整理するとチーム内の混乱が減ります。
| 確認ポイント | 見る場所／やること | 示唆 |
|---|---|---|
| ページ作成方法 | 新規ページ／ニュース → テンプレート選択の流れ | カスタムテンプレ経由だけでGUIDならテンプレ起因の可能性が高い |
| 画像の挿入方法 | ローカルからアップロード／Site Assetsの既存ファイルを指定 | ローカルアップロード時のみGUIDが増えるなら運用で回避できる余地がある |
| テンプレの配布状態 | テンプレートの公開・共有設定、作成者権限、サイトのガバナンス | 推奨手順から外れていると挙動差が出ることがある（ただし直してもGUID化が消える保証はない） |
| タイトルの付け方 | 長すぎるタイトル／記号や絵文字／多言語混在 | フォルダー名として安全変換しにくく、GUID化されやすい条件になっている可能性 |
特に、編集者が「画像は必ずドラッグ＆ドロップで入れる」運用になっていると、GUIDフォルダーの増加が加速しがちです。逆に言えば、画像の入れ方を統一するだけで“GUIDフォルダーに触れない運用”に寄せられるケースもあります。
結論として「ページ名に戻す」ことが難しい理由
「GUIDが嫌だから、フォルダー名だけページ名にしたい」という要求は自然ですが、ここには構造的な壁があります。
- フォルダー名は作成時に決まり、参照URLの一部になるため、後から変えるとリンク切れが起きやすい
- ページ内のWebパーツや画像参照は、見た目以上にURLと紐づいている場合がある
- SharePointは内部整合性を優先し、ユーザーが安全に改名できる導線を提供しにくい
どうしても改名・移動を試す場合でも、本番でいきなりは避け、検証環境でページ表示とリンク参照が崩れないかを徹底的に確認してください。ただし、安定運用を目指すなら「改名して直す」より「GUIDでも困らない設計に寄せる」ほうが結果的にコストが小さくなります。
実務での回避策：いちばん事故が少ない順に紹介
公式テンプレートへ寄せる（フォルダー名が重要な組織向け）
「フォルダー名＝ページ名」で運用設計を組んでおり、編集者も多く、資産の探索性が重要な場合は、最もシンプルな回避策はMicrosoft提供の既定テンプレートを使うことです。
- 既定テンプレートに合わせたレイアウト・パーツ配置へ寄せる
- どうしても固有要件がある部分だけ、編集ガイドライン（入稿ルール）で補う
「カスタムテンプレートを捨てる」のではなく、“テンプレートで強制する部分”を減らし、“ガイドラインで揃える部分”を増やすという発想にすると、テンプレ由来の挙動差で詰まりにくくなります。
カスタムテンプレートは使うが、資産フォルダー名には依存しない（おすすめ）
GUIDフォルダーの問題は「フォルダーを人が探す運用」だと痛みが大きくなります。逆に、次のように運用を変えると、GUIDが出ても実害が減ります。
| やること | 狙い | 具体例 |
|---|---|---|
| 画像ファイル名に意味を持たせる | フォルダー名に頼らず検索できるようにする | 2025-05_製品A_リリース概要_01.png |
| Altテキスト／説明を入力する | 検索性・アクセシビリティを上げる | 画像の意味、用途、掲載ページを明記 |
| 「ローカルからアップロード」より「ライブラリから選ぶ」を推奨 | 自動生成フォルダーを増やしにくくする | 事前に画像を専用ライブラリへアップしてから貼る |
| ページ作成フローを統一 | 編集者ごとの差をなくす | ページ作成→素材準備→貼付→公開の手順を固定 |
ポイントは、「フォルダー名の人間可読性」を、ファイル名・メタデータ・検索の仕組みで置き換えることです。結果として、テンプレートの挙動が変わっても運用が壊れにくくなります。
資産は別ライブラリに集約する（画像用ライブラリ運用）
GUIDフォルダーの散在が辛い場合、現場で効果が出やすいのが画像・資料の保存先を「Site Assets」一本にしない運用です。例えば以下のようなライブラリを別途用意します。
- Images（画像）：ニュースやページで共通利用する画像を保管
- Page Materials（素材）：ページ単位の添付素材を保管（ページ名・日付・担当などで整理）
この運用にすると、編集者は「まず素材ライブラリにアップロード」→「ページではライブラリから選択して挿入」という流れになり、結果としてGUIDフォルダーの存在を意識する場面が減ります。
おすすめのフォルダー設計例（画像用ライブラリ内）
Images/
2025/
2025-05/
product-a/
event/
2025-06/
common/
icon/
header/
重要なのは、ページ自動生成の保存先に期待しないことです。保存先をコントロールできる場所（独自ライブラリ）に寄せるほど、運用の再現性が上がります。
ガバナンスとして「GUIDは改名しない」をルール化する
現場で一番起きがちな事故は、「誰かが善意でGUIDフォルダーを改名してしまい、ページ表示が壊れる」パターンです。だからこそ、最初にルールを明文化しておくのが安全です。
| ルール | 理由 | 補足 |
|---|---|---|
| GUIDフォルダーは改名・移動しない | ページ参照（URL）が壊れる可能性がある | 整理したい場合は「専用ライブラリへ寄せる」方向で解決する |
| 素材は専用ライブラリに置く | 検索性と統制が上がる | アクセス権や承認フローも組みやすい |
| ファイル名の命名規則を統一する | 検索で見つかる／再利用しやすい | 日付・案件・用途・連番を含める |
「テンプレートを作り直しても直らない」場合に見るべきポイント
テンプレートを作り直してもGUID化が続く場合、原因は「テンプレートの中身」ではなく、テンプレートを通したページ作成時の内部フローにあります。つまり、個別のテンプレ修正で直るタイプではありません。現場でやるべきことは、次の2つです。
- “戻す”ではなく“影響を減らす”方向へ舵を切る（素材ライブラリ・命名・ガイドライン）
- 作成者体験（編集手順）を統一して、GUIDフォルダーの増え方をコントロールする
カスタムテンプレートは「ページの見た目と構成」を揃えるには強力ですが、資産管理の裏側まで同等になるとは限りません。運用の影響が出るポイントは、テンプレそのものより入稿フローにある、という前提で設計すると失敗しにくくなります。
現場で効く「編集者向け」入稿フロー例（そのまま運用に落とせる）
GUID問題を避けたい編集者が迷わないよう、手順を固定化すると効果が出ます。以下は、チームに配布しやすい形のサンプルです。
推奨フロー（画像が多いニュース／ページ向け）
- ページを作成（テンプレートはカスタムでも既定でも可）
- 本文に入れる画像を先に「Images」ライブラリへアップロード
- ページ編集画面では、ローカルアップロードではなく「ライブラリから選択」で挿入
- 画像のAltテキスト（代替テキスト）とファイル名を整える
- 公開前にスマホ表示・リンク・画像の欠けを確認
このフローが効く理由
- 自動生成フォルダー（GUID）に素材が入りにくくなり、管理がライブラリ側に寄る
- 素材の再利用がしやすくなり、重複アップロードが減る
- 「誰が作っても同じ場所にある」状態になり、引き継ぎが容易
既にGUIDフォルダーが大量にある場合の扱い方
すでにGUIDフォルダーが増えてしまっている場合、焦って整理（改名・移動）をしないのが第一です。代わりに、次のような“壊さない整理”が現実的です。
壊さない整理の考え方
- 過去分は触らない：リンク切れリスクを増やさない
- 今後分の運用を変える：増え方を抑える
- 探し方を整える：検索・ビュー・命名規則で吸収する
例えば、Site Assetsライブラリのビュー（表示）を工夫し、次の項目で見つけやすくします。
- 作成日（いつ増えたか）
- 作成者（誰のページ由来か）
- ファイル名（命名規則が効く）
GUIDフォルダーを「目で探す」のをやめ、「検索で当てる」前提に切り替えるだけでも、運用負担は大きく下がります。
どうしても“フォルダー名＝ページ名”の利便性が欲しい場合の現実解
どうしても見た目の整理が必要な場合でも、SharePointが自動生成するGUIDフォルダーを改名するのではなく、別の場所に“人間向けの整理棚”を作るのが安全です。
現実解：人間向けフォルダーを別に作る
- Images（画像）ライブラリに、ページタイトル（またはページ識別子）でフォルダーを手動作成
- 素材はそのフォルダーに集約してアップロード
- ページにはそのフォルダー内の画像を挿入（ライブラリから選択）
こうすれば、編集者の「探しやすさ」は人間向けライブラリで担保しつつ、SharePointの自動生成領域（GUID）には極力触れずに済みます。
改善要望を出すなら：伝えるべき情報（テンプレ）
この挙動が運用に与える影響が大きい場合、改善要望を出す価値はあります。その際、単に「GUIDが嫌だ」ではなく、次の情報を添えて伝えると通りやすくなります。
- 発生し始めた時期（例：2025年5月中旬以降）
- 再現手順（どのテンプレで、どう作成し、どの操作で画像を入れたか）
- 既定テンプレートでは起きないこと（比較が強い根拠になる）
- 業務影響（例：監査・引き継ぎ・資産整理・誤削除リスク）
- 望ましい挙動（例：ページ名／URLのファイル名をフォルダー名に反映、または設定で選べるようにする）
また、要望は「戻してほしい」だけでなく、選択肢（設定）として提供してほしいという形にすると、仕様上の整合性と両立しやすく、議論が前に進みやすくなります。
よくある質問
GUIDフォルダー名はセキュリティ上の問題になりますか？
フォルダー名がGUIDであること自体は、直ちにセキュリティ問題ではありません。アクセス制御はフォルダー名ではなく権限と共有設定で決まります。ただし、運用上は「どれが何のページか分からない」ことで誤操作（誤削除・誤共有）が起きやすくなるため、そこがリスクになります。
ページタイトルを変えたらフォルダー名も変わりますか？
変わりません。タイトルは表示用に変更されることがあっても、資産の保存先は安定性のため固定されることが一般的です。タイトル変更のたびにフォルダー名が追随すると、参照URLの整合性が崩れるためです。
既存ページのGUIDフォルダーを整理（改名・移動）しても大丈夫ですか？
おすすめしません。ページ内の参照がURLで埋め込まれている場合、改名・移動でリンク切れが起きる可能性があります。整理したい場合は「今後の素材は専用ライブラリへ寄せる」「ファイル名・メタデータで検索性を上げる」など、壊さない方向で対応するのが安全です。
カスタムテンプレートを諦めずに、見た目も運用も両立できますか？
可能です。ポイントは、カスタムテンプレートに期待する範囲を「レイアウト・パーツ配置」に限定し、資産管理は「専用ライブラリ」と「入稿ルール」で担保することです。テンプレートで全部を制御しようとすると、サービス側の挙動変更に弱くなります。
まとめ：最短で運用を安定させるなら
カスタムページテンプレートで作ったページの資産フォルダーがGUIDになる挙動は、現場感覚ではつらいものの、無理に戻そうとして改名・移動に手を出すと、リンク切れなど別の大きな事故に繋がりやすいのが実情です。
- フォルダー名が重要なら、既定テンプレートへ寄せる
- カスタムテンプレートを使うなら、GUID前提で運用を設計し直す（専用ライブラリ＋命名規則＋入稿フロー統一）
- 既存GUIDフォルダーは極力触らず、今後の増え方をコントロールする
「フォルダー名＝ページ名」という前提を捨て、検索性と統制を別の仕組み（ライブラリ・命名・ガイドライン）で担保できると、テンプレートやサービス更新の影響を受けにくい堅い運用にできます。
コメント